|
4G/LTE - Protocol Stack |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
RLC
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
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 >
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.
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.
< 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.
< RLC Dowlink Data Flow Example >
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. (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.)
< RLC Uplink Data Flow Example >
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 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 >
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 >
< 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.
+-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] | | | +-dl-UM-RLC ::= SEQUENCE | | | +-sn-FieldLength ::= ENUMERATED [size5] | | | +-t-Reordering ::= ENUMERATED [ms0]
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 >
< 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.
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 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.
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
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 : 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
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
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:------------------------------------
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.
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
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)
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 { { 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)
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.
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.
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 >
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.
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.
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, …) >
< 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) >
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.
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, …) >
< 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 >
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.
< 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
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.
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) 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 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) 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)
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 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
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.
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
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 >
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) ) { 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 { i) start t-Reordering; } }
< 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;
start t-Reordering; }
Process of RLC AM Transmission
:: Coming soon
:: Coming soon
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).
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
