OLT and bandwidth allocation method

Abstract

The IEEE-based PON ONU and the ITU-T-based PON ONU are housed in a single OLT. [Solution] The OLT comprises: a first signal processing unit that converts IEEE-based PON bandwidth requests into the following common requests and converts the following common grants into IEEE-based PON transmission permits; a second signal processing unit that converts ITU-T-based PON bandwidth requests into the above common requests and converts the above common grants into ITU-T-based PON transmission permits; and a bandwidth allocation unit that executes the following common DBA based on the common requests and outputs a common grant indicating the allocation result to the first and second signal processing units. The common DBA targets both IEEE-based PON ONUs and ITU-T-based PON ONUs and exclusively allocates the uplink transmission time for each ONU. The common request is a bandwidth request frame with a unified format for the common DBA. The common grant is a transmission permit frame with a unified format for the common DBA.

Description

Technical Field

[0001] The present disclosure relates to an OLT and a bandwidth allocation method.

Background Art

[0002] Patent Document 1 describes a PON system that enables coexistence of various PONs (Passive Optical Networks) with different systems. The PON system of Patent Document 1 includes a first OLT (Optical Line Terminal) and a second OLT, and a first ONU (Optical Network Unit) and a second ONU. The first and second OLTs share the allocation information of the upstream communication bandwidth of the first and second ONUs, and the first OLT allocates the upstream communication bandwidth to the first ONU while avoiding the upstream communication bandwidth of the second ONU.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] In the PON system of Patent Document 1, a plurality of OLTs (the first OLT and the second OLT) are required. Therefore, coexistence of ONUs of PONs with different communication systems in one OLT is not assumed in Patent Document 1. In particular, in IEEE-based PON and ITU-T-based PON, since the upstream communication control methods are significantly different, it has been difficult to accommodate ONUs of both PONs in one OLT.

[0005] In view of such conventional problems, an object of the present disclosure is to provide an OLT that can accommodate ONUs of IEEE-based PON and ITU-T-based PON.

Means for Solving the Problems

[0006] An apparatus according to one aspect of the present disclosure is an OLT connected to a plurality of ONUs by a P2MP ODN, comprising: a first signal processing unit that converts an IEEE-based PON bandwidth request into the following common request and converts the following common grant into an IEEE-based PON transmission permit; a second signal processing unit that converts an ITU-T-based PON bandwidth request into the above common request and converts the above common grant into an ITU-T-based PON transmission permit; and a bandwidth allocation unit that executes the following common DBA based on the above common request and outputs the above common grant, which indicates the allocation result, to the first and second signal processing units.

[0007] Common DBA: A DBA that exclusively allocates the uplink transmission time for both IEEE-based PON ONUs and ITU-T-based PON ONUs. Common Request: A bandwidth request frame with a standardized format for common DBAs. Common Grant: A standardized transmit permission frame format for common DBAs.

[0008] This disclosure can be implemented not only as a system and apparatus having the characteristic configuration described above, but also as a program for causing a computer to execute such characteristic configuration. Furthermore, this disclosure can be implemented as a semiconductor integrated circuit that implements part or all of the system and apparatus. [Effects of the Invention]

[0009] According to this disclosure, an IEEE-based PON ONU and an ITU-T-based PON ONU can be accommodated in a single OLT. [Brief explanation of the drawing]

[0010] [Figure 1] Figure 1 is a network connection diagram showing an example of the overall configuration of a PON system. [Figure 2]Figure 2 is an explanatory diagram showing the recommended wavelength arrangement when GE-PON, 10G-EPON, and 25GS-PON are mixed together. [Figure 3] Figure 3 is an explanatory diagram illustrating the overview of uplink communication control for IEEE-based PON. [Figure 4] Figure 4 is an explanatory diagram illustrating the overview of ITU-T-based PON uplink communication control. [Figure 5] Figure 5 is a block diagram showing an example of the internal configuration of an OLT (Optical Line Terminal). [Figure 6] Figure 6 is an explanatory diagram illustrating an example of bandwidth allocation processing in an OLT. [Figure 7] Figure 7 is a table showing an example of a common request format. [Figure 8] Figure 8 is a table showing an example of a common grant format. [Figure 9] Figure 9 is an explanatory diagram showing an example of the first request transformation. [Figure 10] Figure 10 is an explanatory diagram showing an example of a second request transformation. [Figure 11] Figure 11 is an explanatory diagram showing an example of the first Grant transformation. [Figure 12] Figure 12 is an explanatory diagram showing an example of the second Grant transformation. [Modes for carrying out the invention]

[0011] <Summary of the embodiments of this disclosure> The embodiments of this disclosure are outlined below.

[0012] (1) The apparatus according to one aspect of the present embodiment is an OLT connected to a plurality of ONUs via a P2MP-type ODN, and includes a first signal processing unit that converts the bandwidth requirements of an IEEE-based PON into the following common request and converts the following common grant into the transmission permission of the IEEE-based PON; a second signal processing unit that converts the bandwidth requirements of an ITU-T-based PON into the common request and converts the common grant into the transmission permission of the ITU-T-based PON; and a bandwidth allocation unit that executes the following common DBA based on the common request and outputs the common grant with the allocation result recorded to the first and second signal processing units.

[0013] Common DBA: DBA that exclusively allocates the upstream transmission time of each ONU for both the ONUs of the IEEE-based PON and the ONUs of the ITU-T-based PON Common request: A bandwidth request frame with a unified format for common DBA Common grant: A transmission permission frame with a unified format for common DBA

[0014] According to the OLT of the present embodiment, since the bandwidth allocation unit executes the common DBA based on the common request and outputs the common grant with the allocation result recorded to the first and second signal processing units, scheduling can be performed such that the reception times of the upstream frames from the ONUs of the IEEE-based PON and the reception times of the upstream frames from the ONUs of the ITU-T-based PON do not overlap. Therefore, the ONUs of the IEEE-based PON and the ONUs of the ITU-T-based PON can be accommodated in one OLT.

[0015] (2) In the OLT of (1) above, the common request may include identification information of the allocation target and the total buffer amount of the allocation target. The reason is that in both the IEEE and ITU-T cases, the ONU estimates the required bandwidth in terms of the buffer amount, so at least the total buffer amount of each ONU is required even when performing common DBA.

[0016] (3) In the OLT described in (2) above, the common request may include a PLOAM request flag from the allocation target. In this way, PLOAM, which is used in ITU-T-based PON, can be applied to common requests.

[0017] (4) In the OLT described in (1) to (3) above, the common DBA may be executed in each DBA cycle that proceeds in sync with the downstream PHY frame. In this way, the scheduling of uplink transmissions permitted for each ONU can be aligned with the ITU-T PON policy, which has a stricter time management framework than the IEEE-based PON.

[0018] (5) In the OLT described in (1) to (4) above, the common grant may include the identification information of the allocation target, a starting point that coincides with the start time of the uplink PHY frame, the elapsed time from the starting point, and the amount of transmission permission for the allocation target. In this way, the format of the transmission time and transmission allowance assigned to each ONU can be aligned with the ITU-T PON policy, which has a stricter time management framework than the IEEE-based PON.

[0019] (6) In the OLT described in (5) above, the common grant may include a PLOAM request flag for the allocation target. In this way, the PLOAM transmission permission adopted by ITU-T-based PON can be applied to common grants.

[0020] (7) A method according to one aspect of this embodiment is a bandwidth allocation method performed in the OLT described in (1) to (6) above. Therefore, the bandwidth allocation method of this embodiment has the same effects as the OLT described in (1) to (6) above.

[0021] <Details of the embodiments of this disclosure> The embodiments of this disclosure will be described in detail below with reference to the drawings. At least some of the embodiments described below may be combined in any way.

[0022] [Definition of Terms] In this embodiment, among the upstream and downstream signals transmitted in the PON system 100, the upstream signal may be abbreviated as "US" and the downstream signal may be abbreviated as "DS".

[0023] In this embodiment, a set of multiple types of ONUs that comply with different PON communication protocols may be collectively referred to as "heterogeneous ONUs." PON communication protocols include, for example, IEEE-based PON and ITU-T-based PON. Note that "IEEE" is an abbreviation for "Institute of Electrical and Electronics Engineers." "ITU-T" is an abbreviation for the Telecommunication Standardization Sector of the International Telecommunication Union (ITU).

[0024] [Overall configuration of the PON system] Figure 1 is a network connection diagram showing an example of the overall configuration of the PON system 100. As shown in Figure 1, the PON system 100 is a multi-rate PON system in which multiple types of ONUs 20, 30, and 40 with different transmission speeds are connected to the OLT 10 by an ODN (Optical Distribution Network) 50 in the form of P2MP (Point To Multi Point). Although Figure 1 shows only one ONU20, multiple ONU20 connections are possible. The same applies to ONU30 and 40 with other transmission speeds.

[0025] The ODN50 includes multiple branch fibers 53 that branch off from the trunk fiber 51 via an optical splitter 52. The trunk fiber 51 is connected to the OLT 10, and the multiple branch fibers 53 are connected to the ONUs 20, 30, and 40, respectively. ONU20 is a GE-PON ONU, ONU30 is a 10G-EPON ONU, and ONU40 is a 25GS-PON ONU.

[0026] ONU20 and ONU30 are IEEE-based PON ONUs. ONU40 is an ITU-T-based PON ONU. Therefore, the three sets of ONU20, 30, and 40, which have different transmission speeds, constitute a "heterogeneous ONU." Hereafter, IEEE-based PON ONU20 and 30 may be referred to as "IEEE_ONU" or "First ONU," and ITU-T-based PON ONU40 may be referred to as "ITU-T_ONU" or "Second ONU."

[0027] Here, 25GS-PON is a method specified by the "25GS-PON multi-source agreement," one of the industry associations, and can be said to be neither strictly IEEE-based nor ITU-T-based; however, in this embodiment, it is included in the ITU-T-based PON. The reason is that 25GS-PON largely follows the ITU-T standard for XGS-PON in terms of its Transmission Convergence (TC) layer, which includes uplink bandwidth control. Therefore, from the perspective of uplink bandwidth control, it should be classified as an ITU-T standard.

[0028] [Wavelength arrangement when accommodating different types of ONUs] Figure 2 is an explanatory diagram showing the recommended wavelength arrangement when GE-PON ONU20, 10G-EPON ONU30, and 25GS-PON ONU40 are housed together. As shown in Figure 2, the US wavelength band of GE-PON can vary in the range of 1260–1360 nm depending on the operating temperature. This range interferes with the typical DS wavelength band of 25GS-PON (center wavelength 1300 nm).

[0029] To avoid interference, one could employ strategies such as narrowing the US wavelength band of GE-PON and assigning the DS wavelength of 25GS-PON as standard. However, narrowing the wavelength band requires limiting the temperature range or using distributed feedback (DFB) lasers. Therefore, in the PON system 100 of this embodiment, as shown in Figure 2, the bandwidth of the DS wavelength of 25GS-PON is shifted to, for example, the C / L band.

[0030] However, it is necessary to avoid interference between the DS wavelength band of 10G-EPON (1575-1580nm) and the RF (Radio Frequency) video wavelength band (1550-1560nm), and there is a guard band of approximately 15nm between the two. Therefore, it is preferable to shift the DS wavelength band of 25GS-PON to either 1530-1535 nm or 1595-1625 nm.

[0031] Taking the above into consideration, in this embodiment, the US wavelength and DS wavelength used in each ONU 20, 30, and 40 are set as follows, for example (see Figure 1). ONU20 US wavelength = 1260~1360nm DS wavelength=1480~1500nm ONU30:US wavelength=1260~1280nm DS wavelength=1575~1579nm ONU40: US wavelength = 1260~1280nm, 1290~1310nm, or 1284~1288nm DS wavelength=1530~1535nm

[0032] However, the above wavelength assignment is just one example; for example, the DS wavelength of ONU40 may be set to another wavelength included within the C / L band. As will be explained later, the IEEE-based 1G / 10G-EPON and the ITU-T-based 25GS-PON have fundamentally different methods for controlling uplink communication. For this reason, it was difficult to accommodate both the IEEE_ONU and the ITU-T_ONU in a single OLT.

[0033] In this embodiment, the OLT controls the reception time of the uplink frames received by the OLT from the IEEE_ONU and the ITU-T_ONU so that they are time-division multiplexed, thereby enabling the ONUs to be accommodated in a single ONU. The following describes the outlines of IEEE-based uplink communication control (Figure 3) and ITU-T-based uplink communication control (Figure 4), followed by a description of the internal configuration and control details of the OLT10 in this embodiment.

[0034] [Uplink communication control of IEEE-based PON] Figure 3 is an explanatory diagram illustrating the overview of uplink communication control for IEEE-based PON. As shown in Figure 3, the OLT sends gate frames 1, 2, and 3 to ONU #1, #2, and #3 respectively, instructing ONU #1, #2, and #3 to start transmitting. ONU #1, #2, and #3 transmit uplink signals 1, 2, and 3 according to the timing instructed by the OLT, so no collisions of uplink signals 1, 2, and 3 occur. In addition, a report frame for bandwidth request is transmitted for all or part of uplink signals 1, 2, and 3.

[0035] The OLT and ONUs #1, #2, and #3 each have a local clock (32 bits) in 16ns units. Since the gate frame contains a separate transmission start time for each ONU #1, #2, and #3, it is necessary to synchronize the time between the OLT and ONUs #1, #2, and #3. Therefore, when ONU #1, #2, and #3 receive a gate frame, they synchronize their own clocks with the OLT's clock (timestamp). The OLT also instructs ONU #1, #2, and #3 on the transmission start time (OLT's reception time - RTT (Round Trip Time)) and transmission time. The OLT measures the RTT during ONU discovery and updates it when it receives a report frame.

[0036] [ITU-T-based PON uplink communication control] Figure 4 is an explanatory diagram illustrating the overview of ITU-T-based PON uplink communication control. As shown in Figure 4, the OLT manages the progress of control for both up and down directions using "PHY (Physical Interface) frames" that progress in 125 μs cycles.

[0037] Specifically, the OLT manages the progress of uplink and downlink PHY frames in a one-to-one correspondence and in parallel. The time difference between the start times of the two frames is a fixed value determined by the communications administrator to ensure that reception from the furthest ONU (not shown) is completed in time. The header of the downlink PHY frame contains the ONU's "BWmap" (BandWidth map). The BWmap contains uplink transmission permission information.

[0038] Specifically, BWmap includes the "Alloc ID," "Dynamic Bandwidth Report Upstream (DBRu) Request Flag," "Start Time," and "Grant Size." Note that multiple Alloc IDs (ID=X and Z in the example diagram) can be assigned to a single ONU_X.

[0039] If the DBRu request flag is enabled, ONU_X,Y stores the upstream buffer amount in the Dynamic Bandwidth Report Upstream (DBRu) for the upstream PHY burst. OLT performs Dynamic Bandwidth Allocation (DBA) based on the upstream buffer amounts of ONU_X,Y to determine the transmit permission amount for each ONU_X,Y.

[0040] ONU_X,Y calculates the start time for transmitting the uplink PHY burst based on the start time listed in BWmap, and when its local time reaches that transmission start time, it starts transmitting an uplink PHY burst containing user data (main signal) equivalent to the transmission permission amount in BWmap. Taking ONU_Y as an example, ONU_Y defines the start time of transmission for the uplink PHY burst as the point at which the response time Trsp, equivalent delay EqD_y, and start time Tsrt_y have elapsed from the time the beginning of the downlink PHY frame is received.

[0041] The response time Trsp and equivalent delay EqD_y are delay times specific to ONU_Y and are determined for each ONU based on the results of RTT measurement (ranging) by the OLT. Ranging is performed for each ONU_X,Y through the exchange of ranging requests and responses between the OLT and ONU_X,Y. The start time Tsrt_y is a delay time specific to ONU_Y, determined based on the uplink transmission order assigned to ONU_Y, and is indicated by the start time field in BWmap.

[0042] As described above, in ITU-T-based PON systems, the OLT specifies the transmission timing and transmission allowance to the ONU. This is the same as in IEEE-based PON systems. However, the transmission timing specified by the OLT (the start time Tsrt_y in the BWmap in Figure 4) is not an absolute time, but a relative time based on the boundary of the uplink PHY frame. For this reason, unlike IEEE-based PON, ITU-T-based PON does not manage absolute time in uplink communication control.

[0043] [OLT Internal Configuration] Figure 5 is a block diagram showing an example of the internal configuration of OLT10. In Figure 5, solid arrows indicate "communication frames" exchanged within OLT10. Dashed arrows indicate "control signals" exchanged within OLT10. As shown in Figure 5, the OLT 10 comprises an optical transceiver 11, a first signal processing unit 12, a second signal processing unit 13, a bandwidth allocation unit 14, a switch unit 15, and a management control unit 16.

[0044] The optical transceiver 11 is a multi-rate optical transceiver capable of electro-optical conversion and photoelectric conversion at three or more different transmission speeds. The optical transceiver 11 includes a transmitting unit 11T that converts 1G / 10G / 25G electrical signals into optical signals of predetermined wavelengths as shown in the figure, and a receiving unit 11R that converts optical signals of predetermined wavelengths into 1G / 10G / 25G electrical signals.

[0045] Specifically, the transmitting unit 11T of the optical transceiver 11 converts the 1.25 Gbit / s electrical signal (downlink frame) input from the first signal processing unit 12 into, for example, a downlink optical signal of 1490 nm, and sends this downlink optical signal to the ODN 50. Similarly, the transmitting unit 11T of the optical transceiver 11 converts the 10.31 Gbit / s electrical signal (downlink frame) input from the first signal processing unit 12 into, for example, a downlink optical signal of 1577 nm, and sends this downlink optical signal to the ODN 50.

[0046] Similarly, the transmitting unit 11T of the optical transceiver 11 converts the 25.78 Gbit / s electrical signal (downlink frame) input from the second signal processing unit 13 into a downlink optical signal of, for example, 15XX nm, and sends this downlink optical signal to the ODN 50. The "15XXnm" mentioned above is set to any value that falls within the preferred numerical range of the DS wavelength for 25GS-PON as shown in Figure 1.

[0047] The receiving unit 11R of the optical transceiver 11 converts, for example, an uplink optical signal of 1260~1360nm into electrical signals of various rates and outputs them. In this case, only the electrical signals corresponding to the rates of the uplink optical signal are meaningful, and electrical signals corresponding to other rates become noise or are masked. In Figure 5, "12YYnm" refers to one of the US wavelengths (1270nm or 1310nm) of the 25GS-PON shown in Figure 1.

[0048] The first signal processing unit 12 includes a MAC chip capable of frame processing in accordance with GE-PON and 10G-EPON. This MAC chip is composed of, for example, a System on a Chip (SoC) that includes at least one CPU (Central Processing Unit) and memory. The MAC chip of the first signal processing unit 12 may include an integrated circuit such as an FPGA (Field-Programmable Gate Array) or an ASIC (Application Specific Integrated Circuit) in addition to or as a substitute for a CPU.

[0049] The second signal processing unit 13 includes a MAC chip capable of frame processing in accordance with 25GS-PON. This MAC chip is composed of, for example, an SoC that includes at least one CPU and memory. The MAC chip of the second signal processing unit 13 may include an integrated circuit such as an FPGA or ASIC in addition to, or as a substitute for, the CPU.

[0050] The bandwidth allocation unit 14 is an integrated circuit that performs the "common DBA" described later. The bandwidth allocation unit 14 may consist of, for example, at least one CPU and memory, but it may also include an integrated circuit such as an FPGA or ASIC in addition to the CPU or as a substitute for the CPU. The bandwidth allocation unit 14 can send and receive control frames S1 and S2, respectively, to and from the first signal processing unit 12 and the second signal processing unit 13 via serial communication such as I2C (Inter-Integrated Circuit).

[0051] The switch unit 15 is an integrated circuit, such as an LSI (Large Scale Integration), that has a Layer 2 relay function. The integrated circuit may also have a Layer 3 relay function. The switch unit 15 has multiple Ethernet ports ("Ethernet" is a registered trademark). The first signal processing unit 12 is connected to a predetermined port among the multiple Ethernet ports, and the second signal processing unit 13 is connected to another predetermined port. The first and second signal processing units 12, 13 and the bandwidth allocation unit 14 may be implemented on a single integrated circuit, such as an SoC.

[0052] The management control unit 16 is an integrated circuit, such as an LSI, that can communicate with the management device 17. The management device 17 is, for example, a computer operated by a communications administrator. The management device 17 may be connected to the OLT 10 via a management network such as a LAN (Local Area Network). The management control unit 16 can obtain predetermined setting information from the management device 17 via command line or the like, and performs various setting processes on the OLT 10 based on the obtained setting information.

[0053] For example, the management control unit 16 can perform tasks such as setting the QoS (Quality of Service) of the switch unit 15, setting the bandwidth of each port of the switch unit 15, and setting VLAN (Virtual LAN) settings. Furthermore, when the management control unit 16 acquires configuration information S0 necessary for the calculation of the common DBA, such as the contracted bandwidth, communication speed, and QoS information of the ONUs 20, 30, and 40, it notifies the bandwidth allocation unit 14 of the acquired configuration information S0.

[0054] By the way, if the reception time of the uplink frame transmitted according to the gate frame and the reception time of the uplink frame transmitted according to the BWmap overlap, the uplink optical signals will collide in the trunk fiber 51, which may cause the OLT 10 to fail to receive the uplink optical signals. Therefore, in this embodiment, the bandwidth allocation unit 14 performs a unified DBA (hereinafter referred to as "common DBA") targeting both the first ONU and the second ONU, and each signal processing unit 12, 13 notifies the allocation result of the common DBA based on their respective PON methods.

[0055] Specifically, the first signal processing unit 12 generates a gate frame containing the allocation result for the first ONU and transmits it downlink for each ONU. Furthermore, the second signal processing unit 13 generates a downlink PHY frame in which the allocation result for the second ONU is recorded in the BWmap and transmits it downlink. The uplink bandwidth allocation performed in the OLT 10 of this embodiment will now be described with reference to Figure 6.

[0056] [Bandwidth allocation processing in OLT] Figure 6 is an explanatory diagram showing an example of bandwidth allocation processing in OLT10. In Figure 6, solid arrows indicate "upstream control information" (reports or DBRu) received by OLT10 from ONU20, 30, and 40. "Dotted-dot arrows" indicate "downstream control information" (gates or BWmaps) transmitted by OLT10 to ONU20, 30, and 40. Dashed arrows indicate "internal control information" exchanged within OLT10. Note that this control information does not necessarily have to be in frame format.

[0057] (Parameter definitions) The meanings of the parameters in Figure 6 are as follows: Di: This is the i-th downlink PHY frame. Ui: This is the i-th up PHY frame. i: This is the identification number of the PHY frame. The identification number i is incremented every 125 μs.

[0058] CL: This is the execution cycle of the common DBA. Figure 6 shows an example where the CL is 4 × 125 μs = 500 μs. Hereafter, CL will also be referred to as the "DBA cycle". n is the identification number for the CL (DBA cycle). The identification number n is incremented every 500 μs. j is a common identification number defined for the first and second ONUs. Here, j=1 is ONU20 (first ONU), j=2 is ONU30 (first ONU), and j=3 is ONU40 (second ONU).

[0059] Treq: This is the time it took to receive all requests for each ONUj. Tdba: This is the execution time of the bandwidth allocation process (processes 1 to 5 described below) that starts immediately after the completion of the Treq. Tsby: This is the waiting time until the next CL starts. CL is composed of the three time components mentioned above, and the relationship CL = Treeq + Tdba + Tsby holds true. Tsby is a time length greater than or equal to the time difference between the downlink PHY frame and the uplink PHY frame, and is set to a value that provides sufficient time for a response from the furthest ONUj.

[0060] COM: A control frame with a standardized format for common DBAs. Hereafter, COM will also be referred to as the "common frame." The common frame (COM) includes the following two types of frames:

[0061] COM_R is a bandwidth request frame for common DBAs. In other words, it is a common frame used for bandwidth requests. Hereafter, COM_R will also be referred to as a "common request". There are two types of COM_R: "COM_R1" created by the first signal processing unit 12 and "COM_R2" created by the second signal processing unit 13. The format of the common request (Figure 7) will be described later.

[0062] COM_G is a send grant frame for common DBAs. In other words, it is a common frame used for send grants. Hereafter, COM_G will also be referred to as the "common grant." COM_G has two types: "COM_G1" for the first ONU, which is output to the first signal processing unit 12, and "COM_G2" for the second ONU, which is output to the second signal processing unit 13. The common grant format (Figure 8) will be described later.

[0063] The above COM_R1 and COM_G1 are types of control frames S1 (see Figure 5) exchanged between the first signal processing unit 12 and the bandwidth allocation unit 14. The above COM_R2 and COM_G2 are types of control frames S2 (see Figure 5) exchanged between the second signal processing unit 13 and the bandwidth allocation unit 14.

[0064] In this embodiment, all requests from ONUj are collected during the Treq, which is the initial period of the current DBA cycle (e.g., CLn). Specifically, to ensure that the ONUj request (report and DBRu) is received by the current CLn's Treeq, the gate frame and BWmap are sent to CLn-1. The same procedure is followed for CLn+1 and subsequent cycles.

[0065] BWmap contains multiple Allocation structures (grants), and each Allocation structure has a flag that requests DBRu (requests). By enabling this flag and setting the grant amount to the equivalent of DBRu, the second ONU can also send only requests (DBRu), similar to IEEE-based PON. Additionally, if the DBRu request flag is enabled in BWmap, the second ONU can send DBRu after the FS header in the uplink PHY burst.

[0066] (Types of processes that constitute bandwidth allocation processing) As shown in Figure 6, the bandwidth allocation process by OLT10 is a control that performs predetermined data conversion and common DBA for each DBA cycle, and includes the following processes 1 to 5.

[0067] Process 1: First request conversion (step S100) Process 2: Second request conversion (step S200) Process 3: Common DBA (Step S300) Process 4: First Grant transformation (step S400) Process 5: Second Grant transformation (step S500)

[0068] (First request conversion) The first request conversion is a data conversion performed by the first signal processing unit 12 to create COM_R1 from the report frame of the first ONU (hereinafter also referred to as "R1 conversion"). The created COM_R1 is input to the bandwidth allocation unit 14. A specific example of R1 conversion (Figure 9) will be described later.

[0069] (Second request conversion) The second request conversion is a data conversion performed by the second signal processing unit 13 to create COM_R2 from DBRu (hereinafter also referred to as "R2 conversion"). DBRu is included in the uplink PHY burst received by the second signal processing unit 13 during the Treq period. The created COM_R2 is input to the bandwidth allocation unit 14. A specific example of R2 conversion (Figure 10) will be described later.

[0070] (Common DBA) Common DBA is a dynamic bandwidth allocation performed by the bandwidth allocation unit 14, which generates COM_G1 and COM_G2 using COM_R1 and COM_R2 as input data. Specifically, the bandwidth allocation unit 14 is configured to sleep when the common DBA finishes, so that it is started by a timer after the granted Treeq. As a result, the common DBA is started after the Treeq finishes.

[0071] In a common DBA, the uplink transmission time allowed for each ONUj is scheduled to be mutually exclusive. In addition to the bandwidth request amount based on COM_R, the common DBA may also consider QoS information set for each ONUj.

[0072] (First Grant transformation) The first Grant transform is a data transformation (hereinafter also referred to as the "G1 transform") performed by the first signal processing unit 12 to create a gate frame from COM_G1 for the first ONU. The created gate frame is sent to the first ONU (ONU20,30). A specific example of G1 transformation (Figure 11) will be described later.

[0073] In the first grant transformation, the grant for the report and the grant for the data become separate common grants. In other words, the first signal processing unit 12 does not convert each COM_G1 acquisition into a gate frame, but instead creates a grant (StartTime, GrantSize) for one first ONU from one COM_G1.

[0074] Furthermore, the first signal processing unit 12 aggregates grants with the same assigned ID into a gate frame and transmits it to the first ONU at a timing synchronized with the first BWmap. This timing is instructed, for example, by the bandwidth allocation unit 14 before the common DBA is completed. Furthermore, if the number of grants for the same assigned ID is too large to be consolidated into a single gate, the first signal processing unit 12 can also consolidate the grants for that assigned ID into multiple gates.

[0075] (Second Grant transformation) The second G2 conversion is a data conversion performed by the second signal processing unit 13 to create a BWmap from COM_G2 for the second ONU (hereinafter also referred to as "G2 conversion"). The created BWmap is stored in the header of the downlink PHY frame (specifically the FS header) and sent to the second ONU (ONU40). A specific example of G2 conversion (Figure 12) will be described later.

[0076] Each COM_G2 corresponds to one grant (Alloc ID, Start time, Grant size) within the BWmap. In other words, a BWmap typically aggregates multiple COM_G2s from the second ONU. However, the BWmap recorded in a given downlink PHY frame contains allocation results limited to the uplink PHY frame corresponding to that downlink PHY frame. Therefore, in the second grant transformation, not only the BWmap for Di but also the BWmaps for Di+1, Di+2, and Di+3 may be created. The grant that causes the second ONU to send DBRu is recorded in the BWmap for Di.

[0077] [Specific examples of common requests and common grants] Figure 7 is a table showing an example of a common request format. As shown in Figure 7, the data items for a common request include "Type ID", "Assignment Target ID", "PLOAM Request Flag", "Enable / Disable Request for Buffer Amount and Uplink Received Data Amount", "Buffer Amount (Total)", and "Uplink Received Data Amount". The contents of each data item are as described in the contents column of Figure 7. PLOAM stands for "Physical Layer Operation, Administration and Maintenance," as used in the ITU-T system's PON.

[0078] Figure 8 is a table showing an example of a common grant format. As shown in Figure 8, the data items for the common grant include "Type ID," "Assignment Target ID," "Buffer Amount Notification Request Flag," "PLOAM Request Flag," "Starting Point of Transmission Permission Timing," "Transmission Permission Start Timing," and "Transmission Permission Amount." The contents of each data item are as described in the contents column of Figure 8.

[0079] [Specific example of first request transformation (R1 transformation)] Figure 9 is an explanatory diagram showing an example of the first request transformation. As shown in Figure 9, the first request transformation (R1 transformation: step S100 in Figure 6) includes processes P101 and P102.

[0080] Process P101 is the process of recording the value of the LLID field in the report frame's preamble as the "Assignment ID" of COM_R1, and recording an identification value representing the type of the requesting ONU (e.g., communication speed such as 1G or 10G) as the "Type ID" of COM_R1.

[0081] Process P102 converts the total time in 16ns units recorded in queues #0 to #7 of the report frame into a byte value, and records the converted byte value in the "Buffer Amount (Total)" of COM_R1. Furthermore, if the values ​​recorded in queues #0 to #7 of the report frame are all 0, the "Enable / Disable Request for Buffer Amount and Uplink Received Data Amount" setting for COM_R1 will be disabled. The same applies when COM_R1 is created for reasons other than receiving a report frame.

[0082] Furthermore, the first signal processing unit 12 calculates and stores the grant amount for each first ONU in the first grant conversion (here, the conversion is for Di to Di+3). The grant amount is calculated by converting the transmit permission amount without a buffer amount notification request flag to the amount of data at the communication speed specified by the type ID. In the first request conversion based on the report frame of the Ui, the first signal processing unit 12 may use the amount obtained by subtracting the amount of data being held from the buffer amount calculated from the report frame as the buffer amount for the common report.

[0083] [Specific examples of second request transformation (R2 transformation)] Figure 10 is an explanatory diagram showing an example of a second request transformation. As shown in Figure 10, the second request transformation (R2 transformation: step S200 in Figure 6) includes processes P201, P202, and P203.

[0084] Process P201 is the process of recording the DBRu source Alloc-ID value in the "Assignment Target ID" of COM_R2, and recording the identification value representing the type of ONU of the requesting entity (e.g., communication speed such as 25G) in the "Type ID" of COM_R2.

[0085] Furthermore, the second signal processing unit 13 calculates and stores the grant amount for each second ONU in the second grant conversion (here, the conversion is for Di to Di+3). The grant amount is calculated by converting the transmit permission amount without a buffer amount notification request flag to the amount of data at the communication speed specified by the type ID. In the second request conversion based on the report frame of the Ui, the second signal processing unit 13 may use the amount obtained by subtracting the amount of data being held from the buffer amount calculated from the report frame as the buffer amount for the common report.

[0086] Process 202 is the process of writing the byte value recorded in the BufOcc field of the DBRu in the rising PHY burst to the "Buffer Amount (Total)" of COM_R2. If the value entered in the BufOcc field is 0, the "Enable / Disable Request for Buffer Amount and Uplink Received Data Amount" setting for COM_R2 will be disabled. The same applies when COM_R2 is created for reasons other than DBRu reception.

[0087] Process 203 is the process of turning the "PLOAM request flag" of COM_R2 on or off based on the value of the Ind field in the header of the Upstream FS burst. The second ONU notifies whether there is a PLOAM pending transmission using the value of the 8th bit in the Ind field, so you can decide whether to turn the flag on or off based on the value of that 8th bit, for example.

[0088] [Specific examples of the first Grant transformation (G1 transformation)] Figure 11 is an explanatory diagram showing an example of the first Grant transformation. As shown in Figure 11, the first Grant transformation (G1 transformation: step S300 in Figure 6) includes processes P301, P302, and P303.

[0089] Process P301 is the process of writing the value specified in the "Assignment Target ID" of COM_R1 to the LLID field of the gate frame's preamble. Process 302 is the process of reflecting the on / off status of the "buffer amount notification request flag" of COM_R1 in the Flags value of the "Number of grants / Frags" field in the gate frame. For example, if the request is turned on, bits 4 to 7 of Flags are mapped.

[0090] Process P303 determines the values ​​to be entered for the Grant Start Time and Grant Length in the gate frame, based on the "starting point of the grant start timing," "grant start timing," and "grant amount" of COM_R1. In processing P303, the transmission start time is the time value obtained by converting the (start point + timing - RTT) point in time to the local time of the IEEE OLT (16ns granularity).

[0091] Furthermore, the transmission start time and transmission permission time can be aggregated into a single gate, up to a total of four (#1 to #4). Therefore, if the number of grants for the same assigned ID exceeds four, the grants for that assigned ID will be aggregated by multiple gates.

[0092] [Specific examples of the second Grant transformation (G2 transformation)] Figure 12 is an explanatory diagram showing an example of the second Grant transformation. As shown in Figure 12, the second Grant transformation (G2 transformation: step S400 in Figure 6) includes processes P401, P402, P403, and P404.

[0093] Process P401 is the process of writing the value specified in the "Assignment Target ID" of COM_R1 to the Alloc-ID field of BWmap. Process P402 is the process of reflecting the on / off status of the "buffer amount notification request flag" of COM_R1 in the DBRu field of BWmap. Process P403 is the process of reflecting the on / off status of the "PLOAM request flag" of COM_R1 in the PLOAMu field of BWmap.

[0094] Process P404 is the process of recording the time value specified in the "Transmission Permission Start Timing" of COM_R1 into the StartTime field of BWmap. Process P405 is the process of recording the time value specified in the "Transmission Permit Amount" of COM_R1 into the GrantSize field of BWmap.

[0095] Note that the second Grant transformation shown in Figure 12 is a transformation targeting the BWmap of the first Ui in CLn. In this case, the BWmap of Ui is completed when the time obtained by adding the transmit permission amount at the transmit permission start time exceeds the PHY frame period. Therefore, in the case of the second Ui+1 BWmap, the StartTime field contains the value obtained by subtracting the PHY frame period from the COM_G2 transmit permission start timing. Similarly, in the StartTime field of BWmaps from Ui+2 onward, the value obtained by subtracting an integer multiple of the PHY frame period from the COM_G2 transmit permission start timing.

[0096] [Other variations] The embodiments disclosed herein are illustrative and not restrictive in all respects. The scope of the present invention is not limited to the embodiments described above, and includes all modifications within the scope equivalent to the configurations described in the claims.

[0097] In the above embodiment, the bandwidth allocation process performed by the OLT may include scheduling a "discovery" quiet window for each type of ONU. However, for IEEE-based ONUs, it is not necessary to schedule a "ranging" quiet window for that ONU.

[0098] In the embodiments described above, the first ONU may be one of either a GE-PON ONU (ONU20) or a 10G-EPON ONU (ONU40). In the embodiments described above, the second ONU may be an XGS (10(X)G Symmetric)-PON ONU, an HSP (Higher Speed ​​PON) ONU, or a combination of at least two of the three types of ONUs described above, rather than a 25GS-PON ONU (ONU40).

[0099] In the embodiments described above, the PON system 100 is not limited to a multi-rate PON system. Specifically, for example, a 10G-EPON ONU (ONU40) may be used as the first ONU and an XGS-PON ONU may be used as the second ONU, so that the transmission speeds of the first ONU and the second ONU are equivalent.

[0100] In the above-described embodiment, the ODN 50 may be a circuit configuration in which, for example, a ROADM (Reconfigurable Optical Add / Drop Multiplexer) network, which is a type of core network, is interposed in the middle of the trunk fiber 51. In this case, different paths may be set within the ROADM network for the wavelength of the optical signal used in the PON system 100. [Explanation of symbols]

[0101] 10 OLT 11 Optical transceiver 11T Transmitter 11R Receiver 12 First Signal Processing Unit 13. Second Signal Processing Unit 14. Bandwidth allocation section 15 Switch section 16 Management and Control Unit 17 Management device 20 GE-PON ONU (IEEE_ONU, 1st ONU) 30 10G-EPON ONU (IEEE_ONU, 1st ONU) 40 25GS-PON ONU (ITU-T_ONU, 2nd ONU) 50 ODN 51 Trunk Fiber 52 Optical Splitter 53 Branch fiber 100 PON System

Claims

1. An OLT connected to multiple ONUs via a P2MP-type ODN, A first signal processing unit converts IEEE-based PON bandwidth requests into the following common requests and converts the following common grants into IEEE-based PON transmit permissions, A second signal processing unit that converts the bandwidth request of the ITU-T system PON into the common request and converts the common grant into a transmit permission for the ITU-T system PON, An OLT comprising: a bandwidth allocation unit that executes the following common DBA based on the aforementioned common request and outputs the aforementioned common grant, which contains the allocation result, to the first and second signal processing units. Common DBA: A DBA that exclusively allocates uplink transmission time for both IEEE-based PON ONUs and ITU-T-based PON ONUs. Common Request: A bandwidth request frame with a standardized format for common DBAs. Common Grant: A transmit permission frame with a standardized format for Common DBA.

2. The aforementioned common request is, The OLT according to claim 1, comprising identification information of the allocation target and the total buffer amount of the allocation target.

3. The aforementioned common request is, The OLT according to claim 2, including a PLOAM request flag from the allocation target.

4. The aforementioned common DBA is, The OLT according to any one of claims 1 to 3, which is executed for each DBA cycle that progresses in sync with the downlink PHY frame.

5. The aforementioned common grant is The OLT according to claim 4, comprising: identification information of the object to be allocated; a starting point that coincides with the start time of the uplink PHY frame; the elapsed time from the starting point; and the transmission permission amount of the object to be allocated.

6. The aforementioned common grant is The OLT according to claim 5, including a PLOAM request flag for the allocation target.

7. A bandwidth allocation method performed in an OLT connected to multiple ONUs via a P2MP configuration ODN, The steps include converting IEEE-based PON bandwidth requests into the following common requests, and converting ITU-T-based PON bandwidth requests into the aforementioned common requests, The steps include: executing the following common DBA based on the aforementioned common request and generating the following common grant which records the allocation results; A bandwidth allocation method comprising the steps of converting the common grant into an IEEE-based PON transmit permission, and converting the common grant into an ITU-T-based PON transmit permission. Common DBA: A DBA that targets both IEEE-based PON ONUs and ITU-T-based PON ONUs. Common Request: A bandwidth request frame with a standardized format for common DBAs. Common Grant: A transmit permission frame with a standardized format for Common DBA.

Images