WHITE PAPER

Unlocking Long Term Evolution (LTE): A Protocol Perspective

by Debjani De and Ravi Raj Bhat
INTRODUCTION In todays 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. Todays 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 trafc 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 trafc. 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 DataOptimized (1xEV-DO in 2000), EV-DO Rev.A (with VoIP support in 2004), EV-DO Rev.B (with multicarrier support in 2006), and nally 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 HighSpeed Uplink Packet Access (HSUPA) in 2005, and Release-7 in 2007 culminating at 14Mbps peak bandwidth. Long Term Evolution (LTE) is 3GPPs 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 trafc 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 efciency 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.
Global Headquarters Continuous Computing 9450 Carroll Park Drive San Diego, CA 92121 USA T +1.858.882.8800 F +1.858.777.3388 info@ccpu.com www.ccpu.com

Unlocking Long Term Evolution (LTE): A Protocol Perspective

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 trafc (delivering two to four times the spectral efciency 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), 3GPPs 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 nicky Gen Y consumers.

S3 S4

SGSN
S10

Packet GW MME
S11 S5/S8 S12

MME

RNC

Serving GW
S1-MME
S1 -U

S1-U
S1-

eNodeB

X2

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 denes 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 xed 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 3GPP2s UMB and IEEEs 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.

MM E

X2

X2

eNodeB

eNodeB

Figure 1: LTE Network Architecture

Unlocking Long Term Evolution (LTE): A Protocol Perspective

LTE
DL Access UL Access Data Rate Flexible bandwidth Automatic Repeat Request (ARQ) Hybrid ARQ (HARQ) Time Division Duplex (TDD) Frequency Division Duplex (FDD) Flexible UL Resource Allocation Flexible DL Resource Allocation Security OFDMA Single Carrier FDMA 100Mbps in DL & 50Mbps in UL with 20MHz 1.4, 3 5, 10, 15, 20 Yes Mandatory Yes Yes Yes Yes Authentication and Key Agreement (AKA) Binary Phase Shift Keying (BPSK), Quadrature PSK Modulation (QPSK), Quadrature Amplitude Modulation (16QAM), 64QAM

Mobile WiMax (802.16e-2005)

OFDMA OFDMA Combined UL & DL, 74Mbps with 20MHz 1.25, 3.5, 5, 7, 8.75, 10, 14, 17.5, 20, 28 Yes Optional Yes Yes Yes Yes Extensible Authentication Protocol (EAP)

UMB
OFDMA OFDMA & CDMA 275Mbps in DL & 75Mbps in UL with 20 MHz 1.25, 2.5, 5, 10, 20 Yes Mandatory Yes Yes Yes Yes EAP

BPSK, QPSK, 16QAM, 64QAM

QPSK, 8PSK, 16 QAM, 64 QAM

Convolutional, Turbo, Low Channel Coding Convolutional and Turbo Within 3GPP & non-3GPP (WiMax, 3GPP2) Density Parity Check Code (LDPC) Mobility Within WiMax & non-WiMax (3GPP, 3GPP2)

Convolutional, Turbo, Block Turbo, LDPC Within 3GPP2 & non3GPP2 (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 denes 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 exible, 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 xed 5MHz channels, LTE can scale from 1.25 to 20MHz. This exibility 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 signicantly), it also enables interworking with 3GPP and non-3GPP-based legacy networks, which allows for service continuity.

Unlocking Long Term Evolution (LTE): A Protocol Perspective

Channel

Name Physical Broadcast Channel Physical Random Access Channel Physical Multicast Channel

Dir

Purpose

Physical Parameters Modulation QPSK Channel Coding Rate 1/3 Tail Biting Convolutional coding Rate 1/2

PBCH

DL

Carries Broadcast Information

PRACH

UL

Carries Random Access Preamble

QPSK QPSK, 16QAM, 64QAM

Convolutional coding Rate 1/3 Turbo coding

PMCH

DL

Carries Multicast Control & Data PDUs Informs the UE about the resource allocation of PCH and DL-SCH, and

PDCCH

Physical Downlink Control Channel

DL

Hybrid ARQ information related to DLSCH Carries the uplink scheduling grant Carries Hybrid ARQ ACK/NACKs in response to downlink transmission

Rate 1/3 Tail Biting QPSK Convolutional coding

Variable Rate Block BPSK, QPSK Code, Rate 1/3 Tail biting Convolutional Code

PUCCH

Physical Uplink Control Channel

UL

Carries Scheduling Request (SR) Carries CQI reports

PDSCH PUSCH PHICH

Physical Downlink Shared Channel Physical Uplink Shared Channel Physical HARQ Indicator Channel Physical Control Format Indicator Channel

DL UL DL

Carries DL Broadcast/Shared Control/ Data PDUs Carries UL Shared Control/Data PDUs Carries HARQ ACK/NACK for UL

QPSK, 16QAM, 64QAM QPSK, 16QAM, 64QAM BPSK

Rate 1/3 Turbo coding Rate 1/3 Turbo coding Rate 1/3 Repetition Code Rate 1/16 Block Code

PCFICH

DL

Carries No of OFDM Symbols for PDCCH

QPSK

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 trafc) and User-plane (responsible for transporting user trafc). Figure 2 illustrates the User-plane protocol stacks, while Figure 3 illustrates Control-plane protocol stacks at various nodes and interfaces.
User App IP PDCP RLC MAC PHY PDCP RLC MAC PHY eGTP-U UDP IP eGTP-U UDP IP eGTP-U UDP IP eGTP-U UDP IP eGTP-U UDP IP User App IP eGTP-U UDP IP

UE
Uu

eNodeB
X2-U

eNodeB
S1-U

S-GW
S5/S8

P-GW

Figure 2: User-plane Protocol Stacks

Unlocking Long Term Evolution (LTE): A Protocol Perspective

EMM/ESM RRC PDCP RLC MAC PHY RRC PDCP RLC MAC PHY IP IP IP X2-AP SCTP X2-AP SCTP S1-AP SCTP

EMM/ESM S1-AP SCTP eGTP-C UDP eGTP-C eGTP-C UDP UDP eGTP-C UDP eGTP-C UDP

IP

IP

IP

IP

IP

IP

UE
Uu

eNB
X2-C

eNB
S1-MME

MME
S10

MME
S11 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 briey describe each protocol layers 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. Networkinitiated procedures supported by this layer are to create, activate, modify, and delete EPS bearers. UEinitiated procedures supported by this layer are to request to create, modify, and release EPS bearers with specic 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).
Network-Initiated EPS Bearer Context Activation EPS Bearer Context Modification EPS Bearer Context Deactivation Protocol Configuration UE-Initiated Packet Data Network (PDN) Connectivity PDN Disconnect Update Bearer Resource Allocation Update Bearer Resource Release Update

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 Specic procedures used only for mobility management n EMM Connection management procedures used only for connection management

Unlocking Long Term Evolution (LTE): A Protocol Perspective

Network-Initiated GUTI Reallocation Authentication Security Mode Control Identification EMM Information Detach Paging

UE-Initiated Periodic Tracking Area Update Normal Tracking Area Update Attach Detach Service Request

Legend Connection Management Specific Common

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 Identier), 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 trafc 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 UEs 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 specications, 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 Echo Request/Response Path Version not Supported Suspend/Resume Session Creation and Deletion Tunnel Bearer Creation, Modication, Update and Deletion Downlink Data Notication Forward Relocation Forward tunnel creation Mobility Context/Identity request/response Forward SRNS Context Detach S11 S4 S10 S5/S8 S3 S16

Table 3: GTPv2-C Functionality Mapping

Unlocking Long Term Evolution (LTE): A Protocol Perspective

GTPV1-U Functions Echo Request/Response Error Indication End Marker Transfer of User Payload

S1-U

S5/S8

S12

X2-U

Table 4: GTPv1-U Functionality Mapping While UMTS GTP mainly manages Packet Data Protocol (PDP) contexts, which are intended to carry only data trafc, LTE eGTP manages EPS bearers (i.e., carries all types of trafc). 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 trafc load to each other so that UEs can be moved to eNBs that are lightly loaded. n General Error Reporting allows identication and reporting of general error situations, for which function specic error messages have not been dened. 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 Conguration 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 ow 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.

Unlocking Long Term Evolution (LTE): A Protocol Perspective

S1-AP Functions SAE Bearer Setup/Modify UE Context / Bearer SAE Bearer Release Initial Context Transfer function UE context Release function UE context Modication function Handover Preparation Handover Resource Allocation Handover Handover Notication Path Switch Request Handover Cancellation Status Transfer Loc Paging Location Reporting NAS transport S1 CDMA2000 Tunneling Reset Error Indication S1 Setup Tunnel Conguration Update Overload UE Capability Info Indication Trace

E-UTRAN

MME

Mgmt

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 layers information ow. 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 Broadcast of information related to the Non-Access Stratum (NAS) and Access Stratum Cell selection and Re-selection Establishment / Modication / Release of RRC Connection Paging Establishment / Modication / Release of Data Radio Bearers (DRB) Radio conguration control including assignment / modication of ARQ conguration, HARQ conguration, and Discontinuous Reception (DRX) conguration QoS control including assignment / modication of semi-persistent conguration information for DL and UL, assignment/ modication 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 conguration & 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-conguration & self-optimization E-UTRAN UE

Table 6: RRC Functionality Mapping

Unlocking Long Term Evolution (LTE): A Protocol Perspective

The LTE RRC protocol is signicantly different from UMTS RRC so as to control and congure 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 ows using the Robust Header Compression (ROHC) algorithm, and ciphering services to both control plane (RRC) and user-plane (Application) entities. PDCP provides protection and verication 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 Header compression and decompression of IP data ows 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 verication Timer-based discard of lower layer SDUs Duplicate discarding of lower layer SDUs C-Plane U-Plane

Table 7: PDCP Functionality Mapping

Physical Channels at PHY PUSCH PRACH

Transport Channels at MAC UL-SCH RACHd MCH

Logical Channels at MAC DCCH

Two DCCHs per UE for SRB1 and SRB2 each Uplink Channels One DTCH per service (RAB) per UE for bearer trafc

DTCH CCCH

PMCH

MCCH MTCH MCCH DTCH DCCH

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 Spectrum

PDSCH

DL-SCH

Downlink Channels

PBCH PUCCH PDCCH PCFICH PHICH

PCH

BCH

CCCH BCCH PCCH BCCH

Common shared channels used to control other channels between UEs and E-UTRAN

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

Unlocking Long Term Evolution (LTE): A Protocol Perspective

10

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 congured 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 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) TM UM AM

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

Unlocking Long Term Evolution (LTE): A Protocol Perspective

11

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 PCCH BCCH CCCH DCCH DTCH MCCH MTCH Purpose Paging System Information Broadcast RRC messages transfer UE specic RRC messages and NAS messages transfer User Data transfer MBMS Control messages transfer MBMS User data Transfer

Table 9: MAC Logical Channels

Channel PCH BCH DL-SCH UL-SCH RACH MCH Purpose Paging System Information Broadcast All control signaling and user data in DL All control signaling and user data in UL Random Access 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 dened 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.

Unlocking Long Term Evolution (LTE): A Protocol Perspective

12

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

UE

EUTRAN

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 identied 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 3GPPs 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 nalizing the LTE Release-8 standardization activity by the end of 2008, although the likely completion date looks more like Q1 2009. Provided the battered nancial 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

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 specication (Release 8) [4] 3GPP TS 36.323 V8.3.0 (2008-09); Packet Data Convergence Protocol (PDCP) specication (Release 8) [5] 3GPP TS 36.322 V8.3.0 (2008-09); Radio Link Control (RLC) protocol specication (Release 8) [6] 3GPP TS 36.331 V8.3.0 (2008-09); Radio Resource Control (RRC) protocol specication (Release 8) [7] 3GPP TS 36.413 V8.3.0 (2008-09); S1 Application Protocol (S1AP) specication (Release 8) [8] 3GPP TS 36.423 V8.3.0 (2008-09); X2 Application Protocol (X2AP) specication (Release 8) [9] 3GPP TS 29.281 V1.1.0 (2008-10); GPRS Tunnelling Protocol for User Plane (GTPv1-C); Stage 3 (Release 8)

2009 Continuous Computing Corporation. Continuous Computing reserves the right to make changes to specications, 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 Drive San Diego, CA 92121 USA T +1.858.882.8800 F +1.858.777.3388 info@ccpu.com www.ccpu.com