Acknowledged Mode
RLC Modes
The E-UTRA RLC layer is responsible for managing the flow of each EPS bearer across the air interface. To deal with the range of EPS bearer types, the E-UTRA RLC layer is required to support three different transfer modes: TM (Transparent Mode), UM (Unacknowledged Mode) and AM (Acknowledged Mode). Peer RLC layers dealing with the transfer of one bearer are known as RLC entities.
TM bearers receive no service from the RLC layer, not even the addition of an RLC header to PDUs.
Transport blocks are simply encapsulated and transferred. Error correction, retransmission and segmentation services for TM connections are assumed to take place at higher layers, if at all.
UM bearers receive a connectionless service from the RLC layer. Segmentation and reassembly of RLC PDUs may occur if required; sequential transfer and reordering of PDUs will be performed, duplicate and errored PDUs will be discarded but retransmission is not supported.
AM performs all of the functions of UM but also supports retransmission of errored or missing PDUs.
Further Reading: 3GPP TS 36.322
Radio Access Protocols
LT3600/v1.1 © Wray Castle Limited 4.11
Transparent Mode PDU – no added protocol data
Unacknowledged and Acknowledged Mode
Transport Block/PDCP SDU
Transport Block/PDCP SDU
SN FI E LI
RLC PDU Structure
For TM bearers an RLC PDU is simply the upper layer transport block with no additional protocol data added.
For UM and AM connections the RLC layer adds a header and may or may not perform segmentation or concatenation of transport blocks as required.
There are slightly different header layouts for UM and AM PDUs, but both types support the following fields:
SN – Sequence Number
FI – Framing Information
E – Extension headers present indicator
LI – Length Indicator (optional)
Extension headers can optionally be added to the PDU
Unlike the RLC layer in some legacy GSM and UMTS variants, the E-UTRA RLC has no fixed PDU size. Some legacy systems segmented all traffic into fixed-size RLC PDUs and then forced the MAC layer to concatenate multiple RLC SDUs into its own PDU structure.
The E-UTRA avoids this unnecessary segmentation and concatenation where possible. The RLC layer attempts to deal with an upper-layer TB as a complete unit and will only segment when the TB (plus RLC data) is larger than the MAC PDU that will carry it.
Further Reading: 3GPP TS 36.322
LTE/SAE Engineering Overview
4.12 © Wray Castle Limited LT3600/v1.1
PDCP
Header £$%&^*&@~#%$#~@£$$
Transport Block
PDCP Ciphering
HeaderIP
Transport Block
ROHC Applied
PDCP Operation
Until relatively late on in the development of E-UTRA, PDCP was scheduled to operate between the eNB and the core network over the S1 interface, or between peer eNBs over the X2 interface during handovers. By the time the first release of specifications were published in October 2007, however, the functionality had been moved to the eNB.
The basic functions of the PDCP layer are upper-layer (IP) packet header compression, ciphering and integrity protection of control messages.
The header compression protocol is based on the RoHC framework, specified in IETF RFC 4995.
There are multiple header compression algorithms, called profiles, defined for the RoHC framework.
Each profile is specific to the particular network layer, transport layer or upper layer protocol combinations, e.g. TCP/IP and RTP/UDP/IP. Currently, E-UTRA supports only RoHC profiles that handle TCP/IP flows.
Ciphering and deciphering in E-UTRA are performed at the PDCP layer, rather than at the physical, MAC or RLC layers as has variously been the case in previous
systems.
A detailed description of the E-UTRA ciphering services has yet to be published, but the outline details available so far indicate that it operates following the same principles as the ciphering schemes employed by GSM and R99 UMTS – a shared secret operating between the SIM (Subscriber Identity Module) and the HSS. PDCP is only responsible for ciphering over the air interface. Each eNB will also maintain a separate ciphered connection with the EPC over the S1 interface and with other eNBs over the X2 interface. Ciphering is enabled by the CK (Cipher Key) parameter shared by the SIM and the HSS.
Further Reading: 3GPP TS 36.323
Radio Access Protocols
LT3600/v1.1 © Wray Castle Limited 4.13
MS
eNB No message authentication
Message vulnerable, connection could be hijacked
eNB CMAC message authentication
MS
Message protected, connection cannot be hijacked
Integrity Protection
The PDCP layer is also responsible for ensuring that control messages between the eNB and each UE are protected and that any interception or modification of messages is detectable.
The integrity protection scheme employed in the E-UTRA is outlined in 3GPP TR 35.201 and uses a MAC (Message Authentication Code) mechanism based on the f9 Kasumi algorithm.
CMAC (Cipher-based MAC) authentication provides a simple method of checking the authenticity of a message and determining whether it has been tampered with ‘in flight’.
Management messages are provided with a CMAC tag, which is generated using a combination of the CMAC algorithm, the message content and the encryption system’s ‘shared secret’.
The transmitting device inserts a CMAC into each management message that is issued. The receiving device generates its own CMAC tag based on the received message contents, the CMAC algorithm and its copy of the shared secret. If the message is authentic and unaltered the locally generated CMAC tag should match the one appended to the message and the management message is therefore accepted as genuine.
Integrity protection is enabled by the IK (Integrity Key) parameter shared by the SIM and the HSS.
Further Reading: 3GPP TS 35.201, 36.323
LTE/SAE Engineering Overview
4.14 © Wray Castle Limited LT3600/v1.1
RRC Non-Access
Stratum (NAS) Non-Access
Stratum (NAS)
RRC
User Equipment eNB Evolved Packet Core
Broadcast Control Channel (BCCH) Paging Control Channel (PCCH)
Connection management
As with other E-UTRA protocols, the RRC layer which previously resided in the RNC has been devolved to the eNB. The main RRC functions performed by the eNB include:
creation of BCH (Broadcast Channel) system information
creation and management of the PCH (Paging Channel)
RRC connection management between eNB and UEs, including generating
temporary identifiers such as the C-RNTI
mobility-related functions such as measurement reporting, inter-cell handover and inter-eNB UE context handover
QoS management
direct transfer of messages from the NAS to the UE
The RRC is in overall control of radio resources in each cell and is responsible for collating and managing all relevant information related to the active UEs in its area.
The BCH provides the main means of advertising the services available in a cell and the means by which those services can be accessed. The E-UTRA BCH carries system information related to the NAS, such as PLMN identity (network code and country code) and AS (Access Stratum) details such as cell ID and tracking area identity. E-UTRA has been designed with network sharing in mind and the BCH can in theory carry details of up to six sharing PLMNs (Public Land Mobile Networks).
Each eNB is responsible for managing inter-cell handovers between all the cells it controls. When handover to another cell site is required the eNB will pass details of the current UE context to its neighbour. This includes details of identities used, historical measurements taken and active EPS bearers.
Further Reading: 3GPP TS 36.331
Radio Access Protocols
LT3600/v1.1 © Wray Castle Limited 4.15
Monitors BCH system information Monitors paging channel Performs cell reselection Assigned tracking area ID by MME
Performs location updates No RRC context stored in the eNB.
UE has an E-UTRAN-RRC connection UE has context in E-UTRAN
E-UTRAN knows the cell which the UE belongs to Network can transmit and/or receive data to/from UE
Network-controlled mobility Neighbour cell measurements