LTE Development, Conformance Test ...3gnets.in/files/documents/LTE-Protocol-Stack-MAC-RLC-PDCP.pdf · LTE Protocol Stack- 1 ... LTE Development, Conformance Test, OptimizationCertification

LTE Protocol Stack- 1 [email protected]

LTE Development, Conformance Test,

OptimizationCertification Course – Amateur Level

(3PCA-L1)

3PCA-L2

LTE

MAC-RLC-PDCP

LTE Protocol Stack

Author – Surya Patar Munda

[email protected] www.3gnets.in

----------------------------------------------------------------------------------------------------------------------------- ---------LTE Protocol Stack- www.3gnets.in email: [email protected] – 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

HARQHARQ


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 #0Buffer

Size #1

Buffer Size #1 Buffer Size #2

Buffer

Size #2Buffer 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 nsw;

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

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

Fig 4.3.0 – PDCP Architecture

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.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) 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++;

7. else if SN < RSN: (Normal Earlier) 1. Decipher PDU using COUNT based on RX_HFN and SN;

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; 3. Apply ciphering; if RN, apply integrity_check;

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; 4. Apply ciphering; if RN, apply integrity_check;

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.




Documents

LTE Development, Conformance Test ...3gnets.in/files/documents/LTE-Protocol-Stack-MAC-RLC-PDCP.pdf · LTE Protocol Stack- 1 ... LTE Development, Conformance Test, OptimizationCertification