TS 123 401 V9.2.0 (2009-10) Technical Specification LTE; General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access (3GPP TS 23.401 version 9.2.0 Release 9)
1 TS 123 401 V9.2.0 (2009-10) Reference RTS/TSGS-0223401v920 Keywords LTE 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N 348 623 562 00017 - NAF 742 C Association à but non lucratif enregistrée à la Sous-Préfecture de Grasse (06) N 7803/88 Important notice Individual copies of the present document can be downloaded from: http://www.etsi.org The present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). In case of dispute, the reference shall be the printing on printers of the PDF version kept on a specific network drive within Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other documents is available at http://portal.etsi.org/tb/status/status.asp If you find errors in the present document, please send your comment to one of the following services: http://portal.etsi.org/chaircor/_support.asp Copyright Notification No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media. European Telecommunications Standards Institute 2009. All rights reserved. DECT TM, PLUGTESTS TM, UMTS TM, TIPHON TM, the TIPHON logo and the logo are Trade Marks of registered for the benefit of its Members. 3GPP TM is a Trade Mark of registered for the benefit of its Members and of the 3GPP Organizational Partners. LTE is a Trade Mark of currently being registered for the benefit of its Members and of the 3GPP Organizational Partners. GSM and the GSM logo are Trade Marks registered and owned by the GSM Association.
2 TS 123 401 V9.2.0 (2009-10) Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to. The information pertaining to these essential IPRs, if any, is publicly available for members and non-members, and can be found in SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to in respect of standards", which is available from the Secretariat. Latest updates are available on the Web server (http://webapp.etsi.org/ipr/home.asp). Pursuant to the IPR Policy, no investigation, including IPR searches, has been carried out by. No guarantee can be given as to the existence of other IPRs not referenced in SR 000 314 (or the updates on the Web server) which are, or may be, or may become, essential to the present document. Foreword This Technical Specification (TS) has been produced by 3rd Generation Partnership Project (3GPP). The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or GSM identities. These should be interpreted as being references to the corresponding deliverables. The cross reference between GSM, UMTS, 3GPP and identities can be found under http://webapp.etsi.org/key/queryform.asp.
3 TS 123 401 V9.2.0 (2009-10) Contents Intellectual Property Rights... 2 Foreword... 2 Foreword... 9 1 Scope... 10 2 References... 10 3 Definitions and abbreviations... 12 3.1 Definitions... 12 3.2 Abbreviations... 13 4 Architecture model and concepts... 14 4.1 General concepts... 14 4.2 Architecture reference model... 14 4.2.1 Non-roaming architecture... 14 4.2.2 Roaming architecture... 15 4.2.3 Reference points... 17 4.2.4 Warning System architecture... 18 4.3 High level functions... 18 4.3.1 General... 18 4.3.2 Network access control functions... 19 4.3.2.1 General... 19 4.3.2.2 Network/Access network selection... 19 4.3.2.3 Authentication and authorisation function... 19 4.3.2.4 Admission control function... 19 4.3.2.5 Policy and Charging Enforcement Function... 19 4.3.2.6 Lawful Interception... 19 4.3.3 Packet routeing and transfer functions... 19 4.3.3.1 General... 19 4.3.3.2 IP header compression function... 19 4.3.3.3 Packet screening function... 20 4.3.4 Security functions... 20 4.3.5 Mobility management functions... 20 4.3.5.1 General... 20 4.3.5.2 Reachability Management for UE in ECM-IDLE state... 20 4.3.5.3 Tracking Area list management... 21 4.3.5.4 Inter-eNodeB mobility anchor function... 21 4.3.5.5 Inter-3GPP mobility anchor function... 21 4.3.5.6 Idle mode signalling reduction function... 21 4.3.5.7 Mobility Restrictions... 23 4.3.5.8 IMS voice over PS Session Supported Indication... 23 4.3.6 Radio Resource Management functions... 23 4.3.7 Network management functions... 24 4.3.7.1 General... 24 4.3.7.2 Load balancing between MMEs... 24 4.3.7.3 Load re-balancing between MMEs... 24 4.3.7.4 MME control of overload... 25 4.3.8 Selection functions... 26 4.3.8.1 PDN GW selection function (3GPP accesses)... 26 4.3.8.2 Serving GW selection function... 27 4.3.8.3 MME selection function... 27 4.3.8.4 SGSN selection function... 27 4.3.8.5 Selection of PCRF... 27 4.3.9 IP network related functions... 28 4.3.9.1 Domain Name Service function... 28 4.3.9.2 DHCP function... 28
4 TS 123 401 V9.2.0 (2009-10) 4.3.9.3 Explicit Congestion Notification... 28 4.3.10 Functionality for Connection of enodebs to Multiple MMEs... 28 4.3.11 E-UTRAN Sharing Function... 28 4.3.12 IMS Emergency Session Support... 28 4.3.12.1 Introduction... 28 4.3.12.2 Architecture Reference Model for Emergency Services... 30 4.3.12.3 Mobility and Access Restrictions for Emergency Services... 30 4.3.12.3a Reachability Management for UE in ECM-IDLE state... 30 4.3.12.4 PDN GW selection function (3GPP accesses) for Emergency Services... 30 4.3.12.5 QoS for Emergency Services... 30 4.3.12.6 PCC for Emergency Services... 31 4.3.12.7 Load re-balancing between MMEs for Emergency Services... 31 4.3.12.8 IP Address Allocation... 31 4.3.12.9 Handling of PDN Connections for Emergency Bearer Services... 31 4.3.13 Closed Subscriber Group functions... 31 4.3.14 Location Service functions... 32 4.4 Network elements... 32 4.4.1 E-UTRAN... 32 4.4.2 MME... 32 4.4.3 Gateway... 33 4.4.3.1 General... 33 4.4.3.2 Serving GW... 33 4.4.3.3 PDN GW... 33 4.4.4 SGSN... 34 4.4.5 GERAN... 34 4.4.6 UTRAN... 34 4.4.7 PCRF... 35 4.4.7.1 General... 35 4.4.7.2 Home PCRF (H-PCRF)... 35 4.4.7.3 Visited PCRF (V-PCRF)... 35 4.4.8 PDN GW's associated AAA Server... 35 4.4.9 HeNB subsystem... 35 4.5 Void... 35 4.6 EPS Mobility Management and Connection Management states... 36 4.6.1 General... 36 4.6.2 Definition of main EPS Mobility Management states... 36 4.6.2.1 EMM-DEREGISTERED... 36 4.6.2.2 EMM-REGISTERED... 36 4.6.3 Definition of EPS Connection Management states... 37 4.6.3.1 ECM-IDLE... 37 4.6.3.2 ECM-CONNECTED... 37 4.6.4 State transition and functions... 38 4.7 Overall QoS concept... 39 4.7.1 PDN connectivity service... 39 4.7.2 The EPS bearer... 39 4.7.2.1 The EPS bearer in general... 39 4.7.2.2 The EPS bearer with GTP-based S5/S8... 41 4.7.2.3 The EPS bearer with PMIP-based S5/S8... 42 4.7.3 Bearer level QoS parameters... 42 4.7.4 Support for Application / Service Layer Rate Adaptation... 43 4.7.5 Application of PCC in the Evolved Packet System... 43 4.8 Compatibility Issues... 44 4.8.1 Network Configuration for Interaction with UTRAN/GERAN... 44 5 Functional description and information flows... 45 5.1 Control and user planes... 45 5.1.0 General... 45 5.1.1 Control Plane... 45 5.1.1.1 General... 45 5.1.1.2 enodeb - MME... 45 5.1.1.3 UE - MME... 46 5.1.1.4 SGSN - MME... 46
5 TS 123 401 V9.2.0 (2009-10) 5.1.1.5 SGSN - S-GW... 47 5.1.1.6 S-GW - P-GW... 47 5.1.1.7 MME - MME... 48 5.1.1.8 MME - S-GW... 48 5.1.1.9 MME - HSS... 49 5.1.1.10 MME - EIR... 49 5.1.1.11 CBC - enodeb... 50 5.1.2 User Plane... 51 5.1.2.1 UE - P-GW user plane with E-UTRAN... 51 5.1.2.2 enodeb - S-GW... 51 5.1.2.3 UE - PDN GW user plane with 2G access via the S4 interface... 52 5.1.2.4 UE - PDN GW user plane with 3G access via the S12 interface... 53 5.1.2.5 UE - PDN GW user plane with 3G access via the S4 interface... 54 5.2 Identities... 54 5.2.1 EPS bearer identity... 54 5.2.2 Globally Unique Temporary UE Identity... 54 5.2.3 Tracking Area Identity (TAI)... 55 5.2.4 enodeb S1-AP UE Identity (enb S1-AP UE ID)... 55 5.2.5 MME S1-AP UE Identity (MME S1-AP UE ID)... 55 5.2.6 Closed Subscriber Group ID... 55 5.3 Authentication, security and location management... 55 5.3.1 IP address allocation... 55 5.3.1.1 General... 55 5.3.1.2 IP address allocation, renewal and release mechanisms for GTP based S5/S8... 57 5.3.1.2.1 IPv4 address allocation via default bearer activation and release via PDN connection release... 57 5.3.1.2.2 IPv6 prefix allocation, renewal and release via IPv6 stateless address autoconfiguration... 58 5.3.1.2.3 IPv6 parameter configuration via stateless DHCPv6... 58 5.3.1.2.4 IPv4 address allocation, renewal and release and IPv4 parameter configuration via DHCPv4... 59 5.3.1.2.5 Void... 59 5.3.2 Attach procedure... 59 5.3.2.1 E-UTRAN Initial Attach... 59 5.3.2.2 UTRAN/GERAN Initial Attach... 69 5.3.3 Tracking Area Update procedures... 69 5.3.3.0 Triggers for tracking area update... 69 5.3.3.0A Provision of UE's TAI to MME in ECM-CONNECTED state... 69 5.3.3.1 Tracking Area Update procedure with Serving GW change... 70 5.3.3.2 E-UTRAN Tracking Area Update without S-GW Change... 75 5.3.3.3 Routeing Area Update with MME interaction and without S-GW change... 80 5.3.3.4 Void... 85 5.3.3.5 Void... 85 5.3.3.6 Routeing Area Update with MME interaction and with S-GW change... 85 5.3.4 Service Request procedures... 91 5.3.4.1 UE triggered Service Request... 91 5.3.4.2 Handling of abnormal conditions in UE triggered Service Request... 92 5.3.4.3 Network Triggered Service Request... 93 5.3.5 S1 release procedure... 95 5.3.6 Void... 96 5.3.7 GUTI Reallocation procedure... 96 5.3.8 Detach procedure... 97 5.3.8.1 General... 97 5.3.8.2 UE-initiated Detach procedure... 97 5.3.8.2.1 UE-initiated Detach procedure for E-UTRAN... 97 5.3.8.2.2 UE-initiated Detach procedure for GERAN/UTRAN with ISR activated... 99 5.3.8.3 MME-initiated Detach procedure... 101 5.3.8.3A SGSN-initiated Detach procedure with ISR activated... 103 5.3.8.4 HSS-initiated Detach procedure... 104 5.3.9 HSS User Profile management function procedure... 106 5.3.9.1 General... 106 5.3.9.2 Insert Subscriber Data procedure... 106 5.3.9.3 Purge function... 107 5.3.10 Security Function... 107 5.3.10.1 General... 107
6 TS 123 401 V9.2.0 (2009-10) 5.3.10.2 Authentication and Key Agreement... 108 5.3.10.3 User Identity Confidentiality... 108 5.3.10.4 User Data and Signalling Confidentiality... 108 5.3.10.4.1 AS security mode command procedure... 108 5.3.10.4.2 NAS Security Mode Command procedure... 108 5.3.10.5 ME identity check procedure... 109 5.3.11 UE Reachability procedures... 109 5.3.11.1 General... 109 5.3.11.2 UE Reachability Notification Request procedure... 109 5.3.11.3 UE Activity Notification procedure... 110 5.4 Session Management, QoS and interaction with PCC functionality... 110 5.4.1 Dedicated bearer activation... 110 5.4.2 Bearer modification with bearer QoS update... 112 5.4.2.1 PDN GW initiated bearer modification with bearer QoS update... 112 5.4.2.2 HSS Initiated Subscribed QoS Modification... 114 5.4.3 PDN GW initiated bearer modification without bearer QoS update... 116 5.4.4 Bearer deactivation... 117 5.4.4.1 PDN GW initiated bearer deactivation... 117 5.4.4.2 MME Initiated Dedicated Bearer Deactivation... 120 5.4.5 UE requested bearer resource modification... 121 5.4.6 Void... 123 5.5 Handover... 123 5.5.1 Intra-E-UTRAN handover... 123 5.5.1.1 X2-based handover... 123 5.5.1.1.1 General... 123 5.5.1.1.2 X2-based handover without Serving GW relocation... 124 5.5.1.1.3 X2-based handover with Serving GW relocation... 125 5.5.1.2 S1-based handover... 127 5.5.1.2.1 General... 127 5.5.1.2.2 S1-based handover, normal... 128 5.5.1.2.3 S1-based handover, Reject... 132 5.5.2 Inter RAT handover... 133 5.5.2.0 General... 133 5.5.2.1 E-UTRAN to UTRAN Iu mode Inter RAT handover... 133 5.5.2.1.1 General... 133 5.5.2.1.2 Preparation phase... 134 5.5.2.1.3 Execution phase... 137 5.5.2.1.4 E-UTRAN to UTRAN Iu mode Inter RAT handover Reject... 139 5.5.2.2 UTRAN Iu mode to E-UTRAN Inter RAT handover... 140 5.5.2.2.1 General... 140 5.5.2.2.2 Preparation phase... 141 5.5.2.2.3 Execution phase... 144 5.5.2.2.4 UTRAN Iu mode to E-UTRAN Inter RAT handover reject... 146 5.5.2.3 E-UTRAN to GERAN A/Gb mode Inter RAT handover... 147 5.5.2.3.1 General... 147 5.5.2.3.2 Preparation phase... 147 5.5.2.3.3 Execution phase... 150 5.5.2.3.4 E-UTRAN to GERAN A/Gb mode Inter RAT handover reject... 153 5.5.2.4 GERAN A/Gb mode to E-UTRAN Inter RAT handover... 154 5.5.2.4.1 General... 154 5.5.2.4.2 Preparation phase... 154 5.5.2.4.3 Execution phase... 157 5.5.2.4.4 GERAN A/Gb mode to E-UTRAN Inter RAT handover reject... 159 5.5.2.5 Inter RAT handover Cancel... 160 5.5.2.5.1 General... 160 5.5.2.5.2 Source RAN to Target RAN Inter RAT handover Cancel... 160 5.6 Network Assisted Cell Change... 161 5.6.1 Architecture Principles for E-UTRAN to GERAN NACC... 161 5.6.2 RAN Information Management (RIM) procedures... 162 5.6.2.1 General... 162 5.6.2.2 Addressing, routeing and relaying... 162 5.6.2.2.1 Addressing... 162
7 TS 123 401 V9.2.0 (2009-10) 5.6.2.2.2 Routeing... 163 5.6.2.2.3 Relaying... 163 5.6.2.3 Applications using the RIM Procedures... 163 5.7 Information storage... 163 5.7.1 HSS... 163 5.7.2 MME... 166 5.7.3 Serving GW... 168 5.7.4 PDN GW... 170 5.7.5 UE... 172 5.7.6 Handling of Wild Card APN... 173 5.7A Charging... 173 5.8 MBMS... 173 5.9 Interactions with other services... 174 5.9.1 Location Reporting Procedure... 174 5.10 Multiple-PDN support... 174 5.10.1 General... 174 5.10.2 UE requested PDN connectivity... 174 5.10.3 UE or MME requested PDN disconnection... 180 5.11 UE Capability Handling... 181 5.11.1 General... 181 5.11.2 UE Radio Capability Handling... 181 5.11.3 UE Core Network Capability... 182 5.12 Warning message delivery... 183 5.12.1 General... 183 5.12.2 Warning message delivery procedure... 183 5.12.3 Warning message cancel procedure... 186 5.13 Discontinuous Reception and UE Specific DRX Parameter handling... 188 5.14 Configuration Transfer procedure... 188 5.14.1 Architecture Principles for Configuration Transfer... 188 5.14.2 Addressing, routeing and relaying... 189 5.14.2.1 Addressing... 189 5.14.2.2 Routeing... 189 5.14.2.3 Relaying... 190 5.14.2.4 Applications using the Configuration Transfer procedures... 190 Annex A: Annex B: Annex C: Void... 191 Void... 192 Void... 193 Annex D (normative): Interoperation with Gn/Gp SGSNs... 194 D.1 General Considerations... 194 D.2 Interoperation Scenario... 194 D.2.1 Roaming interoperation scenario... 194 D.2.2 Non-roaming interoperation scenario... 195 D.3 Interoperation procedures... 195 D.3.1 General... 195 D.3.2 Void... 196 D.3.3 MME to 3G SGSN combined hard handover and SRNS relocation procedure... 196 D.3.4 3G SGSN to MME combined hard handover and SRNS relocation procedure... 201 D.3.5 Routeing Area Update... 206 D.3.6 Gn/Gp SGSN to MME Tracking Area Update... 211 D.3.7 E-UTRAN to GERAN A/Gb mode Inter RAT handover... 217 D.3.7.1 General... 217 D.3.7.2 Preparation phase... 218 D.3.7.3 Execution phase... 220 D.3.8 GERAN A/Gb mode to E-UTRAN Inter RAT handover... 222 D.3.8.1 General... 222 D.3.8.2 Preparation phase... 223
8 TS 123 401 V9.2.0 (2009-10) D.3.8.3 Execution phase... 225 Annex E (normative): Annex F (normative): Mapping between EPS and pre-rel-8 QoS parameters... 228 Dedicated bearer activation in combination with the default bearer activation at Attach and UE requested PDN connectivity procedures... 231 Annex G: Void234 Annex H (normative): Annex I (informative): Annex J (informative): Mapping between temporary and area identities... 235 Guidance for contributors to this specification... 236 High Level ISR description... 237 J.1 General description of the ISR concept... 237 J.2 Usage of the TIN... 238 J.3 ISR activation... 238 J.4 Downlink data transfer... 239 J.5 ISR deactivation... 240 J.6 Handling of special situations... 240 Annex K (informative): Change history... 242 History... 246
9 TS 123 401 V9.2.0 (2009-10) Foreword This Technical Specification has been produced by the 3 rd Generation Partnership Project (3GPP). The contents of the present document are subject to continuing work within the TSG and may change following formal TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an identifying change of release date and an increase in version number as follows: Version x.y.z where: x the first digit: 1 presented to TSG for information; 2 presented to TSG for approval; 3 or greater indicates TSG approved document under change control. y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc. z the third digit is incremented when editorial only changes have been incorporated in the document.
10 TS 123 401 V9.2.0 (2009-10) 1 Scope The present document defines the Stage 2 service description for the Evolved 3GPP Packet Switched Domain - also known as the Evolved Packet System (EPS) in this document. The Evolved 3GPP Packet Switched Domain provides IP connectivity using the Evolved Universal Terrestrial Radio Access Network (E-UTRAN). The specification covers both roaming and non-roaming scenarios and covers all aspects, including mobility between E- UTRAN and pre-e-utran 3GPP radio access technologies, policy control and charging, and authentication. The Radio Access Network functionality is documented only to the extent necessary to describe the overall system. TS 36.300 [5] contains the overall description of the Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN). ITU-T Recommendation I.130 [3] describes a three-stage method for characterisation of telecommunication services, and ITU-T Recommendation Q.65 [4] defines Stage 2 of the method. TS 23.402 [2] is a companion specification to this specification. 2 References The following documents contain provisions which, through reference in this text, constitute provisions of the present document. References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific. For a specific reference, subsequent revisions do not apply. For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document. [1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". [2] 3GPP TS 23.402: "Architecture enhancements for non-3gpp accesses". [3] ITU-T Recommendation I.130: "Method for the characterization of telecommunication services supported by an ISDN and network capabilities of an ISDN". [4] ITU-T Recommendation Q.65: "The unified functional methodology for the characterization of services and network capabilities". [5] 3GPP TS 36.300: "Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access (E-UTRAN); Overall description; Stage 2". [6] 3GPP TS 23.203: "Policy and charging control architecture". [7] 3GPP TS 23.060: "General Packet Radio Service (GPRS); Service description; Stage 2". [8] 3GPP TS 43.129: "Packet-switched handover for GERAN A/Gb mode; Stage 2". [9] 3GPP TS 23.003: "Numbering, addressing and identification". [10] 3GPP TS 23.122: "Non-Access-Stratum (NAS) functions related to Mobile Station in idle mode". [11] 3GPP TS 43.022: "Functions related to MS in idle mode and group receive mode". [12] 3GPP TS 25.304: "UE procedures in idle mode and procedures for cell re-selection in connected mode". [13] 3GPP TS 23.246: "Multimedia Broadcast/Multicast Service (MBMS); Architecture and functional description".
11 TS 123 401 V9.2.0 (2009-10) [14] 3GPP TS 29.060: "GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface". [15] 3GPP TS 43.051: "GERAN Overall description - Stage 2". [16] 3GPP TS 25.401: "UTRAN overall description". [17] IETF RFC 1034 (1987): "Domain names concepts and facilities" (STD 13). [18] IETF RFC 4862: "IPv6 Stateless Address Autoconfiguration". [19] IETF RFC 2131: "Dynamic Host Configuration Protocol". [20] IETF RFC 3736: "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6". [21] IETF RFC 3633: "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6". [22] 3GPP TS 25.413: "UTRAN Iu interface Radio Access Network Application Part (RANAP) signalling". [23] 3GPP TS 44.064: "Mobile Station - Serving GPRS Support Node (MS-SGSN); Logical Link Control (LLC) Layer Specification". [24] 3GPP TS 23.251: "Network Sharing; Architecture and functional description". [25] IETF RFC 4039: "Rapid Commit Option for the Dynamic Host Configuration Protocol version 4 (DHCPv4)". [26] IETF RFC 768: "User Datagram Protocol". [27] 3GPP TS 23.221: "Architectural requirements". [28] 3GPP TS 23.008: "Organization of subscriber data". [29] 3GPP TS 23.078: "Customized Applications for Mobile network Enhanced Logic (CAMEL) Phase X; Stage 2". [30] 3GPP TS 23.236: "Intra-domain connection of Radio Access Network (RAN) nodes to multiple Core Network (CN) nodes". [31] IETF RFC 3588: "Diameter Base Protocol". [32] IETF RFC 4861: "Neighbor Discovery for IP Version 6 (IPv6)". [33] 3GPP TS 25.331: "Radio Resource Control (RRC); Protocol Specification". [34] 3GPP TS 36.304: "Evolved Universal Terrestrial Radio Access (E-UTRA); User Equipment (UE) procedures in idle mode". [35] IETF RFC 2960: "Stream Control Transmission Protocol". [36] 3GPP TS 36.413: "Evolved Universal Terrestrial Access Network (E-UTRAN); S1 Application Protocol (S1AP)". [37] 3GPP TS 36.331: "Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification". [38] 3GPP TS 29.061: "Interworking between the Public Land Mobile Network (PLMN) supporting packet based services and Packet Data Networks (PDN)". [39] IETF RFC 3041: "Privacy Extensions for Stateless Address Autoconfiguration in IPv6". [40] 3GPP TS 33.102: "3G Security; Security architecture". [41] 3GPP TS 33.401: "3GPP System Architecture Evolution: Security Architecture". [42] 3GPP TS 48.018: "General Packet Radio Service (GPRS); Base Station System (BSS) - Serving GPRS Support Node (SGSN); BSS GPRS Protocol (BSSGP)".
12 TS 123 401 V9.2.0 (2009-10) [43] 3GPP TS 29.274: "General Packet Radio Service (GPRS); Evolved GPRS Tunnelling Protocol (egtp) for EPS". [44] 3GPP TS 32.251: "Telecommunication management; Charging management; Packet Switched (PS) domain charging". [45] 3GPP TS 24.007: "Mobile radio interface signalling layer 3; General aspects". [46] 3GPP TS 24.301: "Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Stage 3". [47] 3GPP TS 24.008: "Mobile Radio Interface Layer 3 specification; Core Network Protocols; Stage 3". [48] 3GPP TS 23.041: "Technical realization of Cell Broadcast Service (CBS)". [49] 3GPP TS 22.042: "Network Identity and Time Zone (NITZ) service description; Stage 1". [50] Void. [51] 3GPP TS 32.240: "Charging architecture and principles". [52] 3GPP TS 23.228: "IP Multimedia Subsystem (IMS); Stage 2". [53] 3GPP TS 24.285: "Allowed Closed Subscriber Group (CSG) List; Management Object (MO)". [54] 3GPP TS 23.038: "Alphabets and language-specific information". [55] IETF RFC 3168: "The Addition of Explicit Congestion Notification (ECN) to IP". [56] 3GPP TS 26.114: "IP Multimedia Subsystem (IMS); Multimedia Telephony; Media handling and interaction". [57] 3GPP TS 23.271: "Functional stage 2 description of LCS". 3 Definitions and abbreviations 3.1 Definitions For the purposes of the present document, the terms and definitions given in TR 21.905 [1] and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905 [1]. MME Pool Area: 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. Serving GW Service Area: A Serving GW Service Area is defined as an area within which a UE may be served without need to change the Serving GW. A Serving GW Service Area is served by one or more Serving GWs in parallel. Serving GW Service Areas are a collection of complete Tracking Areas. Serving GW Service Areas may overlap each other. PDN Connection: The association between a UE represented by one IPv4 address and/or one IPv6 prefix and a PDN represented by an APN. Default Bearer: The EPS bearer which is first established for a new PDN connection and remains established throughout the lifetime of the PDN connection. Default APN: A Default APN is defined as the APN which is marked as default in the subscription data and used during the Attach procedure and the UE requested PDN connectivity procedure when no APN is provided by the UE.
13 TS 123 401 V9.2.0 (2009-10) 3.2 Abbreviations For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905 [1]. AF ARP AMBR CBC CBE CSG CSG ID DL TFT ECGI ECM ECN EMM EPC EPS E-RAB E-UTRAN GBR GUMMEI GUTI GW HeNB HeNB GW HFN ISR OFCS LBI MBR MME MMEC M-TMSI OMC-ID P-GW PDCP PMIP PSAP PTI QCI RFSP S-GW S-TMSI SDF TAC TAD TAI TAU TI TIN URRP-MME UL TFT Application Function Allocation and Retention Priority Aggregate Maximum Bit Rate Cell Broadcast Centre Cell Broadcast Entity Closed Subscriber Group Closed Subscriber Group Identity DownLink Traffic Flow Template E-UTRAN Cell Global Identifier EPS Connection Management Explicit Congestion Notification EPS Mobility Management Evolved Packet Core Evolved Packet System E-UTRAN Radio Access Bearer Evolved Universal Terrestrial Radio Access Network Guaranteed Bit Rate Globally Unique MME Identifier Globally Unique Temporary Identity Gateway Home enode B Home enode B Gateway Hyper Frame Number Idle mode Signalling Reduction Offline Charging System Linked EPS Bearer Id Maximum Bit Rate Mobility Management Entity MME Code M-Temporary Mobile Subscriber Identity Operation and Maintenance Center Identity PDN Gateway Packet Data Convergence Protocol Proxy Mobile IP Public Safety Answering Point Procedure Transaction Id QoS Class Identifier RAT/Frequency Selection Priority Serving Gateway S-Temporary Mobile Subscriber Identity Service Data Flow Tracking Area Code Traffic Aggregate Description Tracking Area Identity Tracking Area Update Transaction Identifier Temporary Identity used in Next update UE Reachability Request Parameter for MME UpLink Traffic Flow Template
14 TS 123 401 V9.2.0 (2009-10) 4 Architecture model and concepts 4.1 General concepts Local breakout of IP traffic via the visited PLMN is supported, when network policies and user subscription allow it. Local breakout may be combined with support for multiple simultaneous PDN connections, described in clause 5.10. 4.2 Architecture reference model 4.2.1 Non-roaming architecture UTRAN SGSN GERAN S3 S1-MME MME S11 LTE-Uu S10 UE E-UTRAN S1-U HSS S6a S4 Serving Gateway S12 S5 Gx PDN Gateway PCRF SGi Rx Operator's IP Services (e.g. IMS, PSS etc.) Figure 4.2.1-1: Non-roaming architecture for 3GPP accesses UTRAN SGSN GERAN S3 S1-MME MME S11 LTE-Uu S10 UE E-UTRAN S1-U HSS S6a S4 Serving Gateway S12 Gx PDN Gateway PCRF SGi Rx Operator's IP Services (e.g. IMS, PSS etc.) Figure 4.2.1-2: Non-roaming architecture for 3GPP accesses. Single gateway configuration option NOTE 1: Also in this configuration option, S5 can be used between non collocated Serving Gateway and PDN Gateway. NOTE 2: Additional interfaces for 2G/3G access are shown in TS 23.060 [7].
15 TS 123 401 V9.2.0 (2009-10) 4.2.2 Roaming architecture HSS PCRF Gx Rx S6a PDN Gateway SGi Operator s IP Services (e.g. IMS, PSS etc.) HPLMN VPLMN UTRAN S8 SGSN GERAN S1 - MME S3 MME S4 S12 S11 UE LTE - Uu E - UTRAN S10 S 1 - U Serving Gateway Figure 4.2.2-1: Roaming architecture for 3GPP accesses. Home routed traffic NOTE 1: Additional interfaces/reference points for 2G/3G accesses are documented in TS 23.060 [7]. The figures 4.2.2-2 and 4.2.2-3 represent the Roaming with local breakout case with Application Function (AF) in the Home Network and in the Visited Network respectively. The concurrent use of AF's in the home network and AF's in the visited network is not excluded.
16 TS 123 401 V9.2.0 (2009-10) HSS H - PCRF Rx S6a HPLMN S9 Home Operator s IP Services VPLMN UTRAN S G SN GERAN S1 - MME S3 MME S4 S12 Gx V - PCRF S11 UE "LTE - Uu" E - UTRAN S10 S1 - U Serving G ateway S 5 PDN G ateway SGi Visited Oper ator PDN Figure 4.2.2-2: Roaming architecture for local breakout, with home operator's application functions only NOTE 2: See TS 23.203 [6 ] for the role of and functions related to Home and Visited PCRF and S9/Rx reference points. NOTE 3: In figure 4.2.2-2, the control plane signalling and the user plane for accessing to Home Operator's services traverse over the SGi reference point via the Visited Operator's PDN.
17 TS 123 401 V9.2.0 (2009-10) HSS H-PCRF S6a HPLMN S9 VPLMN UTRAN GERAN SGSN S1-MME S3 MME S4 S12 Gx V-PCRF Rx S11 UE LTE-Uu E-UTRAN S10 S1-U Serving Gateway S5 PDN Gateway SGi Visited Operator's IP Services Figure 4.2.2-3: Roaming architecture for local breakout, with visited operator's application functions only 4.2.3 Reference points S1-MME: Reference point for the control plane protocol between E-UTRAN and MME. S1-U: Reference point between E-UTRAN and Serving GW for the per bearer user plane tunnelling and inter enodeb path switching during handover. S3: It enables user and bearer information exchange for inter 3GPP access network mobility in idle and/or active state. S4: It provides related control and mobility support between GPRS Core and the 3GPP Anchor function of Serving GW. In addition, if Direct Tunnel is not established, it provides the user plane tunnelling. S5: It provides user plane tunnelling and tunnel management between Serving GW and PDN GW. It is used for Serving GW relocation due to UE mobility and if the Serving GW needs to connect to a noncollocated PDN GW for the required PDN connectivity. S6a: Gx: It enables transfer of subscription and authentication data for authenticating/authorizing user access to the evolved system (AAA interface) between MME and HSS. It provides transfer of (QoS) policy and charging rules from PCRF to Policy and Charging Enforcement Function (PCEF) in the PDN GW. S8: Inter-PLMN reference point providing user and control plane between the Serving GW in the VPLMN and the PDN GW in the HPLMN. S8 is the inter PLMN variant of S5. S9: It provides transfer of (QoS) policy and charging control information between the Home PCRF and the Visited PCRF in order to support local breakout function. S10: Reference point between MMEs for MME relocation and MME to MME information transfer. S11: Reference point between MME and Serving GW.
18 TS 123 401 V9.2.0 (2009-10) S12: Reference point between UTRAN and Serving GW for user plane tunnelling when Direct Tunnel is established. It is based on the Iu-u/Gn-u reference point using the GTP-U protocol as defined between SGSN and UTRAN or respectively between SGSN and GGSN. Usage of S12 is an operator configuration option. S13: It enables UE identity check procedure between MME and EIR. SGi: It is the reference point between the PDN GW and the packet data network. Packet data network may be an operator external public or private packet data network or an intra operator packet data network, e.g. for provision of IMS services. This reference point corresponds to Gi for 3GPP accesses. Rx: The Rx reference point resides between the AF and the PCRF in the TS 23.203 [6]. SBc: Reference point between CBC and MME for warning message delivery and control functions. When data forwarding is used as part of mobility procedures different user plane routes may be used based on the network configuration (e.g. direct or indirect data forwarding). These routes can be between enodeb and RNC, enodeb and SGSN, RNC and S-GW or between S-GW and SGSN. Explicit reference points are not defined for these routes. Protocol assumption: - The S1-U is based on GTP-U protocol; - The S3 is based on GTP protocol; - The S4 is based on GTP protocol; - The S5 is based on GTP protocol. PMIP variant of S5 is described in TS 23.402 [2]; - The S8 is based on GTP protocol. PMIP variant of S8 is described in TS 23.402 [2]. - S3, S4, S5, S8, S10 and S11 interfaces are designed to manage EPS bearers as defined in clause 4.7.2. NOTE: Redundancy support on reference points S5 and S8 should be taken into account. 4.2.4 Warning System architecture UE E-UTRAN MME CBC CBE LTE-Uu S1-MME SBc Figure 4.2.4-1: Warning System Architecture for 3GPP Accesses NOTE: The CBE and the interface between CBE and CBC are out of scope of 3GPP specifications. 4.3 High level functions 4.3.1 General The following list gives the logical functions performed within this system. Several functional groupings (meta functions) are defined and each encompasses a number of individual functions: - Network Access Control Functions. - Packet Routeing and Transfer Functions. - Mobility Management Functions. - Security Functions.
19 TS 123 401 V9.2.0 (2009-10) - Radio Resource Management Functions. - Network Management Functions. 4.3.2 Network access control functions 4.3.2.1 General Network access is the means by which a user is connected to the evolved packet core system. 4.3.2.2 Network/Access network selection It is the means by which a UE selects a PLMN/Access network from which to gain IP connectivity. The network/access network selection procedure varies for different access technologies. For 3GPP access networks, the network selection principles are described in TS 23.122 [10]. For 3GPP access networks, the access network selection procedures are described in TS 36.300 [5], TS 43.022 [11] and TS 25.304 [12]. Architectural impacts stemming from support for network/access network selection procedures for non-3gpp access and between 3GPP access and non-3gpp accesses are described in TS 23.402 [2]. 4.3.2.3 Authentication and authorisation function This function performs the identification and authentication of the service requester, and the validation of the service request type to ensure that the user is authorised to use the particular network services. The authentication function is performed in association with the Mobility Management functions. 4.3.2.4 Admission control function The purpose of admission control is to determine if the requested resources are available, and then reserve those resources. 4.3.2.5 Policy and Charging Enforcement Function This includes all the functionality of PCEF as defined by TS 23.203 [6]. The PCEF encompasses service data flow detection, policy enforcement and flow based charging functionalities as defined in TS 23.203 [6]. 4.3.2.6 Lawful Interception Lawful interception is the action, performed by a network operator / access provider / service provider, of making available certain information and providing that information to a law enforcement monitoring facility. 4.3.3 Packet routeing and transfer functions 4.3.3.1 General A route is an ordered list of nodes used for the transfer of packets within and between the PLMN(s). Each route consists of the originating node, zero or more relay nodes and the destination node. Routeing is the process of determining and using, in accordance with a set of rules, the route for transmission of a message within and between the PLMN(s). The EPS is an IP network and uses the standard routeing and transport mechanisms of the underlying IP network. 4.3.3.2 IP header compression function The IP header compression function optimises use of radio capacity by IP header compression mechanisms.
20 TS 123 401 V9.2.0 (2009-10) 4.3.3.3 Packet screening function The packet screening function provides the network with the capability to check that the UE is using the exact IPv4- Address and/or IPv6-Prefix that was assigned to the UE. 4.3.4 Security functions The security functions are described in clause 5.3.10. 4.3.5 Mobility management functions 4.3.5.1 General The mobility management functions are used to keep track of the current location of a UE. 4.3.5.2 Reachability Management for UE in ECM-IDLE state The location of a UE in ECM-IDLE state is known by the network on a Tracking Area List granularity. A UE in ECM- IDLE state is paged in all cells of the Tracking Areas in which it is currently registered. The UE may be registered in multiple Tracking Areas. All the tracking areas in a Tracking Area List to which a UE is registered are served by the same serving MME. An EMM-REGISTERED UE performs periodic Tracking Area Updates with the network after the expiry of the periodic TAU timer. If the UE is out of E-UTRAN coverage (including the cases when the UE is camped on GERAN/UTRAN cells) when its periodic TAU timer expires, the UE shall: - if ISR is activated, start the E-UTRAN Deactivate ISR timer. After the E-UTRAN Deactivate ISR timer expires the UE shall deactivate ISR by setting its TIN to "P-TMSI". - if ISR is activated and the UE is camping on a GERAN/UTRAN cell (or returns to coverage in GERAN/UTRAN) and the UE is EPS/IMSI attached, perform a LAU procedure in NMO II/III or a combined RA/LA update procedure in NMO I. - when EMM-REGISTERED, perform a Tracking Area Update when it next returns to E-UTRAN coverage. If the UE is camped on an E-UTRAN cell or is in ECM-CONNECTED state when the UE's periodic RAU timer expires, the UE shall: - if ISR is activated, start the GERAN/UTRAN Deactivate ISR timer. After the GERAN/UTRAN Deactivate ISR timer expires the UE shall deactivate ISR by setting its TIN to "GUTI". - perform a Routing Area Update when it next returns to GERAN/UTRAN coverage. If the UE is EPS attached only and either camps on an E UTRAN cell or is in ECM CONNECTED state when the UE's periodic LAU timer expires, the UE shall perform a Location Area Update procedure in NMO II/III or combined RA/LA update in NMO I when it next returns to GERAN/UTRAN coverage. The E-UTRAN Deactivate ISR timer is stopped when the UE performs a successful Tracking Area Update or combined TA/LA Update; and the GERAN/UTRAN Deactivate ISR timer is stopped when the UE performs a successful Routing Area Update or combined RA/LA Update. Expiry of the periodic TAU timer, or, the periodic RAU timer, or, the periodic LAU timer shall not cause the UE to change RAT. The UE's periodic TAU timer is restarted from its initial value whenever the UE enters ECM-IDLE mode and when the UE leaves the E-UTRAN connection due to handover to GERAN/UTRAN. UTRAN RRC state transitions and GERAN GPRS STANDBY/READY state transitions shall have no other impact on the periodic TAU timer. E-UTRAN RRC state transitions shall have no impact on the periodic RAU timer or periodic LAU timer except that handover from GERAN/UTRAN to E-UTRAN shall cause the periodic RAU timer to be started from its initial value.
21 TS 123 401 V9.2.0 (2009-10) Handover from E UTRAN to UTRAN/GERAN shall cause the periodic TAU timer to be started from its initial value. Typically, the MME runs a mobile reachable timer with a similar value to the UE's periodic TAU timer. If this timer expires in the MME, the MME can deduce that the UE is 'out of coverage' at that moment. However, the MME does not know for how long the UE has been out of coverage, so, the MME shall not immediately delete the UE's bearers. Instead the MME should clear the PPF flag in the MME and start an Implicit Detach timer, with a relatively large value and if ISR is activated, at least slightly larger than the UE's E-UTRAN Deactivate ISR timer. With the PPF clear, the MME does not page the UE in E-UTRAN coverage and shall send a Downlink Data Notification Reject message to the Serving GW when receiving a Downlink Data Notification message from the Serving GW. If this Implicit Detach timer expires before the UE contacts the network, then the MME can deduce that the UE has been 'out of coverage' for a long period of time and implicitly detach the UE as described in clause 5.3.8.3 "MME-initiated Detach procedure". NOTE 1: The SGSN has similar functionality as the MME. NOTE 2: Alternative MME implementations are permitted, however, the externally visible MME behaviour should conform to the above description. 4.3.5.3 Tracking Area list management Tracking Area list management comprises the functions to allocate and reallocate a Tracking Area Identity list to the UE. All the tracking areas in a Tracking Area List to which a UE is registered are served by the same serving MME. 4.3.5.4 Inter-eNodeB mobility anchor function The Inter-eNodeB Mobility Anchor is the functional entity that anchors the user plane for E-UTRAN mobility. 4.3.5.5 Inter-3GPP mobility anchor function The Inter-3GPP Mobility Anchor is the functional entity that anchors the user plane for mobility between 3GPP 2G/3G access systems and the E-UTRA access system. 4.3.5.6 Idle mode signalling reduction function The Idle mode Signalling Reduction (ISR) function provides a mechanism to limit signalling during inter-rat cellreselection in idle mode (ECM-IDLE, PMM-IDLE, GPRS STANDBY states). NOTE: The Idle mode Signalling Reduction function is mandatory for E-UTRAN UEs that support GERAN and/or UTRAN and optional for core network. The UE's ISR capability in the UE Core Network Capability element is for test purpose. ISR shall be activated by decision of the CN nodes and shall be explicitly signalled to the UE as "ISR activated" in the RAU and TAU Accept messages. The UE may have valid MM parameters both from MME and from SGSN. The "Temporary Identity used in Next update" (TIN) is a parameter of the UE's MM context, which identifies the UE identity that the UE shall indicate in the next RAU Request, TAU Request or Attach Request message. The TIN also identifies the status of ISR activation in the UE. The TIN can take one of the three values, "P-TMSI", "GUTI" or "RAT-related TMSI". The UE shall set the TIN when receiving an Attach Accept, a TAU Accept or RAU Accept message according to the rules in table 4.3.5.6-1.
22 TS 123 401 V9.2.0 (2009-10) Table 4.3.5.6-1: Setting of the TIN Message received by UE Attach Accept via E-UTRAN (never indicates "ISR Activated") Attach Accept via GERAN/UTRAN (never indicates "ISR Activated") TAU Accept not indicating "ISR Activated" TAU Accept indicating "ISR Activated" RAU Accept not indicating "ISR Activated" RAU Accept indicating "ISR Activated" Current TIN value stored by UE Any value Any value Any value GUTI P-TMSI or RAT-related TMSI Any value P-TMSI GUTI or RAT-related TMSI TIN value to be set by the UE when receiving message GUTI P-TMSI GUTI GUTI RAT-related TMSI P-TMSI P-TMSI RAT-related TMSI When "ISR Activated" is indicated by the RAU/TAU Accept message but the UE shall not set the TIN to "RAT-related TMSI" is a special situation. Here the UE has deactivated ISR due to special situation handling. By maintaining the old TIN value the UE remembers to use the RAT specific TMSI indicated by the TIN when updating with the CN node of the other RAT. Only if the TIN is set to "RAT-related TMSI" ISR behaviour is enabled for the UE, i.e. the UE can change between all registered areas and RATs without any update signalling and it listens for paging on the RAT it is camped on. If the TIN is set to "RAT-related TMSI", the UE's P-TMSI and RAI as well as its GUTI and TAI(s) shall remain registered with the network and shall remain valid in the UE. Table 4.3.5.6-2: Temporary UE Identity that the UE shall indicate in Attach Request and TAU/RAU Request (as "old GUTI" or as "old P-TMSI/RAI" information element) Message to be sent by UE TIN value: P-TMSI TIN value: GUTI TIN value: RAT-related TMSI TAU Request GUTI mapped from GUTI GUTI P-TMSI/RAI RAU Request P-TMSI/RAI P-TMSI/RAI mapped from P-TMSI/RAI GUTI Attach Request via E- GUTI mapped from GUTI GUTI UTRAN P-TMSI/RAI Attach Request via GERAN/UTRAN P-TMSI/RAI P-TMSI/RAI mapped from GUTI P-TMSI/RAI Table 4.3.5.6-2 shows which temporary identity the UE shall indicate in a Tracking or Routing Area Update Request or in an Attach Request message, when the UE stores these as valid parameters. Situations may occur that cause unsynchronized state information in the UE, MME and SGSN. Such special situations trigger a deactivation of ISR locally in the UE. The UE shall deactivate ISR locally by setting its TIN to the temporary identity of the currently used RAT in following special situations: - Modification of any EPS bearer context or PDP context which was activated before the ISR is activated in the UE; - At the time when the UE moves from E-UTRAN to GERAN/UTRAN or moves from GERAN/UTRAN to E-UTRAN, if any EPS bearer context or PDP context activated after the ISR was activated in the UE exists; - After updating either MME or SGSN about the change of the UE specific DRX parameters to guarantee that the other CN node is also updated; - After updating either MME or SGSN about the change of the UE Core Network Capabilities to guarantee that the other CN node is also updated; - E-UTRAN selection by a UTRAN-connected UE (e.g. when in URA_PCH to release Iu on UTRAN side);
23 TS 123 401 V9.2.0 (2009-10) - After a LAU procedure if the UE has CS fallback activated. The UE shall deactivate ISR locally by setting its TIN to the temporary identity of the RAT that is still available to the UE in following special situations: - After the RAT-specific Deactivate ISR timer expires, e.g. because the coverage of that RAT is lost or the RAT is no more selected by the UE (this may result also in implicit detach by SGSN or MME). ISR shall be deactivated in the UE by the CN node using normal update signalling, i.e. by omitting the signalling of "ISR Activated", in following special situations: - CN node change resulting in context transfer between the same type of CN nodes (SGSN to SGSN or MME to MME); - Serving GW change. 4.3.5.7 Mobility Restrictions Mobility Restrictions comprises the functions for restrictions to mobility handling of a UE in E-UTRAN access. The Mobility Restriction functionality is provided by the UE, the radio access network and the core network. Mobility Restriction functionality in state ECM-IDLE is executed in UE based on information received from the core network. Mobility Restriction functionality in state ECM-CONNECTED is executed in the radio network and the core network. In state ECM-CONNECTED, the core network provides the radio network with a Handover Restriction List. The Handover Restriction List specifies roaming, area and access restrictions. 4.3.5.8 IMS voice over PS Session Supported Indication The serving PLMN shall send an indication toward the UE during the Attach procedure and Tacking Area Update procedures if an IMS voice over PS session is supported. The serving PLMN uses this indicator to indicate to the UE whether it can expect a successful IMS voice over PS session. A UE with "IMS voice over PS" voice capability should take this indication into account, as specified in TS 23.221 [17]. The serving PLMN provides this indication based e.g. on local policy, HPLMN, the SRVCC capability of the network and UE and/or extends of E-UTRAN/UTRAN coverage. This indication is per TAI list. 4.3.6 Radio Resource Management functions Radio resource management functions are concerned with the allocation and maintenance of radio communication paths, and are performed by the radio access network. The RRM strategy in E-UTRAN may be based on user specific information. To support radio resource management in E-UTRAN the MME provides the parameter 'Index to RAT/Frequency Selection Priority' (RFSP Index) to an enb across S1. The RFSP Index is mapped by the enodeb to locally defined configuration in order to apply specific RRM strategies. The RFSP Index is UE specific and applies to all the Radio Bearers. Examples of how this parameter may be used by the E-UTRAN: - to derive UE specific cell reselection priorities to control idle mode camping. - to decide on redirecting active mode UEs to different frequency layers or RATs. The MME receives the subscribed RFSP Index from the HSS (e.g., during the Attach procedure). For non-roaming subscribers the MME chooses the RFSP Index in use according to one of the following procedures, depending on operator's configuration: - the RFSP Index in use is identical to the subscribed RFSP Index, or - the MME chooses the RFSP Index in use based on the subscribed RFSP Index, the locally configured operator's policies and the UE related context information available at the MME, e.g. the UE voice capabilities and settings received as part of the UE Network Capability.
24 TS 123 401 V9.2.0 (2009-10) For roaming subscribers the MME may alternatively choose the RFSP Index in use based on the visited network policy (e.g., an RFSP Index value pre-configured per HPLMN, or a single RFSP Index value to be used for all roamers independent of the HPLMN). The MME forwards the RFSP Index in use to the enb across S1. The RFSP Index in use is also forwarded from source enodeb to target enodeb when X2 is used for intra-e-utran handover. The MME stores the subscribed RFSP Index value received from the HSS and the RFSP Index value in use. During the Tracking Area Update procedure the MME may update the RFSP Index value in use and signal the updated value to the enodeb across S1, if the locally configured operator's policies indicate to do so (e.g., the MME may need to update the RFSP Index value in use if the UE related context information has changed). During inter-mme mobility procedures, the source MME forwards both RFSP Index values to the target MME. The target MME may replace the received RFSP Index value in use with a new RFSP Index value in use that is based on the operator's policies and the UE related context information available at the target MME. The S1 messages that transfer the RFSP Index to the enodeb are specified in TS 36.413 [36]. Refer to TS 36.300 [5] for further information on E-UTRAN. 4.3.7 Network management functions 4.3.7.1 General Network management functions provide mechanisms to support O&M functions related to the Evolved Packet System. 4.3.7.2 Load balancing between MMEs The MME Load Balancing functionality permits UEs that are entering into an MME Pool Area to be directed to an appropriate MME in a manner that achieves load balancing between MMEs. This is achieved by setting a Weight Factor for each MME, such that the probability of the enodeb selecting an MME is proportional to its Weight Factor. The Weight Factor is typically set according to the capacity of an MME node relative to other MME nodes. The Weight Factor is sent from the MME to the enodeb via S1-AP messages (see TS 36.413 [36]). If a HeNB GW is deployed, the Weight Factor is sent from the MME to the HeNB GW. NOTE 1: An operator may decide to change the Weight Factor after the establishment of S1-MME connectivity as a result of changes in the MME capacities. E.g., a newly installed MME may be given a very much higher Weight Factor for an initial period of time making it faster to increase its load. NOTE 2: It is intended that the Weight Factor is NOT changed frequently. e.g. in a mature network, changes on a monthly basis could be anticipated, e.g. due to the addition of RAN or CN nodes. 4.3.7.3 Load re-balancing between MMEs The MME Load Re-balancing functionality permits UEs that are registered on an MME (within an MME Pool Area) to be moved to another MME. NOTE 1: An example use for the MME Load Re-balancing function is for the O+M related removal of one MME from an MME Pool Area. NOTE 2: Typically, this procedure should not be used when the MME becomes overloaded because the Load Balancing function should have ensured that the other MMEs in the pool area are similarly overloaded. The enodebs may have their Load Balancing parameters adjusted beforehand (e.g. the Weight Factor is set to zero if all subscribers are to be removed from the MME, which will route new entrants to the pool area into other MMEs). In addition the MME may off-load a cross-section of its subscribers with minimal impacts on the network and users (e.g. the MME should avoid offloading only the low activity users while retaining the high activity subscribers. Gradual rather than sudden off-loading should be performed as a sudden re-balance of large number of subscribers could overload other MMEs in the pool. With minimal impact on network and the user's experience, the subscribers should be off-loaded as soon as possible). The load re-balancing can off-load part of or all the subscribers.