LTE_Tech_Ov_Sec04_091009_v01

Informa Telecoms & Media

Introduction to LTE Protocols

IntroductIon to LtE ProtocoLs



IntroductIon to LtE ProtocoLs

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

4Introduction to LTE Protocols


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 and PDCP, 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 the MAC layer.

The Radio Link Control (RLC) protocol is much like a standard OSI layer 2 datalink protocol, it provides data segmentation/re-assembly, ARQ services for the layers above. Data flows from the 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. Each of 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 it comes 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.

LTE

Lay

er 2

PD

CP

RR

C

RLC

MA

C

Segm.ARQ

Scheduling/priority handling

Segm.ARQ

Segm.ARQ

Segm.ARQ

Transport channels

PH

Y Channelcoding

Channelcoding

Channelcoding

Channelcoding

Channelcoding

HARQ HARQ HARQ

Multiplexing

Physical channels

Control planeUser plane

PCCHBCCH

ROHCciphering

ROHCciphering

ROHCciphering

Sys infobroadcast Paging

Cipheringintegrity

RRC

Logical channels

Radio bearers

5 Informa Telecoms & Media

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 are carried out by the eNB only. Similarly scheduled information reporting is a UE only function.


Fig. 2 MAc layer Functions (ts 36.321)

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



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 channelsLogical Channels exist between the PDCP layer and MAC, they are principally defined by the type of information that they carry. There are logical channels that carry control data, and logical channels that carry user traffic.

transport channelsTransport 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 is protected from errors, size of data packets, etc. The attributes of data transfer applied to the data in the transport channel is otherwise known as the transport format.

Physical channelsPhysical 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.

Trafficchannel

MAC

PHY

Controlchannel

Logical channelsDefined by Type of information i.e. traffic, control, e.g. BCCH, PCCH, CCCH, MCCH, DCCH

Transport channelsDefined by Transport attribute i.e. channel coding, CRC, interleaving, size of radio data packets, e.g. BCH, PCH, DL-SCH, MCH

Physical channelsDefined by actual physical layer characteristics, bandwidth, FFT size, e.g. PDSCH, PDCCH, PMCH, PBCH


Fig. 3 LtE channels

10



LtE Logical channels

There are two types of logical channel, control channels and traffic channels, they are described below.

control channelsControl 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 on this channel is shared by all the users in the cell, the information broadcast relates to the Operator 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 for UEs 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 from the network 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 a UE and the network. UEs having an RRC connection will exchange RRC and NAS signalling, it should be noted that application level signalling (SIP messages from the IMS) is not handled by the DCCH.

traffic channelsTraffic 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 the transfer 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.

LTE Logical Channels

Logical Control Channels Logical Trafc 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

Multicast Control Channel (MCCH) Multicast control signalling

Dedicated Control Channel (DCCH) Bi-Directional signalling, RRC

connection, RRC and NAS Signalling

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


Fig. 4 LtE Logical channels

12



LtE transport channels

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 be broadcast 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 entire cell, given the nature of the data in this channel it will also support for both dynamic and semi-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 HARQ and 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 is a 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.

LTE Transport Channels

Downlink Transport Channels Uplink Transport Channels

Broadcast Channel (BCH) xed, pre-dened 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.

Paging Channel (PCH) UE discontinuous reception (DRX) to

enable UE power saving broadcast in the entire coverage area

of the cell; mapped to physical resources which

can be used dynamically also for trafc/other control channels.

Multicast Channel (MCH) broadcast in the entire coverage area

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

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;


Fig. 5 LtE transport channels

14



LtE Physical channels

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 four subframes 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 a single 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 is transmitted 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 to downlink 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;

Reference signals one signal transmitted per downlink antenna portSynchronisation signals primary and secondary synchronisation signals.

LTE Physical Channels

Downlink Physical Channels Uplink 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.

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 trafc/other control 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.


Fig. 6 LtE Physical channels

16



channel Mapping

The diagram opposite shows the possible mapping of channels between logical, transport and physical channels.

It can be noted that, whilst the logical channels carry specific types of information, they can be mapped 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 may be used to carry the system information. This depends on the type of system information being transmitted. 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.

Logical

BCCH CCCHPCCH DCCH DTCH MCCH MTCH

PCFICH Physical

Transport

PHICH

PUCCH

PDCCH PBCH PUSCH PDSCH PMCH PRACH

BCHPCH UL-SCH DL-SCH MCH RACH


Fig. 7 Logical to transport channel Mapping

18



the MAc Protocol data unit (Pdu)

MAC layer control data and upper layer user information and signalling is carried over the logical and 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 of the MAC 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 the types of MAC control element.

The MAC control element contains additional control data depending on the reason for the transmission 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 amount of 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.

R ReservedE ExtensionLCID Logical Channel IdentityF Format of Length Field(1 = >128 bytes)L Length of MAC PDU

MAC SDUMAC ControlElementsMAC Header

LLCID FERR

Buffer SizeLGID

C-RNTI

UE Contention Resolution ID

Timing Advance

Power HeadroomLong Buffer Status ReportPadding

Padding

Short Buffer Status Report DRX Command

C-RNTI Timing Advance

Power Headroom Report UE Contention Resolution ID

Reserved Reserved

Identity of the logical channel Identity of the logical channel

CCCH CCCH

UL LCID Values DL LCID Values


Fig. 8 MAc Layer Pdu Format

20



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. The reporting 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 cellMulti-Band type; providing CQI of some subsets of system bandwidth of the cellMIMO type; still under study by 3GPP

Reporting is carried out on the PUSCH when the UE has resources allocated otherwise the PUCCH is used.

HARQ

User 2DTCH

User 1DTCH + DCCH

User 3DTCH + DCCH

toPHYlayer

MAC LayerPriority Handling

Function


Fig. 9 MAc layer Priority Handling

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

22



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.

Discarddatax

ARQ data #1

CRC Data #2 CRC Data #1 CRC Data #1

CRC Data #1

Bufferdatax

ARQ data #1

CRC Data #2 CRC Data #1 CRC Data #1

CRC Data #1 CRC Data #1buffered

CRC Data #1combined


Fig. 10 LtE HArQ

normal ArQ operation

Hybrid-ArQ operation

UL-SCH, DL-SCH support HARQ1 Bit HARQ Field

downlinkAsynchronous ACK/NACK on PUCCH and PUSCH

uplinkSynchronous ACK/NACK on PHICH

24



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;

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

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.

26



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.

UE

No Interaction with Data

PCCH, BCCH

Segmentation, Reassembly, Sequencing, DTCH, DCCH

Segmentation, Reassembly, Packet Retransmission, Sequencing, DTCH, DCCH

E-Node B

AM UM TM TM UM

Lower Layers (MAC, PHY) Lower Layers (MAC, PHY)

AM


Fig. 12 rLc Layer operating Modes

28



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 the data 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 is more header information. The E field may indicate a set of additional information fields namely E and Length Indicator (LI) fields. The Sequence Number (SN) is a 5 or 10 byte number that is incremented 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 a basic (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.

Oct 1

Oct N

Data...

DataSNEFI

...Oct 2

Oct 1

Oct N

FI Framing IndicatorE ExtensionSN Sequence Number

DataSN

P ERFD/C FI SN

...Oct 3

Oct 2

Oct 1

Oct N

D/C Data/ControlRF Re-segmentation FlagP PollingFI Framing InfoE ExtensionSN Sequence Number


Fig. 13

a) the tM Pdu

b) the uM Pdu with 5 byte sn

c) the AM Pdu, showing no LI

30



rLc segmentation and concatenation

RLC supports the segmentation of upper layer data (RLC SDU) which is too large to fit into a single 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 be concatenated into a single PDU.

The size of the PDU will be determined by the underlying protocols, MAC and PHY and will be related to the modulation coding scheme currently being provide by the PHY. The layers in the 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 the segment offset.

Segmentation Concatenation

RLCSDUs

LI Field points to Data field elements

Segmentation

n n+1 n+2 n+3

DataeldHeaderHeader Data eld

Dataeld


Fig. 14 segmentation and concatenation

32



Packet data control Protocol (PdcP)

The main purpose of the PDCP is to provide a service of data reception and delivery to/from the peer 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) is the 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.

User planeEPC data from serving GW

Control plane NAS Signalling from MMERRC Signalling from eNB

Data Radio BearersDRB

Signalling Radio BearersSRB

ROHC ROHC Integrityprocessing

Encryption Encryption


Fig. 15 Basic Model of PdcP Functions

user Plane FunctionsHeader 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 for RLC AM;

Duplicate detection of lower layer SDUs at handover for RLC AM;

Retransmission of PDCP SDUs at handover for RLC AM;Ciphering;Timer-based SDU discard in uplink.

control Plane FunctionsCiphering 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.

34



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.

Data

MAC-IMAC-I (cont.)MAC-I (cont.)MAC-I (cont.)

RRR PDCP sequence number

...Oct 2

Oct 1

Oct N-3

Oct N-2

Oct N-1

Oct N

R Reserved MAC-I Message Authentication Code Integrity

PDCP sequence number (cont.)Data

R RRD/C PDCP sequence number

...

Oct 2

Oct 1

Oct 3

D/C Data/Control; the control data is ROHC Feedback


Fig. 16

a) control Plane PdcP Header Format for srB (signalling radio Bearers)

b) user Plane PdcP Header Format or drB (data radio Bearers)

36



Encryption and data Integrity

It is the PDCP that ensures security for the user across the radio interface. The information in the user plane, including upper layer signalling, will be protected from eavesdropping by the bitwise exclusive OR operation on the user data with a cipher key stream generated by a computational 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 the data 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.

Keysand key

functions

Integrityprocessing IK

NAS, user data or RRC signalling

NAS, user data or RRC signalling

NAS, user data, or RRC signalling MAC-IPDCP

+


Fig. 17 Basic Principles of PdcP data ciphering and Integrity

38



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. The actual 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.

Feedback, ACK, NACK,STATIC-NACK

PDCP State Machine

De-CompressorCompressor

CompressionMachine

FC Full Context, maximum compressionIC Initial Context, compression negotiationNC No Compression, starting condition

IR Initialisation and RefreshCO Compressed packets

Compressed Packets, IR, CO

FC

IC

NC


Fig. 18 PdcP roHc (shown only in a single direction)

40



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 4 Static

Header Length 4 Static

Type of Service 8 Dynamic

Packet Length 16 Inferred

Identification 16 Dynamic

Flags 3 Static

Time to Live 8 Dynamic

Protocol 8 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 in this example. Using ROHC techniques it is possible to reduce the amount of data to only 6 bytes of information.

IP Header20 bytes

RTP12

ROHCCompression

UDP8 VoIP Payload e.g. 32 bytes

6 VoIP Payload e.g. 32 bytes


Fig. 19

a) typical IPv4 Header FieldsField name size class

Version 4 Static

Header Length 4 Static

Type of Service 8 Dynamic

Packet Length 16 Inferred

Identification 16 Dynamic

Flags 3 Static

Time to Live 8 Dynamic

Protocol 8 Static

Header Checksum 16 Inferred

Source Address 32 Static

Destination Address 32 Static

b) Example of roHc compression in VoIP

LTE_Tech_Ov_Sec04_091009_v01

Documents

Transcript of LTE_Tech_Ov_Sec04_091009_v01