Lte protocol-stack-mac-rlc-pdcp

LTE Protocol Stack- 1 surya.patar@3gnets.in
LTE Development, Conformance Test,
OptimizationCertification Course – Amateur Level
(3PCA-L1)
3PCA-L2
LTE
MAC-RLC-PDCP
LTE Protocol Stack
Author – Surya Patar Munda
surya.patar@3gnets.in www.3gnets.in

--------------------------------------------------------------------------------------------------------------------------------------
LTE Protocol Stack- www.3gnets.in email: surya.patar@3gnets.in – Page- 2
. .
Preface:
Dedication – This book is dedicated to my family who has given me support to complete this book.
The colleagues in office have given me encouragement to start and complete this book. My hearty
thanks to all of you. The first release is printed with many terms unexplained and even sentences are
shortened but intended to cover in this book. They will gradually be expanded in next release. Please
do write me on the email given in the pages below to improve.
Who is this book for?
Over the years I have seen the telecom industry struggling to get right people with sufficient domain
knowledge in 2G or 3G or 4G. The specification is very huge and it is often horrendous to go through
the details. This book is referring most of the time with respect to LTE 3GPP specification, Rel-10.
This is an effort to consolidate information in an organised way to give a methodical way of
understanding LTE. This is a very good start for an engineer who is either going to pursue:
 LTE Protocol Stack Development
 LTE ConformanceTesting
 LTE Network/RF Optimization
 LTE entities (UE and Network both) troubleshooting
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:
 LTE Physical Layer - (3PCA-L1)
 LTE L2 Layer - MAC, RLC, PDCP - (3PCA-L2)
 LTE RRC – (3PCA-RRC)
 LTE NAS – (3PCA-NAS)
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.
Edition: July 2013
Price: Rs.149

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

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

--------------------------------------------------------------------------------------------------------------------------------------
. .
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.
Fig 4.1.0 – Layer 2 Protocol Stack
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.
1.1.1. MAC Architecture
MAC layer is the lowest sub-layer in L2 architecture of LTE Protocol stack. The connection to PHY is
through transport channels, to RLC above is through logical channels. MAC performs (de)multiplexing
between logical and transport channels. MAC constructs PDUs, known as transport blocks (TB) from
SDUs received through logical channels, and receiving side recovers MAC SDUs through transport
channels.

--------------------------------------------------------------------------------------------------------------------------------------
. .
MAC consist of a Hybrid ARQ (HARQ), a (De)multiplexing, and a controller. Transmit HARQ includes
transmission and retransmission of TBs, and reception of ACK/NACK. Receive HARQ includes
reception of TBs, combining of received data and generation of ACK/NACK. To enable continuous
transmission while previous TBs are being decoded, up to eight HARQ processes in parallel (16 in
case of TDD) are used to support multi-process „Stop-And-Wait‟ (SAW) HARQ. SAW, after
transmission of TB, stops and awaits feedback from receiver. When NACK or nothing is received,
transmitter retransmits TB. To utilize resources continuously, multi-process HARQ interlaces several
independent SAW processes in time so that all transmission resources can be used by one of the
processes. Each HARQ process is independent of each other and is responsible for a separate SAW
operation and manages a separate buffer. Here is MAC architecture diagram:
Fig 4.1.1 – MAC Architecture
HARQ schemes may be synchronous or asynchronous, and adaptive or non-adaptive. In a
synchronous HARQ scheme, retransmission(s) for each process occur at predefined times relative to
the initial transmission, hence no need to signal HARQ process number, but can be inferred from
transmission timing. In asynchronous HARQ, the retransmissions can occur at any time, and HARQ
process number is sent to correctly associate each retransmission with the corresponding initial
transmission. Synchronous HARQ reduces signalling overhead while asynchronous HARQ increases
flexibility in scheduling.
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.
1.1.2. Logical Channels
MAC provides data transfer service for RLC through logical channels – Signalling Control Channels or
Traffic Channels.
Random
Access Control
PCCH BCCH CCCH DCCH DTCH MAC-control
Upper layers
PCH BCH DL-SCH UL-SCH RACH
Lower layer
(De-) Multiplexing
Logical Channel Prioritization (UL only)
Control
MCCH MTCH
MCH
De Multiplexing
HARQ
HARQ

--------------------------------------------------------------------------------------------------------------------------------------
. .
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.
1.1.3. Transport Channels
Data from MAC is exchanged with PHY through transport channels (TrCH) where data is multiplexed.
The logical channels which require same type of Physical layer treatment are grouped/multiplexed
into same type of TrCH.
Downlink transport channels.
1. Broadcast Channel (BCH). Used to transport parts of SI essential for access to DL-SCH.
2. Downlink Shared Channel (DL-SCH). Used to transport DL data or control and part of SI
(not sent by BCH).
3. Paging Channel (PCH). Used to transport paging, ETWS and change of SI to UEs.
4. Multicast Channel (MCH). Used to transport user data or control requiring MBSFN
combining.
Uplink transport channels.
1. Uplink Shared Channel (UL-SCH). Used to transport user data or control.
2. Random Access Channel (RACH). Used to access network when UE does not have
accurate UL timing synchronization, or when UE has no allocated UL transmission resource.
Fig 4.1.4 – Uplink Channel Mapping
1.1.4. Multiplexing and Mapping between Channels
In DL, DL-SCH carries all logical channels except PCCH. For MBMS, MTCH and MCCH can be
mapped to either DL-SCH(single cell MBMS) or MCH(Multiple cell MBMS).

--------------------------------------------------------------------------------------------------------------------------------------
. .
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.
1.1.6. HARQ Algorithms
1.1.7. DL HARQ Entity
1. One HARQ entity at UE for each Serving Cell with a number of parallel HARQ processes.
2. Each HARQ process has HARQ PID. HARQ entity directs HARQ info and TBs from DL-
SCH to HARQ PID.
3. There will be maximum 8 UL and 8DL HARQ PIDs for one HARQ entity. (15 for TDD).
4. When there is DL spatial multiplexing, one or two TBs are expected per subframe in
same HARQ process, Otherwise, one TB is expected per subframe.
5. For a DL assignment for a TTI:
1. allocate TBs and associated HARQ info to that specific HARQ PID.
6. For a DL assignment for broadcast HARQ process:
1. allocate TB to the broadcast HARQ PID(dedicated PID).
1.1.8. DL HARQ process
1. if NDI is logged; or HARQ PID=Broadcast PID ; or very first TB(no previous NDI): This is
new transmission.
2. else: Consider this transmission to be a retransmission.
3. if new transmission: replace the data in the soft buffer for this TB with the received
data.
4. else if this is a retransmission:
1. if the data has not yet been successfully decoded: combine with the soft buffer
for this TB if same size.
2. if the TB size is different from the last valid TB: replace the soft buffer with the
received data.
5. if the data in the soft buffer was successfully decoded for this TB:
1. if HARQ PID= broadcast process: deliver the decoded PDU to upper layers.
2. else if this is the first successful data in soft buffer for this TB:
1. deliver the decoded MAC PDU to the disassembly and demultiplexing
entity.
3. generate a (ACK) of the data in this TB.
6. else: generate a (NACK) of the data in this TB.

--------------------------------------------------------------------------------------------------------------------------------------
. .
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.
1.1.9. UL HARQ entity
1. One HARQ entity at UE for each Serving Cell with a number of parallel HARQ processes.
2. When there is UL spatial multiplexing, one or two TBs are expected per subframe in
same HARQ process, Otherwise, one TB is expected per subframe.
3. HARQ identifies HARQ process(es) of Tx, routes ACK/NACK, MCS and resource, to
appropriate HARQ process(es).
4. TTI_BUNDLE_SIZE provides number of TTIs of a TTI bundle. HARQ entity invokes the
same process for each tx of same bundle. Within a bundle MCS fixed and no waiting for
feedback for TTI_BUNDLE_SIZE. Feedback is only received for the last TTI of bundle.
5. For each TTI, the HARQ entity identifies HARQ process(es), and for each HARQ
process:
1. if an UL grant was from RAR for this process and this TTI:
1. obtain MAC PDU to transmit from Msg3 buffer or from "Multiplexing
and assembly"
2. deliver the PDU and the HARQ info to the identified HARQ process; &
Transmit
2. else:
1. deliver the uplink grant and the HARQ information (redundancy version)
to the identified HARQ process;
2. instruct the identified HARQ process to generate an adaptive
retransmission.
3. else, if the HARQ buffer of this HARQ process is not empty:
1. instruct the identified HARQ process to generate a non-adaptive
retransmission.
1.1.10. UL HARQ process
10. Each HARQ process is associated with a HARQ buffer, CURRENT_TX_NB(Tx taken
place), HARQ_FEEDBACK.
11. Redundancy variable CURRENT_IRV is module 4.
12. MCS of grant is indicated on PDCCH or Random Access Response and Adaptive
transmissions are performed.
13. maxHARQ-Tx and maxHARQ-Msg3Tx are for maximum retransmissions.
Retransmissions are Non-adaptive.
14. When HARQ feedback is received: set HARQ_FEEDBACK = received value.
15. If the HARQ entity requests a new transmission, the HARQ process shall:
1. CURRENT_TX_NB= 0; set CURRENT_IRV= 0; HARQ buffer= MAC PDU;
2. store UL grant; HARQ_FEEDBACK = NACK;
16. If retransmission requested by HARQ:
1. CURRENT_TX_NB++;
2. if the HARQ entity requests an adaptive retransmission:
1. store UL grant received from the HARQ entity;
2. CURRENT_IRV = as in the HARQ information;
3. HARQ_FEEDBACK= NACK; Re-transmit
3. else if the HARQ entity requests a non-adaptive retransmission:
1. if HARQ_FEEDBACK = NACK: generate a transmission as described
below.
17. To generate a transmission, the HARQ process shall:
1. Generate a transmission as per stored UL grant with RV= CURRENT_IRV value;
CURRENT_IRV++;
18. if CURRENT_TX_NB = maximum number of transmissions – 1: flush the HARQ buffer;

--------------------------------------------------------------------------------------------------------------------------------------
. .
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.
Fig 4.1.12 – Buffer Status Register
1.1.13. DL-SCH Assignment reception (on PDCCH)
1. When UE has C-RNTI, or Temp C-RNTI, UE monitors PDCCH each TTI for each SCell:
1. if DL assignment is received on the PDCCH for UE‟s C-RNTI, or Temporary C-RNTI:
Buffer SizeLCG ID Oct 1
Buffer Size #0
Buffer
Size #1
Buffer Size #1 Buffer Size #2
Buffer
Size #2
Buffer Size #3
Oct 1
Oct 2
Oct 3

--------------------------------------------------------------------------------------------------------------------------------------
. .
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;
3. For other SIB, k=i modulo 4, i =0,1,…, ns
w
–1, where i =subframe number
within SI window ns
w
;
2. indicate DL assignment and RV for dedicated broadcast HARQ process to HARQ
entity for this TTI.
1.1.14. Scheduling Request (SR)
1. SR is used for requesting UL-SCH for new transmission.
2. When SR is triggered, it is pending until it is cancelled.
3. when a MAC PDU is assembled, all pending SR(s) are cancelled and sr-ProhibitTimer is
stopped, when
3. MAC PDU includes a BSR(Buffer Status Report) up to event triggering BSR or
4. UL grant(s) sends all pending data.
4. SR_COUNTER=0, when new SR comes and no pending SR.
5. As long as any SR is pending, for each TTI:
5. if no UL-SCH resources are available for a transmission in this TTI:
1. If no valid PUCCH for SR in any TTI: initiate RA and cancel all pending
SRs;
2. else if UE has valid PUCCH for SR for this TTI and if sr-ProhibitTimer is
not running:
1. if SR_COUNTER < dsr-TransMax:
1. SR_COUNTER++;
2. signal the SR on PUCCH;
3. start the sr-ProhibitTimer.
2. else:
1. notify RRC to release PUCCH/SRS;
2. clear DL/UL grants;
3. initiate RA and cancel all pending SRs.
1.1.15. UL Grant reception
1. UE must have valid grant to transmit on UL-SCH (except HARQ ).
2. UE can receive grants (a)on the PDCCH or (b)RA Response.
3. With UL spatial multiplexing, MAC can receive two grants (one per HARQ process) for
the same TTI.
4. When UE has C-RNTI or Temp C-RNTI:- For each TTI & each Serving Cell and each
grant:
6. if UL grant for this TTI & Serving Cell is received on PDCCH for UE‟s C-RNTI or
Temporary C-RNTI; or
7. if UL grant for this TTI is received in RA Response:
1. consider NDI toggled & store/deliver UL grant/HARQ info to HARQ entity
for this TTI.
2. (re)initialise the configured UL grant to start in this TTI and to recur.

--------------------------------------------------------------------------------------------------------------------------------------
. .
3. deliver the UL grant and the associated HARQ information to the HARQ
entity for this TTI.
5. The period of configured uplink grants is expressed in TTIs.
1.1.16. Multiplexing and Scheduling
3. Scheduling Rules:
1. UE should not segment RLC SDU if the whole SDU fits into the remaining resources;
2. if UE segments an SDU from LoCH, maximize size to fill the grant as much as possible;
3. maximise the transmission of data.
4. UE gives following relative priority in decreasing order:
1. Control Element for C-RNTI or data from UL-CCCH;
2. Control element for BSR(without padding);
3. Control element for PHR or Extended PHR;
4. data from any Logical Channel, except UL-CCCH;
5. BSR included for padding.
5. UE Multiplexes MAC Control Elements and MAC SDUs from Priority unit.
1.1.17. Random Access (RA) Procedure in MAC
RA is used when UE doesn‟t have allocated RB grant but has data to transmit, or UE is not time-
synchronized.
1.1.18. Random Access Procedure initialization
1. RA is initiated by PDCCH order or MAC itself (masked with C-RNTI) in Pcell only.
2. Indicate ra-PreambleIndex and ra-PRACH-MaskIndex.
3. RA information required:
1. prach-ConfigIndex.
2. GroupA and GroupB Preambles:
1. group A Preambles - 0 to sizeOfRA-PreamblesGroupA – 1 and
2. group B Preambles - sizeOfRA-PreamblesGroupA to numberOfRA-
Preambles – 1 from 64 preambles.
3. messagePowerOffsetGroupB and messageSizeGroupA,
4. PCMAX, c (Configured UE Tx power of Serving Cell), and
5. deltaPreambleMsg3(the offset between the preamble and Msg3).
3. ra-ResponseWindowSize. powerRampingStep.
4. preambleTransMax. preambleInitialReceivedTargetPower.
5. DELTA_PREAMBLE(preamble format based offset )
6. maxHARQ-Msg3Tx(max Msg3 HARQ transmissions )
7. mac-ContentionResolutionTimer(Contention Resolution Timer )
4. The Random Access procedure shall be performed as follows:
1. Flush Msg3 buffer;
2. set PREAMBLE_TRANSMISSION_COUNTER =1;
3. set backoff parameter = 0 ms;
4. Select Random Access Resource.
5. Only one RA process at a time. If another request comes in parallel, UE can
ignore or start afresh.
1.1.19. RA Resource selection
5. If ra-PreambleIndex and ra-PRACH-MaskIndex have been explicitly signalled, use
them and skip internal selection.
6. If RA Preamble not signalled, then select as follows(Internal Selection):
1. If Msg3 not yet transmitted:
1. if (group B exists & msg size > messageSizeGroupA & pathloss <
(PCMAX,c – (preambleInitialReceivedTargetPower
+deltaPreambleMsg3 +messagePowerOffsetGroupB))
1. Select group B(Allows bigger size);
2. else: select group A.

--------------------------------------------------------------------------------------------------------------------------------------
. .
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.
1.1.20. MAC PDU (Random Access Response)
1. A MAC PDU consists of header +MAC RAR.
2. The MAC header is of variable size.
3. A MAC header may have many subheaders, one for each RAR except for Backoff Indicator
subheader.
4. If BI included, only once and the very first subheader.
5. RAR subheader fields - E/T/RAPID; BI subheader field - E/T/R/R/BI.
6. MAC RAR Response field details.
1. E(Extension,1bit)-If E="1" Another set of E/T/RAPID fields follows. If E="0“ next byte
RAR/padding;
2. R(Reserved bit)="0".
3. T: T=0 BI subheader, T=1 RAPID subheader.
4. BI(Backoff Indicator, 4bits)- Overload condition.
5. RAPID(Random Access Preamble Identitfier, 6bits)- Identifies transmitted RA Preamble.

--------------------------------------------------------------------------------------------------------------------------------------
. .
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.
1.1.21. Contention Resolution (C-RNTI on PDCCH or DL-
SCH)
1. start mac-ContentionResolutionTimer and mac-ContentionResolutionTimer at each
HARQ retransmission;
2. monitor the PDCCH until mac-ContentionResolutionTimer expires or stopped; When
PDCCH received:
3. When PDCCH received and if C-RNTI was included in Msg3:
1. If PDCCH is addressed to C-RNTI and contains UL grant(definite earlier
success)
1. Contention Resolution successful; stop mac-ContentionResolutionTimer;
2. discard Temporary C-RNTI; RA successfully completed.
4. else if CCCH SDU was included in Msg3 and PDCCH is addressed to Temporary C-
RNTI:
2. stop mac-ContentionResolutionTimer;
3. if received PDU has UE Contention Resolution Identity = CRI in CCCH SDU
transmitted in Msg3:
1. Contention Resolution successful; Disassembly and demultiplexing of the
MAC PDU continue;
2. Set C-RNTI = Temporary C-RNTI; discard Temporary C-RNTI; RA
Completed.
5. Else - discard the Temporary C-RNTI; Discard MAC PDU; Unsuccessful.
6. if mac-ContentionResolutionTimer expires: discard Temporary C-RNTI; Unsuccessful.
7. if Contention Resolution Unsuccessful
3. flush HARQ buffer in the Msg3;
PREAMBLE_TRANSMISSION_COUNTER++;
4. If PREAMBLE_TRANSMISSION_COUNTER = preambleTransMax + 1:
Inform Upper Layers.
5. Select a random backoff time; and delay RA retransmission.
6. proceed to the selection of a Random Access Resource.
8. Completion of the Random Access Successfully
4. Discard explicitly signalled ra-PreambleIndex and ra-PRACH-MaskIndex;
5. Flush HARQ buffer in the Msg3 buffer.
1.1.22. Uplink Timing Alignment (TA)
UL TA is managed by MAC, such that UL data arrives in eNodeB without overlapping with Tx from
other UEs. MAC uses Control Elements to update UL TA. When a UE is inactive for a certain period,
UE may be allowed to lose UL synchronization, even in RRC_CONNECTED. RA is then used to
regain UL synchronization when data transfer resumes.
1.1.23. Discontinuous Reception (DRX)
DRX functionality can be configured for „RRC_CONNECTED‟ UE so that it does not always need to
monitor DL channels. DRX cycle has „On Duration‟ (UE should monitor PDCCH) and „DRX period‟ or
„OFF period‟ (UE can skip DL reception). DRX Duration trade-off is between battery life and response-
time-latency.
To solve this, two DRX cycles – a short and a long cycle – can be configured for each UE. Transition
between cycle is controlled by Timer or commands from eNodeB. Short DRX cycle is like a
confirmation period. If data arrives during this period, then it goes for continuous reception and if not
then enters long DRX cycle.

--------------------------------------------------------------------------------------------------------------------------------------
. .
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.
Following table shows the meaning of each DRX parameters.
DRX Parameter Description
DRX Cycle
The duration of one 'ON time' + one 'OFF time'. This is calculated by the
subframe time and longdrx-CycleStartOffset)
onDurationTimer The duration of 'ON time' within one DRX cycle
drx-Inactivity timer
Specify how long UE should remain 'ON' after the reception of a PDCCH. When
this timer is on UE remains in 'ON state' which may extend UE ON period into the
period which is 'OFF' period otherwise. (See the figure for < case 2 > below)
drx-Retransmission
timer
Specifies the maximum number of consecutive PDCCH subframes the UE
should remain active to wait an incoming retransmission after the first available
retransmission time
shortDRX-Cycle
DRX cycle which can be implemented within the 'OFF' period of a long DRX
Cycle.(See the figure for < case 4 > below)
drxShortCycleTimer
The consecutive number of subframes the UE shall follow the short DRX cycle
after the DRX Inactivity Timer has expired(See the figure for < case 4 > below)
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).

--------------------------------------------------------------------------------------------------------------------------------------
. .
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.
1.1.24. Discontinuous Reception (DRX) Algorithm
1. UE is DRX configured, controlling UE‟s PDCCH monitoring for C-RNTI, TPC-PUCCH-
RNTI, TPC-PUSCH-RNTI.

--------------------------------------------------------------------------------------------------------------------------------------
. .
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.
1.1.25. In DRX UE action in each subframe:
1. if HARQ RTT Timer expires and data in HARQ process soft buffer could not decode:
5. start drx-RetransmissionTimer.
2. if DRX Command received: stop onDurationTimer & drx-InactivityTimer.
3. if drx-InactivityTimer expires or DRX Command received:
6. if Short DRX cycle configured: (re)start drxShortCycleTimer; use Short DRX
Cycle.
7. else: use Long DRX cycle.
4. if drxShortCycleTimer expires: use Long DRX cycle.
5. If Short DRX Cycle is used and [(SFN * 10) + subframe number] modulo (shortDRX-
Cycle) = (drxStartOffset) modulo (shortDRX-Cycle); or
6. if Long DRX Cycle is used and [(SFN * 10) + subframe number] modulo (longDRX-Cycle)
= drxStartOffset:
8. start onDurationTimer.
7. during Active Time, for PDCCH-subframe, if the subframe is not required for uplink
transmission for half-duplex FDD UE operation and if the subframe is not part of a
configured measurement gap:
9. monitor the PDCCH;
10. if PDCCH indicates/assigned a DL transmission, for that HARQ process:
1. start HARQ RTT Timer; stop drx-RetransmissionTimer .
11. if PDCCH indicates new transmission (DL or UL): (re)start drx-InactivityTimer.
8. when not in Active Time, type-0-triggered SRS and CQI/PMI/RI/PTI on PUCCH shall not
be reported.
9. if CQI masking (cqi-Mask) is setup: If onDurationTimer not running, CQI/PMI/RI/PTI on
PUCCH shall not be reported.
2. Regardless, UE receives and transmits HARQ feedback and transmits type-1-triggered SRS.
1.1.26. Multiplexing and Logical Channel Prioritization
In DL multiplexing and channel prioritization is done by eNodeB. For UL UE creates PDU using UL
grant and satisfying required QoS for each bearer. UE has to decide on amount of data for each
logical channel(LoCH) to be included in PDU, and, if necessary, include MAC Control Element.
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.

--------------------------------------------------------------------------------------------------------------------------------------
. .
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).
1.1.27. MAC Priritization algorithm
1. Logical Channel Prioritization is done in every new transmission.
2. RRC schedules each UL logical channel with:
1. Priority(0 highest)
2. prioritisedBitRate(PBR),
3. bucketSizeDuration (BSD).
4. Bj (maintained by UE) for each LoCH-j.
3. Bj - incremented by PBR(j) × TTI duration for each TTI; 0<= Bj <= Bucket Size.
4. bucket size(j) = PBR(j) × BSD;
5. UE allocates resources to LoCH with(Steps):
5. Allocate resource for all LoCH with Bj > 0. If PBR =“infinity”, allocate all available
resources before other lower priority;
6. Decrement Bj by sizeof(MAC SDU) served to LoCH(j) in Step 1
7. if any resources remain, other LoCH are served in decreasing priority order (regardless of
Bj) until data or grant for that LoCH is exhausted.
1.1.28. Activation/Deactivation of SCells
1. If UE has many SCells, NW may (de)activate SCells. The PCell is always activated.
2. Send Activation/Deactivation IE to do this.
3. Deactivates SCell upon expiry of sCellDeactivationTimer. Scells are initially( and at HO)
deactivated.
Fig 4.1.28 – Scell (De)Activation
4. For each Scell, for each TTI:
1. if UE receives Activation IE for SCell:
1. activate the Scell; (re)start sCellDeactivationTimer;
2. Start SRS/CQI/PMI/RI/PTI reporting for the SCell;
3. PDCCH monitoring on/for the SCell;
2. else, if UE receives Deactivation IE for SCell; or sCellDeactivationTimer expires:
1. deactivate the SCell; stop sCellDeactivationTimer;
2. flush HARQ buffers.
3. not transmit SRS/CQI/PMI/RI/PTI/UL-SCH for the SCell;
4. not monitor PDCCH on/for the SCell;
3. if PDCCH on SCell indicates an UL grant or DL assignment; restart
sCellDeactivationTimer.
5. Activation/Deactivation MAC Control Element(1 byte)
1. Seven Ci-fields and one R-field.
1. Ci: Indicates (de)activation status of Scell, if configured with SCellIndex i, else
ignore.
2. Ci ="1“/”0”  SCell with SCellIndex i shall be activated/deactivated.
3. R(Reserved bit)=“0”.
Oct 1C6C7 C5 C4 C3 C2 C1 R

--------------------------------------------------------------------------------------------------------------------------------------
. .
1.1.29. MAC Configuration and Reset
1. MAC reconfiguration
1. Upon addition/removal of an SCell, initialize/remove the corresponding HARQ entity;
2. Apply the new value when the timer is (re)started;
3. Apply the new maximum parameter value;
2. MAC Reset
1. initialize Bj=0 for each LoCH; Stop all timers;
2. Consider timeAlignmentTimer as expired;
3. For UL HARQ processes, NDI= 0;
4. Stop RACH;
5. discard ra-PreambleIndex and ra-PRACH-MaskIndex;
6. Flush Msg3 buffer; Flush DL HARQ soft buffers;
7. Cancel SRs, BSRs, PHRs;
8. For each DL HARQ process, consider new received TB as first one;
9. Release Temporary C-RNTI.
1.1.30. Power Headroom (PH) Reporting
1. PHR Reporting
1. SCell PH = nominal UE Max Tx Pwr – Est. UL-SCH Tx Pwr/ Serving Cell and
2. Pcell PH = UE maximum power –Est. UL-SCH and PUCCH Tx Pwr on PCell.
3. RRC controls PH reporting by
1. periodicPHR-Timer and prohibitPHR-Timer, and
2. dl-PathlossChange in DL pathloss to trigger PHR.
3. Trigger for Power Headroom Report (PHR):
4. prohibitPHR-Timer expires and path loss change > dl-PathlossChange dB for any Scell;
5. periodicPHR-Timer expires;
6. Uppler Layers configuration for PHR;
7. prohibitPHR-Timer expired & UE has UL resources for new Tx, and:
1. required power backoff change > dl-PathlossChange dB since last PHR Tx in
PUCCH.
8. Avoid triggering a PHR power backoff is only temporarily for just few 10ms.
2. Generation & Tx for PHR: If UE has UL resources for new Tx for this TTI:
1. If it is first Tx after last MAC reset, start periodicPHR-Timer;
2. if a (PHR element+subheader) can be accomodated:
3. if extendedPHR is configured:
1. for each activated Serving Cell, get (a) Type 1 PH (b) PCMAX,c ;
2. if simultaneousPUCCH-PUSCH is configured: (a)Type 2 PH for PCell;
3. Generate and transmit Extended PHR;
4. else: Get (a) Type 1 PH; & Generate and transmit a PHR;
5. (re)start periodicPHR-Timer; & prohibitPHR-Timer;
6. cancel all triggered PHR(s).
Reported value
Measured quantity value
(dB)
POWER_HEADROOM_0 -23  PH  -22
 
POWER_HEADROOM_59 36  PH  37
POWER_HEADROOM_63 PH ≥ 40

--------------------------------------------------------------------------------------------------------------------------------------
. .
Fig 4.1.31 – LCID codes in MAC PDU
1.1.31. MAC PDU Formats
After multiplexing, MAC PDU itself can be composed, which consists of MAC header and MAC
payload. Header is composed of MAC subheaders & payload is composed of MAC CE, SDUs and
padding. Each MAC subheader consists of a Logical Channel ID (LCID) and Length (L) field. LCID
indicates payload is Control Element, or LoCH, the SDU belongs. L indicates size of related MAC
SDU or MAC CE.
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:
1.1.32. RNTI Values and Usage
Value (hexa-decimal) RNTI
0000 N/A
0001-003C RA-RNTI, C-RNTI, Semi-Persistent Scheduling C-RNTI,
Temporary C-RNTI, TPC-PUCCH-RNTI and TPC-PUSCH-RNTI
(see note)
003D-FFF3 C-RNTI, Semi-Persistent Scheduling C-RNTI, Temporary C-RNTI,
TPC-PUCCH-RNTI and TPC-PUSCH-RNTI
FFF4-FFFC Reserved for future use
FFFD M-RNTI
FFFE P-RNTI
FFFF SI-RNTI

--------------------------------------------------------------------------------------------------------------------------------------
. .
RNTI Usage Transport
Channel
Logical
Channel
P-RNTI Paging and System Information change
notification
PCH PCCH
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
(when no valid C-RNTI is available)
DL-SCH CCCH
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
access
N/A N/A
SPS-C-RNTI Semi-Persistently scheduled unicast
transmission
(activation, reactivation and retransmission)
DL-SCH,
UL-SCH
DCCH, DTCH
SPS C-RNTI Semi-Persistently scheduled unicast
transmission
(deactivation)
N/A N/A
TPC-PUCCH-
RNTI
Physical layer Uplink power control N/A N/A
TPC-PUSCH-
RNTI
Physical layer Uplink power control N/A N/A

--------------------------------------------------------------------------------------------------------------------------------------
. .

--------------------------------------------------------------------------------------------------------------------------------------
. .
1.2. User Plane – RLC
1.2.1. RLC Introduction
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.
1.2.2. Radio Link Control (RLC) Architecture
RLC layer is located between PDCP („upper‟ layer) and MAC ( „lower‟ layer). It communicates with
PDCP through Service Access Point (SAP), and with MAC via logical channels. It reformats SDUs to
fit them into size indicated by MAC- Transmitter segments and/or concatenates SDUs, and receiver
reassembles PDUs to reconstruct PDCP PDUs. It reorders out of sequence PDUs due to MAC
HARQ. RLC SN and reception buffer are used for HARQ reordering and RLC-level ARQ.
Fig 4.2.2 – RLC Architecture
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.
1.2.3. Transparent Mode (TM) RLC Entity
TM RLC is transparent to PDUs that pass through it –no header addition and nothing is done. Only
RRC messages which do not need RLC can utilize TM RLC, such as SI, paging messages, and
messages when no SRB/DRB(except SRB0) is there. TM RLC is unidirectional and for UL and DL
separate RLC needed.
Oct 1
Oct N
TMD PDU Data
...

--------------------------------------------------------------------------------------------------------------------------------------
. .
Fig 4.2.3 – TM Mode RLC Architecture
1.2.4. Unacknowledged Mode (UM) RLC Entity
UM RLC is unidirectional and utilized by delay-sensitive, error-tolerant real-time applications,
especially VoIP, and other delay-sensitive streaming services, P-T-M MBMS. Main functions of UM
RLC are:
• Segmentation and concatenation of RLC SDUs;
• Reordering of RLC PDUs;
• Duplicate detection of RLC PDUs;
• Reassembly of RLC SDUs.
Fig 4.2.4 – UM Mode RLC Architecture
1.2.5. RLC data structure
1. Basics:
a. AM data transfer variables can take values from 0 to 1023. final value = [value]
modulo 1024.
b. UM data transfer variables can take values from 0 to [2
[sn-FieldLength]
– 1]. final value =
[value ] modulo 2
[sn-FieldLength]
).
c. SN cycling through the field: 0 to 1023 for AM and 0 to [2
[sn-FieldLength]
– 1] for UM.
d. VT(A) and VR(R) are the modulus base at the Tx and Rx side of an AM RLC entity.
e. (VR(UH) – UM_Window_Size) is the modulus base at the receiving side of an UM
RLC entity.
2. TX AM RLC Variables:

--------------------------------------------------------------------------------------------------------------------------------------
. .
a. VT(A) –ACK. SN of the next PDU for which ACK is to be received in-sequence -
lower edge of Tx window. Initially VT(A)=0, and updated whenever ACK received with
SN = VT(A).
b. VT(MS) – Maximum send. VT(MS)=VT(A) + AM_Window_Size, - higher edge of Tx
window.
c. VT(S) – Send. SN for next new PDU. Initially VT(S)=0, updated whenever RLC
delivers PDU with SN = VT(S).
d. POLL_SN – Poll send. VT(S)-1 upon latest TX of PDU with poll bit set to “1”. Initially
set to 0.
3. TX AM RLC counters:
a. PDU_WITHOUT_POLL –Initially 0. PDUs sent since the most recent poll bit
transmitted.
b. BYTE_WITHOUT_POLL – Initially 0. Bytes sent since the most recent poll bit
transmitted.
c. RETX_COUNT –no. of retransmissions of a PDU. One RETX_COUNT per PDU to be
retransmitted.
4. RX AM RLC variables:
a. VR(R) – Receive. SN following the last in-sequence received PDU, lower edge of
receiving window.
i. Initially 0. Updated when RLC receives PDU with SN = VR(R).
b. VR(MR) – Maximum receive SN. VR(MR)=(VR(R)+AM_Window_Size)=SN of first
PDU beyond receiving window -higher edge of the receiving window.
c. VR(X) – t-Reordering variable = SN following SN of PDU which triggered t-
Reordering.
d. VR(MS) – Maximum STATUS transmit(initially 0)- highest “ACK_SN” when STATUS
PDU is constructed.
e. VR(H) – Highest received(initially 0). highest SN among received PDUs plus 1.
5. TX UM RLC variables:
a. VT(US) - SN of next new PDU. Updated whenever RLC delivers PDU with SN =
VT(US).
6. RX UM RLC variables:
a. VR(UR) – UM received. Earliest PDU SN still considered for reordering.
b. VR(UX) – UM t-Reordering. SN of PDU which triggered t-Reordering plus 1.
c. VR(UH) – UM highest received. PDU with highest SN among received PDUs plus 1 -
higher edge of reordering window.
7. Constants
a. AM_Window_Size(=512) - RLC uses to calculate VT(MS) from VT(A), and VR(MR)
from VR(R).
b. UM_Window_Size – Defines SNs of receivable UM PDUs without causing
advancement of receiving window.
c. UM_Window_Size = 16 when a 5 bit SN; 512 when a 10 bit SN; 0 for MCCH or
MTCH.
8. Timers(Configured by RRC)
a. t-PollRetransmit – Tx AM RLC uses to retransmit a poll.
b. t-Reordering – Rx AM/UM RLC uses to detect loss of RLC PDUs at MAC.
c. t-StatusProhibit – Rx AM RLC uses to prohibit transmission of a STATUS PDU.
9. Configurable parameters
a. maxRetxThreshold – Tx AM RLC Max retransmissions.
b. pollPDU – Tx AM RLC triggers poll for every pollPDU PDUs.
c. pollByte – Tx AM RLC triggers poll for every pollByte bytes.
d. sn-FieldLength - UM SN field size in bits.
1.2.6. UM Segmentation and concatenation
Tx UM RLC segments and/or concatenates SDUs to form PDUs, size decided by MAC based on CQI
and resources available. Size of each PDU can be different, but order has to be maintained. Single
PDU can contain SDUs or segments of SDUs according to following pattern:
(zero or one) SDU segment + (zero or more) SDUs + (zero or one) SDU segment.

--------------------------------------------------------------------------------------------------------------------------------------
. .
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.
1.2.7. UM Reordering, duplicate detection, and reassembly
When Rx RLC receives PDUs, it first reorders as they may be OOS because of multiple HARQ.
PDUs will be in reception buffer until all previous PDUs are received and delivered to PDCP.
Any duplicate PDUs are detected by checking SN during reordering and discarded. Cause for
duplicates may be ACK was lost or misinterpreted. To avoid excessive reordering delays, a reordering
timer is started for missing PDU for a fixed delay. If this expires then declare that PDU as lost and
continue to reorder and deliver next SDU‟s from next PDUs.
Only SDUs for which all segments are available are reassembled from stored PDUs and delivered to
PDCP. SDUs where at least one segment is missing are simply discarded and not reassembled. If
SDUs were concatenated in an PDU, RLC separates them into original SDUs. RLC receiver delivers
reassembled SDUs to PDCP in increasing SN.
1.2.8. UM data transfer Algorithm
1. UM Transmit operations - When transmitting PDU to MAC: PDU SN = VT(US); and
VT(US)++.
2. UM Receive operations
1. General
1. SN falls within window if (VR(UH) – UM_Window_Size) <= SN < VR(UH);
2. On receiving PDU from MAC, RLC:
1. either discard PDU or place it in reception buffer;
1. update state variables, reassemble and deliver SDUs to
upper layer and
2. start/stop t-Reordering;
3. On expiry of t-Reordering
1. update state variables, reassemble and deliver SDUs to upper layer
and
2. start/stop t-Reordering;
2. Actions when an UMD PDU(SN=x) is received from lower layer
1. if VR(UR) < x < VR(UH) and x received before; or
2. if (VR(UH) – UM_Window_Size) <= x < VR(UR) {outside window}
1. discard the received UMD PDU;
3. else: place the received UMD PDU in the reception buffer.
UM Data Receive
1. Actions when an UMD PDU(SN=x) is placed in the reception buffer
1. if x falls outside of the reordering window:
1. VR(UH) = x + 1;
2. reassemble SDU, and deliver to upper layer in order of SN if not delivered
before;
3. if VR(UR) falls outside reordering window: set VR(UR) = (VR(UH)–
UM_Window_Size);
2. If SN = VR(UR):
1. VR(UR) =SN of first PDU with SN > current VR(UR) not yet received;
2. reassemble SDUs with SN < updated VR(UR), deliver to upper layer in order
of SN if not delivered before;
3. if t-Reordering is running:
1. if VR(UX) <= VR(UR); or VR(UX) falls outside of the reordering window
1. stop and reset t-Reordering;
4. if t-Reordering is not running
1. if VR(UH) > VR(UR): start t-Reordering; set VR(UX) to VR(UH).
2. Actions when t-Reordering expires
1. VR(UR) = SN of first PDU with SN >= VR(UX) not yet received;
2. reassemble SDUs with SN < updated VR(UR), deliver to upper layer in order of SN if
not delivered before;

--------------------------------------------------------------------------------------------------------------------------------------
. .
3. if VR(UH) > VR(UR): start t-Reordering; set VR(UX) to VR(UH).
1.2.9. Acknowledged Mode (AM) RLC Entity
AM RLC is bidirectional data transfer service and single AM RLC entity performs transmit and receive
– we refer as transmitting side and receiving side respectively.
Automatic Repeat reQuest (ARQ) is performed for error-free transmission corrected by
retransmissions for mainly error-sensitive and delay-tolerant non-real-time applications like browsing
and ftp, streaming. In control plane, RRC messages use AM RLC to ensure reliability.
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.
Fig 4.2.9 – AM Mode RLC Architecture
Main functions of AM RLC can be summarized as follows:
1. Segmentation and concatenation of RLC SDUs;
2. Reordering of RLC PDUs;
3. Duplicate detection of RLC PDUs;
4. Reassembly of RLC SDUs.
5. Retransmission of RLC Data PDUs;
6. Re-segmentation of retransmitted RLC Data PDUs;
7. Polling;
8. Status reporting;
9. Status prohibit.
The first 4 operations are same as UM RLC.
1.2.10. AM Retransmission and resegmentation
In order that Tx side retransmits only missing PDUs, Rx side provides „status report‟ to Tx side
indicating ACK/NACK for PDUs. Status reports are sent by Tx side of remote RLC whose Rx side
received corresponding RLC PDUs. To differentiate Data and Control PDUs, a 1-bit flag is included in
header.
When Tx transmits Data PDUs, it stores PDUs in retransmission buffer for possible retransmission if
requested by Rx through status report. In case of retransmission, Tx can resegment original Data
PDUs into smaller PDU segments if MAC indicates a size smaller than original PDU size.Aanother 1-

--------------------------------------------------------------------------------------------------------------------------------------
. .
bit re-segmentation flag is used in header to indicate resegmentation. The receiver can use status
reports to indicate the status of individual retransmitted segments, not just full PDUs.
1.2.11. AM Polling, status report and status prohibit
The Tx entity can request a status report from peer receiving side, by 1-bit polling indicator in header
& then use status reports to select PDUs to be retransmitted. When peer receiving side receives a
poll, it checks reception buffer status and transmits a status report at the earliest transmission
opportunity. The Rx side can also generate a status report of its own accord if it detects a reception
failure of PDU. Detection of a reception failure triggers a status report instead of considering PDUs as
permanently lost.
Status reports is carefully controlled & has trade-off between transmission delay and radio efficiency.
More status report means less transmission delay but wastes radio resources. If status reports are
sent whilst retransmissions triggered by a previous status report still going on, unnecessary
retransmissions may result more resource/time waste and may be causing more duplicates and
retransmission waste. Therefore, „status prohibit‟ function is available, whereby transmission of new
status reports is prohibited while a timer is running.
1.2.12. RLC PDU Formats
There are two types of PDU- RLC Data & Control PDU.
TM Data (TMD) PDU Format
TMD PDU has only data field and no headers. No segmentation/concatenation is done and SDU is
directly mapped to PDU.
UM Data (UMD) PDU Format
UMD PDU has data field and header. SDUs can be segmented and/or concatenated. PDU header
also has fixed part and extension part (only when data field contains multiple SDU segment.
1. Framing Info (FI)-2bit. Indicates whether first and last data field elements are complete
SDUs or partial SDUs.
2. Sequence Number (SN)-5 or 10 bit. SN allows Rx RLC entity unambiguously to identify
a UMD PDU, for reordering and duplicate-detection.
3. Length Indicator (LI)-11bit. Length of corresponding data field in PDU. There is one-to-
one correspondence between each LI and data field element, except for the last data field
element for which no LI fields as it can be deduced from PDU size.
AM Data (AMD) PDU Format
AMD formats are managed by the list of following variavles:
1. Data field - Max Data field size =max TB size – (MAC PDU header size +RLC PDU header
size).
2. Sequence Number (SN) field(5 or 10bits) - 10 bits for AMD. 5/10 bits for UMD.
3. Extension bit (E) field (1bit) –(”0”-data field follows; “1”-set(E,LI) follows) either from fixed
part or LI.
4. Length Indicator (LI) field (11bits) - PDU Data field element length in byte. First LI for first
data field and so on.
5. Framing Info (FI) field(2bits)- “00”-full SDU, “01”-first segment, “10”-last segment, “11”-
middle segment.
6. Segment Offset (SO) field(15bit) - the first byte position(in bytes) of PDU segment within
original PDU.
7. Last Segment Flag (LSF) field(1bit)-”0”-segment last byte is NOT last byte of PDU; “1”- last
segment of PDU.
8. Data/Control (D/C) field(1bit) – “0”-control; “1”-data
9. Re-segmentation Flag (RF) field(1bit) – “0”-PDU; “1”-PDU Segment
10. Polling bit (P) field(1bit) – “0”-Status not requested; “1”-Status Requested.
11. Reserved 1 (R1) field(1bit) – Reserved, set to 0, to be ignored.
12. Control PDU Type (CPT) field(3bits)- “000”-STATUS PDU, rest reserved.
13. Acknowledgement SN (ACK_SN) field(10bits) – All SN‟s received upto “ACK_SN-
1”(Except NACK_SN).
14. Extension bit 1 (E1) field(1bit)-”0”- NO more sets of(NACK_SN,E1,E2); ”1”-set of
(NACK_SN,E1,E2) follows.
15. Negative Acknowledgement SN (NACK_SN) field(10bits) – SN of the detected lost PDU at
receiving RLC.

--------------------------------------------------------------------------------------------------------------------------------------
. .
16. Extension bit 2 (E2) field(1bit) - Set of (SOstart, SOend) follows NACK_SN- “0”-No, “1”-yes.
17. SO start (SOstart) field(15bits)(with NACK_SN) - position of the first byte of PDU within
missing Data field.
18. SO end (SOend) field(15bits) - position of the last byte of PDU within missing Data field.
"111111111111111" indicates all bytes upto last missing.
AMD PDU Segment Format
Segment format is used in case of re-segmented retransmissions (available retransmission resource
is smaller than original PDU size). If RF indicates PDU is a segment, re-segmentation fields are
included in fixed part of header to enable correct reassembly:
1. Last Segment Flag (LSF) 1bit- Indicates whether this segment is the last segment of
PDU.
2. Segmentation Offset (SO) 15bits- Indicates starting position of the PDU segment
within original PDU.
Fig 4.2.12.1 – AMD PDU Format
AM STATUS PDU Format
Error ratio to data PDU should normally be low due to HARQ in MAC. Hence, STATUS PDU simply
lists all missing portions of AMD PDUs:
1. Control PDU Type (CPT) 3bits- Indicates type of Control PDU. Right now, STATUS
PDU is the only Control PDU defined.
2. ACK_SN 10bit- Indicates SN of the first PDU neither received nor listed in STATUS
PDU. All PDUs up to but not including this PDU are correctly received by receiver
except PDUs or portions of PDUs listed in NACK_SN List.
3. NACK_SN List. List of SNs of PDUs not completely received, optionally including
indicators of which bytes of PDU are missing in case of re-segmentation.

--------------------------------------------------------------------------------------------------------------------------------------
. .
Fig 4.2.12.2 – AMD status PDU format
1.2.13. RLC – ARQ Algorithm
1.2.14. AM Transmit operations
1. Prioritize (a)control PDUs over data PDUs, and prioritize (b)retransmission over (c)new
PDUs.
2. If VT(A) <= SN < VT(MS) then inside window else Outside. SN outside window will not be
transmitted.
3. SN =VT(S)++;
4. Receive ACK STATUS PDU (suppose for SN=x) from its peer AM RLC entity.
1. set VT(A) =SN of PDU with smallest SN,where VT(A) <= SN <= VT(S) and no ACK
yet.
2. if ACK received for all PDUs associated with a transmitted SDU: Indicate Success for
that SDU.
1.2.15. AM Receive operations
Receive operation of SN must qualify within window VR(R) <= SN < VR(MR)
1. Actions when a RLC data PDU(SN=x) is received from MAC
1. PDU contains byte segment y to z of an PDU with SN = x, RLC will:
1. if x falls outside of the receiving window; or x received before: discard PDU;
2. Else: place the received RLC data PDU in the reception buffer;
2. Actions when a RLC data PDU is placed in the reception buffer
1. if x >= VR(H) update VR(H) = x+ 1;
2. if all segments of PDU with SN = VR(MS) are received:
1. VR(MS)= SN of first PDU with SN > current VR(MS) for which all PDUs yet to
received;
3. if x = VR(R):
1. if all segments of PDU with SN = VR(R) are received:
1. VR(R)=SN of first PDU with SN > current VR(R) for which all PDUs
yet to received;
2. VR(MR) = VR(R) + AM_Window_Size;
2. reassemble SDUs from PDUs with SN falling outside window and in-
sequence PDU with SN = VR(R), and deliver SDUs to upper layer in
sequence if not delivered before;
4. if t-Reordering is running:
1. if VR(X) = VR(R); or (VR(X) falls outside window and VR(X) <>VR(MR)): stop
and reset t-Reordering;
5. if t-Reordering is not running & VR (H) > VR(R): start t-Reordering; set VR(X) to
VR(H).
3. Actions when t-Reordering expires
1. VR(MS)=SN of first PDU with SN >= VR(X) for which all PDUs yet to received;
2. if VR(H) > VR(MS): start t-Reordering; set VR(X) to VR(H).
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.

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

--------------------------------------------------------------------------------------------------------------------------------------
. .

--------------------------------------------------------------------------------------------------------------------------------------
. .
1.3. User Plane - PDCP
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.
Fig 4.3.0 – PDCP Architecture
1.3.1 PDCP - Functions and Architecture
PDCP performs the following functions:
 Header compression and decompression for user plane data.
 Security functions:
o ciphering and deciphering for user & control plane data;
o integrity protection and verification for control plane data.
 Handover support functions:
o in-sequence delivery and reordering of PDUs at handover;
o lossless handover for user plane data mapped on RLC-AM;
 Discard for user plane data due to timeout.
PDCP architecture differs for user plane data and control plane data.
PDCP Data PDUs and Control PDUs are defined separately. Data PDUs are used for both C-Plane
and U-Plane data. Control PDUs are only used for feedback of ROHC & status reports in handover
(within user plane).

--------------------------------------------------------------------------------------------------------------------------------------
. .
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.
Fig 4.3.2 – Header Compression concept
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.
1.3.4 Handover – Seamless and Lossless
Handover is performed when UE moves from one cell to another cell. Depending on QoS required, a
seamless or lossless handover is performed as appropriate for each bearer.

--------------------------------------------------------------------------------------------------------------------------------------
. .
Seamless Handover
Seamless handover is applied to all control plane SRB and RLC-UM DRB, which are reasonably
tolerant of losses but less tolerant of delay (VoIP). Seamless HO is designed to minimize complexity
and delay, but may loose some SDUs.
At HO, PDCP entities are reset. New key is anyway generated at HO, no reason to maintain COUNT.
PDCP SDUs not yet started in UE, will be transmitted after HO to target cell. In eNB untransmitted
PDCP SDUs can be forwarded via X2 to T-eNB. PDCP SDUs being processed but not been
successfully received will be lost. This minimizes complexity as no context is transferred between
S-eNB and T-eNB at handover.
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.
1.3.5 Discard of Data Packets
When data rate of a given service is higher than LTE radio interface, this leads to buffering in UE and
in eNB. This buffering allows some freedom to scheduler in MAC –vary instantaneous data rate at
physical layer to adapt to current radio channel conditions. This may seem as jitter to the application
in transfer delay.
When application data rate exceeds radio interface data rate for a long period, large buffered data can
result, which may lead to data loss at handover if lossless handover is not applied to the bearer, or
excessive delay for real time applications.
In fixed internet, sometimes router drops packets when apps data rate exceeds available rate in a part
of internet. Application may detect this loss and adapt data rate to the available data rate.
A discard function is included in PDCP to be able to drop packets like internet, based on a timer. Each
PDCP SDU received from higher layers in transmitter, a timer is started, and when transmission of
PDCP SDU has not yet been initiated in the UE at the expiry of this timer, PDCP SDU is discarded.
Discard mechanism can prevent excessive delay and queuing in transmitter.
1.3.6 PDCP PDU Formats
PDCP data PDUs for U-plane has „D/C‟ field to distinguish Data and Control PDUs. It has 7- or 12-bit
SN. U-plane data contain either uncompressed or a compressed IP packet.
PDCP data PDUs for C-plane (i.e. RRC signalling) has MAC-I field of 32-bit for integrity.Three types
of PDCP Data PDU, distinguished by SN length + MAC-I. PDCP Data PDU for U-plane data with long
SN allows longer interruption times, helps perform lossless handover, but implies higher overhead.
Therefore it is mainly used for data applications with a large IP packet size(ftp, browsing, email)
where overhead % is not too significant.

--------------------------------------------------------------------------------------------------------------------------------------
. .
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.
1.3.7 PDCP Variables
1. PDCP SDUs are byte aligned. A compressed or uncompressed SDU is included into
PDU.
2. Control plane PDCP Data PDU – carries data for control SRBs.
3. User plane PDCP Data PDU with long PDCP SN (12 bits) - Carryes DRB mapped data
on RLC AM/UM.
4. User plane PDCP Data PDU with short PDCP SN (7 bits)- carries DRB mapped data
on RLC UM.
5. PDCP Control PDU for interspersed ROHC feedback packet - carries one
interspersed ROHC feedback packet for DRBs mapped on RLC AM/UM.
6. PDCP Control PDU for PDCP status report- carries PDCP status report for DRBs
mapped on RLC AM.
7. RN user plane PDCP Data PDU with integrity protection - carrying DRB mapped data
on RLC AM or RLC UM.
Fig 4.3.7 – PDCP PDU Format
PDCP Parameters
 PDCP SN(5(SRB),7(DRB),or 12(DB) bits)- configured by pdcp_SN_Size
 Data(var length) - Uncompressed(U-plane,C-plane) or Compressed (U-plane) SDU
 MAC-I(32bits) - For C-plane data that are not integrity protected, the MAC-I field is still
present padded with 0s.
 COUNT(32bits)- COUNT (HFN and SN). Sizeof(HFN part)=32 minus –sizeof(SN).
Wraps around at 2
32
- 1 .
 R(1bit)- Reserved. Set to 0.
 D/C(1bit) – Data or Control
 PDU type(3bits)
 FMS(12bits)- SN of first missing SDU.
 Bitmap(Var) - First bit SN (FMS + 1) modulo 4096 and LSB of first octet  SN (FMS +
8) modulo 4096.
 Interspersed ROHC feedback packet(var)- Contains one ROHC packet with only
feedback, not associated with SDU.

State variables

--------------------------------------------------------------------------------------------------------------------------------------
. .
 Next_PDCP_TX_SN- Next PDU SN of a given PDCP entity. Initially
Next_PDCP_TX_SN =0.
 TX_HFN - HFN for generation of COUNT for Tx PDCP. Initially TX_HFN=0.
 Next_PDCP_RX_SN - next expected SN by Rx PDCP entity. Initially
Next_PDCP_RX_SN= 0.
 RX_HFN - HFN for generation of COUNT forRx PDCP. Initially RX_HFN = 0.
 Last_Submitted_PDCP_RX_SN - For DRBs mapped on RLC AM it indicates SN of last
SDU delivered. Initially Last_Submitted_PDCP_RX_SN =4095.
Timers
 discardTimer – Tx side, a new timer is started upon reception SDU from upper layer.
Constants
 Reordering_Window - The size equals to 2048 (half of SN space), for RB mapped on
RLC AM.
 Maximum_PDCP_SN is: 12 bit(4095), 7bit(127) or 5 bit(31).
1.3.8 PDCP Procedures
1. DL Data Transfer Procedures(for each SDU)
1. Start discardTimer with each received SDU (if configured);
2. associate PDCP SN = Next_PDCP_TX_SN;
3. Header compression of SDU (if configured);
4. Integrity protection, and ciphering using COUNT based on TX_HFN and PDCP SN;
5. Next_PDCP_TX_SN++;
6. if Next_PDCP_TX_SN > Maximum_PDCP_SN:
1. Next_PDCP_TX_SN=0; TX_HFN++;
7. submit the PDU to RLC.
2. DL RLC PDCP Receive for AM
1. Procedures for DRBs mapped on RLC AM
1. At reception of PDU(SN) from RLC:
2. Let SSN= Last_Submitted_PDCP_RX_SN, RW= Reordering_Window, RSN=
Next_PDCP_RX_SN
3. if (SN – SSN> RW) or (0 <= SSN–SN < RW): (Outside Window area)
1. if SN > RSN: decipher PDU, using COUNT based on RX_HFN - 1
and SN;
1. else: decipher PDU, using COUNT based on RX_HFN and
SN;
2. perform header decompression (if configured);
3. discard this SDU;
4. else if RSN– SN > RW: (Finished earlier round)
1. RX_HFN++;
2. Decipher PDU using COUNT based on RX_HFN and SN;
3. RSN=SN + 1;
5. else if (SN – RSN)>= RW, (SN of Prev round)
1. Decipher PDU using COUNT based on RX_HFN – 1 and SN;
6. else if SN >= RSN: (Normal Next)
2. RSN=SN + 1;
3. if RSN> Maximum_PDCP_SN: RSN =0; RX_HFN++;
7. else if SN < RSN: (Normal Earlier)
2. if PDU is not discarded in earlier process:
1. Perform deciphering and header decompression for PDU.
2. Store this SDU (Unless same SN is stored already, then discard this SDU).
3. if PDU is not received due to re-establishment of RLC:
1. In sequence, all stored SDU(s) with associated COUNT < COUNT
associated with received SDU;
2. Process stored SDU(s) with consecutively COUNT starting from
COUNT of received SDU;
3. SSN=SN of the last SDU delivered;.

--------------------------------------------------------------------------------------------------------------------------------------
. .
4. else if SN = SSN+ 1 or SN = SSN– Maximum_PDCP_SN:
1. deliver all stored SDU(s) with consecutively COUNT starting from
COUNT of received SDU;
2. SSN=SN of the last SDU delivered.
3. RN procedures for DRBs mapped on RLC AM
1. RN follows same procedure + Integrity verification.
2. On Integrity verification failure, discard Data PDU, and
1. Readjust RX_HFN, RSN and SSN, as if no reception.
3. DL RLC PDCP Receive DRB for UM
1. Procedures for DRBs mapped on RLC UM
1. if SN < RSN:
1. RX_HFN++;
2. else
1. decipher PDU using COUNT based on RX_HFN and SN;
2. RSN= SN + 1;
3. if RSN> Maximum_PDCP_SN: RSN=0; RX_HFN++;
4. perform header decompression of deciphered PDU;
5. deliver SDU to upper layer.
2. RN procedures for DRBs mapped on RLC UM
1. Follow same procedure + Integrity verification.
2. On Integrity verification failure:
1. discard PDU. Reset RX_HFN and RSN as if no SDU reception.
4. DL RLC PDCP Receive SRB
1. Procedures for SRBs received from Lower Layer
1. if SN < RSN:
1. decipher and integrity_check PDU using COUNT based on RX_HFN
+ 1 and SN;
2. else:
1. decipher and integrity_check PDU using COUNT based on RX_HFN
and SN;
3. if integrity_check pass or not applicable:
1. if SN < RSN: RX_HFN++;
2. RSN=SN + 1; if RSN > Maximum_PDCP_SN: RSN=0; RX_HFN++;
3. deliver SDU;
4. else, if integrity_check fails: discard PDU; Indicate failure.
UL Re-establishment
1. Re-establishment for DRBs mapped on RLC AM
1. Reset ROHC protocol for UL (if configured);
2. Apply ciphering; if RN, apply integrity_check;
3. From first un-ACKed SDU, (re)transmit SDUs(with SNs) in sequence of COUNT
prior to re-establishment :
1. perform ROHC of SDU;
2. perform ciphering using COUNT; if RN, perform integrity_check using
COUNT;
3. submit Data PDU to RLC.
2. Re-establishment for DRBs mapped on RLC UM
1. reset ROHC protocol for UL;
2. Next_PDCP_TX_SN = TX_HFN = 0;
3. perform ciphering using COUNT; if RN, perform integrity_check using COUNT;
4. for each SDU(with SN) not submitted to RLC:
1. consider SDUs as received from upper layer;
2. Transmit SDUs in order of COUNT prior to re-establishment, without
restarting discardTimer.
3. Re-establishment of for SRBs
1. Next_PDCP_TX_SN = TX_HFN = 0;
2. discard stored SDUs/PDUs;
3. apply ciphering and integrity_check.
DL Re-establishments
1. Re-establishment for DRBs mapped on RLC AM
1. Process PDUs from RLC due to re-establishment;

--------------------------------------------------------------------------------------------------------------------------------------
. .
2. Reset header compression protocol for UL;
2. Re-establishment for DRBs mapped on RLC UM
1. process the PDUs from RLC due to the re-establishment;
2. reset header compression protocol for UL;
3. RSN=RX_HFN=0;
3. Re-establishment for SRBs
1. Discard PDUs from RLC due to the re-establishment;
2. RSN=RX_HFN =0;
3. discard stored SDUs/PDUs;
4. Apply ciphering and integrity_check;
PDCP Status Report
1. Transmit operation
1. if RB is configured to send PDCP status report in UL (statusReportRequired),
1. compile a status report of PDUs received from RLC due to re-establishment,
and
2. submit it to RLC as first PDU, by:
1. setting FMS = SN of first missing SDU;
2. if out-of-sequence SDU stored, allocate a Bitmap(rounded to multiple
of 8) of SN stored.
3. Set „0‟=SNs not received or decompression failed; Set “1” for the
rest.
2. Receive operation
1. When PDCP status report is received in UL, RB of AM:
2. for each SDU, with (bit= '1„) or (COUNT <COUNT of FMS SDU), successful delivery
is confirmed.
3. PDCP discard
1. When discardTimer expires for SDU, or successful delivery is confirmed, discard
SDU.

--------------------------------------------------------------------------------------------------------------------------------------
. .

Lte protocol-stack-mac-rlc-pdcp

More Related Content

What's hot

Viewers also liked

Similar to Lte protocol-stack-mac-rlc-pdcp

More from Prashant Sengar

Recently uploaded

Lte protocol-stack-mac-rlc-pdcp