Professional Documents
Culture Documents
Protocol Stack PDF
Protocol Stack PDF
LTE
MAC-RLC-PDCP
LTE Protocol Stack
Author – Surya Patar Munda
surya.patar@3gnets.in www.3gnets.in
3PCA-L2
If you need 3GNets LTE L2 Layer for Amateur Level (3PCA-L2), you need this course. This
knowledge and level is required for the next level – Professional Level (3PCP-L2) where you can
be trained for higher level with Hands on Projects and real implementation. Full Amateur level
courses are:
About Author:
Surya Patar Munda has been in Telecommunications Since 1987 and has gone through the life cycle
of Software Development, Software Testing, Network Deployments, Integration, Testing,
Troubleshooting, Handphone Testing with Specification etc.. a full round of the Telecom industry. He
has worked with Motorola, Nortel Networks, Spirent Communications, Sasken etc. companies with full
round cycle. The Software engineers midset and Testing engineers mindsets are different and so is
the mindset of an RF optimization engineer. This book will cater to all.
Author also conducted many trainings for Telecom industry and has a very good understanding of
what kind of requirement is there for engineers. The goal is not just what and how does it work, but
also the goal is how do I start implementing and how do I test.
----------------------------------------------------------------------------------------------------------------------------- ---------
LTE Protocol Stack- www.3gnets.in email: surya.patar@3gnets.in – Page- 2
. .
Contents
1. Data Link Layer- L2 ......................................................................................................................... 5
1.1. MAC – Medium Access Controller .......................................................................................... 5
1.1.1. MAC Architecture ............................................................................................................ 5
1.1.2. Logical Channels ............................................................................................................. 6
1.1.3. Transport Channels ......................................................................................................... 7
1.1.4. Multiplexing and Mapping between Channels ................................................................ 7
1.1.5. Scheduling ....................................................................................................................... 8
1.1.6. HARQ Algorithms ............................................................................................................ 8
1.1.7. DL HARQ Entity .............................................................................................................. 8
1.1.8. DL HARQ process ........................................................................................................... 8
1.1.9. UL HARQ entity ............................................................................................................... 9
1.1.10. UL HARQ process ........................................................................................................... 9
1.1.11. MAC Data Transfer ....................................................................................................... 10
1.1.12. Scheduling Information Transfer ................................................................................... 10
1.1.13. DL-SCH Assignment reception (on PDCCH) ................................................................ 10
1.1.14. Scheduling Request (SR) .............................................................................................. 11
1.1.15. UL Grant reception ........................................................................................................ 11
1.1.16. Multiplexing and Scheduling ......................................................................................... 12
1.1.17. Random Access (RA) Procedure in MAC ..................................................................... 12
1.1.18. Random Access Procedure initialization ....................................................................... 12
1.1.19. RA Resource selection .................................................................................................. 12
1.1.20. MAC PDU (Random Access Response) ....................................................................... 13
1.1.21. Contention Resolution (C-RNTI on PDCCH or DL-SCH).............................................. 14
1.1.22. Uplink Timing Alignment (TA) ....................................................................................... 14
1.1.23. Discontinuous Reception (DRX) ................................................................................... 14
1.1.24. Discontinuous Reception (DRX) Algorithm ................................................................... 16
1.1.25. In DRX UE action in each subframe: ............................................................................ 17
1.1.26. Multiplexing and Logical Channel Prioritization ............................................................ 17
1.1.27. MAC Priritization algorithm ............................................................................................ 18
1.1.28. Activation/Deactivation of SCells .................................................................................. 18
1.1.29. MAC Configuration and Reset ...................................................................................... 19
1.1.30. Power Headroom (PH) Reporting ................................................................................. 19
1.1.31. MAC PDU Formats........................................................................................................ 20
1.1.32. RNTI Values and Usage ............................................................................................... 20
1.2. User Plane – RLC ................................................................................................................. 23
1.2.1. RLC Introduction ........................................................................................................... 23
1.2.2. Radio Link Control (RLC) Architecture .......................................................................... 23
----------------------------------------------------------------------------------------------------------------------------- ---------
LTE Protocol Stack- www.3gnets.in email: surya.patar@3gnets.in – Page- 3
. .
1.2.3. Transparent Mode (TM) RLC Entity .............................................................................. 23
1.2.4. Unacknowledged Mode (UM) RLC Entity ..................................................................... 24
1.2.5. RLC data structure ........................................................................................................ 24
1.2.6. UM Segmentation and concatenation ........................................................................... 25
1.2.7. UM Reordering, duplicate detection, and reassembly .................................................. 26
1.2.8. UM data transfer Algorithm ........................................................................................... 26
1.2.9. Acknowledged Mode (AM) RLC Entity .......................................................................... 27
1.2.10. AM Retransmission and resegmentation ...................................................................... 27
1.2.11. AM Polling, status report and status prohibit ................................................................ 28
1.2.12. RLC PDU Formats ........................................................................................................ 28
1.2.13. RLC – ARQ Algorithm ................................................................................................... 30
1.2.14. AM Transmit operations ................................................................................................ 30
1.2.15. AM Receive operations ................................................................................................. 30
1.2.16. Retransmission.............................................................................................................. 30
1.3. User Plane - PDCP ............................................................................................................... 33
1.3.1 PDCP - Functions and Architecture .............................................................................. 33
1.3.2 Header Compression .................................................................................................... 34
1.3.3 Security ......................................................................................................................... 34
1.3.4 Handover – Seamless and Lossless ............................................................................. 34
1.3.5 Discard of Data Packets ................................................................................................ 35
1.3.6 PDCP PDU Formats...................................................................................................... 35
1.3.7 PDCP Variables ............................................................................................................ 36
1.3.8 PDCP Procedures ......................................................................................................... 37
----------------------------------------------------------------------------------------------------------------------------- ---------
LTE Protocol Stack- www.3gnets.in email: surya.patar@3gnets.in – Page- 4
. .
1. Data Link Layer- L2
1.1. MAC – Medium Access Controller
LTE Layer 2 user-plane protocol stack is composed of three sublayers – PDCP, RLC, MAC. LTE L2
protocol stack, acts as interface between wireless sources of packet data traffic and LTE PHY layer
and helps L1 to be used efficiently for packet data traffic.
The Packet Data Convergence Protocol (PDCP) layer: This layer processes RRC messages in
control plane and IP packets in user plane. Main functions are header compression, security
(integrity protection and ciphering), and support for reordering and retransmission during
handover. There is one PDCP entity per radio bearer.
The Radio Link Control (RLC) layer: Main functions of RLC are segmentation and reassembly
packets in to adapt them to the size suitable for radio interface. For bearers which need error-free
transmission, retransmission may be performed to recover packet losses. RLC reorders to
compensate out-of-order reception due to HARQ in MAC. There is one RLC entity per radio
bearer.
The Medium Access Control (MAC) layer: MAC multiplexes data from different radio bearers.
There is only one MAC entity per UE. MAC achieves negotiated QoS for each radio bearer, By
deciding data quantity transmitted from each radio bearer and instructing RLC layer to provide
size of packets. ForUL, UE reports Buffer Status Report to eNB, remaining data to be
transmitted. Below figure shows the DL and UL L2 Protocol stack components.
At Tx side, each layer receives a SDU from higher layer, and outputs PDU to the layer below. As an
example, RLC receives PDCP PDUs as RLC SDUs. RLC creates RLC PDUs and provided to MAC as
MAC SDUs. At Rx side, the process is reversed, each layer data is received as PDUs, processes and
sent to higher layer as SDU.
All PDUs, SDUs and headers by PDCP, RLC and MAC are byte aligned, meaning sometimes unused
padding bits are needed as sacrifice to gain processing speed.
Upper layers
HARQ Random
HARQ
Access Control
In adaptive HARQ, modulation, coding scheme, and freq resource allocation may be changed at each
retransmission. In nonadaptive HARQ, retransmissions are performed either by same previous
transmission attributes, or by predefined rules. Adaptive HARQ brings more scheduling gain at the
expense of signalling overhead.
In LTE, DL uses Asynchronous adaptive HARQ, and UL Synchronous (Adaptive/Non Adaptive)
HARQ.
(De)multiplexer (de)multiplexed several logical channels data into/from one transport channel. It
generates MAC PDUs from MAC SDUs for a new transmission. Process prioritises data from logical
channels to decide how much data and from which logical channel(s) should be included in each
PDU. Demultiplexer reassembles MAC SDUs from PDUs and distributes them to appropriate RLC
entities. MAC peers communicate through „MAC Control Elements‟ which can be included in the MAC
PDU. MAC Controller handles Discontinuous Reception (DRX), Random Access Channel (RACH),
Data Scheduling and UL timing alignment.
----------------------------------------------------------------------------------------------------------------------------- ---------
LTE Protocol Stack- www.3gnets.in email: surya.patar@3gnets.in – Page- 6
. .
Control logical channels.
1. Broadcast Control Channel (BCCH). DL channel used to broadcast SI with TM-RLC.
2. Paging Control Channel (PCCH). DL channel used to notify incoming call or SI change.
3. Common Control Channel (CCCH). DL/UL channel used to deliver control information
during connection establishment with TM-RLC.
4. Multicast Control Channel (MCCH). DL channel used to transmit control information for
MBMS services with UM-RLC.
5. Dedicated Control Channel (DCCH). DL/UL channel used to transmit dedicated control to
a specific UE after connection establishment with AM-RLC.
6. Traffic logical channels.
a. Dedicated Traffic Channel (DTCH). UL/DL channel used to transmit dedicated user
data with either UM-RLC or AM-RLC.
b. Multicast Traffic Channel (MTCH). DL channel used to transmit user data for MBMS
services with UM-RLC.
----------------------------------------------------------------------------------------------------------------------------- ---------
LTE Protocol Stack- www.3gnets.in email: surya.patar@3gnets.in – Page- 7
. .
In UL, UL-SCH carries all logical channels.
1.1.5. Scheduling
eNodeB scheduler distributes available RB in one cell among the UEs, and among radio bearers of
each UE, based respectively on the downlink data buffered in the eNodeB and on Buffer Status
Reports (BSRs) received from the UE. eNodeB considers QoS requirements of each bearer, and
selects MAC PDU size. Scheduling algorithm is left to eNodeB implementation, but scheduling
signalling is standardized.
Dynamic scheduling, is done by DL assignment and UL grant messages for allocation of DL/UL
resources, valid for specific single subframes, transmitted on PDCCH using C-RNTI (to identify
intended UE).
Persistent scheduling enables RB to be semi-statically allocated to a UE for a longer time period than
one subframe, avoiding DL assignment or UL grant on PDCCH for each subframe. This is used for
VoIP kind of services where packets are small, periodic and semistatic in size. Overhead of PDCCH is
reduced.
For persistent scheduling, RRC indicates allocation interval at which RB are periodically assigned. RB
allocations, modulation and coding are signalled by PDCCH. PDCCH messages timing is taken as
relative reference. Semi-Persistent Scheduling C-RNTI (SPS-C-RNTI) is used to distinguish it from
dynamic scheduling.
Reconfiguration of RB used for persistent scheduling can be performed when UE moves between a
silent to talk talk spurt, or when codec rate changes. New DL assignment or UL grant is transmitted to
configure larger SPS RB for bigger VoIP packet.
----------------------------------------------------------------------------------------------------------------------------- ---------
LTE Protocol Stack- www.3gnets.in email: surya.patar@3gnets.in – Page- 8
. .
7. If Tx is with Temporary C-RNTI and no Contention Resolution yet; or HARQ
PID=broadcast; or timeAlignmentTimer is stopped or expired: No ACK/NACK.
8. else: Generate ACK/NACK for this TB.
9. NDI will be ignored, if NDI is toggled compared to previous on DL assignments on
PDCCH for its Temp C-RNTI.
----------------------------------------------------------------------------------------------------------------------------- ---------
LTE Protocol Stack- www.3gnets.in email: surya.patar@3gnets.in – Page- 9
. .
1.1.11. MAC Data Transfer
1.1.12. Scheduling Information Transfer
Buffer Status Reports (BSRs) from UE to eNodeB are used to assist eNodeB‟s allocation of UL RB.
BSR indicates the pending data to be sent. Thus eNB knows the RB requirements for both directions.
Two types of BSR: long BSR and short BSR; Logical channels are divided into 4 Logical Channel
Groups (LCG). Short BSR conveys pending data for one group and long BSR conveys for 4 groups.
A BSR can be triggered in following situations:
1. Higher priority logical channels Data arrives compared to previous logical channel priority,
whise data BSR contained.
2. Prdefined time has elapsed since last BSR transmission;
3. Serving cell changes.
If UE doesn‟t have enough UL-SCH resources to send BSR, either single bit „Scheduling Request‟
(SR) is sent on PUCCH or RACH is performed to get UL grant for sending BSR. Thus eNodeB always
has information about data waiting in each UE‟s UL buffer grant RB appropriately.
1. BSR reports how much UL pending data is there with UE to serving eNB.
2. Maintain periodicBSR-Timer and retxBSR-Timer for each logical channel, also
logicalChannelGroup.
3. When is a BSR triggered?
1. UL data, for LoCH of a LCG, becomes RTS(Ready to send) in RLC or PDCP entity.
“Regular BSR”.
2. UL resources allocated and if (padding bits >= sizeof(BSR)+subheader), pad
"Padding BSR";
3. retxBSR-Timer expires and the data is ready for LoCH of LCG, send "Regular BSR";
4. periodicBSR-Timer expires, send "Periodic BSR".
4. Long or Short BSR?
1. if more than one LCG‟ BSR need to be sent in a TTI: report Long BSR; else report
Short BSR.
2. If (sizeof(long BSR)+subheader>=padding bits >= sizeof(BSR)+subheader): report
short BSR.
3. else report Long BSR.
5. If at least one BSR is triggered: Whenever new data is sent on UL-SCH, or UL-SCH is
granted
1. generate the BSR MAC control element(s);
2. start or restart periodicBSR-Timer and retxBSR-Timer.
6. All triggered BSRs shall be cancelled if all pending data is sent.
7. At most one Regular/Periodic BSR per TTI per LoCH. But, padding BSR can be every PDU.
8. Buffer Status Report MAC Control Elements
1. Two types of BSR(Identified by subheader LC(G)ID):
1. Short BSR and Truncated BSR format: one LCG ID and Buffer Size field; or
2. Long BSR format: Four LCG ID and Buffer Size fields.
2. LCG ID(2bits): Group of logical channel(s).
3. Buffer Size(6bit index): Total data across all LoCH group(including RLC/PDCP data
excluding headers) after MAC PDUs for the TTI are built. One of the tables is used
based on extendedBSR-Sizes = true or false.
Buffer
Buffer Size #0 Oct 1
Size #1
LCG ID Buffer Size Oct 1 Buffer Size #1 Buffer Size #2 Oct 2
Buffer
Buffer Size #3 Oct 3
Size #2
----------------------------------------------------------------------------------------------------------------------------- ---------
LTE Protocol Stack- www.3gnets.in email: surya.patar@3gnets.in – Page- 10
. .
1. if this is the first DL assignment for this Temporary C-RNTI: consider NDI is
toggled.
2. if DL assignment is for UE‟s C-RNTI, consider NDI toggled regardless of value of
the NDI.
3. deliver HARQ info to the HARQ entity for this TTI.
2. else, if Serving Cell=PCell and DL assignment is for PCell and no measurement gap in
this TTI; and
3. if this TTI is not MBSFN subframe or transmission mode =tm9 :
1. Receive TB on DL-SCH as per DL assignment and deliver it to HARQ entity;
2. set the HARQ Process ID to the HARQ Process ID associated with this TTI;
3. consider NDI toggled; deliver HARQ info to HARQ entity for this TTI.
2. When the UE needs to read BCCH, the UE may, based on the scheduling information from RRC:
1. BCCH can be read if DL assignment for this TTI for SI-RNTI is received on PDCCH of
PCell;
1. if the redundancy version is not defined in the PDCCH format:
1. Redundancy Version RVK = ceiling(3/2*k) modulo 4,
2. For SIB1, k = (SFN/2) modulo 4, where SFN is the system frame number;
w
3. For other SIB, k=i modulo 4, i =0,1,…, ns –1, where i =subframe number
w
within SI window ns ;
2. indicate DL assignment and RV for dedicated broadcast HARQ process to HARQ
entity for this TTI.
----------------------------------------------------------------------------------------------------------------------------- ---------
LTE Protocol Stack- www.3gnets.in email: surya.patar@3gnets.in – Page- 12
. .
2. else, if Msg3 is being retransmitted: select same group as earlier.
3. randomly select a Preamble within the selected group.
4. set PRACH Mask Index to 0.
7. determine the next subframe containing PRACH permitted (prach-ConfigIndex,
PRACH Mask Index and L1 timing);
8. determine a PRACH within subframe as per PRACH Mask Index.
9. Transmit RA Preamble.
2. Random Access Preamble transmission Parameters
1. set PREAMBLE_RECEIVED_TARGET_POWER =
preambleInitialReceivedTargetPower + DELTA_PREAMBLE +
(PREAMBLE_TRANSMISSION_COUNTER – 1) * powerRampingStep;
2. transmit using selected PRACH (RA-RNTI, preamble index,
PREAMBLE_RECEIVED_TARGET_POWER).
3. Random Access Response(RAR) reception
1. Once RA Preamble(RAPID) transmitted, UE monitors PDCCH of PCell forRARs identified
by RA-RNTI.
2. RAR window(ra-ResponseWindowSize subframes) starts at end of RACH tx subframe +
3 subframes.
3. RA-RNTI= 1 + t_id(index of first subframe(0<=x<10)) +10*f_id(PRACH index within
subframe(0<=y<6))
4. UE stops monitoring after RAR reception with same RAPID.
1. if RA Response contains BI - backoff param = BI; Else backoff param = 0 ms.
2. if RAPID = Transmitted RAPID:
1. process Timing Advance Command;
2. indicate preambleInitialReceivedTargetPower to lower layers.
3. Indicate ((PREAMBLE_TRANSMISSION_COUNTER – 1) *
powerRampingStep) to lower layers.
4. process UL grant and indicate it to lower layers;
5. if ra-PreambleIndex was explicitly signalled (not selected by MAC, not
000000): Success.
1. consider the RA procedure successfully completed.
6. else, if RA Preamble was selected by UE MAC(000000):
1. set Temporary C-RNTI = RAR Temp C-RNTI & include it in
subsequent UL Tx;
2. Start PDU from "Multiplexing and assembly" and store in Msg3
buffer.
5. For contention resolution, minimum UL grant > 56bits in RAR by eNB.
6. If no RAR within RA Response window:
1. PREAMBLE_TRANSMISSION_COUNTER++;
2. If PREAMBLE_TRANSMISSION_COUNTER = preambleTransMax + 1: Inform
Upper Layer, FAILURE.
3. if RA Preamble was selected by MAC: Select a random backoff time; and delay
RA retransmission.
4. proceed to the selection of a Random Access Resource.
----------------------------------------------------------------------------------------------------------------------------- ---------
LTE Protocol Stack- www.3gnets.in email: surya.patar@3gnets.in – Page- 13
. .
6. R(Reserved bit)="0";
7. Timing Advance(TA,11bits) Command:- Index TA (0, 1, 2… 1282) amount of timing
adjustment to apply.
8. UL Grant(20bits): Resources to be used on UL.
9. Temporary C-RNTI(16bits): Temporary identity of UE during Random Access.
10. Padding may be there at the end of the last RAR data field.
----------------------------------------------------------------------------------------------------------------------------- ---------
LTE Protocol Stack- www.3gnets.in email: surya.patar@3gnets.in – Page- 14
. .
UE checks for messages (by its C-RNTI on PDCCH) during „On Duration‟ period of either long or
short DRX cycle depending on currently active cycle. When a message is received during „On
Duration‟, UE starts an „Inactivity Timer’ and monitors PDCCH in every subframe during Timer
running and UE is in a continuous reception mode. Whenever a message is received while Inactivity
Timer is running, restart the Inactivity Timer. Whenever it expires without getting message, UE moves
into short DRX cycle and starts a „Short DRX cycle timer‟. Short DRX cycle may also be initiated by
MAC Control Element. When short DRX cycle timer expires, without message, UE moves into long
DRX cycle.
HARQ Round Trip Time (RTT) timer‟ is defined for UE to sleep during HARQ RTT. When decoding
DL TB for one HARQ fails, UE can next retransmission TB after at least „HARQ RTT‟ subframes.
While HARQ RTT timer is running, UE does not need to monitor PDCCH. At HARQ RTT timer expiry,
UE resumes PDCCH reception.
Scenario 1: Only Long DRX Cycle is configured and No PDCCH is received during the cycle.
Scenario 2: Only Long DRX Cycle is configured and a PDCCH is received during a cycle (real 'ON
time' May get extended depending on DRX Inactivity Timer and when the PDCCH is recieved).
----------------------------------------------------------------------------------------------------------------------------- ---------
LTE Protocol Stack- www.3gnets.in email: surya.patar@3gnets.in – Page- 15
. .
Scenario 3 : Only Long DRX Cycle is configured and a PDCCH and DRX Command MAC CE are
received during a cycle (real 'ON time' MAY get shorter depending on exactly when DRX Command
MAC CE is received).
Scenario 4 : Both Long DRX Cycle and Short DRX Cycle are configured and No PDCCH is received
during the cycle.
----------------------------------------------------------------------------------------------------------------------------- ---------
LTE Protocol Stack- www.3gnets.in email: surya.patar@3gnets.in – Page- 16
. .
2. In RRC_CONNECTED(only in DRX), PDCCH is discontinuously monitored; otherwise
monitors continuously.
3. RRC configures
1. onDurationTimer,
2. drx-InactivityTimer,
3. drx-RetransmissionTimer (one per DL HARQ process),
4. longDRX-Cycle, the value of the
5. drxStartOffset and
6. drxShortCycleTimer and
7. shortDRX-Cycle.
8. A HARQ RTT timer per DL HARQ process.
4. In DRX cycle, the Active Time is:
1. onDurationTimer or drx-InactivityTimer or drx-RetransmissionTimer or mac-
ContentionResolutionTimer is running; or
2. SR is sent on PUCCH and is pending; or
3. UL grant for a pending HARQ retransmission occurs and ready with HARQ
buffer; or
4. PDCCH indicates a new data to C-RNTI of the UE for different preamble, not sent
by UE.
Pack MAC PDU with, data from highest priority LoCH first, then data from next highest priority LoCH,
continuing until PDU size is completely filled or there is no more data to transmit.
It is good method, but sometimes leads to starvation of low-priority bearers, when lower priority LoCH
cannot transmit because data from higher priority LoCH always takes up all resources.
----------------------------------------------------------------------------------------------------------------------------- ---------
LTE Protocol Stack- www.3gnets.in email: surya.patar@3gnets.in – Page- 17
. .
To avoid starvation, Prioritized Bit Rate (PBR) is configured by eNodeB for each LoCH. PBR is the
data rate of a LoCH before allocating any resource to a lower-priority LoCH.
Each LoCH is served in decreasing order of priority, data amount from each LOCH put into PDU is
corresponding to PBR, one by one for all. If there is still room left in PDU, each LoCH is served again
in decreasing order of priority. In this second round, each LoCH is served only if all higher priority
LoCH has no more to send.
MAC CE has higher priority than any other LoCH and in included first in PDU on priority, except in
one situation when UE transmits first RRC message after HO (BSR has lower priority than SRB,
completion of HO ASAP is more important).
C7 C6 C5 C4 C3 C2 C1 R Oct 1
----------------------------------------------------------------------------------------------------------------------------- ---------
LTE Protocol Stack- www.3gnets.in email: surya.patar@3gnets.in – Page- 19
. .
Fig 4.1.31 – LCID codes in MAC PDU
MAC CE helps peer-to-peer signalling, BSR and PHR (power headroom) in UL, and in DL DRX
command and TA. For each type of CE, one special LCID is allocated. When PDU is used for PCCH
or BCCH LoCH, PDU includes data from only one LoCH – since no multiplexing, no LCID required.
Here is the list of MAC control Messages:
----------------------------------------------------------------------------------------------------------------------------- ---------
LTE Protocol Stack- www.3gnets.in email: surya.patar@3gnets.in – Page- 20
. .
RNTI Usage Transport Logical
Channel Channel
P-RNTI Paging and System Information change PCH PCCH
notification
SI-RNTI Broadcast of System Information DL-SCH BCCH
M-RNTI MCCH Information change notification N/A N/A
RA-RNTI Random Access Response DL-SCH N/A
Temp C-RNTI Contention Resolution DL-SCH CCCH
(when no valid C-RNTI is available)
Temp C-RNTI Msg3 transmission UL-SCH CCCH,
DCCH, DTCH
C-RNTI Dynamically scheduled unicast transmission UL-SCH DCCH, DTCH
C-RNTI Dynamically scheduled unicast transmission DL-SCH CCCH,
DCCH, DTCH
C-RNTI Triggering of PDCCH ordered random N/A N/A
access
SPS-C-RNTI Semi-Persistently scheduled unicast DL-SCH, DCCH, DTCH
transmission UL-SCH
(activation, reactivation and retransmission)
SPS C-RNTI Semi-Persistently scheduled unicast N/A N/A
transmission
(deactivation)
TPC-PUCCH- Physical layer Uplink power control N/A N/A
RNTI
TPC-PUSCH- Physical layer Uplink power control N/A N/A
RNTI
----------------------------------------------------------------------------------------------------------------------------- ---------
LTE Protocol Stack- www.3gnets.in email: surya.patar@3gnets.in – Page- 21
. .
----------------------------------------------------------------------------------------------------------------------------- ---------
LTE Protocol Stack- www.3gnets.in email: surya.patar@3gnets.in – Page- 22
. .
1.2. User Plane – RLC
1.2.1. RLC Introduction
LTE Layer 2 user-plane protocol stack is composed of three sublayers – PDCP, RLC, MAC. LTE L2
protocol stack, acts as interface between wireless sources of packet data traffic and LTE PHY layer
and helps L1 to be used efficiently for packet data traffic.
The Radio Link Control (RLC) layer: Main functions of RLC are segmentation and reassembly
packets in to adapt them to the size suitable for radio interface. For bearers which need error-free
transmission, retransmission may be performed to recover packet losses. RLC reorders to
compensate out-of-order reception due to HARQ in MAC. There is one RLC entity per radio
bearer.
At Tx side, each layer receives a SDU from higher layer, and outputs PDU to the layer below. As an
example, RLC receives PDCP PDUs as RLC SDUs. RLC creates RLC PDUs and provided to MAC as
MAC SDUs. At Rx side, the process is reversed, each layer data is received as PDUs, processes and
sent to higher layer as SDU.
All PDUs, SDUs and headers by PDCP, RLC and MAC are byte aligned, meaning sometimes unused
padding bits are needed as sacrifice to gain processing speed.
There are 3 types of RLC entities: Transparent Mode (TM), Unacknowledged Mode (UM), and
Acknowledged Mode (AM). Choice is made by RRC during bearer setup based on QCI and QoS.
----------------------------------------------------------------------------------------------------------------------------- ---------
LTE Protocol Stack- www.3gnets.in email: surya.patar@3gnets.in – Page- 25
. .
After segmentation and/or concatenation of SDUs, RLC includes headers in PDU with sequence
number, size and boundary of each included SDU or SDU segment. PDU is always byte-aligned and
no padding.
Transmitting and receiving sides are similar to UM RLC, except for retransmission blocks.
Transmitting side performs segmentation and/or concatenation of SDUs to form PDUs with headers,
and Receiving side reassembles SDUs from PDUs after HARQ reordering.
----------------------------------------------------------------------------------------------------------------------------- ---------
LTE Protocol Stack- www.3gnets.in email: surya.patar@3gnets.in – Page- 29
. .
Fig 4.2.12.2 – AMD status PDU format
1.2.16. Retransmission
Retransmission
1. Tx RLC receives NACK for PDU or portion of PDU by STATUS PDU from peer RLC. Then
2. if VT(A) <= SN < VT(S): consider for Retransmission.
----------------------------------------------------------------------------------------------------------------------------- ---------
LTE Protocol Stack- www.3gnets.in email: surya.patar@3gnets.in – Page- 30
. .
3. For first time, RETX_COUNT = zero; else RETX_COUNT++;
4. if RETX_COUNT = maxRetxThreshold: Indicate upper layer;
5. if PDU can entirely fit within total size of RLC PDU(s) deliver as it is except set P bit.
6. otherwise: Form new PDU segment and deliver to MAC.
7. segment rest of the segment PDU as necessary, and deliver to MAC, with P field.
Polling - to trigger STATUS for Transmission of a AMD PDU or AMD PDU segment
1. Upon assembly and transmission of PDU:
1. PDU_WITHOUT_POLL++;
2. BYTE_WITHOUT_POLL += PDU data bytes.
3. if (PDU_WITHOUT_POLL >= pollPDU) or (BYTE_WITHOUT_POLL >= pollByte) -
include P bit.
1. Also check - if Tx buffer and (Re)Tx buffer becomes empty (excluding Un-
ACKed) – include P bit.
2. To include a poll bit: P=“1”; PDU_WITHOUT_POLL = 0;
BYTE_WITHOUT_POLL = 0;
2. After Tx PDU including P, VT(S)++ if necessary: POLL_SN = VT(S) – 1; (re) start t-
PollRetransmit
3. Reception of a STATUS report
4. if STATUS ACK or NACK with SN=POLL_SN: If t-PollRetransmit is running: stop & reset.
5. Expiry of t-PollRetransmit
6. If Tx and Re-Tx buffer are empty OR Retransmitting UnAcked PDUs: Include P bit.
----------------------------------------------------------------------------------------------------------------------------- ---------
LTE Protocol Stack- www.3gnets.in email: surya.patar@3gnets.in – Page- 31
. .
----------------------------------------------------------------------------------------------------------------------------- ---------
LTE Protocol Stack- www.3gnets.in email: surya.patar@3gnets.in – Page- 32
. .
1.3. User Plane - PDCP
LTE Layer 2 user-plane protocol stack is composed of three sublayers – PDCP, RLC, MAC. LTE L2
protocol stack, acts as interface between wireless sources of packet data traffic and LTE PHY layer
and helps L1 to be used efficiently for packet data traffic.
The Packet Data Convergence Protocol (PDCP) layer: This layer processes RRC messages in
control plane and IP packets in user plane. Main functions are header compression, security
(integrity protection and ciphering), and support for reordering and retransmission during
handover. There is one PDCP entity per radio bearer.
At Tx side, each layer receives a SDU from higher layer, and outputs PDU to the layer below. As an
example, RLC receives PDCP PDUs as RLC SDUs. RLC creates RLC PDUs and provided to MAC as
MAC SDUs. At Rx side, the process is reversed, each layer data is received as PDUs, processes and
sent to higher layer as SDU.
All PDUs, SDUs and headers by PDCP, RLC and MAC are byte aligned, meaning sometimes unused
padding bits are needed as sacrifice to gain processing speed.
----------------------------------------------------------------------------------------------------------------------------- ---------
LTE Protocol Stack- www.3gnets.in email: surya.patar@3gnets.in – Page- 33
. .
1.3.2 Header Compression
RObust Header Compression (ROHC) protocol is very important in LTE, because there is no support
for transport of voice via Circuit-Switched (CS) domain. To provide VoIP in PS domain close to CS
services, it is necessary to compress IP/UDP/RTP header used for VoIP.
IETF specifies in „RFC 4995‟ (enhanced from UMTS reference RFC 3095) a framework which
supports many different header compression „profiles‟ (i.e. sets of rules for compression). UE may
implement one or more ROHC profiles.
If UE supports VoIP, then ROHC is mandatory (at least one) for compression of RTP, UDP and IP, or
else not. eNB-RRC controls which ROHC profiles supported by UE are allowed. ROHC compressors
in UE and eNB dynamically detect IP flows and choose a suitable profile from the allowed and
supported profiles.
Sender and receiver store the static parts of header (IP addresses of sender/receiver) and
compressed, and update when changed. Dynamic parts (timestamp in RTP) are compressed by
transmitting only the difference from a reference clock.
Non-changing parts are transmitted only once. Feedback is used to confirm correct reception of
initialization for header decompression. Correct decompression is confirmed periodically.
Typically, for transport of VoIP packets which contains a payload of 32 bytes, header is 60 bytes for
IPv6 and 40 bytes for IPv4 – overhead of 188% and 125% respectively.
By ROHC, after initialization of compression entities, overhead is compressed to 4-6 bytes, and thus
relative overhead of 12.5% to 18.8%. This calculation is valid during active periods.During silence
periods This gain is not that high as payloads are small.
1.3.3 Security
Implementation of security, by ciphering and integrity protection, is responsibility of PDCP. A PDCP
Data PDU counter ( „COUNT‟) is used as input to security algorithms. COUNT increments(32 bits) for
each Data PDU during RRC connection, maintained by UE and eNB. For robustness against lost
packets, each Data PDU includes a PDCP Sequence Number (SN), the LSB of COUNT. A loss of
synchronization of COUNT value between UE and eNB can then only occur if SN number of packets
are lost consecutively, a very less probability. Increasing SN can minimize chance but increase
overhead. Counter is designed to protect against replay attack, where attacker tries to resend a
previously intercepted packet. Due to use of COUNT, if retransmitted twice, ciphering pattern will be
completely uncorrelated, thus preventing possible security breaches. Integrity protection is realized by
adding MAC-I to each RRC message. MAC-I is calculated based on AS keys, message itself, RABID,
direction, & COUNT value. If integrity check fails, message will be discarded.
Ciphering is realized by XOR with \message and a ciphering stream generated by ciphering algorithm
based on AS keys, RABID, direction, and COUNT. Ciphering is applied to PDCP Data PDUs. Control
PDUs (feedback or status reports) are neither ciphered nor integrity protected. eNodeB is responsible
for avoiding reuse of COUNT with same combination of RABID, AS base-key and algorithm. To avoid
reuse, eNB may use different RABIDs, trigger intracell handover or trigger a state transition from
connected to idle and back to connected again.
Lossless Handover
Based on SN of PDCP Data PDUs it is possible to ensure in-sequence delivery, and provide a fully
lossless handover with retransmission of PDCP PDUs for which NO ACK before handover. This is
used mainly for delay-tolerant lossless services such as file downloads. Loss can result in drastic
reduction in data rate due to TCP retransmission. Lossless HO is applied for RLC-AM.
Header compression is reset in UE because ROHC context is not forwarded from S-eNB to T-eNB.
PDCP SN & COUNT are maintained.
In normal transmission without HO, RLC in UE and eNodeB ensures in-sequence delivery.
Retransmitted out of sequence PDUs are reordered based on RLC Sequence Number. In PDCP,
PDCP SDUs received out of order are stored in reordering buffer. PDCP SDUs transmitted but not
acknowledged are stored in retransmission buffer in PDCP.
To ensure lossless HO in UL, UE retransmits PDCP SDUs in retransmission buffer. SeNB, after
decompression, delivers PDCP SDUs received in-sequence to the gateway, and forwards PDCP
SDUs received out-of-sequence to target eNodeB.
To ensure lossless HO in DL, SeNB forwards uncompressed Un-Acked PDCP SDUs to TeNB for
retransmission in DL. SeNB receives indication from S-GW that indicates the last packet sent to
SeNB. SeNB forwards this Last Packet indication to TeNB so that TeNB knows when it can start
transmission of packets received from S-GW.
UE can reorder received PDCP SDUs and SDUs that are stored in reordering buffer, and deliver them
to higher layers in sequential order. UE will expect packets from TeNB in ascending order SN. PDCP
status report can be sent from eNodeB to UE and vice versa to update what is already received to
avoid any unnecessary retransmission. Whether to send PDCP status report after handover is
configured independently for each bearer.
----------------------------------------------------------------------------------------------------------------------------- ---------
LTE Protocol Stack- www.3gnets.in email: surya.patar@3gnets.in – Page- 35
. .
PDCP Data PDU for U-plane using short SN is mapped on RLC-UM for VoIP services, where
seamless handover is used and retransmission not necessary. There are two types of PDCP Control
PDU, distinguished by type field in header - Status Reports for lossless HO, or ROHC feedback.
ROHC feedback carries exactly one ROHC feedback packet in one PDCP PDU. Status Report PDU
for lossless HO is used to prevent retransmission of already-correctly-received SDUs, and to request
retransmission of failed ones. Status report contains bitmap indicating what received and what not
with First Missing SDU (FMS) as reference point.
----------------------------------------------------------------------------------------------------------------------------- ---------
LTE Protocol Stack- www.3gnets.in email: surya.patar@3gnets.in – Page- 39
. .
----------------------------------------------------------------------------------------------------------------------------- ---------
LTE Protocol Stack- www.3gnets.in email: surya.patar@3gnets.in – Page- 40
. .
----------------------------------------------------------------------------------------------------------------------------- ---------
LTE Protocol Stack- www.3gnets.in email: surya.patar@3gnets.in – Page- 41
. .
----------------------------------------------------------------------------------------------------------------------------- ---------
LTE Protocol Stack- www.3gnets.in email: surya.patar@3gnets.in – Page- 42
. .