LTE Development, Conformance Test, OptimizationCertification Course – Amateur Level
LTE MAC-RLC-PDCP LTE Protocol Stack Author – Surya Patar Munda
[email protected] www.3gnets.in
3PCA-L2
LTE Protocol Stack- 1
[email protected]
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 LTE LTE LTE
Protocol Stack Development ConformanceTesting Network/RF Optimization entities (UE and Network both) troubleshooting
If you need 3GNets LTE L2 Layer for Amateur Level (3PCA-L2), (3PCA-L2) , you need this course. This knowledge and level is required for the next the next level – – Professional Level (3PCP-L2) where you can be trained for higher level with with Hands on Projects and real implementation. Full Amateur level courses are:
LTE Physical Layer LTE L2 Layer - MAC, RLC, PDCP LTE RRC – RRC – LTE NAS – NAS –
(3PCA-L1) (3PCA-L2) (3PCA-RRC) (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
-------------------------------- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- --------LTE Protocol Stack- www.3gnets.in email:
[email protected] [email protected] – – Page 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 LTE LTE LTE
Protocol Stack Development ConformanceTesting Network/RF Optimization entities (UE and Network both) troubleshooting
If you need 3GNets LTE L2 Layer for Amateur Level (3PCA-L2), (3PCA-L2) , you need this course. This knowledge and level is required for the next the next level – – Professional Level (3PCP-L2) where you can be trained for higher level with with Hands on Projects and real implementation. Full Amateur level courses are:
LTE Physical Layer LTE L2 Layer - MAC, RLC, PDCP LTE RRC – RRC – LTE NAS – NAS –
(3PCA-L1) (3PCA-L2) (3PCA-RRC) (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
-------------------------------- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- --------LTE Protocol Stack- www.3gnets.in email:
[email protected] [email protected] – – Page Page- 2 . .
Contents 1.
Data Link Layer- L2 ........................................................................ ......................................................................................................................... ................................................. 5 1.1.
MAC – 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 ( on PDCCH) ............................................................. ................................................................ ... 10
1.1.14.
Scheduling Request (SR) .......................................................... .............................................................................................. .................................... 11 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 12
1.1.20.
MAC PDU (Random ( Random Access Response) ......................................................... ....................................................................... .............. 13
1.1.21.
Contention Resolution (C-RNTI (C -RNTI on PDCCH or DL-SCH).............................................. DL- SCH).............................................. 14
1.1.22.
Uplink Timing T iming 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 Headr oom (PH) Reporting ................................................................................. 19
1.1.31.
MAC PDU Formats.......................................................................................... Formats........................................................................................................ .............. 20
1.1.32.
RNTI Values and Usage ........................................................... ............................................................................................... .................................... 20
1.2.
User Plane – Plane – RLC ................................................................................................................. 23
1.2.1.
RLC Introduction ........................................................... ........................................................................................................... ................................................ 23
1.2.2.
Radio Link L ink Control (RLC) ( RLC) Architecture ............................................................ .......................................................................... .............. 23
-------------------------------- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- --------LTE Protocol Stack- www.3gnets.in email:
[email protected] [email protected] – – Page Page- 3 . .
1.2.3.
Transparent Mode (TM) (T M) RLC RL C Entity Entit y ................................................................... .............................................................................. ........... 23
1.2.4.
Unacknowledged Mode (UM) RLC Entity ..................................................................... 24
1.2.5.
RLC data structure ........................................................................................................ ........................................................................................................ 24
1.2.6.
UM Segmentation S egmentation and concatenation co ncatenation ........................................................................... ........................................................................... 25
1.2.7.
UM Reordering, duplicate detection, and reassembly reassem bly .................................................. .................................................. 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 – 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 P lane - PDCP ............................................................................................................... ............................................................................................................... 33
1.3.1
PDCP - Functions and a nd Architecture Arc hitecture .............................................................................. .............................................................................. 33
1.3.2
Header Compression .................................................................................................... 34
1.3.3
Security .............................................................. ......................................................................................................................... ........................................................... 34
1.3.4
Handover – Handover – Seamless and Lossless ............................................................... ............................................................................. .............. 34
1.3.5
Discard of Data Packets ............................................................ ................................................................................................ .................................... 35
1.3.6
PDCP PDU Formats............................................................................. Formats...................................................................................................... ......................... 35
1.3.7
PDCP Variables ............................................................ ............................................................................................................ ................................................ 36
1.3.8
PDCP Procedures ......................................................................................................... ......................................................................................................... 37
-------------------------------- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- --------LTE Protocol Stack- www.3gnets.in email:
[email protected] [email protected] – – Page Page- 4 . .
1. Data Link Layer- L2 1.1. MAC – Medium Access Controller LTE Layer 2 user-plane protocol stack is composed of three sublayers – PDCP, RLC, MAC. LTE L2 protocol stack, acts as interface between wireless sources of packet data traffic and LTE PHY layer and helps L1 to be used efficiently for packet data traffic. The Packet Data Convergence Protocol (PDCP) layer: This layer processes RRC messages in control plane and IP packets in user plane. Main functions are header compression, security (integrity protection and ciphering), and support for reordering and retransmission during handover. There is one PDCP entity per radio bearer. The Radio Link Control (RLC) layer: Main functions of RLC are segmentation and reassembly packets in to adapt them to the size suitable for radio interface. For bearers which need error-free transmission, retransmission may be performed to recover packet losses. RLC reorders to compensate out-of-order reception due to HARQ in MAC. There is one RLC entity per radio bearer. The Medium Access Control (MAC) layer: MAC multiplexes data from different radio bearers. There is only one MAC entity per UE. MAC achieves negotiated QoS for each radio bearer, By deciding data quantity transmitted from each radio bearer and instructing RLC layer to provide size of packets. ForUL, UE reports Buffer Status Report to eNB, remaining data to be transmitted. Below figure shows the DL and UL L2 Protocol stack components.
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. ----------------------------------------------------------------------------------------------------------------------------- --------LTE Protocol Stack- www.3gnets.in email:
[email protected] – Page- 5 . .
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: Upper layers
PCCH
MCCH
MTCH
BCCH
CCCH DCCH
DTCH
MAC-control
Logical Channel Prioritization (UL only)
(De-) Multiplexing
De Multiplexing
Random Access Control
HARQ HARQ
PCH
MCH
BCH DL-SCH UL-SCH
Control
RACH
Lower layer
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. ----------------------------------------------------------------------------------------------------------------------------- --------LTE Protocol Stack- www.3gnets.in email:
[email protected] – Page- 6 . .
Control logical channels. 1. Broadcast Control Channel (BCCH). DL channel used to broadcast SI with TM-RLC. 2. Paging Control Channel (PCCH). DL channel used to notify incoming call or SI change. 3. Common Control Channel (CCCH). DL/UL channel used to deliver control information during connection establishment with TM-RLC. 4. Multicast Control Channel (MCCH). DL channel used to transmit control information for MBMS services with UM-RLC. 5. Dedicated Control Channel (DCCH). DL/UL channel used to transmit dedicated control to a specific UE after connection establishment with AM-RLC. 6. Traffic logical channels. a. Dedicated Traffic Channel (DTCH). UL/DL channel used to transmit dedicated user data with either UM-RLC or AM-RLC. b. Multicast Traffic Channel (MTCH). DL channel used to transmit user data for MBMS services with UM-RLC.
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).
----------------------------------------------------------------------------------------------------------------------------- --------LTE Protocol Stack- www.3gnets.in email:
[email protected] – Page- 7 . .
In UL, UL-SCH carries all logical channels.
1.1.5. Scheduling eNodeB scheduler distributes available RB in one cell among the UEs, and among radio bearers of each UE, based respectively on the downlink data buffered in the eNodeB and on Buffer Status Reports (BSRs) received from the UE. eNodeB considers QoS requirements of each bearer, and selects MAC PDU size. Scheduling algorithm is left to eNodeB implementation, but scheduling signalling is standardized. Dynamic scheduling , is done by DL assignment and UL grant messages for allocation of DL/UL resources, valid for specific single subframes, transmitted on PDCCH using C-RNTI (to identify intended UE). Persistent scheduling enables RB to be semi-statically allocated to a UE for a longer time period than one subframe, avoiding DL assignment or UL grant on PDCCH for each subframe. This is used for VoIP kind of services where packets are small, periodic and semistatic in size. Overhead of PDCCH is reduced. For persistent scheduling, RRC indicates allocation interval at which RB are periodically assigned. RB allocations, modulation and coding are signalled by PDCCH. PDCCH messages timing is taken as relative reference. Semi-Persistent Scheduling C-RNTI (SPS-C-RNTI) is used to distinguish it from dynamic scheduling. Reconfiguration of RB used for persistent scheduling can be performed when UE moves between a silent to talk talk spurt, or when codec rate changes. New DL assignment or UL grant is transmitted to configure larger SPS RB for bigger VoIP packet.
1.1.6. HARQ Algorithms 1.1.7. DL HARQ Entity 1. 2. 3. 4. 5. 6.
One HARQ entity at UE for each Serving Cell with a number of parallel HARQ processes. Each HARQ process has HARQ PID. HARQ entity directs HARQ info and TBs from DLSCH to HARQ PID. There will be maximum 8 UL and 8DL HARQ PIDs for one HARQ entity. (15 for TDD). 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. For a DL assignment for a TTI: 1. allocate TBs and associated HARQ info to that specific HARQ PID. 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. 2. 3. 4.
5.
6.
if NDI is logged; or HARQ PID=Broadcast PID ; or very first TB(no previous NDI): This is new transmission. else: Consider this transmission to be a retransmission. if new transmission: replace the data in the soft buffer for this TB with the received data. 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. 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. else: generate a (NACK) of the data in this TB.
----------------------------------------------------------------------------------------------------------------------------- --------LTE Protocol Stack- www.3gnets.in email:
[email protected] – Page- 8 . .
7. 8. 9.
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. else: Generate ACK/NACK for this TB. 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. 2. 3. 4.
5.
One HARQ entity at UE for each Serving Cell with a number of parallel HARQ processes. 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. HARQ identifies HARQ process(es) of Tx, routes ACK/NACK, MCS and resource, to appropriate HARQ process(es). 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. 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;
----------------------------------------------------------------------------------------------------------------------------- --------LTE Protocol Stack- www.3gnets.in email:
[email protected] – Page- 9 . .
1.1.11. MAC Data Transfer 1.1.12. Scheduling Information Transfer Buffer Status Reports (BSRs) from UE to eNodeB are used to assist eNodeB‟s allocation of UL RB. BSR indicates the pending data to be sent. Thus eNB knows the RB requirements for both directions. Two types of BSR: long BSR and short BSR; Logical channels are divided into 4 Logical Channel Groups (LCG). Short BSR conveys pending data for one group and long BSR conveys for 4 groups. A BSR can be triggered in following situations: 1. Higher priority logical channels Data arrives compared to previous logical channel priority, whise data BSR contained. 2. Prdefined time has elapsed since last BSR transmission; 3. Serving cell changes. If UE doesn‟t have enough UL -SCH resources to send BSR, either single bit „Scheduling Request‟ (SR) is sent on PUCCH or RACH is performed to get UL grant for sending BSR. Thus eNodeB always has information about data waiting in each UE‟s UL buffer grant RB appropriately. 1. BSR reports how much UL pending data is there with UE to serving eNB. 2. Maintain periodicBSR-Timer and retxBSR-Timer for each logical channel, also logicalChannelGroup. 3. When is a BSR triggered? 1. UL data, for LoCH of a LCG, becomes RTS(Ready to send) in RLC or PDCP entity. “Regular BSR”. 2. UL resources allocated and if (padding bits >= sizeof(BSR)+subheader), pad "Padding BSR"; 3. retxBSR-Timer expires and the data is ready for LoCH of LCG, send "Regular BSR"; 4. periodicBSR-Timer expires, send "Periodic BSR". 4. Long or Short BSR? 1. if more than one LCG‟ BSR need to be sent in a TTI: report Long BSR; else report Short BSR. 2. If (sizeof(long BSR)+subheader>=padding bits >= sizeof(BSR)+subheader): report short BSR. 3. else report Long BSR. 5. If at least one BSR is triggered: Whenever new data is sent on UL-SCH, or UL-SCH is granted 1. generate the BSR MAC control element(s); 2. start or restart periodicBSR-Timer and retxBSR-Timer . 6. All triggered BSRs shall be cancelled if all pending data is sent. 7. At most one Regular/Periodic BSR per TTI per LoCH. But, padding BSR can be every PDU. 8. Buffer Status Report MAC Control Elements 1. Two types of BSR(Identified by subheader LC(G)ID): 1. Short BSR and Truncated BSR format: one LCG ID and Buffer Size field; or 2. Long BSR format: Four LCG ID and Buffer Size fields. 2. LCG ID(2bits): Group of logical channel(s). 3. Buffer Size(6bit index): Total data across all LoCH group(including RLC/PDCP data excluding headers) after MAC PDUs for the TTI are built. One of the tables is used based on extendedBSR-Sizes = true or false. Buffer Size #0 LCG ID
Buffer Size
Oct 1
Buffer Size #1 Buffer Size #2
Buffer Size #1 Buffer Size #2
Buffer Size #3
Oct 1 Oct 2 Oct 3
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:
----------------------------------------------------------------------------------------------------------------------------- --------LTE Protocol Stack- www.3gnets.in email:
[email protected] – Page- 10 . .
1.
2. 3.
2.
When 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. else, if Serving Cell=PCell and DL assignment is for PCell and no measurement gap in this TTI; and 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. the UE needs to read BCCH, the UE may, based on the scheduling information from RRC: 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 RV K = ceiling(3/2*k ) modulo 4, 2. For SIB1, k = (SFN/2) modulo 4, where SFN is the system frame number; w 3. For other SIB, k =i modulo 4, i =0,1,…, ns –1, where i =subframe number w within SI window ns ; 2. indicate DL assignment and RV for dedicated broadcast HARQ process to HARQ entity for this TTI.
1.1.14. Scheduling Request (SR) 1. 2. 3.
4. 5.
SR is used for requesting UL-SCH for new transmission. When SR is triggered, it is pending until it is cancelled. 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. SR_COUNTER=0, when new SR comes and no pending SR. 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. 2. 3. 4.
UE must have valid grant to transmit on UL-SCH (except HARQ ). UE can receive grants (a)on the PDCCH or (b)RA Response. With UL spatial multiplexing, MAC can receive two grants (one per HARQ process) for the same TTI. 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.
----------------------------------------------------------------------------------------------------------------------------- --------LTE Protocol Stack- www.3gnets.in email:
[email protected] – Page- 11 . .
3.
5.
deliver the UL grant and the associated HARQ information to the HARQ entity for this TTI. The period of configured uplink grants is expressed in TTIs.
1.1.16. Multiplexing and Scheduling 3.
4.
5.
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. 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. 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. 2. 3.
4.
RA is initiated by PDCCH order or MAC itself (masked with C-RNTI) in Pcell only. Indicate ra-PreambleIndex and ra-PRACH-MaskIndex . 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 numberOfRAPreambles – 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 ) 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. 6.
If ra-PreambleIndex and ra-PRACH-MaskIndex have been explicitly signalled, use them and skip internal selection. 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.
----------------------------------------------------------------------------------------------------------------------------- --------LTE Protocol Stack- www.3gnets.in email:
[email protected] – Page- 12 . .
2.
3.
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. Random Access Preamble transmission Parameters 1. set PREAMBLE_RECEIVED_TARGET_POW ER = preambleInitialReceivedTargetPower + DELTA_PREAMBLE + (PREAMBLE_TRANSMISSION_COUNTER – 1) * powerRampingStep; 2. transmit using selected PRACH (RA-RNTI, preamble index, PREAMBLE_RECEIVED_TARGET_POWER). 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 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. 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).
POWER_HEADROOM_0 POWER_HEADROOM_1 POWER_HEADROOM_2 POWER_HEADROOM_3
Measured quantity value (dB) -23 PH -22 -22 PH -21 -21 PH -20 -20 PH -19
POWER_HEADROOM_59
36 PH 37 37 PH 38 38 PH 39 39 PH 40 PH ≥ 40
Reported value
POWER_HEADROOM_60 POWER_HEADROOM_61 POWER_HEADROOM_62 POWER_HEADROOM_63
----------------------------------------------------------------------------------------------------------------------------- --------LTE Protocol Stack- www.3gnets.in email:
[email protected] – Page- 19 . .
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) 0000 0001-003C
003D-FFF3 FFF4-FFFC FFFD FFFE FFFF
RNTI N/A RA-RNTI, C-RNTI, Semi-Persistent Scheduling C-RNTI, Temporary C-RNTI, TPC-PUCCH-RNTI and TPC-PUSCH-RNTI (see note) C-RNTI, Semi-Persistent Scheduling C-RNTI, Temporary C-RNTI, TPC-PUCCH-RNTI and TPC-PUSCH-RNTI Reserved for future use M-RNTI P-RNTI SI-RNTI
----------------------------------------------------------------------------------------------------------------------------- --------LTE Protocol Stack- www.3gnets.in email:
[email protected] – Page- 20 . .
RNTI
Usage
Logical Channel PCCH
DL-SCH N/A DL-SCH DL-SCH
BCCH N/A N/A CCCH
Temp C-RNTI
Paging and System Information change notification Broadcast of System Information MCCH Information change notification Random Access Response Contention Resolution (when no valid C-RNTI is available) Msg3 transmission
Transport Channel PCH
P-RNTI
UL-SCH
C-RNTI C-RNTI
Dynamically scheduled unicast transmission Dynamically scheduled unicast transmission
UL-SCH DL-SCH
C-RNTI
Triggering of PDCCH ordered random access Semi-Persistently scheduled unicast transmission (activation, reactivation and retransmission) Semi-Persistently scheduled unicast transmission (deactivation) Physical layer Uplink power control
N/A
CCCH, DCCH, DTCH DCCH, DTCH CCCH, DCCH, DTCH N/A
Physical layer Uplink power control
SI-RNTI M-RNTI RA-RNTI Temp C-RNTI
SPS-C-RNTI
SPS C-RNTI
TPC-PUCCHRNTI TPC-PUSCHRNTI
DL-SCH, UL-SCH
DCCH, DTCH
N/A
N/A
N/A
N/A
N/A
N/A
----------------------------------------------------------------------------------------------------------------------------- --------LTE Protocol Stack- www.3gnets.in email:
[email protected] – Page- 21 . .
----------------------------------------------------------------------------------------------------------------------------- --------LTE Protocol Stack- www.3gnets.in email:
[email protected] – Page- 22 . .
1.2. User Plane – RLC 1.2.1. RLC Introduction LTE Layer 2 user-plane protocol stack is composed of three sublayers – PDCP, RLC, MAC. LTE L2 protocol stack, acts as interface between wireless sources of packet data traffic and LTE PHY layer and helps L1 to be used efficiently for packet data traffic. The Radio Link Control (RLC) layer: Main functions of RLC are segmentation and reassembly packets in to adapt them to the size suitable for radio interface. For bearers which need error-free transmission, retransmission may be performed to recover packet losses. RLC reorders to compensate out-of-order reception due to HARQ in MAC. There is one RLC entity per radio bearer. At Tx side, each layer receives a SDU from higher layer, and outputs PDU to the layer below. As an example, RLC receives PDCP PDUs as RLC SDUs. RLC creates RLC PDUs and provided to MAC as MAC SDUs. At Rx side, the process is reversed, each layer data is received as PDUs, processes and sent to higher layer as SDU. All PDUs, SDUs and headers by PDCP, RLC and MAC are byte aligned , meaning sometimes unused padding bits are needed as sacrifice to gain processing speed.
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.
TMD PDU Data
Oct 1
Oct N
----------------------------------------------------------------------------------------------------------------------------- --------LTE Protocol Stack- www.3gnets.in email:
[email protected] – Page- 23 . .
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.
2.
Basics: a. AM data transfer variables can take values from 0 to 1023. final value = [value] modulo 1024. [sn-FieldLength ] b. UM data transfer variables can take values from 0 to [2 – 1]. final value = [sn-FieldLength ] [value ] modulo 2 ). [sn-FieldLength ] c. SN cycling through the field: 0 to 1023 for AM and 0 to [2 – 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. TX AM RLC Variables:
----------------------------------------------------------------------------------------------------------------------------- --------LTE Protocol Stack- www.3gnets.in email:
[email protected] – Page- 24 . .
a.
3.
4.
5.
6.
7.
8.
9.
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. 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. 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 tReordering . 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. TX UM RLC variables: a. VT(US) - SN of next new PDU. Updated whenever RLC delivers PDU with SN = VT(US). 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. 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. 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. 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. ----------------------------------------------------------------------------------------------------------------------------- --------LTE Protocol Stack- www.3gnets.in email:
[email protected] – Page- 25 . .
After segmentation and/or concatenation of SDUs, RLC includes headers in PDU with sequence number, size and boundary of each included SDU or SDU segment. PDU is always byte-aligned and no padding.
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) = 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; ----------------------------------------------------------------------------------------------------------------------------- --------LTE Protocol Stack- www.3gnets.in email:
[email protected] – Page- 26 . .
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 perform s 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----------------------------------------------------------------------------------------------------------------------------- --------LTE Protocol Stack- www.3gnets.in email:
[email protected] – Page- 27 . .
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-toone 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_SN1”(Except N ACK_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. ----------------------------------------------------------------------------------------------------------------------------- --------LTE Protocol Stack- www.3gnets.in email:
[email protected] – Page- 28 . .
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.
----------------------------------------------------------------------------------------------------------------------------- --------LTE Protocol Stack- www.3gnets.in email:
[email protected] – Page- 29 . .
Fig 4.2.12.2 – AMD status PDU format
1.2.13. RLC – ARQ Algorithm 1.2.14. AM Transmit operations 1. 2. 3. 4.
Prioritize (a)control PDUs over data PDUs, and prioritize (b) retransmission over (c)new PDUs. If VT(A) 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) = 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 tPollRetransmit 3. Reception of a STATUS report 4. if STATUS ACK or NACK with SN=POLL_SN: If t-PollRetransmit is running: stop & reset. 5. Expiry of t-PollRetransmit 6. If Tx and Re-Tx buffer are empty OR Retransmitting UnAcked PDUs: Include P bit.
----------------------------------------------------------------------------------------------------------------------------- --------LTE Protocol Stack- www.3gnets.in email:
[email protected] – Page- 31 . .
----------------------------------------------------------------------------------------------------------------------------- --------LTE Protocol Stack- www.3gnets.in email:
[email protected] – Page- 32 . .
1.3. User Plane - PDCP LTE Layer 2 user-plane protocol stack is composed of three sublayers – PDCP, RLC, MAC. LTE L2 protocol stack, acts as interface between wireless sources of packet data traffic and LTE PHY layer and helps L1 to be used efficiently for packet data traffic. The Packet Data Convergence Protocol (PDCP) layer: This layer processes RRC messages in control plane and IP packets in user plane. Main functions are header compression, security (integrity protection and ciphering), and support for reordering and retransmission during handover. There is one PDCP entity per radio bearer. At Tx side, each layer receives a SDU from higher layer, and outputs PDU to the layer below. As an example, RLC receives PDCP PDUs as RLC SDUs. RLC creates RLC PDUs and provided to MAC as MAC SDUs. At Rx side, the process is reversed, each layer data is received as PDUs, processes and sent to higher layer as SDU.
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: ciphering and deciphering for user & control plane data; o integrity protection and verification for control plane data. o Handover support functions: in-sequence delivery and reordering of PDUs at handover; o lossless handover for user plane data mapped on RLC-AM; o 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).
----------------------------------------------------------------------------------------------------------------------------- --------LTE Protocol Stack- www.3gnets.in email:
[email protected] – Page- 33 . .
1.3.2 Header Compression RObust Header Compression (ROHC) protocol is very important in LTE, because there is no support for transport of voice via Circuit-Switched (CS) domain. To provide VoIP in PS domain close to CS services, it is necessary to compress IP/UDP/RTP header used for VoIP.
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. ----------------------------------------------------------------------------------------------------------------------------- --------LTE Protocol Stack- www.3gnets.in email:
[email protected] – Page- 34 . .
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. ----------------------------------------------------------------------------------------------------------------------------- --------LTE Protocol Stack- www.3gnets.in email:
[email protected] – Page- 35 . .
PDCP Data PDU for U-plane using short SN is mapped on RLC-UM for VoIP services, where seamless handover is used and retransmission not necessary. There are two types of PDCP Control PDU, distinguished by type field in header - Status Reports for lossless HO, or ROHC feedback. ROHC feedback carries exactly one ROHC feedback packet in one PDCP PDU. Status Report PDU for lossless HO is used to prevent retransmission of already-correctly-received SDUs, and to request retransmission of failed ones. Status report contains bitmap indicating what received and what not with First Missing SDU (FMS) as reference point.
1.3.7 PDCP Variables 1. 2. 3. 4. 5. 6. 7.
PDCP SDUs are byte aligned. A compressed or uncompressed SDU is included into PDU. Control plane PDCP Data PDU – carries data for control SRBs. User plane PDCP Data PDU with long PDCP SN (12 bits) - Carryes DRB mapped data on RLC AM/UM. User plane PDCP Data PDU with short PDCP SN (7 bits)- carries DRB mapped data on RLC UM. PDCP Control PDU for interspersed ROHC feedback packet - carries one interspersed ROHC feedback packet for DRBs mapped on RLC AM/UM. PDCP Control PDU for PDCP status report- carries PDCP status report for DRBs mapped on RLC AM. 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). 32 Wraps around at 2 - 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 ----------------------------------------------------------------------------------------------------------------------------- --------LTE Protocol Stack- www.3gnets.in email:
[email protected] – Page- 36 . .
Next_PDCP_TX_SNNext 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.
2.
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. 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 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;.
----------------------------------------------------------------------------------------------------------------------------- --------LTE Protocol Stack- www.3gnets.in email:
[email protected] – Page- 37 . .
4.
3.
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. 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. 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.
2.
3.
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. 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 . 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;
----------------------------------------------------------------------------------------------------------------------------- --------LTE Protocol Stack- www.3gnets.in email:
[email protected] – Page- 38 . .
2.
3.
2. Reset header compression protocol for UL; 3. Apply ciphering; if RN, apply integrity_check; 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; 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.
2.
3.
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. Receive operation 1. When PDCP status report is received in UL, RB of AM: 2. for each SDU, with (bit= '1„) or (COUNT
