Conclusiones y propuesta de modelo de estudio de autotraducciones

Transport of user traffic over GEM channels

(This appendix does not form an integral part of this Recommendation)

This appendix contains informative material concerning the transport of common user protocols using the GEM channel in G-PON.

It should be noted that there are several implementation options for the carriage of TDM services over GEM. The raw TDM data can be sent over GEM directly (clause I.2); or the TDM can be packaged into Ethernet, which is then sent over GEM (clause I.3); or the TDM can be packaged into SDH tributary units, which is then sent over GEM (clause I.4). The choice of option should be directed by the system architecture. For example, if the service stream is destined to be switched/routed across the wide area network, then Ethernet encapsulation is preferable. Alternatively, if the service stream will be terminated locally at the OLT equipment, then SDH encapsulation is preferable.

I.1 Mapping of GEM frames into the GTC payload

GEM traffic is carried over the GTC protocol in transparent fashion. In the downstream, GEM frames are transmitted from the OLT to the ONUs using the GTC frame payload section. The OLT may allocate as much duration as it needs in the downstream, up to and including nearly all of the downstream frame. The ONU framing sublayer filters the incoming frames based on Port-ID, and delivers the appropriate frames to the ONU GEM client.

In the upstream, frames are transmitted from the ONU to the OLT using the configured GEM allocation time. The ONU buffers GEM frames as they arrive, and then sends them in bursts when allocated time to do so by the OLT. The OLT receives the frames and multiplexes them with bursts from other ONUs, passing them all to the OLT GEM client.

I.2 TDM over GEM

This scheme utilizes variable-length GEM frames to encapsulate the TDM client. TDM data is packed into GEM as shown in Figure I.1. TDM data packets with the same Port-ID are concatenated in the upper layer over TC. The payload section will contain L bytes of the TDM

fragment.

Payload length indicator

PLI

12 bits Port ID12 bits 3 bitsPTI 13 bitsHEC

Fragment payload bytes L Payload type indicator

Figure I.1 – Frame structure for TDM data in GEM frame

TDM clients are mapped to the GEM frame by allowing the length of the GEM frame to vary according to the frequency offset of the TDM client. The length of the TDM fragment is indicated by the 'Payload-Length-Indicator' field.

The TDM source adaptation process should queue the incoming data in an ingress buffer and, once

per frame (i.e., each 125 µs), signal the GEM frame-multiplexing object the number of bytes that are

constant number of bytes according to the nominal TDM rate. From time to time, one more or less byte will need to be transported. This would be reflected in the content of the PLI field.

If the output frequency is faster than the incoming signal frequency, the ingress buffer will start to empty. The buffer fill will eventually fall below the lower threshold. As a result, one less byte would be read from the ingress buffer, and the buffer fill would rise above the lower threshold. Conversely, if the output frequency is slower than the incoming signal frequency, the buffer will start to fill up. The buffer fill will eventually rise above the upper threshold. As a result, one more byte would be read from the ingress buffer, and the buffer fill would decrease below the upper threshold.

Figure I.2 depicts the concepts of mapping variable length TDM fragments into the payload section of a GEM frame.

Figure I.2 – TDM mapping over GEM

I.3 Ethernet over GEM

The Ethernet frames are carried directly in the GEM frame payload. The preamble and SFD bytes are discarded prior to GEM encapsulation. Each Ethernet frame shall be mapped to a single GEM frame (as shown in Figure I.3) or multiple GEM frames, in which case the fragmentation rules of clause 8.3.3 apply. A GEM frame shall carry not more than one Ethernet frame.

PLI Port-ID PTI CRC GEM payload Preamble SFD DA SA Length/Type MAC client data

FCS 7 1 6 6 2 4 5 bytes

Ethernet packet GEM frame

EOF Inter packet gap 12

1

I.4 SDH over GEM

[ITU-T G.707] defines tributary unit (TU) structures. These structures contain user data as well as several mechanisms to preserve and recover data timing that is independent from the transport system timing. GEM can provide the same type of synchronous transport as SDH, so it is possible to carry TU structures over GEM. This clause lays out the details of this method.

I.4.1 Review of SDH TU structures

In SDH transmission structures, a TU includes a low level VC and a TU PTR. There are 4 types of TUs: TU-11, TU-12, TU-2, and TU-3. A TU-11 is used to carry a TDS1 service. A TU-12 is used to carry an E1 service. A TU-2 is used to carry a TDS2 service, and a TU-3 is used to carry a TDS3 or E3 service.

The TU-x structures are illustrated in Figures I.4 and I.5. Note that the bytes shown in the diagram are ordered starting at the upper left, going left to right, then on to the next line, and so forth.

Figure I.5 – The TU-3 frame structure

The structure and function of the pointers in the V1, V2, V3 and V4 bytes in the TU-11, TU-12 and TU2; and in the H1, H2 and H3 bytes in a TU-3 frame, continue to operate exactly as described in [ITU-T G.707].

I.4.2 Transport of TU structures over GEM

The structure about a TU frame mapped into a GEM frame is shown below:

Figure I.6 – GEM frame structure with TU frame data payload

Each TU connection is assigned its own GEM Port-ID. Each TU frame always has a fixed size. This size depends on the type of TU being carried. In addition, the GEM process receives a TU frame exactly once every transmission cycle. This cycle period is measured in the time-base of the G-PON system, which is a synchronous transport system with traceable timing. Hence, clock integrity can be maintained. It should be noted that GEM fragmentation is permitted; however, some implementations may attempt to coordinate the G-PON framing and SDH framing processes such that fragmentation is avoided.

The length and transmission period of TU-11/TU-12/TU-2/TU-3 capsulated in a GEM frame are shown below.

TU type Payload length in GEM _[bytes] Transmission cycle TU-11 4(3 × 9) = 108

TU-12 4(4 × 9) = 144 TU-2 4(12 × 9) = 432

500 μs

TU-3 86 × 9 = 774 125 μs

The payloads are assembled using the structures as shown in Figures I.4 to I.5.

The receiver side can identify the type of the carried TUs in two ways. Primarily, the Port-ID used would have a provisioned association with the TU that it is carrying. Secondarily, the length of the payload would give an additional check on the TU type, since the payload lengths are fixed for each TU type.

Note that while the GEM frame generation process is locked to the G-PON frame timing, there can still be delays in the frame transmission caused by low-level PON processes (e.g., ranging). For typical ranging procedures, two frames at a time are used for ranging. Therefore, the receiving process at the OLT must queue up sufficient TU data so that the client SDH processor can be served with its TU payloads synchronously.

I.5 IP over GEM

The IP packets are carried directly in the GEM frame payload. Each IP packet (or IP packet- fragment) shall be mapped to a single GEM frame (as shown in Figure I.7) or multiple GEM frames, in which case the fragmentation rules of clause 8.3.3 apply. A GEM frame shall carry not more than one IP packet (or IP packet-fragment).

PLI Port-ID PTI CRC Source Addr. Destination Addr. V GEM Payload Id CRC IP Payload TOS Length HL TTL Prot Frag.Off FL