You are on page 1of 37

8/1/2017 ShareTechnote

RLC Home : www.sharetechnote.com

Personally to me, RLC layer is one of the trickest area to understand in very detail. At the beginning it seems to be
simple, but as I getting deeper and deeper into this layer I get more and more confused. Another difficulties is that I
don't find any books or other training material explaining very detail on this area, whereas you would find a lot of
books and materials digging very deeplyinto other layer

Followings are topics that will be described in this page. Don't get scared of the long list. Overall
logic is simple. First, understand the details RLC PDU/SDU structure and go through a lot of
examples.

Overview
Interaction with Other Layers
Data Flow at the Transmitter
Data Flow at the Reciever
Overall Data Flow for TM RLC
Overall Data Flow for UM RLC
Summary of RLC UM Data Flow - Transmission
Summary of RLC UM Data Flow - Reception
Major RLC UM Parameters
Overall Data Flow for AM RLC
Summary of RLC AM Data Flow - Transmission
Summary of RLC AM Data Flow - Reception
Major Functions of RLC AM
RLC AM Parameters
Polling for RLC AM ARQ
Polling Parameter for LTE
Case 1 : Basic Poll Bit Handling
Case 2 : Poll bit and RLC ACK operates by sequence number
Case 3 : Retransmission due to t-PollRetransmit timeout
Case 4 : Retransmission due to RLC NACK
Case 5 : RLF(Radio Link Failure) due to Max Retransmission Failure
Polling Parameter for UMTS
Example 1 : in LTE - RLC Transmission from Network (IP Throughput)
Example 2 : in LTE - RLC Transmission from Network (LTE Registration)
Example 3 : in LTE - RLC Bidirectional (From LTE Attach to YouTube)
RLC Data Structure
TMD Structure
UMD Structure
How to Identify UMD PDU Type ?
AMD Structure
RLC Decoding Tips
Examples for RLC AMD PDU
Data PDU : 88 06
Data PDU : 98 07
Data PDU : B0 08
Data PDU : 8C 00 DD CD DC 5D...
Data PDU : 9C 01 D8 DD DC 5D...
Data PDU : 9C 02 D3 ED DC 5D...
Data PDU : 94 12 84 ED DC 5D...
Data PDU : BC 1B B6 4D DC 5D...
Data PDU : A0 00 ...

http://www.sharetechnote.com/html/RLC_LTE.html 1/37
8/1/2017 ShareTechnote

Data PDU : A0 01 ...


Control PDU : 00 04
Control PDU : 00 08
Control PDU : 00 78
Control PDU : 00 22 00 40 0C 01 C0 20
Examples for RLC UMD PDU
UMD PDU : 1C E1 ...
UMD PDU : 18 E2 ...
UMD PDU : 18 E3 ...
UMD PDU : 1C E4 ...
Examples from real life (Live Network)
Variables, constants and timers for RLC
Process of RLC UM Transmission
Process of RLC UM Reception
Process of RLC AM Transmission
Process of RLC AM Reception
Some issues for RLC layer verification

Overview

As far as I experienced, there are three main topics we have to master on this layer to make our knowledge practical
enough to the development or troubleshooting.
i) Understanding three types of RLC Mode : TM, UM, AM
ii) Segmentation (Splitting) and Concatenation (Combining) mechanism
iii) RLC Timers

I will not explain on these topics right now. It will be explained as you go along with this section.. but this part will be
updated forever as I get more and more insight on this layer.

As in the section for other layer, let's start by "Reading (Verbalizing)" the pictures from the specification. The first
diagram you will see in LTE RLC specification(TS 36.322) is as follows:

< 36.322 Figure 4.2.1-1: Overview model of the RLC sub layer >

http://www.sharetechnote.com/html/RLC_LTE.html 2/37
8/1/2017 ShareTechnote

What do you read from the diagram above ? First you will see the layers labeled 'upper layer' and 'lower layer' ? What
does these layer specifically mean ? 'Upper layer' in this case would mean 'RRC layer' or 'PDCP Layer' or in some case
(especially in the simulation or testing environment' it can be a TE port ( a kind of data Input/Output port).
Then, in which case the upper layer should be RRC Layer and in which case it should be PDCP or TE port ? These are
what you have to figure out as you go along this document.
And then.. you see another layer labelled 'lower layer'. What is the lower layer in this case ? It is simple. It means
'MAC' layer in most case.

There are another small issues that scared me.. it was the term 'entity' which sounded too abstract to me. (it may not
be the case for others). I just take the term 'entity' as a kind of 'thread' or 'task' in software terminology. It may not
be a perfect analogy but this terminology change made me much more comfortable when I am reading the specs.

What else you can read from the diagram above ?


One thing I notice is.. There are separate entity (thread or task) for Uplink and Downlink RLC for TM and UM. But in
AM, both Uplink and Downlink path are merged into a single entity. Why ? This is also what you have to figure out
later.

Another picture that I want you to keep in mind is shown below. Most of signaling message is using RLC and each of
the message is a specific types of RLC mode, TM/UM/AM. Unlike the channel mapping, the association between each
message and RLC type is not so tight meaning that network can allocate RLC types a little bit different from what is
shown below, but I would say the following mapping would be a kind of 'Textbook' mapping.

As we go through this section, you will see the detailed behavior of each RLC mode. If you try to associate this
diagram and the RLC description you will have more practical understanding of RLC and will help you greatly for
protocol stack implementation and troubleshooting.

Interaction with other Layers

RLC sits between PDCP and MAC layer. I would suggest you to understand how user data follow through these layers.
This data flow can be illustrated as below. The illustrations shown here are examples for a specific case (typical max
throughput condition). The illustration and comments would need to be changes if the test condition gets different.

For now, I am illustrating only one specific cases but you can draw varying illustrations depending on situation. I often
see people underestimate the importance of RLC operation and they think RLC is working in a very simple logic. But
this may hold trun only before you see some problem. Once you see the problems it would not be easy to
troubleshoot. In many case you would see lack of detailed information in both UE log nor in network log. My
recommendation for you is to draw this kind of illustrations for as many diverse case as possible and get clear
understandings for each case in your own words before you come across any issues.

http://www.sharetechnote.com/html/RLC_LTE.html 3/37
8/1/2017 ShareTechnote

< Data Flow at the Transmitter >

The transmitting flow can be summarized as illustrated below. In this illustration, a lot of details for each layers are
not mentioned. I focused only on data flow and how multiple IP packets get merged as it goes through lower layer.
More specifically, in this illustration I assume that very large amount of resources (just assume that maximum
possible resources) are allocated for MAC/PHY layer.

(A) A lot of IP packets are comining into PDCP layer from outside of eNB. (NOTE : You see multiple arrows
coming in parallel at this step, but this doesn't mean that the multiple packets are comining in simultaneously.
In reality, each of the arrows comes in one by one in sequence.)
(B) PDCP layer add PDCP header to each of incoming IP packet and send them out.
(C) A lot of PDCP packets are coming into RLC layer (NOTE : You see multiple arrows coming in parallel at this
step, but this doesn't mean that the multiple packets are comining in simultaneously. In reality, each of the
arrows comes in one by one in sequence.)
(D) RLC layer concatenate (combine) these multiple packets (SDU) into a single/huge packets and add a RLC
header containing the detailed information(e.g, Length Indicator) that is required to split it into original packets
at the reciever side. (The example DL AMD : 8C 00, DL AMD : 9C 02 are the RLC PDU of this type)
(E) The concatenated RLC packet (PDU) is forwarded to MAC layer once it gets the signal from the MAC layer.
The maximum data size of the RLC output is determined by MAC layer TBS(Transport Block Size)

NOTE : If MAC TBS size is assigned to be very small (smaller than the single IP packet), the IP packet gets segmented
(as opposed to being concatenated) and requires multiple times of RLC/MAC transmission to send out a whole IP
packet.

< Data Flow at the Reciever >

The Recieving flow can be summarized as illustrated below. In this illustration, a lot of details for each layers are not
mentioned. I focused only on data flow and how a big packets received at PHY/MAC get splitted into individual IP
packets as it goes through higher layer. More specifically, in this illustration I assume that very large amount of
resources (just assume that maximum possible resources) are allocated for MAC/PHY layer.
http://www.sharetechnote.com/html/RLC_LTE.html 4/37
8/1/2017 ShareTechnote

(A) MAC layer received a huge packet carrying many IP packets in it and forward it to RLC layer.
(B) RLC layer splits (segments) the huge packets into multiple SDUs based on the information carried by RLC
header. After this segmentation, RLC header is removed.
(C) Each of the RLC SDUs from RLC is forwarded to PDCP(NOTE : You see multiple arrows coming in parallel at
this step, but this doesn't mean that the multiple packets are forwarded simultaneously. In reality, each of the
arrows are forwarded one by one in sequence.)
(D) Each of the packets coming into PDCP is now stripped of PDCP header.
(E) Each of the packets stripped of PDCP header produces individual IP packets and forwarded up to IP layer.
(NOTE : You see multiple arrows coming in parallel at this step, but this doesn't mean that the multiple packets
are forwarded simultaneously. In reality, each of the arrows are forwarded one by one in sequence.)

Overall Data Flow for TM RLC

For this section as well, let's start reading diagram from the specification.

Let's begin with TM mode. As you see in the following diagram, TM is the simplest RLC mode. TM stands for
'Transparent Mode'. The term 'Transparent' may have many different meaning. In this case, it would mean 'the
contents goes through this layer without any modification'.
What does it mean by 'modification' ? In this context, it would mean
i) It does not add or remove any header to the input data
ii) It does not split the input data into multiple segment
iii) It does not combine the multiple input data into a single big chunk

The only operation operation being done in this mode is a buffering operation, but even this buffering operation is also
very simple. It just keeps the input data for a certain amount of time or until next input data come in, it just discard it
if it does not get transmitted within a certain time frame.

As you see in the diagram, BCCH, PCCH, CCCH goes through this type of RLC process. In WCDMA, Voice call traffic
used this RLC mode as well. It means that even some type of DTCH (voice traffic) uses this mode in WCDMA. However
http://www.sharetechnote.com/html/RLC_LTE.html 5/37
8/1/2017 ShareTechnote

it is technically possible to use TM mode for DTCH as well.

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

Overall Data Flow for UM RLC

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
ii) Segmetation (Split a big chunk into a multiple small chunk)
iii) Concatenation (Combine a multiple small chunk into a large single chunk)
iv) Add RLC header (If you combine or split something, you have to be able to re-split or re-combine them into
orignal chunk on the reciever side. For this, you have to put some tag(header) to those chunk)

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

As you see, DTCH, MTCH. MCCH use this type of RLC process. Again, this is also a matter of choice. You can use AM
or UM mode for DTCH.

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

http://www.sharetechnote.com/html/RLC_LTE.html 6/37
8/1/2017 ShareTechnote

< Summary of RLC UM Data Flow - Transmission >

i) Receive an Higher Layer Data (SDU) from PDCP or RRC


ii) Put the SDU into the transmission Buffer
iii) Segment or Concatenate the SDU into RLC PDU when MAC permit transmission
iv) Add a RLC header to the RLC PDU
v) Send the RLC PDU to the next layer (MAC)

< Summary of RLC UM Data Flow - Reception >

i) The MAC layer passes the received RLC PDU to the RLC layer.
ii) The RLC layer removes the RLC header from the PDU.
iii). The RLC layer assembles the PDUs into a upper layer SDU
iv). Pass the assembled SDUs to the PDCP or RRC layers.

< Major RLC UM Parameters >


+-rrcConnectionReconfiguration-r8 ::= SEQUENCE [001100]


+-radioResourceConfigDedicated ::= SEQUENCE [110101] OPTIONAL:Exist
| +-srb-ToAddModList ::= SEQUENCE OF SIZE(1..2) [1] OPTIONAL:Exist
| +-drb-ToAddModList ::= SEQUENCE OF SIZE(1..maxDRB[11]) [1] OPTIONAL:Exist
| | +-DRB-ToAddMod ::= SEQUENCE [11111]
| | +-eps-BearerIdentity ::= INTEGER (0..15) [5] OPTIONAL:Exist
| | +-drb-Identity ::= INTEGER (1..32) [1]
| | +-pdcp-Config ::= SEQUENCE [110] OPTIONAL:Exist
| | +-rlc-Config ::= CHOICE [um-Bi-Directional] OPTIONAL:Exist
| | | +-um-Bi-Directional ::= SEQUENCE
| | | +-ul-UM-RLC ::= SEQUENCE
| | | | +-sn-FieldLength ::= ENUMERATED [size5]
http://www.sharetechnote.com/html/RLC_LTE.html 7/37
8/1/2017 ShareTechnote

| | | +-dl-UM-RLC ::= SEQUENCE


| | | +-sn-FieldLength ::= ENUMERATED [size5]
| | | +-t-Reordering ::= ENUMERATED [ms0]

Information Element Description


sn-FieldLength This parameter indicates the length of Sequence Number field of RLC-UMD.
This timer is used by the receiving side of an UM RLC entity and receiving UM
t-Reordering
RLC entity in order to detect loss of RLC PDUs at lower layer. Unit = ms

Overall Data Flow for AM RLC

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.

< 36.322 Figure 4.2.1.3.1-1: Model of an acknowledged mode enttiy >

http://www.sharetechnote.com/html/RLC_LTE.html 8/37
8/1/2017 ShareTechnote

< Summary of RLC AM Data Flow - Transmission >

i) Receive an Higher Layer Data (SDU) from PDCP or RRC


ii) Put the SDU into the transmission Buffer
iii) Segment or Concatenate the SDU into RLC PDU when MAC permit transmission
iv) Add a RLC header to the RLC PDU
v) Make a copy of the transmission buffer for a possible retransmission
vi) Send the RLC PDU to the next layer (MAC)

< Summary of RLC AM Data Flow - Reception >

i) The MAC layer passes the received RLC PDU to the RLC layer.
ii) The RLC layer removes the RLC header from the PDU.
iii) If the received RLC PDU does not have any problem, mark it as positive ACK (but whether the ACK is sent
now or sometime later or omitted is determined by some other RLC parameters).
iv). The RLC layer assembles the PDUs into a upper layer SDU
v). Pass the assembled SDUs to the PDCP or RRC layers.

< Major Functions of RLC AM >

I think this list can give you another aspect of reading Figure 4.2.1.3.1-1 shown above. This is one way to learn new
things. Try to describe it from many different perspective. There will be many things overlapped by multiple
perspectives and there will be many things that looks different depending on the perspectives. It will help you to learn
http://www.sharetechnote.com/html/RLC_LTE.html 9/37
8/1/2017 ShareTechnote
perspectives and there will be many things that looks different depending on the perspectives. It will help you to learn
it in either ways. In some case, you will learn many things because they are similar and in other case you will learn
things because they are different.

Segmentation, concatenation, and reassembly: RLC service data units (SDUs) coming from the upper layer are
segmented or concatenated to RLC protocol data units (PDUs) which has a predefined size. Each PDU is
assigned its own sequence number (SN). RLC AM on reciever side will reassemble these PDUs into SDUs using
the sequence number. So allocating the proper Sequence Number is very important in RLC operation.
Error correction by ARQ: In AM RLC, if the sender does not receive ACK from the reciever it automatically send
the same data again and if the sender recieves the ACK in a predefined time frame it sends the next data. This
process is called ARQ. But if RLC is using this ARQ for every transmission, it would create a lot of overhead for
the data transmission. So in reality AM RLC is applying ARQ based on a special rules and this rule is defined by
various factors like some special timers, polling request etc. These factors will be explained below.
Flow control: By changing the window size, RLC can do a kind of flow control.

< Major RLC AM Parameters >



I think it will be helpful to look into some of high level RLC AM parameters (RRC parameters) and correlate these
parameters with RLC AM operation process.

+-rrcConnectionSetup-r8 ::= SEQUENCE [0]


+-radioResourceConfigDedicated ::= SEQUENCE [100101]
| +-srb-ToAddModList ::= SEQUENCE OF SIZE(1..2) [1] OPTIONAL:Exist
| | +-SRB-ToAddMod ::= SEQUENCE [11]
| | +-srb-Identity ::= INTEGER (1..2) [1]
| | +-rlc-Config ::= CHOICE [explicitValue] OPTIONAL:Exist
| | | +-explicitValue ::= CHOICE [am]
| | | +-am ::= SEQUENCE
| | | +-ul-AM-RLC ::= SEQUENCE
| | | | +-t-PollRetransmit ::= ENUMERATED [ms5]
| | | | +-pollPDU ::= ENUMERATED [p4]
| | | | +-pollByte ::= ENUMERATED [kB25]
| | | | +-maxRetxThreshold ::= ENUMERATED [t1]
| | | +-dl-AM-RLC ::= SEQUENCE
| | | +-t-Reordering ::= ENUMERATED [ms35]
| | | +-t-StatusProhibit ::= ENUMERATED [ms35]
| | +-logicalChannelConfig ::= CHOICE [defaultValue] OPTIONAL:Exist
| +-drb-ToAddModList ::= SEQUENCE OF OPTIONAL:Omit
| +-drb-ToReleaseList ::= SEQUENCE OF OPTIONAL:Omit
| +-mac-MainConfig ::= CHOICE [explicitValue] OPTIONAL:Exist
| +-sps-Config ::= SEQUENCE OPTIONAL:Omit
| +-physicalConfigDedicated ::= SEQUENCE [1111001011] OPTIONAL:Exist

Information Element Description


This timer is used by the transmitting side of an AM RLC entity in order to
t-PollRetransmit
retransmit a poll. Unit = ms
In most typical condition, the poll bit is inserted after the number transmitted
pollPDU
RLC PDU gets larger than this value. See 36.322 5.2.2.1
In most typical condition, the poll bit is inserted after the transmited RLC data is
pollByte
greater than (this value x 1000 bytes). See 36.322 5.2.2.1
maxRetxThreshold
This timer is used by the receiving side of an AM RLC entity and receiving AM
t-Reordering
RLC entity in order to detect loss of RLC PDUs at lower layer. Unit = ms
This timer is used by the receiving side of an AM RLC entity in order to prohibit
t-StatusProhibit
transmission of a STATUS PDU. Unit = ms

< Polling for RLC AM ARQ >

As I mentioned above, one of the most important feature for RLC AM is ARQ which is designed for reliable data traffic
and the key factors for RLC ARQ are various Polling mechanism.

This mechanism involves two main part as follows :

http://www.sharetechnote.com/html/RLC_LTE.html 10/37
8/1/2017 ShareTechnote

i) Transmitter side : Poll Request


ii) Receiver side : Status Report carrying ACK, NACK etc

Now the question is to figure out the best timing/situation for Poll Request and the best timing/situation for Satus
Report.

Polling Parameter for LTE :------------------------------------

+-rrcConnectionSetup-r8 ::= SEQUENCE [0]


+-radioResourceConfigDedicated ::= SEQUENCE [100101]
| +-srb-ToAddModList ::= SEQUENCE OF SIZE(1..2) [1] OPTIONAL:Exist
| | +-SRB-ToAddMod ::= SEQUENCE [11]
| | +-srb-Identity ::= INTEGER (1..2) [1]
| | +-rlc-Config ::= CHOICE [explicitValue] OPTIONAL:Exist
| | | +-explicitValue ::= CHOICE [am]
| | | +-am ::= SEQUENCE
| | | +-ul-AM-RLC ::= SEQUENCE
| | | | +-t-PollRetransmit ::= ENUMERATED [ms5]
| | | | +-pollPDU ::= ENUMERATED [p4]
| | | | +-pollByte ::= ENUMERATED [kB25]
| | | | +-maxRetxThreshold ::= ENUMERATED [t1]
| | | +-dl-AM-RLC ::= SEQUENCE
| | | +-t-Reordering ::= ENUMERATED [ms35]
| | | +-t-StatusProhibit ::= ENUMERATED [ms35]
| | +-logicalChannelConfig ::= CHOICE [defaultValue] OPTIONAL:Exist

Information Element Description


This timer is used by the transmitting side of an AM RLC entity in order to
t-PollRetransmit
retransmit a poll. Unit = ms
In most typical condition, the poll bit is inserted after the number transmitted
pollPDU
RLC PDU gets larger than this value. See 36.322 5.2.2.1
In most typical condition, the poll bit is inserted after the transmited RLC data is
pollByte
greater than (this value x 1000 bytes). See 36.322 5.2.2.1

I think some typical example operation would help you understand these parameters and Poll bit operation more
intuitively.

Case 1 : Basic Poll Bit Handling

Case 2 : Poll bit and RLC ACK operates by sequence number

http://www.sharetechnote.com/html/RLC_LTE.html 11/37
8/1/2017 ShareTechnote

Case 3 : Retransmission due to t-PollRetransmit timeout

Case 4 : Retransmission due to RLC NACK

Case 5 : RLF(Radio Link Failure) due to Max Retransmission Failure

http://www.sharetechnote.com/html/RLC_LTE.html 12/37
8/1/2017 ShareTechnote

Polling Parameter for UMTS:------------------------------------

Following is the list of several important factors to trigger for Poll Request and Satus Report. Following table is based
on UMTS RLC AM operation and this triggering mechanism seems to get simpler in LTE. However I would list up more
complicated case (UMTS case) togive you more detailed picture.

Trigger for Poll Description


Timer-based polling This configure the sender to transmit Poll periodically (once in a predefined time
(timerPollPeriodic) period)
This is the maximum waiting time for Status Report from the other party after it
Poll timer (timerPoll) sent a Poll. If Status Report does not arrive until this timer expires after the
transmission of a polling request, the sender send Polling Request again.
Last PDU in buffer If this is configured, the poll should be sent with the last PDU in the RLC
(lastTransmissionPDU-Poll) senders transmission buffer
Last PDU in retransmission buffer If this is configured, the poll should be sent with the last PDU in the RLC
(lastRetransmissionPDU-Poll) senders retransmission buffer
Poll every N PDU (poll-PDU) This triggers the poll for every N PDU sent
Poll every N SDU (poll-SDU) This triggers the poll for every N SDU sent
This sets the polling bit when a certain percentage of the transmission window is
Window-based polling
sent

Trigger for Status Report Description


The RLC reciever should send Status Report whenever it recieves AMD PDU with
Polling bit
Poll bit = 1 except when it is within timerStatusProhibit
If this flag is set to be TRUE, RLC reciever should send Status Report whenever
Missing PDU indicator
it finds any missing RLC sequence number except when it is within
(missingPDU-Indicator)
timerStatusProhibit.
timer-based STATUS transfer If this parameter is configured, RLC sender send Status Report with a predefined
(timerStatusPeriodic) interval except when it is within timerStatusProhibit
This is trigger from MAC layer (not from RLC) which let RLC to send Status
MAC-hs reset
Report whenver MAC-hs resets. This is not influenced by timerStatusProhibit.

http://www.sharetechnote.com/html/RLC_LTE.html 13/37
8/1/2017 ShareTechnote

Example 1 : in LTE - RLC Transmission from Network (IP throughput)

PollPDU = p128
PollByte = kB125
maxRetxThreshold = t32
t-PollRetransmit=ms35
t-Reordering=30ms
t-StatusProhibit = 30ms

SN
Time (mm.ss.ms) Direction AMD PDU # of PDUs Avg Size (Bytes) Poll Bit
(Dec)
00.21.324-00.21.338 DL Data 27 4586 0
00.21.338 DL Data 1 4586 1
00.21.339-00.21.348 DL Data 17 4586 0
00.21.349 UL Status(ACK) 30 1 2 N/A
00.21.349-00.21.353 DL Data 9 4586 0
00.21.353 DL Data 1 4586 1
00.21.354-00.21.368 DL Data 27 4586 0
00.21.368 DL Data 1 4586 1
00.21.369-00.21.381 DL Data 27 4586 0
00.21.382 UL Status(ACK) 90 1 2 N/A
00.21.382 DL Data 1 4586 0
00.21.382 DL Data 1 4586 1
00.21.383-00.21.397 DL Data 27 4586 0
00.21.397 DL Data 1 4586 1
00.21.398-00.21.412 DL Data 27 4586 0
00.21.412 DL Data 1 4586 1
00.21.413-00.21.415 DL Data 4 4586 0
00.21.415 UL Status(ACK) 153 1 2 N/A
00.21.415-00.21.426 DL Data 23 4586 0
00.21.426 DL Data 1 4586 1
00.21.426-00.21.441 DL Data 27 4586 0
00.21.441 DL Data 1 4586 1
00.21.443-00.21.446 DL Data 8 4586 0
00.21.448 UL Status(ACK) 216 1 2 N/A

Example 2 : in LTE - RLC Transmission from Network (LTE Registration)

Based on Table 4.6.3-19C: RLC-Config-SRB-AM-RECONFIG of 36.508

PollPDU = pInfinity (3GPP Default)


PollByte = kBInfinity (3GPP Default)
maxRetxThreshold = 3GPP Default
t-PollRetransmit=ms50
t-Reordering=t6
t-StatusProhibit = t0 (3GPP Default)

Time Avg Size


Direction AMD PDU SN (Dec) # of PDUs Poll Bit Header
(mm.ss.ms) (Bytes)
00.13.297 DL DATA 0 1 46 1 A0 00
00.13.304 UL Status(ACK) 1 1 2 N/A 00 04
00.13.416 DL DATA 1 1 26 1 A0 01
00.13.423 UL Status(ACK) 2 1 2 N/A 00 08
00.13.461 DL DATA 2 1 10 1 A0 02
00.13.468 UL Status(ACK) 3 1 2 N/A 00 0C
00.13.522 DL DATA 3 1 19 1 A0 03
http://www.sharetechnote.com/html/RLC_LTE.html 14/37
8/1/2017 ShareTechnote
00.13.522 DL DATA 3 1 19 1 A0 03
00.13.529 UL Status(ACK) 4 1 2 N/A 00 10
00.13.587 DL DATA 4 1 19 1 A0 04
00.13.594 UL Status(ACK) 5 1 2 N/A 00 14
00.13.617 DL DATA 5 1 10 1 A0 05
00.13.624 UL Status(ACK) 6 1 2 N/A 00 18
00.13.883 DL DATA 6 1 62 0 88 06
00.13.884 DL DATA 7 1 62 0 98 07
00.13.885 DL DATA 8 1 21 1 B0 08
00.13.892 UL Status(ACK) 9 1 2 N/A 00 18

Just for your reference, I put WCDMA RLC parameters in Radio Bearer Setup message as follows.

+-SRB-InformationSetup-r7 ::= SEQUENCE [1]


| +-rb-Identity ::= INTEGER (1..32) [2] OPTIONAL:Exist
| +-rlc-InfoChoice ::= CHOICE [rlc-Info]
| | +-rlc-Info ::= SEQUENCE [1100]
| | +-ul-RLC-Mode ::= CHOICE [ul-AM-RLC-Mode] OPTIONAL:Exist
| | | +-ul-AM-RLC-Mode ::= SEQUENCE [1]
| | | +-transmissionRLC-Discard ::= CHOICE [noDiscard]
| | | | +-noDiscard ::= ENUMERATED [dat10]
| | | +-transmissionWindowSize ::= ENUMERATED [tw128]
| | | +-timerRST ::= ENUMERATED [tr550]
| | | +-max-RST ::= ENUMERATED [rst1]
| | | +-pollingInfo ::= SEQUENCE [010110] OPTIONAL:Exist
| | | +-timerPollProhibit ::= ENUMERATED OPTIONAL:Omit
| | | +-timerPoll ::= ENUMERATED [tp500] OPTIONAL:Exist
| | | +-poll-PDU ::= ENUMERATED OPTIONAL:Omit
| | | +-poll-SDU ::= ENUMERATED [sdu1] OPTIONAL:Exist
| | | +-lastTransmissionPDU-Poll ::= BOOLEAN [TRUE]
| | | +-lastRetransmissionPDU-Poll ::= BOOLEAN [TRUE]
| | | +-pollWindow ::= ENUMERATED [pw50] OPTIONAL:Exist
| | | +-timerPollPeriodic ::= ENUMERATED OPTIONAL:Omit
| | +-dl-RLC-Mode ::= CHOICE [dl-AM-RLC-Mode] OPTIONAL:Exist
| | | +-dl-AM-RLC-Mode ::= SEQUENCE
| | | +-dl-RLC-PDU-size ::= CHOICE [fixedSize]
| | | +-inSequenceDelivery ::= BOOLEAN [TRUE]
| | | +-receivingWindowSize ::= ENUMERATED [rw128]
| | | +-dl-RLC-StatusInfo ::= SEQUENCE [100]
| | | +-timerStatusProhibit ::= ENUMERATED [tsp120] OPTIONAL:Exist
| | | +-dummy ::= ENUMERATED OPTIONAL:Omit
| | | +-missingPDU-Indicator ::= BOOLEAN [TRUE]
| | | +-timerStatusPeriodic ::= ENUMERATED OPTIONAL:Omit

Example 3 : in LTE - RLC Bidirectional (From LTE Attach to YouTube)

This example would the case that you might see most often in real life communication. This example shows all the
RLC traffic both downlink and uplink from power on a UE to the start of YouTube download. This log is captured by
Amarisoft OTS 100. Following is the RLC configuration for SRB, DRB set in RRC Connection Setup and RRC Connection
Reconfiguration message. I put the decoded RLC headers shown on Amarisoft Web based log viewer, followed by
corresponding Hex string. It will be a good practice if you pull out paper and pencil, deocde each hex string by hands
and compare it with the decoded result shown on the log viewer.

srb-ToAddModList {
{
srb-Identity 1,
rlc-Config defaultValue: NULL,
logicalChannelConfig defaultValue: NULL
}
},
srb-ToAddModList {
{
http://www.sharetechnote.com/html/RLC_LTE.html 15/37
8/1/2017 ShareTechnote
{
srb-Identity 2,
rlc-Config defaultValue: NULL,
logicalChannelConfig defaultValue: NULL
}
},
drb-ToAddModList {
{
eps-BearerIdentity 5,
drb-Identity 1,
pdcp-Config {
discardTimer infinity,
rlc-AM {
statusReportRequired TRUE
},
headerCompression notUsed: NULL
},
rlc-Config am: {
ul-AM-RLC {
t-PollRetransmit ms80,
pollPDU p64,
pollByte kB125,
maxRetxThreshold t4
},
dl-AM-RLC {
t-Reordering ms80,
t-StatusProhibit ms60
}
},
logicalChannelIdentity 3,
logicalChannelConfig {
ul-SpecificParameters {
priority 13,
prioritisedBitRate infinity,
bucketSizeDuration ms100,
logicalChannelGroup 3
}
}
}
},

Following is the screencapture of RLC traffic shown on Amarisoft Web Interface logging tool. (I removed a couple of
columns between ENB and Info to make it fit to this page)

http://www.sharetechnote.com/html/RLC_LTE.html 16/37
8/1/2017 ShareTechnote

http://www.sharetechnote.com/html/RLC_LTE.html 17/37
8/1/2017 ShareTechnote

Following is the Hex string of each RLC traffic (PDU) shown above. Try decode these PDU on your own and compare it
with the decoded result shown above if you want to get the detailed understanding of RLC PDU structure.

No RLC PDU
88 00 00 20 30 00 80 23 80 84 17 3a a0 26 49 05
1
07 41 02 0b f6 00 f1 10 00 80 23 c1 00 45 67 05
b0 01 00 26 02 01 d0 11 27 20 80 80 21 10 01 00
2
00 10 81 06 00 00 00 00 83 06 00 00 00 00 00 0d
3 00 08
4 88 00 00 08 00 18 3a a8 08 00
5 b0 01 00 00 00
6 00 08
a0 02 01 48 02 22 f6 54 b6 b1 c0 c0 ea c1 01 22
7
02 02 06 4a 8e d3 00 00 00 00 00
8 00 0c
a0 02 01 08 01 20 3a 90 05 b2 a3 b1 d4 2e 09 ff
9
e6 81 f3 71 fb 65 17 73 50 80 4e 0c a2 cc 5b cc
10 00 0c
a0 03 02 48 03 22 f4 2e 33 18 a0 e0 ea 62 16 c8
11
aa 81 38 32 8b 31 6b 14 f8 90 94 0f e0 12 a0 00
12 00 10
a0 03 02 08 00 89 bb ea 00 ec b8 00 3a e8 08 00
13
2f 83 86 02 03 86 08 00 00 00 00
14 00 10
a0 04 03 48 02 68 f3 8b f7 73 a0 00 eb c4 61 26
15
72 a0 20 a0 c0 04 80 5e a0 00 00 00 00
16 00 14
17 a0 04 03 30 00 10 84 90 80 b1

http://www.sharetechnote.com/html/RLC_LTE.html 18/37
8/1/2017 ShareTechnote

18 00 14
19 a0 05 04 28 00 06 04 bf 29
20 00 18
21 a0 05 04 38 00 00 3e a3 1a bb
22 00 18
88 06 05 38 01 08 09 dc 99 80 05 0c 20 b0 c0 41
23
05 8b a8 ff f1 7f 1f fe 2b a3 ff c5 fc 7f f8 ab
b0 07 fc 7f f8 bf 8f ff 17 f1 ff e2 fe 3f fc 5f
24
c7 ff 00 26 00 00 c8 37 f8 00 00 00 1f f0 00 00
25 00 20
a0 06 05 20 06 02 a1 3f 39 fd 02 80 08 3a 10 17
26
00 30 00 07 88 80 00 08 01 22 90 0e 08 08 48 40
27 00 1c
28 a0 08 06 10 00 d3 10 a9 14
29 00 24
a0 00 00 48 01 a4 e4 cc 6c a2 20 20 e8 60 00 6a
30
40 18 40 50 32 70 40
31 00 04
a0 07 06 08 01 91 3c b9 1a 8f 30 10 3b 0a 18 84
32
0e 0b b2 c4 f4 f5 fe 6b a4 85 9a 65 fd ff 2b 5a
33 00 20
a0 00 80 00 45 00 00 45 2a a0 40 00 40 11 3d 4e
34
c0 a8 02 02 08 08 08 08 1e 02 00 35 00 31 00 d2
35 00 04
a0 00 80 00 45 00 01 0a 88 5d 00 00 36 11 28 cc
36
08 08 08 08 c0 a8 02 02 00 35 1e 02 00 f6 7b da
37 00 04
a0 01 80 01 45 00 00 3c 61 ac 40 00 40 06 bb 29
38
c0 a8 02 02 36 e6 24 56 9f a2 00 50 90 2d f7 5e
39 00 08
a0 01 80 01 45 00 00 3c 00 00 40 00 35 06 27 d6
40
36 e6 24 56 c0 a8 02 02 00 50 9f a2 66 b7 2f 53
41 00 08
8c 02 03 60 80 02 45 00 00 34 61 ad 40 00 40 06
42
bb 30 c0 a8 02 02 36 e6 24 56 9f a2 00 50 90 2d
b0 03 74 72 61 32 2e 62 69 6e 20 48 54 54 50 2f
43
31 2e 31 0d 0a 41 63 63 65 70 74 3a 20 2a 2f 2a
44 00 10
a0 02 80 02 45 00 00 34 f2 c8 40 00 35 06 35 15
45
36 e6 24 56 c0 a8 02 02 00 50 9f a2 66 b7 2f 54
8c 03 5a 20 80 03 45 00 05 a0 f2 ca 40 00 35 06
46
2f a7 36 e6 24 56 c0 a8 02 02 00 50 9f a2 66 b7

RLC Data Structure

Like any data structure, you would not completely understand this structure until you really construct this structure or
analyze the structure with real data either in programming or in manually. Of course my recommendation is to
analyze manually.. I will put some of real RLC data example later, but for now let's just review the diagram from 3GPP
specification and just try to be familiar with them.

< TMD Structure >

The first structure is as follows. It is data structure for TMD (TM mode data) structure. What kind of structure you see
from the following diagram ?

< 36.322 Figure 6.2.1.2-1: TMD PDU >

http://www.sharetechnote.com/html/RLC_LTE.html 19/37
8/1/2017 ShareTechnote

It is Data only structure, not even with Header. Most of the data structure for any data communication has it's own
header. IP packet has IP header. UDP packet has UDP header. TCP header has TCP header. ICMP packet has ICMP
header, etc. But this packet does not have any header. As you know, the most important role of header is to carry the
information as follows :
i) Who is the sender ? (sender address, sender id etc)
ii) Who is the reciepient (reciepient address, id etc)
iii) What is the size of the data ?
iv) etc..

But this data structure has none of these information. It means that the TMD packet does not add any additional
(header) to the input data and does not split or combine the data coming into the RLC entity.
Then how the size of this TMD PDU is determined ? It is automatically set to be the same size as MAC PDU size.
What if the incoming data is bigger than the RLC PDU size ? It just take the initial part of data that can fit into its size
and discard the rest of the data.
What if the incoming data is smaller than the RLC PDU size ? It just take the whole data and pass it to MAC layer and
MAC layer add padding data at the end.

< UMD Structure >

Following is a data structure for UMD (UM mode data) structure. What are the meaning of Fl, E, SN ? You should refer
to other sets of diagrams later. If you remember the diagram in previous section (Fig 4.2.1.2.1-1), RLC UM entity has
capability of segmentation/concatenation. It means ... if the incoming data is greater than the RLC size, it segment
the data into multiple chunks and passthem one by one. In this case, you have to put some tag (number) to each of
the chunks.. otherwise the receiving side cannot combine them in proper sequence. This tag (number) is SN
(Sequence Number). As you see in the following diagram, there are two different types of SN. One is 5 bits and the
other one is 10 bits.

< 36.322 Figure 6.2.1.3-1: UMD PDU with 5 bit SN (No LI) >

< 36.322 Figure 6.2.1.3-2: UMD PDU with 10 bit SN (No LI) >

What if the a lot of small sized data packets are coming into the RLC entity ? The simplest way is to pack the small
chunk as it is (as in TM mode), but it is waste of space.

http://www.sharetechnote.com/html/RLC_LTE.html 20/37
8/1/2017 ShareTechnote

Then what do we have to do in this case ? The simplest way is to put the multiple small chunk into a single RLC
packet. In this case, you need special information for each of the small chunk within the RLC packet, except for the
last one. LI (Length Indicator) is the length value for each of the small chunks within a RLC PDU, except for the last.
For example, if you have 5 chunks in a single RLC packet, you would have four E fields and 4 LI fields since you don't
need E and LI field for the last one (5th one in this case)

< 36.322 Figure 6.2.1.3-3: UMD PDU with 5 bit SN (Odd number of LIs, i.e. K = 1, 3, 5, ) >

< 36.322 Figure 6.2.1.3-4: UMD PDU with 5 bit SN (Even number of LIs, i.e. K = 2, 4, 6, ) >

< 36.322 Figure 6.2.1.3-5: UMD PDU with 10 bit SN (Odd number of LIs, i.e. K = 1, 3, 5, ) >

http://www.sharetechnote.com/html/RLC_LTE.html 21/37
8/1/2017 ShareTechnote

< 36.322 Figure 6.2.1.3-6: UMD PDU with 10 bit SN (Even number of LIs, i.e. K = 2, 4, 6, ) >

Followings are the descriptions for each field in the UMD PDU Header.

E Field : This field indicate whether this field is the end of the header or another extention follows or not.

< 36.322 Table 6.2.2.4-1: E field interpretation (for E field in the fixed part of the header) >

< 36.322 Table 6.2.2.4-2: E field interpretation (for E field in the extension part of the header) >

http://www.sharetechnote.com/html/RLC_LTE.html 22/37
8/1/2017 ShareTechnote

FI Field : This field indicate the relative location of the RLC PDU within a RLC SDU. For example, '01' indicate the PDU
is the first segment of the SDU and '10' indicates the PDU is the last segment of the SDU, and '11' indicate the PDU is
in between the first and last segment. In a SDU, there is only one '01' type PDU and only one '10' type PDU. There
can be one or more '11' type PDU. If FI is 00, it means the RLC PDU is same as RLC SDU. When RLC recieves '01'
type, the layer start buffering the PDU within RLC memory and only when it recieves '10' PDU, RLC reassembles all
the recieved PDU and transfer it to PDCP.

< 36.322 Table 6.2.2.6-1: FI field interpretation >

How to Identify UMD PDU Type ?

In this section, you might have noticed that there are many different header types in UMD, but if you take a look at
RRC configurations for RLC UM, there are not so many parameters to determined the header type. Actually there is
only one parameter(sn-FieldLength) related to UMD header type. This is not enough to determined the exact UMD
header type. For example, if we assume that sn-FieldLength is 5 bit, there are three possible UMD header type as
shown below.

Case 1 : 36.322 Figure 6.2.1.3-1: UMD PDU with 5 bit SN (No LI)
Case 2 : 36.322 Figure 6.2.1.3-3: UMD PDU with 5 bit SN (Odd number of LIs, i.e. K = 1, 3, 5, )
Case 3 : 36.322 Figure 6.2.1.3-4: UMD PDU with 5 bit SN (Even number of LIs, i.e. K = 2, 4, 6, )

Then you may ask how the receiving side RLC can figure out which header. The answer lies in 'E' field. The 'E' field in
the first Octet and the 'E' field in the following bytes (Oct >= 2). The 'E' field in the first octet determines the header
should be 'Case 1' or 'Case 2,3' and the 'E' field in the following octets (more specifically K value) determines whether
the header type is Case 2 or Case 3. If K is 'odd num, the Case 2 header is used. If K is even number, Case 3 header
is used.

< AMD Structure >

The last type of RLC packet type is AMD (AM mode data) structure. Overall structure is very similar to UMD structure
except that it has a couple of additional field D/C, RF, P.

< 36.322 Figure 6.2.1.4-1: AMD PDU (No LI) >

< 36.322 Figure 6.2.1.4-2: AMD PDU (Odd number of LIs, i.e. K = 1, 3, 5, ) >

http://www.sharetechnote.com/html/RLC_LTE.html 23/37
8/1/2017 ShareTechnote

< 36.322 Figure 6.2.1.4-3: AMD PDU (Even number of LIs, i.e. K = 2, 4, 6, ) >

We saw many of small fields in RLC header and now let's try understanding the meaning of each of these fields.

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

< 36.322 Table 6.2.2.9-1: D/C field interpretation >

RF Field : This field indicate tye type of the AMD PDU.

< 36.322 Table 6.2.2.10-1: RF field interpretation >

http://www.sharetechnote.com/html/RLC_LTE.html 24/37
8/1/2017 ShareTechnote

P Field : This field indicate the PDU requires a status report (RLC ACK or NACK) from the other party or not.

< 36.322 Table 6.2.2.11-1: P field interpretation >

FI Field : This field indicate the relative location of the RLC PDU within a RLC SDU. For example, '01' indicate the PDU
is the first segment of the SDU and '10' indicates the PDU is the last segment of the SDU, and '11' indicate the PDU is
in between the first and last segment. In a SDU, there is only one '01' type PDU and only one '10' type PDU. There
can be one or more '11' type PDU. If FI is 00, it means the RLC PDU is same as RLC SDU. When RLC recieves '01'
type, the layer start buffering the PDU within RLC memory and only when it recieves '10' PDU, RLC reassembles all
the recieved PDU and transfer it to PDCP.

< 36.322 Table 6.2.2.6-1: FI field interpretation >

< 36.322 Table 6.2.2.8-1: LSF field interpretation >

E Field : This field indicate whether this field is the end of the header or another extention follows or not.

< 36.322 Table 6.2.2.4-1: E field interpretation (for E field in the fixed part of the header) >

< 36.322 Table 6.2.2.4-2: E field interpretation (for E field in the extension part of the header) >

Following is the structure of STATUS PDU and I recommend you to be familiar with this structure because this would
be very useful for various troubleshoot case.

http://www.sharetechnote.com/html/RLC_LTE.html 25/37
8/1/2017 ShareTechnote

< Figure 6.2.1.6-1: STATUS PDU >

CPT Field : This field applies when PDU type is Control PDU. It indicates whether the PDU is STATUS or not.

< 36.322 Table 6.2.2.13-1: CPT field interpretation >

E1 Field : This field applies when PDU type is Control PDU. It indicates whether E1 and E1 follows or not.

< 36.322 Table 6.2.2.15-1: E1 field interpretation >

< 36.322 Table 6.2.2.17-1: E2 field interpretation >

SOstart and SOend fields indicated the corresponding NACK_SN stands for 'detected as lost' which means a portion or
the whole RLC PDU is lost. According to 36.322, section 6.2.2.18, 6.2.2.19 descrbes these fields as follows.

SOstart (15 bits) : The SOstart field (together with the SOend field) indicates the portion of the AMD PDU with SN =
NACK_SN (the NACK_SN for which the SOstart is related to) that has been detected as lost at the receiving side of the
AM RLC entity.
Specifically, the SOstart field indicates the position of the first byte of the portion of the AMD PDU in bytes within the
Data field of the AMD PDU. The first byte in the Data field of the original AMD PDU is referred by the SOstart field
value "000000000000000", i.e., numbering starts at zero

SOend (15 bits) : The SOend field (together with the SOstart field) indicates the portion of the AMD PDU with SN =
NACK_SN (the NACK_SN for which the SOend is related to) that has been detected as lost at the receiving side of the
AM RLC entity.
Specifically, the SOend field indicates the position of the last byte of the portion of the AMD PDU in bytes within the
Data field of the AMD PDU. The first byte in the Data field of the original AMD PDU is referred by the SOend field value
"000000000000000", i.e., numbering starts at zero. The special SOend value "111111111111111" is used to indicate
that the missing portion of the AMD PDU includes all bytes to the last byte of the AMD PDU

RLC Decoding Tips

When you don't have automatic RLC decoder and you have to manually decode RLC header, you can get a lot of hints
just by the first 4 bits of RLC PDU as listed below. Check this table with the examples.

Binary Hex Description


http://www.sharetechnote.com/html/RLC_LTE.html 26/37
8/1/2017 ShareTechnote

0000 0 AMD Control PDU, Status PDU


100x 8 or 9 AMD Data PDU, Polling Bit = 0
101x A or B AMD Data PDU, Polling Bit = 1

Examples for RLC AMD PDU

Followings are a couple of RLC PDU example. In RLC PDU case, especially AMD PDU case, you should anlayze several
consecutive PDUs in both direction for you to get overal picture.
With these examples, you would learn and get familiar to how to utilize all the tables/diagrams shown above.

DL AMD : 88 06 06 20 06 03 41 39 40 5A D9 80 18 3A 10 17 00 30 00 07 88 80 00 08 01 A2 90 0E 08 08 48 40 3B
0B 73 93 4B A3 9B A8 28 0E 05 40 20 0A E8 08 01 80 71 1C 90 54 9C B2 03 43 A0 02 03 F8

88 06 = 10001000 00000110

D/C = 1 = Data PDU


RF = 0 = AMD PDU
P = 0 = Status PDU is not requested
FI = 01 = First byte of the Data field corresponds to the first byte of a RLC SDU,
Last byte of the Data field does not corresponds to the last byte of a RLC SDU
E = 0 = Data field follows from the octet following the LI field following this E field
SN = 0000000110

DL AMD : 98 07 00 00 01 90 1C 09 38 44 00 00 68 26 05 40 08 12 80 5F B0 07 88 84 00 08 00 00 00 00 08 98 07 88
80 00 01 18 2F A0 00 00 00 00 BF 02 CF 03 20 08 0B 53 E0 FA 81 BC 0F A8 E0 60 78 E6

98 07 = 10011000 00000111

D/C = 1 = Data PDU


RF = 0 = AMD PDU
P = 0 = Status PDU is not requested
FI = 11 = First byte of the Data field does not corresponds to the first byte of a RLC SDU,
Last byte of the Data field does not corresponds to the last byte of a RLC SDU
E = 0 = Data field follows from the octet following the LI field following this E field
SN = 0000000111

DL AMD : B0 08 3E 9D 52 D2 E8 00 FB 50 65 03 FF 04 07 E8 10 55 13 20 49

B0 08 = 10110000 00001000

D/C = 1 = Data PDU


RF = 0 = AMD PDU
P = 1 = Status PDU is requested
FI = 10 = First byte of the Data field does not corresponds to the first byte of a RLC SDU,
Last byte of the Data field corresponds to the last byte of a RLC SDU
E = 0 = Data field follows from the octet following the LI field following this E field
SN = 0000001000

DL AMD : 8C 00 DD CD DC 5D C0 80 00 6D 1B 72 6F 06 97 7E 70 DB 6C 8D C5 F5 88 B3 F3 5D 7F E4 44 B4 FF E9 3F
54 30 67 02 19 EA 57 A2 5A 33 B4 7D B5 6C A5 4B B5 ...

8C 00 DD CD DC 5D = 10001100 00000000 11011101 11001101 11011100 01011101

D/C = 1 = Data PDU


RF = 0 = AMD PDU
P = 0 = Status PDU is not requested
FI = 01 = First byte of the Data field corresponds to the first byte of a RLC SDU,
Last byte of the Data field does not corresponds to the last byte of a RLC SDU
E = 1 = A set of E field and LI field follows from the octet following the fixed part of the header
SN = 0000000000
E =1
LI1 = 10111011100 (1500 Dec)
http://www.sharetechnote.com/html/RLC_LTE.html 27/37
8/1/2017 ShareTechnote
LI1 = 10111011100 (1500 Dec)
E =1
LI2 = 10111011100 (1500 Dec)

RLC PDU = 8C 00 DD CD DC 5D C0 80 00 6D 1B 72 6F 06 97 7E 70 DB 6C 8D C5 F5 88 B3 F3 5D 7F E4 44 B4 FF E9
3F 54 30 67 02 19 EA 57 A2 5A 33 B4 7D B5 6C A5 4B B5...

DL AMD : 9C 01 D8 DD DC 5D C0 EB E2 5F BC 87 1E CA CD 1D F6 65 19 E6 3F B2 E8 F1 A8 87 C7 DC 1E 1A 01 54 91
F6 80 48 72 53 AC C3 43 6A 6B D6 9E DF 43 D6 A4 5C 03 ...

9C 01 D8 DD DC 5D = 10011100 00000001 11011000 11011101 11011100 01011101

D/C = 1 = Data PDU


RF = 0 = AMD PDU
P = 0 = Status PDU is not requested
FI = 11 = First byte of the Data field does not corresponds to the first byte of a RLC SDU,
Last byte of the Data field does not corresponds to the last byte of a RLC SDU
E = 1 = A set of E field and LI field follows from the octet following the fixed part of the header
SN = 0000000001
E =1
LI1 = 10110001101 (1421 Dec)
E =1
LI2 = 10111011100 (1500 Dec)

DL AMD : 9C 02 D3 ED DC 5D C0 E4 D4 DE 42 97 6B C5 3F DD 14 D8 31 CA F6 4F 16 D8 70 8D 4A 8B 0B 4C 07 CB
D0 DC 0B BD 9A FD C3 24 07 3D 79 AA 02 0E E0 23 29 D0 ...

9C 02 D3 ED DC 5D = 10011100 00000010 11010011 11101101 11011100 01011101

D/C = 1 = Data PDU


RF = 0 = AMD PDU
P = 0 = Status PDU is not requested
FI = 11 = First byte of the Data field does not corresponds to the first byte of a RLC SDU,
Last byte of the Data field does not corresponds to the last byte of a RLC SDU
E = 1 = A set of E field and LI field follows from the octet following the fixed part of the header
SN = 0000000010
E =1
LI1 = 1010011 1110 (1342 Dec)
E =1
LI2 = 10111011100 (1500 Dec)

DL AMD : 94 12 84 ED DC 5D C0 BB 9E AE E2 26 8C 70 1D 50 FB 35 B2 B4 1A E1 96 52 5B BE 0A A1 D2 DF C1 FF 46
F4 00 54 06 AD CB 14 8F 56 7A DE 43 A6 D1 F9 C8 ...

94 12 84 ED DC 5D = 10010100 00010010 10000100 11101101 11011100 01011101

D/C = 1 = Data PDU


RF = 0 = AMD PDU
P = 0 = Status PDU is not requested
FI = 10 = First byte of the Data field does not corresponds to the first byte of a RLC SDU,
Last byte of the Data field corresponds to the last byte of a RLC SDU
E = 1 = A set of E field and LI field follows from the octet following the fixed part of the header
SN = 00 00010010
E =1
LI1 = 00001001110 (78 Dec)
E =1
LI2 = 10111011100 (1500 Dec)

DL AMD : BC 1B B6 4D DC 5D C0 C7 33 AF D4 1D FB CC 72 17 B0 35 91 F3 6F 37 38 66 EE 07 D2 8A B1 2C 15 73 80
57 22 CD 3D A5 D8 4A 4B 0A AF 31 C2 2B D6 BD

BC 1B B6 4D DC 5D = 10111100 00011011 10110110 01001101 11011100 01011101

D/C = 1 = Data PDU


http://www.sharetechnote.com/html/RLC_LTE.html 28/37
8/1/2017 ShareTechnote

RF = 0 = AMD PDU
P = 1 = Status PDU is requested
FI = 11 = First byte of the Data field does not corresponds to the first byte of a RLC SDU,
Last byte of the Data field does not corresponds to the last byte of a RLC SDU
E = 1 = A set of E field and LI field follows from the octet following the fixed part of the header
SN = 0000011011 (27 Dec)
E =1
LI1 = 01101100100 (868 Dec)
E =1
LI2 = 10111011100 (1500 Dec)

DL AMD : A0 00 00 08 01 20 3A 90 05 1E F0 63 69 B1 F1 86 1B 25 20 3C 78 DF C6 AB B8 82 F3 93 5A B5 A7 64 80
0D 1E 79 72 F3 93 5E 35 A8 00 00 00 00

A0 00 = 10100000 00000000

D/C = 1 = Data PDU


RF = 0 = AMD PDU
P = 1 = Status PDU is requested
FI = 00 = First byte of the Data field corresponds to the first byte of a RLC SDU,
Last byte of the Data field corresponds to the last byte of a RLC SDU
E = 0 = Data field follows from the octet following the LI field following this E field
SN = 0000000000
RLC PDU = A0 00 00 08 01 20 3A 90 05 1E F0 63 69 B1 F1 86 1B 25 20 3C 78 DF C6 AB B8 82 F3 93 5A B5 A7 64 80
0D 1E 79 72 F3 93 5E 35 A8 00 00 00 00

UL AMD : 00 04 = 00000000 00000100

D/C = 0 = Control PDU


CPT = 000 = Status PDU
ACN_SN = 0000000001 (This is ACK for DL RLC SN 0)
E1 = 0

UL AMD : 00 78 = 00000000 01111000

D/C = 0 = Control PDU


CPT = 000 = Status PDU
ACN_SN = 0000011110 (This is ACK for DL RLC SN 29)
E1 = 0

UL AMD : A0 01 01 48 01 60 EA 61 14 79 E5 CB CE 4D 6A D6 80 00 00 00 00

A0 00 = 10100000 00000001

D/C = 1 = Data PDU


RF = 0 = AMD PDU
P = 1 = Status PDU is requested
FI = 00 = First byte of the Data field corresponds to the first byte of a RLC SDU,
Last byte of the Data field corresponds to the last byte of a RLC SDU
E = 0 = Data field follows from the octet following the LI field following this E field
SN = 0000000001
RLC PDU = A0 01 01 48 01 60 EA 61 14 79 E5 CB CE 4D 6A D6 80 00 00 00 00

DL AMD : 00 08 = 00000000 00001000

D/C = 0 = Control PDU


CPT = 000 = Status PDU
ACN_SN = 0000000010 (This is ACK for UL RLC SN 1)
E1 = 0 (It means that Octat 2 is the last Octat for this RLC PDU).

DL AMD : 00 22 00 40 0C 01 C0 20 = 00000000 00100010 00000000 01000000 00001100 00000001 11000000


00100000

D/C = 0 = Control PDU (1 bit)


http://www.sharetechnote.com/html/RLC_LTE.html 29/37
8/1/2017 ShareTechnote

CPT = 000 = Status PDU (3 bits)


ACN_SN = 0000001000 (10 bits, This is ACK for UL RLC SN 7)
E1 = 1 (1 bit, It means that this is not the end of RLC PDU).

NACK_SN = 0000000000 = 0 (10 bits)


E1 = 1 (1 bit, It means that this is not the end of RLC PDU)
E2 = 0 (1 bit, a set of SOstart and SOend does not follow for this NACK_SN)

NACK_SN = 0000000001 = 1 (10 bits)


E1 = 1 (1 bit, It means that this is not the end of RLC PDU)
E2 = 0 (1 bit, a set of SOstart and SOend does not follow for this NACK_SN)

NACK_SN = 0000000011 = 3 (10 bits)


E1 = 1 (1 bit, It means that this is not the end of RLC PDU)
E2 = 0 (1 bit, a set of SOstart and SOend does not follow for this NACK_SN)

NACK_SN = 0000000100 = 4 (10 bits)


E1 = 0 (1 bit, It means that this is the end of RLC PDU)
E2 = 0 (1 bit, a set of SOstart and SOend does not follow for this NACK_SN)

Examples for RLC UMD PDU

This example data are captured from a RLCs for IP throughput test (in this case, video streaming test)

DL UMD PDU 1: 1C E1 06 8F CC 48 23 E9 90 DA 18 D2 2B 1B A3 D9 5C 72 E8 D7 71 A9 51 A9 82 78 17 80 DC 9B 18
76 17 99 18 48 7F 77 22 B9 8E 79 DA A9 58 5A C8 6E 1C 93 F9 1D 64 C4 58 56 46 0C B5 A3 0C 5E B3 24 49 8F F0
51 FC D7 A0 F6 29 A3 51 73 C2 31 9E F8 4B 0F 07 34 B1 06 A8 E1 79 E0 E0 DD C7 C8 FC 23 52 08 D8 F4 48 ED 9A
70 10 EF DD 1C 80 54 45 00 02 50 0E 62 00 00 80 11 95 C9 01 01 C9 37 01 01 C9 38 04 E7 04 D2 02 3C 9B 62 47
00 44 11 E6 F0 B0 1C 80 33 A5 2C 12 C2 C8 35 16 92 61 68 12 07 0D 81 CC C7 29 C9 21 A1 B9 94 6C 25 22 E3 28
78 1A 6A E3 5A 50 1B 13 83 33 C6 57 11 4D 5B 19 55 08 31 26 75 FA 4B 42 FB 84 FF 2B 1B E2 22 B3 9C 67 07 20
AC 24 07 0D 89 6B 4D 07 24 57 BC 94 CF

1C E1 = 00011100 11100001

R1 =0
R1 =0
R1 =0
FI= 11 = First byte of the Data field does not correspond to the first byte of a RLC SDU,
Last byte of the Data field does not correspond to the last byte of a RLC SDU
E = 1 = A set of E field and LI field follows from the octet following the fixed part of the header
SN = 0011100001 = 225

06 8F = 00000110 10001111

E =0
LI = 0000110 1000 = 104
Padding = 1111

SDU 1:

CC 48 23 E9 90 DA 18 D2 2B 1B A3 D9 5C 72 E8 D7 71 A9 51 A9
82 78 17 80 DC 9B 18 76 17 99 18 48 7F 77 22 B9 8E 79 DA A9
58 5A C8 6E 1C 93 F9 1D 64 C4 58 56 46 0C B5 A3 0C 5E B3 24
49 8F F0 51 FC D7 A0 F6 29 A3 51 73 C2 31 9E F8 4B 0F 07 34
B1 06 A8 E1 79 E0 E0 DD C7 C8 FC 23 52 08 D8 F4 48 ED 9A 70
10 EF DD 1C

SDU 2: (The part in color is IP address of the data going through this RLC. This IP is nothing to do with RLC itself, but
it will be a good example that multiple IP packets are distributed among multiple RLC PDUs)

80 54 45 00 02 50 0E 62 00 00 80 11 95 C9 01 01 C9 37 01 01
C9 38 04 E7 04 D2 02 3C 9B 62 47 00 44 11 E6 F0 B0 1C 80 33
A5 2C 12 C2 C8 35 16 92 61 68 12 07 0D 81 CC C7 29 C9 21 A1
http://www.sharetechnote.com/html/RLC_LTE.html 30/37
8/1/2017 ShareTechnote

B9 94 6C 25 22 E3 28 78 1A 6A E3 5A 50 1B 13 83 33 C6 57 11
4D 5B 19 55 08 31 26 75 FA 4B 42 FB 84 FF 2B 1B E2 22 B3 9C
67 07 20 AC 24 07 0D 89 6B 4D 07 24 57 BC 94 CF

NOTE : The first two bytes (80 54) is the PDCP header and the remaining part is IP packet. If you copy the
whole SDU2 data from the third byte(i.e, 45 00 ..) and decode it with 3GPP decoder, you can see the contents
of the IP packet.

DL UMD PDU 2 : 18 E2 05 D2 2D 55 82 D9 82 51 91 A9 B8 BE C0 42 23 87 1B B6 1B CA B1 B6 3A 09 0E B9 64 6C B0
72 BA 74 53 A4 9D 8D 23 5C 9B 18 23 78 87 55 02 F4 07 E4 48 27 F0 8D 4A 3A 7E 09 80 8B 29 13 1A B2 7E 3C 8C
2B 9F 7F 0C AD E0 38 7E ED 40 B1 E8 73 46 62 4F 12 C8 FB 17 FC 70 FC A2 CF 85 52 A6 C3 40 4A 92 79 42 DC FE
B0 47 00 44 12 E4 2A 94 21 8B DF 37 69 2F 5E D9 8A 3F 65 E8 73 D4 9A 00 EE 49 D0 AC 8E 39 7E 23 F0 F9 43 F8
1B 1E FF 0A F4 5E 7C 8C B0 F2 B3 C3 80 29 E1 3A 9E 2E A0 38 DF 3C EE 1D DF 06 BE FD 82 37 62 13 A5 F1 40 F2
D5 17 6D 99 9E 5A BF D6 AB 1D 7B 96 31 1F 31 0A 1C 24 AA 35 3D 13 00 D5 B1 97 1A BC C4 7C 7A A3 C0 9E AB AC
A3 75 1D 3B 2D D5 04 AA 3F 73 73 36 1F

18 E2 = 00011000 11100010

R1 =0
R1 =0
R1 =0
FI= 11 = First byte of the Data field does not correspond to the first byte of a RLC SDU,
Last byte of the Data field does not correspond to the last byte of a RLC SDU
E = 0 = Data field follows from the octet following the fixed part of the header
SN = 0011100010 = 226

DL UMD PDU 3: 18 E3 4B 8B 6C 04 16 7B A4 DA 64 E7 D5 39 A3 2A 97 15 B0 E2 4E A5 3F 1E 38 50 2E 71 B7 18 F8
D8 F6 B1 E1 39 1C 44 80 F7 E0 F8 1D 21 2E 50 BA 80 84 A2 7F 52 BF 0F 57 3A FE 42 18 E8 2C 89 8C 75 FF 28 3A 98
02 4C 47 00 44 13 3C 11 81 25 A3 1A 5E 5B F7 1A E2 F0 57 F8 A7 D1 3A 4B 82 41 B0 E4 07 D0 A3 55 2C B7 F0 F4
C1 C5 28 90 7E 15 D7 82 CC 07 FE A0 17 0E 7C AD 49 2C 48 A0 1C 23 52 A5 71 A3 D7 5E 7E 3D 1B 8B E0 CE BC 86
8E DA FA 0B F0 B9 2F 6D 3A 0F FF 64 16 EB 53 B6 9D A9 10 4B 69 25 DF 93 30 B6 F1 A4 2E 36 CF 7C F2 92 7D E3
CB 48 AB 5E AC 4F A2 00 01 18 0D 2F 28 D0 F3 A6 04 2A 8B 6A 52 B7 A1 71 A1 C7 EF C0 B0 F2 A5 C9 16 18 30 71
6A FF 47 D2 C2 C0 0D 02 50 FB 2A 87

18 E3 = 00011000 11100011

R1 =0
R1 =0
R1 =0
FI= 11 = First byte of the Data field does not correspond to the first byte of a RLC SDU,
Last byte of the Data field does not correspond to the last byte of a RLC SDU
E = 0 = Data field follows from the octet following the fixed part of the header
SN = 0011100011 = 227

DL UMD PDU 4: 1C E4 02 2F 92 F1 62 09 15 25 34 19 DC E4 3D 46 DE 9A 44 A9 2B 3F CF 44 1A 36 BA B9 89 D6 14
54 F0 B5 F0 60 7C 7F 80 55 45 00 02 50 0E 63 00 00 80 11 95 C8 01 01 C9 37 01 01 C9 38 04 E7 04 D2 02 3C 6C
19 47 00 44 14 29 50 78 3D EE C9 0C 23 9E CF A4 41 4E F1 E5 6B 81 72 B2 1A 57 CD FC 39 55 29 4F 84 CF 52 79
CC A5 03 5A 1A 34 E6 30 39 C2 3F B1 E3 BE 13 99 B8 50 63 4D 45 4E 69 F8 5B 9A 46 4B A6 23 9C 8E 12 99 CD 4C
B0 73 49 78 33 C6 8C 6B C1 94 9C D2 20 F3 87 61 0B EC D1 E3 FD CC 0E D1 9D 2D 20 EE 60 34 6E F6 4E 5E 41 C1
3B 06 B9 72 20 32 B2 35 30 6B 63 E8 BC 3B 27 AB D6 F5 70 B2 0D 4F 09 34 06 69 96 59 1B 37 0D C3 5B D8 2C D4
6A FA 9F 3D 5E E3 5B AF AF F0 D8 43 0B

1C E4 = 00011100 11100100

R1 =0
R1 =0
R1 =0
FI= 11 = First byte of the Data field does not correspond to the first byte of a RLC SDU,
Last byte of the Data field does not correspond to the last byte of a RLC SDU
E = 1 = A set of E field and LI field follows from the octet following the fixed part of the header
SN = 0011100100 = 228

http://www.sharetechnote.com/html/RLC_LTE.html 31/37
8/1/2017 ShareTechnote

02 2F = 00000010 00101111

E =0
LI = 0000010 0010 = 34
Padding = 1111

SDU 1:

92 F1 62 09 15 25 34 19 DC E4 3D 46 DE 9A 44 A9 2B 3F CF 44
1A 36 BA B9 89 D6 14 54 F0 B5 F0 60 7C 7F

SDU 2: (The part in color is IP address of the data going through this RLC. This IP is nothing to do with RLC itself, but
it will be a good example that multiple IP packets are distributed among multiple RLC PDUs)

80 55 45 00 02 50 0E 63 00 00 80 11 95 C8 01 01 C9 37 01 01
C9 38 04 E7 04 D2 02 3C 6C 19 47 00 44 14 29 50 78 3D EE C9
0C 23 9E CF A4 41 4E F1 E5 6B 81 72 B2 1A 57 CD FC 39 55 29
4F 84 CF 52 79 CC A5 03 5A 1A 34 E6 30 39 C2 3F B1 E3 BE 13
99 B8 50 63 4D 45 4E 69 F8 5B 9A 46 4B A6 23 9C 8E 12 99 CD
4C B0 73 49 78 33 C6 8C 6B C1 94 9C D2 20 F3 87 61 0B EC D1
E3 FD CC 0E D1 9D 2D 20 EE 60 34 6E F6 4E 5E 41 C1 3B 06 B9
72 20 32 B2 35 30 6B 63 E8 BC 3B 27 AB D6 F5 70 B2 0D 4F 09
34 06 69 96 59 1B 37 0D C3 5B D8 2C D4 6A FA 9F 3D 5E E3 5B
AF AF F0 D8 43 0B

NOTE : The first two bytes (80 55) is the PDCP header and the remaining part is IP packet. If you copy the
whole SDU2 data from the third byte(i.e, 45 00 ..) and decode it with 3GPP decoder, you can see the contents
of the IP packet.

Examples from real life (Live Network)

Refer to Live Network Examples in Fullstack. You may need to put some more effort to find out RLC layer log from this
example, but you will see more diverse RLC PDU/SDU structure and see the relationship between RLC and other
layers.

Variables, constants and timers for RLC

You may noticed that the overall data flow of RLC sounds relatively easy to understand. But understanding the RLC
layer mechanism in such a detail that would help you with troubleshooting and RLC performance optimization would
not be a simple task. For the level of understanding like this, you need to understand the details of 3GPP 36.322
section 7 (Variables, constants and timers) and 3GPP 36.322 section 5 (Procedures). I would suggest to study section
7 first and then the section 5.

Variable Name Category Description


Acknowledgement state variable
This state variable holds the value of the SN of the next AMD PDU for which
a positive acknowledgment is to be received in-sequence, and it serves as
VT(A) State Variable
the lower edge of the transmitting window.
It is initially set to 0, and is updated whenever the AM RLC entity receives a
positive acknowledgment for an AMD PDU with SN = VT(A).
Maximum send state variable
VT(MS) State Variable VT(MS) = VT(A) + AM_Window_Size
it serves as the higher edge of the transmitting window
Send state variable
This state variable holds the value of the SN to be assigned for the next
VT(S) State Variable newly generated AMD PDU.
It is initially set to 0, and is updated whenever the AM RLC entity delivers an
AMD PDU with SN = VT(S)
VR(R) State Variable Receive state variable
This state variable holds the value of the SN following the last in-sequence
completely received AMD PDU

http://www.sharetechnote.com/html/RLC_LTE.html 32/37
8/1/2017 ShareTechnote

it serves as the lower edge of the receiving window. It is initially set to 0,


and is updated whenever the AM RLC entity receives an AMD PDU with SN =
VR(R).
Maximum acceptable receive state variable
VR(MR)=VR(R) + AM_Window_Size
VR(MR) State Variable
it holds the value of the SN of the first AMD PDU that is beyond the receiving
window and serves as the higher edge of the receiving window.
t-Reordering state variable
VR(X) State Variable This state variable holds the value of the SN following the SN of the RLC data
PDU which triggered t-Reordering
Maximum STATUS transmit state variable
This state variable holds the highest possible value of the SN which can be
VR(MS) State Variable
indicated by 'ACK_SN' when a STATUS PDU needs to be constructed. It is
initially set to 0
Highest received state variable
This state variable holds the value of the SN following the SN of the RLC data
VR(H) State Variable
PDU with the highest SN among received RLC data PDUs. It is initially set to
0.
This state variable holds the value of the SN to be assigned for the next
newly generated UMD PDU.
VT(US) State Variable
It is initially set to 0, and is updated whenever the UM RLC entity delivers an
UMD PDU with SN = VT(US).
UM receive state variable
VR(UR) State Variable This state variable holds the value of the SN of the earliest UMD PDU that is
still considered for reordering. It is initially set to 0
UM t-Reordering state variable
VR(UX) State Variable This state variable holds the value of the SN following the SN of the UMD
PDU which triggered t-Reordering
UM highest received state variable
This state variable holds the value of the SN following the SN of the UMD
VR(UH) State Variable
PDU with the highest SN among received UMD PDUs, and it serves as the
higher edge of the reordering window. It is initially set to 0
Poll send state variable
This state variable holds the value of VT(S)-1 upon the most recent
POLL_SN State Variable
transmission of a RLC data PDU with the poll bit set to '1'. It is initially set to
0.
This counter is initially set to 0. It counts the number of AMD PDUs sent
PDU_WITHOUT_POLL Counter
since the most recent poll bit was transmitted
This counter is initially set to 0. It counts the number of data bytes sent
BYTE_WITHOUT_POLL Counter
since the most recent poll bit was transmitted
This counter counts the number of retransmissions of an AMD PDU. There is
RETX_COUNT Counter
one RETX_COUNT counter per PDU that needs to be retransmitted.
AM_Window_Size Constant AM_Window_Size = 512
UM_Window_Size = 16 when SN size = 5 bits
UM_Window_Size Constant UM_Window_Size = 512 when SN size = 10 bits
UM_Window_Size = 0 when UM RLC is for MTCH or MCCH
used by the transmitting side of an AM RLC entity in order to retransmit a
t-PollRetransmit Timer
poll
This timer is used by the receiving side of an AM RLC entity and receiving UM
t-Reordering Timer RLC entity in order to detect loss of RLC PDUs at lower layer. only one t-
Reordering per RLC entity is running at a given time.
This timer is used by the receiving side of an AM RLC entity in order to
t-StatusProhibit Timer
prohibit transmission of a STATUS PDU
Configurable This parameter is used by the transmitting side of each AM RLC entity to
maxRetxThreshold
parameters limit the number of retransmissions of an AMD PDU
Configurable This parameter is used by the transmitting side of each AM RLC entity to
pollPDU
parameters trigger a poll for every pollPDU PDUs
Configurable This parameter is used by the transmitting side of each AM RLC entity to
pollByte
parameters trigger a poll for every pollByte bytes
Configurable
sn-FieldLength This parameter gives the UM SN field size in bits
parameters

http://www.sharetechnote.com/html/RLC_LTE.html 33/37
8/1/2017 ShareTechnote

Process of RLC UM Transmission

This section is about the RLC UM transmission procedure marked in yellow below. You can see the overall description
from Overall Data Flow for UM RLC

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

The detailed procedure is described in 36.322 5.1.2.1 Transmit operations. (To understand this description, you have
all of the variable description from Variables, constants and timers for RLC)

The process is simple. If I describe it in a psuedo code, it will be as follows.


i) VT(US) = SN (Sequence Number of the current PDU)
ii) VT(US) = VT(US) + 1

Process of RLC UM Reception

This section is about the RLC UM reception procedure marked in yellow below. You can see the overall description
from Overall Data Flow for UM RLC

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

http://www.sharetechnote.com/html/RLC_LTE.html 34/37
8/1/2017 ShareTechnote

The reception process is described in "36.322 5.1.2.2 Receive operations" and at high level point of view the process
goes as follows. Comparing to transmission process, you would immediately notice that recieiving process is much
more complicated. The main reason of this complexity lies in the fact that you cannot guarantee that all the PDUs are
coming in exact order (i.e, in-sequence). So we have to implement a specific algorithm to handle the case when these
PDUs are coming out-of-sequence.

The receiving UM RLC entity shall maintain a reordering window according to state variable VR(UH) as follows:
- a SN falls within the reordering window if (VR(UH) UM_Window_Size) <= SN < VR(UH);
- a SN falls outside of the reordering window otherwise.

When receiving an UMD PDU from lower layer, the receiving UM RLC entity shall:
- either discard the received UMD PDU or place it in the reception buffer (Refer to < Case 1 >);

If the received UMD PDU was placed in the reception buffer:


- update state variables, reassemble and deliver RLC SDUs to upper layer and start/stop t-Reordering as
needed (Refer to < Case 2 >);

When t-Reordering expires, the receiving UM RLC entity shall:


- update state variables, reassemble and deliver RLC SDUs to upper layer and start t-Reordering as needed (Refer to
< Case 3 >).

Looking into this procedure in more detail, it can be split into following three sub process (cases).

< Case 1 : Actions when an UMD PDU is received from lower layer >

This process is described in 36.322 5.1.2.2.2 Actions when an UMD PDU is received from lower layer. I will summarise
the process as follows. (NOTE : x = the sequence number of the received PDU)

if ( ( VR(UR) < x < VR(UH) ) AND (SN is overlapping with any one of previous PDUs) )
OR ((VR(UH) - UM_Window_Size) <= x < VR(UR) )
{
http://www.sharetechnote.com/html/RLC_LTE.html 35/37
8/1/2017 ShareTechnote

discard the received UMD PDU;


} else {
place the received UMD PDU in the reception buffer;
};

< Case 2 : Actions when an UMD PDU is placed in the reception buffer >

This process is described in 36.322 5.1.2.2.3 Actions when an UMD PDU is placed in the reception buffer. I will
summarise the process as follows.

if ( SN is Not within the reordering window)


{

i) VR(UH) = SN + 1;
ii) reassemble RLC SDUs from any UMD PDUs with SN that falls outside of the reordering window, remove RLC
headers when doing so and deliver the reassembled RLC SDUs to upper layer in ascending order of the RLC SN
if not delivered before

if (VR(UR) falls outside of the reordering window) {


VR(UR) = (VR(UH) - UM_Window_Size);
}
}

if (the reception buffer contains an UMD PDU with SN = VR(UR) )


{

i) VR(UR) = (the SN of the first UMD PDU with SN which is greater than current VR(UR) ) that has not been
received);
ii) reassemble RLC SDUs from any UMD PDUs with SN which is smaller than updated VR(UR), remove RLC
headers when doing so and deliver the reassembled RLC SDUs to upper layer in ascending order of the RLC SN
if not delivered before;

if(t-Reordering is running) {
if (VR(UX) <= VR(UR) ) OR (VR(UX) falls outside of the reordering window) AND (VR(UX) != VR(UH) ) {
stop and reset t-Reordering;
}
} else {
if (VR(UH) > VR(UR) ) {
i) start t-Reordering;
ii) VR(UX) = VR(UH) .
}
}

< Case 3 : Actions when t-Reordering expires >

VR(UR) = the SN of the first UMD PDU with SN >= VR(UX) that has not been received;
Reassemble RLC SDUs from any UMD PDUs with SN < updated VR(UR), remove RLC headers when doing so
and deliver the reassembled RLC SDUs to upper layer in ascending order of the RLC SN if not delivered before;

if (VR(UH) > VR(UR) ) {


start t-Reordering;
VR(UX) = VR(UH).
}

Process of RLC AM Transmission

:: Coming soon

Process of RLC AM Reception

:: Coming soon

http://www.sharetechnote.com/html/RLC_LTE.html 36/37
8/1/2017 ShareTechnote

Some issues with RLC Verification/Validation

I think one of the biggest issues with RLC test would be that most of the test equipt does not provide much flexibility
in terms of RLC layer testing. Most of the equipment seems to think of RLC as just an intermediate blocks between
PHY/MAC and RRC/NAS and think that just providing a normal RLC functionality as a big chunk with very limited user
configuration would be good enough, and most of the customer of those equipment vendor does not put many strong
requests for it. It may be OK and I haven't seen many cases where RLC layer is causing any serious issues, but
sometimes this layer is really causing some problem and once the problem happens in this layer it tend to be really
tricky to pin point out the root cause of the problem.

Some of the typical issues which may caused by RLC layer would be

i) When a bunch of RLC PDU/SDUs coming into RLC reciever with out-of sequence, the reciever fails to properly
reorder it in correct sequence.
ii) When a bunch of RLC PDU/SDUs coming into RLC reciever with some missing sequence number, the
receiver fails to detect the exact missing sequence number and send proper RLC status report to the other
party.
iii) When a RLC sender send a RLC packet with Poll Bit Set, the reciever failed to reply with correct RLC status
report or the status report within the specified time frame.

Probably this kind of problem would tend to occur in WCDMA low data rate configuration (e.g, R99) because there
would be higher degree of fragmentation for a single C-plane or U-Plane user data packet. In this theory, LTE would
have less problems since LTE can have very large data pipe that can carry a whole C-Plane/U-Plane packet with single
transmission. But still there would be some possibility of RLC layer issues especially related to fragmentation and
timing issues due to following reasons :

i) In real network (live network), it is not guaranteed that Network would allocate enough resource for the UE so
that it can transmit a whole U-plane/C-plane packet without fragmentation.
ii) Even though the network would allocate the big enough resources for the UE, you cannot guarantee that it
would allocate the resources before RLC timer get expired. (this would be less probable, but possible in theory).

http://www.sharetechnote.com/html/RLC_LTE.html 37/37

You might also like