5G/NR - RLC                                                                                        Home : www.sharetechnote.com









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


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 Model of two transparent mode peer entities >



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 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.




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 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.




RLC Data Structure



UMD Data Structure  


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


< 38.322-Table SI field interpretation >



AMD Data Structure  


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



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



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



< 38.322-Figure 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


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


< 38.322-Table 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 P field interpretation >







< 38.322-Figure STATUS PDU with 12 bit SN >



< 38.322-Figure STATUS PDU with 18 bit SN >