LTE Signalling 1 EPS Overview

Transcription

1 LTE Signalling 1 EPS Overview 2 NAS Protocols (EMM & ESM) 3 S1 and S11 Interface (S1AP & GTP) 4 Uu Interface I (RRC) 5 Uu Interface II (PDCP & RLC) 6 Uu Interface III (MAC) 7 Uu Interface IV (Layer 1) 8 X2 Interface (X2AP) 9 EPS Interworking 10 Signalling Flows Tjärhovsgatan 21, 5th floor SE Stockholm Sweden Tel Fax info@apistraining.com Foldouts

2 The use of a term in this document should not be interpreted in a manner that would affect the validity or legal status of any proprietary rights that may be attached to that term. This is a training document and as such simplifies what are often highly complex technological issues. The system or systems described here should therefore be seen in that light, i. E. as simplifications rather than generalizations. Due to ongoing progress in methodology, design, its contents are furthermore subject to revision without prior notice. assumes no legal responsibility for any error or damage resulting from the use of this document. Copyright All rights are reserved. This training material is the confidential and proprietary property of Apis Technical Training AB. It is to be used solely for the purpose for which it was produced and is not to be copied or otherwise reproduced without the prior written permission of. To our best knowledge, the information in this document is accurate as per the date of publication. Other than by prior written agreement, will not update or otherwise advise of errors in the document which may be brought to our attention. All trademarks are trademarks of their respective owners.. welcomes customer feedback as part of a process of ongoing development of our documentation in order to better meet our customers' needs. Please submit your comments to our Head Office in Stockholm. Tjärhovsgatan 21, 5 th floor SE Stockholm Sweden info@apistraining.com

3 1 EPS Overview 1.1 BACKGROUND EVOLVED UTRA & UTRAN Network Architecture Requirements on E-UTRA/E-UTRAN Overview of Technical Solutions Evolved HSPA (ehspa) EVOLVED PACKET CORE Network Architecture Requirements on the EPC REFERENCES LSIG - Overview Copyright All rights reserved. 1-1

4 1.1 Background 3GPP Long Term Evolution (LTE) is the name given to a project within the Third Generation Partnership Project (3GPP) to improve the UMTS 3G mobile system standard to cope with future requirements. Goals include improving efficiency, lowering costs, reducing complexity, improving services, making use of new spectrum opportunities and better integration with other open standards (such as WLAN and WiMAX). Thus, the term LTE really means a standardisation project. The final outcome from this project will be a new set of standards defining the functionality and requirements of an evolved, packet based, radio access network and a new radio access. The new radio access network is referred to as the Evolved UTRAN (E-UTRAN) and the new radio access is referred to as the Evolved UTRA (E-UTRA). The LTE project is part of 3GPP Release 8. The term LTE has become more or less synonymous to the (proper) terms Evolved UTRA (the new radio access) and Evolved UTRAN (the new radio access network). With this in mind, the author has taken the freedom to use the terms LTE and E-UTRA interchangeably for the new OFDM-based radio interface. The work on LTE started with a workshop in Nov 2004 in Toronto, Canada. The workshop was open to members and non-members of 3GPP. Operators, vendors and research institutes presented contributions with views and proposals on the future evolution of 3G. A set of high level requirements were initially identified: Reduced cost per transmitted bit More services at lower cost with better user experience Flexibility of use of existing and new frequency bands Simplified architecture, open interfaces Reasonable terminal power consumption. It was also agreed that the E-UTRA/E-UTRAN standard should bring significant improvements to justify the standardization effort and that it should avoid unnecessary options (i.e. reduced overall complexity as compared to UMTS). A feasibility study on the UTRA & UTRAN Long Term Evolution was then started in December The objective was "to develop a framework for the evolution of the 3GPP radio access technology towards a high data rate, low latency and packet optimized radio access technology". The study focused on supporting services exclusively from the Packet Switched (PS) domain. LSIG - Overview Copyright All rights reserved. 1-2

5 In parallel to, and coordinated with, the LTE project there is also a 3GPP standardisation project relating to the core network. This project is called System Architecture Evolution (SAE) and aims at standardising the Evolved Packet Core (EPC). The SAE project was started in December 2004, with the objective to develop a framework for an evolution or migration of the 3GPP system to a higher data rate, lower latency, packet optimized system that supports multiple RATs. The EPC is a fully IP-based core network ( all-ip ) supporting access not only via GERAN, UTRAN and E-UTRAN but also via WiFi, WiMAX and wired technologies such as xdsl. The SAE project is also a part of 3GPP Release 8. A short introduction to the Evolved UTRA/N can be found in section 1.2 in this chapter, and an introduction to the EPC in section 1.3. The combination of the E-UTRAN and the EPC is referred to as the Evolved Packet System (EPS). Release/Phase Comment Freeze year Phase 1 Phase 2 Release 96 Release 97 Release 98 Release 99 Release 4 Release 5 Release 6 Release 7 Release 8 GSM (interim configuration) GSM (basic configuration) 14.4 kb/s, HSCSD GPRS AMR EDGE, UTRAN Split Architecture IMS with GERAN/UTRAN access HSDPA IMS with IP-CAN access HSUPA IMS for NGN Evolved HSPA E-UTRAN and EPC Stage 1: September 2005 Stage 2: September 2006 Stage 3: December 2007 Stage 1: March 2008 Stage 2: June 2008 Stage 3: December 2008? Release 9 or 10 LTE Advanced (LTE-A) Figure 1-1: 3GPP phases and releases 2010? The Stage 2 set (general architecture, protocol structure and key concepts) of LTE/SAE standardisation documents where, according to 3GPP, completed in June though several key features where actually delayed until autumn The Stage 3 work (i.e. detailed protocol specifications) is, at the time of writing, expected for completion in December One should be aware that updates/changes/additions to the E-UTRAN/EPC specs are expected throughout Real-life deployment of LTE/SAE-based networks should therefore not be expected until The reader is strongly encouraged to regularly check the 3GPP website ( for new versions of the standardisation documents referenced at the end of each chapter in the current document. LSIG - Overview Copyright All rights reserved. 1-3

6 1.2 Evolved UTRA & UTRAN Network Architecture Uu enb S1-MME MME S6a HSS X2-C X2-U S11 PCRF Gx Rx Uu enb S1-U SGW S5 PGW SGi IMS/Internet/ E-UTRA E-UTRAN EPC Figure 1-2: The Evolved Packet System (EPS), simplified The Evolved UTRAN consists of the evolved NodeB (enb), providing the E-UTRA User Plane (UP) and Control Plane (CP) protocol terminations towards the UE. The enb can be seen as a combination of the UMTS NodeB and Radio Network Controller, hosting functions like dynamic resource allocation (through packet scheduling) and radio resource management. The enbs are interconnected with each other by means of the X2- interface, e.g. for support of handovers without data loss. The X2-interface consists of a UP instance (X2-U) and a CP instance (CP) and is described in more detail in chapter 8. The enbs are connected by means of the S1-interface to the EPC. The S1- interface supports a many-to-many relation between enbs and MME/SGWs and is (logically) divided into a UP instance (S1-U) and a CP instance (S1-MME). The S11-interface allows exchange of control signalling between the MME and the SGW and is a part of the EPC rather than the E-UTRAN. The S1- and S11-interfaces are described in chapter Requirements on E-UTRA/E-UTRAN At the onset of the LTE project a series of requirement targets relating to performance, complexity and interworking were defined. Some of these are listed below: Peak data rate: at least 100 Mb/s DL and 50 Mb/s UL (assuming 20 MHz system bandwidth). Benchmarking targets for data rates is set to 3-4 times those of HSPA as of R6 (5 MHz bandwidth). Control Plane (CP) latency: transition time less than 100 ms from an idle state to an active state, and less than 50 ms between a dormant state (such as R6 CELL_PCH) and an active state. LSIG - Overview Copyright All rights reserved. 1-4

7 User Plane (UP) latency: less than 5 ms in unloaded condition (single user with single data stream) for small IP packet. CP capacity: at least 200 users per cell should be supported in the active state (5 MHz system bandwidth). Mobility: E-UTRAN should be optimized for low mobile speed (0-15 km/h) and higher speeds ( km/h) should be supported with high performance. Mobility shall be maintained between km/h (up to 500 km/h depending on the frequency band). Coverage: the throughput and mobility targets above should be met for 5 km cells with a slight degradation for 30 km cells. Cells range up to 100 km should be possible. Spectrum flexibility: E-UTRA shall operate in different spectrum allocations of different sizes, including 1.4, 3, 5, 10, 15 and 20 MHz in both UL and DL. Operation in paired (FDD) and unpaired (TDD) spectrum shall be supported. Interworking: co-existence in the same geographical area and colocation with GERAN/UTRAN on adjacent channels. E-UTRAN terminals supporting also UTRAN/GERAN operation should be able to support measurement of, and handover from/to, both UTRAN and GERAN. The interruption time during a handover of real-time services between E-UTRAN and UTRAN/GERAN should be less than 300ms. Architecture: the E-UTRAN architecture shall be packet based, supporting real-time and conversational class traffic. The architecture shall minimize the presence of "single points of failure". Complexity: minimised number of options and avoidance of redundant mandatory features Overview of Technical Solutions The E-UTRA radio interface makes exclusive use of shared channels for both data and signalling transfer. In this respect the E-UTRA is similar to the 3GPP R5/R6 High Speed Packet Access, HSPA. The selected radio access technology, however, is very different to HSPA. Where HSPA uses WCDMA, the E-UTRA uses Orthogonal Frequency Division Multiplexing (OFDM). OFDM splits the available system bandwidth into hundreds, or even thousands, of narrow-band so-called sub-carriers. This means that a high bitrate data stream to a given UE is split by the enb into a large number of narrow-band, low bitrate, data streams. The received parallel data streams (sub-carriers) are then de-multiplexed by the UE in order to re-create the original high bitrate data stream. This has several advantages over WCDMA: Better spectral efficieny. More information can be sent using the same system bandwidth as compared to a single-carrier system. LSIG - Overview Copyright All rights reserved. 1-5

8 Flexible/scalable spectrum allocation. The system bandwidth can be expanded in increments (by adding more sub-carriers) as more spectrum becomes available to the operator. For example, the initial system roll-out may use a system bandwidth of 1.4 MHz and at a later stage this may be increased to, say, 5 MHz. Better performance under multipath fading conditions. Multipath effects leads to so-called frequency selective fading, which is much more damaging to a wideband signal than to a narrowband signal (the sub-carrier). There are, of course, drawbacks with OFDM as well. One such drawback is that an OFDM signal exhibits a very high peak-to-average power ratio (PAPR). This is not really a problem on the network side, but leads to very inefficient use of power amplifiers, and hence high power consumption, in a mobile terminal. The E-UTRA system therefore uses a variant of OFDM for uplink transmission that reduces PAPR. This variant of OFDM is called Single-Carrier Frequency Division Multiple Access (SC-FDMA). Despite the name, there is very little that differentiates SC-FDMA from classic OFDM. E-UTRA Uplink Downlink Duplex Band Flow -Fhigh Flow -Fhigh Mode MHz 1980 MHz 2110 MHz 2170 MHz FDD MHz 1910 MHz 1930 MHz 1990 MHz FDD MHz 1785 MHz 1805 MHz 1880 MHz FDD MHz 1755 MHz 2110 MHz 2155 MHz FDD MHz 849 MHz 869 MHz 894MHz FDD MHz 840 MHz 875 MHz 885 MHz FDD MHz 2570 MHz 2620 MHz 2690 MHz FDD MHz 915 MHz 925 MHz 960 MHz FDD MHz MHz MHz MHz FDD MHz 1770 MHz 2110 MHz 2170 MHz FDD MHz MHz MHz MHz FDD 12 [TBD] [TBD] [TBD] [TBD] FDD MHz 787 MHz 746 MHz 756 MHz FDD MHz 798 MHz 758 MHz 768 MHz FDD MHz 1920 MHz 1900 MHz 1920 MHz TDD MHz 2025 MHz 2010 MHz 2025 MHz TDD MHz 1910 MHz 1850 MHz 1910 MHz TDD MHz 1990 MHz 1930 MHz 1990 MHz TDD MHz 1930 MHz 1910 MHz 1930 MHz TDD MHz 2620 MHz 2570 MHz 2620 MHz TDD MHz 1920 MHz 1880 MHz 1920 MHz TDD MHz 2400 MHz Figure 1-3: E-UTRA frequency bands 2300 MHz 2400 MHz TDD The LTE physical layer specifications are written in such a way that it does not really matter on what physical carrier frequency the system is deployed. The table above shows the (currently) supported frequency bands, FDD and TDD, for LTE. LSIG - Overview Copyright All rights reserved. 1-6

9 The use of Multiple Input Multiple Output antenna arrays (MIMO) is an integral part of the E-UTRA standard. The standard supports up to four transmit/receive antennas while the expected baseline configuration is two transmit antennas at the enb and two receive antennas at the UE. In short, MIMO can be used in two different ways: To transmit more information over the radio interface without using more bandwidth than a single antenna system. The number of antennas used increases the system capacity in a linear manner, i.e. two antennas allows twice the amount of information to be transmitted (or, equivalently, the bitrate is doubled). To transmit the same information, with the same bitrate as a single antenna system, but with less output power (or higher reliability). The E-UTRA physical layer channel processing chain (channel coding and modulation) is very similar to what is used today for HSPA. It was agreed at an early stage in the standardisation process that Turbo coding should be used for error correction purposes and that the supported data modulation schemes should be QPSK, 16QAM, and 64QAM for downlink and uplink. The mapping of modulation symbols onto physical channel resources is very different compared to HSPA though. The nature of OFDM gives rise to the concept of 2-dimensional radio resources. The information to be transmitted over the radio interface is mapped onto a 2-dimensional timefrequency resource grid. The OFDM-based E-UTRA physical layer is described in all its glorious detail in chapter 7. (A common misunderstanding is that OFDM, by itself, makes very high bit rates possible. This is not true. Rather, the very high bit rates mentioned for E-UTRA are made possible first and foremost by a higher transmission bandwidth (up to 20MHz), higher order modulation (64QAM) and the support for MIMO with up to four antennas). UE Category Downlink Total DL-SCH bits received per TTI Downlink Max TB bits received per TTI Downlink Total number of soft channel bits Downlink Max. spatial mux. layers Uplink Max TB bits transmitted per TTI Uplink Support for 64QAM Total L2 buffer size (kbyte) No [ 138 ] No [ 687 ] No [ 1373 ] No [ 1832 ] Yes [ 3434 ] Figure 1-4: UE categories There are 5 different UE categories defined for LTE operation. Each LTE UE category combines both downlink and uplink characteristics. This is in stark contrast to HSPA where terminal categories are defined separately for the downlink and for the uplink, giving rise to a large number of possible combinations- each of which must be included in the terminal test specifications. LSIG - Overview Copyright All rights reserved. 1-7

10 The channel and protocol architecture for E-UTRAN layer 2 and layer 3 is quite similar to the one used in UTRAN today. For example, the UE protocol stack is close to identical and the channel hierarchy is still divided into logical, transport and physical channels. The E-UTRA/E-UTRAN layer 3 and layer 2 protocols are described in chapters 2-6 and chapter Evolved HSPA (ehspa) RNC Iu SGSN Iur Gn NB Iu/Gn GGSN Gi IMS / Internet / Figure 1-5: ehspa network architecture A parallel 3GPP R8 project to LTE and SAE is the Evolved High Speed Packet Access, ehspa, project (also referred to as HSPA+). The ehspa features represent a logical evolution from today s HSDPA and HSUPA systems. Roughly speaking, the ehspa project focuses on three areas: Optimising HSPA for real-time packet data services, like VoIP. A large part of achieving this goal relates to a more efficient use of the HSPA control channels. Increasing the system and user throughput. This is achieved by the introduction of higher order modulation (64QAM) and MIMO for HSPA. The theoretical maximum bit rate is around 40Mb/s for the DL and around 12Mb/s for the UL. Simplifying the network architecture. The ehspa NodeB will take on parts of, or all of, the functionality of the RNC. In addition, the SGSN will be removed from the User Plane path (the so-called direct tunnel solution ) allowing IP packets to be routed directly between ehspa NodeB and GGSN. Thus, E-UTRA/E-UTRAN and Evolved HSPA have many concepts in common (collapsed architecture, 64QAM, MIMO). As a matter of fact, the performance (bit rates, spectral efficiency etc) of ehspa R8 is very close to the performance of E-UTRA with 5MHz channel bandwidth. This has led to some level of debate whether to refer to ehspa as a migration path or a complement or a competing technology. LSIG - Overview Copyright All rights reserved. 1-8

11 1.3 Evolved Packet Core Network Architecture UTRAN Iu-PS SGSN GERAN Gb/Iu Gr HSS S3 S4 S12 SPR S6a OCS Sp S1-MME MME S11 OFCS Gy Gz PCRF Gx Rx E-UTRAN X2-C X2-U S1-U S10 SGW S5 PGW SGi IMS / Internet / Trusted IP access S2a S2b epdg SWm S6b HSS/ AAA Non-trusted IP access SWn Figure 1-6: The Evolved Packet System (EPS), detailed Figure 1-6 shows the network architecture of the Evolved Packet Core (EPC). The EPC consists of three main nodes: the Mobility Management Entity (MME), the Serving Gateway (SGW) and the Packet Data Network Gateway (PGW). The MME may be co-located with the SGW, and the SGW may be co-located with the PGW. Hence, the standard allows a completely collapsed one-node core network or a distributed (easily scalable) core network, or any possible combination in-between. The MME connects to the E-UTRAN via the S1-MME interface and is present solely in the CP. It is responsible for handling mobility and security procedures such as network attach, tracking area updates (similar to location/routing area updates) and authentication. The MME also connects to the SGSN via the S3-interface and to the SGW via the S11- interface. These interfaces are used for signalling related to UP bearer management. The SGW connects to the E-UTRAN via the S1-U interface and is present solely in the UP. Its prime responsibility is routing and forwarding of user IP-packets. It acts as a UP anchor when the UE moves between 3GPP radio access technologies (S4-interface). The S12-interface is used for data transfer if the direct tunnel solution is supported in UTRAN. The PGW connects to the SGW via the S5-interface and to external packet data networks (or IMS) via the SGi-interface. It is responsible for the enforcing of QoS and charging policies. It also acts as a UP anchor when the UE moves between 3GPP and non-3gpp radio access (S2-interfaces). LSIG - Overview Copyright All rights reserved. 1-9

12 Additional network nodes/functions, some shown in figure 1-6, may be present as well. For example, an evolved Packet Data Gateway (epdg) is needed for non-trusted IP access and a Policy and Charging Rules Function (PCRF) is required for IMS controlled QoS and charging mechanisms. For the purpose of charging there may also be an Online Charging System (OCS) and/or an Offline Charging System (OFCS) present. The Home Subscriber Server (HSS) holds subscription profiles and security related parameters. Additional subscription/security databases may also be present, such as the Subscription Profile Repository (SPR) and the 'triple-a' server (AAA, short for Authentication, Authorization and Accounting) Requirements on the EPC A (rather long) list of general requirements has been set up as guidelines for the standardisation work related to the EPC. Some of those are: 3GPP and non-3gpp access systems shall be supported. Scalable system architecture and solutions without compromising the system capacity (e.g. by separating CP from UP). CP response time shall be such that the UE can move from an idle state to one where it is sending/receiving data in less than 200 ms. Basic IP connectivity is established during the initial access phase (hence, the UE is always-on ). The Mobility Management (MM) solution shall be able to accommodate terminals with different mobility requirements (fixed, nomadic and mobile terminals). The MM functionality shall allow the network operator to control the type of access system being used by a subscriber. MM procedures shall provide seamless operation of both real-time (e.g. VoIP) and non real-time applications. In order to maximise users' access opportunities, the architecture should allow a UE that is roaming to use a non-3gpp access (e.g. WLAN. For example, it should be possible for a user to use a WLAN access network with which only the visited operator has a direct relationship (not the home operator). The evolved system shall support Ipv4 and Ipv6 connectivity. Access to the evolved system shall be possible with R99 USIM. (Please note that this also dis-allows access using SIM) The authentication framework should be independent from the used access network technology. The SAE/LTE system shall support network-sharing functionality. It shall be possible to support service continuity between IMS over SAE/LTE access and the Circuit Switched (CS) domain. It shall be possible for the operator to provide the UE with access network information pertaining to locally supported 3GPP and non- 3GPP access technologies. LSIG - Overview Copyright All rights reserved. 1-10

13 1.4 References GPRS enhancements for E-UTRAN access Architecture enhancements for non-3gpp accesses High Speed Packet Access (HSPA) evolution, FDD E-UTRA/E-UTRAN; overall description; Stage 2 LSIG - Overview Copyright All rights reserved. 1-11

14 2 NAS Protocols 2.1 INTRODUCTION NAS Functionality NAS Area Concepts and Identities NAS SIGNALLING PROCEDURES EMM Procedures ESM Procedures NAS States and State Transitions NAS MESSAGE FORMATS NAS SECURITY FUNCTIONS Authentication and Key Agreement Ciphering and Integrity Protection REFERENCES LSIG - NAS Copyright All rights reserved. 2-1

15 2.1 Introduction UE NAS enb MME NAS RRC RRC S1AP S1AP PDCP RLC PDCP RLC SCTP SCTP MAC MAC IP IP PHY PHY L1/L2 L1/L2 Uu S1-MME Figure 2-1: NAS protocol stack NAS Functionality The Non Access Stratum (NAS) protocols are used for signalling exchange between the UE and the Mobility Management Entity (MME) in the EPC. As can be seen in figure 2-1, all NAS signalling exchange takes place transparently through the radio access network (i.e. the enodeb will never interpret these messages). The NAS layer sits on top of the RRC layer in the UE and the S1AP layer in the MME. All NAS messages are therefore carried inside, or sent concatenated with, RRC and S1AP messages when transmitted over the radio interface and S1-interface respectively. As of EPS R8 there are only two NAS protocols defined: the EPS Mobility Management protocol (EMM) and the EPS Session Management protocol (ESM). The EMM protocol handles signalling related to UE mobility and signalling related to various security procedures. The ESM protocol handles signalling related to management of default and dedicated user plane bearers. The functionality of both protocols is very similar to the corresponding GSM/UMTS NAS protocols. The EMM protocol is modelled on the GPRS Mobility Management protocol (GMM) and the ESM protocol is modelled on the Session Management protocol (SM). LSIG - NAS Copyright All rights reserved. 2-2

16 2.1.2 NAS Area Concepts and Identities The NAS layer makes use of so-called Tracking Areas (TA) for mobility management purposes. The concept of a Tracking Area is in all respects the same as the GSM/UMTS concept of a Routing Area (or Location Area). Hence, the TA is an operator defined group of cells that all belong to the area served by one MME. One or more TA may be defined for each MME. The MME is aware of the location of an attached UE at the TA level through the TA Update procedure. The TA is typically, but not necessarily, the area within which the UE is paged for incoming calls. TAI = MCC + MNC + TAC, where TAI = Tracking Area Identity MCC = Mobile Country Code (3 digits) MNC = Mobile Network Code (3 digits) TAC = Tracking Area Code (not defined, Sept-08) As an operator option, there may also be MME Pool Areas defined. An MME Pool Area is defined as an area within which a UE may be served without need to change the serving MME. An MME Pool Area is served by one or more MMEs ("pool of MMEs") in parallel. MME Pool Areas are a collection of complete Tracking Areas. MME Pool Areas may overlap each other, as seen in figure 2-2. MME Group 1 MME Group 2 MME 1 MME 2 MME 1 MME 2 MME 3 UE CTX TA 1 TA 2 TA 3 UE TA 4 TA 5 TA 6 TA 7 Pool A GUTI S-TMSI Pool B Pool C PLMN X GUMMEI MMEI GUTI: MCC (3) MNC (3) MMEGI (16) MMEC (8) M-TMSI (32) Figure 2-2: MME pool areas S-TMSI The EPC uses the IMSI number as the permanent user identifier (or rather, USIM identifier). As in the legacy Core Network a temporary identifier is also used, for subscriber identity confidentiality reasons, in place of the IMSI whenever possible. The temporary identifier in the EPS is called the Globally Unique Temporary Identity (GUTI). LSIG - NAS Copyright All rights reserved. 2-3

17 The use of the GUTI is very similar to the use of the legacy TMSI (CS domain) and PTMSI (PS domain) numbers. There is a difference however: the GUTI explicitly links with the MME Pool Area concept. The relationship can be seen in figure 2-2. Please note that the length of MCC and MNC is in digits, while the other fields are given in bits. GUTI = MCC + MNC + MMEGI + MMEC + M-TMSI, where MMEGI = MME Group Identifier (16 bits) MMEC = MME Code (8) M-TMSI = M- Temporary Mobile Subscriber Identity (32) The MMEGI uniquely identifies a group ('pool') of MMEs within one network. The MMEC uniquely identifies an MME within one such group and the M-TMSI uniquely identifies one UE within one MME (the 'M' is just a label and is not an abbreviation for anything). The MMEGI together with the MMEC combines to the MME Identifier (MMEI). Thus, the MMEI uniquely identifies an MME within one core network. The MMEI together with MCC and MNC combines to the Globally Unique MME Identifier (GUMMEI). Thus, the GUMMEI uniquely identifies an MME on planet Earth. The GUTI is allocated when the UE performs initial registration (i.e. Attach ) with an MME. The GUTI is then typically changed whenever the UE performs some EMM-procedure, such as TA Update. The S-TMSI is a shortened version of the GUTI that uniquely identifies the user within an MME Group (the 'S' is just a label and is not an abbreviation for anything). The shorter S-TMSI, rather than the complete GUTI, is used within most NAS messages. 2.2 NAS Signalling Procedures EMM Procedures The EMM procedures are divided into three groups: Common, Specific and Connection Management procedures. The Common procedures relate to security functions and are listed below. Authentication: user (USIM) authentication and NAS key agreement. The procedure uses EPS Authentication Vectors (a variant of the UMTS quintets). Security Mode Control (SMC): initiation of and control of the NAS ciphering and integrity protection functions. GUTI Re-allocation: provision of a new GUTI to the UE. Identification: allows the MME to request either IMSI or IMEI from the UE when needed. LSIG - NAS Copyright All rights reserved. 2-4

18 The Specific procedures relate to registration/de-registration functions. Attach: initial registration of the UE in one MME for EPS services. The attach procedure is always combined with ESM signalling to establish basic IP-connectivity ('default bearer'). The attach procedure may also be combined with IMSI Attach, whereby the UE also becomes registered in the legacy MSC Server (this is to support the 'CS Fallback' feature). Detach: de-registration from the network. May be performed as a combined detach, whereby the UE becomes de-registered for EPS services and/or non-eps services (i.e. IMSI Detach). Tracking Area Update (TAU): performed when the UE enters a TA not currently in its stored list of TAIs (normal TAU) or at timer expiry (periodic TAU). May also be a combined update, whereby the UE also performs a Location Area Update towards the MSC Server. The Connection Management procedures are used for mobile terminating or mobile originating connection management and will always trigger ESM protocol procedures (for the actual call/session setup signalling). Paging: used when the UE is in Idle mode and the network has downlink data or signalling pending. The UE responds by initiating the Service Request procedure (there is no explicit 'paging response' message defined). Service Request (SR): used when the UE is in Idle or Connected mode and has uplink data or signalling pending. The network responds by initiating the Authentication and/or SMC procedure ESM Procedures The ESM procedures are divided into two groups: Network Initated procedures and UE Initiated procedures. The Network Initiated procedures are used for establishment, modification or release of default or dedicated EPS bearers and are listed below. Default EPS Bearer Context Activation: provides the UE with basic IP-connectivity (a default bearer) to a given external Packet Data Network (PDN). The first default bearer is always established in conjunction with the Attach procedure. Subsequent default bearers, to other PDNs, are established when needed. Dedicated EPS Bearer Context Activation: provides the UE with a bearer associated with a certain QoS and packet filter (Traffic Flow Template, TFT). LSIG - NAS Copyright All rights reserved. 2-5

19 EPS Bearer Context Modification: used by the network to modify the QoS and/or TFT for a given dedicated bearer. EPS Bearer Context Deactivation: used by the network to release a given dedicated or default bearer. To release a default bearer is the same as to disconnect from the associated PDN. When the last default bearer is released the UE enters the detached state. The UE Initiated procedures are used for establishment, modification or release of default or dedicated EPS bearers. UE Requested PDN Connection: request for basic IPconnectivity (a default bearer) to a given external Packet Data Network (PDN). The first default bearer is always requested in conjunction with the Attach procedure. Subsequent default bearers, to other PDNs, are requested when needed. This procedure always triggers the network initiated Default EPS Bearer Context Activation procedure: UE Requested PDN Disconnection: used by the UE to disconnect from a given PDN. UE Requested Bearer Resource Allocation: used by the UE to request a dedicated bearer associated with a certain QoS and TFT. This procedure triggers either the Default EPS Bearer Context Activation procedure or the EPS Bearer Context Modification procedure. UE Requested Bearer Resource Release: used by the UE to release a dedicated bearer NAS States and State Transitions There are separate (but mutually dependent) protocol state machines for the EMM protocol and the ESM protocol. The EMM protocol state machine relates to whether the UE is properly registered in the network or not and whether there exists an active NAS Signalling Connection between the UE and MME or not. The ESM protocol state machine deals exclusively with the existence or not of EPS bearers. The EMM protocol state machine contains two sets of states: EMM states and ECM states (EPS Connection Management). The UE is either EMM Registered or EMM Deregistered, i.e. attached or not. The ECM states are only relevant in the EMM Registered state and reflect whether there is an active NAS Signalling Connection established (ECM Connected) or not (ECM Idle). LSIG - NAS Copyright All rights reserved. 2-6

20 A NAS Signalling Connection is required for any exchange of NAS messages, with the exception of the very messages that triggers the establishment of the NAS Signalling Connection itself (e.g. Attach Request or Paging). ESM ACTIVE PDN Context(s): IP-address, APN, QoS Parameters S5 IP-address & TEID S11 IP-address & TEID (S1-U IP-address & TEID) Data Transfer Possible when ECM Connected One Default Bearer Zero, one or more Dedicated Bearer EMM REGISTERED MME context: IMSI, GUTI, TA list IP-address, Security association ECM IDLE No NAS Signalling Connection Tracking Area Updates NAS Connection NAS Connection Release Establishment ECM CONNECTED NAS Signalling Connection Data transfer possible EPS Bearer Establishment Last EPS Bearer Released Attach Detach ESM INACTIVE No PDN context EMM DEREGISTERED No MME context Figure 2-3: NAS states The ESM states are quite straightforward: when at least one (default) bearer is established the UE is in the ESM Active state, otherwise it is in the ESM Inactive state. The ESM signalling needed to establish a bearer requires that the UE is properly registered in the network. It therefore naturally follows that the UE must be in the EMM Registered state whenever it is ESM Active. It also follows that there must be a NAS Signalling Connection present during the ESM signalling phase when a bearer is being established, i.e. the UE is then ECM Connected. However, there is no requirement to keep the NAS Signalling Connection active for the lifetime of an EPS bearer. Hence, the UE may very well be ECM Idle while being ESM Active. This makes sense, since the UE may be attached for days, weeks or even months on end (all the time having a default bearer active). The NAS states (MME related states) are aligned with the RRC states (enodeb related states, see chapter 4). A UE in RRC Idle state is, from the MMEs point of view, in the NAS state ECM Idle. Paging or a request from higher layers to transmit uplink data or signalling will cause a transition from RRC Idle to RRC Connected, causing also a transition from ECM Idle to ECM Connected. This is not shown in figure 2-3 above. LSIG - NAS Copyright All rights reserved. 2-7

21 2.3 NAS Message Formats The NAS messages have different format depending on if it is an EMM message or an ESM message and also on whether the message is security protected or not. All NAS messages are octet-aligned. All EMM messages except Service Request, which has a special format, consist of a Protocol Discriminator, a Security Header Type field, a Message Type field and zero, one or more additional Information Elements (IEs, or payload 'parameters'). All ESM messages consist of a Protocol Discriminator, an EPS Bearer Id field, a Procedure Transaction Id, Message Type field and zero, one or more additional IE. Any security protected NAS message also contains a security header appended at the beginning of the message. The security header consists of a Protocol Discriminator, a Security Header Type field, a NAS Sequence Number field and a Message Authentication Code field. EMM Message ESM Message Security Header Type Protocol Discriminator EPS Bearer Id Protocol Discriminator Message Type Procedure Transaction Id Other Information Elements (Mand/Opt/Cond) Message Type Other Information Elements (Mand/Opt/Cond) Security Header Security Header Type Protocol Discriminator Message Authentication Code (4 oct) NAS Sequence Number Figure 2-4: NAS message format Protocol Discriminator (PD). The PD identifies the NAS protocol (EMM or ESM) to which the message belongs. The PD is defined in TS and shares the same value space as the GSM/UMTS NAS protocols. Security Header Type (SHT). The SHT indicates the presence or not of a security header, i.e. whether the message is security protected or not. Message Type (MT). The MT identifies a message (e.g. 'Attach Request'). LSIG - NAS Copyright All rights reserved. 2-8

22 EPS Bearer Id (EBI). The EBI field specifies the EPS bearer to which the message pertains. Implicitly it also specifies the specific ESM protocol instance to which the message is addressed (there is one ESM protocol entity active per EPS bearer). Procedure Transaction Id (PTI). The PTI allows distinguishing between different parallel bi-directional ESM message flows (or 'transactions'). The PTI also links a 'request' message with its 'response' message for a given transaction. Message Authentication Code (MAC). The MAC field is the output from the NAS integrity protection algorithm (see next section) and is used in the receiver for checking the integrity of the message. NAS Sequence Number (SN). The SN field is used as input to the NAS ciphering and integrity protection algorithms. 2.4 NAS Security Functions Authentication and Key Agreement The purpose of the authentication mechanism is to protect the network against unauthorized use. It also protects the subscribers, by denying the possibility for intruders to impersonate valid users (i.e. making calls on someone else's bill). This is achieved by executing an authentication procedure (authentication challenge) whenever a subscriber requests some kind of service from the network (or initiates a signalling procedure). NAS signalling for authentication takes place between the UE and the MME but involves also the Home Subscriber Server (HSS), where the Authentication Vectors are stored/produced. The authentication procedure also includes network authentication. This process makes sure the UE knows that it is connected to a serving network that is authorised by the user's service provider. Authentication and Key Agreement (AKA) is the combined process of authenticating the user (and network) and calculating keys for NAS ciphering and integrity protection. A so-called security context is established in the UE and in the MME after a successful AKA run. The AKA procedure must, according to the specifications, be performed at least during initial attach. After that it is up to the MME node involved when to perform a new AKA run. It may be performed whenever the UE wishes to execute some signalling procedure (e.g. tracking area update) or when the UE requests some form of service (e.g. establishment of dedicated bearers speech call) or both. LSIG - NAS Copyright All rights reserved. 2-9

23 An EPS Authentication Vector (AV) is produced in the HSS (or in a colocated Authentication Centre, AuC) and consists of four parameters: RAND (128 bits) is input to a set of algorithms, together with the secret authentication key K, for calculation of RES, AUTN and K ASME. The authentication key, K, is uniquely linked to one, and only one, IMSI number in the HSS/AuC. The RAND parameter from a selected AV is sent to the UE in an Authentication Request message whenever the MME wishes to perform an AKA run. This parameter is sometimes referred to as the authentication challenge or random challenge. RES/XRES (length not defined, Sept-08) is the signed response used for authentication. This parameter is sent in the Authentication Response message from the UE to the MME. The UE is regarded as authenticated if the RES provided by the UE matches the one stored in the selected AV in the MME. The term XRES is short for expected RES and is just an indication that the RES (i.e. XRES) stored in the MME will be compared to another version of itself (i.e. the RES sent back from the UE). AUTN (112) is the authentication token used by the UE to validate that the network is authorised. The AUTN is sent to the UE along with the RAND in the Authentication Request message. The AUTN is calculated in the HSS/AuC based on the Anonymity Key (AK) and the Message Authentication Code (MAC) in the same manner as in a GSM/UMTS HSS. Note: do not confuse this 'MAC' parameter with the 'MAC' present in a security protected NAS message, they are not the same! K ASME (256) is the Access Security Management Entity key, where 'ASME' is to be understood as the MME in the EPS case. K ASME is derived from an HSS/AuC produced Ciphering Key (CK) and integrity Key (IK), both 128 bits long. The CK and IK keys are, in turn, calculated in the same manner as in a GSM/UMTS HSS. The EPS system uses a security key hierarchy (figure 2-5) with multiple levels. The base keys on the top level (CK and IK) are only visible to the UE and the home network domain databases (HSS/AuC). On the next level there is K ASME, which is only visible to the UE and the visited MME. K ASME is, in turn, used for derivation of the ciphering and integrity keys needed to protect NAS signalling messages (i.e. signalling between UE and MME). K ASME is also used for derivation of an enodeb key, K enb. Finally, K enb is used for derivation of keys for ciphering and integrity protection of RRC signalling messages and a key for the ciphering of user data over the radio interface (i.e. between UE and enodeb). LSIG - NAS Copyright All rights reserved. 2-10

24 Never leaves Home Domain K CK, IK Never leaves EPC (KASME is vplmn specific) KASME KeNB Only used in access NW (KeNB is cell specific) CKNAS IKNAS CKUP CKCP IKCP Figure 2-5: EPS security key hierarchy This hierarchy allows the keys in the Home domain, the (visited) EPC domain and the Access domain to be cryptographically separate, while still being produced by the same set of Home domain controlled base keys Ciphering and Integrity Protection NAS SN Standard Header Other IEs (one or more message) Other input Encryption CKNAS NAS SN Other input Integrity IKNAS Security Protocol Header Type Discriminator MAC NAS SN Security Header Figure 2-6: Ciphering and integrity protection of NAS messages A simplified version of the processing sequence for ciphering and integrity protection of NAS messages can be seen in figure 2-6 above. The message to be encrypted is fed to the encryption algorithm together with the NAS Ciphering Key, the NAS Sequence Number and additional input parameters. The output is an encrypted message (the NAS SN is not encrypted). The encrypted message is then fed to the integrity algorithm together with the NAS Integrity Key, the NAS SN and additional input parameters. The output is the calculated MAC, which is placed in the security header appended to the message. LSIG - NAS Copyright All rights reserved. 2-11

25 2.5 References Mobile radio interface layer 3; general aspects Non-Access Stratum (NAS) protocol for EPS; stage GPP System Architecture Evolution: security architecture Rationale and track of security decisions in LTE/SAE LSIG - NAS Copyright All rights reserved. 2-12

26 3 S1 and S11-interface (S1AP & GTP) 3.1 INTRODUCTION S1-INTERFACE S1-MME: S1AP Procedures S1-MME: SCTP and Transport Protocols S1-U: GTP-U Procedures S11-INTERFACE GTP-C Procedures GTP Header Format EPS QOS CONCEPTS User Plane Bearer Establishment QoS Parameters REFERENCES LSIG - S1 and S11 Copyright All rights reserved. 3-1

27 3.1 Introduction enb MME SGW S1AP S1AP GTP-C GTP-C SCTP SCTP UDP UDP IP IP IP IP L1/L2 L1/L2 L1/L2 L1/L2 S1-MME S11 enb GTP-U SGW GTP-U UDP UDP IP IP L1/L2 L1/L2 S1-U Figure 3-1: S1/S11 protocol stacks The S1-interface connects E-UTRAN (enbs) with the EPC. The S1- interface is an IP-based interface and can therefore be seen as a point to multi-point interface. The Control Plane (CP) instance of the S1-interface (S1-MME) uses the S1 Application Protocol (S1AP) for control signalling purposes between the enb and the MME. The S1AP protocol runs on top of the Stream Control Transmission Protocol (SCTP). The User Plane (UP) instance of the S1-interface (S1-U) uses the GPRS Tunnelling Protocol- User plane (GTP-U) for user data tunnelling. The termination point on the EPC side for S1-U is the Serving Gateway, SGW. The S11-interface is, like the S1-interface, an IP-based point to multi-point interface. The S11-interface is used for signalling between the MME and the SGW (upper right in figure 3-1) and does not have a UP instance. The S11-interface uses the GPRS Tunnelling Protocol- Control plane (GTP-C) for control signalling purposes. Please see figure 1-2 for the network architecture corresponding to the protocol stacks above. LSIG - S1 and S11 Copyright All rights reserved. 3-2

28 3.2 S1-Interface S1-MME: S1AP Procedures The S1AP protocol is used for control signalling exchange between enb and MME. The S1 procedures are divided into Context management, EPS Bearer management, Handover, Location Reporting, Node management and 'Other' procedures. All UE associated signalling takes place over a logical S1 Connection. The UE-specific S1 Connection is identified in each node with an S1AP UE Identifier. Thus, all S1AP messages pertaining to a specific UE will carry two reference numbers: the S1AP UE Id selected by the enb and the S1AP UE Id selected by the MME. One such pair of reference numbers uniquely identifies a UE context in a node. Context Management Procedures Initial Context Setup. This procedure supports the establishment of the necessary overall initial UE Context in the enb to enable fast Idle-to- Active transition. The UE Context includes: EPS Bearer context, security context, roaming restriction, UE capability info, subscriber type info etc. The procedure is always initiated from the MME, typically in combination with network registration (Attach or TA Update). The logical S1 Connection is established after successful execution of this procedure. UE Context Modification. The purpose of this procedure is to modify an already established UE context in the enb (e.g. change the enb security key). The procedure is always initiated from the MME. UE Context Release. The purpose of this procedure is to release the logical S1 Connection related to a specific UE (thus also releasing the associated UE context). The procedure may be initiated from the MME (e.g. due to completed NAS signalling transaction) or from the enb (due to handover, timer expiry or other radio related reason). EPS Bearer Management Procedures The EPS Bearer management procedures are responsible for establishing, modifying and releasing E-UTRAN resources for user data transport with a given QoS (once an initial UE context is available in the enb). The procedures are always initiated from the MME, with the exception of EPS Bearer Release that may be initiated from the enb. Handover Procedures Handover preparation and execution signalling over the S1-interface is only needed during inter-rat handover or when there is no X2-interface present between the Source enb and the Target enb. For a normal X2- interface initiated inter-enb handover a S1AP Handover Notification message is sent from the Target enb to the MME after the UE has been successfully transferred to the new cell. LSIG - S1 and S11 Copyright All rights reserved. 3-3

29 Location Reporting Procedures These procedures allow the MME to request the current location (i.e. cell) of the UE. The enb can be asked to report immediately or when the UE leavers the current cell. Node Management Procedures S1 Setup. The purpose of the S1 Setup procedure is to exchange application level data needed for the enb and MME to interoperate correctly on the S1-interface. This procedure shall be the first S1AP procedure triggered after the SCTP association (see below) has become operational. The enb informs the MME about its enb Identity number and which TAs it supports. The MME informs the enb about its MME Identity number (GUMMEI) and which PLMNs it supports. Configuration Update. The purpose of this procedure is to exchange application level data that have changed since the last S1 setup procedure was executed. The procedure may be initiated from the enb or the MME. Reset. The purpose of the Reset procedure is to initialise or re-initialise the S1AP UE contexts, in the event of a failure in the MME or enb. This procedure does not affect the application level configuration data exchanged during the S1 Setup procedure. Other Procedures Paging. Enables the MME to page the UE in a specific enb. The MME initiates the paging procedure by sending a Paging message to each enb with cells belonging to the Tracking Area(s) in which the UE is registered. The paging response back to the MME is initiated on the NAS layer and is forwarded to MME by the enb as part of the NAS Signalling Transport procedure. NAS Signalling Transport. This procedure provides means to transport NAS messages to/from a given UE over the S1-interface. (This procedure is in all respects the same as the RRC Information Transfer procedure described in chapter 4) S1-MME: SCTP and Transport Protocols The Stream Control Transmission Protocol (SCTP) is used to support the exchange of S1AP signalling messages between enb and MME. SCTP is a session-oriented protocol providing connection-oriented, error-free, flow-controlled, in-sequence transfer of signalling messages over IP. It is in many respects similar to TCP, but there are some differences. One such difference is that SCTP is message oriented while TCP is byte oriented. Another difference is that the in-sequence delivery is optional for SCTP (i.e. it can be turned off ) while it is always mandatory for TCP. LSIG - S1 and S11 Copyright All rights reserved. 3-4