LTE RLC ARQ Procedure

This week I was giving a workshop on LTE RLC overview, when someone asked me how the LTE RLC ARQ works and what are the differences from UMTS. It was a awesome discussion.

Though I was giving the workshop, but with that discussion I also became clear with many technical points.

Radio Link Protocol in LTE is much more simpler than the UMTS. Functions like ciphering are now moved out of RLC to PDCP. Also there are no more multiple variant of control PDUs. There is only one STATUS PDU which provides status of transmitted RLC PDUs.

If you like to learn more on RLC in 3G check this article.

Before we dive into ARQ (Automatic Repeat Request) mechanism in RLC, let’s take a quick overview on RLC architecture and particularly the RLC AM entity which the only mode where ARQ is supported. RLC TM and UM entities do not support and error correction and recovery.

RLC Architecture

For those who are new to LTE ratio interface, it is good to know where RLC is present. Here is a simple diagram which shows where RLC protocol resides in the stack and how it interacts with other layers.

LTE Radio Interface Protocol Stack

RLC is just in between PDCP and MAC and is controlled by RRC protocol. RRC provides configuration for all layers which terminates at the E-UTRAN (eNodeB).

In UMTS the radio protocols terminate in RNC, but these terminate in eNodeB for LTE. LTE now supports an intelligent eNodeB which combines the functions of UMTS’s NodeB and RNC.

Now that we know where RLC exists, let’s dive right into the architecture. Here is a simple diagram which shows RLC architecture and entities. As we see RLC can operate in there different modes: RLC TM (Transparent Mode), RLC UM (Unacknowledged Mode) and RLC AM (Acknowledged Mode).


RLC AM can perform the following functions.

  • Transfer of upper-layer PDUs
  • Error Correction through ARQ
  • Concatenation, segmentation, and reassembly of RLC SDUs
  • Resegmentation of RLC data PDUs
  • In-sequence delivery of upper-layer PDUs
  • Duplicate detection
  • Protocol error detection and recovery
  • RLC SDU discard
  • RLC re-establishment

For encoding and decoding of RLC PDUs check this post.

The ARQ mechanism of error detection and recovery only exists in RLC AM mode. Here is how RLC AM entity looks like.

RLC AM Mode Architecture

As this discussion is all about ARQ mechanism in LTE RLC, let’s now check the details on this mechanism.

LTE RLC ARQ Procedure

The ARQ procedure in LTE RLC is initiated when the transmitting side RLC entity starts the polling procedure. Polling procedure triggers STATUS reporting from receiving side AM RLC entity. At what condition transmiting side AM RLC entity starts polling procedure depends on the following conditions:

  • Number of AMD PDU >= pollPDU
  • Number of Byte of AMD PDU data >= pollByte
  • Both transmission and retransmission buffers become empty
  • No new RLC data PDU can be transmitted (e.g., due to window stalling)

When transmitting RLC AM entity initiates the polling procedure it sets the POLL (P) bit to 1 in the RLC header. I already explained in my earlier posts details about RLC Header structure and also provided a complete example. If you have missed that you can refer to this post.

Also it is good mention here that the two variables pollPDU and pollByte are configured by RRC which controls the RLC layer.

STATUS PDU Transmission

When a RLC PDU with polling bit set to 1 is received at the receiving end, the receiving RLC AM entity provides status information of all the previously received AMD PDUs which are not acknowledged. To perform this task receiving side RLC AM entity sends STATUS PDU with ACK andNACK information of RLC PDUs or PDU segments to peer entity.

Receiving side RLC entity transmit STATUS PDU when

  • Polling from peer entity is received
  • Detection of reception failure of RLC data PDU(t-Reordering timer expiration)

If t-StatusProhibit timer is running STATUS PDU can not be sent to lower layer. It can only be sent when the times expires. t-StatusProhibit is configures by RRC. After STATUS PDU is sent to lower layer this timer is restarted.

Retransmission of NACKed PDUs

When transmitting side RLC AM entity receives STATUS PDU with only ACK_SN it assumes that the receiving side RLC already received PDUs with sequence number < ACK_SN.

For example,if a STATUS PDU is received with ACK_SN = 6. This says that the receiving side already correctly received PDUs with sequence number 5. Those PDUs can now be removed from transmitting side retransmission buffer.

On the other hand if STATUS PDU contains NACK information, the receiving side RLC AM is saying that some PDUs are mission and those need to be retransmitted. In this case the transmitting side tries to resend those PDUs. Retransmission is continued until maximum retransmission threshold is reached. If a portion of AMD PDU segment to be retransmitted does not fit within total size of RLC PDU(s) at specific transmission opportunity, RLC can resegment AMD PDU segment portion If AMD PDU to be retransmitted does not fit within total size of RLC PDU(s) indicated by lower layer at specific transmission opportunity, RLC can segment the AMD PDU.

Let’s wrap this post with an example.

LTE RLC ARQ Procedure Example

LTE RLC ARQ Procedure

Hope this article will help you to understand LTE RLC ARQ mechanism. If you have any question fell free to ask in the comment section and I will try to answer those.


  1. in the 2nd step of the example diagram, how does the receiving side know to send the status pdu if it didnt receive sn 6 that contained the polling command.

  2. What is missed out in the diagram is the expiration of t-reordering timer for pdu-2

  3. What will happen if Rlc received StatusPDU while still trying to retransmit segments/messages from NackSns of previous StatusPDU?

Leave a Reply

Your email address will not be published. Required fields are marked *