Lte Protocol

(1)

LTE Development, Conformance Test,

OptimizationCertification Course

OptimizationCertification Course –

– Amateur Level

Amateur Level

3PCA-L2

LTE

MAC-RLC-PDCP

LTE Protocol Stack

Author

Author –

– Surya Patar Munda

Surya Patar Munda

www.3gnets.in

(2)

Preface:

Dedication

Dedication – – This book is dedicated to my family who has given me support to complete this book.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 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 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 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.

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

understanding LTE. This is a very good start for an engineer who is either going to pursue:



 _{LTE Protocol Stack Development}_{LTE Protocol Stack Development} 

 _{LTE ConformanceTesting}_{LTE ConformanceTesting} 

 _{LTE Network/RF Optimization}_{LTE Network/RF Optimization} 

 _{LTE entities (UE and Network both) troubleshooting}_{LTE entities (UE and Network both) troubleshooting}

If you need 3GNets

If you need 3GNets LTE L2 Layer for Amateur Level (3PCA-L2)LTE L2 Layer for Amateur Level (3PCA-L2), you need this course. This, you need this course. This knowledge and level is required for the

knowledge and level is required for the next level next level – – Professional Level (3PCP-L2) Professional Level (3PCP-L2) where you canwhere you can be trained for higher level with

be trained for higher level with Hands on Projects and real implementation. Hands on Projects and real implementation. Full Amateur levelFull Amateur level courses are:

courses are:



 _LTE_{LTE Physical}_{Physical Layer}_{Layer -}_- _(3PCA-L1)_(3PCA-L1) 

 _LTE_{LTE L2}_{L2 Layer}_{Layer -}_{- MAC,}_{MAC, RLC,}_{RLC, PDCP}_{PDCP -}_- _(3PCA-L2)_(3PCA-L2) 

 _{LTE RRC}_{LTE RRC –}_– _(3PCA-RRC)_(3PCA-RRC) 

 _{LTE NAS}_{LTE NAS –}_– _(3PCA-NAS)_(3PCA-NAS)

About Author:

Surya Patar Munda has been in Telecommunications Since 1987 and has gone through the life cycle 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, of Software Development, Software Testing, Network Deployments, Integration, Testing, Troubleshooting, Handphone Testing with Specification etc.. a full round of the Telecom industry. He 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 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 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.

the mindset of an RF optimization engineer. This book will cater to all. Author

Author also also conducted conducted many many trainings trainings for for Telecom Telecom industry industry and and has has a a very very good good understanding understanding ofof what kind of requirement is there for engineers. The goal is not just what and how does it work, but 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.

also the goal is how do I start implementing and how do I test.

Edition: July 2013

Price: Rs.149

(3)

Preface:

Dedication

Dedication – – This book is dedicated to my family who has given me support to complete this book.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 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 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 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.

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

understanding LTE. This is a very good start for an engineer who is either going to pursue:



 _{LTE Protocol Stack Development}_{LTE Protocol Stack Development} 

 _{LTE ConformanceTesting}_{LTE ConformanceTesting} 

 _{LTE Network/RF Optimization}_{LTE Network/RF Optimization} 

 _{LTE entities (UE and Network both) troubleshooting}_{LTE entities (UE and Network both) troubleshooting}

If you need 3GNets

If you need 3GNets LTE L2 Layer for Amateur Level (3PCA-L2)LTE L2 Layer for Amateur Level (3PCA-L2), you need this course. This, you need this course. This knowledge and level is required for the

knowledge and level is required for the next level next level – – Professional Level (3PCP-L2) Professional Level (3PCP-L2) where you canwhere you can be trained for higher level with

be trained for higher level with Hands on Projects and real implementation. Hands on Projects and real implementation. Full Amateur levelFull Amateur level courses are:

courses are:



 _LTE_{LTE Physical}_{Physical Layer}_{Layer -}_- _(3PCA-L1)_(3PCA-L1) 

 _LTE_{LTE L2}_{L2 Layer}_{Layer -}_{- MAC,}_{MAC, RLC,}_{RLC, PDCP}_{PDCP -}_- _(3PCA-L2)_(3PCA-L2) 

 _{LTE RRC}_{LTE RRC –}_– _(3PCA-RRC)_(3PCA-RRC) 

 _{LTE NAS}_{LTE NAS –}_– _(3PCA-NAS)_(3PCA-NAS)

About Author:

Surya Patar Munda has been in Telecommunications Since 1987 and has gone through the life cycle 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, of Software Development, Software Testing, Network Deployments, Integration, Testing, Troubleshooting, Handphone Testing with Specification etc.. a full round of the Telecom industry. He 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 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 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.

the mindset of an RF optimization engineer. This book will cater to all. Author

Author also also conducted conducted many many trainings trainings for for Telecom Telecom industry industry and and has has a a very very good good understanding understanding ofof what kind of requirement is there for engineers. The goal is not just what and how does it work, but 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.

also the goal is how do I start implementing and how do I test.

Edition: July 2013

Price: Rs.149

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

(7)

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

(8)

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

(9)

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.

(10)

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

(11)

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 Size

LCGID Oct1

Buffer Size #0 Buffer Size #1 Buffer Size #1 Buffer Size #2 Buffer

Size #2 Buffer Size #3

Oct 1 Oct 2 Oct 3

(12)

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 RV K = 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,…, nsw –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.

(13)

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

(14)

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_POW ER =

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.

(15)

6. R(Reserved bit)="0";

7. Timing Advance(TA,11bits) Command:- Index T A (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.

(16)

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 leas t „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).

(17)

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.

(18)

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

(19)

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.

Oct 1 C6

(20)

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_1 -22_PH_-21 POWER_HEADROOM_2 -21_PH_-20 POWER_HEADROOM_3 -20_PH_-19   POWER_HEADROOM_59 36_PH₃₇ POWER_HEADROOM_60 37_PH₃₈ POWER_HEADROOM_61 38_PH₃₉ POWER_HEADROOM_62 39_PH₄₀ POWER_HEADROOM_63 PH ≥ 40

(21)

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

(22)

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

(23)

(24)

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

(25)

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:

(26)

a. VT(A) – ACK. SN of the next PDU for which ACK is to be received insequence -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:

(27)

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 whent-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;

(28)

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

Lte Protocol

LTE Development, Conformance Test,

LTE Development, Conformance Test,

OptimizationCertification Course

OptimizationCertification Course –

– Amateur Level

Amateur Level

3PCA-L2

3PCA-L2

LTE

LTE

MAC-RLC-PDCP

MAC-RLC-PDCP

LTE Protocol Stack

LTE Protocol Stack

Author

Author –

– Surya Patar Munda

Surya Patar Munda

[email protected]

www.3gnets.in

[email protected]

www.3gnets.in

Preface:

Preface:

Who is this book for?

Who is this book for?

About Author:

About Author:

Edition: July 2013

Edition: July 2013

Price: Rs.149

Price: Rs.149

Preface:

Preface:

Who is this book for?

Who is this book for?

About Author:

About Author:

Edition: July 2013

Edition: July 2013

Price: Rs.149

Price: Rs.149

Contents

Contents

1.

Data Link Layer- L2

1.1. MAC

–

Medium Access Controller

1.1.1. MAC Architecture

1.1.2. Logical Channels

1.1.3. Transport Channels

1.1.4. Multiplexing and Mapping between Channels

1.1.5. Scheduling

1.1.6. HARQ Algorithms

1.1.7. DL HARQ Entity

1.1.8. DL HARQ process

1.1.9. UL HARQ entity

1.1.10. UL HARQ process

1.1.11. MAC Data Transfer

1.1.12. Scheduling Information Transfer

1.1.13. DL-SCH Assignment reception (on PDCCH)

1.1.14. Scheduling Request (SR)

1.1.15. UL Grant reception

1.1.16. Multiplexing and Scheduling

1.1.17. Random Access (RA) Procedure in MAC

1.1.18. Random Access Procedure initialization

1.1.19. RA Resource selection

1.1.20. MAC PDU (Random Access Response)

1.1.21. Contention Resolution (C-RNTI on PDCCH or

DL-SCH)

1.1.22. Uplink Timing Alignment (TA)

1.1.23. Discontinuous Reception (DRX)

1.1.24. Discontinuous Reception (DRX) Algorithm

1.1.25. In DRX UE action in each subframe:

1.1.26. Multiplexing and Logical Channel Prioritization

1.1.27. MAC Priritization algorithm

1.1.28. Activation/Deactivation of SCells

1.1.29. MAC Configuration and Reset