System and method for performing rate adaptation

Abstract

A system and method for performing rate adaptation on constant bit rate (CBR) client data for transmission over a metropolitan transport network (MTN) by defining a plurality of pseudo Ethernet packets at a source node; assembling a plurality of general mapping procedure (GMP) frames by mapping a plurality of blocks of a coded block stream from the CBR client data, a plurality of padding blocks, and a GMP overhead into consecutive ones of the plurality of pseudo Ethernet packets; inserting a fixed number of idle blocks between one or more consecutive ones of the consecutive ones of the pseudo Ethernet packets and inserting an MTN path overhead (POH) frame aligned with the plurality of GMP frames to generate a plurality of rate-adapted GMP frames for transmission to an intermediate node or a sink node over the MTN.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. Provisional Patent Application No. 63 / 216,938 filed on June 30, 2021, U.S. Provisional Patent Application No. 63 / 326,989 filed on April 4, 2022, and U.S. Non-Provisional Patent Application No. 17 / 745,060 filed on May 16, 2022, each of which is incorporated herein by reference in its entirety. Background Art

[0003] The Generic Mapping Procedure (GMP) is an International Telecommunication Union Telecommunication Standardization Sector (ITU-T) method for mapping a constant bit rate (CBR) digital client signal of a given bit rate into the payload of a server layer channel of a telecommunications network. In operation, the source node uses the GMP overhead in each GMP window located in the overhead of the server layer channel to send a count value (Cm) to inform the sink node how many payload data words it will send in the next GMP window. The source node uses a modular arithmetic based on the count value (Cm) to insert fill words to fill any channel bandwidth not required by the client signal. The sink node uses the same modular arithmetic to recover the data. However, the server layer channel of the ITU-TG.8312 standard metropolitan transport network (MTN) project does not provide GMP overhead.

[0004] As defined in ITU-T G.709 (OTN), GMP requires a consistent fixed length between the beginning of each GMP window, i.e., a fixed number of server layer bits per GMP window, because the GMP overhead is in the server layer. The server channel is point-to-point, so that GMP terminates at the ingress to the intermediate node and is regenerated at the egress end of the intermediate node. Since the MTN server channel for MTN lacks GMP overhead, it is desirable to move the GMP functionality to the "path" overhead (POH) of the MTN server layer channel added to the client signal flow, which passes through the intermediate nodes without modification. The problem with using GMP in the POH is that the intermediate nodes have a different clock domain from the source node, which makes it impossible to maintain a constant fixed number of server layer bits for each GMP window. GMP adjusts the amount of payload information sent per GMP window, but the time period of the window is set by the source node based on the reference clock (REFCLK) of the source node.

[0005] There are three categories of previous solutions for transmitting CBR client signals over networks including MTN. One category creates a CBR path signal containing the client and some additional path overhead. It then uses the overhead in the server signal to accommodate the difference between the path signal rate and the server payload channel rate. While there are various approaches within this category, the ITU-T Generic Mapping Procedure (GMP) is a commonly used solution. The disadvantage is that it requires a partial layer overhead that must be processed at each node along the path layer.

[0006] The second category operates in the packet domain. Segments of the CBR client signal stream are periodically encapsulated into conventional standard Ethernet or Internet Protocol (IP) / Multi-Protocol Layer Switching (MPLS) packets and sent from the source to the aggregator as path signals. The aggregator then extracts the client data from the packet to reconstruct the client signal. Differences in the clock domain along the path are accommodated by inserting or removing idle characters between packets, and packet timestamps can also be used. No clear rate-related information is transmitted in the path or server overhead. One disadvantage is the large amount of overhead bandwidth required for conventional Ethernet packet encapsulation. Another disadvantage is that the packet processing along the path generates jitter due to irregular inter-packet arrival times at the aggregator. This significantly increases the complexity of the process of deriving the client signal rate at the aggregator, because the average packet arrival time is the main information available for it, and if timestamps are used, it is complicated to handle. In addition, the use of packets adds undesirable delays at the source node and the aggregation node.

[0007] The third category combines GMP and Ethernet Idle Mapping Procedure (IMP) into an Ethernet block structure based on ordered sets for marking frame boundaries, but without Ethernet packets. The main disadvantage of this method is that it may not be transparent to intermediate nodes that expect to see Ethernet packets at the physical coding sublayer (PCS).

[0008] Therefore, there is a need for a method and apparatus that overcomes the problems associated with intermediate node clock domains when transmitting CBR client signals over a metropolitan transport network (MTN). Summary of the invention

[0009] Examples of the present invention provide a system and method for performing rate adaptation on constant bit rate (CBR) client data for transmission over a metropolitan transport network (MTN), which overcomes problems associated with intermediate node clock domains when transmitting CBR client data over an MTN by incorporating a generic mapping procedure (GMP) overhead into the CBR client data stream at a source node.

[0010] In one example, a method for performing rate adaptation is provided, the method comprising: receiving a coded block stream of CBR client data at a source node; defining a plurality of pseudo Ethernet packets; assembling a generic mapping procedure (GMP) frame stream comprising a plurality of GMP frames by mapping a variable number of coded blocks, a variable number of padding blocks, and a GMP overhead of the coded block stream of the CBR client data into consecutive pseudo Ethernet packets in the plurality of pseudo Ethernet packets; inserting a fixed number of idle blocks into the GMP frame stream; and inserting an MTN path overhead (POH) frame aligned with the plurality of GMP frames into the GMP frame stream to generate a CBR rate adapted GMP frame stream.

[0011] In another example, a method for performing rate adaptation is provided, the method comprising: receiving a coded block stream of CBR client data at a source node; defining a plurality of pseudo Ethernet packets; assembling a generic mapping procedure (GMP) frame stream comprising a plurality of GMP frames by mapping a variable number of blocks, a variable number of padding blocks, and a GMP overhead of the coded block stream of the CBR client data into consecutive pseudo Ethernet packets in the plurality of pseudo Ethernet packets; inserting a fixed number of idle blocks into the GMP frame stream; inserting an MTN path overhead (POH) frame aligned with the plurality of GMP frames into the GMP frame stream to generate a CBR rate adaptation GMP frame stream; and transmitting the CBR rate adaptation GMP frame stream and the number of idle blocks over the MTN. The example also includes: receiving the CBR rate-adapted GMP frame stream at an intermediate node of the MTN; performing idle mapping procedure (IMP) rate adaptation at the intermediate node to modify the number of idle blocks; transmitting the CBR rate-adapted GMP frame stream and the modified number of idle blocks from the intermediate node to a sink node of the MTN; performing idle mapping procedure (IMP) rate adaptation to adapt the CBR rate-adapted GMP frame stream to a local reference clock at the sink node; determining the CBR client data flow rate of the CBR client stream based on the GMP overhead and a difference between a fixed number of idle blocks inserted into the stream GMP frames by the source node and the modified number of idle blocks received at the sink node; and extracting the coded block stream of the CBR client data from the CBR rate-adapted GMP frame stream using the determined CBR client data flow rate.

[0012] In another example, a source node is provided for transmitting a constant bit rate (CBR) client data stream over a metropolitan transport network (MTN). The source node includes circuitry for: receiving a coded block stream of CBR client data; defining a plurality of pseudo Ethernet packets; assembling a generic mapping procedure (GMP) frame stream including a plurality of GMP frames by mapping a variable number of blocks, a variable number of padding blocks, and a GMP overhead of the coded block stream of CBR client data into consecutive pseudo Ethernet packets in the plurality of pseudo Ethernet packets; inserting a fixed number of idle blocks into the GMP frame stream; and inserting an MTN path overhead (POH) frame aligned with the plurality of GMP frames into the GMP frame stream to generate a CBR rate-adapted GMP frame stream.

[0013] Thus, in various examples, a method and apparatus are provided to overcome problems associated with intermediate node clock domains when transmitting CBR client signals over a metropolitan transport network (MTN). BRIEF DESCRIPTION OF THE DRAWINGS

[0014] For a more complete understanding, reference should be made to the following detailed description taken in conjunction with the accompanying drawings, in which:

[0015] Figure 1 is an exemplary diagram showing a basic network using GMP to adapt path flows to source node server channels.

[0016] Figure 2 An exemplary GMP frame is shown.

[0017] Figure 3A An exemplary pseudo Ethernet packet format is shown with client data and a GMP padding block placed into the data block of the packet.

[0018] Figure 3B An exemplary pseudo Ethernet packet format is shown with client data and GMP padding blocks placed into the packet's data block and packet start control block / S / .

[0019] Figure 4 An exemplary pattern of MTN Path Overhead (POH) insertion opportunities in an MTN frame is shown.

[0020] Figure 5A Examples of six pseudo Ethernet 2730 block packets are shown.

[0021] Figure 5B An example of three pseudo Ethernet 5460 block packets is shown.

[0022] Figure 5CAn example of thirty pseudo Ethernet 2730 block packets generated from six packets per calendar slot in an MTN part layer consisting of five calendar slots is shown.

[0023] Fig. 6A An example of JC1-JC6 in the GMP overhead is shown.

[0024] Figure 6B An example of JC1-JC3 definition within the GMP overhead is shown.

[0025] Figure 6C An example of JC4-JC6 definition within the GMP overhead is shown.

[0026] Fig. 7A An example of functional blocks of a source node and a sink node in a first option for performing rate adaptation is shown.

[0027] Figure 7B Shown for Fig. 7A An exemplary termination control block / T / in a GMP frame of the first option is shown in FIG.

[0028] Figure 7C Shown is a method for implementing Fig. 7A An exemplary block diagram of a source node for the first option is shown in FIG.

[0029] Fig.7D Shown is a method for implementing Fig. 7A The first option is shown in and additionally provides an exemplary block diagram of a source node for multiplexing of 64B / 66B encoded blocks of a CBR client data stream.

[0030] Fig. 8A An example of functional blocks of a source node and a sink node in the second option for performing rate adaptation is shown.

[0031] Figure 8B Shown for Fig. 8A An exemplary termination control block / T / in a GMP frame of the second option is shown in FIG.

[0032] Figure 8C Shown is a method for implementing Fig. 8A An exemplary block diagram of a source node for the second option is shown in FIG.

[0033] Fig. 9 Shown is the method for implementing Fig. 7A First option or Fig. 8A An exemplary block diagram of a sink node of the second option.

[0034] Fig.10 An exemplary block diagram of circuitry in a source node for implementing multiplexing of two or more CBR client data streams is shown.

[0035] Fig.11A An exemplary multiplexing 2730 block packet for multiplexing multiple CBR clients is shown.

[0036] Fig. 11B An example of positioning of GMP thread frames in MTN path GMP frames for multiplexing CBR clients is shown.

[0037] Fig. 12A An example of multiplexing threads within a single 3-packet GMP frame is shown.

[0038] Fig. 12B An example of multiplexing threads flooding across an extended GMP frame consisting of 3-packet groups is shown.

[0039] Fig.13 An example of 2730 block groupings for multiples of 32 multiplexed threads is shown.

[0040] Fig.14A It shows that according to Fig. 7A An exemplary flow chart of a method performed by a source node for performing rate adaptation on CBR client data for transmission over an MTN.

[0041] Fig. 14B It shows that according to Fig.14A

[0046] An exemplary flow chart of additional details of a method performed by a source node for performing rate adaptation on CBR client data for transmission over an MTN.

[0042] Fig.15A It shows that according to Fig. 8A Second Option An exemplary flow chart of a method performed by a source node for performing rate adaptation on CBR client data for transmission over an MTN.

[0043] Fig. 15B It shows that according to Fig.15A

[0026] A flow chart of additional details of an exemplary method performed by a source node for performing rate adaptation on CBR client data for transmission over an MTN.

[0044] Fig.16A FIG. 1 is a diagram showing a method for performing a multi-point ... Fig. 14B The first option shown is an exemplary flow chart of a method for performing rate adaptation.

[0045] Fig. 16B FIG. 1 is a diagram showing a method for performing a multi-function operation at an aggregation node of MTN. Fig. 14B The first option shown is an exemplary flow chart of a method for performing data extraction.

[0046] Fig.17A FIG. 1 is a diagram showing a method for performing a multi-point ... Fig. 15B The second option shown is an exemplary flow chart of a method for performing rate adaptation.

[0047] Fig. 17B FIG. 1 is a diagram showing a method for performing a multi-function operation at an aggregation node of MTN. Fig. 15B The second option shown is an exemplary flow chart of a method for performing data extraction.

[0048] Fig.18A is an exemplary flow chart illustrating a method for performing rate adaptation and multiplexing of two or more client data flows at a source node for transmission over an MTN.

[0049] Fig.18B It shows that according to Fig.18A An exemplary flow chart of additional details of a method performed by a source node for performing rate adaptation and multiplexing of two or more client data flows for transmission over an MTN.

[0050] Fig.19A FIG. 1 is a diagram showing a method for performing a multi-point ... Fig.18B The method shown is an exemplary flow chart of a method for performing rate adaptation.

[0051] Fig.19B FIG. 1 is a diagram showing a method for performing a multi-function operation at an aggregation node of MTN. Fig.18B The method shown is an exemplary flow chart of a method for performing data extraction. DETAILED DESCRIPTION

[0052] Various examples will now be referred to in detail, examples of which are shown in the accompanying drawings. Although various examples are discussed herein, it should be understood that they are not intended to be restrictive. On the contrary, the examples proposed are intended to cover alternative forms, modifications and equivalents that may be included in the spirit and scope of the various examples defined by the appended claims. In addition, in this specific embodiment, many specific details are set forth in order to provide a thorough understanding. However, examples may be practiced without one or more of these specific details. In other cases, well-known methods, procedures, components and circuits are not described in detail to avoid unnecessary blurring of the various aspects of the examples.

[0053] It should be understood that although the terms first, second, third (not limited thereto) may be used herein to describe various elements, components, regions, layers and / or parts, these elements, components, regions, layers and / or parts should not be limited by these terms. These terms are only used to distinguish one element, component, region, layer or part from another region, layer or part. Therefore, the first element, component, region, layer or part discussed below may be referred to as the second element, component, region, layer or part without departing from the teachings of the present invention.

[0054] Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by those of ordinary skill in the art to which the invention belongs. It should also be understood that terms (such as those defined in commonly used dictionaries) should be interpreted as having a meaning consistent with their meaning in the context of the relevant art, and will not be interpreted in an idealized or overly formal sense unless explicitly defined as such herein.

[0055] In various examples, the present invention examples provide novel systems and methods for carrying constant bit rate (CBR) client signals based on 64B / 66B block coded Ethernet streams over an ITU-T G.8312 Metropolitan Transport Network (MTN).

[0056] The present invention example overcomes the intermediate clock domain problem by adding a mechanism that maintains a constant GMP window relative to the path layer packets but is variable in the server layer, where inter-packet idle blocks can be inserted or removed. This mechanism eliminates the need for GMP to terminate at the ingress of the intermediate node and regenerate at the egress end of the intermediate node.

[0057] Figure 1 A basic reference network is shown, including a high-level diagram of the relevant network element (NE) functionality. The CBR client data stream is encoded into a stream of IEEE 802.3 Ethernet-compatible coded blocks of CBR client data. In the specific example, the coded blocks of the CBR client data are 64B / 66B coded blocks of CBR client data, however this is not intended to be limiting and other encoding methods for these blocks are within the scope. The MTN nodes perform rate adaptation between the CBR client data stream rate and the server channel rate for the 64B / 66B coded block stream of CBR client data via the IMP (i.e., inserting or removing idle blocks from the inter-packet gap (IPG) region between Ethernet packets). The MTN communicates its path overhead in ordered set (OS) blocks, which are ordered set blocks in units of 2 14The examples use a fixed minimum number of idle blocks between their Ethernet packets so that they will pass transparently through the MTN nodes implementing the IMP and allow the IMP to handle the potential rate adjustment range, which can be around 200ppm. The examples also use GMP to distribute client information within the packets and in one option also provide rate adaptation.

[0058] A key benefit of GMP is that it uses a modular arithmetic to spread GMP padding blocks between client data blocks at consistent intervals. If only IMP is used, the aggregation node may receive a relatively large number of idle characters between client data character groups, which increases aggregation node buffering and latency, and degrades jitter performance and / or complicates the implementation of the aggregation phase-locked loop (PLL) used to recover the client clock. Note that the GMP word size is assumed to be a 64B / 66B block, regardless of the number of 5Gbit / s CalSlots used by the client. The FlexE calendar slot (CalSlot) implementation uses the technology of calendar slot switches, as is known in the art. Those of ordinary skill in the art will understand that the clock timing concepts for data transmission disclosed herein reflect the calendar slot timing adopted in the FlexE technology, which will be the reference required to understand the examples, but this is not intended to be limiting in any way.

[0059] Alternatively, for a client using N CalSlots, the word size may be N 64B / 66B blocks. The application is primarily for carrying CBR client signals, rather than a general Ethernet packet multiplexing interface that combines packets and CBR clients, although it is not limited thereto. Therefore, rather than carrying the GMP overhead via OS blocks and data blocks in known locations, a pseudo Ethernet packet including the GMP overhead may be used. Specifically, the example of the present invention encapsulates the CBR client data into a pseudo Ethernet packet, wherein the GMP overhead is carried in one of the control blocks of the packet, preferably in a / T / block at the end of the packet.

[0060] refer to Figure 1, a system 100 for transmitting a constant bit rate (CBR) client data stream over a metropolitan transport network (MTN) includes a source node 105 including circuitry for receiving a stream 120 of 64B / 66B coded blocks of CBR client data encoded according to the CBR client data stream. The circuitry of the source node 105 defines a plurality of pseudo Ethernet packets at 125, each of the pseudo Ethernet packets having a packet start control block ( / S / ) including a corresponding plurality of bytes, a plurality of data payload blocks, and a packet termination control block ( / T / ) including a corresponding plurality of bytes. The plurality of data payload blocks includes N-2 64B / 66B coded data blocks, where N is the total number of 64B / 66B coded data blocks in the pseudo Ethernet packet.

[0061] After defining the plurality of pseudo-Ethernet packets at 125, the circuitry of the source node 105 then performs rate adaptation using GMP within the pseudo-Ethernet packets and idle insertion and / or removal (I / R) 130 between the pseudo-Ethernet packets. Specifically, when performing rate adaptation at 130, the circuitry of the source node 105 assembles a generic mapping procedure (GMP) frame stream including a plurality of GMP frames by mapping a plurality of blocks of a 64B / 66B coded block stream of CBR client data, a plurality of padding blocks, and GMP overhead into consecutive pseudo-Ethernet packets in the plurality of pseudo-Ethernet packets, and inserting a plurality of idle blocks into the GMP frame stream between the pseudo-Ethernet packets. Thus, the plurality of pseudo-Ethernet packets defined by the source node 105 are populated with a plurality of 64B / 66B coded blocks of CBR client data as determined by the GMP engine, which will be referred to below. Figure 7C Describe in more detail.

[0062] After the rate adaptation at 130, the circuitry of the source node 105 uses the identification of the beginning of the GMP frame to align the plurality of GMP frames with the MTN path overhead (POH) frame by inserting the MTN path overhead (POH) frame aligned with the beginning of the GMP frame to generate a rate-adapted GMP frame stream at 135. The CBR rate-adapted GMP frame stream, including the plurality of idle blocks, is then transmitted to the intermediate node 115 of the MTN.

[0063] There are two logical path representations for carrying CBR client data streams through the MTN network. The MTN path layer 145 extends end-to-end, where a 64B / 66B coded block stream 120 of CBR client data enters the MTN network at a source node 105, passes through one or more intermediate nodes 115, and leaves the MTN at an aggregation node 110. A first MTN portion layer 140 connects the source node 105 to the intermediate nodes 115, and a second MTN portion layer 142 connects the intermediate nodes 115 to the aggregation node 110. The MTN path layer 145 utilizes the first MTN portion layer 140 as its server layer and provides configurable connection-oriented connectivity. The server layer for the first MTN portion layer 140 is provided through various Ethernet interfaces. As Figure 1 As shown, the communication between the source node 105 and the intermediate node 115 and between the intermediate node 115 and the aggregation node 110 occurs through the respective MTN partial layers 140, 145 to establish the communication between the source node 105 and the aggregation node 110 through the MTN path layer 145. Therefore, the GMP overhead for performing the CBR client signal rate adaptation is placed by the source node 105 into the MTN path layer 145 to adapt the 64B / 66B coded block stream 120 of the CBR client data to the aggregation node 110 through the MTN path layer 145 so that it can pass through the intermediate node 115 using Ethernet idle rate adaptation, and provide the aggregation node 110 with rate (frequency / phase) information that it can use to recover the 64B / 66B coded block stream 120 of the CBR client data.

[0064] The intermediate node 115 is typically connected to multiple source nodes 105 and multiple aggregation nodes 110. The CBR rate-adapted GMP frame stream of the 64B / 66B coded block stream 120 of the CBR client data is switched by the intermediate node 115 onto an appropriate egress link that identifies the aggregation node 110 as the destination of the 64B / 66B coded block stream 120 of the CBR client data or identifies the next node along the path to the aggregation node 110. The switching performed by the intermediate node 115 is typically performed using FlexE calendar slot technology using a calendar slot (CalSlot) switch, as is known in the art. A person of ordinary skill in the art will understand that the clock timing concepts for data transmission disclosed herein reflect the calendar slot timing employed in the FlexE technology, which will be a reference required to understand the examples, however this is not intended to be limiting in any way.

[0065] In the intermediate node 115, the CBR rate-adapted GMP frame stream sent by the source node 105 is adapted to the clock rate of the intermediate node 115 using per-client idle insertion and / or removal (I / R) rate adaptation 155, wherein the circuitry of the intermediate node 115 inserts idle 64B / 66B blocks into the CBR rate-adapted GMP frame stream or deletes idle 64B / 66B blocks from the CBR rate-adapted GMP frame stream when necessary to match the CBR rate-adapted GMP frame rate to the clock rate of the intermediate node 115. Thus, when the rate of the CBR rate-adapted GMP frame stream is slower than the rate in the intermediate node 115, the intermediate node 115 inserts additional idle blocks into the CBR rate-adapted GMP frame stream, and when the rate of the CBR rate-adapted GMP frame stream is faster than the rate in the intermediate node 115, the idle blocks are deleted from the CBR rate-adapted GMP frame stream. After distribution by the calendar slot switch 150, the CBR rate-adapted GMP frame stream with the modified number of idle blocks is further modified using per-client idle I / R rate adaptation 160 to adapt the clock rate of the intermediate node 115 to the link rate of the second MTN part layer 142. The CBR rate-adapted GMP frame stream with the twice-modified number of idle blocks is then transmitted to the aggregation node 110 through the second MTN part layer 142 at the corresponding link rate.

[0066] The CBR rate adapted GMP frame stream with twice modified number of idle blocks is received at the sink node 110. Circuitry at the sink node 110 is used to recover the CBR client data stream rate from the received CBR rate adapted GMP frame stream and the twice modified number of idle blocks at 165, and to recover the coded block stream of CBR client data from the packets of the CBR rate adapted GMP frames at 170.

[0067] The GMP frames of the CBR rate-adapted GMP frame stream consist of 64B / 66B blocks of Ethernet-compatible CBR client data assembled into pseudo Ethernet packets by the source node 105. These packets are "pseudo Ethernet" packets in the sense that they follow the Ethernet basic PCS packet syntax, beginning with a / S / start control block and ending with a / T / termination control block. This syntax ensures that all intermediate MTN node 115 implementations can correctly identify the Ethernet inter-packet gap (IPG) for idle (I / R) rate adaptation. However, since the packets are not processed by the Ethernet MAC, they can omit the Ethernet packet MAC overhead and the 32-bit cyclic redundancy check frame check sequence (CRC-32FCS). In addition, the pseudo Ethernet packet length can be made much longer than the allowed Ethernet packet size to provide higher bandwidth efficiency for this application.

[0068] An example of the format of a pseudo Ethernet packet is given in Figure 22, wherein three consecutive pseudo Ethernet packets 205, 210, 215 are included in a GMP frame 200. As shown, each of the pseudo Ethernet packets 205, 210, 215 includes a GMP overhead 235 in a packet termination control block ( / T / ) 230 at the end of the packet. The / T / block 230 also includes a control block type 245. The 64B / 66B encoded blocks of CBR client data 240 are mapped into data blocks 225 of consecutive pseudo Ethernet packets 205, 210, 215. Figure 2 As shown, bytes of the / S / block and the / T / block are used for the application, where the / T / block preferably carries the GMP overhead 235. Although Figure 2 The format of the pseudo Ethernet packet shown in shows the GMP overhead 235 placed in the packet termination control block / T / 230, but this is not intended to be limiting, and placing the GMP overhead 235 in any control block ( / S / or / / T / ) in the control blocks of the pseudo Ethernet packet including the packet start control block / S / 220 or the packet termination control block / T / 230 is within the scope of the examples of the present invention.

[0069] Figure 3A and Figure 3B An exemplary pseudo Ethernet packet is further shown. Figure 3A In , a block of 64B / 66B encoded CBR client data 300 occupies only a 64B / 66B data block ( / D / ) 305 of the pseudo Ethernet packet. Figure 3B In the second example shown in FIG. 1 , in order to increase efficiency, the 64B / 66B encoded CBR client data and GMP padding block 300 may occupy some bytes in the packet start control block ( / S / ) 310 and the packet termination control block ( / T / ) 325 in addition to the 64B / 66B data block ( / D / ) 305 of the pseudo Ethernet packet. Figure 3A and Figure 3B As shown, the bytes of the idle count overhead 335 and the GMP overhead 330 occupy corresponding portions of the packet termination control block ( / T / ) 325. Although in this example, the idle count overhead 335 is shown in the packet termination control block ( / T / ) 325, this is not intended to be limiting, and in another example, the idle count overhead 335 may be placed in the packet start control block ( / S / ) 315.

[0070] Figure 4The frame format of the MTN Path Overhead (POH) insertion opportunity according to ITU-T Rec. G.8312 MTN is shown, where "16K" is nominally 16384 and "32K" is nominally 32768, and "n" is the number of 5 Gbit / s MTN partial calendar time slots used by the client data flow. B, A and L are different types of POH ordered set blocks according to the ITU-T Rec. G.8312 MTN standard. The locations of the B, A and L POH blocks are also shown in Figures 5 and 6. Fig.13 The MTN POH frame starts with a B POH block in a position before the A POH block position occurs. It is noted that according to ITU-T G.8312, there may be periods when no POH is transmitted in an L or A POH block position. Therefore, in the following description it should be understood that the B POH block pair provides a reference point in the MTN POH frame, where L blocks or A blocks are inserted into their corresponding positions within the MTN POH frame when applicable. If no A or L block is transmitted in that corresponding MTN POH position, an idle block may occupy that position without loss of generality.

[0071] The MTN POH block is nominally divided by n*16384 64B / 66B blocks, where n represents the number of 5Gbit / s calendar time slots of the MTN part layer carrying the MTN path. Figure 4 The pseudo Ethernet packet length is selected so that the IPG appears at each regular n*16384 block interval for MTN POH insertion in order to be compatible with the MTN POH cycle requirements shown in . The pseudo Ethernet packet length is also selected so that it more effectively utilizes the intervals between MTN POH blocks and provides sufficient free blocks for IMP. For implementation convenience, the pseudo Ethernet packet length may be selected so that an integer number of GMP frames appear between each MTN POH block.

[0072] like Figure 5A As shown, choosing to fill 16380 64B / 66B blocks with pseudo Ethernet packets of length 2730 64B / 66B blocks leaves 4 64B / 66B blocks into which the source node can insert idle blocks, which covers the required (16384)x(200x10 -6 ) = 3.3 block rate difference. Since 16380 = 4x9x5x7x13, it is possible to divide 16380 64B / 66B blocks into three 5460 block groups (such as Figure 5B as shown) or six 2730 block groups (as Figure 5A), giving an expected integer number of GMP frames. Since MTN nodes switch streams of 64B / 66B blocks, they do not buffer entire Ethernet packets and are therefore largely independent of Ethernet packet length. Although 5460 block packets are more efficient, 2730 block packets may be preferred for compatibility with existing MTN implementations. Note that in FIG. 5A to FIG. 5C The location of the idle blocks in the GMP frame stream is not intended to be limiting. The source node provides the sink node with sufficient knowledge of the number of idle blocks that have been inserted into the interval of the GMP frame stream. In one example, the interval may be an MTN POH frame, such as Figure 5A shown.

[0073] like Fig. 6A As shown, GMP overhead 600 is typically divided into three segments (JC1 605+JC4 610, JC2 615+JC5 620, and JC3 625+JC6 630), which are sufficiently separated to prevent an error burst from affecting more than one segment. Figure 6B and Figure 6C As shown, a GMP frame consisting of 3-packet groups is created, where each packet of the group carries one segment of the GMP overhead. The payload area of ​​the 3-packet group is treated by GMP as a single combined payload area. Specifically, the GMP field of each GMP frame conveys how many 64B / 66B blocks in the payload area of ​​the next 3-packet group GMP frame will carry client data. The 6-byte GMP overhead format is shown in Fig. 6A and Figure 6B , where three rows of GMP overhead are placed into / T / blocks of three consecutive packets, i.e., JC1 605 and JC4 610 are placed in the corresponding first packet, JC2 615 and JC5 620 are placed in the corresponding second packet, and JC3 625 and JC6 630 are placed in the corresponding third packet, and the corresponding first packet, second packet and third packet constitute the corresponding GMP frame. Fields marked as "R" indicate reserved fields, such as bits, bytes, sets of bytes, or data blocks reserved for potential future use. Unlike ITU-T G.709, which relies on partial layer framing modes and fixed intervals to find GMP overhead, the example of the present invention uses MTN POH frames to periodically identify the beginning of GMP frames that embody the GMP window. As shown in FIG. FIG. 5A to FIG. 5C As shown, the first packet after the MTN POH frame is the beginning of the GMP frame. Figure 1 At 135, circuitry of source node 105 uses the identification of the beginning of the GMP frame to align multiple GMP frames with the MTN path overhead (POH) frame by inserting the MTN path overhead (POH) frame aligned with the beginning of the GMP frame to generate a rate-adapted GMP frame stream.

[0074] References Fig. 7A and Fig. 8A The two different options shown in the Figure 1 A more detailed explanation of the rate adaptation performed by the source node 105 using GMP and idle block insertion within multiple pseudo Ethernet packets.

[0075] Fig. 7A A first option for implementing a combination of a Generic Mapping Procedure (GMP) and an Idle Mapping Procedure (IMP) is shown, and Fig. 8A The second option is shown. In both options, the clock source used to derive the path signal rate results in a difference in the relative contributions of GMP and IMP. Both options use an integer number of groups of three fixed length packets between MTN POH block locations.

[0076] exist Fig. 7AIn the option shown in , the source node 705 receives a 64B / 66B coded block stream of CBR client data at 710. At 715, the source node 705 also defines a plurality of pseudo Ethernet packets having a packet start control block ( / S / ), a packet termination control block ( / T / ), and N-2 64B / 66B data block payloads. The source node 705 derives the MTN path signal rate relative to the reference clock rate at the source node 705, and derives the CBR client data stream rate from the 64B / 66B coded block stream of received CBR client data at 720. The GMP frame rate is set by the source node 705 so that the transmission MTN path signal frame and the predetermined fixed number of idle characters per frame will fill the server channel bandwidth evenly. The idle insertion position may vary between each MTN POH block, resulting in an average character per frame that fills the server channel bandwidth. The source node 705 then performs rate adaptation at 725 using the GMP and idle I / R within the plurality of pseudo Ethernet packets. At 725, the source node performs GMP by mapping a variable number of blocks of the 64B / 66B coded block stream of CBR client data into consecutive pseudo Ethernet packets and mapping a variable number of padding blocks into consecutive pseudo Ethernet packets. It is noted that although GMP is described in terms of bytes, the CBR client data bytes and padding blocks are each preferably grouped into 64B / 66B client data blocks and 64B / 66B padding blocks, respectively, and inserted as blocks. The variable number of blocks of the 64B / 66B coded blocks of CBR client data and the variable number of padding blocks are based on the path signal rate derived from the MTN path layer and the CBR client data flow rate. The source node 705 inserts the average of the variable number of blocks of the 64B / 66B coded blocks of CBR client data that arrived during multiple previous GMP frame periods as GMP overhead (GMP OH) into the packet termination control block of the current GMP frame to generate a GMP frame stream. The source node 705 then inserts a fixed number of idle blocks into the GMP frame stream to generate a CBR rate-adapted GMP frame stream at 735. The fixed number of idle blocks is selected as the minimum number of idle blocks required for downstream IMP processing to accommodate a maximum 200ppm clock offset between different FlexE clock domains. Inserting the minimum number of idle blocks improves the server channel bandwidth available for carrying CBR client signals. The source node 705 then transmits the CBR rate-adapted GMP frame stream, including the number of idle blocks, to one or more intermediate nodes via the MTN, and ultimately to the aggregation node 740.

[0077] When a CBR rate-adapted GMP frame stream is received at an intermediate node of the MTN, the intermediate node performs an idle mapping procedure (IMP) rate adaptation of the CBR rate-adapted GMP frame stream to modify the number of idle blocks within the CBR rate-adapted GMP frame stream, and then transmits the CBR rate-adapted GMP frame stream with the modified number of idle blocks to the next node of the MTN, which may be another intermediate node or a sink node. It will be appreciated by those skilled in the art that the intermediate node may be configured and provided in a conventional manner. As described above, the intermediate node inserts or deletes 64B / 66B idle blocks known in the art to synchronize data stream timing between its input rate and output rate without regard to the contents of the 64B / 66B blocks and 64B / 66BPOH blocks of CBR client data.

[0078] When the sink node 740 receives the CBR rate-adapted GMP frame stream with the modified number of idle blocks from the intermediate node through the MTN, at 745, the sink node 740 performs IMP to adapt the CBR rate-adapted GMP frame stream to the local reference clock at the sink node 740. Then, at 750, the sink node 740 determines the CBR client data stream rate based on the GMP overhead and the difference between the fixed number of idle blocks known in advance inserted by the source node and the modified number of idle blocks received at the sink node. Then, at 755, the sink node 740 extracts the CBR client data stream from the CBR rate-adapted GMP frame stream using the determined CBR client data stream rate to recover the original 64B / 66B encoded client signal 760. Therefore, at Fig. 7A In the example shown in , the CBR client data stream transmitted over the MTN is phase locked to the CalSlot clock by the source node 705, and the sink node 740 determines the original client signal data rate by examining the dynamic GMP overhead information and the average number of idle blocks it receives combined with the known number inserted by the source node 705. A phase locked loop (PLL) such as Fig. 9 The operation of the PLL 1130 shown in is an inherent part of the clock recovery circuit, as is known to those skilled in the art.

[0079] Figure 7B Shown in Fig. 7A730 of an exemplary packet termination control block ( / T / ) 775 of a CBR rate-adapted GMP frame stream generated by the source node 705 by placing the GMP overhead in the packet termination control block / T / . The GMP overhead of the packet termination control block 775 provides a count value (GMP Cm) 785 to inform the sink node 705: how many 64B / 66B encoded CBR client data blocks the source node 705 will send in the next window, and can indicate the number of bytes remaining in the buffer (GMP CnD) 780 at the source node 705. Therefore, the GMP overhead provides a beneficial feature of indicating the number of remaining bits or bytes in the buffer (CnD) at the source node 705 that cannot be transmitted in the next frame because they are part of a word or a 64B / 66B encoded block, respectively. This information provides the sink node 740 with higher precision (i.e., bit-level, rather than character-level) information about the CBR client data rate.

[0080] Figure 7C A block diagram is provided showing an example of a source node 900 according to the first option described above, wherein a variable number of data bytes and padding blocks are mapped into a continuous pseudo Ethernet packet to provide a GMP frame stream, and a fixed number of idle blocks are inserted into the GMP frame stream. In this example, the number of GMP padding blocks is changed to fill a GMP frame with a fixed period. If the 64B / 66B encoded client signal is slow, more padding blocks are added. If the 64B / 66B encoded client signal is fast, fewer padding blocks are added.

[0081] refer to Figure 7C, the GMP frame reference 940 and the MTN part frame reference 935 are generated by the reference generator 905 in response to the reference clock 910. The GMP frame reference 940 is provided to the GMP engine 930 and the pseudo Ethernet packet maker 950 of the source node 900. The reference clock 910 is also provided to the client rate measurement circuit 925 and is used by the client rate measurement circuit 925 to measure the clock rate of the received 64B / 66B coded block stream 915 of CBR client data received at the source node 900, so as to derive the CBR client data flow rate from the received 64B / 66B coded block stream 915 of CBR client data. The received 64B / 66B coded block stream 915 of CBR client data is provided to a first-in-first-out (FIFO) buffer 920. The measured clock rate is provided by the client rate measurement circuit 925 to the GMP engine 930. The GMP engine 930 utilizes the measured clock rate from the client rate measurement circuit 925 and the GMP frame reference 940 to determine a variable number of CBR client data 64B / 66B coded blocks and a variable number of padding blocks to be mapped into consecutive pseudo Ethernet packets. The GMP engine 930 provides an indicator 945 of the variable number of CBR client data 64B / 66B coded blocks (Cm) to the pseudo Ethernet packet maker 950. The pseudo Ethernet packet maker 950 defines a pseudo Ethernet packet having one / S / , one / T / , and N-2 64B / 66B data block payloads based on the Cm indicator 945, and inserts the number of CBR client data 64B / 66B coded blocks 915 into the pseudo Ethernet packet to generate a stream of GMP frames 952, wherein the Cm indicator 945 indicates the number of CBR client data 64B / 66B coded blocks 915 provided by the FIFO buffer 920 in response to a read signal from the pseudo Ethernet packet maker 950. The pseudo Ethernet packet maker 950 provides the pseudo Ethernet packets to a multiplexer 970, which is controlled by a multiplexer controller 955. The multiplexer controller 955 is controlled by the pseudo Ethernet packet maker 950 and the MTN section frame reference 935 to direct the multiplexer 970 to select between the pseudo Ethernet packets from the pseudo Ethernet packet maker 950, the POH blocks from the MTN POH 960, and the idle blocks from the idle inserter 965 to perform rate adaptation by inserting a fixed number of idle blocks into the GMP frame stream 952 to generate a CBR rate adapted GMP frame stream. The output of the multiplexer 970 is provided to the MTN section layer 975.

[0082] like Fig. 7A , Figure 7B and Figure 7CAs shown, in a first option for implementing GMP and IMP, the number of CBR client data 64B / 66B coded blocks mapped into consecutive pseudo Ethernet packets is variable, and the number of padding blocks mapped into consecutive pseudo Ethernet packets is variable, wherein the variable number of CBR client data 64B / 66B coded blocks and the variable number of padding blocks are based on MTN and CBR client data flow rates. Additionally, when this option is implemented, the number of idle blocks inserted into the GMP frame stream is fixed.

[0083] Fig.7D A block diagram is provided showing an example of a source node 902 according to the first option described above, which additionally provides multiplexing of 64B / 66B encoded blocks of CBR client data by multiplexing lower rate client data into pseudo Ethernet packets after MTN mapping has been performed.

[0084] refer to Fig.7D, the GMP frame reference 942 and the MTN part frame reference 937 are generated by the reference generator 907 in response to the reference clock 912. The GMP frame reference 942 is provided to the GMP engine 932 and the thread interleaver and pseudo Ethernet packet maker 924 of the source node 902. The reference clock 912 is also provided to the client rate measurement circuit 927 and is used by the client rate measurement circuit 927 to measure the clock rate of the received 64B / 66B coded block streams 917, 919 of CBR client data received at the source node 902, so as to derive the CBR client data flow rate from the received 64B / 66B coded block streams 917, 919 of CBR client data. The received 64B / 66B coded block streams 917, 919 of CBR client data are provided to the GMP thread frame first-in-first-out (FIFO) buffer 922. The GMP and thread frame FIFO buffer 922 performs GMP on the streams 917, 919 to define a plurality of GMP thread frames for each of the streams 917, 919, and the plurality of GMP thread frames are buffered by the FIFO buffer of the GMP and thread frame FIFO buffer 922. Each of the plurality of GMP thread frames includes a variable number of coded blocks of CBR client data and a variable number of padding blocks and GMP OH, as determined by the Cm indicator 947, as has been previously described. Then, in response to a read signal from the thread interleaver and pseudo Ethernet packet maker 924 to the GMP and thread frame FIFO buffer 922, the buffered GMP thread frames are provided from the GMP and thread frame FIFO buffer 922 to the thread interleaver and pseudo Ethernet packet maker 924. Then, the thread interleaver and pseudo Ethernet packet maker 925 maps the GMP thread frames into a plurality of consecutive pseudo Ethernet packets, the plurality of consecutive pseudo Ethernet packets including a plurality of data payload blocks divided into a plurality of interleaving threads and a plurality of GMP OH data payload blocks. The pseudo Ethernet packets are then assembled into a stream of GMP multiplexed frames 954 by the thread interleaver and pseudo Ethernet packet maker 924. The measured clock rate is provided by the client rate measurement circuit 927 to the GMP engine 932. The GMP engine 932 utilizes the measured clock rate from the client rate measurement circuit 927 and the GMP frame reference 942 to determine a variable number of CBR client data 64B / 66B coded blocks and a variable number of padding blocks to be mapped into consecutive pseudo Ethernet packets by the GMP and thread frame FIFO buffer 922. The GMP engine 932 provides an indicator 947 of the variable number of CBR client data 64B / 66B coded blocks (Cm) to the thread interleaver and pseudo Ethernet packet maker 924. The thread interleaver and pseudo Ethernet packet maker 924 defines a pseudo Ethernet packet having one / S / , one / T / , and N-2 64B / 66B data block payloads based on the Cm indicator 947.The thread interleaver and pseudo Ethernet packet maker issues a read signal to the GMP and thread frame FIFP buffer 922 to provide 64B / 66B encoded CBR client data blocks, and inserts the number 926 of 64B / 66B encoded CBR client data blocks indicated by the Cm 947 provided by the GMP engine 932 into the pseudo Ethernet packet to generate a GMP multiplexed frame stream 954. The thread interleaver and pseudo Ethernet packet maker 924 provides the stream of GMP multiplexed frames 954 to the multiplexer 972, which is controlled by the multiplexer controller 957. The multiplexer controller 957 is controlled by the thread interleaver and pseudo Ethernet packet maker 924 and the MTN part frame reference 937 to direct the multiplexer 972 to select between the GMP multiplexed frame 954, the POH blocks from the MTN POH 962 and the idle blocks from the idle inserter 967 to perform rate adaptation by inserting a fixed number of idle blocks between the pseudo Ethernet packets of the GMP multiplexed frame 954 to generate a rate adapted GMP multiplexed frame stream. The output of the multiplexer 972 is provided to the MTN part layer 977.

[0085] A second option for implementing a combination of GMP and IMP is Fig. 8A , where the source node 805 derives the MTN path signal rate (i.e., calendar slot rate) from the CBR client data stream rate. In a second option, a predetermined fixed GMPCm (or a defined repetitive pattern of Cm values) is used to create a packet stream that does not completely fill the space between the MTN POH blocks in order to create a CBR rate-adapted GMP frame stream that is slightly slower than the nominal server channel rate. In this option, GMP provides smooth delivery of payload CBR client data 64B / 66B coded blocks with path frame payload at a fixed rate per path frame.

[0086] exist Fig. 8AIn the option shown in , the source node 805 receives a 64B / 66B coded block stream of CBR client data at 810. At 815, the source node 805 defines multiple pseudo Ethernet empty packets with a packet start control block ( / S / ), a packet termination control block ( / T / ), and a data block payload. In this option, the data block payload 815 has a fixed capacity of N-2 64B / 66B data blocks. A fixed (i.e., static) GMP distribution of 64B / 66B coded blocks of CBR client data and a fixed GMP distribution of padding blocks in the packet payload are implemented to generate a GMP frame stream. At 820, the source node 805 places an indication of the fixed number of data blocks in a GMP overhead called rate adaptation OH, placed in the packet termination control block / T / . The indication of the fixed number of data blocks is optional because the fixed number is known to the source node 805 and the sink node 840. The source node 805 then inserts a variable (k) number of idle blocks into the GMP frame stream to generate a CBR rate-adapted GMP frame stream at 825. The source node 805 inserts a variable number of idle blocks to fill the remaining channel bandwidth. An indication of the variable number of idle blocks is placed in the rate adaptation overhead at 820 to inform the sink node of the number of idle blocks inserted by the source node. Alternatively, the indication of the variable number of idle blocks placed in the idle count overhead 890 can be a running number of idle blocks inserted by the source node from an arbitrary start time (i.e., T=0) with a modulo rollover. With this alternative, the sink node determines the number of idle blocks inserted by the source node in the interval by comparing the indication of the variable number of idle blocks in the currently received idle count overhead with the indication of the variable number of idle blocks in the previously received idle count overhead. The indication of the number of idle blocks inserted by the source node placed in the idle count overhead may optionally include a fractional portion of the next idle block to be sent. The fractional portion of the next idle block indicates that the source has some remaining bandwidth to fill, but that the bandwidth is insufficient to insert another idle block at this point. The idle fraction count information provides the receiver with an understanding of the increase in the source idle insertion rate. The source node 805 then transmits the CBR rate-adapted GMP frame stream to one or more intermediate nodes over the MTN and ultimately to the sink node 840.

[0087] When a CBR rate-adapted GMP frame stream is received at an intermediate node of the MTN, the intermediate node performs an idle mapping procedure (IMP) rate adaptation of the CBR rate-adapted GMP frame stream to modify the number of idle blocks in the CBR rate-adapted GMP frame stream, and then transmits the CBR rate-adapted GMR frame stream with the modified number of idle blocks to the next node of the MTN, which may be another intermediate node or a sink node. However, the change in the number of idle blocks is not placed in the idle count overhead, and does not replace the indication of the number of idle blocks inserted by the source node 805.

[0088] When the sink node 840 receives the CBR rate-adapted GMP frame stream with the modified number of idle blocks over the MTN, at 830, the sink node 840 performs an IMP to adapt the CBR rate-adapted GMP frame stream to the local reference clock at the sink node 840. Then, at 835, the sink node 840 determines a CBR client data flow rate of the CBR client flow based on the GMP overhead and the difference between the indication of the variable number of idle blocks inserted into the CBR rate-adapted GMP frame stream by the source node 805 and the modified number of idle blocks received at the sink node 840. Then, at 845, the sink node 840 extracts the CBR client data flow rate from the CBR rate-adapted GMP frame stream using the determined CBR client data flow rate to recover the 64B / 66B coded blocks of the original CBR client data 850. Therefore, at 846, the sink node 840 extracts the CBR client data flow rate from the CBR rate-adapted GMP frame stream using the determined CBR client data flow rate. Fig. 8A In the example shown in , the CBR client data stream transmitted over the MTN is not phase locked to the CalSlot bit rate, and the sink node 840 determines the original CBR client data rate based on the number of free blocks remaining after IMP processing at the sink node 840 and optionally the free count information inserted by the source node 805. The CalSlot clock is a divided frequency of the local reference clock at the sink node.

[0089] Figure 8B Shown in Fig. 8A 820 of the exemplary packet termination control block ( / T / ) 875 of a CBR rate adaptation GMP frame generated by the source node 805 by placing the GMP OH 880, 885 and the idle count overhead 890 in the packet termination control block / T. Alternatively, the GMP overhead of the termination control block 875 may provide a count value (GMP Cm) 885 to inform the sink node 840: how many 64B / 66B coded blocks the source node 805 will send in the next window, and may indicate the number of bytes remaining in the buffer (GMP CnD) 880 at the source node 805. Since these values ​​(Cm and CnD) are predetermined and fixed, they are optionally inserted into the GMP overhead. The packet termination control block 875 additionally includes an idle count 890 of a variable number of idle blocks inserted by the source node 805, and optionally a fractional number of idle counts to be sent by the source node 805 in the next frame 895.

[0090] Figure 8CA block diagram is provided showing an example of a source node 1000 according to the second option described above, wherein a fixed number of data blocks and padding blocks are mapped into a continuous pseudo Ethernet packet to generate a GMP frame stream, and a variable number of idle blocks are inserted into the GMP frame stream. In this option, the faster the client rate, the less time it will take to accumulate the payload 64B / 66B client data blocks within the GMP frame. The slower the client rate, the longer it will take to accumulate the payload data 64B / 66B client data blocks within the GMP frame. Therefore, the period of the GMP frame is determined by the bit rate of the 64B / 66B encoded blocks 1015 of the incoming CBR client data.

[0091] refer to Figure 8C, the output 1011 of the client rate measurement circuit 1025 is used to clock the reference generator 1005. The reference generator 1005 generates an MTN partial frame reference 1035 using the reference clock 1010, and generates a GMP frame reference 1040 using the output 1011 from the client rate measurement circuit 1025. The GMP frame reference 1040 is provided to the GMP engine 1030. The client rate measurement circuit 1025 is used to measure the clock rate of the 64B / 66B coded blocks 1015 of CBR client data received at the source node 1000, wherein the 64B / 66B coded blocks 1015 of CBR client data are provided to the client rate measurement circuit 1025 and the FIFO buffer 1020 to derive the CBR client data flow rate from the received 64B / 66B coded blocks 1015 of CBR client data. In this example, the measured clock rate may not be provided to the GMP engine 1030, and the GMP engine 1030 is considered to be a free-running GMP engine without external time alignment. The GMP engine 1030 uses the GMP frame reference 1040 to determine the location of a fixed number of 64B / 66B client data blocks 1015 to be mapped into consecutive pseudo Ethernet packets. The GMP engine 1030 provides an indicator of a fixed number of CBR client data blocks (Cm) 1045 to the pseudo Ethernet packet maker 1050. The pseudo Ethernet packet maker 1050 defines a pseudo Ethernet packet having one / S / , one / T / , and N-2 64B / 66B data block payloads based on the Cm indicator 1045, and inserts a plurality of CBR client data blocks 1015 provided by the FIFO buffer 1020 into the pseudo Ethernet packet based on the Cm indicator 1045 to generate a GMP frame stream 1052. The pseudo Ethernet packet maker 1050 provides a GMP frame stream 1052 to a multiplexer 1070. A multiplexer controller 1055 receives the output 1052 of the pseudo Ethernet packet maker 1050, the GMP frame reference 1040, the MTN partial frame reference 1035, and the measured clock rate from the client rate measurement circuit 1025, and in response to these inputs directs the multiplexer 1070 to select between the GMP frame stream 1052 from the pseudo Ethernet packet maker 1050, the POH blocks from the MTN POH 1060, and the idle blocks from the idle inserter 1065 to perform rate adaptation by inserting a variable number of idle blocks into the GMP frame stream 1052 to generate a CBR rate-adapted GMP frame stream. The multiplexer controller 1055 utilizes the MTN partial frame reference 1035 to determine, for each block, which input to the multiplexer 1070 will appear at the output of the multiplexer. The output of the multiplexer 1070 is provided to the MTN part layer 1075 .

[0092] The CBR client data flow rate affects the number of idle blocks that will be inserted into the GMP frame stream to generate the CBR rate-adapted GMP frame stream. For example, if the 64B / 66B coded blocks of the CBR client data are fast, each GMP frame will be assembled in a shorter period of time. Therefore, there will be more GMP frames per second to accommodate a larger number of CBR client bits per second. Since the MTN path POH is used to delimit the GMP frames, the MTN path will match the CBR client flow data rate faster and more MTN POH 1060 will be required per second. However, since the MTN frame portion runs at the rate of the reference clock 1010 and there are more MTN POH blocks per second, there will be fewer idle blocks from the idle inserter 1065 required to fill the MTN portion. Conversely, if the 64B / 66B coded blocks of the CBR client data are slow, there will be fewer GMP frames per second. The MTN path is correspondingly slower, resulting in fewer MTN POH 1060 required per second. More free blocks are then needed from the free inserter 1065 to fill the space in the MTN portion. The number of free blocks to be inserted is reported at 1035 to include in the Figure 8B The idle count overhead 890 and the idle score 895 are included.

[0093] like Fig. 8A , Figure 8B and Figure 8C As shown, in the second option for implementing GMP and IMP, when this option is implemented, the number of CBR client data blocks mapped into consecutive pseudo Ethernet packets is fixed, the number of padding blocks mapped into consecutive pseudo Ethernet packets is fixed, and the number of idle blocks inserted into the GMP frame stream is variable.

[0094] In summary, in the first option, the GMP frame rate is determined by the reference clock at the source node, while in the second option, the GMP frame rate is determined by the CBR client signal rate. Therefore, in the first option, the number of free blocks sent by the source is fixed, while in the second option, the number of free blocks is variable.

[0095] In the first option, the GMP frame rate is fixed and determined by the reference clock at the source. The CBR client data stream rate is variable, and therefore, the number of padding blocks inserted into the GMP frame is variable. When the CBR client data stream rate is slow, more padding blocks are inserted, and when the CBR client data stream rate is fast, fewer padding blocks are required. In the first option, since both the MTN path signal rate (i.e., calendar slot rate) and the GMP frame rate are referenced to the same reference clock, the number of idle blocks inserted into the GMP frame stream is fixed.

[0096] In the second option, the GMP frame rate is an expanded version of the CBR client data flow rate. For example, GMP frame rate = (client signal rate) * (66 / 64) * (total number of blocks carrying client data in the GMP frame) / (total number of blocks in the GMP frame). The GMP frame rate is a constant multiple of the CBR client data flow rate because the number of padding blocks is fixed. Therefore, the GMP frame rate is variable because the CBR client data flow rate is variable. Since the MTN path signal rate is fixed, the number of idle blocks inserted into the GMP frame stream is variable. An indicator of the number of inserted idle blocks is inserted into the GMP frame stream to communicate the variable number of idle blocks to the aggregation node.

[0097] Fig. 9 is a diagram showing a sink node ( Fig. 7A 740 or Fig. 8A 840), the sink node is used to receive Figure 7C and / or Figure 8C The received MTN portion signal 1105 carries the CBR rate adaptation GMP frame stream. The MTN and GMP frames are recovered from the CBR rate adaptation GMP frame stream by the recover MTN and GMP frame circuit 1115 and provided to the count received idle blocks, recover GMP overhead and recover idle count overhead circuit 1120. When the number of idle blocks inserted into the CBR rate adaptation GMP frame stream by the source node is fixed, as shown in FIG. 7A to 7C In the first option described, a fixed number of free blocks is known to the sink node. FIG. 8A to FIG. 8C In the second option described, a variable number of idle blocks inserted by the source node is reported in the overhead. The actual number of idle blocks received at the sink node is a combination of the number of idle blocks inserted by the source node and modified by the intermediate nodes performing IMP. The MTN path signal rate measurement circuit 1110 receives the incoming MTN part signal and measures the MTN path signal bit rate. The measured bit rate is scaled by the DSP engine 1125 to recover the client payload data rate, which varies according to the number of received idle blocks obtained by the circuit 1120, the idle count recovered by the circuit from the idle count overhead, and the Cm:CnD value recovered from the GMP overhead. Extract client payload blocks 1135 use the Cm value from the circuit 1120 to identify the payload and padding blocks within the GMP frame. When the client payload bits from the 64B / 66B data blocks are written into the FIFO buffer 1140, the padding blocks and idle blocks are discarded. A phase locked loop (PLL) 1130 is controlled by the DSP engine 1125 to read from the FIFO buffer 1140 at the CBR client data stream rate.

[0098] In summary, the first option provides the potential clock recovery performance increase achieved by variable GMP with CnD and the possibility of multiplexing lower rate clients, which will be discussed in more detail below. The main advantage of the second option is that the use of static GMP simplifies both the source and sink nodes by using a single process instead of using both GMP and IMP.

[0099] The first option provides a method for carrying a single CBR client data stream in one of the multiple 5Gbit / s MTN partial layer calendar slots. However, there are applications where it is desirable to carry multiple different lower rate CBR client data streams in a single calendar slot. In order to carry multiple different lower rate CBR client data streams in a single calendar slot, a multiplexing capability is added to the first option.

[0100] As described above, the first option of the source node utilizing a variable number of CBR client data blocks, a variable number of padding blocks per GMP frame, and a fixed number of idle blocks within the MTN path signal also allows the possibility of multiplexing multiple lower rate clients into each pseudo Ethernet packet by dividing the packet payload data blocks into interleaved sets. Each set of GMP overhead can be carried in an additional data block at the end of the packet. With this option, since GMP performs rate adaptation, the number of idle blocks is independent of the multiplexed client streams and can remain fixed.

[0101] While combining lower rate clients into 5Gb / s MTN channels is known in the art, known methods perform multiplexing of client signals prior to MTN mapping. In contrast, the present invention examples provide for multiplexing of lower rate client data into pseudo Ethernet packets after MTN mapping has been performed, as shown in reference Fig.10 As shown in the system 1200 shown in.

[0102] In general, multiplexing of a plurality of 64B / 66B coded blocks of a CBR client data stream 1205, 1210 is performed at a source node by a corresponding GMP block 1225, 1230 to define a plurality of corresponding GMP thread frames 1235, 1240 for each of the 64B / 66B coded block streams of CBR client data, wherein each of the plurality of GMP thread frames 1235, 1240 includes a variable number of coded blocks of CBR client data and a variable number of padding blocks and a GMPOH for the corresponding stream of 64B / 66B coded blocks of CBR client data. Additionally, a thread interleaver and pseudo Ethernet packet maker 1245 defines a plurality of pseudo Ethernet packets, wherein each of the plurality of pseudo Ethernet packets includes a plurality of data payload blocks divided into a plurality of interleaved threads and a plurality of interleaved GMP overhead (OH) data payload blocks. Specifically, each of the plurality of interleaved threads may include an integer number of data payload blocks. Then, a variable number of coded client data blocks and a variable number of padding blocks are mapped into one of a plurality of interleaved threads of consecutive pseudo Ethernet packets, and the GMP OH is mapped into a plurality of interleaved GMP OH data payload blocks by the thread interleaver and pseudo Ethernet packet maker 1245. Then, a GMP multiplexed frame stream 1250 is assembled by the thread interleaver and pseudo Ethernet packet maker 1245 including consecutive pseudo Ethernet packets. Then, the GMP multiplexed frame stream 1250 is provided to the IMP block 1255, which inserts a fixed number of idle blocks between consecutive pseudo Ethernet packets of the GMP multiplexed frame stream, and inserts an MTN path overhead (POH) frame aligned with a plurality of GMP multiplexed frames into the GMP multiplexed frame stream 1250 to generate a GMP multiplexed rate adaptation frame stream. Specifically, the 64B / 66B coded blocks of the CBR client threads 1235, 1240 may be mapped into a plurality of interleaved threads of consecutive pseudo Ethernet packets in a round-robin manner by the thread interleaver and pseudo Ethernet packet maker 1245.

[0103] Thus, multiple CBR client data streams can be multiplexed into each pseudo Ethernet packet. In a specific example, the coded blocks of the CBR client are mapped into the interleaved threads of the pseudo Ethernet packet in a round-robin manner by the thread interleaver and pseudo Ethernet packet maker 1245. Each interleaved thread is then treated as its own channel, including having its own GMP overhead. If the CBR client data stream occupies more than one thread, the threads are combined to create a higher rate channel, and a single GMP overhead block is used for multiple threads. Thus, each thread provides a channel of less than 5 Gbit / s, which can be time-division multiplexed together in a 5 Gbit / s calendar slot.

[0104] Fig.10The multiplexing method shown in 1205 can be modified to be applicable to packet-based client data streams other than 64B / 66B encoded CBR client data streams. Specifically, if the 64B / 66B encoded CBR client data streams 1205, 1210 are packet-based client data streams (such as Ethernet-based streams), the packet-based client data stream is treated as a bit stream and encoded into multiple 64B / 66B encoded blocks. Once the packet-based client data stream has been encoded into 64B / 66B encoded blocks, Fig.10 The GMP and IMP blocks 1225, 1230 shown in then provide an interleaved 64B / 66B encoded packet-based client data stream.

[0105] Fig.10 The multiplexing circuit shown in FIG. 7 can be implemented in the source node 705, such as 7A to 7C Multiplexing is used to implement the first option described above because it uses GMP to perform dynamic rate adaptation for each individual thread within a packet, and uses IMP to perform rate adaptation at the packet level. Since the CBR client for each thread may have a different source clock, it may be more difficult to use IMP within the MTN path flow for thread-level rate adaptation, as described above with reference to FIG. 8A to FIG. 8C In the second option described.

[0106] Fig.11A It is shown in Fig.10 12, where each thread 1261, 1262, 1263, 1264, 1265, 1266 of a 64B / 66B encoded block 1260 of CBR client data has its own GMP overhead 1275, which is used to adapt the CBR client data rate to the channel provided by the thread. The GMP overhead 1275 occupies one or more data block locations at the end of the pseudo Ethernet packet. If the client occupies k threads, the GMP overhead of the highest number of threads can be used, resulting in a GMP granularity of k blocks. Fig.11A As shown, in this case, the termination control block / T / 1270 at the end of the packet carries information other than the GMP overhead, such as the multiplexing structure indicator field (MSI) 1280. The packet length 2730 in this example shows an advantageous packet length when multiplexing is used, such as Fig.13 As shown, and illustrated and described with reference to Table 1 below.

[0107] Fig. 11BThe positioning of the GMP thread frame in the MTN path GMP frame for multiplexing CBR clients is shown. Specifically, a thread frame 1287 of a 64B / 66B coded block for CBR client data 1289, 1290, 1292 is defined, including a coded block and a padding block 1293 of the client data and a GMP OH 1289. The thread interleaver and pseudo Ethernet packet 1296 maker define multiple pseudo Ethernet packets, wherein each of the multiple pseudo Ethernet packets includes multiple data payload blocks divided into multiple interleaved threads and multiple interleaved GMP overhead (OH) data payload blocks. Then, a variable number of coded blocks and a variable number of padding blocks are mapped to one of the multiple interleaved threads of a continuous pseudo Ethernet packet, and the GMP OH is mapped to multiple interleaved GMP OH data payload blocks by the thread interleaver and pseudo Ethernet packet 1296. Then, the GMP multiplexed frame stream 1298 is assembled by the thread interleaver and pseudo Ethernet packet 1296 including the continuous pseudo Ethernet packets. In this particular example, the GMP multiplexed frame stream 1298 includes 3 pseudo Ethernet packets that carry 32 GMP thread frames.

[0108] When multiplexing is limited to a single 3-packet GMP frame 1300, such as Fig. 12A As shown, the number of threads may be an integer divisor of the number of blocks in a pseudo Ethernet packet available for carrying client payload, such that each pseudo Ethernet packet contains the same number of blocks per thread, wherein each pseudo Ethernet packet 1305, 1310, 1315 includes a GMP overhead 1322, 1327, 1332 for a payload block 1320, 1325, 1330, respectively. Thus, the pseudo Ethernet packet sizes 1305, 1310, 1315 are selected such that the number of available payload blocks 1320, 1325, 1330 is factored into a convenient and efficient number of threads. The total number of threads may be multiplied by spreading them across multiple GMP frames to form an extended GMP frame, such as Fig. 12B As shown. Fig. 12B As shown, the extended GMP frame 1350 is composed of six pseudo Ethernet packets (i.e., a set of two 3-packet GMP frames) 1360, 1362, 1364, ... 1366 to double the number of available threads while still using the same number of GMP overhead bytes 1370, 1372, 1374, ... 1376 per pseudo Ethernet packet 1360, 1362, 1364, ... 1366. Specifically, Fig. 12B and Fig.11A and Fig. 11B The same exemplary pseudo-Ethernet packet format is used. Fig. 12A A per-packet GMP overhead field is provided for 32 threads. Fig. 12BFIG. 1 shows the expansion of the GMP multiplexing frame to six packets in order to accommodate 64 threads. Since the MTN multiframe 1380 can be composed of 24 pseudo Ethernet packets, such as Fig.13 As shown, up to eight sets of GMP frames 1382, 1384, 1386, 1388, 1390, 1392, 1394, 1396 may therefore be conveniently combined into an extended GMP frame to provide eight times the threads.

[0109] Table 1 shows some potentially advantageous choices for pseudo-Ethernet packet size and number of threads in both GMP frames and extended GMP frames. Note that it is possible to divide the 5Gb / s partial calendar slots into four sets of interleaved individual 1.25Gb / s calendar slots and run the MTN path signals at the corresponding 1 / 4 rates. Table 1 shows the resulting thread rates for two calendar slot rates. Note that the thread payload rate in Table 1 is the channel capacity for carrying client data streams in the 64-bit payload field of the associated 64B / 66B blocks. Option A in Table 1 is attractive for three reasons. First, it provides 32 threads. As a power of 2, 32 is consistent with other multiplexed channelizations that use powers of 2 for implementation convenience. Second, its 155.622Mbit / s capacity is effective for carrying traditional 155.52Mb / s SDH VC-4 / STM-1 client signals. Third, the resulting packet has a length of 2730 blocks, which allows the insertion of a minimum number of idle blocks to cover a potential clock offset of 200ppm, as shown in Table 1. Fig.13 As shown. Therefore, it effectively utilizes the available MTN frame bandwidth. Option B of Table 1 retains these features, but the number of threads is four times that of Option A and the rate is exactly 1 / 4 of Option A. Option C of Table 1 uses a slightly less efficient 2695-block pseudo-Ethernet packet and a less convenient number of threads. However, Option C is very suitable for carrying Ethernet client signals. For example, 100MBASE-R Ethernet client data using native 4B / 5B block encoding can be effectively carried in a 131.82Mb / s channel created based on six threads for the 5Gb / s calendar time slot case or 24 threads for the 1.25Gb / s calendar time slot case. It is also assumed that the client uses 4B / 5B block encoding, and the three threads of the 1.25Gb / s calendar time slot case can be combined into a 16.478Mb / s channel for the efficient transmission of 10MBASE-R Ethernet client data. Note that Fig.13 Use the 2730 block packet size for Option A and Option B in Table 1.

[0110] Table 1 - Potential thread reuse configurations

[0111]

[0112] If the MTN trail signal occupies k calendar slots of the MTN portion, there will be k times more pseudo Ethernet packets between the MTN POH blocks. Rather than increasing the thread rate by a factor of k, the GMP overhead can be spread over k interleaved GMP multiplex frames so that the thread rate remains constant regardless of the value of k.

[0113] Fig.14A A flow chart 1400 is shown of a method for performing rate adaptation on a constant bit rate (CBR) client data stream for transmission over a metropolitan transport network (MTN). The method 1400 is performed by a source node, such as Fig. 7A shown.

[0114] The method 1400 begins at operation 1405 by receiving a 64B / 66B encoded block stream of CBR client data at a source node.

[0115] At operation 1410, method 1400 continues by defining a plurality of pseudo Ethernet packets. Specifically, at operation 1410, a source node creates a plurality of pseudo Ethernet null packets having a fixed payload capacity of one packet start control block ( / S / ), one packet termination control block ( / T / ), and N-2 64B / 66B data blocks. The method continues at 1415 by assembling a general mapping procedure (GMP) frame stream including a plurality of GMP frames by mapping a variable number of blocks of a 64B / 66B coded block stream of CBR client data, a variable number of padding blocks, and GMP overhead into consecutive pseudo Ethernet packets in the plurality of pseudo Ethernet packets. In a specific example, the number of consecutive pseudo Ethernet packets of the plurality of GMP frames is equal to three, and mapping the GMP overhead into consecutive pseudo Ethernet packets may include mapping a portion of the GMP overhead into a packet termination control block or a packet start control block of each of the three consecutive pseudo Ethernet packets. In another example, each of the plurality of pseudo Ethernet packets includes a packet start control block having a plurality of bytes, a plurality of data payload blocks, and a packet termination control block having a plurality of bytes, and assembling the plurality of GMP frames includes mapping a variable number of blocks and a variable number of padding blocks of a 64B / 66B coded block stream of CBR client data into the plurality of data payload blocks of consecutive pseudo Ethernet packets. The GMP overhead may be mapped into a packet start control block or a packet termination control block of consecutive pseudo Ethernet packets.

[0116] At operation 1420, method 1400 continues by inserting a fixed number of idle blocks into the GMP frame stream, and method 1400 ends at operation 1425 by inserting an MTN path overhead (POH) frame aligned with multiple GMP frames into the GMP frame stream to generate a CBR rate adapted GMP frame stream.

[0117] Fig. 14B It shows that 7A to 7C A flow chart 1450 of a method specifically performed by a source node for performing rate adaptation on constant bit rate (CBR) client data for transmission over a metropolitan transport network (MTN) is shown.

[0118] The method begins at operation 1455 by deriving the MTN path signal rate based on a reference clock at a source node and continues at operation 1460 by deriving the CBR client data stream rate from a 64B / 66B coded block stream of CBR client data.

[0119] The method continues at operation 1465 by assembling a plurality of generic mapping procedure (GMP) frames by mapping a variable number of blocks of a 64B / 66B coded block stream of CBR client data, a variable number of padding blocks, and a GMP overhead into consecutive pseudo Ethernet packets in the plurality of pseudo Ethernet packets, wherein the variable number of blocks of the 64B / 66B coded block stream of CBR client data and the variable number of padding blocks are based on a difference between a path signal rate derived from the MTN and the CBR client data stream rate.

[0120] The method continues at operation 1470 by inserting a fixed number of idle blocks into the GMP frame stream and ends at operation 1475 by inserting an MTN path overhead (POH) frame aligned with a plurality of GMP frames into the GMP frame stream to generate a CBR rate adapted GMP frame stream.

[0121] Fig.15A It shows that Fig. 8A A flow chart 1500 of a method specifically performed by a source node for performing rate adaptation on constant bit rate (CBR) client data for transmission over a metropolitan transport network (MTN) is shown.

[0122] The method 1500 begins at operation 1505 by receiving a stream of encoded blocks of CBR client data at a source node.

[0123] At operation 1510, method 1500 continues by defining a plurality of pseudo Ethernet packets. Specifically, at operation 1510, a source node creates a plurality of pseudo Ethernet null packets having a packet start control block ( / S / ), a packet termination control block ( / T / ), and a fixed payload capacity of N-2 data blocks. The method continues at 1515 by assembling a general mapping procedure (GMP) frame stream including a plurality of GMP frames by mapping a fixed number of blocks of a coded block stream of CBR client data, a fixed number of padding blocks, and a GMP overhead into consecutive pseudo Ethernet packets in the plurality of pseudo Ethernet packets. In a specific example, the number of consecutive pseudo Ethernet packets of the plurality of GMP frames is equal to three, and mapping the GMP overhead into consecutive pseudo Ethernet packets may include mapping a portion of the GMP overhead into a packet termination control block of each of the three consecutive pseudo Ethernet packets. In another example, each of the plurality of pseudo Ethernet packets includes a packet start control block having a plurality of bytes, a plurality of data payload blocks, and a packet termination control block having a plurality of bytes, and assembling the plurality of GMP frames includes mapping a fixed number of blocks and a fixed number of padding blocks of the coded block stream of the CBR client data into the plurality of data payload blocks of the consecutive pseudo Ethernet packets. The GMP overhead may be mapped into the packet start control block or the packet termination control block of the consecutive pseudo Ethernet packets.

[0124] At operation 1520, the method 1500 continues by inserting a variable number of idle blocks into the GMP frame stream and inserting an indication of a variable number of idle blocks into the GMP frame stream. The method 1500 ends at operation 1525 by inserting an MTN path overhead (POH) frame aligned with a plurality of GMP frames into the GMP frame stream to generate a CBR rate-adapted GMP frame stream.

[0125] Fig. 15B It shows that FIG. 8A to FIG. 8C A flow chart 1550 of a method specifically performed by a source node for performing rate adaptation on constant bit rate (CBR) client data for transmission over a metropolitan transport network (MTN) is shown.

[0126] The method 1550 begins at operation 1555 by deriving the MTN path layer flow rate based on a reference clock at a source node and continues at operation 1560 by deriving the CBR client data flow rate from a 64B / 66B coded block stream of CBR client data.

[0127] The method continues at operation 1565 by assembling a generic mapping procedure (GMP) frame stream comprising multiple GMP frames by mapping a fixed number of blocks of the encoded block stream of CBR client data, a fixed number of padding blocks, and GMP overhead into consecutive pseudo-Ethernet packets in the multiple pseudo-Ethernet packets, wherein the fixed number of padding blocks is based on the CBR client data stream rate.

[0128] The method continues at operation 1570 by inserting a variable number of idle blocks into the GMP frame stream and inserting an indication of the variable number of idle blocks inserted into the GMP frame stream by the source node, wherein the variable number of idle blocks is based on a difference between the MTN path signal rate and the CBR client data stream rate.

[0129] The method ends at operation 1575 by mapping the indication of the number of idle blocks inserted into the packet termination control block of the pseudo Ethernet packet before the variable number of idle blocks is inserted into the GMP frame stream by the source node. In an alternative example, the indication of the variable number of idle blocks can be mapped to the packet start control block instead of the packet termination control block. In a specific example, the indication of the variable number of fractional remainders of the idle blocks is inserted into the GMP frame stream. In another alternative example, the number of idle blocks and the fractional idle remainder represent the modulo running count of the number of idle blocks transmitted since any start time, rather than the number of idle blocks inserted immediately before or after the packet containing the overhead. In this example, the number of idle blocks transmitted between packets by the receiver is determined as the difference between the idle count overhead values ​​in those corresponding packets.

[0130] Fig.16A Flowchart 1600 shows the flow of CBR client data after rate adaptation. Fig. 14B Continuation of the method shown in . Fig.16A At least a portion of the method 1600 shown in FIG. 1 is performed by an intermediate node of the MTN.

[0131] At operation 1605, the method 1600 begins by transmitting a CBR rate-adapted GMP frame stream, including a fixed number of idle blocks, over the MTN. Fig. 7A The source node shown in FIG. 1 can transmit a CBR rate-adapted GMP frame stream through the MTN.

[0132] At operation 1610, the method continues by receiving a CBR rate-adapted GMP frame stream and a fixed number of idle blocks at a first intermediate node of the MTN. The method continues at operation 1615 by performing an idle mapping procedure (IMP) rate adaptation on the CBR rate-adapted GMP frame stream received at the first intermediate node to modify the number of idle blocks.

[0133] At operation 1620, the method continues by transmitting the CBR rate-adapted GMP frame stream with the modified number of free blocks from the first intermediate node to the next node of the MTN. The next node may be the next intermediate node or a sink node. If the next node is an intermediate node, the method continues as in operation 1615 by performing IMP rate adaptation again. If the next intermediate node is a sink node, the method continues at Fig. 16B Continue at.

[0134] Fig. 16B Flow chart 1650 shows a method performed by an aggregation node of MTN, as previously referenced Fig. 7A and Fig. 9 described.

[0135] The method 1650 begins at operation 1655 by receiving a CBR rate-adapted GMP frame stream having a modified number of idle blocks at a sink node, and continues at operation 1657 by performing an idle mapping procedure (IMP) rate adaptation to adapt the CBR rate-adapted GMP frame stream to a local reference clock at the sink node. The method 1650 continues at operation 1660 by determining a CBR client data stream rate for the CBR client data stream based on the GMP overhead and the difference between a fixed number of idle blocks inserted into the CBR rate-adapted GMP frame stream by a source node and a modified number of idle blocks received at the sink node. In this example, the fixed number of idle blocks inserted by the source node is known by the sink node.

[0136] The method ends at operation 1665 by extracting a stream of coded blocks of CBR client data from the CBR rate adapted GMP frame stream using the determined CBR client data stream rate.

[0137] Fig.17A Flowchart 1700 shows the flow of CBR client data after rate adaptation. Fig. 15B Continuation of the method shown in . Fig.17A The method 1700 shown in FIG. 1 is at least partially performed by an intermediate node of the MTN.

[0138] At operation 1705, the method 1700 begins by transmitting a CBR rate adapted GMP frame stream over the MTN, including a variable number of idle blocks and an indication of a variable number of idle blocks inserted by a source node. Fig. 8A The source node shown in FIG. 1 can transmit a CBR rate-adapted GMP frame stream through the MTN.

[0139] At operation 1710, the method continues by receiving a CBR rate-adapted GMP frame stream, a variable number of idle blocks, and an indication of a variable number of idle blocks inserted by a source node at an intermediate node of the MTN. The method continues at operation 1715 by performing an idle mapping procedure (IMP) rate adaptation on the CBR rate-adapted GMP frame stream received at the intermediate node to modify the number of idle blocks.

[0140] At operation 1720, the method continues by transmitting the CBR rate adapted GMP frame stream with the modified number of free blocks and the indication of the variable number of free blocks inserted by the source node from the intermediate node to the next node of the MTN. The next node may be the next intermediate node or a sink node. If the next node is an intermediate node, the method continues as in operation 1715 by performing IMP rate adaptation again. If the next intermediate node is a sink node, the method continues at Fig. 17B Continue at.

[0141] Fig. 17B Flow chart 1750 shows a method performed by an aggregation node of MTN, as previously referenced Fig. 8A and Fig. 9 described.

[0142] The method 1750 begins at operation 1755 by receiving at a sink node a CBR rate-adapted GMP frame stream having a modified number of free blocks and an indication of a variable number of free blocks inserted by a source node, and continues at operation 1757 by performing an idle mapping procedure (IMP) rate adaptation to adapt the CBR rate-adapted GMP frame stream to a local reference clock at the sink node. The method 1750 continues at operation 1760 by determining a CBR client data stream rate for the CBR client data stream based on the GMP overhead and a difference between the indication of the variable number of free blocks inserted by the source node and the modified number of free blocks received at the sink node.

[0143] The method ends at operation 1765 by extracting a stream of coded blocks of CBR client data from the CBR rate adapted GMP frame stream using the determined CBR client data stream rate.

[0144] Fig.14A , Fig. 14B , Fig.15A , Fig. 15B , Fig.16A , Fig. 16B , Fig.17A and Fig. 17B The flowchart of assumes that the CBR client data stream being rate adapted is from a single client data stream. Fig.18AThe flowchart 1800 shown in FIG. 1 assumes that the client data stream is from two or more client data streams and multiplexing is performed as previously described with reference to FIG. Fig.10 described.

[0145] The method 1800 begins at operation 1805 by receiving two or more CBR client data streams at a source node. Each of the two or more CBR client data streams includes a client payload and any necessary operations, administration, and maintenance (OAM) overhead for the client. The two or more CBR client data streams may be received substantially simultaneously, or alternatively, one or more of the streams may be received non-simultaneously.

[0146] At operation 1810, method 1800 continues by defining a corresponding plurality of GMP thread frames for a 64B / 66B coded block stream for two or more CBR client data, wherein each of the corresponding plurality of GMP thread frames includes a variable number of coded blocks of the CBR client data, a variable number of padding blocks, and a GMP overhead for the 64B / 66B coded block stream of the corresponding CBR client data.

[0147] At operation 1815, method 1800 continues by defining a plurality of pseudo Ethernet packets, wherein each of the plurality of pseudo Ethernet packets comprises a plurality of data payload blocks divided into a plurality of interleaving threads and a plurality of interleaving GMP overhead (OH) data payload blocks. Optionally, the plurality of data payload blocks in each of the plurality of interleaving threads may be an integer number of data payload blocks.

[0148] The method continues at operation 1820 by mapping a corresponding plurality of thread frames of a 64b / 66b coded block stream for each of two or more CBR client data 64b / 66b client data streams into consecutive pseudo Ethernet packets in the plurality of pseudo Ethernet packets by mapping a variable number of coded blocks and a variable number of padding blocks into one of a plurality of interleaved threads of consecutive pseudo Ethernet packets and mapping the GMP OH into a plurality of interleaved GMP overhead data payload blocks. In a specific example, the mapping is performed in a round-robin manner. Although a round-robin approach has been described herein, this is not intended to be limiting in any way, and other approaches may be used without exceeding the scope.

[0149] At operation 1825, the method continues by assembling a GMP multiplexed frame stream comprising consecutive pseudo Ethernet packets.

[0150] At operation 1830, method 1800 continues by inserting a fixed number of idle blocks between consecutive pseudo Ethernet packets of the GMP multiplexed frame stream. Method 1800 ends at operation 1835 by inserting MTN path overhead (POH) frames aligned with the GMP multiplexed frame stream to generate a GMP multiplexed rate adaptation frame stream.

[0151] Fig.18B A method 1850 for rate adaptation and multiplexing of two or more client data streams is shown. Rate adaptation of two or more client data streams may be performed by Fig.7D The system shown in FIG. 1 is implemented, and the multiplexing of two or more client data streams can be performed by Fig.10 The system shown in FIG.

[0152] The method 1850 begins at operation 1855 by deriving an MTN path signal rate based on a reference clock rate at a source node. The method 1850 continues at operation 1860 by deriving a client data stream rate for each of two or more 64B / 66B coded block streams of CBR client data relative to the reference clock rate, wherein for each of the two or more 64B / 66B coded block streams of CBR client data, a variable number of coded blocks of the CBR client data and a variable number of padding blocks are based on a difference between the MTN path signal rate and the corresponding client data stream rate.

[0153] Fig.19A The following is a diagram showing a method for implementing ... Fig.18B The method shown is an example method 1900 of performing rate adaptation.

[0154] The method 1900 begins at operation 1905 by transmitting a GMP multiplexed rate adaptation frame stream and a fixed number of idle blocks over the MTN. The method continues at operation 1910 by receiving the GMP multiplexed rate adaptation frame stream and the fixed number of idle blocks at a first intermediate node of the MTN.

[0155] At the first intermediate node, the method 1900 continues at operation 1915 by performing an idle mapping procedure (IMP) rate adaptation on the GMP multiplexed rate adaptation frame stream received at the first intermediate node to modify the fixed number of idle blocks. The method 1900 ends at operation 1920 by transmitting the GMP multiplexed rate adaptation frame stream with the modified fixed number of idle blocks from the first intermediate node to the next node of the MTN.

[0156] Fig.19B The following is a diagram showing a method for performing a multi-channel ... Fig.18B The method shown is a method for performing data extraction.

[0157] Fig.19B The method 1950 begins at operation 1955 by receiving a GMP multiplexed rate adaptation frame stream with a modified fixed number of idle blocks at a sink node. At operation 1960, the method 1950 continues by performing IMP to adapt the GMP multiplexed rate adaptation frame stream to a local reference clock at the sink node.

[0158] The method 1950 continues at operation 1965 by determining, for each interleaving thread, a corresponding client data flow rate based on the GMP OH and the difference between a fixed number of idle blocks inserted by the source node between consecutive pseudo Ethernet packets of the GMP multiplexed rate adapted frame stream and a modified fixed number of idle blocks received at the sink node. The method 1950 ends at operation 1970 by extracting two or more 64B / 66B coded blocks of CBR client data from the GMP multiplexed rate adapted thread frame stream using the corresponding client data flow rate of the interleaving thread.

[0159] The example systems and methods provide various benefits, including but not limited to: (1) using GMP within packets to enhance flexibility and compatibility with potential MTN equipment implementations; (2) binding CBR packet bearing structures to MTN POH frames so that the exact G.8312 nominal spacing of MTN overhead blocks can be used consistently; (3) enabling a source node to indicate the number of idle blocks it inserts after a packet, including the amount of remaining fractional idle blocks for improved IMP rate adaptation performance; (4) providing the ability to perform TDM client multiplexing within packets, where GMP is used for per-client rate adaptation; (5) not requiring new overhead to be added to MTN path layer signals; (6) improved bandwidth efficiency compared to using conventional Ethernet packets in Ethernet-based CBR service (CES) mode; and (7) carrying CBR client signals in packets that are much longer than Ethernet packets to improve efficiency in MTN networks that operate independently of packet length.

[0160] In various examples, parts of the system of the present invention examples may be implemented in a field programmable gate array (FPGA) or an application specific integrated circuit (ASIC). It will be appreciated by those skilled in the art that the various functions of the circuit elements may also be implemented as processing steps in a software program. Such software may be used, for example, in a digital signal processor, a network processor, a microcontroller, or a general purpose computer.

Claims

1. A method for performing rate adaptation, the method comprising: Receiving, at a source node, a stream of encoded blocks of CBR client data; Define multiple pseudo Ethernet packets; assembling a Generic Mapping Procedure (GMP) frame stream comprising a plurality of GMP frames by mapping a variable number of coded blocks, a variable number of padding blocks, and GMP overhead of the coded block stream of the CBR client data into consecutive pseudo Ethernet packets of the plurality of pseudo Ethernet packets; Inserting a fixed number of idle blocks into the GMP frame stream; as well as Inserting a metropolitan area transport network MTN path overhead POH frame aligned with the multiple GMP frames into the GMP frame stream to generate a CBR rate adaptation GMP frame stream.

2. The method of claim 1, wherein the coded block of CBR client data is a 64B / 66B coded block of CBR client data.

3. The method according to claim 1, wherein the fixed number of idle blocks inserted into the GMP frame stream is known by a sink node of the MTN.

4. The method of claim 1 , wherein each of the plurality of pseudo Ethernet packets comprises a packet start control block, a plurality of data payload blocks, and a packet termination control block, and wherein assembling the GMP frame stream comprises: The GMP overhead is mapped into the packet termination control block or the packet start control block of the consecutive pseudo Ethernet packets.

5. The method of claim 1 , wherein each of the plurality of pseudo Ethernet packets comprises a packet start control block, a plurality of data payload blocks, and a packet termination control block, wherein the number of consecutive pseudo Ethernet packets of each of the plurality of GMP frames is equal to three, and wherein assembling the GMP frame stream comprises: A portion of the GMP overhead is mapped into at least one of the packet termination control block or the packet start control block of each of the three consecutive pseudo Ethernet packets.

6. The method of claim 1 , wherein each of the plurality of pseudo Ethernet packets comprises a packet start control block, a plurality of data payload blocks, and a packet termination control block, and wherein assembling the GMP frame stream comprises: The variable number of blocks and the variable number of padding blocks of the encoded block stream of CBR client data are mapped into the plurality of data payload blocks of the consecutive pseudo Ethernet packets.

7. The method of claim 1, wherein assembling the GMP frame stream comprises: deriving an MTN path signal rate based on a reference clock at the source; deriving a CBR client data stream rate from a stream of coded blocks of said CBR client data; and wherein the variable number of blocks of the coded block stream of the CBR client data mapped into the consecutive pseudo Ethernet packets and the variable number of padding blocks mapped into the consecutive pseudo Ethernet packets are based on a difference between the MTN path signal rate and the CBR client data stream rate.

8. The method according to claim 1, comprising: Transmitting the CBR rate-adapted GMP frame stream, including the fixed number of idle blocks, through the MTN; Receiving the CBR rate adaptation GMP frame stream and the fixed number of idle blocks at an intermediate node of the MTN; performing an idle mapping procedure IMP rate adaptation on the CBR rate adaptation GMP frame stream received at the intermediate node to modify the number of idle blocks; as well as The CBR rate adapted GMP frame stream and the modified number of idle blocks are transmitted from the intermediate node to a next node of the MTN.

9. The method according to claim 8, wherein the next node of the MTN is selected from a next intermediate node and a sink node.

10. The method according to claim 8, wherein the next node of the MTN is a convergence node, the method comprising: receiving, at the sink node, the CBR rate-adapted GMP frame stream and a modified number of idle blocks; Performing idle mapping procedure IMP rate adaptation to adapt the CBR rate adaptation GMP frame stream to a local reference clock at the aggregation node; determining a CBR client data stream rate of the coded block stream of CBR client data based on the GMP overhead and a difference between the fixed number of idle blocks inserted into the CBR rate adapted GMP frame stream by the source node and a modified number of idle blocks received at the sink node; as well as A stream of encoded blocks of the CBR client data is extracted from the CBR rate adapted GMP frame stream using the determined CBR client data stream rate.

11. A method for performing rate adaptation, the method comprising: Receiving, at a source node, a stream of encoded blocks of CBR client data; Define multiple pseudo Ethernet packets; assembling a Generic Mapping Procedure (GMP) frame stream comprising a plurality of GMP frames by mapping a variable number of blocks of the coded block stream of the CBR client data, a variable number of padding blocks, and GMP overhead into consecutive pseudo Ethernet packets of the plurality of pseudo Ethernet packets; Inserting a fixed number of idle blocks into the GMP frame stream; Inserting an MTN path overhead POH frame aligned with the plurality of GMP frames into the GMP frame stream to generate a CBR rate-adapted GMP frame stream; transmitting the CBR rate-adapted GMP frame stream and the number of idle blocks through the MTN; Receiving the CBR rate adaptation GMP frame stream at an intermediate node of the MTN; performing idle mapping procedure IMP rate adaptation at the intermediate node to modify the number of idle blocks; transmitting the CBR rate-adapted GMP frame stream and the modified number of idle blocks from the intermediate node to a sink node of the MTN; receiving, at the sink node, the CBR rate-adapted GMP frame stream and a modified number of idle blocks; Performing idle mapping procedure IMP rate adaptation to adapt the CBR rate adaptation GMP frame stream to a local reference clock at the aggregation node; determining a CBR client data flow rate for the coded block stream of the CBR client data based on the GMP overhead and a difference between the fixed number of idle blocks inserted into the GMP frame stream by the source node and a modified number of idle blocks received at the sink node; as well as A stream of encoded blocks of the CBR client data is extracted from the CBR rate adapted GMP frame stream using the determined CBR client data stream rate.

12. A source node for transmitting a constant bit rate (CBR) client data stream via a metropolitan transport network (MTN), the source node comprising circuits for: Receives a stream of coded blocks of CBR client data; Define multiple pseudo Ethernet packets; assembling a Generic Mapping Procedure (GMP) frame stream comprising a plurality of GMP frames by mapping a variable number of blocks of the coded block stream of the CBR client data, a variable number of padding blocks, and GMP overhead into consecutive pseudo Ethernet packets of the plurality of pseudo Ethernet packets; Inserting a fixed number of idle blocks into the GMP frame stream; as well as Inserting the MTN path overhead POH frame aligned with the plurality of GMP frames into the GMP frame stream to generate a CBR rate-adapted GMP frame stream.

13. The source node of claim 12, wherein the circuitry of the source node is further configured to transmit the plurality of CBR rate adaptation GMP frames inserted by the source, the fixed number of idle blocks and the indication of the fixed number of idle blocks to one or more intermediate nodes or one or more aggregation nodes of the MTN.

14. The source node of claim 12, wherein the coded block of CBR client data is a 64B / 66B coded block of CBR client data.

15. The source node of claim 12, wherein the fixed number of idle blocks inserted into the GMP frame stream is known by a sink node of the MTN.

16. The source node of claim 12, wherein each of the plurality of pseudo-Ethernet packets comprises a packet start control block, a plurality of data payload blocks, and a packet termination control block, and the source node is used to assemble the GMP frame stream by mapping the variable number of blocks and the variable number of padding blocks of the encoded block stream of the CBR client data into the plurality of data payload blocks of the consecutive pseudo-Ethernet packets.

17. The source node according to claim 12, wherein each of the multiple pseudo-Ethernet packets includes a packet start control block, multiple data payload blocks and a packet termination control block, and the source node is used to assemble the GMP frame stream by mapping the GMP overhead into the packet termination control block or the packet start control block of the consecutive pseudo-Ethernet packets.

18. The source node of claim 12, wherein each of the plurality of pseudo-Ethernet packets comprises a packet start control block, a plurality of data payload blocks, and a packet termination control block, and wherein the number of consecutive pseudo-Ethernet packets of each of the plurality of GMP frames is equal to three, and the source node is used to assemble the GMP frame stream by mapping a portion of the GMP overhead into at least one of the packet termination control block or the packet start control block of each of the three consecutive pseudo-Ethernet packets.

19. The source node of claim 12, wherein the circuitry of the source node is to assemble the GMP frame stream: deriving an MTN path signal rate based on a reference clock at the source; deriving a CBR client data stream rate from a stream of coded blocks of said CBR client data; and wherein the variable number of blocks of the coded block stream of the CBR client data mapped into the consecutive pseudo Ethernet packets and the variable number of padding blocks mapped into the consecutive pseudo Ethernet packets are based on a difference between the MTN path signal rate and the CBR client data stream rate.

Images