CCPU LTE Protocol Perspective-2

WHITE PAPER

Global HeadquartersContinuous Computing

9450 Carroll Park DriveSan Diego, CA 92121 USAT +1.858.882.8800F [email protected]

www.ccpu.com

INTRODUCTION

In today’s ever-shrinking mobile and global village, information on the go is becoming as mundane as a four-square meal. While Generation X grew up with broadband Internet and the mobile access revolution, Gen Y is having a ball with ready connectivity to media-rich content and the social networking revolution. Today’s new consumers want anytime, anywhere access, and this helps drive ever-growing demand for new and innovative applications that capitalize on the triple play of simultaneous voice, video, and data sessions with differentiated Quality of Service (QoS).

Under the constant pressure of dwindling voice revenues and ever-increasing competition for market-share from new entrants in a deregulated market, operators are increasingly offering bundled “all-you-can-savor” services to win over new customers, retain existing ones, and increase overall Average Revenue Per User (ARPU). In turn, these service innovations are driving up traffic both in the access domain as well as in the core network, spurring demand for unwired and mobile access to tens of megabits per second of data traffic.

While Third Generation (3G) wireless technologies under the banner of the International Mobile Telecommunication-2000 (IMT-2000) initiative of ITU promised access up to 133Mbps bandwidth, unfortunately both mainstream options – Code Division Multiple Access 2000 (CDMA2000) and Wideband CDMA (WCDMA) – have failed to deliver on that objective. Industry-wide collaborative projects focused on technology standards – Third Generation Partnership Project (3GPP) for WCDMA and 3GPP2 for CDMA2000 – have put forth evolutionary solutions to meet the early promise of IMT-2000 and the growing demand for wireless bandwidth.

3GPP2 started out with CDMA2000 1X (released in 1999), then followed up with Evolution Data-Optimized (1xEV-DO in 2000), EV-DO Rev.A (with VoIP support in 2004), EV-DO Rev.B (with multi-carrier support in 2006), and finally Ultra Mobile Broadband (UMB, formerly known as EV-DO Rev.C) in 2007. Similarly, 3GPP started out with Release-99 using WCDMA and followed up with Release-5 supporting High-Speed Downlink Packet Access (HSDPA) in 2002, Release-6 supporting High-Speed Uplink Packet Access (HSUPA) in 2005, and Release-7 in 2007 culminating at 14Mbps peak bandwidth.

Long Term Evolution (LTE) is 3GPP’s latest initiative, standardized in the form of Release-8 and targeted for completion by early 2009. LTE promises to get us to 100Mbps downlink (DL) speed and 50Mbps Uplink (UL) speed with 20MHz bandwidth. Fortunately, operators worldwide appear to be embracing LTE, and service providers and infrastructure vendors alike are gearing up for the next phase of telecom advancement. This paper is a primer on the technical aspects of LTE and illustrates various key features of this exciting new technology.

WHAT IS LTE?

Second generation wireless technologies like Global System for Mobile Communications (GSM), General Packet Radio Services (GPRS), and CDMA have served us well with voice traffic but have fallen short on supporting the insatiable demand for anywhere, anytime access to media-rich data content. At the same time, because of the spiraling cost of acquiring radio spectrum and retooling core network infrastructure to offer competitive services, network operators have been forced to optimize 2G spectral efficiency to support more voice calls along with new data/video applications. Likewise, 3G technologies such as Universal Mobile Telecommunication System (UMTS using WCDMA) and CDMA2000 have served admirably on increasing voice capacity but have also fallen short on the data front.

Unlocking Long Term Evolution (LTE):A Protocol Perspective

by Debjani De and Ravi Raj Bhat

Unlocking Long Term Evolution (LTE): A Protocol Perspective 2

LTE started out as an evolutionary approach by 3GPP in 2004 to advance the UMTS Terrestrial Radio Access Network (UTRAN) to deliver faster data speeds and new services by creating a new radio access technology optimized for IP-based traffic (delivering two to four times the spectral efficiency of a 3G/HSPA network) while offering operators a simple upgrade path from 3G networks. While the LTE initiative focuses on Evolved UTRAN (E-UTRAN), 3GPP’s System Architecture Evolution (SAE) initiative migrates the core network architecture to move away from traditional circuit-switched infrastructure (e.g., Signaling System 7, SS7, and Asynchronous Transfer Mode, ATM) to all-IP network, more commonly referred to as the Evolved Packet Core (EPC). E-UTRAN and EPC together form the next generation Evolved Packet System (EPS), enabling faster deployment of value-added services to cater to increasingly demanding and finicky Gen Y consumers.

eNodeB

eNodeB

eNodeB

MME

Serving GW

X2

X2 X2

S1-MME S1-U

S1-MM

E

S1-U

SGSN

RNC

Packet GW

S4

S3

S5/S8 S11

MME

S10

S12

Figure 1: LTE Network Architecture

Figure 1 illustrates the LTE network architecture. The EPC forms the all-IP core network being developed by SAE and introduces the Mobility Management Entity (MME) providing control plane functionality and the Serving Gateway (SGW) providing data plane functionality. The MME and SGW could physically be one device, but logically they are two. On the Radio Access Network (RAN), a mobile device gets access to the network through an evolved Node B (eNB), which is connected to the MME/SGW through the S1 interface. eNBs are connected to each other via the X2 interface. 3GPP defines a new Sx interface to connect the EPC to the UMTS core.

LTE uses Orthogonal Frequency Division Multiplexing (OFDM) at the radio interface to deliver up to 100Mbps on the downlink and up to 50Mbps on the uplink. OFDMA allows multiple users to share available bandwidth. The entire available bandwidth (of variable size up to a maximum of 20MHz in LTE, as compared to a fixed 5MHz in UMTS) is divided into a number of sub-carriers. Each user in the system is allotted a certain number of sub-carriers out of the total number of available sub-carriers. Twelve such sub-carriers make resource blocks; as the available bandwidth increases, available resource blocks increase and hence allowable user data rate increases. Also, Multiple Input / Multiple Output (MIMO) with spatial multiplexing helps improve the data rate. LTE siblings delivering similar capacity improvements are 3GPP2’s UMB and IEEE’s 802.16e-2005, commonly known as Mobile WiMax. Table 1 compares LTE with UMB and Mobile WiMax, which is currently being upgraded for higher data rates as part of the 802.16m amendment effort planned to be completed by 2010.


LTEMobile WiMax (802.16e-2005)

UMB

DL Access OFDMA OFDMA OFDMA

UL Access Single Carrier FDMA OFDMA OFDMA & CDMA

Data Rate100Mbps in DL & 50Mbps

in UL with 20MHz

Combined UL & DL,

74Mbps with 20MHz

275Mbps in DL & 75Mbps

in UL with 20 MHz

Flexible bandwidth 1.4, 3 5, 10, 15, 201.25, 3.5, 5, 7, 8.75, 10, 14,

17.5, 20, 281.25, 2.5, 5, 10, 20

Automatic Repeat Request (ARQ) Yes Yes Yes

Hybrid ARQ (HARQ) Mandatory Optional Mandatory

Time Division Duplex (TDD) Yes Yes Yes

Frequency Division Duplex (FDD) Yes Yes Yes

Flexible UL Resource Allocation Yes Yes Yes

Flexible DL Resource Allocation Yes Yes Yes

SecurityAuthentication and Key

Agreement (AKA)

Extensible Authentication

Protocol (EAP)EAP

Modulation

Binary Phase Shift Keying

(BPSK), Quadrature PSK

(QPSK), Quadrature

Amplitude Modulation

(16QAM), 64QAM

BPSK, QPSK, 16QAM,

64QAM

QPSK, 8PSK, 16

QAM, 64 QAM

Channel Coding Convolutional and Turbo

Convolutional, Turbo, Low

Density Parity Check Code

(LDPC)

Convolutional, Turbo, Block

Turbo, LDPC

MobilityWithin 3GPP & non-3GPP

(WiMax, 3GPP2)

Within WiMax & non-WiMax

(3GPP, 3GPP2)

Within 3GPP2 & non-

3GPP2 (3GPP, WiMax)

Table 1: Comparison of Various 4G Technologies

LTE supports at least 200 active users in every 5MHz cell (i.e., 200 active data clients) with sub-5ms latency for small IP packets. LTE allows radio spectrum to be sliced as small as 1.25MHz and as large as 20MHz, allowing evolutionary and differentiated service roll-out. LTE works with an optimal cell size of 5km and is required to deliver acceptable performance up to cell sizes of 100km. LTE defines six downlink physical channels and three uplink physical channels as shown in Table 2.

WHAT MAKES LTE EVOLUTIONARY?

LTE employs a different radio access technology as compared to UMTS and redesigns the core network to be all-IP. So, why does 3GPP claim LTE to be evolutionary rather than revolutionary? The explanation is that LTE is flexible, allowing operators to determine the spectrum in which it will be deployed. LTE not only operates in a number of different frequency bands (allowing operators to deploy it at lower frequencies with better propagation characteristics), but it also features scalable bandwidth. While WCDMA/HSPA uses fixed 5MHz channels, LTE can scale from 1.25 to 20MHz. This flexibility allows LTE networks to be launched with a small amount of spectrum, alongside existing UMTS spectrum, and operators may add more spectrum as users switch over from UMTS to LTE. Although LTE introduces the MME/SGW to enable an all-IP core, and so reducing the number of network elements (thereby reducing the cost and latency significantly), it also enables interworking with 3GPP and non-3GPP-based legacy networks, which allows for service continuity.


Channel Name Dir PurposePhysical Parameters

Modulation Channel Coding

PBCHPhysical Broadcast

ChannelDL Carries Broadcast Information QPSK

Rate 1/3 Tail Biting

Convolutional

coding

PRACHPhysical Random

Access ChannelUL Carries Random Access Preamble QPSK

Rate 1/2

Convolutional

coding

PMCHPhysical Multicast

ChannelDL Carries Multicast Control & Data PDUs

QPSK, 16QAM,

64QAM

Rate 1/3 Turbo

coding

PDCCHPhysical Downlink

Control ChannelDL

Informs the UE about the resource

allocation of PCH and DL-SCH, and

Hybrid ARQ information related to DL-

SCH

Carries the uplink scheduling grant

QPSK

Rate 1/3 Tail Biting

Convolutional

coding

PUCCHPhysical Uplink

Control ChannelUL

Carries Hybrid ARQ ACK/NACKs in

response to downlink transmission

Carries Scheduling Request (SR)

Carries CQI reports

BPSK, QPSK

Variable Rate Block

Code, Rate 1/3 Tail

biting Convolutional

Code

PDSCHPhysical Downlink

Shared ChannelDL

Carries DL Broadcast/Shared Control/

Data PDUs

QPSK, 16QAM,

64QAM

Rate 1/3 Turbo

coding

PUSCHPhysical Uplink

Shared ChannelUL Carries UL Shared Control/Data PDUs

QPSK, 16QAM,

64QAM

Rate 1/3 Turbo

coding

PHICHPhysical HARQ

Indicator ChannelDL Carries HARQ ACK/NACK for UL BPSK

Rate 1/3 Repetition

Code

PCFICH

Physical Control

Format Indicator

Channel

DL Carries No of OFDM Symbols for PDCCH QPSKRate 1/16 Block

Code

Table 2: LTE Physical Channels

LTE PROTOCOLS

Logically, LTE network protocols can be divided into Control-plane (responsible for setting up bearer transport which carries user traffic) and User-plane (responsible for transporting user traffic). Figure 2 illustrates the User-plane protocol stacks, while Figure 3 illustrates Control-plane protocol stacks at various nodes and interfaces.

PHY

MAC

RLC

PDCP

User App

UE

Uu

IP

PHY

MAC

RLC

PDCP

IP

UDP

eGTP-U

IP

UDP

eGTP-U

IP

UDP

eGTP-U

IP

UDP

eGTP-U

IP

UDP

eGTP-U

IP

UDP

eGTP-U

User App

IP

X2-U S1-U S5/S8

eNodeB eNodeB S-GW P-GW

Figure 2: User-plane Protocol Stacks


PHY

MAC

RLC

PDCP

UE

Uu

RRC

PHY

MAC

RLC

PDCP

IP

SCTP

X2-C S1-MME S10

eNB eNB MME MME

EMM/ESM

RRC X2-AP

IP

SCTP

X2-AP

IP

SCTP

S1-AP

IP

SCTP

S1-AP

IP

UDP

eGTP-C

EMM/ESM

IP

UDP

eGTP-C

IP

UDP

eGTP-C

IP

UDP

eGTP-C

S11

IP

UDP

eGTP-C

S5/S8

Figure 3: Control-plane Protocol Stacks

In EPS, Non-Access Stratum (NAS) procedures include the procedures used by the protocols for mobility management and session management between User Equipment (UE) and MME. The following sections briefly describe each protocol layer’s functionality and how it compares to the equivalent protocol in UMTS if there is one.

EPS SESSION MANAGEMENT (ESM)

The ESM protocol provides procedures for the handling of EPS bearer contexts. Together with the bearer control provided by the access stratum, this protocol is used for the control of user plane bearers. Network-initiated procedures supported by this layer are to create, activate, modify, and delete EPS bearers. UE-initiated procedures supported by this layer are to request to create, modify, and release EPS bearers with specific QoS. If accepted by the network, a corresponding network-initiated procedure is started. Figure 4 illustrates segregation of network-initiated and UE-initiated procedures. The equivalent protocol in UMTS is Session Management (SM).

EPS Bearer Context Activation

EPS Bearer Context Modification

EPS Bearer Context Deactivation

Protocol Configuration

Packet Data Network (PDN) Connectivity

PDN Disconnect Update

Bearer Resource Allocation Update

Bearer Resource Release Update

Network-Initiated UE-Initiated

Figure 4: ESM Procedure Distribution

EPS MOBILITY MANAGEMENT (EMM)

The EMM protocol provides procedures for managing mobility when the UE is using the E-UTRAN. The EMM protocol also provides control of security for the NAS protocols. EMM procedures can be divided into three groups as illustrated in Figure 5 with color coding for each type of procedure:

n EMM Common procedures used for both connection management and mobility management

n EMM Specific procedures used only for mobility management

n EMM Connection management procedures used only for connection management


GUTI Reallocation

Authentication

Security Mode Control

Identification

Periodic Tracking Area Update

Normal Tracking Area Update

Attach

Detach

Network-Initiated UE-Initiated

EMM Information

Detach

Paging

Service Request

Connection Management Specific Common

Legend

Figure 5: ESM Procedure Distribution

The Attach procedure is initiated by the UE to use packet services in the EPC. The UE sends an attach request to the MME, which answers with Attach Accept or Attach Reject. A default or dedicated EPS bearer is created at the end of a successful attach procedure. Identities used by the UE for this procedure are GUTI (Globally Unique Temporary Identifier), if available, or International Mobile Subscriber Identity (IMSI). The Detach procedure can be initiated by the network (to terminate EPS bearer) or the UE (to terminate one/both EPS and non-EPS bearer).

A Service Request is initiated by the UE if there is UL signaling data to be sent. Paging is initiated by the MME if there is downlink traffic to be delivered to the UE. The GUTI Re-allocation procedure is initiated by the MME, normally as a part of another MM procedure (e.g., tracking area update, attach, etc.). The MME sends a GUTI Re-allocation command to the UE, which stores the GUTI and responds with a GUTI Re-allocation complete. Tracking Area Update is used to register a UE’s tracking area (normal) or periodically update UE availability in the MME (periodic). The MME responds with a tracking area updating accept/reject. The equivalent protocol in UMTS is GMM (GPRS Mobility Management).

EVOLVED GPRS TUNNELING PROTOCOL (eGTP)

3GPP outlines eGTP in two separate specifications, GTPv2-C and GTPv1-U. GTPv2-C is responsible for creating, maintaining, and deleting tunnels on Sx interfaces. It is also responsible for forwarding Relocation messages, SRNS context, and creation of forwarding tunnels during inter-LTE handovers. GTPv1-U is used for transferring user data using GTP tunnels. Table 3 and Table 4 illustrate various functionalities supported by GTPv2-C and GTPv1-U at different Sx interfaces. Table 3 also attempts to group functionalities into Path Management, Tunnel Management, and Mobility categories.

GTPV2-C Functions S11 S4 S10 S5/S8 S3 S16

Path

Echo Request/Response • • • • • •

Version not Supported • • • • • •

Suspend/Resume • •

Tunnel

Session Creation and Deletion • • •

Bearer Creation, Modification, Update and Deletion • •

Downlink Data Notification •

Mobility

Forward Relocation •

Forward tunnel creation •

Context/Identity request/response • • •

Forward SRNS Context • • •

Detach •

Table 3: GTPv2-C Functionality Mapping


GTPV1-U Functions S1-U S5/S8 S12 X2-U

Echo Request/Response • • • •

Error Indication • • • •

End Marker • • • •

Transfer of User Payload • • • •

Table 4: GTPv1-U Functionality Mapping

While UMTS GTP mainly manages Packet Data Protocol (PDP) contexts, which are intended to carry only data traffic, LTE eGTP manages EPS bearers (i.e., carries all types of traffic). eGTP introduces new control messages and TLIV (Type, Length, Instance, Value) encoding. It also introduces an end-marker in GTP-U to mark the end of data transfer.

X2 APPLICATION PROTOCOL (X2AP)

X2AP comes in the control path of two eNBs and is primarily used for handover support and load balancing between multiple eNBs. This is a new protocol introduced in LTE and does not have any equivalent protocol in UMTS, although it has some commonality with RNSAP, which runs between two adjacent RNCs in UMTS. The X2AP protocol provides following functions:

n Mobility Management allows the eNB to move the responsibility of a certain UE to another eNB.

n Load Management allows eNBs to indicate resource status, overload, and traffic load to each other so that UEs can be moved to eNBs that are lightly loaded.

n General Error Reporting allows identification and reporting of general error situations, for which function specific error messages have not been defined.

n Reset allows the complete reset of the X2 interface.

n X2 Setup allows exchanging necessary data for the eNB for setup of the X2 interface.

n eNB Configuration Update allows updating of application-level data needed for two eNBs to interoperate correctly over the X2 interface.

S1 APPLICATION PROTOCOL (S1AP)

S1AP provides the signaling service between E-UTRAN and the EPC. S1AP services are divided into two groups: Non UE-associated services are related to the whole S1 interface instance between the eNB and MME utilizing a non UE-associated signaling connection, while UE-associated services are related to one UE. S1AP functions that provide these services are associated with a UE-associated signaling connection that is maintained for the UE in question. The common unit used by S1AP protocol functions is SAE bearer, which is one or more service data flow context between the UE and the EPC. Table 5 illustrates S1AP functions and maps them into related groups, namely UE context/Bearer, Handover, UE Location, Management, and Tunneling. This is a new protocol introduced in LTE and does not have any equivalent protocol in UMTS, although it has some commonality with RANAP in UMTS.


S1-AP Functions E-UTRAN MME

UE Context

/ Bearer

SAE Bearer Setup/Modify •

SAE Bearer Release • •

Initial Context Transfer function •

UE context Release function • •

UE context Modification function •

Handover

Handover Preparation •

Handover Resource Allocation •

Handover Notification •

Path Switch Request •

Handover Cancellation •

Status Transfer • •

LocPaging •

Location Reporting •

MgmtNAS transport • •

S1 CDMA2000 Tunneling • •

Tunnel

Reset • •

Error Indication • •

S1 Setup •

Configuration Update • •

Overload •

UE Capability Info Indication •

Trace •

Table 5: S1AP Functionality Mapping

RADIO RESOURCE CONTROL (RRC)

The RRC layer provides the E-UTRAN Radio signaling connections to the upper layers (e.g., Radio Resource Manager, RRM) to support the exchange of the upper layer’s information flow. The signaling connection is used between the UE and the core network to transfer upper layer information. For each core network domain, at most one signaling connection may exist at any given time. The RRC layer maps the signaling connections for one UE on a single RRC connection. Table 6 lists all the functions supported by RRC and maps it to E-UTRAN and UE.

RRC Functions E-UTRAN UE

Broadcast of information related to the Non-Access Stratum (NAS) and Access Stratum •

Cell selection and Re-selection •

Establishment / Modification / Release of RRC Connection • •

Paging •

Establishment / Modification / Release of Data Radio Bearers (DRB) •

Radio configuration control including assignment / modification of ARQ configuration, HARQ

configuration, and Discontinuous Reception (DRX) configuration• •

QoS control including assignment / modification of semi-persistent configuration information for

DL and UL, assignment/ modification of parameters for UL rate control in the UE, i.e. allocation of

a priority and a prioritized bit rate (PBR) for each RB

•

Measurement configuration & reporting for intra-frequency, inter frequency, inter RAT mobility •

Other functions including transfer of dedicated NAS information & non-3GPP dedicated

information, transfer of UE radio access capability information, and support for E-UTRAN sharing

(multiple PLMN identities)

• •

Support of self-configuration & self-optimization •

Table 6: RRC Functionality Mapping


The LTE RRC protocol is significantly different from UMTS RRC – so as to control and configure the new LTE-MAC layer, driven by the new OFDM-based physical layer. Some of the aspects in which LTE RRC moves away from UMTS RRC are Reduced SystemInformationBroadcast messages, only two RRC states – RRC_IDLE and RRC_CONNECTED, and only three Signaling Radio Bearers - SRB (0, 1, 2).

PACKET DATA CONVERGENCE PROTOCOL (PDCP)

PDCP provides data transfer, header compression of IP data flows using the Robust Header Compression (ROHC) algorithm, and ciphering services to both control plane (RRC) and user-plane (Application) entities. PDCP provides protection and verification services to control plane protocols. Figure 6 illustrates the functional entities within the PDCP protocol. PDCP uses the services provided by the RLC sub-layer. PDCP is used for Signaling Radio Bearer (SRB) and Data Radio Bearer (DRB) mapped on the DCCH and DTCH types of logical channels. PDCP is not used for any other type of logical channels.

PDCP Functions C-Plane U-Plane

Header compression and decompression of IP data flows using the ROHC protocol •

Data transfer • •

Maintenance of PDCP sequence numbers for radio bearers mapped on RLC Acknowledged

Mode (AM)• •

In-sequence delivery of upper layer PDUs at handover • •

Elimination of duplicate lower layer SDUs at handover for radio bearers mapped on RLC AM • •

Ciphering & deciphering • •

Integrity protection & integrity verification •

Timer-based discard of lower layer SDUs • •

Duplicate discarding of lower layer SDUs • •

Table 7: PDCP Functionality Mapping

One DTCH per service (RAB) per UE

for bearer traffic

Two DCCHs per UE for SRB1 and SRB2 each

PDCCH

PUCCH

PCFICH

PHICH Common shared channels used to control other channels between UEs

and E-UTRAN

Logical Channels at MAC

Transport Channels at

MAC

Physical Channels at

PHY

BCCHCCCHDCCHDTCHMCCH

MTCH

DL-SCH

BCCHBCHPBCHPCCHPCH

PDSCH

MCCHMCHPMCH

Uplink Channels

Downlink Channels

PRACH

PUSCH UL-SCHCCCHDTCHDCCH

RACHdR

adio Spectrum

Figure 6: PDCP Functional Entities (Source [4])

LTE PDCP diverges from UMTS PDCP by supporting ciphering for both user plane and control plane data, and integrity protection for control plane data. LTE PDCP does not support IPHC, while UMTS PDCP does. LTE PDCP supports control plane transfer for DCCH while UMTS PDCP does not. LTE PDCP supports SDU discard timer while UMTS PDCP does not.


RADIO LINK CONTROL (RLC)

RLC is responsible for segmentation and reassembly as well as the error correction procedure (through ARQ). An RLC entity can be configured to perform data transfer in one of the following three modes: Transparent Mode (TM), where the RLC acts as a pass-through layer for the data; Unacknowledged Mode (UM), where the RLC executes all the functions except for storing and re-transmission of data; and Acknowledged Mode (AM) where the RLC implements its full functionality.

Each of these modes differs in the way the RLC functional entities are used as illustrated in Figure 7. Table 8 lists all the critical functions implemented by the RLC and how they are used in different modes.

RLC Functions TM UM AM

Transfer of Upper Layer PDUs • • •

Error Correction through ARQ •

Concatenation, segmentation & reassembly of RLC SDUs • •

Re-segmentation of RLC data PDUs •

In-sequence delivery of upper layer PDUs • •

Duplicate detection RLC PDUs • •

RLC SDU discard • •

RLC re-establishment • • •

Protocol error detection & recovery (Discarding RLC PDU that contains reserved or invalid values) • • •

Table 8: Mapping RLC Functions to Different Modes of Operation

LTE RLC diverges from UMTS RLC by not supporting ciphering for user plane PDUs (instead, the ciphering function is pushed to PDCP), supporting HARQ reordering, and handling total RLC PDU size for segmentation instead of Transport Block (TB) size. LTE RLC does not have SDU discard timer whereas UMTS RLC supports it.

Figure 7: RLC Functional Entities

MEDIUM ACCESS CONTROL (MAC)

MAC is responsible for dynamically managing air interface resources among various UEs. The MAC layer achieves this via managing logical resources called Logical Channels (depending upon what type of data is transferred) and Transport Channels (depending upon how and with which type of characteristics the data is transferred).


Figure 8: MAC Function Mapping to Logical/Transport Channels

Table 9 and Table 10 give brief descriptions of various Logical and Transport channels. Figure 8 maps MAC functionality to Logical and Transport channels (e.g., Priority handling is implemented for BCCH, CCCH, DCCH and DTCH; whereas Multiplexing and De-multiplexing is implemented for all these four channels plus MCCH and MTCH.)

Channel Purpose

PCCH Paging

BCCH System Information Broadcast

CCCH RRC messages transfer

DCCH UE specific RRC messages and NAS messages transfer

DTCH User Data transfer

MCCH MBMS Control messages transfer

MTCH MBMS User data Transfer

Table 9: MAC Logical Channels

Channel Purpose

PCH Paging

BCH System Information Broadcast

DL-SCH All control signaling and user data in DL

UL-SCH All control signaling and user data in UL

RACH Random Access

MCH Multicast and Broadcast

Table 10: MAC Transport Channels

There are two MAC entities, one in the UE and another in the E-UTRAN. The functions in these two entities are different as illustrated in Table 11. MAC is responsible for data transfer in both the uplink and downlink direction using transport channels. Characteristics of transport channels are defined by transport format. MAC also allocates radio resources. E-UTRAN MAC prioritizes UEs for allocation of UL/DL-grant (radio resource budget for data transmission). MAC uses the logical channel prioritization procedure to allocate grants among logical channels of a UE.


MAC Functions UE EUTRAN

Mapping between logical channels & 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 prioritization •

Transport format selection • •

Table 11: MAC Function mapping to UE and EUTRAN MAC entities

Figure 9 illustrates how various logical, transport, and physical channels are mapped to each other in a cell along with information on respective reference points (i.e., which channel is identified at which layer) for each channel. One of the major differences from UMTS (Rel-9) MAC is that LTE MAC does not have any dedicated transport channel. Also, LTE-MAC carries out both UL and DL scheduling and works on 1ms TTI. LTE MAC takes on the responsibility to manage per-UE QoS, which was done by RRM in UMTS.

SUMMARY

3GPP’s LTE initiative is spurring a complete relook at both the radio interface and the core network design to not only simplify network architecture and lower deployment costs (by reducing the number of network elements and moving to an all-IP core), but also to enable truly broadband, mobility-enabled wireless access to media-rich content. 3GPP has been driving toward finalizing the LTE Release-8 standardization activity by the end of 2008, although the likely completion date looks more like Q1 2009. Provided the battered financial markets witness a respectable turnaround in the next nine to twelve months, LTE rollouts should be well on their way by 2009-2010, paving the way for a new era in high-speed, high-quality personalized mobile communication.

13

©2009 Continuous Computing Corporation.

Continuous Computing reserves the right to make changes to specifications, with or without notice, at its sole discretion. Continuous Computing, the Continuous Computing logo, Create | Deploy | Converge, Embedded Solution Partners, The Embedded Solution Experts, Flex8, Flex21, FlexChassis, FlexCompute, FlexCore, FlexDSP, FlexPacket, FlexStore, FlexSwitch, FlexTCA, Quick!Start, TAPA, Trillium, Trillium+plus, the Trillium logo, and upSuite are trademarks or registered trademarks of Continuous Computing Corporation. Other names and brands may be claimed as the property of others.

MC00xxx 0209/BP/EC

Global Headquarters

9450 Carroll Park DriveSan Diego, CA 92121 USAT +1.858.882.8800F [email protected]

www.ccpu.com

REFERENCES

[1] 3GPP TS 29.274 V1.3.0 (2008-10); Evolved GPRS Tunnelling Protocol for Control Plane (GTPv2-C); Stage 3 (Release 8)

[2] 3GPP TS 24.301 V1.0.0 (2008-10); Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Stage 3 (Release 8)

[3] 3GPP TS 36.321 V8.3.0 (2008-09); Medium Access Control (MAC) protocol specification (Release 8)

[4] 3GPP TS 36.323 V8.3.0 (2008-09); Packet Data Convergence Protocol (PDCP) specification (Release 8)

[5] 3GPP TS 36.322 V8.3.0 (2008-09); Radio Link Control (RLC) protocol specification (Release 8)

[6] 3GPP TS 36.331 V8.3.0 (2008-09); Radio Resource Control (RRC) protocol specification (Release 8)

[7] 3GPP TS 36.413 V8.3.0 (2008-09); S1 Application Protocol (S1AP) specification (Release 8)

[8] 3GPP TS 36.423 V8.3.0 (2008-09); X2 Application Protocol (X2AP) specification (Release 8)

[9] 3GPP TS 29.281 V1.1.0 (2008-10); GPRS Tunnelling Protocol for User Plane (GTPv1-C); Stage 3 (Release 8)

CCPU LTE Protocol Perspective-2

Documents

tracking area

ip data flows

radio link

radio bearers

udp ip egtp

plane protocol

mac function

s1 application