Documente Academic
Documente Profesional
Documente Cultură
LTE
MAC-RLC-PDCP
LTE Protocol Stack
Author Surya Patar Munda
surya.patar@3gnets.in
www.3gnets.in
3PCA-L2
surya.patar@3gnets.in
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.
If you need 3GNets LTE L2 Layer for Amateur Level (3PCA-L2), you need this course. This
knowledge and level is required for the next level Professional Level (3PCP-L2) where you can
be trained for higher level with Hands on Projects and real implementation. Full Amateur level
courses are:
LTE Physical Layer LTE L2 Layer - MAC, RLC, PDCP LTE RRC
LTE 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.
Contents
1.
1.1.1.
1.1.2.
1.1.3.
1.1.4.
1.1.5.
Scheduling ....................................................................................................................... 8
1.1.6.
1.1.7.
1.1.8.
1.1.9.
1.1.10.
1.1.11.
1.1.12.
1.1.13.
1.1.14.
1.1.15.
1.1.16.
1.1.17.
1.1.18.
1.1.19.
1.1.20.
1.1.21.
1.1.22.
1.1.23.
1.1.24.
1.1.25.
1.1.26.
1.1.27.
1.1.28.
1.1.29.
1.1.30.
1.1.31.
1.1.32.
1.2.
1.2.1.
1.2.2.
1.2.3.
1.2.4.
1.2.5.
1.2.6.
1.2.7.
1.2.8.
1.2.9.
1.2.10.
1.2.11.
1.2.12.
1.2.13.
1.2.14.
1.2.15.
1.2.16.
Retransmission.............................................................................................................. 30
1.3.
1.3.1
1.3.2
1.3.3
Security ......................................................................................................................... 34
1.3.4
1.3.5
1.3.6
1.3.7
1.3.8
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
(De-) Multiplexing
De Multiplexing
HARQ
HARQ
PCH
MCH
Control
Random
Access Control
RACH
Lower layer
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.
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
1. if this is the first DL assignment for this Temporary C-RNTI: consider NDI is
toggled.
2. if DL assignment is for UEs C-RNTI, consider NDI toggled regardless of value of
the NDI.
3. deliver HARQ info to the HARQ entity for this TTI.
2. else, if Serving Cell=PCell and DL assignment is for PCell and no measurement gap in
this TTI; and
3. if this TTI is not MBSFN subframe or transmission mode =tm9 :
1. Receive TB on DL-SCH as per DL assignment and deliver it to HARQ entity;
2. set the HARQ Process ID to the HARQ Process ID associated with this TTI;
3. consider NDI toggled; deliver HARQ info to HARQ entity for this TTI.
2. When the UE needs to read BCCH, the UE may, based on the scheduling information from RRC:
1. BCCH can be read if DL assignment for this TTI for SI-RNTI is received on PDCCH of
PCell;
1. if the redundancy version is not defined in the PDCCH format:
1. Redundancy Version RVK = ceiling(3/2*k) modulo 4,
2. For SIB1, k = (SFN/2) modulo 4, where SFN is the system frame number;
w
3. For other SIB, k=i modulo 4, i =0,1,, ns 1, where i =subframe number
w
within SI window ns ;
2. indicate DL assignment and RV for dedicated broadcast HARQ process to HARQ
entity for this TTI.
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.
(preambleInitialReceivedTargetPower
+deltaPreambleMsg3 +messagePowerOffsetGroupB))
1. Select group B(Allows bigger size);
2. else: select group A.
----------------------------------------------------------------------------------------------------------------------------- --------LTE Protocol Stack- www.3gnets.in
email: surya.patar@3gnets.in Page- 12
.
.
6. R(Reserved bit)="0";
7. Timing Advance(TA,11bits) Command:- Index TA (0, 1, 2 1282) amount of timing
adjustment to apply.
8. UL Grant(20bits): Resources to be used on UL.
9. Temporary C-RNTI(16bits): Temporary identity of UE during Random Access.
10. Padding may be there at the end of the last RAR data field.
UE checks for messages (by its C-RNTI on PDCCH) during On Duration period of either long or
short DRX cycle depending on currently active cycle. When a message is received during On
Duration, UE starts an Inactivity Timer and monitors PDCCH in every subframe during Timer
running and UE is in a continuous reception mode. Whenever a message is received while Inactivity
Timer is running, restart the Inactivity Timer. Whenever it expires without getting message, UE moves
into short DRX cycle and starts a Short DRX cycle timer. Short DRX cycle may also be initiated by
MAC Control Element. When short DRX cycle timer expires, without message, UE moves into long
DRX cycle.
HARQ Round Trip Time (RTT) timer is defined for UE to sleep during HARQ RTT. When decoding
DL TB for one HARQ fails, UE can next retransmission TB after at least HARQ RTT subframes.
While HARQ RTT timer is running, UE does not need to monitor PDCCH. At HARQ RTT timer expiry,
UE resumes PDCCH reception.
Following table shows the meaning of each DRX parameters.
DRX Parameter
Description
The duration of one 'ON time' + one 'OFF time'. This is calculated by the
DRX Cycle
subframe time and longdrx-CycleStartOffset)
onDurationTimer
The duration of 'ON time' within one DRX cycle
Specify how long UE should remain 'ON' after the reception of a PDCCH. When
drx-Inactivity timer 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)
Specifies the maximum number of consecutive PDCCH subframes the UE
drx-Retransmission
should remain active to wait an incoming retransmission after the first available
timer
retransmission time
DRX cycle which can be implemented within the 'OFF' period of a long DRX
shortDRX-Cycle
Cycle.(See the figure for < case 4 > below)
The consecutive number of subframes the UE shall follow the short DRX cycle
drxShortCycleTimer
after the DRX Inactivity Timer has expired(See the figure for < case 4 > below)
Scenario 1: Only Long DRX Cycle is configured and No PDCCH is received during the cycle.
Scenario 2: Only Long DRX Cycle is configured and a PDCCH is received during a cycle (real 'ON
time' May get extended depending on DRX Inactivity Timer and when the PDCCH is recieved).
Scenario 3 : Only Long DRX Cycle is configured and a PDCCH and DRX Command MAC CE are
received during a cycle (real 'ON time' MAY get shorter depending on exactly when DRX Command
MAC CE is received).
Scenario 4 : Both Long DRX Cycle and Short DRX Cycle are configured and No PDCCH is received
during the cycle.
To avoid starvation, Prioritized Bit Rate (PBR) is configured by eNodeB for each LoCH. PBR is the
data rate of a LoCH before allocating any resource to a lower-priority LoCH.
Each LoCH is served in decreasing order of priority, data amount from each LOCH put into PDU is
corresponding to PBR, one by one for all. If there is still room left in PDU, each LoCH is served again
in decreasing order of priority. In this second round, each LoCH is served only if all higher priority
LoCH has no more to send.
MAC CE has higher priority than any other LoCH and in included first in PDU on priority, except in
one situation when UE transmits first RRC message after HO (BSR has lower priority than SRB,
completion of HO ASAP is more important).
C7
C6
C5
C4
C3
C2
C1
Oct 1
restart
Reported value
POWER_HEADROOM_0
POWER_HEADROOM_1
POWER_HEADROOM_2
POWER_HEADROOM_3
POWER_HEADROOM_59
POWER_HEADROOM_60
POWER_HEADROOM_61
POWER_HEADROOM_62
POWER_HEADROOM_63
36 PH 37
37 PH 38
38 PH 39
39 PH 40
PH 40
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
RNTI
Usage
P-RNTI
Temp C-RNTI
C-RNTI
C-RNTI
UL-SCH
DL-SCH
C-RNTI
N/A
SI-RNTI
M-RNTI
RA-RNTI
Temp C-RNTI
SPS-C-RNTI
SPS C-RNTI
TPC-PUCCHRNTI
TPC-PUSCHRNTI
Transport
Channel
PCH
Logical
Channel
PCCH
DL-SCH
N/A
DL-SCH
DL-SCH
BCCH
N/A
N/A
CCCH
UL-SCH
CCCH,
DCCH, DTCH
DCCH, DTCH
CCCH,
DCCH, DTCH
N/A
DL-SCH,
UL-SCH
DCCH, DTCH
N/A
N/A
N/A
N/A
N/A
N/A
Oct 1
Oct N
3.
4.
5.
6.
7.
8.
9.
a. VT(A) ACK. SN of the next PDU for which ACK is to be received in-sequence lower edge of Tx window. Initially VT(A)=0, and updated whenever ACK received with
SN = VT(A).
b. VT(MS) Maximum send. VT(MS)=VT(A) + AM_Window_Size, - higher edge of Tx
window.
c. VT(S) Send. SN for next new PDU. Initially VT(S)=0, updated whenever RLC
delivers PDU with SN = VT(S).
d. POLL_SN Poll send. VT(S)-1 upon latest TX of PDU with poll bit set to 1. Initially
set to 0.
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.
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.
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.
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.
1.2.16. Retransmission
Retransmission
1. Tx RLC receives NACK for PDU or portion of PDU by STATUS PDU from peer RLC. Then
2. if VT(A) <= SN < VT(S): consider for Retransmission.
----------------------------------------------------------------------------------------------------------------------------- --------LTE Protocol Stack- www.3gnets.in
email: surya.patar@3gnets.in Page- 30
.
.
3.
4.
5.
6.
7.
Polling - to trigger STATUS for Transmission of a AMD PDU or AMD PDU segment
1. Upon assembly and transmission of PDU:
1. PDU_WITHOUT_POLL++;
2. BYTE_WITHOUT_POLL += PDU data bytes.
3. if (PDU_WITHOUT_POLL >= pollPDU) or (BYTE_WITHOUT_POLL >= pollByte) include P bit.
1. Also check - if Tx buffer and (Re)Tx buffer becomes empty (excluding UnACKed) 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.
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.
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.
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.
State variables
----------------------------------------------------------------------------------------------------------------------------- --------LTE Protocol Stack- www.3gnets.in
email: surya.patar@3gnets.in Page- 36
.
.
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).
UL Re-establishment
1. Re-establishment for DRBs mapped on RLC AM
1. Reset ROHC protocol for UL (if configured);
2. Apply ciphering; if RN, apply integrity_check;
3. From first un-ACKed SDU, (re)transmit SDUs(with SNs) in sequence of COUNT
prior to re-establishment :
1. perform ROHC of SDU;
2. perform ciphering using COUNT; if RN, perform integrity_check using
COUNT;
3. submit Data PDU to RLC.
2. Re-establishment for DRBs mapped on RLC UM
1. reset ROHC protocol for UL;
2. Next_PDCP_TX_SN = TX_HFN = 0;
3. perform ciphering using COUNT; if RN, perform integrity_check using COUNT;
4. for each SDU(with SN) not submitted to RLC:
1. consider SDUs as received from upper layer;
2. Transmit SDUs in order of COUNT prior to re-establishment, without
restarting discardTimer.
3. Re-establishment of for SRBs
1. Next_PDCP_TX_SN = TX_HFN = 0;
2. discard stored SDUs/PDUs;
3. apply ciphering and integrity_check.
DL Re-establishments
1. Re-establishment for DRBs mapped on RLC AM
1. Process PDUs from RLC due to re-establishment;
----------------------------------------------------------------------------------------------------------------------------- --------LTE Protocol Stack- www.3gnets.in
email: surya.patar@3gnets.in Page- 38
.
.