WO2024031206A1

WO2024031206A1 - Accurate reporting mechanism for bandwidth requirements of optical network unit

Info

Publication number: WO2024031206A1
Application number: PCT/CN2022/000113
Authority: WO
Inventors: 孙武
Original assignee: 孙武
Priority date: 2022-08-08
Filing date: 2022-08-08
Publication date: 2024-02-15

Abstract

Disclosed in the present invention is an accurate reporting mechanism for a bandwidth requirement of each priority queue of an optical network unit in a passive optical network communication system. In the present invention, defects of existing passive optical network protocols in an optical network unit bandwidth requirement reporting mechanism are first analyzed, and it is proposed that an optical line terminal needs to be prevented from remotely estimating the bandwidth requirements of the optical network unit. In the new reporting mechanism, the amount of data received by the input port of a buffer within a period of time instead of the amount of buffer data at a certain moment is reported by the optical network unit, and reported information contains payload and corresponding overhead. After such an improvement, the optical network unit no longer needs to send an idle frame to the optical line terminal, thereby achieving 100% effective utilization of an uplink bandwidth. In addition, the reporting mechanism performs reporting at the entrance of the buffer instead of performing reporting after an uncertain delay after the payload has entered the buffer, and therefore, compared with implementation methods proposed based on the existing passive optical network protocols, the method provided by the present invention can achieve the smallest possible and more stable delay. FIG. 2 is the drawing of the abstract of the present invention.

Description

An accurate reporting mechanism for optical network unit bandwidth requirements

Technical field

The present invention belongs to the field of communications, and relates to the dynamic bandwidth allocation (Dynamic Bandwidth Allocation, DBA for short) of Passive Optical Networks (PON for short), paying special attention to the priorities ( Accurate reporting of Quality of Service (QoS) queue bandwidth requirements. The PON in the present invention includes but is not limited to the following protocols: EPON, 10G EPON, GPON, 10G GPON, etc.

Background technique

As a popular development direction of future access network technology, PON technology has attracted more and more attention from the industry.

A typical passive optical network system mainly consists of an optical line terminal (OLT), an optical distribution network and an optical network unit. The topology is a point-to-multipoint structure, that is, an optical line terminal connects multiple devices through the optical distribution network. optical network unit.

In the above passive optical network system, the optical line terminal is responsible for allocating corresponding time slots to each optical network unit for the transmission of uplink data; while the uplink bandwidth is fully utilized, the uplink data sent by each optical network unit is Conflicts cannot occur; therefore, how to better realize uplink bandwidth allocation in passive optical network systems is one of the most important technologies in passive optical network technology. Generally speaking, the OLT will estimate the bandwidth requirements of various priority queues of each ONU as accurately as possible, and allocate appropriate bandwidth to each queue of the ONU according to the Service Level Agreement (Service Level Agreement, referred to as SLA), and then download the bandwidth. Sent to each ONU for uploading data; the SLA contains information such as the definition of the priority queue QoS type and the maximum allocable bandwidth.

In the existing PON technology, the OLT estimates the bandwidth requirements of various priorities in the ONU through the information reported by the ONU and/or the statistical information on the OLT side. To this end, GPON and 10G GPON implement dynamic bandwidth allocation through the DBRu and Grant mechanisms (see Figure 1): ONU reports the bandwidth requirements of a certain priority queue of the ONU through DBRu, specifically the amount of cached data in Buffer104 , and the OLT allocates the bandwidth after receiving the information reported by the ONU and sends it to each ONU through the Grant in the BWmap (Bandwidth Map) structure; in the EPON and 10G EPON protocols, the MPCP (Multi-Point Control Protocol) protocol is used The REPORT frame and GATE frame (see also Figure 1) are used for dynamic bandwidth allocation: ONU reports the bandwidth requirements of a certain priority queue of the ONU through the REPORT frame, which is also the amount of buffered data in Buffer104, and the OLT receives the ONU report After receiving the information, the bandwidth is allocated and sent to each ONU through GATE frame.

However, the existing ONU reporting mechanism of PON technology still has shortcomings in accurately estimating the ONU's bandwidth requirements: First, the ONU reports the amount of buffered data in Buffer104 at a certain time instead of the input port of Buffer104 over a period of time. The amount of data absorbed within the ONU, the latter represents the actual bandwidth demand of a certain priority queue of the ONU within a period of time; secondly, the information reported by the ONU only includes the demand for payload, and does not include uploading these payloads. The overhead required by the load (overhead), and the actual bandwidth requirement of the ONU is the sum of the payload and the overhead; thirdly, the reporting mechanism of the existing PON protocol is obtained after an uncertain delay after the payload has entered the buffer. Reporting does not occur at the entrance of the buffer, which will inevitably bring more delays; the present invention will adjust the relevant mechanisms in the existing PON protocol to allow the ONU to proactively report a certain priority queue The sum of the payload absorbed and the associated overhead over a period of time; instead of requiring the OLT to remotely estimate the actual bandwidth requirements of the ONU, this method is cumbersome and inaccurate and will cause more delays. .

Contents of the invention

Considering that 10G GPON and GPON better support DBA and QoS, in the following description, the uplink frame structure of 10G GPON will be used as an example; as shown in Figure 3, two ONUs each uploaded an uplink burst ( Also called burst), there is a reserved bandwidth between two uplink bursts, called gap; the head and tail of an ONU burst are the XGTC Header and XGTC Trailer check bits respectively; the ONU burst contains the current ONU The payload of the priority queue (called AllocID in the 10GPON protocol) (XGEM payload as shown in Figure 3) also includes the XGEM Header and DBRu of each AllocID.

The present invention proposes that the bandwidth demand information of a certain priority queue reported by the ONU is not the amount of buffered data in Buffer 104 at a certain moment, but includes the amount of data absorbed by the input port of Buffer 204 within a period of time as shown in Figure 2;

The period of time referred to above refers to a dynamic bandwidth allocation cycle (DBA Allocation Cycle); the length of a dynamic bandwidth allocation cycle can be fixed or unfixed; as shown in Figure 4, generally, in a dynamic bandwidth allocation cycle During the bandwidth allocation cycle, each ONU will allocate bandwidth once and only once in turn. All AllocIDs in each ONU can upload their own upstream payload and overhead in the same upstream burst, and one AllocID contains several XGEM Ports. -ID; each data packet (Service Data Unit, SDU for short) or slice of SDU corresponds to an XGEM Port-ID.

The overhead of the payload can be divided into two parts; one is the overhead related to AllocID, such as the bandwidth requirement DBRu of the QoS queue that each AllocID needs to be reported regularly; in Figure 3, this overhead includes DBRu and XGEM Header; Generally speaking, how many AllocIDs an ONU contains, how many DBRus are reported accordingly; how many XGEM Port-IDs an AllocID contains, how many XGEM Header overheads need to be reported when DBRu is non-zero; It is worth mentioning that EPON and 10G EPON protocols continue to use the simple Ethernet data format, but add the MPCP protocol to implement bandwidth reporting and other functions. They do not introduce universal framing protocols and Port-ID, so in EPON and 10G In EPON, the overhead related to the queue does not include the XGEM Header.

The second is the overhead related to ONU. In Figure 3, this overhead includes XGTC Header, XGTC Trailer and gap; in the dynamic bandwidth allocation algorithm on the OLT side, AllocID is used as the unit for allocating bandwidth instead of ONU; ONU The relevant overhead can be distributed to all AllocIDs of the ONU in a certain way (for example, evenly distributed), or this part of the overhead can be uniformly reserved at the OLT end without reporting it at the ONU end. In the present invention, ONU-related The overhead can be evenly distributed to all AllocIDs of the ONU.

The ONU regularly and proactively reports to the OLT the sum of the payload and related overhead absorbed by its QoS queues within a dynamic bandwidth allocation cycle; these overheads include two parts, one is the overhead related to AllocID, and the other is Is the overhead related to ONU; since each ONU will allocate bandwidth once and only once within a DBA Allocation Cycle, the overhead related to ONU is basically fixed; the overhead related to AllocID depends on the number of AllocIDs contained in the ONU and Each AllocID contains the number of XGEM Port-IDs. A queue needs to report the cost of one DBRu. An XGEM Port-ID needs to report the cost of an XGEM Header when DBRu is non-zero.

Scenarios that require slicing: When a queue on the ONU side receives a data packet and its overhead in a dynamic bandwidth allocation cycle, the total length is Len, and the maximum bandwidth Bmax in the SLA corresponding to the AllocID on the OLT side is less than this length Len, then, these data packets must be sliced and uploaded several times; the slicing process can be realized in the interaction of the OLT-side dynamic bandwidth algorithm and the ONU-side bandwidth demand reporting; for example, the Bmax of the OLT side is (1000+overhead) Bytes, here, overhead includes an ONU-related overhead ov_onu, a bandwidth reporting overhead ov_dbru and an XGEM Header overhead ov_xgem_header, and a queue on the ONU side uploaded a 1500-byte Large packets and no data packets are input in the following cycles; after the AllocID uploads the bandwidth requirement of (1500+overhead), the OLT end will allocate (1000+overhead) byte upload time slots to the AllocID to Upload data, and at the same time, the OLT records in the DBA that the AllocID still has 500 bytes to upload, then the DBRu uploaded by the AllocID becomes (ov_onu+ov_dbru), and the OLT then allocates (500+overhead) time slots to Upload the remaining 500 bytes of the large packet; in order to upload the large packet, the OLT performs a slicing action on the data packet and allocates two XGEM Headers; it can be seen that even if there is no data packet input for an AllocID within a dynamic bandwidth allocation period, The default overhead (ov_onu+ov_dbru) will still be reported. Every time the OLT side slices the data packet to be uploaded, the OLT side must allocate an additional XGEM Header overhead; every time the OLT side slices the AllocID, it must allocate a DBRu overhead and an ONU-related overhead. However, these two overheads are default overheads and are not included in the additional overhead caused by slicing.

From another perspective, overhead can be classified in another way: DBRu overhead and ONU-related overhead can be classified as default overhead; non-default XGEM Header overhead can be defined as Port-ID-related overhead, which can also be divided into There are two categories: one is the overhead related to Port-ID reported by the ONU side, and the other is the overhead related to Port-ID caused by slicing on the OLT side. It can be seen that regardless of the classification, idle frames are not included in the overhead.

When the payload and overhead of AllocID are accurately reported, for fixed bandwidth and guaranteed bandwidth, OLT will accurately meet the requirements of AllocID, and the ONU end does not need to send an idle frame (Idle Frame) to the OLT end; for non-guaranteed bandwidth and the best-effort bandwidth, there is naturally no opportunity to send idle frames; that is to say, from the perspective of ONU reporting, no bandwidth will be wasted; the accurate reporting mechanism at the ONU end proposed by the present invention can maximize the use of the total uplink bandwidth.

In the present invention, the payload is reported to the OLT at the entrance of the buffer; in the implementation of the PON series protocol, the payload is sent to the buffer and after an uncertain delay in the buffer, Only when the payload is reported to the OLT; therefore, in terms of the delay from when the payload is reported to the OLT to when the payload is taken away by the OLT, compared with the method proposed by the protocol, the method of this patent will have a smaller and more efficient payload upload. Stable delay.

The above description of the payload and related overhead can be extended to protocols and application scenarios with similar requirements such as GPON, EPON, 10G EPON and PCIE; the examples used here are used to provide a further understanding of the present invention and constitute the basis of this application. This part is used to explain the present invention and does not constitute an improper limitation of the present invention; any modifications and improvements made within the spirit and principles of the present invention are within the protection scope of the present invention.

Description of drawings

The drawings described here are used to provide a further understanding of the present invention and constitute a part of this application. The illustrative embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation of the present invention. In the attached picture:

Figure 1 is a framework diagram of the ONU bandwidth reporting and OLT bandwidth allocation mechanism of the PON protocol;

Figure 2 is a framework diagram of the ONU bandwidth reporting and OLT bandwidth allocation mechanism proposed by the present invention;

Figure 3 is a schematic diagram of the uplink frame structure of 10G GPON;

Figure 4 is a timing diagram in which each queue is sequentially allocated bandwidth during the allocation period.

Detailed ways

The embodiment uses Figure 2 to describe its implementation framework: OLT201 and ONU202 respectively represent the master node and slave node of the communication system; in the slave node ONU202, Buffer204 is used to absorb the input payload; in the master node OLT201, the dynamic bandwidth The allocation module DBA203 is used to allocate uplink bandwidth to the communication system.

The embodiment uses Figure 2 to describe the dynamic bandwidth allocation process: ONU202 reports the sum of the input payload and related overhead at the entrance of Buffer204; the bandwidth requirement is reported to the DBA203 module through DBRu or REPORT 206; the DBA203 module provides Each priority queue allocates corresponding bandwidth on the upstream channel; the allocated bandwidth is sent to ONU202 through Grant or GATE 205; each priority queue of ONU uploads corresponding upstream data in the allocated time slot.

In the description of this specific implementation, the uplink frame structure of 10G GPON will be used as an example; the bandwidth demand information of a certain priority queue reported by the ONU is not the amount of cached data in Buffer104 at a certain time, but includes the amount of data cached in Buffer104 at a certain time, but includes the following information: The amount of data absorbed by the Buffer204 input port shown in 2 within a period of time; the so-called period of time refers to a dynamic bandwidth allocation cycle (DBA Allocation Cycle); the length of a dynamic bandwidth allocation cycle can be fixed or unfixed; As shown in Figure 4, within a dynamic bandwidth allocation cycle, each ONU will allocate bandwidth once and only once in turn. All AllocIDs in each ONU can upload their own uplink payload and overhead in the same uplink burst. An AllocID contains several XGEM Port-IDs.

The overhead of the payload can be divided into two parts; the first part is the overhead related to AllocID; in Figure 3, this overhead includes DBRu and XGEM Header; how many AllocIDs a certain ONU contains, then how many DBRus are reported accordingly ;How many XGEM Port-IDs a certain AllocID contains, and how many XGEM Header overheads need to be reported when DBRu is non-zero.

The second part is the overhead related to ONU. In Figure 3, this overhead includes XGTC Header, XGTC Trailer and gap; in the dynamic bandwidth allocation algorithm on the OLT side, AllocID is used as the unit for allocating bandwidth instead of ONU; The ONU-related overhead can be distributed to all AllocIDs of the ONU in some way (for example, evenly distributed), or this part of the overhead can be reserved uniformly on the OLT side without reporting it on the ONU side; in this implementation, ONU-related overhead is evenly distributed among all AllocIDs of the ONU.

The ONU regularly and proactively reports to the OLT the sum of the payload and related overhead absorbed by its QoS queues within a dynamic bandwidth allocation cycle; these overheads include two parts, one is the overhead related to AllocID, and the other is Is the overhead related to ONU; since each ONU will allocate bandwidth once and only once within a DBA Allocation Cycle, the overhead related to ONU is basically fixed; the overhead related to AllocID depends on the number of AllocIDs contained in the ONU and Each AllocID contains the number of XGEM Port-IDs. A queue needs to report the cost of one DBRu. An XGEM Port-ID needs to report the cost of an XGEM Header when DBRu is non-zero. Overhead can also be classified in another way: DBRu overhead and ONU-related overhead can be classified as default overhead; non-default XGEM Header overhead can be defined as Port-ID-related overhead.

In the implementation of ONU, compared with the existing methods of PON series protocols, the method proposed by the present invention accurately reports the actual bandwidth demand of a certain priority queue of ONU within a period of time; in accurately reporting the payload and AllocID In the case of overhead, for fixed bandwidth and guaranteed bandwidth, the OLT will accurately meet the requirements of AllocID, and the ONU end does not need to send an idle frame (Idle Frame) to the OLT end; for non-guaranteed bandwidth and best-effort bandwidth, the ONU end Naturally, there is no chance to send idle frames; that is to say, the ONU does not need to send idle frames to the OLT, and no bandwidth will be wasted; at the same time, there will be a smaller and more stable delay when the payload is uploaded from the ONU to the OLT. .

In the implementation of OLT, compared with the existing methods of PON series protocols, the method proposed by the present invention avoids the OLT remotely estimating the bandwidth requirements of the ONU; the original estimation method is complex and inaccurate and will bring more delay.

Claims

A method for accurately reporting the bandwidth requirements of each priority queue of an ONU in a PON communication system; it is characterized by:

This reporting mechanism is improved on the basis of the existing PON protocol to prevent the OLT from remotely estimating the ONU's bandwidth requirements. This mechanism allows the ONU to proactively report the payload and related information absorbed by a certain priority queue within a period of time. The sum of the two overheads is the bandwidth requirement of the ONU; the payload in the bandwidth requirement information of a certain priority queue reported by the ONU is not the amount of cached data at a certain moment in the existing PON protocol, but It is the amount of data absorbed by the priority queue input port in a dynamic bandwidth allocation cycle; in a dynamic bandwidth allocation cycle, each ONU is allocated bandwidth once and only once, and all queues in each ONU can be allocated in the same Upload the respective upstream payload and overhead in the upstream burst.
The method according to claim 1, characterized in that:

The bandwidth demand information of a certain priority queue reported by the ONU not only includes the amount of payload absorbed within a dynamic bandwidth allocation period described in claim 1, but also includes the overhead required to upload these payloads; the overhead of the payload can be divided into It is divided into two parts; one is the overhead related to the priority queue; the other is the overhead related to the ONU.
The method according to claim 2, characterized in that:

The overhead related to priority queues includes the bandwidth requirements of each queue that need to be reported regularly. How many queues a certain ONU contains will report the bandwidth requirements of the corresponding queues. It can also include other queues. Related overhead, for GPON and 10G GPON, the overhead related to the priority queue also includes the overhead of GEM Header, how many GEM Port-IDs does an AllocID contain, and how many GEMs need to be reported when DBRu is non-zero? Header overhead.
The method according to claim 2, characterized in that:

The ONU-related overhead includes a section of reserved bandwidth between two upstream bursts, as well as other ONU-related overhead such as the head and tail parity bits of the ONU burst; the ONU-related overhead can be calculated in some way. The overhead can be allocated to all queues of the ONU for reporting. This overhead can also be reserved uniformly on the OLT side without reporting it on the ONU side.
The method according to claim 1, characterized in that:

When the total length of data packets and their overhead received by a queue on the ONU side during a dynamic bandwidth allocation period is greater than the maximum bandwidth in the SLA corresponding to the queue on the OLT side, then these data packets must be sliced and divided several times. Upload.
The method according to claim 5, characterized in that:

Overhead can be classified in another way: the overhead reported by bandwidth requirements and the overhead related to ONU can be classified as default overhead; the non-default GEM Header overhead can be defined as the overhead related to Port-ID, which can also be divided into two categories , one is the overhead related to the Port-ID reported by the ONU side, and the other is the overhead related to the Port-ID caused by slicing on the OLT side.