LTE Air Int Sec04 190709 v02 PDF

The LTE Protocols Layer 2 MAC, RLC and PDCP
The LTE Protocols

Layer 2 MAC, RLC and PDCP
Informa Telecoms & Media
The LTE Protocols Layer 2 MAC,

RLC and PDCP
Introduction to The LTE Layer 2 Protocols
Medium Access Layer (MAC)
LTE Channels and Channel Mapping
LTE Logical channels
LTE Transport Channels
LTE Physical Channels
Channel Mapping
The MAC Protocol Data Unit (PDU)
Priority Handling
Hybrid-ARQ
Radio Link Control (RLC)
Transmission Modes of RLC
RLC Protocol Data Units
RLC Segmentation and Concatenation
Packet Data Control Protocol (PDCP)
PDCP Frame Formats
Encryption and Data Integrity
Robust Header Compression (ROHC)
Compression Efficiency
4
6
8
10
12
14
16
18
20
22
24
26
28
30
32
34
36
38
40
Introduction to The LTE Layer 2 Protocols

The layer 2 protocols of are shown in the figure opposite. There are 3 sub layers, MAC, RLC
andPDCP, all of these provide data transfer services to the user plane and control plane.
The Medium Access Control (MAC) protocol primary task is to map and multiplex the logical
and transport channels. Data flow priority handling from the RLC layer is also carried out in
theMAC layer.
The Radio Link Control (RLC) protocol is much like a standard OSI layer 2 datalink protocol,
itprovides data segmentation/re-assembly, ARQ services for the layers above. Data flows
fromthe RLC layer are mapped to logical channels for handling by the MAC layer.
The Packet Data Control Protocol (PDCP) supports header compression and security related
services for the radio and radio signalling bearers from the user plane and control plane.
Eachof the bearers corresponds to the flow of a specific type of information i.e. voice, video.
RRC is not strictly part of layer 2 in a data transfer sense but is of prime importance when
itcomes to the setup and management of radio resources that will be used by the user plane
and control plane for transferring Access Stratum and Non-Access Stratum messages.
Control plane
PDCP
Sys info
broadcast
ROHC
ciphering
ROHC
ciphering
Paging
ROHC
ciphering
RRC
RRC
User plane
Ciphering
integrity
Segm.
ARQ
Segm.
ARQ
Segm.
ARQ
BCCH
PCCH
Segm.
ARQ
LTE Layer 2
RLC
Radio bearers
Logical channels
MAC
Scheduling/priority handling
Multiplexing
HARQ
HARQ
HARQ
PHY
Transport channels
Channel
coding
Channel
coding
Channel
coding
Channel
coding
Channel
coding
Physical channels
Fig. 1 LTE Layer 2 Overview

Medium Access Layer (MAC)

The MAC layer supports the following functions;
mapping between logical channels and transport channels;

multiplexing of MAC SDUs from one or different logical channels onto transport blocks (TB)
to be delivered to the physical layer on transport channels;
de-multiplexing of MAC SDUs from one or different logical channels from transport blocks
(TB) delivered from the physical layer on transport channels;
scheduling information reporting;
error correction through HARQ;
priority handling between UEs by means of dynamic scheduling;
priority handling between logical channels of one UE;
Logical Channel prioritisation;
transport format selection
The actual implementation of these functions are dependant on whether they reside in the UE
or the eNB. Functions like the priority handling between UEs and transport format selection
arecarried out by the eNB only. Similarly scheduled information reporting is a UE only function.
Mapping between logical channels and

transport channels;
Multiplexing of MAC SDUs from one or
different logical channels onto transport
blocks (TB) to be delivered to the physical
layer on transport channels;
Demultiplexing of MAC SDUs from one
ordifferent logical channels from transport
blocks (TB) delivered from the physical
layer on transport channels;
Scheduling information reporting;
Error correction through HARQ;
Priority handling between UEs by means
ofdynamic scheduling;
Priority handling between logical channels
of one UE;
Logical Channel prioritisation;
Transport format selection
Fig. 2 MAC layer Functions (TS 36.321)

LTE Channels and Channel Mapping

Information, both signalling and user, is transmitted through the protocol stack and over air
using channels. There are 3 basic types of channel defined, Logical, Transport and Physical
channels. Each channel is defined by a set of functions or attributes which determines the
handling of the data over the radio interface.
Logical Channels
Logical Channels exist between the PDCP layer and MAC, they are principally defined by
thetype of information that they carry. There are logical channels that carry control data, and
logical channels that carry user traffic.
Transport Channels
Transport Channels exist between the MAC layer and the Physical Layer and are define the
manner in which the data will be transferred, i.e. the type of channel coding, whether the data
isprotected from errors, size of data packets, etc. The attributes of data transfer applied to
thedata in the transport channel is otherwise known as the transport format.
Physical Channels
Physical Channels are the actual implementation of the transport channels in the physical layer.
The only exist in the physical layer and depend on the physical layer characteristics, i.e. channel
bandwidth, FFT size, etc.
Traffic
channel
MAC
PHY
Control
channel
Logical channels
Defined by Type of information
i.e. traffic, control,
e.g. BCCH, PCCH,
CCCH, MCCH, DCCH
Transport channels
Defined by Transport attribute
i.e. channel coding,
CRC, interleaving,
size of radio data packets,
e.g. BCH, PCH, DL-SCH, MCH
Physical channels
Defined by actual physical layer
characteristics, bandwidth,
FFT size, e.g. PDSCH,
PDCCH, PMCH, PBCH
Fig. 3 LTE Channels

LTE Logical channels

There are two types of logical channel, control channels and traffic channels, they are
describedbelow.
Control Channels
Control channels are used for transfer of control plane information only. The control channels
offered by MAC are:
Broadcast Control Channel (BCCH)
A downlink channel for broadcasting system control information. Information broadcast
onthischannel is shared by all the users in the cell, the information broadcast relates to
theOperator identity, cell configuration, access information etc
Paging Control Channel (PCCH)
A downlink channel that transfers paging information. This channel is used when the network
does not know the location cell of the UE.
Common Control Channel (CCCH)
Channel for transmitting control information between UEs and network. This channel is used
forUEs having no RRC connection with the network. It would be used during the earliest
phases of communication establishment.
Multicast Control Channel (MCCH)
A point-to-multipoint downlink channel used for transmitting MBMS control information
fromthenetwork to the UE, for one or several MTCHs. This channel is only used by UEs that
receive MBMS.
Dedicated Control Channel (DCCH)
A point-to-point bi-directional channel that transmits dedicated control information between
aUE and the network. UEs having an RRC connection will exchange RRC and NAS signalling,
itshould be noted that application level signalling (SIP messages from the IMS) is not handled
by the DCCH.
Traffic Channels
Traffic channels are used for the transfer of user plane information only. The traffic channels
offered by MAC are:
Dedicated Traffic Channel (DTCH)
A Dedicated Traffic Channel (DTCH) is a point-to-point channel, dedicated to one UE, for
thetransfer of user information. The DTCH will also carry signalling from the application layers,
this may be SIP and RTSP signalling if the EPC supports IMS (IP Multimedia Subsystem)
Multicast Traffic Channel (MTCH)
A point-to-multipoint downlink channel for transmitting traffic data from the network to the UE.
This channel is only used by UEs that receive MBMS.
10
LTE Logical Channels
Logical Control Channels
Broadcast Control Channel (BCCH)

System Information Messages
Paging Control Channel (PCCH)
Paging Messages, UE Location
not known
Common Control Channel (CCCH)
Early communication, no RRC
connection
Logical Traffic Channels
Dedicated Traffic Channel (DTCH)

Point-Point bi-directional channel,
User data and application level
signalling (SIP)
Multicast Traffic Channel (MTCH)
Point-Multi-point channel supporting
data transfer for the MMBS service
Multicast Control Channel (MCCH)

Multicast control signalling
Dedicated Control Channel (DCCH)
Bi-Directional signalling, RRC
connection, RRC and NAS Signalling
Fig. 4 LTE Logical Channels

11

Transport channels are classified in to uplink and downlink channels and are described below.
Broadcast Channel (BCH)
The BCH has a fixed and pre-defined transport format largely defined by the requirement to
bebroadcast in the entire coverage area of the cell since the information carried by this channel
contains system information.
Downlink Shared Channel (DL-SCH)
This channel will carry downlink signalling and traffic and may have to be broadcast in the
entirecell, given the nature of the data in this channel it will also support for both dynamic
andsemi-static resource allocation with the option to support for UE discontinuous reception
(DRX) to enable UE power saving, Error control is supported in this channel by means of
HARQand dynamic link adaptation by varying the modulation, coding and transmit power.
Spectral efficiency can also be increased due to the possibility of using beamforming antenna
techniques. The channel also supports MBMS transmissions.
Paging Channel (PCH)
This channel is associated with the PCCH and will carry paging message to UEs not currently
connected to the network. The PCH supports discontinuous reception (DRX) to enable UE
power saving where the sleep cycle is indicated by the network to the UE. The PCH may also
have to be broadcast in the entire coverage area of the cell. The PCH is also mapped to
physical resources which can be used dynamically also for traffic/other control channels.
Multicast Channel (MCH)
The channel is associated with the multicast services from the upper layers and as such there
isa requirement to broadcast both control and user data over the entire coverage area of the
cell. It also support the Single Frequency Network as semi-static resource allocation
Uplink Shared Channel (UL-SCH)
The UL_SCH carries common and dedicated signalling as well as dedicated traffic information.
It supports the same features as the DL-SCH.
Random Access Channel (RACH)
The RACH is a very specific transport channel, it carries limited control information during the
very earliest stages of connection establishment. This a common uplink channel therefore there
is the risk of collisions during UE transmission.
12
Downlink Transport Channels
Broadcast Channel (BCH)

fixed, pre-defined transport format;
broadcast in the entire coverage area
of the cell.
Downlink Shared Channel (DL-SCH)
HARQ;
dynamic link adaptation by varying
the modulation, coding and transmit
power;
broadcast in the entire cell;
beamforming;
dynamic and semi-static resource
allocation;
UE discontinuous reception (DRX) to
enable UE power saving;
MBMS transmission.
Uplink Transport Channels
Uplink Shared Channel (UL-SCH)

beamforming
dynamic link adaptation by varying
the transmit power and potentially
modulation and coding;
HARQ;
dynamic and semi-static resource
allocation.
Random Access Channel (RACH)
limited control information;
collision risk;
Paging Channel (PCH)

UE discontinuous reception (DRX) to
enable UE power saving
of the cell;
mapped to physical resources which
can be used dynamically also for
traffic/other control channels.
Multicast Channel (MCH)
of the cell;
MBSFN combining of MBMS
transmission on multiple cells;
support for semi-static resource
allocation e.g. with a time frame of a
long cyclic
Fig. 5 LTE Transport Channels

13

The physical channels are the actual implementations of the transport channels on the radio
interface. They only exist within the physical layer and are highly dependant on the actual
capabilities of the physical layer itself.
The physical channels are:
Physical broadcast channel (PBCH)
The system information is transmitted cyclically within BCH transport block and mapped to
foursubframes over a 40 ms interval, there is minimal synchronisation from the UE perspective
since the 40 ms timing is blindly detected, i.e. there is no explicit signalling indicating 40 ms
timing. Each subframe is assumed to be self-decodable, i.e. the BCH can be decoded from
asingle reception, assuming sufficiently good channel conditions.
Physical control format indicator channel (PCFICH)
This channel informs the UE about the number of OFDM symbols used for the PDCCHs and
istransmitted in every subframe.
Physical downlink control channel (PDCCH)
This channel informs the UE about the resource allocation of PCH and DL-SCH, and Hybrid
ARQ information related to DL-SCH and also carries the uplink scheduling grant.
Physical Hybrid ARQ Indicator Channel (PHICH)
Carries Hybrid ARQ ACK/NAKs in response to uplink transmissions.
Physical downlink shared channel (PDSCH)
Carries the DL-SCH and PCH.
Physical multicast channel (PMCH)
Carries the MCH, Mulitcast/Broadcast information
Physical uplink control channel (PUCCH)
This channel carries uplink control information such as Hybrid ARQ ACK/NAKs in response
todownlink transmission, carries Scheduling Request (SR) and, CQI reports.
Physical uplink shared channel (PUSCH)
Carries the UL-SCH, user data and application level signalling
Physical random access channel (PRACH)
Carries the random access preamble sent by the UE to initiate and RRC connection.
There are also physical signals which are sent on the downlink but are not given any channel
designation, they include;
14
Reference signals one signal transmitted per downlink antenna port

Synchronisation signals primary and secondary synchronisation signals.
Downlink Physical Channels
Physical broadcast channel (PBCH)

BCH transport block is mapped to
four subframes within a 40 ms
blindly detected, there is no explicit
signalling indicating 40 ms timing;
the BCH can be decoded from a
single reception.
Physical control format indicator
channel (PCFICH)
Informs the UE about the number of
OFDM symbols used for the
PDCCHs;
Transmitted in every subframe.
Uplink Physical Channels
Physical uplink control channel

(PUCCH)
Carries Hybrid ARQ ACK/NAKs ;
Carries Scheduling Request (SR);
Carries CQI reports.
Physical uplink shared channel
(PUSCH)
Carries the UL-SCH.
Physical random access channel
(PRACH)
Carries the random access
preamble.
Physical downlink control channel

(PDCCH)
resource allocation of PCH and
DL-SCH, and Hybrid ARQ
information related to DL-SCH;
Carries the uplink scheduling grant.
Physical Hybrid ARQ Indicator
Channel (PHICH)
Carries Hybrid ARQ ACK/NAKs
Physical downlink shared channel
(PDSCH)
Carries the DL-SCH and PCH.
Physical multicast channel (PMCH)
Carries the MCH.
also for traffic/other control channels.
Fig. 6 LTE Physical Channels

15
Channel Mapping
The diagram opposite shows the possible mapping of channels between logical, transport
andphysical channels.
It can be noted that, whilst the logical channels carry specific types of information, they can
bemapped to common transport channels and in the case of the multicast control and traffic
channels different transport channels can be used to carry the data.
In the case of the BCCH logical channel, it will be noted that both the BCH and DL-SCH
maybeused to carry the system information. This depends on the type of system information
beingtransmitted. Critical system information messages such as those that carry scheduling
information and need to be transmitted on a regular basis are transmitted as a fixed format
message via the BCH and PBCH. Mapping system information to the DL_SCH allows some
flexibility and additional capacity for less time dependant information.
The RACH channel carries only the access preamble and has no instance above the MAC layer,
therefore the channel is not mapped to a logical channel. Once an RRC connection has been
granted the RACH is no longer used.
Some physical channels do not carry information above the physical layer therefore have no
transport channel equivalents. Examples include PUCCH, PDCCH, PCFICH, PHICH, these
carry information related to the coding of the physical blocks and HARQ mechanism.
16
Logical
PCCH
BCCH
CCCH
DCCH
DTCH
MCCH
MTCH
Transport
PCH
BCH
UL-SCH
DL-SCH
MCH
Physical
PUCCH PCFICH
PDCCH PHICH
RACH
PBCH
PUSCH
PDSCH
PMCH
PRACH
Fig. 7 Logical to Transport channel Mapping

17
The MAC Protocol Data Unit (PDU)

MAC layer control data and upper layer user information and signalling is carried over the
logicaland transport channels in a MAC PDU. The PDU consist of a MAC header, MAC control
elements and the Service Data Unit (SDU). The SDU contains the data from the upper layers.
The MAC Header contains the following information
R Reserved Bit
E Extension Field, this indicates if the presence of the LCID and L fields
F Format Field, this indicates the size of the Length Field, the field of set to 0 if the size
oftheMAC control field or MAC SDU is less than 128 bytes otherwise it is set to 1.
L Length Field, indicates the length of the MAC SDU or Control Field.
LCID Logical Channel Identity, this describes the logical channel instance i.e. CCCH or
thetypes of MAC control element.
The MAC control element contains additional control data depending on the reason for
thetransmission of the MAC PDU. It may contain any of the following information.
The LGID and Buffer size allow the MAC entity to report the current buffer sizes i.e. the
amountof data ready for transmission across logical channel groups
The MAC Layer can identify the current connection at the cell level by declaring the C-RNTI
(Cell Radio Network Temporary Identifier), this may also be used for contention resolution
during the access phase.
The UE-Contention Resolution ID may also be used during the access phase to resolve contention.
The Timing Advance Field indicates to the UE the value of timing advance to apply to the uplink
transmissions.
The Power Headroom field indicates the difference between the currently applied power control
level and the maximum power available.
18
MAC Header
MAC Control
Elements
R R E LCID F
MAC SDU
UL LCID Values
DL LCID Values
CCCH
CCCH
Identity of the logical channel Identity of the logical channel

Reserved
Reserved
Power Headroom Report
UE Contention Resolution ID
C-RNTI
Timing Advance
Short Buffer Status Report
DRX Command
Long Buffer Status Report
Padding
LGID
Buffer Size
C-RNTI
UE Contention Resolution ID
Timing Advance
Power Headroom
Padding
R Reserved
E Extension
LCID Logical Channel Identity
F Format of Length Field(1 = >128 bytes)
L Length of MAC PDU
Fig. 8 MAC Layer PDU Format

19
Priority Handling
The Mac layer is responsible for the scheduling of transmissions both UL and DL. This Scheduling
process is closely related to the QoS allocated to individual users or individual flows of data for
each user.
Priority handing, which is one of the main functions supported by the MAC layer, refers to the
process which selects packets from queues submitted for transmission by the underlying
layers. This process must take in to account the data waiting on the DTCH as well as signalling
information submitted on the DCCH. In addition to this ARQ or data repetition must also be
considered. The priority handling process if tightly coordinated with the H-ARQ mechanism also
supported by the MAC Layer.
On the network side the scheduling function must arbitrate between all uplink scheduling
requests from terminals that share the same UL-SCH and coordinate the transmission of data
on the downlink channels, DL-SCH.
On the side of the UE the MAC layer will blend flows from the terminal applications for uplink
transmission, and will prioritise its own uplink flows.
In addition to scheduling on the basis of traffic volumes and QoS requirements the scheduling
function may take into account the current condition of the radio environment. Measurements
reports from the UE will indicate the quality of the channel on a periodic or aperiodic basis.
Thereporting regime is controlled by the eNB (enhanced Node B). There are 3 types of Channel
Quality Indications (CQI)
Wideband type; providing CQI of entire system bandwidth of the cell

Multi-Band type; providing CQI of some subsets of system bandwidth of the cell
MIMO type; still under study by 3GPP
Reporting is carried out on the PUSCH when the UE has resources allocated otherwise the
PUCCH is used.
20
User 1
DTCH + DCCH
User 2
DTCH
User 3
DTCH + DCCH
MAC Layer
Priority Handling
Function
HARQ
to
PHY
layer
CQI Reporting to Assist the Scheduling

Process
Wideband type; providing CQI of entire system
bandwidth of the cell
Multi-Band type; providing CQI of some subsets of
system bandwidth of the cell
MIMO type; still under study by 3GPP
Fig. 9 MAC layer Priority Handling

21
Hybrid-ARQ
ARQ mechanisms use Cyclic Redundancy Checks (or similar) to detect errors present in
transmitted data, the detection of errors will trigger the re-transmission of the error block of data.
The difference with Hybrid-ARQ is that the receiver will buffer the errorred data blocks and combine
them with the retransmitted information to improve the overall effectiveness of the retransmission.
Common methods used are Chase combining where the retransmitted block is identical to the
original data and Incremental Redundancy where new parity bits are transmitted to further improve
the error correction capability of the channel.
The system used in LTE supports parallel processes, allowing the data flow to continue when one
of the processes becomes stuck with retransmissions.
HARQ in LTE relies on a single bit feedback mechanism to signal the need for a retransmission.
Retransmissions in the downlink are asynchronous and adaptive. The uplink is synchronous
meaning that retransmission can only be transmitted at certain predefined points during the
transmission of the subframes. This reduces the over head in the uplink direction.
The UL-SCH and DL-SCH both support HARQ. In the downlink direction the ACK/NACKs are
sent on the PUCCH and PUSCH. In the uplink direction the ACK/NACKs are sent on the PHICH
(Physical HARQ Indicator Channel).
In the event of HARQ failure, i.e. errors being passed to the RLC layer, it is possible that RLC will
run a basic ARQ system that will retransmit entire block of data. This will depend on the mode
of RLC operation. This process is sometimes referred to as outer ARQ.
22
Normal ARQ Operation

CRC
Data #2
CRC
Data #1
CRC
Data #1
x Discard
data
ARQ data #1
CRC
Data #1
Hybrid-ARQ Operation
CRC
Data #2
CRC
Data #1
CRC
Data #1
x Buffer
data
ARQ data #1
CRC
Data #1
CRC
CRC
Data #1
buffered
Data #1
combined
UL-SCH, DL-SCH support HARQ

1 Bit HARQ Field
Downlink
Asynchronous
ACK/NACK on PUCCH and PUSCH
Uplink
Synchronous
ACK/NACK on PHICH
Fig. 10 LTE HARQ
23
Radio Link Control (RLC)

The RLC layer is roughly equivalent to the OSI layer 2 Datalink protocols in that it provides the
means to transmit and receive frames of information in a reliable fashion, supporting sequencing
and error control functions. The overall functions provided by RLC are;
24
Transfer of upper layer PDUs supporting Acknowledged Mode (AM) or Un-acknowledged

Mode (UM);
Transparent Mode (TM) data transfer;
Error Correction through ARQ (CRC check provided by the physical layer, in other words
noCRC needed at RLC level);
Segmentation according to the size of the TB: only if an RLC SDU does not fit entirely
intothe TB then the RLC SDU is segmented into variable sized RLC PDUs, which do not
include any padding;
Re-segmentation of PDUs that need to be retransmitted: if a retransmitted PDU does not
fitentirely into the new TB used for retransmission then the RLC PDU is re-segmented;
The number of re-segmentations is not limited;
Concatenation of SDUs for the same radio bearer;
In-sequence delivery of upper layer PDUs except at HO;
Duplicate Detection;
Protocol error detection and recovery;
SDU discard;
Reset.
Transfer of upper layer PDUs supporting Acknowledged

Mode (AM) or Un-acknowledged Mode (UM);
Transparent Mode (TM) data transfer;
Error Correction through ARQ (CRC check provided by the
physical layer, in other words no CRC needed at RLC level);
Segmentation according to the size of the TB: only if an
RLC SDU does not fit entirely into the TB then the RLC
SDU is segmented into variable sized RLC PDUs, which
do not include any padding;
Re-segmentation of PDUs that need to be retransmitted: if a
retransmitted PDU does not fit entirely into the new TB used
for retransmission then the RLC PDU is re-segmented;
The number of re-segmentations is not limited;
Concatenation of SDUs for the same radio bearer;
In-sequence delivery of upper layer PDUs except at HO;
Duplicate Detection;
Protocol error detection and recovery;
SDU discard;
Reset.
Fig. 11 Functions of RLC

25
Transmission Modes of RLC

RLC is able to transmit data in 3 different modes.
Transparent Mode (TM) is the simplest mode of operation. This mode does not change any
aspect of the data being transmitted and s typically used for BCCH and PCCH logical channel data.
The data in these channels does not require sequencing, retransmission or acknowledgement, the
information is simply passed from the upper layers to the MAC layer.
Whilst the received data does not generate any explicit acknowledgements, Unacknowledged
Mode (UM) is able to detect mis-sequenced and lost packets. This is due to the presence of
the packet sequence number in the header of the header. Since RLC also supports the function
of segmentation, UM is also able to perform reassembly of packets. UM may be applied to any
dedicated or multicast logical channel depending on the type of QoS required.
Acknowledged Mode (AM) is the most complex mode of operation and provided the most
control over the data link. The principle service of AM is the ability of RLC to request the
retransmission of missing packets also know as ARQ (note; this is different to HARQ supported
by the MAC layer). The DTCH and DCCH are the only channels to benefit from the AM
operation. It should also be noted that RLC does not perform error checking . CRC processes
are performed by the physical layer and the majority of retransmission will be carried out by the
HARQ function, however HARQ function is able to report to the RLC, which may result in the
RLC AM requesting the retransmission of data.
26
UE
AM
UM
E-Node B
TM
TM
Lower Layers (MAC, PHY)
UM
AM
Lower Layers (MAC, PHY)
No Interaction with Data

PCCH, BCCH
Segmentation, Reassembly, Sequencing, DTCH, DCCH
Segmentation, Reassembly, Packet Retransmission, Sequencing, DTCH, DCCH
Fig. 12 RLC Layer Operating Modes

27
RLC Protocol Data Units

The RLC layer receives information from the upper layers (PDCP and RRC), it packs the
information in to an RLC PDU, applying the headers appropriate to the mode of operation.
In TM there are no headers applied to the data, hence the name Transparent Mode.
The UM PDU contains a 2 bit Framing Info field (FI), to indicate if the first and/or last byte of
thedata field is the first/or last byte of an RLC SDU. An extension bit (E) is present to indicate
the nature of the data following the sequence number in the header, specifically whether there
ismore header information. The E field may indicate a set of additional information fields namely
Eand Length Indicator (LI) fields. The Sequence Number (SN) is a 5 or 10 byte number that
isincremented for every new PDU transmitted, the SN ca n be use to identify lost and out of
sequence PDUs.
The AM PDU is contains complex and various information in the header depending on the type
of data and the extent of segmentation/concatenation taking place. The figure opposite shows
abasic (fixed) header including the Data/Control (D/C) bit, the Re-segmentation Flag (RF), a
polling bit (P), Framing Info (FI), Extension (E) and Sequence Number Field.
An optional set of headers may be included (indicated via the E bit) which contains E and
Length Indicator (LI) fields. The optional header is present if the data field contains more that
one element, i.e. more than one distinct piece of upper layer data.
28
a) The TM PDU
Data
...
Oct 1
Oct N
b) The UM PDU with 5 byte SN

FI
SN
Oct 1
Data
...
Oct 2
Oct N
FI Framing Indicator
E Extension
SN Sequence Number
c) The AM PDU, showing no LI

D/C
RF
FI
SN
Data
...
SN
Oct 1
Oct 2
Oct 3
Oct N
D/C Data/Control
RF Re-segmentation Flag
P Polling
FI Framing Info
E Extension
SN Sequence Number
Fig. 13
29
RLC Segmentation and Concatenation

RLC supports the segmentation of upper layer data (RLC SDU) which is too large to fit into
asingle RLC PDU or the current RLC PDU has too little space remaining.
Similarly, if the RLC SDUs are smaller than the current RLC PDU then multiple SDUs may
beconcatenated into a single PDU.
The size of the PDU will be determined by the underlying protocols, MAC and PHY and will
berelated to the modulation coding scheme currently being provide by the PHY. The layers
inthe protocol stack will communicate about the maximum size of the PDU.
In the example shown opposite the extension header will be present in the RLC header which
will contain the Length Indicator Field. The LI field will indicate the byte length of each of the
data field elements.
Where the entire data field contains only part of a single upper layer packet the RLC layer will
use a header known as the AM Segment Header, this contains additional information about
thesegment offset.
30
Segmentation
RLC
SDUs
Data
field
Concatenation
n+1
Header
n+2
Data field
Segmentation
n+3
Header
Data
field
LI Field points to Data field elements
Fig. 14 Segmentation and Concatenation

31
Packet Data Control Protocol (PDCP)

The main purpose of the PDCP is to provide a service of data reception and delivery to/from
thepeer PDCP entity and to allow the efficient and secure transmission of data from the upper
layers. The data delivery service is largely handled by the RLC layer however there are a few
additional functions that PDCP carries out, these functions are perhaps a little outside the
standard description of OSI layer 2 functions.
There are four basic areas of function
Layer 2 related functions; re-sequencing and duplicate detection of the data packets passed
between eNB during inter-eNB handovers, the PDCP sequence number enables this function
IP header compression and decompression, the IP/TCP/UDP/RTP headers can be compressed
to ensure maximum efficiency over the radio interface, Robust Header Compression (ROHC)
isthe method used in LTE.
Encryption of user data and signalling, any information from the user plane or control plane may
be subject to the encryption methods supported by the PDCP layer, this will include all NAS,
RRC, SIP RTCP etc types of signalling
Signalling message integrity, NAS and RRC signalling messages may be protected by message
integrity processing preventing undetected man-in-the-middle attacks.
32
User plane
EPC data from serving GW
ROHC
Control plane
NAS Signalling from MME
RRC Signalling from eNB
ROHC
Encryption
Data Radio Bearers

DRB
Integrity
processing
Encryption
Signalling Radio Bearers

SRB
User Plane Functions

Header compression and decompression: ROHC only;
Transfer of user data: transmission of user data means
that PDCP receives PDCP SDU from the NAS and
forwards it to the RLC layer and vice versa;
In-sequence delivery of upper layer PDUs at handover
forRLC AM;
Duplicate detection of lower layer SDUs at handover
forRLC AM;
Retransmission of PDCP SDUs at handover for RLC AM;
Ciphering;
Timer-based SDU discard in uplink.
Control Plane Functions

Ciphering and Integrity Protection;
Transfer of control plane data: transmission of control
plane data means that PDCP receives PDCP SDUs from
RRC and forwards it to the RLC layer and vice versa.
Fig. 15 Basic Model of PDCP Functions
33
PDCP Frame Formats

The header format used depends on the source of the upper layer data.
Control plane information from RRC is mapped to the signalling radio bearers and the header
includes a PDCP sequence number an the MAC-I (Message Authentication Code Integrity).
User plane headers do not carry the integrity data but maintain the sequence number. An additional
field Data/Control (D/C) allow the PDCP to send control information on the Data Radio Bearers.
This control data is related to the ROHC feedback mechanism.
The sequence number is used to ensure I order delivery to the upper layers and will perform data
reordering after handover.
There is also header format for reporting PDCP status, used to indicate missing data via a bit map
field and a FMS (First Missing SDU) Field.
34
a) Control Plane PDCP Header Format

forSRB (Signalling Radio Bearers)
R
PDCP sequence number

Data
...
MAC-I
MAC-I (cont.)
MAC-I (cont.)
MAC-I (cont.)
Oct 1
Oct 2
Oct N-3
Oct N-2
Oct N-1
Oct N
R Reserved
MAC-I Message Authentication Code Integrity
b) User Plane PDCP Header Format

orDRB(Data Radio Bearers)
D/C
R
R
PDCP sequence number
PDCP sequence number (cont.)
Data
...
Oct 1
Oct 2
Oct 3
D/C Data/Control; the control data is ROHC Feedback
Fig. 16
35
Encryption and Data Integrity

It is the PDCP that ensures security for the user across the radio interface. The information
inthe user plane, including upper layer signalling, will be protected from eavesdropping by
thebitwise exclusive OR operation on the user data with a cipher key stream generated by
acomputational process defined within the encryption function of the PDCP layer. The key
exchange and generation functions are controlled by the RRC layer and passed to the PDCP
layer prior to encryption being activated.
Data integrity defines the process of generating a unique signature based on the contents of
thedata field. The signature is carried in the PDCP header as a MAC I (Message Authentication
Code). Signature checking or verification at the receiving side will detect any changes to the
data field, possibly due to a man in the middle attack, the packet may be discarded and the
data connection terminated.
36
NAS, user data or RRC signalling
Keys
and key
functions
Integrity
processing
IK
NAS, user data or RRC signalling
PDCP
NAS, user data, or RRC signalling
MAC-I
Fig. 17 Basic Principles of PDCP Data Ciphering and Integrity

37
Robust Header Compression (ROHC)

Given the environment that LTE is being introduced in to, it seems highly probable that the
majority of services supported will be IP based, the core of the network is IP based and the
networks that the EPC will interconnect with will be largely IP based. (the meaning of IP based in
this context includes all of the associated IP protocols including UDP/TCP, RTP, RTCP, SIP etc).
These protocols have evolved within the wired systems of the internet and local area networks
where bandwidth is not the premium resource it is on the radio interface. Hence the protocols
and headers tend to be rather longwinded, containing lengthy headers with much repeated or
static information.
Much of the information is redundant and especially so in point to point systems such as the
radio interface part of the network. Consider also that the radio interface is prone to errors and
retransmissions, then the lengthy headers and additional protocol overheads consume even
more bandwidth than is really necessary.
Many of these protocol headers may be compressed to reduce the amount of information
transmitted over the air. There are many suggested compression/de-compression schemes
from the IETF however they tend to address a single protocol such as the IP header, in addition
these mechanisms require a great deal of information to be sent in order to synchronise the
compression process and to re-synchronise the process in the event of lost or errored data,
thus negating the advantage of the compression in the first instance.
Robust Header Compression, defined by the IETF in RFCs 3095, 3843 and 4996 addresses
some of these issues.
The ROHCv2 describe the original framework (from v1) and introduces the concept of profiles which
describes the behaviour of various protocol compression cases including compression machine
state changes and the behaviour after transmission begins and the handling of erroneous data.
The ROHC decompressor is based on a 3 level state machine, NC (No Context), IC (Initial Context
and FC (Full Context). The decompressor will enter the NC state until it receives packets with the
correct ROHC header. It continues to exchange compressed packets in FC state until failures
occur, when the state machine enters IC or NC until ROHC sychronisation is re-established.
Theactual state of the machine is controlled by messages exchanged on the feedback channel.
The ACK acknowledges the receipt of correctly compressed packets, NACK indicates that
some of the dynamic fields are invalid and STATIC-NACK indicates that the static fields are no
longer valid and will force a complete context update.
Two type of packets are described for ROHC,
IR, Initialisation and Refresh, which contains the static and dynamic fields of the packet header
(uncompressed), this is used when the transmission starts or when negative feedback is used
CO, Compressed, contains the compressed header and the user data information, the level of
compression in the header will depend on the compression algorithm in use and the feedback
received.
The IR and CO packets are protected with a CRC to allow integrity checking, the information
derived from the CRC process will be used to generated feedback for the compression cycle.
38
PDCP State Machine

Feedback, ACK, NACK,
STATIC-NACK
FC
Compression
Machine
IC
NC
Compressed Packets, IR, CO
Compressor
De-Compressor
FC Full Context, maximum compression

IC Initial Context, compression negotiation
NC No Compression, starting condition
IR Initialisation and Refresh
CO Compressed packets
Fig. 18 PDCP ROHC (shown only in a single direction)

39
Compression Efficiency
ROHC uses existing methods of compression that have been well used in the past. The majority
of these techniques exploit the fact the protocol headers like IP, TCP, RTP etc contain static
information i.e. the information does not change from packet to packet, or information that can
be inferred or deduced from other information such as the payload length and information that
is dynamic or variable, such variable information often changes in a predictable manner or within
a limited range of values
The table below is an example of the IPv4 header shown the classification of the fields
Field Name
Size
Class
Version
Static
Header Length
Static
Type of Service
Dynamic
Packet Length
16
Inferred
Identification
16
Dynamic
Flags
Static
Time to Live
Dynamic
Protocol
Static
Header Checksum
16
Inferred
Source Address
32
Static
Destination Address
32
Static
In the case of VoIP the voice information is packetised by RTP, encapsulated by UDP then the
IP header is placed at the front of the data. The overhead due to protocol headers is 40 bytes
inthis example. Using ROHC techniques it is possible to reduce the amount of data to only
6bytes of information.
40
a) Typical IPv4 Header Fields

Field Name
Size
Class
Version
Static
Header Length
Static
Type of Service
Dynamic
Packet Length
16
Inferred
Identification
16
Dynamic
Flags
Static
Time to Live
Dynamic
Protocol
Static
Header Checksum
16
Inferred
Source Address
32
Static
Destination Address
32
Static
b) Example of ROHC Compression in VoIP

IP Header
20 bytes
UDP
8
RTP
12
VoIP Payload e.g. 32 bytes
ROHC
Compression
VoIP Payload e.g. 32 bytes
Fig. 19
41

LTE Air Int Sec04 190709 v02 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

LTE Air Int Sec04 190709 v02 PDF

Uploaded by

Copyright:

Available Formats

The LTE Protocols Layer 2 MAC, RLC and PDCP

The LTE Protocols

Informa Telecoms & Media

The LTE Protocols Layer 2 MAC, RLC and PDCP

The LTE Protocols Layer 2 MAC,

Informa Telecoms & Media

The LTE Protocols Layer 2 MAC, RLC and PDCP

Introduction to The LTE Layer 2 Protocols

Informa Telecoms & Media

Fig. 1 LTE Layer 2 Overview

The LTE Protocols Layer 2 MAC, RLC and PDCP

Medium Access Layer (MAC)

mapping between logical channels and transport channels;

Informa Telecoms & Media

Mapping between logical channels and

Fig. 2 MAC layer Functions (TS 36.321)

The LTE Protocols Layer 2 MAC, RLC and PDCP

LTE Channels and Channel Mapping

Informa Telecoms & Media

Fig. 3 LTE Channels

The LTE Protocols Layer 2 MAC, RLC and PDCP

LTE Logical channels

Informa Telecoms & Media

LTE Logical Channels

Logical Control Channels

Broadcast Control Channel (BCCH)

Logical Traffic Channels

Dedicated Traffic Channel (DTCH)

Multicast Control Channel (MCCH)

Fig. 4 LTE Logical Channels

The LTE Protocols Layer 2 MAC, RLC and PDCP

LTE Transport Channels

Informa Telecoms & Media

LTE Transport Channels

Downlink Transport Channels

Broadcast Channel (BCH)

Uplink Transport Channels

Uplink Shared Channel (UL-SCH)

Paging Channel (PCH)

Fig. 5 LTE Transport Channels

The LTE Protocols Layer 2 MAC, RLC and PDCP

LTE Physical Channels

Reference signals one signal transmitted per downlink antenna port

Informa Telecoms & Media

LTE Physical Channels

Downlink Physical Channels

Physical broadcast channel (PBCH)

Uplink Physical Channels

Physical uplink control channel

Physical downlink control channel

Fig. 6 LTE Physical Channels

The LTE Protocols Layer 2 MAC, RLC and PDCP

Informa Telecoms & Media

Fig. 7 Logical to Transport channel Mapping

The LTE Protocols Layer 2 MAC, RLC and PDCP

The MAC Protocol Data Unit (PDU)

Informa Telecoms & Media

Identity of the logical channel Identity of the logical channel

Power Headroom Report

Short Buffer Status Report

Long Buffer Status Report

Fig. 8 MAC Layer PDU Format

The LTE Protocols Layer 2 MAC, RLC and PDCP

a) Control Plane PDCP Header Format

b) User Plane PDCP Header Format

a) Typical IPv4 Header Fields

b) Example of ROHC Compression in VoIP