NR RLC is almost same as LTE RLC. So if you are already faimiliar with LTE RLC, you wouldn't need much of extra study to understand NR RLC. If you are new to overall functionality of RLC, I would suggest you to go through LTE RLC page first. Since I wouldn't see any NR test equipment and UE in near future, I wouldn't be able to put much of practical information on NR RLC until the equipment and UE are available. Your knowledge on LTE RLC would help you understand NR RLC.

Actually a large portions of the contents on this page comes from the direct copy of LTE RLC page and I would try to highlight those parts which is unique to NR RLC.

• Overview / Overall Functionality
• TM Mode / Procedure
• Example 1 : BCCH System Information Delivery
• Example 2 : PCCH Paging Delivery
• Example 3 : CCCH Initial Access Message
• UM Mode / Procedure
• Example 1 : Downlink DTCH SDU Without Segmentation
• Example 2 : Uplink DTCH SDU With Segmentation
• Example 3 : Segmented UM SDU With a Missing Segment
• AM Mode / Procedure
• Example 1 : Downlink DCCH SDU With Successful ACK
• Example 2 : Downlink AMD PDU Loss and RLC Retransmission
• Example 3 : Uplink DTCH SDU With Segmentation and ACK
• Example 4 : Segment Level NACK and Retransmission
• Example 5 : Polling and T-PollRetransmit
• Example 6 : Duplicate AMD PDU After Retransmission
• RLC Data Structure
• TMD Data Structure
• UMD Data Structure
• Example 1 : Complete UMD PDU Without SN
• Example 2 : First Segment With 6 Bit SN
• Example 3 : Middle Segment With 6 Bit SN and SO
• Example 4 : Last Segment With 12 Bit SN and SO
• AMD Data Structure
• Example 1 : AMD PDU With 12 Bit SN and Complete SDU
• Example 2 : AMD PDU With 12 Bit SN, First Segment and Poll
• Example 3 : AMD PDU With 12 Bit SN and SO
• Example 4 : AMD PDU With 18 Bit SN and Complete SDU
• Example 5 : AMD PDU With 18 Bit SN and SO
• STATUS PDU
• Example 1 : STATUS PDU With 12 Bit SN, ACK Only
• Example 2 : STATUS PDU With 12 Bit SN and One NACK
• Example 3 : STATUS PDU With Segment-Level NACK
• Example 4 : STATUS PDU With NACK Range
• Example 5 : STATUS PDU With 18 Bit SN and One NACK
• RRC Parameters defining RLC

Overview / Overall Functionality

As in LTE and WCDMA, NR RLC has three different mode : TM(Transparent Mode), UM(Unacknowledge Mode) and AM(Acknowledge mode). The details of each of these mode will be described later, but the very brief summary of key features of these mode is as follows :

• TM : No RLC Header, Buffering at Tx only, No Segmentation/Reassembly, No feedback (i.e, No ACK/NACK)
• UM : RLC Header, Buffering at both Tx and Rx, Segmentation/Reassembly, No feedback(i.e, No ACK/NACK)
• AM : RLC Header, Buffering at both Tx and Rx, Segmentation/Reassembly, Feedback(i.e, ACK/NACK)

Each of these mode can both transmit and receive data. In TM and UM, separate entity is used for transmission and reception, but in AM a single RLC entity perform both transmission and reception as illustrated below.

One important thing you need to pay attention to is that each of logical channels use a specific RLC mode as shown below.

• BCCH, PCCH, CCCH use RLC TM only.
• DCCH use RLC AM only.
• DTCH use RLC UM or AM. (Which mode is used for each DTCH channel ? This is determined by RRC message).

Now let's look into a little bit further details on how data is processed by each RLC Mode. Since each RLC mode is associated with a specific set logical channels, I would suggest you to associate this RLC mode procedure to RLC layer processing mechanism for each of those channels.

TM Mode / Procedure

As you see in the following illustration. TM mode would mean 'almost no processing to RLC data'. The only thing it does is to buffer data on Tx side. There is no RLC header, No reordering, no segmentation, no reassembly is happening in this layer. Because of this 'no data processing' nature of TM mode, if you compare the RLC input and RLC output data of TM mode, you would see no difference between the two.

One important thing to keep in mind is that you need to pay attention to MAC/PHY resource allocation. Even if MAC/PHY resource is allocated smaller than the RLC packet, the RLC wouldn't care. It would just forward whatever it has to MAC/PHY. So those RLC data bigger than MAC/PHY resource may be chopped off or discarded.

Again another this to be noticed is that the local channel BCCH / PCCH / CCCH data is processed by this RLC mode.

< 38.322 - Figure 4.2.1.1.1-1: Model of two transparent mode peer entities >

Example 1 : BCCH System Information Delivery

In this example, the gNB sends system information over BCCH. From RLC point of view, the upper layer already provides a complete BCCH message. RLC TM does not add any RLC header and does not split the message. It buffers the SDU on the transmit side and forwards the same byte sequence to MAC as a TMD PDU.

Step 1 : The RRC layer at the gNB creates a BCCH SDU. For RLC, this is just an upper layer packet to be delivered transparently.

Step 2 : RLC TM maps the BCCH SDU to one TMD PDU. Since TM has no RLC header, the TMD PDU data field is the BCCH SDU itself.

Step 3 : The TMD PDU is passed to MAC. If the lower layer resource is not suitable for the full payload, RLC TM does not perform segmentation to solve it.

Step 4 : On the UE side, RLC TM receives the TMD PDU from MAC. There is no RLC sequence number to check and no reordering operation.

Step 5 : RLC TM delivers the received payload to RRC as a BCCH SDU. Ideally, this SDU is identical to the SDU created at the gNB side.

Example 2 : PCCH Paging Delivery

In this example, the network sends a paging message over PCCH. Paging is a good example of why TM is simple: the network wants to broadcast a small control message at a paging occasion, and RLC does not need retransmission, polling or status reporting. If the UE misses the paging occasion, RLC TM itself does not recover it.

Step 1 : The network RRC layer generates a PCCH SDU containing the paging information.

Step 2 : RLC TM creates a TMD PDU that contains only the PCCH SDU. There is no RLC header, so there is no RLC sequence number for later retransmission or duplicate detection.

Step 3 : RLC forwards the TMD PDU to MAC. The paging occasion, PDCCH monitoring and physical transmission are controlled below RLC.

Step 4 : If the UE successfully receives the transmission, MAC passes the payload to RLC TM. RLC TM does not perform reassembly or reordering.

Step 5 : RLC TM delivers the PCCH SDU to RRC. If the paging was missed, RLC TM does not send a NACK or trigger retransmission.

Example 3 : CCCH Initial Access Message

In this example, the UE sends an initial RRC message over CCCH, such as an RRCSetupRequest on SRB0. The UE does not yet have a normal dedicated signaling bearer using RLC AM, so CCCH uses RLC TM. The RLC operation is still the same: one complete CCCH SDU is passed through as one TMD PDU.

Step 1 : The UE RRC layer creates a CCCH SDU, for example an RRCSetupRequest before dedicated signaling radio bearers are established.

Step 2 : RLC TM maps the CCCH SDU directly to a TMD PDU. There is no RLC SN, no segmentation information and no retransmission buffer.

Step 3 : The TMD PDU is passed to MAC for uplink transmission. The handling of uplink grant, transport block size and HARQ belongs to MAC/PHY, not RLC TM.

Step 4 : At the gNB, MAC passes the received payload to RLC TM. Since no RLC header exists, there is no header removal step.

Step 5 : RLC TM delivers the payload to RRC as the CCCH SDU. If this message is lost, recovery is handled by the access/RRC procedure, not by RLC retransmission.

UM Mode / Procedure

Next, let's look into UM mode. UM stands for 'Unacknowledged Mode'. 'Unacknowledged Mode' means 'it does not require any reception response from the other party'. 'Reception response' simply mean 'ACK' or 'NACK' from the other party. (UM mode is similar to TM mode in that it does not require any ACK/NACK from the other party, but it is different from TM in that I has it's own header)

What is the difference between UM mode and TM mode we saw above ? It seems that UM mode is doing more operation than TM mode.

What kind of operation UM mode do ? You can just 'read' diagram for the answer. The answer would be a little bit different with transmitter side and reciever side.

Let's read the operation on transmitting side first. If you just read (verbalize) the diagram

i) Buffering the data and generate RLC Header.

ii) Segmetation (Split a big chunk into a multiple small chunk) and Modify RLC Header (Some field in RLC header should be changed based on the segmentation status)

iii) Add RLC header

NOTE : If you compare this in LTE process, it seems that UM RLC does not perform any 'Concatenation'. According to following statement from 38.322 v0.1.0, the 'concatenation' process is moved to MAC layer.

From RAN2 NR#1:

-   Working assumption on no RLC concatenation taken at RAN2#96 is confirmed (i.e., concatenation of RLC PDUS is performed in MAC).

Then, read the operation on recieving side. If you just read (verbalize) the diagram

i) Buffering

ii) Reordering (Sometimes the chunks transmitted earlier from transmitter may arrive late at the reciever. In this case you have to reorder the incoming chunks into proper order for reassembly).

iii) Remove the RLC header (you would remember that the transmitter put the header to each of the chunk. So you have to remove this before you reassemble the data).

iv) Reassembly

< 38.322 - Figure 4.2.1.2.1-1: Model of two unacknowledged mode peer entities >

For those who already familiar with LTE RLC, I put the NR RLC UM and LTE RLC UM side by side for comparision. You see there is no difference in reciver side operation, but there is some difference in transmitter side. The most important difference in transmitter side is that NR RLC UM does not perform 'Concatenation' process.

Example 1 : Downlink DTCH SDU Without Segmentation

In this example, the gNB sends one DTCH SDU using UM mode and the SDU fits into the available lower layer resource. RLC UM still adds an RLC header, but it does not segment the SDU and it does not expect any RLC ACK/NACK from the UE.

Step 1 : The gNB PDCP layer sends one DTCH SDU to RLC UM. This may be used for a bearer where low latency is more important than RLC retransmission.

Step 2 : RLC UM creates one UMD PDU and adds the UM header. For a complete SDU, the header indicates that the PDU contains the whole SDU.

Step 3 : RLC passes the UMD PDU to MAC. Unlike AM, no copy is kept in an RLC retransmission buffer for possible RLC-level retransmission.

Step 4 : The UE receives the UMD PDU from MAC and removes the RLC UM header. Since there was no segmentation, no reassembly operation is needed.

Step 5 : RLC UM delivers the DTCH SDU to PDCP. There is no RLC ACK/NACK or STATUS PDU in this procedure.

Example 2 : Uplink DTCH SDU With Segmentation

In this example, the UE sends a DTCH SDU that is too large for one available uplink transmission. RLC UM segments the SDU into multiple UMD PDUs, adds the proper UM headers, and the gNB RLC UM entity reassembles the original SDU after receiving all segments.

Step 1 : The UE PDCP layer sends a DTCH SDU to RLC UM. The SDU is larger than what RLC can pass as one PDU for the current lower layer opportunity.

Step 2 : RLC UM creates the first segment. A segmented UMD PDU contains UM header information such as segmentation indication and sequence numbering.

Step 3 : RLC UM creates the next segment or segments. For segments after the first segment, offset information can be used so the receiver knows where that segment belongs in the original SDU.

Step 4 : The gNB RLC UM receiver gets the first segment and stores it in the receive buffer. It cannot deliver the SDU upward yet because the SDU is incomplete.

Step 5 : The gNB receives the remaining segment or segments. RLC UM uses the header fields to put the pieces in the correct order.

Step 6 : Once all required pieces are available, RLC removes the UM headers and reassembles the original DTCH SDU.

Step 7 : The reassembled SDU is delivered to PDCP. Even though segmentation and reassembly were used, no RLC ACK/NACK is generated.

Example 3 : Segmented UM SDU With a Missing Segment

In this example, the gNB sends a segmented DTCH SDU in UM mode, but one segment is not received by the UE. This shows the main limitation of UM mode: it can detect that reassembly is incomplete, but it does not request RLC retransmission from the peer entity.

Step 1 : The gNB PDCP layer submits a DTCH SDU to RLC UM, and the SDU needs to be split into multiple RLC PDUs.

Step 2 : RLC UM sends the first segment with a UM header that marks it as part of a segmented SDU.

Step 3 : RLC UM sends another segment, but at least one required segment is not received by the UE. MAC/PHY may perform HARQ below RLC, but RLC UM itself has no retransmission mechanism.

Step 4 : The UE receives one segment and stores it in the UM receive buffer. It cannot deliver the original SDU because all pieces are not available.

Step 5 : The receiver determines that reassembly cannot be completed, for example after the relevant reassembly handling expires or the missing part is no longer recoverable.

Step 6 : Since this is UM mode, the UE does not send an RLC STATUS PDU or NACK. The incomplete SDU is discarded or withheld from PDCP depending on the receiver state.

AM Mode / Procedure

Now let's look at AM mode which is the most complicated RLC type. 'AM' stands for 'Acknowledge Mode'. As it's name implies it requires ACK/NACK from the other party. It is more like TCP packet in IP world, whereas RLC UM is more like UDP in IP world.

Is it expecting the ACK/NACK for every transmission ? If it is the case, isn't it too much overhead ? Good question. Yes.. it is too much overhead. That's why we have RLC window concept (like TCP Window in IP traffic) and Polling bit concept and all sorts of ACK/NACK scheduling mechanism which makes it extremely difficult to understand full details of RLC AM operation. (This kind of detailed procedure would not be explained now.. but not sure by when I can get to the level of details -:)

Now just look into the diagram from the specification. If you go through the left column and the right colum, you will see the same procedures you saw in UM mode. so I don't want to verbalize that part again. What is different from UM mode lies in the middle column, namely 'Retransmission buffer' and 'RLC control' procedure.

Let's just follow the arrrows. What is coming into the retransmission buffer ? i.e, what is the input to the retransmission buffer ?

After RLC transmitter do the segmentation/concatenation process, it adds RLC header and then it creates two identical copies and transmit the one copy of the data out to lower layer (MAC) and send another copy to Retransmission buffer.

If the RLC get Nack or does not get any response from the other party for a certain period of time, the RLC packet (we call this RLC PDU) in the retransmission buffer gets transmitted again. If the RLC get ACK, the ones in retransmission buffer would be discarded.

< 38.322 - Figure 4.2.1.3.1-1: Model of an acknowledged mode entity >

For those who already familiar with LTE RLC, I put the NR RLC AM and LTE RLC AM side by side for comparision. You see there is no difference in reciver side operation, but there is some difference in transmitter side. The most important difference in transmitter side is that NR RLC AM does not perform 'Concatenation' process.

Example 1 : Downlink DCCH SDU With Successful ACK

In this example, the gNB sends one DCCH SDU using AM mode and the UE receives it successfully. The important difference from UM mode is that the transmitting AM entity keeps a copy in the retransmission buffer until it receives positive status information from the peer RLC entity.

Step 1 : The gNB receives one DCCH SDU from the upper layer. DCCH normally uses RLC AM because signaling usually needs reliable delivery.

Step 2 : RLC AM creates an AMD PDU and assigns sequence number 10. The SN is the basic reference used later by the receiver to acknowledge or negatively acknowledge the PDU.

Step 3 : The gNB keeps a copy of the AMD PDU in the retransmission buffer. This is the main AM behavior that does not exist in TM or UM.

Step 4 : The UE receives the AMD PDU from MAC, removes the RLC AM header and obtains the original SDU.

Step 5 : The UE RLC AM entity delivers the recovered DCCH SDU to PDCP.

Step 6 : The UE sends a STATUS PDU when status reporting is triggered, commonly by polling. ACK_SN = 11 means that all AMD PDUs up to but not including SN 11 are acknowledged, assuming no NACK field is present.

Step 7 : The gNB receives the status information and removes SN 10 from the retransmission buffer because it no longer needs to be protected by RLC retransmission.

Example 2 : Downlink AMD PDU Loss and RLC Retransmission

In this example, the gNB sends several AMD PDUs and one of them is not received by the UE. The receiver reports the missing sequence number in a STATUS PDU. The transmitter then retransmits the missing AMD PDU from its retransmission buffer.

Step 1 : The gNB sends SN 20 and keeps a copy for possible retransmission.

Step 2 : The gNB sends SN 21, but the UE RLC entity does not receive it. This is the kind of error AM is designed to repair at the RLC layer.

Step 3 : The gNB sends SN 22 with the P bit set. The P bit requests a STATUS PDU from the peer AM entity.

Step 4 : The UE receives SN 20 and SN 22. Since SN 21 is missing, the UE knows that the sequence is not continuous.

Step 5 : The UE sends a STATUS PDU containing NACK_SN = 21. Depending on exact status content, the STATUS PDU may also carry ACK_SN and extension fields.

Step 6 : The gNB uses the retransmission buffer to send SN 21 again. This retransmission is an RLC AM function, separate from MAC HARQ.

Step 7 : The UE receives the retransmitted SN 21 and fills the receive-side gap.

Step 8 : Once the missing PDU is available, the UE can deliver the corresponding SDUs upward in the proper order.

Example 3 : Uplink DTCH SDU With Segmentation and ACK

In this example, the UE sends a large DTCH SDU using AM mode. The SDU is segmented into multiple AMD PDUs. The gNB reassembles the SDU and later acknowledges reception, which allows the UE to remove the transmitted segments from its retransmission buffer.

Step 1 : The UE receives a large DTCH SDU from PDCP. Since it cannot be sent as one suitable RLC PDU, AM segmentation is needed.

Step 2 : RLC AM sends the first segment. The sequence number identifies the SDU being segmented, and the segment is kept in the retransmission buffer.

Step 3 : RLC AM sends the last segment. Segment information and offset information allow the receiver to reconstruct the original SDU.

Step 4 : The gNB receives the segments and buffers them because the complete SDU is reconstructed only after all needed pieces are available.

Step 5 : After all segments of SN 40 are present, the gNB reassembles the SDU and delivers it to PDCP.

Step 6 : The gNB sends status information acknowledging reception up to SN 41.

Step 7 : The UE receives the ACK information and removes all buffered copies associated with SN 40.

Example 4 : Segment Level NACK and Retransmission

In this example, a large AMD SDU is segmented and only part of the SDU is lost. AM mode can report not only a missing sequence number, but also a missing byte range within a segmented SDU by using segment offset information in the STATUS PDU.

Step 1 : The gNB sends the first segment of SDU SN 50. Since this is AM, the transmitted segment is also stored for possible retransmission.

Step 2 : The middle segment is transmitted but lost before the UE RLC entity receives it.

Step 3 : The last segment is received. The UE can see that it has the beginning and ending parts, but not the whole SDU.

Step 4 : The UE marks SN 50 as incomplete and identifies the missing byte range by using segment offset information.

Step 5 : The UE sends a STATUS PDU with NACK_SN = 50 and segment offset fields such as SOstart and SOend. This is more precise than simply asking for the whole SDU again.

Step 6 : The gNB retransmits only the missing part from the retransmission buffer.

Step 7 : The UE receives the missing segment, completes reassembly and delivers the recovered SDU upward.

Example 5 : Polling and T-PollRetransmit

In this example, the transmitter requests status by setting the poll bit, but no STATUS PDU is received before the poll retransmission timer expires. This shows why AM mode has polling control in addition to normal data transmission and retransmission.

Step 1 : The UE sends an AMD PDU with the P bit set. This asks the peer AM entity to provide status information.

Step 2 : The gNB receives the polled AMD PDU. A receiving AM entity does not necessarily send status after every data PDU, but a poll is a direct request for status reporting.

Step 3 : The STATUS PDU may be delayed or may not reach the UE. From the UE transmitter point of view, the poll has not been answered yet.

Step 4 : T-PollRetransmit expires at the UE. This prevents the transmitter from waiting forever for status information.

Step 5 : The UE sends another AMD PDU with the poll bit set. Depending on buffer state, this may be new data or a suitable PDU from the retransmission buffer.

Step 6 : The gNB sends STATUS information. The UE can then update its retransmission buffer and decide whether anything must be retransmitted.

Example 6 : Duplicate AMD PDU After Retransmission

In this example, a PDU is retransmitted because it was reported missing, but the original copy arrives late as well. AM mode uses sequence numbers and receiver state to avoid delivering the same SDU twice.

Step 1 : The gNB transmits SN 70, but the PDU is delayed or not available to the UE RLC entity when status is generated.

Step 2 : The UE reports SN 70 as missing in a STATUS PDU.

Step 3 : The gNB receives the NACK and retransmits SN 70 from the retransmission buffer.

Step 4 : The UE receives one copy of SN 70 and delivers the corresponding SDU upward if it is complete and in order.

Step 5 : The delayed original copy later reaches the UE. From RLC AM point of view, this is now a duplicate PDU.

Step 6 : The UE discards the duplicate and does not deliver the same SDU again. This is why AM needs sequence number based receiver state in addition to retransmission.

RLC Data Structure

RLC data structure describes how the payload from upper layer is carried over the RLC interface for each operating mode. In TM, the structure is almost transparent and there is no RLC header. In UM, the RLC header carries information needed for sequence handling, segmentation and reassembly, but it does not support RLC retransmission. In AM, the header and STATUS PDU structure become more complicated because AM has to support ordered delivery, polling, ACK/NACK reporting, retransmission and segment-level recovery.

TMD Data Structure

TMD stands for Transparent Mode Data. This is the simplest RLC PDU structure because the RLC entity does not add any RLC header to the upper layer payload. The TMD PDU is essentially the RLC SDU itself, so there is no sequence number, no segmentation information, no polling bit and no retransmission related field in this structure.

<  38.322-Figure 6.2.2.2-1: TMD PDU  >

UMD Data Structure  

There are various types of UMD PDU as illustrated below.

First type is the one shown below. The RLC header has only SI field and R field and has no SN field. 38.322-6.2.2.3 states "When an UMD PDU contains a complete RLC SDU, the UMD PDU header only contains the SI and R fields. An UMD PDU header contains the SN field only when the corresponding RLC SDU is segmented."

< 38.322-Figure 6.2.1.3-1: UMD PDU containing a complete RLC SDU >

Second type is the ones shown below. This type carries SN field. The length of SN field is 6 or 12 bits. Which one to be used is determined by RRC Configuration SN-FieldLengthUM.  This type does not carry SO (Segment Offset) field. 38.322-6.2.2.3 states "An UMD PDU carrying the first segment of an RLC SDU does not carry the SO field in its header."

< 38.322-Figure 6.2.2.3-2: UMD PDU with 6 bit SN (No SO) >

< 38.322-Figure 6.2.2.3-3: UMD PDU with 12 bit SN (No SO) >

Third type is the ones shown below. It carries SI,SN and SO.  The existence of SO indicates that this PDU carries a segment of an SDU and the segment is NOT the first segment. (If it is the first segment, SO field would not be carried).

< 38.322-Figure 6.2.2.3-4: UMD PDU with 6 bit SN and with SO >

< 38.322-Figure 6.2.2.3-5: UMD PDU with 12 bit SN and with SO >

SI : SI stands for Segment Information. The meaning of each possible SI field value is defined in the table below.

< 38.322-Table 6.2.2.4-1: SI field interpretation >

SO : SO stands for Segment Offset. It indicates the position of the RLC SDU segment within the original RLC SDU. The unit of SO is in Byte.

UMD Decoding Examples

The following examples show how to decode a UMD PDU from a raw hex string. In each example, the first bit field is read from the first bit of the first octet. The data field bytes are just example payload bytes and their internal upper layer meaning is not decoded by RLC.

Color code : SI, R, SN, SO, Data

Example 1 : Complete UMD PDU Without SN

Hex string : 00 C0 FF EE

Binary String : 00000000 11000000 11111111 11101110

In this example, the first octet is 00 in hex, or 00000000 in binary. The SI value is 00, so the receiver treats the following bytes as one complete SDU and delivers them upward without reassembly.

Example 2 : First Segment With 6 Bit SN

Hex string : 65 AA BB CC

Binary String : 01100101 10101010 10111011 11001100

The first octet 65 is 01100101 in binary. The first two bits 01 show that this is the first segment, and the remaining six bits 100101 give SN = 37.

Example 3 : Middle Segment With 6 Bit SN and SO

Hex string : E5 00 18 DD EE

Binary String : 11100101 00000000 00011000 11011101 11101110

The first octet E5 is 11100101 in binary. The SI value 11 tells the receiver that this is a middle segment, SN 37 identifies the segmented SDU, and SO 24 tells where this segment starts inside the original SDU.

Example 4 : Last Segment With 12 Bit SN and SO

Hex string : 83 45 00 40 11 22

Binary String : 10000011 01000101 00000000 01000000 00010001 00100010

The first two octets 83 45 are 10000011 01000101 in binary. SI is 10, which means last segment. The next two bits are reserved, and the following 12 bits form SN = 0x345. Since this is not the first segment, the 16 bit SO field is present and indicates byte offset 64.

AMD Data Structure  

RLC AM PDU structure is illustrated below. D/C, P, SI are common to every types of AM PDU. The main difference is the length of SN field and the existence of SO field.

Following type carries SN field but does not carry SO(Segment Offset) field. It mean that this PDU non-segmented SDU(a complete SDU) or the first segment of a segmented SDU.

The length of SN field can be 12 or 18 bits. Which one to use is determined by RRC parameter : SN-FieldLengthAM.

< 38.322-Figure 6.2.1.4-1: AMD PDU with 12 bit SN (No SO) >

< 38.322-Figure 6.2.1.4-2: AMD PDU with 18 bit SN (No SO) >

The second type of AMD PDU carries SO as illustrated below. It mean that this PDU carries a Non-First segment of a segmented SDU.  The length of SO field is always 16 bits.

< 38.322-Figure 6.2.1.4-3: AMD PDU with 12 bit SN with SO >

< 38.322-Figure 6.2.1.4-4: AMD PDU with 18 bit SN with SO >

SO : SO stands for Segment Offset. It indicates the position of the RLC SDU segment in bytes within the original RLC SDU

NOTE : 38.322-6.2.2.4 states 'An AMD PDU header contains a D/C, a P, a SI, and a SN. An AMD PDU header contains the SO field only when the Data field consists of an RLC SDU segment which is not the first segment, in which case a 16 bit SO is present'.

D/C : This field indicate whether the RLC PDU is for Data or Control.

< 38.322-Table 6.2.2.6-1: D/C field interpretation >

P : P stands for Polling bit. This indicates whether it requires RLC ACK or NACK from the other party.

< 38.322-Table 6.2.2.7-1: P field interpretation >

SI : SI stands for Segment Information. The meaning of each possible SI field value is defined in the table below.

< 38.322-Table 6.2.2.4-1: SI field interpretation >

AMD Decoding Examples

The following examples show how to decode AMD PDUs from raw hex strings. These examples focus on the RLC AM header fields and use simple payload bytes for the data field. The SN length is determined by RRC configuration, so the receiver must know whether the bearer is configured with 12 bit SN or 18 bit SN before decoding the header.

Color code : D/C, P, SI, R, SN, SO, Data

Example 1 : AMD PDU With 12 Bit SN and Complete SDU

Hex string : 81 23 DE AD BE EF

Binary String : 10000001 00100011 11011110 10101101 10111110 11101111

The first two octets 81 23 are 10000001 00100011 in binary. D/C = 1 indicates data, P = 0 means no polling, SI = 00 means complete SDU, and the following 12 bits form SN = 0x123.

Example 2 : AMD PDU With 12 Bit SN, First Segment and Poll

Hex string : D1 24 AA BB CC

Binary String : 11010001 00100100 10101010 10111011 11001100

The first two octets D1 24 are 11010001 00100100 in binary. D/C = 1 and P = 1 show that this is a polled data PDU, SI = 01 marks the first segment, and SN = 0x124 identifies the segmented SDU.

Example 3 : AMD PDU With 12 Bit SN and SO

Hex string : B1 24 00 20 44 55

Binary String : 10110001 00100100 00000000 00100000 01000100 01010101

The first two octets identify this as a 12 bit SN AMD PDU with SN = 0x124. Because SI = 11, the SO field is present and tells the receiver where this non-first segment belongs in the original SDU.

Example 4 : AMD PDU With 18 Bit SN and Complete SDU

Hex string : C2 34 56 99 88

Binary String : 11000010 00110100 01010110 10011001 10001000

The first three octets C2 34 56 are 11000010 00110100 01010110 in binary. After D/C, P, SI and reserved bits, the next 18 bits form SN = 0x23456.

Example 5 : AMD PDU With 18 Bit SN and SO

Hex string : A2 34 56 00 80 77 66

Binary String : 10100010 00110100 01010110 00000000 10000000 01110111 01100110

The first three octets decode the fixed AMD header for 18 bit SN. SI = 10 means last segment, so the 16 bit SO field is present after the SN field and indicates where this final segment begins inside the original SDU.

STATUS PDU  

Status PDU is used to carry various RLC control information like ACK sequence Number, NACK sequence number or the exact location of the NACK in the unit of Bytes etc.  The full stucture of Status PDU is as follows, but only D/C, CPT, ACK_SN field are always present and other fields may or may not present depending on situation. The receiving side of RLC can figure out whether thse additional fields (e.g, NACK SN, SO, NACK range etc) by checking the extention field (E1, E2, E3) which will be explained later.

< 38.322-Figure 6.2.2.5-1: STATUS PDU with 12 bit SN >

< 38.322-Figure 6.2.2.5-2: STATUS PDU with 18 bit SN >

E1, E2, E3    As mentioned above, E1, E2, E3 field indicates whether a specific optional field (i.e, NACK SN, SO, NACK range etc). The meaning of E1, E2, E3 is specified as follows in 3GPP. Simply put, E1 indicates the existance of NACK_SN field, E2 indicates the existence of SOstart,SOstop field and E3 indicates the existence of NACK range field.

< 38.322 - Table 6.2.3.11-1: E1 field interpretation >

< 38.322 - Table 6.2.3.13-1: E2 field interpretation >

< 38.322 - Table 6.2.3.16-1: E3 field interpretation >

NACK range : This field indicate the number of consecutive RLC SDUs are lost starting from the sequence number specified by NACK_SN.

STATUS PDU Decoding Examples

The following examples show how to decode STATUS PDUs from raw hex strings. In all examples, D/C = 0 indicates an RLC control PDU and CPT = 000 indicates STATUS PDU. The exact length of ACK_SN and NACK_SN depends on the AM SN length configured by RRC.

Color code : D/C, CPT, ACK_SN, E1/E2/E3, NACK_SN, SO, NACK range, R

Example 1 : STATUS PDU With 12 Bit SN, ACK Only

Hex string : 00 11 00

Binary String : 00000000 00010001 00000000

This is the simplest STATUS PDU example. The receiver is telling the transmitter that everything before ACK_SN 17 has been received and there is no missing SN to retransmit.

Example 2 : STATUS PDU With 12 Bit SN and One NACK

Hex string : 01 23 80 12 00

Binary String : 00000001 00100011 10000000 00010010 00000000

This STATUS PDU says that SN 288 is missing while the receiver state has progressed up to ACK_SN 291. The transmitter should retransmit SN 288 if it is still available in the retransmission buffer.

Example 3 : STATUS PDU With Segment-Level NACK

Hex string : 00 34 80 03 24 00 10 00 1F

Binary String : 00000000 00110100 10000000 00000011 00100100 00000000 00010000 00000000 00011111

This STATUS PDU does not ask for the whole SN 50 again. It requests retransmission of only the missing byte range from SOstart 16 to SOend 31.

Example 4 : STATUS PDU With NACK Range

Hex string : 02 05 80 20 02 03

Binary String : 00000010 00000101 10000000 00100000 00000010 00000011

This example compactly reports a burst loss. Instead of listing SN 512, SN 513 and SN 514 separately, the STATUS PDU uses one NACK_SN and a NACK range value of 3.

Example 5 : STATUS PDU With 18 Bit SN and One NACK

Hex string : 00 00 4A 00 04 00

Binary String : 00000000 00000000 01001010 00000000 00000100 00000000

This example is similar to the 12 bit single-NACK case, but the ACK_SN and NACK_SN fields are longer. The receiver must use the configured 18 bit AM SN length to parse the bit positions correctly.

RRC Parameters defining RLC

RLC behavior is not determined only by the RLC mode itself. The actual operation is configured by RRC through RLC-BearerConfig and the related RLC-Config parameters. These parameters decide which logical channel is served, whether the bearer uses TM, UM or AM, the uplink and downlink RLC entity configuration, sequence number length, timers, polling thresholds and retransmission related behavior. Because of this, when debugging RLC operation, it is important to read the RRC configuration first and then interpret the observed RLC PDUs based on that configuration.

RLC-BearerConfig ::=             SEQUENCE {

    logicalChannelIdentity         LogicalChannelIdentity,

    servedRadioBearer                CHOICE {

        srb-Identity                    SRB-Identity,

        drb-Identity                    DRB-Identity

    }       OPTIONAL,   -- Cond LCH-SetupOnly

    reestablishRLC                ENUMERATED {true}     OPTIONAL,   -- Need R

    rlc-Config                    RLC-Config            OPTIONAL,   -- Cond LCH-Setup

    mac-LogicalChannelConfig      LogicalChannelConfig   OPTIONAL,   -- Cond LCH-Setup

    ... 

}

RLC-Config ::=                      CHOICE {

    am                                  SEQUENCE {

        ul-AM-RLC                           UL-AM-RLC,

        dl-AM-RLC                           DL-AM-RLC

    },

    um-Bi-Directional                   SEQUENCE {

        ul-UM-RLC                           UL-UM-RLC,

        dl-UM-RLC                           DL-UM-RLC

    },

    um-Uni-Directional-UL               SEQUENCE {

        ul-UM-RLC                           UL-UM-RLC

    },

    um-Uni-Directional-DL               SEQUENCE {

        dl-UM-RLC                           DL-UM-RLC

    },

    ...

}

UL-AM-RLC ::=           SEQUENCE {

    sn-FieldLength          SN-FieldLengthAM        OPTIONAL,   -- Cond Reestab

    t-PollRetransmit        T-PollRetransmit,

    pollPDU                 PollPDU,

    pollByte                PollByte,

    maxRetxThreshold        ENUMERATED { t1, t2, t3, t4, t6, t8, t16, t32 }

}

DL-AM-RLC ::=           SEQUENCE {

    sn-FieldLength          SN-FieldLengthAM        OPTIONAL,   -- Cond Reestab

    t-Reassembly            T-Reassembly,

    t-StatusProhibit        T-StatusProhibit

}

UL-UM-RLC ::=           SEQUENCE {

    sn-FieldLength          SN-FieldLengthUM        OPTIONAL    -- Cond Reestab

}

DL-UM-RLC ::=           SEQUENCE {

    sn-FieldLength          SN-FieldLengthUM        OPTIONAL,   -- Cond Reestab

    t-Reassembly            T-Reassembly

}

SN-FieldLengthUM ::=    ENUMERATED {size6, size12}

SN-FieldLengthAM ::=    ENUMERATED {size12, size18}

T-PollRetransmit ::=    ENUMERATED {

                            ms5, ms10, ms15, ms20, ms25, ms30, ms35,

                            ms40, ms45, ms50, ms55, ms60, ms65, ms70,

                            ms75, ms80, ms85, ms90, ms95, ms100, ms105,

                            ms110, ms115, ms120, ms125, ms130, ms135,

                            ms140, ms145, ms150, ms155, ms160, ms165,

                            ms170, ms175, ms180, ms185, ms190, ms195,

                            ms200, ms205, ms210, ms215, ms220, ms225,

                            ms230, ms235, ms240, ms245, ms250, ms300,

                            ms350, ms400, ms450, ms500, ms800, ms1000,

                            ms2000, ms4000, spare5, spare4, spare3,

                            spare2, spare1}

PollPDU ::=             ENUMERATED {

                            p4, p8, p16, p32, p64, p128, p256, p512, p1024, p2048, p4096,

                            p6144, p8192, p12288, p16384, p20480, p24576, p28672, p32768,

                            p40960, p49152, p57344, p65536, infinity, spare8, spare7, spare6,

                            spare5, spare4, spare3, spare2, spare1}

PollByte ::=            ENUMERATED {

                            kB1, kB2, kB5, kB8, kB10, kB15, kB25, kB50, kB75,

                            kB100, kB125, kB250, kB375, kB500, kB750, kB1000,

                            kB1250, kB1500, kB2000, kB3000, kB4000, kB4500,

                            kB5000, kB5500, kB6000, kB6500, kB7000, kB7500,

                            mB8, mB9, mB10, mB11, mB12, mB13, mB14, mB15,

                            mB16, mB17, mB18, mB20, mB25, mB30, mB40, infinity,

                            spare20, spare19, spare18, spare17, spare16,

                            spare15, spare14, spare13, spare12, spare11,

                            spare10, spare9, spare8, spare7, spare6, spare5,

                            spare4, spare3, spare2, spare1}

T-Reassembly ::=        ENUMERATED {

                            ms0, ms5, ms10, ms15, ms20, ms25, ms30, ms35,

                            ms40, ms45, ms50, ms55, ms60, ms65, ms70,

                            ms75, ms80, ms85, ms90, ms95, ms100, ms110,

                            ms120, ms130, ms140, ms150, ms160, ms170,

                            ms180, ms190, ms200, spare1}

T-StatusProhibit ::=    ENUMERATED {

                            ms0, ms5, ms10, ms15, ms20, ms25, ms30, ms35,

                            ms40, ms45, ms50, ms55, ms60, ms65, ms70,

                            ms75, ms80, ms85, ms90, ms95, ms100, ms105,

                            ms110, ms115, ms120, ms125, ms130, ms135,

                            ms140, ms145, ms150, ms155, ms160, ms165,

                            ms170, ms175, ms180, ms185, ms190, ms195,

                            ms200, ms205, ms210, ms215, ms220, ms225,

                            ms230, ms235, ms240, ms245, ms250, ms300,

                            ms350, ms400, ms450, ms500, ms800, ms1000,

                            ms1200, ms1600, ms2000, ms2400, spare2, spare1}

Reference

[1]