Unlocking Long Term Evolution (LTE): A Protocol Perspective


Published on

Published in: Technology
1 Comment
No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Unlocking Long Term Evolution (LTE): A Protocol Perspective

  1. 1. WHITE PAPER Unlocking Long Term Evolution (LTE): A Protocol Perspective by Debjani De INTRODUCTION and Ravi Raj Bhat 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. 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
  2. 2. 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. S3 S4 SGSN S10 Packet GW MME MME S5/S8 S12 S11 RNC Serving GW S1-MME S1-U -U S1 S1- MM X2 E X2 eNodeB eNodeB X2 eNodeB 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.
  3. 3. Unlocking Long Term Evolution (LTE): A Protocol Perspective 3 Mobile WiMax LTE UMB (802.16e-2005) DL Access OFDMA OFDMA OFDMA UL Access Single Carrier FDMA OFDMA OFDMA & CDMA 100Mbps in DL & 50Mbps Combined UL & DL, 275Mbps in DL & 75Mbps Data Rate in UL with 20MHz 74Mbps with 20MHz in UL with 20 MHz 1.25, 3.5, 5, 7, 8.75, 10, 14, Flexible bandwidth 1.4, 3 5, 10, 15, 20 1.25, 2.5, 5, 10, 20 17.5, 20, 28 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 Authentication and Key Extensible Authentication Security EAP Agreement (AKA) Protocol (EAP) Binary Phase Shift Keying (BPSK), Quadrature PSK BPSK, QPSK, 16QAM, QPSK, 8PSK, 16 Modulation (QPSK), Quadrature 64QAM QAM, 64 QAM Amplitude Modulation (16QAM), 64QAM Convolutional, Turbo, Low Convolutional, Turbo, Block Channel Coding Convolutional and Turbo Density Parity Check Code Turbo, LDPC (LDPC) Within 3GPP & non-3GPP Within WiMax & non-WiMax Within 3GPP2 & non- Mobility (WiMax, 3GPP2) (3GPP, 3GPP2) 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.
  4. 4. Unlocking Long Term Evolution (LTE): A Protocol Perspective 4 Physical Parameters Channel Name Dir Purpose Modulation Channel Coding Rate 1/3 Tail Biting Physical Broadcast PBCH DL Carries Broadcast Information QPSK Convolutional Channel coding Rate 1/2 Physical Random PRACH UL Carries Random Access Preamble QPSK Convolutional Access Channel coding Physical Multicast QPSK, 16QAM, Rate 1/3 Turbo PMCH DL Carries Multicast Control & Data PDUs Channel 64QAM coding Informs the UE about the resource allocation of PCH and DL-SCH, and Rate 1/3 Tail Biting Physical Downlink Hybrid ARQ information related to DL- PDCCH DL QPSK Convolutional Control Channel SCH coding Carries the uplink scheduling grant Carries Hybrid ARQ ACK/NACKs in response to downlink transmission Variable Rate Block Physical Uplink Code, Rate 1/3 Tail PUCCH UL BPSK, QPSK Control Channel Carries Scheduling Request (SR) biting Convolutional Code Carries CQI reports Physical Downlink Carries DL Broadcast/Shared Control/ QPSK, 16QAM, Rate 1/3 Turbo PDSCH DL Shared Channel Data PDUs 64QAM coding Physical Uplink QPSK, 16QAM, Rate 1/3 Turbo PUSCH UL Carries UL Shared Control/Data PDUs Shared Channel 64QAM coding Physical HARQ Rate 1/3 Repetition PHICH DL Carries HARQ ACK/NACK for UL BPSK Indicator Channel Code Physical Control Rate 1/16 Block PCFICH Format Indicator DL Carries No of OFDM Symbols for PDCCH QPSK Code Channel 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. User App User App IP IP PDCP PDCP eGTP-U eGTP-U eGTP-U eGTP-U eGTP-U eGTP-U RLC RLC UDP UDP UDP UDP UDP UDP MAC MAC IP IP IP IP IP IP PHY PHY UE eNodeB eNodeB S-GW P-GW Uu X2-U S1-U S5/S8 Figure 2: User-plane Protocol Stacks
  5. 5. Unlocking Long Term Evolution (LTE): A Protocol Perspective 5 EMM/ESM EMM/ESM RRC RRC X2-AP X2-AP S1-AP S1-AP eGTP-C eGTP-C eGTP-C eGTP-C eGTP-C PDCP PDCP SCTP SCTP SCTP SCTP UDP UDP UDP UDP UDP RLC RLC MAC MAC IP IP IP IP IP IP IP IP IP PHY PHY UE eNB eNB MME MME Uu X2-C S1-MME S10 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 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). Network-Initiated UE-Initiated Packet Data Network (PDN) EPS Bearer Context Activation Connectivity EPS Bearer Context Modification PDN Disconnect Update EPS Bearer Context Deactivation Bearer Resource Allocation Update Protocol Configuration 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 Specific procedures used only for mobility management n EMM Connection management procedures used only for connection management
  6. 6. Unlocking Long Term Evolution (LTE): A Protocol Perspective 6 Network-Initiated UE-Initiated GUTI Reallocation Periodic Tracking Area Update Authentication Normal Tracking Area Update Security Mode Control Attach Identification Detach EMM Information Service Request Detach Legend Paging Connection Specific Common Management 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 Echo Request/Response • • • • • • Path Version not Supported • • • • • • Suspend/Resume • • Session Creation and Deletion • • • Tunnel Bearer Creation, Modification, Update and Deletion • • Downlink Data Notification • Forward Relocation • Forward tunnel creation • Mobility Context/Identity request/response • • • Forward SRNS Context • • • Detach • Table 3: GTPv2-C Functionality Mapping
  7. 7. Unlocking Long Term Evolution (LTE): A Protocol Perspective 7 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.
  8. 8. Unlocking Long Term Evolution (LTE): A Protocol Perspective 8 S1-AP Functions E-UTRAN MME SAE Bearer Setup/Modify • SAE Bearer Release • • UE Context Initial Context Transfer function • / Bearer UE context Release function • • UE context Modification function • Handover Preparation • Handover Resource Allocation • Handover Notification • Handover Path Switch Request • Handover Cancellation • Status Transfer • • Paging • Loc Location Reporting • NAS transport • • Mgmt S1 CDMA2000 Tunneling • • Reset • • Error Indication • • S1 Setup • Tunnel 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
  9. 9. Unlocking Long Term Evolution (LTE): A Protocol Perspective 9 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 Physical Transport Logical Channels Channels at Channels at at MAC PHY MAC Two DCCHs per UE for DCCH SRB1 and SRB2 each PUSCH UL-SCH DTCH Uplink Channels CCCH PRACH RACHd One DTCH per service (RAB) per UE MCCH for bearer traffic Radio Spectrum PMCH MCH MTCH MCCH DTCH DL-SCH Downlink Channels PDSCH DCCH CCCH BCCH PCH PCCH PBCH BCH BCCH PUCCH PHICH Common shared channels used to control other channels between UEs PDCCH and E-UTRAN PCFICH 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.
  10. 10. 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 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).
  11. 11. 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 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.
  12. 12. Unlocking Long Term Evolution (LTE): A Protocol Perspective 12 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. 13. 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 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) ©2009 Continuous Computing Corporation. Global Headquarters Continuous Computing reserves the right to make changes to specifications, with or without notice, at its sole discretion. 9450 Carroll Park Drive Continuous Computing, the Continuous Computing logo, Create | Deploy | Converge, Embedded Solution Partners, San Diego, CA 92121 USA The Embedded Solution Experts, Flex8, Flex21, FlexChassis, FlexCompute, FlexCore, FlexDSP, FlexPacket, FlexStore, T +1.858.882.8800 FlexSwitch, FlexTCA, Quick!Start, TAPA, Trillium, Trillium+plus, the Trillium logo, and upSuite are trademarks or registered F +1.858.777.3388 trademarks of Continuous Computing Corporation. Other names and brands may be claimed as the property of others. info@ccpu.com MC00xxx 0209/BP/EC www.ccpu.com