3GPP TS 23.401: Technical Specification

3GPP TS 23.401 V15.10.
0 (2019-12)
Technical Specification
3rd Generation Partnership Project;
Technical Specification Group Services and System Aspects;
General Packet Radio Service (GPRS) enhancements for
Evolved Universal Terrestrial Radio Access Network
(E-UTRAN) access
(Release 15)
The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP.
The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented.
This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this
Specification.
Specifications and reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners' Publications Offices.
Release 15 2 3GPP TS 23.401 V15.10.0 (2019-12)
Keywords
LTE, GSM, UMTS, GPRS, architecture, stage 2
3GPP
Postal address
3GPP support office address

650 Route des Lucioles - Sophia Antipolis
Valbonne - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Internet
http://www.3gpp.org
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.
© 2019, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC).
All rights reserved.
UMTS™ is a Trade Mark of ETSI registered for the benefit of its members
3GPP™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners
LTE™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners
GSM® and the GSM logo are registered and owned by the GSM Association
3GPP
Release 15 3 3GPP TS 23.401 V15.10.0 (2019-12)
Contents
Foreword........................................................................................................................................................12
1 Scope....................................................................................................................................................13
2 References............................................................................................................................................13
3 Definitions and abbreviations...............................................................................................................16
3.1 Definitions.........................................................................................................................................................16
3.2 Abbreviations.....................................................................................................................................................18
4 Architecture model and concepts..........................................................................................................19
4.1 General concepts................................................................................................................................................19
4.2 Architecture reference model............................................................................................................................20
4.2.1 Non-roaming architecture............................................................................................................................20
4.2.2 Roaming architecture...................................................................................................................................21
4.2.3 Reference points...........................................................................................................................................23
4.2.4 Warning System architecture.......................................................................................................................24
4.3 High level functions...........................................................................................................................................24
4.3.1 General.........................................................................................................................................................24
4.3.2 Network access control functions................................................................................................................25
4.3.2.1 General...................................................................................................................................................25
4.3.2.2 Network/Access network selection........................................................................................................25
4.3.2.3 Authentication and authorisation function.............................................................................................25
4.3.2.4 Admission control function....................................................................................................................25
4.3.2.5 Policy and Charging Enforcement Function..........................................................................................25
4.3.2.6 Lawful Interception................................................................................................................................25
4.3.2a Support for Dual Connectivity.....................................................................................................................25
4.3.3 Packet routing and transfer functions...........................................................................................................27
4.3.3.1 General...................................................................................................................................................27
4.3.3.2 IP header compression function.............................................................................................................27
4.3.3.3 Packet screening function.......................................................................................................................27
4.3.3.4 IP Multicast Forwarding between a network accessed by LIPA and a UE............................................27
4.3.4 Security functions........................................................................................................................................27
4.3.5 Mobility management functions..................................................................................................................27
4.3.5.1 General...................................................................................................................................................27
4.3.5.2 Reachability Management for UE in ECM-IDLE state.........................................................................28
4.3.5.3 Tracking Area list management.............................................................................................................29
4.3.5.4 Inter-eNodeB mobility anchor function.................................................................................................29
4.3.5.5 Inter-3GPP mobility anchor function.....................................................................................................29
4.3.5.6 Idle mode signalling reduction function.................................................................................................30
4.3.5.7 Mobility Restrictions..............................................................................................................................32
4.3.5.8 IMS voice over PS Session Supported Indication..................................................................................32
4.3.5.8A Homogenous Support of IMS Voice over PS Sessions Indication........................................................32
4.3.5.9 Voice domain preference and UE's usage setting..................................................................................33
4.3.5.10 Preferred and Supported Network Behaviour........................................................................................33
4.3.6 Radio Resource Management functions......................................................................................................34
4.3.7 Network management functions..................................................................................................................35
4.3.7.1 General...................................................................................................................................................35
4.3.7.1a GTP-C signalling based Load and Overload Control............................................................................35
4.3.7.1a.1 GTP-C Load Control........................................................................................................................35
4.3.7.1a.2 GTP-C Overload Control..................................................................................................................35
4.3.7.2 Load balancing between MMEs.............................................................................................................37
4.3.7.3 Load re-balancing between MMEs........................................................................................................37
4.3.7.4 MME control of overload.......................................................................................................................38
4.3.7.4.1 General..............................................................................................................................................38
4.3.7.4.1a Throttling of Downlink Data Notification Requests........................................................................40
4.3.7.4.1b Throttling of NIDD Submit Requests...............................................................................................40
4.3.7.4.2 NAS level congestion control...........................................................................................................41
3GPP
Release 15 4 3GPP TS 23.401 V15.10.0 (2019-12)
4.3.7.5 PDN GW control of overload.................................................................................................................46

4.3.8 Selection functions.......................................................................................................................................46
4.3.8.1 PDN GW selection function (3GPP accesses).......................................................................................46
4.3.8.2 Serving GW selection function..............................................................................................................48
4.3.8.3 MME selection function.........................................................................................................................49
4.3.8.4 SGSN selection function........................................................................................................................50
4.3.8.5 Selection of PCRF..................................................................................................................................50
4.3.9 IP network related functions........................................................................................................................51
4.3.9.1 Domain Name Service function.............................................................................................................51
4.3.9.2 DHCP function.......................................................................................................................................51
4.3.9.3 Explicit Congestion Notification............................................................................................................51
4.3.10 Functionality for Connection of eNodeBs to Multiple MMEs....................................................................51
4.3.11 E-UTRAN Sharing Function.......................................................................................................................51
4.3.12 IMS Emergency Session Support................................................................................................................52
4.3.12.1 Introduction............................................................................................................................................52
4.3.12.2 Architecture Reference Model for Emergency Services........................................................................53
4.3.12.3 Mobility and Access Restrictions for Emergency Services...................................................................53
4.3.12.3a Reachability Management for UE in ECM-IDLE state.........................................................................54
4.3.12.4 PDN GW selection function (3GPP accesses) for Emergency Services................................................54
4.3.12.5 QoS for Emergency Services.................................................................................................................54
4.3.12.6 PCC for Emergency Services.................................................................................................................54
4.3.12.7 Load re-balancing between MMEs for Emergency Services.................................................................55
4.3.12.8 IP Address Allocation............................................................................................................................55
4.3.12.9 Handling of PDN Connections for Emergency Bearer Services............................................................55
4.3.12.10 ISR function for Emergency Bearer Services........................................................................................55
4.3.12.11 Support of eCall Only Mode..................................................................................................................55
4.3.13 Closed Subscriber Group functions.............................................................................................................56
4.3.14 Location Service functions...........................................................................................................................56
4.3.15 Selected IP Traffic Offload (SIPTO) function.............................................................................................56
4.3.15a Selected IP Traffic Offload (SIPTO) at the Local Network........................................................................57
4.3.15a.1 General...................................................................................................................................................57
4.3.15a.2 SIPTO at the Local Network with stand-alone GW (with S-GW and L-GW collocated) function.......58
4.3.15a.3 SIPTO at the Local Network with L-GW function collocated with the (H)eNB...................................58
4.3.16 Local IP Access (LIPA) function.................................................................................................................59
4.3.17 Support for Machine Type Communications (MTC)..................................................................................60
4.3.17.1 General...................................................................................................................................................60
4.3.17.2 Overview of protection from Potential MTC Related Overload............................................................60
4.3.17.3 Optimising periodic TAU Signalling.....................................................................................................62
4.3.17.4 UE configuration and usage of indicators..............................................................................................62
4.3.17.5 Void........................................................................................................................................................64
4.3.17.6 Support of UEs configured for low access priority, Extended Access Barring and permission for
override...................................................................................................................................................64
4.3.17.7 High latency communication.................................................................................................................64
4.3.17.8 Support for Non-IP Data Delivery (NIDD)............................................................................................65
4.3.17.8.1 General..............................................................................................................................................65
4.3.17.8.2 ESM Procedures...............................................................................................................................65
4.3.17.8.3 Delivery mechanism.........................................................................................................................66
4.3.17.9 Service Gap Control...............................................................................................................................67
4.3.18 Multimedia Priority Service.........................................................................................................................69
4.3.18.1 General...................................................................................................................................................69
4.3.18.2 IMS-based Multimedia Priority Services...............................................................................................70
4.3.18.2.1 Originating IMS-based MPS Session...............................................................................................70
4.3.18.2.2 Terminating IMS-based MPS Session..............................................................................................70
4.3.18.3 Priority EPS Bearer Services..................................................................................................................70
4.3.18.4 CS fallback.............................................................................................................................................71
4.3.18.5 Network Congestion Controls for MPS.................................................................................................71
4.3.18.6 Load Re-balancing between MMEs for MPS........................................................................................71
4.3.19 Core Network node resolution.....................................................................................................................71
4.3.19.1 General...................................................................................................................................................71
4.3.19.2 MSB in LAC and MME Group ID.........................................................................................................71
4.3.19.3 Explicit Indication..................................................................................................................................71
3GPP
Release 15 5 3GPP TS 23.401 V15.10.0 (2019-12)
4.3.20 Relaying function.........................................................................................................................................72

4.3.20.1 General...................................................................................................................................................72
4.3.20.2 RN startup and attach procedure............................................................................................................72
4.3.20.2.1 General..............................................................................................................................................72
4.3.20.2.2 Attach for RN preconfiguration........................................................................................................73
4.3.20.2.3 Attach for RN operation...................................................................................................................73
4.3.20.3 DeNB E-RAB activation/modification..................................................................................................74
4.3.21 Core Network assisted eNodeB parameters tuning......................................................................................75
4.3.21.1 CN Assistance Information....................................................................................................................75
4.3.21.2 Void........................................................................................................................................................75
4.3.21.3 Core Network Assistance Procedures....................................................................................................75
4.3.22 UE Power Saving Mode...............................................................................................................................76
4.3.23 Access network selection and traffic steering based on RAN-assisted WLAN interworking.....................77
4.3.23a Access network selection and traffic steering based on RAN-Controlled WLAN interworking................78
4.3.24 RAN user plane congestion management function......................................................................................78
4.3.24.1 General...................................................................................................................................................78
4.3.24.2 RAN user plane congestion mitigation in the RAN...............................................................................78
4.3.24.3 RAN user plane congestion mitigation in the CN..................................................................................78
4.3.25 Dedicated Core Networks (DCNs)..............................................................................................................79
4.3.25.1 General...................................................................................................................................................79
4.3.25.1a UE assisted Dedicated Core Network selection.....................................................................................80
4.3.25.2 Considerations for Roaming...................................................................................................................81
4.3.25.3 Considerations for Network Sharing......................................................................................................81
4.3.26 Support for Monitoring Events....................................................................................................................81
4.3.27 Paging Enhancements..................................................................................................................................81
4.3.27.1 Paging for Enhanced Coverage..............................................................................................................81
4.3.27a Restriction of use of Enhanced Coverage for voice centric UE..................................................................82
4.3.27b Enhanced Coverage for data centric UEs....................................................................................................82
4.3.28 Restriction of use of Enhanced Coverage....................................................................................................82
4.3.29 3GPP PS Data Off........................................................................................................................................82
4.3.29.1 General...................................................................................................................................................82
4.3.30 Unlicensed spectrum aggregation (LAA/LWA/LWIP)...............................................................................83
4.3.31 Subscription handling for Aerial UEs..........................................................................................................84
4.4 Network elements..............................................................................................................................................84
4.4.1 E-UTRAN....................................................................................................................................................84
4.4.2 MME............................................................................................................................................................84
4.4.3 Gateway.......................................................................................................................................................86
4.4.3.1 General...................................................................................................................................................86
4.4.3.2 Serving GW............................................................................................................................................86
4.4.3.3 PDN GW................................................................................................................................................86
4.4.4 SGSN...........................................................................................................................................................87
4.4.5 GERAN........................................................................................................................................................88
4.4.6 UTRAN........................................................................................................................................................88
4.4.7 PCRF............................................................................................................................................................88
4.4.7.1 General...................................................................................................................................................88
4.4.7.2 Home PCRF (H-PCRF)..........................................................................................................................88
4.4.7.3 Visited PCRF (V-PCRF)........................................................................................................................88
4.4.8 PDN GW's associated AAA Server.............................................................................................................88
4.4.9 HeNB subsystem..........................................................................................................................................88
4.4.10 DeNB...........................................................................................................................................................89
4.4.11 CSG Subscriber Server................................................................................................................................90
4.4.12 RAN Congestion Awareness Function........................................................................................................90
4.5 Void...................................................................................................................................................................91
4.6 EPS Mobility Management and Connection Management states......................................................................91
4.6.1 General.........................................................................................................................................................91
4.6.2 Definition of main EPS Mobility Management states.................................................................................91
4.6.2.1 EMM-DEREGISTERED.......................................................................................................................91
4.6.2.2 EMM-REGISTERED.............................................................................................................................91
4.6.3 Definition of EPS Connection Management states......................................................................................92
4.6.3.1 ECM-IDLE.............................................................................................................................................92
4.6.3.2 ECM-CONNECTED..............................................................................................................................93
3GPP
Release 15 6 3GPP TS 23.401 V15.10.0 (2019-12)
4.6.4 State transition and functions.......................................................................................................................93

4.7 Overall QoS concept..........................................................................................................................................94
4.7.1 PDN connectivity service.............................................................................................................................94
4.7.2 The EPS bearer.............................................................................................................................................95
4.7.2.1 The EPS bearer in general......................................................................................................................95
4.7.2.2 The EPS bearer with GTP-based S5/S8.................................................................................................97
4.7.2.3 The EPS bearer with PMIP-based S5/S8...............................................................................................98
4.7.3 Bearer level QoS parameters........................................................................................................................98
4.7.4 Support for Application / Service Layer Rate Adaptation.........................................................................100
4.7.5 Application of PCC in the Evolved Packet System...................................................................................100
4.7.6 Bearer Control Mode in EPC.....................................................................................................................101
4.7.7 Support of rate control of user data using CIoT EPS Optimisation...........................................................101
4.7.7.1 General.................................................................................................................................................101
4.7.7.2 Serving PLMN Rate Control................................................................................................................102
4.7.7.3 APN Rate Control................................................................................................................................102
4.7.8 Inter-UE QoS for NB-IoT UEs using Control Plane CIoT EPS Optimisation..........................................103
4.8 Compatibility Issues........................................................................................................................................104
4.8.1 Network Configuration for Interaction with UTRAN/GERAN................................................................104
4.9 Paging Policy Differentiation..........................................................................................................................104
4.10 Introduction of CIoT EPS Optimisations........................................................................................................104
4.11 User Plane CIoT EPS Optimisation.................................................................................................................105
4.12 Supporting up to 15 EPS bearers per UE........................................................................................................106
5 Functional description and information flows....................................................................................107
5.1 Control and user planes...................................................................................................................................107
5.1.0 General.......................................................................................................................................................107
5.1.1 Control Plane..............................................................................................................................................107
5.1.1.1 General.................................................................................................................................................107
5.1.1.2 eNodeB - MME....................................................................................................................................107
5.1.1.3 UE - MME............................................................................................................................................108
5.1.1.4 SGSN - MME.......................................................................................................................................108
5.1.1.5 SGSN - S-GW......................................................................................................................................109
5.1.1.6 S-GW - P-GW......................................................................................................................................109
5.1.1.7 MME - MME.......................................................................................................................................110
5.1.1.8 MME - S-GW.......................................................................................................................................110
5.1.1.9 MME - HSS..........................................................................................................................................111
5.1.1.10 MME - EIR...........................................................................................................................................111
5.1.1.11 Void......................................................................................................................................................111
5.1.1.12 MME - CSS..........................................................................................................................................112
5.1.1.13 MME - RCAF.......................................................................................................................................112
5.1.2 User Plane..................................................................................................................................................113
5.1.2.1 UE - P-GW user plane with E-UTRAN...............................................................................................113
5.1.2.2 eNodeB - S-GW...................................................................................................................................113
5.1.2.3 UE - PDN GW user plane with 2G access via the S4 interface...........................................................114
5.1.2.4 UE - PDN GW user plane with 3G access via the S12 interface.........................................................115
5.1.2.5 UE - PDN GW user plane with 3G access via the S4 interface...........................................................116
5.1.2.6 UE - P-GW user plane with Control Plane CIoT EPS Optimisations..................................................117
5.2 Identities..........................................................................................................................................................117
5.2.1 EPS bearer identity.....................................................................................................................................117
5.2.2 Globally Unique Temporary UE Identity..................................................................................................117
5.2.3 Tracking Area Identity (TAI).....................................................................................................................118
5.2.4 eNodeB S1-AP UE Identity (eNodeB S1-AP UE ID)...............................................................................118
5.2.5 MME S1-AP UE Identity (MME S1-AP UE ID)......................................................................................118
5.2.6 Closed Subscriber Group ID......................................................................................................................118
5.3 Authentication, security and location management.........................................................................................118
5.3.1 IP address allocation..................................................................................................................................118
5.3.1.1 General.................................................................................................................................................118
5.3.1.2 IP address allocation, renewal and release mechanisms for GTP based S5/S8...................................121
5.3.1.2.1 IPv4 address allocation via default bearer activation and release via PDN connection release.....121
5.3.1.2.2 Allocation, renewal and release of the IPv6 default prefix via IPv6 stateless address
autoconfiguration............................................................................................................................121
5.3.1.2.3 IPv6 parameter configuration via stateless DHCPv6.....................................................................122
3GPP
Release 15 7 3GPP TS 23.401 V15.10.0 (2019-12)
5.3.1.2.4 IPv4 address allocation, renewal and release and IPv4 parameter configuration via DHCPv4.....122
5.3.1.2.5 Void................................................................................................................................................123
5.3.1.2.6 IPv6 Prefix Delegation via DHCPv6..............................................................................................123
5.3.2 Attach procedure........................................................................................................................................123
5.3.2.1 E-UTRAN Initial Attach......................................................................................................................123
5.3.2.2 UTRAN/GERAN Initial Attach...........................................................................................................138
5.3.3 Tracking Area Update procedures.............................................................................................................139
5.3.3.0 Triggers for tracking area update.........................................................................................................139
5.3.3.0A Provision of UE's TAI to MME in ECM-CONNECTED state............................................................140
5.3.3.1 Tracking Area Update procedure with Serving GW change................................................................141
5.3.3.1A Tracking Area Update procedure with Serving GW change and data forwarding..............................150
5.3.3.2 E-UTRAN Tracking Area Update without S-GW Change..................................................................152
5.3.3.3 Routing Area Update with MME interaction and without S-GW change...........................................161
5.3.3.4 Void......................................................................................................................................................168
5.3.3.5 Void......................................................................................................................................................168
5.3.3.6 Routing Area Update with MME interaction and with S-GW change................................................168
5.3.4 Service Request procedures.......................................................................................................................175
5.3.4.1 UE triggered Service Request..............................................................................................................175
5.3.4.2 Handling of abnormal conditions in UE triggered Service Request....................................................178
5.3.4.3 Network Triggered Service Request....................................................................................................179
5.3.4A Connection Suspend procedure..................................................................................................................184
5.3.4B Data Transport in Control Plane CIoT EPS Optimisation.........................................................................185
5.3.4B.1 General.................................................................................................................................................185
5.3.4B.2 Mobile Originated Data Transport in Control Plane CIoT EPS Optimisation with P-GW connectivity
..............................................................................................................................................................186
5.3.4B.3 Mobile Terminated Data Transport in Control Plane CIoT EPS Optimisation with P-GW connectivity
..............................................................................................................................................................190
5.3.4B.4 Establishment of S1-U bearer during Data Transport in Control Plane CIoT EPS Optimisation........196
5.3.4B.5 eNB Control Plane Relocation Indication procedure...........................................................................197
5.3.5 S1 release procedure..................................................................................................................................198
5.3.5A Connection Resume procedure..................................................................................................................200
5.3.6 Void............................................................................................................................................................202
5.3.6A PDN GW Pause of Charging procedure....................................................................................................202
5.3.7 GUTI Reallocation procedure....................................................................................................................204
5.3.8 Detach procedure.......................................................................................................................................204
5.3.8.1 General.................................................................................................................................................204
5.3.8.2 UE-initiated Detach procedure.............................................................................................................205
5.3.8.2.1 UE-initiated Detach procedure for E-UTRAN...............................................................................205
5.3.8.2.2 UE-initiated Detach procedure for GERAN/UTRAN with ISR activated.....................................206
5.3.8.3 MME-initiated Detach procedure.........................................................................................................208
5.3.8.3A SGSN-initiated Detach procedure with ISR activated.........................................................................210
5.3.8.4 HSS-initiated Detach procedure...........................................................................................................211
5.3.9 HSS User Profile management function procedure...................................................................................213
5.3.9.1 General.................................................................................................................................................213
5.3.9.2 Insert Subscriber Data procedure.........................................................................................................213
5.3.9.3 Purge function......................................................................................................................................214
5.3.10 Security Function.......................................................................................................................................215
5.3.10.1 General.................................................................................................................................................215
5.3.10.2 Authentication and Key Agreement.....................................................................................................215
5.3.10.3 User Identity Confidentiality................................................................................................................215
5.3.10.4 User Data and Signalling Confidentiality............................................................................................215
5.3.10.4.1 AS security mode command procedure..........................................................................................215
5.3.10.4.2 NAS Security Mode Command procedure.....................................................................................215
5.3.10.5 ME identity check procedure...............................................................................................................216
5.3.11 UE Reachability procedures.......................................................................................................................217
5.3.11.1 General.................................................................................................................................................217
5.3.11.2 UE Reachability Notification Request procedure................................................................................217
5.3.11.3 UE Activity Notification procedure.....................................................................................................217
5.3.12 Update CSG Location Procedure...............................................................................................................218
5.3.13 CSS subscription data management function procedure............................................................................218
5.3.13.1 General.................................................................................................................................................218
3GPP
Release 15 8 3GPP TS 23.401 V15.10.0 (2019-12)
5.3.13.2 Insert CSG Subscriber Data procedure................................................................................................218

5.3.14 UE Radio Capability Match Request.........................................................................................................219
5.4 Session Management, QoS and interaction with PCC functionality...............................................................220
5.4.1 Dedicated bearer activation........................................................................................................................220
5.4.2 Bearer modification with bearer QoS update.............................................................................................222
5.4.2.1 PDN GW initiated bearer modification with bearer QoS update...............................................................222
5.4.2.2 HSS Initiated Subscribed QoS Modification.......................................................................................225
5.4.3 PDN GW initiated bearer modification without bearer QoS update.........................................................226
5.4.4 Bearer deactivation....................................................................................................................................228
5.4.4.1 PDN GW initiated bearer deactivation.................................................................................................228
5.4.4.2 MME Initiated Dedicated Bearer Deactivation....................................................................................232
5.4.5 UE requested bearer resource modification...............................................................................................233
5.4.6 Void............................................................................................................................................................236
5.4.7 E-UTRAN initiated E-RAB modification procedure.................................................................................236
5.4.8 E-UTRAN initiated UE Context Modification procedure.........................................................................238
5.5 Handover.........................................................................................................................................................239
5.5.1 Intra-E-UTRAN handover.........................................................................................................................239
5.5.1.1 X2-based handover...............................................................................................................................239
5.5.1.1.1 General............................................................................................................................................239
5.5.1.1.2 X2-based handover without Serving GW relocation......................................................................240
5.5.1.1.3 X2-based handover with Serving GW relocation...........................................................................242
5.5.1.2 S1-based handover...............................................................................................................................245
5.5.1.2.1 General............................................................................................................................................245
5.5.1.2.2 S1-based handover, normal............................................................................................................246
5.5.1.2.3 S1-based handover, Reject.............................................................................................................252
5.5.1.2.4 S1-based handover, Cancel.............................................................................................................253
5.5.2 Inter RAT handover...................................................................................................................................253
5.5.2.0 General.................................................................................................................................................253
5.5.2.1 E-UTRAN to UTRAN Iu mode Inter RAT handover..........................................................................254
5.5.2.1.1 General............................................................................................................................................254
5.5.2.1.2 Preparation phase............................................................................................................................255
5.5.2.1.3 Execution phase..............................................................................................................................258
5.5.2.1.4 E-UTRAN to UTRAN Iu mode Inter RAT handover Reject.........................................................261
5.5.2.2 UTRAN Iu mode to E-UTRAN Inter RAT handover..........................................................................262
5.5.2.2.1 General............................................................................................................................................262
5.5.2.2.3 Execution phase..............................................................................................................................266
5.5.2.2.4 UTRAN Iu mode to E-UTRAN Inter RAT handover reject..........................................................269
5.5.2.3 E-UTRAN to GERAN A/Gb mode Inter RAT handover....................................................................269
5.5.2.3.1 General............................................................................................................................................269
5.5.2.3.3 Execution phase..............................................................................................................................274
5.5.2.3.4 E-UTRAN to GERAN A/Gb mode Inter RAT handover reject.....................................................277
5.5.2.4 GERAN A/Gb mode to E-UTRAN Inter RAT handover....................................................................278
5.5.2.4.1 General............................................................................................................................................278
5.5.2.4.3 Execution phase..............................................................................................................................282
5.5.2.4.4 GERAN A/Gb mode to E-UTRAN Inter RAT handover reject.....................................................285
5.5.2.5 Inter RAT handover Cancel.................................................................................................................285
5.5.2.5.1 General............................................................................................................................................285
5.5.2.5.2 Source RAN to Target RAN Inter RAT handover Cancel.............................................................286
5.6 Network Assisted Cell Change........................................................................................................................287
5.6.1 Architecture Principles for E-UTRAN to GERAN NACC.......................................................................287
5.6.2 Void............................................................................................................................................................288
5.7 Information storage..........................................................................................................................................288
5.7.1 HSS............................................................................................................................................................289
5.7.2 MME..........................................................................................................................................................292
5.7.3 Serving GW...............................................................................................................................................296
5.7.4 PDN GW....................................................................................................................................................298
5.7.5 UE..............................................................................................................................................................300
5.7.6 Handling of Wild Card APN......................................................................................................................301
3GPP
Release 15 9 3GPP TS 23.401 V15.10.0 (2019-12)
5.7.7 CSS............................................................................................................................................................302
5.7A Charging..........................................................................................................................................................302
5.7A.1 General.......................................................................................................................................................302
5.7A.2 Usage Data Reporting for Secondary RAT................................................................................................303
5.7A.3 Secondary RAT Usage Data Reporting Procedure....................................................................................303
5.7A.4 Secondary RAT Periodic Usage Data Reporting Procedure......................................................................305
5.8 MBMS.............................................................................................................................................................305
5.9 Interactions with other services.......................................................................................................................305
5.9.1 Location Reporting Procedure...................................................................................................................305
5.9.2 Location Change Reporting Procedure......................................................................................................306
5.9.2.1 General.................................................................................................................................................306
5.9.2.2 Reporting at Presence Reporting Area entering and leaving...............................................................308
5.9.3 IMSI and APN information retrieval procedure........................................................................................309
5.10 Multiple-PDN support and PDN activation for UEs supporting "Attach without PDN connectivity"...........310
5.10.1 General.......................................................................................................................................................310
5.10.2 UE requested PDN connectivity................................................................................................................311
5.10.3 UE or MME requested PDN disconnection...............................................................................................319
5.10.4 MME triggered Serving GW relocation.....................................................................................................321
5.11 UE Capability Handling..................................................................................................................................323
5.11.1 General.......................................................................................................................................................323
5.11.2 UE Radio Capability Handling..................................................................................................................323
5.11.3 UE Core Network Capability.....................................................................................................................325
5.11.4 UE Radio Capability for Paging Information............................................................................................326
5.11.5 UE Radio Capability for Category M Differentiation...............................................................................326
5.12 Warning message delivery...............................................................................................................................327
5.12.1 General.......................................................................................................................................................327
5.12.2 Void............................................................................................................................................................327
5.12.3 Void............................................................................................................................................................327
5.13 Discontinuous Reception and UE Specific DRX Parameter handling............................................................327
5.13a Extended Idle mode Discontinuous Reception (DRX)....................................................................................328
5.14 Configuration Transfer procedure...................................................................................................................329
5.14.1 Architecture Principles for Configuration Transfer...................................................................................329
5.14.2 Addressing, routing and relaying...............................................................................................................330
5.14.2.1 Addressing............................................................................................................................................330
5.14.2.2 Routing.................................................................................................................................................331
5.14.2.3 Relaying...............................................................................................................................................331
5.14.2.4 Applications using the Configuration Transfer procedures.................................................................331
5.15 RAN Information Management (RIM) procedures.........................................................................................331
5.15.1 General.......................................................................................................................................................331
5.15.2 Addressing, routing and relaying...............................................................................................................331
5.15.2.1 Addressing............................................................................................................................................331
5.15.2.2 Routing.................................................................................................................................................332
5.15.2.3 Relaying...............................................................................................................................................332
5.15.3 Applications using the RIM Procedures....................................................................................................332
5.16 MME-initiated procedure on UE's CSG membership change.........................................................................332
5.17 Home eNodeB Multicast Packet Forwarding Function...................................................................................332
5.18 HPLMN Notification with specific indication due to MME initiated Bearer removal...................................333
5.19 Procedures to support Dedicated Core Networks............................................................................................333
5.19.1 NAS Message Redirection Procedure........................................................................................................333
5.19.2 Attach, TAU and RAU procedure for Dedicated Core Network...............................................................334
5.19.2a Impacts to Handover Procedures...............................................................................................................337
5.19.3 MME/SGSN or HSS initiated Dedicated Core Network Reselection.......................................................338
3GPP
Release 15 10 3GPP TS 23.401 V15.10.0 (2019-12)
Annex A (informative): Void.....................................................................................................................340
Annex B (informative): Void......................................................................................................................341
Annex C (informative): Void.....................................................................................................................342
Annex D (normative): Interoperation with Gn/Gp SGSNs.....................................................................343
D.1 General Considerations.......................................................................................................................343

D.2 Interoperation Scenario.......................................................................................................................343
D.2.1 Roaming interoperation scenario.....................................................................................................................343
D.2.2 Non-roaming interoperation scenario..............................................................................................................344
D.3 Interoperation procedures...................................................................................................................344
D.3.1 General.............................................................................................................................................................344
D.3.2 Void.................................................................................................................................................................345
D.3.3 MME to 3G SGSN combined hard handover and SRNS relocation procedure..............................................345
D.3.4 3G SGSN to MME combined hard handover and SRNS relocation procedure..............................................350
D.3.5 Routing Area Update.......................................................................................................................................356
D.3.6 Gn/Gp SGSN to MME Tracking Area Update................................................................................................362
D.3.7 E-UTRAN to GERAN A/Gb mode Inter RAT handover................................................................................369
D.3.7.1 General.......................................................................................................................................................369
D.3.7.2 Preparation phase.......................................................................................................................................370
D.3.7.3 Execution phase.........................................................................................................................................373
D.3.8 GERAN A/Gb mode to E-UTRAN Inter RAT handover................................................................................375
D.3.8.1 General.......................................................................................................................................................375
D.3.8.2 Preparation phase.......................................................................................................................................376
D.3.8.3 Execution phase.........................................................................................................................................378
Annex E (normative): Mapping between EPS and Release 99 QoS parameters....................................381
3GPP
Release 15 11 3GPP TS 23.401 V15.10.0 (2019-12)
Annex F (normative): Dedicated bearer activation in combination with the default bearer activation at
Attach and UE requested PDN connectivity procedures.........................384
Annex G (informative): Void.....................................................................................................................387
Annex H (normative): Mapping between temporary and area identities...............................................388
Annex I (informative): Guidance for contributors to this specification.................................................389
Annex J (informative): High Level ISR description.................................................................................390
J.1 General description of the ISR concept..............................................................................................390

J.2 Usage of the TIN................................................................................................................................391
J.3 ISR activation.....................................................................................................................................391
J.4 Downlink data transfer.......................................................................................................................392
J.5 ISR deactivation.................................................................................................................................393
J.6 Handling of special situations.............................................................................................................393
Annex K (informative): Isolated E-UTRAN Operation for Public Safety..............................................395
K.1 General description of the IOPS concept............................................................................................395

K.2 Operation of isolated public safety networks using a Local EPC........................................................395
K.2.1 General Description.........................................................................................................................................395
K.2.2 UE configuration.............................................................................................................................................395
K.2.3 IOPS network configuration............................................................................................................................396
K.2.4 IOPS network establishment/termination........................................................................................................396
K.2.5 UE mobility.....................................................................................................................................................399
Annex L (informative): Optimised EPS Architecture option for CIoT..................................................401
L.1 Introduction........................................................................................................................................401
L.2 Non-Roaming Architecture.................................................................................................................401
L.3 Roaming architecture..........................................................................................................................402
L.4 C-SGN................................................................................................................................................402
Annex M (informative): Functions and procedures over NB-IoT RAT.................................................403
Annex N (informative): Change history....................................................................................................407
3GPP
Release 15 12 3GPP TS 23.401 V15.10.0 (2019-12)
Foreword
This Technical Specification has been produced by the 3rd 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.
3GPP
Release 15 13 3GPP TS 23.401 V15.10.0 (2019-12)
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.
An Evolved Packet System architecture optimised for the support of Cellular IoT (Internet of Things) applications is
also defined in this document.
The Evolved Packet System also provides support for the E-UTRAN to control a Dual Connectivity radio connection
that uses a combination of E-UTRA and another radio access technology (e.g. NR). TS 36.300 [5] contains the overall
description for Dual Connectivity.
Enhancements to support interworking of EPS with 5GS are captured in TS 23.501 [83] and TS 23.502 [84].
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 Network (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".
3GPP
Release 15 14 3GPP TS 23.401 V15.10.0 (2019-12)
[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".
[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 4960: "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".
3GPP
Release 15 15 3GPP TS 23.401 V15.10.0 (2019-12)
[38] 3GPP TS 29.061: "Interworking between the Public Land Mobile Network (PLMN) supporting
packet based services and Packet Data Networks (PDN)".
[39] Void.
[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)".
[43] 3GPP TS 29.274: "3GPP Evolved Packet System (EPS); Evolved General Packet Radio Service
(GPRS) Tunnelling Protocol for Control plane (GTPv2-C); Stage 3".
[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.261: "IP flow mobility and seamless Wireless Local Area Network (WLAN) offload;
Stage 2".
[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".
[58] 3GPP TS 23.272: "Circuit Switched (CS) fallback in Evolved Packet System (EPS); Stage 2".
[59] 3GPP TS 23.107: "Quality of Service (QoS) concept and architecture".
[60] 3GPP TS 23.292: "IP Multimedia Subsystem (IMS) centralized services; Stage 2".
[61] 3GPP TS 29.303: "Domain Name System Procedures; Stage 3".
[62] IETF RFC 3376: "Internet Group Management Protocol, Version 3".
[63] IETF RFC 3810: "Multicast Listener Discovery Version 2 (MLDv2) for IPv6".
[64] IETF RFC 3927: "Dynamic Configuration of IPv4 Link-Local Addresses".
[65] IETF RFC 4291: "IP Version 6 Addressing Architecture".
[66] 3GPP TS 22.368: "Service Requirements for Machine-Type Communications (MTC); Stage 1".
[67] 3GPP TS 22.011: "Service Accessibility".
3GPP
Release 15 16 3GPP TS 23.401 V15.10.0 (2019-12)
[68] 3GPP TS 22.153: "Multimedia priority service".
[69] 3GPP TS 24.368: "Non-Access Stratum (NAS) configuration Management Object (MO)".
[70] IETF RFC 6603: "Prefix Exclude Option for DHCPv6-based Prefix Delegation".
[71] 3GPP TS 23.002: "Network Architecture".
[72] 3GPP TS 23.007: "Restoration procedures".
[73] 3GPP TS 22.173: "IP Multimedia Core Network Subsystem (IMS) Multimedia Telephony Service
and supplementary services; Stage 1".
[74] 3GPP TS 23.682: "Architecture enhancements to facilitate communications with packet data

networks and applications".
[75] 3GPP TS 23.380: "IMS Restoration Procedures".
[76] 3GPP TS 36.423: "Evolved Universal Terrestrial Radio Access Network (E-UTRAN); X2

Application Protocol (X2AP)".
[77] IETF RFC 5795: "The RObust Header Compression (ROHC) Framework".
[78] 3GPP TS 36.323: "Evolved Universal Terrestrial Radio Access (E-UTRA); Packet Data
Convergence Protocol (PDCP) specification".
[79] 3GPP TS 29.128: " Mobility Management Entity (MME) and Serving GPRS Support Node
(SGSN) interfaces for interworking with packet data networks and applications".
[80] 3GPP TS 22.101: "3rd Generation Partnership Project; Technical Specification Group Services
and Systems Aspects; Service aspects; Service principles".
[81] 3GPP TS 23.167: "3rd Generation Partnership Project; Technical Specification Group Services
and Systems Aspects; IP Multimedia Subsystem (IMS) emergency sessions".
[82] 3GPP TS 36.306: "Evolved Universal Terrestrial Radio Access (E-UTRA); User Equipment (UE)
radio access capabilities".
[83] 3GPP TS 23.501: "System Architecture for the 5G System; Stage 2".
[84] 3GPP TS 23.502: "Procedures for the 5G System; Stage 2".
[85] 3GPP TS 37.340: "Evolved Universal Terrestrial Radio Access (E-UTRA) and NR; Multi-
connectivity; Stage 2".
[86] 3GPP TS 29.002: "Mobile Application Part (MAP) specification".
[87] 3GPP TS 36.321: "Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access
Control (MAC) protocol specification".
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.
3GPP
Release 15 17 3GPP TS 23.401 V15.10.0 (2019-12)
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 PDN represented by an APN and a UE, represented by one IPv4 address
and/or one IPv6 prefix (for IP PDN Type) or by the UE Identity (for Non-IP PDN Type).
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.
eCall Only Mode: A UE configuration option that allows the UE to attach at EPS and register in IMS to perform only
eCall Over IMS, and an IMS call to a non-emergency MSISDN or URI for test and/or terminal reconfiguration services.
For a short period following either such call, an incoming call (e.g. callback from a PSAP or HPLMN operator) or other
incoming session (e.g. for USIM reconfiguration) is possible. At other times when the UE is configured in this mode,
the UE is required to refrain from any signaling to a network. Use of eCall Only Mode is configured in the USIM for
the UE.
en-gNB: As defined in TS 37.340 [85].
PDN Connection to the SCEF: The association between a UE, represented by the UE Identity, and a PDN represented
by an APN to external packet data network via SCEF to allow transfer of Non-IP data. It includes establishment and
persistence of T6 connection between MME and SCEF (see TS 29.128 [79]).
Emergency attached UE: A UE which only has bearer(s) related to emergency bearer service.
NOTE 1: The above term is equivalent to the term "attached for emergency bearer services" as specified in
TS 24.301 [46].
LIPA PDN connection: a PDN Connection for local IP access for a UE connected to a HeNB.
SIPTO at local network PDN connection: a PDN connection for SIPTO at local network for a UE connected to a
(H)eNB.
Correlation ID: For a LIPA PDN connection, Correlation ID is a parameter that enables direct user plane path between
the HeNB and L-GW.
SIPTO Correlation ID: For a SIPTO at local network PDN connection, SIPTO Correlation ID is a parameter that
enables direct user plane path between the (H)eNB and L-GW when they are collocated.
Local Home Network: A set of (H)eNBs and L-GWs in the standalone GW architecture, where the (H)eNBs have IP
connectivity for SIPTO at the Local Network via all the L-GWs.
Local Home Network ID: An identifier that uniquely identifies a Local Home Network within a PLMN.
Presence Reporting Area: An area defined within 3GPP Packet Domain for the purposes of reporting of UE presence
within that area due to policy control and/or charging reasons. In case of E-UTRAN, a Presence Reporting Area may
consist in a set of neighbor or non-neighbor Tracking Areas, or eNBs and/or cells. There are two types of Presence
Reporting Areas: "UE-dedicated Presence Reporting Areas" and "Core Network pre-configured Presence Reporting
Areas" that apply to an MME pool.
RAN user plane congestion: RAN user plane congestion occurs when the demand for RAN resources exceeds the
available RAN capacity to deliver the user data for a prolonged period of time.
NOTE 2: Short-duration traffic bursts is a normal condition at any traffic load level, and is not considered to be
RAN user plane congestion. Likewise, a high-level of utilization of RAN resources (based on operator
configuration) is considered a normal mode of operation and might not be RAN user plane congestion.
IOPS-capable eNB: an eNB that has the capability of IOPS mode operation, which provides local IP connectivity and
public safety services to IOPS-enabled UEs via a Local EPC when the eNB has lost backhaul to the Macro EPC or it
has no backhaul to the Macro EPC.
IOPS network: an IOPS network consists of one or more eNBs operating in IOPS mode and connected to a Local EPC.
3GPP
Release 15 18 3GPP TS 23.401 V15.10.0 (2019-12)
Local EPC: a Local EPC is an entity which provides functionality that eNBs in IOPS mode of operation use, instead of
the Macro EPC, in order to support public safety services.
Macro EPC: the EPC which serves an eNB when it is not in IOPS mode of operation.
Nomadic EPS: a deployable system which has the capability to provide radio access (via deployable IOPS-capable
eNB(s)), local IP connectivity and public safety services to IOPS-enabled UEs in the absence of normal EPS
IOPS-enabled UE: is an UE that is configured to use networks operating in IOPS mode.
Cellular IoT: Cellular network supporting low complexity and low throughput devices for a network of Things.
Cellular IoT supports both IP and Non-IP traffic.
Narrowband-IoT: a 3GPP Radio Access Technology that forms part of Cellular IoT. It allows access to network
services via E-UTRA with a channel bandwidth limited to 180 kHz (corresponding to one PRB). Unless otherwise
indicated in a clause, Narrowband-IoT is a subset of E-UTRAN.
LTE-M: a 3GPP RAT type Identifier used in the Core Network only, which is a sub-type E-UTRAN RAT type, and
defined to identify in the Core Network the E-UTRAN when used by a UE indicating Category M in its UE radio
capability.
WB-E-UTRAN: in the RAN, WB-E-UTRAN is the part of E-UTRAN that excludes NB-IoT. In the Core Network, the
WB-E-UTRAN also excludes LTE-M.
DCN-ID: DCN identity identifies a specific dedicated core network (DCN).
For the purposes of the present document, the following terms and definitions given in TS 23.167 [81] apply:
eCall Over IMS: See TS 23.167 [81].
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].
5GS 5G System
AF Application Function
ARP Allocation and Retention Priority
AMBR Aggregate Maximum Bit Rate
CBC Cell Broadcast Centre
CBE Cell Broadcast Entity
CIoT Cellular IoT
CSG Closed Subscriber Group
CSG ID Closed Subscriber Group Identity
C-SGN CIoT Serving Gateway Node
CSS CSG Subscriber Server
DCN Dedicated Core Network
DeNB Donor eNode B
DL TFT DownLink Traffic Flow Template
DRX Discontinuous Reception
ECGI E-UTRAN Cell Global Identifier
ECM EPS Connection Management
ECN Explicit Congestion Notification
EMM EPS Mobility Management
eNB evolved Node B
EPC Evolved Packet Core
EPS Evolved Packet System
E-RAB E-UTRAN Radio Access Bearer
E-UTRAN Evolved Universal Terrestrial Radio Access Network
GBR Guaranteed Bit Rate
GUMMEI Globally Unique MME Identifier
GUTI Globally Unique Temporary Identity
3GPP
Release 15 19 3GPP TS 23.401 V15.10.0 (2019-12)
GW Gateway
HeNB Home eNode B
HeNB GW Home eNode B Gateway
HFN Hyper Frame Number
IOPS Isolated E-UTRAN Operation for Public Safety
IoT Internet of Things
ISR Idle mode Signalling Reduction
LAA Licensed Assisted Access
LBI Linked EPS Bearer Id
L-GW Local GateWay
LIPA Local IP Access
LWA LTE/WLAN Aggregation
LWIP LTE/WLAN Radio Level Integration with IPsec Tunnel
MBR Maximum Bit Rate
MME Mobility Management Entity
MMEC MME Code
MTC Machine-Type Communications
M-TMSI M-Temporary Mobile Subscriber Identity
NB-IoT Narrowband IoT
NR New Radio
OCS Online Charging System
OFCS Offline Charging System
OMC-ID Operation and Maintenance Centre Identity
P-GW PDN Gateway
PCC Policy and Charging Control
PCRF Policy and Charging Rules Function
PRA Presence Reporting Area
PDCP Packet Data Convergence Protocol
PMIP Proxy Mobile IP
PSAP Public Safety Answering Point
PSM Power Saving Mode
PTI Procedure Transaction Id
QCI QoS Class Identifier
RCAF RAN Congestion Awareness Function
RFSP RAT/Frequency Selection Priority
RN Relay Node
RUCI RAN User Plane Congestion Information
S-GW Serving Gateway
S-TMSI S-Temporary Mobile Subscriber Identity
SDF Service Data Flow
SIPTO Selected IP Traffic Offload
TAC Tracking Area Code
TAD Traffic Aggregate Description
TAI Tracking Area Identity
TAU Tracking Area Update
TI Transaction Identifier
TIN Temporary Identity used in Next update
URRP-MME UE Reachability Request Parameter for MME
UL TFT UpLink Traffic Flow Template
ULR-Flags Update Location Request Flags
3GPP
Release 15 20 3GPP TS 23.401 V15.10.0 (2019-12)
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.
CIoT EPS Optimisations provide improved support of small data transfer, described in clause 4.11.
4.2 Architecture reference model

4.2.1 Non-roaming architecture
UTRAN
SGSN
GERAN HSS
S3
S1-MME S6a
MME
PCRF
S12 Rx
S11 Gx
S4
LTE-Uu S10
Serving S5 PDN SGi Operator's IP
UE E-UTRAN Gateway Gateway Services
S1-U (e.g. IMS, PSS etc.)
Figure 4.2.1-1: Non-roaming architecture for 3GPP accesses
UTRAN
SGSN
GERAN HSS
S3
S1-MME S6a
MME
PCRF
S12 Rx
S11 Gx
S4
LTE-Uu S10
Serving PDN SGi Operator's IP
S1-U (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].
3GPP
Release 15 21 3GPP TS 23.401 V15.10.0 (2019-12)
4.2.2 Roaming architecture
HSS PCRF
Gx Rx
S6a
PDN SGi Operator’s IP
Gateway Services
(e.g. IMS, PSS etc.)
HPLMN
VPLMN
UTRAN S8
SGSN
GERAN
S12
S3
S1-MME S4
MME
S11
S10
“ LTE - Uu ” Serving
Gateway
UE E-UTRAN
S1-U
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.
3GPP
Release 15 22 3GPP TS 23.401 V15.10.0 (2019-12)
HSS
H-PCRF
Rx
S6a
Home
Operator’s IP
S9 Services
HPLMN
VPLMN
UTRAN
SGSN
GERAN
S3
S4
V-PCRF
S1-MME S12
MME
Gx
S11
S10
S5
"LTE-Uu"
Serving PDN SGi
E-UTRAN Gateway Visited Operator
UE Gateway PDN
S1- U
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.
3GPP
Release 15 23 3GPP TS 23.401 V15.10.0 (2019-12)
HSS
H-PCRF
S6a
S9
HPLMN
VPLMN UTRAN
SGSN
GERAN
S3 V-PCRF
S4
S1-MME
S12
MME Rx
Gx
S11
S10
LTE-Uu
S5 SGi Visited
Serving PDN Operator's IP
S1-U
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. S1-U does not apply to the Control Plane CIoT EPS
Optimisation.
S3: It enables user and bearer information exchange for inter 3GPP access network mobility in idle and/or
active state. This reference point can be used intra-PLMN or inter-PLMN (e.g. in the case of Inter-PLMN
HO).
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 non-
collocated PDN GW for the required PDN connectivity.
S6a: It enables transfer of subscription and authentication data for authenticating/authorizing user access to the
evolved system (AAA interface) between MME and HSS.
Gx: 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. This
reference point can be used intra-PLMN or inter-PLMN (e.g. in the case of Inter-PLMN HO).
3GPP
Release 15 24 3GPP TS 23.401 V15.10.0 (2019-12)
S11: Reference point providing control plane between MME and Serving GW. In addition, in order to support
Control Plane CIoT EPS Optimisation, the S11-U reference point provides user plane between MME and
Serving GW.
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].
NOTE 1: Except where stated otherwise, this specification does not make an explicit assumption as to whether an
interface is intra-PLMN or inter-PLMN.
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.
These user plane forwarding routes can cross inter-PLMN boundaries (e.g. in the case of Inter-PLMN HO).
Protocol assumption:
- The S1-U is based on GTP-U protocol;
- The S3 is based on GTP protocol;
- The S4 and S11 are 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 2: Redundancy support on reference points S5 and S8 should be taken into account.
4.2.4 Warning System architecture

Refer to TS 23.041 [48] and TS 23.002 [71] for the Warning System architecture.
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 Routing and Transfer Functions.
- Mobility Management Functions.
- Security Functions.
- Radio Resource Management Functions.
- Network Management Functions.
3GPP
Release 15 25 3GPP TS 23.401 V15.10.0 (2019-12)
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 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.2a Support for Dual Connectivity

Dual Connectivity involves two RAN nodes, i.e. Master and Secondary RAN nodes (see TS 36.300 [5] for the
definitions), in providing radio resources to a given UE (with active radio bearers), while a single S1-MME termination
point exists for an UE between a MME and the E-UTRAN. The E-UTRAN architecture and related functions to support
Dual Connectivity with E-UTRAN is further described in TS 36.300 [5]. Dual Connectivity with E-UTRAN as Master
RAN node and NR as Secondary RAN node is further described in TS 37.340 [85].
Dual connectivity defines "Master Cell Group (MCG) bearer" and "Secondary Cell Group (SCG) bearer" alternatives
(see TS 36.300 [5]). For E-RABs configured as "MCG bearers" the U-plane termination points are maintained, whereas
for E-RABs configured as "SCG bearers" it enables changing the U-plane termination point in the E-UTRAN by means
of S1-MME signalling without changing the S1-MME termination point.
Dual Connectivity also defines a "split bearer" alternative TS 36.300 [5]. The "split bearer" in the E-UTRAN is
transparent to the core network entities (e.g. MME, S-GW etc.) with the exception of the CSG membership verification
by the MME when the Secondary eNB is a hybrid access eNB.
The E-UTRAN uses the per-UE information supplied by the MME and local E-UTRAN configuration data to determine
whether or not to use Dual Connectivity for that UE, and, on a per EPS bearer basis the E-UTRAN decides whether to
use an MCG bearer or SCG bearer, and, whether or not that bearer is a "split bearer".
3GPP
Release 15 26 3GPP TS 23.401 V15.10.0 (2019-12)
NOTE 1: Typically, the MME and SGW cannot determine whether the RAN termination point(s) for the S1-U
interface are located on a Master RAN node that has multiple IP addresses, or, on a Secondary RAN
node.
If the MME has an Access Restriction for NR for a UE (either signalled from the HSS, or, locally generated by VPLMN
policy in the MME) then the MME shall signal this to the E-UTRAN as part of Handover Restriction List and to the UE
in Attach and TAU Accept as defined in clauses 5.3.2.1, 5.5.2.2.3, 5.5.2.4.3 and D.3.6 respectively.
An eNB supporting Dual Connectivity with NR checks whether the UE is allowed to use NR. If the UE is not allowed
to use NR, the eNB shall not establish Dual Connectivity with NR as a secondary RAT.
The MME uses "UE support for dual connectivity with NR" for SGW and PGW selection when the UE indicates
support for NR and there is no Access Restriction for NR for the UE.
An E-UTRAN cell, based on operator configuration, broadcasts whether it is capable of supporting dual connectivity
with locally available NR secondary cell(s).
At inter-RAT handover from GERAN/UTRAN, the Access Restriction for NR is either already in the MME's UE
context, or, is obtained from the HSS during the subsequent Tracking Area Update procedure (i.e. not from the source
SGSN or source RAN). In both inter-RAT handover cases, any NR Access Restriction is then signalled to the E-
UTRAN.
NOTE 2: This signalling of the Access Restriction during the TAU after the inter-RAT handover procedure means
that there is a small risk that NR resources are transiently allocated.
The eNB, at which the S1-MME terminates, performs all necessary S1-MME related functions (as specified for any
serving eNB) such as mobility management, relaying of NAS signalling, E-RAB handling, etc. and manages the
handling of user plane connection of S1-U.
Additional functional characteristics are:
- User location information reporting is based on the identity of the cell that is serving the UE and supported by
the eNB terminating S1-MME.
- Path update signalling for E-RABs configured as "SCG bearers" and Serving GW relocation cannot occur at the
same time.
- During handover with dual connectivity, the requirement of forwarding "end marker" packets to target node is
also applicable to secondary RAN node if it is the source node for S1-U bearer.
- After handover with data forwarding, the E-UTRAN initiated E-RAB modification procedure of clause 5.4.7
should not be initiated by the target eNB before "end marker" packet is received at the target RAN node or a
timer in target eNB expires.
- Relaying function is not supported.
- CSG function may be supported in case the Secondary eNB is a hybrid access eNB (see more details in
clause 5.4.7 and in TS 36.300 [5]).
NOTE 3: A HeNB cannot be the Master eNB, i.e. a HeNB cannot initiate the Secondary eNB Addition procedure.
NOTE 4: A HeNB is not allowed to be the Secondary eNB if the HeNB is a closed access eNB.
- When the Secondary eNB is a hybrid access eNB, the Master eNodeB may ask CSG membership verification to
the MME using E-RAB Modification Indication message (for SCG bearers) or UE Context Modification
Indication (for split bearers) message. The MME shall determine the CSG membership based on the CSG
Membership Information as specified in TS 36.300 [5] and shall respond to the Master eNodeB using
respectively a E-RAB Modification Confirm or a UE Context Modification Confirm, but shall not update the
User CSG Information in the Core Network.
- The LIPA function may be supported for the SCG bearer alternative, in the case that the Secondary eNB is a
HeNB with a collocated L-GW (see more details in TS 36.300 [5]).
- "SIPTO at the Local Network with L-GW function collocated with the (H)eNB" function may be supported (see
more details in TS 36.300 [5]):
3GPP
Release 15 27 3GPP TS 23.401 V15.10.0 (2019-12)
- For the MCG and split bearer alternatives, in case the Master eNB is collocated with a L-GW; and/or
- For the SCG bearer alternative, in case the Secondary eNB is a (H)eNB with a collocated L-GW.
NOTE 5: LIPA or SIPTO at the Local Network PDN connection can be established if the SeNB has already been
added before the UE requests establishment of the LIPA or SIPTO at the Local Network PDN connection.
NOTE 6: LIPA or SIPTO at the Local Network PDN connection can be established if the UE is in the coverage of
the candidate SeNB when the UE requests establishment of the LIPA or SIPTO at the Local Network
PDN connection, but the SeNB has not yet been added. In this case, there is a time gap between the
moment when the PDN connection establishment is completed and the moment when the SeNB Addition
procedure is completed.
- "SIPTO at the Local Network with stand-alone GW" function may be supported for the MCG, SCG, and split
bearer alternatives if the Master and Secondary eNBs belong to the same LHN (see more detail in
TS 36.300 [5]).
4.3.3 Packet routing 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. Routing 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 routing and transport mechanisms of the underlying IP network.
The Maximum Transfer Unit (MTU) size considerations in clause 9.3 of TS 23.060 [7] are also applicable to EPS.
4.3.3.2 IP header compression function

The IP header compression function optimises use of radio capacity by IP header compression mechanisms.
When Control Plane CIoT EPS Optimisation is supported for PDN connections of IP PDN Type, if the IP header
compression based on ROHC framework IETF RFC 5795 [77] is implemented in the MME and the UE, the ROHC
profiles defined in TS 36.323 [78] may be supported.
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.3.4 IP Multicast Forwarding between a network accessed by LIPA and a UE

The Home eNodeB L-GW should support IP forwarding of packets to multicast groups between the UE and the
network accessed by LIPA.
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.
Intra-RAT mobility for NB-IoT UEs is supported.
3GPP
Release 15 28 3GPP TS 23.401 V15.10.0 (2019-12)
Inter-RAT idle mode mobility between NB-IoT and WB-EUTRAN/UTRAN/GERAN is supported. Tracking area list
management as defined in clause 4.3.5.3 is required to ensure that at inter-RAT mobility, the UE performs a TAU or
RAU procedure.
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. All cells of the
Tracking Areas in which a UE in ECM-IDLE is currently registered needs to be taken into account for paging. 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.
The MME may allocate long periodic TAU timer value to the UE according to clause 4.3.17.3.
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 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 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.
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. Whenever the UE enters ECM IDLE mode the timer is started with
a value similar to the UE's periodic TAU timer. If this timer expires in the MME, the MME can deduce that the UE is
not reachable. However, the MME does not know for how long the UE is not reachable, 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.
3GPP
Release 15 29 3GPP TS 23.401 V15.10.0 (2019-12)
If MME has allocated an Active Time to the UE, then the MME starts the Active timer with the value of Active Time
whenever the UE enters ECM IDLE mode. If this timer expires in the MME, the MME can deduce that the UE is not
reachable and should clear the PPF flag in the MME.
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 the 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".
If the MME is requested to monitor Reachability for Data and the UE enters ECM-CONNECTED, the MME sends a
Monitoring Report message to the address that was indicated in the related Monitoring Request as described in
TS 23.682 [74].
When the MME applies General NAS level Mobility Management Congestion Control to a UE, the MME may need to
adjust the mobile reachable timer and/or Implicit Detach timer (as clause 4.3.7.4.2.4).
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.
The "tracking area list concept" is used with E-UTRAN. With this concept, when the UE registers with the network, the
MME allocates a set (a "list") of tracking areas to the UE. By making the centre of this set of tracking areas close to the
UE's current location, the chance of a UE rapidly making another tracking area update can be reduced.
If SIPTO at local network with stand-alone GW, Serving GW relocation without mobility and ISR are supported in the
core network the Tracking Area list should only contain either Tracking Areas inside one local network or inside the
macro network. If the tracking area list covers both local network and macro network, the ISR shall not be activated if
the UE is allowed to use SIPTO at local network.
The MME determines the RAT type the UE is camping on, i.e. NB-IoT or WB-E-UTRAN, based on the Tracking Area
indicated in the INITIAL UE MESSAGE by the eNB.
To ensure a UE initiates tracking area updating procedure when perfoming inter-RAT mobility between NB-IoT and
WB-E-UTRAN, the E-UTRAN shall be configured such that a Tracking Area does not contain both WB-E-UTRAN
and NB-IoT cells, and, the MME shall not allocate a Tracking Area Identity list that contains both NB-IoT and WB-E-
UTRAN Tracking Areas.
To ensure the UE initiates tracking area update procedure when it moves to and from an MME that supports 15 EPS
bearers per UE as defined in clause 4.12 to an MME that does not support 15 EPS bearers per MME and vice versa, the
MME shall allocate a Tracking Area Identity list that provides homogenous support for 15 EPS bearers per UE.
Other features (e.g. User Plane CIoT EPS Optimisation, Supporting up to 15 EPS bearers per UE) may require the
MME to adapt how it creates the "list" of TAIs.
NOTE: This TAI list functionality is different to the SGSN behaviour in GERAN and UTRAN systems. In
GERAN/UTRAN the UE is only registered in one Routeing Area at a time.
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.
3GPP
Release 15 30 3GPP TS 23.401 V15.10.0 (2019-12)
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 cell-
reselection in idle mode (ECM-IDLE, PMM-IDLE, GPRS STANDBY states).
NOTE 1: 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.
The MME/SGSN activates ISR only if the Serving GW supports the ISR. How MME/SGSN determines a Serving GW
supports ISR is implementation dependent.
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.
Table 4.3.5.6-1: Setting of the TIN
Message received by UE Current TIN value stored by TIN value to be set by the
UE UE when receiving
message
Attach Accept via E-UTRAN Any value GUTI
(never indicates "ISR Activated")
Attach Accept via Any value P-TMSI
GERAN/UTRAN
(never indicates "ISR Activated")
TAU Accept Any value GUTI
not indicating "ISR Activated"
TAU Accept GUTI GUTI
indicating "ISR Activated" P-TMSI or RAT-related TMSI RAT-related TMSI
RAU Accept Any value P-TMSI
not indicating "ISR Activated"
RAU Accept P-TMSI P-TMSI
indicating "ISR Activated" GUTI or RAT-related 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 TIN value: P-TMSI TIN value: GUTI TIN value: RAT-related
UE 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 P-TMSI/RAI P-TMSI/RAI mapped from P-TMSI/RAI
GERAN/UTRAN GUTI
3GPP
Release 15 31 3GPP TS 23.401 V15.10.0 (2019-12)
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 by means other than PSHO, if any EPS bearer context or PDP context activated after the ISR was
activated in the UE exists;
- At the time when the UE moves from GERAN/UTRAN to E-UTRAN by means other than PSHO and CS to PS
SRVCC, if the PDP contexts were suspended in GERAN and not successfully resumed before returning to
E-UTRAN;
- 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);
- E-UTRAN selection from GERAN READY state;
- GERAN selection by an E-UTRAN-connected UE via Cell Change Order that is not for CS fallback;
- After a LAU procedure if the UE has CS fallback and/or SMS over SGs activated.
- For a UE that is IMS registered for voice, then after that UE moves from a Registration Area that supports IMS
voice over PS sessions (see 4.3.5.8 for more information) to one that does not, and vice versa. It shall be
possible, e.g. using Device Management or initial provisoning, to configure the UE to apply/not apply this
particular exception.
NOTE 2: A UE moving between Registration Areas that both support IMS voice over PS sessions, or, both that do
not support IMS voice over PS sessions, is unaffected by the above.
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;
- When the UE only has bearers related to emergency bearer service;
- TAU or RAU when UE moves over the border between local and macro network where SIPTO at local network
with stand-alone GW and Serving GW relocation without mobility are supported in the core network.
- TAU or RAU when the network confirms to use PSM for the UE.
If tracking area list or routing area covers both local network and macro network, the ISR shall not be activated if the
UE is allowed to use SIPTO at local network and Serving GW relocation without mobility are supported in the core
network.
3GPP
Release 15 32 3GPP TS 23.401 V15.10.0 (2019-12)
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. If roaming restriction to GERAN or UTRAN
access needs to be enforced, a MME that is connected to eNBs that may handover or invoke release with redirection to
UTRAN or GERAN is configured with a list of HPLMN IDs that are permitted to access GERAN or UTRAN unless
restricted by the UE individual access restriction information received from HSS.
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 Tracking 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 according to TS 22.173 [73] with a bearer that supports
Conversational Voice as specified in TS 23.203 [6]. A UE with "IMS voice over PS" voice capability should take this
indication into account when establishing voice over PS sessions (as specified in TS 23.221 [27]) as well as when
determining whether to deactivate the special handling of ISR locally (as detailed in clause 4.3.5.6).
The serving PLMN provides this indication based e.g. on local policy, HPLMN, Voice Support Match Indicator, the
SRVCC capability of the network and UE and/or extends of E-UTRAN/UTRAN coverage. The serving PLMN shall
indicate to the UE that the UE can expect a successful IMS voice over PS session only if the MME is configured to
know that the serving PLMN has a roaming agreement for IMS voice with the HPLMN of the UE. This indication is per
TAI list.
On request by the HSS, the MME shall indicate the following:
- whether or not an IMS voice over PS Session is supported in the TA(s) that are registered for the UE ("IMS
voice over PS Session Supported Indication"), together with the time of the last radio contact with the UE; and
- the current RAT type.
NOTE: In order to support routing of incoming IMS voice calls to the correct domain (PS or CS), the network-
based T-ADS (see TS 23.292 [60] and TS 23.221 [27]) requires that there is homogeneous support/non-
support of IMS voice over PS session for all registered TAs of the UE.
4.3.5.8A Homogenous Support of IMS Voice over PS Sessions Indication

The "Homogenous Support of IMS Voice over PS Sessions" indication is provided by the MME to the HSS, and can be
used by the HSS to avoid requesting the serving nodes whether or not an IMS Voice over PS session according to
TS 22.173 [73] with a bearer that supports Conversational Voice as specified in TS 23.203 [6] is supported. This
indication is stored in the MME MM context.
The MME shall behave as follows whenever it sends a Update Location Request or a Notify Request message to the
HSS:
- if "IMS Voice over PS Sessions" is supported homogeneously in all TAs in the serving MME for the UE, the
MME shall include the "Homogenous Support of IMS Voice over PS Sessions" indication set to "Supported".
- if none of the TAs of the serving MME supports "IMS Voice over PS Sessions" for the UE, the MME shall
include the "Homogenous Support of IMS Voice over PS Sessions" indication set to "Not supported".
- if "IMS Voice over PS Sessions" support is either non-homogeneous or unknown, the MME shall not include the
"Homogenous Support of IMS Voice over PS Sessions" indication.
Regarding homogenous support/non-support of IMS Voice over PS session for all registered TAs of the UE, see
clause 4.3.5.8.
3GPP
Release 15 33 3GPP TS 23.401 V15.10.0 (2019-12)
4.3.5.9 Voice domain preference and UE's usage setting

If the UE supports CS fallback, or the UE is configured to support IMS voice, or both, the UE shall include the
information element "Voice domain preference and UE's usage setting" in Attach Request, Tracking Area Update
Request and Routing Area Update Request messages. The purpose of this information element is to signal to the
network the UE's usage setting and voice domain preference for E-UTRAN. The UE's usage setting indicates whether
the UE behaves in a voice centric or data centric way (as defined in TS 23.221 [27]). The voice domain preference for
E-UTRAN indicates whether the UE is configured as CS Voice only, CS Voice preferred and IMS PS Voice as
secondary, IMS PS Voice preferred and CS Voice as secondary, or IMS PS Voice only (as defined in TS 23.221 [27]).
In this Release of the specifications, inter-RAT mobility to/from the NB-IoT RAT is not supported, and GBR bearers
are not supported in the NB-IoT RAT. Hence the UE should not include the "Voice domain preference and UE's usage
setting" IE when sending an Attach Request or Tracking Area Update Request on the NB-IoT RAT.
NOTE: Depending on operator's configuration, the UE's usage setting and voice domain preference for
E-UTRAN can be used by the network to choose the RFSP Index in use (see clause 4.3.6). As an
example, this enables the enforcement of selective idle mode camping over GERAN/UTRAN for voice
centric UEs relying on CS Fallback for voice support in E-UTRAN.
4.3.5.10 Preferred and Supported Network Behaviour

A UE includes in a Preferred Network Behaviour indication the Network Behaviour the UE can support and what it
would prefer to use.
The Preferred Network Behaviour includes this information:
- Whether Control Plane CIoT EPS Optimisation is supported.
- Whether User Plane CIoT EPS Optimisation is supported.
- Whether Control Plane CIoT EPS Optimisation is preferred or whether User Plane Plane CIoT EPS Optimisation
is preferred.
- Whether S1-U data transfer is supported.
- Whether SMS transfer without Combined Attach is requested.
- Whether Attach without PDN Connectivity is supported.
- Whether header compression for Control Plane CIoT EPS Optimisation is supported.
If SMS transfer without Combined EPS Attach is requested by the UE, a supporting MME provides SMS transfer
without the UE performing the combined EPS attach specified in TS 23.272 [58]. An MME connected to NB-IoT
should support SMS transfer without the UE being required to perform a Combined Attach.This feature is only
available to UEs that only support NB-IoT.
If S1-U data transfer is supported is indicated by the UE, the UE supports data transfer that is not subject to CIoT EPS
Optimisations. If the UE indicates support of User Plane CIoT EPS Optimisation then it shall also indicate support of
S1-U data transfer.
If Attach without PDN connection is supported, the UE need not establish a PDN connection as part of the Attach
procedure and the UE and MME may at any time release all the PDN connections and remain EPS attached.
The MME indicates the network behaviour the network accepts in the Supported Network Behaviour information. This
indication is per TAI List. The MME may indicate one or more of the following:
- Whether Control Plane CIoT EPS Optimisation is supported.
- Whether User Plane CIoT EPS Optimisation is supported.
- Whether S1-U data transfer is supported.
- Whether SMS transfer without Combined Attach is accepted.
- Whether Attach without PDN Connectivity is supported.
3GPP
Release 15 34 3GPP TS 23.401 V15.10.0 (2019-12)
- Whether header compression for Control Plane CIoT EPS Optimisation is supported.
If the MME indicates support of User Plane CIoT EPS Optimisation then it shall also indicate support of S1-U data
transfer. If the UE and MME indicate support for User Plane CIoT EPS Optimisation, MME sets the UE User Plane
CIoT Support Indicator to "supported" in S1-AP messages as defined in TS 36.413 [36].
For NB-IoT UEs that only support Control Plane CIoT EPS Optimisation, the MME shall include support for Control
Plane CIoT EPS Optimisation in NAS accept messages.
A UE that supports the NB-IoT shall always indicate support for Control Plane CIoT EPS Optimisation.
In a network that supports Dedicated Core Networks (see clause 5.19), the Preferred Network Behaviour indication
from the UE may be used to influence policy decisions that can cause rerouting of the Attach or TAU from an MME to
another MME.
Other CIoT EPS Optimisations include "Attach without PDN connection establishment"; "PDN type = non-IP"; and
"UE connection to SCEF". These features are requested by implicit and explicit signalling described within the relevant
clauses of this TS.
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 eNodeB 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, including UE's usage setting and voice
domain preference for E-UTRAN, if received during Attach and Tracking Area Update procedures (see
clause 4.3.5.9).
NOTE: One example of how the MME can use the "UE voice capabilities and settings" is to select an RFSP value
that enforces idle mode camping on 2G/3G for a UE acting in a "Voice centric" way and provisioned with
"CS Voice preferred, IMS Voice as secondary", in order to minimize the occurrancy of RAT changes.
Another example is the selection of an RFSP value that prevents idle mode camping on 2G for a UE
provisioned with "IMS PS voice preferred, CS Voice as secondary" if other RATs supporting IMS Voice
are available, as the UE would in such case always select the CS domain for its voice calls.
For roaming subscribers the MME may alternatively choose the RFSP Index in use based on the visited network policy,
but can take input from the HPLMN into account (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 eNodeB 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 (e.g. the MME may need to
update the RFSP Index value in use if the UE related context information in the MME has changed). When the RFSP
Index value in use is changed, the MME immediately provides the updated RFSP Index value in use to eNodeB by
modifying an existing UE context or by establishing an new UE context in the eNodeB or by being configured to
3GPP
Release 15 35 3GPP TS 23.401 V15.10.0 (2019-12)
include the updated RFSP Index value in use in the DOWNLINK NAS TRANSPORT message if the user plane
establishment is not needed. 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.1a GTP-C signalling based Load and Overload Control
4.3.7.1a.1 GTP-C Load Control

GTP-C Load Control feature is an optional feature which allows a GTP control plane node to send its Load Control
Information to a peer GTP control plane node which the receiving GTP control plane peer node uses to augment
existing GW selection procedure (i.e. as described in "PDN GW Selection" and "Serving GW Selection" according to
clauses 4.3.8.1, and 4.3.8.2 respectively). Load Control Information reflects the operating status of the resources of the
originating GTP control plane node.
NOTE 1: How a node computes its Load Control Information is implementation dependent.
Where certain pre-condition as described in clause 12.2.4.1 of TS 29.274 [43], is applicable, an optional feature APN
level load control may be supported and activated in the network. If this feature is activated, the PDN GW may convey
the Load Control Information at APN level (reflecting the operating status of the resources at the APN level), besides at
node level.
GTP-C Load Control feature allows the Serving GW to send its Load Control Information to the MME/SGSN.
GTP-C Load Control feature also allows the PDN GW to send its Load Control Information to the MME/SGSN via a
Serving GW.
Upon receiving Load Control Information the MME/SGSN supporting GTP-C Load Control feature uses it according to
clauses 4.3.8.1, and 4.3.8.2 for "PDN GW Selection" and "Serving GW Selection" respectively.
A node supporting GTP-C Load Control feature sends Load Control Information in any GTP control plane request or
response message such that exchange of Load Control Information does not trigger extra signalling.
A node supporting GTP-C Load Control feature sends Load Control Information to a peer GTP control node based on
whether local configuration allows for it.
A node supporting GTP-C Load Control feature may decide to send different values of Load Control Information on
inter-network (roaming) and on intra-network (non-roaming) interfaces based on local configuration.
Local configuration may allow the VPLMN to decide whether or not to act upon Load Control Information sent from a
peer GTP control plane node in the HPLMN.
NOTE 2: Refer to clause 12 of TS 29.274 [43] for the details, such as exact format of the Load Control
Information, mechanisms to discover the support of the feature by the peer node, interfaces for which this
feature is applicable, APN level load control, etc.
4.3.7.1a.2 GTP-C Overload Control

GTP-C Overload Control feature is an optional feature. Nodes using GTP control plane signalling may support
communication of Overload Control Information in order to mitigate overload situation for the overloaded node through
actions taken by the peer node(s). This feature is supported over S4, S11, S5 and S8 interfaces via GTPv2 control plane
protocol.
3GPP
Release 15 36 3GPP TS 23.401 V15.10.0 (2019-12)
A GTP-C node is considered to be in overload when it is operating over its nominal capacity resulting in diminished
performance (including impacts to handling of incoming and outgoing traffic). Overload Control Information reflects an
indication of when the originating node has reached such situation. This information, when transmitted between GTP-C
nodes may be used to reduce and/or throttle the amount of GTP-C signalling traffic between these nodes. As such, the
Overload Control Information provides guidance to the receiving node to decide actions which leads to mitigation
towards the sender of the information.
NOTE 1: How a node determines its Overload Control Information is implementation dependent.
The Overload Control Information may convey information regarding the node itself and/or regarding specific APN(s)
status. In order to mitigate overload,
- it shall be possible to signal control information about the overload of a GTP-C node (e.g. S-GW, P-GW);
- the PDN GW may detect overload for certain APNs, e.g. based on Diameter overload indication received from a
PCRF or from an external AAA server, or e.g. based on shortage of resources for an APN (IP address pool). It
shall be possible to signal appropriate control information about the APN status in addition to the mechanism
described in clause 4.3.7.5.
For a given APN, the PDN GW shall either activate the congestion control by conveying the Overload Control
Information at APN level or by conveying the "PDN GW back-off time" (as specified in clause 4.3.7.5), but not both at
the same time, as specified in more detail in clause 12.3.8 of TS 29.274 [43].
GTP-C Overload Control feature allows the MME/SGSN to send its Overload Control Information to the PDN GW via
Serving GW.
GTP-C Overload Control feature allows the Serving GW to send its Overload Control Information to the MME/SGSN
and P-GW.
GTP-C Overload Control feature also allows the PDN GW to send its Overload Control Information to the MME/SGSN
via a Serving GW.
GTP-C overload Control feature should continue to allow for preferential treatment of priority users (eMPS) and
emergency services as per existing specifications.
An MME/SGSN may during ESM and EMM procedures apply certain restrictions towards GWs (Serving GW and/or
PDN GW as applicable) that have indicated overload, e.g.:
- reject EPS Session Management requests from the UE (e.g. PDN Connectivity, Bearer Resource Allocation or
Bearer Resource Modification Requests) with a Session Management back-off timer as described in
clause 4.3.7.4.2;
- reject Mobility Management signalling requests from UEs (such as Attach, Detach, Service Request, Tracking
Area Update) with a Mobility Management back-off timer (e.g. reject Service Request requiring to activate user
plane bearers in an overloaded SGW) as described in clause 4.3.7.4.2;
- reject or accept requests for data transmission via Control Plane CIoT EPS Optimisation from UEs (e.g. Control
Plane Service Request and ESM Data Transport) with a Control Plane data back-off timer as described in
clause 4.3.7.4.2.7;
- may reduce/throttle messages towards the GWs indicating overload status;
- other implementation specific mechanisms, which are outside the scope of 3GPP specifications.
A PDN GW may take the following actions for MME/SGSN which have indicated overload:
- Limit or completely block non-GBR dedicated bearer establishment;
- Limit or completely block all Dedicated Bearer establishments or modification, except QCI=1 bearers;
- Limit or completely block all Dedicated Bearer establishments, including the QCI=1 bearers;
- other implementation specific mechanisms, which are outside the scope of 3GPP specifications.
A node supporting GTP-C Overload Control feature sends Overload Control Information in any GTP control plane
request or response message such that exchange of Overload Control Information does not trigger extra signalling.
3GPP
Release 15 37 3GPP TS 23.401 V15.10.0 (2019-12)
The computation and transfer of the Overload Control Information shall not add significant additional load to the node
itself and to its corresponding peer nodes. The calculation of Overload Control Information should not severely impact
the resource utilization of the node.
Based on local policies/configuration, a GTP-C node may support Overload Control feature and act upon or ignore
Overload Control Information in the VPLMN when received from HPLMN and in the HPLMN when received from
VPLMN. When this feature is supported, a GTP-C node may decide to send different values of Overload Control
Information on inter-network (roaming) and on intra-network (non-roaming) interfaces based on local
policies/configuration.
NOTE 2: Refer to clause 12 of TS 29.274 [43] for the details, such as exact format of the Overload Control
Information, mechanisms to discover the support of the feature by the peer node, interfaces for which this
feature is applicable, APN level overload control, etc.
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.
In some networks, the eNodeB may be configured to select specific MME for UEs configured for low access priority
with a different load balance to that used for MME selection for other UEs.
NOTE 3: The eNodeB can determine whether or not the "UE is configured for low access priority" from
information received in the RRC establishment or RRC resume signalling.
When DCNs are used, load balancing by eNodeB is only performed between MMEs that belong to the same DCN
within the same MME pool area, i.e. MMEs with the same PLMN and MMEGI value. When an MME serves multiple
DCNs and one DCN is supported by multiple MMEs, in order to achieve load balancing across the MMEs of the same
MME pool area supporting the same DCN, each DCN supported by this MME may have its own Weight Factor
(Weight Factor per DCN). The Weight Factor per DCN is set according to the capacity of an MME node for a specific
DCN relative to other MME nodes' capacity for that DCN within the same MME pool area. The eNB is provided with
per DCN Weight Factors, if any, by the connected MMEs at the set-up of the S1 connection. The DCN Load Balancing
functionality permits UEs that are entering into a pool area or being re-directed to an appropriate DCN to be distributed
in a manner that achieves load balancing between the CN nodes of the same DCN. The eNodeB may be configured to
select MME(s) from a specific CN for UEs configured for low access priority only for the case that no other
information and configuration is available for selecting an MME from a specific DCN.
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).
3GPP
Release 15 38 3GPP TS 23.401 V15.10.0 (2019-12)
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.
To off-load ECM-CONNECTED mode UEs, the MME initiates the S1 Release procedure with release cause "load
balancing TAU required" (clause 5.3.5). The S1 and RRC connections are released and the UE initiates a TAU but
provides neither the S-TMSI nor the GUMMEI to eNodeB in the RRC establishment.
NOTE 3: Special care needs to be taken when offloading Relay Nodes. This is because there may be UEs
connected to the RN and some of these UEs may be registered on other MMEs.
The MME should not release all S1 connections which are selected to be released immediately when offloading is
initiated. The MME may wait until the S1 Release is performed due to inactivity. When the MME is to be offloaded
completely the MME can enforce an S1 Release for all remaining UEs that were not offloaded by normal TAU
procedures or by S1 releases caused by inactivity.
To off-load UEs which perform TA Updates or Attaches initiated in ECM-IDLE mode, the MME completes that
procedure and the procedure ends with the MME releasing S1 with release cause "load balancing TAU required". The
S1 and RRC connections are released and the UE initiates a TAU but provides neither the S-TMSI nor the GUMMEI to
eNodeB in the RRC establishment.
When the UE provides neither the S-TMSI nor the GUMMEI in the RRC establishment, the eNodeB should select an
MME based on the Weight Factors of the MMEs in the pool.
To off-load UEs in ECM-IDLE state without waiting for the UE to perform a TAU or perform Service request and
become ECM-CONNECTED, the MME first pages UE to bring it to ECM-CONNECTED state. If paging the UE fails
and ISR is activated, the MME should adjust its paging retransmission strategy (e.g. limit the number of short spaced
retransmissions) to take into account the fact that the UE might be in GERAN/UTRAN coverage.
Hardware and/or software failures within an MME may reduce the MME's load handling capability. Typically such
failures should result in alarms which alert the operator/O+M system. Only if the operator/O+M system is sure that
there is spare capacity in the rest of the pool, the operator/O+M system might use the load re-balancing procedure to
move some load off this MME. However, extreme care is needed to ensure that this load re-balancing does not overload
other MMEs within the pool area (or neighbouring SGSNs) as this might lead to a much wider system failure.
When the Dedicated Core Network (DCN) feature is used, the DCN load re-balancing functionality permits UEs that
are registered on an MME in the DCN (within a pool area) to be moved to another MME in the same DCN in a manner
that achieves load balancing between the CN nodes of the DCN and pool area. The DCN load re-balancing is triggered
by the source MME (within a DCN). The details are as follows:
- If the UE is in ECM-IDLE state, the NAS Message Redirection procedure (see clause 5.19.1) is triggered at the
next intra-MME Tracking Area Update Request enabling eNodeB to load balance between MMEs of the same
DCN. To off-load UEs in ECM-IDLE state without waiting for the UE to perform a TAU or perform Service
request, the MME first pages the UE to bring it to ECM-CONNECTED state and proceeds as decribed for the
ECM-CONNECTED case below.
- If the UE is in ECM-CONNECTED state, the MME performs the GUTI reallocation procedure, includes the
unchanged GUTI of the UE and a non-broadcast TAI to induce the UE to peform a TAU procedure, and forces
the UE to go to ECM-IDLE state. During the subsequent TAU procedure the MME uses the NAS Message
Redirection procedure (see clause 5.19.1) to redirect the UE to another MME within the same DCN.
4.3.7.4 MME control of overload
4.3.7.4.1 General
The MME shall contain mechanisms for avoiding and handling overload situations. These can include the use of NAS
signalling to reject NAS requests from UEs.
In addition, under unusual circumstances, the MME shall restrict the load that its eNodeBs are generating on it if it is
configured to enable the overload restriction. This can be achieved by the MME invoking the S1 interface overload
procedure (see TS 36.300 [5] and TS 36.413 [36]) to all or to a proportion of the eNodeB's with which the MME has S1
3GPP
Release 15 39 3GPP TS 23.401 V15.10.0 (2019-12)
interface connections. To reflect the amount of load that the MME wishes to reduce, the MME can adjust the proportion
of eNodeBs which are sent S1 interface OVERLOAD START message, and the content of the OVERLOAD START
message.
The MME should select the eNodeBs at random (so that if two MMEs within a pool area are overloaded, they do not
both send OVERLOAD START messages to exactly the same set of eNodeBs).
The MME may optionally include a Traffic Load Reduction Indication in the OVERLOAD START message. In this
case the eNodeB shall, if supported, reduce the type of traffic indicated according the requested percentage (see
TS 36.413 [36]).
NOTE 1: The MME implementation may need to take into account the fact that eNodeBs compliant to Release 9
and earlier version of the specifications do not support the percentage overload indication.
An MME supporting Control Plane CIoT EPS Optimisation may include an indication in the OVERLOAD START
message indicating overload from data transfers via Control Plane CIoT EPS Optimisation.
Using the OVERLOAD START message, the MME can request the eNodeB to:
- reject RRC connection requests that are for non-emergency, non-exception reporting and non-high priority
mobile originated services; or
NOTE 2: This blocks PS service and service provided by MSC following an EPS/IMSI attach procedure.
- reject new RRC connection requests for EPS Mobility Management signalling (e.g. for TA Updates) for that
MME;
- only permit RRC connection requests for emergency sessions and mobile terminated services for that MME.
This blocks emergency session requests from UEs with USIMs provisioned with Access Classes 11 and 15 when
they are in their HPLMN/EHPLMN and from UEs with USIMs provisioned with Access Classes 12, 13 and 14
when they are in their home country (defined as the MCC part of the IMSI, see TS 22.011 [67]); or.
NOTE 3: The MME can restrict the number of responses to paging by not sending paging messages for a
proportion of the events that initiate paging. As part of this process, the MME can provide preference for
paging UEs with Emergency Bearer Services and terminations associated with MPS ARP.
- only permit RRC connection requests for high priority sessions, exception reporting and mobile terminated
services for that MME;
- reject new RRC connection requests from UEs that access the network with low access priority;
- not accept RRC connection requests with RRC establishment cause "mo-data" or "delayTolerantAccess" from
UEs that only support Control Plane CIoT EPS Optimisation.
NOTE 4: The RRC connection requests listed in this clause also include the request for RRC Connection Resume.
When rejecting an RRC connection request for overload reasons the eNodeB indicates to the UE an appropriate timer
value that limits further RRC connection requests for a while.
An eNodeB supports rejecting of RRC connection establishments for certain UEs as specified in TS 36.331 [37].
Additionally, an eNodeB provides support for the barring of UEs configured for Extended Access Barring, as described
in TS 22.011 [67]. These mechanisms are further specified in TS 36.331 [37]. If the UE is camping on NB-IoT,
Extended Access Barring does not apply.
An eNodeB may initiate Extended Access Barring when:
- all the MMEs connected to this eNB request to restrict the load for UEs that access the network with low access
priority; or
- requested by O&M.
If an MME invokes the S1 interface overload procedure to restrict the load for UEs that access the network with low
access priority, the MME should select all eNodeBs with which the MME has S1 interface connections. Alternatively,
the selected eNodeBs may be limited to a subset of the eNodeBs with which the MME has S1 interface connection (e.g.
particular location area or where devices of the targeted type are registered).
3GPP
Release 15 40 3GPP TS 23.401 V15.10.0 (2019-12)
During an overload situation the MME should attempt to maintain support for emergency bearer services (see
clause 4.3.12) and for MPS (see clause 4.3.18).
When the MME is recovering, the MME can either:
- send OVERLOAD START messages with new percentage value that permit more traffic to be carried, or
- the MME sends OVERLOAD STOP messages.
to some, or all, of the eNodeB(s).
In addition, to protect the network from overload the MME has the option of rejecting NAS request messages which
include the low access priority indicator before rejecting NAS request messages without the low access priority
indicator (see clause 4.3.7.4.2 for more information).
NOTE 5: It cannot be guaranteed that voice services will be available for mobile terminated calls while the
Mobility Management back-off timer is running. It is recommended, that UEs requiring voice services are
not configured for low access priority.
In addition, for UEs that don't support the Service Gap Control feature (see clause 4.3.17.9), the MME may use
"General NAS level Mobility Management control" as defined in clause 4.3.7.4.2.1.
4.3.7.4.1a Throttling of Downlink Data Notification Requests

Under unusual circumstances (e.g. when the MME load exceeds an operator configured threshold), the MME may
restrict the signalling load that its SGWs are generating on it, if configured to do so.
The MME can reject Downlink Data Notification requests for non-priority traffic for UEs in idle mode or to further
offload the MME, the MME can request the SGWs to selectively reduce the number of Downlink Data Notification
requests it sends for downlink non-priority traffic received for UEs in idle mode according to a throttling factor and for
a throttling delay specified in the Downlink Data Notification Ack message.
The SGW determines whether a bearer is to be subjected to the throttling of Downlink Data Notification Requests on
the basis of the bearer's ARP priority level and operator policy (i.e. operator's configuration in the SGW of the ARP
priority levels to be considered as priority or non- priority traffic). While throttling, the SGW shall throttle the
Downlink Data Notification Requests for low and normal priority bearers by their priority. The MME determines
whether a Downlink Data Notification request is priority or non-priority traffic on the basis of the ARP priority level
that was received from the SGW and operator policy.
If ISR is not active for the UE, during the throttling delay, the SGW drops downlink packets received on all its non-
priority bearers for UEs known as not user plane connected (i.e. the SGW context data indicates no downlink user plane
TEID) served by that MME in proportion to the throttling factor, and sends a Downlink Data Notification message to
the MME only for the non throttled bearers.
If ISR is active for the UE, during the throttling delay, the SGW does not send DDN to the MME and only sends the
DDN to the SGSN. If both MME and SGSN are requesting load reduction, the SGW drops downlink packets received
on all its non-priority bearers for UEs known as not user plane connected (i.e. the SGW context data indicates no
downlink user plane TEID) in proportion to the throttling factors.
The SGW resumes normal operations at the expiry of the throttling delay. The last received value of the throttling factor
and throttling delay supersedes any previous values received from that MME. The reception of a throttling delay restarts
the SGW timer associated with that MME.
4.3.7.4.1b Throttling of NIDD Submit Requests

Under unusual circumstances (e.g. when the MME load exceeds an operator configured threshold), the MME may
restrict NIDD Submit Request messages that its SCEFs are generating on it, if configured to do so.
3GPP
Release 15 41 3GPP TS 23.401 V15.10.0 (2019-12)
4.3.7.4.2 NAS level congestion control
4.3.7.4.2.1 General
NAS level congestion control contains the functions: "APN based congestion control" and "General NAS level Mobility
Management control".
The use of the APN based congestion control is for avoiding and handling of EMM and ESM signalling congestion
associated with UEs with a particular APN. Both UEs and network shall support the functions to provide APN based
EMM and ESM congestion control.
The MME may detect the NAS signalling congestion associated with the APN and start and stop performing the APN
based congestion control based on criteria such as:
- Maximum number of active EPS bearers per APN;
- Maximum rate of EPS Bearer activations per APN;
- One or multiple PDN GWs of an APN are not reachable or indicated congestion to the MME;
- Maximum rate of MM signalling requests associated with the devices with a particular subscribed APN; and/or
- Setting in network management.
The MME may detect the NAS signalling congestion associated with the UEs belonging to a particular group. The
MME may start and stop performing the group specific NAS level congestion control based on criteria such as:
- Maximum rate of MM and SM signalling requests associated with the devices of a particular group; and/or
The MME may detect the NAS signalling congestion associated with the UEs that belong to a particular group and are
subscribed to a particular APN. The MME may start and stop performing the APN and group specific NAS level
congestion control based on criteria such as:
- Maximum number of active EPS bearers per group and APN;
- Maximum rate of MM and SM signalling requests associated with the devices of a particular group and a
particular subscribed APN; and/or
The MME should not apply NAS level congestion control for high priority access and emergency services.
With General NAS level Mobility Management control, the MME may also use the reject of NAS level Mobility
Management signalling requests under general congestion conditions such as detecting congestion of one or several
DCNs in an MME serving multiple DCNs.
In addition, for UEs that don't support the Service Gap Control feature (see clause 4.3.17.9), the MME may return a
Mobility Management back-off timer to the UE in responses to requests where the intention is to send MO data or re-
attach with PDN connectivity when the Service gap timer for the UE is running at the MME.
4.3.7.4.2.2 APN based Session Management congestion control
The APN based Session Management congestion control may be activated by MME due to e.g. congestion situation at
MME, or by OAM at MME, or by a restart or recovery condition of a PDN GW, or by a partial failure or recovery of a
PDN GW for a particular APN(s).
The MME may reject the EPS Session Management (ESM) requests from the UE (e.g. PDN Connectivity, or Bearer
Resource Allocation Requests) with a Session Management back-off timer when ESM congestion associated with the
APN is detected. If the UE provides no APN, then the MME uses the APN which is used in PDN GW selection
procedure.
The MME may deactivate PDN connections belonging to a congested APN by sending the NAS Deactivate EPS Bearer
Context Request message to the UE with a Session Management back-off timer. If Session Management back-off timer
3GPP
Release 15 42 3GPP TS 23.401 V15.10.0 (2019-12)
is set in the NAS Deactivate EPS Bearer Context Request message then the cause "reactivation requested" should not be
set.
NOTE 1: UEs that don't support the Session Management back-off timer (including earlier release of UE) might
contribute to increasing the signalling load in the MME by reattempting Session Management procedure.
The MME may store a Session Management back-off time per UE and APN when congestion control is active for an
APN if a request without the low access priority indicator is rejected by the MME. The MME may immediately reject
any subsequent request from the UE targeting to the APN before the stored Session Management back-off time is
expired. If the MME stores the Session Management back-off time per UE and APN and the MME decides to send a
Session Management Request message to a UE connected to the congested APN (e.g. due to decreased congestion
situation), the MME shall clear the Session Management back-off time prior to sending any Session Management
Request message to the UE.
NOTE 2: The above functionality is to diminish the performance advantage for UEs that do not support the NAS
level back-off timer (e.g. pre-Rel-10 UEs) compared to UEs that do support it.
Upon reception of the Session Management back-off timer in the EPS Session Management reject message or in the
NAS Deactivate EPS Bearer Context Request message, the UE shall take the following actions until the timer expires:
- If APN is provided in the rejected EPS Session Management Request message or if the Session Management
back-off timer is received in the NAS Deactivate EPS Bearer Context Request message, the UE shall not initiate
any Session Management procedures for the congested APN. The UE may inititate Session Management
procedures for other APNs.
- If APN is not provided in the rejected EPS Session Management Request message, the UE shall not initiate any
Session Management requests of any PDN type without APN. The UE may initiate Session Management
procedures for specific APN.
- Cell/TA/PLMN/RAT change do not stop the Session Magement back-off timer.
- The UE is allowed to initiate the Session Management procedures for high priority access and emergency
services even when the Session Management back-off timer is running.
- The UE is allowed to initiate Bearer Resource Modification procedure to report 3GPP PS Data Off status change
when the EPS Session Management back off timer is running.
- If the UE receives a network initiated EPS Session Management Request message for the congested APN while
the Session Management back-off timer is running, the UE shall stop the Session Management back-off timer
associated with this APN and respond to the MME.
- If the UE is configured with a permission for overriding low access priority and the Session Management back-
off timer is running due to a reject message received in response to a request with low access priority, the upper
layers in the UE may request the initiation of Session Management procedures without low access priority.
The UE is allowed to initiate PDN disconnection procedure (e.g. sending PDN Disconnection Request) when the EPS
Session Management back off timer is running.
NOTE 3: The UE does not delete the related Session Management back-off timer when disconnecting a PDN
connection.
The UE shall support a separate Session Management back-off timer for every APN that the UE may activate.
To avoid that large amounts of UEs initiate deferred requests (almost) simultaneously, the MME should select the
Session Management back-off timer value so that deferred requests are not synchronized.
The APN based Session Management congestion control is applicable to the NAS ESM signalling initiated from the UE
in the control plane. The Session Management congestion control does not prevent the UE to send and receive data or
initiate Service Request procedures for activating user plane bearers towards the APN(s) that are under ESM congestion
control.
4.3.7.4.2.3 APN based Mobility Management congestion control
The MME may perform the APN based congestion control for UEs with a particular subscribed APN by rejecting
Attach procedures with a Mobility Management back-off timer.
3GPP
Release 15 43 3GPP TS 23.401 V15.10.0 (2019-12)
When congestion control is active for UEs with a particular subscribed APN, a Mobility Management back-off timer
may be sent by the MME to UE.
If MME maintains the UE context, the MME may store the back-off time per UE if a request without the low access
priority indicator is rejected by the MME. The MME may immediately reject any subsequent request from the UE
before the stored back-off time is expired.
NOTE 1: The above functionality is to diminish the performance advantage for UEs that do not support the NAS
level back-off timer (e.g. pre-Rel-10 UEs) compared to UEs that do support it.
After rejecting Attach Requests, the MME should keep the Subscriber Data for some time. This allows for rejection of
subsequent requests without HSS signalling when the congestion situation resulting from UEs with a particular
subscribed APN persists.
NOTE 2: Prior to the reject of attach messages of a UE by the MME, Subscriber Data for a UE may be present at
the MME because it was not deleted after the UE's detach. In this case when APN based congestion
control is active for a particular APN in the MME, the first reject of an attach message by the MME for
this UE, may be done without HSS signaling as well.
While the Mobility Management back-off timer is running, the UE shall not initiate any NAS request for Mobility
Management procedures. However, the UE is allowed to initiate the Mobility Management procedures for high priority
access and emergency services even when the Mobility Management back-off timer is running. While the Mobility
Management back-off timer is running, the UE is allowed to perform Tracking Area Update if it is already in connected
mode.
While the Mobility Management back-off timer is running, the UE configured with a permission for overriding low
access priority is allowed to initiate the Mobility Management procedures without low access priority if the Mobility
Management back-off timer was started due to a reject message received in response to a request with low access
priority and the upper layers in the UE request to activate a PDN connection without low access priority or the UE has
an activated PDN connection that is not with low access priority.
Mobility Management back-off timer value so that deferred requests are not synchronized.
NOTE 3: When receiving the Mobility Management back-off timer the UE behaviour is not APN specific.
4.3.7.4.2.4 General NAS level Mobility Management congestion control
Under general overload conditions the MME may reject Mobility Management signalling requests from UEs. When a
NAS request is rejected, a Mobility Management back-off timer may be sent by the MME and MME may store the
back-off time per UE if a request without the low access priority indicator is rejected by the MME and if MME
maintains the UE context. The MME may immediately reject any subsequent request from the UE before the stored
back-off time is expired. While the Mobility Management back-off timer is running, the UE shall not initiate any NAS
request for Mobility Management procedures except for Detach procedure and except for high priority access,
emergency services and mobile terminated services. After any such Detach procedure, the back-off timer continues to
run. While the Mobility Management back-off timer is running, the UE is allowed to perform Tracking Area Update if
it is already in connected mode. If the UE receives a paging request from the MME while the Mobility Management
back off timer is running, the UE shall stop the Mobility Management back-off timer and initiate the Service Request
procedure or the Tracking Area Update procedure as described in clause 5.3.3.0.
While the Mobility Management back-off timer is running, the UE configured with a permission for overriding low
access priority is allowed to initiate the Mobility Management procedures without low access priority if the Mobility
Management back-off timer was started due to a reject message received in response to a request with low access
priority and the upper layers in UE request to establish a PDN connection without low access priority or the UE has an
established PDN connection that is without low access priority.
While the Mobility Management back-off timer is running, the UE configured with permission for sending exception
reporting is allowed to initiate the Control Plane Service Request procedure for exception reporting. If the Mobility
Management back-off timer was started due to a reject message received in response to a request for exception
reporting, the UE shall not initiate the Control Plane Service Request procedure for exception reporting while the
Mobility Management back-off timer is running.
The Mobility Management back-off timer shall not impact Cell/RAT and PLMN change. Cell/RAT and TA change do
not stop the Mobility Management back-off timer. The Mobility Management back-off timer shall not be a trigger for
3GPP
Release 15 44 3GPP TS 23.401 V15.10.0 (2019-12)
PLMN reselection. The back-off timer is stopped as defined in TS 24.301 [46] when a new PLMN that is not an
equivalent PLMN is accessed.
Mobility Management back-off timer value so that the deferred requests are not synchronized.
When the UE receives a handover command, the UE shall proceed with the handover procedure regardless of whether
Mobility Management back-off timer is running.
The MME should not reject Tracking Area Update procedures that are performed when the UE is already in connected
mode.
For idle mode inter CN node mobility, the MME may reject Tracking Area Update procedures and include a Mobility
Management back off timer value in the Tracking Area Reject message.
If the MME rejects Tracking Area Update request or Service request with a Mobility Management back-off timer which
is larger than the sum of the UE's periodic TAU timer plus the Implicit Detach timer, the MME should adjust the mobile
reachable timer and/or Implicit Detach timer such that the MME does not implicitly detach the UE while the Mobility
Management back-off timer is running.
NOTE: This is to minimize unneeded signalling after the Mobility Management back-off timer expires.
4.3.7.4.2.5 Group specific NAS level congestion control
The group specific NAS level congestion control applies to a specific group of UEs. Each group has a group identifier
assigned.
A UE belongs to a group, if the corresponding group identifier is stored in the UE's subscription data in the HSS. A UE
may belong to multiple groups and the MME may perform the Group specific NAS level congestion control to an UE as
described below independent of whether Group specific NAS level congestion control is activated for one, multiple, or
all groups the UE belongs to. The group identifier shall be stored per UE in the HSS and obtained by the MME as part
of normal HSS signalling. A UE is not aware of a group subscription.
The group specific NAS level congestion control may be activated for Session Management signalling, or for Mobility
Management signalling, or both. The group specific NAS level congestion control is activated based on operator
policies.
When the group specific NAS level congestion control for Session Management signalling is active for a particular
group, the MME's behaviour is similar to that in clause 4.3.7.4.2.2, with the following modifications:
- MME may apply ESM congestion control to all subscribed APNs for UEs that belong to this particular group.
NOTE: How the MME applies ESM congestion control to all subscribed APNs is left to Stage 3.
- The MME rejects the EPS Session Management (ESM) request(s) from the UE belonging to this particular group
(e.g. PDN Connectivity, or Bearer Resource Allocation Requests) with a Session Management back-off timer.
When group specific NAS level congestion control for Mobility Management signalling is active for a particular group,
the MME's behaviour is similar to that in clause 4.3.7.4.2.3, but applied to UEs subscribed to this particular group rather
that subscribed to a particular APN.
Group specific NAS level congestion control is performed at the MME based on the UE's subscription information
provided by the HSS. There is no impact on the UE, and hence, UE's behaviour as described in clauses 4.3.7.4.2.2 and
4.3.7.4.2.3 does not change.
4.3.7.4.2.6 APN and group specific NAS level congestion control
The APN and group specific NAS level congestion control is the interclause of APN specific NAS level congestion
control and Group specific NAS level congestion control, i.e. it applies to a specific group of UEs with a particular
subscribed APN. Each group of UEs has a group identifier assigned and stored in the HSS.
A UE may belong to multiple groups and the MME may perform the APN and group specific NAS level congestion
control to an UE as described below independent of whether the APN and group specific NAS level congestion control
is activated for one, multiple or all groups the UE belongs to. The group identifier(s) shall be stored per UE in the HSS
3GPP
Release 15 45 3GPP TS 23.401 V15.10.0 (2019-12)
and obtained by the MME as part of normal HSS signalling. A UE is not aware of the group identifier(s) that the UE
belongs to.
The APN and group specific NAS level congestion control may be activated for Session Management signalling, or for
Mobility Management signalling, or both. The APN and group specific NAS level congestion control is activated based
on operator policies.
When the APN and group specific NAS level congestion control for Session Management signalling is activated for a
UE belonging to a particular group and initiating signalling to a particular APN, the MME's behaviour is similar to that
in clause 4.3.7.4.2.2, with the following modifications:
- The EPS Session Management (ESM) congestion control is applied to this particular APN, and for UEs
belonging to this particular group,
- The MME may reject ESM requests from the UEs belonging to this particular group and attaching to this
particular APN (e.g. PDN Connectivity, or Bearer Resource Allocation Requests) with a Session Management
back-off timer. If the UE provides no APN, then the MME uses the APN which is used in PDN GW selection
procedure.
- The MME may deactivate PDN connections of the UEs, belonging to this particular group and attaching to this
particular APN, by sending the NAS Deactivate EPS Bearer Context Request message to the UE with a Session
Management back-off timer.
When the APN and group specific NAS level congestion control for Mobility Management signalling is activated for a
UE belonging to a particular group and with a particular subscribed APN, the MME's behaviour is similar to that in
clause 4.3.7.4.2.3, but applied to UEs with this particular subscribed APN and belonging to this particular group.
APN and group specific NAS level congestion control is performed at the MME based on the UE's subscription
information provided by the HSS. There is no impact on the UE, and hence, UE's behaviour described in
clauses 4.3.7.4.2.2 and 4.3.7.4.2.3 does not change.
4.3.7.4.2.7 Control Plane data specific NAS level congestion control
Under overload conditions the MME may restrict requests from UEs for data transmission via Control Plane CIoT EPS
Optimisation. A Control Plane data back-off timer may be returned by the MME (e.g.in Attach/TAU/RAU Accept
messages, Service Reject message or Service Accept message). While the Control Plane data back-off timer is running,
the UE shall not initiate any data transfer via Control Plane CIoT EPS Optimisation, i.e. the UE shall not send any
Control Plane Service Request with ESM Data Transport message as defined in TS 24.301 [46]. The MME shall store
the Control Plane data back-off timer per UE and shall reject any further request (other than exception reporting and a
response to paging) for data transmission via Control Plane Service Request from that UE while the Control Plane data
back-off timer is still running.
NOTE 1: The Control Plane data back-off timer does not affect any other mobility management or session
management procedure.
NOTE 2: The Control Plane data back-off timer does not apply to user plane data communication.
If the UE is allowed to send exception reporting, the UE may initiate Control Plane Service Request for exception
reporting even if Control Plane data back-off timer is running.
The UE may respond with Control Plane Service Request without ESM Data Transport to a paging even if the Control
Plane data back-off timer is running.
If the MME receives a Control Plane Service Request in reponse to paging, and the MME has a Control Plane data
back-off timer running for the UE, and the MME is not overloaded, and MME decides to accept the Control Plane
Service Request, then the MME shall respond with Service Accept message without the Control Plane data back-off
timer and stop the Control Plane data back-off timer. If the UE receives a Service Accept message without the Control
Plane data back-off timer from the MME while the Control Plane data back-off timer is running, the UE shall stop the
Control Plane data back-off timer. The Control Plane data back-off timer in the UE and the MME is stopped at PLMN
change.
If the MME receives a Control Plane Service Request with ESM Data Transport message, and decides to send the UE a
Control Plane data back-off timer, the MME may decide to process the Control Plane Service Request with ESM Data
Transport message, i.e. decrypt and forward the data payload, or not based on the following:
3GPP
Release 15 46 3GPP TS 23.401 V15.10.0 (2019-12)
- If the UE has additionally indicated in a NAS Release Assistance Information in the NAS PDU that no further
Uplink or Downlink Data transmissions are expected, then the MME may process (integrity
check/decipher/forward) the received Control Plane data packet, and send SERVICE ACCEPT to the UE with
Control Plane data back-off timer. The UE interprets this as successful transmission of the Control Plane data
packet and starts the Control Plane data back-off timer.
- For all other cases, the MME may decide to not process the received control plane data packet and sends
SERVICE REJECT to the UE with Control Plane data back-off timer. The UE interprets this indication as
unsuccessful delivery of the control plane data packet and starts the Control Plane data back-off timer. Then
MME may take into consideration whether the PDN Connection is set to Control Plane only to make the
decision whether to reject the packet and send SERVICE REJECT or move the PDN connection to user plane
and process the data packet.
- Alternatively, if UE has not provided in the in Control Plane service request the NAS Release Assistance
Information, and the EPS bearer belongs to a PDN connection not set to Control Plane only, and UE supports
User Plane CIoT Optimisation (or legacy S1-U), then the MME may initiate establishment of S1-U bearer during
Data Transport in Control Plane CIoT EPS Optimisation (according to the procedure defined in clause 5.3.4B.4).
In this case MME may also return a Control Plane data back-off timer within the NAS message.
The MME only includes the Control Plane data back-off timer if the UE has indicated support for Control Plane data
back-off timer in the Attach/TAU/RAU request.
NOTE 3: If the MME is overloaded or close to overload, but the UE has not indicated support for Control Plane
data back-off timer, the MME can use other overload control mechanisms, e.g. mobility management
back-off timer or use user plane data communication.
4.3.7.5 PDN GW control of overload

The PDN GW may provide mechanisms for avoiding and handling overload situations. These include the rejection of
PDN connection requests from UEs.
The PDN GW may detect APN congestion and start and stop performing overload control based on criteria such as:
- Maximum number of active bearers per APN; and/or
- Maximum rate of bearer activations per APN.
When performing overload control the PDN GW rejects PDN connection requests. When receiving the rejection from
the PDN GW, the MME rejects the UE's PDN connection request as specified in clause 4.3.7.4.2. In addition the PDN
GW may indicate a "PDN GW back-off time" for a specific APN to the MME. The MME should reject PDN
connection requests, for the specific APN related to that PDN GW during the "PDN GW back-off time", by the means
specified in clause 4.3.7.4.2. If a PDN GW indicates APN congestion by the "PDN GW back-off time" the MME may
select another PDN GW of that APN instead of rejecting PDN connection requests unless there is already an existing
PDN connection to the same APN for the UE, in which case, the MME shall reject PDN connection request.
4.3.8 Selection functions
4.3.8.1 PDN GW selection function (3GPP accesses)

The PDN GW selection function allocates a PDN GW that shall provide the PDN connectivity for the 3GPP access. The
function uses subscriber information provided by the HSS and possibly additional criteria such as SIPTO/LIPA support
per APN configured in the SGSN/MME, UE support for dual connectivity with NR, 15 EPS bearers support by the UE,
CIoT EPS Optimisation(s) impacting PDN GW e.g. Non-IP support, NB-IoT RAT support (for generation of
accounting information), etc.
NOTE 1: Selection of PDN GWs optimised for different RATs (e.g. NB-IoT) can be achieved by the allocation of
different APNs to subscribers allowed to use specific RATs and/or using the UE Usage Type.
The criteria for PDN GW selection may include load balancing between PDN GWs. When the PDN GW IP addresses
returned from the DNS server include Weight Factors, the MME should use it if load balancing is required. The Weight
Factor is typically set according to the capacity of a PDN GW node relative to other PDN GW nodes serving the same
APN. For further details on the DNS procedure see TS 29.303 [61].
3GPP
Release 15 47 3GPP TS 23.401 V15.10.0 (2019-12)
When the MME supports the GTP-C Load Control feature, it takes into account the Load Information received from the
PDN GW in addition to the Weight Factors received from the DNS server to perform selection of an appropriate PDN
GW.
NOTE 2: How Weight Factors can be used in conjunction with Load Information received via GTP control plane
signalling is left up to Stage 3.
The PDN subscription contexts provided by the HSS contain:
- the identity of a PDN GW and an APN (PDN subscription contexts with subscribed PDN GW address are not
used when there is interoperation with pre Rel-8 2G/3G SGSN), or
- an APN and an indication for this APN whether the allocation of a PDN GW from the visited PLMN is allowed
or whether a PDN GW from the home PLMN shall be allocated. Optionally an identity of a PDN GW may be
contained for handover with non-3GPP accesses.
- optionally for an APN, an indication of whether SIPTO above RAN, or SIPTO at the Local Network, or both, is
allowed or prohibited for this APN.
- optionally for an APN, an indication of whether LIPA is conditional, prohibited, or only LIPA is supported for
this APN.
In the case of static address allocation, a static PDN GW is selected by either having the APN configured to map to a
given PDN GW, or the PDN GW identity provided by the HSS indicates the static PDN GW.
The HSS also indicates which of the PDN subscription contexts is the Default one for the UE.
To establish connectivity with a PDN when the UE is already connected to one or more PDNs, the UE provides the
requested APN for the PDN GW selection function.
If one of the PDN subscription contexts provided by the HSS contains a wild card APN (see TS 23.003 [9]), a PDN
connection with dynamic address allocation may be established towards any APN requested by the UE. An indication
that SIPTO (above RAN, at the local network, or both) is allowed or prohibited for the wild card APN allows or
prohibits SIPTO for any APN that is not present in the subscription data.
If the HSS provides the identity of a statically allocated PDN GW, or the HSS provides the identity of a dynamically
allocated PDN GW and the Request Type indicates "Handover", no further PDN GW selection functionality is
performed. If the HSS provides the identity of a dynamically allocated PDN GW, the HSS also provides information
that identifies the PLMN in which the PDN GW is located.
NOTE 3: The MME uses this information to determine an appropriate APN-OI and S8 protocol type (PMIP or
GTP) when the MME and PDN GW are located in different PLMNs.
If the HSS provides the identity of a dynamically allocated PDN GW and the Request Type indicates "initial Request",
either the provided PDN GW is used or a new PDN GW is selected. When a PDN connection for an APN with SIPTO-
allowed is requested, the PDN GW selection function shall ensure the selection of a PDN GW that is appropriate for the
UE's location. The PDN GW identity refers to a specific PDN GW. If the PDN GW identity includes the IP address of
the PDN GW, that IP address shall be used as the PDN GW IP address; otherwise the PDN GW identity includes an
FQDN which is used to derive the PDN GW IP address by using Domain Name Service function, taking into account
the protocol type on S5/S8 (PMIP or GTP).
NOTE 4: Provision of a PDN GW identity of a PDN GW as part of the subscriber information allows also for a
PDN GW allocation by HSS.
If the HSS provides a PDN subscription context that allows for allocation of a PDN GW from the visited PLMN for this
APN and, optionally, the MME is configured to know that the visited VPLMN has a suitable roaming agreement with
the HPLMN of the UE, the PDN GW selection function derives a PDN GW identity from the visited PLMN. If a visited
PDN GW identity cannot be derived, or if the subscription does not allow for allocation of a PDN GW from the visited
PLMN, then the APN is used to derive a PDN GW identity from the HPLMN. The PDN GW identity is derived from
the APN, subscription data and additional information by using the Domain Name Service function. If the PDN GW
identity is a logical name instead of an IP address, the PDN GW address is derived from the PDN GW identity, protocol
type on S5/S8 (PMIP or GTP) by using the Domain Name Service function. The S8 protocol type (PMIP or GTP) is
configured per HPLMN in MME/SGSN.
3GPP
Release 15 48 3GPP TS 23.401 V15.10.0 (2019-12)
In order to select the appropriate PDN GW for SIPTO above RAN service, the PDN GW selection function uses the
TAI (Tracking Area Identity), the serving eNodeB identifier, or TAI together with serving eNodeB identifier depending
on the operator's deployment during the DNS interrogation as specified in TS 29.303 [61] to find the PDN GW identity.
In roaming scenario PDN GW selection for SIPTO is only possible when a PDN GW in the visited PLMN is selected.
Therefore in a roaming scenario with home routed traffic, PDN GW selection for SIPTO is not performed.
In order to select the appropriate GW for SIPTO at the local network service with a stand-alone GW (with S-GW and L-
GW collocated), the PDN GW selection function uses the APN and the Local Home Network ID during the DNS
interrogation as specified in TS 29.303 [61] to find the PDN GW identity. The Local Home Network ID is provided to
the MME by the (H)eNB in every INITIAL UE MESSAGE and every UPLINK NAS TRANSPORT control message as
specified in TS 36.413 [36]. The MME uses the Local Home Network ID to determine if the UE has left its current
local network and if S-GW relocation is needed.
For SIPTO at the Local Network with L-GW function collocated with the (H)eNB the PDN GW selection function uses
the L-GW address proposed by the (H)eNB in the S1-AP message, instead of DNS interrogation.
In order to select the appropriate L-GW for LIPA service, if permitted by the CSG subscription data and if the UE is
roaming, the VPLMN LIPA is allowed, the PDN GW selection function uses the L-GW address proposed by HeNB in
the S1-AP message, instead of DNS interrogation. If no L-GW address is proposed by the HeNB and the UE requested
an APN with LIPA permissions set to "LIPA-only", the request shall be rejected. If no L-GW address is proposed by
the HeNB and the UE requested an APN with LIPA permissions set to "LIPA-conditional", the MME uses DNS
interrogation for PDN GW selection to establish a non-LIPA PDN connection. The PDN subscription context for an
APN with LIPA permissions set to "LIPA-only" shall not contain a statically configured PDN address or a statically
allocated PDN GW. A static PDN address or a static PDN GW address, if configured by HSS for an APN with LIPA
permissions set to "LIPA-conditional", is ignored by MME when the APN is established as a LIPA PDN connection.
When establishing a PDN connection for a LIPA APN, the VPLMN Address Allowed flag is not considered.
The PDN GW domain name shall be constructed and resolved by the method described in TS 29.303 [61], which takes
into account any value received in the APN-OI Replacement field for home routed traffic. Otherwise, or when the
resolution of the above PDN GW domain name fails, the PDN GW domain name shall be constructed by the serving
node using the method specified in Annex A of TS 23.060 [7] and clause 9 of TS 23.003 [9]. If the Domain Name
Service function provides a list of PDN GW addresses, one PDN GW address is selected from this list. If the selected
PDN GW cannot be used, e.g. due to an error, then another PDN GW is selected from the list. The specific interaction
between the MME/SGSN and the Domain Name Service function may include functionality to allow for the retrieval or
provision of additional information regarding the PDN GW capabilities (e.g. whether the PDN GW supports
PMIP-based or GTP-based S5/S8, or both).
NOTE 5: The APN as constructed by the MME/SGSN for PDN GW resolution takes into account the APN-OI
Replacement field. This differs from the APN that is provided in charging data to another SGSN and
MME over the S3, S10 and S16 interfaces as well as to Serving GW and PDN GW over the S11, S4 and
S5/S8 interfaces, in that the APN-OI Replacement field is not applied. See clause 5.7.2 of the present
document for more details.
If the UE provides an APN for a PDN, this APN is then used to derive the PDN GW identity as specified for the case of
HSS provided APN if one of the subscription contexts allows for this APN.
If there is an existing PDN connection to the same APN used to derive the PDN GW address, the same PDN GW shall
be selected.
As part of PDN GW selection, an IP address of the assigned PDN GW may be provided to the UE for use with host
based mobility as defined in TS 23.402 [2], if the PDN GW supports host-based mobility for inter-access mobility
towards accesses where host-based mobility can be used. If a UE explicitly requests the address of the PDN GW and the
PDN GW supports host based mobility then the PDN GW address shall be returned to the UE.
When DCNs with dedicated PDN GWs are used, the DNS procedure (TS 29.303 [61]) for PDN GW selection may be
used such that a PDN GW belonging to a DCN serving a particular category of UEs, e.g. identified by UE Usage Type,
is selected. When UEs with the same UE Usage type are served by multiple DCNs, it shall also be possible to select the
PDN GW belonging to the DCN serving the particular UE.
4.3.8.2 Serving GW selection function

The Serving GW selection function selects an available Serving GW to serve a UE. The selection bases on network
topology, i.e. the selected Serving GW serves the UE's location and for overlapping Serving GW service areas, the
3GPP
Release 15 49 3GPP TS 23.401 V15.10.0 (2019-12)
selection may prefer Serving GWs with service areas that reduce the probability of changing the Serving GW. When
SIPTO is allowed then it is also considered as a criterion for Serving GW selection, e.g. when the first PDN connection
is requested. Other criteria for Serving GW selection should include load balancing between Serving GWs, UE support
for dual connectivity with NR, CIoT EPS Optimisation(s) impacting Serving GW e.g. Non-IP support, NB-IoT RAT
support (for generation of accounting information), etc. When the Serving GW IP addresses returned from the DNS
server include Weight Factors, the MME should use it if load balancing is required. The Weight Factor is typically set
according to the capacity of a Serving GW node relative to other Serving GW nodes serving the same Tracking area.
For further details on DNS procedure see TS 29.303 [61].
When the MME supports the GTP-C Load Control feature, it takes into account the Load Information received from the
Serving GW in addition to the Weight Factors received from the DNS server to perform selection of an appropriate
Serving GW.
NOTE 1: How Weight Factors can be used in conjuction with Load Information received via GTP control plane
signalling is left up to Stage 3.
If a subscriber of a GTP only network roams into a PMIP network, the PDN GWs selected for local breakout support
the PMIP protocol, while PDN GWs for home routed traffic use GTP. This means the Serving GW selected for such
subscribers may need to support both GTP and PMIP, so that it is possible to set up both local breakout and home
routed sessions for these subscribers. For a Serving GW supporting both GTP and PMIP, the MME/SGSN should
indicate the Serving GW which protocol should be used over S5/S8 interface. The MME/SGSN is configured with the
S8 variant(s) on a per HPLMN granularity.
If a subscriber of a GTP only network roams into a PMIP network, the PDN GWs selected for local breakout may
support GTP or the subscriber may not be allowed to use PDN GWs of the visited network. In both cases a GTP only
based Serving GW may be selected. These cases are considered as roaming between GTP based operators.
If combined Serving and PDN GWs are configured in the network the Serving GW Selection Function may preferably
derive a Serving GW that is also a PDN GW for the UE.
In order to provide SIPTO at the local network service with stand-alone GW, the L-GW and Serving GW shall be co-
located. The Serving GW selection function in the MME is used to ensure that the Serving GW is provided according to
operator policy as described in clause 4.3.15a. When the L-GW is collocated with the (H)eNB, the Serving GW remains
located in the mobile operator's core network.
The Domain Name Service function may be used to resolve a DNS string into a list of possible Serving GW addresses
which serve the UE's location. The specific interaction between the MME/SGSN and the Domain Name Service
function may include functionality to allow for the retrieval or provision of additional information regarding the Serving
GW capabilities (e.g. whether the Serving GW supports PMIP-based or GTP-based S5/S8, or both). The details of the
selection are implementation specific.
For handover from non-3GPP accesses in roaming scenario, the Serving GW selection function for local anchoring is
described in TS 23.402 [2].
The Serving GW selection function in the MME is used to ensure that all Tracking Areas in the Tracking Area List
belong to the same Serving GW service area.
When DCNs with dedicated Serving GWs are used, the DNS procedure (TS 29.303 [61]) for Serving GW selection may
be used such that a Serving GW belonging to a DCN serving a particular category of UEs, e.g. identified by UE Usage
Type, is selected. When UEs with the same UE Usage type are served by multiple DCNs, it shall also be possible to
select the Serving GW belonging to the DCN serving the particular UE.
NOTE 2: Selection of Serving GWs optimised for different RATs (e.g. NB-IoT) can be achieved by using UE
Usage Type and/or by using different TAIs for different RATs.
4.3.8.3 MME selection function

The MME selection function selects an available MME for serving a UE. The selection is based on network topology,
i.e. the selected MME serves the UE's location and for overlapping MME service areas, the selection may prefer MMEs
with service areas that reduce the probability of changing the MME. When a MME/SGSN selects a target MME, the
selection function performs a simple load balancing between the possible target MMEs. In networks that deploy
dedicated MMEs/SGSNs for UEs configured for low access priority, the possible target MME selected by source
MME/SGSN is typically restricted to MMEs with the same dedication.
3GPP
Release 15 50 3GPP TS 23.401 V15.10.0 (2019-12)
When a MME/SGSN supporting DCNs selects a target MME, the selected target MME should be restricted to MMEs
that belong to the same DCN. The DNS procedure may be used by the source CN node to select the target MME from a
given DCN. If both low access priority and UE Usage Type parameter are used for MME selection, selection based on
UE Usage type parameter overrides selection based on the low access priority indication.
When a MME supporting CIoT EPS Optimisation(s) selects a target MME, the selected MME should all support the
CIoT EPS Optimisations applicable to the given UE's attachment. In case the source MME is unable to find a target
MME matching all CIoT EPS Optimisation(s) applicable to a given UE's attachment, then the source MME, based on
implementation, selects a target MME which provides the CIoT EPS Optimisation(s) best applicable to that UE's
attachment.
When an eNodeB selects an MME, the eNodeB may use a selection function which distinguishes if the GUMMEI is
mapped from P-TMSI/RAI or is a native GUMMEI. The indication of mapped or native GUMMEI shall be signalled by
the UE to the eNodeB as an explicit indication. The eNodeB may differentiate between a GUMMEI mapped from
P-TMSI/RAI and a native GUMMEI based on the indication signalled by the UE. Alternatively, the differentiation
between a GUMMEI mapped from P-TMSI/RAI and a native GUMMEI may be performed based on the value of most
significant bit of the MME Group ID, for PLMNs that deploy such mechanism. In this case, if the MSB is set to "0"
then the GUMMEI is mapped from P-TMSI/RAI and if MSB is set to "1", the GUMMEI is a native one. Alternatively
the eNodeB makes the selection of MME only based on the GUMMEI without distinguishing on mapped or native.
When an eNodeB selects an MME, the selection shall achieve load balancing as specified in clause 4.3.7.2.
When DCNs are deployed, to maintain a UE in the same DCN when the UE enters a new MME pool area, the eNodeB's
NNSF should have configuration that selects, based on the MMEGIs or NRIs of neighbouring pool areas, a connected
MME from the same DCN. Alternately, for PLMN wide inter-pool intra-RAT mobility, the operator may divide up the
entire MMEGI and NRI value space into non-overlapping sets with each set allocated to a particular DCN. In this case
all eNodeBs may be configured with the same MME selection configuration. If UE assisted DCN selection feature is
supported and a DCN-ID is provided by the UE, the DCN-ID shall be used in the eNodeB for MME selection to
maintain the same DCN when the serving MME is not available.
When selecting an MME for a UE that is using the NB-IoT RAT, and/or for a UE that signals support for CIoT EPS
Optimisations in RRC signalling (As specified in TS 36.331 [37], for NB-IoT, UE indicates whether it supports "User
Plane CIoT EPS Optimisation" and "EPS Attach without PDN Connectivity". And for WB-E-UTRAN, UE indicates
whether it supports "Control Plane CIoT EPS Optimisation", "User Plane CIoT EPS Optimisation" and "EPS Attach
without PDN Connectivity"), the eNodeB's MME selection algorithm shall select an MME taking into account the
MME's support (or non-support) for the Release 13 NAS signalling protocol.
When DCN are deployed for the purpose of CIoT EPS Optimisation, UE included CIoT EPS Optimisation information
in the RRC signalling, may depending on eNB configuration, be used to perform initial DCN selection.
4.3.8.4 SGSN selection function

The SGSN selection function selects an available SGSN to serve a UE. The selection is based on network topology, i.e.
the selected SGSN serves the UE's location and for overlapping SGSN service areas, the selection may prefer SGSNs
with service areas that reduce the probability of changing the SGSN. When a MME/SGSN selects a target SGSN, the
selection function performs a simple load balancing between the possible target SGSNs. In networks that deploy
dedicated MMEs/SGSNs for UEs configured for low access priority, the possible target SGSN selected by source
MME/SGSN is typically restricted to SGSNs with the same dedication.
When a MME/SGSN supporting DCNs selects a target SGSN, the selected target SGSN should be restricted to SGSNs
that belong to the same CN. The DNS procedure may be used by the source CN node to select the target SGSN from a
given DCN. If both low access priority and UE Usage Type parameter are used for SGSN selection, selection based on
UE Usage type parameter overrides selection based on the low access priority indication.
4.3.8.5 Selection of PCRF

The PDN GW and AF may be served by one or more PCRF nodes in the HPLMN and, in roaming with local breakout
scenarios, one or more PCRF nodes in the VPLMN.
The selection of PCRF and linking of the different UE's PCC sessions over the multiple PCRF interfaces (e.g. Rx
session, Gx session, S9 session etc.) for a UE IP CAN session is described in TS 23.203 [6].
3GPP
Release 15 51 3GPP TS 23.401 V15.10.0 (2019-12)
4.3.9 IP network related functions
4.3.9.1 Domain Name Service function

The Domain Name Service function resolves logical PDN GW names to PDN GW addresses. This function is standard
Internet functionality according to RFC 1034 [17], which allows resolution of any name to an IP address (or addresses)
for PDN GWs and other nodes within the EPS.
4.3.9.2 DHCP function

The Dynamic Host Configuration Function allows to deliver IP configuration information for UEs. This function is
standard Internet functionality according to RFC 2131 [19], RFC 3736 [20], RFC 3633 [21] and RFC 4039 [25].
4.3.9.3 Explicit Congestion Notification

The E-UTRAN/UTRAN and the UE support the RFC 3168 [55] Explicit Congestion Notification (ECN), as described
in TS 36.300 [5], TS 25.401 [16] and TS 26.114 [56].
4.3.10 Functionality for Connection of eNodeBs to Multiple MMEs

An eNodeB may connect to several MMEs. This implies that an eNodeB must be able to determine which of the
MMEs, covering the area where an UE is located, should receive the signalling sent from a UE. To avoid unnecessary
signalling in the core network, a UE that has attached to one MME should generally continue to be served by this MME
as long as the UE is in the radio coverage of the pool area to which the MME is associated. The concept of pool area is
a RAN based definition that comprises one or more TA(s) that, from a RAN perspective, are served by a certain group
of MMEs. This does not exclude that one or more of the MMEs in this group serve TAs outside the pool area. This
group of MMEs is also referred to as an MME pool.
To enable the eNodeB to determine which MME to select when forwarding messages from an UE, this functionality
defines a routing mechanism (and other related mechanism). A routing mechanism (and other related mechanism) is
defined for the MMEs. The routing mechanism is required to find the correct old MME (from the multiple MMEs that
are associated with a pool area). When a UE roams out of the pool area and into the area of one or more MMEs that do
not know about the internal structure of the pool area where the UE roamed from, the new MME will send the
Identification Request message or the Context Request message to the old MME using the GUTI. The routing
mechanism in both the MMEs and the eNodeB utilises the fact that every MME that serves a pool area must have its
own unique value range of the GUTI parameter within the pool area.
4.3.11 E-UTRAN Sharing Function

E-UTRAN Sharing is an agreement between operators and shall be transparent to the user. This implies that an
E-UTRAN UE needs to be able to discriminate between core network operators available in a shared radio access
network and that these operators can be handled in the same way as operators in non-shared networks. E-UTRAN
terminals support E-UTRAN Sharing.
An E-UTRAN Sharing architecture allows different core network operators to connect to a shared radio access network.
The operators do not only share the radio network elements, but may also share the radio resources themselves. In
addition to this shared radio access network the operators may or may not have additional dedicated radio access
networks, like for example, 3G or 2G radio access networks. For E-UTRAN both Multi-Operator Core Network
(MOCN) configuration and Gateway Core Network (GWCN) configuration as defined in TS 23.251 [24] are supported
over the S1 reference point. E-UTRAN terminals shall support shared networks and hence, only functions for
"Supporting UEs" in TS 23.251 [24] applies for E-UTRAN Sharing.
E-UTRAN Radio Access Network Sharing functions is further described in TS 36.300 [5].
In networks that support network sharing as defined in TS 23.251 [24], for a UE in state ECM-CONNECTED, the
Handover Restriction List provided by the core-network to the radio access network is also used to inform the radio
access network about the Selected PLMN and equivalent PLMNs as defined in TS 36.413 [36].
3GPP
Release 15 52 3GPP TS 23.401 V15.10.0 (2019-12)
4.3.12 IMS Emergency Session Support
4.3.12.1 Introduction
Clause 4.3.12 IMS Emergency Session provides an overview about functionality for emergency bearer services in a
single clause. This overview applies to eCall Over IMS unless stated otherwise. The specific functionality is described
in the affected procedures and functions of this specification. For discrepancies between this overview clause and the
detailed procedure and function descriptions the latter take precedence.
Emergency bearer services are provided to support IMS emergency sessions. Emergency bearer services are
functionalities provided by the serving network when the network is configured to support emergency services.
Emergency bearer services are provided to normal attached or emergency attached UEs and depending on local
regulation, to UEs that are in limited service state. Receiving emergency services in limited service state does not
require a subscription. Depending on local regulation and an operator's policy, the MME may allow or reject an
emergency attach request for UEs in limited service state. Four different behaviours of emergency bearer support have
been identified as follows:
a. Valid UEs only. No limited service state UEs are supported in the network. Only UEs that have a valid
subscription, are authenticated and authorized for PS service in the attached location are allowed. UEs should be
attached to the network and then perform a PDN Connection Request when an IMS emergency session is
detected by the UE.
b. Only UEs that are authenticated are allowed. These UEs must have a valid IMSI. These UEs are
authenticated and may be in limited service state due to being in a location that they are restricted from service.
A UE that can not be authenticated will be rejected.
c. IMSI required, authentication optional. These UEs must have an IMSI. If authentication fails, the UE is
granted access and the unauthenticated IMSI retained in the network for recording purposes. The IMEI is used in
the network as the UE identifier. IMEI only UEs will be rejected (e.g., UICCless UEs).
d. All UEs are allowed. Along with authenticated UEs, this includes UEs with an IMSI that can not be
authenticated and UEs with only an IMEI. If an unauthenticated IMSI is provided by the UE, the unauthenticated
IMSI is retained in the network for recording purposes. The IMEI is used in the network to identify the UE.
To provide emergency bearer services, the MME is configured with MME Emergency Configuration Data that are
applied to all emergency bearer services that are established by an MME on UE request. The MME Emergency
Configuration Data contain the Emergency APN which is used to derive a PDN GW, or the MME Emergency
Configuration Data may also contain the statically configured PDN GW for the Emergency APN.
UEs that are in limited service state, as specified in TS 23.122 [10], initiate the Attach procedure with indicating that the
attach is to receive emergency services. Also UEs that had attached for normal services and do not have emergency
bearers established and are camped on a cell in limited service state (e.g. because of restricted Tracking Area or not
allowed CSG) shall initiate this Attach procedure, indicating that the attach is to receive emergency services. The
network supporting emergency services for UEs in limited service state provides emergency bearer services to these
UE, regardless whether the UE can be authenticated, has roaming or mobility restrictions or a valid subscription,
depending on local regulation. For emergency services other than eCall, the UEs in limited service state determine that
the cell supports emergency services over E-UTRAN from a broadcast indicator in AS. Emergency calls for eCall Over
IMS are only performed if the UE has a UICC.
A serving network shall provide an Access Stratum broadcast indication to UEs as to whether eCall Over IMS is
supported.
NOTE 1: The Access Stratum broadcast indicator is determined according to operators' preference and minimally
indicates that the PLMN, or all of the PLMNs in the case of network sharing, and at least one emergency
centre or PSAP to which an eCall Over IMS session can be routed, support eCall Over IMS.
A UE in limited service state determines that the cell supports eCall Over IMS using both the broadcast indicator for
support of emergency services over E-UTRAN and the broadcast indicator for eCall over IMS.
NOTE 2: The broadcast indicator for eCall Over IMS does not indicate whether UEs in limited service state are
supported, as such the broadcast indicator for support of emergency services over E-UTRAN that
indicates limited service state support needs to also be applied.
3GPP
Release 15 53 3GPP TS 23.401 V15.10.0 (2019-12)
For a UE that is Emergency Attached, if it is unauthenticated the EPS security context is not set up on UE.
UEs that camp normally on a cell, i.e. without any conditions that result in limited service state, initiate the normal
initial attach procedure if not already attached. Normal attached UEs initiate the UE Requested PDN Connectivity
procedure to receive emergency bearer services. The UEs that camp normally on a cell are informed that the PLMN
supports emergency bearer services over E-UTRAN from the Emergency Service Support indicator in the Attach and
TAU procedures. UEs that camp normally on a cell may also use the emergency attach procedure under conditions
specified in TS 24.301 [46], e.g. when the MM back-off timer is running.
NOTE 3: Failure of the normal initial attach may occur e.g. when the network rejects the request with a back-off
time.
NOTE 4: The establishment of the emergency bearer services may fail when the UE needs to perform a TAU prior
to the UE Requested PDN Connectivity procedure, i.e. the UE moved into a non-registered Tracking Area
with the MM back-off timer running in the UE.
NOTE 5: The Emergency Service Support indicator in the Attach and TAU procedures does not enable support for
eCall Over IMS.
For a UE that is Emergency Attached, normal PLMN selection principles apply after the end of the IMS emergency
session.
For emergency bearer services any EPC functions, procedures and capabilities are provided according to clause 4
except when specified differently in the following clauses.
For emergency bearer services, there is a risk of service disruption due to failed inter PLMN mobility attempts.
For emergency bearer services, handover from non-3GPP access to E-UTRAN access is supported as specified in
TS 23.402 [2] clause 4.5.7.2.10.
The UE shall set the RRC establishment cause or RRC resume cause to emergency as defined in TS 36.331 [37] when it
requests an RRC connection in relation to an emergency session. Specific situations that require setting the RRC
establishment cause or RRC resume cause to emergency are described in TS 24.301 [46].
Support for emergency bearer services is not available when the UE is using NB-IoT, i.e. the MME shall not indicate
support for emergency bearer services using the Emergency Service Support indicator in the Attach and TAU
procedures to a UE that accesses the network using a RAT Type equal to NB-IoT, and an NB-IoT cell shall not indicate
support for emergency services in any broadcast information in AS.
When a PLMN supports IMS and emergency bearer services, all MMEs in that PLMN shall have the same capability to
support emergency bearer services.
NOTE 6: Idle mode Signalling Reduction (ISR) is not supported by the network for UEs that only have bearers
related to emergency bearer service.
For emergency services other than eCall, a UE that is not in in limited service state, as specified in TS 23.122 [10]
determines from a NAS indicator whether additional emergency numbers/types received via WLAN from trusted
sources may be used for detecting emergency calls.
4.3.12.2 Architecture Reference Model for Emergency Services

According to clause 4.2, the non-roaming architectures (Figure 4.2.1-1 and Figure 4.2.1-2) and roaming architecture
with the visited operator's application function (Figure 4.2.2-3) apply for emergency services. The other roaming
architectures with services provided by the home network do not apply for emergency services.
4.3.12.3 Mobility and Access Restrictions for Emergency Services

When Emergency Services are supported and local regulation requires Emergency Sessions to be provided regardless of
mobility or access restrictions, the Mobility Restrictions in clause 4.3.5.7, should not be applied to UEs receiving
emergency services. When the E-RABs for emergency bearers are established, the ARP value for emergency bearer
services indicates the usage for emergency services to the E-UTRAN.
During handovers, the source E-UTRAN and source MME ignore any UE related restrictions during handover
evaluation when there are active emergency bearers. E-UTRAN shall not initiate handover to GERAN PS domain.
3GPP
Release 15 54 3GPP TS 23.401 V15.10.0 (2019-12)
During handover to a CSG cell, if the UE is not a CSG member of target CSG cell and has emergency bearer services,
the target eNodeB only accepts the emergency bearers and the target MME releases the non-emergency PDN
connections that were not accepted by the target eNodeB as specified in clause 5.10.3. Such UEs behave as emergency
attached.
During Tracking Area Update procedures, including a TAU as part of a handover, the target MME ignores any mobility
or access restrictions for UE with emergency bearer services where required by local regulation. Any non emergency
bearer services are deactivated, according to clause 5.10.3, by the target MME when not allowed by the subscription for
the target location. Such UEs behave as emergency attached. To allow the emergency attached UE to get access to
normal services after the emergency session has ended and when it has moved to a new area that is not stored by the UE
as a forbidden area, the UE may explicitly detach and reattach to normal services without waiting for the emergency
PDN connection deactivation by the PDN GW.
This functionality applies to all mobility procedures.
4.3.12.3a Reachability Management for UE in ECM-IDLE state

An emergency attached UE when its periodic TAU update timer expires shall not initiate a periodic TAU procedure but
enter EMM-DEREGISTERED state. For emergency attached UEs the MME runs a mobile reachable timer with a
similar value to the UE's periodic TAU timer. Any time after expiry of this timer the MME may change the EMM state
of an emergency attached UE to EMM-DEREGISTERED. The MME assigns the periodic TAU timer value to
emergency attached UE. This timer keeps the UE emergency attached after change to EMM-IDLE state to allow for a
subsequent emergency service without a need to emergency attach again.
4.3.12.4 PDN GW selection function (3GPP accesses) for Emergency Services

When a PDN GW is selected for IMS emergency services support, the PDN GW selection function described in
clause 4.3.8.1 for normal bearer services is applied to the Emergency APN or the MME selects the PDN GW directly
from the MME Emergency Configuration Data. If the PDN GW selection function described in clause 4.3.8.1 is used it
shall always derive a PDN GW in the visited PLMN, which guarantees that also the IP address is allocated by the
visited PLMN. In networks that support handover between E-UTRAN and HRPD accesses, the MME selects a PDN
GW that is statically configured in the MME Emergency Configuration Data. In networks that support handover
between E-UTRAN and WLAN accesses, when the UE has been authorized but has not been authenticated, the MME
selects the PDN GW that is statically configured in the MME Emergency Configuration Data. The PDN GW selection
does not depend on subscriber information in the HSS since emergency service support is a local, not subscribed
service. The MME Emergency Configuration Data contains the Emergency APN which is used to derive a PDN GW, or
the MME Emergency Configuration Data may also contain the statically configured PDN GW for the Emergency APN.
This functionality is used by the Attach procedure and by the UE Requested PDN Connectivity procedure, in both cases
when establishing emergency bearer services.
NOTE: It is assumed that the PDN GW that is statically configured in the MME Emergency Configuration Data
is the same as the PDN GW configured in WLAN and HRPD accesses.
4.3.12.5 QoS for Emergency Services

Where local regulation require supporting calls from an unauthorised caller, the MME may not have subscription data.
Additionally, the local network may want to provide IMS emergency services support differently than what is allowed
by a UE subscription. Therefore, the initial QoS values used for establishing emergency bearer services are configured
in the MME in the MME Emergency Configuration Data.
NOTE: For IMS emergency services prior to this Release of this specification, dynamic PCC support was not
required in the specifications. In such cases, the PDN GW sets the ARP value that is reserved for
emergency services, which the PDN GW bases on the usage of the Emergency APN.
This functionality is used by the Attach procedure and by the UE Requested PDN Connectivity procedure, in both cases
when establishing emergency bearer services.
4.3.12.6 PCC for Emergency Services

Dynamic PCC is used for UEs establishing emergency service, the procedures are as described in TS 23.203 [6]. When
establishing emergency bearer services with a PDN GW, according to clause 4.7.5, the PCRF provides the PDN GW
3GPP
Release 15 55 3GPP TS 23.401 V15.10.0 (2019-12)
with the QoS parameters, including an ARP value reserved for the emergency bearers to prioritize the bearers when
performing admission control. Dynamic PCC shall be used to manage IMS emergency sessions when an operator
allows IMS emergency sessions.
NOTE: For IMS emergency services prior to this Release of this specification, dynamic PCC support was not
required in the specifications. According to clause 4.7.5, when solely using voice/GTT, local
configuration of static policy functions is also allowed prior to this Release of this specification and is not
subject to standardization.
The PCRF ensures that the emergency PDN connection is used only for IMS emergency sessions. The PCRF rejects an
IMS session established via the emergency PDN connection if the AF (i.e. P-CSCF) does not provide an emergency
indication to the PCRF.
4.3.12.7 Load re-balancing between MMEs for Emergency Services

As per load re-balancing procedures in clause 4.3.7.3, the MME is allowed to off-load ECM-CONNECTED mode UEs
by initiating S1 Release procedures. When a UE is in ECM-CONNECTED mode with an active emergency bearer
service, the MME should not release the UE for load re-balancing. The MME should wait until the UE initiates a TAU
or becomes inactive. The MME may release the UE under critical conditions such as the need to perform an MME node
restart.
4.3.12.8 IP Address Allocation

Emergency bearer service is provided by the serving PLMN. The UE and PLMN must have compatible IP address
versions in order for the UE to obtain a local emergency PDN connection. IP address allocation in the serving PLMN is
provided per clause 5.3.1 with the exception that the PDN GW associated with the emergency APN shall support PDN
type IPv4 and PDN type IPv6.
4.3.12.9 Handling of PDN Connections for Emergency Bearer Services

The default and dedicated EPS bearers of a PDN Connection associated with the emergency APN shall be dedicated for
IMS emergency sessions and shall not allow any other type of traffic. The emergency bearer contexts shall not be
changed to non-emergency bearer contexts and vice versa. The PDN GW shall block any traffic that is not from or to
addresses of network entities (e.g. P-CSCF) providing IMS emergency service. Dynamic PCC shall be deployed in
order to support IMS emergency sessions, the procedures are as described in TS 23.203 [6]. If there is already an
emergency PDN GW connection, the UE shall not request another emergency PDN Connection. The MME shall reject
any additional emergency PDN Connection requests. The UE shall not request any bearer resource modification for the
emergency PDN connection. The PDN GW shall reject any UE requested bearer resource modification that is for the
emergency PDN Connection. The ARP reserved for emergency bearer service shall only be assigned to EPS bearers
associated with an emergency PDN Connection.
4.3.12.10 ISR function for Emergency Bearer Services

When UE has only emergency bearer service, ISR does not apply.
4.3.12.11 Support of eCall Only Mode

For service requirements for eCall only mode, refer to TS 22.101 [80].
A UE configured for eCall Only Mode shall remain in EMM-DEREGISTERED state, shall camp on a network cell
when available but shall refrain from any Mobility Management or other signalling with the network. The UE may
instigate Mobility Management and Connection Management procedures in order to establish, maintain and release an
eCall Over IMS session or a session to any non-emergency MSISDN(s) or URI(s) configured in the UICC for test
and/or terminal reconfiguration services. Following the release of either session, the UE starts a timer whose value
depends on the type of session (i.e. whether eCall or a session to a non-emergency MSISDN or URI for
test/reconfiguration). While the timer is running, the UE shall perform normal Mobility Management procedures and is
permitted to respond to paging to accept and establish an incoming session (e.g. from an emergency centre, PSAP or
HPLMN operator). When the timer expires, the UE shall perform a UE-initiated detach procedure if still attached and
enter EMM-DEREGISTERED state.
3GPP
Release 15 56 3GPP TS 23.401 V15.10.0 (2019-12)
NOTE 1: An HPLMN operator can change the eCall Only Mode configuration state of a UE in the UICC. An
HPLMN operator can also instead add, modify or remove a non-emergency MSISDN or URI in the UICC
for test and/or terminal reconfiguration services. This can occur following a UE call to a non-emergency
MSISDN or URI configured for reconfiguration. When the eCall Only Mode configuration is removed,
the UE operates as a normal UE that can support eCall over IMS.
NOTE 2: A test call and a reconfiguration call can be seen as normal (non-emergency) call by a serving PLMN and
normal charging rules can apply depending on operator policy.
NOTE 3: An MSISDN configured in the UICC for test and/or terminal reconfiguration services for eCall Over IMS
can differ from an MSISDN configured in the UICC for test services for eCall over the CS domain.
When attaching to EPS for E-UTRAN access, a UE configured for eCall Only Mode may indicate support for radio
capabilities for IRAT Handover (for UTRAN) or SRVCC Handover (for GERAN), but shall not indicate support for
IMS Voice over RATs other than E-UTRAN.
NOTE 4: Access to the PS domain for a UE configured for eCall Only Mode is only supported by E-UTRAN in
this version of the specification.
4.3.13 Closed Subscriber Group functions

Closed Subscriber Group identifies a group of subscribers who are permitted to access one or more CSG cells of the
PLMN as a member of the CSG for a HeNB. The following CSG related functions are defined:
- CSG subscription handling function stores and updates the user's CSG subscription data at the UE and the
network.
- For closed mode, CSG access control function ensures a UE has valid subscription at a CSG where it performs
an access.
- Admission and rate control function is used to provide different admission and rate control for CSG and non-
CSG members for a hybrid CSG cell.
- CSG charging function enables per CSG charging for a subscriber consuming network services via a CSG cell or
a hybrid cell.
- CSG Paging Optimisation function is optionally used to filter paging messages as described in clause 5.3.4.3.
- VPLMN Autonomous CSG roaming function is optionally supported whereby a VPLMN, if allowed by the
HPLMN, stores and manages VPLMN specific CSG subscription information for roaming UEs without
interaction with the HSS.
- CSG membership verification without updating the User CSG Information in the Core Network in case of Dual
Connectivity when the Secondary eNB is a hybrid access eNB.
4.3.14 Location Service functions

LCS procedures are described in the LCS stage 2 specification, see TS 23.271 [57].
In addition, in the Detach and Bearer Deactivation procedures, the MME shall inform the S-GW of the last known
location of the UE, and shall provide information to enable the determination of the time at which the UE was in that
location. The S-GW shall (if necessary taking into account information from the SGSN) inform the PDN GW of the last
known location of the UE, and shall provide information to enable the determination of the time at which the UE was in
that location. If requested by the PCRF the PDN GW shall indicate this information to the PCRF as defined in
TS 23.203 [6]. The information can also be made available on the SGi interface as specified in TS 29.061 [38] and on
the CDRs at network elements such as the S-GW and PDN GW as specified in TS 32.251 [44].
4.3.15 Selected IP Traffic Offload (SIPTO) function

The SIPTO function enables an operator to offload certain types of traffic at a network node close to that UE's point of
attachment to the access network.
3GPP
Release 15 57 3GPP TS 23.401 V15.10.0 (2019-12)
SIPTO above RAN can be achieved by selecting a set of GWs (S-GW and P-GW) that is geographically/topologically
close to a UE's point of attachment.
SIPTO above RAN corresponds to a traffic offload through a P-GW located in the mobile operator's core network.
SIPTO applies to both the non-roaming case and, provided appropriate roaming agreements are in place between the
operators, to the roaming case.
Offload of traffic for a UE is available for UTRAN and E-UTRAN accesses only. When the UE enters to UTRAN/E-
UTRAN from another type of access network (e.g., from GERAN), it is the responsibility of the new SGSN/MME to
decide whether to perform deactivation with reactivation request for a given PDN connection, depending on SIPTO
permissions for the relevant APN.
Realization for SIPTO above RAN relies on the same architecture models and principles as for local breakout described
in clause 4.2.
In order to select a set of appropriate GW (S-GW and P-GW) based on geographical/topological proximity to UE, the
GW selection function specified in TS 29.303 [61] uses the UE's current location information.
In order for the operator to allow/prohibit SIPTO on per user and per APN basis, subscription data in the HSS is
configured to indicate to the MME if offload is allowed or prohibited. If the SIPTO permissions information from the
HSS conflicts with MME's configuration for that UE, then SIPTO is not used.
If HSS indicates VPLMN address not allowed, then VPLMN (i.e. MME) shall not provide SIPTO.
In the absence of any SIPTO permissions indication from the HSS the VPLMN (i.e MME) shall not provide SIPTO.
The MME may be configured on a per APN basis as to whether or not to use SIPTO (e.g. to handle the case where the
HSS is not configured with SIPTO information for the UE).
For SIPTO above RAN, as a result of UE mobility (e.g. detected by the MME at TAU or SGSN at RAU or movement
from GERAN), the target MME may wish to redirect a PDN connection towards a different GW that is more
appropriate for the UE's current location, e.g. MME may know whether the UE's new location is served by the same
GW as the old one. When the MME decides upon the need for GW relocation, the MME deactivates the impacted PDN
connections indicating "reactivation requested" as specified in clause 5.10.3. If all of the PDN connections for the UE
need to be relocated, the MME may initiate the "explicit detach with reattach required" procedure as specified in
clause 5.3.8.3.
NOTE: If either of the above procedures for GW relocation are initiated while the UE has active applications, it
may cause disruption of services that are affected if the IP address changes.
4.3.15a Selected IP Traffic Offload (SIPTO) at the Local Network
4.3.15a.1 General
The SIPTO at the Local Network function enables an IP capable UE connected via a (H)eNB to access a defined IP
network (e.g. the Internet) without the user plane traversing the mobile operator's network.
The subscription data in the HSS are configured per user and per APN to indicate to the MME if offload at the local
network is allowed or not.
SIPTO at the Local Network can be achieved by selecting a L-GW function collocated with the (H)eNB or selecting
stand-alone GWs (with S-GW and L-GW collocated) residing in the Local Network. In both cases the selected IP traffic
is offloaded via the Local Network.
Specific to the HeNB subsystem, the applicability of SIPTO at the Local Network does not depend on CSG membership
and the feature can be applied to any UE, as long as the UE is allowed to access the cell.
For this release of the specification, no interface between the L-GW and the PCRF is specified and there is no support
for dedicated bearers on the PDN connection used for SIPTO at the Local Network. The Local GW (L-GW) shall reject
any UE requested bearer resource modification.
3GPP
Release 15 58 3GPP TS 23.401 V15.10.0 (2019-12)
For this release of the specification, SIPTO at the Local Network is intended for offloading Internet traffic only, thus the
L-GW does not provide APN specific connectivity. Therefore if the subscription data in the HSS indicate that offload at
the Local Network is allowed, this implies that the related APN is typically used for providing Internet connectivity.
If the MME detects a change in SIPTO permissions in the subscription data for a given subscriber for a given APN and
the subscriber has already established a SIPTO at the local network PDN connection to that APN, the MME shall
release the SIPTO at the Local Network PDN connection for that APN with "reactivation requested" cause as specified
in clause 5.10.3.
NOTE: In this release of the specification it is assumed that the target S-GW selected during the Handover also
has connectivity to the L-GW.
4.3.15a.2 SIPTO at the Local Network with stand-alone GW (with S-GW and L-GW
collocated) function
SIPTO at the Local Network is achieved using a stand-alone GW (with S-GW and L-GW collocated) residing in the
Local Network.
A (H)eNB supporting SIPTO at the Local Network with the stand-alone GW includes the Local Home Network ID to
the MME in every INITIAL UE MESSAGE, every UPLINK NAS TRANSPORT control message, HANDOVER
NOTIFY and PATH SWITCH REQUEST messages.
If a SIPTO PDN connection is initiated as an additional subsequent PDN connection, the MME should check if the
S-GW is optimal for the user's current location. If it is not, and if the network supports S-GW relocation without being
triggered by a mobility event, the MME may decide to perform an MME triggered Serving GW relocation according to
clause 5.10.4, when possible (e.g. no other restrictions apply).
For SIPTO at the Local Network with a stand-alone GW, the location of the Serving GW may be determined based on
the operator policy and user's profile regarding support of SIPTO at Local Network so that:
- At attachment to the (H)eNB, a local S-GW can always be selected independent of whether a SIPTO at the Local
Network PDN connection is established or not. If mobility is performed to the macro network without having a
SIPTO connection, a S-GW relocation can be performed as specified via existing mobility procedures with S-
GW relocation.
- At attachment to a (H)eNB, a macro S-GW may be allocated for PDN connection in the operator's network. If a
new PDN connection is requested by the UE that requires that a local S-GW is selected to provide for SIPTO at
the Local Network, S-GW relocation from the macro S-GW to the local S-GW shall be performed as specified in
clause 5.10.4.
As IP data session continuity for SIPTO at the Local Network PDN connection is not supported in this release of the
specification, subsequent to handover completion the (target) MME should disconnect the SIPTO at the Local Network
PDN connection with "reactivation requested" cause as specified in clause 5.10.3, unless the Local Home Network ID is
not changed. The IP data session should be maintained if the Local Home Network ID is not changed. If the UE has no
other PDN connection and the Local Home Network ID is changed, the (target) MME initiates "explicit detach with
reattach required" procedure according to clause 5.3.8.3.
Upon completion of Tracking Area Update procedure, the (new) MME shall trigger the re-establishment of the SIPTO
at the Local Network PDN connection when it detects that the UE has moved away from the (H)eNB and to a (H)eNB
with different Local Home Network ID, as specified in clause 5.3.3 and clause 5.3.4.
NOTE: It is expected that all MMEs/SGSNs in a PLMN have support for SIPTO at the Local Network where the
operator deploys this feature, in order to support mobility procedures. For a mobility event where target
MME/SGSN does not support SIPTO at the Local Network, the handling of PDN deactivation for SIPTO
at Local Network PDN connection is not specified.
4.3.15a.3 SIPTO at the Local Network with L-GW function collocated with the (H)eNB
SIPTO at the Local Network is achieved using a Local GW (L-GW) function collocated with the (H)eNB and using the
same procedures as described in clause 4.3.15, with the following additions:
3GPP
Release 15 59 3GPP TS 23.401 V15.10.0 (2019-12)
- The (H)eNB supporting the SIPTO at the Local Network function includes the Local GW address to the MME in
every INITIAL UE MESSAGE and every UPLINK NAS TRANSPORT control message specified in
TS 36.413 [36].
- The PDN GW selection function uses the L-GW address proposed by (H)eNB in the S1-AP message, instead of
DNS interrogation.
- Specific to the HeNB subsystem, the Local GW information for SIPTO at the Local Network is signalled on S1
separately from the Local GW information for LIPA. The L-GW shall be able to discriminate between PDN
connection for SIPTO at the Local Network and for LIPA.
NOTE 1: The protocol option (i.e. GTP or PMIP) supported on the S5 interface between Local GW and S-GW is
configured on the MME.
The direct user plane path between the (H)eNB and the collocated L-GW is enabled with a SIPTO Correlation ID
parameter that is associated with the default EPS bearer on the PDN connection used for SIPTO at the Local Network.
Upon establishment of the default EPS bearer the MME sets the SIPTO Correlation ID equal to the PDN GW TEID
(GTP-based S5) or the PDN GW GRE key (PMIP-based S5). The SIPTO Correlation ID is then signalled by the MME
to the (H)eNB as part of E-RAB establishment and is stored in the E-RAB context in the (H)eNB. The SIPTO
Correlation ID is used in the (H)eNB for matching the radio bearers with the direct user plane path connections from the
collocated L-GW for SIPTO at local network PDN connection.
As IP data session continuity for the SIPTO at the Local Network PDN connection is not supported in this release of the
specification, the SIPTO at the Local Network PDN connection shall be re-established when the UE moves away from
(H)eNB. During the handover procedure, when the source (H)eNB releases its resources related to the UE, the (H)eNB
shall request using intra-node signalling the collocated L-GW to re-establish the SIPTO at the Local Network PDN
connection. The L-GW starts a timer. When the timer expires, the L-GW shall initiate the release of the SIPTO at the
Local Network PDN connection using the PDN GW initiated bearer deactivation procedure according to clause 5.4.4.1
with the "reactivation requested" cause value.
4.3.16 Local IP Access (LIPA) function

The LIPA function enables an IP capable UE connected via a HeNB to access other IP capable entities in the same
residential/enterprise IP network without the user plane traversing the mobile operator's network except HeNB
subsystem.
The Local IP Access is achieved using a Local GW (L-GW) colocated with the HeNB.
LIPA is established by the UE requesting a new PDN connection to an APN for which LIPA is permitted, and the
network selecting the Local GW associated with the HeNB and enabling a direct user plane path between the Local GW
and the HeNB. The HeNB supporting the LIPA function includes the Local GW address to the MME in every INITIAL
UE MESSAGE and every UPLINK NAS TRANSPORT control message as specified in TS 36.413 [36].
NOTE 1: The protocol option (i.e. GTP or PMIP) supported on the S5 interface between Local GW and S-GW is
configured on the MME.
For this release of the specification no interface between the L-GW and the PCRF is specified and there is no support
for Dedicated bearers on the PDN connection used for Local IP Access. The Local GW (L-GW) shall reject any UE
requested bearer resource modification.
The direct user plane path between the HeNB and the collocated L-GW is enabled with a Correlation ID parameter that
is associated with the default EPS bearer on a PDN connection used for Local IP Access. Upon establishment of the
default EPS bearer the MME sets the Correlation ID equal to the PDN GW TEID (GTP-based S5) or the PDN GW
GRE key (PMIP-based S5). The Correlation ID is then signalled by the MME to the HeNB as part of E-RAB
establishment and is stored in the E-RAB context in the HeNB. The Correlation ID is used in the HeNB for matching
the radio bearers with the direct user plane path connections from the collocated L-GW.
If the UE is roaming and if the HSS indicates LIPA roaming allowed for this UE in this VPLMN, then the VPLMN (i.e.
MME) may provide LIPA for this UE. Furthermore, in the absence of any LIPA information for the requested APN
from the HSS, the VPLMN (i.e MME) shall not provide LIPA. The VPLMN address allowed flag is not considered
when establishing a LIPA PDN connection.
3GPP
Release 15 60 3GPP TS 23.401 V15.10.0 (2019-12)
LIPA is supported for APNs that are valid only when the UE is connected to a specific CSG. LIPA is also supported for
"conditional" APNs that can be authorized to LIPA service when the UE is using specific CSG. APNs marked as "LIPA
prohibited" or without a LIPA permission indication cannot be used for LIPA.
MME shall release a LIPA PDN connection to an APN if it detects that the UE's LIPA CSG authorization data for this
APN has changed and the LIPA PDN connection is no longer allowed in the current cell.
As mobility of the LIPA PDN connection is not supported in this release of the specification, the LIPA PDN connection
shall be released when the UE moves away from H(e)NB. Before starting the handover procedure towards the target
RAN, the H(e)NB shall request using an intra-node signalling the collocated L-GW to release the LIPA PDN
connection. The H(e)NB determines that the UE has a LIPA PDN connection from the presence of the Correlation ID in
the UE (E-)RAB context. The L-GW shall then initiate and complete the release of the LIPA PDN connection using the
PDN GW initiated bearer deactivation procedure as per clause 5.4.4.1 or GGSN initiated PDP context deactivation
procedure as specified in TS 23.060 [7]. The H(e)NB shall not proceed with the handover preparation procedure
towards the target RAN until the UE's (E-)RAB context is clear for the Correlation ID.
At the handover, the source MME checks whether the LIPA PDN connection has been released. If it has not been
released:
- and the handover is the S1-based handover or the Inter-RAT handover, the source MME shall reject the
handover.
- and the handover is X2-based handover, the MME shall send a Path Switch Request Failure message (see more
detail in TS 36.413 [36]) to the target HeNB. The MME performs explicit detach of the UE as described in the
MME initiated detach procedure of clause 5.3.8.3.
NOTE 2: The direct signalling (implementation dependent) from the H(e)NB to the L-GW is only possible since
mobility of the LIPA PDN connection is not supported in this release.
During idle state mobility events, the MME/SGSN shall deactivate the LIPA PDN connection when it detects that the
UE has moved away from the HeNB.
4.3.17 Support for Machine Type Communications (MTC)
4.3.17.1 General
This clause provides an overview about functionality for Machine Type Communications according to service
requirements described in TS 22.368 [66]. The specific functionality is described in the affected procedures and features
of this and other specifications. For discrepancies between this overview clause and the detailed procedure and function
descriptions, the latter take precedence.
MTC functionality is provided by the visited and home networks when the networks are configured to support machine
type communication. It applies to both the non-roaming case and the roaming case and some functionality may be
dependent upon the existence of appropriate roaming agreements between the operators.
Some of the MTC functions are controlled by subscriber data. Other MTC functions are based on indicators sent by the
UE to the network. MTC functionality is performed by UEs that are configured to support different options as described
in clause 4.3.17.4.
Though motivated by scenarios and use cases defined in TS 22.368 [66], the functions added to support MTC have
general applicability and are in no way constrained to any specific scenario or use case except where explicitly stated.
4.3.17.2 Overview of protection from Potential MTC Related Overload

The number of MTC devices may be several orders of magnitude greater than "traditional" devices. Many (but not all)
MTC devices will be relatively stationary and/or generate low volumes of traffic. However, these UEs have the
capability to generate normal quantities of signalling. As normal signalling from large numbers of UEs may cause
overload independently whether the UE is used for MTC or not, generic functionality for overload and congestion
control is required.
The total signalling from large numbers of UEs is a concern in at least two situations:
- when an application (running in many UEs) requests many UEs to do "something" at the same time; and/or
3GPP
Release 15 61 3GPP TS 23.401 V15.10.0 (2019-12)
- when many UEs are roamers and their serving network fails, then they can all move onto the local competing
networks, and potentially overload the not (yet) failed network(s).
To counter these potential problems, the following standardised indications and mechanisms are provided in a generic
manner. These permit node specific features to be developed to protect the networks.
a) Where applicable, UEs can be configured for enhancements as described in subsequent bullets Post-
manufacturing configuration can be performed remotely as described in clause 4.3.17.4.
b) For mobile originated services, UEs configured for low access priority provide the E-UTRAN with information
indicating that the RRC connection establishment request has low access priority (see clause 4.3.17.4).
Clause 4.3.17.4 describes when low access priority is not applicable.
c) RRC signalling has the capability of providing 'extended wait timers' when rejecting messages from UEs. These
'extended wait timers' are only used by UEs that access the network with low access priority.
d) The MME can initiate rejection of RRC connection establishments in the E-UTRAN for UEs that access the
network with low access priority as described in clause 4.3.7.4.1. In addition, MME signalling or O&M can
trigger E-UTRAN to initiate Extended Access Barring. These mechanisms are further described in
clause 4.3.7.4.1.
e) Overload messages from the MME to E-UTRAN are extended to aid the RAN in performing the functionality in
bullets b, c and d above.
f) UEs configured with a long minimum periodic PLMN search time limit (see TS 24.368 [69]) have an increased
minimum time in between their searches for more preferred PLMNs.
NOTE 1: Following the failure of a more preferred PLMN, UEs configured as above might change to other local
competing networks. Expiry of this search timer will lead to the UE re-attempting to access the failed
network, and then, if that network has not yet recovered, reaccessing one of the local competing
networks. Use of a too short timer for the more preferred PLMN search can both prevent the failed
network from recovering, and, impose more load on the local competing networks.
g) At PLMN change, UEs configured to perform Attach with IMSI at PLMN change (see TS 24.368 [69]) do this
rather than a TA update with GUTI (thus avoiding the need to reject the TA update, and to request the IMSI
following the subsequent Attach with GUTI).
NOTE 2: In the case of a network failure, this reduces the message processing load on a local competing network
and hence makes that network more likely to survive the failure of the other network.
h) For mobile originated services, UEs configured for low access priority (see TS 24.368 [69]) provide a low access
priority indication to the MME in NAS signalling that permit the MME to undertake protective measures (e.g. to
permit the MME to immediately command the UE to move to a state where it does not need to generate further
signalling messages and/or does not reselect PLMNs), as described in clause 4.3.7.4.1. Clause 4.3.17.4 describes
when low access priority is not applicable.
i) Using Periodic TAU timer value sent by the HSS and/or UE provided low access priority indication (bullet h
above), the MME can allocate a long periodic TAU timer value to the UE. A long periodic TAU timer is likely
to slow down the rate at which a UE detects a network failure and thus it slows down the rate of movement of
UEs from a failed network to other local competing networks (see clause 4.3.17.3).
j) Mechanisms for the MME and P-GW to detect congestion associated with a particular APN (see clauses
4.3.7.4.2 and 4.3.7.5).
k) The addition of 'back off timers' to EMM and ESM signalling messages (e.g. to rejection messages). These
include some time randomisation to guard against a repeat of a load peak. The MME should be able to apply this
behaviour on a per-APN basis. as described in clause 4.3.7.4.2
l) Signalling that permits the P-GW to request the MME to generate the above ESM signalling with 'back off
timers' (see clause 4.3.7.5).
m) An MME overload control mechanism to selectively limit the number of Downlink Data Notification requests
the S-GW sends to the MME for downlink low priority traffic received for UEs in idle mode (see
clause 4.3.7.4.1a).
3GPP
Release 15 62 3GPP TS 23.401 V15.10.0 (2019-12)
n) UE configured for specific handling of the invalid USIM state, the "forbidden PLMN list", the "forbidden
PLMNs for attach in S1mode list" and the "forbidden PLMNs for GPRS service list" remembers that the USIM
is invalid and keeps the PLMN forbidden lists even if the UE is switched off and then switched on.
o) When the UE has an activated PDN connection without low access priority or the UE is requested to establish
such a PDN connection and the UE is configured with a permission for overriding low access priority the UE
doesn't provide a low access priority indication to the MME in NAS MM signalling and also not to the RAN in
the RRC requests. In the NAS request for activating a PDN connection this UE always indicates what the upper
layers requested, i.e. the UE indicates low access priority in that NAS request unless the upper layers request
activation of a PDN connection without low access priority.
p) When the UE has an activated PDN connection that is without low access priority or the UE is requested to
activate such a PDN connection and the UE is configured with a permission for overriding Extended Access
Barring, then the UE ignores any Extended Access Barring (if it is activated in the network) as defined in
TS 22.011 [67].
NOTE 3: It is assumed that the mechanisms described in this entire clause are designed by Stage 3 in a manner that
allows extensibility and forward compatibility.
q) The eNodeB may use the low access priority indication provided by the UE to steer UEs configured for low
access priority to specific MMEs.
4.3.17.3 Optimising periodic TAU Signalling

To reduce network load from periodic TAU signalling and to increase the time until the UE detects a potential need for
changing the RAT or PLMN (e.g. due to network problems) the longer values of the periodic TAU timer and Mobile
Reachable timer shall be supported.
A long periodic RAU/TAU timer value may be locally configured at MME or may be stored as part of the subscription
data in HSS. During Attach and TAU procedures the MME allocates the periodic RAU/TAU timer value as periodic
TAU timer to the UE based on VPLMN operator policy, low access priority indication from the UE, periodic
RAU/TAU timer value requested by UE and subscription information received from the HSS.
If MME receives a subscribed periodic RAU/TAU timer value from the HSS it allocates the subscribed value to the UE
as periodic TAU timer. A visited PLMN MME may use subscribed periodic RAU/TAU timer value, if available, as an
indication to decide for allocating a locally configured periodic RAU/TAU timer value to the UE.
If no subscribed periodic RAU/TAU timer value is received from the HSS, the MME should:
- if the periodic RAU/TAU timer value requested by UE is within the boundaries of the VPLMN operator policy,
allocate the value requested by the UE;
- if the periodic RAU/TAU timer value requested by UE is higher than allowed per the VPLMN operator policy,
allocate the highest allowed value per the VPLMN operator policy;
- if the periodic RAU/TAU timer value requested by UE is lower than allowed per the VPLMN operator policy,
allocate the lowest allowed value per the VPLMN operator policy.
4.3.17.4 UE configuration and usage of indicators

A subscriber can by agreement with its operator be required to use UEs that are configured (see TS 24.368 [69]) to
support one or more of the following options:
- UE configured for low access priority; and/or
- UE configured with a permission for overriding low access priority, which is only applicable for a UE that is
also configured for low access priority; and/or
- UE configured to perform Attach with IMSI at PLMN change; and/or
- UE configured with a long minimum periodic PLMN search time limit; and/or
- UE configured for specific handling of the invalid USIM state, the "forbidden PLMN list", the "forbidden
PLMNs for attach in S1mode list" and the "forbidden PLMNs for GPRS service list"; and/or
3GPP
Release 15 63 3GPP TS 23.401 V15.10.0 (2019-12)
- UE configured for Extended Access Barring; and/or
- UE configured with a permission for overriding Extended Access Barring, which is only applicable for a UE that
is also configured for Extended Access Barring.
NOTE 1: When a UE is accessing the network with low access priority, then the UE may be subject for longer
backoff timers at overload and consequently need to be designed to be tolerant to delays when accessing
the network.
UEs can be configured for one or more of the above options with the following restrictions:
- in this Release of the specification, a UE that is configured for low access priority shall also be configured for
Extended Access Barring; and
- in this Release of the specification, a UE that is configured for Extended Access Barring shall be configured for
low access priority.
- in this Release of the specification, a UE that is configured for overriding low access priority shall also be
configured for overriding Extended Access Barring; and
- in this Release of the specification, a UE that is configured for overriding Extended Access Barring shall also be
configured for overriding low access priority.
UEs can be configured for one or more of the above options. Post-manufacturing configuration of these options in the
UE can be performed only by OMA DM or (U)SIM OTA procedures. UEs capable of the above options should support
configuration of these options by both OMA DM and (U)SIM OTA procedures.
A UE configured for low access priority shall transmit the low access priority indicator to the MME during the
appropriate NAS signalling procedures and transmit the corresponding low access priority to the E-UTRAN during
RRC connection establishment procedures.
NOTE 2: The low access priority indicator in NAS signalling and the corresponding low access priority for RRC
connection establishment are used by the network to decide whether to accept the NAS request or the
setup of the RRC connection respectively.
Low access priority shall not be applicable in the following situations:
- for all procedures related to an emergency PDN connection; used for IMS Emergency sessions that are to be
prioritized as per the requirements for IMS Emergency session procedures (see clause 4.3.12). When an
emergency PDN connection gets established, the MME may, based on MME configuration, initiate the
deactivation of any non-emergency PDN connection using the MME requested PDN disconnection procedure
described in clause 5.10.3;
- for all procedures when preferential access to the network is provided to the UE by the Access Class 11-15
mechanism according to TS 36.331 [37] and TS 22.011 [67] e.g. for Multimedia Priority Services as described in
clause 4.3.18;
NOTE 3: The configuration of a UE for low access priority and Access Class 11-15 are configured independently
of each other. However, the home operator can take care to prevent a subscription for Access Class 11-15
from being used in a UE configured for low access priority.
- for RRC connection establishment procedures when responding to paging;
- for a UE configured with a permission for overriding low access priority under conditions described by bullet o
in clause 4.3.17.2; or
- other specific situations described in TS 24.301 [46].
If the NAS session management request message used to establish a new PDN connection contains a low access priority
indication, the MME shall forward the low access priority indication in the Create Session Request message to the S-
GW/P-GW. The low priority indication gets associated with a PDN connection when it is established and it shall not
change until the PDN connection is deactivated.
The low access priority indication may be included in charging records by the visited and home networks. In order to
permit the S-GW to include the low access priority indicator in the charging records, the low access priority indicator
3GPP
Release 15 64 3GPP TS 23.401 V15.10.0 (2019-12)
should be stored in the MME EPS Bearer contexts and should be passed as part of these contexts to other SGSN/MME
or S-GW nodes in mobility management procedures.
NOTE 4: In this release there is no other usage of storing the low access priority indicator in EPS Bearer contexts
other than for the purpose to include it in charging records. Particularly, the low access priority indicator
in EPS Bearer contexts is not used by the network to make overload control decisions.
A network node may invoke one or more of the following mechanisms based on the indicators received in signalling
from UEs or forwarded by other network nodes:
- based on the low access priority indicator in NAS request messages, bullets e, h, i, k and l as defined in
clause 4.3.17.2; and/or
- based on the low access priority for RRC connection establishment, bullets b, c and q as defined in
clause 4.3.17.2.
A UE shall invoke one or more of the following mechanisms based on the configuration and capabilities of the UE:
- when UE is configured with a long minimum periodic PLMN search time limit, the UE invokes actions as
described in bullet f in clause 4.3.17.2; and/or
- when UE is configured to perform Attach with IMSI at PLMN change, the UE invokes actions as described in
bullet g in clause 4.3.17.2; and/or
- when a UE is configured for low access priority, the UE invokes actions as described in bullets b and h in
- when UE is configured for specific handling of the invalid USIM state, the "forbidden PLMN list", the
"forbidden PLMNs for attach in S1mode list" and the "forbidden PLMNs for GPRS service list", the UE invokes
actions as defined in bullet n in clause 4.3.17.2; and/or
- when UE is configured for Extended Access Barring, the UE invokes actions as defined in bullet d in
- when a UE is configured with a permission for overriding low access priority and configured with a permission
for overriding Extended Access Barring, the UE invokes actions as described in bullets o) and p) in
clause 4.3.17.2.
4.3.17.5 Void
4.3.17.6 Support of UEs configured for low access priority, Extended Access Barring
and permission for override
The feature is specified in TS 23.060 [7] clause 5.3.13.6.
4.3.17.7 High latency communication

Functions for High latency communication may be used to handle mobile terminated (MT) communication with UEs
being unreachable while using power saving functions e.g. UE Power Saving Mode (see clause 4.3.22) or extended idle
mode DRX (see clause 5.13a) depending on operator configuration. "High latency" refers to the initial response time
before normal exchange of packets is established. That is, the time it takes before a UE has woken up from its power
saving state and responded to the initial downlink packet(s). The feature is described in TS 23.682 [74].
The High latency communication includes invoking extended buffering of MT data at the Serving GW when the UE is
in a power saving state and not reachable. The handling is specified in the Network Triggered Service Request
procedure, clause 5.3.4.3. Establishing the user plane for delivering the buffered data when the UE contacts the MME or
SGSN by signalling shall be done in the Tracking Area Update and Routing Area Update procedures. The MME/SGSN
uses its parameter DL Data Buffer Expiration Time in the MM context information to remember if there is buffered DL
data to be delivered when the UE becomes reachable. When set, the DL Data Buffer Expiration Time shall be cleared at
any user plane setup to the RAN, i.e. buffered DL data can been delivered. At TAU/RAU procedures with MME/SGSN
change, the old MME/SGSN shall indicate in the context response to the new MME/SGSN that buffered DL data is
3GPP
Release 15 65 3GPP TS 23.401 V15.10.0 (2019-12)
waiting and hence the new MME/SGSN shall establish the user plane for delivery of the buffered DL data. When the
DL Data Buffer Expiration Time has expired, the MME/SGSN considers no DL data to be buffered and no indications
of Buffered DL Data Waiting are sent during context transfers at TAU procedures. At TAU/RAU procedures with
Serving GW change, the buffered DL data is forwarded to the new Serving GW or Gn/Gp-SGSN.
For Control Plane CIoT EPS Optimisation, the High latency communication includes invoking the buffering of MT data
at the Serving GW or the MME as specified in Mobile Terminated Data Transport in Control Plane CIoT EPS
Optimisation with P-GW connectivity, clause 5.3.4B.3. When the UE contacts MME, MME delivers the buffered data
using NAS PDUs. If MT data is buffered in MME, at TAU procedures with MME change the buffered data in the old
MME is discarded.
The High latency communication also includes sending event notifications to application servers that have requested
"UE Reachability" or "Availability after DDN failure" monitoring events. Event notifications are sent when a UE
becomes reachable, for example as part of the Attach Procedure, TAU/RAU procedures and the UE triggered Service
Request procedure.
When "UE Reachability" moniorting is requested for UE's that are using extended idle mode DRX, an event notification
is sent to the application server when the UE is about to become reachable for paging.
If the MME is aware that some signalling or data is pending in the network for an UE that is known as being
unreachable for a long duration, e.g. for UE's having extended idle mode DRX or PSM enabled, the MME may include
a Pending Data indication in the next S1-AP message towards an eNB. If the eNB receives this indication, the eNB may
take this information into account when determining user inactivity. At inter-RAN node handovers, if some signalling
or data are still pending, the target MME may send a Pending Data indication to the target RAN node.
4.3.17.8 Support for Non-IP Data Delivery (NIDD)
4.3.17.8.1 General
The support of Non-IP data is part of the CIoT EPS Optimisations. A PDN Type "Non-IP" is used for Non-IP data. The
Non-IP data delivery to SCS/AS is accomplished by one of two mechanisms:
- Delivery using SCEF as defined in clause 4.3.17.8.3.2.
- Delivery using a Point-to-Point (PtP) SGi tunnel as defined in clause 4.3.17.8.3.3.
When the Reliable Data Service is not used, Non-IP data in-sequence delivery cannot be guaranteed and data PDUs
may be lost requiring higher protocol layers to ensure guaranteed delivery when needed. The Reliable Data Service is
defined in TS 23.682 [74].
NOTE: If UEs use protocols that require broadcast/multicast mechanisms (e.g. use "IP stacks" on top of PDN
connections of type "Non-IP"), this may cause increased traffic and power consumption to the UE and the
network.
The SMS service may also be used to deliver data without use of the IP protocol. The SMS service is always supported
for CIoT EPS Optimisations, i.e. can be used simultaneously with Non-IP and IP data. When only the SMS service is
needed, an attach without PDN connection establishment can be used, see clause 5.3.2.
Dedicated bearers are not supported for the Non-IP data.
4.3.17.8.2 ESM Procedures

The UE indicates in the ESM connection request, e.g. in Attach or PDN Connectivity Request, that a Non-IP PDN type
shall be used. The subscription information has a default APN for PDN Type Non-IP, which the MME uses for the first
received Non-IP connectivity request unless the UE has included an APN in the request.
3GPP
Release 15 66 3GPP TS 23.401 V15.10.0 (2019-12)
4.3.17.8.3 Delivery mechanism
4.3.17.8.3.1 General
At each PDN connectivity request, the MME decides which delivery mechanism (SCEF based delivery or SGi based
delivery) is used for delivering the Non-IP data between RAN and AS. An indication associated with the used APN
determines if SCEF based delivery or SGi based delivery shall be used.
4.3.17.8.3.2 SCEF based delivery
When the MME decides to use SCEF based delivery mechanism for Non-IP data, a PDN connection is established
towards the selected SCEF. Such a PDN Connection is also known as an "SCEF Connection". The APN used for SCEF
based delivery is an FQDN, which either resolves to an SCEF hostname or to an SCEF IP addresss.
The SCEF based delivery is applicable only to the Control Plane CIoT EPS Optimisation (see clause 4.10).
The support of Non-IP data via the SCEF is further defined in TS 23.682 [74].
4.3.17.8.3.3 SGi based delivery
4.3.17.8.3.3.1 General
When support of Non-IP data is provided at the SGi interface, different point-to-point tunneling techniques may be
used. Point-to-point tunneling by UDP/IP encapsulation can be used as described in clause 4.3.17.8.3.3.2 below. Other
techniques as described in clause 4.3.17.8.3.3 below may be used.
Support for the SGi based delivery of Non-IP data can be used by any UE. That is, it is independent of support for the
User Plane CIoT EPS Optimisation and the Control Plane CIoT EPS Optimisation (see clause 4.10).
The P-GW decides at PDN connection establishment based on pre-configuration which point-to-point tunneling
technique is used for the SGi based delivery between the P-GW and the AS.
NOTE: The pre-configuration can be done in the P-GW per APN or based on other criterion such as SLA
between operator and 3rd party application service provider, etc.
4.3.17.8.3.3.2 SGi PtP tunnelling based on UDP/IP
SGi PtP tunnelling based on UDP/IP may be used to deliver Non-IP data to AS via SGi.
A point-to-point tunnel is used by the P-GW towards the AS. The tunnel parameters (i.e. destination IP address and
UDP port) for SGi PtP tunneling based on UDP/IP are pre-configured on the P-GW. IP address allocation procedures
for PDN connections are performed locally (e.g. without involving the UE) by the P-GW based on APN configuration
and according to clause 5.3.1. Only single IP address is used (i.e. both IPv4 and IPv6 addresses are not allocated).
The P-GW acts as a transparent forwarding node for the payload between the UE and the AS.
For uplink Non-IP data, the P-GW forwards the received data to the AS over the SGi PtP tunnel using UDP/IP
encapsulation. When the Reliable Data Service is enabled, the P-GW processes the Reliable Data Service Header. The
Reliable Data Service Configuration is pre-configured on the P-GW. The Reliable Data Service Configuration is
For downlink Non-IP data, the AS sends the data using UDP/IP encapsulation with the IP address of the UE and the
3GPP defined UDP port for "Non-IP" data. The P-GW decapsulates the received data (i.e. removes the UDP/IP headers)
and forwards the data to S-GW on the GTP-U tunnel identified by the IP address of the UE (i.e. PDN connection) for
delivery to the UE. When the Reliable Data Service is enabled, the P-GW adds the Reliable Data Service Header.
The P-GW performs the IP related operations (e.g. allocates IP address for the PDN connection), but the IP address or
IP prefix is not provided to the UE (i.e. SLAAC / Router Advertisements are not performed. DHCP or DHCPv6 are not
used). In case of IPv6 the P-GW assigns an Interface Identifier for the PDN connection. The allocated IP address or
IPv6 prefix identifies the PDN connection of the UE. The P-GW may inform the MME of the assigned IPv6 prefix for a
given UE. However, the UE is not informed about the assigned IPv6 prefix.
NOTE 1: Whether the P-GW informs S-GW/MME of the assigned IP v6 prefix or not is left to stage 3 decision.
3GPP
Release 15 67 3GPP TS 23.401 V15.10.0 (2019-12)
NOTE 2: It is recommended to use IPv6 for CIoT. IPv4 based addressing is deprecated for machine type
communication used over 3GPP accesses, see TS 23.221 [27].
4.3.17.8.3.3.3 Other SGi PtP tunnelling mechanisms
SGi PtP tunnelling mechanisms such as PMIPv6/GRE, L2TP, GTP-C/U, etc, may be used to deliver Non-IP data to AS
via SGi. The general handling of such delivery mechanisms is as described below.
A point-to-point tunnel is established by the P-GW towards the AS. Depending on the type of protocol employed on the
SGi PtP tunnel, the SGi PtP tunnel setup may be done at the time of Attach or at the time of first MO datagram being
sent by the CIoT UE. The P-GW selects the AS based on the P-GW configuration (e.g. per APN, or per PtP tunnel type
etc.). However, IP address allocation procedures for the UE (according to clause 5.3.1) are not performed by the P-GW.
NOTE: An AS can be dedicated for handling a specific Non-IP data protocol.
The P-GW acts as a transparent forwarding node between the UE and the AS.
For uplink Non-IP data, the P-GW forwards the received data to the AS over the established SGi PtP tunnel.
For downlink Non-IP data, the AS locates the right SGi PtP tunnel for the UE (using information such as UE identifiers
in the Non-IP protocol itself, etc) to forward the data. The AS sends the data to P-GW over the established SGi PtP
tunnel. The P-GW in turn sends the data to S-GW on the GTP-U tunnel identified by the associated SGi PtP tunnel for
delivery to the UE.
4.3.17.9 Service Gap Control

Service Gap Control is an optional feature intended for MTC/CIoT UEs to control the frequency at which these UEs can
access the network. That is, to ensure a minimum time gap between consecutive Mobile Originated data
communications initiated by the UE. This helps reducing peak load situations when there are a large number of these
UEs in an operator network. Service Gap Control is intended to be used for "small data allowance plans" for MTC/CIoT
UEs where the applications are tolerant to service latency.
NOTE 1: Time critical applications, such as emergency services and regulatory prioritised services can suffer from
the latency caused by the Service Gap Control feature. Therefore Service Gap Control feature is not
recommended for subscriptions with such applications and services.
Service Gap Time is a subscription parameter used to set the Service Gap timer and is enforced in the UE and in the
MME on a per UE level (i.e. the same Service Gap Timer applies for all PDN connections that the UE has). The UE
indicates its capability of support for Service Gap Control in the Attach Request message and TAU Request message to
the MME. The MME passes the Service Gap Time to the UE in the Attach Accept message and/or Tracking Area
Update Accept message for UE that has indicated its supports of the Service Gap Control. The Service Gap Control
shall be applied in a UE when a Service Gap Time is stored in the UE context and applied in the MME when the
Service Gap Time is stored in the MM context.
Service Gap Control requires the UE to stay in ECM-IDLE mode for at least the whole duration of the Service Gap
timer before triggering Mobile Originated user data transmission, except for procedures that are exempted (see
TS 24.301 [46]). The Service Gap timer shall be started each time a UE moves from ECM-CONNECTED to ECM-
IDLE, unless the connection request was initiated by the paging of a Mobile Terminated event, or after a TAU
procedure without active flag or signalling active flag, which shall not trigger a new or extended Service Gap interval.
When a Service Gap timer expires, the UE is allowed to send a connection request again. If the UE does so, the Service
Gap timer will be restarted at the next ECM-CONNECTED to ECM-IDLE transition.
The Service Gap control is applied in ECM-IDLE state only and does not impact UE Mobile Originated user data
transmission or Mobile Originated signaling in ECM-CONNECTED state. The Service Gap timer is not stopped upon
ECM-IDLE state to ECM-CONNECTED state transition. The UE shall not initiate connection requests for MO user
plane data, MO control plane data, or MO SMS when a Service Gap timer is running. The UE shall also not initiate
Attach Requests when a Service Gap timer is running, unless it is Attach Request without PDN connectivity or
Emergency Attach which are allowed.
NOTE 2: As a consequence of allowing Attach without PDN connectivity procedure, the UE with a running
Service Gap timer does not initiate further MO signalling, except for tracking area updating procedure,
until the UE receives MT signalling or after the UE has moved to ECM-IDLE state and the Service Gap
Timer is not running.
3GPP
Release 15 68 3GPP TS 23.401 V15.10.0 (2019-12)
NOTE 3: Implementations need to make sure that latest and up-to-date data are always sent when a Service Gap
timer expires.
The MME may enforce the Service Gap timer by rejecting connection request for MO user plane data, MO control
plane data, or MO SMS when a Service Gap timer is running. The MME may enforce the Service Gap timer by not
allowing Attach Requests when a Service Gap timer is running, unless it is Attach Request without PDN connectivity or
Emergency Attach which are allowed. When rejecting the connection requests and the Attach Requests while the
Service Gap timer is running, the MME may include a Mobility Management back-off timer corresponding to the time
left of the current Service Gap timer. For the UEs that does not support Service Gap Control (e.g. pre-release-15 UEs),
Service Gap Control may be enforced using "General NAS level Mobility Management control" as defined in
clause 4.3.7.4.2.1.
When the MME starts the Service Gap timer, the MME should invoke the Service Gap timer with a value that is slightly
shorter than the Service Gap Time value provided to the UE in the subscription information received from the HSS.
NOTE 4: This ensures that the MME doesn't reject any UE requests just before the Service Gap timer expires e.g.
because of slightly unsynchronized timers between UE and MME.
A UE which transitions from a PSM or eDRX power saving state shall apply Service Gap Control when it wakes up if
the Service Gap timer is still running.
Additional aspects of Service Gap Control:
- Service Gap Control applies in all PLMNs.
- When the Service Gap timer is running and the UE receives paging, the UE shall respond as normal.
- Service Gap Control applies to low priority (delayTolerant) and normal traffic.
- Service Gap Control does not apply to exception reporting for NB-IoT.
- Emergency Attach and Attach without PDN Connectivity are allowed when a Service Gap timer is running.
- Service Gap Control shall be effective also for UEs performing detach and reattach unless it is Attach Request
without PDN connectivity or Emergency Attach.
- Tracking Area Update with active flag or signalling active flag is not allowed when a Service Gap timer is
running.
- If the Service Gap timer is running, the Service Gap is applied at PLMN selection as follows:
a) Re-attach to the registered PLMN: The remaining Service Gap timer value survives and controls the re-
attach.
b) Attach or Tracking Area Update to a different PLMN: The remaining Service Gap timer value survives and
controls the Attach/Tracking Area Update to the new PLMN.
c) USIM swap: The Service Gap timer is no longer running and the Service Gap feature does not apply, unless
re-instatiated by the serving PLMN.
- Multiple uplink packets and downlink packets are allowed during one RRC connection for UE operating within
its APN Rate Control limits.
The following procedures are impacted by Service Gap Control:
- E-UTRAN Initial Attach, see clause 5.3.2.1;
- Tracking Area Update procedures, see clause 5.3.3;
- UE Triggered Service Request, see clause 5.3.4.1;
- Connection Resume Request, see clause 5.3.5A.
NOTE 5: Since UE triggered Service Request and Connection Resume Request are prevented by Service Gap
timer, this implictly prevents the UE from initiating MO data in Control Plane EPS Optimisations (see
clause 5.3.4B.2), MO NIDD procedure (see TS 23.682 [74]) and MO SMS (see TS 23.272 [58]).
3GPP
Release 15 69 3GPP TS 23.401 V15.10.0 (2019-12)
4.3.18 Multimedia Priority Service
4.3.18.1 General
Multimedia Priority Service (MPS) allows certain subscribers (i.e. Service Users as per TS 22.153 [68]) priority access
to system resources in situations such as during congestion, creating the ability to deliver or complete sessions of a high
priority nature. Service Users are government-authorized personnel, emergency management officials and/or other
authorized users. MPS supports priority sessions on an "end-to-end" priority basis.
MPS is based on the ability to invoke, modify, maintain and release sessions with priority, and deliver the priority
media packets under network congestion conditions. MPS is supported in a roaming environment when roaming
agreements are in place and where regulatory requirements apply.
NOTE 1: If a session terminates on a server in the Internet (e.g. web-based service), then the remote end and the
Internet transport are out of scope for this specification.
A Service User obtains priority access to the Radio Access Network by using the Access Class Barring mechanism
according to TS 36.331 [37] and TS 22.011 [67]. This mechanism provides preferential access to UEs based on its
assigned Access Class. If a Service User belongs to one of the special access-classes as defined in TS 22.011 [67], the
UE has preferential access to the network compared to ordinary users in periods of congestion.
MPS subscription allows users to receive priority services, if the network supports MPS. MPS subscription entitles a
USIM with special Access Class(es). MPS subscription includes indication for support of EPS bearer priority service,
IMS priority service and CS Fallback priority service support for the end user. Priority level regarding EPS bearer and
IMS are also part of the MPS subscription information. The usage of priority level is defined in TS 23.203 [6] and
TS 23.228 [52].
Service Users is treated as On Demand MPS subscribers or not, based on regional/national regulatory requirements. On
Demand service is based on Service User invocation/revocation explicitly and applied to the PDN connections for an
APN. When not On Demand, MPS service does not require invocation, and provides priority treatment for all EPS
bearers for a given Service User after attachment to the EPS network.
NOTE 2: According to regional/national regulatory requirements and operator policy, On-Demand MPS Service
Users can be assigned the highest priority.
For this release of the specification, MPS is supported for E-UTRAN access only in case of 3GPP accesses.
Since the Service User has an access class within the range for priority services, the Establishment Cause in RRC
connection request is set to highPriorityAccess. When the eNodeB receives mobile initiated signalling with
establishment cause set to highPriorityAccess, the eNodeB handles the RRC connection request with priority. When the
MME receives and verifies mobile initiated signalling with establishment cause set to highPriorityAccess, the MME
establishes the S1 bearer with priority.
The terminating network identifies the priority of the MPS session and applies priority treatment, including paging with
priority, to ensure that the MPS session can be established with priority to the terminating user (either a Service User or
normal user).
Priority treatment for MPS includes priority message handling, including priority treatment during authentication,
security, and location management procedures.
Priority treatment for MPS session requires appropriate ARP and QCI (where necessary for non-GBR bearers) setting
for bearers according to the operator's policy.
When an MPS session is requested by a Service User, the following bearer management principles apply in the
network:
- EPS bearers (including default bearer) employed in an MPS session shall be assigned ARP value settings
appropriate for the priority level of the Service User.
- Setting ARP pre-emption capability and vulnerability for MPS bearers, subject to operator policies and
depending on national/regional regulatory requirements.
- Pre-emption of non-Service Users over Service Users during network congestion situation, subject to operator
policy and national/regional regulations.
3GPP
Release 15 70 3GPP TS 23.401 V15.10.0 (2019-12)
Priority treatment is applicable to IMS based multimedia services, priority EPS bearer services (PS data without IMS
interaction) and CS Fallback.
For Multimedia Priority services any EPC functions, procedures and capabilities are provided according to this clause's
specification except when specified differently in the following clauses.
4.3.18.2 IMS-based Multimedia Priority Services
4.3.18.2.1 Originating IMS-based MPS Session

IMS based MPS sessions are permitted to be originated from any UE, in addition to MPS-subscribed UEs.
The MPS-subscribed UE, based on the MPS IMS subscription information, operator's policy and national/regional
regulations, may be given priority treatment for the default bearer and the EPS bearer carrying IMS signalling in the
EPS prior to and during IMS-based MPS invocation. Further, priority treatment in the EPS for signalling and media
bearers may be modified/established via dynamic PCC based on the session authorization information received from the
AF.
As the IMS media bearer is established after the IMS session of the MPS service has been established, it can be
assigned with correct ARP value when it is established. However IMS signalling related EPS bearer needs to be
upgraded if it has not been assigned with an appropriate ARP setting for the MPS service when the IMS session of the
MPS service has been initiated.
Also to avoid cases where the default bearer may not be allocated resources in the handover case, due to low ARP
priority for the PDN connection, it is necessary to assure that the default bearer has an ARP setting appropriate for the
MPS service.
4.3.18.2.2 Terminating IMS-based MPS Session

The terminating network identifies the priority of the IMS-based MPS session and applies priority treatment to ensure
that the call is delivered with priority to the terminating user (either a Service User or normal user).
If the existing ARP of the default or dedicated EPS bearer that is used to transport IMS signalling are not appropriate
for the MPS service, then PCRF updates to the appropriate settings.
S-GW triggers a new priority paging towards MME in case the ongoing paging is lower priority than the incoming data
received in the S-GW for IMS terminating session.
4.3.18.3 Priority EPS Bearer Services

The Service User receives on demand priority treatment according to its MPS profile, i.e. On-Demand. If the Service
User is not authorized to use on-demand priority request, the Service User receives priority treatment (i.e. appropriate
ARP and QCI ) at initial attach for all bearers, based on user profile data stored in the HSS/SPR and authorized by the
PCRF (see TS 23.203 [6], clause 7.2).
An On-Demand Service User requires explicit invocation/revocation via SPR MPS user profile update (see
TS 23.203 [6], clause 7.5). Since MPS user profile are part of inputs for PCC rules, the update will trigger PCC rules
modification to achieve appropriate ARP and QCI settings for bearers (see TS 23.203 [6], clause 7.4.2).
When the eNodeB receives mobile initiated signalling with establishment cause set to highPriorityAccess, the eNodeB
handles the RRC connection request with priority. When the MME receives and verifies mobile initiated signalling with
establishment cause set to highPriorityAccess, the MME establishes the S1 bearer with priority. Based on MPS EPS
priority subscription, MME can verify whether the UE is permitted to handle the request preferentially comparing to
other UEs not prioritized.
An AF for MPS Priority Service is used to provide Priority EPS Bearer Services using network-initiated resource
allocation procedures (via interaction with PCC) for originating accesses.
NOTE: Use of 3rd party AF for MPS services for Service Users is outside the scope of 3GPP specification.
3GPP
Release 15 71 3GPP TS 23.401 V15.10.0 (2019-12)
4.3.18.4 CS fallback
CS Fallback allows users to fallback to GERAN/UTRAN/1x RTT while in E-UTRAN access thus allowing the network
to transfer the call towards GERAN/UTRAN CS domain. In order to ensure that a priority CSFB call to/from a service
user is given proper priority treatment in the EPS, MPS subscription indicates the user's CS priority status, i.e. MPS CS
Priority, which is provided to MME with user's subscription information. When the eNodeB receives mobile initiated
signalling with establishment cause set to highPriorityAccess, the eNodeB handles the RRC connection request with
priority. When the MME receives and verifies mobile initiated signalling with establishment cause set to
highPriorityAccess, the MME establishes the S1 bearer with priority.
Details on the priority treatment of CSFB, see TS 23.272 [58].
4.3.18.5 Network Congestion Controls for MPS

Based on regional/national requirements and network operator policy, MPS shall be exempted from network congestion
controls up to the point where further exemptions cause network instability. The MME should not apply NAS level
congestion control for mobile initiated signalling with establishment cause set to highPriorityAccess. The MME should
not apply congestion control for termination requests related with an ARP associated with MPS.
4.3.18.6 Load Re-balancing between MMEs for MPS

When a UE is in ECM-CONNECTED mode with a bearer having an ARP associated with MPS, the MME should not
release the UE for load re-balancing, except under critical conditions such as the need to perform an MME node restart.
The MME should wait until the UE initiates a TAU or becomes ECM-IDLE before initiating load re-balancing.
4.3.19 Core Network node resolution
4.3.19.1 General
The indication of mapped or native GUTI shall be signalled by the UE to the MME as an explicit indication in Attach
Request and TAU Request messages. The indication of mapped or native P-TMSI/RAI shall be signalled by the UE to
the SGSN as an explicit indication in Attach Request and RAU Request messages. The MME/SGSN resolves the old
MME/SGSN using old GUTI respective old P-TMSI/RAI sent in the Attach request and TAU/RAU request messages ,
and determines if the old GUTI or the old P-TMSI/RAI is mapped or native by one of the following two methods:
- Indication using most significant bit (MSB) in LAC and MME Group ID.
- Explicit indication sent from UE to MME and SGSN.
4.3.19.2 MSB in LAC and MME Group ID

For PLMNs deployed with such mechanism the MME differentiates between a GUMMEI mapped from P-TMSI/RAI
and a native GUMMEI based on the value of most significant bit of the MME Group ID; i.e. the MSB is set to "0" then
the GUMMEI is mapped from P-TMSI/RAI and if MSB is set to "1", the GUMMEI is a native one, as specified in
TS 23.003 [9].
For PLMNs deployed with such mechanism the S4-SGSN differentiates between a P-TMSI/RAI mapped from GUTI
and a native P-TMSI/RAI based on the value of most significant bit of the LAC; i.e. the MSB is set to "1" then the
P-TMSI/RAI is mapped from GUTI and if MSB is set to "0", the P-TMSI/RAI is a native one, as specified in
TS 23.003 [9].
4.3.19.3 Explicit Indication

For PLMNs deployed with such mechanism the MME differentiates between a GUTI mapped from P-TMSI/RAI or a
native GUTI based on the explicit indication sent by the UE.
For PLMNs deployed with such mechanism the S4-SGSN differentiates between a P-TMSI/RAI mapped from GUTI or
a native P-TMSI/RAI based on the explicit indication sent by the UE.
3GPP
Release 15 72 3GPP TS 23.401 V15.10.0 (2019-12)
4.3.20 Relaying function
4.3.20.1 General
The relaying function enables an operator to improve and extend the coverage area by having a Relay Node (RN)
wirelessly connected to an eNB serving the RN, called Donor eNB (DeNB), via a modified version of the E-UTRA
radio interface called the Un interface as specified in TS 36.300 [5].
The relaying function and use of RN/DeNB entities in a network is transparent to the operations of the UEs connected
to it and associated core network entities (e.g. MME, S/P-GW, PCRF etc.) for the UEs.
The relaying architecture is shown in figure 4.3.20.1-1.
MME MME
(RN) (UE)
S11
(UE)
S11
S1 (RN) P-GW SGi
(RN) (UE)
S1-MME
)
(UE)
LTE
Uu S5/S8
Relay Un DeNB/ S1-U S-GW
UE Node GW (RN) (UE)
Figure 4.3.20.1-1: Relaying Architecture
NOTE 1: Impact to core network elements from the introduction of RNs and DeNB is minimized by reusing the
existing nodes and protocols when interacting with the core network.
NOTE 2: Functions of the MME for the RN and MME for the UE may be collocated in a single MME.
The RN supports the eNB functionality like termination of the radio protocols of the E-UTRA radio interface and the S1
and X2 interfaces. The RN also supports a subset of the UE functionality and protocols to wirelessly connect to the
DeNB.
In addition to supporting eNB functionality, the DeNB also embeds and provides the S-GW/P-GW-like functions
needed for the RN operation. This includes creating a session for the RN and managing EPS bearers for the RN as
shown in clause 4.3.20.3, as well as terminating the S1-AP and S11 interfaces towards the MME serving the RN. Due to
the proxy functionality, the DeNB appears as an MME (for S1), an eNB (for X2) and an S-GW to the RN.
The RN and DeNB also perform mapping of signalling and data packets onto EPS bearers that are setup for the RN.
The mapping is based on existing QoS mechanisms defined for the UE and the P-GW and are described in
TS 36.300 [5].
4.3.20.2 RN startup and attach procedure
4.3.20.2.1 General
The startup procedure for the Relay Node is based on the normal UE attach procedure and consists of the following two
phases:
- Phase I: Attach for RN preconfiguration.
- Phase II: Attach for RN operation (MME of the RN).
3GPP
Release 15 73 3GPP TS 23.401 V15.10.0 (2019-12)
NOTE: When the certificate-based solution is used, the RN uses USIM-INI in Phase I and USIM-RN in Phase II
with necessarily different IMSIs. When pre-shared key is used, there is only need for one USIM and the
RN uses the same IMSI during Phase I and Phase II. The MME does not treat certificate-based and pre-
shared key-based solution differently. The use of the certificate-based and pre-shared key solutions is
specified in Annex D of TS 33.401 [41].
4.3.20.2.2 Attach for RN preconfiguration

The RN attaches to the E-UTRAN/EPC as a UE at power-up (i.e. the RN shall not include the RN indication in the
RRC Connection establishment signalling). The eNB treats the RN as a normal UE when performing MME selection.
Because the eNB does not indicate that this is a RN in the S1 interface Initial UE message, the MME does not perform
any further RN specific actions (e.g. it ignores any indication from the HSS that "this subscription includes a permission
to operate as a RN").
The authentication of the "RN acting as an UE" is performed by the MME during this attach procedure, using the
information obtained from the HSS.
The MME performs the S-GW and P-GW selection as for a normal UE.
NOTE: It is the responsibility of the HSS operator to ensure that the RN subscription includes an APN
configuration that ensures that the RN subscription cannot be used for other purposes, e.g. only a single
APN is configured for the use of RNs in phase I, and, that this APN is reserved for RNs only.
The RN retrieves initial RN configuration parameters as user plane traffic, across the SGi reference point, from RN
OAM (e.g. list of DeNB cells and selected PLMN).
After this operation is complete, the RN detaches from the network using the normal UE initiated detach procedure, see
clause 5.3.8.2.1 and the RN triggers Phase II.
4.3.20.2.3 Attach for RN operation

To start relay operations, the normal attach procedure, with the following exceptions, is applied:
- The RN and the USIM-RN perform local security operations (e.g. establishment of a secure channel between
them) as specified in TS 33.401 [41];
- The RN selects a cell from the list acquired during Phase I;
- The RN establishes an RRC connection with the DeNB, indicating that the connection is for a RN;
- The DeNB is aware of the MMEs that support RN functionality. In all cases when the RN indication is recieved,
the DeNB shall ensure that the current or (re)selected MME supports RN functionality;
NOTE 1: The RN follows normal UE behaviour, e.g. the RN's NAS may use either an IMSI or a GUTI. Also, the
RN's NAS may or may not provide an S-TMSI to the RN's AS, and hence, the RRCConnectionRequest
may either contain an S-TMSI or a random value.
- In the S1 interface Initial UE Message, the DeNB sends the RN indication to the MME. This message also
carries the IP address of the S-GW/P-GW function embedded in the DeNB;
- The subscription data supplied to the MME by the HSS for USIM-RN includes an indication that the
subscription is permitted to be used by a RN.
- If the S1 interface Initial UE Message indicates that this is a RN, but the subscription data does not indicate that
the subscription includes a permission to operate as a RN, then the MME shall reject the NAS procedure (e.g.
Attach Request, Tracking Area Update Request, Service Request, etc) with an appropriate cause value (e.g. one
that avoids retries on this PLMN yet does not harm a RN that has unexpectedly performed PLMN reselection).
NOTE 2: It is anticipated that the MME checks that the HPLMN of the USIM-RN is authorised to attach RNs to
this MME.
- The MME and RN perform the normal EPS Authentication procedures.
3GPP
Release 15 74 3GPP TS 23.401 V15.10.0 (2019-12)
- MME (RN) selects the S-GW/P-GW in DeNB for the RN based on the IP address included in the Initial UE
Message (i.e. all GW selection and APN related procedures are bypassed during this phase). The MME performs
S11 interface signalling with the S-GW/P-GW located in the DeNB;
- The MME accepts the attach procedure and sets up an S1 context with the DeNB.
When relay function is enabled, MMEs in a pool should all have the same relaying function capability in order to have
consistent support for functions such as redundancy, load balancing.
RN DeNB MME HSS
1. RRC connection setup
2a. NAS Attach, Authentication, Security, ... 2b. Authentication, Security, ...
3. GTP-C Create Session
4b. S1 Context Setup

4a. RRC connection re-config.
(NAS Attach Accept)
Figure 4.3.20.2-1: RN attach procedure
The detach procedure for the RN is the same as the normal UE detach procedure, though the RN should ensure that no
UE is connected to the RN cells before detaching. It is up to RN implementation how it ensures no UE is connected.
4.3.20.3 DeNB E-RAB activation/modification

This procedure is used by the DeNB to change the EPS bearer allocation for the RN. The procedure is the same as the
normal network-initiated bearer activation/modification procedure with the exception that the S-GW/P-GW
functionality (steps 1 and 6) is performed by the DeNB.
RN DeNB MME
1. GTP- C Create/Update Bearer Request
2 . S 1 -AP Bea rer Setu p/ Mo dify Re ques t

(NAS Se ssio n Ma nag eme nt Me ss age)
3 . RRC connection re -config .
4 . S1- AP Bearer Setup/Modify Response
5b. Direct Transfer

5a. Direct Transfer ( …)
(NAS Session Management Message )
6. GTP-C Create/ Update Bearer Response
Figure 4.3.20.3-1: DeNB-initiated bearer activation/modification procedure
NOTE: It is up to implementation if and when the DeNB sets up and modifies EPS bearers for the RN, in addition
to the initial bearer set up procedures at Attach.
3GPP
Release 15 75 3GPP TS 23.401 V15.10.0 (2019-12)
4.3.21 Core Network assisted eNodeB parameters tuning
4.3.21.1 CN Assistance Information

Core Network assisted eNodeB parameters tuning aids the eNodeB to minimize the UE state transitions and achieve
optimum network behaviour. How the eNB uses the Core Network assistance information is not in scope of this
specification and is implementation specific.
Core Network assistance information may be derived by the MME per UE in the MME based on collection of UE
behaviour statistics or other available information about the expected UE behaviour (such as subscribed APN, IMSI
ranges or other subscription information). If the HSS provides the Communication Pattern (CP) parameters (see
TS 23.682 [74]) within the subscription profile information, then the MME may use the CP parameters for selecting the
CN assisted eNB parameters. The CP parameters received from the HSS are used by the MME as input to derive the
CN assisted eNB parameter values. For the case of statistics-based Core Network assistance information collection, this
may be enabled based on local configuration (e.g. subscribed APN, IMSI ranges or other subscription information).
This information provides the eNB with a way to understand the UE behaviour for these aspects:
- "Expected UE activity behaviour", i.e. the expected pattern of the UE's changes between ECM-CONNECTED
and ECM-IDLE states. This may be derived e.g. from statistical information or from subscription information.
- "Expected HO interval", i.e. the expected time interval between inter-eNB handovers. This may be derived e.g.
from statistical information or from subscription information. The "Expected HO interval" parameter is not
based on subscription information. Highly mobile UEs may have the ECM-CONNECTED state reduced to
reduce handover signalling, unless the activity data do not justify that, as reduced handover signalling would be
outweighed by more Service Request signalling).
- "UE Differentiation Information" including the Communication Pattern parameters (see TS 23.682 [74]) to
support Uu operation optimisation for NB-IoT UE differentiation.
The respective signalling to support this feature is specified in TS 36.413 [36]. The cases where the Traffic Profile (see
see TS 23.682 [74]) is not used are described in clauses 5.3.4B.2 and 5.3.4B.3.
The MME decides when to send this information to the eNB as "Expected UE behaviour" carried in S1-AP signalling
over the S1-MME interface as per procedure documented in clause 4.3.21.3.
NOTE 1: The calculation of the Core Network assistance information, i.e. the algorithms used and related criteria,
and the decision when it is considered suitable and stable to send to the eNB are vendor specific.
Unreliable information should not be provided to the eNB as it may drive undesirable system effects.
NOTE 2: It is recommended the MME or, depending on where this assessment is performed, the eNB, can consider
the average times in the ECM-CONNECTED and ECM-IDLE states an accurate representation of the
traffic patterns if the average time in ECM-CONNECTED mode is short enough to assume the UE is
generally actively transmitting and/or receiving data while in ECM-CONNECTED state.
NOTE 3: When there are multiple overlapping CP parameter sets received from the HSS for one UE, then the
MME considers a merge per CP parameter when deriving the CN assisted eNB parameters, e.g. based on
the Scheduled communication time and/or Communication duration time parameters. A conflict on the
Stationary Indication parameter can be resolved by considering the UE as "mobile".
4.3.21.2 Void
4.3.21.3 Core Network Assistance Procedures

The MME provides CN assistance information to the eNodeB if available, during the setup of the S1 signalling
connection (e.g., Attach, Service Request).
The following figure is a high level description of the transfer of information from an MME to eNodeB during a service
request procedure.
3GPP
Release 15 76 3GPP TS 23.401 V15.10.0 (2019-12)
UE eNB MME
On- going signalling connection
Release
UE is
ECM-idle
CN assistance data
produced by MME
Service Request, S1 Connection & Radio Bearer Establishment

CN assistance data provided to eNodeB by MME
The eNB may use assistance data for reducing

the number of connected idle transitions and
reducing mobility related signalling affecting the
MME
Figure 4.3.21.3-1: Core Network assisted eNodeB parameters tuning
4.3.22 UE Power Saving Mode

A UE may adopt a PSM that is described in TS 23.682 [74]. If a UE is capable of adopting a PSM and it wants to use
the PSM it shall request an Active Time value and may request a Periodic TAU/RAU Timer value during every Attach
and TAU procedures, which are handled as described in TS 23.682 [74]. The UE shall not request a Periodic TAU/RAU
Timer value if it is not requesting an Active Time value. The network shall not allocate an Active Time value if the UE
has not requested it.
PSM has no support in the CS domain on the network side.
NOTE 1: When the PSM is activated the UE might not be available for paging of Mobile Terminated CS services
even though the UE is registered in the CS domain.
NOTE 2: The Attach and TAU procedures of this specification are not showing the details of the Periodic TAU
Time and Active Time negotiation, i.e. are not showing the related IEs.
If the network allocates an Active Time value, the UE and the MME starts the Active timer (see clause 4.3.5.2) with the
Active Time value allocated by the network when transitioning from ECM_CONNECTED to ECM_IDLE. The UE
shall stop the Active timer, if running, when a transition to ECM_CONNECTED mode is made. When the Active timer
expires, the UE deactivates its Access Stratrum functions and enters PSM. In PSM, due to deactivation of Access
Stratum functions, the UE stops all idle mode procedures, but continues to run any NAS timers that may apply, e.g. the
periodic TAU timer. The UE shall resume Access Stratum functions and idle mode procedures before the periodic TAU
timer expires for performing the periodic TAU procedure as applicable. The UE may resume idle mode procedures and
Access Stratum functions any time while in PSM, e.g. for mobile originated communications. Any timers and
conditions that remain valid during power-off, e.g. for NAS-level back-off, apply in the same way during PSM.
3GPP
Release 15 77 3GPP TS 23.401 V15.10.0 (2019-12)
When the Active timer expires for the UE, the MME knows that the UE entered PSM and is not available for paging.
The MME handles availability for paging as detailed in clause 4.3.5.2.
On UE side the PSM complies with some substates of EMM_REGISTERED, as specified in TS 24.301 [46]. The MME
considers the UE to be EMM_REGISTERED, but not reachable. The UE's Access Stratum functions are considered as
deactivated during PSM.
For mobile terminated data while a UE is in PSM, the functions for High latency communication may be used as
When the UE has bearers for emergency services, the UE shall not apply PSM.
4.3.23 Access network selection and traffic steering based on RAN-

assisted WLAN interworking
As described in TS 36.300 [5], TS 36.304 [34], TS 36.331 [37] and TS 25.331 [33], UTRAN and E-UTRAN may
provide RAN assistance parameters to the UE via RRC signalling. The RAN assistance parameters may e.g. include E-
UTRAN signal strength and quality thresholds, WLAN channel utilization thresholds, WLAN backhaul data rate
thresholds, a list of WLAN identifiers and Offload Preference Indicator (OPI). The UE uses the RAN assistance
parameters to perform access network selection and traffic steering decisions between 3GPP access and WLAN using
procedures defined in TS 36.304 [34] or using ANDSF policies defined in TS 23.402 [2]. Co-existence between the
procedures defined in TS 36.304 [34] and ANDSF policies is described in TS 23.402 [2].
For traffic steering decisions using procedures defined in TS 36.304 [34] the MME may provide information to the UE
indicating which PDN Connection can be offloaded to WLAN and which PDN Connection shall not be offloaded to
WLAN. When provided by the MME, this indication is provided in NAS signalling on a per PDN Connection basis
when a PDN Connection is established. The MME may provide a per-RAT indication for the PDN connection, e.g. if
the indication is different for UTRAN and for E-UTRAN. If the MME provides a single indication, the UE shall apply
such indication both to E-UTRAN and UTRAN.
Traffic steering decisions using procedures defined in TS 36.304 [34] are not applicable to non-seamless WLAN
offload (see TS 23.402 [2] for the definition of non-seamless WLAN offload).
In order for the operator to allow/prohibit WLAN offloading on per user and per APN basis, subscription data in the
HSS may be configured to indicate if WLAN offload is allowed or prohibited for an APN.
The MME determines the WLAN offloading permissions for the UE and PDN Connection as described below:
- The MME determines the offloadability of a PDN Connection based on subscription data and locally configured
policy (e.g. for roaming users or when the subscription data does not include any WLAN offloadability
indication).
- When the UE establishes a new PDN Connection, the MME may indicate whether this PDN Connection is
offloadable or not offloadable to WLAN.
- The MME may provide an updated WLAN offloadability indication of a PDN Connection to the UE. This may
be initiated by HSS as part of the Insert Subscriber Data procedure as described in clause 5.3.9.2. It can also be
initiated by the MME by initiating steps 4 to 7 of the Bearer Modification Procedure in clause 5.4.3, Figure
5.4.3-1 or by adding the WLAN offloadability indication to a session management NAS message sent to the UE
as part of an existing procedure. The MME shall not trigger signaling to an ECM-IDLE UE solely for the
purpose of updating the WLAN offloadability indication.
When the UE applies the procedures defined in TS 36.304 [34] and TS 25.304 [12], if the UE has Local Operating
Environment Information (LOEI), as defined in TS 23.261 [54], the UE shall consider the RAN rules in combination
with the non-radio related aspects of LOEI, and shall give priority to LOEI in case it indicates WLAN is not acceptable
for non-radio related reasons. For example, if the active RAN rule indicates that traffic shall be moved to WLAN
access, but the LOEI in the UE indicates that WLAN access is unacceptable due to non-radio related causes (e.g. due to
authentication issues, low battery power, etc.), the UE shall not move the traffic to WLAN.
When the UE applies the procedures defined in TS 36.304 [34], the UE takes into account the WLAN offloadability
indication from MME to perform handover between 3GPP access and WLAN access using the handover procedures
3GPP
Release 15 78 3GPP TS 23.401 V15.10.0 (2019-12)
When the UE receives a WLAN offloadability indication from the network for a PDN connection the UE stores it for
the lifetime of that PDN Connection and updates it if a new value is received from the network. The UE shall apply the
latest indication previously received for the PDN Connection.
The indication of whether a PDN connection is offloadable or not offloadable should be passed from the source to the
target serving node in mobility management procedures from a MME to a MME/SGSN. This allows the target
SGSN/MME to learn the indication previously provided to the UE and to decide the need for providing an updated
indication to the UE.
4.3.23a Access network selection and traffic steering based on RAN-

Controlled WLAN interworking
As described in TS 36.300 [5] E-UTRAN may support RAN-Controlled WLAN interworking (RCLWI) for controlling
traffic steering between E-UTRAN and WLAN for UEs in RRC_CONNECTED. When E-UTRAN sends an "offload"
command to the UE, the UE passes an indication to the upper layers indicating that traffic steering to/from WLAN is
needed. The upper layers determine to initiate traffic steering to/from WLAN based on the UE capability and the
configuration information that has received from NAS layer indicating which PDN connections are offloadable. When
the UE receives the "offload" command from the EUTRAN, the UE shall perform handover to WLAN only the PDN
connections that have been authorized for offloading.
The NAS level indication about "offloadability" of PDN connections is defined in clause 4.3.23.
The UE uses the RCLWI procedures to perform access network selection and traffic steering decisions between 3GPP
access and WLAN or using ANDSF policies defined in TS 23.402 [2]. Co-existence between the procedures defined for
RCLWI, ANDSF policies and user preference is described in TS 23.402 [2].
4.3.24 RAN user plane congestion management function
4.3.24.1 General
The user plane congestion management function addresses how the system can effectively mitigate RAN user plane
congestion in order to reduce the negative impact on the perceived service quality. The congestion mitigation measures
include traffic prioritization, traffic reduction and limitation of traffic, and shall be able to manage user plane traffic
across a range of variables including the user's subscription, the type of application, and the type of content. Congestion
mitigation can be performed in the RAN or in the CN, or in a combined way both in the RAN and in the CN.
4.3.24.2 RAN user plane congestion mitigation in the RAN

Editor's note: Text to be added depending on the outcome of the UPCON study.
4.3.24.3 RAN user plane congestion mitigation in the CN

RAN user plane congestion mitigation in the CN uses RAN OAM information, collected by the RAN Congestion
Awareness Function (RCAF), to detect congestion. The RAN Congestion Awareness Function is further described in
clause 4.4.12. This functionality is applicable only in case of UTRAN/E-UTRAN accesses.
NOTE 1: The criteria used for detection of RAN user plane congestion (including detection of congestion
abatement) are outside the scope of 3GPP specifications.
NOTE 2: The interface to the RAN's OAM system is not standardized.
The RCAF can transfer RAN user plane congestion information (RUCI) to the PCRF over the Np reference point in
order to mitigate the congestion by measures selected by the PCRF, as specified in TS 23.203 [6]. Decisions to apply
congestion mitigation measures may take into account operator policies and subscriber information and all additional
available IP-CAN session information.
Different mechanisms and mitigation actions applicable as described in TS 23.203 [6] in order to mitigate RAN User
Plane Congestion. Those mechanisms include e.g. service/application gating, service/application bandwidth limitation,
deferring of services.
3GPP
Release 15 79 3GPP TS 23.401 V15.10.0 (2019-12)
NOTE 3: Co-existence between congestion mitigation in RAN and CN can be assured by appropriate network
configuration of applicable policies for congestion mitigation, as well as related RAN parameter
alignment/tuning, such as tuning of parameters for e.g., load balancing, carrier aggregation, co-ordinated
multipoint, dual connectivity. This parameter alignment/tuning is not further specified.
NOTE 4: A condition leading to interoperability issues which may lead to suboptimal situation is that the time
scales for actions of congestion mitigation in RAN and in CN are of comparable duration. Therefore,
congestion mitigation in RAN and CN cannot have comparable time scales, otherwise interoperability is
affected.
4.3.25 Dedicated Core Networks (DCNs)
4.3.25.1 General
This feature enables an operator to deploy multiple DCNs within a PLMN with each DCN consisting of one or multiple
CN nodes. Each DCN may be dedicated to serve specific type(s) of subscriber. This is an optional feature and enables
DCNs to be deployed for one or multiple RATs (e.g. GERAN, UTRAN, E-UTRAN, WB-E-UTRAN and NB-IoT).
There can be several motivations for deploying DCNs, e.g. to provide DCNs with specific characteristics/functions or
scaling, to isolate specific UEs or subscribers (e.g. M2M subscribers, subscribers belonging to a specific enterprise or
separate administrative domain, etc.).
A DCN comprises of one or more MME/SGSN and it may comprise of one or more SGW/PDN GW/PCRF. This
feature enables subscribers to be allocated to and served by a DCN based on subscription information ("UE Usage
Type"). The feature in this clause handles both DCN selections without any specific UE functionality, i.e. it works also
with UEs of earlier releases and UE assisted DCN selection.
The main specific functions are for routing and maintaining UEs in their respective DCN. The following deployment
scenarios are supported for DCN:
- DCNs may be deployed to support one RAT only, (e.g. only dedicated MMEs are deployed to support E-
UTRAN and dedicated SGSNs are not deployed), to support multiple RATs, or to support all RATs.
- Networks deploying DCNs may have a default DCN, which is managing UEs for which a DCN is not available
or if sufficient information is not available to assign a UE to a DCN. One or multiple DCNs may be deployed
together with a default DCN that all share the same RAN.
- The architecture supports scenarios where the DCN is only deployed in a part of the PLMN e.g. only for one
RAT or only in a part of the PLMN area. Such heterogeneous or partial deployment of DCNs may, depending on
operator deployment and configuration, result in service with different characteristics or functionality, depending
on whether the UE is inside or outside the service area or RAT that supports the DCN.
NOTE 1: Heterogeneous or partial deployment of DCNs may result in increased occurrence of UEs first being
served by a CN node in the default DCN and then being redirected to a CN node in the DCN that serves
the UE when the UE moves from areas outside of DCN coverage to an area of DCN coverage. It may also
result in an increased re-attach rate in the network. As this has impacts on the required capacity of the
default CN nodes deployed at edge of DCN coverage, it is not recommended to deploy DCNs
heterogeneously or partially.
- Even if the DCN is not deployed to serve a particular RAT or service area of PLMN, the UE in that RAT or
service area may still be served by a PDN GW from the DCN.
High level overview for supporting DCNs is provided below. Details are captured in appropriate clauses of this
specification, TS 23.060 [7] and TS 23.236 [30].
- An optional subscription information parameter ("UE Usage Type") is used in the selection of a DCN. An
operator configures which of his DCN(s) serves which UE Usage Type(s). The HSS provides the "UE Usage
Type" value in the subscription information of the UE to the MME/SGSN. Both standardized and operator
specific values for UE Usage Type are possible.
- The serving network selects the DCN based on the operator configured (UE Usage Type to DCN) mapping,
other locally configured operator's policies and the UE related context information available at the serving
network, e.g. information about roaming. UEs with different UE Usage Type values may be served by the same
DCN. Moreover, UEs that share the same UE Usage Type value may be served by different DCNs.
3GPP
Release 15 80 3GPP TS 23.401 V15.10.0 (2019-12)
- If the configuration shows no DCN for the specific "UE Usage Type" value in the subscription information, then
the serving MME/SGSN serves the UE by the default DCN or selects a DCN using serving operator specific
policies.
- Some subscribers may be configured without "UE Usage Type" value. In this case, the MME/SGSN may select
the DCN that serves the UE using locally configured operator's policies and the UE related context information
available at the serving network (other than UE provided DCN-ID). The MME/SGSN performs procedures
described in clauses 5.19.1 and 5.19.2.
- The "UE Usage Type" is associated with the UE (describing its usage characteristic), i.e. there is only one UE
Usage Type" per UE subscription.
- For each DCN, one or more CN nodes may be configured as part of a pool.
- For MME, the MMEGI(s) identifies a DCN within the PLMN. For SGSNs, a group identifier(s) identifies a
DCN within the PLMN. That is, the group of SGSNs that belong to a DCN within a PLMN. This identifier may
have the same format as NRI (e.g. an NRI value that does not identify a specific SGSN node in the serving area)
in which case it is called "Null-NRI" or it may have a format independent of NRI, in which case it is called
"SGSN Group ID". The "Null-NRI" or "SGSN Group ID" is provided by an SGSN to RAN which triggers the
NNSF procedure to select an SGSN from the group of SGSNs corresponding to the Null-NRI/SGSN Group ID
(see clause 5.19.1).
NOTE 2: SGSN Group IDs enable to handle deployment scenarios where in a service area all NRI values are
allocated to SGSNs and hence no NRI value remains that can be used as Null-NRI.
- The dedicated MME/SGSN that serves the UE selects a dedicated S-GW and P-GW based on UE Usage Type.
- At initial access to the network if sufficient information is not available for RAN to select a specific DCN, the
RAN may selects a CN node from the default DCN. A redirection to another DCN may then be required.
- To redirect a UE from one DCN to a different DCN, the redirection procedure via RAN, described in
clause 5.19.1, is used to forward the NAS message of the UE to the target DCN.
- All selection functions are aware of DCN(s), including the network node selection function (NNSF) of RAN
nodes, for selecting and maintaining the appropriate DCN for the UEs.
4.3.25.1a UE assisted Dedicated Core Network selection

This feature is to reduce the need for DECOR reroute by using an indication (DCN-ID) sent from the UE and used by
RAN to select the correct DCN. The DCN-ID shall be assigned to the UE by the serving PLMN and is stored in the UE
per PLMN ID. Both standardized and operator specific values for DCN-ID are possible. The UE shall use the PLMN
specific DCN-ID whenever a PLMN specific DCN-ID is stored for the target PLMN.
The HPLMN may provision the UE with a single default standardized DCN-ID which shall be used by the UE only if
the UE has no PLMN specific DCN-ID of the target PLMN. When a UE configuration is changed with a new default
standardized DCN-ID, the UE shall delete all stored PLMN specific DCN-IDs.
The UE provides the DCN-ID to RAN at registration to a new location in the network, i.e. in Attach, TAU and RAU.
RAN selects serving node (MME or SGSN) based on the DCN-ID provided by the UE and configuration in RAN. For
E-UTRAN the eNB is configured with DCNs supported by the connected MMEs at the setup of the S1 connection. For
UTRAN and GERAN the BSS/RNC is configured with the DCNs supported in the connected SGSN via O&M. Both
standardized DCN-IDs and PLMN specific DCN-IDs can in the RAN configuration be assigned to the same network. If
information provided by the UE (e.g. GUTI, NRI, etc.) indicates a node (MME or SGSN) for attach/TAU/RAU and a
serving node (MME or SGSN) corresponding to the UE information can be found by the RAN node, the normal node
selection shall take precedence over the selection based on DCN-ID. At registration the MME/SGSN may check if the
correct DCN is selected. The check is performed as specified in clause 4.3.25.1. If the MME/SGSN concludes that the
selected DCN is not the correct DCN, a DECOR reroute is performed and the SGSN/MME in the new DCN assigns a
new DCN-ID to the UE. The serving MME/SGSN can also assign a new DCN-ID to the UE if e.g. the DCN-ID in the
UE has become obsolete or when the UE Usage Type has been updated in the subscription information leading to a
change of DCN. This is performed as part of the GUTI Reallocation procedure.
3GPP
Release 15 81 3GPP TS 23.401 V15.10.0 (2019-12)
4.3.25.2 Considerations for Roaming

In the case of roaming, if the HPLMN of the visiting UE does not support DCNs, i.e. doesn't provide the UE Usage
Type, the serving MME/SGSN may select the DCN that serves the UE using operator specific policies based on other
subscription or UE provided information.
In the case of roaming, if the HPLMN provides the UE Usage Type parameter to the VPLMN, this parameter is
provided irrespective of its value (standardized or operator specific). The handling of the UE Usage Type parameter in
the VPLMN is based on operator policies, e.g. roaming agreements.
If the UE assisted DCN selection feature is supported:
- If the UE has a DCN-ID for the VPLMN the UE shall send that PLMN specific DCN-ID to the RAN, and
- If the UE has no PLMN specific DCN-ID for this VPLMN and if the UE has a pre-provisioned default
standardized DCN-ID it shall send the pre-provisioned default standardized DCN-ID to the RAN.
4.3.25.3 Considerations for Network Sharing

If the network supports the MOCN configuration for network sharing (see TS 23.251 [24]), each network sharing
operator has separate CN(s). Mechanisms for selection of serving operator for supporting and non-supporting UEs are
defined in TS 23.251 [24]. Each of the sharing operators may deploy one or more DCNs.
If Selected PLMN information is provided by the UE, the RAN selects the CN operator based on this provided
information and then DECOR rerouting may, if needed, be initiated within the CN of the selected operator. If the UE
assisted DCN selection feature is supported and both the Selected PLMN information and DCN-ID is provided by the
UE, the RAN first selects the CN operator followed by selection of a DCN supported by the selected CN operator.
If Selected PLMN information is not provided by the UE (may only happen in GERAN and UTRAN), the network
initiates MOCN redirection, including CS/PS coordination, to select a CN operator that can serve the UE. After this,
DECOR rerouting is initiated if needed. The serving node in the selected DCN ends the MOCN redirection. If the UE
assisted DCN selection feature is supported and Selected PLMN information is not provided by the UE, the network
initiates CN operator selection and after the CN operator selection is concluded the DCN is selected based on the UE
provided DCN-ID. As the PLMN information included in the RAI is the Common PLMN (refer to TS 23.251 [24]),
which does not reflect the selected CN operator, the network may also return the PLMN ID of the selected CN operator.
When the UE receives the NAS Accept message, the UE associates the DCN-ID with both the PLMN ID of the selected
CN operator and the Common PLMN IDs.
The functions for redirecting or maintaining UEs in specific DCNs are configured to work within the CNs of the same
operator.
4.3.26 Support for Monitoring Events

The Monitoring Events feature is intended for monitoring of specific events in 3GPP system and making such
monitoring event information available via the Service Capability Exposure Function (SCEF). The architecture and
related functions to support Monitoring Events are defined in TS 23.682 [74].
4.3.27 Paging Enhancements
4.3.27.1 Paging for Enhanced Coverage

Support of UEs in Enhanced Coverage is specified in TS 36.300 [5].
Whenever S1 is released and Information for Enhanced Coverage is available for the UE, the eNB sends it to the MME
as described in clause 5.3.5.
The MME stores the received Information for Enhanced Coverage and, if Enhanced Coverage Restricted parameter is
not set then MME, includes it in every subsequent Paging message for all eNBs selected by the MME for paging.
3GPP
Release 15 82 3GPP TS 23.401 V15.10.0 (2019-12)
4.3.27a Restriction of use of Enhanced Coverage for voice centric UE

If the UE's usage setting is "voice centric" as defined in TS 23.221 [27], it shall not operate in CE mode B.
If the UE supports CE mode B and UE's usage setting is set to "voice centric" in the Attach or TAU request message
then the MME shall indicate to eNB that CE mode B is restricted. If the UE supports CE mode B and UE's usage setting
is set to "data centric" in the Attach or TAU request message then, based on operator's policy and the Enhanced
Coverage Restricted parameter (see clause 4.3.28), the MME shall indicate to eNB that CE mode B is not restricted.
The MME keeps the CE mode B Restricted parameter in the MM Context. The MME shall send the CE mode B
Restricted parameter to the eNB via S1 signalling indicating whether the UE is "restricted" or "not restricted" for the
use of CE mode B, e.g. in PAGING, INITIAL CONTEXT SETUP REQUEST, HANDOVER REQUEST, PATH
SWITCH REQUEST ACKNOWLEDGE, CONNECTION ESTABLISHMENT INDICATION, and DOWNLINK NAS
TRANSPORT message carrying the TAU ACCEPT message.
If the UE supports CE mode B and the CE mode B Restricted parameter stored in the MME's MM context is set to "not
restricted", the MME shall use the extended NAS timer settings for the UE as specified in TS 24.301 [46].
4.3.27b Enhanced Coverage for data centric UEs

The support for UEs in Enhanced Coverage is specified in TS 36.300 [5].
The IMS impacts for data centric UEs in Enhanced Coverage is specified in Annex E of TS 23.228 [52].
4.3.28 Restriction of use of Enhanced Coverage

The usage of Enhanced Coverage may require use of extensive resources (e.g. radio and signalling resources) from the
network. This feature enables the operator to prevent specific subscribers from using Enhanced Coverage.
The UE indicates its capability of support for restriction of use of Enhanced Coverage in Attach and TAU procedure for
the RAT it is camping on to the MME. MME receives Enhanced Coverage Restricted parameter from the HSS. This
parameter is kept as part of subscription data in the HSS and specifies per PLMN whether the enhanced coverage
functionality is restricted or not for the UE. For roaming UEs, if HSS doesn't provide any Enhanced Coverage
Restricted parameter or the provided Enhanced Coverage Restricted parameter is in conflict with the roaming
agreement, the MME uses default Enhanced Coverage Restricted parameter locally configured in the VPLMN based on
the roaming agreement with the subscriber's HPLMN. The UE shall assume that restriction for use of Enhanced
Coverage is same in the equivalent PLMNs. If the UE includes the support for restriction of use of Enhanced Coverage,
MME sends Enhanced Coverage Restricted parameter to the UE in the Attach/TAU Accept message. The UE shall use
the value of Enhanced Coverage Restricted parameter to determine if enhanced coverage feature is restricted or not.
NOTE: How this parameter is used by UE at AS layer is defined in the RAN specification.
The UE assumes Enhanced Coverage is allowed unless explicitly restricted by the network for a PLMN.
If the MME has sent the Enhanced Coverage Restricted parameter to the UE, the MME provides an Enhanced Coverage
Restricted parameter to the eNB via S1 signalling during paging, and whenever the UE context is established in RAN,
e.g. during service request procedure, attach procedure, and TAU procedure.
4.3.29 3GPP PS Data Off
4.3.29.1 General
This feature, when activated by the user, prevents transport via 3GPP access of all IP packets and non-IP data except for
those related to 3GPP PS Data Off Exempt Services. The 3GPP PS Data Off Exempt Services are a set of operator
services, defined in TS 23.221 [27], that are the only allowed services when the 3GPP PS Data Off feature has been
activated by the user.
3GPP
Release 15 83 3GPP TS 23.401 V15.10.0 (2019-12)
UEs may be configured with up to two lists of 3GPP PS Data Off Exempt Services and the list(s) are provided to the
UEs by HPLMN via Device Management or UICC provisioning. When the UE is configured with two lists, one list is
valid for the UEs camping in the home PLMN and the other list is valid for any VPLMN the UE is roaming in. When
the UE is configured with a single list, without an indication to which PLMNs the list is applicable, then this list is valid
for the home PLMN and any PLMN the UE is roaming in.
NOTE 1: The operator needs to ensure coordinated lists of 3GPP Data Off Exempt Services provisioned in the UE
and configured in the network.
The UE discovers whether a PDN GW supports 3GPP PS Data Off feature at initial attach and during the establishment
of a PDN connection via the presence of the 3GPP PS Data Off Support Indication in the Create Session response
message.
NOTE 2: When the UE detects that the PDN GW does not support 3GPP PS Data Off feature, how the UE reacts to
non exempt services MT requests from the network is implementation dependent.
The UE shall report its 3GPP PS Data Off status in PCO (Protocol Configuration Option) to PDN GW during Initial
Attach procedure as described in clause 5.3.2.1 and UE requested PDN connectivity procedure as described in
clause 5.10.2.
NOTE 3: This also covers scenarios when the user activates/deactivates 3GPP PS Data Off while connected via
WLAN access only, and then a handover to 3GPP access occurs.
If 3GPP PS Data Off is activated, the UE prevents the sending of uplink IP packets and non-IP data except for those
related to 3GPP PS Data Off Exempt Services, based on the pre-configured list of Data Off Exempt Services.
For those PDN GWs that indicated support for the 3GPP PS Data Off feature during PDN connection setup and at
Initial Attach, the UE shall report immediately a change of its 3GPP PS Data Off status in PCO by using Bearer
Resource Modification procedure as described in clause 5.4.5, this also applies to the scenario of inter-RAT mobility
procedure to E-UTRAN and also to scenarios where the 3GPP PS Data Off status is changed when the session
management back-off timer is running as specified in clause 4.3.7.4.2. If the UE has not received any 3GPP PS Data
Off Support Indication during the establishment of the PDN connection, it shall not report any change of its 3GPP PS
Data Off Status for this PDN connection.
The additional behaviour of the PDN GW for 3GPP PS Data Off is controlled by local configuration or policy from the
PCRF as defined in TS 23.203 [6].
NOTE 4: For the PDN connection used for IMS services, the 3GPP Data Off Exempt Services are enforced in the
IMS domain as specified TS 23.228 [52]. Policies configured in the PDN GW/PCRF need to ensure those
services are always allowed when the 3GPP Data Off status of the UE is set to "activated".
4.3.30 Unlicensed spectrum aggregation (LAA/LWA/LWIP)

Unlicensed spectrum aggregation in EPS can either use LTE-Assisted Access (LAA) that is using the Carrier
Aggregation (CA) RAN configuration defined in TS 36.300 [5] or LWA/LWIP aggregation using WLAN as secondary
RAT that is using the Dual Connectivity architecture defined in clause 4.3.2a and TS 36.300 [5].
For either case if the UE has Access Restriction for Unlicensed Spectrum in the form of LAA, or LWA/LWIP (either
signalled from the HSS, or, locally generated by VPLMN policy in the MME) the MME signals this to the E-UTRAN
as part of Handover Restriction List.
An eNB supporting aggregation with unlicensed spectrum in the form of LAA, LWA/LWIP checks whether the UE is
allowed to use unlicensed spectrum. If the UE is not allowed to use Unlicensed Spectrum, the eNB shall not establish
dual connectivity or carrier aggregation (CA) with LTE in unlicensed spectrum in the form of LAA or WLAN as a
secondary RAT in the form of LWA/LWIP.
At inter-RAT handover from GERAN/UTRAN, the Access Restriction for Unlicensed Spectrum is either already in the
MME's UE context, or is obtained from the HSS during the subsequent Tracking Area Update procedure (i.e. not from
the source SGSN or source RAN). In both inter-RAT handover cases, any Access Restriction for use of Unlicensed
Spectrum is then signalled to the E-UTRAN.
NOTE: This signalling of the Access Restriction during the TAU after the inter-RAT handover procedure means
that there is a small risk that unlicensed spectrum resources are transiently allocated.
3GPP
Release 15 84 3GPP TS 23.401 V15.10.0 (2019-12)
4.3.31 Subscription handling for Aerial UEs

This clause describes subscription information handling in order to support operating Aerial UE function over E-
UTRAN as defined in TS 36.300 [5] and TS 36.331 [37].
The eNB supporting Aerial UE function handling uses the per user information supplied by the MME to determine
whether or not to allow the UE to use Aerial UE function.
Support of Aerial UE function is stored in the user's subscription information in HSS. HSS transfers this information to
the MME via Update Location message during Attach and Tracking Area Update procedures. Home Operator may
revoke user's subscription authorisation for operating Aerial UEs at any time.
MME that supports Aerial UE function provides the user's subscription information on Aerial UE authorisation to the
eNB via the S1 AP Initial Context Setup Request during Attach, Tracking Area Update and Service Request procedures.
For the intra and inter MME S1 based handover (intra RAT) or Inter-RAT handover to E-UTRAN, the Aerial UE
subscription information for the user is included in the S1-AP UE Context Modification Request message sent to the
target eNodeB after the handover procedure.
For X2-based handover, the Aerial UE subscription information for the user is sent to target eNodeB as follows:
- If the source eNodeB supports Aerial UE function and the user's Aerial UE subscription information is included
in the UE context, the source eNodeB shall include the information in the X2-AP Handover Request message to
the target eNodeB.
- The MME shall send the Aerial UE subscription information to the target eNodeB in the Path Switch Request
Acknowledge message.
If the Aerial UE subscription information has changed, the updated Aerial UE subscription information is included in
the S1-AP UE Context Modification Request message sent to the eNodeB.
4.4 Network elements

4.4.1 E-UTRAN
E-UTRAN is described in more detail in TS 36.300 [5].
In addition to the E-UTRAN functions described in TS 36.300 [5], E-UTRAN functions include:
- Header compression and user plane ciphering (for user plane data sent across S1-U);
- MME selection when no routing to an MME can be determined from the information provided by the UE;
- UL bearer level rate enforcement based on UE-AMBR and MBR via means of uplink scheduling
(e.g. by limiting the amount of UL resources granted per UE over time);
- DL bearer level rate enforcement based on UE-AMBR;
- UL and DL bearer level admission control;
- Transport level packet marking in the uplink, e.g. setting the DiffServ Code Point, based on the QCI, and
optionally the ARP priority level, of the associated EPS bearer;
- ECN-based congestion control.
4.4.2 MME
MME functions include:
- NAS signalling;
3GPP
Release 15 85 3GPP TS 23.401 V15.10.0 (2019-12)
- NAS signalling security;
- Inter CN node signalling for mobility between 3GPP access networks (terminating S3);
- UE Reachability in ECM-IDLE state (including control, execution of paging retransmission and optionally
Paging Policy Differentiation);
- Tracking Area list management;
- Mapping from UE location (e.g. TAI) to time zone, and signalling a UE time zone change associated with
mobility,
- PDN GW and Serving GW selection;
- MME selection for handovers with MME change;
- SGSN selection for handovers to 2G or 3G 3GPP access networks;
- Roaming (S6a towards home HSS);
- Authentication;
- Authorization;
- Bearer management functions including dedicated bearer establishment;
- Lawful Interception of signalling traffic;
- Warning message transfer function (including selection of appropriate eNodeB);
- UE Reachability procedures;
- Support Relaying function (RN Attach/Detach);
- Change of UE presence in Presence Reporting Area reporting upon PCC request,
- in the case of Change of UE presence in Presence Reporting Area reporting, management of Core Network
pre-configured Presence Reporting Areas.
- For the Control Plane CIoT EPS Optimisation:
a) transport of user data (IP and Non-IP);
b) local Mobility Anchor point;
c) header compression (for IP user data);
d) ciphering and integrity protection of user data;
e) Lawful Interception of user traffic not transported via the Serving GW (e.g. traffic using T6a).
NOTE: The Serving GW and the MME may be implemented in one physical node or separated physical nodes.
For CIoT EPS Optimisation, the Serving GW and the MME can be implemented in one physical node
(e.g. C-SGN) or separated physical nodes. The C-SGN can also encompass the PDN GW function.
The MME shall signal a change in UE Time Zone only in case of mobility and in case of UE triggered Service Request,
PDN Disconnection and UE Detach. If the MME cannot determine whether the UE Time Zone has changed (e.g. the
UE Time Zone is not sent by the old MME during MME relocation), the MME should not signal a change in UE Time
Zone. A change in UE Time Zone caused by a regulatory mandated time change (e.g. daylight saving time or summer
time change) shall not trigger the MME to initiate signalling procedures due to the actual change. Instead the MME
shall wait for the UE's next mobility event or Service Request procedure and then use these procedures to update the UE
Time Zone information in the PDN GW.
3GPP
Release 15 86 3GPP TS 23.401 V15.10.0 (2019-12)
4.4.3 Gateway
4.4.3.1 General
Two logical Gateways exist:
- Serving GW (S-GW);
- PDN GW (P-GW).
NOTE: The PDN GW and the Serving GW may be implemented in one physical node or separated physical
nodes.
4.4.3.2 Serving GW
The Serving GW is the gateway which terminates the user plane interface towards E-UTRAN (except when user data is
transported using the Control Plane CIoT EPS Optimisation).
For each UE associated with the EPS, at a given point of time, there is a single Serving GW.
The functions of the Serving GW, for both the GTP-based and the PMIP-based S5/S8, include:
- the local Mobility Anchor point for inter-eNodeB handover (except when user data is transported using the
Control Plane CIoT EPS Optimisation);
- sending of one or more "end marker" to the source eNodeB, source SGSN or source RNC immediately after the
Serving GW switches the path during inter-eNodeB and inter-RAT handover, especially to assist the reordering
function in eNodeB.
- Mobility anchoring for inter-3GPP mobility (terminating S4 and relaying the traffic between 2G/3G system and
PDN GW);
- ECM-IDLE mode downlink packet buffering and initiation of network triggered service request procedure and
optionally Paging Policy Differentiation;
- Lawful Interception;
- Packet routing and forwarding;
- Transport level packet marking in the uplink and the downlink, e.g. setting the DiffServ Code Point, based on the
QCI, and optionally the ARP priority level, of the associated EPS bearer;
- Accounting for inter-operator charging. For GTP-based S5/S8, the Serving GW generates accounting data per
UE and bearer;
- Interfacing OFCS according to charging principles and through reference points specified in TS 32.240 [51];
- Forwarding of "end marker" to the source eNodeB, source SGSN or source RNC when the "end marker" is
received from PDN GW and the Serving GW has downlink user plane established. Upon reception of "end
marker", the Serving GW shall not send Downlink Data Notification.
Additional Serving GW functions for the PMIP-based S5/S8 are captured in TS 23.402 [2].
Connectivity to a GGSN is not supported.
4.4.3.3 PDN GW
The PDN GW is the gateway which terminates the SGi interface towards the PDN.
If a UE is accessing multiple PDNs, there may be more than one PDN GW for that UE, however a mix of S5/S8
connectivity and Gn/Gp connectivity is not supported for that UE simultaneously.
PDN GW functions include for both the GTP-based and the PMIP-based S5/S8:
- Per-user based packet filtering (by e.g. deep packet inspection);
3GPP
Release 15 87 3GPP TS 23.401 V15.10.0 (2019-12)
- Lawful Interception;
- UE IP address allocation;
- Transport level packet marking in the uplink and downlink, e.g. setting the DiffServ Code Point, based on the
QCI, and optionally the ARP priority level, of the associated EPS bearer;
- Accounting for inter-operator charging: for home routed roaming, the P-GW shall collect and report the uplink
and downlink data volume (per EPS bearer) as received from and sent to the serving node;
- UL and DL service level charging as defined in TS 23.203 [6]

(e.g. based on SDFs defined by the PCRF, or based on deep packet inspection defined by local policy);
- Interfacing OFCS through according to charging principles and through reference points specified in
TS 32.240 [51].
- UL and DL service level gating control as defined in TS 23.203 [6];
- UL and DL service level rate enforcement as defined in TS 23.203 [6]

(e.g. by rate policing/shaping per SDF);
- UL and DL rate enforcement based on APN-AMBR

(e.g. by rate policing/shaping per aggregate of traffic of all SDFs of the same APN that are associated with Non-
GBR QCIs);
- DL rate enforcement based on the accumulated MBRs of the aggregate of SDFs with the same GBR QCI
(e.g. by rate policing/shaping);
- DHCPv4 (server and client) and DHCPv6 (client and server) functions;
- The network does not support PPP bearer type in this version of the specification. Pre-Release 8 PPP
functionality of a GGSN may be implemented in the PDN GW;
- The PDN GW may support Non-IP data transfer (e.g. with CIoT EPS Optimisations);
- packet screening;
- sending of one or more "end marker" to the source SGW immediately after switching the path during SGW
change;
- PCC related features (e.g. involving PCRF and OCS) as described in TS 23.203 [6].
Additionally the PDN GW includes the following functions for the GTP-based S5/S8:
- UL and DL bearer binding as defined in TS 23.203 [6];
- UL bearer binding verification as defined in TS 23.203 [6];
- Functionality as defined in RFC 4861 [32];
- Accounting per UE and bearer.
The P-GW provides PDN connectivity to both GERAN/UTRAN only UEs and E-UTRAN capable UEs using any of
E-UTRAN, GERAN or UTRAN. The P-GW provides PDN connectivity to E-UTRAN capable UEs using E-UTRAN
only over the S5/S8 interface.
4.4.4 SGSN
In addition to the functions described in TS 23.060 [7], SGSN functions include:
- Inter EPC node signalling for mobility between 2G/3G and E-UTRAN 3GPP access networks;
- PDN and Serving GW selection: the selection of S-GW/P-GW by the SGSN is as specified for the MME;
- Handling UE Time Zone as specified for the MME;
3GPP
Release 15 88 3GPP TS 23.401 V15.10.0 (2019-12)
- MME selection for handovers to E-UTRAN 3GPP access network.
4.4.5 GERAN
GERAN is described in more detail in TS 43.051 [15].
4.4.6 UTRAN
UTRAN is described in more detail in TS 25.401 [16].
4.4.7 PCRF
4.4.7.1 General
PCRF is the policy and charging control element. PCRF functions are described in more detail in TS 23.203 [6].
In non-roaming scenario, there is only a single PCRF in the HPLMN associated with one UE's IP-CAN session. The
PCRF terminates the Rx interface and the Gx interface.
In a roaming scenario with local breakout of traffic there may be two PCRFs associated with one UE's IP-CAN session:
- H-PCRF that resides within the H-PLMN;
- V-PCRF that resides within the V-PLMN.
4.4.7.2 Home PCRF (H-PCRF)

The functions of the H-PCRF include:
- terminates the Rx reference point for home network services;
- terminates the S9 reference point for roaming with local breakout;
- associates the sessions established over the multiple reference points (S9, Rx), for the same UE's IP-CAN
session (PCC session binding).
The functionality of H-PCRF is described in TS 23.203 [6].
4.4.7.3 Visited PCRF (V-PCRF)

The functions of the V-PCRF include:
- terminates the Gx and S9 reference points for roaming with local breakout;
- terminates Rx for roaming with local breakout and visited operator's Application Function.
The functionality of V-PCRF is described in TS 23.203 [6].
4.4.8 PDN GW's associated AAA Server

The PDN Gateway may interact with a AAA server over the SGi interface. This AAA Server may maintain information
associated with UE access to the EPC and provide authorization and other network services. This AAA Server could be
a RADIUS or Diameter Server in an external PDN network, as defined in TS 29.061 [38]. This AAA Server is logically
separate from the HSS and the 3GPP AAA Server.
4.4.9 HeNB subsystem

A HeNB subsystem consists of a HeNB, optionally a HeNB GW and optionally a Local GW.
The Local IP Access and SIPTO at the Local Network with L-GW function collocated with the HeNB functions are
achieved using a Local GW (L-GW) colocated with the HeNB.
3GPP
Release 15 89 3GPP TS 23.401 V15.10.0 (2019-12)
Figure 4.4.9-1 illustrates the architecture for LIPA and/or SIPTO at the Local Network with L-GW function collocated
with the HeNB.
LIPA or
SIPTO@LN
user plane SGi
L-GW
S5
HeNB S1-U SGW S5 PDN GW SGi
S1-MME S11
Uu
MME
UE
Figure 4.4.9-1: Architecture for LIPA or SIPTO at the Local Network with L-GW collocated with the
HeNB
NOTE 1: The optional HeNB GW is not shown in the figure for simplicity.
The HeNB subsystem is connected by means of the standard S1 interface to the EPC (Evolved Packet Core), more
specifically to the MME (Mobility Management Entity) by means of the S1-MME interface and to the Serving Gateway
(S-GW) by means of the S1-U interface. When LIPA or SIPTO at the Local Network with L-GW function collocated
with the HeNB is activated, the L-GW has a S5 interface with the S-GW.
NOTE 2: In this specification and for simplification the term eNodeB refers to the HeNB subsystem if the UE
accesses the network via a HeNB unless stated otherwise.
NOTE 3: Detailed functions of HeNB and HeNB GW are described in TS 36.300 [5].
NOTE 4: An L-GWcollocated with a HeNB may support LIPA, or SIPTO@LN, or both.
The Local GW is the gateway towards the IP networks (e.g. residential/enterprise networks, Internet) associated with
the HeNB. The Local GW has the following PDN GW functions:
- UE IP address allocation;
- DHCPv4 (server and client) and DHCPv6 (client and server) functions;
- Packet screening;
- Functionality as defined in RFC 4861 [32].
Additionally, the Local GW has the following functions:
- ECM-IDLE mode downlink packet buffering;
- ECM-CONNECTED mode direct tunnelling towards the HeNB.
NOTE 5: The architecture for SIPTO at the Local Network with L-GW function collocated with a HeNB depicted
in Figure 4.4.9-1 also applies to SIPTO at the Local Network with L-GW function collocated with an
eNB.
4.4.10 DeNB
DeNB function is described in more detail in TS 36.300 [5].
DeNB provides the necessary S/P-GW functions for the operation of RNs connected to the DeNB.
3GPP
Release 15 90 3GPP TS 23.401 V15.10.0 (2019-12)
In order to provide the Relay Function the DeNB shall support the following P-GW functions:
- IP address allocation for the UE functionality of the RN;
- Downlink transport level packet mapping between the DSCP value used over S1-U of the UE (which is the SGi
interface of the PDN GW function in the DeNB) and the EPS bearers with an appropriate QCI value and
optionally ARP priority level value, established between the PDN GW function in the DeNB and the UE
function of the RN;
- Uplink transport level packet mapping between QCI value and optionally ARP priority level value, of the EPS
bearers (established between the PDN GW function in the DeNB and the UE function of the RN) and the DSCP
value used over S1-U of the UE (which is the SGi interface of the PDN GW function in the DeNB).
In order to provide the Relay Function the DeNB shall support the following S-GW functions:
- Termination the S11 session of the MME(RN).
S-GW functions related to ECM-IDLE are not required.
S-GW functions related to mobility management are not supported.
4.4.11 CSG Subscriber Server

CSG Subscriber Server (CSS) is an optional element that stores CSG subscription data for roaming subscribers. The
CSS stores and provides VPLMN specific CSG subscription information to the MME. The CSS is accessible from the
MME via the S7a interface. The CSS is always in the same PLMN as the current MME.
If the same CSG ID exists in both CSS subscription data and HSS subscription data, the CSG subscription data from the
HSS shall take precedence over the data from CSS.
Figure 4.4.11-1 illustrates CSS connected to MME.
MME S7a CSS
Figure 4.4.11-1: CSS connected to MME
4.4.12 RAN Congestion Awareness Function

The RAN Congestion Awareness Function (RCAF) is an element that provides RAN User Plane Congestion
Information (RUCI) to the PCRF to enable the PCRF to take the RAN user plane congestion status into account for
policy decisions.
The RCAF collects information related to user plane congestion from the RAN's OAM system based on which the
RCAF determines the congestion level (and the identifier) of an eNB or E-UTRAN cell.
Via the Nq interface the RCAF determines the UEs served by a congested eNB or congested E-UTRAN cell and
retrieves the APNs of the active PDN connections of those UEs. The decision whether the RCAF operates on eNB or E-
UTRAN cell level is up to operator configuration.
Via the Np reference point, the RCAF sends the RUCI to the PCRFs serving the UEs' PDN connections.
NOTE 1: The details of congestion reporting to the PCRF and the Np reference point are specified in
TS 23.203 [6].
NOTE 2: In the case of roaming or RAN sharing as specified in TS 23.251 [24], Np is an inter-operator reference
point. Whether Np applies in case of roaming and RAN sharing is subject to inter-operator agreements.
Figure 4.4.12-1 illustrates the RCAF connected to the MME. The RCAF is located in the same PLMN as the serving
MME except in network sharing scenarios where the RCAF belongs to the RAN operator.
3GPP
Release 15 91 3GPP TS 23.401 V15.10.0 (2019-12)
MME Nq RCAF
Figure 4.4.12-1: RCAF connected to MME
4.5 Void
4.6 EPS Mobility Management and Connection Management

states
4.6.1 General
The EPS Mobility Management (EMM) states describe the Mobility Management states that result from the mobility
management procedures e.g. Attach and Tracking Area Update procedures.
Two EMM states are described in this document:
- EMM-DEREGISTERED.
- EMM-REGISTERED.
NOTE 1: Other specifications may define more detailed EMM states (see e.g. TS 24.301 [46]).
The EPS Connection Management (ECM) states describe the signalling connectivity between the UE and the EPC.
Two ECM states are described in this document:
- ECM-IDLE.
- ECM-CONNECTED.
NOTE 2: The ECM-CONNECTED and ECM-IDLE states used in this document correspond respectively to the
EMM-CONNECTED and EMM-IDLE modes defined in TS 24.301 [46].
In general, the ECM and EMM states are independent of each other. Transition from EMM-REGISTERED to EMM-
DEREGISTERED can occur regardless of the ECM state, e.g. by explicit detach signalling in ECM-CONNECTED or
by implicit detach locally in the MME during ECM-IDLE. However there are some relations, e.g. to transition from
EMM-DEREGISTERED to EMM-REGISTERED the UE has to be in the ECM-CONNECTED state.
4.6.2 Definition of main EPS Mobility Management states
4.6.2.1 EMM-DEREGISTERED
In the EMM-DEREGISTERED state, the EMM context in MME holds no valid location or routing information for the
UE. The UE is not reachable by a MME, as the UE location is not known.
In the EMM-DEREGISTERED state, some UE context can still be stored in the UE and MME, e.g. to avoid running an
AKA procedure during every Attach procedure.
During the successful Inter-RAT TAU/RAU/handover procedure and ISR activated is not indicated to the UE, the old
S4 SGSN/old MME changes the EMM state of the UE to GPRS-IDLE/PMM-DETACHED/EMM-DEREGISTERED.
4.6.2.2 EMM-REGISTERED
The UE enters the EMM-REGISTERED state by a successful registration with an Attach procedure to either E-UTRAN
or GERAN/UTRAN. The MME enters the EMM-REGISTERED state by a successful Tracking Area Update procedure
3GPP
Release 15 92 3GPP TS 23.401 V15.10.0 (2019-12)
for a UE selecting an E-UTRAN cell from GERAN/UTRAN or by an Attach procedure via E-UTRAN. In the EMM-
REGISTERED state, the UE can receive services that require registration in the EPS.
NOTE: The UE employs a single combined state machine for EMM and GMM states.
The UE location is known in the MME to at least an accuracy of the tracking area list allocated to that UE (excluding
some abnormal cases).
In the EMM-REGISTERED state, the UE shall:
- always have at least one active PDN connection (unless the UE supports "Attach without PDN connectivity");
- setup the EPS security context.
After performing the Detach procedure, the state is changed to EMM-DEREGISTERED in the UE and in the MME.
Upon receiving the TAU Reject and Attach Reject messages the actions of the UE and MME depend upon the 'cause
value' in the reject message, but, in many cases the state is changed to EMM-DEREGISTERED in the UE and in the
MME.
If all the bearers belonging to a UE that does not support "Attach without PDN connectivity" are released (e.g., after
handover from E-UTRAN to non-3GPP access), the MME shall change the MM state of that UE to EMM-
DEREGISTERED. If the UE that does not support "Attach without PDN connectivity" camps on E-UTRAN and the UE
detects that all of its bearers are released, the UE shall change the MM state to EMM-DEREGISTERED. If all the
bearers (PDP contexts) belonging to a UE are released, while the UE camps on GERAN/UTRAN, the UE shall
deactivate ISR by setting its TIN to "P-TMSI" as specified in TS 23.060 [7]. This ensures that the UE performs
Tracking Area Update when it re-selects E-UTRAN. If the UE switches off its E-UTRAN interface when performing
handover to non-3GPP access, the UE shall automatically change its MM state to EMM-DEREGISTERED.
The MME may perform an implicit detach any time after the Implicit Detach timer expires. The state is changed to
EMM-DEREGISTERED in the MME after performing the implicit detach.
4.6.3 Definition of EPS Connection Management states
4.6.3.1 ECM-IDLE
A UE is in ECM-IDLE state when no NAS signalling connection between UE and network exists. In ECM-IDLE state,
a UE performs cell selection/reselection according to TS 36.304 [34] and PLMN selection according to TS 23.122 [10].
Except for UEs that have had their RRC connection suspended, as described in clause 5.3.4A, there exists no UE
context in E-UTRAN for the UE in the ECM-IDLE state. There is no S1_MME and no S1_U connection for the UE in
the ECM-IDLE state.
In the EMM-REGISTERED and ECM-IDLE state, the UE shall:
- perform a tracking area update if the current TA is not in the list of TAs that the UE has received from the
network in order to maintain the registration and enable the MME to page the UE;
- perform the periodic tracking area updating procedure to notify the EPC that the UE is available;
- perform a tracking area update if the RRC connection was released with release cause "load balancing TAU
required";
- perform a tracking area update when the UE reselects an E-UTRAN cell and the UE's TIN indicates "P-TMSI";
- perform a tracking area update for a change of the UE's Core Network Capability information or the UE specific
DRX parameter;
- perform a tracking area update when a change in conditions in the UE require a change in the extended idle
mode DRX parameters previously provided by the MME.
- perform a tracking area update when the UE manually selects a CSG cell, and the CSG ID and associated PLMN
of that cell is absent from both the UE's Allowed CSG list and the UE's Operator CSG list;
3GPP
Release 15 93 3GPP TS 23.401 V15.10.0 (2019-12)
- answer to paging from the MME by performing a service request procedure or, if the UE has had its RRC
connection suspended, the UE initiates the Connection Resume procedure (clause 5.3.5A);
- perform the service request procedure in order to establish the radio bearers when uplink user data is to be sent,
or uplink NAS signalling is to be sent for UE requested bearer modification procedure (clause 5.4.5), UE
requested PDN connectivity (clause 5.10.2), UE requested PDN disconnection (clause 5.10.3), or if the UE has
had its RRC connection suspended the UE initiates the Connection Resume procedure (clause 5.3.5A).
The UE and the MME shall enter the ECM-CONNECTED state when the signalling connection is established between
the UE and the MME. Initial NAS messages that initiate a transition from ECM-IDLE to ECM-CONNECTED state are
Attach Request, Tracking Area Update Request, Service Request or Detach Request. A successful completion of the
Connection Resume procedure, described in clause 5.3.5.A, initiates at UE and MME a state transition from ECM-
IDLE to ECM-CONNECTED.
When the UE is in ECM-IDLE state, the UE and the network may be unsynchronized, i.e. the UE and the network may
have different sets of established EPS bearers. When the UE and the MME enter the ECM-CONNECTED state, the set
of EPS Bearers is synchronized between the UE and network.
4.6.3.2 ECM-CONNECTED
The UE location is known in the MME with an accuracy of a serving eNodeB ID. The mobility of UE is handled by the
handover procedure, except for when the NB-IoT is being used, in which case there are no handover procedures.
The UE performs the tracking area update procedure when the TAI in the EMM system information is not in the list of
TA's that the UE registered with the network, or when the UE handovers to an E-UTRAN cell and the UE's TIN
indicates "P-TMSI".
For a UE in the ECM-CONNECTED state, there exists a signalling connection between the UE and the MME. The
signalling connection is made up of two parts: an RRC connection and an S1_MME connection.
The UE shall enter the ECM-IDLE state when its signalling connection to the MME has been released or broken. This
release or failure is explicitly indicated by the eNodeB to the UE or detected by the UE.
The S1 release procedure or, if the UE is enabled to use User Plane CIoT EPS Optimisation the S1 Connection Suspend
procedure (clause 5.3.4A) changes the state at both UE and MME from ECM-CONNECTED to ECM-IDLE.
NOTE 1: The UE may not receive the indication for the S1 release, e.g. due to radio link error or out of coverage.
In this case, there can be temporal mismatch between the ECM-state in the UE and the ECM-state in the
MME.
After a signalling procedure, the MME may decide to release the signalling connection to the UE, after which the state
at both the UE and the MME is changed to ECM-IDLE.
NOTE 2: There are some abnormal cases where the UE transitions to ECM-IDLE.
When a UE changes to ECM-CONNECTED state and the network initiates establishment of data radio bearers, then if a
data radio bearer cannot be established, or the UE cannot maintain a data radio bearer in the ECM-CONNECTED state
during handovers, the corresponding EPS bearer is deactivated. An exception to this is when the UE has been informed
by the MME that a specific EPS bearer will never use a data radio bearer (e.g.because that EPS bearer is for a
connection to the SCEF).
3GPP
Release 15 94 3GPP TS 23.401 V15.10.0 (2019-12)
4.6.4 State transition and functions

Detach,
Attach Reject,
TAU reject,
E-UTRAN interface switched off due to Non-3GPP handover,
All bearers deactivated and UE does not support “Attach
without PDN connectivity”
EMM-DEREGISTERED EMM-REGISTERED
Attach accept
Figure 4.6.4-1: EMM state model in UE
Detach,
Attach Reject,
TAU reject,
All bearers deactivated and UE does not support
“Attach without PDN connectivity”
EMM-DEREGISTERED EMM-REGISTERED
Attach accept
TAU accept for a UE selecting
E-UTRAN from GERAN/UTRAN
Figure 4.6.4-2: EMM state model in MME
RRC connection
released
ECM-IDLE ECM-CONNECTED
RRC connection
established
Figure 4.6.4-3: ECM state model in UE
S1 connection
released
ECM-IDLE ECM-CONNECTED
S1 connection
established
Figure 4.6.4-4: ECM state model in MME
3GPP
Release 15 95 3GPP TS 23.401 V15.10.0 (2019-12)
4.7 Overall QoS concept

4.7.1 PDN connectivity service
The Evolved Packet System provides connectivity between a UE and a PLMN external packet data network. This is
referred to as PDN Connectivity Service.
The IP PDN Connectivity Service supports the transport of traffic flow aggregate(s), consisting of one or more Service
Data Flows (SDFs).
NOTE: The concept of SDF is defined in the context of PCC, TS 23.203 [6], and is not explicitly visible in the
NAS signalling.
A PDN connection to an SCEF has the following characteristics:
- It is only supported for WB-EUTRA, LTE-M and NB-IoT RAT types;
- It applies only when Control Plane CIoT EPS Optimisation are applicable;
- It does not support the transport of traffic flow aggregate(s);
- It does not support Emergency Services.
4.7.2 The EPS bearer
4.7.2.1 The EPS bearer in general

For E-UTRAN access to the EPC the PDN connectivity service is provided by an EPS bearer for GTP-based S5/S8, and
if IP is in use, by an EPS bearer concatenated with IP connectivity between Serving GW and PDN GW for PMIP-based
S5/S8.
In this release of the specifications, dedicated bearers are only supported for the IP PDN Connectivity Service.
When User Plane (S1-U) is used for data traffic, then an EPS bearer uniquely identifies traffic flows that receive a
common QoS treatment between a UE and a PDN GW for GTP-based S5/S8, and between UE and Serving GW for
PMIP-based S5/S8. The packet filters signalled in the NAS procedures are associated with a unique packet filter
identifier on per-PDN connection basis.
NOTE 1: The EPS Bearer Identity together with the packet filter identifier is used to reference which packet filter
the UE intends to modify or delete, i.e. it is used to implement the unique packet filter identifier.
An EPS bearer is the level of granularity for bearer level QoS control in the EPC/E-UTRAN. That is, all traffic mapped
to the same EPS bearer receive the same bearer level packet forwarding treatment (e.g. scheduling policy, queue
management policy, rate shaping policy, RLC configuration, etc.). Providing different bearer level packet forwarding
treatment requires separate EPS bearers.
NOTE 2: In addition but independent to bearer level QoS control, the PCC framework allows an optional
enforcement of service level QoS control on the granularity of SDFs independent of the mapping of SDFs
to EPS bearers.
One EPS bearer is established when the UE connects to a PDN, and that remains established throughout the lifetime of
the PDN connection to provide the UE with always-on IP connectivity to that PDN. That bearer is referred to as the
default bearer. Any additional EPS bearer that is established for the same PDN connection is referred to as a dedicated
bearer.
The EPS bearer traffic flow template (TFT) is the set of all packet filters associated with that EPS bearer. An UpLink
Traffic Flow Template (UL TFT) is the set of uplink packet filters in a TFT. A DownLink Traffic Flow Template (DL
TFT) is the set of downlink packet filters in a TFT. Every dedicated EPS bearer is associated with a TFT. A TFT may
be also assigned to the default EPS bearer. The UE uses the UL TFT for mapping traffic to an EPS bearer in the uplink
direction. The PCEF (for GTP-based S5/S8) or the BBERF (for PMIP-based S5/S8) uses the DL TFT for mapping
traffic to an EPS bearer in the downlink direction. The UE may use the UL TFT and DL TFT to associate EPS Bearer
Activation or Modification procedures to an application and to traffic flow aggregates of the application. Therefore the
3GPP
Release 15 96 3GPP TS 23.401 V15.10.0 (2019-12)
PDN GW shall, in the Create Dedicated Bearer Request and the Update Bearer Request messages, provide all available
traffic flow description information (e.g. source and destination IP address and port numbers and the protocol
information).
For the UE, the evaluation precedence order of the packet filters making up the UL TFTs is signalled from the P-GW to
the UE as part of any appropriate TFT operations.
NOTE 3: The evaluation precedence index of the packet filters associated with the default bearer, in relation to
those associated with the dedicated bearers, is up to operator configuration. It is possible to "force"
certain traffic onto the default bearer by setting the evaluation precedence index of the corresponding
filters to a value that is lower than the values used for filters associated with the dedicated bearers.
A TFT of an uplink unidirectional EPS bearer is only associated with UL packet filter(s) that matches the uplink
unidirectional traffic flow(s) A TFT of a downlink unidirectional EPS bearer is associated with DL packet filter(s) that
matches the unidirectional traffic flow(s) and a UL packet filter that effectively disallows any useful packet flows (see
clause 15.3.3.4 in TS 23.060 [7] for an example of such packet filter.
The UE routes uplink packets to the different EPS bearers based on uplink packet filters in the TFTs assigned to these
EPS bearers. The UE evaluates for a match, first the uplink packet filter amongst all TFTs that has the lowest evaluation
precedence index and, if no match is found, proceeds with the evaluation of uplink packet filters in increasing order of
their evaluation precedence index. This procedure shall be executed until a match is found or all uplink packet filters
have been evaluated. If a match is found, the uplink data packet is transmitted on the EPS bearer that is associated with
the TFT of the matching uplink packet filter. If no match is found, the uplink data packet shall be sent via the EPS
bearer that has not been assigned any uplink packet filter. If all EPS bearers (including the default EPS bearer for that
PDN) have been assigned one or more uplink packet filters, the UE shall discard the uplink data packet.
NOTE 4: The above algorithm implies that there is at most one EPS bearer without any uplink packet filter.
Therefore, some UEs may expect that during the lifetime of a PDN connection (where only network has
provided TFT packet filters) at most one EPS bearer exists without any uplink packet filter.
To ensure that at most one EPS bearer exists without any uplink packet filter, the PCEF (for GTP-based S5/S8) or the
BBERF (for PMIP-based S5/S8) maintains a valid state for the TFT settings of the PDN connection as defined in
clause 15.3.0 of TS 23.060 [7] and if necessary, adds a packet filter which effectively disallows any useful packet flows
in uplink direction (see clause 15.3.3.4 in TS 23.060 [7] for an example of such a packet filter) to the TFT of a
dedicated bearer.
NOTE 5: The default bearer is the only bearer that may be without any uplink packet filter and thus, a packet filter
which effectively disallows any useful packet flows in uplink direction will not be added by the
PCEF/BBERF.
The initial bearer level QoS parameter values of the default bearer are assigned by the network, based on subscription
data (in E-UTRAN the MME sets those initial values based on subscription data retrieved from HSS).
In a non-roaming scenario, the PCEF may change the QoS parameter value received from the MME based on
interaction with the PCRF or based on local configuration. When the PCEF changes those values, the MME shall use
the bearer level QoS parameter values received on the S11 reference point during establishment or modification of the
default bearer.
In a roaming scenario, based on local configuration, the MME may downgrade the ARP or APN-AMBR and/or remap
QCI parameter values received from HSS to the value locally configured in MME (e.g. when the values received from
HSS do not comply with services provided by the visited PLMN). The PCEF may change the QoS parameter values
received from the MME based on interaction with the PCRF or based on local configuration. Alternatively, the PCEF
may reject the bearer establishment.
NOTE 6: For certain APNs (e.g. the IMS APN defined by the GSMA) the QCI value is strictly defined and
therefore remapping of QCI is not permitted.
NOTE 7: In roaming scenarios, the ARP/APN-AMBR/QCI values provided by the MME for a default bearer may
deviate from the subscribed values depending on the roaming agreement. If the PCC/PCEF rejects the
establishment of the default bearer, this implies that Attach via E-UTRAN will fail. Similarly, if the
PCEF (based on interaction with the PCRF or based on local configuration) upgrades the ARP/APN-
AMBR/QCI parameter values received from the MME, the default bearer establishment and attach may
be rejected by the MME.
3GPP
Release 15 97 3GPP TS 23.401 V15.10.0 (2019-12)
NOTE 8: Subscription data related to bearer level QoS parameter values retrieved from the HSS are not applicable
for dedicated bearers.
For WB-E-UTRA, the decision to establish or modify a dedicated bearer can only be taken by the EPC, and the bearer
level QoS parameter values are always assigned by the EPC.
Dedicated bearers are not supported over NB-IoT. The PDN GW uses the RAT Type to ensure that no dedicated bearers
are active when the UE is accessing over NB-IoT. In case of inter-RAT mobility from WB-EUTRA to NB-IoT, the UE
and MME indicate local deactivation of non-default EPS bearers at TAU as specified in TS 24.301 [46].
The MME shall not modify the bearer level QoS parameter values received on the S11 reference point during
establishment or modification of a default or dedicated bearer (except when the conditions described in NOTE 8 apply).
Consequently, "QoS negotiation" between the E-UTRAN and the EPC during default or dedicated bearer
establishment / modification is not supported. Based on local configuration, the MME may reject the establishment or
modification of a default or dedicated bearer if the bearer level QoS parameter values sent by the PCEF over a GTP
based S8 roaming interface do not comply with a roaming agreement.
NOTE 9: The MME, based on local policies, can downgrade the ARP pre-emption capability, APN-AMBR or
MBR (for GBR bearers) parameters received over S8 and allow the bearer establishment or modification
of a default or dedicated bearer. The HPLMN is expected to set EPS QoS parameters compliant with
roaming agreements, therefore the HPLMN is not informed about any downgrade of EPS bearer QoS
parameters. The consequences of such a downgrade are that APN-AMBR and MBR enforcement at the
HPLMN and at the UE will not be aligned.
At inter-RAT mobility, based on local configuration, the MME may perform a mapping of QCI values for which there
is no mapping defined in Table E.3 or which are not supported in the target RAT.
NOTE 10:The PCRF ensures that the EPS bearer QCI values are aligned with the QCI values mapped by the MME
for the current RAT as described in clause A.4.1.2 of TS 23.203 [6].
The distinction between default and dedicated bearers should be transparent to the access network (e.g. E-UTRAN).
An EPS bearer is referred to as a GBR bearer if dedicated network resources related to a Guaranteed Bit Rate (GBR)
value that is associated with the EPS bearer are permanently allocated (e.g. by an admission control function in the
eNodeB) at bearer establishment/modification. Otherwise, an EPS bearer is referred to as a Non-GBR bearer.
NOTE 11:Admission control can be performed at establishment / modification of a Non-GBR bearer even though a
Non-GBR bearer is not associated with a GBR value.
A dedicated bearer can either be a GBR or a Non-GBR bearer. A default bearer shall be a Non-GBR bearer.
NOTE 12:A default bearer provides the UE with IP connectivity throughout the lifetime of the PDN connection.
That motivates the restriction of a default bearer to bearer type Non-GBR.
3GPP
Release 15 98 3GPP TS 23.401 V15.10.0 (2019-12)
4.7.2.2 The EPS bearer with GTP-based S5/S8
Application / Service Layer
UL Traffic Flow Aggregates DL Traffic Flow Aggregates

UL-TFT DL-TFT
UL-TFT  RB-ID DL-TFT  S5/S8-TEID
RB-ID S1-TEID S1-TEID S5/S8-TEID
UE eNodeB
eNB Serving GW PDN GW
Radio Bearer S1 Bearer S5/S8 Bearer
Figure 4.7.2.2-1: Two Unicast EPS bearers (GTP-based S5/S8)
An EPS bearer is realized by the following elements:
- In the UE, the UL TFT maps a traffic flow aggregate to an EPS bearer in the uplink direction;
- In the PDN GW, the DL TFT maps a traffic flow aggregate to an EPS bearer in the downlink direction;
- A radio bearer (defined in TS 36.300 [5]) transports the packets of an EPS bearer between a UE and an eNodeB.
If a radio bearer exists, there is a one-to-one mapping between an EPS bearer and this radio bearer;
- An S1 bearer transports the packets of an EPS bearer between an eNodeB and a Serving GW;
- An E-RAB (E-UTRAN Radio Access Bearer) refers to the concatenation of an S1 bearer and the corresponding
radio bearer, as defined in TS 36.300 [5].
- An S5/S8 bearer transports the packets of an EPS bearer between a Serving GW and a PDN GW;
- A UE stores a mapping between an uplink packet filter and a radio bearer to create the mapping between a traffic
flow aggregate and a radio bearer in the uplink;
- A PDN GW stores a mapping between a downlink packet filter and an S5/S8 bearer to create the mapping
between a traffic flow aggregate and an S5/S8 bearer in the downlink;
- An eNodeB stores a one-to-one mapping between a radio bearer and an S1 Bearer to create the mapping between
a radio bearer and an S1 bearer in both the uplink and downlink;
- A Serving GW stores a one-to-one mapping between an S1 Bearer and an S5/S8 bearer to create the mapping
between an S1 bearer and an S5/S8 bearer in both the uplink and downlink.
The PDN GW routes downlink packets to the different EPS bearers based on the downlink packet filters in the TFTs
assigned to the EPS bearers in the PDN connection. Upon reception of a downlink data packet, the PDN GW evaluates
for a match, first the downlink packet filter that has the lowest evaluation precedence index and, if no match is found,
proceeds with the evaluation of downlink packet filters in increasing order of their evaluation precedence index. This
procedure shall be executed until a match is found, in which case the downlink data packet is tunnelled to the Serving
GW on the EPS bearer that is associated with the TFT of the matching downlink packet filter. If no match is found, the
downlink data packet shall be sent via the EPS bearer that does not have any TFT assigned. If all EPS bearers
(including the default EPS bearer for that PDN) have been assigned a TFT, the PDN GW shall discard the downlink
data packet.
3GPP
Release 15 99 3GPP TS 23.401 V15.10.0 (2019-12)
4.7.2.3 The EPS bearer with PMIP-based S5/S8

See clause 4.10.3 in TS 23.402 [2].
4.7.3 Bearer level QoS parameters

The EPS bearer QoS profile includes the parameters QCI, ARP, GBR and MBR, described in this clause. This clause
also describes QoS parameters which are applied to an aggregated set of EPS Bearers: APN-AMBR and UE-AMBR.
Each EPS bearer (GBR and Non-GBR) is associated with the following bearer level QoS parameters:
- QoS Class Identifier (QCI);
- Allocation and Retention Priority (ARP).
A QCI is a scalar that is used as a reference to access node-specific parameters that control bearer level packet
forwarding treatment (e.g. scheduling weights, admission thresholds, queue management thresholds, link layer protocol
configuration, etc.), and that have been pre-configured by the operator owning the access node (e.g. eNodeB). A one-to-
one mapping of standardized QCI values to standardized characteristics is captured in TS 23.203 [6].
NOTE 1: On the radio interface and on S1, each PDU (e.g. RLC PDU or GTP-U PDU) is indirectly associated with
one QCI via the bearer identifier carried in the PDU header. The same applies to the S5 and S8 interfaces
if they are based on GTP.
NOTE 2: When required by operator policy, the eNodeB can be configured to also use the ARP priority level in
addition to the QCI to control bearer level packet forwarding treatment in the eNodeB for SDFs having
high priority ARPs.
The ARP shall contain information about the priority level (scalar), the pre-emption capability (flag) and the pre-
emption vulnerability (flag). The primary purpose of ARP is to decide whether a bearer establishment / modification
request can be accepted or needs to be rejected due to resource limitations (typically available radio capacity for GBR
bearers). The priority level information of the ARP is used for this decision to ensure that the request of the bearer with
the higher priority level is preferred. In addition, the ARP can be used (e.g. by the eNodeB) to decide which bearer(s) to
drop during exceptional resource limitations (e.g. at handover). The pre-emption capability information of the ARP
defines whether a bearer with a lower ARP priority level should be dropped to free up the required resources. The pre-
emption vulnerability information of the ARP defines whether a bearer is applicable for such dropping by a pre-emption
capable bearer with a higher ARP priority level.
Once a bearer has been successfully established, the packet handling (e.g. scheduling and rate control) within the
eNodeB, PDN GW, and Serving GW should be solely determined by the following EPS bearer QoS parameters: QCI,
GBR and MBR, and by the AMBR parameters. However, when required by operator policy, the eNodeB can be
configured to also use a bearer's ARP priority level in addition to the QCI to determine the relative priority of the SDFs
for packet handling (e.g. scheduling and rate control) in the eNodeB as defined in TS 23.203 [6] clause 6.1.7.2. This
configuration applies only for bearers with high priority ARPs as defined in TS 23.203 [6] clause 6.1.7.3.
The ARP priority level may be used in addition to the QCI to determine the transport level packet marking, e.g. to set
the DiffServ Code Point. The ARP is not included within the EPS QoS Profile sent to the UE.
NOTE 3: The ARP should be understood as "Priority of Allocation and Retention"; not as "Allocation, Retention,
and Priority".
NOTE 4: Video telephony is one use case where it may be beneficial to use EPS bearers with different ARP values
for the same UE. In this use case an operator could map voice to one bearer with a higher ARP, and video
to another bearer with a lower ARP. In a congestion situation (e.g. cell edge) the eNodeB can then drop
the "video bearer" without affecting the "voice bearer". This would improve service continuity.
NOTE 5: The ARP may also be used to free up capacity in exceptional situations, e.g. a disaster situation. In such a
case the eNodeB may drop bearers with a lower ARP priority level to free up capacity if the pre-emption
vulnerability information allows this.
Each GBR bearer is additionally associated with the following bearer level QoS parameters:
- Guaranteed Bit Rate (GBR);
3GPP
Release 15 100 3GPP TS 23.401 V15.10.0 (2019-12)
- Maximum Bit Rate (MBR).
The GBR denotes the bit rate that can be expected to be provided by a GBR bearer. The MBR limits the bit rate that can
be expected to be provided by a GBR bearer (e.g. excess traffic may get discarded by a rate shaping function). See
clause 4.7.4 for further details on GBR and MBR.
GBR bearers are not supported by NB-IoT. The PDN GW uses the RAT Type to ensure that GBR bearers are not active
when the UE is using NB-IoT.
Each APN access, by a UE, is associated with the following QoS parameter:
- per APN Aggregate Maximum Bit Rate (APN-AMBR).
The subscribed APN-AMBR is a subscription parameter stored per APN in the HSS, which applies as APN-AMBR
unless the APN-AMBR is modified by the MME (e.g in roaming scenarios and/or for usage of NB-IoT) or the PDN
GW, based on local policy (e.g. for RAT Type = NB-IoT) or PCRF interactions. The APN-AMBR limits the aggregate
bit rate that can be expected to be provided across all Non-GBR bearers and across all PDN connections of the same
APN (e.g. excess traffic may get discarded by a rate shaping function). Each of those Non-GBR bearers could
potentially utilize the entire APN-AMBR, e.g. when the other Non-GBR bearers do not carry any traffic. GBR bearers
are outside the scope of APN-AMBR. The P-GW enforces the APN-AMBR in downlink. Enforcement of APN-AMBR
in uplink is done in the UE and additionally in the P-GW.
NOTE 6: All simultaneous active PDN connections of a UE that are associated with the same APN shall be
provided by the same PDN GW (see clauses 4.3.8.1 and 5.10.1).
APN-AMBR applies to all PDN connections of an APN. For the case of multiple PDN connections of an APN, if a
change of APN-AMBR occurs due to local policy or the PDN GW is provided the updated APN-AMBR for each PDN
connection from the MME or PCRF, the PDN GW initiates explicit signaling for each PDN connection to update the
APN-AMBR value.
Each UE in state EMM-REGISTERED is associated with the following bearer aggregate level QoS parameter:
- per UE Aggregate Maximum Bit Rate (UE-AMBR).
The UE-AMBR is limited by a subscription parameter stored in the HSS. The MME shall set the UE-AMBR to the sum
of the APN-AMBR of all active APNs up to the value of the subscribed UE-AMBR. The UE-AMBR limits the
aggregate bit rate that can be expected to be provided across all Non-GBR bearers of a UE (e.g. excess traffic may get
discarded by a rate shaping function). Each of those Non-GBR bearers could potentially utilize the entire UE-AMBR,
e.g. when the other Non-GBR bearers do not carry any traffic. GBR bearers are outside the scope of UE AMBR. The
E-UTRAN enforces the UE-AMBR in uplink and downlink except for PDN connections using the Control Plane CIoT
EPS Optimisation.
The GBR and MBR denote bit rates of traffic per bearer while UE-AMBR/APN-AMBR denote bit rates of traffic per
group of bearers. Each of those QoS parameters has an uplink and a downlink component. On S1_MME the values of
the GBR, MBR, and AMBR refer to the bit stream excluding the GTP-U/IP header overhead of the tunnel on S1_U.
The HSS defines, for each PDN subscription context, the 'EPS subscribed QoS profile' which contains the bearer level
QoS parameter values for the default bearer (QCI and ARP) and the subscribed APN-AMBR value. The subscribed
ARP shall be used to set the priority level of the EPS bearer parameter ARP for the default bearer while the pre-emption
capability and the pre-emption vulnerability information for the default bearer are set based on MME operator policy. In
addition, the subscribed ARP shall be applied by the P-GW for setting the ARP priority level of all dedicated EPS
bearers of the same PDN connection unless a different ARP priority level setting is required (due to P-GW
configuration or interaction with the PCRF).
NOTE 7: The ARP parameter of the EPS bearer can be modified by the P-GW (e.g. based on interaction with the
PCRF due to e.g. MPS user initiated session) to assign the appropriate pre-emption capability and the pre-
emption vulnerability setting.
The ARP pre-emption vulnerability of the default bearer should be set appropriately to minimize the risk of unnecessary
release of the default bearer.
3GPP
Release 15 101 3GPP TS 23.401 V15.10.0 (2019-12)
4.7.4 Support for Application / Service Layer Rate Adaptation

The E-UTRAN/UTRAN and the UE support the RFC 3168 [55] Explicit Congestion Notification (ECN), as described
in TS 36.300 [5], TS 25.401 [16] and TS 26.114 [56]. The IP level ECN scheme enables the E-UTRAN/UTRAN to
trigger a rate adaptation scheme at the application / service / transport layer. To make sufficient time available for end-
to-end codec rate adaptation the E-UTRAN/UTRAN should attempt to not drop any packets on a bearer for a default
grace period of at least 500 ms after it has indicated congestion with ECN on the bearer for packets within the packet
delay budget. During this ECN grace period the E-UTRAN/UTRAN should also attempt to meet the QCI characteristics
/ QoS class associated with the bearer.
NOTE 1: Note that the receiving end-point should interpret all ECN-CE signals received within one end-to-end
round-trip time as one "congestion event" (see IETF RFC 3168 [55] and TS 26.114 [56]).
The MBR of a particular GBR bearer may be set larger than the GBR.
NOTE 2: Enforcement of APN-AMBR / UE-AMBR is independent of whether the MBR of a particular GBR
bearer has been set larger than the GBR (see clause 4.7.3).
The EPC does not support E-UTRAN/UTRAN-initiated "QoS re-negotiation". That is, the EPC does not support an
eNodeB/RNC initiated bearer modification procedure. If an eNodeB/RNC can no longer sustain the GBR of an active
GBR bearer then the eNodeB/RNC should simply trigger a deactivation of that bearer.
4.7.5 Application of PCC in the Evolved Packet System

The Evolved Packet System applies the PCC framework as defined in TS 23.203 [6] for QoS policy and charging
control. PCC functionality is present in the AF, PCEF and PCRF.
An EPS needs to support both PCEF and PCRF functionality to enable dynamic policy and charging control by means
of installation of PCC rules based on user and service dimensions. However, an EPS may only support PCEF
functionality in which case it shall support static policy and charging control.
NOTE: The local configuration of PCEF static policy and charging control functionality is not subject to
standardization. The PCEF static policy and control functionality is not based on subscription
information.
The following applies to the use of dynamic policy and charging control in EPS:
- The service level (per SDF) QoS parameters are conveyed in PCC rules (one PCC rule per SDF) over the Gx
reference point. The service level QoS parameters consist of a QoS Class Identifier (QCI) Allocation and
Retention Priority (ARP) and authorised Guaranteed and Maximum Bit Rate values for uplink and downlink.
The QCI is a scalar that represents the QoS characteristics that the EPS is expected to provide for the SDF. ARP
is an indicator of the priority for the SDF that is used to decide about the assignment of resources due to resource
limitations. The service level ARP assigned by PCRF in a PCC rule may be different from the bearer level ARP
stored in subscription data;
- The set of standardized QCIs and their characteristics that the PCRF in an EPS can select from is provided in
TS 23.203 [6]. It is expected that the PCRF selects a QCI in such a way that the IP-CAN receiving it can support
it;
- It is not required that an IP-CAN supports all standardized QCIs;
- In the case of IP address configuration subsequent to initial attachment, i.e. through DHCP mechanism to
complete the IP address configuration, the PDN GW/PCEF shall notify the PCRF of the UE's IP address by
means of an IP-CAN Session Modification procedure or IP-CAN Session Establishment procedure as defined in
TS 23.203 [6] when it is assigned. If the PCRF response leads to an EPS bearer modification the PDN GW
should initiate a bearer update procedure;
- For local breakout, the visited network has the capability to reject the QoS authorized by the home network
based on operator policies.
The following applies regardless of whether dynamic or static policy and charging control is used in EPS:
- For E-UTRAN the value of the ARP of an EPS bearer is identical to the value of the ARP of the SDF(s) mapped
to that EPS bearer;
3GPP
Release 15 102 3GPP TS 23.401 V15.10.0 (2019-12)
- For the same UE/PDN connection: SDFs associated with different QCIs or with the same service-level QCI but
different ARP shall not be mapped to the same EPS bearer;
- The bearer level QCI of an EPS bearer is identical to the value of the QCI of the SDF(s) mapped to that EPS
bearer.
4.7.6 Bearer Control Mode in EPC

The Bearer Control Mode (BCM) for E-UTRAN access is always UE/NW. Hence, explicit signalling between the UE
and the network to determine BCM for E-UTRAN access does not occur.
GERAN/UTRAN/E-UTRAN capable UEs negotiate the BCM of a PDN Connection applicable for GERAN/UTRAN
access during E-UTRAN Initial Attach and during UE Requested PDN Connectivity procedure. Such UEs provide the
Network Request Support UE (NRSU) parameter to the PDN GW in PCO. The PDN GW derives the BCM applicable
to GERAN/UTRAN access based on the NRSU and operator policy. The selected BCM, valid for GERAN/UTRAN, is
provided back to the UE in PCO IE in the E-UTRAN Attach Accept or PDN Connectivity Accept message. The
selected BCM is also stored in the PDN GW and the UE, and applied by UE upon moving to GERAN or UTRAN
access unless explicitly informed by PDN GW of a change in BCM (see TS 23.060 [7]) via PCO IE.
NOTE 1: In Rel-8 it was not mandatory for GERAN/UTRAN/E-UTRAN capable UEs to provide NRSU to the
PDN GW during E-UTRAN Initial Attach and UE Requested PDN Connectivity procedure.
When a GERAN/UTRAN/E-UTRAN capable UE moves from UTRAN or GERAN access to E-UTRAN access, it
stores the BCM used in UTRAN or GERAN access to be used again when the UE moves back to UTRAN or GERAN
access unless explicitly informed by PDN GW of a change in BCM (see TS 23.060 [7]) via the PCO IE.
If PCC is deployed, the PDN GW requests PCRF to perform BCM selection for the RAT the UE is accessing at
IP-CAN session establishment and IP-CAN session modification. The PCRF, determines the applicable BCM, based on
a number of factors (see TS 23.203 [6]), and informs the PDN GW. If the BCM has changed, the PDN GW informs the
UE of the new BCM via the PCO IE.
4.7.7 Support of rate control of user data using CIoT EPS Optimisation
4.7.7.1 General
The rate of user data sent to and from a UE (e.g. a UE using CIoT EPS Optimisations) can be controlled in two different
ways:
- Serving PLMN Rate Control
- APN Rate Control
Serving PLMN Rate Control is intended to allow the Serving PLMN to protect its MME and the Signalling Radio
Bearers in the E-UTRAN from the load generated by NAS Data PDUs.
APN Rate Control is intended to allow HPLMN operators to offer customer services such as "maximum of Y messages
per day".
NOTE: Existing AMBR mechanisms are not suitable for such a service since, for radio efficiency and UE battery
life reasons, an AMBR of e.g. > 100kbit/s is desirable and such an AMBR translates to a potentially large
daily data volume.
The PDN GW in the visited PLMN may send the APN rate control parameter for an emergency PDN connection.
4.7.7.2 Serving PLMN Rate Control

The Serving PLMN Rate Control value is configured in the MME.
NOTE 1: Homogeneous support of Serving PLMN Rate Control in a network is assumed.
At PDN connection establishment, the MME may inform the UE and PDN GW/SCEF (as specified in TS 24.301 [46]
and TS 29.274 [43]) of any per PDN connection local Serving PLMN Rate Control that the Serving PLMN intends to
enforce for NAS Data PDUs. The MME shall only indicate Serving PLMN Rate Control command to the PDN GW if
3GPP
Release 15 103 3GPP TS 23.401 V15.10.0 (2019-12)
the PDN connection is using S11-U and set to Control Plane only. The MME shall only indicate Serving PLMN Rate
Control command to the SCEF if that PDN connection is using SCEF.
This rate control is operator configurable and expressed as "X NAS Data PDUs per deci hour" where X is an integer
that shall not be less than 10. There are separate limits for uplink and downlink NAS Data PDUs:
- The UE shall limit the rate at which it generates uplink NAS Data PDUs to comply with the Serving PLMN
policy. In the UE the indicated rate control applies only on the PDN connection where it was received, and
therefore the UE shall limit the rate of its uplink NAS Data PDUs to comply with the rate that is indicated for the
PDN connection. The indicated rate is valid until the PDN connection is released.
- The PDN GW/SCEF shall limit the rate at which it generates downlink Data PDUs. In the PDN GW/SCEF the
indicated rate control applies only on the PDN connection where it was received, and therefore the
PDN GW/SCEF shall limit the rate of its downlink Data PDUs to comply with the rate that is indicated for the
PDN connection.
- The MME may enforce these limits per PDN connection by discarding or delaying packets that exceed this
limitthese limits. The Serving PLMN Rate does not include SMS sent via NAS Transport PDUs. The MME starts the
Serving PLMN Rate Control when the first NAS Data PDU is received.
NOTE 2: If the UE/PDN GW/SCEF starts the Serving PLMN rate control at a different time than the MME, PDUs
sent within the limit enforced at the UE/PDN GW/SCEF can still exceed the limit enforced by the MME.
NOTE 3: It is assumed that the Serving PLMN Rate is sufficiently high to not interfere with the APN Rate Control
as the APN Rate Control, if used, is assumed to allow fewer messages. NAS PDUs related to exception
reports are not subject to the Serving PLMN Rate Control.
4.7.7.3 APN Rate Control

The APN Rate Control is configured in the PDN GW or in the SCEF. The PDN GW or SCEF can send an APN Uplink
Rate Control command to the UE using the PCO information element.
The APN Uplink Rate Control applies to data PDUs sent on that APN by either Data Radio Bearers (S1-U) or
Signalling Radio Bearers (NAS Data PDUs).
The rate control information is separate for uplink and downlink and in the form of:
- a positive integer 'number of packets per time unit', and
- an indication as to whether or not exception reports can still be sent if this rate control limit has been met, and
- if the UE indicated support for it, an integer 'number of additional allowed exception report packets per time unit'
once the rate control limit has been reached.
UEs supporting APN Rate Control shall support the 'number of additional allowed exception report packets per time
unit' and shall provide an indication to the CN at PDN connection establishment.
NOTE 1: Pre-Rel-14 UEs do not support the 'number of additional allowed exception report packets per time unit'
and do not send an indication to the CN at PDN connection establishment.
The UE shall comply with this uplink rate control instruction. If the UE exceeds the uplink 'number of packets per time
unit', the UE may still send uplink exception reports if allowed and the 'number of additional allowed exception reports
per time unit' has not been exceeded. The UE shall consider this rate control instruction as valid until it receives a new
one from either PDN GW or from SCEF.
When the last PDN connection using a given APN is released, the APN Rate Control Status (including the number of
packets still allowed in the given time unit, the number of additional exception reports still allowed in the given time
unit and the termination time of the current APN Rate Control validity period) may be stored in the MME so that it can
be retrieved for a subsequent re-establishment of a new first PDN connection for that given APN.
At subsequent establishment of a new first PDN connection for that given APN, the PDN GW/SCEF may receive the
previously stored APN Rate Control Status and, if the first APN Rate Control validity period has not expired, it applies
the received APN Rate Control Status and provides the related parameters to the UE in the PCO (instead of the
configured APN Rate Control parameters). If the initially applied parameters differ from the configured APN Rate
3GPP
Release 15 104 3GPP TS 23.401 V15.10.0 (2019-12)
Control parameters, the PDN GW/SCEF uses the configured APN Rate Control parameters once the first APN Rate
Control validity period expires, and sends an update to the UE with the configured APN Rate Control parameters.
NOTE 2: The storage of the APN Rate Control Status information for very long time intervals can be
implementation specific.
The PDN GW or SCEF realises the APN rate control based on a 'maximum allowed rate' per direction. If PDN GW or
SCEF provided the 'number of additional allowed exception report packets per time unit' to the UE, then the 'maximum
allowed rate' is equal to the 'number of packets per time unit' plus the 'number of additional allowed exception report
packets per time unit'. Otherwise, the 'maximum allowed rate' is equal to the 'number of packets per time unit'.
NOTE 3: Pre-Rel-14 UEs understand only the 'number of packets per time unit', and, if an indication that exception
reports are allowed has been sent to such UEs, there is a risk that exception report packets are discarded
by the PDN GW or SCEF. To overcome this problem, the PDN GW or SCEF can still apply a configured
'number of additional allowed exception report packets per time unit' even though not sent to pre-Rel-14
UEs.
The PDN GW or SCEF may enforce the uplink rate by discarding or delaying packets that exceed the 'maximum
allowed rate'. The PDN GW or SCEF shall enforce the downlink rate by discarding or delaying packets that exceed the
downlink part of the 'maximum allowed rate'.
NOTE 4: It is assumed that the Serving PLMN Rate is sufficiently high to not interfere with the APN Rate Control
as the APN Rate Control, if used, is assumed to allow fewer messages. NAS PDUs related to exception
reports are not subject to the Serving PLMN Rate Control.
4.7.8 Inter-UE QoS for NB-IoT UEs using Control Plane CIoT EPS
Optimisation
To allow the E-UTRAN to prioritise resource allocation between different NB-IoT UEs when some of the UEs are
using the Control Plane CIoT EPS Optimisation, the eNB may request, based on configuration, the MME to supply the
eNB with the negotiated QoS profile for any UE that is using the Control Plane CIoT EPS Optimisation.
The QoS profile sent to the eNB by the MME consists of the E-RAB Level QoS Parameter in the E-RAB to be Setup
List IE (see TS 36.413 [36]).
In order to reduce signalling load on the MME, the eNB may be configured to request the QoS profile from the MME
by using the UE's S-TMSI as identifier, e.g., when the eNB's NB-IoT load exceeds certain threshold(s) or when the eNB
needs to cache the QoS profile.
If the UE has more than one EPS bearer active, the MME sends QoS profile for only one EPS bearer to the eNB. In this
case the MME uses local configuration (e.g. considering table 6.1.7 in TS 23.203 [6], the MME chooses the non-GBR
EPS bearer with the QCI corresponding to the highest Priority Level) to determine which EPS bearer's QoS to send to
the eNB. If the MME has no EPS bearers active for the UE, then this fact is indicated to the eNB.
The eNB can use the QoS profile to assist with resource prioritisation decisions between different NB-IoT UEs
(irrespective of whether the UE/eNB is using the Control Plane CIoT EPS Optimisation, or, the User Plane CIoT EPS
Optimisation).
4.8 Compatibility Issues

4.8.1 Network Configuration for Interaction with UTRAN/GERAN
GPRS idle mode mobility within GERAN or UTRAN and also between GERAN and UTRAN specifies a set of
sequence number handling functions, e.g. the exchange of sequence numbers during Routing Area Update procedures.
EPS idle mode mobility procedures don't specify any such sequence number mappings for IRAT mobility scenarios. To
avoid interoperation issues a network that deploys E-UTRAN together with GERAN and/or UTRAN shall not configure
usage of the GPRS feature "reordering required" for PDP contexts of PDP type IPv4, IPv6 or IPv4v6. Also the network
shall not configure usage of lossless PDCP of UTRAN and the GERAN SGSN shall not configure usage of
acknowledged mode LLC/NSAPI/SNDCP.
3GPP
Release 15 105 3GPP TS 23.401 V15.10.0 (2019-12)
4.9 Paging Policy Differentiation

Paging policy differentiation is an optional feature that allows the MME, based on operator configuration, to apply
different paging strategies as defined in clause 5.3.4.3 for different traffic or service types provided within the same
PDN connection.
When it supports Paging Policy Differentiation feature, the Serving GW provides a Paging Policy Indication in the
Downlink Data Notification. The Paging Policy Indication is based on information received with the downlink packet
that triggers the Downlink Data Notification. For example, as defined in TS 23.228 [52], the P-CSCF may support
Paging Policy Differentiation by marking packet(s) to be sent towards the UE that relate to specific IMS services (e.g.
conversational voice as defined in IMS multimedia telephony service).
The PDN GW shall not modify the received downlink IP packet e.g. the DSCP (IPv4) / TC (IPv6). Unconditionally, for
each bearer and for each packet of PDN type IPv4, IPv6 or IPv4v6 that triggers a Downlink Data Notification, the SGW
shall send the DSCP in TOS (IPv4) / TC (IPv6) information received in the IP payload of the GTP-U packet from the
PDN GW in the Paging Policy Indication in the Downlink Data Notification.
It shall be possible for the operator to configure the MME in such a way that the Paging Policy Indicator only applies to
certain HPLMNs and/or APNs and/or QCIs.
NOTE 1: Network configuration needs to ensure that the information used as a trigger for Paging Policy Indication
is not changed within the EPS.
NOTE 2: Network configuration needs to ensure that the specific DSCP in TOS (IPv4) / TC (IPv6) value, used as a
trigger for Paging Policy Indication, is managed correctly in order to avoid the accidental use of certain
paging policies.
4.10 Introduction of CIoT EPS Optimisations

CIoT EPS Optimisations provide improved support of small data transfer. One optimisation is based on User Plane
transport of user data and is referred to as User Plane CIoT EPS Optimisation. Another optimisation, known as Control
Plane CIoT EPS Optimisation, transports user data or SMS messages via MME by encapsulating them in NAS,
reducing the total number of control plane messages when handling a short data transaction. For EPC Mobile
Originated Location Request (EPC-MO-LR) and EPC Mobile Terminated Location Request (EPC-MT-LR) when the
UE and network support Control Plane CIoT EPS Optimisation, Control Plane Service Request is used. These
optimisations can be used separately e.g. if the UE or the network supports one of them, or in parallel if the UE and the
network supports both. If both the Control Plane and User Plane CIoT EPS Optimisations are supported for a UE, the
PDN connections that only use the Control Plane CIoT EPS Optimisation, i.e. the MME has included Control Plane
Only Indicator in the ESM request, will only be handled via the Control Plane CIoT EPS Optimisation. All other PDN
connections are handled using Control Plane or User Plane CIoT EPS Optimisations. In addition, the Control Plane
CIoT Optimisation can be used to support PDN connections to an SCEF, while regular S1-U data transfer is used
independently to support PDN connections to P-GW. The MME shall consistently include Control Plane Only Indicator
either in all SGi PDN connections of a UE or in none of them. All the SGi PDN connections of a UE shall either use
S11-U or S1-U at any point in time.
The CIoT data could include e.g. status information, measurement data from Machine-to-Machine applications.
Several types of MME are envisaged, e.g.
- an MME that supports either User Plane or Control Plane CIoT EPS Optimisation;
- an MME that supports both User Plane and Control Plane CIoT EPS Optimisations;
- an MME that does not support any CIoT EPS Optimisations.
The E-UTRAN shall support the routeing of UEs to an MME that can process the request from the UE.
The CIoT EPS Optimisations are negotiated as described in clause 4.3.5.10 "Preferred and Supported Network
Behaviour".
CIoT EPS Optimisations may be supported also by UEs that are not limited to low complexity and low throughput
applications for Machine Type Communications.
3GPP
Release 15 106 3GPP TS 23.401 V15.10.0 (2019-12)
If Control Plane CIoT EPS Optimisation applies, separation of S11-U from S1-U may be required, and if required, the
MME and the Serving GW shall handle the IP address and TEID for the S1-U and the address and TEID for the S11-U
separately.
NOTE: Homogeneous support of separation of S11-U from S1-U in the MMEs and Serving GWs is assumed.
4.11 User Plane CIoT EPS Optimisation

The User Plane CIoT EPS Optimisation functionality enables support for transfer of user plane data without the need
for using the Service Request procedure to establish Access Stratum (AS) context in the serving eNodeB and UE.
If the following preconditions are met:
- UE and MME support User Plane CIOT EPS Optimisation as defined in clause 4.3.5.10,
- MME indicates "UE User Plane CIoT Support Indicator" IE to "supported" as defined in TS 36.413 [36],
- and the UE performs an initial connection establishment that establishes the AS bearers and the AS security
context in the network and UE,
then the RRC connection can be suspended by means of a Connection Suspend Procedure (see clause 5.3.4A).
Based on trigger from the NAS layer when UE is in ECM-IDLE including if it attempts to send data using Control
Plane CIoT EPS Optimisation as defined in clause 5.3.4B, the UE shall attempt the Connection Resume procedure, see
clause 5.3.5A and TS 24.301 [46]. If the Connection Resume procedure fails, the UE initiates the pending NAS
procedure, see TS 24.301 [46]. To maintain support for User Plane CIoT EPS Optimisation at UE mobility between
cells configured on different eNodeBs, the AS Context should be transferred between the eNodeBs, see TS 36.300 [5]
and TS 36.423 [76].
By using the Connection Suspend procedure, see clause 5.3.5A and TS 36.300 [5]:
- the UE at transition into ECM-IDLE stores the AS information;
- the eNodeB stores the AS information, the S1AP association and the bearer context for that UE;
- MME stores the S1AP association and the bearer context for that UE and enters ECM-IDLE.
In the context of this functionality, the UE and the eNodeB store the relevant AS information at transition into ECM-
IDLE.
By using the Connection Resume procedure, see clause 5.3.5A and TS 36.300 [5]:
- the UE resumes the connection with the network using the AS information stored during the Connection
Suspend procedure;
- the, potentially new, eNodeB notifies the MME that the connection with the UE has been securely resumed and
the MME enters ECM-CONNECTED.
If a MME has a S1AP association stored for a UE and the MME receives for that UE a EMM procedure over another
UE-associated logical S1-connection or at Tracking Area Update procedure with MME change, or SGSN Context
Request, when the UE has re-attached, or when the UE has been Detached, the MME and the previously involved
eNodeB shall delete that stored S1AP association using the S1 Release procedure, see clause 5.3.5 and TS 36.413 [36].
4.12 Supporting up to 15 EPS bearers per UE

A UE attached to WB-E-UTRAN access, including for dual connectivity using E-UTRAN access as described in
clause 4.3.2a, may support 8 or 15 EPS bearers. To enable support of establishing 15 EPS bearers, it requires the EPC
connected to the E-UTRAN access to support 15 EPS bearers for such UEs.
If the UE supports 15 EPS bearers, then the UE shall indicate this to the MME in NAS signalling as defined in
TS 24.301 [46].
3GPP
Release 15 107 3GPP TS 23.401 V15.10.0 (2019-12)
The network shall support E-UTRAN idle mode mobility and handover procedures in such PLMNs, where only part of
the network nodes have been upgraded to support 15 EPS bearers. In case of mobility procedures involving target nodes
not supporting 15 EPS bearers, additional bearers not supported by the non-upgraded nodes should be thus released.
The network shall homogeneously support 15 EPS bearers per UE, at least per MME pool area/SGW serving area, in
order to avoid EPS bearer deactivations and attempts from services to re-activate the deactivated EPS bearers caused by
UE mobility within that area, by defining the tracking areas accordingly (see clause 4.3.5.3).
The MME shall provide the UE with a TAI List such that it triggers the UE to perform the TAU procedure, as defined
in clause 5.3.3.0, when the UE enters and exits the area with support for 15 EPS bearers per UE. The TAU procedure
execution enables the nodes in the supporting area to identify a supporting UE when it enters the area. When exiting the
area, also enables the nodes to remove bearer resources for the UE towards nodes without support for 15 EPS bearers
per UE.
NOTE 1: In order for the above TAI List handling to be fully successful, the network requires the PGWs the UE is
connected to from these MME pool area/SGW serving area to be upgaded to support 15 EPS bearers.
For a UE supporting 15 EPS bearers, mobility to UTRAN or GERAN may also lead to selective release of EPS bearers,
due to the lack of support of 15 PDP contexts in the GPRS core network and Radio Access networks.
NOTE 2: EPS bearers need to be released either because the UE has more than 8 active EPS bearers, or because
they are identified by EPS Bearer Identities not supported.
In order to minimize the impact from release of bearers not supported by the target nodes during mobility, the MME
should be able to allocate the EPS bearer IDs in such way that the bearers with higher operator preference will be
preserved in case of mobility involving legacy target nodes. This prioritised bearer allocation should be based on, at
least, the Allocation Retention Priority of the EPS bearers and may take other bearer parameters (e.g. QCI, APN) into
consideration.
All PDN GWs in a PLMN shall support 15 EPS bearers. MME may be configured to take into account additional PDN
GW information such as whether the HPLMN supports 15 EPS bearers when selecting PDN GW (e.g. in case of
roaming users Home Routed PDN GW selection) for UEs supporting 15 EPS bearers.
For inter-PLMN handover, support of 15 EPS bearers is based on MME configuration according to operator policy (e.g.
bilateral agreements between operators).
5 Functional description and information flows
5.1 Control and user planes

5.1.0 General
NOTE:
- Refer to TS 23.402 [2] for the corresponding protocol stack for PMIP based S5/S8.
- Refer to TS 23.203 [6] for the corresponding protocol stack for Policy Control and Charging (PCC)
function related reference points.
5.1.1 Control Plane
5.1.1.1 General
The control plane consists of protocols for control and support of the user plane functions:
- controlling the E-UTRA network access connections, such as attaching to and detaching from E-UTRAN;
- controlling the attributes of an established network access connection, such as activation of an IP address;
- controlling the routing path of an established network connection in order to support user mobility; and
3GPP
Release 15 108 3GPP TS 23.401 V15.10.0 (2019-12)
- controlling the assignment of network resources to meet changing user demands.
The following control planes are used in E-UTRAN mode.
5.1.1.2 eNodeB - MME
S1-AP S1-AP
SCTP SCTP
IP IP
L2 L2
L1 L1
eNodeB S1-MME
MME
Legend:
- S1 Application Protocol (S1-AP): Application Layer Protocol between the eNodeB and the MME.
- Stream Control Transmission Protocol (SCTP): This protocol guarantees delivery of signalling
messages between MME and eNodeB (S1). SCTP is defined in RFC 4960 [35].
Figure 5.1.1.2-1: Control Plane for S1-MME Interface
NOTE: Refer to TS 36.300 [5] for the corresponding control plane for the HeNB Subsystem - MME.
5.1.1.3 UE - MME
NAS NAS
Relay
RRC S1-AP
RRC S1-AP
PDCP PDCP SCTP SCTP
RLC RLC IP IP
MAC MAC L2 L2
L1 L1 L1 L1
LTE-Uu S1-MME
UE eNodeB MME
Legend:
- NAS: The NAS protocol supports mobility management functionality and user plane bearer activation,
modification and deactivation. It is also responsible of ciphering and integrity protection of NAS signalling.
- LTE-Uu: The radio protocol of E-UTRAN between the UE and the eNodeB is specified in TS 36.300 [5].
Figure 5.1.1.3-1: Control Plane UE - MME
3GPP
Release 15 109 3GPP TS 23.401 V15.10.0 (2019-12)
5.1.1.4 SGSN - MME
GTP-C GTP-C
UDP UDP
IP IP
L2 L2
L1 L1
S3
SGSN MME
Legend:
- GPRS Tunnelling Protocol for the control plane (GTP-C): This protocol tunnels signalling messages
between SGSN and MME (S3).
- User Datagram Protocol (UDP): This protocol transfers signalling messages. UDP is defined in
RFC 768 [26].
Figure 5.1.1.4-1: Control Plane for S3 Interface
5.1.1.5 SGSN - S-GW
GTP-C GTP-C
UDP UDP
IP IP
L2 L2
L1 L1
SGSN S4
S-GW
Legend:
between SGSN and S-GW (S4).
RFC 768 [26].
Figure 5.1.1.5-1: Control Plane for S4 interface
3GPP
Release 15 110 3GPP TS 23.401 V15.10.0 (2019-12)
5.1.1.6 S-GW - P-GW
GTP-C GTP-C
UDP UDP
IP IP
L2 L2
L1 L1
S5 or S8
S- GW P-GW
Legend:
between S-GW and P-GW (S5 or S8).
- User Datagram Protocol (UDP): This protocol transfers signalling messages between S-GW and P-GW.
UDP is defined in RFC 768 [26].
Figure 5.1.1.6-1: Control Plane for S5 and S8 interfaces
5.1.1.7 MME - MME
GTP-C GTP-C
UDP UDP
IP IP
L2 L2
L1 L1
S10
MME MME
Legend:
between MMEs (S10).
- User Datagram Protocol (UDP): This protocol transfers signalling messages between MMEs. UDP is
defined in RFC 768 [26].
3GPP
Release 15 111 3GPP TS 23.401 V15.10.0 (2019-12)
5.1.1.8 MME - S-GW
GTP-C GTP-C
UDP UDP
IP IP
L2 L2
L1 L1
S11
MME S-GW
Legend:
between MME and S-GW (S11).
RFC 768 [26].
5.1.1.9 MME - HSS
Diameter Diameter
SCTP SCTP
IP IP
L2 L2
L1 L1
S6a
MME HSS
Legend:
- Diameter: This protocol supports transferring of subscription and authentication data for
authenticating/authorizing user access to the evolved system between MME and HSS (S6a). Diameter is
- Stream Control Transmission Protocol (SCTP): This protocol transfers signalling messages. SCTP is
Figure 5.1.1.9-1: Control Plane for S6a interface
3GPP
Release 15 112 3GPP TS 23.401 V15.10.0 (2019-12)
5.1.1.10 MME - EIR
Diameter Diameter
SCTP SCTP
IP IP
L2 L2
L1 L1
S13
MME EIR
Legend:
- Diameter: This protocol supports UE identity check procedure between MME and EIR (S13). Diameter is
- Stream Control Transmission Protocol (SCTP): This protocol transfers signalling messages. SCTP is
5.1.1.11 Void
5.1.1.12 MME - CSS
Diameter Diameter
SCTP SCTP
IP IP
L2 L2
L1 L1
MME S7a CSS
Legend:
Diameter: This protocol supports transferring of CSG subscription data for roaming subscribers only
between MME and CSS (S7a). Diameter is defined in RFC 3588 [31].
Stream Control Transmission Protocol (SCTP): This protocol transfers signalling messages. SCTP is
Figure 5.1.1.12-1: Control Plane for S7a interface
3GPP
Release 15 113 3GPP TS 23.401 V15.10.0 (2019-12)
5.1.1.13 MME - RCAF
Nq-AP Nq-AP
SCTP SCTP
IP IP
L2 L2
L1 L1
Nq
MME RCAF
Legend:
Nq-AP: This application layer protocol supports the IMSI and APN retrieval procedure between the RCAF
and the MME.
Stream Control Transmission Protocol (SCTP): This protocol transfers signalling messages. SCTP is
Figure 5.1.1.13-1: Control Plane for Nq interface
5.1.2 User Plane
5.1.2.1 UE - P-GW user plane with E-UTRAN
Application
IP IP
Relay Relay
PDCP GTP-U
PDCP GTP-U GTP-U
GTP-U
RLC RLC UDP/IP UDP/IP UDP/IP UDP/IP
MAC MAC L2 L2 L2 L2
L1 L1 L1 L1 L1 L1
LTE-Uu S1-U S5/S8 SGi

a
UE eNodeB Serving GW PDN GW
Legend:
- GPRS Tunnelling Protocol for the user plane (GTP-U): This protocol tunnels user data between
eNodeB and the S-GW as well as between the S-GW and the P-GW in the backbone network. GTP shall
encapsulate all end user IP packets.
- MME controls the user plane tunnel establishment and establishes User Plane Bearers between eNodeB
and S-GW.
- UDP/IP: These are the backbone network protocols used for routing user data and control signalling.
- LTE-Uu: The radio protocols of E-UTRAN between the UE and the eNodeB are specified in TS 36.300 [5].
Figure 5.1.2.1-1: User Plane
3GPP
Release 15 114 3GPP TS 23.401 V15.10.0 (2019-12)
5.1.2.2 eNodeB - S-GW
GTP-U GTP-U
UDP UDP
IP IP
L2 L2
L1 L1
S1-U
eNodeB S-GW
Legend:
eNodeB and S-GW.
- User Datagram Protocol (UDP): This protocol transfers user data. UDP is defined in RFC 768 [26].
Figure 5.1.2.2-1: User Plane for eNodeB – S-GW
NOTE: Refer to TS 36.300 [5] for the corresponding user plane for the HeNB Subsystem - S-GW.
5.1.2.3 UE - PDN GW user plane with 2G access via the S4 interface
Application
IP IP
Relay Relay
SNDCP GTP -U
SNDCP GTP -U GTP -U GTP -U
LLC LLC UDP UDP UDP UDP
Relay BSSGP
RLC IP IP IP IP
RLC BSSGP
MAC MAC Networ k Network L2 L2 L2 L2

Service Service
GSM RF GSM L1bis L1bis L1 L1 L1 L1

RF
Um Gb S4 S5/S8 SGi
UE BS SGSN Serving G W PDN GW
Legend:
- GPRS Tunnelling Protocol for the user plane (GTP-U): This protocol tunnels user data between SGSN
and the S-GW as well as between the S-GW and the P-GW in the backbone network. GTP shall
- Protocols on the Um and the Gb interfaces are described in TS 23.060 [7].
Figure 5.1.2.3-1: User Plane for A/Gb mode
3GPP
Release 15 115 3GPP TS 23.401 V15.10.0 (2019-12)
Application
IP
IP
Relay Relay GTP -U

PDCP
PDCP GTP -U GTP -U GTP -U
RLC RLC UDP/IP UDP/IP UDP/IP UDP/IP
MAC MAC L2 L2 L2 L2
L1 L1 L1 L1 L1 L1
Uu Iu S5/S8 SGi
UE UTRAN Serving GW PDN GW
Legend:
UTRAN and the S-GW as well as between the S-GW and the P-GW in the backbone network. GTP shall
- Protocols on the Uu interface are described in TS 23.060 [7].
- SGSN controls the user plane tunnel establishment and establish a Direct Tunnel between UTRAN and
S-GW as shown in Figure 5.1.2.4-1.
Figure 5.1.2.4-1: User Plane for UTRAN mode and Direct Tunnel on S12
3GPP
Release 15 116 3GPP TS 23.401 V15.10.0 (2019-12)
Application
IP
IP
Relay Relay Relay GTP -U

PDCP
GTP -U GTP -U
PDCP GTP -U GTP -U GTP -U
RLC RLC UDP/IP UDP/IP UDP/IP UDP/IP UDP/ IP UDP/IP
MAC MAC L2 L2 L2 L2 L2 L2
L1 L1 L1 L1 L1 L1 L1 L1
Uu Iu S4 S5/S8 SGi
UE UTRAN SGSN Servin g GW PDN GW
NOTE: Please refer to TS 23.402 [2] for the corresponding stack for PMIP based S5/S8.
Legend:
UTRAN and the SGSN, between SGSN and S-GW as well as between the S-GW and the P-GW in the
backbone network. GTP shall encapsulate all end user IP packets.
- Protocols on the Uu and the Iu interfaces are described in TS 23.060 [7].
- SGSN controls the user plane tunnel establishment and establishes a tunnel between SGSN and S-GW. If
Direct Tunnel is established between UTRAN and S-GW, see Figure 5.1.2.4-1.
Figure 5.1.2.5-1: User Plane for Iu mode
3GPP
Release 15 117 3GPP TS 23.401 V15.10.0 (2019-12)
5.1.2.6 UE - P-GW user plane with Control Plane CIoT EPS Optimisations
IP/Non IP IP/Non IP
NAS
NAS GTP-u GTP-u
PDCP
S1AP UDP UDP
PDCP S1AP
RLC RLC SCTP/IP SCTP/IP IP IP
MAC MAC L2 L2 L2 L2
L1 L1 L1 L1 L1 L1
S1-MME S11 SGi
UE E-UTRAN MME S/P-GW
Legend:
- GTP-u (GPRS Tunnelling Protocol User plane): This protocol tunnels user data between MME and the
S-GW as well as between the S-GW and the P-GW in the backbone network. GTP shall encapsulate all
end user IP packets.
- NAS: this is the Non Access Stratum Layer used to carry Data between UE and MME and may include
Header compression and security functions of user plane IP data. Whether a convergence protocol
sublayer may be required for this purpose is a stage 3 matter.
Figure 5.1.2.6-1: User Plane with Control Plane CIoT EPS Optimisations
5.2 Identities
5.2.1 EPS bearer identity
An EPS bearer identity uniquely identifies an EPS bearer for one UE accessing via E-UTRAN. The EPS Bearer Identity
is allocated by the MME. When using an EPS Radio Bearer, there is a one to one mapping between EPS RB and EPS
Bearer, and the mapping between EPS RB Identity and EPS Bearer Identity is made by E-UTRAN. The E-RAB ID
value used at S1 and X2 interfaces to identify an E-RAB is the same as the EPS Bearer ID value used to identify the
associated EPS Bearer. When using Control Plane CIoT EPS Optimisation for user data transport for the PDN
connectivity service, the MME (for uplink) and UE (for downlink) uses the EPS Bearer Identity contained within the
NAS PDUs to identify the associated EPS bearer.
When there is a mapping between an EPS bearer and a PDP context, the same identity value is used for the EPS bearer
ID and the NSAPI/RAB ID.
In some SM signalling messages in GERAN/UTRAN, transaction identifier (TI) represents NSAPI. The TI is
dynamically allocated by the UE for UE-requested PDP context activation, and by the network for network-requested
PDP context activation. A corresponding allocation is also needed for EPS Bearers in order to successfully transfer
Bearers to GERAN/UTRAN. The TI is deallocated when a PDP context/EPS Bearer has been deactivated. TI usage is
5.2.2 Globally Unique Temporary UE Identity

The MME shall allocate a Globally Unique Temporary Identity (GUTI) to the UE. The GUTI is defined in
TS 23.003 [9].
3GPP
Release 15 118 3GPP TS 23.401 V15.10.0 (2019-12)
5.2.3 Tracking Area Identity (TAI)

This is the identity used to identify tracking areas. The Tracking Area Identity is constructed from the MCC (Mobile
Country Code), MNC (Mobile Network Code) and TAC (Tracking Area Code).
A TAI should be associated with a single time zone. All TAIs served by one eNodeB shall be in the same time zone.
NOTE: Changes in the TAI of a cell can occur but are normally infrequent and linked with O+M activity.
5.2.4 eNodeB S1-AP UE Identity (eNodeB S1-AP UE ID)

This is the temporary identity used to identify a UE on the S1-MME reference point within the eNodeB. It is unique
within the eNodeB.
5.2.5 MME S1-AP UE Identity (MME S1-AP UE ID)

This is the temporary identity used to identify a UE on the S1-MME reference point within the MME. It is unique
within the MME.
5.2.6 Closed Subscriber Group ID

A CSG ID is a unique identifier within the scope of PLMN defined in TS 23.003 [9] which identifies a Closed
Subscriber Group (CSG) in the PLMN associated with a CSG cell or group of CSG cells.
5.3 Authentication, security and location management

5.3.1 IP address allocation
5.3.1.1 General
The procedures of clause 5.3.1 apply to UEs activating a PDN connection of PDN Type IPv4, IPv6 or IPv4v6. Part of it
also applies for PDN Type Non-IP when SGi PtP Tunnelling based on UDP/IP, see clause 4.3.17.8, is used.
A UE shall perform the address allocation procedures for at least one IP address (either IPv4 address or IPv6 prefix)
after the default bearer activation if no IPv4 address is allocated during the default bearer activation.
One of the following ways shall be used to allocate IP addresses for the UE:
a) The HPLMN allocates the IP address to the UE when the default bearer is activated (dynamic or static HPLMN
address);
b) The VPLMN allocates the IP address to the UE when the default bearer is activated (dynamic VPLMN address);
or
c) The PDN operator or administrator allocates an (dynamic or static) IP address to the UE when the default bearer
is activated (External PDN Address Allocation).
The IP address allocated for the default bearer shall also be used for the dedicated bearers within the same PDN
connection. IP address allocation for PDN connections, which are activated by the UE requested PDN connectivity
procedure, is handled with the same set of mechanisms as those used within the Attach procedure.
PDN types IPv4, IPv6 and IPv4v6 are supported. An EPS Bearer of PDN type IPv4v6 may be associated with one IPv6
prefix only or with both one IPv4 address and one IPv6 prefix. PDN type IPv4 is associated with an IPv4 address. PDN
type IPv6 is associated with an IPv6 prefix. PDN types IPv4 and IPv6 are utilised for the UE and/or the PDN GW
support IPv4 addressing only or IPv6 prefix only; or operator preferences dictate the use of a single IP version only, or
the subscription is limited to IPv4 only or IPv6 only for this APN. In addition, PDN type IPv4 and IPv6 are utilised for
interworking with nodes of earlier releases.
3GPP
Release 15 119 3GPP TS 23.401 V15.10.0 (2019-12)
The way that the UE sets the requested PDN type may be pre-configured in the device per APN. Unless otherwise
configured (including when the UE does not send any APN), the UE sets the PDN type during the Attach or PDN
Connectivity procedures based on its IP stack configuration as follows:
- A UE which is IPv6 and IPv4 capable shall request for PDN type IPv4v6.
- A UE which is only IPv4 capable shall request for PDN type IPv4.
- A UE which is only IPv6 capable shall request for PDN type IPv6.
- When the IP version capability of the UE is unknown in the UE (as in the case when the MT and TE are
separated and the capability of the TE is not known in the MT), the UE shall request for PDN type IPv4v6.
NOTE 1: At intersystem changes between GERAN/UTRAN and E-UTRAN there is a 1-to-1 mapping between
PDP type IPv4v6 and PDN type IPv4v6 without re-negotiation of the PDP/PDN type used for a PDN
connection.
The HSS stores one or more PDN types per APN in the subscription data. During the Attach or UE requested PDN
connectivity procedure the MME compares the requested PDN type to the PDN type in the subscription records for the
given APN and sets the PDN type as follows:
- If the requested PDN type is allowed by subscription, the MME sets the PDN type as requested.
- If the requested PDN type is IPv4v6 and subscription data only allows PDN type IPv4 or only allows PDN type
IPv6, the MME sets the PDN type according to the subscribed value. A reason cause shall be returned to the UE
indicating that only the assigned PDN type is allowed. In this case the UE shall not request another PDN
connection to the same APN for the other IP version during the existence of the PDN connection.
- If the requested PDN type is IPv4 or IPv6, and either the requested PDN type or PDN type IPv4v6 are
subscribed, the MME sets the PDN type as requested. Otherwis the PDN connection request is rejected.
- If the requested PDN type is IPv4v6, and both IPv4 and IPv6 PDN types are allowed by subscription but not
IPv4v6, the MME shall set the PDN type to IPv4 or IPv6 where the selection between IPv4 and IPv6 is
implementation specific. The UE should then initiate the UE requested PDN connectivity procedure to this APN
in order to activate a second PDN connection with the other single address PDN type which was not allocated by
the network.
NOTE 2: If the MT and TE are separated, the UE might not be able to use reason cause "single address bearers
only" as a trigger for activating a second single-stack EPS bearer.
The PDN GW may restrict the usage of a PDN type IPv4v6 as follows.
- If the PDN GW receives a request for PDN type IPv4v6, but the PDN GW operator preferences dictate the use of
IPv4 addressing only or IPv6 prefix only for this APN, the PDN type shall be changed to a single address PDN
type (IPv4 or IPv6) and a reason cause shall be returned to the UE indicating that only the assigned PDN type is
allowed. In this case the UE shall not request another PDN connection to the same APN for the other IP version
during the existence of the PDN connection.
- If the PDN GW receives a request for PDN type IPv4v6, but the MME does not set the Dual Address Bearer
Flag due to the MME operator using single addressing per bearer to support interworking with nodes of earlier
releases the PDN type shall be changed to a single IP version only and a reason cause shall be returned to the UE
indicating that only single IP version per PDN connection is allowed. In this case the UE should request another
PDN connection for the other IP version using the UE requested PDN connectivity procedure to the same APN
with a single address PDN type (IPv4 or IPv6) other than the one already activated.
During inter-RAT mobility between E-UTRAN and UTRAN/GERAN, an EPS bearer with PDN type IPv4v6 shall be
mapped one-to-one to PDP type IPv4v6.
During inter-RAT mobility between E-UTRAN and UTRAN/GERAN, an EPS bearer with PDN type IPv4 shall be
mapped one-to-one to a PDP context of PDP type IPv4. An EPS bearer with PDN type IPv6 shall be mapped one-to-one
to a PDP context of PDP type IPv6.
It is the HPLMN operator that shall define in the subscription whether a dynamic HPLMN or VPLMN address may be
used.
3GPP
Release 15 120 3GPP TS 23.401 V15.10.0 (2019-12)
The EPS UE may indicate to the network within the Protocol Configuration Options element that the UE wants to
obtain the IPv4 address with DHCPv4, which is a deferred IPv4 address allocation option, or during the default bearer
activation procedure. This implies the following behaviour both for static and dynamic address allocation:
- the UE may indicate that it prefers to obtain an IPv4 address as part of the default bearer activation procedure. In
such a case, the UE relies on the EPS network to provide IPv4 address to the UE as part of the default bearer
activation procedure.
- the UE may indicate that it prefers to obtain the IPv4 address after the default bearer setup by DHCPv4. That is,
when the EPS network supports DHCPv4 and allows that, it does not provide the IPv4 address for the UE as part
of the default bearer activation procedures. The network may respond to the UE by setting the PDN Address to
0.0.0.0. After the default bearer establishment procedure is completed, the UE uses the connectivity with the EPS
and initiates the IPv4 address allocation on its own using DHCPv4. However, if the EPS network provides IPv4
address to the UE as part of the default bearer activation procedure, the UE should accept the IPv4 address
indicated in the default bearer activation procedure.
- if the UE sends no Address Allocation Preference, the PDN GW determines whether DHCPv4 is used between
the UE and the PDN GW (for the deferred IPv4 address allocation) or not, based on per APN configuration
Both EPS network elements and UE shall support the following mechanisms:
a. IPv4 address allocation via default bearer activation, if IPv4 is supported.
b. /64 IPv6 prefix allocation via IPv6 Stateless Address autoconfiguration according to RFC 4862 [18], if IPv6 is
supported;
Furthermore, the Protocol Configuration Options may be used during bearer activation to configure parameters which
are needed for IP address allocation.
Both EPS network elements and UE may support the following mechanisms:
a. IPv4 address allocation and IPv4 parameter configuration after the attach procedure via DHCPv4 according to
RFC 2131 [19] and RFC 4039 [25];
b. IPv6 parameter configuration via Stateless DHCPv6 according to RFC 3736 [20].
c. Allocation of IPv6 prefixes using DHCPv6 according to RFC 3633 [21].
EPS network elements may support the following mechanism:
a. Allocation of a static IPv4 address and/or a static IPv6 prefix based on subscription data in the HSS.
If the static IP address/prefix is not stored in the HSS subscription record, it may be configured on a per-user per-APN
basis in the DHCP/Radius/Diameter server and the PDN GW retrieves the IP address/prefix for the UE from the
DHCP/Radius/Diameter server. In this case, static IP address/prefix is allocated by the same procedures as the dynamic
IP address/prefix allocation (i.e. in such cases it is transparent to the PDN GW if the IP address is static or dynamic).
If the static IP address/prefix is stored in the HSS subscription record, during the default bearer establishment the PDN
GW receives this static IP address/prefix from Serving GW. In this case the PDN GW shall deliver the received
address/prefix to the UE. The static IP address/prefix is delivered to the UE in the same way as a dynamic IP
address/prefix. Thus it is transparent to the UE whether the PLMN or the external PDN allocates the IP address and
whether the IP address is static or dynamic.
The following clauses describe how the above listed IP address allocation mechanisms work when GTP based S5/S8 is
used. The way of working of the IP address allocation mechanisms for PMIP based S5/S8 can be found in
TS 23.402 [2].The procedures can be used both for PLMN (VPLMN/HPLMN) or external PDN based IP address
allocation.
In order to support DHCP based IP address configuration, the PDN GW shall act as the DHCP server towards the UE
for both HPLMN assigned dynamic and static IP addressing and for VPLMN assigned dynamic IP addressing. When
DHCP is used for external PDN assigned addressing and parameter configuration, the PDN GW shall act as the DHCP
server towards the UE and it shall act as the DHCP client towards the external DHCP server. The Serving GW does not
have any DHCP functionality. It forwards packets, including DHCP packets, between the UE and the PDN GW.
3GPP
Release 15 121 3GPP TS 23.401 V15.10.0 (2019-12)
IPv6 Stateless Address autoconfiguration specified in RFC 4862 [18] is the basic mechanism to allocate /64 IPv6 prefix
to the UE.
During default bearer establishment, the PDN GW sends the IPv6 prefix and Interface Identifier to the S-GW, and then
the S-GW forwards the IPv6 prefix and Interface Identifier to the MME or to the SGSN. The MME or the SGSN
forwards the IPv6 Interface Identifier to the UE. The MME does not forward the IPv6 prefix to the UE. If the UE
receives the IPv6 prefix from the SGSN during PDP Context Activation procedure, it shall ignore it.
5.3.1.2 IP address allocation, renewal and release mechanisms for GTP based
S5/S8
5.3.1.2.1 IPv4 address allocation via default bearer activation and release via PDN
connection release
An IPv4 address may be provided to the UE as part of the default bearer activation and the IPv4 address is released
when PDN connection associated with the IPv4 address is released.
When the PLMN allocates an IPv4 address, it is the PDN GW responsibility to allocate and release the IPv4 address.
The PDN GW may use an internal IPv4 address pool in this case. The PDN GW allocates an IPv4 address upon default
bearer activation and it releases the IPv4 address upon PDN connection release associated with the IPv4 address for a
given UE.
NOTE: If the PDN type is IPv4v6, when the PDN Connection is released, the IPv6 address is also released.
When an IPv4 address is allocated from an external PDN, it is the PDN GW responsibility to obtain the IPv4 address
from the external PDN, and to allocate, renew and release the IPv4 address. The PDN GW may use DHCPv4 to obtain,
renew and release the IPv4 address from the external PDN. If RADIUS or Diameter is used towards the external PDN,
as described in TS 29.061 [38], the IP address can be obtained, renewed and released as part of these procedures. If
DHCPv4 is used, the PDN GW functions as a DHCPv4 Client. If RADIUS is used, the PDN GW functions as a
RADIUS Client. If Diameter is used, the PDN GW functions as a Diameter Client.
After releasing the IPv4 address, the PDN GW should not assign that IPv4 address to other user immediately.
5.3.1.2.2 Allocation, renewal and release of the IPv6 default prefix via IPv6 stateless
address autoconfiguration
When the PLMN allocates an IPv6 prefix, it is the PDN GW responsibility to allocate and release the IPv6 prefix. The
PDN GW may use an internal IPv6 prefix pool in this case. The PDN GW allocates a globally unique /64 IPv6 prefix
via Router Advertisement to a given UE.
When an IPv6 prefix is allocated from an external PDN, it is the PDN GW responsibility to obtain the IPv6 prefix from
the external PDN and to allocate, renew and release the IPv6 prefix. The PDN GW may use DHCPv6 to obtain the IPv6
prefix from the external PDN. In this case, the PDN GW functions as a DHCPv6 client. If RADIUS or Diameter is used
towards the external PDN as described in TS 29.061 [38], the IPv6 prefix can be obtained, renewed and released as part
of these procedures. If RADIUS is used, the PDN GW functions as the RADIUS Client. If Diameter is used, the PDN
GW functions as the Diameter Client.
The procedure of stateless IPv6 address autoconfiguration is the following: After default bearer establishment the UE
may send a Router Solicitation message to the PDN GW to solicit a Router Advertisement message. The PDN GW
sends a Router Advertisement message (solicited or unsolicited) to the UE. The Router Advertisement messages shall
contain the same IPv6 prefix as the one provided during default bearer establishment. If the UE receives an IPv6 prefix
from a SGSN during the PDP Context activation procedure, it shall ignore it.
After the UE has received the Router Advertisement message, it constructs a full IPv6 address via IPv6 Stateless
Address autoconfiguration in accordance with RFC 4862 [18]. To ensure that the link-local address generated by the
UE does not collide with the link-local address of the PDN GW, the PDN GW shall provide an interface identifier (see
RFC 4862 [18]) to the UE and the UE shall use this interface identifier to configure its link-local address. For stateless
address autoconfiguration however, the UE can choose any interface identifier to generate IPv6 addresses, other than
link-local, without involving the network. However, the UE shall not use any identifiers defined in TS 23.003 [9] as the
basis for generating the interface identifier. For privacy, the UE may change the interface identifier used to generate full
IPv6 address, as defined in TS 23.221 [27] without involving the network.
3GPP
Release 15 122 3GPP TS 23.401 V15.10.0 (2019-12)
Any prefix that the PDN GW advertises to the UE is globally unique. The PDN GW shall also record the relationship
between the UE's identity (IMSI) and the allocated IPv6 prefix. Because any prefix that the PDN GW advertises to the
UE is globally unique, there is no need for the UE to perform Duplicate Address Detection for any IPv6 address
configured from the allocated IPv6 prefix. Even if the UE does not need to use Neighbor Solicitation messages for
Duplicate Address Detection, the UE may, for example, use them to perform Neighbor Unreachability Detection
towards the PDN GW, as defined in RFC 4861 [32]. Therefore, the PDN GW shall respond with a Neighbor
Advertisement upon receiving a Neighbor Solicitation message from the UE.
In order to renew the allocated IPv6 prefix, the PDN GW sends a Router Advertisement (solicited or unsolicited) to the
UE with the same prefix and new non-zero values in preferred and valid lifetime fields.
In order to release the allocated IPv6 prefix, the PDN GW shall initiate the PDN connection release procedure. Upon
release of the PDN connection, the UE shall implicitly release the prefix for the corresponding PDN connection.
NOTE 2: If the PDN type is IPv4v6, when the PDN Connection is released, the IPv4 address is also released.
After releasing the IPv6 prefix, the PDN GW should not assign that IPv6 prefix to other user immediately.
5.3.1.2.3 IPv6 parameter configuration via stateless DHCPv6

The UE may use stateless DHCPv6 for additional parameter configuration. The PDN GW acts as the DHCP server.
When PLMN based parameter configuration is used, the PDN GW provides the requested parameters from locally
provisioned database. When external PDN based parameter configuration is used, the PDN GW obtains the requested
configuration parameters from the external PDN as described in the previous clauses. When the PDN GW acts as a
DHCPv6 server towards the UE, the PDN GW may act as DHCPv6 client towards the external PDN to request the
configuration parameters for the UE. If RADIUS or Diameter is used towards the external PDN as described in
TS 29.061 [38], the requested configuration parameters can be fetched as part of these procedures.
5.3.1.2.4 IPv4 address allocation, renewal and release and IPv4 parameter configuration
via DHCPv4
When the PLMN allocates an IPv4 address, it is the PDN GW responsibility to allocate, renew and release the IPv4
address.
When external PDN allocation is used, the PDN GW functions as a DHCPv4 server towards the UE. The PDN GW
may act as a DHCP Client when interacting with a DHCPv4 server in the external PDN in order to obtain, renew and
release the IPv4 address and to obtain the configuration parameters. Or, if RADIUS or Diameter is used towards the
external PDN as described in TS 29.061 [38], the IPv4 address and the requested configuration parameters can be
obtained, renewed and released as part of these procedures.
If dynamic policy provisioning is deployed, and the PCRF was not informed about the IPv4 address at IP-CAN session
establishment, the PDN GW shall initiate an IP-CAN Session Modification procedure to inform the PCRF about an
allocated IPv4 address. If the IPv4 address is released, the PDN GW shall inform the PCRF about the de-allocation of
an IPv4 address.
If the UE sends DHCPv4 lease renewal message to renew the lease of the allocated IPv4 address, the PDN GW shall
renew the lease of the allocated IPv4 address. If the IPv4 address was obtained from an external PDN, the PDN GW
shall perform the DHCPv4 lease renewal procedure with the external PDN if DHCPv4 was used for obtaining IPv4
address from external PDN. If Diameter or RADIUS procedures where used to obtain the IPv4 address from external
PDN, the PDN GW may perform corresponding update procedures as applicable. If the external PDN extends lease of
the allocated IPv4 address, the PDN GW responds accordingly to the UE. Otherwise, if the external PDN does not
extend the lease of the allocated IPv4 address, the PDN GW responds with the remaining lease time of the IPv4 address.
If there is no PDN address allocated to the UE for this PDN connection, the PDN GW shall perform PDN GW initiated
bearer deactivation procedure as defined in clause 5.4.4.1.
If the UE sends DHCPv4 release message to release the allocated IPv4 address for the PDN connection, the PDN GW
may anytime thereafter release the IPv4 address. If the PDN connection has no allocated PDN address, the PDN GW
may at any time initiate PDN GW initiated bearer deactivation procedure as defined in clause 5.4.4.1.
NOTE: If the PDN type is IPv4v6 the release of the allocated IPv4 address does not mean that there is no
allocated PDN address for the PDN connection, as the IPv6 prefix still remains allocated to that PDN
connection.
3GPP
Release 15 123 3GPP TS 23.401 V15.10.0 (2019-12)
If the PDN connection is released without any DHCPv4 release signalling with the UE, the UE and the PDN GW shall
release the IPv4 address implicitly, as soon as the PDN connection is released.
After releasing the IPv4 address, the PDN GW should not assign that IPv4 address to any other user immediately.
5.3.1.2.5 Void
5.3.1.2.6 IPv6 Prefix Delegation via DHCPv6

Optionally a single network prefix shorter than the default /64 prefix may be assigned to a PDN connection. In this case,
the /64 default prefix used for IPv6 stateless autoconfiguration will be allocated from this network prefix; the remaining
address space from the network prefix can be delegated to the PDN connection using prefix delegation after the default
bearer establishment and IPv6 prefix allocation via IPv6 stateless address autoconfiguration as defined in
clause 5.3.1.2.2. When PLMN based parameter configuration is used, the PDN GW provides the requested IPv6 prefix
from a locally provisioned pool. When external PDN based IPv6 prefix allocation is used, the PDN GW obtains the
prefix from the external PDN.
NOTE: Allocation of IPv6 prefixes with flexible prefix length can leverage e.g. local configuration on the
PDN GW or interaction with the AAA server.
The address space provided is maintained as an IPv6 address space pool available to the PDN connection for DHCPv6
IPv6 prefix requests with the exclusion of the IPv6 prefix that is allocated to the PDN connection during default bearer
establishment as defined in clause 5.3.1.2.2. The total IPv6 address space available for the PDN connection (UE default
bearer prefix and UE PDN connection IPv6 address space pool) shall be possible to aggregate into one IPv6 prefix that
will represent all IPv6 addresses that the UE may use. If the UE had indicated that it supports prefix exclusion and the
prefix to be delegated to the UE includes the /64 prefix that was allocated to the PDN Connection, the PDN GW shall
utilise the prefix exclusion feature as specified for DHCPv6 Prefix Delegation in IETF RFC 6603 [70].
The UE uses DHCPv6 to request additional IPv6 prefixes (i.e. prefixes in addition to the default prefix) from the PDN
GW after completing stateless IPv6 address autoconfiguration procedures. The UE acts as a "Requesting Router" as
described in RFC 3633 [21] and inserts one or more IA_PD option(s) into a DHCPv6 Solicit message sent from the UE
to the PDN GW. The PDN GW acts as the DHCP server and fulfils the role of a "Delegating Router" according to
RFC 3633 [21]. The UE optionally includes the RAPID_COMMIT option in the DHCPv6 Solicit message to trigger
two-message DHCPv6 procedure instead of the four-message DHCPv6 procedure. The UE shall include
OPTION_PD_EXCLUDE option code in an OPTION_ORO option to indicate support for prefix exclusion. In response
to the DHCPv6 Solicit message, the UE receives a DHCPv6 Reply message with one or more IA_PD prefix(es) for
every IA_PD option that it sent in the DHCPv6 Solicit message. The PDN GW delegates a prefix excluding the default
prefix with help of OPTION_PD_EXCLUDE. Prefix exclusion procedures shall follow IETF RFC 6603 [70].
5.3.2 Attach procedure
5.3.2.1 E-UTRAN Initial Attach

A UE/user needs to register with the network to receive services that require registration. This registration is described
as Network Attachment. The always-on IP connectivity for UE/users of the EPS may be enabled by establishing a
default EPS bearer during Network Attachment. The PCC rules applied to the default EPS bearer may be predefined in
the PDN GW and activated in the attachment by the PDN GW itself. The Attach procedure may trigger one or multiple
Dedicated Bearer Establishment procedures to establish dedicated EPS bearer(s) for that UE. During the attach
procedure, the UE may request for an IP address allocation. Terminals utilising only IETF based mechanisms for IP
address allocation are also supported.
During the Initial Attach procedure the Mobile Equipment Identity is obtained from the UE. The MME operator may
check the ME Identity with an EIR. The MME passes the ME Identity (IMEISV) to the HSS and to the PDN GW.
During the Initial Attach procedure, if the MME supports SRVCC and if any of the conditions described in step 8 in
Figure 5.3.2.1-1 are satisfied, the MME informs the HSS with the UE SRVCC capability e.g. for further IMS
registration.
The E-UTRAN Initial Attach procedure is used for Emergency Attach by UEs that need to perform emergency services
but cannot gain normal services from the network. These UEs are in limited service state as defined in TS 23.122 [10].
3GPP
Release 15 124 3GPP TS 23.401 V15.10.0 (2019-12)
Also UEs that had attached for normal services and do not have emergency bearers established and are camped on a cell
in limited service state (e.g. restricted Tracking Area or not allowed CSG) shall initiate the Attach procedures indicating
that the attach is to receive emergency services. UEs that camp normally on a cell, i.e. UEs that are not in limited
service state, should initiate normal initial attach when not already attached and shall initiate the UE Requested PDN
Connectivity procedure to receive emergency EPS bearer services.
NOTE 1: A UE that is emergency attached performs initial attach procedure before being able to obtain normal
services.
In order to limit load on the network, only when performing an E-UTRAN Attach with a new PLMN (i.e. not the
registered PLMN or an equivalent PLMN of the registered PLMN), a UE configured to perform Attach with IMSI at
PLMN change (see TS 24.368 [69]) shall identify itself by its IMSI instead of any stored temporary identifier.
This procedure is also used to establish the first PDN connection over E-UTRAN when the UE already has active PDN
connections over a non-3GPP access network and wants to establish simultaneous PDN connections to different APNs
over multiple accesses.
3GPP
Release 15 125 3GPP TS 23.401 V15.10.0 (2019-12)
UE eNodeB new MME Old Serving GW PDN GW PCRF HSS

MME/SGSN
1. Attach Request
EIR
2. Attach
Request 3. Identification Request
3. Identification Response
4. Identity Request
4. Identity Response
5a. Authentication / Security
5b. Identity Request/Response
5b. ME Identity Check
6. Ciphered Options Request
6. Ciphered Options Response
7. Delete Sesion Request 7. PCEF Initiated IP-CAN
Session Termination
(E) 7. Delete Session Response
(A)
8. Update Location Request
9. Cancel Location
9. Cancel Location Ack
10. Delete Session Request 10. PCEF Initiated IP-CAN

Session Termination
(F) 10. Delete Session Response (B)
11. Update Location Ack

12. Create Session Request
14. PCEF Initiated IP-CAN Session
Establishment/Modification
(C)
15. Create Session Response
First Downlink Data (if not handover)
17. Initial Context Setup Request or Downlink NAS transport with Attach Accept
18. RRC Connection Reconfiguration or RRC Direct Transfer
19. RRC Connection Reconfiguration Complete
20. Initial Context Setup Response
21. Direct Transfer
22. Attach Complete
First Uplink Data
23. Modify Bearer Request
23a. Modify Bearer Request
23b. Modify Bearer Response
(D)
24. Modify Bearer Response
First Downlink Data
25. Notify Request
26. Notify Response
Figure 5.3.2.1-1: Attach procedure
NOTE 2: For a PMIP-based S5/S8, procedure steps (A), (B), and (C) are defined in TS 23.402 [2]. Steps 7, 10, 13,
14, 15 and 23a/b concern GTP based S5/S8.
3GPP
Release 15 126 3GPP TS 23.401 V15.10.0 (2019-12)
NOTE 3: The Serving GWs and PDN GWs involved in steps 7 and/or 10 may be different to those in steps 13-15.
NOTE 4: The steps in (D) are executed only upon handover from non-3GPP access or if Presence Reporting Area
Information is received from the MME.
NOTE 5: More detail on procedure steps (E) is defined in the procedure steps (B) in clause 5.3.8.3.
NOTE 6: More detail on procedure steps (F) is defined in the procedure steps (B) in clause 5.3.8.4.
1. A UE, camping on an E-UTRAN cell reads the related System Information Broadcast.
An E-UTRAN cell for a PLMN that supports CIoT enhancements shall broadcast:
For the NB-IoT case:
- Whether it can connect to an MME which supports EPS Attach without PDN Connectivity.
For the WB-E-UTRAN case:
- Whether it supports Control Plane CIoT EPS Optimisation and it can connect to an MME which supports
Control Plane CIoT EPS Optimisation.
- Whether it supports User Plane CIoT EPS Optimisation and it can connect to an MME which supports User
Plane CIoT EPS Optimisation.
- Whether it can connect to an MME which supports EPS Attach without PDN Connectivity.
If the PLMN does not advertise support of EPS attach without PDN connectivity and the UE can only attach
without PDN connectivity, then the UE shall not attach to the PLMN in this cell and shall proceed as specified in
TS 23.122 [10].
In the case of WB-E-UTRAN, if the PLMN does not support Control Plane CIoT EPS Optimisation, and the UE
only supports Control Plane CIoT EPS Optimisation and cannot otherwise attach, then the UE shall not proceed
with the Attach to the PLMN in this cell and shall proceed as specified in TS 23.122 [10].
If a Service Gap timer is running in the UE (see clause 4.3.17.9) and the Attach Type is not Emergency Attach
and it is not an Attach without PDN connectivity, then the UE shall not send Attach Requests to this PLMN or
any other PLMN as long as the timer is running.
If the UE can proceed to attach, it initiates the Attach procedure by the transmission, to the eNodeB, of an Attach
Request (IMSI or old GUTI, Old GUTI type, last visited TAI (if available), UE Core Network Capability, UE
Specific DRX parameters, extended idle mode DRX parameters, Attach Type, ESM message container (Request
Type, PDN Type, Protocol Configuration Options, Ciphered Options Transfer Flag, Header Compression
Configuration), KSIASME, NAS sequence number, NAS-MAC, additional GUTI, P-TMSI signature, Voice
domain preference and UE's usage setting, Preferred Network behaviour, MS Network Capability, Support for
restriction of use of Enhanced Coverage) message together with RRC parameters indicating the Selected
Network and the old GUMMEI.
In the RRC connection establishment signalling associated with the Attach Request, the UE indicates its support
of the CIoT EPS Optimisations, relevant for MME selection.
If the UE identifies itself with the old GUTI, the UE shall set the Old GUTI Type to indicate whether the Old
GUTI is a native GUTI or is mapped from a P-TMSI and RAI. The old GUTI may be derived from a P-TMSI
and RAI. IMSI shall be included if the UE does not have a valid GUTI or a valid P-TMSI available, or if the UE
is configured to perform Attach with IMSI at PLMN change and is accessing a new PLMN. The UE stores the
TIN in detached state. If the UE's TIN indicates "GUTI" or "RAT-related TMSI" and the UE holds a valid GUTI
then the old GUTI indicates this valid GUTI. If the UE's TIN indicates "P-TMSI" and the UE holds a valid
P-TMSI and related RAI then these two elements are indicated as the old GUTI. Mapping a P-TMSI and RAI to
a GUTI is specified in TS 23.003 [9]. If the UE holds a valid GUTI and the old GUTI indicates a GUTI mapped
from a P-TMSI and RAI, then the UE indicates the GUTI as additional GUTI. If the old GUTI indicates a GUTI
mapped from a P-TMSI and RAI and the UE has a valid P-TMSI signature associated to it, the P-TMSI signature
shall be included. The UE sets the voice domain preference and UE's usage setting according to its
configuration, as described in clause 4.3.5.9.
3GPP
Release 15 127 3GPP TS 23.401 V15.10.0 (2019-12)
Alternatively, when a UE only supports E-UTRAN, if the UE has a GUTI available and the UE is accessing the
same PLMN (or ePLMN), then it identifies itself with the old GUTI and sets the Old GUTI Type to 'native',
otherwise the UE configuration determines whether the UE identifies itself with its IMSI or the Old GUTI.
The UE includes the extended idle mode DRX parameters information element if the UE needs to enable
extended idle mode DRX.
If available, the last visited TAI shall be included in order to help the MME produce a good list of TAIs for any
subsequent Attach Accept message. Selected Network indicates the PLMN that is selected for network sharing
purposes. The RRC parameter "old GUMMEI" takes its value from the "old GUTI" contained in the Attach
Request. UE Network Capability is described in UE capabilities, see clause 5.11.
If the UE has valid security parameters, the Attach Request message shall be integrity protected by the NAS-
MAC in order to allow validation of the UE by the MME. KSIASME, NAS sequence number and NAS-MAC are
included if the UE has valid EPS security parameters. NAS sequence number indicates the sequential number of
the NAS message. If the UE does not have a valid EPS security association, then the Attach Request message is
not integrity protected. In this case the security association is established in step 5a. The UE network capabilities
indicate also the supported NAS and AS security algorithms.
PDN type indicates the requested IP version (IPv4, IPv4/IPv6, IPv6). For a UE that support CIoT EPS
Optimisations, the PDN type may also be "Non-IP " Protocol Configuration Options (PCO) are used to transfer
parameters between the UE and the PDN GW, and are sent transparently through the MME and the Serving GW.
The Protocol Configuration Options may include the Address Allocation Preference indicating that the UE
prefers to obtain an IPv4 address only after the default bearer activation by means of DHCPv4. If the UE intends
to send PCO which require ciphering (e.g., PAP/CHAP usernames and passwords) or send an APN, or both, the
UE shall set the Ciphered Options Transfer Flag and send PCO or APN or both only after authentication and
NAS security setup have been completed (see below).
NOTE 7: External network operators wanting to use PAP for authentication are warned that PAP is an obsolete
protocol from a security point of view. CHAP provides stronger security than PAP.
If the UE supports 3GPP PS Data Off, it shall include in the PCO the 3GPP PS Data Off UE Status, which
indicates whether the user has activated or deactivated 3GPP PS Data Off.
If the UE has UTRAN or GERAN capabilities, it shall send the NRSU in the PCO to indicate the support of the
network requested bearer control in UTRAN/GERAN. The UE sends the ETFTU in the PCO to indicate the
support of the extended TFT filter format. Request Type is included in the ESM message container and indicates
"Handover" when the UE has already an activated PDN GW/HA due to mobility with non-3GPP accesses.
If a UE indicates support of CIoT EPS Optimisations in the RRC message, it may omit the ESM message
container. If the ESM message container is omitted the MME shall not establish a PDN connection as part of the
Attach procedure. In this case steps 6, 12 to 16 and 23 to 26 are not executed. In addition, for the case of UEs
attaching with Control Plane CIoT EPS Optimisation with no user plane establishment, steps 17 to 22 are
replaced by S1 AP NAS Transport and RRC Direct Transfer messages that just transport the NAS Attach Accept
and NAS Attach Complete messages.
Attach Type indicates whether it is an EPS attach or a combined EPS/IMSI attach or an Emergency Attach.
Emergency Attach shall not be indicated when the UE is using NB-IoT. When using CIoT EPS Optimisations,
the UE may indicate EPS attach and request SMS by setting the "SMS transfer without Combined Attach" flag
in the Preferred Network Behaviour IE.
If a UE includes a Preferred Network Behaviour, this defines the Network Behaviour the UE is expecting to be
available in the network as defined in clause 4.3.5.10.
If a UE indicated Control Plane CIoT EPS Optimisation supported in Preferred Network Behavior, and the UE
included the ESM message container, and the PDN type was IPv4 or IPv6 or IPv4v6, and the UE supports
header compression, it shall include the Header Compression Configuration. The Header Compression
Configuration includes the information necessary for the ROHC channel setup. Optionally, the Header
Compression Configuration may include additional header compression context setup parameters if the UE
already has the application traffic information, e.g. the target server IP address.
For an Emergency Attach the UE shall set both the Attach Type and the Request Type to "Emergency" and the
IMSI shall be included if the UE does not have a valid GUTI or a valid P-TMSI available. The IMEI shall be
included when the UE has no IMSI, no valid GUTI and no valid P-TMSI.
3GPP
Release 15 128 3GPP TS 23.401 V15.10.0 (2019-12)
2. The eNodeB derives the MME address from the RRC parameters carrying the old GUMMEI, the indicated
Selected Network and the RAT (NB-IoT or WB-E-UTRAN). If that MME is not associated with the eNodeB or
the old GUMMEI is not available, the eNodeB selects an MME as described in clause 4.3.8.3 on "MME
selection function". The eNodeB forwards the Attach Request message in a S1-MME control message (Initial
UE message) together with the Selected Network, CSG access mode, CSG ID, L-GW address, TAI+ECGI of the
cell from where it received the message to the new MME. CSG ID is provided if the UE attaches via a CSG cell
or hybrid cell. CSG access mode is provided if the UE attaches via a hybrid cell. If the CSG access mode is not
provided but the CSG ID is provided, the MME shall consider the cell as a CSG cell. If the eNodeB has a
collocated L-GW, it includes the L-GW address in the Initial UE message to the MME.
If the MME is not configured to support Emergency Attach the MME shall reject any Attach Request that
indicates Attach Type "Emergency".
If the UE has included the Preferred Network Behaviour, and what the UE indicated it supports in Preferred
Network Behaviour is incompatible with the network support e.g. the UE indicated support only for Control
Plane CIoT EPS Optimisation and the MME only supports User Plane CIoT EPS Optimisation, the MME shall
reject the Attach Request with an appropriate cause value (e.g. one that avoids retries on this PLMN).
To assist Location Services, the eNB indicates the UE's Coverage Level to the MME.
3. If the UE identifies itself with GUTI and the MME has changed since detach, the new MME determines the type
of the old node, i.e. MME or SGSN, as specified in clause 4.3.19, uses the GUTI received from the UE to derive
the old MME/SGSN address, and sends an Identification Request (old GUTI, complete Attach Request message)
to the old MME/SGSN to request the IMSI. If the request is sent to an old MME, the old MME first verifies the
Attach Request message by NAS MAC and then responds with Identification Response (IMSI, MM Context). If
the request is sent to an old SGSN, the old SGSN first verifies the Attach Request message by the P-TMSI
signature and then responds with Identification Response (MM Context). If the UE is not known in the old
MME/SGSN or if the integrity check or P-TMSI signature check for the Attach Request message fails, the old
MME/SGSN responds with an appropriate error cause. The MM context contains security related information as
well as other parameters (including IMSI) as described in clause 5.7.2 (Information Storage for MME).
The additional GUTI in the Attach Request message allows the new MME to find any already existing UE
context stored in the new MME when the old GUTI indicates a GUTI mapped from a P-TMSI and RAI.
For an Emergency Attach if the UE identifies itself with a temporary identity that is not known to the MME the
MME immediately requests the IMSI from the UE. If the UE identifies itself with IMEI, the IMSI request shall
be skipped.
NOTE 8: A SGSN always responds with the UMTS security parameters and the MME may store it for later use.
4. If the UE is unknown in both the old MME/SGSN and new MME, the new MME sends an Identity Request to
the UE to request the IMSI. The UE responds with Identity Response (IMSI).
5a If no UE context for the UE exists anywhere in the network, if the Attach Request (sent in step 1) was not
integrity protected, or if the check of the integrity failed, then authentication and NAS security setup to activate
integrity protection and NAS ciphering are mandatory. Otherwise it is optional. If NAS security algorithm is to
be changed, the NAS security setup is performed in this step. The authentication and NAS security setup
functions are defined in clause 5.3.10 on "Security Function".
If the MME is configured to support Emergency Attach for unauthenticated IMSIs and the UE indicated Attach
Type "Emergency" the MME skips the authentication and security setup or the MME accepts that the
authentication may fail and continues the attach procedure.
After step 5a, all NAS messages shall be protected by the NAS security functions (integrity and ciphering)
indicated by the MME unless the UE is emergency attached and not successfully authenticated.
5b. The ME Identity (IMEISV) shall be retrieved from the UE. The ME identity shall be transferred encrypted
unless the UE performs Emergency Attach and cannot be authenticated.
For an Emergency Attach, the UE may have included the IMEI in the Emergency Attach. If so, the ME Identity
retrieval is skipped.
In order to minimise signalling delays, the retrieval of the ME Identity may be combined with NAS security
setup in step 5a. The MME may send the ME Identity Check Request (ME Identity, IMSI) to the EIR. The EIR
3GPP
Release 15 129 3GPP TS 23.401 V15.10.0 (2019-12)
shall respond with ME Identity Check Ack (Result). Dependent upon the Result, the MME decides whether to
continue with this Attach procedure or to reject the UE.
For an Emergency Attach, the IMEI check to the EIR may be performed. If the IMEI is blocked, operator
policies determine whether the Emergency Attach procedure continues or is stopped.
6. If the UE has set the Ciphered Options Transfer Flag in the Attach Request message, the Ciphered Options i.e.
PCO or APN or both, shall now be retrieved from the UE.
In order to handle situations where the UE may have subscriptions to multiple PDNs, if the Protocol
Configuration Options contains user credentials (e.g. user name/password within PAP or CHAP parameters) then
the UE should also send the APN to the MME.
7. If there are active bearer contexts in the new MME for this particular UE (i.e. the UE re-attaches to the same
MME without having properly detached before), the new MME deletes these bearer contexts by sending Delete
Session Request (LBI) messages to the GWs involved. The GWs acknowledge with Delete Session Response
(Cause) message. If a PCRF is deployed, the PDN GW employs an IP-CAN Session Termination procedure to
indicate that resources have been released.
8. If the MME has changed since the last detach, or if there is no valid subscription context for the UE in the MME,
or if the UE provides an IMSI or the UE provides an old GUTI which doesn't refer to a valid context in the
MME, or for some network sharing scenario (e.g. GWCN) if the PLMN-ID of the TAI supplied by the eNodeB
is different from that of the GUTI in the UE's context, the MME sends an Update Location Request (MME
Identity, IMSI, ME Identity (IMEISV), MME Capabilities, ULR-Flags, Homogeneous Support of IMS Voice
over PS Sessions, UE SRVCC capability, equivalent PLMN list) message to the HSS. The MME capabilities
indicate the MME's support for regional access restrictions functionality. ULR-Flags indicates "Initial-Attach-
Indicator" as this is an Attach procedure. The inclusion of the equivalent PLMN list indicates that the MME
supports the inter-PLMN handover to a CSG cell in an equivalent PLMN using the subscription information of
the target PLMN. The "Homogenous Support of IMS Voice over PS Sessions" indication (see clause 4.3.5.8A)
shall not be included unless the MME has completed its evaluation of the support of "IMS Voice over PS
Session" as specified in clause 4.3.5.8.
NOTE 9: At this step, the MME may not have all the information needed to determine the setting of the IMS Voice
over PS Session Supported indication for this UE (see clause 4.3.5.8). Hence the MME can send the
"Homogenous Support of IMS Voice over PS Sessions" later on in this procedure.
If the UE performs Initial or Handover Attach in a VPLMN supporting Autonomous CSG Roaming and the
HPLMN has enabled Autonomous CSG Roaming in the VPLMN (via Service Level Agreement) and the MME
needs to retrieve the CSG subscription information of the UE from the CSS, the MME initiates the Update CSG
Location Procedure with CSS as described in clause 5.3.12.
If the MME determines that only the UE SRVCC capability has changed, the MME sends a Notify Request to
the HSS to inform about the changed UE SRVCC capability.
If there is a valid subscription context for the UE in the MME with a Service Gap timer running and the Attach
Type is not Emergency Attach and it is not an Attach without PDN connectivity, the MME rejects the Attach
Request from the UE with an appropriate cause value. In addition, MME may also provide a UE with a Mobility
Management Back-off Timer set to the remaining value of the Service Gap timer.
For an Emergency Attach in which the UE was not successfully authenticated, the MME shall not send an
Update Location Request to the HSS.
9. The HSS sends Cancel Location (IMSI, Cancellation Type) to the old MME. The old MME acknowledges with
Cancel Location Ack (IMSI) and removes the MM and bearer contexts. If the ULR-Flags indicates "Initial-
Attach-Indicator" and the HSS has the SGSN registration, then the HSS sends Cancel Location (IMSI,
Cancellation Type) to the old SGSN. The Cancellation Type indicates the old MME/SGSN to release the old
Serving GW resource.
10. If there are active bearer contexts in the old MME/SGSN for this particular UE, the old MME/SGSN deletes
these bearer contexts by sending Delete Session Request (LBI) messages to the GWs involved. The GWs return
Delete Session Response (Cause) message to the old MME/SGSN. If a PCRF is deployed, the PDN GW
employs an IP-CAN Session Termination procedure as defined in TS 23.203 [6] to indicate that resources have
been released.
3GPP
Release 15 130 3GPP TS 23.401 V15.10.0 (2019-12)
11. The HSS acknowledges the Update Location message by sending an Update Location Ack (IMSI, Subscription
data) message to the new MME. The Subscription Data contain one or more PDN subscription contexts. Each
PDN subscription context contains an 'EPS subscribed QoS profile' and the subscribed APN-AMBR (see
clause 4.7.3) and the WLAN offloadability indication (see clause 4.3.23). The new MME validates the UE's
presence in the (new) TA.
If due to regional subscription restrictions or access restrictions (e.g. CSG restrictions) the UE is not allowed to
attach in the TA or due to subscription checking fails for other reasons, the new MME rejects the Attach Request
with an appropriate cause. If all checks are successful then the new MME constructs a context for the UE. If the
APN provided by the UE is not allowed by subscription, based on operator policy, the MME may reject the
Attach Request from the UE with an appropriate cause, or accept the Attach Request by replacing the UE
requested APN with a network supported APN. The MME uses that network supported APN for the remainder
of this procedure, except that the MME provides to the UE the same APN that the UE requested. If the Update
Location is rejected by the HSS, the new MME rejects the Attach Request from the UE with an appropriate
cause.
The Subscription Data may contain CSG subscription information for the registered PLMN and for the
equivalent PLMN list requested by MME in step 8.
The subscription data may contain Enhanced Coverage Restricted parameter. If received from the HSS, MME
stores this Enhanced Coverage Restricted parameter in the MME MM context.
The subscription data may contain Service Gap Time parameter. If received from the HSS, MME stores this
Service Gap Time in the MME MM context and passes it to the UE in the Attach Accept message.
The subscription data may contain Subscribed Paging Time Window parameter that applies to the UEs on a
specific RAT, e.g. NB-IoT. If received from the HSS, MME stores this Subscribed Paging Time Window
parameter in the MME MM context.
If the UE provided APN is authorized for LIPA according to the user subscription, the MME shall use the CSG
Subscription Data to authorize the connection.
For an Emergency Attach the MME shall not check for access restrictions, regional restrictions or subscription
restrictions (e.g. CSG restrictions). For an Emergency Attach, the MME shall ignore any unsuccessful Update
Location Response from HSS and continue with the Attach procedure.
12. If an ESM container was not included in the Attach Request, steps 12, 13,14,15,16 are skipped. If the attach type
is not set to "Emergency", and the ESM container was included in the Attach Request, and the UE has indicated
support for Attach without PDN Connectivity, and the network supports Attach without PDN Connectivity, and
the PDN Connection Restriction is set in the subscriber data, then the new MME shall not establish PDN
connection, and steps 12, 13, 14, 15 and 16 are skipped.
For an Emergency Attach the MME applies the parameters from MME Emergency Configuration Data for the
emergency bearer establishment performed in this step and any potentially stored IMSI related subscription data
are ignored by the MME.
If the UE performs Initial or Handover Attach via a CSG cell and there is no subscription for that CSG or the
CSG subscription is expired the MME shall reject the Attach Request with an appropriate cause. If the UE has
this CSG ID and associated PLMN on its Allowed CSG list the UE shall remove the CSG ID and associated
PLMN from the list when receiving this reject cause.
If a subscribed PDN address is allocated for the UE for this APN, the PDN subscription context contains the
UE's IPv4 address and/or the IPv6 prefix and optionally the PDN GW identity. If the PDN subscription context
contains a subscribed IPv4 address and/or IPv6 prefix, the MME indicates it in the PDN address. For Request
Type indicating "Initial request", if the UE does not provide an APN, the MME shall use the PDN GW
corresponding to the default APN for default bearer activation. If the UE provides an APN, this APN shall be
employed for default bearer activation. For Request Type indicating "Handover", if the UE provides an APN, the
MME shall use the PDN GW corresponding to the provided APN for default bearer activation, If the UE does
not provide an APN, and the subscription context from HSS contains a PDN GW identity corresponding to the
default APN, the MME shall use the PDN GW corresponding to the default APN for default bearer activation.
The case where the Request Type indicates "Handover" and the UE does not provide an APN, and the
subscription context from HSS does not contain a PDN GW identity corresponding to the default APN
constitutes an error case. If the Request Type indicates "Initial request" and the selected PDN subscription
context contains no PDN GW identity the new MME selects a PDN GW as described in clause 4.3.8.1 on PDN
3GPP
Release 15 131 3GPP TS 23.401 V15.10.0 (2019-12)
GW selection function (3GPP accesses). If the PDN subscription context contains a dynamically allocated PDN
GW identity and the Request Type does not indicate "Handover" the MME may select a new PDN GW as
described in clause PDN GW selection function, e.g. to allocate a PDN GW that allows for more efficient
routing.
For initial and handover Emergency Attach the MME uses the PDN GW Selection function defined in
clause 4.3.12.4 to select a PDN GW.
If the subscription context does not indicate that the APN is for a PDN connection to an SCEF, the new MME
selects a Serving GW as described in clause 4.3.8.2 on Serving GW selection function and allocates an EPS
Bearer Identity for the Default Bearer associated with the UE. Then it sends a Create Session Request (IMSI,
MSISDN, MME TEID for control plane, PDN GW address, PDN Address, APN, RAT type, LTE-M RAT type
reporting to PGW flag, Default EPS Bearer QoS, PDN Type, APN-AMBR, EPS Bearer Identity, Protocol
Configuration Options, Handover Indication, ME Identity (IMEISV), User Location Information (ECGI), UE
Time Zone, User CSG Information, MS Info Change Reporting support indication, Selection Mode, Charging
Characteristics, Trace Reference, Trace Type, Trigger Id, OMC Identity, Maximum APN Restriction, Dual
Address Bearer Flag, the Protocol Type over S5/S8, Serving Network, APN Rate Control Status) message to the
selected Serving GW. If Control Plane CIoT EPS Optimisation applies, then the MME shall also indicate S11-U
tunnelling of NAS user data and send its own S11-U IP address and MME DL TEID for DL data forwarding by
the SGW. User CSG Information includes CSG ID, access mode and CSG membership indication.
For PDN type "non-IP" when Control Plane CIoT EPS Optimisations are enabled for the UE, if APN
subscription data indicate a SCEF connection needs to be used, then the MME allocates an EPS Bearer Identity
for the Default Bearer associated with the UE and establishes a connection to the SCEF address indicated in
subscription data as per TS 23.682 [74] and the steps 12,13,14,15,16 are not executed. The rest of the
interactions with the UE apply as specified below.
If the MME determines the PDN connection shall only use the Control Plane CIoT EPS Optimisation, the MME
shall include a Control Plane Only PDN Connection Indicator in Create Session Request.
If the Request Type indicates "Emergency", Maximum APN restriction control shall not be performed.
For emergency attached UEs IMSI is included if available and if the IMSI cannot be authenticated then the IMSI
shall be marked as unauthenticated.
The RAT type is provided in this message for the later PCC decision. The RAT type shall distinguish between
NB-IoT, LTE-M and WB-E-UTRA types. The subscribed APN-AMBR for the APN is also provided in this
message. The MSISDN is included if provided in the subscription data from the HSS. Handover Indication is
included if the Request Type indicates handover. Selection Mode indicates whether a subscribed APN was
selected, or a non-subscribed APN sent by the UE was selected. Charging Characteristics indicates which kind of
charging the bearer context is liable for. The MME may change the requested PDN type according to the
subscription data for this APN as described in clause 5.3.1.1. The MME shall set the Dual Address Bearer Flag
when the PDN type is set to IPv4v6 and all SGSNs which the UE may be handed over to are Release 8 or above
supporting dual addressing, which is determined based on node pre-configuration by the operator. The Protocol
Type over S5/S8 is provided to Serving GW which protocol should be used over S5/S8 interface.
The charging characteristics for the PS subscription and individually subscribed APNs as well as the way of
handling Charging Characteristics and whether to send them or not to the P-GW is defined in TS 32.251 [44].
The MME shall include Trace Reference, Trace Type, Trigger Id, and OMC Identity if S-GW and/or P-GW trace
is activated. The MME shall copy Trace Reference, Trace Type, and OMC Identity from the trace information
received from the HLR or OMC.
The Maximum APN Restriction denotes the most stringent restriction as required by any already active bearer
context. If there are no already active bearer contexts, this value is set to the least restrictive type (see clause 15.4
of TS 23.060 [7]). If the P-GW receives the Maximum APN Restriction, then the P-GW shall check if the
Maximum APN Restriction value does not conflict with the APN Restriction value associated with this bearer
context request. If there is no conflict the request shall be allowed, otherwise the request shall be rejected with
sending an appropriate error cause to the UE.
If the MME requires the eNB to check whether the UE radio capabilities are compatible with the network
configuration (e.g. whether the SRVCC or frequency support by the UE matches that of the network) to be able
to set the IMS voice over PS Session Supported Indication (see clause 4.3.5.8), then the MME may send a UE
Radio Capability Match Request to the eNB as defined in clause 5.3.14.
3GPP
Release 15 132 3GPP TS 23.401 V15.10.0 (2019-12)
The MME includes the latest APN Rate Control status if it has stored it.
13. The Serving GW creates a new entry in its EPS Bearer table and sends a Create Session Request (IMSI,
MSISDN, APN, Serving GW Address for the user plane, Serving GW TEID of the user plane, Serving GW
TEID of the control plane, RAT type, Default EPS Bearer QoS, PDN Type, PDN Address, subscribed APN-
AMBR, EPS Bearer Identity, Protocol Configuration Options, Handover Indication, ME Identity, User Location
Information (ECGI), UE Time Zone, User CSG Information, MS Info Change Reporting support indication,
PDN Charging Pause Support indication, Selection Mode, Charging Characteristics, Trace Reference, Trace
Type, Trigger Id, OMC Identity, Maximum APN Restriction, Dual Address Bearer Flag, Serving Network, APN
Rate Control Status) message to the PDN GW indicated by the PDN GW address received in the previous step.
After this step, the Serving GW buffers any downlink packets it may receive from the PDN GW without sending
a Downlink Data Notification message to the MME until it receives the Modify Bearer Request message in step
23 below. The MSISDN is included if received from the MME.
If the Serving GW has received the Control Plane Only PDN Connection Indicator in step 12, the Serving GW
informs the PDN GW this information in Create Session Request. The Serving GW and PDN GW shall indicate
the use of CP only on their CDRs.
PDN GWs shall not perform any checks of Maximum APN Restriction if Create Default Bearer Request
includes the emergency APN.
For emergency attached UEs IMSI is included if available and if the IMSI cannot be authenticated then the IMSI
shall be marked as unauthenticated.
In the case of handover attach, and if the PDN GW detects that the 3GPP PS Data Off UE Status is active, the
PDN GW shall indicate this status to the charging system for offline and online charging.
14. If dynamic PCC is deployed and the Handover Indication is not present, the PDN GW performs an IP-CAN
Session Establishment procedure as defined in TS 23.203 [6], and thereby obtains the default PCC rules for the
UE. If the UE is accessing over WB-E-UTRA, this may lead to the establishment of a number of dedicated
bearers following the procedures defined in clause 5.4.1 in association with the establishment of the default
bearer, which is described in Annex F.
The IMSI, APN, UE IP address, User Location Information (ECGI), UE Time Zone, Serving Network, RAT
type, APN-AMBR, Default EPS Bearer QoS, ETFTU (if ETFTU is not provided it means UE and/or the
PDN GW does not support the extended TFT filter format) are provided to the PCRF by the PDN GW if
received by the previous message. The User Location Information and UE Time Zone are used for location
based charging. For emergency attached UEs which are unauthenticated the PDN GW provides the IMEI as the
UE Identity instead of IMSI, to the PCRF. If the PCRF decides that the PDN connection may use the extended
TFT filter format, it shall return the ETFTN indicator to the PDN GW for inclusion in the protocol Configuration
Options returned to the UE.
The PCRF may modify the APN-AMBR and the QoS parameters (QCI and ARP) associated with the default
bearer in the response to the PDN GW as defined in TS 23.203 [6].
If the PCC is configured to support emergency services and if dynamic PCC is deployed, the PCRF, based on the
emergency APN, sets the ARP of the PCC rules to a value that is reserved for emergency services and the
authorization of dynamic PCC rules as described in of TS 23.203 [6]. If dynamic PCC is not deployed, the PDN
GW uses the ARP of the default emergency EPS bearer for any potentially initiated dedicated emergency EPS
bearer. The P-GW determines that emergency services are requested based on the emergency APN received in
Create Session Request message.
NOTE 10:While the PDN GW/PCEF may be configured to activate predefined PCC rules for the default bearer, the
interaction with the PCRF is still required to provide e.g. the UE IP address information to the PCRF.
NOTE 11:If the IP address is not available when the PDN GW performs the IP-CAN Session Establishment
procedure with the PCRF, the PDN GW initiates an IP-CAN Session Modification procedure to inform
the PCRF about an allocated IP address as soon as the address is available. In this version of the
specification, this is applicable only to IPv4 address allocation.
3GPP
Release 15 133 3GPP TS 23.401 V15.10.0 (2019-12)
If dynamic PCC is deployed and the Handover Indication is present, the PDN GW executes a PCEF Initiated
IP-CAN Session Modification procedure with the PCRF as specified in TS 23.203 [6] to report the new IP-CAN
type. Depending on the active PCC rules, the establishment of dedicated bearers for the UE may be required. The
establishment of those bearers shall take place in combination with the default bearer activation as described in
Annex F. This procedure can continue without waiting for a PCRF response. If changes to the active PCC rules
are required, the PCRF may provide them after the handover procedure is finished.
In both cases (Handover Indication is present or not), if dynamic PCC is not deployed, the PDN GW may apply
local QoS policy. If the UE is accessing over WB-E-UTRA, this may lead to the establishment of a number of
dedicated bearers for the UE following the procedures defined in clause 5.4.1 in combination with the
establishment of the default bearer, which is described in Annex F.
If the CSG information reporting triggers are received from the PCRF, the PDN GW should set the CSG
Information Reporting Action IE accordingly.
If 3GPP PS Data Off status is received in the PCO from the UE and PDN GW supports 3GPP PS Data Off, the
PDN GW shall provide the 3GPP PS Data Off status to the PCRF. If the PCRF supports 3GPP PS Data Off, it
shall return 3GPP PS Data Off support to the PDN GW for inclusion in the PCO returned to the UE.
The additional behaviour of the PDN GW for 3GPP PS Data Off is defined in TS 23.203 [6].
If received, the PDN GW may take the APN Rate Control Status into account when encoding the APN Rate
Control parameters in Protocol Configuration Options and when enforcing the APN Rate Control as described in
clause 4.7.7.3.
15. The P-GW creates a new entry in its EPS bearer context table and generates a Charging Id for the Default
Bearer. The new entry allows the P-GW to route user plane PDUs between the S-GW and the packet data
network, and to start charging. The way the P-GW handles Charging Characteristics that it may have received is
The PDN GW returns a Create Session Response (PDN GW Address for the user plane, PDN GW TEID of the
user plane, PDN GW TEID of the control plane, PDN Type, PDN Address, EPS Bearer Identity, EPS Bearer
QoS, Protocol Configuration Options, Charging Id, Prohibit Payload Compression, APN Restriction, Cause, MS
Info Change Reporting Action (Start) (if the PDN GW decides to receive UE's location information during the
session), CSG Information Reporting Action (Start) (if the PDN GW decides to receive UE's User CSG
information during the session), Presence Reporting Area Action (if the PDN GW decides to receive
notifications about a change of UE presence in Presence Reporting Area), PDN Charging Pause Enabled
indication (if PDN GW has chosen to enable the function), APN-AMBR, Delay Tolerant Connection) message
to the Serving GW.
The PDN GW takes into account the received PDN type, the Dual Address Bearer Flag and the policies of
operator when the PDN GW selects the PDN type to be used as follows. If the received PDN type is IPv4v6 and
both IPv4 and IPv6 addressing is possible in the PDN but the Dual Address Bearer Flag is not set, or only single
IP version addressing for this APN is possible in the PDN, the PDN GW selects a single IP version (either IPv4
or IPv6). If the received PDN type is IPv4 or IPv6 or "Non IP", the PDN GW uses the received PDN type if it is
supported in the PDN, otherwise an appropriate error cause will be returned. For IPv4, IPv6 and IPv4v6, the
PDN GW allocates a PDN Address according to the selected PDN type. If the PDN GW has selected a PDN type
different from the received PDN Type, the PDN GW indicates together with the PDN type IE a reason cause to
the UE why the PDN type has been modified, as described in clause 5.3.1.1. The PDN GW shall either accept or
reject (but not modify) the PDN type if the PDN type is set to "Non IP". PDN Address may contain an IPv4
address for IPv4 and/or an IPv6 prefix and an Interface Identifier, or be omitted for PDN type "Non IP". If the
PDN has been configured by the operator so that the PDN addresses for the requested APN shall be allocated by
usage of DHCPv4 only, or if the PDN GW allows the UE to use DHCPv4 for address allocation according to the
Address Allocation Preference received from the UE, the PDN Address shall be set to 0.0.0.0, indicating that the
IPv4 PDN address shall be negotiated by the UE with DHCPv4 after completion of the Default Bearer
Activation procedure. For external PDN addressing for IPv6, the PDN GW obtains the IPv6 prefix from the
external PDN using either RADIUS or Diameter client function. In the PDN Address field of the Create Session
Response, the PDN GW includes the Interface Identifier and IPv6 prefix. The PDN GW sends Router
Advertisement to the UE after default bearer establishment with the IPv6 prefix information for all cases.
3GPP
Release 15 134 3GPP TS 23.401 V15.10.0 (2019-12)
If the PDN address is contained in the Create Session Request, the PDN GW shall allocate the IPv4 address
and/or IPv6 prefix contained in the PDN address to the UE. The IP address allocation details are described in
clause 5.3.1 on "IP Address Allocation". The PDN GW derives the BCM based on the NRSU and operator
policy. The PDN GW derives whether the extended TFT filter format is to be used based on the ETFTU, ETFTN
received from the PCRF and operator policy. Protocol Configuration Options contains the BCM, ETFTN as well
as optional PDN parameters that the P-GW may transfer to the UE. These optional PDN parameters may be
requested by the UE, or may be sent unsolicited by the P-GW. Protocol Configuration Options are sent
transparently through the MME.
The PDN GW includes a Delay Tolerant Connection indication if the PDN GW supports receiving a rejection
cause from the SGW indicating that the UE is temporarily not reachable due to power saving and holding mobile
terminated procedures, until the PDN GW receives a message indicating that the UE is available for end to end
signalling.
When the Handover Indication is present, the PDN GW does not yet send downlink packets to the S-GW; the
downlink path is to be switched at step 23a.
If the PDN GW is an L-GW, it does not forward downlink packets to the S-GW. The packets will only be
forwarded to the HeNB at step 20 via the direct user plane path.
If the 3GPP PS Data Off UE Status was present in the Create Session Request PCO and the network supports
3GPP PS Data Off feature, the PDN GW shall include the 3GPP PS Data Off Support Indication in the Create
Session Response PCO.
16. The Serving GW returns a Create Session Response (PDN Type, PDN Address, Serving GW address for User
Plane, Serving GW TEID User Plane, Serving GW TEID for control plane, EPS Bearer Identity, EPS Bearer
QoS, PDN GW addresses and TEIDs (GTP-based S5/S8) or GRE keys (PMIP-based S5/S8) at the PDN GW(s)
for uplink traffic, Protocol Configuration Options, Prohibit Payload Compression, APN Restriction, Cause, MS
Info Change Reporting Action (Start), Presence Reporting Area Action, CSG Information Reporting Action
(Start), APN-AMBR, Delay Tolerant Connection) message to the new MME.
If Control Plane CIoT EPS Optimisation applies, and if the MME does not include Control Plane Only PDN
Connection Indicator in the Create Session Request:
- If separation of S11-U from S1-U is required, the Serving GW shall include the Serving GW IP address and
TEID for S11-U and additionally the Serving GW IP address and TEID for S1-U in Create Session Response.
- Otherwise, if separation of S11-U from S1-U is not required, the Serving GW includes the Serving GW IP
address and TEID for S11-U in Create Session Response.
17. If an APN Restriction is received, then the MME shall store this value for the Bearer Context and the MME shall
check this received value with the stored value for the Maximum APN Restriction to ensure there are no
conflicts between values. If the Bearer Context is accepted, the MME shall determine a (new) value for the
Maximum APN Restriction. If there is no previously stored value for Maximum APN Restriction, then the
Maximum APN Restriction shall be set to the value of the received APN Restriction. MME shall not deactivate
bearer(s) with emergency ARP, if present, to maintain valid APN restriction combination.
The P-GW shall ignore Maximum APN restriction if the request includes the Emergency APN.
If the MS Info Change Reporting Action (Start) and/or the CSG Information Reporting Action (Start) are
received for this bearer context, then the MME shall store this for the bearer context and the MME shall report to
that P-GW via the S-GW whenever a UE's location and/or User CSG information change occurs that meets the
P-GW request, as described in clause 15.1.1a of TS 23.060 [7]. If Presence Reporting Area Action is received for
this bearer context, the MME shall store this information for the bearer context and shall report to that P-GW via
the S-GW whenever a change of UE presence in a Presence Reporting Area is detected, as described in
clause 5.9.2.2.
The MME determines the UE AMBR to be used by the eNodeB based on the subscribed UE-AMBR and the
APN-AMBR for the default APN, see clause 4.7.3.
For emergency attach the MME determines the UE-AMBR to be used by the eNodeB from the APN AMBR
received from the S-GW.
3GPP
Release 15 135 3GPP TS 23.401 V15.10.0 (2019-12)
If new MME hasn't received, from Step 12, Voice Support Match Indicator for the UE from the eNB then, based
on implementation, the MME may set IMS Voice over PS session supported Indication and update it at a later
stage.
The new MME sends an Attach Accept (GUTI, TAI List, Session Management Request (APN, PDN Type, PDN
Address, EPS Bearer Identity, Protocol Configuration Options, Header Compression Configuration, Control
Plane Only Indicator), NAS sequence number, NAS-MAC, IMS Voice over PS session supported Indication,
Emergency Service Support indicator, LCS Support Indication, Supported Network Behaviour, Service Gap
Time, Enhanced Coverage Restricted, Indication for support of 15 EPS bearers per UE) message to the eNodeB.
GUTI is included if the new MME allocates a new GUTI. PDN Type and PDN Address are omitted if the Attach
Request (step 1) did not contain an ESM message container. The MME indicates the CIoT EPS Optimisations it
accepts in the Supported Network Behaviour information as defined in clause 4.3.5.10. Service Gap Time is
included if Service Gap Time is present in the subscription information (step 11) and the UE has indicated UE
Service Gap Control Capability. This message is contained in an S1_MME control message Initial Context Setup
Request, unless the MME has selected to use the Control Plane CIoT EPS Optimisation, or, the UE did not
include the ESM message container in the Attach Request (step 1), in which case an S1-AP Downlink NAS
transport message is used. The S1-AP Initial Context Setup Request message also includes the AS security
context information for the UE, the Handover Restriction List, the EPS Bearer QoS, the UE-AMBR, EPS Bearer
Identity, as well as the TEID at the Serving GW used for user plane and the address of the Serving GW for user
plane and whether User Plane CIoT EPS Optimisation is allowed for the UE. If the PDN type is set to "Non-IP"
the MME includes it in the S1-AP Initial Context Setup Request so that the eNodeB disables header
compression. In addition, if the PDN connection is established for Local IP Access, the corresponding S1 Initial
Context Setup Request message includes a Correlation ID for enabling the direct user plane path between the
HeNB and the L-GW. If the PDN connection is established for SIPTO at the Local Network with L-GW function
collocated with the (H)eNB, the corresponding S1-AP Initial Context Setup Request message includes a SIPTO
Correlation ID for enabling the direct user plane path between the (H)eNB and the L-GW. LIPA and SIPTO do
not apply to Control Plane CIoT EPS Optimisation.
NOTE 12:In this release of the 3GPP specification the Correlation ID and SIPTO Correlation ID is set equal to the
user plane PDN GW TEID (GTP-based S5) or GRE key (PMIP-based S5) that the MME has received in
step 16.
If Control Plane CIoT EPS Optimisation applies for an IP PDN connection, and the UE has sent in the Attach
Request the Header Compression Configuration, and the MME supports the header compression parameters, the
MME shall include the Header Compression Configuration in the PDN Connectivity Accept message. The MME
also binds the uplink and downlink ROHC channels to support header compression feedback signalling. If the
UE has included header compression context setup parameters in Header Compression Configuration in the
Attach Request, the MME may acknowledge the header compression context setup parameters. If the ROHC
context is not established during the attach procedure for the PDN connection, before using the compressed
format for sending the data, the UE and the MME need to establish the ROHC context with ROHC IR packet
based on Header Compression Configuration.
If the MME based on local policy determines the PDN connection shall only use the Control Plane CIoT EPS
Optimisation, the MME shall include a Control Plane Only Indicator in the Session Management Request. For
PDN connections with an SCEF, the MME shall always include the Control Plane Only Indicator.A UE
receiving the Control Plane Only Indicator, for a PDN connection shall only use the Control Plane CIoT EPS
Optimisation for this PDN connection.
If the ESM container was not included in the Attach Request in step 1, then the Attach Accept message shall not
include PDN related parameters, and the Downlink NAS transfer S1-AP message shall not include Access
stratum context related information but may include CSG related information.
If the attach type is not set to "Emergency", and the ESM container was included in Attach Request in step 1,
and the UE indicated support of Attach without PDN Connection in the Attach Request, and the MME supports
Attach without PDN Connection, and PDN connection restriction is set in subscriber data, then the MME shall
discard the ESM container in the Attach Request message, and shall not include PDN related parameters in the
Attach Accept, but may include CSG related information.
In the Attach Accept message, the MME does not include the IPv6 prefix within the PDN Address. The MME
includes the EPS Bearer QoS parameter QCI and APN-AMBR into the Session Management Request.
Furthermore, if the UE has UTRAN or GERAN capabilities and the network supports mobility to UTRAN or
GERAN, the MME uses the EPS bearer QoS information to derive the corresponding PDP context parameters
QoS Negotiated (R99 QoS profile), Radio Priority, Packet Flow Id and TI and includes them in the Session
3GPP
Release 15 136 3GPP TS 23.401 V15.10.0 (2019-12)
Management Request. If the UE indicated in the UE Network Capability it does not support BSS packet flow
procedures, then the MME shall not include the Packet Flow Id. Handover Restriction List is described in
clause 4.3.5.7 "Mobility Restrictions". The MME sets the IMS Voice over PS session supported Indication as
described in clause 4.3.5.8. LCS Support Indication indicates whether the network supports the EPC-MO-LR
and/or CS-MO-LR as described in TS 23.271 [57]. The MME may include an indication whether the traffic of
this PDN Connection is allowed to be offloaded to WLAN, as described in clause 4.3.23. Indication for support
of 15 EPS bearers per UE indicates the network support for up to 15 EPS bearers per UE as defined in
clause 4.12.
If the UE initiates the Attach procedure at a hybrid cell, the MME shall check whether the CSG ID is contained
in the CSG subscription and is not expired. The MME shall send an indication whether the UE is a CSG member
to the RAN along with the S1-MME control message. Based on this information the RAN may perform
differentiated treatment for CSG and non-CSG members.
If the MME or PDN GW has changed the PDN Type, an appropriate reason cause shall be returned to the UE as
described in clause 5.3.1.1. If the UE has indicated PDN type "Non-IP", the MME and PDN GW shall not
change PDN type.
For an emergency attached UE, i.e. for UEs that have only emergency EPS bearers established, there is no AS
security context information included in the S1 control messages and there is no NAS level security when the
UE cannot be authenticated. The Emergency Service Support indicator informs the UE that Emergency bearer
services are supported, i.e. the UE is allowed to request PDN connectivity for emergency services.
If the UE included extended idle mode DRX parameters information element, the MME includes extended idle
mode DRX parameters information element if it decides to enable extended idle mode DRX with Paging Time
Window length assigned considering Subscribed Paging Time Window (if available) and the local policy.
If the UE included support for restriction of use of Enhanced Coverage in step 1, the MME sends Enhanced
Coverage Restricted parameter to the eNB in S1-AP Initial Context Set-up Request message. MME also sends
Enhanced Coverage Restricted parameter to the UE in the Attach Accept message.
If the UE is not allowed to use NR as Secondary RAT, the MME indicates that to the UE in the Attach Accept
message.
18. If the eNodeB received an S1-AP Initial Context Setup Request the eNodeB sends the RRC Connection
Reconfiguration message including the EPS Radio Bearer Identity to the UE, and the Attach Accept message
will be sent along to the UE.
If the eNodeB received an S1-AP Downlink NAS Transport message (e.g. containing the Attach Accept
message), the eNode B sends a RRC Direct Transfer message to the UE.
The UE shall store the QoS Negotiated, Radio Priority, Packet Flow Id and TI, which it received in the Session
Management Request, for use when accessing via GERAN or UTRAN. The APN is provided to the UE to notify
it of the APN for which the activated default bearer is associated. For further details, see TS 36.331 [37]. The UE
may provide EPS Bearer QoS parameters to the application handling the traffic flow(s). The application usage of
the EPS Bearer QoS is implementation dependent. The UE shall not reject the RRC Connection Reconfiguration
on the basis of the EPS Bearer QoS parameters contained in the Session Management Request.
If the UE receives Enhanced Coverage Restricted parameter in the Attach Accept message, UE shall store this
information and shall use the value of Enhanced Coverage Restricted parameter to determine if enhanced
coverage feature should be used or not. If the UE receives a Service Gap Time in the Attach Accept message, the
UE shall store this parameter and apply Service Gap Control (see clause 4.3.17.9).
If the attach procedure is initiated by manual CSG selection and occurs via a CSG cell, the UE upon receiving
the Attach accept shall check if the CSG ID and associated PLMN of the cell where the UE has sent the Attach
Request message is contained in its Allowed CSG list. If the CSG ID and associated PLMN is not in the UE's
Allowed CSG list, the UE shall add the CSG ID and associated PLMN to its Allowed CSG list. Manual CSG
selection is not supported when an emergency service has been initiated.
NOTE 13:If the UE receives an Attach Accept message via a hybrid cell, the UE does not add the corresponding
CSG ID and associated PLMN to its Allowed CSG list. Adding a CSG ID and associated PLMN to the
UE's local Allowed CSG list for a hybrid cell is performed only by OTA or OMA DM procedures.
When receiving the Attach Accept message the UE shall set its TIN to "GUTI" as no ISR Activated is indicated.
3GPP
Release 15 137 3GPP TS 23.401 V15.10.0 (2019-12)
If the UE receives an IPv4 address set to 0.0.0.0, it may negotiate the IPv4 address with DHCPv4 as specified in
TS 29.061 [38]. If the UE receives an IPv6 interface identifier, it may wait for the Router Advertisement from
the network with the IPv6 prefix information or it may send a Router Solicitation if necessary.
NOTE 14:The IP address allocation details are described in clause 5.3.1 on "IP Address Allocation".
If Control Plane CIoT EPS Optimisation applies or the UE has not included the ESM message container in the
Attach Request in step 1, then the steps 19 and 20 are not executed.
19. The UE sends the RRC Connection Reconfiguration Complete message to the eNodeB. For further details, see
TS 36.331 [37].
20. The eNodeB sends the Initial Context Response message to the new MME. This Initial Context Response
message includes the TEID of the eNodeB and the address of the eNodeB used for downlink traffic on the S1_U
reference point.
The MME shall be prepared to receive this message either before or after the Attach Complete message (sent in
step 22).
If the Correlation ID or SIPTO Correlation ID was included in the Initial Context Setup Request message, the
eNodeB shall use the included information to establish direct user plane path with the L-GW and forward uplink
data for Local IP Access or SIPTO at the Local Network with L-GW function collocated with the (H)eNB
accordingly.
21. The UE sends a Direct Transfer message to the eNodeB, which includes the Attach Complete (EPS Bearer
Identity, NAS sequence number, NAS-MAC) message. If the UE omitted the ESM message container from the
Attach Request message in step 1, then the EPS Bearer Identity is omitted from the Attach Complete message.
22. The eNodeB forwards the Attach Complete message to the new MME in an Uplink NAS Transport message.
If the ESM message container was included in step 1, after the Attach Accept message and once the UE has
obtained (if applicable to the PDN type) a PDN Address, the UE can then send uplink packets towards the
eNodeB which will then be tunnelled to the Serving GW and PDN GW. If Control Plane CIoT EPS
Optimisations apply, UL data is sent as specified in clause 5.3.4B. If the UE requested for a dual address PDN
type (IPv4v6) to a given APN and was granted a single address PDN type (IPv4 or IPv6) by the network with a
reason cause indicating that only single IP version per PDN connection is allowed sent together with the PDN
type, the UE should request for the activation of a parallel PDN connection to the same APN with a single
address PDN type (IPv4 or IPv6) other than the one already activated. If the UE receives no reason cause in
step 18 in response to an IPv4v6 PDN type and it receives an IPv6 Interface Identifier apart from the IPv4
address or 0.0.0.0 in the PDN Address field, it considers that the request for a dual address PDN was successful.
It can wait for the Router Advertisement from the network with the IPv6 prefix information or it may send
Router Solicitation if necessary.
23. Upon reception of both, the Initial Context Response message in step 20 and the Attach Complete message in
step 22, the new MME sends a Modify Bearer Request (EPS Bearer Identity, eNodeB address, eNodeB TEID,
Handover Indication, Presence Reporting Area Information, RAT type, LTE-M RAT type reporting to PGW)
message to the Serving GW. If the Control Plane CIoT EPS Optimisation applies and the PDN connection is not
served by a SCEF and if the MME does not need to report a change of UE presence in Presence Reporting Area,
sending of Modify Bearer Request and steps 23a, 23b and 24 are skipped; otherwise if the PDN connection is
served by SCEF, steps 23,24, 25, and 26 are not executed. If the MME has been requested to report a change of
UE presence in Presence Reporting Area, the MME includes in this message the Presence Reporting Area
Information comprising the PRA identifier(s) and indication(s) on whether the UE is inside or outside the
area(s). When receiving the request for reporting change of UE presence in Presence Reporting Area, and the
MME decides not to activate reporting UE presence in one or more of the received Presence Reporting Area(s),
the MME reports also the inactive Presence Reporting Area(s) in this message. The RAT type information
element is included if the UE is using the LTE-M RAT type. If PDN GW expects the LTE-M RAT type
reporting as specified in clause 5.11.5, the MME also includes the LTE-M RAT type reporting to PGW flag to
indicate that the Serving GW needs to forward the LTE-M RAT type to the PGW.
23a. If the Handover Indication is included in step 23, the Serving GW sends a Modify Bearer Request (Handover
Indication) message to the PDN GW to prompt the PDN GW to tunnel packets from non 3GPP IP access to
3GPP access system and immediately start routing packets to the Serving GW for the default and any dedicated
EPS bearers established. If Presence Reporting Area Information is included in step 23, the Serving GW sends a
Modify Bearer Request (Presence Reporting Area Information) message to the PDN GW. If the LTE-M RAT
3GPP
Release 15 138 3GPP TS 23.401 V15.10.0 (2019-12)
type and the LTE-M RAT type reporting to PGW flag were received at step 23, the Serving GW shall include the
LTE-M RAT type in the Modify Bearer Request message to the PGW. Otherwise the Serving GW includes RAT
type WB-E-UTRAN.
NOTE 15:The PDN GW is expected to handle the uplink packets sent by the UE via 3GPP access after step 22, even
if they arrive before path switch in step 23.
NOTE 16:The PDN GW forwards the Presence Reporting Area Information to the PCRF, to the OCS or to both as
23b. The PDN GW acknowledges by sending Modify Bearer Response to the Serving GW.
24. The Serving GW acknowledges by sending Modify Bearer Response (EPS Bearer Identity) message to the new
MME. The Serving GW can then send its buffered downlink packets.
If there is a "Availability after DDN Failure" monitoring event or a "UE Reachability" monitoring event
configured for the UE in the EMM Context of the MME, the MME sends an event notification (see
TS 23.682 [74] for further information).
25. After the MME receives Modify Bearer Response (EPS Bearer Identity) message, if Request Type does not
indicate handover and an EPS bearer was established and the subscription data indicates that the user is allowed
to perform handover to non-3GPP accesses, and if the MME selected a PDN GW that is different from the PDN
GW identity which was indicated by the HSS in the PDN subscription context, the MME shall send a Notify
Request including the APN and PDN GW identity to the HSS for mobility with non-3GPP accesses. The
message shall include information that identifies the PLMN in which the PDN GW is located.
If the ME identity of the UE has changed and step 8 has not been performed, the MME sends a Notify Request
(ME Identity) message to inform the HSS of the updated ME identity.
For an unauthenticated or roaming UE, if the Request Type of the UE requested connectivity procedure indicates
"Emergency", the MME shall not send any Notify Request to an HSS. For a non-roaming authenticated UE,
based on operator configuration (e.g. on whether Voice over WLAN is supported or not by the operator, on
whether the operator uses a fixed PDN GW for emergency calls, etc.), if the Request Type indicates
"Emergency", the MME may send a Notify Request to the HSS including the "PDN GW currently in use for
emergency services", which comprises the PDN GW address and an indication that the PDN connection is for
emergency services. The HSS shall store it as part of the UE context for emergency services.
After step 8, and in parallel to any of the preceding steps, the MME shall send a Notify Request (Homogeneous
Support of IMS Voice over PS Sessions) message to the HSS:
- If the MME has evaluated the support of IMS Voice over PS Sessions, see clause 4.3.5.8, and
- If the MME determines that it needs to update the Homogeneous Support of IMS Voice over PS Sessions,
see clause 4.3.5.8A.
26. In the case of non-emergency services, the HSS stores the APN and PDN GW identity pair. In the case of
emergency services, the HSS stores the "PDN GW currently in use for emergency services". The HSS then sends
a Notify Response to the MME.
NOTE 17:For handover from non-3GPP access, the PDN GW initiates resource allocation deactivation procedure in
the trusted/untrusted non-3GPP IP access as specified in TS 23.402 [2].
5.3.2.2 UTRAN/GERAN Initial Attach

When a UE attaches to UTRAN/GERAN, it executes the normal attach procedure as defined in TS 23.060 [7]. When
the UE needs an IP address, it initiates PDP context activation procedure as defined in TS 23.060 [7].
This procedure along with PDP context activation is also used to establish the first PDN connection over
UTRAN/GERAN when the UE already has active PDN connections over a non-3GPP access network and wants to
establish simultaneous PDN connections to different APNs over multiple accesses.
3GPP
Release 15 139 3GPP TS 23.401 V15.10.0 (2019-12)
5.3.3 Tracking Area Update procedures
5.3.3.0 Triggers for tracking area update

A stand-alone tracking area update (with or without S-GW change, described in clauses 5.3.3.1 and 5.3.3.2 respectively)
occurs when a GPRS-attached or E-UTRAN-attached UE experiences any of the following conditions:
- UE detects it has entered a new TA that is not in the list of TAIs that the UE registered with the network (except
for the case of a UE configured to perform Attach with IMSI when entering a TA in a new non-equivalent
PLMN in RRC-IDLE mode);
- the periodic TA update timer has expired;
- UE was in UTRAN PMM_Connected state (e.g. URA_PCH) when it reselects to E-UTRAN;
- UE was in GPRS READY state when it reselects to E-UTRAN;
- the TIN indicates "P-TMSI" when the UE reselects to E-UTRAN (e.g. due to bearer configuration modifications
performed on GERAN/UTRAN);
- the RRC connection was released with release cause "load re-balancing TAU required";
- the RRC layer in the UE informs the UE's NAS layer that an RRC connection failure (in either E-UTRAN or
UTRAN) has occurred;
- a change of the UE Network Capability and/or MS Network Capability and/or UE Specific DRX Parameters
and/or TS 24.008 [47] MS Radio Access capability (e.g. due to GERAN radio capability change, E-UTRAN,
NG-RAN capability change or cdma2000 Radio Access Technology Capability change) information of the UE.
- a change in conditions in the UE require a change in the extended idle mode DRX parameters previously
provided by the MME.
- for a UE supporting CS fallback, or configured to support IMS voice, or both, a change of the UE's usage setting
or voice domain preference for E-UTRAN.
- for a SR-VCC capable UE, a change of MS Classmark 2 and/or MS Classmark 3 and/or Supported Codecs.
- UE manually selects a CSG cell whose CSG ID and associated PLMN is absent from both the UE's Allowed
CSG list and the UE's Operator CSG list.
- UE receives a paging request from the MME while the Mobility Management back off timer is running and the
UE's TIN indicates "P-TMSI".
- a change in any of the values of information included in Preferred Network Behaviour as defined in
clause 4.3.5.10 that would create incompatibility with the Supported Network Behaviour provided by the serving
MME.
NOTE 1: The complete list of TAU triggers is specified in TS 24.301 [46].
The procedure is initiated by an UE in either ECM-IDLE state or ECM-CONNECTED state. The decision to perform
S-GW change during the tracking area update procedure is made by the MME independently from the triggers above.
If SIPTO is allowed for the APN associated with a PDN connection, the MME should re-evaluate whether the
PDN GW location is still acceptable. If the MME determines that PDN GW re-location is needed, the MME may
initiate PDN deactivation with reactivation requested according to clause 5.10.3 at the end of the tracking area/routing
area update procedure.
NOTE 2. It depends on the operator's configuration in the MME whether to use the deactivation with reactivation
request or allow the continued usage of the already connected GW.
If SIPTO at the local network is allowed for the APN associated with a PDN connection the MME handles the SIPTO at
the Local Network PDN connection as follows.
For a L-GW collocated with (H)eNB:
3GPP
Release 15 140 3GPP TS 23.401 V15.10.0 (2019-12)
- For intra-MME mobility, upon completion of the TAU procedure the MME shall deactivate the SIPTO at the
local Network PDN connection with the "reactivation requested" cause value according to clause 5.10.3. If the
UE has no other PDN connection, the MME initiates "explicit detach with reattach required" procedure
according to clause 5.3.8.3.
- For Inter-MME/SGSN mobility, as part of the Tracking Area Update procedure, the source MME shall remove
the bearer(s) corresponding to the SIPTO at Local Network PDN connection and shall release the core network
resources associated to the SIPTO at the Local Network PDN connection by performing the MME-initiated PDN
Connection Deactivation before sending the Context Response message.
For a stand-alone GW:
- For intra-MME mobility, upon completion of the TAU procedure the MME checks that the Local Home
Network ID has changed and decides whether to deactivate the SIPTO at the local Network PDN connection
with the "reactivation requested" cause value according to clause 5.10.3. If the UE has no other PDN connection,
the MME initiates "explicit detach with reattach required" procedure according to clause 5.3.8.3.
- For Inter-MME/SGSN mobility, upon completion of the TAU/RAU procedure the new MME/SGSN checks that
the Local Home Network ID has changed and decides whether to deactivate the SIPTO at the Local Network
PDN connection with the "reactivation requested" cause value according to clause 5.10.3. If the UE has no other
PDN connection, the MME initiates "explicit detach with reattach required" procedure according to
clause 5.3.8.3.
If LIPA is active for a PDN connection of the UE, the source MME (or S4-SGSN) shall not include LIPA bearer(s) in
the EPS bearer Context during Tracking Area Update procedure and shall release the core network resources of this
LIPA PDN connection by peforming the MME requested PDN disconnection procedure according to steps 2 to 6 of
clause 5.10.3 before it responds with the Context Response message in the case of inter-MME/SGSN mobility or after it
receives Tracking Area Update Request in the case of intra-MME mobility.
NOTE 3: The source MME may not be able to release the LIPA PDN connection after the Context Response is sent
as when there is no S-GW relocation, the S-GW will assign the S11 control tunnel of the UE to the new
MME after the new MME updates the context information.
During the Tracking Area Update procedure, if the MME supports SRVCC and if the UE SRVCC capability has
changed, the MME informs the HSS with the UE SRVCC capability e.g. for further IMS registration.
The cell selection for UTRAN is described in TS 25.304 [12] and TS 25.331 [33].
If during the Tracking Area Update procedure the MME detects that the Serving GW or/and the MME needs be
relocated, the old MME may reject any PDN GW initiated EPS bearer(s) request received since the Tracking Area
Update procedure started and if rejected, the old MME shall include an indication that the request has been temporarily
rejected due to mobility procedure in progress. The rejection is forwarded by the Serving GW to the PDN GW, with the
indication that the request has been temporarily rejected.
Upon reception of a rejection for an EPS bearer(s) PDN GW initiated procedure with an indication that the request has
been temporarily rejected due to mobility procedure in progress, the PDN GW start a locally configured guard timer.
The PDN GW shall re-attempt, up to a pre-configured number of times, when either it detects that the Tracking Area
Update procedure is completed or has failed using message reception or at expiry of the guard timer.
5.3.3.0A Provision of UE's TAI to MME in ECM-CONNECTED state

The eNodeB shall include the TAI+ECGI of the current cell in every S1-AP UPLINK NAS TRANSPORT message. If
Dual Connectivity is activated for the UE, the eNodeB shall also include the PSCell ID in every S1-AP UPLINK NAS
TRANSPORT message.
NOTE: An eNodeB can contain cells from more than one Tracking Area and intra-eNodeB cell changes are not
normally notified to the MME. However, the MME needs to know the UE's current TAI in order to
correctly produce a TAU accept message.
3GPP
Release 15 141 3GPP TS 23.401 V15.10.0 (2019-12)
5.3.3.1 Tracking Area Update procedure with Serving GW change
UE eNodeB new MME old MME/ new Serving old Serving PDN GW HSS
RNC GW GW
old S4
SGSN
1. Trigger to start
TAU procedure PCRF
2. TAU Request
3. TAU Request
4. Context Request
5. Context Response
6. Authentication / Security
7. Context Acknowledge
9a. PCEF Initiated IP-CAN
Session Modification

(A)

12. Update Location
13. Cancel Location
15. Iu Release Command 14. Cancel Location Ack
16. Iu Release Complete

18. Delete Session Request
20. TAU Accept (B)

21. TAU Complete 19. Delete Session Response
Figure 5.3.3.1-1: Tracking Area Update procedure with Serving GW change
NOTE 1: For a PMIP-based S5/S8, procedure steps (A) and (B) are defined in TS 23.402 [2]. Steps 9 and 10
concern GTP based S5/S8.
NOTE 2: In case of Tracking Area Update without MME change the signalling in steps 4, 5, 7 and steps 12-17 are
skipped.
1. One of the triggers described in clause 5.3.3.0 for starting the TAU procedure occurs.
2. The UE initiates the TAU procedure by sending, to the eNodeB, a TAU Request (UE Core Network Capability,
MS Network Capability, Preferred Network behaviour, Support for restriction of use of Enhanced Coverage, old
GUTI, Old GUTI type, last visited TAI, active flag, signalling active flag, EPS bearer status, P-TMSI Signature,
additional GUTI, eKSI, NAS sequence number, NAS-MAC, KSI, Voice domain preference and UE's usage
setting) message together with RRC parameters indicating the Selected Network and the old GUMMEI. An
exception is that, if the TAU was triggered for load re-balancing purposes (see clause 4.3.7.3), the old GUMMEI
is not included in the RRC parameters. The UE shall set the Old GUTI Type to indicate whether the Old GUTI is
a native GUTI or is mapped from a P-TMSI and RAI.
If the UE's TIN indicates "GUTI" or "RAT-related TMSI" and the UE holds a valid GUTI then the old GUTI
indicates this valid GUTI. If the UE's TIN indicates "P-TMSI" and the UE holds a valid P-TMSI and related RAI
then these two elements are indicated as the old GUTI. Mapping a P-TMSI and RAI to a GUTI is specified in
Annex H. When the UE is in connected mode (e.g. in URA_PCH) when it reselects to E-UTRAN, the UE shall
set its TIN to "P-TMSI".
3GPP
Release 15 142 3GPP TS 23.401 V15.10.0 (2019-12)
If the UE holds a valid GUTI and the old GUTI indicates a GUTI mapped from a P-TMSI and RAI, then the UE
indicates the GUTI as additional GUTI. If the old GUTI indicates a GUTI mapped from a P-TMSI and RAI, and
the UE has a valid P-TMSI signature, the P-TMSI signature shall be included.
The additional GUTI in the Tracking Area Update Request message allows the new MME to find any already
existing UE context stored in the new MME when the old GUTI indicates a value mapped from a P-TMSI and
RAI.
Alternatively, when a UE only supports E-UTRAN, it identifies itself with the old GUTI and sets the Old GUTI
Type to 'native'.
The RRC parameter "old GUMMEI" takes its value from the identifier that is signalled as the old GUTI
according to the rules above. For a combined MME/SGSN the eNodeB is configured to route the MME-code(s)
of this combined node to the same combined node. This eNodeB is also configured to route MME-code(s) of
GUTIs that are generated by the UE's mapping of the P-TMSIs allocated by the combined node. Such an
eNodeB configuration may also be used for separate nodes to avoid changing nodes in the pool caused by inter
RAT mobility.
The last visited TAI shall be included in order to help the MME produce a good list of TAIs for any subsequent
TAU Accept message. Selected Network indicates the network that is selected. Active flag is a request by UE to
activate the radio and S1 bearers for all the active EPS Bearers by the TAU procedure when the UE is in ECM-
IDLE state. Signalling active flag is a request by UE using Control Plane CIoT EPS Optimisation to maintain the
NAS signalling connection after Tracking Area Update Procedure is completed in order to transmit pending Data
using the Data Transport in Control Plane CIoT EPS Optimisation or NAS signalling. The EPS bearer status
indicates each EPS bearer that is active in the UE. The TAU Request message shall be integrity protected by the
NAS-MAC as described in TS 33.401 [41]. eKSI, NAS sequence number and NAS-MAC are included if the UE
has valid EPS security parameters. NAS sequence number indicates the sequential number of the NAS message.
KSI is included if the UE indicates a GUTI mapped from a P-TMSI in the information element "old GUTI".
In the RRC connection establishment signalling associated with the TAU Request, the UE indicates its support
of the CIoT EPS Optimisations relevant for MME selection.
For UE using CIoT EPS Optimisation without any activated PDN connection, there is no active flag or EPS
bearer status included in the TAU Request message. For a UE with a running Service Gap timer in the UE the
UE shall not set the active flag and the signalling active flag in the TAU request message (see clause 4.3.17.9).
If the UE has PDN connection of PDN Type "non-IP", UE shall indicate EPS bearer status included in the TAU
Request message.
The UE sets the voice domain preference and UE's usage setting according to its configuration, as described in
clause 4.3.5.9.
The UE includes extended idle mode DRX parameters information element if it needs to enable extended idle
mode DRX, even if extended idle mode DRX parameters were already negotiated before.
Selected Network and the RAT (NB-IoT or WB-E-UTRAN). If that MME is not associated with that eNodeB or
the GUMMEI is not available or the UE indicates that the TAU procedure was triggered by load re-balancing,
the eNodeB selects an MME as described in clause 4.3.8.3 on "MME Selection Function".
The eNodeB forwards the TAU Request message together with the CSG access mode, CSG ID, TAI+ECGI of
the cell from where it received the message and with the Selected Network to the new MME. CSG ID is
provided by RAN if the UE sends the TAU Request message via a CSG cell or a hybrid cell. CSG access mode
is provided if the UE sends the TAU Request message via a hybrid cell. If the CSG access mode is not provided
but the CSG ID is provided, the MME shall consider the cell as a CSG cell. For SIPTO at the Local Network
with stand-alone GW architecture the eNodeB includes the Local Home Network ID in the Initial UE Message
and in Uplink NAS Transport message if the target cell is in a Local Home Network.
3GPP
Release 15 143 3GPP TS 23.401 V15.10.0 (2019-12)
4. The new MME differentiates the type of the old node, i.e. MME or SGSN, as specified in clause 4.3.19, uses the
GUTI received from the UE to derive the old MME/S4 SGSN address, and sends a Context Request (old GUTI,
complete TAU Request message, P-TMSI Signature, MME Address, UE validated, CIoT EPS Optimisation
support inidication) message to the old MME/old S4 SGSN to retrieve user information. UE Validated indicates
that the new MME has validated the integrity protection of the TAU message, e.g. based on native EPS security
context for the UE. To validate the Context Request the old MME uses the complete TAU Request message and
the old S4 SGSN uses the P-TMSI Signature and responds with an appropriate error if integrity check fails in old
MME/S4 SGSN. This shall initiate the security functions in the new MME. If the security functions authenticate
the UE correctly, the new MME shall send a Context Request (IMSI, complete TAU Request message, MME
Address, UE Validated) message to the old MME/S4 SGSN with the UE Validated set. If the new MME
indicates that it has authenticated the UE or if the old MME/old S4 SGSN correctly validates the UE, then the
old MME/old S4 SGSN starts a timer.
If the UE with emergency bearers is not authenticated in the old MME/old S4 SGSN (in a network supporting
unauthenticated UEs) the old MME/old S4 SGSN continues the procedure with sending a Context Response and
starting the timer also when it cannot validate the Context Request.
If the new MME supports CIoT EPS Optimisation, CIoT EPS Optimisation support indication is included in the
Context Request indicating support for various CIoT EPS Optimisations (e.g. support for header compression for
CP CIoT EPS Optimisation, etc.).
5. If the Context Request is sent to an old MME the old MME responds with a Context Response (IMSI, ME
Identity (IMEISV), MM Context, EPS Bearer Context(s), Serving GW signalling Address and TEID(s), ISR
Supported, MS Info Change Reporting Action (if available), CSG Information Reporting Action (if available),
UE Time Zone, UE Core Network Capability, UE Specific DRX Parameters, Remaining Running Service Gap
timer, LTE-M UE Indication) message. If the new MME supports CIoT EPS Optimisation and the use of header
compression has been negotiated between the UE and the old MME, the Context Response also includes the
Header Compression Configuration which includes the information necessary for the ROHC channel setup but
not the RoHC context itself.
If the Context Request is sent to an old S4 SGSN the old S4 SGSN responds with a Context Response (MM
Context, EPS Bearer Context(s), Serving GW signalling Address and TEID(s), ISR Supported, MS Info Change
Reporting Action (if available), CSG Information Reporting Action (if available), UE Time Zone, UE Core
Network Capability, UE Specific DRX Parameters). If the source MME has not yet reported a non-zero MO
Exception Data Counter to the PDN GW, the Context Response also includes the MO Exception Data Counter as
The MM Context contains security related information as well as other parameters (including IMSI and ME
Identity (if available)) as described in clause 5.7.2 (Information Storage for MME). The unused Authentication
Quintets in the MM Context are also maintained in the SGSN. TS 33.401 [41] gives further details on the
transfer of security related information.
If the MM Context received with the Context Response message did not include IMEISV and the MME does not
already store the IMEISV of the UE, the MME shall retrieve the ME Identity (IMEISV) from the UE.
The PDN GW Address and TEID(s) (for GTP-based S5/S8) or GRE Keys (PMIP-based S5/S8 at the PDN
GW(s) for uplink traffic) and the TI(s), is part of the EPS Bearer Context. If the UE is not known in the old
MME/old S4 SGSN or if the integrity check for the TAU Request message fails, the old MME/old S4 SGSN
responds with an appropriate error cause. ISR Supported is indicated if the old MME/old S4 SGSN and
associated Serving GW are capable to activate ISR for the UE.
If the UE receives emergency bearer services from the old MME/old S4 SGSN and the UE is UICCless, IMSI
can not be included in the Context Response. For emergency attached UEs, if the IMSI cannot be authenticated,
then the IMSI shall be marked as unauthenticated. Also, in this case, security parameters are included only if
available.
If SIPTO at the Local Network is active for a PDN connection in the architecture with stand-alone GW, the old
MME/old S4 SGSN shall include the Local Home Network ID of the old cell in the EPS Bearer context
corresponding to the SIPTO at the Local Network PDN connection.
For UE using CIoT EPS Optimisation without any activated PDN connection, there is no EPS Bearer Context(s)
included in the Context Response message.
3GPP
Release 15 144 3GPP TS 23.401 V15.10.0 (2019-12)
Based on the CIoT EPS Optimisation support indication, old MME only transfers the EPS Bearer Context(s) that
the new MME supports. If the new MME does not support CIoT EPS Optimisation, EPS Bearer Context(s) of
non-IP PDN connection are not transferred to the new MME. If the EPS Bearer Context(s) of a PDN connection
has not been transferred, the old MME shall consider all bearers of that PDN connection as failed and release
that PDN connection by triggering the MME requested PDN disconnection procedure specified in clause 5.10.3.
The buffered data in the old MME is discarded after receipt of Context Acknowledgement.
If the EPS Bearer Context(s) are to be transferred to the new MME, the old MME also includes the Serving GW
IP address and TEID for both S1-U and S11-U, if available.
If the Old MME is aware the UE is a LTE-M UE, it provides the LTE-M UE Indication to the new MME.
6. If the integrity check of TAU Request message (sent in step 2) failed, then authentication is mandatory. The
authentication functions are defined in clause 5.3.10 on "Security Function". Ciphering procedures are described
in clause 5.3.10 on "Security Function". If GUTI allocation is going to be done and the network supports
ciphering, the NAS messages shall be ciphered.
If this TAU request is received for a UE which is already in ECM_CONNECTED state and the PLMN-ID of the
TAI sent by the eNodeB in Step 3 is different from that of the GUTI, included in the TAU Request message, the
MME shall delay authenticating the UE until after Step 21 (TAU Complete message).
NOTE 3: The MME delays the authentication such that the UE first updates its registered PLMN-ID to the new
PLMN-ID selected by the RAN during handover. The new PLMN-ID is provided by the MME to the UE
as part of the GUTI in the TAU accept message in Step 20. Doing this ensures that the same PLMN-ID is
used in the derivation of the Kasme key by both the network and the UE.
If the new MME is configured to allow emergency bearer services for unauthenticated UE the new MME behave
as follows:
- where a UE has only emergency bearer services, the MME either skip the authentication and security
procedure or accepts that the authentication may fail and continues the Tracking Area Update procedure; or
- where a UE has both emergency and non emergency bearer services and authentication fails, the MME
continues the Tracking Area Update procedure and deactivates all the non-emergency PDN connections as
specified in clause 5.10.3.
7. The MME (if the MME has changed then it is the new MME) determines to relocate the Serving GW. The
Serving GW is relocated when the old Serving GW cannot continue to serve the UE. The MME (if the MME has
changed then it is the new MME) may also decide to relocate the Serving GW if a new Serving GW is expected
to serve the UE longer and/or with a more optimal UE to PDN GW path, or if a new Serving GW can be co-
located with the PDN GW. Selection of a new Serving GW is performed according to clause 4.3.8.2 on "Serving
GW selection function".
If the MME has changed the new MME sends a Context Acknowledge (Serving GW change indication) message
to the old MME/old S4 SGSN. Serving GW change indication indicates a new Serving GW has been selected.
The old MME/old S4 SGSN marks in its UE context that the information in the GWs is invalid. And, if the old
node is an MME, the old MME marks in its UE context that the information in the HSS is invalid. This ensures
that the old MME/old S4 SGSN updates the GWs, and the old MME updates the HSS, if the UE initiates a TAU
or RAU procedure back to the old MME/old S4 SGSN before completing the ongoing TAU procedure.
NOTE 4: Updating the GWs refers to deletion of session(s) on the Serving GW followed by re-creation of
session(s) on the Serving GW. The re-creation of session(s) on the Serving GW will result in successful
re-establishment of the S5/S8 tunnel between the selected Serving GW and the PDN GW.
If the security functions do not authenticate the UE correctly, then the TAU shall be rejected, and the new MME
shall send a reject indication to the old MME/old S4 SGSN. The old MME/old S4 SGSN shall continue as if the
Identification and Context Request was never received.
ISR is not indicated in the Context Acknowledge as ISR is not activated due to the S-GW change.
For UE using CIoT EPS Optimisation without any activated PDN connection, the steps 8, 9, 10, 11, 18 and 19
are skipped.
8. If the MME has changed the new MME verifies the EPS bearer status received from the UE with the bearer
contexts received from the old MME/old S4 SGSN. If the MME has not changed the MME verifies EPS bearer
3GPP
Release 15 145 3GPP TS 23.401 V15.10.0 (2019-12)
status from the UE with the bearer contexts available in the MM context. The MME releases any network
resources related to EPS bearers that are not active in the UE. If there is no bearer context at all, the MME rejects
the TAU Request.
If the MME selected a new Serving GW it sends a Create Session Request (IMSI, bearer contexts, MME
Address and TEID, Type, the Protocol Type over S5/S8, RAT type, LTE-M RAT type reporting to PGW flag,
Serving Network, UE Time Zone, MO Exception data counter) message per PDN connection to the selected new
Serving GW. The PDN GW address and TFT (for PMIP-based S5/S8) are indicated in the bearer Contexts. Type
indicates to the Serving GW to send the Modify Bearer Request to the PDN GW. The Protocol Type over S5/S8
is provided to Serving GW which protocol should be used over S5/S8 interface. RAT type indicates a change in
radio access. If it is a mobility from a SGSN to a MME and if the MME supports location information change
reporting, the MME shall include the User Location Information (according to the supported granularity) in the
Create Session Request, regardless of whether location information change reporting had been requested in the
previous RAT by the PDN GW. If it is an inter MME mobility and if the PDN GW requested location
information change reporting, the MME includes the User Location Information IE in this message if it is
different compared to the previously sent information. If the PDN GW requested User CSG information, the
MME also includes the User CSG Information IE in this message. If Control Plane CIoT EPS Optimisation
applies, the MME may also indicate S11-U tunnelling of NAS user data and send its own S11-U IP address and
MME DL TEID for DL data forwarding by the SGW. The MME shall include the MO Exception data counter if
it has received the counter for RRC cause "MO Exception data" in the Context Response message.
If only the Control Plane CIoT EPS Optimisation is used, the MME shall include a Control Plane Only PDN
Connection Indicator in Create Session Request.
If the new MME receives the EPS bearer context with SCEF, then the new MME updates the SCEF as defined in
TS 23.682 [74].
If the UE is using the LTE-M RAT type and the PDN GW expects the LTE-M RAT type reporting as specified
in clause 5.11.5, the MME also includes the LTE-M RAT type reporting to PGW flag to indicate to the Serving
GW to forward the LTE-M RAT type to the PDN GW.
9. The Serving GW informs the PDN GW(s) about the change of for example the RAT type that e.g. can be used
for charging, by sending the message Modify Bearer Request (Serving GW Address and TEID, RAT type,
Serving Network, PDN Charging Pause Support Indication) per PDN connection to the PDN GW(s) concerned.
User Location Information IE and/or UE Time Zone IE and/or User CSG Information IE and/or MO Exception
data counter are also included if they are present in step 8. The Serving GW and PDN GW indicate each use of
the RRC establishment cause "MO Exception Data" by the related counter on its CDR.
indicates the use of CP only on its CDR.
If LTE-M RAT type and the LTE-M RAT type reporting to PGW flag were received at step 8, the Serving GW
shall include the LTE-M RAT type in the Modify Bearer Request message to the PGW. Otherwise the Serving
GW includes RAT type WB-E-UTRAN.
9a If dynamic PCC is deployed, and RAT type information needs to be conveyed from the PDN GW to the PCRF,
then the PDN GW shall send RAT type information to the PCRF by means of an IP-CAN Session Modification
procedure as defined in TS 23.203 [6].
NOTE 5: The PDN GW does not need to wait for the PCRF response, but continues in the next step. If the PCRF
response leads to an EPS bearer modification the PDN GW should initiate a bearer update procedure.
10. The PDN GW updates its bearer contexts and returns a Modify Bearer Response (MSISDN, Charging Id, PDN
Charging Pause Enabled Indication (if PDN GW has chosen to enable the function)) message. The MSISDN is
included if the PDN GW has it stored in its UE context. If there has been a RAT change towards E-UTRAN and
location information change reporting is required and supported in the target MME, the PDN GW shall provide
MS Info Change Reporting Action in the Modify Bearer Response.
If the Serving GW is relocated, the PDN GW shall send one or more "end marker" packets on the old path
immediately after switching the path in order to assist the reordering function in the target eNodeB. If the
Serving GW has no downlink user plane established, the Serving GW shall discard the "end marker" received
from the PDN GW and shall not send Downlink Data Notification. Otherwise the Serving GW shall forward the
"end marker" packets to the source eNodeB or source S4 SGSN.
3GPP
Release 15 146 3GPP TS 23.401 V15.10.0 (2019-12)
11. The Serving GW updates its bearer context. This allows the Serving GW to route bearer PDUs to the PDN GW
when received from eNodeB.
The Serving GW returns a Create Session Response (Serving GW address and TEID for user plane and control
plane and PDN GW TEIDs (for GTP-based S5/S8) or GRE keys (for PMIP-based S5/S8) for uplink traffic and
control plane, MS Info Change Reporting Action) message to the new MME.
If Control Plane CIoT EPS Optimisation applies and if the MME does not include Control Plane Only PDN
TEID for S11-U and additionally the Serving GW IP address and TEID for S1-U in the Create Session
Response.
- Otherwise, if separation of S11-U from S1-U is not required, the Serving GW includes the Serving GW IP
When the MME receives the Create Session Response message, the MME checks if there is a "Availability after
DDN Failure" monitoring event or a "UE Reachability" monitoring event configured for the UE in the MME and
in such a case sends an event notification (see TS 23.682 [74] for further information).
12. The new MME verifies whether it holds subscription data for the UE identified by the GUTI, the additional
GUTI or by the IMSI received with the context data from the old CN node.
If there are no subscription data in the new MME for this UE, or for some network sharing scenario (e.g.
GWCN) if the PLMN-ID of the TAI supplied by the eNodeB is different from that of the GUTI in the UE's
context, then the new MME sends an Update Location Request (MME Identity, IMSI, ULR-Flags, MME
Capabilities, Homogeneous Support of IMS Voice over PS Sessions, UE SRVCC capability, equivalent PLMN
list, ME Identity (IMEISV)) message to the HSS. ULR-Flags indicates that update location is sent from an MME
and the MME registration shall be updated in HSS. The HSS does not cancel any SGSN registration. The MME
capabilities indicate the MME's support for regional access restrictions functionality. The inclusion of the
equivalent PLMN list indicates that the MME supports the inter-PLMN handover to a CSG cell in an equivalent
PLMN using the subscription information of the target PLMN. The "Homogenous Support of IMS Voice over
PS Sessions" indication (see clause 4.3.5.8A) shall not be included unless the MME has completed its evaluation
of the support of "IMS Voice over PS Session" as specified in clause 4.3.5.8. The ME Identity is included if
step 5 caused the MME to retrieve the IMEISV from the UE.
NOTE 6: At this step, the MME may not have all the information needed to determine the setting of the IMS Voice
If the UE initiates the TAU procedure in a VPLMN supporting Autonomous CSG Roaming and the HPLMN has
enabled Autonomous CSG Roaming in the VPLMN (via Service Level Agreement) and the MME needs to
retrieve the CSG subscription information of the UE from the CSS, the MME initiates the Update CSG Location
Procedure with CSS as described in clause 5.3.12.
If all the EPS bearers of the UE have emergency ARP value, the new MME may skip the update location
procedure or proceed even if the update location fails.
13. The HSS sends the message Cancel Location (IMSI, Cancellation Type) to the old MME with Cancellation Type
set to Update Procedure.
14. If the timer started in step 4 is not running, the old MME removes the MM context. Otherwise, the contexts are
removed when the timer expires. It also ensures that the MM context is kept in the old MME for the case the UE
initiates another TAU procedure before completing the ongoing TAU procedure to the new MME. The old MME
acknowledges with the message Cancel Location Ack (IMSI).
15. When old S4 SGSN receives the Context Acknowledge message and if the UE is in Iu Connected, the old
S4 SGSN sends an Iu Release Command message to the RNC after the timer started in step 4 has expired.
16. The RNC responds with an Iu Release Complete message.
3GPP
Release 15 147 3GPP TS 23.401 V15.10.0 (2019-12)
17. The HSS acknowledges the Update Location Request message by sending an Update Location Ack (IMSI,
Subscription Data) message to the new MME. The Subscription Data may contain the CSG subscription data for
the registered PLMN and for the equivalent PLMN list requested by MME in step 12.
The subscription data may contain a Service Gap Time. If received from the HSS, the MME stores this Service
Gap Time in the MME MM context for the UE and passes it to the UE in the Tracking Area Update Accept
message.
If the Update Location is rejected by the HSS, the new MME rejects the TAU Request from the UE with an
appropriate cause. In such cases, the new MME releases any local MME EPS Bearer contexts for this particular
UE, and additionally deletes the EPS bearer resources in the new Serving GW by sending the Delete Session
Request (Cause, Operation Indication) messages to the new Serving GW. The Operation Indication flag shall not
be set. Therefore, the new Serving GW receiving this request shall not initiate a delete procedure towards the
PDN GW.
If the UE initiates the TAU procedure at a CSG cell, the new MME shall check whether the CSG ID and
associated PLMN is contained in the CSG subscription and is not expired. If the CSG ID and associated PLMN
is not present or expired, the MME shall send a Tracking Area Update reject message to the UE with an
appropriate cause value. The UE shall remove the CSG ID and associated PLMN from its Allowed CSG list if
present. If the UE has ongoing emergency bearer services no CSG access control shall be performed.
If all checks are successful then the new MME constructs a context for the UE.
18. If the MME has changed, when the timer started in step 4 expires the old MME/old S4 SGSN releases any local
MME or SGSN bearer resources and additionally the old MME/old S4 SGSN deletes the EPS bearer resources
by sending the Delete Session Request (Cause, Operation Indication) messagesto the old Serving GW if it
received the Serving GW change indication in the Context Acknowledge message in step 7. When the Operation
Indication flag is not set, that indicates to the old Serving GW that the old Serving GW shall not initiate a delete
procedure towards the PDN GW. If ISR is activated the Cause indicates to the old S-GW that the old S-GW shall
delete the bearer resources on the other old CN node by sending Delete Bearer Request message(s) to that CN
node.
If the MME has not changed, step 11 triggers the release of the EPS bearer resources at the old Serving GW.
19. The Serving GW acknowledges with Delete Session Response (Cause) messages. The Serving GW discards any
packets buffered for the UE.
20. If due to regional subscription restrictions or access restrictions (e.g. CSG restrictions) the UE is not allowed to
access the TA:
- The MME rejects the Tracking Area Update Request with an appropriate cause to the UE.
- For UEs with emergency EPS bearers, i.e. at least one EPS bearer has an ARP value reserved for emergency
services, the new MME accepts the Tracking Area Update Request and deactivates all non-emergency PDN
connections as specified in clause 5.10.3. If the Tracking Area Update procedure is initiated in ECM-IDLE
state, all non-emergency EPS bearers are deactivated by the Tracking Area Update procedure without bearer
deactivation signalling between the UE and the MME.
The MME sends a TAU Accept (GUTI, TAI list, EPS bearer status, NAS sequence number, NAS-MAC, IMS
Voice over PS session supported, Emergency Service Support indicator, LCS Support Indication, Supported
Network Behaviour, Service Gap Time, Enhanced Coverage Restricted, Indication of support of 15 EPS bearers
per UE) message to the UE. If the active flag is set the MME may provide the eNodeB with Handover
Restriction List. GUTI is included if the MME allocates a new GUTI. If the active flag is set in the TAU Request
message the user plane setup procedure can be activated in conjunction with the TAU Accept message. If the DL
Data Buffer Expiration Time for the UE in the MME has not expired, the user plane setup procedure is activated
even if the MME did not receive the active flag in the TAU Request message. If the new MME receives the
Downlink Data Notification message or any downlink signalling message while the UE is still connected, the
3GPP
Release 15 148 3GPP TS 23.401 V15.10.0 (2019-12)
user plane setup procedure may be activated even if the new MME did not receive the active flag in the TAU
Request message. The procedure is described in detail in TS 36.300 [5]. The message sequence should be the
same as for the UE triggered Service Request procedure specified in clause 5.3.4.1 from the step when MME
establishes the bearer(s). The MME indicates the EPS bearer status IE to the UE. The UE removes any internal
resources related to bearers that are not marked active in the received EPS bearer status. If the EPS bearer status
information was in the TAU Request, the MME shall indicate the EPS bearer status to the UE. Handover
Restriction List is described in clause 4.3.5.7 "Mobility Restrictions". The MME sets the IMS Voice over PS
session supported as described in clause 4.3.5.8.
For UE using CIoT EPS Optimisation without any activated PDN connection, there is no EPS bearer status
included in the TAU Accept message.
The MME indicates the CIoT EPS Optimisations it supports and prefers in the Supported Network Behaviour
information as defined in clause 4.3.5.10.
If there is a Service Gap timer running for the UE in the MME, and the active flag or the signalling active flag is
received in the TAU Request message, the MME shall ignore the active flag and signalling active flag and not
perform any of the actions related to these flags.
The MME shall include the Service Gap Time in the TAU Accept message if the UE has indicated Service Gap
Control capability and either if Service Gap Time was received in step 17 from HSS in the subscription
information or if the Service Gap Time in the subscription information has been updated by HSS User Profile
management (i.e. the Insert Subscriber Data procedure in clause 5.3.9.2).
Coverage Restricted parameter to the eNB in the S1-AP message as defined in clause 4.3.28. The MME also
sends the Enhanced Coverage Restricted parameter to the UE in the TAU Accept message. UE shall store
Enhanced Coverage Restricted parameter and shall use the value of Enhanced Coverage Restricted parameter to
determine if enhanced coverage feature should be used or not.
If the MME successfully obtained Header Compression Configuration parameters in step 5 it indicates the
continued use of previous negotiated configuration to the UE in the Header Compression Context Status for each
EPS Bearer of the UE. When Header Compression Context Status indicates that the previous negotiated
configuration can no longer be used for some EPS bearers, the UE shall stop performing header compression and
decompression, when sending or receiving data using Control Plane CIoT EPS Optimisation on these EPS
bearers.
If the MME did not receive the Voice Support Match Indicator in the MM Context, then the MME may send a
UE Radio Capability Match Request to the eNB as described in clause 5.3.14. If the MME hasn't received Voice
Support Match Indicator from the eNB then, based on implementation, MME may set IMS Voice over PS
session supported Indication and update it at a later stage. After step 12, and in parallel to any of the preceding
steps, the MME shall send a Notify Request (Homogeneous Support of IMS Voice over PS Sessions) message to
the HSS:
The Emergency Service Support indicator informs the UE that Emergency bearer services are supported. LCS
Support Indication indicates whether the network supports the EPC-MO-LR and/or CS-MO-LR as described in
TS 23.271 [57]. Indication for support of 15 EPS bearers per UE indicates the network support for up to 15 EPS
bearers per UE as defined in clause 4.12.
mode DRX parameters information element if it decides to enable extended idle mode DRX with Paging Time
Window length assigned considering Subscribed Paging Time Window (if available) and the local policy.
When receiving the TAU Accept message and there is no ISR Activated indication the UE shall set its TIN to
"GUTI".
For a S-GW change, ISR Activated is never indicated by the MME as it needs a RAU with the same S-GW first
to activate ISR. For an MME change, ISR is not activated by the new MME to avoid context transfer procedures
with two old CN nodes.
3GPP
Release 15 149 3GPP TS 23.401 V15.10.0 (2019-12)
If the TAU procedure is initiated by manual CSG selection and occurs via a CSG cell, the UE upon receiving the
TAU Accept message shall add the CSG ID and associated PLMN to its Allowed CSG list if it is not already
present. Manual CSG selection is not supported if the UE has emergency bearers established.
If the user plane setup is performed in conjunction with the TAU Accept message and the TAU is performed via
a hybrid cell, then the MME shall send an indication whether the UE is a CSG member to the RAN along with
the S1-MME control message. Based on this information the RAN may perform differentiated treatment for
CSG and non-CSG members.
NOTE 7: If the UE receives a TAU Accept message via a hybrid cell, the UE does not add the corresponding CSG
ID and associated PLMN to its Allowed CSG list. Adding a CSG ID and associated PLMN to the UE's
local Allowed CSG list for a hybrid cell is performed only by OTA or OMA DM procedures.
If the UE receives a Service Gap Time in the TAU Accept message, the UE shall store this parameter and apply
Service Gap Control (see clause 4.3.17.9).
21. If GUTI was included in the TAU Accept, the UE acknowledges the received message by returning a TAU
Complete message to the MME.
When the "Active flag" is not set in the TAU Request message and the Tracking Area Update was not initiated
in ECM-CONNECTED state, the new MME releases the signalling connection with UE, according to
clause 5.3.5. For a UE using Control Plane CIoT EPS Optimisation, when the "Signalling active flag" is set, the
new MME shall not release the NAS signalling connection with the UE immediately after the TAU procedure is
completed.
NOTE 8: The new MME may initiate E-RAB establishment (see TS 36.413 [36]) after execution of the security
functions, or wait until completion of the TA update procedure. For the UE, E-RAB establishment may
occur anytime after the TA update request is sent.
In the case of a rejected tracking area update operation, due to regional subscription, roaming restrictions or access
restrictions (see TS 23.221 [27] and TS 23.008 [28]) the new MME should not construct an MM context for the UE. In
the case of receiving the subscriber data from HSS, the new MME may construct an MM context and store the
subscriber data for the UE to optimise signalling between the MME and the HSS. A reject shall be returned to the UE
with an appropriate cause and the S1 connection shall be released. Upon return to idle, the UE shall act according to
TS 23.122 [10].
The new MME shall determine the Maximum APN restriction based on the received APN Restriction of each bearer
context in the Context Response message and then store the new Maximum APN restriction value.
The bearer contexts shall be prioritized by the new MME. If the new MME is unable to support the same number of
active bearer contexts as received from old MME/SGSN, the prioritisation is used to decide which bearer contexts to
maintain active and which ones to delete. In any case, the new MME shall first update all contexts in one or more
P-GWs and then deactivate the bearer context(s) that it cannot maintain as described in the clause "MME Initiated
Dedicated Bearer Deactivation Procedure". This shall not cause the MME to reject the tracking area update.
The new MME shall not deactivate emergency service related EPS bearers, i.e. EPS bearers with ARP value reserved
for emergency services.
NOTE 9: If MS (UE) was in PMM-CONNECTED state the bearer contexts are sent already in the Forward
Relocation Request message as described in the clause "Serving RNS relocation procedures" of
TS 23.060 [7].
If the tracking area update procedure fails a maximum allowable number of times, or if the MME returns a Tracking
Area Update Reject (Cause) message, the UE shall enter EMM DEREGISTERED state.
If the new MME identifies that the RAT type has changed, the MME checks the subscription information to identify for
each APN whether to maintain the PDN connection, disconnect the PDN connection with a reactivation request, or,
disconnect the PDN connection without reactivation request. If the MME decides to deactivate a PDN connection it
performs MME-initiated PDN Connection Deactivation procedure after the tracking area update procedure is completed
but before the S1/RRC interface connection is released. Existing ESM cause values as specified in TS 24.301 [46] (e.g.
#39, "reactivation requested"; #66 "Requested APN not supported in current RAT and PLMN combination"; and for a
dedicated bearer, possibly #37 "EPS QoS not accepted") are used to cause predictable UE behaviour. If all the PDN
connections are disconnected and the UE does not support "attach without PDN connectivity", the MME shall request
the UE to detach and reattach.
3GPP
Release 15 150 3GPP TS 23.401 V15.10.0 (2019-12)
5.3.3.1A Tracking Area Update procedure with Serving GW change and data
forwarding
UE eNodeB RNC new MME old MME/ new S-GW old S-GW
P-GW HSS
old S4
SGSN
1. Trigger to start
TAU procedure PCRF
2. TAU Request
3. TAU Request
4. Context Request
5. Context Response ("Buffered DL data waiting")

9a. PCEF Initiated IP-CAN
9a. Update Location

9b. Cancel Location
9b. Cancel Location Ack
9c. Update Location Ack

10. TAU Accept
10. TAU Complete (A)
11. Initial Context Setup Request

11. Initial Context Setup Complete (eNB F-TEID)
12. Modify Bearer Request (eNB F-TEID)
13. Create Indirect Forwarding Tunnel Request (eNB F-TEID)

13. Create Indirect Forwarding Tunnel Response (Forwarding F-TEID)
14. Context Acknowledge (Forwarding F-TEID, Forwarding indication)

15. Modify Bearer Request (Forwarding F-TEID)
16.Forwarding of DL data buffered
17. Iu Release Command
18. Delete Session Response

(B)
19. Delete Indirect Forwarding Tunnel Request

19. Delete Indirect Forwarding Tunnel Response
3GPP
Release 15 151 3GPP TS 23.401 V15.10.0 (2019-12)
Figure 5.3.3.1A-1: Tracking Area Update procedure with Serving GW change and data forwarding
NOTE 1: The procedure steps (A) and (B) are defined in clause 5.3.3.1. Step 5 in the figure above has compared to
clause 5.3.3.1 one additional parameter which is described below.
4. The timer setting by the old S4 SGSN or MME in step 4 (as in clause 5.3.3.1) shall ensure that the buffered data
in the old Serving GW can be forwarded before the old Serving GW resource is released.
5. DL data is being buffered in the old Serving GW and the DL Data Expiration Time has not expired, therefore the
old MME/old S4-SGSN indicates Buffered DL Data Waiting in the Context Response. This triggers the new
MME to setup the user plane and invoke data forwarding. For Control Plane CIoT EPS Optimisation, if the DL
data is buffered in the old Serving GW, and when the Buffered DL Data Waiting is indicated, the new MME
shall setup the S11 user plane with the new Serving GW and invoke data forwarding. If the DL data is buffered
in the old MME and the DL Data Expiration Time has not expired, the old MME shall discard the buffered DL
data.
11-12. The user plane is setup. These procedure steps are defined in clause 5.3.4.1, steps 4-7 and steps 8-12
respectively in the UE Triggered Service Request procedure.
NOTE 2: It is assumed that Pause of PGW Charging is not invoked by SGW that is performing extended data
buffering.
For Control Plane CIoT EPS Optimisation, steps 11 and 12 are skipped.
13. Since it was indicated in step 5 that buffered DL data is waiting, the new MME sets up forwarding parameters by
sending Create Indirect Data Forwarding Tunnel Request (target eNodeB addresses and TEIDs for forwarding)
to the Serving GW. The Serving GW sends a Create Indirect Data Forwarding Tunnel Response (target Serving
GW addresses and TEIDs for forwarding) to the target MME. For Control Plane CIoT EPS Optimisation, the
new MME sets up forwarding parameters by sending Create Indirect Data Forwarding Tunnel Request (target
MME address and TEID for forwarding) to the Serving GW. Upon receipt of the Create Indirect Data
Forwarding Tunnel Response message the new MME starts a timer for release of resources if resources for
indirect forwarding were allocated in the new S-GW.
Indirect forwarding may be performed via a Serving GW which is different from the Serving GW used as the
anchor point for the UE.
14. This procedure step is defined in clause 5.3.3.1, step 7. In addition the new MME includes the F-TEID where
buffered DL data should be forwarded and a Forwarding indication in the Context Acknowledge message. The
F-TEID is the F-TEID for the indirect forwarding received from step 13 or it may be the F-TEID of the eNB
(when eNB supports forwarding).
15. A Modify Bearer Request( F-TEID ) is sent to the old Serving GW. The F-TEID is the Forwarding F-TEID
where the buffered DL data shall be forwarded.
16. The old Serving GW forwards its buffered data towards the received F-TEID in step 15. The buffered DL data is
sent to the UE over the radio bearers established in step 11. For Control Plane CIoT EPS Optimisation, the
buffered DL data is sent to the new MME from the new Serving GW and is sent to the UE as described in steps
12-14 of clause 5.3.4B.3.
17-18. As steps 15-16, 18-19 in clause 5.3.3.1.
19. If indirect forwarding was used, then the expiry of the timer at the new MME started at step 13 triggers the new
MME to send a Delete Indirect Data Forwarding Tunnel Request message to the new S-GW to release temporary
resources used for indirect forwarding that were allocated at step 13.
3GPP
Release 15 152 3GPP TS 23.401 V15.10.0 (2019-12)
5.3.3.2 E-UTRAN Tracking Area Update without S-GW Change
RNC Old MME / Serving PDN

PDN
UE eNodeB BSC MME Old S4 SGSN GW GW PCRF HSS
1. Trigger to start TAU

procedure
2. Tracking Area Update Request
4. Context Request
5. Context Response

11. PCEF Initiated IP-CAN
12. Modify Bearer Response (A)


15. Cancel Location

20. Tracking Area Update Accept

21. Tracking Area Update Complete
Figure 5.3.3.2-1: E-UTRAN Tracking Area Update without S-GW change
NOTE 1: For a PMIP-based S5/S8, procedure steps (A) are defined in TS 23.402 [2]. Steps 12 and 14 concern GTP
based S5/S8.
NOTE 2: In case of Tracking Area Update without MME change the signalling in steps 4, 5, 7 and steps 9-19 are
skipped. A change of UE Time Zone, User CSG information or Serving Network is signalled in the next
Service Request. If TAI change need to be reported to the PDN GW, location information change
reporting procedure described in clause 5.9.2 is performed.
3GPP
Release 15 153 3GPP TS 23.401 V15.10.0 (2019-12)
NOTE 3: Deferred reporting of UE Time Zone, or Serving Network per NOTE 2 may fail when inter-MME/SGSN
mobility occurs before a UE sends SERVICE REQUEST and the target MME/SGSN (e.g. pre-Release
10) does not support the "Change to Report" flag.
2. The UE initiates a TAU procedure by sending, to the eNodeB, a Tracking Area Update Request (UE Core
Network Capability, MS Network Capability, Preferred Network behaviour, Support for restriction of use of
Enhanced Coverage, active flag, signalling active flag, EPS bearer status, old GUTI, Old GUTI Type, last visited
TAI, P-TMSI signature, additional GUTI, KSISGSN, KSIASME, NAS sequence number, NAS-MAC, Voice domain
preference and UE's usage setting) message together with RRC parameters indicating the Selected Network and
the old GUMMEI. An exception is that, if the TAU was triggered for load re-balancing purposes (see
clause 4.3.7.3), the old GUMMEI is not included in the RRC parameters. The UE shall set the Old GUTI Type to
indicate whether the Old GUTI is a native GUTI or is mapped from a P-TMSI and RAI.
then these two elements are indicated as the old GUTI. Mapping a P-TMSI and RAI to a GUTI is specified in
Annex H. When the UE is in connected mode (e.g. in URA_PCH) when it reselects to E-UTRAN, the UE shall
set its TIN to "P-TMSI".
indicates the GUTI as additional GUTI. If the old GUTI indicates a GUTI mapped from a P-TMSI and RAI, and
the UE has a valid P-TMSI signature, the P-TMSI signature shall be included.
The additional GUTI in the Tracking Area Update Request message allows the new MME to find any already
existing UE context stored in the new MME when the old GUTI indicates a value mapped from a P-TMSI and
RAI.
Alternatively, when a UE only supports E-UTRAN, it identifies itself with the old GUTI and sets the Old GUTI
Type to 'native'.
GUTIs that are generated the UE's mapping of the P-TMSIs allocated by the combined node. Such an eNodeB
configuration may also be used for separate nodes to avoid changing nodes in the pool caused by inter RAT
mobility.
The last visited TAI shall be included in order to help the MME produce a good list of TAIs for any subsequent
TAU Accept message. Selected Network indicates the network that is selected. Active flag is a request by the
UE to activate the radio and S1 bearers for all the active EPS Bearers by the TAU procedure. Signalling active
flag is a request by UE using Control Plane CIoT EPS Optimisation to maintain the NAS signalling connection
after Tracking Area Update Procedure is completed in order to transmit pending Data using the Data Transport
in Control Plane CIoT EPS Optimisation or NAS signalling. The UE's ISR capability is included in the UE Core
Network Capability element. The EPS bearer status indicates each EPS bearer that is active in the UE. The TAU
Request message shall be integrity protected by the NAS-MAC as described in TS 33.401 [41]. KSIASME is
included if the UE has valid security parameters. NAS sequence number indicates the sequential number of the
NAS message.
For UE using CIoT EPS Optimisation without any activated PDN connection, there is no active flag or EPS
bearer status included in the TAU Request message. For a UE with a running Service Gap timer in the UE the
UE shall not set the active flag or the signalling active flag in the TAU request message (see clause 4.3.17.9).
If the UE has PDN connection of PDN Type "non-IP", UE shall indicate EPS bearer status included in the TAU
Request message.
KSISGSN is included if the UE indicates a GUTI mapped from a P-TMSI in the information element "old GUTI".
clause 4.3.5.9.
3GPP
Release 15 154 3GPP TS 23.401 V15.10.0 (2019-12)
The UE includes extended idle mode DRX parameters information element if it needs to enable extended idle
mode DRX, even if extended idle mode DRX parameters were already negotiated before.
Selected Network and the RAT (NB-IoT or WB-E-UTRAN). If that GUMMEI is not associated with the
eNodeB, or the GUMMEI is not available or the UE indicates that the TAU procedure was triggered by load re-
balancing, the eNodeB selects the MME as described in clause 4.3.8.3 on "MME Selection Function". The
eNodeB forwards the TAU Request message together with the CSG access mode, CSG ID, TAI+ECGI of the
cell from where it received the message and with the Selected Network to the MME. CSG ID is provided by
RAN if the UE sends the TAU Request message via a CSG cell or a hybrid cell. CSG access mode is provided if
the UE sends the TAU Request message via a hybrid cell. If the CSG access mode is not provided but the CSG
ID is provided, the MME shall consider the cell as a CSG cell. For SIPTO at the Local Network with stand-alone
GW architecture the eNodeB includes the Local Home Network ID in the Initial UE Message and in Uplink
NAS Transport message if the target cell is in a Local Home Network.
4. The new MME differentiates the type of the old node, i.e. MME or SGSN, as specified in clause 4.3.19, uses the
GUTI received from the UE to derive the old MME/S4 SGSN address and sends a Context Request (old GUTI,
MME Address, UE Validated, complete TAU Request message, P-TMSI Signature, CIoT EPS Optimisation
support inidication) message to the old MME/S4 SGSN to retrieve the user information. UE Validated indicates
that the new MME has validated the integrity protection of the TAU message, e.g. based on native EPS security
context for the UE. To validate the Context Request the old MME uses the complete TAU Request message and
the old S4 SGSN uses the P-TMSI Signature and responds with an appropriate error if integrity check fails in old
MME/S4 SGSN. This shall initiate the security functions in the new MME. If the security functions authenticate
the UE correctly, the new MME shall send a Context Request (IMSI, complete TAU Request message, MME
Address, UE Validated) message to the old MME/S4 SGSN with the UE Validated set. If the new MME
indicates that it has authenticated the UE or if the old MME/old S4 SGSN authenticates the UE, the old
MME/old S4 SGSN starts a timer.
If the UE with emergency bearers is not authenticated in the old MME/old S4 SGSN (in a network supporting
unauthenticated UEs) the old MME/old S4 SGSN continues the procedure with sending a Context Response and
starting the timer also when it cannot validate the Context Request.
If the new MME supports CIoT EPS Optimisation, CIoT EPS Optimisation support indication is included in the
Context Request indicating support for various CIoT EPS Optimisations (e.g. support for header compression for
CP CIoT EPS Optimisation, etc.).
5. If the Context Request is sent to an old MME the old MME responds with a Context Response (IMSI, ME
Identity (IMEISV), unused EPS Authentication Vectors, KSIASME, KASME, EPS Bearer Context(s), Serving GW
signalling Address and TEID(s), MS Info Change Reporting Action (if available), CSG Information Reporting
Action (if available), UE Time Zone, UE Core Network Capability, UE Specific DRX Parameters, Change to
Report (if present), Remaining Running Service Gap timer, LTE-M UE Indication) message. If the new MME
supports CIoT EPS Optimisation and the use of header compression has been negotiated between the UE and old
MME, the Context Response also includes the Header Compression Configuration which includes the
information necessary for the ROHC channel setup but not the RoHC context itself.
If the Context Request is sent to an old S4 SGSN the old S4 SGSN responds with a Context Response (IMSI,
ME Identity (if available), unused Authentication Quintets, CK, IK, KSISGSN, EPS Bearer Context(s), Serving
GW signalling Address and TEID(s), ISR Supported, MS Info Change Reporting Action (if available), CSG
Information Reporting Action (if available), UE Time Zone, UE Core Network Capability, UE Specific DRX
Parameters, Change to Report (if present)) message. The Authentication Quintets are maintained by the old S4
SGSN. TS 33.401 [41] gives further details on the transfer of security related information.
Change to Report flag is included by the old MME or the old S4 SGSN if reporting of change of UE Time Zone,
or Serving Network, or both towards Serving GW / PDN GW was deferred by the old MME or old S4 SGSN.
If the Context Response message did not include IMEISV and the MME does not already store the IMEISV of
the UE, the MME shall retrieve the ME Identity (IMEISV) from the UE.
3GPP
Release 15 155 3GPP TS 23.401 V15.10.0 (2019-12)
The PDN GW Address and TEID(s) (for GTP-based S5/S8) or GRE Keys (PMIP-based S5/S8 at the PDN
GW(s) for uplink traffic and the TI(s), is part of the EPS Bearer Context. ISR Supported is indicated if the old
SGSN and associated Serving GW are capable to activate ISR for the UE.
The new MME shall ignore the UE Core Network Capability contained in the Context Response only when it
has previously received an UE Core Network Capability in the Tracking Area Update Request. If the UE is not
known in the old MME/old S4 SGSN or if the integrity check for the TAU request message fails, the old
MME/old S4 SGSN responds with an appropriate error cause.
If the DL Data Buffer Expiration Time for the UE has not expired (see High latency communication in
clause 4.3.17.7), the old MME/old S4-SGSN indicates Buffered DL Data Waiting in the Context Response.
When this is indicated, the new MME shall setup the user plane in conjunction to the TAU procedure for
delivery of the buffered DL data.
If the UE receives emergency bearer services from the old MME/old S4 SGSN and the UE is UICCless, IMSI
can not be included in the Context Response. For emergency attached UEs, if the IMSI cannot be authenticated,
then the IMSI shall be marked as unauthenticated. Also, in this case, security parameters are included only if
available.
MME/old S4 SGSN shall include the Local Home Network ID of the old cell in the EPS Bearer context
Based on the CIoT EPS Optimisation support indication, old MME only transfers the EPS Bearer Context(s) that
the new MME supports. If the new MME does not support CIoT EPS Optimisation, EPS Bearer Context(s) of
non-IP PDN connection are not transferred to the new MME. If the EPS Bearer Context(s) of a PDN connection
has not been transferred, the old MME shall consider all bearers of that PDN connection as failed and release
that PDN connection by triggering the MME requested PDN disconnection procedure specified in clause 5.10.3.
The buffered data in the old MME is discarded after receipt of Context Acknowledgement.
If the EPS Bearer Context(s) are to be transferred to the new MME, the old MME also includes the Serving GW
IP address and TEID for both S1-U and S11-U, if available.
6. If the integrity check of TAU Request message (sent in step 2) failed, then authentication is mandatory. The
authentication functions are defined in clause 5.3.10 on "Security Function". Ciphering procedures are described
in clause 5.3.10 on "Security Function". If GUTI allocation is going to be done and the network supports
ciphering, the NAS messages shall be ciphered.
If this TAU request is received for a UE which is already in ECM_CONNECTED state and the PLMN-ID of the
TAI sent by the eNodeB in Step 3 is different from that of the GUTI included in the TAU Request message, the
MME shall delay authenticating the UE until after Step 21 (TAU Complete message).
NOTE 4: The MME delays the authentication such that the UE first updates its registered PLMN-ID to the new
PLMN-ID selected by the RAN during handover. The new PLMN-ID is provided by the MME to the UE
as part of the GUTI in the TAU accept message in Step 20. Doing this ensures that the same PLMN-ID is
used in the derivation of the Kasme key by both the network and the UE.
If the new MME is configured to allow emergency bearer services for unauthenticated UE the new MME behave
as follows:
- where a UE has only emergency bearer services, the MME either skip the authentication and security
procedure or accepts that the authentication may fail and continues the Tracking Area Update procedure; or
- where a UE has both emergency and non emergency bearer services and authentication fails, the MME
continues the Tracking Area Update procedure and deactivates all the non-emergency PDN connections as
7. If the old node is an old MME the new MME sends a Context Acknowledge message to the old MME. The old
MME marks in its context that the information in the GW and the HSS are invalid. This ensures that the MME
3GPP
Release 15 156 3GPP TS 23.401 V15.10.0 (2019-12)
updates the GWs and the HSS if the UE initiates a TAU procedure back to the MME before completing the
ongoing TAU procedure.
NOTE 5: Updating the GWs refers to modification of session(s) on the Serving GW. This will result in successful
re-establishment of the S11/S4 tunnel between the MME/SGSN and the Serving GW.
If the old node is an old S4 SGSN the MME sends a Context Acknowledge (ISR Activated) message to the old
SGSN. Unless ISR Activated is indicated by the MME, the old S4 SGSN marks in its context that the
information in the GWs is invalid. This ensures that the old S4 SGSN updates the GWs if the UE initiates a RAU
procedure back to the old S4 SGSN before completing the ongoing TAU procedure. If ISR Activated is indicated
to the old S4 SGSN, this indicates that the old S4 SGSN shall maintain its UE context including authentication
quintets and stop the timer started in step 4. In this case, if the Implicit Detach timer is running, the old S4 SGSN
shall re-start it with a slightly larger value than the UE's GERAN/UTRAN Deactivate ISR timer. Also, in this
case, if the old SGSN has maintained the Serving GW address for user plane and S4 GTP-U TEID, the old
SGSN shall remove Serving GW address for user plane and S4 GTP-U TEID locally. When ISR Activated is not
indicated and this timer expires the old SGSN deletes all bearer resources of that UE. As the Context
Acknowledge from the MME does not include any S-GW change the S4 SGSN does not send any Delete
Session Request message to the S-GW. The MME shall not activate ISR if the associated Serving GW does not
support ISR.
If the security functions do not authenticate the UE correctly, then the TAU shall be rejected, and the MME shall
send a reject indication to the old MME/old S4 SGSN. The old MME/old S4 SGSN shall continue as if the
Identification and Context Request was never received.
For UE using CIoT EPS Optimisation without any activated PDN connection, the steps 9, 10, 11, 12 and 13 are
skipped.
8. Void.
9. If the MME has changed the new MME adopts the bearer contexts received from the old MME/SGSN as the
UE's EPS bearer contexts to be maintained by the new MME. The MME establishes the EPS bearer(s) in the
indicated order. The MME deactivates the EPS bearers which cannot be established.
The MME verifies the EPS bearer status received from the UE with the EPS bearer contexts it maintains and
releases any network resources related to EPS bearers that are not active in the UE. If there is no bearer context
at all, the MME rejects the TAU Request. If the MME has changed the new MME sends a Modify Bearer
Request (new MME address and TEID, ISR Activated, RAT type, LTE-M RAT type reporting to PGW flag)
message per PDN connection to the Serving GW. If there is no need for the SGW to send the signalling to the
PDN GW, the MME may send Modify Access Bearers Request (new MME address and TEID) per UE to the
Serving GW to optimise the signalling. The PDN GW address is indicated in the bearer contexts. If indicated, the
information ISR Activated indicates that ISR is activated. If it is a mobility from a SGSN to a MME and if the
MME supports location information change reporting, the MME shall include the User Location Information
(according to the supported granularity) in the Modify Bearer Request, regardless of whether location
information change reporting had been requested in the previous RAT by the PDN GW. If it is an inter MME
mobility and if the PDN GW requested location information change reporting, the MME includes the User
Location Information IE in this message if it is different compared to the previously sent information. If the PDN
GW requested User CSG information, the MME also includes the User CSG Information IE in this message. If
either the UE Time Zone has changed or Context Response message indicated pending UE Time Zone change
reporting (via Change to Report flag), the MME includes the UE Time Zone IE in this message. If either the
Serving Network has changed or Context Response message indicated pending Serving Network change
reporting (via Change to Report flag) the MME includes the new Serving Network IE in this message. In
network sharing scenarios Serving Network denotes the serving core network. If the old node is an old MME at a
Tracking Area Update with a MME change ISR Activated shall not be indicated.
NOTE 6: The User CSG Information IE is only sent in step 9 if the "Active flag" is set in the TAU Request
message.
When the Modify Access Bearers Request or Modify Bearer Request does not indicate ISR Activated the S-GW
deletes any ISR resources by sending a Delete Bearer Request to the other CN node that has bearer resources on
the S-GW reserved.
If the new MME receives the EPS bearer context with SCEF, then the new MME updates the SCEF as defined in
TS 23.682 [74].
3GPP
Release 15 157 3GPP TS 23.401 V15.10.0 (2019-12)
For Control Plane CIoT EPS Optimisation, if the DL data is buffered in the Serving GW, and if this is a Tracking
Area Update without MME change and the DL Data Buffer Expiration Time in the MM context for the UE in
the MME has not expired, or if this is a Tracking Area Update with MME change and the old MME/old S4-
SGSN indicated Buffered DL Data Waiting in the Context Response in step 5, the MME shall also indicate S11-
U tunnelling of NAS user data and include it's own S11-U IP address and MME DL TEID for DL data
forwarding by the SGW in the Modify Bearer Request. The MME may also do so without DL data buffered in
the SGW.
10. If the RAT type has changed, or the Serving GW has received the User Location Information IE or the UE Time
Zone IE or User CSG Information IE and/or the Serving Network IE from the MME in step 9, the Serving GW
informs the PDN GW(s) about this information that e.g. can be used for charging, by sending the message
Modify Bearer Request (RAT type) per PDN connection to the PDN GW(s) concerned. User Location
Information IE and/or UE Time Zone IE and/or User CSG Information IE and/or Serving Network IE are also
included if they are present in step 9.
If the Modify Bearer Request message is not sent because of above reasons and the PDN GW charging is
paused, then the SGW shall send Modify Bearer Request message with PDN Charging Pause Stop Indication to
inform the PDN GW that the charging is no longer paused. Other IEs are not included in this message.
11. If dynamic PCC is deployed, and RAT type information or UE location information needs to be conveyed from
the PDN GW to the PCRF, then the PDN GW shall send this information to the PCRF by means of an IP-CAN
Session Modification procedure as defined in TS 23.203 [6].
12. The PDN GW updates its context field to allow DL PDUs to be routed to the correct Serving GW. PDN GW
returns a Modify Bearer Response (MSISDN) to the Serving GW. The MSISDN is included if the PDN GW has
it stored in its UE context. If there has been a RAT change towards E-UTRAN and location information change
reporting is required and supported in the target MME, the PDN GW shall provide MS Info Change Reporting
Action in the Modify Bearer Response.
13. The Serving GW updates its bearer context. If ISR Activated is indicated in step 9 and RAT Type received in
step 9 indicates E-UTRAN, then the Serving GW only updates the MME Control Plane Address stored locally
and keep the SGSN related information unchanged. Also, in this case, if the Serving GW has maintained the
SGSN address for user plane and S4 GTP-U TEID, the Serving GW removes the SGSN address for user plane
and S4 GTP-U TEID locally. Otherwise the Serving GW shall update all of the information stored locally for
this UE with the related information received from the MME. This allows the Serving GW to route Bearer PDUs
to the PDN GW when received from eNodeB. The Serving GW shall return a Modify Bearer Response (Serving
GW address and TEID for uplink traffic, MS Info Change Reporting Action) message to the new MME as a
response to a Modify Bearer Request message, or a Modify Access Bearers Response (Serving GW address and
TEID for uplink traffic) as a response to a Modify Access Bearers Request message. If the Serving GW cannot
serve the MME Request in the Modify Access Bearers Request message without S5/S8 signalling other than to
unpause charging in the PDN GW or without corresponding Gxc signalling when PMIP is used over the S5/S8
interface, it shall respond to the MME with indicating that the modifications are not limited to S1-U bearers, and
the MME shall repeat its request using Modify Bearer Request message per PDN connection.
When the MME receives the Modify Bearer Response or the Modify Access Bearers Response message, the
MME checks if there is a "Availability after DDN Failure" monitoring event or a "UE Reachability" monitoring
event configured for the UE in the MME and in such a case sends an event notification (see TS 23.682 [74] for
further information).
For Control Plane CIoT EPS Optimisation, if the MME address and MME DL TEID are provided in step 9, the
Serving GW includes Serving GW address and Serving GW UL TEID in the Modify Bearer Response message.
The DL data is sent to the MME from the Serving GW.
3GPP
Release 15 158 3GPP TS 23.401 V15.10.0 (2019-12)
The buffered DL data is sent to the UE as described in steps 12-14 of clause 5.3.4B.3.
14. The new MME verifies whether it holds subscription data for the UE identified by the GUTI, the additional
GUTI or by the IMSI received with the context data from the old CN node.
If there are no subscription data in the new MME for this UE, or for some network sharing scenario (e.g.
GWCN) if the PLMN-ID of the TAI supplied by the eNodeB is different from that of the GUTI in the UE's
context, then the new MME informs the HSS of the change of MME by sending an Update Location Request
(MME Id, IMSI, ULR-Flags, MME Capabilities, Homogenous Support of IMS Voice over PS Sessions, UE
SRVCC capability, equivalent PLMN list, ME Identity (IMEISV)) message to the HSS. ULR-Flags indicates
that update location is sent from an MME and the MME registration shall be updated in HSS. The HSS does not
cancel any SGSN registration. The MME capabilities indicate the MME's support for regional access restrictions
functionality. The inclusion of the equivalent PLMN list indicates that the MME supports the inter-PLMN
handover to a CSG cell in an equivalent PLMN using the subscription information of the target PLMN. The
"Homogenous Support of IMS Voice over PS Sessions" indication (see clause 4.3.5.8A) shall not be included
unless the MME has completed its evaluation of the support of "IMS Voice over PS Session" as specified in
clause 4.3.5.8. The ME Identity is included if step 5 caused the MME to retrieve the IMEISV from the UE.
NOTE 8: At this step, the MME may not have all the information needed to determine the setting of the IMS voice
If the UE initiates the TAU procedure in a VPLMN supporting Autonomous CSG Roaming and the HPLMN has
enabled Autonomous CSG Roaming in the VPLMN (via Service Level Agreement) and the MME needs to
retrieve the CSG subscription information of the UE from the CSS, the MME initiates the Update CSG Location
If all the EPS bearers of the UE have emergency ARP value, the new MME may skip the update location
procedure or proceed even if the update location fails.
15. The HSS sends a Cancel Location (IMSI, Cancellation type) message to the old MME with a Cancellation Type
set to Update Procedure.
16. When receiving a Cancel Location message and the timer started in step 4 is not running, the old MME removes
the MM and bearer contexts. Otherwise, the contexts are removed when the timer expires. It also ensures that the
MM context is kept in the old MME for the case the UE initiates another TAU procedure before completing the
ongoing TAU procedure to the new MME. The old MME acknowledges with a Cancel Location Ack (IMSI)
message.
NOTE 9: ISR Activated is never indicated from new to old MME.
So an old MME deletes all the bearer resources of the UE in any case when the timer started in step 4 expires,
which is independent on receiving a Cancel Location message.
17. When receiving the Context Acknowledge message and if the UE is Iu Connected, the old SGSN sends an Iu
Release Command message to the RNC after the timer started in step 4 has expired.
18. The RNC responds with an Iu Release Complete message.
19. The HSS acknowledges the Update Location Request by returning an Update Location Ack (IMSI, Subscription
Data) message to the new MME after the cancelling of the old MME context is finished. If all checks are
successful, the MME constructs an MM context for the UE. The Subscription Data may contain the CSG
subscription data for the registered PLMN and for the equivalent PLMN list requested by MME in step 14.
The subscription data may contain Service Gap Time. If received from the HSS, the MME stores this Service
Gap Time in the MME MM context for the UE and passes it to the UE in the Tracking Area Update Accept
message if the UE has indicated Service Gap Control capability.
3GPP
Release 15 159 3GPP TS 23.401 V15.10.0 (2019-12)
If the UE initiates the TAU procedure at a CSG cell, the new MME shall check whether the CSG ID and
is not present or expired, the MME shall send a Tracking Area Update reject message to the UE with an
appropriate cause value. The UE shall remove the CSG ID and associated PLMN from its Allowed CSG list if
present.
If the Update Location is rejected by the HSS, the new MME rejects the TAU Request from the UE with an
appropriate cause sent in the TAU Reject message to the UE. In such cases, the new MME releases any local
MME EPS Bearer contexts for this particular UE.
access the TA:
- The MME rejects the Tracking Area Update Request with an appropriate cause to the UE.
- For UEs with emergency EPS bearers, i.e. at least one EPS bearer has an ARP value reserved for emergency
services, the new MME accepts the Tracking Area Update Request and deactivates all non-emergency PDN
connections as specified in clause 5.10.3. If the Tracking Area Update procedure is initiated in ECM-IDLE
state, all non-emergency EPS bearers are deactivated by the Tracking Area Update procedure without bearer
deactivation signalling between the UE and the MME.
The MME responds to the UE with a Tracking Area Update Accept (GUTI, TAI-list, EPS bearer status, NAS
sequence number, NAS-MAC, ISR Activated, IMS Voice over PS session supported, Emergency Service
Support indicator, LCS Support Indication, Supported Network Behaviour, Service Gap Time, Enhanced
Coverage Restricted, Indication of support of 15 EPS bearers per UE) message. If the active flag is set the
Handover Restriction List may be sent to eNodeB as eNodeB handles the roaming restrictions and access
restrictions in the Intra E-UTRAN case. If the active flag is set in the TAU Request message the user plane setup
procedure is activated in conjunction with the TAU Accept message. If this is a Tracking Area Update without
MME change and the DL Data Buffer Expiration Time in the MM context for the UE in the MME has not
expired, or if this is a Tracking Area Update with MME change and the old MME/old S4-SGSN indicated
Buffered DL Data Waiting in the Context Response in step 5, the user plane setup procedure is activated even if
the MME did not receive the active flag in the TAU Request message. If the new MME receives the Downlink
Data Notification message or any downlink signalling message while the UE is still connected, the user plane
setup procedure may be activated even if the new MME did not receive the active flag in the TAU Request
message. The procedure is described in detail in TS 36.300 [5]. The message sequence should be the same as for
the UE triggered Service Request procedure specified in clause 5.3.4.1 from the step when MME establish the
bearers(s). The EPS bearer status indicates the active bearers in the network. The UE removes any internal
resources related to bearers not marked active in the received EPS bearer status. If the EPS bearer status
information was in the TAU Request, the MME shall indicate the EPS bearer status to the UE. If ISR Activated
is indicated to the UE, this indicates that its P-TMSI and RAI shall remain registered with the network and shall
remain valid in the UE. At a Tracking Area Update with an MME change ISR Activated shall not be indicated.
At a Tracking Area Update without an MME change, if ISR is activated for the UE when the MME receives the
Tracking Area Update Request, the MME should maintain ISR by indicating ISR Activated in the Tracking Area
Update Accept message. Handover Restriction List is described in clause 4.3.5.7 "Mobility Restrictions". The
MME sets the IMS Voice over PS session supported as described in clause 4.3.5.8.
The MME indicates the CIoT EPS Optimisations it supports and prefers in the Supported Network Behaviour
If there is a Service Gap timer running for the UE in the MME, the MME shall ignore the active flag and
signalling active flag and not perform any of the actions related to these flags.
The MME shall include the Service Gap Time in the TAU Accept message if the UE has indicated Service Gap
Control capability and either if Service Gap Time was received in step 19 from HSS in the subscription
information or if the Service Gap Time in the subscription information has been updated by HSS User Profile
management (i.e. the Insert Subscriber Data procedure in clause 5.3.9.2).
3GPP
Release 15 160 3GPP TS 23.401 V15.10.0 (2019-12)
Coverage Restricted parameter to the eNB in the S1-AP message as defined in clause 4.3.28. The MME also
sends the Enhanced Coverage Restricted parameter to the UE in the TAU Accept message. UE shall store
Enhanced Coverage Restricted parameter and shall use the value of Enhanced Coverage Restricted parameter to
determine if enhanced coverage feature should be used or not.
If the MME successfully obtained Header Compression Configuration parameters in step 5 it indicates he
continued use of previous negotiated configuration to the UE in the Header Compression Context Status for each
EPS Bearer of the UE. When Header Compression Context Status indicates that the previous negotiated
configuration can no longer be used for some EPS bearers, the UE shall stop performing header compression and
decompression when sending or receiving data using Control Plane CIoT EPS Optimisation on these EPS
bearers.
The MME checks if there is a "Availability after DDN Failure" monitoring event or a "UE Reachability"
monitoring event configured for the UE in the MME for which an event notification has not yet been sent. In
such a case an event notification is sent (see TS 23.682 [74] for further information).
If the MME did not receive the Voice support match indicator in the MM Context, then the MME may send a
UE Radio Capability Match Request to the eNB as described in clause 5.3.14. If the MME hasn't received Voice
support match indicator from the eNB then based on implementation MME may set IMS Voice over PS session
supported Indication and update it at a later stage. After step 14, and in parallel to any of the preceding steps, the
MME shall send a Notify Request (Homogeneous Support of IMS Voice over PS Sessions) message to the HSS:
The Emergency Service Support indicator informs the UE that Emergency bearer services are supported. LCS
Support Indication indicates whether the network supports the EPC-MO-LR and/or CS-MO-LR as described in
TS 23.271 [57]. Indication for support of 15 EPS bearers per UE indicates the network supports 15 EPS bearers
as defined in clause 4.12.
"GUTI". When ISR Activated is indicated and the UE's TIN indicates "GUTI" the UE's TIN shall not be
changed. When ISR Activated is indicated and the TIN is "P-TMSI" or "RAT-related TMSI" the UE shall set its
TIN to "RAT-related TMSI".
For an MME change ISR is not activated by the new MME to avoid context transfer procedures with two old CN
nodes.
For an emergency attached UE, emergency ISR is not activated.
If the TAU procedure is initiated by manual CSG selection and occurs via a CSG cell, the UE upon receiving
TAU Accept message shall add the CSG ID and associated PLMN to its Allowed CSG list if it is not already
mode DRX parameters information element in the TAU accept if it decides to enable extended idle mode DRX
with Paging Time Window length assigned considering Subscribed Paging Time Window (if available) and the
local policy.
If the user plane setup is performed in conjunction with the TAU Accept message and the TAU is performed via
a hybrid cell, then the MME shall send an indication whether the UE is a CSG member to the RAN along with
the S1-MME control message. Based on this information the RAN may perform differentiated treatment for
CSG and non-CSG members.
NOTE 10:If the UE receives a TAU Accept message via a hybrid cell, the UE does not add the corresponding CSG
If the UE receives a Service Gap Time in the TAU Accept message, the UE shall store this parameter and apply
Service Gap Control (see clause 4.3.17.9).
3GPP
Release 15 161 3GPP TS 23.401 V15.10.0 (2019-12)
21. If the GUTI was changed the UE acknowledges the new GUTI by returning a Tracking Area Update Complete
message to the MME.
in ECM-CONNECTED state, the MME releases the signalling connection with UE, according to clause 5.3.5.
For a UE using Control Plane CIoT EPS Optimisation, when the "Signalling active flag" is set, the new MME
shall not release the NAS signalling connection with the UE immediately after the TAU procedure is completed.
NOTE 11:The new MME may initiate E-RAB establishment (see TS 36.413 [36]) after execution of the security
functions, or wait until completion of the TA update procedure. For the UE, E-RAB establishment may
occur anytime after the TA update request is sent.
In the case of a rejected tracking area update operation, due to regional subscription, roaming restrictions, or access
restrictions (see TS 23.221 [27] and TS 23.008 [28]) the new MME should not construct an MM context for the UE. In
the case of receiving the subscriber data from HSS, the new MME may construct an MM context and store the
subscriber data for the UE to optimise signalling between the MME and the HSS. A reject shall be returned to the UE
with an appropriate cause and the S1 connection shall be released. Upon return to idle, the UE shall act according to
TS 23.122 [10].
If the new MME is unable to update the bearer context in one or more P-GWs, the new MME shall deactivate the
corresponding bearer contexts as described in clause "MME Initiated Dedicated Bearer Deactivation Procedure". This
shall not cause the MME to reject the tracking area update.
The bearer contexts shall be prioritized by the new MME. If the new MME is unable to support the same number of
active bearer contexts as received from old MME/SGSN, the prioritisation is used to decide which bearer contexts to
maintain active and which ones to delete. In any case, the new MME shall first update all contexts in one or more
P-GWs and then deactivate the context(s) that it cannot maintain as described in clause "MME Initiated Dedicated
Bearer Deactivation Procedure". This shall not cause the MME to reject the tracking area update.
The new MME shall not deactivate emergency service related EPS bearers, i.e. EPS bearers with ARP value reserved
for emergency services.
NOTE 12:If MS (UE) was in PMM-CONNECTED state the bearer contexts are sent already in the Forward
Relocation Request message as described in clause "Serving RNS relocation procedures" of
TS 23.060 [7].
If the new MME identifies that the RAT type has changed, the MME checks the subscription information to identify for
each APN whether to maintain the PDN connection, disconnect the PDN connection with a reactivation request, or,
disconnect the PDN connection without reactivation request. If the MME decides to deactivate a PDN connection it
performs MME-initiated PDN Connection Deactivation procedure after the tracking area update procedure is completed
but before the S1/RRC interface connection is released. Existing ESM cause values as specified in TS 24.301 [46] (e.g.
#39, "reactivation requested"; #66 "Requested APN not supported in current RAT and PLMN combination"; and for a
dedicated bearer, possibly #37 "EPS QoS not accepted") are used to cause predictable UE behaviour. If all the PDN
connections are disconnected and the UE does not support "attach without PDN connectivity", the MME shall request
the UE to detach and reattach.
5.3.3.3 Routing Area Update with MME interaction and without S-GW change
The Routing Area Update without S-GW change procedure takes place when a UE that is registered with an MME
selects a UTRAN or GERAN cell and the S-GW is not changed by the procedure. In this case, the UE changes to a
Routing Area that the UE has not yet registered with the network. This procedure is initiated by an ECM-IDLE state UE
and may also be initiated if the UE is in ECM-CONNECTED state. The RA update case is illustrated in Figure 5.3.3.3-
1.
NOTE 1: This procedure covers the MME to 2G or 3G SGSN RAU.
3GPP
Release 15 162 3GPP TS 23.401 V15.10.0 (2019-12)
RNC/ Serving Old

MME PDN
UE eNodeB BSS SGSN GW PCRF HSS
SGSN GW
1. UE Changes to
UTRAN or GERAN
2a. Routeing Area Update Request

2b. Routeing Area Update Request
3. Context Request
4. Context Response
5. Authentication



12. Update Location
13. Cancel Location
14. S1-AP: S1 Release Command
Release E-UTRAN
connection
14. S1-AP: S1 Release Complete
18. Routeing Area Update Accept

19. Routeing Area Update Complete
20. Service Request
21. RAB Assignment Request

21b. RAB Assignment Response
Figure 5.3.3.3-1: Routing Area Update with MME interaction and without S-GW change
1. The UE selects a UTRAN or GERAN cell. This cell is in a Routing Area that the UE not yet registered with the
network, or the UE reselects a UTRAN or GERAN cell and the TIN indicates "GUTI". The UE in
ECM-CONNECTED state may change to the GERAN cell through Network Assisted Cell Change (NACC).
3GPP
Release 15 163 3GPP TS 23.401 V15.10.0 (2019-12)
2a. The UE sends a Routing Area Update Request (old P-TMSI, P-TMSI Type, old RAI, UE Core Network
Capability, MS Network Capability, P-TMSI Signature, additional P-TMSI/RAI, KSI, Voice domain preference
and UE's usage setting) message to the new SGSN. The UE shall set the P-TMSI Type to indicate whether the P-
TMSI is a native P-TMSI or is mapped from a GUTI.
If the UE's internal TIN indicates "GUTI" and the UE holds a valid GUTI then the UE indicates the GUTI as the
old P-TMSI and old RAI. If the UE's TIN indicates "P-TMSI" or "RAT-related TMSI" and the UE holds a valid
P-TMSI and related RAI then these two elements are indicated as old P-TMSI and old RAI. Mapping a GUTI to
a P-TMSI and an RAI is specified in TS 23.003 [9].
If the UE holds a valid P-TMSI and related RAI and the old P-TMSI and old RAI indicate a P-TMSI/RAI
mapped from a GUTI, then the UE indicates these parameters as additional P-TMSI/RAI.
The old P-TMSI is indicated in the RAU Request message for Iu-mode only. For Gb mode the TLLI is derived
from the value that is determined as the old P-TMSI according to the rules above. The routing parameter that is
signalled in the RRC signalling to the RNC for routing to the SGSN is derived from the identifier that is
signalled as the old P-TMSI according to the rules above. For a combined MME/SGSN the RAN is configured to
route the NRI(s) of this combined node to the same combined node. The RAN is also configured to route NRI(s)
of P-TMSIs that are generated by the UE's mapping of the GUTIs allocated by the combined node. Such a RAN
mobility.
If the UE has a follow-on request, i.e. if there is pending uplink traffic (signalling or data), the 3G SGSN may
use, as an implementation option, the follow-on request indication to release or keep the Iu connection after the
completion of the RA update procedure.
KSI is mapped from an eKSI identifying a KASME if the UE indicates a P-TMSI mapped from GUTI in the
information element "old P-TMSI". KSI identifies a (CK, IK) pair if the UE indicates a P-TMSI in the
information element "old P-TMSI".
clause 4.3.5.9.
2b. The RNC shall add the Routing Area Identity, CSG access mode, CSG ID before forwarding the message to the
SGSN. This RA identity corresponds to the RAI in the MM system information sent by the RNC to the UE. The
BSS shall add the Cell Global Identity (CGI) of the cell where the UE is located before passing the message to
the new SGSN. CSG ID is provided by RAN if the UE sends the RAU Request message via a CSG cell or a
hybrid cell. CSG access mode is provided if the UE sends the RAU Request message via a hybrid cell. If the
CSG access mode is not provided but the CSG ID is provided, the SGSN shall consider the cell as a CSG cell.
For SIPTO at the Local Network the with stand-alone GW architecture the RNC includes the Local Home
Network ID in the Initial UE Message and in Direct Transfer message if the target cell is in a Local Home
Network.
3. The new S4 SGSN determines the type of the old node, i.e. MME or SGSN, as specified in clause 4.3.19, uses
the old RAI received from the UE to derive the old MME address, and sends a Context Request (P-TMSI, old
RAI, New SGSN Address, P-TMSI Signature) message to the old MME to get the context for the UE. To
validate the Context Request the old MME uses a NAS token mapped from the P-TMSI Signature. If the UE is
not known in the old MME, the old MME responds with an appropriate error cause. If integrity check fails in the
old MME, the old MME responds with an appropriate error cause which shall initiate the security functions in
the new S4 SGSN. If the security functions authenticate the UE correctly, the new S4 SGSN shall send a Context
Request (IMSI, old RAI, New SGSN Address, UE Validated) message to the old MME.UE Validated indicates
that the new S4 SGSN has authenticated the UE. If the new S4 SGSN indicates that it has authenticated the UE
or if the old MME authenticates the UE, the old MME starts a timer.
If the UE with emergency bearers is not authenticated in the old MME (in a network supporting unauthenticated
UEs) the old MME continues the procedure with sending a Context Response and starting the timer also when it
cannot validate the Context Request.
4. The old MME responds with one Context Response (IMSI, ME Identity (if available), KSI, CK, IK, unused
Authentication Quintets, EPS Bearer Contexts, Serving GW signalling Address and TEID(s), ISR Supported,
MS Info Change Reporting Action (if available), CSG Information Reporting Action (if available), UE Time
Zone, UE Core Network Capability, UE Specific DRX Parameters, Change to Report (if present)) message. The
PDN GW Address and TEID(s) (for GTP-based S5/S8) or GRE Keys (PMIP-based S5/S8) for uplink traffic and
control plane, and the TI(s) is part of the EPS Bearer context(s). The unused Authentication Quintets in the MM
3GPP
Release 15 164 3GPP TS 23.401 V15.10.0 (2019-12)
Context may be sent if stored by the MME and the MME received the unused Authentication Quintets from the
same SGSN previously. ISR Supported is indicated if the old MME and associated Serving GW are capable to
activate ISR for the UE.
If the UE receives emergency bearer services from the old MME and the UE is UICCless, IMSI can not be
included in the Context Response. For emergency attached UEs, if the IMSI cannot be authenticated, then the
IMSI shall be marked as unauthenticated. Also, in this case, security parameters are included only if available.
The new S4 SGSN shall ignore the UE Core Network Capability contained in the Context Response only when it
has previously received an UE Core Network Capability in the Routing Area Update Request. If UE is not
known in the old MME, the old MME responds with an appropriate error cause.
Change to Report flag is included by the old MME if reporting of change of UE Time Zone, or Serving Network,
or both towards Serving GW / PDN GW was deferred by the old MME.
The new SGSN maps the EPS bearers to PDP contexts 1-to-1 and maps the EPS Bearer QoS parameter values of
an EPS bearer to the Release 99 QoS parameter values of a PDP context as defined in Annex E. The PDP
context(s) are established in the indicated order. The SGSN deactivates the PDP contexts which cannot be
established.
MME shall include the Local Home Network ID of the old cell in the EPS Bearer context corresponding to the
SIPTO at the Local Network PDN connection.
The old MME only transfers the EPS Bearer Context(s) that the new SGSN supports. If not supported, EPS
Bearer Context(s) of non-IP PDN connection are not transferred to the new SGSN. If the EPS Bearer Context(s)
of a PDN connection has not been transferred, the old MME shall consider all bearers of that PDN connection as
failed and release that PDN connection by triggering the MME requested PDN disconnection procedure
5. Security functions may be executed. Procedures are defined in clause 5.3.10 on "Security Function".
If the new SGSN is configured to allow emergency bearer services for unauthenticated UE the new SGSN
behave as follows:
- where a UE has only emergency bearer services, the SGSN either skip the authentication and security
procedure or accepts that the authentication may fail and continues the Routing Area Update procedure; or
- where a UE has both emergency and non emergency bearer services and authentication fails, the SGSN
continues the Routing Area Update procedure and deactivates all the non-emergency PDP contexts as
specified in TS 23.060 [7].
6. The new S4 SGSN sends a Context Acknowledge (ISR Activated) message to the old MME. Unless ISR is
indicated by the new S4 SGSN, the old MME marks in its context that the information in the GWs is invalid.
This ensures that the old MME updates the GW if the UE initiates a TAU procedure back to the old MME before
completing the ongoing RAU procedure.
NOTE 3: Updating the GWs refers to modification of session(s) on the Serving GW. This will result in successful
re-establishment of the S11/S4 tunnel between the MME/SGSN and the Serving GW.
ISR Activated indicates to the old MME that it shall maintain the UE's contexts and the MME stops the timer
started in step 3. In this case, if the Implicit Detach timer is running, the old MME shall re-start it with a slightly
larger value than the UE's E-UTRAN Deactivate ISR timer. When ISR Activated is not indicated and this timer
expires the old MME deletes all bearer resources of that UE. As the Context Acknowledge from the new
S4 SGSN does not include any S-GW change the old MME does not send any Delete Session Request message
to the S-GW. The SGSN shall not activate ISR if the associated Serving GW does not support ISR.
If the security functions do not authenticate the UE correctly, then the RAU is rejected, and the new S4 SGSN
sends a reject indication to the old MME. The old MME shall continue as if the Identification and Context
Request was never received.
3GPP
Release 15 165 3GPP TS 23.401 V15.10.0 (2019-12)
For UE using CIoT EPS Optimisation without any activated PDN connection, the steps 7, 8, 9, 10, and 11 are
skipped.
If the new SGSN identifies that the RAT type has changed, the SGSN checks the subscription information to
identify for each APN whether to maintain the PDN connection, disconnect the PDN connection with a
reactivation request or disconnect PDN connection without reactivation request. If the SGSN decides to deactive
a PDN connection it performs SGSN-initiated PDN Connection Deactivation procedure after tracking area
procedure is completed. Existing SM cause values as specified in TS 24.008 [47] (e.g. #39, "reactivation
requested"; #66 "Requested APN not supported in current RAT and PLMN combination"; and for a dedicated
bearer, possibly #37 "QoS not accepted") are used to cause predictable UE behaviour.
7. In this procedure flow the Serving GW is not relocated. The SGSN sends a Modify Bearer Request (new SGSN
Address and TEID, RAT type, ISR Activated) message per PDN connection to the Serving GW. If indicated, the
information ISR Activated indicates that ISR is activated. As it is a mobility from E-UTRAN, if the target SGSN
supports location information change reporting, the target SGSN shall include the User Location Information
(according to the supported granularity) in the Modify Bearer Request, regardless of whether location
information change reporting had been requested in the previous RAT by the PDN GW. If the PDN GW
requested User CSG information, the SGSN also includes the User CSG information IE in this message. If either
the UE Time Zone has changed , or Context Response message from old MME indicated pending UE Time Zone
change reporting (via Change to Report flag), the SGSN includes the UE Time Zone IE in this message. If either
the Serving Network has changed, or Context Response message from old MME indicated pending Serving
Network change reporting (via Change to Report flag) the SGSN includes the new Serving Network IE in this
message. In network sharing scenarios Serving Network denotes the serving core network.
When the Modify Bearer Request does not indicate ISR Activated the S-GW deletes any ISR resources by
sending a Delete Bearer Request to the other CN node that has bearer resources on the S-GW reserved. RAT
type indicates a change in radio access.
If ISR Activated is indicated or SGSN and SGW are configured to release S4 U-Plane when EPS Bearer
Contexts associated with the released RABs are to be preserved, the SGSN does not send SGSN address and
TEID for U-Plane in Modify Bearer Request.
NOTE 4: The User CSG Information IE is not sent in step 7 if the "follow-on request indication" indicates releasing
the Iu connection after the completion of the RA update procedure.
8. If the RAT type has changed or the Serving GW has received the User Location Information IE and/or the UE
Time Zone IE and/or User CSG information IE and/or the Serving Network IE from the MME in step 7 the
Serving GW informs the PDN GW(s) about the change of this information that e.g. can be used for charging, by
sending the message Modify Bearer Request (RAT type) per PDN connection to the PDN GW(s) concerned.
User Location Information IE and/or UE Time Zone IE and/or User CSG information IE and/or Serving
Network IE are also included if they are present in step 7.
9. If dynamic PCC is deployed, and RAT type information or UE location information needs to be conveyed from
the PDN GW to the PCRF, then the PDN GW shall send this information to the PCRF by means of an IP-CAN
Session Modification procedure as defined in TS 23.203 [6].
10. The PDN GW updates its context field and returns a Modify Bearer Response (MSISDN) message to the Serving
GW. MSISDN is included if the PDN GW has it stored in its UE context. If location information change
reporting is required and supported in the target SGSN, the PDN GW shall provide MS Info Change Reporting
Action in the Modify Bearer Response.
11. The Serving GW updates its context fields. If ISR Activated is indicated in step 7 and RAT Type received in step
7 indicates UTRAN or GERAN, then the Serving GW only updates the SGSN Control Plane Address and keeps
the MME related information unchanged. Otherwise the Serving GW shall update all of the information stored
locally for this UE with the related information received from the SGSN. Then the Serving GW returns a Modify
Bearer Response (Serving GW address and TEID for uplink traffic, MS Info Change Reporting Action) message.
When the SGSN receives the Modify Bearer Response message, the SGSN checks if there is a "Availability after
DDN Failure" monitoring event or a "UE Reachability" monitoring event configured for the UE in the SGSN
and in such a case sends an event notification (see TS 23.682 [74] for further information).
3GPP
Release 15 166 3GPP TS 23.401 V15.10.0 (2019-12)
12. The new SGSN verifies whether it holds subscription data for the UE identified by the P-TMSI, the additional
PTMSI/RAI or by the IMSI received with the context data from the old CN node.
The additional P-TMSI/RAI allows the new SGSN to find any already existing UE context stored in the new
SGSN. If there are no subscription data in the new SGSN for this UE, or for some network sharing scenario (e.g.
GWCN) if the PLMN-ID of the RAI supplied by the RNC is different from that of the RAI in the UE's context,
then the new SGSN informs the HSS of the change of the SGSN by sending an Update Location (SGSN
Number, SGSN Address, IMSI, Homogenous Support of IMS Voice over PS Sessions, UE SRVCC capability,
equivalent PLMN list) message to the HSS. For "Homogenous Support of IMS Voice over PS Sessions", see
clause 5.3.8A of TS 23.060 [7]. The inclusion of the equivalent PLMN list indicates that the SGSN supports the
inter-PLMN handover to a CSG cell in an equivalent PLMN using the subscription information of the target
PLMN.
If the UE initiates the RAU procedure in a VPLMN supporting Autonomous CSG Roaming and the HPLMN has
enabled Autonomous CSG Roaming in the VPLMN (via Service Level Agreement) and the SGSN needs to
retrieve the CSG subscription information of the UE from the CSS, the SGSN initiates the Update CSG Location
13. The HSS sends a Cancel Location (IMSI, Cancellation Type) message to the old SGSN with the Cancellation
Type set to Update Procedure.
When receiving the Cancel Location message the old SGSN removes all the UE contexts. The old SGSN
acknowledges with a Cancel Location Ack (IMSI) message.
14. When receiving the Context Acknowledge message from the new SGSN and if the old MME has an S1-MME
association for the UE, the source MME sends a S1-U Release Command to the source eNodeB after the timer
started in step 3 has expired. The RRC connection is released by the source eNodeB. The source eNodeB
confirms the release of the RRC connection and of the S1-U connection by sending a S1-U Release Complete
message to the source MME.
Data) to the new SGSN. The Subscription Data may contain the CSG subscription data for the registered PLMN
and for the equivalent PLMN list requested by SGSN in step 12.
If the UE initiates the RAU procedure at a CSG cell, the new S4 SGSN shall check whether the CSG ID and
is not present or expired, the S4 SGSN shall send a RAU reject message to the UE with an appropriate cause
value. The UE shall remove the CSG ID and associated PLMN from its Allowed CSG list if present.
If the Update Location is rejected by the HSS, the new SGSN rejects the RAU Request from the UE with an
appropriate cause sent in the RAU Reject message to the UE. In such cases, the new SGSN releases any local
SGSN EPS Bearer contexts for this particular UE.
16. Void.
17. Void.
access the RA:
- For UEs with ongoing emergency bearer services, the new SGSN accept the Routing Area Update Request
and deactivates the non-emergency PDP contexts as specified in clause 9.2.4.2 in TS 23.060 [7]. .If the
Routing Area Update procedure is initiated in PMM-IDLE/STANDBY state, all non-emergency PDP
Contexts are deactivated by the Routing Area without PDP Context deactivation signalling between the UE
and the SGSN
- For all other cases, the new SGSN rejects Routing Area Update Request with an appropriate cause to the UE
and notifies the HSS of rejection (details of this notification is covered in stage 3).
The new SGSN responds to the UE with a Routing Area Update Accept (P-TMSI, P-TMSI signature, ISR
Activated, Emergency Service Support indicator, PDP context status) message to the UE. P-TMSI is included if
the SGSN allocates a new P-TMSI. The Emergency Service Support indicator informs the UE that Emergency
bearer services are supported over UTRAN.
3GPP
Release 15 167 3GPP TS 23.401 V15.10.0 (2019-12)
If ISR Activated is indicated to the UE, its GUTI and list of TAs shall remain registered with the network and
shall remain valid in the UE.
When receiving the RAU Accept message and there is no ISR Activated indication the UE shall set its TIN to
"P-TMSI". When ISR Activated is indicated and the UE's TIN indicates "P-TMSI" the TIN shall not be changed.
When ISR Activated is indicated and the UE's TIN indicates "GUTI" or "RAT-related TMSI" the UE shall set its
TIN to "RAT-related TMSI".
If an SGSN change ISR is not activated by the new SGSN to avoid context transfer procedures with two old CN
nodes.
If the RAU procedure is initiated by manual CSG selection and occurs via a CSG cell, the UE upon receiving the
RAU Accept shall add the CSG ID and associated PLMN to its Allowed CSG list if it is not already present.
Manual CSG selection is not supported if the UE has emergency bearers established.
In Iu mode, if after step 7 the new SGSN receives a Downlink Data Notification message or any other downlink
signalling message while the UE is still connected, the new SGSN may prolong the PS signalling connection
with the UE.
If there is DL data buffered for a UE using power saving functions (i.e. the DL Data Buffer Expiration Time in
the MM context for the UE in the SGSN has not expired), the user plane setup is performed in conjunction with
the RAU Accept message.
With the PDP context status information, the UE shall deactivate all those bearers contexts locally which are
active in the UE, but are indicated by the SGSN as being inactive.
If the user plane setup is performed in conjunction with the RAU Accept message and the RAU is performed via
a hybrid cell, then the SGSN shall send an indication whether the UE is a CSG member to the RAN along with
the RANAP message. Based on this information the RAN may perform differentiated treatment for CSG and
non-CSG members.
NOTE 6: If the UE receives a RAU Accept message via a hybrid cell, the UE does not add the corresponding CSG
19. If P-TMSI was included in the Routing Area Update Accept message, the UE acknowledges the new P-TMSI by
returning a Routing Area Update Complete message to the SGSN.
20. For Iu-mode, if the UE has uplink data or signalling pending it shall send a Service Request (P-TMSI, CKSN,
Service Type) message to the new SGSN. If a P-TMSI was allocated in step 18, that P-TMSI is the one included
in this message. Service Type specifies the requested service. Service Type shall indicate one of the following:
Data or Signalling.
21. If the UE has sent the Service Request, the new 3G SGSN requests the RNC to establish a radio access bearer by
sending a RAB Assignment Request (RAB ID(s), QoS Profile(s), GTP SNDs, GTP SNUs, PDCP SNUs)
message to the RNC. If Direct Tunnel is established the SGSN provides to the RNC the Serving GW's Address
for User Plane and TEID for uplink data.
22. If the SGSN established Direct Tunnel in step 21) it shall send Modify Bearer Request per PDN connection to
the Serving GW and include the RNC's Address for User Plane and downlink TEID for data. The Serving GW
updates the Address for User Plane and TEID for downlink data and return a Modify Bearer Response.
NOTE 7: EPS does not support any CAMEL procedures.
NOTE 8: The new SGSN may initiate RAB establishment after execution of the security functions (step 5), or wait
until completion of the RA update procedure. For the MS, RAB establishment may occur anytime after
the RA update request is sent (step 2).
In the case of a rejected routing area update operation, due to regional subscription, roaming restrictions or access
restrictions (see TS 23.221 [27] and TS 23.008 [28]) the new SGSN should not construct an MM context. In the case of
receiving the subscriber data from HSS, the new SGSN may construct an MM context and store the subscriber data for
the UE to optimise signalling between the SGSN and the HSS. A reject shall be returned to the UE with an appropriate
cause and the PS signalling connection shall be released. Upon return to idle, the UE shall act according to
TS 23.122 [10].
3GPP
Release 15 168 3GPP TS 23.401 V15.10.0 (2019-12)
If the network supports the MOCN configuration for network sharing, the SGSN may, if the UE is not a 'Network
Sharing Supporting MS', in this case decide to initiate redirection by sending a Reroute Command to the RNS, as
described in TS 23.251 [24] instead of rejecting the routing area update.
If the new SGSN is unable to update the bearer context in one or more P-GWs, the new SGSN shall deactivate the
corresponding bearer contexts as described in clause "SGSN-initiated PDP Context Deactivation Procedure" of
TS 23.060 [7]. This shall not cause the SGSN to reject the routing area update.
The new SGSN shall determine the Maximum APN restriction based on the received APN Restriction of each bearer
The PDP contexts shall be prioritized by the new SGSN. If the new SGSN is unable to support the same number of
active PDP contexts as received from the old MME, the prioritisation is used to decide which PDP contexts to maintain
active and which ones to delete. In any case, the new SGSN shall first update all PDP contexts in one or more P-GWs
and then deactivate the PDP context(s) that it cannot maintain as described in clause "SGSN-initiated PDP Context
Deactivation Procedure" of TS 23.060 [7]. This shall not cause the SGSN to reject the routing area update.
NOTE 9: If the UE was in PMM-CONNECTED state the bearer contexts are sent already in the Forward
TS 23.060 [7].
If the routing area update procedure fails a maximum allowable number of times, or if the SGSN returns a Routing Area
Update Reject (Cause) message, the UE shall enter PMM DETACHED state.
5.3.3.4 Void
5.3.3.5 Void
5.3.3.6 Routing Area Update with MME interaction and with S-GW change
The Routing Area Update with S-GW change procedure takes place when a UE that is registered with an MME selects
a UTRAN or GERAN cell and the S-GW is changed by the procedure. In this case, the UE changes to a Routing Area
that the UE has not yet registered with the network. This procedure is initiated by an ECM-IDLE state UE and may also
be initiated if the UE is in ECM-CONNECTED state. This RA update case is illustrated in Figure 5.3.3.6-1.
NOTE 1: This procedure covers the MME to 2G or 3G SGSN RAU.
3GPP
Release 15 169 3GPP TS 23.401 V15.10.0 (2019-12)
RNC/ New Old PDN Old

UE BSS eNodeB SGSN MME HSS
Serving Serving GW SGSN PCRF
GW GW
1. UE Changes to
UTRAN or GERAN
2a. Routeing Area Update Request
2b. Routeing Area Update Request

3. Context Request
4. Context Response
5. Security Functions



12. Update Location
13. Cancel Location
14. S1-AP: S1 Release Command
Release E-UTRAN
connection
14. S1-AP: S1 Release Complete

(B)
19. Routeing Area Update Complete
20. Service Request
21. RAB Assignment Request

21b. RAB Assignment Response
Figure 5.3.3.6-1: Routing Area Update with MME interaction and with S-GW change
concern GTP based S5/S8
3GPP
Release 15 170 3GPP TS 23.401 V15.10.0 (2019-12)
network or the UE reselects a UTRAN or GERAN cell and the TIN indicates "GUTI". The UE in
2a. The UE sends a Routing Area Update Request (old RAI, old P-TMSI, P-TMSI Type, UE Core Network
Capability, MS Network Capability, P-TMSI Signature, additional P-TMSI/RAI, KSI, Voice domain preference
and UE's usage setting) message to the new SGSN. The UE shall set the P-TMSI Type to indicate whether the P-
TMSI is a native P-TMSI or is mapped from a GUTI.
If the UE's TIN indicates "GUTI" and the UE holds a valid GUTI then the UE indicates the GUTI as the old
P-TMSI and old RAI. If the UE's TIN indicates "P-TMSI" or "RAT-related TMSI" and the UE holds a valid
mapped from a GUTI, then the UE indicates these parameters as additional P-TMSI/RAI.
mobility.
If the UE has a follow-on request, i.e. if there is pending uplink traffic (signalling or data), the 3G-SGSN may
use, as an implementation option, the follow-on request indication to release or keep the Iu connection after the
completion of the RA update procedure.
KSI is mapped from an eKSI identifying a KASME if the UE indicates a P-TMSI mapped from GUTI in the
clause 4.3.5.9.
2b. The RNC shall add the Routing Area Identity, CSG access mode, CSG ID before forwarding the message to the
SGSN. This RA identity corresponds to the RAI in the MM system information sent by the RNC to the UE. The
BSS shall add the Cell Global Identity (CGI) of the cell where the UE is located before passing the message to
the new SGSN. CSG ID is provided by RAN if the UE sends the RAU Request message via a CSG cell or a
hybrid cell. CSG access mode is provided if the UE sends the RAU Request message via a hybrid cell. If the
CSG access mode is not provided but the CSG ID is provided, the SGSN shall consider the cell as a CSG cell.
For SIPTO at the Local Network the with stand-alone GW architecture the RNC includes the Local Home
Network ID in the Initial UE Message and in Direct Transfer message if the target cell is in a Local Home
Network.
3. The new S4 SGSN determines the type of the old node, i.e. MME or SGSN, as specified in clause 4.3.19, uses
the old RAI received from the UE to derive the old MME address, and the new S4 SGSN sends a Context
Request (P-TMSI, old RAI, New SGSN Address, P-TMSI Signature) message to the old MME to get the context
for the UE. To validate the Context Request the old MME uses a NAS token mapped from the P-TMSI
Signature. If the UE is not known in the old MME, the old MME responds with an appropriate error cause. If
integrity check fails in the old MME, the old MME responds with an appropriate error cause which should
initiate the security functions in the new S4 SGSN. If the security functions authenticate the UE correctly, the
new S4 SGSN shall send a Context Request (IMSI, old RAI, New SGSN Address, UE Validated) message to the
old MME. UE Validated indicates that the new S4 SGSN has authenticated the UE. If the new S4 SGSN
indicates that it has authenticated the UE or if the old MME authenticates the UE, the old MME starts a timer.
4. The old MME responds with a Context Response (MM Context, EPS Bearer Contexts, Serving GW signalling
Address and TEID(s), MS Info Change Reporting Action (if available), CSG Information Reporting Action (if
3GPP
Release 15 171 3GPP TS 23.401 V15.10.0 (2019-12)
available), UE Time Zone and ISR Supported) message. The MM context contains security related information
as well as other parameters (including IMSI) as described in clause 5.7.2 (Information Storage for MME). The
PDN GW Address and TEID(s) (for GTP-based S5/S8) or GRE Keys (PMIP-based S5/S8) for uplink traffic and
control plane, and the TI(s) is part of the EPS Bearer context(s). The unused Authentication Quintets in the MM
Context may be sent if stored by the MME and if the MME received the unused Authentication Quintets from
the same SGSN previously.
If the UE receives only emergency bearer services from the old MME and the UE is UICCless, IMSI can not be
included in the Context Response. For emergency attached UEs, if the IMSI cannot be authenticated, then the
IMSI shall be marked as unauthenticated. Also, in this case, security parameters are included only if available.
ISR Supported is indicated if the old MME and associated Serving GW are capable to activate ISR for the UE.
The new SGSN shall ignore the UE Core Network Capability in the MM Context of the Context Response only
when it has previously received an UE Core Network Capability in the Routing Area Request. If UE is not
known in the old MME, the old MME responds with a appropriate error cause.
The new SGSN maps the EPS bearers to PDP contexts 1-to-1 and maps the EPS Bearer QoS parameter values of
an EPS bearer to the Release 99 QoS parameter values of a bearer context as defined in Annex E. The PDP
context(s) are established in the indicated order. The SGSN deactivates the PDP contexts which cannot be
established.
MME shall include the Local Home Network ID of the old cell in the EPS Bearer context corresponding to the
SIPTO at the Local Network PDN connection.
If the UE uses power saving functions and the DL Data Buffer Expiration Time for the UE has not expired (see
High latency communication in clause 4.3.17.7), the old MME indicates Buffered DL Data Waiting in the
Context Response. When this is indicated, the new SGSN shall invoke data forwarding (corresponding to
clause 5.3.3.1A) and setup the user plane in conjunction to the RAU procedure for delivery of the buffered DL
data to the UE.
The old MME only transfers the EPS Bearer Context(s) that the new SGSN supports. If not supported, EPS
Bearer Context(s) of non-IP PDN connection are not transferred to the new SGSN. If the EPS Bearer Context(s)
of a PDN connection has not been transferred, the old MME shall consider all bearers of that PDN connection as
failed and release that PDN connection by triggering the MME requested PDN disconnection procedure
5. Security functions may be executed. Procedures are defined in clause 5.3.10 on "Security Function".
For ongoing emergency services only, if the new SGSN is configured to support emergency bearer services in
limited service state, it may skip the authentication procedure or proceed even if authentication fails. If the new
SGSN does not support emergency bearer services in limited service state, then it rejects the RAU request with
an appropriate reject cause.
6. If the new SGSN identifies that the RAT type has changed, the SGSN checks the subscription information to
reactivation request or disconnect PDN connection without reactivation request. If the SGSN decides to deactive
a PDN connection it performs SGSN-initiated PDN Connection Deactivation procedure after tracking area
procedure is completed. Existing SM cause values as specified in TS 24.008 [47] (e.g. #39, "reactivation
requested"; #66 "Requested APN not supported in current RAT and PLMN combination"; and for a dedicated
bearer, possibly #37 "QoS not accepted") are used to cause predictable UE behaviour.
The new SGSN determines to relocate the Serving GW. The Serving GW is relocated when the old Serving GW
cannot continue to serve the UE. The new SGSN may also decide to relocate the Serving GW if a new Serving
GW is expected to serve the UE longer and/or with a more optimal UE to PDN GW path, or if a new Serving
GW can be co-located with the PDN GW. Selection of a new Serving GW is performed according to
clause 4.3.8.2 on "Serving GW selection function".
The new SGSN sends a Context Acknowledge (Serving GW change indication) message to the old MME.
Serving GW change indication indicates a new Serving GW has been selected. The old MME marks in its
3GPP
Release 15 172 3GPP TS 23.401 V15.10.0 (2019-12)
context that the information in the GWs is invalid. This ensures that the old MME updates the GWs if the UE
initiates a TAU procedure back to the old MME before completing the ongoing RAU procedure.
NOTE 3: Updating the GWs refers to deletion of session(s) on the Serving GW followed by re-creation of
session(s) on the Serving GW. The re-creation of session(s) on the Serving GW will result in successful
re-establishment of the S5/S8 tunnel between the selected Serving GW and the PDN GW.
The old MME deletes all bearer resources of the UE when the timer started in step 3 expires.
If the security functions do not authenticate the UE correctly, then the RAU is rejected, and the new S4 SGSN
sends a reject indication to the old MME. The MME shall continue as if the Identification and Context Request
was never received.
For UE using CIoT EPS Optimisation without any activated PDN connection, the steps 7, 8, 9, 10, 11, 16 and 17
are skipped.
7. In this procedure flow the Serving GW is relocated. The SGSN sends a Create Session Request (IMSI, bearer
contexts, SGSN Address and TEID for the control plane, RAT Type, Type, the Protocol Type over S5/S8,
Serving Network, UE Time Zone, etc) message per PDN connection to the selected new Serving GW. The PDN
GW address is indicated in the bearer contexts. Type indicates to the Serving GW to send the Modify Bearer
Request to the PDN GW. The Protocol Type over S5/S8 is provided to Serving GW which protocol should be
used over S5/S8 interface. RAT type indicates a change in radio access. As it is a mobility from E-UTRAN, if
the target SGSN supports location information change reporting, the target SGSN shall include the User
Location Information (according to the supported granularity) in the Modify Bearer Request, regardless of
whether location information change reporting had been requested in the previous RAT by the PDN GW. If the
PDN GW requested User CSG information, the SGSN also includes the User CSG Information IE in this
message.
8. The new Serving GW sends the message Modify Bearer Request (Serving GW Address, Serving GW TEID,
RAT type, Serving Network) per PDN connection to the PDN GW concerned. User Location Information IE
and/or UE Time Zone IE and/or User CSG Information IE are also included if they are present in step 7.
9. If dynamic PCC is deployed, and RAT type information or UE location information or UE Time Zone needs to
be conveyed from the PDN GW to the PCRF, then the PDN GW shall send this information to the PCRF by
means of an IP-CAN Session Modification procedure as defined in TS 23.203 [6].
10. The PDN GW updates its context field and returns a Modify Bearer Response (Charging Id, MSISDN) message
to the Serving GW. The MSISDN is included if the PDN GW has it stored in its UE context. If location
information change reporting is required and supported in the target SGSN, the PDN GW shall provide MS Info
Change Reporting Action in the Modify Bearer Response.
immediately after switching the path. If the source Serving GW has no downlink user plane established, the
Serving GW shall discard the "end marker" received from the PDN GW and shall not send Downlink Data
Notification. Otherwise the Serving GW shall forward the "end marker" packets to the source eNodeB.
11. The new Serving GW updates its bearer context. This allows the Serving GW to route Bearer PDUs to the PDN
GW when received from RNC. The new Serving GW returns a Create Session Response (Serving GW address
and TEID, PDN GW Address and TEIDs (for GTP-based S5/S8) or GRE keys (for PMIP-based S5/S8, MS Info
Change Reporting Action) at the PDN GW(s) for uplink traffic) message to the SGSN.
When the SGSN receives the Create Session Response message, the SGSN checks if there is a "Availability after
DDN Failure" monitoring event or a "UE Reachability" monitoring event configured for the UE in the SGSN
and in such a case sends an event notification (see TS 23.682 [74] for further information).
12. The new SGSN verifies whether it holds subscription data for the UE identified by the P-TMSI, the additional
P-TMSI/RAI or by the IMSI received with the context data from the old CN node.
The additional P-TMSI/RAI allows the new SGSN to find any already existing UE context stored in the new
SGSN. If there are no subscription data in the new SGSN for this UE, or for some network sharing scenario (e.g.
GWCN) if the PLMN-ID of the RAI supplied by the RNC is different from that of the RAI in the UE's context,
3GPP
Release 15 173 3GPP TS 23.401 V15.10.0 (2019-12)
then the new SGSN informs the HSS of the change of SGSN by sending an Update Location (SGSN Number,
SGSN Address, IMSI, Homogenous Support of IMS Voice over PS Session, UE SRVCC capability, equivalent
PLMN list) message to the HSS. For "Homogenous Support of IMS Voice over PS Sessions", see clause 5.3.8A
of TS 23.060 [7]. The inclusion of the equivalent PLMN list indicates that the SGSN supports the inter-PLMN
handover to a CSG cell in an equivalent PLMN using the subscription information of the target PLMN.
If the UE initiates the RAU procedure in a VPLMN supporting Autonomous CSG Roaming and the HPLMN has
enabled Autonomous CSG Roaming in the VPLMN (via Service Level Agreement) and the SGSN needs to
retrieve the CSG subscription information of the UE from the CSS, the SGSN initiates the Update CSG Location
13. The HSS sends a Cancel Location (IMSI, Cancellation Type) message to the old SGSN with the Cancellation
Type set to Update Procedure.
When receiving the Cancel Location message the old SGSN removes all the UE contexts. The old SGSN
acknowledges with a Cancel Location Ack (IMSI) message.
14. When receiving the Context Acknowledge message from the new S4 SGSN and if the old MME has an S1-
MME association for the UE, the source MME sends a S1-U Release Command to the source eNodeB after the
timer started in step3 has expired. The RRC connection is released by the source eNodeB. The source eNodeB
confirms the release of the RRC connection and of the S1-U connection by sending a S1-U Release Complete
message to the source MME.
Data) to the new SGSN. If the Update Location is rejected by the HSS, the new SGSN rejects the RAU Request
from the UE with an appropriate cause. In such cases, the SGSN releases any local SGSN EPS Bearer contexts
for this particular UE, and additionally deletes the EPS bearer resources in the new Serving GW by sending the
Delete Session Request (Cause, Operation Indication) messages to the new Serving GW. The Operation
Indication flag shall not be set. Therefore, the new Serving GW receiving this request shall not initiate a delete
procedure towards the PDN GW.
The new SGSN validates the UE's presence in the (new) RA. If due to regional subscription restrictions or access
restrictions (e.g. CSG restrictions) the UE is not allowed to be attached in the RA, the SGSN rejects the Routing
Area Update Request with an appropriate cause to the UE and notifies the HSS of the rejection. The Subscription
Data may contain the CSG subscription data for the registered PLMN and for the equivalent PLMN list
requested by SGSN in step 12.
If the UE initiates the RAU procedure at a CSG cell, the new S4 SGSN shall check whether the CSG ID and
is not present or expired, the S4 SGSN shall send a RAU reject message to the UE with an appropriate cause
value. The UE shall remove the CSG ID and associated PLMN from its Allowed CSG list if present.
16. When the timer started in step 3 expires and the old MME received the Serving GW change indication in the
Context Acknowledge message, the old MME deletes the EPS bearer resources by sending Delete Session
Request (Cause, Operation Indication) messages to the old Serving GW. The operation Indication flag is not set,
that indicates to the old Serving GW that the old Serving GW shall not initiate a delete procedure towards the
PDN GW. If ISR is activated the cause indicates to the old S-GW that the old S-GW shall delete the bearer
resources on the other old CN node by sending Delete Bearer Request message(s) to that CN node.
17. The old Serving GW acknowledges with Delete Session Response (Cause) messages. The old Serving GW
discards any packets buffered for the UE.
18. If due to regional subscription restrictions or access restrictions the UE is not allowed to access the RA:
- For UEs with ongoing emergency bearer services, the new SGSN accept the Routing Area Update Request and
deactivates the non-emergency PDP contexts as specified in clause 9.2.4.2 of TS 23.060 [7]. If the Routing Area
Update procedure is initiated in PMM-IDLE/STANDBY state, all non-emergency PDP Contexts are deactivated
by the Routing Area Update procedure without PDP Context deactivation signalling between the UE and the
SGSN.
- For all other cases, the new SGSN rejects Routing Area Update Request with an appropriate cause to the UE and
notifies the HSS of rejection (details of this notification is specified in stage 3).
3GPP
Release 15 174 3GPP TS 23.401 V15.10.0 (2019-12)
The new SGSN responds to the UE with a Routing Area Update Accept (P-TMSI, P-TMSI Signature,
Emergency Service Support indicator, PDP context status) message. The Emergency Service Support indicator
informs the UE that Emergency bearer services are supported over UTRAN.
For an S-GW change ISR Activated is never indicated by the SGSN to the UE as it needs a TAU with the same
S-GW first to activate ISR. For an SGSN change ISR is not activated by the new SGSN to avoid context transfer
procedures with two old CN nodes.
When receiving the RAU Accept message, as there is no ISR Activated indication, the UE shall set its TIN to
"P-TMSI".
In Iu mode, if after step 7 the new SGSN receives a Downlink Data Notification message or any other downlink
signalling message while the UE is still connected, the new SGSN may prolong the PS signalling connection
with the UE.
If there is DL data buffered for a UE using power saving functions (i.e. the DL Data Buffer Expiration Time in
the MM context for the UE in the SGSN has not expired), the user plane setup is performed in conjunction with
the RAU Accept message.
If the RAU procedure is initiated by manual CSG selection and occurs via a CSG cell, the UE upon receiving the
RAU Accept message shall add the CSG ID and associated PLMN to its Allowed CSG list if it is not already
With the PDP context status information, the UE shall deactivate all those bearers contexts locally which are
active in the UE, but are indicated by the SGSN as being inactive.
If the user plane setup is performed in conjunction with the RAU Accept message and the RAU is performed via
a hybrid cell, then the SGSN shall send an indication whether the UE is a CSG member to the RAN along with
the RANAP message. Based on this information the RAN may perform differentiated treatment for CSG and
non-CSG members.
NOTE 5: If the UE receives a RAU Accept message via a hybrid cell, the UE does not add the corresponding CSG
NOTE 6: When ISR Activated is indicated and the UE's TIN indicates "P-TMSI" the TIN is not changed. When
ISR Activated is indicated and the UE's TIN indicates "GUTI" or "RAT-related TMSI" the UE shall set
its TIN to "RAT-related TMSI".
19. If the P-TMSI was included in the RAU Accept message, the UE acknowledges the new P-TMSI by returning a
Routing Area Update Complete message to the SGSN.
20. For Iu-mode, if the UE has uplink data or signalling pending it shall send a Service Request (P-TMSI, CKSN,
Service Type) message to the new SGSN. If a P-TMSI was allocated in step 18, that P-TMSI is the one included
in this message. Service Type specifies the requested service. Service Type shall indicate one of the following:
Data or Signalling.
21. If the UE has sent the Service Request, the new 3G SGSN requests the RNC to establish a radio access bearer by
sending a RAB Assignment Request (RAB ID(s), QoS Profile(s), GTP SNDs, GTP SNUs, PDCP SNUs)
message to the RNC. If Direct Tunnel is established the SGSN provides to the RNC the Serving GW's Address
for User Plane and TEID for uplink data.
22. If the SGSN established Direct Tunnel in step 21) it shall send Modify Bearer Request to the Serving GW and
include the RNC's Address for User Plane and downlink TEID for data. The Serving GW updates the Address
for User Plane and TEID for downlink data and return a Modify Bearer Response.
NOTE 7: EPS does not support any CAMEL procedures.
In the case of a rejected routing area update operation, due to regional subscription, roaming restrictions, access
restrictions (see TS 23.221 [27] and TS 23.008 [28]) or because the SGSN cannot determine the HLR address to
establish the locating updating dialogue, the new SGSN should not construct an MM context. In the case of receiving
the subscriber data from HLR, the new SGSN may construct an MM context and store the subscriber data for the UE to
optimise signalling between the SGSN and the HSS. A reject shall be returned to the UE with an appropriate cause and
the PS signalling connection shall be released. Upon return to idle, the UE shall act according to TS 23.122 [10].
3GPP
Release 15 175 3GPP TS 23.401 V15.10.0 (2019-12)
If the new SGSN is unable to update the bearer context in one or more P-GWs, the new SGSN shall deactivate the
corresponding bearer contexts as described in clause "SGSN-initiated PDP Context Deactivation Procedure" of
TS 23.060 [7]. This shall not cause the SGSN to reject the routing area update.
The new SGSN shall determine the Maximum APN restriction based on the received APN Restriction of each bearer
The PDP contexts shall be prioritized by the new SGSN. If the new SGSN is unable to support the same number of
active PDP contexts as received from old MME, the prioritisation is used to decide which PDP contexts to maintain
active and which ones to delete. In any case, the new SGSN shall first update all PDP contexts in one or more P-GWs
and then deactivate the PDP context(s) that it cannot maintain as described in clause "SGSN-initiated PDP Context
Deactivation Procedure" of TS 23.060 [7]. This shall not cause the SGSN to reject the routing area update.
If the routing area update procedure fails a maximum allowable number of times, or if the SGSN returns a Routing Area
Update Reject (Cause) message, the MS shall enter IDLE state.
5.3.4 Service Request procedures
5.3.4.1 UE triggered Service Request
UE eNodeB MME Serving GW PDN GW PCRF HSS
1. NAS: Service Request
2. NAS: Service Request
3. Authentication/Security
4. S1-AP: Initial Context Setup Request
5. Radio Bearer Establishment
6. Uplink Data
7. S1-AP: Initial Context Setup Complete

(A)

Figure 5.3.4.1-1: UE triggered Service Request procedure
The Service Request procedure in this clause is triggered by the UE in ECM-IDLE status to establish user plane radio
bearers for the UE.
The UE in ECM-IDLE state can also use this procedure to establish user plane radio bearers even if the UE applies
Control Plane CIoT EPS Optimisation, when the UE and MME supports S1-U data transfer or User Plane EPS
Optimisation in addition to Control Plane CIoT EPS Optimisation.
NOTE 1: For a PMIP-based S5/S8, procedure steps (A) are defined in TS 23.402 [2]. Steps 9 and 11 concern GTP-
based S5/S8.
3GPP
Release 15 176 3GPP TS 23.401 V15.10.0 (2019-12)
1. The UE sends NAS message Service Request towards the MME encapsulated in an RRC message to the
eNodeB. The RRC message(s) that can be used to carry the S-TMSI and this NAS message are described in
TS 36.300 [5].
2. The eNodeB forwards NAS message to MME. NAS message is encapsulated in an S1-AP: Initial UE Message
(NAS message, TAI+ECGI of the serving cell, S-TMSI, CSG ID, CSG access Mode, RRC establishment cause).
Details of this step are described in TS 36.300 [5]. If the MME can't handle the Service Request it will reject it.
CSG ID is provided if the UE sends the Service Request message via a CSG cell or a hybrid cell. CSG access
mode is provided if the UE sends the Service Request message via a hybrid cell. If the CSG access mode is not
provided but the CSG ID is provided, the MME shall consider the cell as a CSG cell.
If a CSG ID is indicated and CSG access mode is not provided, and there is no subscription data for this CSG ID
and associated PLMN or the CSG subscription is expired, the MME rejects the Service Request with an
appropriate cause. The UE shall remove the CSG ID and associated PLMN of the cell where the UE has initiated
the service request procedure from the Allowed CSG list, if present.
For UEs with emergency EPS bearers, i.e. at least one EPS bearer has an ARP value reserved for emergency
services, if CSG access restrictions do not allow the UE to get normal services the MME shall deactivate all non-
emergency bearers and accept the Service Request.
If LIPA is active for a PDN connection and if the cell accessed by the UE does not link to the L-GW where the
UE inititiated the LIPA PDN Connection, the MME shall not request the establishment of the bearers of the
LIPA PDN connection from the eNodeB in step 4 and shall request disconnection of the LIPA PDN connection
according to clause 5.10.3. If the UE has no other PDN connection then the MME shall reject the Service
Request with an appropriate cause value resulting in the UE detaching, skip the following steps of the procedure
and initiate the release of the core network resources with the implicit MME-initiated Detach procedure
If there is a "Availability after DDN Failure" monitoring event or a "UE Reachability" monitoring event
configured for the UE in the MME, the MME sends an event notification (see TS 23.682 [74] for further
information).
3. NAS authentication/security procedures as defined in clause 5.3.10 on "Security function" may be performed.
4. If there is a Service Gap timer running in the MME MM Context for the UE and the MME is not waiting for a
MT paging response from the UE, the MME rejects the Service Request with an appropriate cause. In addition,
MME may also provide a UE with a Mobility Management Back-off timer set to the remaining value of the
Service Gap timer.
The MME deletes S11-U related information in UE context if there is any, including TEID(DL) for the S11-U
for Control Plane CIoT EPS Optimisation if data buffering is in the MME, ROHC context for Control Plane
CIoT EPS Optimisation, etc, but not the Header Compression Configuration. The MME sends S1-AP Initial
Context Setup Request (Serving GW address, S1-TEID(s) (UL), EPS Bearer QoS(s), Security Context, MME
Signalling Connection Id, Handover Restriction List, CSG Membership Indication) message to the eNodeB. If
there is a PDN connection established for Local IP Access, this message includes a Correlation ID for enabling
the direct user plane path between the HeNB and the L-GW. If there is a PDN connection established for SIPTO
at the Local Network with L-GW function collocated with the (H)eNB, this message includes a SIPTO
Correlation ID for enabling the direct user plane path between the (H)eNB and the L-GW. This step activates the
radio and S1 bearers for all the active EPS Bearers. The eNodeB stores the Security Context, MME Signalling
Connection Id, EPS Bearer QoS(s) and S1-TEID(s) in the UE RAN context. The step is described in detail in
TS 36.300 [5]. Handover Restriction List is described in clause 4.3.5.7 "Mobility Restrictions".
NOTE 2: In this release of the 3GPP specification the Correlation ID and SIPTO Correlation ID is set equal to the
user plane PDN GW TEID (GTP-based S5) or GRE key (PMIP-based S5) which is specified in
clause 5.3.2.1 and clause 5.10.2.
If the UE included support for restriction of use of Enhanced Coverage, the MME sends Enhanced Coverage
Restricted parameter to the eNB in the S1-AP message.
The MME shall only request to establish Emergency EPS Bearer if the UE is not allowed to access the cell
where the UE initiated the service request procedure due to CSG access restriction.
3GPP
Release 15 177 3GPP TS 23.401 V15.10.0 (2019-12)
If the Service Request is performed via a hybrid cell, CSG Membership Indication indicating whether the UE is a
CSG member shall be included in the S1-AP message from the MME to the RAN. Based on this information the
RAN can perform differentiated treatment for CSG and non-CSG members.
5. The eNodeB performs the radio bearer establishment procedure. The user plane security is established at this
step, which is described in detail in TS 36.300 [5]. When the user plane radio bearers are setup. EPS bearer state
synchronization is performed between the UE and the network, i.e. the UE shall locally remove any EPS bearer
for which no radio bearers are setup and, if the radio bearer for a default EPS bearer is not established, the UE
shall locally deactivate all EPS bearers associated to that default EPS bearer.
6. The uplink data from the UE can now be forwarded by eNodeB to the Serving GW. The eNodeB sends the
uplink data to the Serving GW address and TEID provided in the step 4. The Serving GW forwards the uplink
data to the PDN GW.
7. The eNodeB sends an S1-AP message Initial Context Setup Complete (eNodeB address, List of accepted EPS
bearers, List of rejected EPS bearers, S1 TEID(s) (DL)) to the MME. This step is described in detail in
TS 36.300 [5]. If the Correlation ID or SIPTO Correlation ID is included in step 4, the eNodeB shall use the
included information to establish a direct user plane path to the L-GW and forward uplink data for Local IP
Access or SIPTO at the Local Network with L-GW function collocated with the (H)eNB accordingly.
8. The MME sends a Modify Bearer Request message (eNodeB address, S1 TEID(s) (DL) for the accepted EPS
bearers, Delay Downlink Packet Notification Request, RAT Type, MO Exception data counter) per PDN
connection to the Serving GW. If the Serving GW supports Modify Access Bearers Request procedure and if
there is no need for the Serving GW to send the signalling to the PDN GW, the MME may send Modify Access
Bearers Request (eNodeB address(es) and TEIDs for downlink user plane for the accepted EPS bearers, Delay
Downlink Packet Notification Request) per UE to the Serving GW to optimise the signalling. The Serving GW is
now able to transmit downlink data towards the UE. The usage of the Delay Downlink Packet Notification
Request Information Element is specified in clause 5.3.4.2 below. If the PDN GW requested UE's location
and/or User CSG information and the UE's location and/or User CSG information has changed, the MME also
includes the User Location Information IE and/or User CSG Information IE in this message. If ISR is activated
or if the Serving Network IE has changed compared to the last reported Serving Network IE then the MME also
includes the Serving Network IE in this message. If the UE Time Zone has changed compared to the last
reported UE Time Zone then the MME shall include the UE Time Zone IE in this message. If the internal flag
Pending Network Initiated PDN Connection Signalling is set, the MME indicates UE available for end to end
signalling in the Modify Bearer Request message and reset the flag.
The MME only includes the MO Exception data counter if the RRC establishment cause is set to "MO exception
data" and the UE is accessing via the NB-IoT RAT. The MME maintains the MO Exception Data Counter for
Serving PLMN Rate Control purposes (see clause 4.7.7.2). The MME may immediately send the MO Exception
Data Counter to the Serving GW. Alternatively, in order to reduce signalling, the MME may send the MO
Exception Data Counter to the Serving GW as described in TS 29.274 [43].
The MME and the Serving GW clears the DL Data Buffer Expiration Time in their UE contexts if it was set, to
remember that any DL data buffered for a UE using power saving functions has been delivered and to avoid any
unnecessary user plane setup in conjunction with a later TAU.
If a default EPS bearer is not accepted by the eNodeB, all the EPS bearers associated to that default bearer shall
be treated as non-accepted bearers. The MME releases the non-accepted bearers by triggering the bearer release
procedure as specified in clause 5.4.4.2. If the Serving GW receives a DL packet for a non-accepted bearer, the
Serving GW drops the DL packet and does not send a Downlink Data Notification to the MME.
9. If the RAT Type has changed compared to the last reported RAT Type or if the UE's Location and/or Info IEs
and/or UE Time Zone and/or if ISR is not activated and Serving Network id and/or the indication UE available
for end to end signalling are present in step 8, the Serving GW shall send the Modify Bearer Request message
(RAT Type, MO Exception data counter) per PDN connection to the PDN GW. User Location Information IE
and/or User CSG Information IE and/or Serving Network IE and/or UE Time Zone and/or the indication UE
available for end to end signalling are also included if they are present in step 8.
paused, then the SGW shall send a Modify Bearer Request message with PDN Charging Pause Stop Indication
to inform the PDN GW that the charging is no longer paused. Other IEs are not included in this message.
If the Modify Bearer Request message is not sent because of above reasons but the MME indicated the MO
Exception data counter, then the Serving Gateway should notify the PDN GW that this RRC establishment cause
3GPP
Release 15 178 3GPP TS 23.401 V15.10.0 (2019-12)
has been used by the MO Exception Data Counter (see TS 29.274 [43]). The Serving GW indicates each use of
this RRC establishment cause by the related counter on its CDR.
10. If dynamic PCC is deployed, the PDN GW interacts with the PCRF to get the PCC rule(s) according to the RAT
Type by means of a PCEF initiated IP-CAN Session Modification procedure as defined in TS 23.203 [6]. If
dynamic PCC is not deployed, the PDN GW may apply local QoS policy.
The PDN GW indicates each use of the RRC establishment cause "MO Exception Data" by the related counter
on its CDR.
11. The PDN GW sends the Modify Bearer Response to the Serving GW.
12. The Serving GW shall return a Modify Bearer Response (Serving GW address and TEID for uplink traffic) to
the MME as a response to a Modify Bearer Request message, or a Modify Access Bearers Response (Serving
GW address and TEID for uplink traffic) as a response to a Modify Access Bearers Request message. If the
Serving GW cannot serve the MME Request in the Modify Access Bearers Request message without S5/S8
signalling other than to unpause charging in the PDN GW or without corresponding Gxc signalling when PMIP
is used over the S5/S8 interface, it shall respond to the MME with indicating that the modifications are not
limited to S1-U bearers, and the MME shall repeat its request using a Modify Bearer Request message per PDN
connection.
If SIPTO at the Local Network is active for a PDN connection with stand-alone GW deployment and the Local
Home Network ID for stand-alone accessed by the UE differs from the Local Home Network ID where the UE
initiated the SIPTO@LN PDN Connection, the MME shall request disconnection of the SIPTO at the local
network PDN connection(s) with the "reactivation requested" cause value according to clause 5.10.3. If the UE
has no other PDN connection, the MME initiated "explicit detach with reattach required" procedure according to
clause 5.3.8.3.
If SIPTO at the Local Network is active for a PDN connection with collocated LGW deployement and the L-GW
CN address of the cell accessed by the UE differs from the L-GW CN address of the cell where the UE initiated
the SIPTO at the Local Network PDN Connection, the MME shall request disconnection of the SIPTO at the
local network PDN connection(s) with the "reactivation requested" cause value according to clause 5.10.3. If the
UE has no other PDN connection, the MME initiated "explicit detach with reattach required" procedure
5.3.4.2 Handling of abnormal conditions in UE triggered Service Request

Under certain conditions, the current UE triggered Service Request procedure can cause unnecessary Downlink Packet
Notification messages which increase the load of the MME.
This can occur when uplink data sent in step 6 causes a response on the downlink which arrives at the Serving GW
before the Modify Bearer Request message, step 8. This data cannot be forwarded from the Serving GW to the eNodeB
and hence it triggers a Downlink Data Notification message.
If the MME receives a Downlink Data Notification after step 2 and before step 9, the MME shall not send S1 interface
paging messages. However, across all the UEs on that MME, the MME shall monitor the rate at which these events
occur. If the rate becomes significant (as configured by the operator) and the MME's load exceeds an operator
configured value, the MME shall indicate "Delay Downlink Packet Notification Request" with parameter D to the
Serving Gateway, where D is the requested delay given as an integer multiple of 50 ms, or zero. The Serving GW then
uses this delay in between receiving downlink data and sending the Downlink Data Notification message.
NOTE 1: A low rate of reception of Downlink Data Notifications between steps 2 and 9 should be considered a
normal circumstance, e.g. due to the chance that a UE Terminating call/session is initiated at roughly the
same time as the UE triggered Service Request procedure.
NOTE 2: It is recommended that this rate is determined over 60 second periods.
The MME shall use the step 8 Modify Access Bearers Request or Modify Bearer Request of the UE initiated Service
Request procedure to indicate "Delay Downlink Packet Notification Request" to the Serving GW.
To determine the amount of delay requested by a given MME, the Serving GW either uses the last Modify Access
Bearers Request or Modify Bearer Request message which is part of a Service Request procedure, or, just uses one of
the Service Request procedure's Modify Access Bearers Request or Modify Bearer Request messages received within
the preceding 30 seconds. The latter mode of operation shall be taken into account when implementing the MME.
3GPP
Release 15 179 3GPP TS 23.401 V15.10.0 (2019-12)
The MME is responsible for setting the value of D. The exact algorithm for setting the value is implementation
dependent, two examples are given below to serve as a guideline:
EXAMPLE 1: The MME adaptively increases the value of D when the rate of unnecessary Downlink Data
Notifications is too high; and correspondingly it decreases the value when the rate is not too high.
EXAMPLE 2: When unnecessary Downlink Data Notifications arrive, the MME measures the average time from
the reception of the unnecessary Downlink Data Notification to the reception of the Modify
Access Bearers Request or Modify Bearer Response from the Serving GW in the same UE
triggered Service Request Procedure. The value of D is calculated from this average, by adding a
safety margin.
Normally, upon receipt of a downlink data packet for which there is no DL-TEID of the S1 user plane tunnel, the S-GW
shall send the Downlink Data Notification message to the MME without delay.
If the S-GW determines from the last Modify Access Bearers Request or Modify Bearer Request message which is part
of a Service Request procedure that a given MME request delaying of the Downlink Packet Notification by a delay of
D, it shall (only for UEs of that MME) buffer the Downlink Data for a period D. If the DL-TEID and eNodeB address
for the UE is received before the expiry of the timer, the timer shall be cancelled and the Network triggered Service
Request procedure is finished without sending the Downlink Data Notification message to the MME, i.e. DL data are
sent to the UE. Otherwise the Downlink Data Notification message is sent to the MME when the timer expires.
NOTE 3: The above procedure and indicated time values are intended to ensure that the procedure is "stable";
avoids RAN impacts; and, that the negative impacts of shortening the DRX interval on UE battery life are
avoided.
5.3.4.3 Network Triggered Service Request
UE eNodeB RNC/BSC MME SGSN S-GW PDN GW

1. Downlink Data
2a. Downlink Data Notification
2b. Downlink Data Notification Ack

3a. Paging 2b. Downlink Data Notification Ack

3b. Paging
4a. Paging
4b. Paging
5. Service Request Procedure
6a. Stop Paging
6b. Stop Paging
Downlink Data E-UTRAN
Downlink Data 2G or 3G non DT
Downlink Data 3G DT
Figure 5.3.4.3-1: Network triggered Service Request procedure
If the MME needs to signal with the UE that is in ECM-IDLE state, e.g. to perform the MME/HSS-initiated detach
procedure for the ECM-IDLE mode UE or the S-GW receives control signalling (e.g. Create Bearer Request or Update
Bearer Request), the MME starts network triggered service request procedure from step 3a in the Network Triggered
Service request procedure.
If the MME wishes to use the Control Plane CIoT EPS Optimisation for mobile terminating services, then the procedure
of clause 5.3.4B.3 is used to replace the procedure of this clause.
If ISR is activated, when the Serving GW receives a Create Bearer Request or Update Bearer Request for a UE, and the
S-GW does not have a downlink S1-U and the SGSN has notified the Serving GW that the UE has moved to PMM-
IDLE or STANDBY state, the Serving GW buffers signalling messages and sends a Downlink Data Notification to
3GPP
Release 15 180 3GPP TS 23.401 V15.10.0 (2019-12)
trigger the MME and SGSN to page the UE. If the Serving GW, while waiting for the user plane to be established, is
triggered to send a second Downlink Data Notification with higher priority (i.e. ARP priority level) than the first
Downlink Data Notification was sent with, the Serving GW sends a new Downlink Data Notification message
indicating the higher priority to the MME. If the Serving GW receives additional downlink signalling messages for a
bearer with same or lower priority than the first Downlink Data Notification was sent for or if the Serving GW has sent
the second Downlink Data Notification message indicating the higher priority and receives additional downlink
signalling messages for this UE, the Serving GW buffers these downlink signalling messages and does not send a new
Downlink Data Notification. The S-GW will be notified about the current RAT type based on the UE triggered service
request procedure. The S-GW will go on executing the dedicated bearer activation or dedicated bearer modification
procedure, i.e. send the corresponding buffered signalling to MME or SGSN which UE resides in now and inform the
current RAT type to the PDN GW if the RAT type has been changed compared to the last reported RAT Type. If
dynamic PCC is deployed, the current RAT type information shall also be conveyed from the PDN GW to the PCRF. If
the PCRF response leads to an EPS bearer modification the PDN GW should initiate a bearer update procedure as
specified in clause 5.4.2.1 below.
When the Serving GW sends a Downlink Data Notification, it shall include both EPS Bearer ID and ARP. If the
Downlink Data Notification is triggered by the arrival of downlink data packets at the Serving GW, the Serving GW
shall include the EPS Bearer ID and ARP associated with the bearer on which the downlink data packet was received. If
the Downlink Data Notification is triggered by the arrival of control signalling, the Serving GW shall include the EPS
Bearer ID and ARP if present in the control signalling. If the ARP is not present in the control signalling, the Serving
GW shall include the ARP in the stored EPS bearer context.
If a LIPA PDN connection exists, when the L-GW receives the downlink data for a UE that is in ECM-IDLE state, the
L-GW sends the first downlink user packet to Serving GW and buffers all other downlink user packets. The Serving
GW will trigger the MME to page the UE.
1. When the Serving GW receives a downlink data packet/control signalling for a UE known as not user plane
connected (i.e. the S-GW context data indicates no downlink user plane TEID), it buffers the downlink data
packet and identifies which MME or SGSN is serving that UE.
If that MME has requested the Serving GW to throttle downlink low priority traffic and if the downlink data
packet is received on a low priority bearer to be throttled (see clause 4.3.7.4.1a), the SGW drops the downlink
data. The steps below are not executed.
If that MME has requested the S-GW to delay sending the Downlink Data Notification (see clause 5.3.4.2 on
"Handling of abnormal conditions in UE triggered Service Request"), the Serving GW buffers the downlink data
and waits until the timer expires before continuing with step 2. If the DL-TEID and eNodeB address for that UE
is received before the expiry of the timer, the timer shall be cancelled and the Network triggered Service Request
procedure is finished without executing the steps below, i.e. DL data are sent to the UE.
If the Serving GW receives additional downlink data packets/control signalling for this UE before the expiry of
the timer, the Serving GW does not restart this timer.
2. The Serving GW sends a Downlink Data Notification message (ARP, EPS Bearer ID, Paging Policy Indication)
to the MME and SGSN nodes for which it has control plane connectivity for the given UE. The ARP and EPS
Bearer ID are always set in Downlink Data Notification. The MME and SGSN respond to the S-GW with a
Downlink Data Notification Ack message. When supporting Paging Policy Differentiation, the Serving GW
indicates in the message the Paging Policy Indication related to the downlink data that triggered the Downlink
Data Notification message, as described in clause 4.9.
NOTE 1: The ARP, the EPS Bearer ID and optionally the Paging Policy Indication are sent to the SGSN as well as
MME, but the usage of these parameters at SGSN is not specified in this release of the specification.
An MME and an SGSN that detects that the UE is in a power saving state (e.g. Power Saving Mode or extended
idle mode DRX) and cannot be reached by paging at the moment, shall invoke extended buffering depending on
operator configuration, except for cases described in next paragraphs. MME/SGSN derives the expected time
before radio bearers can be established to the UE. The MME/SGSN then indicates DL Buffering Requested to
the Serving GW in the Downlink Data Notification Ack message and includes a DL Buffering Duration time and
optionally a DL Buffering Suggested Packet Count. The MME/SGSN stores a new value for the DL Data Buffer
Expiration Time in the MM context for the UE based on the DL Buffering Duration time and skips the remaining
steps of this procedure. The DL Data Buffer Expiration Time is used for UEs using power saving state and
indicates that there are buffered data in the Serving GW and that the user plane setup procedure is needed when
the UE makes signalling with the network. When the DL Data Buffer Expiration Time has expired, the
3GPP
Release 15 181 3GPP TS 23.401 V15.10.0 (2019-12)
MME/SGSN considers no DL data to be buffered and no indications of Buffered DL Data Waiting are sent
during context transfers at TAU procedures.
If there is a "Availability after DDN Failure" monitoring event configured for the UE in the MME/SGSN, the
MME/SGSN does not invoke extended buffering. Instead, the MME/SGSN sets the Notify-on-available-after-
DDN-failure flag to remember to send an "Availability after DDN Failure" notification when the UE becomes
available. If there is a "UE Reachability" monitoring event configured for the UE in the MME/SGSN, the
MME/SGSN should not need to invoke extended buffering.
NOTE 2: When "Availability after DDN failure" and "UE reachability" monitoring events are used for a UE, the
application server is assumed to send data when the UE is reachable or about to become reachable, hence
no extended buffering is needed. If there are multiple application servers, the event notifications and
extended buffering may be needed simultaneously. It is assumed this is handled through additional
information based on SLA as described in the next paragraph.
The MME/SGSN may use additional information based on a SLA with the MTC user for when to invoke
extended buffering, e.g. only invoke it for a certain APN, do not invoke it for certain subscribers, invoke
extended buffering in conjunction with "Availability after DDN failure" and "UE reachability" monitoring
events, etc.
A Serving GW that receives a DL Buffering Requested indication in a Downlink Data Notification Ack message
stores a new value for the DL Data Buffer Expiration Time based on the DL Buffering Duration time and does
not send any additional Downlink Data Notification if subsequent downlink data packets are received in the
Serving GW before the buffer time DL Data Buffer Expiration Time has expired for the UE.
If the Serving GW, while waiting for the user plane to be established, is triggered to send a second Downlink
Data Notification for a bearer with higher priority (i.e. ARP priority level) than the first Downlink Data
Notification was sent for, the SGW sends a new Downlink Data Notification message indicating the higher
priority to the MME. If the Serving GW receives additional downlink data packets for a bearer with same or
lower priority than the first Downlink Data Notification was sent for or if the Serving GW has sent the second
Downlink Data Notification message indicating the higher priority and receives additional downlink data packets
for this UE, the Serving GW buffers these downlink data packets and does not send a new Downlink Data
Notification.
If the Serving GW, while waiting for the user plane to be established, receives a Modify Bearer Request message
from MME or SGSN other than the one it sent a Downlink Data Notification message to, the Serving GW re-
sends the Downlink Data Notification message only to the new MME or SGSN from which it received the
Modify Bearer Request message even if ISR is active.
If the Tracking Area Update procedure with MME change or the Routing Area Update procedure is in progress
when the old MME receives a Downlink Data Notification message, the old MME may reject a Downlink Data
Notification message with an indication that the Downlink Data Notification message has been temporarily
rejected.
Similarly, if the Routing Area Update procedure with SGSN change or the Tracking Area Update procedure is in
progress when the old SGSN receives a Downlink Data Notification message, the old SGSN may reject a
Downlink Data Notification message with an indication that the Downlink Data Notification message has been
temporarily rejected.
Upon reception of a Downlink Data Notification Ack message with an indication that the Downlink Data
Notification message has been temporarily rejected and if the Downlink Data Notification is triggered by the
arrival of downlink data packets at the Serving GW, the Serving GW may start a locally configured guard timer
and buffers all downlink user packets received to the given UE and waits for a Modify Bearer Request message
to come. Upon reception of a Modify Bearer Request message, the Serving GW re-sends the Downlink Data
Notification message only to the new MME or SGSN from which it received the Modify Bearer Request
message even if ISR is active. Otherwise the Serving GW releases buffered downlink user packets at expiry of
the guard timer or receiving the Delete Session Request message from MME/SGSN.
arrival of signalling messages at the Serving GW, the Serving GW may reject the PDN GW initiated EPS
bearer(s) request with the same indication that the request has been temporarily rejected. Upon reception of a
rejection for an EPS bearer(s) PDN GW initiated procedure with an indication that the request has been
temporarily rejected, the PDN GW may start a locally configured guard timer. The PDN GW may re-attempt, up
3GPP
Release 15 182 3GPP TS 23.401 V15.10.0 (2019-12)
to a pre-configured number of times, when either it detects the UE accesses via a new SGW or at expiry of the
guard timer.
3a. If the UE is registered in the MME and considered reachable for paging, the MME sends a Paging message
(NAS ID for paging, TAI(s), UE identity based DRX index, Paging DRX length, list of CSG IDs for paging,
Paging Priority indication, Enhanced Coverage Restricted, CE mode B Restricted) to each eNodeB belonging to
the tracking area(s) in which the UE is registered. The step is described in detail in TS 36.300 [5] and
TS 36.413 [36]. Steps 3-4 are omitted if the MME already has a signalling connection over S1-MME towards the
UE but the S1-U tunnel has not yet been established.
If extended idle mode DRX is enabled for the UE, the MME pages the UE just before the occurrence of the UE's
next paging occasion, which is determined as described in TS 23.682 [74].
NOTE 3: Steps 3a and 4a are performed also when the UE and the network support User Plane CIoT EPS
Optimisation and the previous RRC connection has been suspended.
Paging priority indication is included only:
- if the MME receives a Downlink Data Notification or Create Bearer Request with an ARP priority level
associated with MPS or other priority services, as configured by the operator.
- One Paging Priority level can be used for multiple ARP priority level values. The mapping of ARP priority
level values to Paging Priority level (or levels) is configured by operator policy.
During a congestion situation the eNodeB may prioritise the paging of UEs according to the Paging Priority
indications.
If the MME, while waiting for a UE response to the Paging Request message sent without Paging Priority
indication, receives an Update Bearer Request, Create Bearer Request or Downlink Data Notification, any of
which indicates an ARP priority level associated with MPS or other priority services, as configured by the
operator, the MME shall send another paging message with the suitable Paging Priority.
When the MME is configured to support CSG paging optimisation in the CN, the MME should avoid sending
Paging messages to those eNodeB(s) with CSG cells for which the UE does not have a CSG subscription. When
the MME is configured to support CSG paging optimisation in the HeNB Subsystem, the list of CSG IDs for
paging is included in the Paging message. For CSG paging optimisation, the CSG IDs of expired CSG
subscriptions and valid CSG subscriptions are both included in the list. If the UE has emergency bearer service
the MME shall not perform the CSG paging optimisation.
NOTE 4: An expired CSG subscription indicates that the UE is not allowed service in the CSG. However, since the
removal of the CSG from the UE is pending, it is possible the UE will camp on that CSG and therefore
the UE is still paged for the CSG.
NOTE 5: The eNodeB reports to the MME the CSG ID supported. For More detail of this procedure refer to
TS 36.413 [36].
When the MME supports SIPTO at Local Network and LIPA paging for traffic arriving on the PDN connection
with L-GW function collocated with the (H)eNB the MME should only page this (H)eNB to avoid sending
Paging messages to eNodeB(s) that are not handling this specific PDN connection.
Paging strategies may be configured in the MME for different combinations of APN, Paging Policy Indication
from SGW when available (see clause 4.9) and other EPS bearer context information e.g. QCI. APN and any
EPS bearer context information are identified by EPS bearer ID received in Downlink Data Notification. Paging
strategies may include:
- paging retransmission scheme (e.g. how frequently the paging is repeated or with what time interval);
- determining whether to send the Paging message to the eNodeBs during certain MME high load conditions;
- whether to apply sub-area based paging (e.g. first page in the last known ECGI or TA and retransmission in
all registered TAs).
If extended idle mode DRX was enabled in the UE, the MME may additionally take into account the Paging
Time Window length for paging retransmission schemes.
3GPP
Release 15 183 3GPP TS 23.401 V15.10.0 (2019-12)
NOTE 6: The Paging priority in the Paging message is set based on priority level of the ARP IE received in
Downlink Data Notification or Create/Update Bearer Request message and is independent from any
paging strategy.
The MME and the E-UTRAN may support further paging optimisations in order to reduce the signalling load
and the network resources used to successfully page a UE by one or several following means:
- by the MME implementating specific paging strategies (e.g. the S1 Paging message is sent to the eNB that
served the UE last);
- by the MME considering Information On Recommended Cells And ENBs provided by the E-UTRAN at
transition to ECM IDLE. The MME takes the eNB related part of this information into account to determine
the eNBs to be paged, and provides the information on recommended cells within the S1 Paging message to
each of these eNBs;
- by the E-UTRAN considering the Paging Attempt Count Information provided by the MME at paging.
When implementing such optimisations/strategies, the MME shall take into account any PSM active timer and
the DRX interval for the UE.
If the UE Radio Capability for Paging Information is available in the MME for the RAT corresponding to the
TAI(s) in the S1 Paging message, the MME shall add the UE Radio Capability for Paging Information for that
RAT in the S1 Paging message to the eNB.
If the Information On Recommended Cells And ENBs For Paging is available in the MME, the MME shall take
that information into account to determine the eNBs for paging and, when paging an eNB, the MME may
transparently convey the information on recommended cells to the eNB.
The MME may include in the S1AP Paging message(s) the paging attempt count information. The paging
attempt count information shall be the same for all eNBs selected by the MME for paging.
If the MME has Information for Enhanced Coverage stored and Enhanced Coverage is not restricted then the
MME shall include Information for Enhanced Coverage in the Paging message for all eNBs selected by the
MME for paging. For including the Enhanced Coverage Restricted parameter in the paging message, see
clause 4.3.28.
For including the CE mode B Restricted parameter in the Paging message, see clause 4.3.27a.
3b. If the UE is registered in the SGSN, the SGSN sends paging messages to RNC/BSS, which is described in detail
in TS 23.060 [7].
4a. If eNodeBs receive paging messages from the MME, the UE is paged by the eNodeBs. The step is described in
detail in TS 36.300 [5] and TS 36.304 [34].
4b. If RNC/BSS nodes receive paging messages from the SGSN the UE is paged by the RNSC/BSS, which is
described in detail in TS 23.060 [7].
5. When UE is in the ECM-IDLE state, upon reception of paging indication in E-UTRAN access, the UE initiates
the UE triggered Service Request procedure (clause 5.3.4.1) or, if the UE is enabled to use User Plane CIoT EPS
Optimisation and there is suspended access stratum context stored in the UE, the UE initiates the Connection
Resume procedure (clause 5.3.5A). If the MME already has a signalling connection over S1-MME towards the
UE but the S1-U tunnel has not yet been established, then the messages sequence performed start from the step
when MME establishes the bearer(s).
Upon reception of paging indication in UTRAN or GERAN access, the MS shall respond in respective access as
specified TS 24.008 [47] and the SGSN shall notify the S-GW.
The MME and/or SGSN supervises the paging procedure with a timer. If the MME and/or SGSN receives no
response from the UE to the Paging Request message, it may repeat the paging according to any applicable
paging strategy described in step 2.
If the MME and/or SGSN receives no response from the UE after this paging repetition procedure, it shall use
the Downlink Data Notification Reject message to notify the Serving GW about the paging failure, if paging was
triggered by a Downlink Data Notification message, unless the MME or SGSN is aware of an ongoing MM
procedure that prevents the UE from responding, i.e. the MME or SGSN received a Context Request message
3GPP
Release 15 184 3GPP TS 23.401 V15.10.0 (2019-12)
indicating that the UE performs TAU or RAU procedure with another MME or SGSN. If paging was triggered
by control signalling from the Serving GW and if the MME or SGSN receives no response from the UE after this
paging repetition procedure, the MME or SGSN shall reject that control signalling. When a Downlink Data
Notification Reject message is received, if ISR is not activated, the Serving GW deletes the buffered packet(s). If
ISR is activated and the Serving GW receives Downlink Data Notification Reject message from both SGSN and
MME, the Serving GW deletes the buffered packet(s) or rejects the control signalling which triggers the Service
Request procedure. The Serving GW may invoke the procedure PDN GW Pause of Charging (clause 5.3.6A) if
UE is in ECM IDLE and the PDN GW has enabled "PDN charging pause" feature.
NOTE 7: The Serving GW may initiate the procedure PDN GW Pause of Charging at any time before step 5 if the
UE is in ECM IDLE and the PDN GW has indicated that the feature is enabled for this PDN. See
clause 5.3.6A.
6a. If ISR is activated and paging response is received in E-UTRAN access the Serving GW sends a "Stop Paging"
message to the SGSN.
6b. If ISR is activated and paging response is received in UTRAN or GERAN access the Serving GW sends a "Stop
Paging" message to the MME.
The Serving GW transmits downlink data towards the UE via the RAT which performed the Service Request procedure.
For a LIPA PDN connection, after the UE enters connected mode, the packets buffered in the L-GW are forwarded to
the HeNB on the direct path. If the UE enters connected mode at a different cell than the one where the L-GW is
colocated, the MME shall deactivate the LIPA PDN connection as defined in clause 5.3.4.1 step 2.
If the network triggered service request fails due to no response from the UE, then MME and/or SGSN may based on
operator policy initiate the Dedicated Bearer Deactivation procedure for preserved GBR bearers. For details, see
clause 5.4.4.2 for MME and TS 23.060 [7] for SGSN.
5.3.4A Connection Suspend procedure

This procedure is used by the network to suspend the connection if the UE and the network support User Plane CIoT
EPS Optimisation (see TS 36.300 [5]).
tion
UE eNodeB MME Serving GW PDN GW
1. S1-AP: UE Context Suspend Request

1a. Change Notification
1b. Change Notification
1c. Change Notification Ack

1d. Change Notification Ack
2. Release Access Bearers Request
3. Release Access Bearers Response

4. S1-AP: UE Context Suspend Response
5. RRC Connection Suspend
Figure 5.3.4A-1: eNodeB initiated Connection Suspend procedure
1. The eNodeB initiates the Connection Suspend procedure to the MME, see TS 36.413 [36]. The eNodeB indicates
to the MME that the UE's RRC connection is to be suspended upon which MME enters ECM-IDLE. Data related
to the S1AP association, UE Context and bearer context, necessary to resume the connection is kept in the eNB,
UE and the MME.
The eNodeB may include the Information On Recommended Cells And eNBs For Paging in the S1 UE Context
Suspend Request message. If available, the MME shall store this information to be used when paging the UE.
3GPP
Release 15 185 3GPP TS 23.401 V15.10.0 (2019-12)
The eNB includes Information for Enhanced Coverage, if available, in the S1 UE Context Suspend Request
message.
If the PLMN has configured secondary RAT reporting and the eNodeB has Secondary RAT usage data to report,
the Secondary RAT usage data is included.
If Dual Connectivity was activated by that eNodeB at the time of the Connection Suspend or earlier by that
eNodeB, the eNodeB shall include the last known PSCell ID and the time elapsed since the Dual Connectivity
was released.
If Service Gap Control is being applied to the UE (see clause 4.3.17.9) and the Service Gap timer is not already
running, the Service Gap timer shall be started in the MME when entering ECM-IDLE, unless the connection
was initiated after a paging of an MT event, or after a TAU procedure without any active flag or signalling active
flag set.
1a-d. If the eNodeB provided Secondary RAT usage data in step 1 and if PGW secondary RAT usage data
reporting is active, the MME initiates the Secondary RAT usage data reporting procedure in clause 5.7A.3 as
illustrated in figure 5.7A.3-2.
2. The MME sends a Release Access Bearers Request (Secondary RAT usage data) message to the Serving GW
that requests the release of all S1-U bearers for the UE. If Secondary RAT usage data was received in step 1,
Secondary RAT usage data is included in this message. The message indicates that the SGW is the target for the
reporting.
3. The Serving GW releases all eNodeB related information (address and downlink TEIDs) for the UE and
responds with a Release Access Bearers Response message to the MME. Other elements of the UE's Serving
GW context are not affected. If downlink packets arrive for the UE, the Serving GW starts buffering downlink
packets received for the UE and initiating the "Network Triggered Service Request" procedure, described in
clause 5.3.4.3.
NOTE: Based on operator policy any received Indication of "Abnormal Release of Radio Link" may be used by
Serving GW in subsequent decisions to trigger PDN charging pause if the feature has been enabled on
that PDN.
The Serving GW informs the MME in the Release Access Bearer Response message about release of S1-U
bearers.
4. The MME sends an S1AP: UE Context Suspend Response message to the eNB to successfully terminate the
Connection Suspend procedure initiated by the eNB, see TS 36.413 [36].
5. The eNodeB sends RRC message to suspend the RRC Connection towards the UE, see TS 36.300 [5]).
If Service Gap Control is being applied for the UE (see clause 4.3.17.9) and the Service Gap timer is not already
running, the Service Gap timer shall be started in the UE when entering ECM-IDLE, unless the connection was
initiated as a response to paging of an MT event, or after a TAU procedure without any active flag or signalling
active flag set.
5.3.4B Data Transport in Control Plane CIoT EPS Optimisation
5.3.4B.1 General
If the UE and MME use the Control Plane CIoT EPS Optimisation, they can transfer data in NAS PDUs including the
EPS Bearer Identity of the PDN connection they relate to, for which there is no S1-U bearers established (i.e. when an
S1-U bearer is established the UE shall use S1-U to transfer data PDUs). Both the IP and Non IP data types are
supported. If the UE and the MME support Control Plane CIoT EPS Optimisation, then for SMS transfer and EPC
Mobile Originated Location Request (EPC-MO-LR) or EPC Mobile Terminated Location Request (EPC-MT-LR) the
Service Request procedures defined in clause 5.3.4 are not used for MO and MT SMS or for EPC-MO-LR and EPC-
MT-LR, but instead UE and MME shall be using the Data Transport in Control Plane CIoT EPS Optimisation.
This is accomplished by using the NAS transport capabilities of RRC and S1-AP protocols and the data transport of
GTP-u tunnels between MME and S-GW and between S-GW and P-GW, or if a Non-IP connection is provided by via
the MME with the SCEF, then data transfer occurs as indicated in TS 23.682 [74].
3GPP
Release 15 186 3GPP TS 23.401 V15.10.0 (2019-12)
For IP data, the UE and MME may perform header compression based on ROHC framework IETF RFC 5795 [77]. For
uplink IP data, UE implements ROHC compressor, and MME implements the decompressor. For downlink IP data,
MME implements the ROHC compressor, and UE implements the decompressor. The uplink and downlink ROHC
channels are bound by UE and MME to support feedback. The configurations for the header compression are
established during the PDN connection establishment procedure.
To minimise potential conflicts between NAS signalling PDUs and NAS Data PDUs, the MME should complete any
security related procedures (e.g. Authetication, Security Mode Command, GUTI reallocation) before alerting the HSS,
MSC or SGW of the UE's entry into ECM-CONNECTED state, and before commencing downlink transfer of NAS
Data PDUs. The priority handling between the EMM/ESM NAS signalling PDUs and NAS Data PDUs is specified in
TS 24.301 [46].
5.3.4B.2 Mobile Originated Data Transport in Control Plane CIoT EPS Optimisation
with P-GW connectivity
UE eNodeB MME S-GW P-GW
0. UE is ECM
Idle
1. RRC Connection establishment or

RRC early data request (NAS DATA PDU
with EBI)
1b. Retrieve UE context
2. S1-AP Initial UE Message (NAS

Data PDU with EBI)
3. Check Integrity and

decrypts data

8. Uplink data 8. Uplink data
9. Downlink data 9. Downlink data
10. Data encryption

and Integrity
protection
11. Downlink S1-AP msg.
11. S1-AP UE context release

command
12a. RRC DL Message (NAS data PDU with

EBI)
12b. RRC Early Data Complete (NAS data

PDU with EBI)
13. NAS Delivery notification
14. No further
activity detected
15. S1 release procedure (see clause 5.3.5)
Figure 5.3.4B.2-1: MO Data transport in NAS PDU
0. The UE is ECM-IDLE.
1. The UE establishes a RRC connection or sends the RRCEarlyDataRequest message as defined in TS 36.300 [5]
and sends as part of it an integrity protected NAS PDU. The NAS PDU carries the EPS Bearer ID and encrypted
Uplink Data. For IP PDN type PDN connections configured to support Header Compression, the UE shall apply
header compression before encapsulating data into the NAS message. The UE may also indicate in a NAS
Release Assistance Information in the NAS PDU whether no further Uplink or Downlink Data transmissions are
expected, or only a single Downlink data transmission (e.g. Acknowledgement or response to Uplink data)
subsequent to this Uplink Data transmission is expected.
3GPP
Release 15 187 3GPP TS 23.401 V15.10.0 (2019-12)
1b. In the NB-IoT case, the eNB, based on configuration, may retrieve the EPS negotiated QoS profile from the
MME, if not previously retrieved. The MME Code within the S-TMSI in the RRCConnectionRequest message is
used to identify the MME. In the case of network sharing, the MME Codes shall be unique within the area of
overlapping MME pools of the participating operators. The eNB may apply prioritisation between requests from
different UEs before triggering step 2 and throughout the RRC connection. The eNB may retrieve additional
parameters (e.g., UE Radio Capabilities - see TS 36.413 [36]).
2. The NAS PDU sent in step 1 is relayed to the MME by the eNodeB using a S1-AP Initial UE message. If the
RRCEarlyDataRequest message was received in step 1, the eNB includes the "EDT Session" indication in the
S1-AP Initial UE message.
If the NAS Release Assistance Information is received from the UE it overrides the Traffic Profile (see
TS 23.682 [74]) and the MME does not send the Traffic Profile to the eNB.
3. If there is a Service Gap timer running in the MME MM Context for the UE and the MME is not waiting for a
MT paging response from the UE, the MME rejects the request by discarding the NAS data PDU and sending a
Service Reject message to the UE with an appropriate cause. The MME may also provide UE with a Mobility
Management Back-off timer set to the remaining value of Service Gap timer, followed by executing step 15.
The MME checks the integrity of the incoming NAS PDU and decrypts the data it contains. When the ROHC is
configured to be used, the MME shall decompress the IP header if header compression applies to the PDN
connection.
The MME performs (and the UE responds to) any EMM or ESM procedures if necessary, e.g. the security
related procedures. Steps 4 to 9 can continue in parallel to this, however, steps 10 and 11 shall await completion
of all the EMM and ESM procedures.
4a. If the S11-U connection is not established, the MME sends a Modify Bearer Request message (MME address,
MME TEID DL, Delay Downlink Packet Notification Request, RAT Type, LTE-M RAT type reporting to PGW
flag, MO Exception data counter) for each PDN connection to the Serving GW. The Serving GW is now able to
transmit downlink data towards the UE. The usage of the Delay Downlink Packet Notification Request
Information Element is specified in clause 5.3.4.2 with reference to the UE initiated service request procedure,
but it equally applies in this case. The MME shall indicate S11-U tunnelling of NAS user data and send its own
S11-U IP address and MME DL TEID for DL data forwarding by the SGW. Also, regardless of whether the S11-
U was already established:
- If the PDN GW requested UE's location and/or User CSG information and the UE's location and/or User
CSG information has changed, the MME shall send the Modify Bearer Request message and also includes
the User Location Information IE and/or User CSG Information IE in this message.
- If the Serving Network IE has changed compared to the last reported Serving Network IE then the MME
shall send the Modify Bearer Request message and also includes the Serving Network IE in this message.
- If the UE Time Zone has changed compared to the last reported UE Time Zone then the MME shall send the
Modify Bearer Request message and include the UE Time Zone IE in this message.
If the RAT type currently used is NB-IOT this shall be reported as different from other E-UTRA flavours.
The MME only includes MO Exception data counter if the RRC establishment cause is set to "MO exception
data" and the UE is accessing via the NB-IoT RAT. The Serving GW indicates each use of this RRC
establishment cause by the related counter on its CDR. The MME maintains the MO Exception Data Counter for
Serving PLMN Rate Control purposes (see clause 4.7.7.2). The MME may immediately send the MO Exception
Data Counter to the Serving GW. Alternatively, in order to reduce signalling, the MME may send the MO
Exception Data Counter to the Serving GW as indicated in TS 29.274 [43].
4b If the S11-U connection is established and the UE is accessing via the NB-IoT RAT with the RRC establishment
cause set to "MO exception data", the MME should notify the Serving Gateway. The MME maintains the MO
Exception Data Counter for Serving PLMN Rate Control purposes (see clause 4.7.7.2). The MME may
3GPP
Release 15 188 3GPP TS 23.401 V15.10.0 (2019-12)
immediately send the MO Exception Data Counter to the Serving GW. Alternatively, in order to reduce
signalling, the MME may send the MO Exception Data Counter to the Serving GW as indicated in
TS 29.274 [43].
and/or UE Time Zone and Serving Network id are present in step 4, the Serving GW shall send the Modify
Bearer Request message (RAT Type, MO Exception data counter) to the PDN GW. User Location Information
IE and/or User CSG Information IE and/or Serving Network IE and/or UE Time Zone are also included if they
are present in step 4.
If LTE-M RAT type and the LTE-M RAT type reporting to PGW flag were received at step 4a, the Serving GW
paused, then the SGWS-GW shall send a Modify Bearer Request message with PDN Charging Pause Stop
Indication to inform the PDN GW that the charging is no longer paused. Other IEs are not included in this
message.
If the Modify Bearer Request message is not sent because of above reasons but the MME indicated MO
Exception data counter, then the Serving Gateway should notify the PDN GW that this RRC establishment cause
has been used by the indication of the MO Exception Data Counter (see TS 29.274 [43]). The Serving GW
indicates each use of this RRC establishment cause by the related counter on its CDR.
The PDN GW indicates each use of the RRC establishment cause "MO Exception Data" by the related counter
on its CDR.
7. If a Modify Bearer Request message was sent at step 4 the Serving GW shall return a Modify Bearer Response
(Serving GW address and TEID for uplink traffic) to the MME as a response to a Modify Bearer Request
message. The Serving GW address for S11-U User Plane and Serving GW TEID are used by the MME to
forward UL data to the SGW.
8. The MME sends Uplink data to the P-GW via the S-GW.
9. If no Downlink Data are expected based on the NAS Release Assistance Information from the UE in step 1, this
means that all application layer data exchanges have completed with the UL data transfer, and if the MME is not
aware of pending MT traffic and S1-U bearers are not established, step 10 is skipped and step 11 applies.
Otherwise, Downlink data may arrive at the P-GW and the P-GW sends them to the MME via the S-GW. If no
data is received steps10-12 are skipped and the eNB may trigger step 14 after step 13 detects no activity. While
the RRC connection is active, the UE may still send Uplink data and may receive Downlink data in NAS PDUs
that are carried in a S1AP Uplink or (respectively) Downlink messages (not shown in the figure). At any time the
UE has no user plane bearers established it may provide NAS Release Assistance Information with the Uplink
data. In this case, to assist Location Services, the eNB may indicate, if needed, the UE's Coverage Level to the
MME.
10. If Downlink data are received in step 9, the MME encrypts and integrity protects the Downlink data.
11. If step 10 is executed then Downlink data are encapsulated in a NAS PDU and sent to the eNB in a S1-AP
Downlink NAS Message. If the configuration in the MME indicates that the eNodeB supports
acknowledgements of downlink NAS data PDUs and if acknowledgements of downlink NAS data PDUs are
enabled in the subscription information for the UE, the MME indicates in the S1-AP Downlink NAS message
that acknowledgment is requested from the eNodeB. For IP PDN type PDN connections configured to support
Header Compression, the MME shall apply header compression before encapsulating data into the NAS
message. If step 10 is not executed, or NAS Service Accept message is not to be sent, the MME sends
Connection Establishment Indication message to the eNB to complete the establishment of the UE-associated
logical S1-connection. The UE Radio Capability may be provided from the MME to the eNB in the DL NAS
Transport message or Connection Establishment Indication message, and the eNB shall store the received UE
Radio Capability information as specified in TS 36.300 [5].
If the NAS Release Assistance Information was received with Uplink data and it indicated that Downlink data
was expected, it means that the next downlink packet following the sending of the NAS Release Assistance
3GPP
Release 15 189 3GPP TS 23.401 V15.10.0 (2019-12)
Information is the last packet of the application layer data exchange, then for this case, unless the MME is aware
of additional pending MT traffic and unless S1-U bearers are established, the MME sends a S1 UE Context
Release Command immediately after the S1-AP message including the Downlink data encapsulated in NAS
PDU as an indication that the eNodeB shall release the RRC connection promptly after successfully sending data
to the UE. Alternatively, if "EDT Session" indication was received in step 2, the MME may include End
Indication for no further data in the S1-AP message including the Downlink data encapsulated in NAS PDU. If
the MME includes the End Indication indicating no further data and if the eNB does not proceed with RRC
connection establishment, then the eNB skips step 12a and initiates step 12b.
If the NAS Release Assistance Information was received indicating no Downlink Data expected, it means that all
application layer data exchanges have completed with the UL data transfer, then for this case, unless the MME is
aware of additional pending MT traffic and unless S1-U bearers are established:
- the MME sends S1AP UE Context Release Command either:
- immediately after the S1AP DL NAS TRANSPORT (NAS Service Accept), in which case steps 12b and
14 are skipped, or
- immediately after S1AP CONNECTION ESTABLISHMENT INDICATION, in which case steps 12a,
12b, 13, and 14 are skipped.
- Alternatively, if the MME received "EDT Session" indication from the eNB in step 2, the MME should
include End Indication with no further data in S1AP DL NAS TRANSPORT (NAS Service Accept) or S1AP
CONNECTION ESTABLISHMENT INDICATION. If the eNB does not proceed with RRC connection
establishment, the eNB skips step 12a and initiates stop 12b.
If the UE is accessing via an NB-IoT cell, or if it is accessing via an WB-E-UTRAN cell and is capable of CE
mode B, to determine the NAS PDU retransmission strategy the MME should take into account the transmission
delay of the NAS PDU and the CE mode B Restricted parameter stored in the MME's MM context and, if
applicable, the CE mode, i.e. set the NAS timers long enough according to the worst transmission delay (see
TS 24.301 [46]).
12a. The eNB sends a RRC Downlink data message including the Downlink data encapsulated in NAS PDU. If in
step 11 the S1-AP message with the NAS DATA PDU was followed by an S1 UE Context Release Command,
step 15 is completed promptly after the Downlink Data transmission of the NAS PDU to the UE and the
acknowledgement to MME in step 13 have been completed at the eNB, and the eNB does not need to enter
step 14. If header compression was applied to the PDN, the UE would perform header decompression to rebuild
the IP header.
12b. If End Indication with no further data is received in S1AP message from the MME, the eNB may send the
RRCEarlyDataComplete message with any NAS payload received from step 11 (either NAS data PDU or NAS
service accept) as defined in TS 36.300 [5]. Step 14 is skipped in this case.
13. The eNodeB sends a NAS Delivery indication to the MME if requested. If the eNodeB reports an unsuccessful
delivery with an S1-AP NAS Non Delivery Indication, the MME should wait for some time until the UE has
potentially changed cell and re-established contact with the MME, by which MME should resend the Downlink
S1-AP message to the eNodeB, otherwise the MME reports an unsuccessful delivery to the SCEF in case of T6a
procedure (see TS 23.682 [74], clause 5.13.3). If the eNodeB reports a successful delivery with an S1-AP NAS
Delivery Indication and if the Downlink data was received over the T6a interface, the MME should respond to
the SCEF (see TS 23.682 [74], clause 5.13.3). If the eNodeB does not support S1-AP NAS delivery indications,
the MME indicates a cause code 'Success Unacknowledged Delivery' to the SCEF otherwise 'Success
Acknowledged Delivery', for the SCEF to know if reliable delivery was possible or not.
14. If no NAS PDU activity exists for a while, the eNB starts an S1 release in step 15.
15. An S1 release procedure according to clause 5.3.5 triggered by the eNodeB or MME. Alternatively, if the MME
in step 11 sent S1 UE Context Release Command then the procedure starts with step 5 in clause 5.3.5, or
Connection Suspend Procedure defined in clause 5.3.4A. The UE and the MME shall store the ROHC
configuration and context for the uplink/downlink data transmission when entering ECM_CONNECTED state
next time.
3GPP
Release 15 190 3GPP TS 23.401 V15.10.0 (2019-12)
5.3.4B.3 Mobile Terminated Data Transport in Control Plane CIoT EPS Optimisation
with P-GW connectivity
UE eNodeB MME S-GW P-GW
0.UE is ECM
idle
1. Downlink data
2. Downlink data Notification
2. Downlink data Notification ACK
3. Paging
4. Paging
5. RRC Connection establishment

(NAS Control Plane Service request) 5b. Retrieve UE context
6. S1-AP Initial UE Message (NAS

Control Plane Service request)
11. Downlink data
12. Data
encryption and
13. Downlink S1-AP msg Integrity protection
(NAS DATA PDU with EBI)
14. RRC DL msg (NAS PDU with data)
15. NAS Delivery notification
16. RRC UL msg (NAS PDU with data)

17. UL S1-AP msg
(NAS DATA PDU with EBI)
18. Check integrity and decrypts data)
19. Uplink data

19. Uplink data
20. No further activity
detected
21. S1 release procedure (see clause 5.3.5)
Figure 5.3.4B.3-1: MT Data transport in NAS PDUs
0. The UE is EPS attached and in ECM-Idle mode.
1. When the S-GW receives a downlink data packet/control signalling for a UE, if the S- GW context data indicates
no downlink user plane TEID towards the MME), it buffers the downlink data packet and identifies which MME
is serving that UE.
If that MME has requested the Serving GW to throttle downlink low priority traffic and if the downlink data
packet is received on a low priority bearer to be throttled (see clause 4.3.7.4.1a), the S-GW drops the downlink
data. The steps below are not executed.
If that MME has requested the S-GW to delay sending the Downlink Data Notification (see clause 5.3.4.2 on
"Handling of abnormal conditions in UE triggered Service Request"), the Serving GW buffers the downlink data
and waits until the timer expires before continuing with step 2. If the DL-TEID and MME address for that UE is
received before the expiry of the timer, the timer shall be cancelled and the Mobile Terminated Data transport
procedure is progressed from step 11 as Downlink data are sent to the UE.
If the Serving GW receives additional downlink data packets/control signalling for this UE before the expiry of
the timer, the Serving GW does not restart this timer.
2. If the Serving GW is buffering data in step 1, the Serving GW sends a Downlink Data Notification message
(ARP, EPS Bearer ID) to the MME for which it has control plane connectivity for the given UE. The ARP and
3GPP
Release 15 191 3GPP TS 23.401 V15.10.0 (2019-12)
EPS Bearer ID are always set in Downlink Data Notification. The MME responds to the S-GW with a Downlink
Data Notification Ack message.
An MME detects that the UE is in a power saving state (e.g. Power Saving Mode) and cannot be reached by
paging at the time of receiving Downlink data notification, shall invoke extended buffering depending on
operator configuration, except for cases described in next paragraphs. The MME derives the expected time
before radio bearers can be established to the UE. The MME then indicates Downlink Buffering Requested to
the Serving GW in the Downlink Data Notification Ack message and includes a Downlink Buffering Duration
time and optionally a Downlink Buffering Suggested Packet Count. The MME stores a new value for the
Downlink Data Buffer Expiration Time in the MM context for the UE based on the Downlink Buffering
Duration time and skips the remaining steps of this procedure. The Downlink Data Buffer Expiration Time is
used for UEs using power saving state and indicates that there are buffered data in the Serving GW and that the
user plane setup procedure is needed when the UE makes signalling with the network. When the Downlink Data
Buffer Expiration Time has expired, the MME considers no Downlink data to be buffered and no indications of
Buffered Downlink Data Waiting are sent during context transfers at TAU procedures.
If there is an "Availability after DDN Failure" monitoring event configured for the UE in the MME, the MME
does not invoke extended buffering. Instead, the MME sets the Notify-on-available-after-DDN-failure flag to
remember to send an "Availability after DDN Failure" notification when the UE becomes available. If there is a
"UE Reachability" monitoring event configured for the UE in the MME, the MME does not invoke extended
buffering.
NOTE 1: When "Availability after DDN failure" and "UE reachability" monitoring events are used for a UE, the
application server is assumed to send data only when the UE is reachable, hence no extended buffering is
needed. If there are multiple application servers, the event notifications and extended buffering may be
needed simultaneously. It is assumed this is handled through additional information based on SLA as
described in the next paragraph.
The MME may use additional information based on a SLA with the MTC user for when to invoke extended
buffering, e.g. only invoke it for a certain APN, do not invoke it for certain subscribers, invoke extended
buffering in conjunction with "Availability after DDN failure" and "UE reachability" monitoring events, etc.
A Serving GW that receives a Downlink Buffering Requested indication in a Downlink Data Notification Ack
message stores a new value for the Downlink Data Buffer Expiration Time based on the Downlink Buffering
Duration time and does not send any additional Downlink Data Notification if subsequent downlink data packets
are received in the Serving GW before the buffer time Downlink Data Buffer Expiration Time has expired for
the UE.
If the Serving GW, while waiting for the user plane to be established, is triggered to send a second Downlink
Data Notification for a bearer with higher priority (i.e. ARP priority level) than that of the bearer for which the
first Downlink Data Notification was sent, the S-GW sends a new Downlink Data Notification message
indicating the higher priority to the MME. If the Serving GW receives additional downlink data packets for a
bearer with same or lower priority than the first Downlink Data Notification was sent for or if the Serving GW
has sent the second Downlink Data Notification message indicating the higher priority and receives additional
downlink data packets for this UE, the Serving GW buffers these downlink data packets and does not send a new
Downlink Data Notification.
If the Serving GW, while waiting for the user plane to be established, receives a Modify Bearer Request message
from an MME other than the one it sent a Downlink Data Notification message to, the Serving GW re-sends the
Downlink Data Notification message but only to the new MME from which it received the Modify Bearer
Request message.
arrival of downlink data packets at the Serving GW, the Serving GW may start a locally configured guard timer
and buffers all downlink user packets received to the given UE and waits for a Modify Bearer Request message
to come. Upon reception of a Modify Bearer Request message, the Serving GW re-sends the Downlink Data
Notification message but only to the new MME from which it received the Modify Bearer Request message.
Otherwise the Serving GW releases buffered downlink user packets upon expiry of the guard timer or upon
receiving the Delete Session Request message from MME.
3GPP
Release 15 192 3GPP TS 23.401 V15.10.0 (2019-12)
If the S11-U is already established (buffering is in the MME), step 2 is not executed and step 11 is immediately
executed. Steps 7,8,9,10 are executed only if conditions are met when the NAS control plane service request is
received at step 6, as outlined below in the respective clauses.
An MME detecting that the UE is in a power saving state (e.g. Power Saving Mode) and cannot be reached by
paging at the time of receiving Downlink data, shall start extended buffering depending on operator
configuration, except for cases described in next paragraphs. The MME derives the expected time before radio
bearers can be established to the UE, stores a new value for the Downlink Data Buffer Expiration Time in the
MM context for the UE and skips the remaining steps of this procedure. When the Downlink Data Buffer
Expiration Time has expired, the MME considers no Downlink data to be buffered.
Also for the case of buffering in the MME the "Availability after DDN Failure" monitoring event can be
configured for the UE, even though the actual DDN is not received and the Downlink data is received. The "UE
Reachability" monitoring event can be configured.also. The extended buffering can also be configured as per
what is described above in this step of the procedure for the case of buffering in S-GW.
3. If the UE is registered in the MME and considered reachable, the MME sends a Paging message (NAS ID for
paging, TAI(s), UE identity based DRX index, Paging DRX length, list of CSG IDs for paging, Paging Priority
indication, Enhanced Coverage Restricted, CE mode B Restricted) to each eNodeB belonging to the tracking
area(s) in which the UE is registered.
Paging priority indication is included only:
- if the MME receives a Downlink Data Notification (or a Downlink packet for a EPS bearer, for the case of
buffering in MME) with an ARP priority level associated with priority services, as configured by the
operator.
- One Paging Priority level can be used for multiple ARP priority level values. The mapping of ARP priority
level values to Paging Priority level (or levels) is configured by operator policy.
During a congestion situation the eNodeB may prioritise the paging of UEs according to the Paging Priority
indications.
If the MME, while waiting for a UE response to the Paging Request message sent without Paging Priority
indication, receives a Downlink Data Notification (or a Downlink packet for a EPS bearer, for the case of
buffering in MME) which indicates an ARP priority level associated with priority services, as configured by
the operator, the MME shall send another paging message with the suitable Paging Priority.
When the MME is configured to support CSG paging optimisation in the CN, the MME should avoid sending
Paging messages to those eNodeB(s) with CSG cells for which the UE does not have a CSG subscription.
When the MME is configured to support CSG paging optimisation in the HeNB Subsystem, the list of CSG
IDs for paging is included in the Paging message. For CSG paging optimisation, the CSG IDs of expired
CSG subscriptions and valid CSG subscriptions are both included in the list. If the UE has emergency bearer
service the MME shall not perform the CSG paging optimisation.
NOTE 2: An expired CSG subscription indicates that the UE is not allowed service in the CSG. However, since the
removal of the CSG from the UE is pending, it is possible the UE will camp on that CSG and therefore
the UE is still paged for the CSG.
NOTE 3: The eNodeB reports to the MME the CSG ID supported. For More detail of this procedure refer to
TS 36.413 [36].
Paging strategies may be configured in the MME. Paging strategies may include:
- paging retransmission scheme (e.g. how frequently the paging is repeated or with what time interval);
- determining whether to send the Paging message to the eNodeBs during certain MME high load conditions;
- whether to apply sub-area based paging (e.g. first page in the last known ECGI or TA and retransmission in
all registered TAs).
NOTE 4: The Paging priority in the Paging message is set based on priority level of the ARP IE received in
Downlink Data Notification or Create/Update Bearer Request message and is independent from any
paging strategy.
3GPP
Release 15 193 3GPP TS 23.401 V15.10.0 (2019-12)
The MME and the E-UTRAN may support further paging optimisations in order to reduce the signalling load
and the network resources used to successfully page a UE by one or several following means:
- by the MME implementating specific paging strategies (e.g. the S1 Paging message is sent to the eNB that
served the UE last);
- by the MME considering Information On Recommended Cells And eNodeBs provided by the E-UTRAN at
transition to ECM IDLE. The MME takes the eNB related part of this information into account to determine
the eNBs to be paged, and provides the information on recommended cells within the S1 Paging message to
each of these eNBs;
- by the E-UTRAN considering the Paging Attempt Count Information provided by the MME at paging.
When implementing such optimisations/strategies, the MME shall take into account any PSM active timer and
the DRX interval for the UE.
If the UE Radio Capability for Paging Information is available in the MME for the RAT corresponding to the
TAI(s) in the S1 Paging message, the MME shall add the UE Radio Capability for Paging Information for that
RAT in the S1 Paging message to the eNB.
If the Information on Recommended Cells And ENBs For Paging is available in the MME, the MME shall take
that information into account to determine the eNBs for paging and, when paging an eNB, the MME may
transparently convey the information on recommended cells to the eNB.
The MME may include in the S1AP Paging message(s) the paging attempt count information. The paging
attempt count information shall be the same for all eNBs selected by the MME for paging.
If the MME has Information for Enhanced Coverage stored and Enhanced Coverage is not restricted then the
MME shall include Information for Enhanced Coverage in the Paging message for all eNBs selected by the
MME for paging. For including the Enhanced Coverage Restricted parameter in the paging message, see
clause 4.3.28.
For including the CE mode B Restricted parameter in the Paging message, see clause 4.3.27a.
4. If eNodeBs receive paging messages from the MME, the UE is paged by the eNodeBs.
5. As the UE is in the ECM-IDLE state, upon reception of paging indication, the UE sends Control Plane Service
Request NAS message (as defined in TS 24.301 [46]) over RRC Connection request and S1-AP initial message.
The Control Plane Service Request NAS message, when Control Plane CIoT EPS Optimisation applies, does not
trigger Data radio bearer establishment by the MME and the MME can immediately send Downlink Data it
receives using a NAS PDU to the eNodeB. The MME supervises the paging procedure with a timer. If the MME
receives no response from the UE to the Paging Request message, it may repeat the paging according to any
applicable paging strategy described in step 3.
5b. In the NB-IoT case, the eNB, based on configuration, may retrieve the EPS negotiated QoS profile from the
MME, if not previously retrieved. The MME Code within the S-TMSI in the RRCConnectionRequest message is
used to identify the MME. In the case of network sharing, the MME Codes shall be unique within the area of
overlapping MME pools of the participating operators. The eNB may apply prioritisation between requests from
different UEs before triggering step 6 and throughout the RRC connection. The eNB may retrieve additional
parameters (e.g., UE Radio Capabilities - see TS 36.413 [36]).
6. If the MME receives no response from the UE after this paging repetition procedure, it shall use the Downlink
Data Notification Reject message to notify the Serving GW about the paging failure (or, equivalently, if the
buffering is in the MME, the MME simply discards data for the UE locally), unless the MME is aware of an
ongoing MM procedure that prevents the UE from responding, i.e. the MME received a Context Request
message indicating that the UE performs TAU with another MME. When a Downlink Data Notification Reject
message is received, the Serving GW deletes the buffered packet(s). The Serving GW may invoke the procedure
PDN GW Pause of Charging (clause 5.3.6A) if UE is in ECM IDLE and the PDN GW has enabled "PDN
charging pause" feature. If buffering is in the MME, Pause Charging is triggered by the MME via a Release
Access Bearer Request to the S-GW(not shown in Figure 5.3.4B.3-1) including a "Abnormal Release of Radio
Link" cause , which releases the S11-U.
3GPP
Release 15 194 3GPP TS 23.401 V15.10.0 (2019-12)
NOTE 5: The Serving GW (or MME, in the case of buffering in the MME) may initiate the procedure P-GW Pause
of Charging at any time before step 5 if the UE is in ECM IDLE and the P-GW has indicated that the
feature is enabled for this PDN. See clause 5.3.6A.0.
The MME performs (and the UE responds to) any EMM or ESM procedures if necessary, e.g. the security
related procedures. Steps 7 to 11 can continue in parallel to this, however, steps 12 and 13 shall await completion
of all the EMM and ESM procedures.
7. If the S11-U is not established, the MME sends a Modify Bearer Request message (MME address, MME TEID
DL, Delay Downlink Packet Notification Request, RAT Type, LTE-M RAT type reporting to PGW flag) for
each PDN connection to the Serving GW. The Serving GW is now able to transmit downlink data towards the
UE. The usage of the Delay Downlink Packet Notification Request Information Element is specified in
clause 5.3.4.2 with reference to the UE initiated service request procedure, but it equally applies in this case. The
MME shall indicate S11-U tunnelling of NAS user data and send its own S11-U IP address and MME DL TEID
for DL data forwarding by the SGW. Also, regardless of whether the S11-U was already established:
- If the P-GW requested UE's location and/or User CSG information and the UE's location and/or User CSG
information has changed, the MME shall send the Modify Bearer Request message and also includes the
User Location Information IE and/or User CSG Information IE in this message.
- If the Serving Network IE has changed compared to the last reported Serving Network IE then the MME
shall send the Modify Bearer Request message and also includes the Serving Network IE in this message.
- If the UE Time Zone has changed compared to the last reported UE Time Zone then the MME shall send the
Modify Bearer Request message and include the UE Time Zone IE in this message.
If the RAT type currently used is NB-IOT this shall be reported as different from other -E-UTRA flavours.
and/or UE Time Zone and Serving Network id are present in step 7, the Serving GW shall send the Modify
Bearer Request message (RAT Type) to the P-GW. User Location Information IE and/or User CSG Information
IE and/or Serving Network IE and/or UE Time Zone are also included if they are present in step 7.
paused, then the S-GW shall send a Modify Bearer Request message with PDN Charging Pause Stop Indication
to inform the PDN GW that the charging is no longer paused. Other IEs are not included in this message.
10. If a Modify Bearer Request message was sent at step 7, the Serving GW shall return a Modify Bearer Response
(Serving GW address and TEID for uplink traffic) to the MME as a response to a Modify Bearer Request
message. The Serving GW address for S11-U User Plane and Serving GW TEID are used by the MME to
forward UL data to the SGW.
11. Buffered (if S11-U was not established) Downlink data is sent by the S-GW to the MME.
12-13. The MME encrypts and integrity protects Downlink data and sends it to the eNodeB using a NAS PDU
carried by a Downlink S1-AP message. If the configuration in the MME indicates that the eNodeB supports
acknowledgements of downlink NAS data PDUs and if acknowledgements of downlink NAS data PDUs are
enabled in the subscription information for the UE, the MME indicates in the Downlink S1-AP message that
acknowledgment is requested from the eNodeB. For IP PDN type PDN connections configured to support
Header Compression, the MME shall apply header compression before encapsulating data into the NAS
message. Alternatively and if the MME decides that S1-U bearers need to be established in case the UE and
MME accept User Plane EPS Optimisation or S1-U data transfer, steps 4-12 from clause 5.3.4.1 are followed.
3GPP
Release 15 195 3GPP TS 23.401 V15.10.0 (2019-12)
If the UE is accessing via an NB-IoT cell, or if it is accessing via an WB-E-UTRAN cell and is capable of CE
mode B, to determine the NAS PDU retransmission strategy the MME should take into account the transmission
delay of the NAS PDU and the CE mode B Restricted parameter stored in the MME's MM context and, if
applicable, the CE mode, i.e. set the NAS timers long enough according to the worst transmission delay (see
TS 24.301 [46]).
14. The NAS PDU with data is delivered to the UE via a Downlink RRC message. This is taken by the UE as
implicit acknowledgment of the Service Request message sent in step 5. If header compression was applied, to
the PDN, the UE shall perform header decompression to rebuild the IP header.
15. The eNodeB sends a NAS Delivery indication to the MME if requested. If the eNodeB reports an unsuccessful
delivery with an S1-AP NAS Non Delivery Indication, the MME should wait for some time until the UE has
potentially changed cell and re-established contact with the MME, by which MME should resend the Downlink
S1-AP message to the eNodeB, otherwise the MME reports an unsuccessful delivery to the SCEF in case of T6a
procedure (see TS 23.682 [74], clause 5.13.3). If the eNodeB reports a successful delivery with an S1-AP NAS
Delivery Indication and if the Downlink data was received over the T6a interface, the MME should respond to
the SCEF (see TS 23.682 [74], clause 5.13.3). If the eNodeB does not support S1-AP NAS delivery indications,
the MME indicates a cause code 'Success Unacknowledged Delivery' to the SCEF otherwise 'Success
Acknowledged Delivery', for the SCEF to know if reliable delivery was possible or not.
16. While the RRC connection is still up, further Uplink and Downlink data can be transferred using NAS PDUs. In
step 17 an Uplink data transfer is shown using an Uplink RRC message encapsulating a NAS PDU with data. At
any time the UE has no user plane bearers established, the UE may provide a Release Assistance Information
with Uplink data in the NAS PDU.
For IP PDN type PDN connections configured to support Header Compression, the UE shall apply header
compression before encapsulating it into the NAS message.
17. The NAS PDU with data is send to the MME in a Uplink S1-AP message.
To assist Location Services, the eNB may indicate, if changed, the UE's Coverage Level to the MME.
If the Release Assistance Information is received from the UE it overrides the Traffic Profile (see
TS 23.682 [74]) and the MME does not send the Traffic Profile to the eNB.
18. The data is checked for integrity and decrypted. If header compression was applied to the PDN, the MME shall
perform header decompression to rebuild the IP header.
19. The MME sends Uplink data to the PDN GW via the S-GW and executes any action related to the presence of
Release Assistance Information as follows:
- for the case where the Release Assistance Information indicates there is no downlink data to follow the
uplink data then unless the MME is aware of pending MT traffic, and unless S1-U bearers exist, the MME
immediately releases the connection and therefore step 21 is executed.
- for the case where the Release Assistance Information indicates that downlink data will follow the uplink
transmission then unless the MME is aware of additional pending MT traffic and unless S1-U bearers exist,
the MME sends a S1 UE Context Release Command to the eNodeB immediately after the S1-AP message
including the Downlink data encapsulated in NAS PDU.
20. If no NAS activity exists for a while the eNB detects inactivity and executes step 21.
21. The eNB starts an eNodeB initiated S1 release procedure according to clause 5.3.5 or Connection Suspend
Procedure defined in clause 5.3.4A. The UE and the MME shall store the ROHC configuration and context for
the uplink/downlink data transmission when entering ECM_CONNECTED state next time.
3GPP
Release 15 196 3GPP TS 23.401 V15.10.0 (2019-12)
5.3.4B.4 Establishment of S1-U bearer during Data Transport in Control Plane CIoT
EPS Optimisation
UE eNodeB MME S-GW HSS P-GW
1. MO/MT Data Transport in Control Plane CIoT EPS optimisation
UE in
ECM_CONNECTED
2.Control Plane
Service Request 3. S1-AP: UL NAS Transport
(w/ active flag) (Control Plane Service Request
w/ active flag)
MME establishes
S1-U bearer(s)
4. Release Access Bearers
5.Release Access Bearers response
6. S1-AP: Init. Context Setup
Request
(Service Accept)
7. Radio bearers setup
8.Uplink data 8.Uplink data
9. S1-AP: Init. Context Setup Comp.

Figure 5.3.4B.4-1: Establishment of S1-U bearer during Data Transport in Control Plane CIoT EPS
Optimisation
UE or MME can use this procedure if the UE and MME successfully negotiate S1-U data transfer or User Plane CIoT
EPS Optimisation in addition to Control Plane CIoT EPS Optimisation based on the Preferred and Supported Network
Behaviour as defined in clause 4.3.5.10. The MME either because it has received the NAS message as defined in steps
2-3 or the MME decides that S1-U based data transfer is now preferred e.g. determined by the size of data transferred in
UL and DL using Control Plane CIoT EPS Optimisation triggers the establishment of S1-U bearer(s). The MME checks
if the UE can support the establishment of required number of additional user plane radio bearers based on the
maximum number of user plane radio bearers indicated by UE in the UE Network Capability IE as defined in
clause 5.11.3. If the MME takes the decision that S1-U data transfer is now preferred steps 2-3 are not needed.
1. UE is sending and receiving data in NAS PDUs using the Control Plane CIoT EPS Optimisation.
2. The UE may be triggered to establish user plane bearers and sends a Control Plane Service Request with an
active flag towards the MME encapsulated in an RRC message to the eNodeB. The RRC message and this NAS
message are described in TS 36.300 [5] and TS 24.301 [46] respectively.
3. The eNodeB forwards the Control Plane Service Request with active flag to MME. NAS message is
encapsulated in an S1-AP UL NAS Transport Message (NAS message, TAI+ECGI of the serving cell, S-TMSI,
CSG ID, CSG access Mode). Details of this step are described in TS 36.300 [5]. If the MME receives the
Control Plane Service Request with active flag defined in steps 2-3 it shall establish S1-U bearer(s) and execute
the transfer. If the MME cannot handle the procedure associated to the Control Plane Service Request with
active flag, it shall reject it. CSG ID is provided if the UE sends the NAS message via a CSG cell or a hybrid
cell. CSG access mode is provided if the UE sends the NAS message via a hybrid cell. If the CSG access mode
is not provided but the CSG ID is provided, the MME shall consider the cell as a CSG cell.If a CSG ID is
indicated and CSG access mode is not provided, and there is no subscription data for this CSG ID and associated
PLMN or the CSG subscription is expired, the MME rejects the Control Plane Service Request with an
appropriate cause. The UE shall remove the CSG ID and associated PLMN of the cell where the UE has initiated
the service request procedure from the Allowed CSG list, if present.
4. The MME shall send any remaining UL data over S11-U and in order to minimize the possible occurrence of out
of order DL data e.g. caused by earlier DL data which were sent on the Control Plane may send a Release Access
Bearers Request message to the Serving GW that requests the release of all S11-U bearers for the UE. The MME
locally deletes any existing ROHC context used for Control Plane CIoT EPS Optimisation, and other S11-U
3GPP
Release 15 197 3GPP TS 23.401 V15.10.0 (2019-12)
related information in UE context, including TEID (DL) for the S11-U, etc, but not the Header Compression
Configuration.
NOTE: The MME may use the "Delay Downlink Packet Notification Request" causing the Serving GW to not
send Downlink Data Notifications as described in clause 5.3.4.2 to minimize the impact of possible
Downlink Data Notifications this step may cause.
5. If the Serving GW receives the Release Access Bearers Request message it releases all MME related information
(address and downlink TEIDs) for the UE and responds with a Release Access Bearers Response message to the
MME. Other elements of the UE's Serving GW context are not affected. If downlink packets arrive for the UE,
the Serving GW starts buffering downlink packets received for the UE and initiating the "Network Triggered
Service Request" procedure, described in clause 5.3.4.3.
6. The MME sends S1-AP Initial Context Setup Request (Serving GW address, S1-TEID(s) (UL), EPS Bearer
QoS(s), Security Context, MME Signalling Connection Id, Handover Restriction List, CSG Membership
Indication, Service Accept) message to the eNodeB for all PDN connections that MME has not included Control
Plane Only Indicator in ESM request. The MME responds to the UE with a Service Accept message. The
eNodeB stores the Security Context, MME Signalling Connection Id, EPS Bearer QoS(s) and S1-TEID(s) in the
UE RAN context. The step is described in detail in TS 36.300 [5]. Handover Restriction List is described in
clause 4.3.5.7 "Mobility Restrictions".
7. If the Control Plane Service Request is performed via a hybrid cell, CSG Membership Indication indicating
whether the UE is a CSG member shall be included in the S1-AP message from the MME to the RAN. Based on
this information the RAN can perform differentiated treatment for CSG and non-CSG members. The eNodeB
performs the radio bearer establishment procedure. The user plane security is established at this step, which is
described in detail in TS 36.300 [5]. The UE needs to locally delete any existing ROHC context used for Control
Plane CIoT EPS Optimisation. When the user plane radio bearers are setup, EPS bearer state synchronization is
performed between the UE and the network, i.e. the UE shall locally remove any EPS bearer for which the MME
has not included Control Plane Only Indicator in ESM request and for which no radio bearers are setup. If the
radio bearer for a default EPS bearer is not established, the UE shall locally deactivate all EPS bearers associated
to that default EPS bearer.
8. As the user plane radio bearers are setup the UE shall use user plane bearers to transfer data PDUs, except for
EPS bearers the MME has included Control Plane Only Indicator in ESM request and for which Control Plane
CIoT EPS Optimisation is still be used. The uplink data from the UE can now be forwarded by eNodeB to the
Serving GW. The eNodeB sends the uplink data to the Serving GW address and TEID provided in the step 6.
The Serving GW forwards the uplink data to the PDN GW.
9. The eNodeB sends an S1-AP message Initial Context Setup Complete (eNodeB address, List of accepted EPS
bearers, List of rejected EPS bearers, S1 TEID(s) (DL)) to the MME. This step is described in detail in
TS 36.300 [5].
bearers, Delay Downlink Packet Notification Request, RAT Type) per PDN connection to the Serving GW. If
the Serving GW supports Modify Access Bearers Request procedure and if there is no need for the Serving GW
to send the signalling to the PDN GW, the MME may send Modify Access Bearer Request (eNodeB address(es)
and TEIDs for downlink user plane for the accepted EPS bearers, Delay Downlink Packet Notification Request)
per UE to the Serving GW to optimise the signalling. The Serving GW is now able to transmit downlink data
towards the UE.
connection.
5.3.4B.5 eNB Control Plane Relocation Indication procedure

For intra-NB-IoT mobility for UE and MME using Control Plane CIoT EPS Optimisation the eNB CP Relocation
Indication procedures may be used. The purpose of the eNB CP Relocation Indication procedure is to request the MME
3GPP
Release 15 198 3GPP TS 23.401 V15.10.0 (2019-12)
to authenticate the UE's re-establishment request as described in TS 33.401 [41], and initiate the establishment of the
UE's S1 connection and, if necessary, the S11-U connection after the UE has initiated a RRC Re-establishment
procedure in a new eNB.
More details are defined in TS 36.300 [5].
5.3.5 S1 release procedure

This procedure is used to release the logical S1-AP signalling connection (over S1-MME) and all S1 bearers (in S1-U)
for a UE. This Procedure releases the S11-U bearer in Control Plane CIoT EPS Optimisation (except in case of
buffering in MME), instead of the S1-U bearer. The procedure will move the UE from ECM-CONNECTED to ECM-
IDLE in both the UE and MME, and all UE related context information is deleted in the eNodeB. When the S1-AP
signalling connection is lost, e.g. due to loss of the signalling transport or because of an eNodeB or MME failure, the S1
release procedure is performed locally by the eNodeB and by the MME. When the S1 release procedure is performed
locally by the eNodeB or by the MME each node performs locally its actions as described in the procedure flow below
without using or relying on any of the signalling shown directly between eNodeB and MME.
If Service Gap Control shall be applied for the UE (see clause 4.3.17.9) and the Service Gap timer is not already
running, the Service Gap timer shall be started in MME and UE when entering ECM-IDLE, unless the connection was
initiated after a paging of an MT event, or after a TAU procedure without any active flag set or signalling active flag
set.
The initiation of S1 Release procedure is either:
- eNodeB-initiated with cause e.g. O&M Intervention, Unspecified Failure, User Inactivity, Repeated RRC
signalling Integrity Check Failure, Release due to UE generated signalling connection release, CS Fallback
triggered, Inter-RAT Redirection, etc. as defined in TS 36.413 [36]; or
- MME-initiated with cause e.g. authentication failure, detach, not allowed CSG cell (e.g. the CSG ID of the
currently used CSG cell expires or is removed from the CSG subscription data), etc.
Both eNodeB-initiated and MME-initiated S1 release procedures are shown in Figure 5.3.5-1.

1a. RRC Connection Release
1b. S1-AP: S1 UE Context Release Request
2. Release Access Bearers Request
3. Release Access Bearers Response
4. S1-AP: S1 UE Context Release Command
5. RRC Connection Release
6. S1-AP: S1 UE Context Release Complete

7b. Change Notification
7c. Change Notification Ack

7d. Change Notification Ack
Figure 5.3.5-1: S1 Release Procedure
1a. In certain cases the eNodeB may release the UE's signalling connection before or in parallel to requesting the
MME to release the S1 context, e.g. the eNodeB initiates an RRC Connection Release for CS Fallback by
redirection. If the reason for the release is that the eNodeB received Release Assistance Indicator in Access
3GPP
Release 15 199 3GPP TS 23.401 V15.10.0 (2019-12)
Stratum as defined in TS 36.321 [87], the eNodeB should not immediately release the RRC connection, instead
send S1 UE context Release Request with appropriate cause value e.g. user inactivity.
1b. If the eNodeB detects a need to release the UE's signalling connection and all radio bearers for the UE, the
eNodeB sends an S1 UE Context Release Request (Cause) message to the MME. Cause indicates the reason for
the release (e.g. O&M intervention, unspecified failure, user inactivity, repeated integrity checking failure, or
release due to UE generated signalling connection release).
the Secondary RAT usage data is included in S1 UE Context Release Request.
NOTE 1: Step 1 is only performed when the eNodeB-initiated S1 release procedure is considered. Step 1 is not
performed and the procedure starts with Step 2 when the MME-initiated S1 release procedure is
considered.
The MME upon receiving S1 UE context Release Request with Cause=user inactivity continues with the S1
release procedure unless the MME is aware of pending MT traffic or signalling and/or NAS Release Assistance
Information that may have been received in NAS PDU when Control Plane CIoT EPS Optimisation is used,
which indicates that downlink data is expected.
For Control Plane CIoT EPS Optimisation with data buffering in the MME, step 2 and step 3 are skipped.
2. The MME sends a Release Access Bearers Request (Abnormal Release of Radio Link Indication, Secondary
RAT usage data) message to the S-GW that requests the release of all S1-U bearers for the UE, or the S11-U in
Control Plane CIoT EPS Optimisation if buffering is in the S-GW. This message is triggered either by an S1
Release Request message from the eNodeB, or by another MME event. The Abnormal Release of Radio Link
Indication is included if the S1 release procedure is due to an abnormal release of the radio link. If secondary
RAT usage data was received in Step 1b, the MME includes Secondary RAT usage data in this message.
3. If the S-GW has received a Release Access Bearers Request, the S-GW releases all eNodeB related information
(address and TEIDs), or the MME TEIDs related information in Control Plane CIoT EPS Optimisation (address
and TEIDs), for the UE and responds with a Release Access Bearers Response message to the MME. Other
elements of the UE's S-GW context are not affected. The S-GW retains the S1-U configuration that the S-GW
allocated for the UE's bearers. The S-GW starts buffering downlink packets received for the UE and initiating
the "Network Triggered Service Request" procedure, described in clause 5.3.4.3, if downlink packets arrive for
the UE. In Control Plane CIoT EPS Optimisation Downlink data triggers Mobile Terminated Data transport in
NAS signalling defined in clause 5.3.4B.3.
NOTE 2: Based on operator policy any received Indication of "Abnormal Release of Radio Link" may be used by
Serving GW in subsequent decisions to trigger PDN charging pause if the feature has been enabled on
that PDN.
4. The MME releases S1 by sending the S1 UE Context Release Command (Cause) message to the eNodeB.
5. If the RRC connection is not already released, the eNodeB sends a RRC Connection Release message to the UE
in Acknowledged Mode. Once the message is acknowledged by the UE, the eNodeB deletes the UE's context.
6. The eNodeB confirms the S1 Release by returning an S1 UE Context Release Complete (ECGI, TAI, Secondary
RAT usage data) message to the MME. With this, the signalling connection between the MME and the eNodeB
for that UE is released. This step shall be performed promptly after step 4, e.g. it shall not be delayed in
situations where the UE does not acknowledge the RRC Connection Release.
If Dual Connectivity was activated by that eNodeB at the time of the release or earlier by that eNodeB, the
eNodeB shall include the last known PSCell ID and the time elapsed since the Dual Connectivity was released.
The eNodeB may include the Information On Recommended Cells And eNodeBs For Paging in the S1 UE
Context Release Complete message. If available, the MME shall store this information to be used when paging
the UE.
The eNB includes Information for Enhanced Coverage, if available, in the S1 UE Context Release Complete
message.
If the PLMN has configured secondary RAT usage data reporting, the eNodeB has not included Secondary RAT
usage data at step 1b, and the eNodeB has Secondary RAT usage data to report, the Secondary RAT usage data
3GPP
Release 15 200 3GPP TS 23.401 V15.10.0 (2019-12)
is included in this message. If Secondary RAT usage data was included at step 1b then MME ignores Secondary
RAT usage data at step 6.
The MME deletes any eNodeB related information ("eNodeB Address in Use for S1-MME", "MME UE S1 AP
ID" and "eNB UE S1AP ID") from the UE's MME context, but, retains the rest of the UE's MME context
including the S-GW's S1-U configuration information (address and TEIDs). All non-GBR EPS bearers
established for the UE are preserved in the MME and in the Serving GW.
If the cause of S1 release is because of User I inactivity, Inter-RAT Redirection, the MME shall preserve the
GBR bearers. If the cause of S1 release is because of CS Fallback triggered, further details about bearer handling
are described in TS 23.272 [58]. Otherwise, e.g. Radio Connection With UE Lost, S1 signalling connection lost,
eNodeB failure the MME shall trigger the MME Initiated Dedicated Bearer Deactivation procedure
(clause 5.4.4.2) for the GBR bearer(s) of the UE after the S1 Release procedure is completed.
NOTE 3: EPC does not support the GPRS preservation feature with setting the MBR for GBR bearers to zero.
NOTE 4: The MME can defer the deactivation of GBR bearers for a short period (in the order of seconds) upon
receipt of an S1AP UE Context Release Request due to radio reasons, so as to allow the UE to re-
establish the corresponding radio and S1-U bearers and thus avoid deactivation of the GBR bearers.
If LIPA is active for a PDN connection, the HeNB informs the collocated L-GW by internal signalling to
releases the direct user plane path to the HeNB. After the direct user plane path is released, if downlink packets
arrive for the UE, the L-GW forwards the first packet on the S5 tunnel to the S-GW to initiate the "Network
Triggered Service Request" procedure, as described in clause 5.3.4.3.
7. If the eNodeB provided and MME accepted Secondary RAT usage data in step 6 (i.e. MME initiated S1 release),
the MME initiates the Secondary RAT usage data reporting procedure in clause 5.7A.3 as illustrated in figure
5.7A.3-2 (steps 7a - 7d). If PGW secondary RAT usage reporting is active, steps 7b and 7c are performed,
otherwise only steps 7a and 7d are performed.
If the eNodeB provided Secondary RAT usage data in step 1b (i.e. eNB initiated S1 release) and PGW secondary
RAT usage data reporting is active, the MME initiates the Secondary RAT usage data reporting procedure in
clause 5.7A.3 as illustrated in figure 5.7A.3-2.
5.3.5A Connection Resume procedure

This procedure is used by the UE to resume the ECM-connection if the UE and the network support User Plane CIoT
EPS Optimisation and the UE has stored the necessary information to conduct the Connection Resume procedure (see
TS 36.300 [5]) otherwise the Service Request procedures are used, see clause 5.3.4.
1.Random Access
2.RRC Connection Resume
3.S1-AP UE Context Resume Request
4.S1-AP UE Context Resume Response
5.RRC Reconfiguration
6. Uplink Data
Figure 5.3.5A-1: UE initiated Connection Resume procedure
1. The UE triggers the Random Access procedure to the eNodeB, see TS 36.300 [5].
2. The UE triggers the RRC Connection Resume procedure including information needed by the eNodeB to access
the UE's stored AS context, see TS 36.300 [5]. The E-UTRAN performs security checks. EPS bearer state
synchronization is performed between the UE and the network, i.e. the UE shall locally remove any EPS bearer
3GPP
Release 15 201 3GPP TS 23.401 V15.10.0 (2019-12)
for which no radio bearer is setup and which is not a Control Plane CIoT EPS bearer. If the radio bearer for a
default EPS bearer is not established, the UE shall locally deactivate all EPS bearers associated to that default
EPS bearer.
3. The eNodeB notifies the MME that the UE's RRC connection is resumed in the S1-AP UE Context Resume
Request message which includes an RRC resume cause. If the eNodeB is not able to admit all suspended bearers,
the eNodeB shall indicate this in the list of rejected EPS bearers, see TS 36.413 [36].
If there is a Service Gap timer running in the MME for the UE and the MME is not waiting for a MT paging
response from the UE and the RRC Connection Establishment Cause for the Connection Resume Request is not
'mo-Signalling', the MME rejects the resume request by sending a S1-AP UE Context Resume Reject message to
eNodeB.
NOTE: If the UE then sends a subsequent Service Request while the Service Gap timer is running, the MME will
send a Service Reject NAS message to the UE with a Mobility Management back-off timer corresponding
to the remaining time of the current Service Gap timer (see procedure in clause 5.3.4).
The MME enters the ECM-CONNECTED state. The MME identifies that the UE returns at the eNodeB for
which MME has stored data related to the S1AP association, UE Context and bearer context including the DL
TEID(s), necessary to resume the connection, see Connection Suspend procedure in clause 5.3.4A.
If a default EPS bearer is not accepted by the eNodeB, all the EPS bearers associated to that default bearer shall
be treated as non-accepted bearers. The MME releases the non-accepted and non-established bearers by
triggering the bearer release procedure as specified in clause 5.4.4.2.
3a. If the S1-U connection is resumed and the UE is accessing via the NB-IoT RAT with the RRC resume cause set
to "MO exception data", the MME should notify the Serving Gateway of each use of this establishment cause by
the MO Exception Data Counter. The MME maintains the MO Exception Data Counter and sends it to the
Serving GW as indicated in TS 29.274 [43].
3b. The Serving Gateway should notify the PDN GW if the RRC establishment cause "MO Exception Data" has
been used by the MO Exception Data Counter (see TS 29.274 [43]). The Serving GW indicates each use of this
RRC establishment cause by the related counter on its CDR.
3c. The PDN GW indicates each use of the RRC establishment cause "MO Exception Data" by the related counter
on its CDR.
4. MME acknowledges the connection resumption in S1-AP UE Context Resume Response message. If the MME
is not able to admit all suspended E-RABs the MME shall indicate this in the E-RABs Failed To Resume List IE.
5. If the MME included in step 4 a list of E-RABs failed to resume, the eNodeB reconfigures the radio bearers.
6. The uplink data from the UE can now be forwarded by eNodeB to the Serving GW. The eNodeB sends the
uplink data to the Serving GW address and TEID stored during the Connection Suspend procedure, see
clause 5.3.4A. The Serving GW forwards the uplink data to the PDN GW.
bearers, Delay Downlink Packet Notification Request, RAT Type) per PDN connection to the Serving GW. If
the Serving GW supports Modify Access Bearers Request procedure and if there is no need for the Serving GW
to send the signalling to the PDN GW, the MME may send Modify Access Bearers Request (eNodeB address(es)
and TEIDs for downlink user plane for the accepted EPS bearers, Delay Downlink Packet Notification Request)
per UE to the Serving GW to optimise the signalling. The Serving GW is now able to transmit downlink data
towards the UE.
The MME and the Serving GW clears the DL Data Buffer Expiration Time in their UE contexts if it was set, to
remember that any DL data buffered for a UE using power saving functions has been delivered and to avoid any
unnecessary user plane setup in conjunction with a later TAU.
3GPP
Release 15 202 3GPP TS 23.401 V15.10.0 (2019-12)
connection.
If SIPTO at the Local Network is active for a PDN connection with stand-alone GW deployment and the Local
Home Network ID for stand-alone accessed by the UE differs from the Local Home Network ID where the UE
initiated the SIPTO@LN PDN Connection, the MME shall request disconnection of the SIPTO at the local
network PDN connection(s) with the "reactivation requested" cause value according to clause 5.10.3. If the UE
has no other PDN connection, the MME initiated "explicit detach with reattach required" procedure according to
clause 5.3.8.3.
If SIPTO at the Local Network is active for a PDN connection with collocated LGW deployement and the L-GW
CN address of the cell accessed by the UE differs from the L-GW CN address of the cell where the UE initiated
the SIPTO at the Local Network PDN Connection, the MME shall request disconnection of the SIPTO at the
local network PDN connection(s) with the "reactivation requested" cause value according to clause 5.10.3. If the
UE has no other PDN connection, the MME initiated "explicit detach with reattach required" procedure
5.3.6 Void
5.3.6A PDN GW Pause of Charging procedure

The PDN GW Pause of Charging procedure is optionally supported by the Serving GW and PDN GW and has the
purpose to limit a mismatch between PDN GW and Serving GW charging volume and packet counts. Generally, it aims
for the PDN GW charging and usage monitoring data to more accurately reflect the downlink traffic actually sent to the
E-UTRAN.
NOTE 1: A consequence of using this procedure is that PDN GW charging data does not correspond to the volume
that traversed the PDN GW, and it is therefore not possible to count the downlink packets dropped
between the PDN GW and the E-UTRAN.
The Serving GW may indicate support of this function to the PDN GW when the PDN connection is activated or when
a new/target Serving GW is used for a PDN connection. This is indicated to the PDN GW by a "PDN Charging Pause
Support Indication" in the Create Session Request during PDN activation/Attach and in the Modify Bearer Request in
procedures with a change of Serving GW.
NOTE 2: It is assumed that Pause of PGW Charging is not invoked by SGW that is performing extended data
buffering.
The PDN GW may indicate if the feature is to be enabled on a per PDN connection basis, if the current Serving GW
supports the feature and the operator's policy is to enable the feature. This is indicated to the Serving GW by a "PDN
Charging Pause Enabled" Indication in the Create Session Response during PDN activation/Attach and in the Modify
Bearer Response in procedures with a change of Serving GW. This is an indication to the Serving GW that when the
criteria for pause of PDN GW charging are met (as described further down in this clause) the PDN GW charging can be
paused.
NOTE 3: PDNs where this function applies are based on an operator policy in the PDN GW. What enters into that
policy is operator specific but may be based on for example if the PDN uses SDF based charging, UE is
in home or visited network, APN employed, UE is configured for NAS signalling low priority, Charging
Characteristics value etc.
The PDN GW shall stop any charging and usage monitoring actions for the PDN connection upon receiving a "PDN
Charging Pause Start" Indication in a Modify Bearer Request. When the PDN GW receives a Modify Bearer Request
for a PDN connection for which charging has been stopped previously and, if the Modify Bearer Request contains a
"PDN Charging Pause Stop" Indication or does not contain a "PDN Charging Pause Start" Indication, then the PDN
GW shall continue charging for the PDN connection.
3GPP
Release 15 203 3GPP TS 23.401 V15.10.0 (2019-12)
NOTE 4: In addition to the Service Request Procedure, the PDN GW charging is also unpaused during mobility
procedures involving the Serving GW based on Modify Bearer Request messages without "PDN
Charging Pause Start" indication or during mobility procedures involving the Gn/Gp SGSN based on
Update PDP Context Request messages.
NOTE 5: A Delete Bearer Command or Delete Bearer Request or Delete Bearer Response for a dedicated bearer
does not unpause a previously paused PDN charging.
When bearers become suspended for a UE (see TS 23.272 [58]), the PDN GW charging is no longer paused and the
PDN GW continues charging for the PDN connection after suspended bearers are resumed.
NOTE 6: The PDN GW discards packets received for a suspended UE as described in TS 23.272 [58].
While the PDN GW charging is currently paused and the UE is in ECM-IDLE (for ISR case the device is at same time
in PMM-IDLE or STANDBY in UTRAN/GERAN accesses) the following applies:
- The PDN GW shall not perform charging and usage monitoring actions for downlink traffic on this PDN.
NOTE 7: The Serving GW charges anyway only for the amount of transmitted downlink traffic as described in
clause 5.7A.
- Based on operator policy/configuration in the PDN GW, the PDN GW may limit the rate of downlink traffic sent
to the Serving GW.
Based on operator policy/configuration in the Serving GW, the Serving GW may discard rather than buffer the
downlink user plane packets for this PDN connection while the PDN GW charging is paused. This is to avoid delivery
of user plane packets to the UE that were not counted in the PDN GW for charging and usage monitoring purposes.
Regardless of operator policy/configuration, the downlink user plane packets received from PDN GW at the Serving
GW shall trigger Downlink Data Notifications as described in clause 5.3.4.3.
When the Serving GW receives a Modify Bearer Request or Modify Access Bearers Request for a PDN connection
triggering a Modify Bearer Request towards the PDN GW, the Serving GW shall consider the PDN charging as being
unpaused if it has been paused previously.
Serving GW PDN GW
1. User Plane Data
1. User Plane Data
2. Trigger to
pause charging in
PDN GW
4. Mofify Bearer Response
Figure 5.3.6A: PDN GW Pause of charging procedure
1. The Serving GW receives downlink data packets for a UE known as not user plane connected (i.e. the Serving
GW context data indicates no downlink user plane TEID for the eNodeB) as described in clause 5.3.4.3 step 1,
i.e. the packets are buffered or discarded in Serving GW based on operator policy.
2. Based on operator policy/configuration the Serving GW triggers the procedure to pause PDN charging.
Triggering criteria are based on Serving GW operator policy/configuration. Example of such policy may be:
3GPP
Release 15 204 3GPP TS 23.401 V15.10.0 (2019-12)
a. Operator specified criteria/threshold (e.g. number/fraction of packets/bytes dropped at Serving GW in

downlink since last time the UE was in ECM-CONNECTED state (or for ISR case PMM-CONNECTED
state)).
b. Recent indication of "Abnormal Release of Radio Link" (see clause 5.3.5) or a recent Downlink Data
Notification Reject (clause 5.3.4.3) without UE shortly re-entering ECM-CONNECTED state (or for ISR
case without also re-entering PMM-CONNECTED state).
3. Serving GW sends a Modify Bearer Request (PDN Charging Pause Start) message to the PDN GW. PDN
Charging Pause Start indicates that PDN GW charging shall be paused.
4. PDN GW confirms with a Modify Bearer Response message.
5.3.7 GUTI Reallocation procedure

The MME may initiate the GUTI Reallocation procedure to reallocate the GUTI and/or TAI list at any time when a
signalling association is established between UE and MME. The GUTI Reallocation procedure allocates a new GUTI
and/or a new TAI list to the UE. The GUTI and/or the TAI list may also be reallocated by the Attach or the Tracking
Area Update procedures.
The GUTI Reallocation procedure is illustrated in Figure 5.3.7-1.
UE eNodeB MME
1. GUTI Reallocation Command
2. GUTI Reallocation Complete
Figure 5.3.7-1: GUTI Reallocation Procedure
1. The MME sends GUTI Reallocation Command (GUTI, TAI list) to the UE.
2. The UE returns GUTI Reallocation Complete message to the MME.
5.3.8 Detach procedure
5.3.8.1 General
The Detach procedure allows:
- the UE to inform the network that it does not want to access the EPS any longer, and
- the network to inform the UE that it does not have access to the EPS any longer.
The UE is detached either explicitly or implicitly:
- Explicit detach: The network or the UE explicitly requests detach and signal with each other.
- Implicit detach: The network detaches the UE, without notifying the UE. This is typically the case when the
network presumes that it is not able to communicate with the UE, e.g. due to radio conditions.
Four detach procedures are provided when the UE accesses the EPS through E-UTRAN. The first detach procedure is
UE-initiated detach procedure and other detach procedures are network-initiated detach procedure:
3GPP
Release 15 205 3GPP TS 23.401 V15.10.0 (2019-12)
- UE-Initiated Detach Procedure. In the ISR activated case the UE initiated detach is split into two sub procedures,
one for UE camping on E-UTRAN and one for UE camping on GERAN/UTRAN;
- MME-Initiated Detach Procedure;
- SGSN-Initiated Detach procedure with ISR activated;
- HSS-Initiated Detach Procedure.
NOTE 1: The MME and the UE may enter EMM-DEREGISTERED state without the above procedures.
5.3.8.2 UE-initiated Detach procedure

The Detach procedure when initiated by the UE is described in clauses 5.3.8.2.1 and 5.3.8.2.2.
5.3.8.2.1 UE-initiated Detach procedure for E-UTRAN

Figure 5.3.8.2-1 shows the case when UE camps on E-UTRAN and Detach Request is sent to MME.
UE eNodeB MME SGSN Serving GW PDN GW PCRF HSS
1. Detach Request
4. Detach Notification

Session Termination
(A)
10. Detach Ack
11. Detach Accept
12. Signalling Connection Release
Figure 5.3.8.2-1: UE-Initiated Detach Procedure - UE camping on E-UTRAN
NOTE 1: For a PMIP-based S5/S8, procedure steps (A) are defined in TS 23.402 [2]. Steps 6, 7 and 8 concern GTP
based S5/S8
1. The UE sends NAS message Detach Request (GUTI, Switch Off) to the MME. This NAS message is used to
trigger the establishment of the S1 connection if the UE was in ECM-IDLE mode. Switch Off indicates whether
detach is due to a switch off situation or not. The eNodeB forwards this NAS message to the MME along with
the TAI+ECGI of the cell which the UE is using.
If the MME receives a Detach Request via a CSG cell with Switch Off parameter indicating that detach is not
due to a switch off situation, and the CSG subscription for this CSG ID and associated PLMN is absent or
expired, the MME shall trigger a MME-initiated Detach procedure as specified in clause 5.3.8.3.
If Dual Connectivity is active for the UE, the PSCell ID shall be included in the Uplink NAS Transport that
carries the Detach Request message.
NOTE 2: Security procedures may be invoked if the NAS message is used to establish the S1 connection.
3GPP
Release 15 206 3GPP TS 23.401 V15.10.0 (2019-12)
NOTE 3: For emergency attached UEs that were not successfully authenticated, security procedures are not
performed.
2. If the UE has no activated PDN connection, then steps 2 to 10 are not executed. If the PLMN has configured
secondary RAT usage data reporting, the MME shall wait for step 11, if applicable, and shall perform step 12
before step 2 onwards. For any PDN connection to the SCEF, the MME indicates to the SCEF that the PDN
connection for the UE is no longer available according to TS 23.682 [74] and steps 2 to 10 are not executed. For
PDN connections to the P-GW, the active EPS Bearers in the Serving GW regarding this particular UE are
deactivated by the MME sending Delete Session Request (LBI, User Location Information (ECGI), Secondary
RAT usage data) per PDN connection to the Serving GW. If ISR is activated, then the Serving GW shall not
release the Control Plane TEID allocated for MME/SGSN until it receives the Delete Session Request message
in step 5. If the UE Time Zone has changed, the MME includes the UE Time Zone IE in this message. If
Secondary RAT usage data report was received from RAN, the MME includes this in the Delete Session Request
message.
3. When the S-GW receives the first Delete Session Request message from the MME or SGSN in ISR activated
state, the Serving GW deactivates ISR, releases the related EPS Bearer context information and responds with
Delete Session Response (Cause).
When the S-GW receives the Delete Session Request message from the MME or SGSN in ISR deactivated state,
the Serving GW releases the related EPS Bearer context information and jumps to step 6 by sending a Delete
Session Request (LBI) message per PDN connection to the PDN GW. After step 7 the Serving GW responds
back to the MME/SGSN with the Delete Session Response (Cause and, optionally, APN Rate Control Status
according to clause 4.7.7.3) message.
4. If ISR is activated, MME sends Detach Indication (Cause) message to the associated SGSN. The Cause indicates
complete detach.
5. The active PDP contexts in the Serving GW regarding this particular UE are deactivated by the SGSN sending
Delete Session Request (LBI, CGI/SAI) per PDN connection to the Serving GW. If the UE Time Zone has
changed, the SGSN includes the UE Time Zone IE in this message.
6. If ISR is activated, Serving GW deactivates ISR. If ISR is not activated in the Serving GW, the Serving GW
sends Delete Session Request (LBI, User Location Information (ECGI or CGI/SAI), Secondary RAT usage data)
per PDN connection to the PDN GW. If ISR is not activated, this step shall be triggered by step 2. This message
indicates that all bearers belonging to that PDN connection shall be released. If the MME and/or SGSN sends
UE's Location Information, and/or UE Time Zone Information, and/or Secondary RAT usage data in step 2
and/or step 5, the S-GW includes the User Location Information, and/or UE Time Zone, and/or User CSG
Information with the least age in this message and/or Secondary RAT usage data information.
7. The PDN GW acknowledges with Delete Session Response (Cause and, optionally, APN Rate Control Status
according to clause 4.7.7.3).
8. The PDN GW employs a PCEF initiated IP-CAN Session Termination Procedure as defined in TS 23.203 [6]
with the PCRF to indicate to the PCRF that EPS Bearer is released if PCRF is applied in the network. If
requested by the PCRF the PDN GW indicates User Location Information and/or UE Time Zone Information to
the PCRF as defined in TS 23.203 [6].
9. The Serving GW acknowledges with Delete Session Response (Cause and, optionally, APN Rate Control
Status).
10. The SGSN sends Detach Acknowledge message to the MME (optionally APN Rate Control Status). If received,
the MME stores the APN Rate Control Status in the MM context.
11. If Switch Off indicates that detach is not due to a switch off situation, the MME sends a Detach Accept to the
UE.
12. The MME releases the S1-MME signalling connection for the UE by sending S1 Release Command to the
eNodeB with Cause set to Detach. The details of this step are covered in the "S1 Release Procedure", as
described in clause 5.3.5.
NOTE 4: In the "S1 Release Procedure", if Dual Connectivity was active at the time of the release, the eNodeB
includes the PSCell ID.
3GPP
Release 15 207 3GPP TS 23.401 V15.10.0 (2019-12)
5.3.8.2.2 UE-initiated Detach procedure for GERAN/UTRAN with ISR activated

Figure 5.3.8.2-2 shows the case when UE with ISR Activated camps on GERAN/UTRAN and Detach Request is sent to
SGSN. Refer to clause 6.6.1 of TS 23.060 [7] for the UE-initiated Detach procedure when ISR is not activated.
UE BSS/UTRAN SGSN MME Serving GW PDN GW PCRF HSS
1. Detach Request
6. Delete Bearer
SessionRequ
Request
est
7. Delete Bearer
SessionResponse
Response
8. PCEF Initiated IP
IP-CAN
CAN
Session Termination
(A)
10. Detach Ack
11. Detach Accept
Figure 5.3.8.2-2: UE-Initiated Detach Procedure - UE camping on GERAN/UTRAN, ISR activated
1. The UE sends NAS message Detach Request (Detach Type, P-TMSI, P-TMSI-Signature, Switch Off) to the
SGSN. Detach Type indicates which type of detach is to be performed, i.e. GPRS Detach only, IMSI Detach
only or combined GPRS and IMSI Detach. Switch Off indicates whether detach is due to a switch off situation
or not. The Detach Request message includes P-TMSI and P-TMSI Signature. P-TMSI Signature is used to
check the validity of the Detach Request message. If P-TMSI Signature is not valid or is not included, the
authentication procedure should be performed.
If the SGSN receives a Detach Request via a CSG cell with Switch Off parameter indicating that detach is not
due to a switch off situation, and the CSG subscription for this CSG ID and associated PLMN is absent or
expired, the SGSN shall trigger a SGSN-initiated Detach procedure as specified in clause 5.3.8.3A.
2. The active EPS Bearers in the Serving GW regarding this particular UE are deactivated by the SGSN sending
Delete Session Request (LBI, User Location Information (CGI/SAI)) per PDN connection to the Serving GW.
Because ISR is activated, then the Serving GW shall not release the Control Plan TEID allocated for
MME/SGSN until it receives the Delete Session Request message in step 5. If the UE Time Zone has changed,
the SGSN includes the UE Time Zone IE in this message.
3. Because the Serving GW receives this message in ISR activated state, the Serving GW deactivates ISR and
acknowledges with Delete Session Response (Cause).
4. Because ISR is activated, the SGSN sends Detach Notification (Cause) message to the associated MME. Cause
indicates complete detach.
5. The active PDP contexts in the Serving GW regarding this particular UE are deactivated by the MME sending
Delete Session Request (LBI, ECGI) per PDN connection to the Serving GW. If the UE Time Zone has changed,
the MME includes the UE Time Zone IE in this message.
6. Serving GW deactivates ISR and sends Delete Session Request (LBI, User Location Information (ECGI or
CGI/SAI)) per PDN connection to the PDN GW. If ISR is not activated, this step shall be triggered by step 2.
This message indicates that all bearers belonging to that PDN connection shall be released. If the MME and/or
SGSN sends UE's Location Information and/or UE Time Zone Information in step 2 and/or step 5, the S-GW
includes the User Location Information and/or UE Time Zone with the least age in this message.
3GPP
Release 15 208 3GPP TS 23.401 V15.10.0 (2019-12)
7. The PDN GW acknowledges with Delete Session Response (Cause).
8. The PDN GW employs a PCEF initiated IP CAN Session Termination Procedure as defined in TS 23.203 [6]
with the PCRF to indicate to the PCRF that EPS Bearer is released if PCRF is applied in the network. If
requested by the PCRF the PDN GW indicates User Location Information and/or UE Time Zone Information to
the PCRF as defined in TS 23.203 [6].
9. The Serving GW acknowledges with Delete Session Response (Cause).
10. The MME sends Detach Acknowledge message to the SGSN.
11. If Switch Off indicates that detach is not due to a switch off situation, the SGSN sends a Detach Accept to the
UE.
12. If the MS was GPRS detached, then the 3G SGSN releases the PS signalling connection.
5.3.8.3 MME-initiated Detach procedure

The MME-Initiated Detach procedure when initiated by the MME is illustrated in Figure 5.3.8.3-1.
This procedure may be also used as part of the SIPTO function when the MME determines that GW relocation is
desirable for all PDN connection(s) serving SIPTO-allowed APNs. The MME initiates the "explicit detach with reattach
required" procedure and the UE should then re-establish those PDN connections for the same APN(s).
UE eNodeB MME SGSN Serving GW PDN GW PCRF HSS
1. Detach Request

(B)

Session Termination
(A)
10. Detach Ack
11. Detach Accept
Figure 5.3.8.3-1: MME-Initiated Detach Procedure
based S5/S8.
NOTE 2: Procedure steps (B) are used by the procedure steps (E) in clause 5.3.2.1.
1. The MME initiated detach procedure is either explicit (e.g. by O&M intervention) or implicit. The MME may
implicitly detach a UE, if it has not had communication with UE for a long period of time. The MME does not
send the Detach Request (Detach Type) message to the UE for implicit detach. The implicit detach is local to the
MME, i.e. an SGSN registration will not be detached. If the UE is in ECM-CONNNECTED state the MME may
explicitly detach the UE by sending a Detach Request message to the UE. The Detach Type may be set to re-
attach in which case the UE should re-attach at the end of the detach process. If the UE is in ECM-IDLE state the
MME pages the UE.
3GPP
Release 15 209 3GPP TS 23.401 V15.10.0 (2019-12)
For emergency attached UEs, MME initiated implicit detach procedures are based on an inactivity timeout
specific to emergency.
If this Detach procedure is due to the UE's Detach Request via a CSG cell which the UE is not allowed to access,
i.e. the CSG subscription for this CSG ID and associated PLMN is absent or expired, the MME shall send a
Detach Request to UE with an appropriate cause indicating the UE is not allowed to access this CSG.
2. If the UE has no activated PDN connection, then steps 2 to 10 are not executed. If the PLMN has configured
secondary RAT usage reporting, the MME shall wait for step 11, if applicable, and perform step 12 before step 2
onwards. For any PDN connections to the SCEF, the MME indicates to the SCEF that the PDN connection for
the UE is no longer available according to TS 23.682 [74] and steps 2 to 10 are not executed. For PDN
connections to the P-GW, any EPS Bearer Context information in the Serving GW regarding this particular UE
and related to the MME are deactivated by the MME sending Delete Session Request (LBI, User Location
Information (ECGI), NAS Release Cause if available, Secondary RAT usage data) message per PDN connection
to the Serving GW. If the UE Time Zone has changed, the MME includes the UE Time Zone IE in this message.
NAS Release Cause is only sent by the MME to the PDN GW if this is permitted according to MME operator's
policy. If Secondary RAT usage data report was received from the RAN, the MME includes this in the Delete
Session Request message.
Delete Session Response (Cause).
When the S-GW receives the Delete Session Request message from the MME or SGSN in ISR deactivated state,
the Serving GW releases the related EPS Bearer context information and jumps to step 6 by sending a Delete
Session Request (LBI) message to the PDN GW. After step 7 the Serving GW responds back to the MME/SGSN
with the Delete Session Response (Cause and, optionally, APN Rate Control Status according to clause 4.7.7.3)
message.
4. If ISR is activated, MME sends Detach Notification (Cause) message to the associated SGSN. The cause
indicates whether it is a local or complete detach.
5. If cause indicates complete detach then the SGSN sends a Delete Session Request (LBI, CGI/SAI) message per
PDN connection to the Serving GW. If Cause indicates local detach then SGSN deactivates ISR and steps 5 to 9
shall be skipped. If the UE Time Zone has changed, the SGSN includes the UE Time Zone IE in this message.
6. If ISR is activated, Serving GW deactivates ISR.
If ISR is not activated and the Serving GW received one or several Delete Bearer Request message(s) from
SGSN in step 2, the Serving GW sends a Delete Session Request (LBI, User Location Information (ECGI or
CGI/SAI), NAS Release Cause if available, Secondary RAT usage data) message for each associated PDN
connection to the PDN GW. NAS Release Cause is the one received in the Delete Session Request from the
MME. This message indicates that all bearers belonging to that PDN connection shall be released.
If the MME and/or SGSN send(s) UE's Location Information, and/or UE Time Zone and/or Secondary RAT
usage data in step 2 and/or step 5, the S-GW includes the User Location Information, and/or UE Time Zone
Information with the least age in this message and/or Secondary RAT usage data.
8. The PDN GW employs an IP-CAN Session Termination procedure as defined in TS 23.203 [6] with the PCRF to
indicate to the PCRF that the EPS Bearer(s) are released if a PCRF is configured. If requested by the PCRF the
PDN GW indicates User Location Information and/or UE Time Zone Information and NAS Release Cause (if
available) to the PCRF as defined in TS 23.203 [6].
9. The Serving GW acknowledges with Delete Session Response (Cause, APN Rate Control Status) message.
10. The SGSN sends Detach Acknowledge message to the MME (APN Rate Control Status). The MME stores the
APN Rate Control Status in the MM context.
11. If the UE receives the Detach Request message from the MME in the step 1, the UE sends a Detach Accept
message to the MME any time after step 1. The eNodeB forwards this NAS message to the MME along with the
TAI+ECGI of the cell which the UE is using.
3GPP
Release 15 210 3GPP TS 23.401 V15.10.0 (2019-12)
carries the Detach Accept message.
If the UE receives Detach Request from the MME via a CSG cell with the cause indicating the UE is not allowed
to access this CSG, the UE shall remove this CSG ID and associated PLMN from its Allowed CSG list, if
present.
12. After receiving the Detach Accept message, Delete Session Response and, if appropriate, Detach Acknowledge
message, the MME releases the S1-MME signalling connection for the UE by sending an S1 Release Command
(Cause) message to the eNodeB. The details of this step are covered in the "S1 Release Procedure", as described
in clause 5.3.5 by step 4 to step 6. If the Detach Type requests the UE to make a new attach, the UE reattaches
after the RRC Connection Release is completed.
5.3.8.3A SGSN-initiated Detach procedure with ISR activated

The SGSN-Initiated Detach procedure with ISR activated is illustrated in Figure 5.3.8.3A-1. Refer to clause 6.6.2.1 of
TS 23.060 [7] for the SGSN-initiated Detach procedure when ISR is not activated.
UE BSS/UTRAN SGSN MME Serving GW PDN GW PCRF HSS
1. Detach Request

Session Termination
(A)
10. Detach Ack
11. Detach Accept
Figure 5.3.8.3A-1: SGSN-Initiated Detach Procedure with ISR activated
based S5/S8.
1. The SGSN initiated detach procedure is either explicit (e.g. by O&M intervention) or implicit. The SGSN may
implicitly detach a UE, if it has not had communication with UE for a long period of time. The SGSN does not
send the Detach Request (Detach Type) message to the UE for implicit detach. The implicit detach is local to the
SGSN, i.e. an MME registration will not be detached. If the UE is in PMM-CONNNECTED state the SGSN
may explicitly detach the UE by sending a Detach Request message to the UE. The Detach Type may be set to
re-attach in which case the UE should re-attach at the end of the detach process. If the UE is in PMM-IDLE state
the SGSN pages the UE.
If this Detach procedure is due to the UE's Detach Request via a CSG cell which the UE is not allowed to access,
i.e. the CSG subscription for this CSG ID and associated PLMN is absent or expired, the SGSN shall send a
Detach Request to UE with an appropriate cause indicating the UE is not allowed to access this CSG.
3GPP
Release 15 211 3GPP TS 23.401 V15.10.0 (2019-12)
2. Any EPS Bearer Context information in the Serving GW regarding this particular UE and related to the SGSN is
deactivated by the SGSN sending Delete Session Request (LBI, User Location Information (ECGI)) message per
PDN connection to the Serving GW. If the UE Time Zone has changed, the SGSN includes the UE Time Zone
IE in this message.
3. Because the Serving GW receives this message in ISR activated state, the Serving GW deactivates ISR, releases
the SGSN related EPS Bearer context information and acknowledges with Delete Session Response (Cause).
4. Because ISR is activated, the SGSN sends Detach Notification (Cause) message to the associated MME. The
cause indicates whether it is a local or complete detach.
5. If cause indicates complete detach then the MME sends a Delete Session Request (LBI, User Location
Information (ECGI)) message per PDN connection to the Serving GW. If Cause indicates local detach then
MME deactivates ISR and steps 5 to 9 shall be skipped. If the UE Time Zone has changed, the MME includes
the UE Time Zone IE in this message.
6. The Serving GW sends a Delete Session Request (LBI, User Location Information (ECGI or CGI/SAI)) message
per PDN connection to the PDN GW. This message indicates that all bearers belonging to that PDN connection
shall be released. If the MME and/or SGSN sends UE's Location Information and/or UE Time Zone in step 2
and/or step 5, the S-GW includes the User Location Information and/or UE Time Zone Information with the
least age in this message.
7. The PDN GW acknowledges with Delete Session Response (Cause) message.
8. The PDN GW employs an IP CAN Session Termination procedure as defined in TS 23.203 [6] with the PCRF to
indicate to the PCRF that the EPS Bearer(s) are released if a PCRF is configured. If requested by the PCRF the
PDN GW indicates User Location Information and/or UE Time Zone Information to the PCRF as defined in
TS 23.203 [6].
9. The Serving GW acknowledges with Delete Session Response (Cause) message.
10. The MME sends Detach Acknowledge message to the SGSN.
11. If the UE receives the Detach Request message from the SGSN in the step 1, the UE sends a Detach Accept
message to the SGSN any time after step 1.
If the UE receives Detach Request from the SGSN via a CSG cell with the cause indicating the UE is not
allowed to access this CSG, the UE shall remove this CSG ID and associated PLMN from its Allowed CSG list,
if present.
12. After receiving the Detach Accept message, if Detach Type did not request the UE to make a new attach, then
the 3G SGSN releases the PS signalling connection.
5.3.8.4 HSS-initiated Detach procedure

The HSS-Initiated Detach procedure is initiated by the HSS. The HSS uses this procedure for operator-determined
purposes to request the removal of a subscriber's MM and EPS bearer at the MME and also at the SGSN if both an
MME and an SGSN are registered in the HSS.
For UEs with emergency EPS bearers, the MME/SGSN shall not initiate detach procedure. Instead the MME/SGSN
shall deactivate all the non emergency PDN connection.
For subscription change, e.g. RAT restrictions to disallow one of the RATs, the Insert Subscription Data procedure shall
be used towards the MME, and also towards the SGSN if both an MME and an SGSN are registered in the HSS.
This procedure is not applied if a Cancel Location is sent to the MME or the SGSN with a cause other than Subscription
Withdrawn.
The HSS-Initiated Detach Procedure is illustrated in Figure 5.3.8.4-1.
3GPP
Release 15 212 3GPP TS 23.401 V15.10.0 (2019-12)
UE eNodeB RNC/BSS MME SGSN Serving GW PDN GW PCRF HSS
1a. Cancel Location

2a. Detach Request
1a. Cancel Location ACK
2b. Detach Request 1b. Cancel Location

1b. Cancel Location ACK
3a. Delete Session Request (B)

3b. Delete Session Request
7a. Delete Session Response 5. Delete Session Response

7b. Delete Session Response
Session Termination
(A)
8a. Detach Accept
8b. Detach Accept
10a. Signalling Connection Release
10b. Signalling Connection Release
Figure 5.3.8.4-1: HSS-Initiated Detach Procedure
based S5/S8.
NOTE 2: Procedure steps (B) are used by the procedure steps (F) in clause 5.3.2.1.
NOTE 3: The steps below apply for an S4-SGSN. For Gn/Gp SGSN, the procedure specified in clause 6.6.2.2. of
TS 23.060 [7] applies for the SGSN.
1. If the HSS wants to request the immediate deletion of a subscriber's MM contexts and EPS Bearers, the HSS
shall send a Cancel Location (IMSI, Cancellation Type) message with Cancellation Type set to Subscription
Withdrawn to the registered MME and also to the SGSN if an SGSN is also registered. When receiving the
Cancel Location Message the MME/SGSN acknowledges with a Cancel Location ACK (IMSI) message to the
HSS.
2. If Cancellation Type is Subscription Withdrawn, the MME/SGSN which has an active UE context informs the
UE which is in ECM-CONNECTED state, that it has been detached, by sending Detach Request (Detach Type)
message to the UE. If the Cancel Location message includes a flag to indicate re-attach is required, the
MME/SGSN shall set the Detach Type to indicate that re-attach is required. If the UE is in ECM-IDLE state the
MME pages the UE.
NOTE 4: The UE will receive only one Detach Request message in the RAT where it currently camps on.
3a. If the UE has no activated PDN connection, then steps 3 to 7 are not executed. If the PLMN has configured
secondary RAT usage data reporting, the MME shall wait for Step 8a, if applicable, and perform step 10a before
step 3a. If the MME has an active UE context, for any PDN connection to the SCEF, the MME indicates to the
SCEF that the PDN connection for the UE is no longer available according to TS 23.682 [74] and steps 3 to 7 are
not executed. For PDN connections to the P-GW, the MME sends a Delete Session Request (LBI, User Location
Information (ECGI), NAS Release Cause if available, Secondary RAT usage data if available) message per PDN
connection to the Serving GW to deactivate the EPS Bearer Context information in the Serving GW. NAS
Release Cause is only sent by the MME to the PDN GW if this is permitted according to MME operator's policy.
3b. If the SGSN has an active UE context, the SGSN sends a Delete Session Request (LBI, User Location
Information (CGI/SAI)) per PDN connection to the Serving GW to deactivate the EPS Bearer Context
information in the Serving GW.
3GPP
Release 15 213 3GPP TS 23.401 V15.10.0 (2019-12)
Delete Session Response in step 7.
When the S-GW receives one or several Delete Session Request message(s) from the MME or SGSN in ISR
deactivated state, the Serving GW releases the related EPS Bearer context information and sends a Delete
Session Request (LBI, User Location Information (ECGI or CGI/SAI), NAS Release Cause if available,
Secondary RAT usage data if PGW secondary RAT usage data reporting is active) message for each associated
PDN connection to the PDN GW. NAS Release Cause is the one received in the Delete Session Request from
the MME or SGSN. This message indicates that all bearers belonging to that PDN connection shall be released.
If the UE Time Zone has changed, the MME includes the UE Time Zone IE in this message. If the MME and/or
SGSN sends UE's Location Information and/or UE Time Zone Information in step 3a and/or step 3b, the S-GW
includes the User Location Information and/or UE Time Zone with the least age in this message.
6. The PDN GW employs a PCEF initiated IP-CAN Session Termination procedure as defined in TS 23.203 [6]
with the PCRF to indicate to the PCRF that the EPS bearer is released if a PCRF is configured. If requested by
the PCRF the PDN GW indicates User Location Information and/or UE Time Zone Information and NAS
Release Cause (if available) to the PCRF as defined in TS 23.203 [6].
7. The Serving GW acknowledges with Delete Session Response (TEID and, optionally, APN Rate Control Status)
message.
If received, the MME stores the APN Rate Control Status in the MM context.
8. If the UE receives the Detach Request message from the MME/SGSN, the UE sends a Detach Accept message to
the MME/SGSN any time after step 2. The message is sent either in E-UTRAN or GERAN/UTRAN access
depending on which access the UE received the Detach Request. For the Detach Accept message from UE to
MME the eNodeB forwards this NAS message to the MME along with the TAI+ECGI of the cell which the UE
is using.
carries the Detach Accept message.
9. Void.
10a. After receiving the Detach Accept message, the MME releases the S1-MME signalling connection for the UE
by sending S1 Release Command (Cause) message to the eNodeB with Cause set to Detach. The details of this
step are covered in the "S1 Release Procedure", as described in clause 5.3.5.
10b. After receiving the Detach Accept message, if Detach Type did not request the UE to make a new attach,
then the 3G SGSN releases the PS signalling connection.
5.3.9 HSS User Profile management function procedure
5.3.9.1 General
The HSS user profile management function allows the HSS to update the HSS user profile stored in the MME.
Whenever the HSS user profile is changed for a user in the HSS, and the changes affect the HSS user profile stored in
the MME, the MME shall be informed about these changes by the means of the following procedure:
- Insert Subscriber Data procedure, used to add or modify the HSS user profile in the MME.
5.3.9.2 Insert Subscriber Data procedure

The Insert Subscriber Data procedure is illustrated in Figure 5.3.9.2-1.
3GPP
Release 15 214 3GPP TS 23.401 V15.10.0 (2019-12)
MME HSS
1. Insert Subscriber Data
2. Insert Subscriber Data Ack
Figure 5.3.9.2-1: Insert Subscriber Data procedure
1. The HSS sends an Insert Subscriber Data (IMSI, Subscription Data) message to the MME.
2. The MME updates the stored Subscription Data and acknowledges the Insert Subscriber Data message by
returning an Insert Subscriber Data Ack (IMSI) message to the HSS. The update result should be contained in
the Ack message.
The MME initiates appropriate action according to the changed subscriber data (e.g. MME initiates detach if the
UE is not allowed to roam in this network). For received PDN subscription contexts that have no related active
PDN connection in the MME, no further action is required except storage in the MME. Otherwise if the
subscribed QoS Profile has been modified and the UE is in ECM-CONNECTED state or in ECM-IDLE state
when ISR is not activated but the UE is reachable by the MME, the HSS Initiated Subscribed QoS Modification
procedure, as described in Figure 5.4.2.2-1, is invoked from step 2a. When ISR is not activated and the UE is in
ECM IDLE state and is not reachable by the MME, e.g. when the UE is suspended, when the UE has entered
into power saving mode or when the PPF is cleared in the MME, the HSS Initiated Subscribed QoS Modification
procedure, as described in Figure 5.4.2.2-1, is invoked from step 2a at the next ECM IDLE to ECM
CONNECTED transition. If the UE is in ECM-IDLE state and the ISR is activated, this procedure is invoked at
the next ECM-IDLE to ECM-CONNECTED transition. If the UE is in ECM-IDLE state and the ISR is not
activated and if the subscription change no longer allows the PDN connection, the MME initiated PDN
disconnection procedure in clause 5.10.3 is used to delete the concerned PDN connection. If the MME receives
RAT specific Subscribed Paging Time Window that is different from the one stored in the MME MM context,
the MME updates RAT specific Subscribed Paging Time Window parameter in the MME MM context to the
value received from the HSS.
If the UE is in ECM-CONNECTED state and connected via a CSG or hybrid cell, the MME shall check the
received CSG subscription data. If the MME detects that the CSG membership to that cell has changed or
expired, the MME initiates the procedure in clause 5.16.
If the MME received a changed Service Gap Time parameter in the updated subscription data, the MME shall
provide the new Service Gap Time value to the UE in the next Tracking Area Update Accept message, or, if the
UE does not send any Tracking Area Update Request within a certain time period that shall be longer than any
PSM or eDRX interval used by the UE, the MME may initiate a detach with reattach required of the UE or an
RRC connection release with release cause load balancing TAU required of the UE.
5.3.9.3 Purge function

The Purge function allows an MME to inform the HSS that it has deleted the subscription data and MM context of a
detached UE. The MME may, as an implementation option, delete the subscription data and MM context of an UE
immediately after the implicit or explicit detach of the UE. Alternatively the MME may keep for some time the
subscription data and the MM context of the detached UE, so that the data can be reused at a later attach without
accessing the HSS.
MME HSS
1. Purge UE
2. Purge UE Acknowledge
Figure 5.3.9.3-1: Purge Procedure
3GPP
Release 15 215 3GPP TS 23.401 V15.10.0 (2019-12)
1. After deleting the Subscription data and MM contexts of a detached UE, the MME sends Purge UE (IMSI)
message to the HSS.
2. The HSS sets the UE Purged for E-UTRAN flag and acknowledges with a Purge UE Ack message.
5.3.10 Security Function
5.3.10.1 General
The security functions include:
- Guards against unauthorised EPS service usage (authentication of the UE by the network and service request
validation).
- Provision of user identity confidentiality (temporary identification and ciphering).
- Provision of user data and signalling confidentiality (ciphering).
- Provision of origin authentication of signalling data (integrity protection).
- Authentication of the network by the UE.
Security-related network functions for EPS are described in TS 33.401 [41].
5.3.10.2 Authentication and Key Agreement

EPS AKA is the authentication and key agreement procedure that shall be used over E-UTRAN, between the UE and
MME. EPS AKA is specified in TS 33.401 [41].
5.3.10.3 User Identity Confidentiality

An M-TMSI identifies a user between the UE and the MME. The relationship between M-TMSI and IMSI is known
only in the UE and in the MME.
5.3.10.4 User Data and Signalling Confidentiality

There are two different levels of the security associations between the UE and the network.
i) RRC and UP security association is between the UE and E-UTRAN. The RRC security associations protect the
RRC signalling between the UE and E-UTRAN (integrity protection and ciphering). The UP security association
is also between the UE and E-UTRAN and provide user plane encryption function.
ii) NAS security association is between the UE and the MME. It provides integrity protection and encryption of
NAS signalling and, when the Control Plane CIoT EPS Optimisation is used, user data.
5.3.10.4.1 AS security mode command procedure

The MME triggers the RRC level AS security mode command procedure by sending the needed security parameters to
the eNodeB. This enables ciphering of the UP traffic and ciphering and integrity protection of the RRC signalling as
5.3.10.4.2 NAS Security Mode Command procedure

The MME uses the NAS Security Mode Command (SMC) procedure to establish a NAS security association between
the UE and MME, in order to protect the further NAS signalling messages. This procedure is also used to make changes
in the security association, e.g. to change the security algorithm.
3GPP
Release 15 216 3GPP TS 23.401 V15.10.0 (2019-12)
UE eNodeB MME
1. NAS Security Mode Command
2. NAS Security Mode Complete
Figure 5.3.10.4.2-1: NAS Security Mode Command Procedure
1. The MME sends NAS Security Mode Command (Selected NAS algorithms, eKSI, ME Identity request, UE
Security Capability) message to the UE. ME identity request may be included when NAS SMC is combined with
ME Identity retrieval (see clause 5.3.10.5).
2. The UE responds NAS with Security Mode Complete (NAS-MAC, ME Identity) message. The UE includes the
ME Identity if it was requested in step 1.
NOTE: The NAS Security Mode Command procedure is typically executed as part of the Attach procedure (see
clause 5.3.2.1) in advance of, or in combination with, executing the ME Identity Check procedure (see
clause 5.3.10.5) and in the TAU procedure (see clauses 5.3.3.1 and 5.3.3.2).
More details of the procedure are described in TS 33.401 [41].
5.3.10.5 ME identity check procedure

The Mobile Equipment Identity Check Procedure permits the operator(s) of the MME and/or the HSS and/or the
PDN GW to check the Mobile Equipment's identity (e.g. to check that it has not been stolen, or, to verify that it does not
have faults).
The ME Identity can be checked by the MME passing it to an Equipment Identity Register (EIR) and then the MME
analysing the response from the EIR in order to determine its subsequent actions (e.g. sending an Attach Reject if the
EIR indicates that the Mobile Equipment is blacklisted).
The ME identity check procedure is illustrated in Figure 5.3.10.5-1.
UE eNodeB MME EIR
1. Identity Request
1. Identity Response
2. ME Identity Check
2. ME Identity Check Ack
Figure 5.3.10.5-1: Identity Check Procedure
1. The MME sends Identity Request (Identity Type) to the UE. The UE responds with Identity Response (Mobile
Identity).
2. If the MME is configured to check the IMEI against the EIR, it sends ME Identity Check (ME Identity, IMSI) to
EIR. The EIR responds with ME Identity Check Ack (Result).
NOTE: The Identity Check Procedure is typically executed as part of the Attach procedure (see clause 5.3.2.1).
3GPP
Release 15 217 3GPP TS 23.401 V15.10.0 (2019-12)
5.3.11 UE Reachability procedures
5.3.11.1 General
There are two procedures necessary for any service related entity that would need to be notified by the reachability of
the UE at EPC NAS level:
- UE Reachability Notification Request procedure; and
- UE Activity Notification procedure.
5.3.11.2 UE Reachability Notification Request procedure

The UE Reachability Notification Request procedure is illustrated in Figure 5.3.11.2-1.
MME HSS
1. UE-REACHABILITY-NOTIFICATION-REQUEST (URRP-MME)
Figure 5.3.11.2-1: UE Reachability Notification Request Procedure
1) If a service-related entity requests the HSS to provide an indication regarding UE reachability on EPS, the HSS
stores the service-related entity and sets the URRP-MME parameter to indicate that such request is received. If
the value of URRP-MME parameter has changed from "not set" to "set", the HSS sends a UE-
REACHABILITY-NOTIFICATION-REQUEST (URRP-MME) to the MME. If the MME has an MM context
for that user, the MME sets URRP-MME to indicate the need to report to the HSS information regarding changes
in UE reachability, e.g. when the next NAS activity with that UE is detected.
5.3.11.3 UE Activity Notification procedure

The UE Activity Notification procedure is illustrated in Figure 5.3.11.3-1.
UE MME HSS
1. UE Activity
2. UE-Activity-Notification
3. Inform requesting
entities about change in UE
reachability
Figure 5.3.11.3-1: UE Activity Procedure
1) The MME receives an indication regarding UE reachability, e.g. an Attach Request message from the UE or
MME receive an indication from S-GW that UE has handed over to non-3GPP coverage.
2) If the MME contains an MM context of the UE and if URRP-MME for that UE is configured to report once that
the UE is reachable, the MME shall send a UE-Activity-Notification (IMSI, UE-Reachable) message to the HSS
and clears the corresponding URRP-MME for that UE.
3) When the HSS receives the UE-Activity-Notification (IMSI, UE-Reachable) message or the Update Location
message for an UE that has URRP-MME set, it triggers appropriate notifications to the entities that have
subscribed to the HSS for this notification and clears the URRP-MME for that UE.
3GPP
Release 15 218 3GPP TS 23.401 V15.10.0 (2019-12)
5.3.12 Update CSG Location Procedure

The Update CSG Location procedure takes place when the SGSN/MME needs to retrieve the CSG subscription
information of the UE from the CSS.
SGSN/MME CSS
1. Update CSG Location Request
2. Update CSG Location Ack
Figure 5.3.12-1: Update CSG Location Procedure
1. The SGSN/MME sends Update CSG Location Request (MME Identity, IMSI, MSISDN) to the CSS. The
MSIDSN is included if available.
2. The CSS acknowledges the Update CSG Location message by sending an Update CSG Location Ack (IMSI,
CSG Subscription data) message to the SGSN/MME.
5.3.13 CSS subscription data management function procedure
5.3.13.1 General
The CSS subscription data management function allows the CSS to update the CSS subscription data stored in the
MME.
The CSS subscription data is stored and managed in the MME independently from the Subscription Data received from
the HSS.
Whenever the CSS subscription data is changed for a user in the CSS, and the changes affect the CSG subscription
information stored in the MME, the MME shall be informed about these changes by the means of the following
procedure:
- Insert CSG Subscriber Data procedure, used to add or modify the CSS subscription data in the MME.
5.3.13.2 Insert CSG Subscriber Data procedure

The Insert CSG Subscriber Data procedure is illustrated in Figure 5.3.13.2-1.
CSS
MME
1. Insert CSG Subscriber Data
2. Insert CSG Subscriber Data Ack
Figure 5.3.13.2-1: Insert CSG Subscriber Data procedure
1. The CSS sends an Insert CSG Subscriber Data (IMSI, CSG Subscription Data) message to the MME.
3GPP
Release 15 219 3GPP TS 23.401 V15.10.0 (2019-12)
2. The MME updates the stored CSG Subscription Data and acknowledges the Insert CSG Subscriber Data
message by returning an Insert CSG Subscriber Data Ack (IMSI) message to the CSS. The update result should
be contained in the Ack message.
The MME initiates appropriate action according to the changed CSG subscriber data. If the UE is in ECM-
CONNECTED state and connected via a CSG or hybrid cell, the MME shall check the received CSG subscriber
data. If the MME detects that the CSG membership to that cell has changed or expired, the MME initiates the
procedure in clause 5.16.
5.3.14 UE Radio Capability Match Request

If the MME, e.g. based on SRVCC capability in NAS, UE Usage Type or local policy, requires more information on the
UE radio capabilities support to be able to set the IMS voice over PS Session Supported Indication (see clause 4.3.5.8),
then the MME may send a UE Radio Capability Match Request message to the eNB. This procedure is typically used
during the Initial Attach procedure, during Tracking Area Update procedure for the "first TAU following
GERAN/UTRAN Attach" or for "UE radio capability update" or when MME has not received the Voice Support Match
Indicator (as part of the MM Context).
UE eNodeB MME
1. S1-AP: UE Radio Capability Match Request
2. RRC: UE Capability Enquiry
3. RRC: UE Capability Information

4. S1-AP: UE Radio Capability Match Response
5 S1-AP UE Capability Info Indication
Figure 5.3.14-1: UE Radio Capability Match Request
1 The MME indicates whether the MME wants to receive Voice support match indicator. The MME may include
the UE Radio Capability information that it has previously received from the eNB via a S1-AP UE
CAPABILITY INFO INDICATION as described in clause 5.11.2.
2. Upon receiving a UE Radio Capability Match Request from the MME, if the eNB has not already received the
UE radio capabilities from the UE or from MME in step 1, the eNB requests the UE to upload the UE radio
capability information by sending the RRC UE Capability Enquiry.
3. The UE provides the eNB with its UE radio capabilities sending the RRC UE Capability Information.
4. The eNB checks whether the UE radio capabilities are compatible with the network configuration for ensuring
voice service continuity of voice calls initiated in IMS.
For determining the appropriate UE Radio Capability Match Response, the eNB is configured by the operator to
check whether the UE supports certain capabilities required for Voice continuity of voice calls using IMS PS. In
a shared network, the eNB keeps a configuration separately per PLMN.
NOTE 1: What checks to perform depends on network configuration, i.e. following are some examples of UE
capabilities to be taken into account:
- the SRVCC, and UTRAN/E-UTRAN Voice over PS capabilities;
- the Radio capabilities for UTRAN/E-UTRAN FDD and/or TDD; and/or
- the support of UTRAN/E-UTRAN frequency bands.
3GPP
Release 15 220 3GPP TS 23.401 V15.10.0 (2019-12)
NOTE 2: The network configuration considered in the decision for the Voice Support Match Indicator is
homogenous within a certain area (e.g. MME Pool Area) in order to guarantee that the Voice Support
Match Indicator from the eNB is valid within such area.
The eNB provides a Voice Support Match Indicator to the MME to indicate whether the UE capabilities and
networks configuration are compatible for ensuring voice service continuity of voice calls initiated in IMS.
The MME stores the received Voice support match indicator in the MM Context and uses it as an input for
setting the IMS voice over PS Session Supported Indication.
5. If eNB requested radio capabilities from UE in step 2 and 3, eNB also sends the UE radio capabilities to the
MME using the S1-AP UE CAPABILITY INFO INDICATION. The MME stores the UE radio capabilities
without interpreting them for further provision to the eNB in cases described in clause 5.11.2.
NOTE 3: Steps 4 and 5 may be received by the MME in any order.
5.4 Session Management, QoS and interaction with PCC

functionality
5.4.1 Dedicated bearer activation
The dedicated bearer activation procedure for a GTP based S5/S8 is depicted in figure 5.4.1-1. This procedure shall not
be used when the UE is accessing over NB-IoT (i.e. RAT Type = NB-IoT).
UE eNodeB MME Serving GW PDN GW PCRF
1. IP-CAN Session
(A)
Modification
2. Create Bearer Request
3. Create Bearer Request

4. Bearer Setup Request/
Session Management Request
5. RRC Connection Reconfiguration
7. Bearer Setup Response

8. Direct Transfer
9. Session Management Response
10. Create Bearer Response
11. Create Bearer Response
12. IP-CAN Session
Modification
(B)
Figure 5.4.1-1: Dedicated Bearer Activation Procedure
NOTE 1: Steps 3-10 are common for architecture variants with GTP based S5/S8 and PMIP-based S5/S8. For an
PMIP-based S5/S8, procedure steps (A) and (B) are defined in TS 23.402 [2]. Steps 1, 2, 11 and 12
1. If dynamic PCC is deployed, the PCRF sends a PCC decision provision (QoS policy) message to the PDN GW.
This corresponds to the initial steps of the PCRF-Initiated IP-CAN Session Modification procedure or to the
PCRF response in the PCEF initiated IP-CAN Session Modification procedure as defined in TS 23.203 [6], up to
the point that the PDN GW requests IP-CAN Bearer Signalling. The PCC decision provision message may
3GPP
Release 15 221 3GPP TS 23.401 V15.10.0 (2019-12)
indicate that User Location Information and/or UE Time Zone Information is to be provided to the PCRF as
defined in TS 23.203 [6]. If dynamic PCC is not deployed, the PDN GW may apply local QoS policy.
2. The PDN GW uses this QoS policy to assign the EPS Bearer QoS, i.e., it assigns the values to the bearer level
QoS parameters QCI, ARP, GBR and MBR; see clause 4.7.3. If this dedicated bearer is created as part of the
handover procedure from non-3GPP access with GTP-based S2a/S2b, then the PDN GW applies the Charging Id
already in use for the corresponding dedicated bearer while the UE was in non-3GPP access (i.e bearer with the
same QCI and ARP as in non-3GPP access). Otherwise, the PDN GW generates a Charging Id for the dedicated
bearer. The PDN GW sends a Create Bearer Request message (IMSI, PTI, EPS Bearer QoS, Maximum Packet
Loss Rate (UL, DL), TFT, S5/S8 TEID, Charging Id, LBI, Protocol Configuration Options) to the Serving GW,
the Linked EPS Bearer Identity (LBI) is the EPS Bearer Identity of the default bearer. The Procedure
Transaction Id (PTI) parameter is only used when the procedure was initiated by a UE Requested Bearer
Resource Modification Procedure - see clause 5.4.5. Protocol Configuration Options may be used to transfer
application level parameters between the UE and the PDN GW (see TS 23.228 [52]), and are sent transparently
through the MME and the Serving GW.
NOTE 2: The PCO is sent in the dedicated bearer activation procedure either in response to a PCO received from
the UE, or without the need to send a response to a UE provided PCO e.g. when the network wants the
bearer to be dedicated for IMS signalling.
For a QCI=1 bearer, the Maximum Packet Loss Rate (UL, DL) may be provided by the PDN GW as described in
TS 23.203 [6].
3. The Serving GW sends the Create Bearer Request (IMSI, PTI, EPS Bearer QoS, Maximum Packet Loss Rate
(UL, DL), TFT, S1-TEID, PDN GW TEID (GTP-based S5/S8), LBI, Protocol Configuration Options) message
to the MME. If the UE is in ECM-IDLE state the MME will trigger the Network Triggered Service Request from
step 3 (which is specified in clause 5.3.4.3). In that case the following steps 4-7 may be combined into Network
Triggered Service Request procedure or be performed stand-alone. The MME checks if the UE can support the
establishment of additional user plane radio bearer based on the maximum number of user plane radio bearers
indicated by NB-IoT UE in the UE Network Capability IE as defined in clause 5.11.3 and for WB-E-UTRAN in
clause 4.12.
If the UE is in ECM-IDLE state and extended idle mode DRX is enabled for the UE, the MME will trigger
Network Triggered Service Request from step 3 (which is specified in clause 5.3.4.3), and start a timer which is
configured to a value smaller than the GTP re-transmission timer. If the MME receives no response from the UE
before the timer expires, the MME sends a Create Bearer Response with a rejection cause indicating that the UE
is temporarily not reachable due to power saving and, if a Delay Tolerant Connection indication was set for the
PDN connection, the MME sets the internal flag Pending Network Initiated PDN Connection Signalling. The
rejection is forwarded by the Serving GW to the PDN GW. In this case, the steps 4-11 are skipped.
NOTE 3: If ISR is activated and the Serving GW does not have a downlink S1-U and the SGSN has notified the
Serving GW that the UE has moved to PMM-IDLE or STANDBY state, the Serving GW sends Downlink
Data Notification to trigger MME and SGSN to page the UE (as specified in clause 5.3.4.3) before
sending the Create Bearer Request message.
4. The MME selects an EPS Bearer Identity, which has not yet been assigned to the UE. The MME then builds a
Session Management Request including the PTI, TFT, EPS Bearer QoS parameters (excluding ARP), Protocol
Configuration Options, the EPS Bearer Identity, the Linked EPS Bearer Identity (LBI) and a WLAN
offloadability indication. If the UE has UTRAN or GERAN capabilities and the network supports mobility to
UTRAN or GERAN, the MME uses the EPS bearer QoS parameters to derive the corresponding PDP context
parameters QoS Negotiated (R99 QoS profile), Radio Priority, Packet Flow Id and TI and includes them in the
Session Management Request. If the UE indicated in the UE Network Capability it does not support BSS packet
flow procedures, then the MME shall not include the Packet Flow Id. The MME then signals the Bearer Setup
Request (EPS Bearer Identity, EPS Bearer QoS, Maximum Packet Loss Rate (UL, DL), Session Management
Request, S1-TEID) message to the eNodeB.
The MME may include an indication whether the traffic of this PDN Connection is allowed to be offloaded to
WLAN as described in clause 4.3.23.
5. The eNodeB maps the EPS Bearer QoS to the Radio Bearer QoS. It then signals a RRC Connection
Reconfiguration (Radio Bearer QoS, Session Management Request, EPS RB Identity) message to the UE. The
UE shall store the QoS Negotiated, Radio Priority, Packet Flow Id and TI, which it received in the Session
Management Request, for use when accessing via GERAN or UTRAN. The UE NAS stores the EPS Bearer
3GPP
Release 15 222 3GPP TS 23.401 V15.10.0 (2019-12)
Identity and links the dedicated bearer to the default bearer indicated by the Linked EPS Bearer Identity (LBI).
The UE uses the uplink packet filter (UL TFT) to determine the mapping of traffic flows to the radio bearer. The
UE may provide the EPS Bearer QoS parameters to the application handling the traffic flow. The application
usage of the EPS Bearer QoS is implementation dependent. The UE shall not reject the RRC Connection
Reconfiguration on the basis of the EPS Bearer QoS parameters contained in the Session Management Request.
NOTE 4: How the eNB uses the Maximum Packet Loss Rate (UL, DL) for handover threshold decision, if
provided, is out of scope of 3GPP specifications.
NOTE 5: The details of the Radio Bearer QoS are specified in TS 36.300 [5].
6. The UE acknowledges the radio bearer activation to the eNodeB with a RRC Connection Reconfiguration
Complete message.
7. The eNodeB acknowledges the bearer activation to the MME with a Bearer Setup Response (EPS Bearer
Identity, S1-TEID) message. The eNodeB indicates whether the requested EPS Bearer QoS could be allocated or
not.
The MME shall be prepared to receive this message either before or after the Session Management Response
message (sent in step 9).
8. The UE NAS layer builds a Session Management Response including EPS Bearer Identity. The UE then sends a
Direct Transfer (Session Management Response) message to the eNodeB.
9. The eNodeB sends an Uplink NAS Transport (Session Management Response) message to the MME.
10. Upon reception of the Bearer Setup Response message in step 7 and the Session Management Response message
in step 9, the MME acknowledges the bearer activation to the Serving GW by sending a Create Bearer Response
(EPS Bearer Identity, S1-TEID, User Location Information (ECGI)) message.
11. The Serving GW acknowledges the bearer activation to the PDN GW by sending a Create Bearer Response (EPS
Bearer Identity, S5/S8-TEID, User Location Information (ECGI)) message.
12. If the dedicated bearer activation procedure was triggered by a PCC Decision Provision message from the PCRF,
the PDN GW indicates to the PCRF whether the requested PCC decision (QoS policy) could be enforced or not,
allowing the completion of the PCRF-Initiated IP-CAN Session Modification procedure or the PCEF initiated
IP-CAN Session Modification procedure as defined in TS 23.203 [6], after the completion of IP-CAN bearer
signalling. If requested by the PCRF the PDN GW indicates User Location Information and/or UE Time Zone
Information to the PCRF as defined in TS 23.203 [6].
If the dedicated bearer activation is rejected with a cause indicating that the UE is temporarily not reachable due
to power saving, then the PDN GW re-attempts the same procedure after it receives the indication that the is UE
available for end to end signalling in the subsequent Modify Bearer Request message.
NOTE 6: The exact signalling of step 1 and 12 (e.g. for local break-out) is outside the scope of this specification.
This signalling and its interaction with the dedicated bearer activation procedure are to be specified in
TS 23.203 [6]. Steps 1 and 12 are included here only for completeness.
5.4.2 Bearer modification with bearer QoS update
5.4.2.1 PDN GW initiated bearer modification with bearer QoS update

The PDN GW initiated bearer modification procedure (including EPS Bearer QoS update) for a GTP based S5/S8 is
depicted in figure 5.4.2.1-1. This procedure is used in cases when one or several of the EPS Bearer QoS parameters
QCI, GBR, MBR or ARP are modified (including the QCI or the ARP of the default EPS bearer e.g. due to the HSS
Initiated Subscribed QoS Modification procedure, as described in clause 5.4.2.2) or to modify the APN-AMBR.
Modification from a QCI of resource type non-GBR to a QCI of resource type GBR and vice versa is not supported by
this procedure.
NOTE 1: The QCI of an existing dedicated bearer should only be modified if no additional bearer can be
established with the desired QCI.
3GPP
Release 15 223 3GPP TS 23.401 V15.10.0 (2019-12)
(A) 1. IP-CAN Session

Modification
2. Update Bearer request
3. Update Bearer Request

4. Bearer Modify Request/
Session Management Request
7. Bearer Modify Response

8. Direct Transfer
9. Session Management Response
10. Update Bearer Response
11. Update Bearer response
12. IP-CAN Session
(B) Modification
Figure 5.4.2.1-1: Bearer Modification Procedure with Bearer QoS Update
NOTE 2: Steps 3-10 are common for architecture variants with GTP based S5/S8 and PMIP-based S5/S8. For a
This corresponds to the initial steps of the PCRF-Initiated IP-CAN Session Modification procedure or to the
PCRF response in the PCEF initiated IP-CAN Session Modification procedure as defined in TS 23.203 [6], up to
defined in TS 23.203 [6]. If dynamic PCC is not deployed, the PDN GW may apply local QoS policy.
2. The PDN GW uses this QoS policy to determine that the authorized QoS of a service data flow has changed or
that a service data flow shall be aggregated to or removed from an active bearer. The PDN GW generates the
TFT and updates the EPS Bearer QoS to match the traffic flow aggregate. The PDN GW then sends the Update
Bearer Request (PTI, EPS Bearer Identity, EPS Bearer QoS, APN-AMBR, TFT, Maximum Packet Loss Rate
(UL, DL)) message to the Serving GW. The Procedure Transaction Id (PTI) parameter is used when the
procedure was initiated by a UE Requested Bearer Resource Modification Procedure - see clause 5.4.5. For
APN-AMBR, the EPS bearer identity must refer to a non-GBR bearer.
For a QCI=1 bearer, the Maximum Packet Loss Rate (UL, DL) may be provided by the PDN GW as described in
TS 23.203 [6].
3. The Serving GW sends the Update Bearer Request (PTI, EPS Bearer Identity, EPS Bearer QoS, TFT,
APN-AMBR, Maximum Packet Loss Rate (UL, DL)) message to the MME. If the UE is in ECM-IDLE state the
MME will trigger the Network Triggered Service Request from step 3 (which is specified in clause 5.3.4.3). In
that case the following steps 4-7 may be combined into Network Triggered Service Request procedure or be
performed stand-alone. If only the QoS parameter ARP is modified and if the UE is in ECM IDLE state the
MME shall skip the Network Triggered Service Request. In that case the following steps 4-9 are also skipped
and the MME sends an Update Bearer Response to the Serving GW.
If extended idle mode DRX is enabled for the UE, the MME will trigger Network Triggered Service Request
from step 3 (which is specified in clause 5.3.4.3), and start a timer which is configured to a value smaller than
the GTP re-transmission timer. If the MME receives no response from the UE before the timer expires, the MME
sends an Update Bearer Response with a rejection cause indicating that the UE is temporarily not reachable due
to power saving and, if a Delay Tolerant Connection indication was set for the PDN connection, the MME sets
the internal flag Pending Network Initiated PDN Connection Signalling. The rejection is forwarded by the
Serving GW to the PDN GW. In this case, the steps 4-11 are skipped.
3GPP
Release 15 224 3GPP TS 23.401 V15.10.0 (2019-12)
sending the Update Bearer Request message.
4. The MME builds a Session Management Request including the PTI, EPS Bearer QoS parameters (excluding
ARP), TFT, APN-AMBR, EPS Bearer Identity and a WLAN offloadability indication. If the UE has UTRAN or
GERAN capabilities and the network supports mobility to UTRAN or GERAN, the MME uses the EPS Bearer
QoS parameters to derive the corresponding PDP context parameters QoS Negotiated (R99 QoS profile), Radio
Priority and Packet Flow Id and includes them in the Session Management Request. If the UE indicated in the
UE Network Capability it does not support BSS packet flow procedures, then the MME shall not include the
Packet Flow Id. If the APN-AMBR has changed the MME may update the UE-AMBR if appropriate. The MME
then sends the Bearer Modify Request (EPS Bearer Identity, EPS Bearer QoS, Session Management Request,
UE-AMBR, Maximum Packet Loss Rate (UL, DL)) message to the eNodeB.
5. The eNodeB maps the modified EPS Bearer QoS to the Radio Bearer QoS. It then signals a RRC Connection
Reconfiguration (Radio Bearer QoS, Session Management Request, EPS RB Identity) message to the UE. The
UE shall store the QoS Negotiated, Radio Priority, Packet Flow Id, which it received in the Session Management
Request, for use when accessing via GERAN or UTRAN. If the APN-AMBR has changed, the UE stores the
modified APN-AMBR value and sets the MBR parameter of the corresponding non-GBR PDP contexts (of this
PDN connection) to the new value. The UE uses the uplink packet filter (UL TFT) to determine the mapping of
traffic flows to the radio bearer. The UE may provide EPS Bearer QoS parameters to the application handling the
traffic flow(s). The application usage of the EPS Bearer QoS is implementation dependent. The UE shall not
reject the Radio Bearer Modify Request on the basis of the EPS Bearer QoS parameters contained in the Session
Management Request. The UE shall set its TIN to "GUTI" if the modified EPS bearer was established before
ISR activation.
NOTE 4: The details of the Radio Bearer QoS are specified in TS 36.300 [5].
6. The UE acknowledges the radio bearer modification to the eNodeB with a RRC Connection Reconfiguration
Complete message.
7. The eNodeB acknowledges the bearer modification to the MME with a Bearer Modify Response (EPS Bearer
Identity) message. With this message, the eNodeB indicates whether the requested EPS Bearer QoS could be
allocated or not.
message (sent in step 9).
10. Upon reception of the Bearer Modify Response message in step 7 and the Session Management Response
message in step 9, the MME acknowledges the bearer modification to the Serving GW by sending an Update
Bearer Response (EPS Bearer Identity, User Location Information (ECGI)) message.
11. The Serving GW acknowledges the bearer modification to the PDN GW by sending an Update Bearer Response
(EPS Bearer Identity, User Location Information (ECGI)) message.
12. If the Bearer modification procedure was triggered by a PCC Decision Provision message from the PCRF, the
PDN GW indicates to the PCRF whether the requested PCC decision (QoS policy) could be enforced or not by
sending a Provision Ack message allowing the completion of the PCRF-Initiated IP-CAN Session Modification
procedure or the PCEF initiated IP-CAN Session Modification procedure as defined in TS 23.203 [6], after the
completion of IP-CAN bearer signalling. If requested by the PCRF the PDN GW indicates User Location
Information and/or UE Time Zone Information to the PCRF as defined in TS 23.203 [6].
If the Bearer modification is rejected with a cause indicating that the UE is temporarily not reachable due to
power saving, then the PDN GW re-attempts the same procedure after it receives the indication that the is UE
3GPP
Release 15 225 3GPP TS 23.401 V15.10.0 (2019-12)
This signalling and its interaction with the bearer activation procedure are to be specified in
5.4.2.2 HSS Initiated Subscribed QoS Modification

The HSS Initiated Subscribed QoS Modification for a GTP-based S5/S8 is depicted in figure 5.4.2.2-1.
1. Insert Subscriber data

1a. Insert Subscriber data Ack
. 2a. UE Ctxt Update
2b. Modify Bearer Command
3. Modify Bearer Command
(A) 4. PCEF Initiated IP-CAN

6. Procedure as in TS 23.401, steps 3 to 10 of

Figure 5.4.2.1-1 or steps 3 to 8 of Figure 5.4.3-1
(B)
8. Provision Ack
Figure 5.4.2.2-1: HSS Initiated Subscribed QoS Modification
NOTE 1: For a PMIP-based S5/S8, procedure steps (A) and steps (B) are defined in TS 23.402 [2]. Steps 3, 4, 5, 7
and 8 concern GTP based S5/S8.
1. The HSS sends an Insert Subscriber Data (IMSI, Subscription Data) message to the MME. The Subscription
Data includes EPS subscribed QoS (QCI, ARP) and the subscribed UE-AMBR and APN-AMBR.
1a. The MME updates the stored Subscription Data and acknowledges the Insert Subscriber Data message by
returning an Insert Subscriber Data Ack (IMSI) message to the HSS (see clause 5.3.9.2).
2a If only the subscribed UE-AMBR has been modified, the MME calculates a new UE-AMBR value as described
in clause 4.7.3 and may then signal a modified UE-AMBR value to the eNodeB by using S1-AP UE Context
Modification Procedure. The HSS Initiated Subscribed QoS Modification Procedure ends after completion of the
UE Context Modification Procedure.
2b. If the QCI and/or ARP and/or subscribed APN-AMBR has been modified and there is related active PDN
connection with the modified QoS Profile the MME sends the Modify Bearer Command (EPS Bearer Identity,
EPS Bearer QoS, APN-AMBR) message to the Serving GW. The EPS Bearer Identity identifies the default
bearer of the affected PDN connection. The EPS Bearer QoS contains the EPS subscribed QoS profile to be
updated.
3. The Serving GW sends the Modify Bearer Command (EPS Bearer Identity, EPS Bearer QoS, APN-AMBR)
message to the PDN GW.
4. If PCC infrastructure is deployed, the PDN GW informs the PCRF about the updated EPS Bearer QoS and APN-
AMBR. The PCRF sends new updated PCC decision to the PDN GW. This corresponds to the PCEF-initiated
IP-CAN Session Modification procedure as defined in TS 23.203 [6].
3GPP
Release 15 226 3GPP TS 23.401 V15.10.0 (2019-12)
5. The PDN GW modifies the default bearer of each PDN connection corresponding to the APN for which
subscribed QoS has been modified. If the subscribed ARP parameter has been changed, the PDN GW shall also
modify all dedicated EPS bearers having the previously subscribed ARP value unless superseded by PCRF
decision. The PDN GW then sends the Update Bearer Request (EPS Bearer Identity, EPS Bearer QoS, TFT,
APN-AMBR) message to the Serving GW.
NOTE 2: As no PTI is included the MME use protocol specific details, as described in TS 29.274 [43], to determine
if the Update Bearer Request was triggered by this procedure or not.
6. If the QCI and/or ARP parameter(s) have been modified, steps 3 to 10, as described in clause 5.4.2.1, Figure
5.4.2.1-1, are invoked. If neither the QCI nor the ARP have been modified, but instead only the APN-AMBR
was updated, steps 3 to 8, as described in clause 5.4.3, Figure 5.4.3-1, are invoked.
(EPS Bearer Identity, User Location Information (ECGI)) message. If the bearer modification fails the PDN GW
deletes the concerned EPS Bearer.
8. The PDN GW indicates to the PCRF whether the requested PCC decision was enforced or not by sending a
Provision Ack message.
5.4.3 PDN GW initiated bearer modification without bearer QoS update

The bearer modification procedure without bearer QoS update is used to update the TFT for an active default or
dedicated bearer, to modify the APN-AMBR, to retrieve User Location from the MME, to inform PCO to UE or to
instruct the MME (e.g. to activate/deactivate the location reporting).
The procedure for a GTP based S5/S8 is depicted in figure 5.4.3-1. In this procedure there is no need to update the
underlying radio bearer(s). This procedure may be triggered if the APN-AMBR is changed by the PCRF/PDN GW.
1. IP-CAN Session
(A) Modification
4. Downlink NAS Transport
5. Direct Transfer
6. Direct Transfer
7. Uplink NAS Transport
10. IP-CAN Session

(B) Modification
Figure 5.4.3-1: Bearer Modification Procedure without Bearer QoS Update
concern GTP based S5/S8. Steps 3-8 may also be used within the HSS Initiated Subscribed QoS
Modification.
3GPP
Release 15 227 3GPP TS 23.401 V15.10.0 (2019-12)
This corresponds to the beginning of the PCRF-initiated IP-CAN Session Modification procedure or to the PCRF
response in the PCEF initiated IP-CAN Session Modification procedure as defined in TS 23.203 [6], up to the
point that the PDN GW requests IP-CAN Bearer Signalling. The PCC decision provision message may indicate
that User Location Information and/or UE Time Zone Information is to be provided to the PCRF as defined in
TS 23.203 [6]. If dynamic PCC is not deployed, the PDN GW may apply local QoS policy.
2. The PDN GW uses this QoS policy to determine that a service data flow shall be aggregated to or removed from
an active bearer. The PDN GW generates the TFT and determines that no update of the EPS Bearer QoS is
needed. The PDN GW then sends the Update Bearer Request (PTI, EPS Bearer Identity, APN-AMBR, TFT,
Retrieve Location) message to the Serving GW. The Procedure Transaction Id (PTI) parameter is used when the
procedure was initiated by a UE Requested Bearer Resource Modification procedure - see clause 5.4.5. "Retrieve
Location" is indicated if requested by the PCRF. If the PDN GW initiated bearer modification procedure was
triggered by a UE requested bearer resource modification procedure and if 3GPP PS Data Off UE Status was
present in the Bearer Resource Command PCO, the PDN GW shall include the 3GPP PS Data Off Support
Indication in the Update Bearer Request PCO.
3. The Serving GW sends the Update Bearer Request (PTI, EPS Bearer Identity, APN-AMBR, TFT, Retrieve
Location) message to the MME. If the UE is in ECM-IDLE state (and extended idle mode DRX is not enabled)
the MME will trigger the Network Triggered Service Request from step 3 (which is specified in clause 5.3.4.3).
In that case the following steps 4-7 may be combined into Network Triggered Service Request procedure or be
performed stand-alone. If both the PCO and the TFT are absent and the APN-AMBR has not been modified, the
MME shall skip the following steps 4-7.
If the UE is in ECM-IDLE state and extended idle mode DRX is enabled for the UE, the MME will trigger
Network Triggered Service Request from step 3 (which is specified in clause 5.3.4.3), , and start a timer which is
configured to a value smaller than the GTP re-transmission timer . If the MME receives no response from the UE
before the timer expires, the MME sends an Update Bearer Response with a rejection cause indicating that UE is
temporarily not reachable due to power saving and then sets the internal flag Pending Network Initiated PDN
Connection Signalling. The rejection is forwarded by the Serving GW to the PDN GW. In this case, the steps 4-9
are skipped.
sending the Update Bearer Request message.
NOTE 3: The PCO can be set by the PDN GW in accordance with the TS 23.380 [75].
4. The MME builds a Session Management Request message including the TFT, APN-AMBR, EPS Bearer Identity
and a WLAN offloadability indication. The MME then sends a Downlink NAS Transport (Session Management
Configuration) message to the eNodeB. If the APN AMBR has changed, the MME may also update the UE
AMBR. And if the UE-AMBR is updated, the MME signal a modified UE-AMBR value to the eNodeB by using
S1-AP UE Context Modification Procedure.
5. The eNodeB sends the Direct Transfer (Session Management Request) message to the UE. The UE uses the
uplink packet filter (UL TFT) to determine the mapping of traffic flows to the radio bearer. The UE stores the
modified APN-AMBR value and sets the MBR parameter of the corresponding non-GBR PDP contexts (of this
PDN connection) to the new value. The UE shall set its TIN to "GUTI" if the modified EPS bearer was
established before ISR activation.
8. If the procedure is performed without steps 4-7 and location retrieval is requested and the UE is
ECM_CONNECTED and unless the MME is configured not to retrieve ECGI from the eNodeB under this
condition, the MME uses the Location Reporting Procedure described in clause 5.9.1 to retrieve the ECGI from
the eNodeB. The MME acknowledges the bearer modification to the Serving GW by sending an Update Bearer
3GPP
Release 15 228 3GPP TS 23.401 V15.10.0 (2019-12)
Response (EPS Bearer Identity, User Location Information (ECGI)) message. The MME includes the last known
User Location information.
NOTE 4: Based on operator policy and local regulation the MME may, instead of using the Location Reporting
Procedure described in clause 5.9.1 to retrieve the ECGI from the eNodeB, use the last known User
Location information obtained from e.g. attach procedure, tracking area update procedure, etc.
(EPS Bearer Identity, User Location Information (ECGI)) message.
10. If the bearer modification procedure was triggered by a PCC Decision Provision message from the PCRF, the
PDN GW indicates to the PCRF whether the requested PCC decision (QoS policy) could be enforced or not by
sending a Provision Ack message. This then allows the PCRF-Initiated IP-CAN Session Modification procedure
or the PCEF initiated IP-CAN Session Modification procedure as defined in TS 23.203 [6] to continue and
eventually conclude, proceeding after the completion of IP-CAN bearer signalling. If requested by the PCRF the
TS 23.203 [6].
If the bearer modification is rejected with a cause indicating that the UE is temporarily not reachable due to
power saving, then the PDN GW re-attempts the same procedure after it receives the indication that the is UE
This signalling and its interaction with the bearer activation procedure are to be specified in
5.4.4 Bearer deactivation
5.4.4.1 PDN GW initiated bearer deactivation

The bearer deactivation procedure for a GTP based S5/S8 is depicted in figure 5.4.4.1-1. This procedure can be used to
deactivate a dedicated bearer or deactivate all bearers belonging to a PDN address. If the default bearer belonging to a
PDN connection is deactivated, the PDN GW deactivates all bearers belonging to the PDN connection.
When the last bearer belonging to the last PDN connection of a given APN is released, the PGW may forward to the
MME the APN Rate Control Status for storing it in the MM context according to clause 4.7.7.3.
3GPP
Release 15 229 3GPP TS 23.401 V15.10.0 (2019-12)
UE eNodeB PDN GW PCRF HSS

MME SGSN Serving GW
1. IP-CAN Session
(A)
Modification
2. Delete Bearer Request
3a. Delete Bearer Request

4a. Detach Request 3b. Delete Bearer Request
4b. Triggering for reactivation in ECM-IDLE
4c. Deactivate Bearer Request
6a. RRC Connection Reconfiguration complete
6b. Deactivate Bearer Response
7a. Direct Transfer

7b. Deactivate EPS Bearer Context Accept
7c. Detach Accept
8a. Delete Bearer Response

8b. Delete Bearer Response
9. Delete Bearer Response

10. IP-CAN Session
Modification
11. Signalling Connection Release (B)
Figure 5.4.4.1-1: PDN GW Initiated Bearer Deactivation
concern GTP-based S5/S8.
1. If dynamic PCC is not deployed, the PDN GW is triggered to initiate the Bearer Deactivation procedure due
either a QoS policy or on request from the MME (as outlined in clause 5.4.4.2) or on intra-node signalling
request from the HeNB to release the LIPA PDN Connection. Optionally, the PCRF sends QoS policy to the
PDN GW. This corresponds to the initial steps of the PCRF-initiated IP-CAN Session Modification procedure or
the response to the PCEF initiated IP-CAN Session Modification procedure as defined in TS 23.203 [6], up to
defined in TS 23.203 [6]. If dynamic PCC is not deployed, the PDN GW may apply local QoS policy. The PDN
GW initiated Bearer deactivation is also performed when handovers occur from 3GPP to non-3GPP, in which
case, the default bearer and all the dedicated bearers associated with the PDN address are released, but the PDN
address is kept in the PDN GW.
For an emergency PDN connection the PDN GW initiates the deactivation of all bearers of that emergency PDN
connection when the PDN connection is inactive (i.e. not transferring any packets) for a configured period of
time or when triggered by dynamic PCC.
2. The PDN GW sends a Delete Bearer Request (PTI, EPS Bearer Identity, Causes and, optionally, APN Rate
Control Status according to clause 4.7.7.3) message to the Serving GW. The Procedure Transaction Id (PTI)
parameter in this step and in the following steps is only used when the procedure was initiated by a UE
Requested Bearer Resource Modification Procedure - see clause 5.4.5. This message can include an indication
that all bearers belonging to that PDN connection shall be released. The PDN GW includes 'Cause' IE in the
3GPP
Release 15 230 3GPP TS 23.401 V15.10.0 (2019-12)
Delete Bearer Request message and sets the IE to 'RAT changed from 3GPP to Non-3GPP' if the Delete Bearer
Request message is caused by a handover from 3GPP to non-3GPP.
3a. The Serving GW sends the Delete Bearer Request (PTI, EPS Bearer Identity, Cause and, optionally, APN Rate
Control Status) message to the MME. This message can include an indication that all bearers belonging to that
PDN connection shall be released.
3b. If ISR is activated, the Serving GW sends the Delete Bearer Request (PTI, EPS Bearer Identity, Cause) message
to the SGSN. This message can include an indication that all bearers belonging to that PDN connection shall be
released, and the SGSN releases all bearer resources of the PDN connection.
NOTE 2: If all the bearers belonging to a UE are released due to a handover from 3GPP to non-3GPP, the SGSN
changes the MM state of the UE to IDLE (GERAN network) or PMM-DETACHED (UTRAN network).
If ISR is activated, upon receiving Delete Bearer Request from SGW for the last PDN connection for a given
UE, MME shall locally de-activate ISR.
NOTE 3: In this case, SGSN locally de-activates ISR as well (see TS 23.060 [7]).
Steps 4 to 7 are not performed if at least one of the following three conditions is fulfilled:
(i) The UE is in ECM-IDLE and the last PDN connection of the UE is not being deleted and the Delete Bearer
Request received from the Serving GW does not contain the cause "reactivation requested", which has been sent
from the PDN GW;
(ii) UE is in ECM-IDLE and the last PDN connection is deleted due to ISR deactivation;
(iii) UE is in ECM-IDLE and the last PDN connection is deleted in 3GPP due to handover to non-3GPP access.
When steps 4 to 7 are not performed, the EPS bearer state is synchronized between the UE and the network at the next
ECM-IDLE to ECM-CONNECTED transition (e.g. Service Request or TAU procedure).
4a. If the last PDN connection of a UE that does not support "Attach without PDN connectivity" is being released
and the bearer deletion is neither due to ISR deactivation nor due to handover to non-3GPP accesses, the MME
explicitly detaches the UE by sending a Detach Request message to the UE. If the UE is in ECM-IDLE state the
MME initiates paging via Network Triggered Service Request procedure in clause 5.3.4.3 from step 3a onwards
in order to inform UE of the request. Steps 4b to 7b are skipped in this case, and the procedure continues from
step 7c.
4b. If the UE is in ECM-IDLE state and the reason for releasing PDN connection is "reactivation requested", the
MME initiates paging via Network Triggered Service Request procedure in clause 5.3.4.3 from step 3a onwards
in order to inform UE of the request and step 4c is performed after completion of the paging.
4c. If the release of the bearer in E-UTRAN has already been signalled to the MME, steps 4c to 7 are omitted.
Otherwise, if this is not the last PDN connection for the UE which is being released, the MME sends the S1-AP
Deactivate Bearer Request (EPS Bearer Identity) message to the eNodeB. The MME builds a NAS Deactivate
EPS Bearer Context Request message including the EPS Bearer Identity and a WLAN offloadability indication,
and includes it in the S1-AP Deactivate Bearer Request message. When the bearer deactivation procedure was
originally triggered by a UE request, the NAS Deactivate EPS Bearer Context Request message includes the
PTI.
WLAN as described in clause 4.3.23 if the PDN connection is not released.
5. The eNodeB sends the RRC Connection Reconfiguration message including the EPS Radio Bearer Identity to
release and the NAS Deactivate EPS Bearer Context Request message to the UE.
6a. The UE RRC releases the radio bearers indicated in the RRC message in step 5, and indicates the radio bearer
status to the UE NAS. Then the UE NAS removes the UL TFTs and EPS Bearer Identity according to the radio
bearer status indication from the UE RRC. The UE responds to the RRC Connection Reconfiguration Complete
message to the eNodeB.
3GPP
Release 15 231 3GPP TS 23.401 V15.10.0 (2019-12)
6b. The eNodeB acknowledges the bearer deactivation to the MME with a Deactivate Bearer Response (EPS Bearer
Identity, ECGI, TAI, PSCell ID, Secondary RAT usage data) message. If the PLMN has configured secondary
RAT usage reporting and the eNodeB has Secondary RAT usage data to report, the Secondary RAT usage data is
included.
The PSCell ID is included if Dual Connectivity is active for the UE in the RAN.
message sent in step 7b, and before or after, any Detach Request message sent in step 7c.
7a The UE NAS layer builds a Deactivate EPS Bearer Context Accept message including EPS Bearer Identity. The
UE then sends a Direct Transfer (Deactivate EPS Bearer Context Accept) message to the eNodeB.
7b. The eNodeB sends an Uplink NAS Transport (Deactivate EPS Bearer Context Accept) message to the MME.
7c. If the UE receives the Detach Request message from the MME in the step 4a, the UE sends a Detach Accept
message to the MME any time after step 4a. The eNodeB forwards this NAS message to the MME along with
the TAI+ECGI of the cell which the UE is using.
NOTE 4: The UE may not be able to send this message, e.g. when the UE is out of coverage of E-UTRAN due to
mobility to non-3GPP access.
7a,b,c If Dual Connectivity is active for the UE, the PSCell ID shall be included in the Uplink NAS Transport sent
by the eNodeB.
8a. After reception of both the Deactivate Bearer Response message in step 6b and the Deactivate EPS Bearer
Context Accept message in step 7b, the MME deletes the bearer context related to the deactivated EPS bearer
and acknowledges the bearer deactivation to the Serving GW by sending a Delete Bearer Response (EPS Bearer
Identity, User Location Information (ECGI), RAN/NAS Release Cause, Secondary RAT usage data) message. If
the MME received Secondary RAT usage data in step 6b, the MME shall include it in this message. If extended
idle mode DRX is enabled, then the MME acknowledges the bearer deactivation to the Serving GW and at the
same time the MME initiates the deactivation towards the UE. If the S1 connection had already been released by
the eNB due to radio link failure and the MME receives a Delete Bearer Request while it is still deferring the
sending of the S1 release (see clause 5.3.5), the MME shall include in the Delete Bearer Response the RAN/NAS
Cause received in the S1 Release due to radio link failure procedure.
8b The SGSN deletes PDP Context related to the deactivated EPS bearer and acknowledges the bearer deactivation
to the Serving GW by sending a Delete Bearer Response (EPS Bearer Identity, User Location Information
(CGI/SAI)) message. If extended idle mode DRX is enabled, then the SGSN acknowledges the bearer
deactivation to the Serving GW and at the same time the SGSN initiates the deactivation towards the UE.
9. If ISR is activated, after receiving the two Delete Bearer Response messages from the MME and the SGSN, or if
ISR is not activated, after receiving the Delete Bearer Response messages from the MME, the Serving GW
deletes the bearer context related to the deactivated EPS bearer acknowledges the bearer deactivation to the PDN
GW by sending a Delete Bearer Response (EPS Bearer Identity, User Location Information (ECGI or CGI/SAI),
Secondary RAT usage data) message. If the MME and/or SGSN sent UE's Location Information and/or UE
Time Zone in step 8a and/or step 8b, the Serving GW includes the User Location Information and/or UE Time
Zone Information with the least age in this message. The Serving GW includes the Secondary RAT usage data if
it was received in step 8a and if PGW secondary RAT usage data reporting is active.
10. The PDN GW deletes the bearer context related to the deactivated EPS bearer. If the dedicated bearer
deactivation procedure was triggered by receiving a PCC decision message from the PCRF, the PDN GW
indicates to the PCRF whether the requested PCC decision was successfully enforced by completing the PCRF-
initiated IP-CAN Session Modification procedure or the PCEF initiated IP-CAN Session Modification procedure
as defined in TS 23.203 [6], proceeding after the completion of IP-CAN bearer signalling. If requested by the
PCRF the PDN GW indicates User Location Information and/or UE Time Zone Information to the PCRF as
defined in TS 23.203 [6]. If available, the PDN GW shall send RAN/NAS Release Cause to the PCRF as defined
in TS 23.203 [6].
11. If the UE is being explicitly detached, the MME releases the S1-MME signalling connection for the UE by
sending an S1 Release Command (Cause) message to the eNodeB. The details of this step are covered in the "S1
Release Procedure", as described in clause 5.3.5 by step 4 to step 6.
3GPP
Release 15 232 3GPP TS 23.401 V15.10.0 (2019-12)
This signalling and its interaction with the dedicated bearer activation procedure are to be specified in
If all the bearers belonging to a UE that does not support "Attach without PDN connectivity" are released, the MME
shall change the MM state of the UE to EMM-DEREGISTERED and the MME sends the S1 Release Command to the
eNodeB, which initiates the release of the RRC connection for the given UE if it is not released yet, and returns an S1
Release Complete message to the MME.
If all bearers of an emergency attached UE are deactivated the MME may initiate the explicit MME-Initiated Detach
procedure. Regardless of the outcome of any explicit Detach procedure the MME changes the EMM state of the UE to
EMM-DEREGISTERED and the MME sends the S1 Release Command to the eNodeB if it is not yet released.
If the default bearer belonging to a PDN connection is deactivated, the MME determines the Maximum APN
Restriction for the remaining PDN connections and stores this new value for the Maximum APN Restriction. In
addition if ISR is activated the SGSN determines the Maximum APN Restriction for the remaining bearer contexts and
stores this new value for the Maximum APN Restriction.
5.4.4.2 MME Initiated Dedicated Bearer Deactivation

MME initiated Dedicated Bearer Deactivation is depicted in Figure 5.4.4.2-1 below. This procedure deactivates
dedicated bearers. Default bearers are not affected. To initiate the release of the full PDN connection including the
default bearer, the MME uses the UE or MME requested PDN disconnection procedure defined in clause 5.10.3.
0. Radio Bearer Release

1. Indication of Bearer Release
2. Delete Bearer Command
3. Delete Bearer Command
(A)
7. Procedure as in TS 23.401,
Figure 5.4.4.1-1, between step 4 and step 7
8. Delete Bearer Response
9. Delete Bearer (B)

Response
Figure 5.4.4.2-1: MME initiated Dedicated Bearer Deactivation
NOTE 1: For a PMIP-based S5/S8, procedure steps (A) and steps (B) are defined in TS 23.402 [2]. Steps 3, 4, 5
and 9 concern GTP based S5/S8
0. Radio bearers for the UE in the ECM-CONNECTED state may be released due to local reasons (e.g. abnormal
resource limitation or radio conditions do not allow the eNodeB to maintain all the allocated GBR bearers: it is
not expected that non-GBR bearers are released by the eNodeB unless caused by error situations). The UE
deletes the bearer contexts related to the released radio bearers.
3GPP
Release 15 233 3GPP TS 23.401 V15.10.0 (2019-12)
1. When the eNodeB releases radio bearers in step 0, it sends an indication of bearer release to the MME. This
indication may be e.g. the Bearer Release Request (EPS Bearer Identity) message to the MME, or alternatively
Initial Context Setup Complete, Handover Request Ack and UE Context Response, Path Switch Request may
also indicate the release of a bearer.
The eNodeB includes the ECGI and TAI in the indication sent to the MME. The eNodeB also includes the
PSCell ID if Dual Connectivity is active for the UE in the RAN.
the Secondary RAT usage data is included.
2. The MME sends the Delete Bearer Command (EPS Bearer Identity, User Location Information, UE Time Zone,
RAN/NAS Release Cause if available, Secondary RAT usage data) message per PDN connection to the Serving
GW to deactivate the selected dedicated bearer. RAN/NAS Release Cause indicates the RAN release cause
and/or the NAS release cause. RAN/NAS Release Cause is only sent by the MME to the PDN GW if this is
permitted according to MME operator's policy. If the MME received Secondary RAT usage data in step 1, the
MME shall include it in this message.
3. The Serving GW sends the Delete Bearer Command (EPS Bearer Identity, User Location Information, UE Time
Zone, RAN/NAS Release Cause, Secondary RAT usage data) message per PDN connection to the PDN GW.
The Serving GW includes the Secondary RAT usage data it in this message if it was received in the previous
message and if PGW secondary RAT usage data reporting is active.
4. If PCC infrastructure is deployed, the PDN GW informs the PCRF about the loss of resources by means of a
PCEF-initiated IP-CAN Session Modification procedure as defined in TS 23.203 [6] and provides the User
Location Information, UE Time Zone and RAN/NAS Release cause (if available) received in the Delete Bearer
Command from the S-GW if requested by the PCRF as defined in TS 23.203 [6]. The PCRF sends an updated
PCC decision to the PDN GW.
NOTE 2: User Location Information and UE Time Zone might not be available if the MME or the Serving GW are
of a previous release and did not provide this information.
5. The PDN GW sends a Delete Bearer Request (EPS Bearer Identity) message to the Serving GW.
6. The Serving GW sends the Delete Bearer Request (EPS Bearer Identity) message to the MME.
7. Steps between steps 4 and 7, as described in clause 5.4.4.1, are invoked. This is omitted if the bearer deactivation
was triggered by the eNodeB in step 0 and step 1.
This is also omitted if the MME initiated bearer release due to failed bearer set up during handover, the UE and
the MME deactivate the failed contexts locally without peer-to peer ESM signalling.
8. The MME deletes the bearer contexts related to the deactivated EPS bearer and acknowledges the bearer
deactivation to the Serving GW by sending a Delete Bearer Response (EPS Bearer Identity, User Location
Information (ECGI), Secondary RAT usage data) message. The MME includes the Secondary RAT usage data if
it received this in step 7 from the eNodeB.
9. The Serving GW deletes the bearer context related to the deactivated EPS bearer and acknowledges the bearer
deactivation to the PDN GW by sending a Delete Bearer Response (EPS Bearer Identity, Secondary RAT usage
data) message. The Serving GW includes the Secondary RAT usage data if it was received in step 8 and if PGW
secondary RAT usage data reporting is active.
5.4.5 UE requested bearer resource modification

The UE requested bearer resource modification procedure for an E-UTRAN is depicted in figure 5.4.5-1. The procedure
allows the UE to request for a modification of bearer resources (e.g. allocation or release of resources) for one traffic
flow aggregate with a specific QoS demand. Alternatively, the procedure allows the UE to request for the modification
of the packet filters used for an active traffic flow aggregate, without changing QoS. If accepted by the network, the
request invokes either the Dedicated Bearer Activation Procedure, the Bearer Modification Procedure or a dedicated
bearer is deactivated using the PDN GW Initiated Bearer Deactivation Procedure. The procedure is used by the UE
when the UE already has a PDN connection with the PDN GW. A UE can send a subsequent Request Bearer Resource
Modification Message before the previous procedure is completed. The UE requested bearer resource modification
procedure is used to indicate the change of 3GPP PS Data Off UE Status to the PDN GW via the PCO, only if the UE
has been previously informed that the PDN GW supports the 3GPP PS Data Off feature. When a UE supports only
3GPP
Release 15 234 3GPP TS 23.401 V15.10.0 (2019-12)
Control Plane CIoT EPS Optimisation as defined in clause 5.3.4B the UE need not support the UE requested bearer
resource modification procedure in order to modify the traffic flow aggregate, as the UE does not support any DRBs.
The UE may need to support UE requested bearer resource modification procedure for other purposes, e.g. header
compression negotiation, see TS 24.301 [46].
The UE supporting 15 EPS bearers as defined in clause 4.12 shall not initiate a UE requested bearer resource
modification procedure that would trigger the establishment of a new EPS bearer, if it has already 8 EPS bearers
established and the UE has not received an Indication for support of 15 EPS bearers per UE or has received cause #65
"maximum number of EPS bearers reached".
In this procedure the UE signals a Traffic Aggregate Description (TAD) which is a partial TFT, together with a
Procedure Transaction Identifier (PTI), and an EPS Bearer Identity (when the TAD operation is modify, delete or add to
an existing packet filter). When the TAD operation is modify or delete, the packet filter identifiers of the TAD are the
same as the TFT packet filter identifiers of the referenced EPS Bearer (as the concatenation of the TFT packet filter
identifier and the EPS Bearer identifier represents a unique packet filter identifier within the PDN connection), for
which resources are being modified. The TAD is released by the UE after it has received a TFT related to the current
PTI from the network.
1. Request Bearer Resource Modification

2. Bearer Resource Command
3. Bearer Resource Command

(A) 4. PCEF Initiated IP-CAN
Session Modification, begin
5. Dedicated bearer activation as per Figure 5.4.1-1, from step 2 to 11; or

Bearer modification procedure as per Figure 5.4.2.1-1, from step 2 to 11, or as per
Figure 5.4.3-1, from step 2 to 9; or Dedicated bearer deactivation procedure as per
Figure 5.4.4.1-1, from step 2 to 9; or Bearer modification without bearer QoS update
as per Figure 5.4.3-1, from step 4 to 7.
Figure 5.4.3-1, from step 2 to 9 6. PCEF Initiated IP-CAN
Session Modification, end
Figure 5.4.5-1: UE requested bearer resource modification
NOTE 1: Steps 1, 2, and 5 are common for architecture variants with GTP-based S5/S8 and PMIP-based S5/S8.
The procedure steps marked (A) differ in the case that PMIP-based S5/S8 is employed and is defined in
TS 23.402 [2].
If the bearer resource modification procedure is initiated for re-negotiation of header compression configuration for
Control Plane CIoT EPS Optimisation, the MME shall not send Bearer Resource Command message to the Serving
GW. In this case, the Bearer Modification Procedures (according to clause 5.4.3) is invoked and only the steps from 4 to
7 are performed.
1. The UE sends a Request Bearer Resource Modification (LBI, PTI, EPS Bearer Identity, QoS, TAD, Protocol
Configuration Options) message to the MME. If the UE was in ECM-IDLE mode, this NAS message is preceded
by the Service Request procedure.
The TAD indicates one requested operation (add, modify, or delete packet filters). If traffic flows are added, the
TAD includes the packet filter(s) (consisting of the packet filter information including packet filter precedence,
but without a packet filter identifier) to be added. The UE also sends the QCI requested and GBR, if applicable,
for the added traffic flows. If the UE wants to link the new packet filter(s) to an existing packet filter to enable
the usage of existing bearer resources for the new packet filter(s), the UE shall provide an existing packet filter
identifier together with the new packet filter(s). If the new packet filter(s) are not linked to an existing packet
filter the UE shall provide at least one UL packet filter in the TAD. In case a downlink only traffic flow(s) is to
be added the UE shall provide an UL packet filter that effectively disallows any useful packet flows (see
clause 15.3.3.4 of TS 23.060 [7] for an example of such packet filter).
3GPP
Release 15 235 3GPP TS 23.401 V15.10.0 (2019-12)
NOTE 2: Receiving at least one UL packet filter from the UE ensures that a valid state for the TFT settings of the
PDN connection as defined in clause 15.3.0 of TS 23.060 [7] is maintained in case the TAD add operation
results in the establishment of a new dedicated EPS bearer.
If the UE wants to change the GBR in addition, the UE includes the GBR requirement of the EPS Bearer. The
TAD is released when the procedure is completed.
When only requesting for a modification of GBR (i.e. decrease or increase), the TAD shall include the existing
packet filter identifier(s) for which the GBR change request applies to. The UE includes the GBR requirement of
the EPS Bearer. The TAD is released when the procedure is completed.
When requesting for a modification of packet filter(s) (e.g. change of port number), the TAD shall include
packet filter identifier(s) for which the change request applies to together with the changed packet filter
information.
If the UE requests for deletion of traffic flows, the TAD includes the packet filter identifier(s) to be deleted. If
the packet filters to be deleted were mapped to a GBR Bearer, the UE includes the new GBR requirement of the
EPS Bearer.
The UE sends the Linked Bearer Id (LBI) only when the requested operation is add, to indicate to which PDN
connection the additional bearer resource is linked to. The EPS Bearer Identity is only sent when the requested
operation is modify or delete. The Procedure Transaction Id is dynamically allocated by the UE for this
procedure. The UE should ensure as far as possible that previously used PTI values are not immediately reused.
The PTI is released when the procedure is completed. Protocol Configuration Options may be used to transfer
application level parameters between the UE and the PDN GW (see TS 23.228 [52]), and are sent transparently
through the MME and the Serving GW.
If the PDN GW indicated support for the 3GPP PS data off feature during PDN connection setup, the UE shall
include in the PCO the 3GPP PS Data Off Support Indication, which indicates whether the user has activated or
deactivated 3GPP PS Data Off.
2. The MME sends the Bearer Resource Command (IMSI, LBI, PTI, EPS Bearer Identity, QoS, TAD, Protocol
Configuration Options) message to the selected Serving GW. The MME validates the request using the Linked
Bearer Id. The same Serving GW address is used by the MME as for the EPS Bearer identified by the Linked
Bearer Id received in the Request Bearer Resource Modification message.
3. The Serving GW sends the Bearer Resource Command (IMSI, LBI, PTI, EPS Bearer Identity, QoS, TAD,
Protocol Configuration Options) message to the PDN GW. The Serving GW sends the message to the same PDN
GW as for the EPS Bearer identified by the Linked Bearer Id.
4. The PDN GW may either apply a locally configured QoS policy, or it may interact with the PCRF to trigger the
appropriate PCC decision, which may take into account subscription information. This corresponds to the
beginning of a PCEF-initiated IP-CAN Session Modification procedure as defined in TS 23.203 [6], up to the
point that the PDN GW requests IP-CAN Bearer Signalling. When interacting with PCRF, the PDN GW
provides to the PCRF the content of the TAD and, if applicable, the GBR change (increase or decrease)
associated with the packet filter information contained in the TAD. The GBR change is either calculated from
the current Bearer QoS and the requested Bearer QoS from the UE, or set to the requested GBR if the TAD
indicates an add operation and no EPS Bearer Identity was received. If the TAD indicates an add operation, the
requested QCI is also provided to the PCRF unless an existing packet filter identifier is provided together with
the new packet filter.
The PCC decision provision message may indicate that User Location Information and/or UE Time Zone
information is to be provided to the PCRF as defined in TS 23.203 [6].
If the TAD operation is modify, delete, a request for changing the GBR, or add with a link to existing packet
filter(s), then the PDN GW provides to the PCRF the SDF filter identifier(s), previously assigned on Gx, that
correspond to the received packet filter identifiers of the EPS bearer indicated by the received EPS bearer
identity.
NOTE 3: The ability of the PCRF to handle multiple PCC rules in the same request depends on operator policy. It
is therefore recommended that the UE avoids providing references to multiple packet filters for different
applications and services.
3GPP
Release 15 236 3GPP TS 23.401 V15.10.0 (2019-12)
If the PDN GW detects that the 3GPP PS Data Off UE Status has changed, the PDN GW shall indicate this event
to the charging system for offline and online charging.
If the 3GPP PS Data Off UE Status indicates that 3GPP PS Data Off is activated for the UE, the PDN GW shall
enforce the PCC rules for downlink traffic to be applied when 3GPP PS Data Off is activated, as described in
TS 23.203 [6].
5. If the request is accepted, either the Dedicated Bearer Activation Procedure (according to clause 5.4.1), the PDN
GW Initiated Bearer Deactivation Procedure (according to clause 5.4.4.1) or one of the Bearer Modification
Procedures (according to clause 5.4.2.1 or 5.4.3) is invoked. The PTI allocated by the UE is used as a parameter
in the invoked Dedicated Bearer Activation Procedure, the PDN GW Initiated Bearer Deactivation Procedure or
the Bearer Modification Procedure to correlate it to the UE Requested Bearer Resource Modification Procedure.
This provides the UE with the necessary linkage to what EPS Bearer to be used for the new traffic flow
aggregate. The PDN GW shall not modify the QoS parameters requested by the UE.
The PDN GW inserts, modifies or removes packet filter(s) corresponding to the TAD into the TFT for the EPS
bearer. If PCC is in use, the PDN GW uses the service data flow filters as specified in the resulting PCC rule(s).
The PDN GW validates the state of the TFT settings of the PDN connection as defined in clause 15.3.0 of
TS 23.060 [7]. If after the execution of all TAD operations the TFT of the dedicated EPS bearer contains only
packet filters for the downlink direction, the PDN GW shall add a packet filter which effectively disallows any
useful packet flows in uplink direction (see clause 15.3.3.4 in TS 23.060 [7] for an example of such a packet
filter) to the TFT.
NOTE 4: The PDN GW addition of an uplink packet filter allows the handling of pre-Release 11 UEs which may
have provided only downlink packet filters in a TAD add operation without linking to an existing packet
filter.
When a new packet filter is inserted into a TFT, the PDN GW assigns a new packet filter identifier which is
unique within the TFT. The PDN GW maintains the relation between the SDF filter identifier in the PCC rule
received from the PCRF and the packet filter identifier of the TFT of this EPS bearer. If all of the packet filter(s)
for a dedicated EPS bearer have been removed from the TFT, the PDN GW performs the PDN GW Initiated
Bearer Deactivation Procedure.
If the requested QoS is not granted (i.e. the requested QoS cannot be accepted or resources could not be
allocated), or the resulting TFT settings of the PDN connection does not pass the validation, then the PDN GW
sends a Bearer Resource Failure Indication (with a cause indicating the reason why the request failed or was
rejected) message, which shall be delivered to the UE.
6. If the PDN GW interacted with the PCRF in step 4, the PDN GW indicates to the PCRF whether the PCC
decision could be enforced or not. This corresponds to the completion of the PCEF-initiated IP-CAN session
modification procedure as defined in TS 23.203 [6], proceeding after the completion of IP-CAN bearer
signalling. If requested by the PCRF the PDN GW indicates User Location Information and/or UE Time Zone
Information to the PCRF as defined in TS 23.203 [6].
5.4.6 Void
5.4.7 E-UTRAN initiated E-RAB modification procedure

When SCG bearer option is applied to support dual connectivity operation, this procedure is used to transfer bearer
contexts to and from Secondary eNodeB (see TS 36.300 [5]) or Secondary gNodeB (see TS 37.340 [85]). During this
procedure, both the MME and Serving GW are never relocated. The presence of IP connectivity between the Serving
GW and the Master eNodeB (see TS 36.300 [5] or TS 37.340 [85] for Master eNodeB definition), as well as between
the Serving GW and the Secondary RAN node is assumed.
NOTE: In E-UTRAN, eNodeB is not allowed to negotiate bearer-level QoS parameters as defined in
clause 4.7.2.1.
3GPP
Release 15 237 3GPP TS 23.401 V15.10.0 (2019-12)
Master Secondary Serving

UE eNodeB RAN node MME GW PDN GW
SCG bearer Addition, Modification

or Release
Forwarding of data
1 E-RAB Modification Indication

2 Modify Bearer Request
3 Modify Bearer Response

Downlink and Uplink data for SCG Bearers
Downlink and Uplink data for MCG Bearers

4a. End marker for bearers transferred to SeNB
4a. End marker for bearers transferred to SeNB
4b. End marker for bearers transferred to MeNB

4b. End marker for bearers transferred to MeNB
5 E-RAB Modification Confirm
Figure 5.4.7-1: E-UTRAN initiated E-RAB modification procedure
1. The Master eNodeB sends a E-RAB Modification Indication message (eNodeB address(es) and TEIDs for
downlink user plane for all the EPS bearers, CSG Membership Information, Secondary RAT usage data) to the
MME. The Master eNB indicates for each bearer whether it is modified or not. If the PLMN has configured
secondary RAT usage reporting and the eNodeB has Secondary RAT usage data to report, the Secondary RAT
usage data is included.
If the Secondary eNB is a hybrid access eNB, the Master eNB includes the CSG Membership Information for the
SCG bearer(s) in the E-RAB Modification Indication message. The MME determines the CSG membership
based on the CSG Membership Information as specified in TS 36.300 [5], but does not update the User CSG
Information in the Core Network. A failure of the CSG Membership Information verification does not impact the
E-UTRAN initiated E-RAB modification procedure.
2. The MME sends a Modify Bearer Request (eNodeB address(es) and TEIDs for downlink user plane for all the
EPS bearers, ISR Activated, Secondary RAT usage data and indication to send it to PDN GW) message per PDN
connection to the Serving GW, only for the affected PDN connections. If ISR was activated before this
procedure, MME should maintain ISR. The UE is informed about the ISR status in the Tracking Area Update
procedure. If the Serving GW supports Modify Access Bearers Request procedure and if there is no need for the
SGW to send the signalling to the PDN GW, the MME may send a Modify Access Bearers Request (eNodeB
address(es) and TEIDs for downlink user plane for all the EPS bearers, ISR Activated) to the Serving GW to
optimise the signalling. If the MME received Secondary RAT usage data in step 1, the MME shall include it in
this message.
If Secondary RAT usage data was included and if PGW secondary RAT usage data reporting is active, the
Serving GW shall send Modify Bearer Request (Secondary RAT usage data) message to the PDN GW for each
PDN connection. The PDN GW responds with Modify Bearer Response message to the Serving GW.
3. The Serving GW returns a Modify Bearer Response (Serving GW address and TEID for uplink traffic) message
to the MME as a response to a Modify Bearer Request message, or a Modify Access Bearers Response (Serving
GW address and TEID for uplink traffic) as a response to a Modify Access Bearers Request message.
3GPP
Release 15 238 3GPP TS 23.401 V15.10.0 (2019-12)
The Serving GW starts sending downlink packets to the eNodeB using the newly received address and TEID.
4. In order to assist the reordering function in the Master eNodeB and/or Secondary RAN nodes, for the bearers
that are switched between Master eNodeB and Secondary RAN nodes, the Serving GW shall send one or more
"end marker" packets on the old path immediately after switching the path as defined in TS 36.300 [5],
clause 10.1.2.2.
5. The MME confirms the E-RAB modification with the E-RAB Modification Confirm (CSG Membership Status)
message. The MME indicates for each bearer whether it was successfully modified, kept unmodified or already
released by the EPC as defined in TS 36.413 [36]. For the EPS bearers that have not been switched successfully
in the core network, it is the MME decision whether to maintain or release the corresponding EPS bearers. The
eNB uses the CSG Membership Status to decide on further actions, as specified in TS 36.300 [5].
5.4.8 E-UTRAN initiated UE Context Modification procedure

When split bearer option is applied to support dual connectivity operation, this procedure is used is by the eNB to
request the modifications on the established UE Context. In the current version of the specification, this procedure is
only used for membership verification, as described in TS 36.300 [5].
Master Secondary Serving

UE eNodeB eNodeB MME GW PDN GW
1- Addition of a hybrid
HeNB as the SeNB
2- UE Context Modification Indication

(CSG Membership Info)
3- CSG membership verification
4- UE Context Modification Confirm
5- Further actions if
membership
verifications fails
Downlink and Uplink data for split bearers
Figure 5.4.7-1: E-UTRAN initiated UE context modification procedure
1. The addition of an hybrid HeNB as the SeNB is triggered, providing the CSG-ID and the CSG Membership
Information to the MeNB.
2. The Master eNodeB sends UE Context Modification Indication message to the MME, which includes the CSG
Membership Information of the SeNB.
3. The MME verifies the CSG membership based on the provided CSG Membership Information as specified in
TS 36.300 [5], but does not update the User CSG Information in the Core Network. A failure of the CSG
Membership Information verification does not impact the E-UTRAN UE Context Modification procedure.
4. The MME confirms the UE Context Modification Indication with the UE Context Modification Confirm (CSG
Membership Status) message. If CSG Membership Information was not present in the UE Context Modification
Indication message, the MME can not perform CSG Membership Information verification and does not provide
CSG Membership Status in the UE Context Modification Confirm message.
5. In case the CSG Membership Status returned by the MME is different from what was reported by the UE, the
eNB may decide on further actions.
3GPP
Release 15 239 3GPP TS 23.401 V15.10.0 (2019-12)
5.5 Handover
5.5.1 Intra-E-UTRAN handover
5.5.1.1 X2-based handover
5.5.1.1.1 General
These procedures are used to hand over a UE from a source eNodeB to a target eNodeB using the X2 reference point. In
these procedures the MME is unchanged. Two procedures are defined depending on whether the Serving GW is
unchanged or is relocated. In addition to the X2 reference point between the source and target eNodeB, the procedures
rely on the presence of S1-MME reference point between the MME and the source eNodeB as well as between the
MME and the target eNodeB.
The handover preparation and execution phases are performed as specified in TS 36.300 [5]. If emergency bearer
services are ongoing for the UE handover to the target eNodeB is performed independent of the Handover Restriction
List. The MME checks, as part of the Tracking Area Update in the execution phase, if the handover is to a restricted
area and if so MME releases the non-emergency bearers as specified in clause 5.10.3.
If the serving PLMN changes during X2-based handover, the source eNodeB shall indicate to the target eNodeB (in the
Handover Restriction List) the PLMN selected to be the new Serving PLMN.
When the UE receives the handover command it will remove any EPS bearers for which it did not receive the
corresponding EPS radio bearers in the target cell. As part of handover execution, downlink and optionally also uplink
packets are forwarded from the source eNodeB to the target eNodeB. When the UE has arrived to the target eNodeB,
downlink data forwarded from the source eNodeB can be sent to it. Uplink data from the UE can be delivered via the
(source) Serving GW to the PDN GW or optionally forwarded from the source eNodeB to the target eNodeB. Only the
handover completion phase is affected by a potential change of the Serving GW, the handover preparation and
execution phases are identical.
If the MME receives a rejection to a NAS procedure (e.g. dedicated bearer establishment/modification/release; location
reporting control; NAS message transfer; etc.) from the eNodeB with an indication that an X2 handover is in progress
(see TS 36.300 [5]), the MME shall reattempt the same NAS procedure either when the handover is complete or the
handover is deemed to have failed, except in case of Serving GW relocation. The failure is known by expiry of the timer
guarding the NAS procedure.
If the X2 handover includes the Serving GW relocation, and if the MME receives a rejection to a NAS message transfer
for a Downlink NAS Transport or Downlink Generic NAS Transport message from the eNodeB with an indication that
an X2 handover is in progress, the MME should resend the corresponding message to the target eNodeB when either the
handover is complete or to the source eNodeB when the handover is deemed to have failed if the MME is still the
serving MME.
If the MME receives a rejection to a NAS message transfer for a CS Service Notification or to a UE Context
Modification Request message with a CS Fallback indicator from the eNodeB with an indication that an X2 handover is
in progress, the MME shall resend the corresponding message to the target eNodeB when the handover is complete or
to the source eNodeB when the handover is deemed to have failed.
If during the handover procedure the MME detects that the Serving GW needs be relocated, the MME shall reject any
PDN GW initiated EPS bearer(s) request received since handover procedure started and shall include an indication that
the request has been temporarily rejected due to handover procedure in progress. The rejection is forwarded by the
Serving GW to the PDN GW, with the indication that the request has been temporarily rejected.
been temporarily rejected due to handover procedure in progress, the PDN GW start a locally configured guard timer.
The PDN GW shall re-attempt, up to a pre-configured number of times, when either it detects that the handover is
completed or has failed using message reception or at expiry of the guard timer.
3GPP
Release 15 240 3GPP TS 23.401 V15.10.0 (2019-12)
5.5.1.1.2 X2-based handover without Serving GW relocation

This procedure is used to hand over a UE from a source eNodeB to a target eNodeB using X2 when the MME is
unchanged and decides that the Serving GW is also unchanged. The presence of IP connectivity between the Serving
GW and the source eNodeB, as well as between the Serving GW and the target eNodeB is assumed.
Source Target Serving

UE eNodeB eNodeB MME GW PDN GW
Downlink and uplink data
Handover preparation
Handover execution
Forwarding of data
1a RAN Usage data report
Downlink data Handover completion

Uplink data
1b Path Switch Request
2 Modify Bearer Request
3a Modify Bearer Request

(A)
3b Modify Bearer Response
4 Modify Bearer Response

Downlink data
5. End marker
5. End marker
6 Path Switch Request Ack
7 Release Resource
8. Tracking Area Update procedure
Figure 5.5.1.1.2-1: X2-based handover without Serving GW relocation
NOTE 1: For a PMIP-based S5/S8, procedure steps (A) are defined in TS 23.402 [2].
1a. If the PLMN has configured secondary RAT usage reporting, the source eNodeB during the handover execution
phase may provide RAN usage data Report (Secondary RAT usage data, handover flag) to the MME. The source
eNB shall provide this only when the Target eNB has confirmed handover over X2 interface (see TS 36.300 [5]
and the source eNB has sent a HO command to the UE). The handover flag indicates to the MME that it should
buffer the usage data report before forwarding it to the Serving GW.
1b. The target eNodeB sends a Path Switch Request message to MME to inform that the UE has changed cell,
including the TAI+ECGI of the target cell and the list of EPS bearers to be switched.
If Dual Connectivity is activated for the UE, the PSCell ID shall be included in the Path Switch Request
message.
If the target cell is a CSG cell , the target eNodeB includes the CSG ID of the target cell in Path Switch Request
message. If the target cell is in hybrid mode, it includes the CSG ID of the target cell and CSG Access Mode set
to "hybrid" in the Path Switch Request message. Moreover, the Path Switch Request message contains the CSG
Membership Status IE if the hybrid cell accessed by the UE has a different CSG from the source cell or the
source cell does not have a CSG ID. The MME determines the CSG membership based on the CSG ID and the
target PLMN id received from the target eNodeB.The MME updates the User CSG information based on the
CSG ID and CSG Access Mode received from the target eNodeB and CSG membership if one of the parameters
has changed.
3GPP
Release 15 241 3GPP TS 23.401 V15.10.0 (2019-12)
For SIPTO at the Local Network with stand-alone GW architecture, the target eNodeB shall include the Local
Home Network ID of the target cell in the Path Switch Request message.
The MME determines that the Serving GW can continue to serve the UE.
2. The MME sends a Modify Bearer Request (eNodeB address(es) and TEIDs for downlink user plane for the
accepted EPS bearers, ISR Activated, Secondary RAT usage data) message per PDN connection to the Serving
GW for each PDN connection where the default bearer has been accepted by the target eNodeB. If the PDN GW
requested location information change reporting, the MME also includes the User Location Information IE in
this message if it is different compared to the previously sent information. If the UE Time Zone has changed, the
MME includes the UE Time Zone IE in this message. If the Serving Network has changed, the MME includes
the new Serving Network IE in this message. If ISR was activated before this procedure, MME should maintain
ISR. The UE is informed about the ISR status in the Tracking Area Update procedure. If the Serving GW
supports Modify Access Bearers Request procedure and if there is no need for the SGW to send the signalling to
the PDN GW, the MME may send Modify Access Bearers Request (eNodeB address(es) and TEIDs for
downlink user plane for the accepted EPS bearers, ISR Activated) per UE to the Serving GW to optimise the
signalling. The MME includes the Secondary RAT usage data if the MME received it from the source eNodeB in
step 1a.
If the PDN GW requested UE's User CSG information (determined from the UE context), the MME includes the
User CSG Information IE in this message if the User CSG Information has changed.
The MME uses the list of EPS bearers to be switched, received in step 1, to determine whether any dedicated
EPS bearers in the UE context have not been accepted by the target eNodeB. The MME releases the non-
accepted dedicated bearers by triggering the bearer release procedure as specified in clause 5.4.4.2. If the
Serving GW receives a DL packet for a non-accepted bearer, the Serving GW drops the DL packet and does not
send a Downlink Data Notification to the MME.
If the default bearer of a PDN connection has not been accepted by the target eNodeB and there are multiple
PDN connections active, the MME shall consider all bearers of that PDN connection as failed and release that
PDN connection by triggering the MME requested PDN disconnection procedure specified in clause 5.10.3.
If none of the default EPS bearers have been accepted by the target eNodeB or there is a LIPA PDN connection
that has not been released, the MME shall act as specified in step 6.
3. If the Serving GW has received the User Location Information IE and/or the UE Time Zone IE and/or the
Serving Network IE and/or User CSG Information IE from the MME in step 2 the Serving GW informs the PDN
GW(s) about this information that e.g. can be used for charging, by sending the message Modify Bearer Request
(Serving GW Address and TEID, User Location Information IE and/or UE Time Zone IE and/or Serving
Network IE and/or User CSG Information IE, Secondary RAT usage data) per PDN connection to the PDN
GW(s) concerned. The Serving GW shall return a Modify Bearer Response (Serving GW address and TEID for
uplink traffic) message to the MME as a response to a Modify Bearer Request message, or a Modify Access
Bearers Response (Serving GW address and TEID for uplink traffic) as a response to a Modify Access Bearers
Request message. If the Serving GW cannot serve the MME Request in the Modify Access Bearers Request
message without S5/S8 signalling or without corresponding Gxc signalling when PMIP is used over the S5/S8
interface, it shall respond to the MME with indicating that the modifications are not limited to S1-U bearers, and
the MME shall repeat its request using Modify Bearer Request message per PDN connection. The Serving GW
forwards the Secondary RAT usage data to the PDN GW, if the Serving GW received it in step 2 and if PGW
secondary RAT usage data reporting is active.
4. The Serving GW starts sending downlink packets to the target eNodeB using the newly received address and
TEIDs. A Modify Bearer Response message is sent back to the MME.
5. In order to assist the reordering function in the target eNodeB, the Serving GW shall send one or more "end
marker" packets on the old path immediately after switching the path as defined in TS 36.300 [5],
clause 10.1.2.2.
6. The MME confirms the Path Switch Request message with the Path Switch Request Ack message. If the
UE-AMBR is changed, e.g. all the EPS bearers which are associated to the same APN are rejected in the target
eNodeB, the MME shall provide the updated value of UE-AMBR to the target eNodeB in the Path Switch
Request Ack message.
If the CSG membership status was included in the Path Switch Request message, the MME shall include its
verified CSG membership status in the Path Switch Request Ack message.
3GPP
Release 15 242 3GPP TS 23.401 V15.10.0 (2019-12)
If some EPS bearers have not been switched successfully in the core network, the MME shall indicate in the Path
Switch Request Ack message which bearers failed to be established (see more detail in TS 36.413 [36]) and for
dedicated bearers initiate the bearer release procedure as specified in clause 5.4.4.2 to release the core network
resources of the failed dedicated EPS bearers. The target eNodeB shall delete the corresponding bearer contexts
when it is informed that bearers have not been established in the core network.
If none of the default EPS bearers have been switched successfully in the core network or if they have not been
accepted by the target eNodeB or the LIPA PDN connection has not been released, the MME shall send a Path
Switch Request Failure message (see more detail in TS 36.413 [36]) to the target eNodeB. The MME performs
explicit detach of the UE as described in the MME initiated detach procedure of clause 5.3.8.3.
7. By sending Release Resource the target eNodeB informs success of the handover to source eNodeB and triggers
the release of resources. This step is specified in TS 36.300 [5].
8. The UE initiates a Tracking Area Update procedure when one of the conditions listed in clause "Triggers for
tracking area update" applies. If ISR is activated for the UE when the MME receives the Tracking Area Update
Request, the MME should maintain ISR by indicating ISR Activated in the Tracking Area Update Accept
message.
NOTE 2: It is only a subset of the TA update procedure that is performed by the MME, since the UE is in
ECM-CONNECTED state and the MME is not changed.
5.5.1.1.3 X2-based handover with Serving GW relocation

This procedure is used to hand over a UE from a source eNodeB to a target eNodeB using X2 when the MME is
unchanged and the MME decides that the Serving GW is to be relocated. The presence of IP connectivity between the
source Serving GW and the source eNodeB, between the source Serving GW and the target eNodeB, and between the
target Serving GW and target eNodeB is assumed. (If there is no IP connectivity between target eNodeB and source
Serving GW, it is assumed that the S1-based handover procedure in clause 5.5.1.2 shall be used instead.)
3GPP
Release 15 243 3GPP TS 23.401 V15.10.0 (2019-12)
Source Target Source Target

UE eNodeB MME Serving GW Serving GW PDN GW
eNodeB
Downlink and uplink data
Handover preparation
Handover execution
Forwarding of data
1a. RAN Usage data report
Downlink data Handover completion

Uplink data
1b. Path Switch Request

(A)
Downlink data
5. Path Switch Request Ack
Uplink data
6. Release Resource
7a. Delete Session Request
(B)
Figure 5.5.1.1.3-1: X2-based handover with Serving GW relocation
NOTE 1: For a PMIP-based S5/S8, procedure steps (A) and (B) are defined in TS 23.402 [2].
1a. If the PLMN has configured Secondary RAT usage data reporting and the source eNodeB has Secondary RAT
usage data to report, the eNodeB sends a RAN usage data Report (Secondary RAT usage data, handover flag)
message to the MME. The eNB shall provide this only when it is to perform a Path Switch (i.e. the Target eNB
has confirmed it is ready over X2 interface (see TS 36.300 [5] and the source eNB has sent a HO command to
the UE). The handover flag indicates to the MME that it should buffer the report before forwarding the
Secondary RAT usage charging data.
1b. The target eNodeB sends a Path Switch Request message to MME to inform that the UE has changed cell,
including the ECGI of the target cell and the list of EPS bearers to be switched.
If Dual Connectivity is activated for the UE, the PSCell ID shall be included in the Path Switch Request
message.
If the target cell is a CSG cell, the target eNodeB includes the CSG ID of the target cell in Path Switch Request
message. If the target cell is in hybrid mode, it includes the CSG ID of the target cell and CSG Access Mode set
to "hybrid" in the Path Switch Request message. Moreover, the Path Switch Request message contains the CSG
Membership Status IE if the hybrid cell accessed by the UE has a different CSG from the source cell or the
source cell does not have a CSG ID. The MME determines the CSG membership based on the CSG ID and the
target PLMN id received from the target eNodeB. The MME updates the User CSG information based on the
CSG ID and CSG Access Mode received from the target eNodeB and CSG membership if one of the parameters
has changed.
Home Network ID of the target cell in the Path Switch Request message.
3GPP
Release 15 244 3GPP TS 23.401 V15.10.0 (2019-12)
The MME determines that the Serving GW is relocated and selects a new Serving GW according to clause
4.3.8.2 on "Serving GW Selection Function".
NOTE 2: The MME knows the S-GW Service Area with a TA granularity.
2. The MME sends a Create Session Request (bearer context(s) with PDN GW addresses and TEIDs (for GTP-
based S5/S8) or GRE keys (for PMIP-based S5/S8) at the PDN GW(s) for uplink traffic, eNodeB address(es)
and TEIDs for downlink user plane for the accepted EPS bearers, the Protocol Type over S5/S8, Serving
Network, UE Time Zone, Secondary RAT usage data) message per PDN connection to the target Serving GW
for each PDN connection where the default bearer has been accepted by the target eNodeB. The target Serving
GW allocates the S-GW addresses and TEIDs for the uplink traffic on S1_U reference point (one TEID per
bearer). The Protocol Type over S5/S8 is provided to Serving GW which protocol should be used over S5/S8
interface. If the PDN GW requested location information change reporting, the MME also includes the User
Location Information IE in this message if it is different compared to the previously sent information. If the PDN
GW requested UE's User CSG information (determined from the UE context), the MME includes the User CSG
Information IE in this message if the User CSG Information has changed.
The MME uses the list of EPS bearers to be switched, received in step 1, to determine whether any dedicated
EPS bearers in the UE context have not been accepted by the target eNodeB. The MME releases the non-
accepted dedicated bearers by triggering the bearer release procedure as specified in clause 5.4.4.2 via target
Serving GW. If the Serving GW receives a DL packet for a non-accepted bearer, the Serving GW drops the DL
packet and does not send a Downlink Data Notification to the MME.
If the default bearer of a PDN connection has not been accepted by the target eNodeB and there are multiple
PDN connections active, the MME shall consider all bearers of that PDN connection as failed and release that
PDN connection by triggering the MME requested PDN disconnection procedure specified in clause 5.10.3 via
source Serving GW.
If none of the default EPS bearers have been accepted by the target eNodeB or there is a LIPA PDN connection
that has not been released, the MME shall act as specified in step 5.
If the MME received it from the source eNodeB in step 1a and PDN GW Secondary RAT reporting is active, the
MME includes the Secondary RAT usage data with a flag stating that the target SGW shall not process the
information and only forward it to the PDN GW.
3. The target Serving GW assigns addresses and TEIDs (one per bearer) for downlink traffic from the PDN GW.
The Serving GW allocates DL TEIDs on S5/S8 even for non-accepted bearers. It sends a Modify Bearer Request
(Serving GW addresses for user plane and TEID(s), Serving Network, PDN Charging Pause Support Indication,
Secondary RAT usage data) message per PDN connection to the PDN GW(s). The S-GW also includes User
Location Information IE and/or UE Time Zone IE and/or User CSG Information IE if it is present in step 2. The
PDN GW updates its context field and returns a Modify Bearer Response (Charging Id, MSISDN, PDN
Charging Pause Enabled Indication (if PDN GW has chosen to enable the function), etc.) message to the Serving
GW. The MSISDN is included if the PDN GW has it stored in its UE context. The PDN GW starts sending
downlink packets to the target GW using the newly received address and TEIDs. These downlink packets will
use the new downlink path via the target Serving GW to the target eNodeB. The Serving GW shall allocate
TEIDs for the failed bearers and inform to the MME. The Serving GW forwards the Secondary RAT usage data
to the PDN GW, if the Serving GW received it in step 2 and if PGW secondary RAT usage data reporting is
active.
immediately after switching the path in order to assist the reordering function in the target eNodeB. The source
Serving GW shall forward the "end marker" packets to the source eNodeB.
4. The target Serving GW sends a Create Session Response (Serving GW addresses and uplink TEID(s) for user
plane) message back to the target MME. The MME starts a timer, to be used in step 7.
5. The MME confirms the Path Switch Request message with the Path Switch Request Ack (Serving GW addresses
and uplink TEID(s) for user plane) message. If the UE-AMBR is changed, e.g. all the EPS bearers which are
associated to the same APN are rejected in the target eNodeB, the MME shall provide the updated value of
UE-AMBR to the target eNodeB in the Path Switch Request Ack message. The target eNodeB starts using the
new Serving GW address(es) and TEID(s) for forwarding subsequent uplink packets.
If the CSG membership status was included in the Path Switch Request message, the MME shall include its
verified CSG membership status in the Path Switch Request Ack message.
3GPP
Release 15 245 3GPP TS 23.401 V15.10.0 (2019-12)
If some EPS bearers have not been switched successfully in the core network, the MME shall indicate in the Path
Switch Request Ack message which bearers failed to be established (see more detail in TS 36.413 [36]) and for
dedicated bearers initiate the bearer release procedure as specified in clause 5.4.4.2 to release the core network
resources of the failed dedicated EPS bearers. The target eNodeB shall delete the corresponding bearer contexts
when it is informed that bearers have not been established in the core network.
If none of the default EPS bearers have been switched successfully in the core network or if they have not been
accepted by the target eNodeB or the LIPA PDN connection has not been released, the MME shall send a Path
Switch Request Failure message (see more detail in TS 36.413 [36]) to the target eNodeB. The MME performs
explicit detach of the UE as described in the MME initiated detach procedure of clause 5.3.8.3.
6. By sending Release Resource the target eNodeB informs success of the handover to source eNodeB and triggers
the release of resources. This step is specified in TS 36.300 [5].
7. When the timer has expired after step 4, the source MME releases the bearer(s) in the source Serving GW by
sending a Delete Session Request message (Cause, Operation Indication, Secondary RAT usage data). The
operation Indication flag is not set, that indicates to the Source Serving GW that the Source Serving GW shall
not initiate a delete procedure towards the PDN GW. The Source Serving GW acknowledges with Delete
Session Response messages. If ISR has been activated before this procedure, the cause indicates to the Source
S-GW that the Source S-GW shall delete the bearer resources on the other old CN node by sending Delete
Bearer Request message(s) to that CN node. The MME includes the Secondary RAT usage data in this message
if it received it in step 1a.
tracking area update" applies.
NOTE 3: It is only a subset of the TA update procedure that is performed by the MME, since the UE is in
ECM-CONNECTED state. The UE is informed about the ISR status in the Tracking Area Update
procedure.
5.5.1.2 S1-based handover
5.5.1.2.1 General
The S1-based handover procedure is used when the X2-based handover cannot be used. The source eNodeB initiates a
handover by sending Handover Required message over the S1-MME reference point. This procedure may relocate the
MME and/or the Serving GW. The source MME selects the target MME. The MME should not be relocated during
inter-eNodeB handover unless the UE leaves the MME Pool Area where the UE is served. The MME (target MME for
MME relocation) determines if the Serving GW needs to be relocated. If the Serving GW needs to be relocated the
MME selects the target Serving GW, as specified in clause 4.3.8.2 on Serving GW selection function.
The source eNodeB decides which of the EPS bearers are subject for forwarding of downlink and optionally also uplink
data packets from the source eNodeB to the target eNodeB. The EPC does not change the decisions taken by the RAN
node. Packet forwarding can take place either directly from the source eNodeB to the target eNodeB, or indirectly from
the source eNodeB to the target eNodeB via the source and target Serving GWs (or if the Serving GW is not relocated,
only the single Serving GW).
The availability of a direct forwarding path is determined in the source eNodeB and indicated to the source MME. If X2
connectivity is available between the source and target eNodeBs, a direct forwarding path is available.
If a direct forwarding path is not available, indirect forwarding may be used. The source MME uses the indication from
the source eNodeB to determine whether to apply indirect forwarding. The source MME indicates to the target MME
whether indirect forwarding should apply. Based on this indication, the target MME determines whether it applies
indirect forwarding.
If the MME receives a rejection to an S1 interface procedure (e.g. dedicated bearer establishment/modification/release;
location reporting control; NAS message transfer; etc.) from the eNodeB with an indication that an S1 handover is in
progress (see TS 36.300 [5]), the MME shall reattempt the same S1 interface procedure when either the handover is
complete or is deemed to have failed if the MME is still the serving MME, except in case of Serving GW relocation. If
the S1 handover changes the serving MME, the source MME shall terminate any other ongoing S1 interface procedures
except the handover procedure.
3GPP
Release 15 246 3GPP TS 23.401 V15.10.0 (2019-12)
If the S1 handover includes the Serving GW relocation, and if the MME receives a rejection to a NAS message transfer
for a Downlink NAS Transport or Downlink Generic NAS Transport message from the eNodeB with an indication that
an S1 handover is in progress, the MME should resend the corresponding message to the target eNodeB when either the
handover is complete or to the source eNodeB when the handover is deemed to have failed if the MME is still the
serving MME.
If the MME receives a rejection to a NAS message transfer for a CS Service Notification or to a UE Context
modification Request message with a CS Fallback indication from the eNodeB with an indication that an S1 handover is
in progress, the MME shall resend the corresponding message to the target eNodeB when either the handover is
complete or to the source eNodeB when the handover is deemed to have failed if the MME is still the serving MME.
In order to minimise the number of procedures rejected by the eNodeB, the MME should pause non-handover related
S1 interface procedures (e.g. downlink NAS message transfer, E-RAB Setup/Modify/Release, etc.) while a handover is
ongoing (i.e. from the time that a Handover Required has been received until either the Handover procedure has
succeeded (Handover Notify) or failed (Handover Failure)) and continue them once the Handover procedure has
completed if the MME is still the serving MME, except in case of Serving GW relocation.
If during the handover procedure the MME detects that the Serving GW or/and the MME needs be relocated, the MME
shall reject any PDN GW initiated EPS bearer(s) request received since handover procedure started and shall include an
indication that the request has been temporarily rejected due to handover procedure in progress. The rejection is
forwarded by the Serving GW to the PDN GW, with the indication that the request has been temporarily rejected.
been temporarily rejected due to handover procedure in progress, the PDN GW start a locally configured guard timer.
The PDN GW shall re-attempt, up to a pre-configured number of times, when either it detects that the handover is
completed or has failed using message reception or at expiry of the guard timer.
If emergency bearer services are ongoing for the UE, handover to the target eNodeB is performed independent of the
Handover Restriction List. The MME checks, as part of the Tracking Area Update in the execution phase, if the
handover is to a restricted area and if so MME releases the non-emergency bearers as specified in clause 5.10.3.
If emergency bearer services are ongoing for the UE, handover to the target CSG cell is performed independent of the
UE's CSG subscription. If the handover is to a CSG cell that the UE is not subscribed, the target eNodeB only accepts
the emergency bearers and the target MME releases the non-emergency PDN connections that were not accepted by the
target eNodeB as specified in clause 5.10.3.
For inter-PLMN handover to a CSG cell, if the source MME has the CSG-ID list of the target PLMN, the source MME
shall use it to validate the CSG membership of the UE in the target CSG cell. Otherwise, based on operator's
configuration the source MME may allow the handover by validating the CSG membership of the UE in the target CSG
cell using the CSG-ID list of the registered PLMN-ID. If neither the CSG-ID list of the target PLMN nor the operator's
configuration permits the handover,the source MME shall reject the handover due to no CSG membership information
of the target PLMN-ID.
As specified in clause 4.3.8.3, with regard to CIoT EPS Optimisations, the source MME attempts to perform handover
to a target MME that can support the UE's Preferred Network Behaviour. For a UE that is using a Non-IP connection to
a PDN Gateway, or a PDN connection to a SCEF, if these bearers cannot be supported by the target MME, the source
MME does not attempt to handover those bearers, but instead releases them upon successful completion of the
handover. If the MME does not have any bearer for the UE that can be transferred, then the MME sends an S1-AP
Handover Preparation Failure message to the source eNB.
NOTE: Inter-PLMN handover to a CSG cell in a PLMN which is not an equivalent PLMN for the UE is not
supported.
5.5.1.2.2 S1-based handover, normal

This procedure describes the S1-based handover in the normal case, clause 5.5.1.2.3 describes it when the procedure is
rejected by the target eNodeB or the target MME and clause 5.5.1.2.4 describes when the procedure is canceled by the
source eNodeB.
3GPP
Release 15 247 3GPP TS 23.401 V15.10.0 (2019-12)
Source Target Source Target Source Target Serving

UE eNodeB eNodeB MME MME Serving GW GW PDN GW HSS
Downlink User Plane data
1. Decision to trigger a
relocation via S1
2. Handover Required
3. Forward Relocation Request
4a. Create Session Response
5. Handover Request
5a. Handover Request Acknowledge
6. Create Indirect Data Forwarding Tunnel Request
6a. Create Indirect Data Forwarding Tunnel Response
7. Forward Relocation Response

8.. Create Indirect Data Forwarding Tunnel Request
9. Handover Command
9a. Handover Command
9b. RAN Usage data report
10. eNB Status Transfer
10a. Forward Access Context Notification
10b. Forward Access Context Acknowledge
10c. MME Status Transfer
11a. Only for Direct forwarding of data

11b. Only for Indirect forwarding of data
Detach from old cell and

synchronize to new cell
12. Handover Confirm
Downlink data
Uplink User Plane data
13. Handover Notify

14. Forward Relocation Complete Notification
14b. Forward Relocation Complete Acknowledge
(A)
16a. Modify Bearer Response
19c. Delete Session Request

19a. UE Context Release Command
(B)
19b. UE Context Release Complete
19d. Delete Session Response
20a. Delete Indirect Data Forwarding Tunnel Request
20b. Delete Indirect Data Forwarding Tunnel Response
21a. Delete Indirect Data Forwarding Tunnel Request
21b. Delete Indirect Data Forwarding Tunnel Response
Figure 5.5.1.2.2-1: S1-based handover
3GPP
Release 15 248 3GPP TS 23.401 V15.10.0 (2019-12)
NOTE 1: For a PMIP-based S5/S8, procedure steps (A) and (B) are defined in TS 23.402 [2]. Steps 16 and 16a
NOTE 2: If the Serving GW is not relocated, the box "Source Serving GW" in figure 5.5.1.2.2-1 is acting as the
target Serving GW.
1. The source eNodeB decides to initiate an S1-based handover to the target eNodeB. This can be triggered e.g. by
no X2 connectivity to the target eNodeB, or by an error indication from the target eNodeB after an unsuccessful
X2-based handover, or by dynamic information learnt by the source eNodeB.
2. The source eNodeB sends Handover Required (Direct Forwarding Path Availability, Source to Target
transparent container, target eNodeB Identity, CSG ID, CSG access mode, target TAI, S1AP Cause) to the
source MME. The source eNodeB indicates which bearers are subject to data forwarding. Direct Forwarding
Path Availability indicates whether direct forwarding is available from the source eNodeB to the target eNodeB.
This indication from source eNodeB can be based on e.g. the presence of X2. The target TAI is sent to MME to
facilitate the selection of a suitable target MME. When the target cell is a CSG cell or a hybrid cell, the source
eNodeB shall include the CSG ID of the target cell. If the target cell is a hybrid cell, the CSG access mode shall
be indicated.
3. The source MME selects the target MME as described in clause 4.3.8.3 on "MME Selection Function" and if it
has determined to relocate the MME, it sends a Forward Relocation Request (MME UE context, Source to
Target transparent container, RAN Cause, target eNodeB Identity, CSG ID, CSG Membership Indication, target
TAI, MS Info Change Reporting Action (if available), CSG Information Reporting Action (if available), UE
Time Zone, Direct Forwarding Flag, Serving Network, Local Home Network ID, LTE-M UE Indication)
message to the target MME. The target TAI is sent to the target MME to help it to determine whether S-GW
relocation is needed (and, if needed, aid SGW selection). The old Serving Network is sent to target MME to
support the target MME to resolve if Serving Network is changed. In network sharing scenarios Serving
Network denotes the serving core network.
The source MME shall perform access control by checking the UE's CSG subscription when CSG ID is provided
by the source eNodeB. If there is no subscription data for this CSG ID or the CSG subscription is expired, and
the target cell is a CSG cell, the source MME shall reject the handover with an appropriate cause unless the UE
has emergency bearer services.
The MME UE context includes IMSI, ME Identity, UE security context, UE Network Capability, AMBR,
Selected CN operator ID, APN restriction, Serving GW address and TEID for control signalling, and EPS Bearer
context(s).
An EPS Bearer context includes the PDN GW addresses and TEIDs (for GTP-based S5/S8) or GRE keys (for
PMIP-based S5/S8) at the PDN GW(s) for uplink traffic, APN, Serving GW addresses and TEIDs for uplink
traffic, and TI.
Based on the CIoT EPS Optimisation capabilities of the target MME (determined according to the target MME
selection procedure of clause 4.3.8.3) the source MME only includes the EPS Bearer Context(s) that the target
MME can support. If none of the UE's EPS Bearers can be supported by the selected target MME, the source
MME rejects the S1 handover attempt by sending a Handover Preparation Failure (Cause) message to the Source
eNodeB. If the target MME supports CIoT EPS Optimisation and the use of header compression has been
negotiated between the UE and the source MME, the source MME also includes in the Forward Relocation
Request the previously negotiated Header Compression Configuration that includes the information necessary
for the ROHC channel setup but not the RoHC context itself.
If the source MME includes EPS Bearer Context, in addition to the Serving GW IP address and TEID for S1-U
use plane, the source MME also includes Serving GW IP address and TEID for S11-U, if available.
NOTE 3: If the handover is successful, the source MME will signal to the SGW and/or SCEF to release any non-
included EPS Bearers after step 14. The non-included bearers are locally released by the UE following the
Bearer Context Status synchronisation that occurs during the Tracking Area Update at step 18.
If SIPTO at the Local Network is active for a PDN connection in the architecture with stand-alone GW the
source MME shall include the Local Home Network ID of the source cell in the EPS Bearer context
RAN Cause indicates the S1AP Cause as received from source eNodeB.
3GPP
Release 15 249 3GPP TS 23.401 V15.10.0 (2019-12)
The source MME includes the CSG ID in the Forward Relocation Request when the target cell is a CSG or
hybrid cell. When the target cell is a hybrid cell, or if there are one or several emergency bearers and the target
cell is a CSG cell, the CSG Membership Indication indicating whether the UE is a CSG member shall be
included in the Forward Relocation Request message.
The Direct Forwarding Flag indicates if direct forwarding is applied, or if indirect forwarding is going to be set
up by the source side.
The target MME shall determine the Maximum APN restriction based on the APN Restriction of each bearer
context in the Forward Relocation Request, and shall subsequently store the new Maximum APN restriction
value.
If the UE receives only emergency services and the UE is UICCless, IMSI can not be included in the MME UE
context in Forward Relocation Request message. For emergency attached UEs, if the IMSI cannot be
authenticated, then the IMSI shall be marked as unauthenticated. Also, in this case, security parameters are
included only if available.
4. If the MME has been relocated, the target MME verifies whether the source Serving GW can continue to serve
the UE. If not, it selects a new Serving GW as described in clause 4.3.8.2 on "Serving GW Selection Function".
If the MME has not been relocated, the source MME decides on this Serving GW re-selection.
If the source Serving GW continues to serve the UE, no message is sent in this step. In this case, the target
Serving GW is identical to the source Serving GW.
If a new Serving GW is selected, the target MME sends a Create Session Request (bearer context(s) with PDN
GW addresses and TEIDs (for GTP-based S5/S8) or GRE keys (for PMIP-based S5/S8) at the PDN GW(s) for
uplink traffic, Serving Network, UE Time Zone) message per PDN connection to the target Serving GW. The
target Serving GW allocates the S-GW addresses and TEIDs for the uplink traffic on S1_U reference point (one
TEID per bearer). The target Serving GW sends a Create Session Response (Serving GW addresses and uplink
TEID(s) for user plane) message back to the target MME.
5. The Target MME sends Handover Request (EPS Bearers to Setup, AMBR, S1AP Cause, Source to Target
transparent container, CSG ID, CSG Membership Indication, Handover Restriction List) message to the target
eNodeB. This message creates the UE context in the target eNodeB, including information about the bearers, and
the security context. For each EPS Bearer, the Bearers to Setup includes Serving GW address and uplink TEID
for user plane, and EPS Bearer QoS. If the direct forwarding flag indicates unavailability of direct forwarding
and the target MME knows that there is no indirect data forwarding connectivity between source and target, the
Bearers to Setup shall include "Data forwarding not possible" indication for each EPS bearer. Handover
Restriction List is sent if available in the Target MME; it is described in clause 4.3.5.7 "Mobility Restrictions".
S1AP Cause indicates the RAN Cause as received from source MME.
The Target MME shall include the CSG ID and CSG Membership Indication when provided by the source MME
in the Forward Relocation Request message.
The target eNodeB sends a Handover Request Acknowledge (EPS Bearer Setup list, EPS Bearers failed to setup
list Target to Source transparent container) message to the target MME. The EPS Bearer Setup list includes a list
of addresses and TEIDs allocated at the target eNodeB for downlink traffic on S1-U reference point (one TEID
per bearer) and addresses and TEIDs for receiving forwarded data if necessary. If the UE-AMBR is changed, e.g.
all the EPS bearers which are associated to the same APN are rejected in the target eNodeB, the MME shall
recalculate the new UE-AMBR and signal the modified UE-AMBR value to the target eNodeB.
If none of the default EPS bearers have been accepted by the target eNodeB, the target MME shall reject the
handover as specified in clause 5.5.1.2.3.
If the target cell is a CSG cell, the target eNodeB shall verify the CSG ID provided by the target MME, and
reject the handover with an appropriate cause if it does not match the CSG ID for the target cell. If the target
eNodeB is in hybrid mode, it may use the CSG Membership Indication to perform differentiated treatment for
CSG and non-CSG members. If the target cell is a CSG cell, and if the CSG Membership Indication is "non
member", the target eNodeB only accepts the emergency bearers.
3GPP
Release 15 250 3GPP TS 23.401 V15.10.0 (2019-12)
6. If indirect forwarding applies and the Serving GW is relocated, the target MME sets up forwarding parameters
by sending Create Indirect Data Forwarding Tunnel Request (target eNodeB addresses and TEIDs for
forwarding) to the Serving GW. The Serving GW sends a Create Indirect Data Forwarding Tunnel Response
(target Serving GW addresses and TEIDs for forwarding) to the target MME. If the Serving GW is not relocated,
indirect forwarding may be set up in step 8 below.
7. If the MME has been relocated, the target MME sends a Forward Relocation Response (Cause, Target to Source
transparent container, Serving GW change indication, EPS Bearer Setup List, Addresses and TEIDs) message to
the source MME. For indirect forwarding, this message includes Serving GW Address and TEIDs for indirect
forwarding (source or target). Serving GW change indication indicates a new Serving GW has been selected.
8. If indirect forwarding applies, the source MME sends Create Indirect Data Forwarding Tunnel Request
(addresses and TEIDs for forwarding) to the Serving GW. If the Serving GW is relocated it includes the tunnel
identifier to the target serving GW.
The Serving GW responds with a Create Indirect Data Forwarding Tunnel Response (Serving GW addresses and
TEIDs for forwarding) message to the source MME.
9. The source MME sends a Handover Command (Target to Source transparent container, Bearers subject to
forwarding, Bearers to Release) message to the source eNodeB. The Bearers subject to forwarding includes list
of addresses and TEIDs allocated for forwarding. The Bearers to Release includes the list of bearers to be
released.
9a. The Handover Command is constructed using the Target to Source transparent container and is sent to the UE.
Upon reception of this message the UE will remove any EPS bearers for which it did not receive the
corresponding EPS radio bearers in the target cell.
9b. If the PLMN has configured Secondary RAT usage data reporting and the source eNodeB has Secondary RAT
usage data to report, the eNodeB sends a RAN Usage data Report (Secondary RAT usage data, handover flag)
message to the source MME. The handover flag indicates to the MME that it should buffer the report before
forwarding the Secondary RAT usage data.
10. The source eNodeB sends the eNodeB Status Transfer message to the target eNodeB via the MME(s) to convey
the PDCP and HFN status of the E-RABs for which PDCP status preservation applies, as specified in
TS 36.300 [5]. The source eNodeB may omit sending this message if none of the E-RABs of the UE shall be
treated with PDCP status preservation.
If there is an MME relocation the source MME sends this information to the target MME via the Forward Access
Context Notification message which the target MME acknowledges. The source MME or, if the MME is
relocated, the target MME, sends the information to the target eNodeB via the MME Status Transfer message.
11. The source eNodeB should start forwarding of downlink data from the source eNodeB towards the target
eNodeB for bearers subject to data forwarding. This may be either direct (step 11a) or indirect forwarding (step
11b).
12. After the UE has successfully synchronized to the target cell, it sends a Handover Confirm message to the target
eNodeB. Downlink packets forwarded from the source eNodeB can be sent to the UE. Also, uplink packets can
be sent from the UE, which are forwarded to the target Serving GW and on to the PDN GW.
13. The target eNodeB sends a Handover Notify (TAI+ECGI, Local Home Network ID) message to the target
MME. If Dual Connectivity is activated for the UE, the PSCell ID shall be included in the Handover Notify
message.
Home Network ID of the target cell in the Handover Notify message.
14. If the MME has been relocated, the target MME sends a Forward Relocation Complete Notification message to
the source MME. The source MME in response sends a Forward Relocation Complete Acknowledge (Secondary
RAT usage data) message to the target MME. The source MME includes Secondary RAT usage data in this
3GPP
Release 15 251 3GPP TS 23.401 V15.10.0 (2019-12)
message if it received this in step 9b. Regardless if MME has been relocated or not, a timer in source MME is
started to supervise when resources in Source eNodeB and if the Serving GW is relocated, also resources in
Source Serving GW shall be released.
Upon receipt of the Forward Relocation Complete Acknowledge message the target MME starts a timer if the
target MME allocated S-GW resources for indirect forwarding.
For all bearers that were not included in the Forward Relocation Request message sent in step 3, the MME now
releases them by sending a Delete Bearer Command to the SGW, or, the appropriate message to the SCEF.
15. The MME sends a Modify Bearer Request (eNodeB address and TEID allocated at the target eNodeB for
downlink traffic on S1-U for the accepted EPS bearers, ISR Activated, Secondary RAT usage data if PGW
secondary RAT usage data reporting is active) message to the target Serving GW for each PDN connection,
including the PDN connections that need to be released. If the PDN GW requested location information change
reporting and/or User CSG information (determined from the UE context), the MME also includes the User
Location Information IE (if it is different compared to the previously sent information) and/or User CSG
Information IE in this message. If the UE Time Zone has changed, the MME includes the UE Time Zone IE in
this message. If Serving GW is not relocated but the Serving Network has changed or if the MME has not
received any old Serving Network information from the old MME, the MME includes the Serving Network IE in
this message. For the case that neither MME nor S-GW changed, if ISR was activated before this procedure
MME should maintain ISR. The UE is informed about the ISR status in the Tracking Area Update procedure. If
the Serving GW supports Modify Access Bearers Request procedure and if there is no need for the SGW to send
the signalling to the PDN GW, the MME may send Modify Access Bearers Request (eNodeB address and TEID
allocated at the target eNodeB for downlink traffic on S1 U for the accepted EPS bearers, ISR Activated) per UE
to the Serving GW to optimise the signalling. If Serving GW is not relocated and if Secondary RAT usage data
was received in step 9a, the MME includes the Secondary RAT usage data in the message. If the Serving GW
has been relocated and if PGW Secondary RAT reporting is active, the MME includes the Secondary RAT usage
data and also includes a flag stating that the Serving GW should not process the information and only forward it
to the PDN GW.
The MME releases the non-accepted dedicated bearers by triggering the bearer release procedure as specified in
clause 5.4.4.2. If the Serving GW receives a DL packet for a non-accepted bearer, the Serving GW drops the DL
If the default bearer of a PDN connection has not been accepted by the target eNodeB and there are other PDN
connections active, the MME shall handle it in the same way as if all bearers of a PDN connection have not been
accepted. The MME releases these PDN connections by triggering the MME requested PDN disconnection
procedure specified in clause 5.10.3.
When the Modify Bearer Request does not indicate ISR Activated the Serving GW deletes any ISR resources by
sending a Delete Bearer Request to the other CN node that has bearer resources on the Serving GW reserved.
16. If the Serving GW is relocated, the target Serving GW assigns addresses and TEIDs (one per bearer) for
downlink traffic from the PDN GW. It sends a Modify Bearer Request (Serving GW addresses for user plane and
TEID(s), Serving Network, PDN Charging Pause Support Indication, Secondary RAT usage data) message per
PDN connection to the PDN GW(s). The S-GW also includes User Location Information IE and/or UE Time
Zone IE and/or User CSG Information IE if they are present in step 15. The Serving GW also includes Serving
Network IE if it is present in step 4 or step 15. The Serving GW allocates DL TEIDs on S5/S8 even for non-
accepted bearers. The PDN GW updates its context field and returns a Modify Bearer Response (Charging Id,
MSISDN, PDN Charging Pause Enabled Indication (if PDN GW has chosen to enable the function), etc.)
message to the target Serving GW. The MSISDN is included if the PDN GW has it stored in its UE context. The
PDN GW starts sending downlink packets to the target GW using the newly received address and TEIDs. These
downlink packets will use the new downlink path via the target Serving GW to the target eNodeB. The
Secondary RAT usage data is included if it was received in step 15 and if PGW secondary RAT usage data
reporting is active.
If the Serving GW is not relocated, but has received the User Location Information IE and/or UE Time Zone IE
and/or User CSG Information IE and/or Serving Network IE from the MME in step 15, the Serving GW shall
inform the PDN GW(s) about these information that e.g. can be used for charging, by sending the message
Modify Bearer Request (User Location Information IE, UE Time Zone IE, User CSG Information IE, Serving
Network IE) to the PDN GW(s) concerned. A Modify Bearer Response message is sent back to the Serving GW.
3GPP
Release 15 252 3GPP TS 23.401 V15.10.0 (2019-12)
If the Serving GW is not relocated and it has not received User Location Information IE nor UE Time Zone IE
nor User CSG Information IE nor Serving Network IE from the MME in step 15, no message is sent in this step
and downlink packets from the Serving-GW are immediately sent on to the target eNodeB.
Serving GW shall forward the "end marker" packets to the source eNodeB. If data forwarding -direct or indirect)
occurs, the source eNodeB shall forward the "end marker" packets to the target eNodeB via the forwarding
tunnel.
17. The Serving GW shall return a Modify Bearer Response (Serving GW address and TEID for uplink traffic)
message to the MME as a response to a Modify Bearer Request message, or a Modify Access Bearers Response
(Serving GW address and TEID for uplink traffic) as a response to a Modify Access Bearers Request message. If
the Serving GW cannot serve the MME Request in the Modify Access Bearers Request message without S5/S8
limited to S1-U bearers, and the MME shall repeat its request using Modify Bearer Request message per PDN
connection.
If the Serving GW does not change, the Serving GW shall send one or more "end marker" packets on the old
path immediately after switching the path in order to assist the reordering function in the target eNodeB. If data
forwarding (direct or indirect) occurs, the source eNodeB shall forward the "end marker" packets to the target
eNodeB via the forwarding tunnel.
For a UE supporting CIoT EPS Optimisations, the EPS bearer status information shall be included in the TAU
Request. The MME shall then indicate the EPS bearer status to the UE in the TAU Accept and the UE shall
locally release any non-transferred bearer.
The target MME knows that it is a Handover procedure that has been performed for this UE as it received the
bearer context(s) by handover messages and therefore the target MME performs only a subset of the TA update
procedure, specifically it excludes the context transfer procedures between source MME and target MME. In this
case, the target MME shall set the Header Compression Context Status for each EPS Bearer in the TAU Accept
message based on information obtained in step 3.
19. When the timer started in step 14 expires the source MME sends a UE Context Release Command () message to
the source eNodeB. The source eNodeB releases its resources related to the UE and responds with a UE Context
Release Complete () message. When the timer started in step 14 expires and if the source MME received the
Serving GW change indication in the Forward Relocation Response message, it deletes the EPS bearer resources
by sending Delete Session Request (Cause, LBI, Operation Indication, Secondary RAT usage data) messages to
the Source Serving GW. The operation Indication flag is not set, that indicates to the Source Serving GW that the
Source Serving GW shall not initiate a delete procedure towards the PDN GW. Secondary RAT usage data is
included if it was received in step 9b. The Source Serving GW acknowledges with Delete Session Response ()
messages. If ISR has been activated before this procedure, the cause indicates to the Source S-GW that the
Source S-GW shall delete the bearer resources on the other old CN node by sending Delete Bearer Request
message(s) to that CN node.
20. If indirect forwarding was used then the expiry of the timer at source MME started at step 14 triggers the source
MME to send a Delete Indirect Data Forwarding Tunnel Request message to the S-GW to release the temporary
resources used for indirect forwarding that were allocated at step 8.
21. If indirect forwarding was used and the Serving GW is relocated, then the expiry of the timer at target MME
started at step 14 triggers the target MME to send a Delete Indirect Data Forwarding Tunnel Request message to
the target S-GW to release temporary resources used for indirect forwarding that were allocated at step 6.
5.5.1.2.3 S1-based handover, Reject

The Target eNodeB rejects the use of the Handover procedure if none of the requested bearers in the Handover Request
message could be established. In this case no UE context is established in the target MME/eNodeB and no resources are
allocated. Further, the Target MME rejects the handover request and clears all resource in Target eNodeB and Target
3GPP
Release 15 253 3GPP TS 23.401 V15.10.0 (2019-12)
MME if the Target eNodeB accepts the handover request but none of the default EPS bearers gets resources allocated.
In both cases, the UE remains in the Source eNodeB/MME.
Source Target Source Target Source Target Serving

UE eNodeB eNodeB MME MME Serving GW GW PDN GW HSS
1. Decision to trigger a
relocation via S1
5. Handover Request 4a. Create Session Response
6a. Handover Failure

6b. Handover Request Acknowledge
. 7a. Delete Session Response
8. Forward Relocation Response (Reject)
9. Handover Preparation Failure
Figure 5.5.1.2.3-1: S1-based handover, Reject
NOTE 1: Steps 3, 4, 7 and 8 are performed if the MME is relocated.
NOTE 2: If the MME is not relocated Steps 5 and 6 are performed by the source MME and, in the description
below, the source MME acts as the target MME.
1-5. Steps 1 to 5 in the flow are identical to steps 1-5 in clause 5.5.1.2.2.
6a. If the Target eNodeB fails to allocate any resources for any of the requested EPS bearers it sends a Handover
Failure (Cause) message to the Target MME. The Target MME clears any reserved resources for this UE in the
target MME.
6b. If the Target MME receives a Handover Request Acknowledge message from the Target eNodeB but none of the
default EPS bearers are in the EPS Bearer Setup list IE, the Target MME clears any reserved resources for this
UE in both the Target MME and the Target eNodeB.
7. This step is only performed for Serving GW relocation, i.e. if steps 4/4a have been performed. The Target MME
deletes the EPS bearer resources by sending Delete Session Request (Cause) messages to the Target Serving
GW. The Target Serving GW acknowledges with Delete Session Response (Cause) messages.
8. The Target MME sends the Forward Relocation Response (Cause) message to the Source MME.
9. When the Source MME receives the Forward Relocation Response message, it sends a Handover Preparation
Failure (Cause) message to the Source eNodeB.
5.5.1.2.4 S1-based handover, Cancel

Instead of completing the handover procedure, the source eNodeB may at any time during the handover procedure, up
to the time when a handover command message is sent to the UE cancel the handover.
The MME shall cancel the handover resources as defined in clause 5.5.2.5.1 for case the source RAN is eNodeB.
5.5.2 Inter RAT handover
5.5.2.0 General
During Inter RAT handover indirect forwarding may apply for the downlink data forwarding performed as part of the
handover. From its configuration data the MME knows whether indirect forwarding applies and it allocates a downlink
3GPP
Release 15 254 3GPP TS 23.401 V15.10.0 (2019-12)
data forwarding path on a Serving GWs for indirect forwarding. From its configuration data the S4 SGSN knows
whether indirect forwarding applies and it allocates downlink data forwarding paths on Serving GWs for indirect
forwarding. It is configured on MME and S4 SGSN whether indirect downlink data forwarding does not apply, applies
always or applies only for inter PLMN inter RAT handovers.
During the handover procedure, the source MME shall reject any PDN GW initiated EPS bearer(s) request received
since handover procedure started and shall include an indication that the request has been temporarily rejected due to
handover procedure in progress. The rejection is forwarded by the Serving GW to the PDN GW, with the indication that
the request has been temporarily rejected.
been temporarily rejected due to handover procedure in progress, the PDN GW behaves as specified in clause 5.5.1.2.1.
For inter-PLMN handover to a CSG cell, if the source MME/S4-SGSN has the CSG-ID list of the target PLMN, the
source MME/S4-SGSN shall use it to validate the CSG membership of the UE in the target CSG cell. Otherwise, based
on operator's configuration the source MME/S4-SGSN may allow the handover by validating the CSG membership of
the UE in the target CSG cell using the CSG-ID list of the registered PLMN-ID. If neither the CSG-ID list of the target
PLMN nor the operator's configuration permits the handover, the source MME/S4-SGSN shall reject the handover due
to no CSG membership information of the target PLMN-ID
NOTE 1: Inter-PLMN handover to a CSG cell in a PLMN which is not an equivalent PLMN for the UE is not
supported.
NOTE 2: Inter-PLMN handover to a CSG cell of an equivalent PLMN is only supported if the CSG-ID of the cell is
in the CSG-ID list of both equivalent PLMNs.
NOTE 3: Upon bearer loss or UE-detected bearer QoS degradation during inter-RAT 3GPP handover, after
receiving the Handover Command the UE can adopt an implementation dependent mechanism to trigger
the handover of one or more PDN connections or mobility of one or more IP flows to WLAN (e.g. taking
into account policies obtained from ANDSF).
5.5.2.1 E-UTRAN to UTRAN Iu mode Inter RAT handover
5.5.2.1.1 General
Pre-conditions:
- The UE is in ECM-CONNECTED state (E-UTRAN mode).
If emergency bearer services are ongoing for an UE, handover to the target RNC is performed independent of the
Handover Restriction List. The SGSN checks, as part of the Routing Area Update in the execution phase, if the
handover is to a restricted area and if so SGSN deactivate the non-emergency PDP context as specified in
TS 23.060 [7], clause 9.2.4.2.
If emergency bearer services are ongoing for the UE, the source MME evaluates the handover to the target CSG cell
independent of the UE's CSG subscription. If the handover is to a CSG cell that the UE is not subscribed, the target
RNC will only accept the emergency bearers and the target SGSN deactivates the non-emergency PDP contexts that
were not accepted by the target RNC as specified in TS 23.060 [7], clause 9.2.4.2.
3GPP
Release 15 255 3GPP TS 23.401 V15.10.0 (2019-12)
5.5.2.1.2 Preparation phase
Source Source Target

UE eNodeB Target RNC Source MME Target SGSN Serving GW Serving GW PDN GW HSS
Uplink and DownlinkUser Plane PDUs
1. Handover Initiation
2. Handover Required 3. Forward Relocation Request

5. RelocationRequest
5a. Relocation Request Acknowledge


Figure 5.5.2.1.2-1: E-UTRAN to UTRAN Iu mode Inter RAT HO, preparation phase
1. The source eNodeB decides to initiate an Inter-RAT handover to the target access network, UTRAN Iu mode. At
this point both uplink and downlink user data is transmitted via the following: Bearer(s) between UE and source
eNodeB, GTP tunnel(s) between source eNodeB, Serving GW and PDN GW.
If the UE has an ongoing emergency bearer service the source eNodeB shall not initiate PS handover to a
UTRAN cell that is not IMS voice capable.
NOTE 1: The process leading to the handover decision is outside of the scope of this specification.
2. The source eNodeB sends a Handover Required (S1AP Cause, Target RNC Identifier, CSG ID, CSG access
mode, Source to Target Transparent Container) message to the source MME to request the CN to establish
resources in the target RNC, target SGSN and the Serving GW. The bearers that will be subject to data
forwarding (if any) are identified by the target SGSN in a later step (see step 7 below). When the target cell is a
CSG cell or a hybrid cell, the source eNodeB shall include the CSG ID of the target cell. If the target cell is a
hybrid cell, the CSG access mode shall be indicated.
3. The source MME determines from the 'Target RNC Identifier' IE that the type of handover is IRAT Handover to
UTRAN Iu mode. The source MME selects the target SGSN as described in clause 4.3.8.4 on "SGSN Selection
Function". The Source MME initiates the Handover resource allocation procedure by sending a Forward
Relocation Request (IMSI, Target Identification, CSG ID, CSG Membership Indication, MM Context, PDN
Connections, MME Tunnel Endpoint Identifier for Control Plane, MME Address for Control plane, Source to
Target Transparent Container, RAN Cause, MS Info Change Reporting Action (if available), CSG Information
Reporting Action (if available), UE Time Zone, ISR Supported, Serving Network) message to the target SGSN.
The information ISR Supported is indicated if the source MME and associated Serving GW are capable to
activate ISR for the UE. When ISR is activated the message should be sent to the SGSN that maintains ISR for
the UE when this SGSN is serving the target identified by the Target Identification. This message includes all
PDN Connections active in the source system and for each PDN Connection includes the associated APN, the
address and the uplink Tunnel endpoint parameters of the Serving GW for control plane, and a list of EPS Bearer
Contexts. RAN Cause indicates the S1AP Cause as received from source eNodeB. The old Serving Network is
sent to target MME to support the target MME to resolve if Serving Network is changed.
The source MME shall perform access control by checking the UE's CSG subscription when CSG ID is provided
by the source eNodeB. If there is no subscription data for this CSG ID or the CSG subscription is expired, and
the target cell is a CSG cell, the source MME shall reject the handover with an appropriate cause unless the UE
has emergency bearer services.
3GPP
Release 15 256 3GPP TS 23.401 V15.10.0 (2019-12)
The source MME includes the CSG ID in the Forward Relocation Request when the target cell is a CSG cell or
The MM context includes information on the EPS Bearer context(s). The source MME does not include any EPS
Bearer Context information for "Non-IP" bearers or for any SCEF connection. If none of the UE's EPS Bearers
can be supported by the selected target SGSN, the source MME rejects the handover attempt by sending a
Handover Preparation Failure (Cause) message to the Source eNodeB.
included EPS Bearers after step 6 of the Execution procedure. The non-included bearers are locally
released by the UE following the Bearer Context Status synchronisation that occurs during the Routing
Area Update at step 10 of the Execution procedure.
The target SGSN maps the EPS bearers to PDP contexts 1-to-1 and maps the EPS Bearer QoS parameter values
of an EPS bearer to the Release 99 QoS parameter values of a bearer context as defined in Annex E
Prioritization of PDP Contexts is performed by the target core network node, i.e. target SGSN.
The MM context contains security related information, e.g. supported ciphering algorithms as described in
TS 29.274 [43]. Handling of security keys is described in TS 33.401 [41].
The target SGSN shall determine the Maximum APN restriction based on the APN Restriction of each bearer
context in the Forward Relocation Request, and shall subsequently store the new Maximum APN restriction
value.
source MME shall include the Local Home Network ID of the source cell in the PDN Connections
4. The target SGSN determines if the Serving GW is to be relocated, e.g., due to PLMN change. If the Serving GW
is to be relocated, the target SGSN selects the target Serving GW as described under clause 4.3.8.2 on "Serving
GW selection function", and sends a Create Session Request message (IMSI, SGSN Tunnel Endpoint Identifier
for Control Plane, SGSN Address for Control plane, PDN GW address(es) for user plane, PDN GW UL TEID(s)
for user plane, PDN GW address(es) for control plane, and PDN GW TEID(s) for control plane, the Protocol
Type over S5/S8, Serving Network) per PDN connection to the target Serving GW. The Protocol Type over
S5/S8 is provided to Serving GW which protocol should be used over S5/S8 interface.
The target SGSN establishes the EPS Bearer context(s) in the indicated order. The SGSN deactivates, as
provided in step 7 of the execution phase, the EPS Bearer contexts which cannot be established.
4a. The target Serving GW allocates its local resources and returns a Create Session Response (Serving GW
address(es) for user plane, Serving GW UL TEID(s) for user plane, Serving GW Address for control plane,
Serving GW TEID for control plane) message to the target SGSN.
5. The target SGSN requests the target RNC to establish the radio network resources (RABs) by sending the
message Relocation Request (UE Identifier, Cause, CN Domain Indicator, Integrity protection information (i.e.
IK and allowed Integrity Protection algorithms), Encryption information (i.e. CK and allowed Ciphering
algorithms), RAB to be setup list, CSG ID, CSG Membership Indication, Source RNC to Target RNC
Transparent Container, Service Handover related information). If the Access Restriction is present in the MM
context, the Service Handover related information shall be included by the target SGSN for the Relocation
Request message in order for RNC to restrict the UE in connected mode to handover to the RAT prohibited by
the Access Restriction.
For each RAB requested to be established, RABs To Be Setup shall contain information such as RAB ID, RAB
parameters, Transport Layer Address, and Iu Transport Association. The RAB ID information element contains
the NSAPI value, and the RAB parameters information element gives the QoS profile. The Transport Layer
Address is the Serving GW Address for user plane (if Direct Tunnel is used) or the SGSN Address for user plane
(if Direct Tunnel is not used), and the Iu Transport Association corresponds to the uplink Tunnel Endpoint
Identifier Data in Serving GW or SGSN respectively.
Ciphering and integrity protection keys are sent to the target RNC to allow data transfer to continue in the new
RAT/mode target cell without requiring a new AKA (Authentication and Key Agreement) procedure.
3GPP
Release 15 257 3GPP TS 23.401 V15.10.0 (2019-12)
Information that is required to be sent to the UE (either in the Relocation Command message or after the
handover completion message) from RRC in the target RNC shall be included in the RRC message sent from the
target RNC to the UE via the transparent container. More details are described in TS 33.401 [41].
The Target SGSN shall include the CSG ID and CSG Membership Indication when provided by the source
MME in the Forward Relocation Request message.
In the target RNC radio and Iu user plane resources are reserved for the accepted RABs. Cause indicates the
RAN Cause as received from source MME. The Source RNC to Target RNC Transparent Container includes the
value from the Source to Target Transparent Container received from the source eNodeB.
If the target cell is a CSG cell, the target RNC shall verify the CSG ID provided by the target SGSN, and reject
the handover with an appropriate cause if it does not match the CSG ID for the target cell. If the target cell is in
hybrid mode, the target RNC may use the CSG Membership Indication to perform differentiated treatment for
CSG and non-CSG members. If the target cell is a CSG cell, and if the CSG Membership Indication is "non
member", the target RNC only accepts the emergency bearers.
5a. The target RNC allocates the resources and returns the applicable parameters to the target SGSN in the message
Relocation Request Acknowledge (Target RNC to Source RNC Transparent Container, RABs setup list, RABs
failed to setup list).
Upon sending the Relocation Request Acknowledge message the target RNC shall be prepared to receive
downlink GTP PDUs from the Serving GW, or Target SGSN if Direct Tunnel is not used, for the accepted
RABs.
Each RABs setup list is defined by a Transport Layer Address, which is the target RNC Address for user data,
and the Iu Transport Association, which corresponds to the downlink Tunnel Endpoint Identifier for user data.
Any EPS Bearer contexts for which a RAB was not established are maintained in the target SGSN and the UE.
These EPS Bearer contexts shall be deactivated by the target SGSN via explicit SM procedures upon the
completion of the routing area update (RAU) procedure.
6. If 'Indirect Forwarding' and relocation of Serving GW apply and Direct Tunnel is used the target SGSN sends a
Create Indirect Data Forwarding Tunnel Request message (Target RNC Address and TEID(s) for DL data
forwarding) to the Serving GW. If 'Indirect Forwarding' and relocation of Serving GW apply and Direct Tunnel
is not used, then the target SGSN sends a Create Indirect Data Forwarding Tunnel Request message (SGSN
Address and TEID(s) for DL data forwarding) to the Serving GW.
6a. The Serving GW returns a Create Indirect Data Forwarding Tunnel Response (Cause, Serving GW Address(es)
and Serving GW DL TEID(s) for data forwarding) message to the target SGSN.
7. The target SGSN sends the message Forward Relocation Response (Cause, SGSN Tunnel Endpoint Identifier for
Control Plane, SGSN Address for Control Plane, Target to Source Transparent Container, Cause, RAB Setup
Information, Additional RAB Setup Information, Address(es) and TEID(s) for User Traffic Data Forwarding,
Serving GW change indication) to the source MME. Serving GW change indication indicates a new Serving GW
has been selected. The Target to Source Transparent Container contains the value from the Target RNC to
Source RNC Transparent Container received from the target RNC.
The IE 'Address(es) and TEID(s) for User Traffic Data Forwarding' defines the destination tunnelling endpoint
for data forwarding in target system, and it is set as follows:
- If 'Direct Forwarding' applies, or if 'Indirect Forwarding' and no relocation of Serving GW apply and Direct
Tunnel is used, then the IE 'Address(es) and TEID(s) for User Traffic Data Forwarding' contains the
addresses and GTP-U tunnel endpoint parameters to the Target RNC received in step 5a.
- If 'Indirect Forwarding' and relocation of Serving GW apply, then the IE 'Address(es) and TEID(s) for User
Traffic Data Forwarding' contains the addresses and DL GTP-U tunnel endpoint parameters to the Serving
GW received in step 6. This is independent from using Direct Tunnel or not.
- If 'Indirect Forwarding' applies and Direct Tunnel is not used and relocation of Serving GW does not apply,
then the IE 'Address(es) and TEID(s) for User Traffic Data Forwarding' contains the DL GTP-U tunnel
endpoint parameters to the Target SGSN.
3GPP
Release 15 258 3GPP TS 23.401 V15.10.0 (2019-12)
8. If "Indirect Forwarding" applies, the Source MME sends the message Create Indirect Data Forwarding Tunnel
Request (Address(es) and TEID(s) for Data Forwarding (received in step 7)), EPS Bearer ID(s)) to the Serving
GW used for indirect forwarding.
8a. The Serving GW returns the forwarding parameters by sending the message Create Indirect Data Forwarding
Tunnel Response (Cause, Serving GW Address(es) and TEID(s) for Data Forwarding). If the Serving GW
doesn't support data forwarding, an appropriate cause value shall be returned and the Serving GW Address(es)
and TEID(s) will not be included in the message.
5.5.2.1.3 Execution phase

Uplink and Downlink User Plane PDUs
1. Handover Command
2. HO from- E-UTRAN Command
3. RAN Usage data report
4. UTRAN Iu Access Procedures
4a. Handover to UTRAN Complete
Sending of Downlink User Plane PDUs

uplink data
possible If Direct Forwarding applies
Via Target SGSN in case Direct Tunnel is not used If Indirect Forwarding applies.
5. Relocation Complete

6a. Forward Relocation Complete Acknowledge
For Serving GW relocation Steps 7, 8 and 9, 8. Modify Bearer Request

and the following User Plane path, will be (A)
handled by Target Serving GW 8a. Modify Bearer Response
Uplink and Downlink User Plane PDUs (Via Target SGSN if Direct Tunnel is not used)
10. Routeing Area Update procedure

11b. Release Resources
(B)
11a. Delete Session Response
12. Delete Indirect Data Forwarding Tunnel Request
12a. Delete Indirect Data Forwarding Tunnel Response
Figure 5.5.2.1.3-1: E-UTRAN to UTRAN Iu mode Inter RAT HO, execution phase
3GPP
Release 15 259 3GPP TS 23.401 V15.10.0 (2019-12)
NOTE: For a PMIP-based S5/S8, procedure steps (A) and (B) are defined in TS 23.402 [2]. Step (B) shows PCRF
interaction in the case of PMIP-based S5/S8. Steps 8 and 8a concern GTP based S5/S8
The source eNodeB continues to receive downlink and uplink user plane PDUs.
1. The source MME completes the preparation phase towards source eNodeB by sending the message Handover
Command (Target to Source Transparent Container, E-RABs to Release List, Bearers Subject to Data
Forwarding List). The "Bearers Subject to Data forwarding list" IE may be included in the message and it shall
be a list of 'Address(es) and TEID(s) for user traffic data forwarding' received from target side in the preparation
phase (Step 7 of the preparation phase) when 'Direct Forwarding' applies, or the parameters received in Step 8a
of the preparation phase when 'Indirect Forwarding' applies.
The source eNodeB initiates data forwarding for bearers specified in the "Bearers Subject to Data Forwarding
List". The data forwarding may go directly to target RNC or alternatively go via the Serving GW if so decided
by source MME and or/ target SGSN in the preparation phase.
2. The source eNodeB will give a command to the UE to handover to the target access network via the message HO
from E-UTRAN Command. This message includes a transparent container including radio aspect parameters that
the target RNC has set-up in the preparation phase. The details of this E-UTRAN specific signalling are
Upon the reception of the HO from E-UTRAN Command message containing the Handover Command message,
the UE shall associate its bearer IDs to the respective RABs based on the relation with the NSAPI and shall
suspend the uplink transmission of the user plane data.
3. If the PLMN has configured Secondary RAT usage data reporting and the source eNodeB has Secondary RAT
usage data to report, the eNodeB sends the RAN Usage data report message (Secondary RAT usage data) to the
MME. Since the handover is an inter-RAT handover, the MME continues with the Secondary RAT usage data
reporting procedure as in clause 5.7A.3. The reporting procedure in clause 5.7A.3 is only performed if PGW
secondary RAT usage reporting is active.
4. The UE moves to the target UTRAN Iu (3G) system and executes the handover according to the parameters
provided in the message delivered in step 2. The procedure is the same as in step 6 and 8 in clause 5.2.2.2 in
TS 43.129 [8] with the additional function of association of the received RABs and existing Bearer Id related to
the particular NSAPI.
The UE may resume the user data transfer only for those NSAPIs for which there are radio resources allocated in
the target RNC.
5. When the new source RNC-ID + S-RNTI are successfully exchanged with the UE, the target RNC shall send the
Relocation Complete message to the target SGSN. The purpose of the Relocation Complete procedure is to
indicate by the target RNC the completion of the relocation from the source E-UTRAN to the RNC. After the
reception of the Relocation Complete message the target SGSN shall be prepared to receive data from the target
RNC. Each uplink N-PDU received by the target SGSN is forwarded directly to the Serving GW.
For SIPTO at the Local Network with stand-alone GW architecture, the target RNC shall include the Local
Home Network ID of the target cell in the Relocation Complete message.
6. Then the target SGSN knows that the UE has arrived to the target side and target SGSN informs the source
MME by sending the Forward Relocation Complete Notification (ISR Activated, Serving GW change) message.
If indicated, ISR Activated indicates to the source MME that it shall maintain the UE's context and that it shall
activate ISR, which is only possible when the S-GW is not changed. The source MME will also acknowledge
that information. A timer in source MME is started to supervise when resources in Source eNodeB and Source
Serving GW (for Serving GW relocation) shall be released.
When the timer expires and ISR Activated is not indicated by the target SGSN the source MME releases all
bearer resources of the UE. If Serving GW change is indicated and this timer expires the source MME deletes
the EPS bearer resources by sending Delete Session Request (Cause, Operation Indication) messages to the
Source Serving GW. The operation Indication flag is not set, that indicates to the Source Serving GW that the
Source Serving GW shall not initiate a delete procedure towards the PDN GW. If ISR has been activated before
this procedure, the cause indicates to the Source S-GW that the Source S-GW shall delete the bearer resources on
the other old CN node by sending Delete Bearer Request message(s) to that CN node.
3GPP
Release 15 260 3GPP TS 23.401 V15.10.0 (2019-12)
Upon receipt of the Forward Relocation Complete Acknowledge message the target SGSN starts a timer if the
target SGSN allocated S-GW resources for indirect forwarding.
7. The target SGSN will now complete the Handover procedure by informing the Serving GW (for Serving GW
relocation this will be the Target Serving GW) that the target SGSN is now responsible for all the EPS Bearer
Contexts the UE has established. This is performed in the message Modify Bearer Request (SGSN Tunnel
Endpoint Identifier for Control Plane, NSAPI(s), SGSN Address for Control Plane, SGSN Address(es) and
TEID(s) for User Traffic for the accepted EPS bearers (if Direct Tunnel is not used) or RNC Address(es) and
TEID(s) for User Traffic for the accepted EPS bearers (if Direct Tunnel is used) and RAT type, ISR Activated)
per PDN connection. As it is a mobility from E-UTRAN, if the target SGSN supports location information
change reporting, the target SGSN shall include the User Location Information (according to the supported
granularity) in the Modify Bearer Request, regardless of whether location information change reporting had been
requested in the previous RAT by the PDN GW. If the PDN GW requested User CSG information (determined
from the UE context), the SGSN also includes the User CSG Information IE in this message. If the UE Time
Zone has changed, the SGSN includes the UE Time Zone IE in this message. If Serving GW is not relocated but
the Serving Network has changed or if the SGSN has not received any old Serving Network information from
the old MME, the SGSN includes the new Serving Network IE in this message. In network sharing scenarios
Serving Network denotes the serving core network. If indicated, the information ISR Activated indicates that
ISR is activated, which is only possible when the S-GW is not changed. When the Modify Bearer Request does
not indicate ISR Activated and S-GW is not changed, the S-GW deletes any ISR resources by sending a Delete
Bearer Request to the other CN node that has bearer resources on the S-GW reserved.
The SGSN releases the non-accepted EPS Bearer contexts by triggering the Bearer Context deactivation
procedure. If the Serving GW receives a DL packet for a non-accepted bearer, the Serving GW drops the DL
packet and does not send a Downlink Data Notification to the SGSN.
8. The Serving GW (for Serving GW relocation this will be the Target Serving GW) may inform the PDN GW(s)
the change of for example for Serving GW relocation or the RAT type that e.g. can be used for charging, by
sending the message Modify Bearer Request per PDN connection. The S-GW also includes User Location
Information IE and/or UE Time Zone IE and/or User CSG Information IE if they are present in step 7. Serving
Network should be included if it is received in step 7 or in step 4 in clause 5.5.2.1.2. For Serving GW relocation,
the Serving GW allocates DL TEIDs on S5/S8 even for non-accepted bearers and may include the PDN
Charging Pause Support Indication. The PDN GW must acknowledge the request with the message Modify
Bearer Response. In the case of Serving GW relocation, the PDN GW updates its context field and returns a
Modify Bearer Response (Charging Id, MSISDN, PDN Charging Pause Enabled Indication (if PDN GW has
chosen to enable the function), etc.) message to the Serving GW. The MSISDN is included if the PDN GW has it
stored in its UE context. If location information change reporting is required and supported in the target SGSN,
the PDN GW shall provide MS Info Change Reporting Action in the Modify Bearer Response.
If PCC infrastructure is used, the PDN GW informs the PCRF about the change of, for example, the RAT type.
immediately after switching the path. The source Serving GW shall forwards the "end marker" packets to the
source eNodeB.
9. The Serving GW (for Serving GW relocation this will be the Target Serving GW) acknowledges the user plane
switch to the target SGSN via the message Modify Bearer Response (Cause, Serving GW Tunnel Endpoint
Identifier for Control Plane, Serving GW Address for Control Plane, Protocol Configuration Options, MS Info
Change Reporting Action). At this stage the user plane path is established for all EPS Bearer contexts between
the UE, target RNC, target SGSN if Direct Tunnel is not used, Serving GW (for Serving GW relocation this will
be the Target Serving GW) and PDN GW.
path immediately after switching the path.
10. When the UE recognises that its current Routing Area is not registered with the network, or when the UE's TIN
indicates "GUTI", the UE initiates a Routing Area Update procedure with the target SGSN informing it that the
UE is located in a new routing area. It is RAN functionality to provide the PMM-CONNECTED UE with
Routing Area information.
3GPP
Release 15 261 3GPP TS 23.401 V15.10.0 (2019-12)
The target SGSN knows that an IRAT Handover has been performed for this UE as it received the bearer
context(s) by handover messages and therefore the target SGSN performs only a subset of the RAU procedure,
specifically it excludes the context transfer procedures between source MME and target SGSN.
For a UE supporting CIoT EPS Optimisations, the UE uses the bearer status information in the RAU Accept to
identify any non-transferred bearers that it shall locally release.
11. When the timer started at step 6 expires, the source MME sends a Release Resources message to the Source
eNodeB. The Source eNodeB releases its resources related to the UE.
When the timer started in step 6 expires and if the source MME received the Serving GW change indication in
the Forward Relocation Response message, it deletes the EPS bearer resources by sending Delete Session
Request (Cause, Operation Indication, Secondary RAT usage data) messages to the Source Serving GW. The
operation indication flag is not set, that indicates to the Source Serving GW that the Source Serving GW shall
not initiate a delete procedure towards the PDN GW. Secondary RAT usage data is included if it was received in
step 3. The Source Serving GW acknowledges with Delete Session Response (Cause) messages. If ISR has been
activated before this procedure, the cause indicates to the Source S-GW that the Source S-GW shall delete the
bearer resources on the other old CN node by sending Delete Bearer Request message(s) to that CN node.
resources used for indirect forwarding.
13. If indirect forwarding was used and the Serving GW is relocated, then the expiry of the timer at target SGSN
started at step 6 triggers the target SGSN to send a Delete Indirect Data Forwarding Tunnel Request message to
the target S-GW to release temporary resources used for indirect forwarding.
5.5.2.1.4 E-UTRAN to UTRAN Iu mode Inter RAT handover Reject

The Target RNC may reject the use of the Handover procedure if none of the requested RABs in the Relocation Request
message could be established. In this case no UE context is established in the target SGSN/RNC and no resources are
allocated. The UE remains in the Source eNodeB/MME.

5. Relocation Request
6. Relocation Failure
.8. Forward Relocation Response (Reject)
Figure 5.5.2.1.4-1: E-UTRAN to UTRAN Iu mode Inter RAT HO reject
1. The Step 1 to 5 in the flow are identical to the ones in clause 5.5.2.1.2.
6. If the Target RNC fails to allocate any resources for any of the requested RABs it sends a Relocation Failure
(Cause) message to the Target SGSN. When the Target SGSN receives the Relocation Failure message from
Target RNC the Target SGSN clears any reserved resources for this UE.
3GPP
Release 15 262 3GPP TS 23.401 V15.10.0 (2019-12)
7. This step is only performed for Serving GW relocation, i.e. if Steps 4/4a have been performed. The Target SGSN
8. The Target SGSN sends the Forward Relocation Response (Cause) message to the Source MME.
9. When the Source MME receives the Forward Relocation Response message it send a Handover Preparation
5.5.2.2 UTRAN Iu mode to E-UTRAN Inter RAT handover
5.5.2.2.1 General
The UTRAN Iu mode to E-UTRAN Inter RAT handover procedure takes place when the network decides to perform a
handover. The decision to perform PS handover from UTRAN Iu mode to E-UTRAN is taken by the network based on
radio condition measurements reported by the UE to the UTRAN RNC.
If emergency bearer services are ongoing for the UE, the MME checks as part of the Tracking Area Update in the
execution phase, if the handover is to a restricted area and if so MME releases the non-emergency bearers as specified
in clause 5.10.3.
If emergency bearer services are ongoing for the UE, the source SGSN evaluates the handover to the target CSG cell
independent of the UE's CSG subscription. If the handover is to a CSG cell that the UE is not subscribed, the target
eNodeB only accepts the emergency bearers and the target MME releases the non-emergency PDN connections that
were not accepted by the target eNodeB as specified in clause 5.10.3.
Source Target Target PDN

UE RNC eNodeB Source SGSN Target MME Serving GW Serving GW GW HSS
Uplink and Downlink User Plane PDUs (via Source SGSN in case Direct Tunnel is not used)
2. Relocation Required

5. Handover Request

Figure 5.5.2.2.2-1: UTRAN Iu mode to E-UTRAN Inter RAT HO, preparation phase
1. The source RNC decides to initiate an Inter-RAT handover to the E-UTRAN. At this point both uplink and
downlink user data is transmitted via the following: Bearers between UE and source RNC, GTP tunnel(s)
between source RNC, source SGSN (only if Direct Tunnel is not used), Serving GW and PDN GW.
3GPP
Release 15 263 3GPP TS 23.401 V15.10.0 (2019-12)
2. The source RNC sends a Relocation Required (Cause, Target eNodeB Identifier, CSG ID, CSG access mode,
Source RNC Identifier, Source RNC to Target RNC Transparent Container) message to the source SGSN to
request the CN to establish resources in the target eNodeB, Target MME and the Serving GW. The bearers that
will be subject to data forwarding (if any) are identified by the target MME in a later step (see step 7 below).
When the target cell is a CSG cell or a hybrid cell, the source RNC shall include the CSG ID of the target cell. If
the target cell is a hybrid cell, the CSG access mode shall be indicated.
3. The source SGSN determines from the 'Target eNodeB Identifier' IE that the type of handover is IRAT
Handover to E-UTRAN. The source SGSN selects the target MME as described in clause 4.3.8.3 on "MME
Selection Function". The Source SGSN initiates the Handover resource allocation procedure by sending Forward
Relocation Request (IMSI, Target Identification, CSG ID, CSG Membership Indication, MM Context, PDN
Connections, SGSN Tunnel Endpoint Identifier for Control Plane, SGSN Address for Control plane, Source to
Target Transparent Container, RAN Cause, MS Info Change Reporting Action (if available), CSG Information
Reporting Action (if available), UE Time Zone, ISR Supported, Serving Network, Change to Report (if present))
message to the target MME. This message includes all EPS Bearer contexts corresponding to all the bearers
established in the source system and the uplink Tunnel endpoint parameters of the Serving GW. If the
information ISR Supported is indicated, this indicates that the source SGSN and associated Serving GW are
capable to activate ISR for the UE. When ISR is activated the message should be sent to the MME that maintains
ISR for the UE when this MME is serving the target identified by the Target Identification. RAN Cause indicates
the Cause as received from source RNC. The Source to Target Transparent Container contains the value from the
Source RNC to Target RNC Transparent Container received from the Source RNC. The old Serving Network is
sent to target MME to support the target MME to resolve if Serving Network is changed.
Change to Report flag is included by the source SGSN if reporting of change of UE Time Zone, or Serving
Network, or both towards Serving GW / PDN GW was deferred by the source SGSN.
The source SGSN shall perform access control by checking the UE's CSG subscription when CSG ID is
provided by the source RNC. If there is no subscription data for this CSG ID or the CSG subscription is expired,
and the target cell is a CSG cell, the source SGSN shall reject the handover with an appropriate cause unless the
UE has emergency bearer services.
The source SGSN includes the CSG ID in the Forward Relocation Request when the target cell is a CSG cell or
This message includes all PDN Connections active in the source system and for each PDN Connection includes
the associated APN, the address and the uplink tunnel endpoint parameters of the Serving GW for control plane,
and a list of EPS Bearer Contexts.
Prioritization of EPS Bearer Contexts is performed by the target core network node.
The MM context contains security related information, e.g. UE Network capabilities and used UMTS integrity
and ciphering algorithm(s) as well as keys, as described in clause 5.7.2 (Information Storage for MME).
The target MME selects the NAS ciphering and integrity algorithms to use. These algorithms will be sent
transparently from the target eNodeB to the UE in the Target to Source Transparent Container (EPC part).
The MME establishes the EPS bearer(s) in the prioritized order. The MME deactivates, as provided in step 8 of
the execution phase, the EPS bearers which cannot be established.
context received in the Forward Relocation Request, and shall subsequently store the new Maximum APN
restriction value.
source SGSN shall include the Local Home Network ID of the source cell in the PDN Connections
4. The target MME determines if the Serving GW is to be relocated, e.g., due to PLMN change. If the Serving GW
is to be relocated, the target MME selects the target Serving GW as described under clause 4.3.8.2 on "Serving
GW selection function". The target MME sends a Create Session Request message (IMSI, MME Address and
TEID, MME Tunnel Endpoint Identifier for Control Plane, MME Address for Control plane, PDN GW
address(es) for user plane, PDN GW UL TEID(s) for user plane, PDN GW address for control plane, and PDN
3GPP
Release 15 264 3GPP TS 23.401 V15.10.0 (2019-12)
GW TEID(s) for control plane, the Protocol Type over S5/S8, Serving Network) per PDN connection to the
target Serving GW. The Protocol Type over S5/S8 is provided to Serving GW which protocol should be used
over S5/S8 interface.
4a. The target Serving GW allocates its local resources and returns them in a Create Session Response (Serving GW
Serving GW TEID for control plane) message to the target MME.
5. The target MME requests the target eNodeB to establish the bearer(s) by sending the message Handover Request
(UE Identifier, S1AP Cause, KeNB, allowed AS Integrity Protection and Ciphering algorithm(s), NAS Security
Parameters to E-UTRAN, EPS Bearers to be setup list, CSG ID, CSG Membership Indication, Source to Target
Transparent Container). The NAS Security Parameters to E-UTRAN includes the NAS Integrity Protection and
Ciphering algorithm(s), eKSI and NONCEMME are targeted for the UE. S1AP Cause indicates the RAN Cause as
received from source SGSN. The Source to Target Transparent Container contains the value from the RAN
Transparent Container received from the source SGSN.
NOTE 2: The target MME derives K'ASME from CK and IK in the MM context and associates it with eKSI, as
described in TS 33.401 [41] and selects NAS Integrity Protection and Ciphering algorithm(s). The MME
and UE derive the NAS keys and KeNB from K'ASME. If the MME shares an EPS security association with
the UE, the MME may activate this native EPS security context by initiating a NAS SMC procedure after
having completed the handover procedure.
For each EPS bearer requested to be established, 'EPS Bearers To Be Setup' IE shall contain information such as
ID, bearer parameters, Transport Layer Address, "Data forwarding not possible" indication, and S1 Transport
Association. The target MME ignores any Activity Status Indicator within an EPS Bearer Context and requests
the target eNodeB to allocate resources for all EPS Bearer Contexts received from the source side. The Transport
Layer Address is the Serving GW Address for user data, and the S1 Transport Association corresponds to the
uplink Tunnel Endpoint Identifier Data. "Data forwarding not possible" indication shall be included if the target
MME decides the corresponding bearer will not be subject to data forwarding.
The target MME shall include the CSG ID and CSG Membership Indication when provided by the source SGSN
in the Handover Request message.
The information about the selected NAS ciphering and integrity protection algorithm(s), KSI and NONCE MME
will be sent transparently from the target eNodeB to the UE in the Target to Source Transparent Container, and
in the message UTRAN HO Command from source RNC to the UE. This will then allow data transfer to
continue in the new RAT/mode target cell without requiring a new AKA (Authentication and Key Agreement)
procedure. More details are described in TS 33.401 [41].
If the target cell is a CSG cell, the target eNodeB shall verify the CSG ID provided by the target MME, and
reject the handover with an appropriate cause if it does not match the CSG ID for the target cell. If the target
eNodeB is in hybrid mode, it may use the CSG Membership Status to perform differentiated treatment for CSG
and non-CSG members. If the target cell is a CSG cell, and if the CSG Membership Indication is "non member",
the target eNodeB only accepts the emergency bearers.
5a. The target eNodeB allocates the requested resources and returns the applicable parameters to the target MME in
the message Handover Request Acknowledge (Target to Source Transparent Container, EPS Bearers setup list,
EPS Bearers failed to setup list). The target eNodeB shall ignore it if the number of radio bearers in the Source to
Target Transparent container does not comply with the number of bearers requested by the MME and allocate
bearers as requested by the MME. Upon sending the Handover Request Acknowledge message the target
eNodeB shall be prepared to receive downlink GTP PDUs from the Serving GW for the accepted EPS bearers.
The target eNodeB selects AS integrity and ciphering algorithm(s). In addition to the information provided by
the MME (eKSI, NAS Integrity Protection and Ciphering algorithm(s) and NONCE MME), the target eNodeB
inserts AS integrity and ciphering algorithm(s) into the UTRAN RRC message, which is contained in the Target
to Source Transparent Container.
6. If 'Indirect Forwarding' and relocation of Serving GW apply the target MME sends a Create Indirect Data
Forwarding Tunnel Request message (Target eNodeB Address, TEID(s) for DL data forwarding) to the Serving
GW.
3GPP
Release 15 265 3GPP TS 23.401 V15.10.0 (2019-12)
and Serving GW DL TEID(s) for data forwarding) message to the target MME.
7. The target MME sends the message Forward Relocation Response (Cause, List of Set Up RABs, EPS Bearers
setup list, MME Tunnel Endpoint Identifier for Control Plane, RAN Cause, MME Address for control plane,
Target to Source Transparent Container, Address(es) and TEID(s) for Data Forwarding, Serving GW change
indication) to the source SGSN. Serving GW change indication indicates whether a new Serving GW has been
selected. The Target to Source Transparent Container includes the value from the Target to Source Transparent
Container received from the target eNodeB.
The IE 'Address(es) and TEID(s) for User Traffic Data Forwarding' defines the destination tunnelling endpoint
for data forwarding in target system, and it is set as follows. If 'Direct Forwarding' or if 'Indirect Forwarding' but
no relocation of Serving GW applies, then the IEs 'Address(es) and TEID(s) for Data Forwarding' contains the
forwarding DL GTP-U tunnel endpoint parameters to the eNodeB received in step 5a.
If 'Indirect Forwarding' and relocation of Serving GW apply the IEs 'Address(es) and TEID(s) for Data
Forwarding' contains the DL GTP-U tunnel endpoint parameters to the Target eNodeB or to the forwarding
Serving GW received in step 6a.
8. If "Indirect Forwarding" applies, the source SGSN shall send the message Create Indirect Data Forwarding
Tunnel Request (Address(es) and TEID(s) for Data Forwarding (received in step 7)) to the Serving GW used for
8a. The Serving GW returns the forwarding user plane parameters by sending the message Create Indirect Data
Forwarding Tunnel Response (Cause, Serving GW Address(es) and TEID(s) for data forwarding). If the Serving
GW doesn't support data forwarding, an appropriate cause value shall be returned and the Serving GW
Address(es) and TEID(s) will not be included in the message.
3GPP
Release 15 266 3GPP TS 23.401 V15.10.0 (2019-12)
Source Target Source Target PDN

Uplink and Downlink User Plane PDUs (via Source SGSN if Direct Tunnel is not used)
1. Relocation Command
2. HO from UTRAN Command
4. E-UTRAN Access Procedures
5. HO to E-UTRAN Complete
Downlink Payload User Plane PDUs (via Source SGSN if Direct Tunnel is not used)
Sending of
uplink data If Direct Forwarding applies
possible Via Source SGSN in case Direct Tunnel is not used
If Indirect Forwarding applies
6. Handover Notify

12b. Iu Release (B)

Command/Completion
Figure 5.5.2.2.3-1: UTRAN Iu mode to E-UTRAN Inter RAT HO, execution phase
NOTE: For a PMIP-based S5/S8, procedure steps (A) and (B) are defined in TS 23.402 [2]. Step (B) shows PCRF
interaction in the case of PMIP-based S5/S8. Steps 9 and 9a concern GTP based S5/S8.
The source RNC continues to receive downlink and uplink user plane PDUs.
1. The source SGSN completes the preparation phase towards source RNC by sending the message Relocation
Command (Target RNC to Source RNC Transparent Container, RABs to be Released List, RABs Subject to
Data Forwarding List). The "RABs to be Released list" IE will be the list of all NSAPIs (RAB Ids) for which a
Bearer was not established in Target eNodeB. The "RABs Subject to Data forwarding list" IE may be included in
the message and it shall be a list of 'Address(es) and TEID(s) for user traffic data forwarding' received from
target side in step 7 of the preparation phase when 'Direct Forwarding' applies. If 'Indirect Forwarding' is
applicable and Direct Tunnel is used the "RABs Subject to Data Forwarding List" IE includes the parameters
received in Step 8a of the preparation phase. If 'Indirect Forwarding' is applicable and Direct Tunnel is not used
the "RABs Subject to Data Forwarding List" IE includes the source SGSN address(es) and TEID(s) allocated for
3GPP
Release 15 267 3GPP TS 23.401 V15.10.0 (2019-12)
indirect data forwarding by Source SGSN. The Target RNC to Source RNC Transparent Container contains the
value from the Target to Source Transparent Container received from the target MME.
2. The source RNC will command to the UE to handover to the target eNodeB via the message HO from UTRAN
Command. The access network specific message to UE includes a transparent container including radio aspect
parameters that the target eNodeB has set-up in the preparation phase.
The source RNC may initiate data forwarding for the indicated RABs/EPS Bearer contexts specified in the
"RABs Subject to Data Forwarding List". The data forwarding may go directly to target eNodeB, or alternatively
go via the Serving GW if so decided by source SGSN and/or target MME in the preparation phase.
Upon the reception of the HO from UTRAN Command message containing the Relocation Command message,
the UE shall associate its RAB IDs to the respective bearers ID based on the relation with the NSAPI and shall
3. Void.
4. The UE moves to the E-UTRAN and performs access procedures toward target eNodeB.
5. When the UE has got access to target eNodeB it sends the message HO to E-UTRAN Complete.
The UE shall implicitly derive the EPS bearers for which an E-RAB was not established from the HO from
UTRAN Command and deactivate them locally without an explicit NAS message at this step.
6. When the UE has successfully accessed the target eNodeB, the target eNodeB informs the target MME by
sending the message Handover Notify (TAI+ECGI, Local Home Network ID).
Home Network ID of the target cell in the Handover Notify message.
7. Then the target MME knows that the UE has arrived to the target side and target MME informs the source SGSN
by sending the Forward Relocation Complete Notification (ISR Activated, Serving GW change) message. If ISR
Activated is indicated, this indicates to the source SGSN that it shall maintain the UE's contexts and activate
ISR, which is only possible when the S-GW is not changed. The source SGSN shall also acknowledge that
information. A timer in source SGSN is started to supervise when resources in the in Source RNC and Source
Serving GW (for Serving GW relocation) shall be released
target MME applies indirect forwarding.
8. The target MME will now complete the Inter-RAT Handover procedure by informing the Serving GW (for
Serving GW relocation this will be the Target Serving GW) that the target MME is now responsible for all the
bearers the UE have established. This is performed in the message Modify Bearer Request (Cause, MME Tunnel
Endpoint Identifier for Control Plane, EPS Bearer ID, MME Address for Control Plane, eNodeB Address(es)
and TEID(s) for User Traffic for the accepted EPS bearers and RAT type, ISR Activated) per PDN connection.
As it is a mobility from UTRAN, if the target MME supports location information change reporting, the target
MME shall include the User Location Information (according to the supported granularity) in the Modify Bearer
Request, regardless of whether location information change reporting had been requested in the previous RAT
by the PDN GW. If the PDN GW requested User CSG information (determined from the UE context), the MME
also includes the User CSG Information IE in this message. If either the UE Time Zone has changed or Forward
Relocation Request message from source SGSN indicated pending UE Time Zone change reporting (via Change
to Report flag), the MME includes the UE Time Zone IE in this message. If either Serving GW is not relocated
but the Serving Network has changed or Forward Relocation Request message from source SGSN indicated
pending Serving Network change reporting (via Change to Report flag), the MME includes the new Serving
Network IE in this message. If indicated, the information ISR Activated indicates that ISR is activated, which is
only possible when the S-GW was not changed. When the Modify Bearer Request does not indicate ISR
Activated and S-GW is not changed, the S-GW deletes any ISR resources by sending a Delete Bearer Request to
the other CN node that has bearer resources on the S-GW reserved.
3GPP
Release 15 268 3GPP TS 23.401 V15.10.0 (2019-12)
9. The Serving GW (for Serving GW relocation this will be the Target Serving GW) may inform the PDN GW the
change of for example for Serving GW relocation or the RAT type that e.g. can be used for charging, by sending
the message Modify Bearer Request per PDN connection. The S-GW also includes User Location Information
IE and/or UE Time Zone IE and/or User CSG Information IE if they are present in step 8. Serving Network
should be included if it is received in step 8 or in step 4 in clause 5.5.2.2.2. For Serving GW relocation, the
Serving GW allocates DL TEIDs on S5/S8 even for non-accepted bearers and may include the PDN Charging
Pause Support Indication. The PDN GW must acknowledge the request with the message Modify Bearer
Response. In the case of Serving GW relocation, the PDN GW updates its context field and returns a Modify
Bearer Response (Charging Id, MSISDN, PDN Charging Pause Enabled Indication (if PDN GW has chosen to
enable the function), etc.) message to the Serving GW. The MSISDN is included if the PDN GW has it stored in
its UE context. If location information change reporting is required and supported in the target MME, the PDN
GW shall provide MS Info Change Reporting Action in the Modify Bearer Response.
Serving GW shall forward the "end marker" packets to the source SGSN or RNC.
switch to the target MME via the message Modify Bearer Response (Cause, Serving GW Tunnel Endpoint
Change Reporting Action). At this stage the user plane path is established for all bearers between the UE, target
eNodeB, Serving GW (for Serving GW relocation this will be the Target Serving GW) and PDN GW.
path immediately after switching the path in order to assist the reordering function in the target eNodeB.
The target MME knows that an IRAT Handover has been performed for this UE as it received the bearer
context(s) by handover messages and therefore the target MME performs only a subset of the TA update
procedure, specifically it excludes the context transfer procedures between source SGSN and target MME.
If the Subscription Data received from the HSS (during the TAU in step 11) contains information that is
necessary for the E-UTRAN to be aware of (e.g. a restriction in the UE's permission to use NR as a secondary
RAT, Unlicensed Spectrum or a combination of them), or an existing UE context in the MME indicates that the
UE is not permitted to use NR as a secondary RAT or Unlicensed Spectrum or a combination of them and the
MME has not provided this information to the target eNodeB during step 5 of the handover preparation phase,
then the MME sends an updated Handover Restriction List in the Downlink NAS Transport message that it sends
to RAN. If the UE is not allowed to use NR as Secondary RAT, the MME indicates that to the UE in TAU
Accept message.
12. When the timer started in step 7 expires the source SGSN will clean-up all its resources towards source RNC by
sending the Iu Release Command to the RNC. When there is no longer any need for the RNC to forward data,
the source RNC responds with an Iu Release Complete message.
When the timer started in step 7 expires and if the source SGSN received the Serving GW change indication in
Request (Cause, Operation Indication) messages to the Source Serving GW. The operation Indication flag is not
set, that indicates to the Source Serving GW that the Source Serving GW shall not initiate a delete procedure
towards the PDN GW. The Source Serving GW acknowledges with Delete Session Response (Cause) messages.
If ISR has been activated before this procedure, the cause indicates to the Source S-GW that the Source S-GW
shall delete the bearer resources on the other old CN node by sending Delete Bearer Request message(s) to that
CN node.
13. If indirect forwarding was used then the expiry of the timer at source SGSN started at step 7 triggers the source
SGSN to send a Delete Indirect Data Forwarding Tunnel Request message to the S-GW to release the temporary
3GPP
Release 15 269 3GPP TS 23.401 V15.10.0 (2019-12)
5.5.2.2.4 UTRAN Iu mode to E-UTRAN Inter RAT handover reject

The Target eNodeB may reject the use of the Handover procedure if none of the requested EPS bearers in the Handover
Request message could be established. In this case no UE context is established in the target MME/eNodeB and no
resources are allocated. The UE remains in the Source RNC/SGSN.
Source Target Source Target PDN

Uplink and Downlink User Plane PDUs (via Source SGSN in case Direct Tunnel is not used)

5. Handover Request
6. Handover Failure
9. Relocation Preparation Failure
Figure 5.5.2.2.4-1: UTRAN Iu mode to E-UTRAN Inter RAT HO reject
1. Steps 1 to 5 in the flow are identical to the ones in clause 5.5.2.2.2.
6. If the Target eNodeB fails to allocate any resources for any of the requested EPS Bearers it sends a Handover
Failure (Cause) message to the Target MME. When the Target MME receives the Handover Failure message
from Target eNodeB the Target MME clears any reserved resources for this UE.
7. This step is only performed for Serving GW relocation, i.e. if Steps 4/4a have been performed. The Target MME
8. The Target MME sends the Forward Relocation Response (Cause) message to the Source SGSN.
9. When the Source SGSN receives the Forward Relocation Response message it send a Relocation Preparation
Failure (Cause) message to the Source RNC.
5.5.2.3 E-UTRAN to GERAN A/Gb mode Inter RAT handover
5.5.2.3.1 General
The procedure is based on Packet-switched handover for GERAN A/Gb mode defined in TS 43.129 [8].
Pre-conditions:
- The UE is in ECM-CONNECTED state (E-UTRAN mode);
- The BSS must support PFM, Packet Flow Management, procedures.
3GPP
Release 15 270 3GPP TS 23.401 V15.10.0 (2019-12)

UE eNodeB Target BSS Source MME Target SGSN Serving GW Serving GW PDN GW HSS

5. PS Handover Request
5a. PS Handover Request Acknowledge
Figure 5.5.2.3.2-1: E-UTRAN to GERAN A/Gb Inter RAT HO, preparation phase
1. The source eNodeB decides to initiate an Inter RAT Handover to the target GERAN A/Gb mode (2G) system. At
this point both uplink and downlink user data is transmitted via the following: Bearer(s) between UE and Source
eNodeB, GTP tunnel(s) between Source eNodeB, Serving GW and PDN GW.
If the UE has an ongoing emergency bearer service the source eNodeB shall not initiate PS handover to GERAN.
NOTE 1: The process leading to the handover decision is outside of the scope of this specification
2. The source eNodeB sends a Handover Required (S1AP Cause, Target System Identifier, Source to Target
Transparent Container) message to the Source MME to request the CN to establish resources in the Target BSS,
Target SGSN and the Serving GW. The bearers that will be subject to data forwarding (if any) are identified by
the target SGSN in a later step (see step 7 below).
The 'Target System Identifier' IE contains the identity of the target global cell Id.
3. The Source MME determines from the 'Target System Identifier' IE that the type of handover is IRAT Handover
to GERAN A/Gb mode. The Source MME selects the Target SGSN as described in clause 4.3.8.4 on "SGSN
Selection Function". The Source MME initiates the Handover resource allocation procedure by sending a
Forward Relocation Request (IMSI, Target Identification (shall be set to "empty"), MM Context, PDN
Connections, MME Tunnel Endpoint Identifier for Control Plane, MME Address for Control plane, Source to
Target Transparent Container, Packet Flow ID, XID parameters (if available), Target Cell Identification, MS
Info Change Reporting Action (if available), CSG Information Reporting Action (if available), UE Time Zone,
ISR Supported, RAN Cause, Serving Network) message to the target SGSN. If the information ISR Supported is
indicated, this indicates that the source MME and associated Serving GW are capable to activate ISR for the UE.
When ISR is activated the message should be sent to the SGSN that maintains ISR for the UE when this SGSN is
serving the target identified by the Target Identification. This message includes all PDN Connections active in
the source system and for each PDN Connection includes the associated APN, the address and the uplink Tunnel
endpoint parameters of the Serving GW for control plane, and a list of EPS Bearer Contexts. The old Serving
Network is sent to target MME to support the target MME to resolve if Serving Network is changed. In network
sharing scenarios Serving Network denotes the serving core network.
The MM context includes information on the EPS Bearer context(s). If none of the UE's EPS Bearers can be
supported by the selected target SGSN, the source MME rejects the handover attempt by sending a Handover
Preparation Failure (Cause) message to the Source eNodeB.
3GPP
Release 15 271 3GPP TS 23.401 V15.10.0 (2019-12)
released by the UE following the Bearer Context Status synchronisation that occurs during the Routing
The target SGSN maps the EPS bearers to PDP contexts 1-to-1 and maps the EPS Bearer QoS parameter values
of an EPS bearer to the Release 99 QoS parameter values of a bearer context as defined in Annex E.
Prioritization of PDP Contexts is performed by the target core network node, i.e. target SGSN.
If the Source MME supports IRAT Handover to GERAN A/Gb procedure it has to allocate a valid PFI during
the bearer activation procedure. RAN Cause indicates the S1AP Cause as received from the source eNodeB. The
Source to Target Transparent Container includes the value from the Source to Target Transparent Container
received from the source eNodeB.
The MM context contains security related information, e.g. supported ciphering algorithms, as described in
The target SGSN selects the ciphering algorithm to use. This algorithm will be sent transparently from the target
SGSN to the UE in the NAS container for Handover (part of the Target to Source Transparent Container). The
IOV-UI parameter, generated in the target SGSN, is used as input to the ciphering procedure and it will also be
transferred transparently from the target SGSN to the UE in the NAS container for Handover. More details are
When the target SGSN receives the Forward Relocation Request message the required EPS Bearer, MM,
SNDCP and LLC contexts are established and a new P-TMSI is allocated for the UE. When this message is
received by the target SGSN, it begins the process of establishing PFCs for all EPS Bearer contexts.
When the target SGSN receives the Forward Relocation Request message it extracts from the EPS Bearer
Contexts the NSAPIs and SAPIs and PFIs to be used in the target SGSN. If for a given EPS Bearer Context the
target SGSN does not receive a PFI from the source MME, it shall not request the target BSS to allocate TBF
resources corresponding to that EPS Bearer Context. If none of the EPS Bearer Contexts forwarded from the
source MME has a valid PFI allocated the target SGSN shall consider this as a failure case and the request for
Handover shall be rejected.
If when an SAPI and PFI was available at the source MME but the target SGSN does not support the same SAPI
and PFI for a certain NSAPI as the source MME, the target SGSN shall continue the Handover procedure only
for those NSAPIs for which it can support the same PFI and SAPI as the source MME. All EPS Bearer contexts
for which no resources are allocated by the target SGSN or for which it cannot support the same SAPI and PFI
(i.e. the corresponding NSAPIs are not addressed in the response message of the target SGSN), are maintained
and the related SAPIs and PFIs are kept. These EPS Bearer contexts may be modified or deactivated by the
target SGSN via explicit SM procedures upon RAU procedure.
The source MME shall indicate the current XID parameter settings if available (i.e. those XID parameters
received during a previous IRAT Handover procedure) to the target SGSN. If the target SGSN can accept all
XID parameters as indicated by the source MME, the target SGSN shall create a NAS container for Handover
indicating 'Reset to the old XID parameters'. Otherwise, if the target SGSN cannot accept all XID parameters
indicated by the source MME or if no XID parameters were indicated by the source MME, the target SGSN shall
create a NAS container for Handover indicating Reset (i.e. reset to default parameters).
The target SGSN shall determine the Maximum APN restriction based on the APN Restriction of each bearer
restriction value.
source MME shall include the Local Home Network ID of the source cell in the PDN Connections
4. The target SGSN determines if the Serving GW is to be relocated, e.g., due to PLMN change. If the Serving GW
is to be relocated, the target SGSN selects the target Serving GW as described under clause 4.3.8.2 on "Serving
GW selection function", and sends a Create Session Request message (IMSI, SGSN Tunnel Endpoint Identifier
for Control Plane, SGSN Address for Control plane, PDN GW address(es) for user plane, PDN GW UL TEID(s)
for user plane, PDN GW address(es) for control plane, and PDN GW TEID(s) for control plane, the Protocol
3GPP
Release 15 272 3GPP TS 23.401 V15.10.0 (2019-12)
Type over S5/S8, Serving Network) per PDN connection to the target Serving GW. The Protocol Type over
S5/S8 is provided to Serving GW which protocol should be used over S5/S8 interface.
4a. The target Serving GW allocates its local resources and returns a Create Session Response (Serving GW
Serving GW TEID for control plane) message to the target SGSN.
5. The target SGSN establishes the EPS Bearer context(s) in the indicated order. The SGSN deactivates, as
provided in step 9 of the execution phase, the EPS Bearer contexts which cannot be established.
The Target SGSN requests the Target BSS to establish the necessary resources (PFCs) by sending the message
PS Handover Request (Local TLLI, IMSI, Cause, Target Cell Identifier, PFCs to be set-up list, Source RNC to
Target BSS Transparent Container and NAS container for handover). The target SGSN shall not request
resources for which the Activity Status Indicator within a EPS Bearer Context indicates that no active bearer
exists on the source side for that PDP context. The Cause indicates the RAN Cause as received from the source
MME. The Source RNC to Target BSS Transparent Container contains the value from the Source to Target
Transparent Container received from the source MME. All EPS Bearer Contexts indicate active status because
E-UTRAN does not support selective RAB handling.
Based upon the ABQP for each PFC the target BSS makes a decision about which PFCs to assign radio
resources. The algorithm by which the BSS decides which PFCs that need resources is implementation specific.
Due to resource limitations not all downloaded PFCs will necessarily receive resource allocation. The target BSS
allocates TBFs for each PFC that it can accommodate.
The target BSS shall prepare the 'Target to Source Transparent Container' which contains a PS Handover
Command including the EPC part (NAS container for Handover) and the RN part (Handover Radio Resources).
5a. The Target BSS allocates the requested resources and returns the applicable parameters to the Target SGSN in
the message PS Handover Request Acknowledge (Local TLLI, List of set-up PFCs, Target BSS to Source RNC
Transparent Container, Cause). Upon sending the PS Handover Request Acknowledge message the target BSS
shall be prepared to receive downlink LLC PDUs from the target SGSN for the accepted PFCs.
Any EPS Bearer contexts for which a PFC was not established are maintained in the target SGSN and the related
SAPIs and PFIs are kept. These EPS Bearer contexts shall be deactivated by the target SGSN via explicit SM
procedures upon the completion of the routing area update (RAU) procedure.
6. If indirect forwarding and relocation of Serving GW applies the target SGSN sends a Create Indirect Data
Forwarding Tunnel Request message (Target SGSN Address(es) and TEID(s) for DL data forwarding) to the
Serving GW used for indirect packet forwarding.
6a. The Serving GW returns a Create Indirect Data Forwarding Tunnel Response (Cause, Serving GW DL
Address(es) and TEID(s) for data forwarding) message to the target SGSN.
7. The Target SGSN sends the message Forward Relocation Response (Cause, SGSN Tunnel Endpoint Identifier
for Control Plane, SGSN Address for Control Plane, Target to Source Transparent Container, RAN Cause, List
of set-up PFIs, Address(es) and TEID(s) for User Traffic Data Forwarding, Serving GW change indication) to
the Source MME. Serving GW change indication indicates a new Serving GW has been selected. RAN Cause
indicates the Cause as received from the target BSS. The Target to Source Transparent Container includes the
value from the Target BSS to Source RNC Transparent Container received from the target BSS.
If 'Indirect Forwarding' and relocation of Serving GW applies, then the IEs 'Address(es) and TEID(s) for User
Traffic Data Forwarding' contain the DL GTP-U tunnel endpoint parameters received in step 6a. Otherwise the
IEs 'Address(es) and TEID(s) for User Traffic Data Forwarding' contains the DL GTP-U tunnel endpoint
parameters to the Target SGSN.
The target SGSN activates the allocated LLC/SNDCP engines as specified in TS 44.064 [23] for an SGSN
originated Reset or 'Reset to the old XID parameters'.
8. If "Indirect Forwarding" applies, the Source MME sends the message Create Indirect Data Forwarding Tunnel
Request (Address(es) and TEID(s) for Data Forwarding (received in step 7)) to the Serving GW used for indirect
packet forwarding.
3GPP
Release 15 273 3GPP TS 23.401 V15.10.0 (2019-12)
Forwarding Tunnel Response (Cause, Serving GW Address(es) and TEID(s) for Data Forwarding). If the
Serving GW doesn't support data forwarding, an appropriate cause value shall be returned and the Serving GW
3GPP
Release 15 274 3GPP TS 23.401 V15.10.0 (2019-12)
Source Source Target PDN

UE eNodeB Target BSS Source MME Target SGSN Serving GW Serving GW GW HSS

1. Handover Command
2. HO from E-UTRAN Command
4. GERAN A/Gb Access Procedures

5. XID Response
Downlink User Plane PDUs
Only if ”Direct Forwarding” applies

Sending of
uplink data Only if ”Indirect Forwarding” applies
possible
6. PS Handover Complete
7. XID Response
12. XID Negotiation for LLC ADM
12a. SABM UA exchange
re-establishment and XID negotiation for LLC ABM)
13. Routeing Area Update procedure

13a. PS Handover Complete Ack
14b. Release Resource (B)
Figure 5.5.2.3.3-1: E-UTRAN to GERAN A/Gb mode Inter RAT HO, execution phase
NOTE 1: For a PMIP-based S5/S8, procedure steps (A) and (B) are defined in TS 23.402 [2]. Step (B) shows PCRF
interaction in the case of PMIP-based S5/S8. Steps 10 and 10a concern GTP based S5/S8
1. The Source MME completes the preparation phase towards Source eNodeB by sending the message Handover
Command (Target to Source Transparent Container (PS Handover Command with RN part and EPC part),
3GPP
Release 15 275 3GPP TS 23.401 V15.10.0 (2019-12)
E-RABs to Release List, Bearers Subject to Data Forwarding List), S1AP Cause. The "Bearers Subject to Data
forwarding list" may be included in the message and it shall be a list of 'Address(es) and TEID(s) for user traffic
data forwarding' received from target side in the preparation phase (Step 7 of the preparation phase for Direct
Forwarding, else parameters received in Step 8a of the preparation phase). S1AP Cause indicates the RAN Cause
as received from the target SGSN.
Source eNodeB initiate data forwarding for the bearers specified in the "Bearers Subject to Data Forwarding
List". The data forwarding may go directly i.e. to target SGSN or alternatively go via the Serving GW if so
decided by source MME and/or target SGSN in the preparation phase.
2. The Source eNodeB will give a command to the UE to handover to the Target Access System via the message
HO from E-UTRAN Command. This message includes a transparent container including radio aspect parameters
that the Target BSS has set-up in the preparation phase (RN part). This message also includes the XID and IOV-
UI parameters received from the Target SGSN (EPC part).
Upon the reception of the HO from E-UTRAN Command message containing the Handover Command message,
the UE shall associate its bearer IDs to the respective PFIs based on the relation with the NSAPI and shall
4. The UE moves to the Target GERAN A/Gb (2G) system and performs executes the handover according to the
parameters provided in the message delivered in step 2. The procedure is the same as in step 6 in clause 5.3.2.2
in TS 43.129 [8] with the additional function of association of the received PFI and existing Bearer Id related to
the particular NSAPI.
5. After accessing the cell using access bursts and receiving timing advance information from the BSS in step 4, the
UE processes the NAS container and then sends one XID response message to the target SGSN via target BSS.
The UE sends this message immediately after receiving the Packet Physical Information message containing the
timing advance or, in the synchronised network case, immediately if the PS Handover Access message is not
required to be sent.
Upon sending the XID Response message, the UE shall resume the user data transfer only for those NSAPIs for
which there are radio resources allocated in the target cell. For NSAPIs using LLC ADM, for which radio
resources were not allocated in the target cell, the UE may request for radio resources using the legacy
procedures.
If the Target SGSN indicated XID Reset (i.e. reset to default XID parameters) in the NAS container included in
the HO from E-UTRAN Command message, and to avoid collision cases the mobile station may avoid triggering
XID negotiation for any LLC SAPI used in LLC ADM, but wait for the SGSN to do so (see step 12). In any case
the mobile station may avoid triggering XID negotiation for any LLC SAPI used in LLC ABM, but wait for the
SGSN to do so (see step 12a).
This step is the same as specified in clause 5.3.2.2 in TS 43.129 [8].
6. Upon reception of the first correct RLC/MAC block (sent in normal burst format) from the UE to the Target
BSS, the Target BSS informs the Target SGSN by sending the message PS Handover Complete (IMSI, and
Local TLLI, Request for Inter RAT Handover Info). The target BSS that supports inter-RAT PS handover to
UTRAN shall, when the INTER RAT HANDOVER INFO was not included in the Source BSS to Target BSS
transparent container received in the PS HANDOVER REQUEST message as specified in TS 48.018 [42],
request the INTER RAT HANDOVER INFO from the target SGSN by setting the 'Request for Inter RAT
Handover Info' to '1'.
7. The Target BSS also relays the message XID Response to the Target SGSN. Note, the message in step 6 and 7
may arrive in any order in the Target SGSN.
8. Then the Target SGSN knows that the UE has arrived to the target side and Target SGSN informs the Source
MME by sending the Forward Relocation Complete Notification (ISR Activated, Serving GW change) message.
If ISR Activated is indicated, the source MME shall maintain the UE's contexts and activate ISR, which is only
possible when the S-GW is not changed. The Source MME will also acknowledge that information. A timer in
3GPP
Release 15 276 3GPP TS 23.401 V15.10.0 (2019-12)
source MME is started to supervise when resources in Source eNodeB and Source Serving GW (for Serving GW
relocation) shall be released.
Upon receipt of the Forward Relocation Complete Acknowledge message the target SGSN starts a timer if the
target SGSN allocated S-GW resources for indirect forwarding.
9. The Target SGSN will now complete the Handover procedure by informing the Serving GW (for Serving GW
relocation this will be the Target Serving GW) that the Target SGSN is now responsible for all the EPS Bearer
Context(s) the UE has established. This is performed in the message Modify Bearer Request (SGSN Tunnel
Endpoint Identifier for Control Plane, NSAPI(s), SGSN Address for Control Plane, SGSN Address(es) and
TEID(s) for User Traffic for the accepted EPS bearers and RAT type, ISR Activated) per PDN connection. As it
is a mobility from E-UTRAN, if the target SGSN supports location information change reporting, the target
SGSN shall include the User Location Information (according to the supported granularity) in the Modify Bearer
by the PDN GW. If the PDN GW requested User CSG information (determined from the UE context), the SGSN
also includes the User CSG Information IE in this message. If the UE Time Zone has changed, the SGSN
includes the UE Time Zone IE in this message. If Serving GW is not relocated but the Serving Network has
changed or if the SGSN has not received any old Serving Network information from the old MME, the SGSN
includes the new Serving Network IE in this message. In network sharing scenarios Serving Network denotes the
serving core network. If indicated, ISR Activated indicates that ISR is activated, which is only possible when the
S-GW was not changed. When the Modify Bearer Request does not indicate ISR Activated and S-GW is not
changed, the S-GW deletes any ISR resources by sending a Delete Bearer Request to the other CN node that has
bearer resources on the S-GW reserved.
The SGSN releases the non-accepted EPS Bearer contexts by triggering the EPS Bearer context deactivation
procedure. If the Serving GW receives a DL packet for a non-accepted bearer, the Serving GW drops the DL
packet and does not send a Downlink Data Notification to the SGSN.
10. The Serving GW (for Serving GW relocation this will be the Target Serving GW) may inform the PDN GW the
change of, for example, for Serving GW relocation or the RAT type, that e.g. can be used for charging, by
the Serving GW allocates DL TEIDs on S5/S8 even for non-accepted bearers and may include the PDN
Charging Pause Supported Indication. The PDN GW must acknowledge the request with the message Modify
Bearer Response. In the case of Serving GW relocation, the PDN GW updates its context field and returns a
Modify Bearer Response (Charging Id, MSISDN, PDN Charging Pause Enabled Indication (if PDN GW has
chosen to enable the function), etc.) message to the Serving GW. The MSISDN is included if the PDN GW has it
stored in its UE context. If location information change reporting is required and supported in the target SGSN,
the PDN GW shall provide MS Info Change Reporting Action in the Modify Bearer Response.
immediately after switching the path. The source Serving GW shall forward the "end marker" packets to the
source eNodeB.
switch to the Target SGSN via the message Modify Bearer Response (Cause, Serving GW Tunnel Endpoint
Change Reporting Action). At this stage the user plane path is established for all EPS Bearer contexts between
the UE, Target BSS, Target SGSN, Serving GW (for Serving GW relocation this will be the Target Serving GW)
and PDN GW.
path immediately after switching the path.
12. If the Target SGSN indicated XID Reset (i.e. reset to default XID parameters) in the NAS container included in
the HO from E-UTRAN Command message, then on receipt of the PS Handover Complete the Target SGSN
initiates an LLC/SNDCP XID negotiation for each LLC SAPI used in LLC ADM. In this case if the Target
SGSN wants to use the default XID parameters, it shall send an empty XID Command. If the Target SGSN
3GPP
Release 15 277 3GPP TS 23.401 V15.10.0 (2019-12)
indicated 'Reset to the old XID parameters' in the NAS container, no further XID negotiation is required for LLC
SAPIs used in LLC ADM only.
12a. The Target SGSN (re-)establishes LLC ABM for the EPS Bearer contexts which use acknowledged
information transfer. During the exchange of SABM and UA the SGSN shall perform LLC/SNDCP XID
negotiation.
These steps (12 and 12a) are the same as specified in clause 5.3.2.2 in TS 43.129 [8].
13. After the UE has finished the reconfiguration procedure the UE shall initiate the Routing Area Update procedure.
NOTE 2: The RAU procedure is performed regardless if the UE has this routing area registered or not, as specified
by TS 43.129 [8]. This is needed e.g. to update the START-PS value stored in the 2G-SGSN. The
START_PS is delivered to SGSN in INTER RAT HANDOVER INFO parameter of RAU Complete
message when requested by SGSN in RAU Accepted.
The target SGSN knows that an IRAT Handover has been performed for this UE as it received the bearer
context(s) by handover messages and therefore the target SGSN performs only a subset of the RAU procedure,
specifically it excludes the context transfer procedures between source MME and target SGSN.
For a UE supporting CIoT EPS Optimisations, the UE uses the bearer status information in the RAU Accept to
identify any non-transferred bearers that it shall locally release.
13a. Upon reception of the PS Handover Complete message with the 'Request for Inter RAT Handover Info' set to
'1', the SGSN should send then PS Handover Complete Acknowledge (TLLI, INTER RAT HANDOVER INFO)
to the target BSS.
NOTE 3: An SGSN that does not recognize the "Request for Inter RAT Handover Info" in the PS Handover
Complete message will not send the PS Handover Complete Acknowledge message back to the BSS.
The target BSS receiving the PS Handover Complete Acknowledge message shall set the 'Reliable INTER RAT
HANDOVER' to '1' in the PS Handover Required message in any subsequent PS handover to GERAN A/Gb
mode. The target BSS failing to receive the PS Handover Complete Acknowledge message shall set the 'Reliable
INTER RAT HANDOVER' to '0' in the PS Handover Required message in any subsequent PS handover to
GERAN A/Gb mode. The Target BSS shall, upon receipt of the INTER RAT HANDOVER INFO in the PS
Handover Complete Acknowledge message, overwrite its current INTER RAT HANDOVER INFO with this
new one.
14. When the timer started at step 8 expires, the source MME sends a Release Resources message to the source
When the timer started in step 8 expires and if the source MME received the Serving GW change indication in
Request (Cause, Operation Indication, Secondary RAT usage data) messages to the Source Serving GW. The
operation Indication flag is not set, that indicates to the Source Serving GW that the Serving GW changes and
the Source Serving GW shall not initiate a delete procedure towards the PDN GW. Secondary RAT usage data is
included if it was received in step 3. The Source Serving GW acknowledges with Delete Session Response
(Cause) messages. If ISR has been activated before this procedure, the cause indicates to the Source S-GW that
the Source S-GW shall delete the bearer resources on the other old CN node by sending Delete Bearer Request
16. If indirect forwarding was used and the Serving GW is relocated, then the expiry of the timer at target SGSN
started at step 8 triggers the target SGSN to send a Delete Indirect Data Forwarding Tunnel Request message to
5.5.2.3.4 E-UTRAN to GERAN A/Gb mode Inter RAT handover reject

The Target BSS may reject the use of the Handover procedure if none of the requested PFCs in the PS Handover
Request message could be established. In this case no UE context is established in the target SGSN/BSS and no
resources are allocated. The UE remains in the Source eNodeB/MME.
3GPP
Release 15 278 3GPP TS 23.401 V15.10.0 (2019-12)

UE eNodeB Target BSS Source MME Target SGSN Serving GW Serving GW PDN GW HSS

6. PS Handover Request Nack


Figure 5.5.2.3.4-1: E-UTRAN to GERAN A/Gb Inter RAT HO reject
6. If the Target BSS fails to allocate any resources for any of the requested PFCs it sends a PS Handover Request
Nack (Cause) message to the Target SGSN. When the Target SGSN receives the PS Handover Request Nack
message from Target BSS the Target SGSN clears any reserved resources for this UE.
7. This step is only performed for Serving GW relocation, i.e. if Steps 4/4a have been performed. The Target SGSN
8. The Target SGSN sends the Forward Relocation Response (Cause) message to the Source MME.
9. When the Source MME receives the Forward Relocation Response message it send a Handover Preparation
5.5.2.4 GERAN A/Gb mode to E-UTRAN Inter RAT handover
5.5.2.4.1 General
The procedure is based on Packet-switched handover for GERAN A/Gb mode, defined in TS 43.129 [8].
Pre-conditions:
- The UE is in READY state (GERAN A/Gb mode);
- The UE has at least one PDP/EPS Bearer Context established;
- The BSS must support PFM, Packet Flow Management, procedures.
3GPP
Release 15 279 3GPP TS 23.401 V15.10.0 (2019-12)

UE Source
BSS eNodeB
SGSN
Target MME Serving GW Serving GW PDN GW HSS
2. PS Handover Required
5. Handover Request
5a. handover Request Acknowledge

Figure 5.5.2.4.2-1: GERAN A/Gb mode to E-UTRAN inter RAT HO, preparation phase
1. The source access system, Source BSS, decides to initiate an Inter-RAT Handover to the E-UTRAN. At this
point both uplink and downlink user data is transmitted via the following: Bearers between UE and Source BSS,
BSSGP PFC tunnel(s) between source BSS and source SGSN, GTP tunnel(s) between Source SGSN, Serving
GW and PDN GW.
2. The source BSS sends the message PS handover Required (TLLI, Cause, Source Cell Identifier, Target eNodeB
Identifier, Source eNodeB to Target eNodeB Transparent Container and active PFCs list) to Source SGSN to
request the CN to establish resources in the Target eNodeB, Target MME and the Serving GW.
NOTE 2: In contrast to most inter-RAT handover preparation phases, this Source to Target Transparent Container
does not contain the UE's target RAT radio capabilities.
3. The Source SGSN determines from the 'Target eNodeB Identifier' IE that the type of handover is IRAT PS
Handover to E-UTRAN. The Source SGSN selects the Target MME as described in clause 4.3.8.3 on "MME
Selection Function". The Source SGSN initiates the Handover resource allocation procedure by sending message
Forward Relocation Request (IMSI, Target Identification, MM Context, PDN Connections, SGSN Tunnel
Endpoint Identifier for Control Plane, SGSN Address for Control plane, Source to Target Transparent Container,
RAN Cause, Packet Flow ID, SNDCP XID parameters, LLC XID parameters, MS Info Change Reporting
Action (if available), CSG Information Reporting Action (if available), UE Time Zone, ISR Supported, Serving
Network) to the target MME. When ISR is activated the message should be sent to the MME that maintains ISR
for the UE when this MME is serving the target identified by the Target Identification. If indicated, the
information ISR Supported indicates that the source SGSN and associated Serving GW are capable to activate
ISR for the UE. This message includes all PDN Connections active in the source system and for each PDN
Connection includes the associated APN, the address and the uplink tunnel endpoint parameters of the Serving
GW for control plane, and a list of EPS Bearer Contexts established in the source system. The EPS Bearer
Contexts indicate the PFIs and the XID parameters related to those EPS Bearer Contexts, and the uplink Tunnel
endpoint parameters of the Serving GW. The old Serving Network is sent to target MME to support the target
MME to resolve if Serving Network is changed. In network sharing scenarios Serving Network denotes the
serving core network.
3GPP
Release 15 280 3GPP TS 23.401 V15.10.0 (2019-12)
The RAN Cause includes the value from the Cause IE received from the source BSS. Source to Target
Transparent Container includes the value from the Source eNodeB to Target eNodeB Transparent Container
received from the source BSS.
supported by the selected target MME, the source SGSN rejects the handover attempt by sending a PS Handover
Required Negative Acknowledge (Cause) message to the Source BSS.
NOTE 3: If the handover is successful, the source SGSN will signal to the SGW and/or SCEF to release any non-
released by the UE following the Bearer Context Status synchronisation that occurs during the Tracking
Prioritization of EPS Bearer Contexts is performed by the target core network node.
The MME establishes the EPS bearer(s) in the prioritized order. The MME deactivates, as provided in step 8 of
the execution phase, the EPS bearers which cannot be established.
For the EPS Bearer Context with traffic class equals 'Background', the source SGSN shall indicate via the
Activity Status Indicator IE that radio bearers shall be established on the target side.
restriction value.
4. The target MME determines if the Serving GW is to be relocated, e.g. due to PLMN change. If the Serving GW
is to be relocated, the target MME selects the target Serving GW as described under clause 4.3.8.2 on "Serving
GW selection function". The target MME sends a Create Session Request message (IMSI, MME Tunnel
Endpoint Identifier for Control Plane, MME Address for Control plane, PDN GW address(es) for user plane,
PDN GW UL TEID(s) for user plane, PDN GW address for control plane, and PDN GW TEID(s) for control
plane, the Protocol Type over S5/S8, Serving Network) per PDN connection to the target Serving GW. The
Protocol Type over S5/S8 is provided to Serving GW which protocol should be used over S5/S8 interface.
4a. The target Serving GW allocates its local resources and returns them in a Create Session Response (Serving GW
5. The Target MME will request the Target eNodeB to establish the Bearer(s) by sending the message Handover
Request (UE Identifier, S1AP Cause, Integrity protection information (i.e. IK and allowed Integrity Protection
algorithms), Encryption information (i.e. CK and allowed Ciphering algorithms), EPS Bearers to be setup list,
Source to Target Transparent Container, Handover Restriction List). The Target MME ignores any Activity
Status Indicator within an EPS Bearer Context and requests the eNodeB to allocate resources for all EPS Bearer
Contexts received from the source side. The S1AP Cause includes the value from the RAN Cause IE received
from the source SGSN. The target eNodeB shall ignore it if the number of radio bearers in the Source to Target
Transparent container does not comply with the number of bearers requested by the MME and allocate bearers as
requested by the MME. Handover Restriction List is sent if it is available in the Target MME; it is described in
clause 4.3.5.7.
For each EPS bearer requested to be established, 'EPS Bearers To Be Setup' IE shall contain information such as
ID, bearer parameters, Transport Layer Address, "Data forwarding not possible" indication, and S1 Transport
Association. The Transport Layer Address is the Serving GW Address for user data, and the S1 Transport
Association corresponds to the uplink Tunnel Endpoint Identifier Data. "Data forwarding not possible"
indication shall be included if the target MME decides the corresponding bearer will not be subject to data
forwarding.
The ciphering and integrity protection keys will be sent transparently from the target eNodeB to the UE in the
Target to Source Transparent Container, and in the message PS Handover Command from source BSS to the UE.
This will then allow data transfer to continue in the new RAT/mode target cell without requiring a new AKA
(Authentication and Key Agreement) procedure. More details are described in TS 33.401 [41].
3GPP
Release 15 281 3GPP TS 23.401 V15.10.0 (2019-12)
5a. The Target eNodeB allocates the request resources and returns the applicable parameters to the Target MME in
the message Handover Request Acknowledge (Target to Source Transparent Container, S1AP Cause, EPS
Bearers setup list, EPS Bearers failed to setup list). Upon sending the Handover Request Acknowledge message
the target eNodeB shall be prepared to receive downlink GTP PDUs from the Serving GW for the accepted EPS
bearers.
6. If 'Indirect Forwarding' and relocation of Serving GW apply, the target MME sends a Create Indirect Data
Forwarding Tunnel Request message (Target eNodeB Address(es) and TEID(s) for DL data forwarding) to the
Serving GW.
and DL TEID(s) for data forwarding) message to the target MME.
7. The Target MME sends the message Forward Relocation Response (Cause, List of Set Up PFCs, MME Tunnel
Endpoint Identifier for Control Plane, RAN Cause, MME Address for control plane, Target to Source
Transparent Container, Address(es) and TEID(s) for Data Forwarding, Serving GW change indication) to the
Source SGSN. Serving GW change indication indicates whether a new Serving GW has been selected. The RAN
Cause includes the value from the S1AP Cause IE received from the target eNodeB. The Target to Source
Transparent Container includes the value from the Target to Source Transparent Container received from the
target eNodeB.
If 'Direct Forwarding' applies or if 'Indirect Forwarding' but no relocation of Serving GW applies, then the IEs
'Address(es) and TEID(s) for Data Forwarding' contain the DL GTP-U tunnel endpoint parameters to the
eNodeB received in step 5a. If 'Indirect Forwarding' and relocation of Serving GW apply the IEs 'Address(es)
and TEID(s) for Data Forwarding' contain the DL GTP-U tunnel endpoint parameters to the Serving GW
received in step 6a.
8. If 'Indirect Forwarding' applies, the source SGSN shall send the message Create Indirect Data Forwarding
Tunnel Request (Address(es) and TEID(s) for Data Forwarding (received in step 7)) to the Serving GW used for
indirect packet forwarding.
Forwarding Tunnel Response (Cause, Serving GW Address(es) and TEID(s) for Data Forwarding). If the
Serving GW doesn't support data forwarding, an appropriate cause value shall be returned and the Serving GW
3GPP
Release 15 282 3GPP TS 23.401 V15.10.0 (2019-12)
Source Target Target PDN

UE Source SGSN Target MME Source HSS
BSS eNodeB Serving GW Serving GW GW
Only if 'Direct Forwarding' applies
Only if 'Indirect Forwarding' applies
1. PS HO Required Acknowledge
2. PS Handover Command
6. Handover Notify
Sending of
uplink data
possible 7. Forward Relocation Complete Notification

For Serving GW relocation Steps 8, 9 and 10, and (A)
the following User Plane path, will be handled by 9a. Modify Bearer Response
Target Serving GW
11. BSS Packet Flow Delete Procedure

Figure 5.5.2.4.3-1: GERAN A/Gb mode to E-UTRAN Inter RAT HO, execution phase
NOTE: For a PMIP-based S5/S8, procedure steps (A) are defined in TS 23.402 [2]. Steps 9 and 9a concern GTP
based S5/S8.
The source SGSN continues to receive downlink and uplink user plane PDUs.
When source SGSN receives the Forward Relocation Response message it may start downlink N-PDU relay and
duplication to the target eNodeB (for Direct Forwarding) or via the Serving GW (for Indirect Forwarding), and the
target eNodeB may start blind transmission of downlink user data towards the UE over the allocated radio channels.
1. The Source SGSN completes the preparation phase towards Source BSS by sending the message PS HO
Required Acknowledge (TLLI, List of Set Up PFCs, Target RNC to Source BSS Transparent Container, Cause).
This message includes all PFIs that could be established on the Target side. The Cause includes the value from
3GPP
Release 15 283 3GPP TS 23.401 V15.10.0 (2019-12)
the RAN Cause IE received from the target MME. The Target RNC to Source BSS Transparent Container
includes the value from the Target to Source Transparent Container received from the target MME.
Before sending the PS Handover Required Acknowledge message, the source SGSN may suspend downlink data
transfer for any EPS Bearer contexts.
Before sending the PS Handover Command message to the UE the source BSS, may try to empty the downlink
BSS buffer for any BSS PFCs.
2. The Source BSS will command the UE to handover to the target eNodeB via the message PS Handover
Command. The access system specific message to UE includes a transparent container including radio aspect
parameters that the Target eNodeB has set-up in the preparation phase.
3. Void.
4. The UE moves to the E-UTRAN and performs access procedures toward Target eNodeB.
5. When the UE has got access to Target eNodeB it sends the message HO to E-UTRAN Complete.
The UE shall implicitly derive the EPS bearers for which an E-RAB was not established from the PS Handover
Command and deactivate them locally without an explicit NAS message at this step.
6. When the UE has successfully accessed the Target eNodeB, the Target eNodeB informs the Target MME by
sending the message Handover Notify (TAI+ECGI). As a separate activity the Target eNodeB retrieves the UE
E-UTRA capability information using the procedure for UE Radio Capability Handling (see clause 5.11.2).
If Dual Connectivity is activated for the UE, the PSCell ID shall be included in the Handover Notify message.
7. Then the Target MME knows that the UE has arrived to the target side and Target MME informs the Source
SGSN by sending the Forward Relocation Complete Notification (ISR Activated, Serving GW change) message.
If indicated, ISR Activated indicates to the source SGSN that it shall maintain the UE's contexts and activate
ISR, which is only possible when the S-GW is not changed. The Source SGSN shall also acknowledge that
information. When the Forward Relocation Complete Notification message has been received and there is no
longer any need for the SGSN to forward data, the SGSN stops data forwarding. A timer in source SGSN is
started to supervise when resources in the Source Serving GW (for Serving GW relocation) shall be released.
target MME applies indirect forwarding.
8. The Target MME will now complete the Handover procedure by informing the Serving GW (for Serving GW
relocation this will be the Target Serving GW) that the Target MME is now responsible for all the EPS bearers
the UE have established. This is performed in the message Modify Bearer Request (Cause, MME Tunnel
Endpoint Identifier for Control Plane, EPS Bearer ID(s), MME Address for Control Plane, eNodeB Address(es)
and TEID(s) for User Traffic for the accepted EPS bearers and RAT type, ISR Activated) per PDN connection.
As it is a mobility from GERAN, if the target MME supports location information change reporting, the target
MME shall include the User Location Information (according to the supported granularity) in the Modify Bearer
by the PDN GW. If the PDN GW requested User CSG information (determined from the UE context), the MME
also includes the User CSG Information IE in this message. If the UE Time Zone has changed, the MME
includes the UE Time Zone IE in this message. If the Serving GW is not relocated but the Serving Network has
changed or if the MME has not received any old Serving Network information from the old SGSN, the MME
includes the new Serving Network IE in this message. If indicated, ISR Activated indicates that ISR is activated,
which is only possible when the S-GW was not changed. When the Modify Bearer Request does not indicate ISR
Activated and S-GW is not changed, the S-GW deletes any ISR resources by sending a Delete Bearer Request to
the other CN node that has bearer resources on the S-GW reserved.
3GPP
Release 15 284 3GPP TS 23.401 V15.10.0 (2019-12)
9. The Serving GW (for Serving GW relocation this will be the Target Serving GW) informs the PDN GW(s) the
the Serving GW allocates DL TEIDs on S5/S8 even for non-accepted bearers and PDN Charging Pause Support
Indication shall be included. The PDN GW must acknowledge the request with the message Modify Bearer
Response (Charging Id, MSISDN, PDN Charging Pause Enabled Indication (if PDN GW has chosen to enable
the function), etc.) to the Serving GW. If location information change reporting is required and supported in the
target MME, the PDN GW shall provide MS Info Change Reporting Action in the Modify Bearer Response.
Serving GW shall forward the "end marker" packets to the source SGSN.
switch to the Target MME via the message Modify Bearer Response (Cause, Serving GW Tunnel Endpoint
Identifier for Control Plane, Serving GW (for Serving GW relocation this will be the Target Serving GW)
Address for Control Plane, Protocol Configuration Options, MS Info Change Reporting Action). At this stage the
user plane path is established for all bearers between the UE, Target eNodeB, Serving GW (for Serving GW
relocation this will be the Target Serving GW) and PDN GW.
path immediately after switching the path in order to assist the reordering function in the target eNodeB.
11. When the timer at the source SGSN started in step 7 expires the Source SGSN will clean-up all its resources
towards Source BSS by performing the BSS Packet Flow Delete procedure.
If the Subscription Data received from the HSS (during the TAU in step 12) contains information that is
necessary for the E-UTRAN to be aware of (e.g. a restriction in the UE's permission to use NR as a secondary
RAT, Unlicensed Spectrum or a combination of them), or an existing UE context in the MME indicates that the
UE is not permitted to use NR as a secondary RAT, Unlicensed Spectrum or a combination of them and the
MME has not provided this information to the target eNodeB during step 5 of the handover preparation phase,
then the MME sends an updated Handover Restriction List in the Downlink NAS Transport message that it sends
to E-UTRAN. If the UE is not allowed to use NR as Secondary RAT, the MME indicates that to the UE in TAU
Accept message.
13. When the timer at the source SGSN started in step 7 expires and if the source SGSN received the Serving GW
change indication in the Forward Relocation Response message, it deletes the EPS bearer resources by sending
Delete Session Request (Cause, Operation Indication) messages to the Source Serving GW. The operation
Indication flag is not set, that indicates to the Source Serving GW that the Source Serving GW shall not initiate a
delete procedure towards the PDN GW. The Source Serving GW acknowledges with Delete Session Response
(Cause) messages. If ISR has been activated before this procedure, the cause indicates to the Source S-GW that
the Source S-GW shall delete the bearer resources on the other old CN node by sending Delete Bearer Request
14. If indirect forwarding was used then the expiry of the timer at source SGSN started at step 7 triggers the source
SGSN to send a Delete Indirect Data Forwarding Tunnel Request message to the S-GW to release the temporary
3GPP
Release 15 285 3GPP TS 23.401 V15.10.0 (2019-12)
5.5.2.4.4 GERAN A/Gb mode to E-UTRAN Inter RAT handover reject

The Target eNodeB may reject the use of the Handover procedure if none of the requested EPS bearers in the Handover
Request message could be established. In this case no UE context is established in the target MME/eNodeB and no
resources are allocated. The UE remains in the Source BSS/SGSN.

UE Source
BSS eNodeB
SGSN
Target MME Serving GW Serving GW PDN GW HSS
5. Handover Request
6. Handover Failure
9. PS Handover Required Negative Acknowledge
Figure 5.5.2.4.4-1: GERAN A/Gb mode to E-UTRAN inter RAT HO reject
6. If the Target eNodeB fails to allocate any resources for any of the requested EPS Bearers it sends a Handover
Failure (Cause) message to the Target MME. When the Target MME receives the Handover Failure message
from Target eNodeB the Target MME clears any reserved resources for this UE.
7. This step is only performed for Serving GW relocation, i.e. if Steps 4/4a have been performed. The Target MME
8. The Target MME sends the Forward Relocation Response (Cause) message to the Source SGSN.
9. When the Source SGSN receives the Forward Relocation Response message it send a PS Handover Required
Negative Acknowledge (Cause) message to the Source BSS.
5.5.2.5 Inter RAT handover Cancel
5.5.2.5.1 General
Instead of completing the handover procedure, the source RAN node (eNodeB, RNC or BSS) may at any time during
the handover procedure, up to the time when a handover command message is sent to the UE cancel the handover. The
reason for cancelling may be e.g. due to a timer expiration or due to other events within the source RAN node and is
initiated by sending a handover cancel PDU to the source EPC node (MME or SGSN).
A handover cancel PDU shall also be sent by the source RAN node after a handover command message is sent to the
UE for the case where the handover fails and the UE returns to the old cell or radio contact with the UE is lost. This is
done in order to release the resources reserved for the Handover in the target system.
3GPP
Release 15 286 3GPP TS 23.401 V15.10.0 (2019-12)
5.5.2.5.2 Source RAN to Target RAN Inter RAT handover Cancel
Source Target Source Target Source Target

UE RAN RAN MME/SGSN SGSN/MME Serving GW Serving GW PDN GW HSS
1. Source RAN (BSS, RNC or eNodeB)

decides to cancel the handover procedure
2. PS Handover Cancel Only if Source RAN is BSS

2. Relocation Cancel Only if Source RAN is RNC
2. Handover Cancel Only if Source RAN is eNodeB
3. Relocation Cancel Request
4. Delete BSS PFC Procedure

Only if Target RAN is BSS
4. Iu Release Procedure
Only if Target RAN is RNC
4. Release Resources
Only if Target RAN is eNodeB
6. Relocation Cancel Response
7. Relocation Cancel Acknowledge Only if Source RAN is RNC

7. Handover Cancel Acknowledge Only if Source RAN is eNodeB
Figure 5.5.2.5.2-1: Inter RAT handover Cancel
1. The source RAN decides to cancel the previously requested relocation of Handover resources. This may be due
to not enough accepted bearers, UE returned to source cell or any other reason.
2. The source RAN sends a Cancel message with a Cause to the source EPC node (SGSN or MME). If the source
RAN is:
a) BSS the message sent is PS Handover Cancel (Cause),
b) RNC the message sent is Relocation Cancel (Cause), or
c) eNodeB the message sent is Handover Cancel (Cause).
3. The source EPC node terminates the relocation towards the target side by sending a Relocation Cancel Request
(IMSI) message to the target EPC node. The Source EPC node also resumes operation on the resources in the
source side.
4. The target EPC node triggers the release of resources in the target RAN and also releases its own resources
allocated for this handover.
5. This step is only performed for Serving GW relocation. The Target EPC node deletes the EPS bearer resources
by sending Delete Session Request (Cause) messages to the Target Serving GW. The Target Serving GW
acknowledges with Delete Session Response (Cause) messages.
3GPP
Release 15 287 3GPP TS 23.401 V15.10.0 (2019-12)
6. The target EPC node acknowledge the release of all resources on the target side by returning a Relocation Cancel
Response (Cause) message to the source EPC node.
7. The source EPC node returns a Cancel acknowledge message to the source RAN. If the source RAN is:
a) BSS there will be no acknowledge message sent to the source BSS,
b) RNC the message sent is Relocation Cancel Acknowledge (Cause), or
c) eNodeB the message sent is Handover Cancel Acknowledge (Cause).
8. If indirect forwarding tunnel is setup during handover preparation then cancellation of handover triggers the
source MME/SGSN to send a Delete Indirect Data Forwarding Tunnel Request message to the S-GW to release
the temporary resources used for indirect forwarding.
9. If indirect forwarding tunnel is setup during handover preparation and serving GW is relocated then cancellation
of handover triggers the target MME/SGSN to send a Delete Indirect Data Forwarding Tunnel Request message
to the S-GW to release the temporary resources used for indirect forwarding.
5.6 Network Assisted Cell Change

Network Assisted Cell Change (NACC) is a means that enables better performance for packet data services upon inter-
cell change for those networks that do not support PS Handover. It reduces the service interruption time for UEs in
active mode upon cell change by providing in the source cell, prior to the cell change, system information of a target
cell allowing packet access.
Within the scope of this specification, NACC is applicable for inter-RAT cell changes from a source E-UTRAN cell
towards a target GERAN cell.
When the UE changes from a source E-UTRAN cell towards a target GERAN cell, the UE locally deactivates ISR by
setting its TIN from "RAT-related TMSI" to "GUTI", if any EPS bearer context activated after the ISR was activated in
the UE exists.
When the UE changes from a source E-UTRAN cell in connected mode towards a target GERAN cell from the same
RA via Cell Change Order that is not for CS fallback and the ISR is active, the UE locally deactivates ISR by setting its
TIN from "RAT-related TMSI" to "GUTI".
5.6.1 Architecture Principles for E-UTRAN to GERAN NACC

Introducing NACC from E-UTRAN to GERAN follows the principles of the Network Assisted Cell Change between
UTRAN and GERAN as described in TS 25.413 [22] and TS 23.060 [7]. It specifies the RAN Information Management
(RIM) procedures as specified in clause 5.15 and depicted in figure 5.6-1.
3GPP
Release 15 288 3GPP TS 23.401 V15.10.0 (2019-12)
RIM Signaling
eNodeB S1 MME
E-UTRAN Relaying RIM

Signaling S3/Gn
GERAN
Gb/Iu
BSS SGSN
RIM Signaling
Figure 5.6-1: E-UTRAN to GERAN NACC basic network architecture
The support for the NACC from E-UTRAN to GERAN has the following impacts on E-UTRAN / GERAN architecture:
- Affected nodes: BSC, eNodeB, MME, SGSN;
- Affected network interfaces: Gb, Iu, S3, Gn, S1;
- Affected radio interfaces: Um and Uu.
5.6.2 Void
5.7 Information storage

This clause describes information storage structures required for the EPS when 3GPP access only is deployed.
Information storage for the case where non 3GPP accesses are deployed is in TS 23.402 [2].
3GPP
Release 15 289 3GPP TS 23.401 V15.10.0 (2019-12)
5.7.1 HSS
IMSI is the prime key to the data stored in the HSS. The data held in the HSS is defined in Table 5.7.1-1 here below.
The table below is applicable to E-UTRAN in stand-alone operation only.
Table 5.7.1-1: HSS data
Field Description
IMSI IMSI is the main reference key.
MSISDN The basic MSISDN of the UE (Presence of MSISDN is optional).
IMEI / IMEISV International Mobile Equipment Identity - Software Version Number
External Identifier List External Identifier(s) used in the external network(s) to refer to the subscription.
See TS 23.682 [74] for more information.
MME Identity The Identity of the MME currently serving this UE.
MME Capabilities Indicates the capabilities of the MME with respect to core functionality e.g.
regional access restrictions.
MS PS Purged from EPS Indicates that the EMM and ESM contexts of the UE are deleted from the MME.
ODB parameters Indicates that the status of the operator determined barring
Access Restriction Indicates the access restriction subscription information. It may include different
values for HPLMN and roaming case. It includes separate settings for WB-E-
UTRAN and NB-IoT. It includes restriction information on the use of NR as a
secondary RAT for user plane connectivity and use of Unlicensed Spectrum (in
the form of LAA, or LWA/LWIP).
EPS Subscribed Charging The charging characteristics for the UE, e.g. normal, prepaid, flat-rate, and/or
Characteristics hot billing subscription.
Trace Reference Identifies a record or a collection of records for a particular trace.
Trace Type Indicates the type of trace, e.g. HSS trace, and/or MME/ Serving GW / PDN
GW trace.
OMC Identity Identifies the OMC that shall receive the trace record(s).
Subscribed-UE-AMBR The Maximum Aggregated uplink and downlink MBRs to be shared across all
Non-GBR bearers according to the subscription of the user.
APN-OI Replacement Indicates the domain name to replace the APN OI when constructing the PDN
GW FQDN upon which to perform a DNS resolution. This replacement applies
for all the APNs in the subscriber's profile. See TS 23.003 [9] clause 9.1.2 for
more information on the format of domain names that are allowed in this field.
RFSP Index An index to specific RRM configuration in the E-UTRAN
URRP-MME UE Reachability Request Parameter indicating that UE activity notification from
MME has been requested by the HSS.
CSG Subscription Data The CSG Subscription Data is a list of CSG IDs per PLMN and for each CSG
ID optionally an associated expiration date which indicates the point in time
when the subscription to the CSG ID expires; an absent expiration date
indicates unlimited subscription.
For a CSG ID that can be used to access specific PDNs via Local IP Access,
the CSG ID entry includes the corresponding APN(s).
VPLMN LIPA Allowed Specifies per PLMN whether the UE is allowed to use LIPA.
EPLMN list Indicates the Equivalent PLMN list for the UE's registered PLMN.
Subscribed Periodic RAU/TAU Indicates a subscribed Periodic RAU/TAU Timer value
Timer
Extended idle mode DRX cycle Indicates a subscribed extended idle mode DRX cycle length value.
length
RAT specific Subscribed Paging Indicates a Subscribed Paging Time Window value for the associated RAT, NB-
Time Window IoT, WB-E-UTRAN or both.
MPS CS priority Indicates that the UE is subscribed to the eMLPP or 1x RTT priority service in
the CS domain.
UE-SRVCC- Capability Indicates whether the UE is UTRAN/GERAN SRVCC capable or not.
MPS EPS priority Indicates that the UE is subscribed to MPS in the EPS domain.
UE Usage Type Indicates the usage characteristics of the UE for use with Dedicated Core
Networks (see clause 4.3.25).
Group ID-list List of the subscribed group(s) that the UE belongs to
Communication Patterns Indicates per UE the Communication Patterns and their corresponding validity
times as specified in TS 23.682 [74].The Communication Patterns are not
provided to the SGSN.
Monitoring Event Information Data Describes the monitoring event configuration information. See TS 23.682 [74]
for more information.
3GPP
Release 15 290 3GPP TS 23.401 V15.10.0 (2019-12)
Field Description
PDN Connection Restriction Indicates whether the establishment of the PDN connection is restricted for the
UE.
Enhanced Coverage Restricted Specify PLMN(s) with Enhanced Coverage restrictions.
Acknowledgements of downlink Indicates whether acknowledgement of downlink NAS data PDUs for Control
NAS data PDUs Plane CIoT EPS Optimisation is disabled for this UE (enabled by default).
Service Gap Time Used to set the Service Gap timer for Service Gap Control (see
clause 4.3.17.9).
Each subscription profile contains one or more PDN subscription contexts:
Context Identifier Index of the PDN subscription context (Note 8).
PDN Address Indicates subscribed IP address(es).
PDN Type Indicates the subscribed PDN Type (IPv4, IPv6, IPv4v6, Non-IP)
APN-OI Replacement APN level APN-OI Replacement which has same role as UE level APN-OI
Replacement but with higher priority than UE level APN-OI Replacement. This
is an optional parameter. When available, it shall be used to construct the
PDN GW FQDN instead of UE level APN-OI Replacement.
Access Point Name (APN) A label according to DNS naming conventions describing the access point to
the packet data network (or a wildcard) (NOTE 6).
Invoke SCEF Selection Indicates whether this APN is used for establishing PDN connection to the
SCEF
SCEF ID Indicates the FQDN or IP address of the SCEF which is to be selected for this
APN. It is required if "Invoke SCEF Seletion" indicator is set.
SIPTO permissions Indicates whether the traffic associated with this APN is prohibited for SIPTO,
allowed for SIPTO excluding SIPTO at the local network, allowed for SIPTO
including SIPTO at the local network or allowed for SIPTO at the local network
only (NOTE 7).
LIPA permissions Indicates whether the PDN can be accessed via Local IP Access. Possible
values are: LIPA-prohibited, LIPA-only and LIPA-conditional.
WLAN offloadability Indicates whether the traffic associated with this APN is allowed to be offloaded
to WLAN using the WLAN/3GPP Radio Interworking feature or if it shall be kept
on 3GPP access (see clause 4.3.23). The indication may contain separate
values per RAT (E-UTRA and UTRA).
EPS subscribed QoS profile The bearer level QoS parameter values for that APN's default bearer (QCI and
ARP) (see clause 4.7.3).
Subscribed-APN-AMBR The maximum aggregated uplink and downlink MBRs to be shared across all
Non-GBR bearers, which are established for this APN.
EPS PDN Subscribed Charging The charging characteristics of this PDN Subscribed context for the UE, e.g.
Characteristics normal, prepaid, flat-rate, and/or hot billing subscription. The charging
characteristics is associated with this APN.
VPLMN Address Allowed Specifies per VPLMN whether for this APN the UE is allowed to use the PDN
GW in the domain of the HPLMN only, or additionally the PDN GW in the
domain of the VPLMN.
PDN GW identity The identity of the PDN GW used for this APN. The PDN GW identity may be
either an FQDN or an IP address. The PDN GW identity refers to a specific
PDN GW.
PDN GW Allocation Type Indicates whether the PDN GW is statically allocated or dynamically selected by
other nodes. A statically allocated PDN GW is not changed during PDN GW
selection.
PDN continuity at inter RAT Provides for this APN how to handle a PDN connection when UE the moves
mobility between "broadband" (WB-E-UTRAN and UTRAN) and "narrowband" (NB-IoT,
GPRS, EC-GSM-IoT). Possible values are: maintain the PDN connection;
disconnect the PDN connection with a reactivation request; disconnect PDN
connection without reactivation request; or to leave it to local VPLMN policy.
PLMN of PDN GW Identifies the PLMN in which the dynamically selected PDN GW is located.
Homogenous Support of IMS Voice Indicates per UE and MME if "IMS Voice over PS Sessions" is homogeneously
over PS Sessions for MME supported in all TAs in the serving MME or homogeneously not supported, or,
support is non-homogeneous/unknown, see clause 4.3.5.8A.
List of APN - PDN GW ID relations (for PDN subscription context with wildcard APN):
APN - P-GW relation #n The APN and the identity of the dynamically allocated PDN GW of a PDN
connection that is authorised by the PDN subscription context with the wildcard
APN. The PDN GW identity may be either an FQDN or an IP address. The
PDN GW identity refers to a specific PDN GW.
NOTE 1: IMEI and SVN are stored in HSS when the Automatic Device Detection feature is supported, see clause
15.5 of TS 23.060 [7].
3GPP
Release 15 291 3GPP TS 23.401 V15.10.0 (2019-12)
NOTE 2: The 'EPS subscribed QoS profile' stored in HSS is complementary to the legacy 'GPRS subscribed QoS
profile'.
NOTE 3: Void.
NOTE 4: How to indicate which of the PDN subscription contexts stored in the HSS is the default one for the UE is
defined in stage 3.
NOTE 5: To help with the selection of a co-located or topologically appropriate PDN GW and Serving GW, the
PDN GW identity shall be in the form of an FQDN.
NOTE 6: The "Access Point Name (APN)" field in the table above contains the APN-NI part of the APN.
NOTE 7: In this specification, the values "prohibited for SIPTO" and " allowed for SIPTO excluding SIPTO at the
local network" correspond to the pre Rel-12 values "prohibited for SIPTO" and "allowed for SIPTO".
Actual coding of these values belongs to Stage 3 domain.
NOTE 8: There may be at most two default APNs for a given user. One default APN can belong to either of the
three PDN types of "IPv4", "IPv6", or "IPv4v6", and another default APN can belong to PDN type of
"Non-IP".
An expired CSG subscription should not be removed from the HSS subscription data before it is removed from the UE's
Allowed CSG list or Operator CSG list. When a CSG subscription is cancelled it should be handled as an expired
subscription in HSS subscription data to allow for removing it from UE's Allowed CSG list or Operator CSG list first.
One (and only one) of the PDN subscription contexts stored in the HSS may contain a wild card APN (see
TS 23.003 [9]) in the Access Point Name field.
The PDN subscription context marked as the default one shall not contain a wild card APN.
The PDN subscription context with a wildcard APN shall not contain a statically allocated PDN GW.
If the LIPA permission and SIPTO permission flags are both included for a particular APN, they shall be set in a
consistent manner, e.g, if the LIPA permission is set to LIPA-only or LIPA-conditional, the SIPTO permission shall be
set to SIPTO-prohibited. Conversely, if the SIPTO permission indicates the APN is a SIPTO-allowed APN, the LIPA
permission shall be set to LIPA-prohibited. A SIPTO-allowed APN is an APN for which the SIPTO permission is set to
allowed for SIPTO excluding SIPTO at the local network, allowed for SIPTO including SIPTO at the local network or
allowed for SIPTO at the local network only.
3GPP
Release 15 292 3GPP TS 23.401 V15.10.0 (2019-12)
5.7.2 MME
The MME maintains MM context and EPS bearer context information for UEs in the ECM-IDLE, ECM-CONNECTED
and EMM-DEREGISTERED states. Table 5.7.2-1 shows the context fields for one UE.
Table 5.7.2-1: MME MM and EPS bearer Contexts
3GPP
Release 15 293 3GPP TS 23.401 V15.10.0 (2019-12)
Field Description
IMSI IMSI (International Mobile Subscriber Identity) is the subscriber's permanent
identity.
IMSI-unauthenticated-indicator This is an IMSI indicator to show the IMSI is unauthenticated.
MSISDN The basic MSISDN of the UE. The presence is dictated by its storage in the HSS.
MM State Mobility management state ECM-IDLE, ECM-CONNECTED, EMM-
DEREGISTERED.
GUTI Globally Unique Temporary Identity.
ME Identity Mobile Equipment Identity – (e.g. IMEI/IMEISV) Software Version Number
Tracking Area List Current Tracking area list
TAI of last TAU TAI of the TA in which the last Tracking Area Update was initiated.
E-UTRAN Cell Global Identity Last known E-UTRAN cell
E-UTRAN Cell Identity Age Time elapsed since the last E-UTRAN Cell Global Identity was acquired
PS Cell Global Identity Last known Primary Cell of Secondary Cell Group
PS Cell Age Time elapsed since the last Primary Cell of Secondary Cell Group Identity was
acquired
CSG ID Last known CSG ID when the UE was active
CSG membership Last known CSG membership of the UE when the UE was active
Access mode Access mode of last known ECGI when the UE was active
Authentication Vector Temporary authentication and key agreement data that enables an MME to
engage in AKA with a particular user. An EPS Authentication Vector consists of
four elements:
a) network challenge RAND,
b) an expected response XRES,
c) Key KASME,
d) a network authentication token AUTN.
UE Radio Access Capability UE radio access capabilities including WB-E-UTRAN capabilities but not NB-IoT
capabilities.
LTE-M Indication Indicates the UE is a LTE-M UE and the UE Radio Access Capability includes LTE
Cat- M1 or LTE Cat-M1 and LTE Cat-M2. This is based on indication from the E-
UTRAN provides.
NB-IoT specific UE Radio NB-IoT specific UE radio access capabilities.
Access Capability
MS Classmark 2 GERAN/UTRAN CS domain core network classmark (used if the MS supports
SRVCC to GERAN or UTRAN)
MS Classmark 3 GERAN CS domain radio network classmark (used if the MS supports SRVCC to
GERAN)
Supported Codecs List of codecs supported in the CS domain (used if the MS supports SRVCC to
GERAN or UTRAN)
UE Network Capability UE network capabilities including security algorithms and key derivation functions
supported by the UE
MS Network Capability For a GERAN and/or UTRAN capable UE, this contains information needed by the
SGSN.
UE Specific DRX Parameters UE specific DRX parameters for A/Gb mode, Iu mode and S1-mode
Active Time value for PSM UE specific Active Time value allocated by MME for power saving mode handling.
Extended idle mode DRX Negotiated extended idle mode DRX parameters for S1-mode.
parameters
RAT specific Subscribed Paging Indicates a Subscribed Paging Time Window value for the associated RAT, NB-
Time Window IoT, WB-E-UTRAN or both.
Selected NAS Algorithm Selected NAS security algorithm
eKSI Key Set Identifier for the main key KASME. Also indicates whether the UE is using
security keys derived from UTRAN or E-UTRAN security association.
KASME Main key for E-UTRAN key hierarchy based on CK, IK and Serving network
identity
NAS Keys and COUNT KNASint, K_NASenc, and NAS COUNT parameter.
Selected CN operator id Selected core network operator identity (to support network sharing as defined in
TS 23.251 [24]).
Recovery Indicates if the HSS is performing database recovery.
Access Restriction The access restriction subscription information. For this purpose, WB-E-UTRAN
and NB-IoT are separate RATs. In addition, it includes restriction information on
the use of NR as secondary RAT for user plane connectivity and use of
Unlicensed Spectrum (in the form of LAA, or LWA/LWIP).
ODB for PS parameters Indicates that the status of the operator determined barring for packet oriented
services.
3GPP
Release 15 294 3GPP TS 23.401 V15.10.0 (2019-12)
Field Description
APN-OI Replacement Indicates the domain name to replace the APN-OI when constructing the PDN GW
FQDN upon which to perform a DNS resolution. This replacement applies for all
the APNs in the subscriber's profile. See TS 23.003 [9] clause 9.1.2 for more
information on the format of domain names that are allowed in this field.
MME IP address for S11 MME IP address for the S11 interface (used by S-GW)
MME TEID for S11 MME Tunnel Endpoint Identifier for S11 interface.
S-GW IP address for S11/S4 S-GW IP address for the S11 and S4 interfaces
S-GW TEID for S11/S4 S-GW Tunnel Endpoint Identifier for the S11 and S4 interfaces.
SGSN IP address for S3 SGSN IP address for the S3 interface (used if ISR is activated for the GERAN
and /or UTRAN capable UE)
SGSN TEID for S3 SGSN Tunnel Endpoint Identifier for S3 interface (used if ISR is activated for the
E-UTRAN capable UE)
eNodeB Address in Use for S1- The IP address of the eNodeB currently used for S1-MME.
MME
eNB UE S1AP ID Unique identity of the UE within eNodeB.
MME UE S1AP ID Unique identity of the UE within MME.
Subscribed UE-AMBR The Maximum Aggregated uplink and downlink MBR values to be shared across
all Non-GBR bearers according to the subscription of the user.
UE-AMBR The currently used Maximum Aggregated uplink and downlink MBR values to be
shared across all Non-GBR bearers.
EPS Subscribed Charging The charging characteristics for the UE e.g. normal, prepaid, flat rate and/or hot
Characteristics billing.
Subscribed RFSP Index An index to specific RRM configuration in the E-UTRAN that is received from the
HSS.
RFSP Index in Use An index to specific RRM configuration in the E-UTRAN that is currently in use.
Trace reference Identifies a record or a collection of records for a particular trace.
Trace type Indicates the type of trace
Trigger id Identifies the entity that initiated the trace
OMC identity Identifies the OMC that shall receive the trace record(s).
URRP-MME URRP-MME indicating that the HSS has requested the MME to notify the HSS
regarding UE reachability at the MME
DL Data Buffer Expiration Time When extended buffering of DL data has been invoked for UEs that uses power
saving functions e.g. PSM, this time is when the buffer will expire in the Serving
GW.
Suggested number of buffered Suggested number of buffered downlink packets at extended buffering. This is an
downlink packets optional parameter.
CSG Subscription Data The CSG Subscription Data is associated lists of CSG IDs for the visiting PLMN
and the equivalent PLMNs fo the visitng PLMN, and for each CSG ID optionally an
associated expiration date which indicates the point in time when the subscription
to the CSG ID expires; an absent expiration date indicates unlimited subscription.
For a CSG ID that can be used to access specific PDNs via Local IP Access, the
CSG ID entry includes the corresponding APN(s).
LIPA Allowed Specifies whether the UE is allowed to use LIPA in this PLMN.
Subscribed Periodic RAU/TAU Indicates a subscribed Periodic RAU/TAU Timer value.
Timer
MPS CS priority Indicates that the UE is subscribed to the eMLPP or 1x RTT priority service in the
CS domain.
MPS EPS priority Indicates that the UE is subscribed to MPS in the EPS domain.
Voice Support Match Indicator An indication whether the UE radio capabilities are compatible with the network
configuration (e.g. whether the SRVCC and frequency support by the UE matches
those that the network relies upon for voice coverage). The MME uses it as an
input for setting the IMS voice over PS Session Supported Indication.
Homogenous Support of IMS Indicates per UE if "IMS Voice over PS Sessions" is homogeneously supported in
Voice over PS Sessions all TAs in the serving MME or homogeneously not supported, or, support is non-
homogeneous/unknown, see clause 4.3.5.8A.
UE Radio Capability for Paging Information used by the eNB to determine the timing of paging events and/or
Information - WB-E-UTRAN enhance the paging towards the UE (see clause 5.11.4). The UE Radio Capability
for Paging Information is defined in TS 36.413 [36].
UE Radio Capability for Paging Information used by the eNB to determine the timing of paging events and/or
Information - NB-IoT enhance the paging towards the UE (see clause 5.11.4). The UE Radio Capability
for Paging Information is defined in TS 36.413 [36].
Information On Recommended Information sent by the eNB, and used by the MME when paging the UE to help
Cells And ENBs For Paging determining the eNBs to be paged as well as to provide the information on
recommended cells to each of these eNBs, in order to optimise the probability of
successful paging while minimizing the signalling load on the radio path.
3GPP
Release 15 295 3GPP TS 23.401 V15.10.0 (2019-12)
Field Description
Paging Attempt Count Information provided by the MME and used by the eNB to optimise signalling load
and the use of network resources to successfully page a UE.
Information for Enhanced Information for Enhanced Coverage level and cell ID provided by the last eNB the
Coverage UE was connected to.
CE mode B Support Indicator Indicates whether CE mode B is supported by the UE. The MME receives this
from eNB (see TS 36.413 [36]).
Enhanced Coverage Restricted Specifies whether the UE is restricted to use enhanced coverage feature or not.
CE mode B Restricted Specifies whether the UE is restricted to use CE mode B (i.e. Coverage Extension
mode B) or not.
UE Usage Type Indicates the usage characteristics of the UE for use with Dedicated Core
Networks (see clause 4.3.25).
Group ID-list List of the subscribed group(s) that the UE belongs to
Monitoring Event Information Describes the monitoring event configuration information. See TS 23.682 [74] for
Data more information.
Delay Tolerant Connection Indicates that the PDN connection is delay tolerant such that the PDN GW
supports holding the procedure, after receiving a reject with a cause indicating that
UE is temporarily not reachable due to power saving, until the PDN GW receives a
message indicating that the UE is available for end to end signalling
PDN Connection Restriction Indicates whether the establishment of the PDN connection is restricted for the
UE.
Acknowledgements of downlink Indicates whether acknowledgement of downlink NAS data PDUs for Control
NAS data PDUs Plane CIoT EPS Optimisation is disabled for this UE (enabled by default).
Service Gap Time Used to set the Service Gap timer for Service Gap Control (see clause 4.3.17.9).
List of APN Rate Control Indicates for each APN, the APN Rate Control Status (see clause 4.7.7.3).
Statuses
For each active PDN connection:
APN in Use The APN currently used. This APN shall be composed of the APN Network
Identifier and the default APN Operator Identifier, as specified in TS 23.003 [9],
clause 9.1.2. Any received value in the APN OI Replacement field is not applied
here.
APN Restriction Denotes the restriction on the combination of types of APN for the APN associated
with this EPS bearer Context.
APN Subscribed The subscribed APN received from the HSS.
PDN Type IPv4, IPv6,r IPv4v6 or Non-IP
SCEF ID The IP address of the SCEF currently being used for providing PDN connection to
the SCEF.
IP Address(es) IPv4 address and/or IPv6 prefix
NOTE: The MME might not have information on the allocated IPv4 address.
Alternatively, following mobility involving a pre-release 8 SGSN, this
IPv4 address might not be the one allocated to the UE.
Header Compression ROHC configuration and context(s) for IP header compression for Control Plane
Configuration CIoT EPS Optimisation.
EPS PDN Charging The charging characteristics of this PDN connection, e.g. normal, prepaid, flat-rate
Characteristics and/or hot billing.
APN-OI Replacement APN level APN-OI Replacement which has same role as UE level APN-OI
Replacement but with higher priority than UE level APN-OI Replacement. This is
an optional parameter. When available, it shall be used to construct the PDN GW
FQDN instead of UE level APN-OI Replacement.
SIPTO permissions Indicates whether the traffic associated with this APN is prohibited for SIPTO,
allowed for SIPTO excluding SIPTO at the local network, allowed for SIPTO
including SIPTO at the local network or allowed for SIPTO at the local network
only.
Local Home Network ID If SIPTO@LN is enabled for this PDN connection it indicates the identity of the
Local Home Network to which the (H)eNB belongs.
LIPA permissions Indicates whether the PDN can be accessed via Local IP Access. Possible values
are: LIPA-prohibited, LIPA-only and LIPA-conditional.
WLAN offloadability Indicates whether the traffic associated with this PDN Connection is allowed to be
offloaded to WLAN using the WLAN/3GPP Radio Interworking feature or if it shall
be kept on 3GPP access (see clause 4.3.23). The indication may contain separate
VPLMN Address Allowed Specifies whether the UE is allowed to use the APN in the domain of the HPLMN
only, or additionally the APN in the domain of the VPLMN.
PDN GW Address in Use The IP address of the PDN GW currently used for sending control plane signalling.
(control plane)
PDN GW TEID for S5/S8 PDN GW Tunnel Endpoint Identifier for the S5/S8 interface for the control plane.
(control plane) (For GTP-based S5/S8 only).
3GPP
Release 15 296 3GPP TS 23.401 V15.10.0 (2019-12)
Field Description
MS Info Change Reporting Need to communicate change in User Location Information to the PDN GW with
Action this EPS bearer Context.
CSG Information Reporting Need to communicate change in User CSG Information to the PDN GW with this
Action EPS bearer Context.
This field denotes separately whether the MME/SGSN are requested to send
changes in User CSG Information for (a) CSG cells, (b) hybrid cells in which the
subscriber is a CSG member and (c) hybrid cells in which the subscriber is not a
CSG member.
Presence Reporting Area Action Need to communicate a change of UE presence in Presence Reporting Area. This
field denotes separately the PRA identifier(s), and the list(s) of the Presence
Reporting Area elements (if provided by the PDN GW). The status (i.e. active or
inactive) for each Presence Reporting Area is stored in the MME when dynamic
resource handling for Presence Reporting Area is configured in the MME.
EPS subscribed QoS profile The bearer level QoS parameter values for that APN's default bearer (QCI and
ARP) (see clause 4.7.3).
Subscribed APN-AMBR The Maximum Aggregated uplink and downlink MBR values to be shared across
all Non-GBR bearers, which are established for this APN, according to the
subscription of the user.
APN-AMBR The Maximum Aggregated uplink and downlink MBR values to be shared across
all Non-GBR bearers, which are established for this APN, as decided by the
PDN GW.
PDN GW GRE Key for uplink PDN GW assigned GRE Key for the S5/S8 interface for the user plane for uplink
traffic (user plane) traffic. (For PMIP-based S5/S8 only)
Default bearer Identifies the EPS Bearer Id of the default bearer within the given PDN connection.
low access priority Indicates that the UE requested low access priority when the PDN connection was
opened.
NOTE: The low access priority indicator is only stored for the purpose to be
included in charging records.
Communication Patterns Indicates per UE the Communication Patterns and their corresponding validity
times as specified in TS 23.682 [74]. The Communication Patterns are not
provided to the SGSN.
PDN continuity at inter RAT Provides for this APN how to handle a PDN connection when UE the moves
mobility between "broadband" (WB-E-UTRAN and UTRAN) and "narrowband" (NB-IoT,
GPRS, EC-GSM-IoT). Possible values are: maintain the PDN connection;
disconnect the PDN connection with a reactivation request; disconnect PDN
connection without reactivation request; or to leave it to local VPLMN policy.
For each bearer within the PDN connection:
EPS Bearer ID An EPS bearer identity uniquely identifies an EP S bearer for one UE accessing
via E-UTRAN
S-GW IP address for S1-u/S11- IP address of the S-GW for the S1-u interface. Also IP address of the S-GW for
u the S11-u interface if no separation of S1-U and S11-U is required. The S11-u
interface is used for Control Plane CIoT EPS Optimisation.
S-GW IP address for S11-u IP address of the S-GW for the S11-u interfaces if S11-u is separated from S1-u.
The S11-u interface is used for Control Plane CIoT EPS Optimisation.
S-GW TEID for S1-u/S11-u Tunnel Endpoint Identifier of the S-GW for the S1-u interface. Also Tunnel
Endpoint Identifier of the S-GW for the S11-u interface if no separation of S1-U
and S11-U is required. The S11-u interface is used for Control Plane CIoT EPS
Optimisation.
S-GW TEID for S11-u Tunnel Endpoint Identifier of the S-GW for the S11-u interface if if S11-u is
separated from S1-u. The S11-u interface is used for Control Plane CIoT EPS
Optimisation.
MME IP address for S11-u MME IP address for the S11-u interface (Used by the S-GW). The S11-u interface
is used for Control Plane CIoT EPS Optimisation.
MME TEID for S11-u MME Tunnel Endpoint Identifier for the S11-u interface (Used by the S-GW). The
S11-u interface is used for Control Plane CIoT EPS Optimisation.
PDN GW TEID for S5/S8 (user P-GW Tunnel Endpoint Identifier for the S5/S8 interface for the user plane. (Used
plane) for S-GW change only).
NOTE: The PDN GW TEID is needed in MME context as S-GW relocation is
triggered without interaction with the source S-GW, e.g. when a TAU
occurs. The Target S-GW requires this Information Element, so it must
be stored by the MME.
3GPP
Release 15 297 3GPP TS 23.401 V15.10.0 (2019-12)
Field Description
PDN GW IP address for S5/S8 P GW IP address for user plane for the S5/S8 interface for the user plane. (Used
(user plane) for S-GW change only).
NOTE: The PDN GW IP address for user plane is needed in MME context as
S-GW relocation is triggered without interaction with the source S-GW,
e.g. when a TAU occurs. The Target S GW requires this Information
Element, so it must be stored by the MME.
EPS bearer QoS QCI and ARP
optionally: GBR and MBR for GBR bearer
TFT Traffic Flow Template. (For PMIP-based S5/S8 only)
Serving PLMN-Rate-Control The Serving PLMN-Rate-Control limits the maximum number of NAS Data PDUs
per deci hour sent per direction (uplink/downlink) using the Control Plane CIoT
EPS Optimisation for a PDN connection.
The MME Emergency Configuration Data is used instead of UE subscription data received from the HSS, for all
emergency bearer services that are established by an MME on UE request.
Table 5.7.2-2: MME Emergency Configuration Data
Field Description
Emergency Access Point Name A label according to DNS naming conventions describing the access point used for
(em APN) Emergency PDN connection (wild card not allowed).
Emergency QoS profile The bearer level QoS parameter values for Emergency APN's default bearer (QCI
and ARP). The ARP is an ARP value reserved for emergency bearers.
Emergency APN-AMBR The Maximum Aggregated uplink and downlink MBR values to be shared across
all Non-GBR bearers, which are established for the Emergency APN, as decided
by the PDN GW.
Emergency PDN GW identity The statically configured identity of the PDN GW used for emergency APN. The
PDN GW identity may be either an FQDN or an IP address.
Non-3GPP HO Emergency PDN The statically configured identity of the PDN GW used for emergency APN when a
GW identity PLMN supports handover to non-3GPP access. The PDN GW identity may be
either an FQDN or an IP address.(NOTE 1)
NOTE 1: The FQDN always resolves to one PDN GW.
NOTE: QCI for Emergency APN's default bearer is set per operator configuration.
5.7.3 Serving GW
The Serving GW maintains the following EPS bearer context information for UEs. Table 5.7.3-1 shows the context
fields for one UE.
For emergency attached UEs which are not authenticated, IMEI is stored in context.
3GPP
Release 15 298 3GPP TS 23.401 V15.10.0 (2019-12)
Table 5.7.3-1: S-GW EPS bearer context
Field Description E-UTRAN UTRAN/

GERAN
IMSI IMSI (International Mobile Subscriber Identity) is the subscriber X X
permanent identity.
IMSI-unauthenticated- This is an IMSI indicator to show the IMSI is unauthenticated. X X
indicator
ME Identity Mobile Equipment Identity (e.g. IMEI/IMEISV). X X
MSISDN The basic MSISDN of the UE. The presence is dictated by its X X
storage in the HSS.
Selected CN operator id Selected core network operator identity (to support network X X
sharing as defined in TS 23.251 [24]).
LTE-M Indication Information used by the core network to differentiate traffic X
from category M UEs for charging purposes, where different
values of M (e.g. M1, M2) are defined in TS 36.306 [82].
MME TEID for S11 MME Tunnel Endpoint Identifier for the S11 interface X
MME IP address for S11 MME IP address the S11 interface. X
S-GW TEID for S11/S4 S-GW Tunnel Endpoint Identifier for the S11 Interface and the X X
(control plane) S4 Interface (control plane).
S-GW IP address for S-GW IP address for the S11 interface and the S4 Interface X X
S11/S4 (control plane) (control plane).
SGSN IP address for S4 SGSN IP address for the S4 interface (Used by the S-GW). X
(control plane)
SGSN TEID for S4 (control SGSN Tunnel Endpoint Identifier for the S4 interface. X
plane)
Trace reference Identifies a record or a collection of records for a particular X X
trace.
Trace type Indicates the type of trace X X
Trigger id Identifies the entity that initiated the trace X X
OMC identity Identifies the OMC that shall receive the trace record(s). X X
Last known Cell Id This is the last location of the UE known by the network X X
(NOTE 1) (NOTE 1)
Last known Cell Id age This is the age of the above UE location information X X
(NOTE 1) (NOTE 1)
DL Data Buffer Expiration The time until the Serving GW buffers DL data, when the MME X X
Time has requested extended buffering in an DDN Ack (e.g. when a
UE is in PSM).
Serving PLMN-Rate-Control For inclusion on Serving GW CDR to allow post processing of X
CDRs and permit detection of abusive UEs.
For each PDN Connection:
NOTE: The following entries are repeated for each PDN.
APN in Use The APN currently used, as received from the MME or S4 X X
SGSN.
PDN Type IPv4, IPv6, IPv4v6 or Non-IP. (This information is needed by X
the SGW in order to determine whether to perform Paging
Policy Differentiation).
EPS PDN Charging The charging characteristics of this PDN connection, e.g. X X
Characteristics normal, prepaid, flat-rate and/or hot billing.
P-GW Address in Use The IP address of the P-GW currently used for sending control X X
(control plane) plane signalling.
P-GW TEID for S5/S8 P-GW Tunnel Endpoint Identifier for the S5/S8 interface for the X X
(control plane) control plane. (For GTP-based S5/S8 only).
P-GW Address in Use (user The IP address of the P-GW currently used for sending user X X
plane) plane traffic. (For PMIP-based S5/S8 only)
P-GW GRE Key for uplink PDN GW assigned GRE Key for the S5/S8 interface for the X X
traffic (user plane) user plane for uplink traffic. (For PMIP-based S5/S8 only)
S-GW IP address for S5/S8 S-GW IP address for the S5/S8 for the control plane signalling. X X
(control plane)
S-GW TEID for S5/S8 S-GW Tunnel Endpoint Identifier for the S5/S8 control plane X X
(control plane) interface. (For GTP-based S5/S8 only).
S-GW Address in Use (user The IP address of the S-GW currently used for sending user X X
plane) plane traffic. (For PMIP-based S5/S8 only)
S-GW GRE Key for downlink Serving GW assigned GRE Key for the S5/S8 interface for the X X
traffic (user plane) user plane for downlink traffic. (For PMIP-based S5/S8 only)
Default Bearer Identifies the default bearer within the PDN connection by its X X
EPS Bearer Id. (For PMIP based S5/S8.)
3GPP
Release 15 299 3GPP TS 23.401 V15.10.0 (2019-12)

GERAN
For each EPS Bearer within the PDN Connection:
NOTE: The following entries defining the EPS Bearer specific parameters are included within the set of parameters defining
the PDN Connection.
EPS Bearer Id An EPS bearer identity uniquely identifies an EPS bearer for X X
one UE accessing via E-UTRAN
TFT Traffic Flow Template X X
plane) plane traffic. (For GTP-based S5/S8 only).
P-GW TEID for S5/S8 (user P-GW Tunnel Endpoint Identifier for the S5/S8 interface for the X X
plane) user plane. (For GTP-based S5/S8 only).
S-GW IP address for S5/S8 S-GW IP address for user plane data received from PDN GW. X X
(user plane) (For GTP-based S5/S8 only).
S-GW TEID for S5/S8 (user S-GW Tunnel Endpoint Identifier for the S5/S8 interface for the X X
plane) user plane. (For GTP-based S5/S8 only).
S-GW IP address for S1-u, S-GW IP address for the S1-u interface (used by the eNodeB), X X
S12, S4 (user plane) and for the S12 interface (used by the RNC) and for the S4
S11-u interface (used by the SGSN). Also S-GW IP address for the
S11-u interface (used by the MME) if no separation of S1-U
and S11-U is required. The S11-u interface is used for Control
S-GW IP address for S11-u S-GW IP address for the S11-u interface (used by the MME). if X
S11-u is separated from S1-u. The S11-u interface is used for
Control Plane CIoT EPS Optimisation.
S-GW TEID for S1-u, S12, S-GW Tunnel Endpoint Identifier for the S1-u interface, for the X X
S4 (user plane) and S11-u S12 interface (used by the RNC) and for the S4 interface (used
by the SGSN). Also S-GW Tunnel Endpoint Identifier for the
S11-u interface (used by the MME) if no separation of S1-U
and S11-U is required. The S11-u interface is used for Control
S-GW TEID for S11-u S-GW Tunnel Endpoint Identifier for the S11-u interface (used X
by the MME) if S11-u is separated from S1-u. The S11-u
interface is used for Control Plane CIoT EPS Optimisation.
MME IP address for S11-u MME IP address for the S11-u interface (Used by the S-GW). X
The S11-u interface is used for Control Plane CIoT EPS
Optimisation.
MME TEID for S11-u MME Tunnel Endpoint Identifier for the S11-u interface (Used X
by the S-GW). The S11-u interface is used for Control Plane
CIoT EPS Optimisation.
eNodeB IP address for S1-u eNodeB IP address for the S1-u interface (Used by the S-GW). X
eNodeB TEID for S1-u eNodeB Tunnel Endpoint Identifier for the S1-u interface. X
RNC IP address for S12 RNC IP address for the S12 interface (Used by the S-GW). X
RNC TEID for S12 RNC Tunnel Endpoint Identifier for the S12 interface. X
SGSN IP address for S4 SGSN IP address for the S4 interface (Used by the S-GW). X
(user plane)
SGSN TEID for S4 (user SGSN Tunnel Endpoint Identifier for the S4 interface. X
plane)
EPS Bearer QoS ARP, GBR, MBR, QCI. X X
Charging Id Charging identifier, identifies charging records generated by X X
S-GW and PDN GW.
NOTE 1: The "Last Known Cell Id Age" is stored so that when UE location information is made available from both E-
UTRAN and UTRAN/GERAN, the Serving GW can determine the "Last Known Cell Id".
5.7.4 PDN GW
The PDN GW maintains the following EPS bearer context information for UEs. Table 5.7.4-1 shows the context fields
for one UE.
For emergency attached UEs which are not authenticated, IMEI is stored in context.
3GPP
Release 15 300 3GPP TS 23.401 V15.10.0 (2019-12)
Table 5.7.4-1: P-GW context

GERAN
IMSI IMSI (International Mobile Subscriber Identity) is the X X
subscriber permanent identity.
IMSI-unauthenticated- This is an IMSI indicator to show the IMSI is unauthenticated. X X
indicator
ME Identity Mobile Equipment Identity (e.g. IMEI/IMEISV). X X
MSISDN The basic MSISDN of the UE. The presence is dictated by its X X
storage in the HSS.
Selected CN operator id Selected core network operator identity (to support network X X
sharing as defined in TS 23.251 [24]).
RAT type Current RAT X X
LTE-M Indication Information used by the core network to differentiate traffic X
from Category M UEs for charging purposes, where different
values of M (e.g. M1, M2) are defined in TS 36.306 [82].
Trace reference Identifies a record or a collection of records for a particular X X
trace.
Trace type Indicates the type of trace X X
Trigger id Identifies the entity that initiated the trace X X
OMC identity Identifies the OMC that shall receive the trace record(s). X X
For each APN in use:
NOTE: The following entries are repeated for each APN.
APN in use The APN currently used, as received from the S-GW. X X
APN AMBR The maximum aggregated uplink and downlink MBR values X X
to be shared across all Non-GBR bearers, which are
established for this APN.
APN Rate Control The APN-Rate-Control limits the maximum number of X
uplink/downlink packets and the maximum number of
additional exception report packets per a specific time unit
(e.g. minute, hour, day, week) for this APN. It includes an
indication as to whether or not Exception reports may still be
sent when the limit has been met.
For each PDN Connection within the APN:
NOTE: The following entries are repeated for each PDN connection within the APN.
IP Address(es) IPv4 address and/or IPv6 prefix X X
PDN type IPv4, IPv6, IPv4v6 or Non-IP X X
S-GW Address in Use The IP address of the S-GW currently used for sending X X
(control plane) control plane signalling.
S-GW TEID for S5/S8 S-GW Tunnel Endpoint Identifier for the S5/S8 interface for X X
(control plane) the control plane. (For GTP-based S5/S8 only).
plane) plane traffic. (For PMIP-based S5/S8 only).
S-GW GRE Key for downlink Serving GW assigned GRE Key for the S5/S8 interface for X X
traffic (user plane) the user plane for downlink traffic. (For PMIP-based S5/S8
only).
P-GW IP address for S5/S8 P-GW IP address for the S5/S8 for the control plane X X
(control plane) signalling.
P-GW TEID for S5/S8 P-GW Tunnel Endpoint Identifier for the S5/S8 control plane X X
(control plane) interface. (For GTP-based S5/S8 only).
plane) plane traffic. (For PMIP-based S5/S8 only).
P-GW GRE Key for uplink PDN GW assigned GRE Key for the S5/S8 interface for the X X
traffic (user plane) user plane for uplink traffic. (For PMIP-based S5/S8 only).
MS Info Change Reporting The MME and/or SGSN serving the UE support(s) X X
support indication procedures for reporting User Location Information and/or
User CSG Information.
MS Info Change Reporting Denotes whether the MME and/or the SGSN is/are X X
Action requested to send changes in User Location Information
change.
3GPP
Release 15 301 3GPP TS 23.401 V15.10.0 (2019-12)

GERAN
CSG Information Reporting Denotes whether the MME and/or the SGSN is/are X X
Action requested to send changes in User CSG Information change.
This field denotes separately whether the MME/SGSN are
requested to send changes in User CSG Information for (a)
CSG cells, (b) hybrid cells in which the subscriber is a CSG
member, and (c) hybrid cells in which the subscriber is not a
CSG member, or any combination of the above.
Presence Reporting Area Denotes whether the MME and/or the SGSN is/are X X
Action requested to send changes of UE presence in Presence
Reporting Area.This field denotes separately the Presence
Reporting Area identifier and the list of Presence Reporting
Area elements.
BCM The negotiated Bearer Control Mode for GERAN/UTRAN. X
Default Bearer Identifies the default bearer within the PDN connection by its X X
EPS Bearer Id. The default bearer is the one which is
established first within the PDN connection. (For GTP based
S5/S8 or for PMIP based S5/S8 if multiple PDN connections
to the same APN are supported).
EPS PDN Charging The charging characteristics of this PDN connection e.g.
Characteristics normal, prepaid, flat-rate and/or hot billing.
Serving PLMN-Rate-Control The Serving PLMN-Rate-Control limits the maximum number X
of uplink/downlink messages per a specific time unit (e.g.
minute, hour, day, week) for a PDN connection.
3GPP PS Data Off Status Current 3GPP PS Data Off status of the UE.
For each EPS Bearer within the PDN Connection:
NOTE 1: The following entries defining the EPS Bearer specific parameters are included within the set of parameters
defining the PDN Connection.
NOTE 2: The following entries are stored only for GTP-based S5/S8.
EPS Bearer Id An EPS bearer identity uniquely identifies an EPS bearer for X X
one UE accessing via E-UTRAN
TFT Traffic Flow Template X X
plane) plane traffic.
S-GW TEID for S5/S8 (user S-GW Tunnel Endpoint Identifier for the S5/S8 interface for X X
plane) the user plane.
P-GW IP address for S5/S8 P-GW IP address for user plane data received from PDN X X
(user plane) GW.
P-GW TEID for S5/S8 (user P-GW Tunnel Endpoint Identifier for the GTP Based S5/S8 X X
plane) interface for user plane.
EPS Bearer QoS ARP, GBR, MBR, QCI. X X
Charging Id Charging identifier, identifies charging records generated by X X
S-GW and PDN GW.
5.7.5 UE
The UE maintains the following context information. Table 5.7.5-1 shows the context fields. A GERAN or UTRAN
capable UE maintains in addition the context information as described in a similar UE context table in TS 23.060 [7].
3GPP
Release 15 302 3GPP TS 23.401 V15.10.0 (2019-12)
Table 5.7.5-1: UE context
Field Description
IMSI IMSI (International Mobile Subscriber Identity) is the subscriber's permanent identity.
EMM State Mobility management state EMM-REGISTERED, EMM-DEREGISTERED.
GUTI Globally Unique Temporary Identity.
ME Identity Mobile Equipment Identity – (e.g. IMEI/IMEISV) Software Version Number.
Tracking Area List Current Tracking area list.
last visited TAI A TAI which is contained in the TA list the UE registered to the network and which
identifies the tracking area last visited by the UE.
Selected NAS Algorithm Selected NAS security algorithm.
Selected AS Algorithm Selected AS security algorithms.
eKSI Key Set Identifier for the main key KASME. Also indicates whether the UE is using
security keys derived from UTRAN or E-UTRAN security association
KASME Main key for E-UTRAN key hierarchy based on CK, IK and Serving network identity.
NAS Keys and COUNT KNASint, KNASenc, and NAS COUNT parameter.
Temporary Identity used in This parameter is used internally by the UE to memorise which temporary ID it has
Next update (TIN) to indicate in the Attach Request and RAU/TAU Request as specified in clause
4.3.5.6.
UE Specific DRX Preferred E-UTRAN DRX cycle length
Parameters
Active Time value for PSM UE specific Active Time value allocated by MME for power saving mode handling.
Extended idle mode DRX Extended idle mode DRX parameters received from the MME.
parameters
Allowed CSG list The Allowed CSG list, which is under both user and operator control, indicates the
list of CSG IDs and the associated PLMN where the UE is a member.
Operator CSG list The Operator CSG list, which is under exclusive Operator control, indicates the list
of CSG IDs and the associated PLMN where the UE is a member.
Service Gap Time Used to set the Service Gap timer for Service Gap Control (see clause 4.3.17.9).
For each active PDN connection:
APN in Use The APN currently used. This APN shall be composed of the APN Network Identifier
and the default APN Operator Identifier, as specified in TS 23.003 [9], clause 9.1.2.
APN AMBR The maximum aggregated uplink and downlink MBR to be shared across all Non-
GBR bearers, which are established for this APN.
Assigned PDN Type The PDN Type assigned by the network (IPv4, IPv6, IPv4v6 or Non-IP).
IP Address(es) IPv4 address and/or IPv6 prefix
Header Compression ROHC configuration and context(s) for IP header compression for Control Plane
Configuration CIoT EPS Optimisation.
Default Bearer Identifies the default bearer within the PDN connection by its EPS Bearer Id. The
default bearer is the one which is established first within the PDN connection.
WLAN offloadability Indicates whether the traffic associated with this PDN Connection is allowed to be
offloaded to WLAN using the WLAN/3GPP Radio Interworking feature or if it shall be
kept on 3GPP access (see clause 4.3.23). The indication may contain separate
APN Rate Control The APN-Rate-Control limits the maximum number of uplink packets and the
maximum number of additional exception report packets per a specific time unit (e.g.
minute, hour, day, week) for this APN. It includes an indication as to whether or not
Exception reports may still be sent when the limit has been met.
Serving PLMN-Rate-Control The Serving PLMN-Rate-Control limits the maximum number of NAS Data PDUs
per deci hour sent uplink using the Control Plane CIoT EPS Optimisation for a PDN
connection.
For each EPS Bearer within the PDN connection
EPS Bearer ID An EPS bearer identity uniquely identifies an EPS bearer for one UE accessing via
E-UTRAN.
EPS bearer QoS GBR and MBR for GBR bearer.
TFT Traffic Flow Template.
5.7.6 Handling of Wild Card APN

When the wild card APN is present in the subscription context, the UE is authorized to connect to APNs which are not
present in the subscription context.
When a request is received for registering a PDN GW ID and there is no PDN subscription context with this APN, the
nodes (HSS/MME/ S4 SGSN) shall store the PDN GW ID - APN relation for the UE.
3GPP
Release 15 303 3GPP TS 23.401 V15.10.0 (2019-12)
When a request is received for deregistering of PDN GW ID and there is no PDN subscription context with this APN,
the nodes (HSS/MME/S4 SGSN) shall delete the PDN GW ID - APN relation from the list of APN - PDN GW ID
relations.
5.7.7 CSS
Please refer to TS 23.008 [28] for the content of the information storage for the CSS.
5.7A Charging
5.7A.1 General
Accounting functionality is provided by the Serving GW and the PDN GW. When a Secondary RAT may be used, the
Serving GW and PDN GW can be assisted by the E-UTRAN (see clause 5.7A.4).
The Serving GW shall be able to collect and report for each UE accounting information, i.e. the amount of data
transmitted in uplink and downlink direction categorized with the QCI and ARP pair per UE per PDN connection. For
GTP-based S5/S8 the accounting information is collected and reported per bearer.
The Serving GW shall not collect UE accounting information for packets that are being processed for the sole purpose
of indirect forwarding.
The Serving GW for inter-operator charging, and the PDN GW shall be able to interface the OFCS according to
charging principles and through reference points specified in TS 32.240 [51].
The PDN GW shall be able to provide charging functionality for each UE according to TS 23.203 [6]. The PDN GW
data collection for charging and usage monitoring purposes can be temporarily paused as described in clause 5.3.6A.
A PDN GW without a Gx interface shall be able to support flow based online and offline charging based on local
configuration and interaction with the Online and Offline Charging Systems.
The Online Charging System may provide a PRA identifier(s) to the PDN GW to subscribe to notifications about
changes of UE presence in Presence Reporting Area as defined in the TS 23.203 [6]. For UE-dedicated Presence
Reporting Areas the Online Charging System also provides the list(s) of the elements comprising each subscribed UE-
dedicated Presence Reporting Area.
The PDN GW shall be able to collect and report, for each UE, accounting information, i.e. the amount of data received
and transmitted in uplink and downlink direction categorized with the QCI and ARP pair per UE per PDN connection.
For GTP-based S5/S8 the accounting information is collected and reported per bearer. The PDN GW data collection can
be temporarily paused as described in clause 5.3.6A based on operator configuration in the PDN GW.
NOTE: A consequence of pausing the PDN GW data collection is that PDN GW accounting information may not
correspond to the volume that traversed the PDN GW and it is therefore not possible to verify accounting
information collected at the Serving GW for inter-operator charging.
The Charging identifier(s) generated by the PDN GW per bearer for GTP-based S5/S8 and per PDN connection for
PMIP-based S5/S8 and the PDN GW address for control signalling enables the correlation of the reporting from a
Serving GW and a PDN GW. The Charging identifier is uniquely assigned within the PDN GW.
The PDN GW receives Charging Characteristics from the Serving GW through GTP-S5/S8, or through PMIP for PMIP-
based S5/S8. The handling of the Charging Characteristics in the P-GW is defined in TS 32.251 [44].
To enable CSG charging function for a subscriber consuming network services via a CSG cell or a hybrid cell, User
CSG Information is transferred to the PDN GW as indicated by CSG Information Reporting Action. User CSG
Information includes CSG ID, access mode and CSG membership indication. CSG membership indication of whether
the UE is a member of the CSG is included if the access mode is hybrid.
The valid CSG information shall be available in the serving GW and PDN GW in connected mode.
The PCRF shall, if deployed, provide User CSG Information reporting rules to the PDN GW at Attach and PDN
Connectivity Request. PDN GW sets the CSG Information Reporting Action IE according to the User CSG Information
reporting rules and sends it to Serving GW and MME.
3GPP
Release 15 304 3GPP TS 23.401 V15.10.0 (2019-12)
To enable the MME to signal the correct RAT Type (NB-IoT or WB-E-UTRAN) to the SGW and PDN GW for
accounting information generation purposes, the eNodeB informs the MME of the RAT Type and TAC associated with
each cell in the S1 SETUP REQUEST and ENB CONFIGURATION UPDATE messages (TS 36.413 [36]). If the
eNodeB signals WB-EUTRAN and the UE is of Category M from the UE's radio capability, the MME reports RAT
Type LTE-M to the SGW. See clause 5.11.5 for more details.
5.7A.2 Usage Data Reporting for Secondary RAT

When a Secondary RAT can be used in conjunction with E-UTRAN, the HPLMN or VPLMN operator may wish to
record the data volume sent on the Secondary RAT.
In order to reduce the complexity of this procedure, and to align with existing per EPS bearer accounting procedures,
the following principles are used in this release:
a) The PLMN locally activates the Secondary RAT Usage Data Reporting by E-UTRAN O&M. The activation can
happen separately for Data Volume Reporting of NR and Unlicensed Spectrum. If the PLMN uses this feature, it
should ensure that this functionality is supported by all eNodeBs that support NR, Unlicensed Spectrum
aggregation (if used to record data volume sent over unlicensed spectrum) as a Secondary RAT.
b) The E-UTRAN reports uplink and downlink data volumes to the EPC for the Secondary RAT on a per EPS
bearer basis and per time interval.
NOTE 1: Secondary RAT includes access type NR and usage data reporting for Secondary RAT includes reporting
of the combination of NR usage as defined in TS 37.340 [85].
c) At X2 handover and S1 handover, the source eNodeB reports the data volumes to the EPC. The reported data
volume excludes data forwarded to the target RAN node.
d) At S1 Release, Connection Suspend, and EPS Bearer Deactivation the eNodeB reports the data volumes to the
EPC.
e) To assist "partial CDR" generation at the Serving GW and the PDN GW, E-UTRAN O&M can instruct the E-
UTRAN to also make periodic reports in case no event has triggered a report before the period expires.
NOTE 2: The timing of these periodic E-UTRAN reports is not expected to align with the timing of partial CDR
generation. Hence the frequency of E-UTRAN reports might be greater than that of partial CDR
generation.
NOTE 3: RAN needs to be able to partition the measurements in a report to indicate usage that occurred before and
after an absolute time. An example of the absolute time is that RAN is configured to partition data usage
reports that occurred before and after midnight.
f) As an option, the Serving Gateway sends the data volume reports on to PDN GWs identified in bilateral roaming
agreements.
5.7A.3 Secondary RAT Usage Data Reporting Procedure

The procedure in Figure 5.7A.3-1 may be used to report Secondary RAT usage data from eNodeB to the MME. It is
executed by the eNodeB to report the Secondary RAT usage data information which is then included in messages on
S11 towards Serving GW and S5/S8 interface to the PGW (e.g. during I-RAT handover procedures, S1 handover, X2
handover). This then further uses existing EPC signaling of the procedures involved.
The procedure in Figure 5.7A.3-2 may be used to report the Secondary RAT usage data from MME to the Serving GW.
Optionally, it is used to report the Secondary RAT usage data from Serving GW to the PDN GW when the reporting to
PDN GW is activated.
If the Secondary RAT usage data is provided by an S1AP message from eNodeB to MME other than the one indicated
in Figure 5.7A.3-1, the procedures in clause 5.7A.3-2 may be used to transfer the secondary RAT usage data to the
Serving GW and PDN GW (e.g. during S1 Release procedure).
During IRAT handovers, the procedures 5.7A.3-1 to 5.7A.3-2 in its entirety is executed to provide reporting of
Secondary RAT usage data to the Serving GW and to the PDN GW if PGW secondary RAT usage data reporting is
active.
3GPP
Release 15 305 3GPP TS 23.401 V15.10.0 (2019-12)
Handover related signalling of IRAT procedures may be used to provide reporting of Secondary RAT usage data to the
Serving GW instead of the signaling of figure 5.7A.3-2, when PGW secondary RAT usage data reporting is not active.
eNB MME
Figure 5.7A.3-1: RAN Secondary RAT usage data Reporting procedure
1. The eNB, if it supports Dual Connectivity with Secondary RAT (using NR radio (see clause 4.3.2a on Support
for Dual Connectivity), using unlicensed spectrum aggregation in the form of LAA/LWA/LWIP (see
clause 4.3.30)) and it is configured to report Secondary RAT usage data for the UE, depending on certain
conditions documented in this specification, it shall send a RAN usage data Report message to the MME
including the Secondary RAT usage data for the UE. The eNB will send only one RAN usage report for a UE
when the UE is subject to handover by RAN. The RAN usage data report includes a handover flag to indicate
when the message is sent triggered by X2-handover.
If Dual Connectivity is active or had been activated by that eNB, the eNB shall add the PSCell ID (and the time
elapsed since the Dual Connectivity was released if Dual Connectivity is no longer activated) to the RAT usage
data Report message.
eNodeB MME Serving GW PDN GW
RAN reports Secondary

RAT usage data
1. Change Notification
3. Change Notification Ack
Figure 5.7A.3-2: GW Secondary RAT usage data Reporting procedure
The eNB, if it supports Dual Connectivity with Secondary RAT (using NR radio (see clause 4.3.2a on Support for Dual
Connectivity), using unlicensed spectrum aggregation in the form of LAA/LWA/LWIP (see clause 4.3.30)) and it is
configured to report Secondary RAT usage data for the UE, it shall send include the Secondary RAT usage data for the
UE to the MME in certain messages depending on certain conditions documented elsewhere in this TS.
Secondary RAT usage reporting from the eNB is provided using S1 signaling message which are either at the UE level
(eg. Path Switch Request, etc), or at bearer level (eg. E-RAB modification indication, Deactivate bearer response, etc.)
3GPP
Release 15 306 3GPP TS 23.401 V15.10.0 (2019-12)
as captured in relevant clauses in this specification. In case Secondary RAT usage report is provided in bearer level
signaling message by the eNodeB, the Secondary RAT usage report is related only to the specific bearer.
1. The MME forwards the Secondary RAT usage data to the SGW in a Change Notification Request (Secondary
RAT usage data) message. If the SGW is requested to forward Secondary RAT usage data to the PGW, the
MME includes a flag causing the SGW to forward this to the PGW. Also, the MME informs the Serving GW if
the secondary RAT usage data shall not be processed by the Serving GW (e.g. during Serving GW relocation
when the usage data is to be forwarded via the target Serving GW).
2. The Serving GW may, based on flags received in the previous message and local configuration in the Serving
GW, send the Change Notification (Secondary RAT usage data) message to the PDN GW.
3. The PDN GW acknowledges receiving the Secondary RAT usage data for the UE by a Change Notification
Ack() message to the Serving GW.
4. The SGW acknowledges by sending a Change Notification ack() message back to the MME.
5.7A.4 Secondary RAT Periodic Usage Data Reporting Procedure

Periodic reporting of the Secondary RAT usage data is an optional function. When eNodeB, as defined in bullet e) of
clause 5.7A.2, is configured with a "time interval for Secondary RAT usage data reporting", the eNodeB shall send a
RAN Usage Data Report message for periodic reporting purposes to the MME only when this timer expires for a UE for
which Secondary RAT usage data reporting is ongoing. The timer runs from the last usage reporting for the UE. The
MME also indicates to SGW if secondary RAT usage data reporting to the PGW is active.
The procedures 5.7A.3-1 to 5.7A.3-2 in its entirety is executed to provide periodic reporting of Secondary RAT usage
data to the Serving GW and to the PDN GW when PGW secondary RAT usage data reporting is active. At use for
periodic usage data reporting, the procedure 5.7A.3-1 uses signalling from eNB which does not include a handover flag.
5.8 MBMS
MBMS is a point-to-multipoint service in which data is transmitted from a single source entity to multiple recipients.
Transmitting the same data to multiple recipients allows network resources to be shared.
Support of MBMS for EPS is defined in TS 23.246 [13].
5.9 Interactions with other services

5.9.1 Location Reporting Procedure
This procedure is used by an MME to request the eNodeB to report where the UE is currently located when the target
UE is in ECM-CONNECTED state. The need for the eNodeB to continue reporting ceases when the UE transitions to
ECM-IDLE. This procedure may be used for services that require accurate cell identification (e.g. for emergency
services, lawful intercept, charging). When Dual Connectivity is activated, the PSCell information is only reported if
requested by the MME.
3GPP
Release 15 307 3GPP TS 23.401 V15.10.0 (2019-12)
eNodeB MME
1. Location reporting control
2. Location Report
3. Cancel location reporting
Figure 5.9.1-1: Location Reporting Procedure
1) The MME sends a Location Reporting Control message to the eNodeB. The Location Reporting Control
message shall identify the UE for which reports are requested, the requested location information and may
contain information such as reporting type. Requested location information is TAI+EGCI, and if requested by
the MME, PSCell ID.
Reporting type indicates whether the message is intended to trigger:
- a single stand-alone report about the current Cell ID serving the UE; or
start the eNodeB to report whenever the UE changes cell.
In addition, the MME shall be able to control whether or not the RAN reports changes in the UE's PSCell ID.
NOTE 1: Requesting reports whenever the UE changes cell can increase signalling load on multiple interfaces.
Requesting reports for changes in PSCell ID can further increase signalling load. Hence it is
recommended that any such reporting is only applied for a limited number of subscribers.
2) The eNodeB sends a Location Report message informing the MME about the location of the UE which shall
include the requested location information.
3) The MME can send a Cancel Location Reporting message to inform the eNodeB that it should terminate location
reporting for a given UE. This message is needed only when the reporting was requested for a reporting period.
NOTE 2: Location reporting is transferred during X2 handover, although new control signalling is not transferred
during an active handover.
5.9.2 Location Change Reporting Procedure
5.9.2.1 General
The PDN GW may request for each PDN connection independently whether the MME shall report changes of
ECGI/eNodeB ID/TAI (by using the "MS Info Change Reporting Action" parameter) and/or the UE entering/leaving a
Presence Reporting Area (by using the "Presence Reporting Area Action" parameter) and/or whether the MME shall
report changes of user CSG information (by using "CSG Information Reporting Action" parameter) to the PDN GW.
This reporting (any combination of "MS Info Change Reporting Action" and/or "Presence Reporting Area Action"
and/or "CSG Information Reporting Action") may be controlled by the PDN GW at the following procedures:
- Attach,
- Tracking Area Update (when inducing a Modify Bearer procedure to the PDN GW),
- Inter-RAT Mobility to E-UTRAN (when inducing a Modify Bearer procedure to the PDN GW),
- Dedicated bearer activation,
- PDN GW initiated bearer modification with bearer QoS update,
- PDN GW initiated bearer modification without bearer QoS update,
3GPP
Release 15 308 3GPP TS 23.401 V15.10.0 (2019-12)
- UE requested PDN connectivity,
- UE requested bearer resource modification.
The "Presence Reporting Area Action" and "Presence Reporting Area Information" parameters apply to all procedures
listed above but, within this specification, their usage has only been described in the message flows related with the
Attach and the UE requested PDN connectivity procedures.
The reporting of UE entering/leaving a Presence Reporting Area is further described in clause 5.9.2.2.
The PDN GW may also request the MME to stop any of the above mentioned types of reporting. The MME shall obey
the last explicit instruction received from the PDN GW or source MME.
During both mobility management and session management procedures, the MME shall indicate to the PDN GW the
support of reporting location changes (using the MS Info Change Reporting support indication):
- If ECGI/eNodeB ID/TAI information is permitted to be sent to the PDN GW according to MME operator's
policy,
- If CSG information is permitted to be sent to the PDN GW according to MME operator's policy.
The MME may be configured to report ECGI/eNodeB ID/TAI changes only when one or more E-RAB(s) are
established. Otherwise the MME shall report ECGI/eNodeB ID/TAI changes as soon as detected.
If the level of support changes during a mobility management procedure then the MME shall indicate the current level
of support to the S-GW and shall in addition provide ECGI/eNodeB ID/TAI even if the PDN GW has not requested this
information. This could for example happen during MME change when the level of support indicated by the old MME
is not the same as in the new MME.
NOTE 1: The inclusion of ECGI/eNodeB ID/TAI will trigger a Modify Bearer Request message from S-GW to the
PDN GW and therefore this will make sure that the new level of support reaches the PDN GW.
At change of Serving Node (MME/S4-SGSN), the old Serving Node provides the new serving node with "MS Info
Change Reporting Action" as previously requested by the PDN GW. The new Serving Node takes the "MS Info Change
Reporting Action" immediately into account with the exception that, at mobility between a S4-SGSN and a MME, the
new MME (respectively S4-SGSN) does not take into account the "MS Info Change Reporting Action" received from
the S4-SGSN (respectively MME) but assumes that no location information change reporting is requested for the target
RAT. At a change of RAT type between EUTRAN and UTRAN or between EUTRAN and GERAN, if location
information change reporting is required in the target RAT, the PDN GW shall request "MS Info Change Reporting
Action" from the new Serving Node (MME or S4-SGSN). Upon inter-RAT mobility, if the target MME/S4-SGSN
supports location information change reporting, the target MME/S4-SGSN shall include the User Location Information
in the Create Session Request / Modify Bearer Request, regardless of whether location Information change reporting
had been requested in the previous RAT by the PDN GW.
The PDN GWPDN GW shall not request the MME to report location changes if it has not received the indication for
corresponding support from the MME.
NOTE 2: For E-UTRAN access, homogeneous support of reporting changes of UE presence in a Presence
Reporting Area in a network is assumed: When the PCRF configuration indicates that reporting changes
of UE presence in a Presence Reporting Area is supported for E-UTRAN, this means it is supported by all
the PDN GWPDN GW, all MME and all the SGW including the MME and SGW working in network
sharing mode. If change of UE presence in Presence Reporting Area reporting is not supported, the PCRF
may instead activate location information change reporting at cell, eNodeB or tracking area level.
The following procedure shall be used for location change reports to the PDN GWPDN GW where the report is not
combined with other mobility management or session management signalling. The procedure shall only apply when the
MME has been explicitly requested to report location changes.
The following procedure can be used for MO Exception Data Counter reporting where the report is not combined with
other mobility management or session management signalling. The MME only includes the MO Exception data counter
if the RRC establishment cause is set to "MO exception data" and the UE is accessing via the NB-IoT RAT. The MME
maintains the MO Exception Data Counter for Serving PLMN Rate Control purposes (see clause 4.7.7.2). The MME
may immediately send the MO Exception Data Counter to the Serving GW. Alternatively, in order to reduce signalling,
the MME may send the MO Exception Data Counter to the Serving GW as described in TS 29.274 [43]. The SGW and
PDN GWPDN GW indicate each use of this RRC establishment cause by the related counter on its CDR.
3GPP
Release 15 309 3GPP TS 23.401 V15.10.0 (2019-12)
NOTE 3: Due to the increased signalling load, it is recommended that ECGI/eNodeB ID/TAI or CSG reporting is
only applied for a limited number of subscribers.
Figure 5.9.2.1-1 represents the ECGI change triggering a report of change in ECGI, and/or the User CSG information
change triggering a report of change in user CSG information. The figure also shows the reporting of a TAI change
and/or when a UE enters or leaves a Presence Reporting Area.
UE eNodeB MME SGW PGW
1a. ECGI Info Update

1b. MME detects User CSG
Info change
1c. MME detects TAI change
1d. MME detects

Presence Reporting Area
entering/leaving
Figure 5.9.2.1-1: Notification of the ECGI, TAI and/or user CSG information changes
1a. the MME has received an ECGI information Update from the eNodeB.
1b. The MME detects that the user CSG information has changed by comparing with the MME stored user CSG
information, or
1c. The MME detects that the TAI of the UE has changed, or
1d. The MME detects that the UE has entered or left a Presence Reporting Area defined for this UE.
NOTE 4: It is possible that these changes are triggered at same time.
2. If the MME has been requested to report location changes to the PDN GWPDN GW for the UE (under the
conditions specified in clause 5.9.2), the MME shall send the Change Notification message to the SGW
indicating the new ECGI, TAI and/or user CSG information. The MME stores the notified user CSG
information. If the MME has been requested to report a change of UE presence in Presence Reporting Area
(under the conditions specified in clause 5.9.2), the MME shall send the Change Notification message including
the Presence Reporting Area Information comprising the area identifier(s) and indication(s) on whether the UE is
inside or outside the area(s). If MME decides to reactivate one or more of the inactive Presence Reporting
Area(s), the Presence Reporting Area Information in this message also comprises the reactivated PRA
identifier(s), and indication(s) on whether the UE is inside or outside the reactivated area(s).
3. The SGW forwards the Change Notification message to the PDN GWPDN GW. If dynamic PCC is deployed,
and location changes need to be conveyed to the PCRF, then the PDN GWPDN GW shall send this information
to the PCRF as defined in TS 23.203 [6]. If Presence Reporting Area Information has been received, the PDN
GWPDN GW shall forward the Presence Reporting Area Information to the PCRF, to the OCS or to both as
4. The PDN GW sends the Change Notification Ack to the SGW.
5. The SGW forwards the Change Notification Ack to the MME.
3GPP
Release 15 310 3GPP TS 23.401 V15.10.0 (2019-12)
5.9.2.2 Reporting at Presence Reporting Area entering and leaving

In some use cases policy control/charging decisions, such as QoS modification or charging rate change depend on
whether the UE is located inside or outside a specific area of interest (Presence Reporting Area), and especially on
whether the UE enters or leaves that specific area of interest.
A Presence Reporting Area can be:
- Either a "UE-dedicated Presence Reporting Area", defined in the subscriber profile and composed of a short list
of TAs/RAs, or eNBs and/or cells/SAs in a PLMN;
- Or a "Core Network predefined Presence Reporting Area", predefined in MME/SGSN and composed of a short
list of TAs/RAs, or eNBs and/or cells/SAs in a PLMN.
NOTE 1: eNBs are identified via the Global eNB ID IE defined in TS 36.413 [36].
NOTE 2: Change of UE presence in Presence Reporting Area reporting does not apply to roaming.
The reporting of changes of UE presence in Presence Reporting Area is for a specific UE and is triggered as defined in
TS 23.203 [6]. The PDN GW may request to Start/Stop reporting of changes of UE presence for one or more Presence
Reporting Area(s) by using the Presence Reporting Area Action parameter. For UE-dedicated Presence Reporting
Areas, the reporting request (Start) shall contain the PRA identifier(s) and the list(s) of TAs/RAs, or eNBs and/or
cells/SAIs composing the Presence Reporting Area(s). For Core Network predefined Presence Reporting Areas, the
reporting request (Start) shall contain the PRA identifier(s). The request to Stop a reporting contains the PRA
identifier(s).
Each Core Network predefined Presence Reporting Area can be configured with a priority level in the MME/S4-SGSN.
In order to prevent overload, the MME/S4-SGSN may set the reporting for one or more of the received Presence
Reporting Area(s) to inactive under consideration of the priority configured for each of Core Network predefined
Presence Reporting Area(s), while storing the reporting request for this Presence Reporting Area in the user context.
Upon reception of a request for change of UE presence in Presence Reporting Area reporting, the MME/S4-SGSN shall
report to the PDN GW via the SGW the Presence Reporting Area Information comprising the PRA identifier(s) and
indication(s) on whether the UE is inside or outside the Presence Reporting Area(s). If the UE is in ECM-IDLE state,
the MME may either bring the UE into ECM-CONNECTED state, or, report based on the UE's last known location and
when the UE was there. One or more Presence Reporting Area may be set for a given PDN connection at a time. The
serving node if needed only sets the reporting of UE presence in a Presence Reporting Area to inactive when receiving
the reporting request for this Presence Reporting Area. If the MME/S4-SGSN decides to set the reporting of UE
presence in one or more of the received Presence Reporting Area(s) to inactive, the MME/S4-SGSN shall also report
the inactive Presence Reporting Area(s).
The MME/S4-SGSN shall notify the PDN GW when the UE enters or leaves a Presence Reporting Area, and no
notifications are sent for UE movements inside or outside a Presence Reporting Area. The report of the change of UE
presence in Presence Reporting Area shall contain the Presence Reporting Area Information comprising the PRA
identifier(s) and indication(s) on whether the UE is inside or outside the area(s). A report shall be sent if the UE
presence is different to the last one reported.
The MME/S4-SGSN may be configured with a PRA identifier which refers to a Set of Core Network predefined
Presence Reporting Areas. The PDN GW may request Start reporting for this Set of Presence Reporting Areas by only
indicating this PRA identifier in the Presence Reporting Area Action. When the Presence Reporting Area(s) to be
reported belong to a set of Core Network predefined Presence Reporting Areas in which the MME/S4-SGSN is
requested to report on change of UE presence, the MME/S4-SGSN shall additionally add to the report the PRA
identifier of the Set of Core Network predefined Presence Reporting Areas.
Upon change of serving EPC node (MME, S4-SGSN), the PRA identifier(s) and if provided by the PDN GW the list(s)
of Presence Reporting Area elements are transferred for all PDN connections as part of MM Context information to the
target serving node during the mobility procedure. If one or more Presence Reporting Area(s) was set to inactive, the
target serving node may decide to reactivate one or more of the inactive Presence Reporting Area(s). The target serving
node indicates per PDN connection to the corresponding PDN GW the PRA identifier(s) and whether the UE is inside
or outside the Presence Reporting Area(s) as well as the inactive Presence Reporting Area(s), if any.
NOTE 3: The target serving node cannot set the Presence Reporting Area(s) received from the source serving node
to inactive.
3GPP
Release 15 311 3GPP TS 23.401 V15.10.0 (2019-12)
5.9.3 IMSI and APN information retrieval procedure

This procedure is used by the RCAF to determine the UEs that are served by a congested eNB or E-UTRAN cell and
the APNs of the active PDN connections of these UEs. This information is used to determine the PCRFs serving these
UEs and subsequently report RAN user-plane congestion information (RUCI) to the PCRFs. The decision whether the
RCAF requests MME to retrieve the list of UEs on eNB or E-UTRAN cell level is up to operator configuration.
NOTE 1: The details of congestion reporting to the PCRF are specified in TS 23.203 [6].
The RCAF determines the MMEs that are serving the congested eNB or E-UTRAN cell based on the Tracking Area
Identities served by the congested eNB or E-UTRAN cell. For further details on the related DNS procedure see
TS 29.303 [61]. The following steps are applied to all MMEs serving the congested eNB or E-UTRAN cell.
NOTE 2: In network sharing scenarios the RCAF belongs to the RAN operator. In this case it is up to inter-operator
agreements and operator configuration which sharing partner's MMEs the RCAF queries IMSI and APN
information from.
MME RCAF
1. IMSI/APN information request
2. IMSI/APN information response
Figure 5.9.3-1: IMSI and APN information retrieval procedure
1. The RCAF sends an IMSI/APN information request to the MME. The request shall identify whether the request
refers to an eNB or an E-UTRAN cell and shall contain the related eNB ID or ECGI.
NOTE 3: The eNB ID is defined in TS 36.413 [36].
2. The MME sends the IMSI/APN information response to the RCAF. The response shall contain the list of UEs
(identified by the IMSIs) served by the eNB or E-UTRAN cell and the list of APNs of the active PDN
connections of each IMSI.
If the RCAF requested the IMSI/APN information on E-UTRAN cell level, then the MME first determines the
list of UEs served by that E-UTRAN cell. The MME may achieve this by querying the eNB that the E-UTRAN
cell belongs to for the exact ECGI for all UEs served by this eNB using the Location Reporting procedure
(clause 5.9.1).
NOTE 4: Applying the Location Reporting feature due to an E-UTRAN cell level RCAF request can increase S1-
MME interface signalling load.
NOTE 5: In order for RCAF to maintain the list of impacted UEs (identified by the IMSIs) (and related APN
information) for a congested cell, the RCAF needs to regularly receive IMSI/APN information updates
from the MME. The details of whether the RCAF needs to query the MME regularly or whether the
MME updates the RCAF regularly without further explicit requests from the RCAF is specified in Stage
3.
5.10 Multiple-PDN support and PDN activation for UEs

supporting "Attach without PDN connectivity"
5.10.1 General
The EPS shall support simultaneous exchange of traffic to multiple PDNs through the use of separate PDN GWs or a
single PDN GW. The usage of multiple PDNs is controlled by network policies and defined in the user subscriptionEPS
Optimisation.
3GPP
Release 15 312 3GPP TS 23.401 V15.10.0 (2019-12)
The EPS shall support UE-initiated connectivity establishment in order to allow multiple PDN connections to one or
more PDNs. It shall be possible for a UE to initiate disconnection from any PDN.
All simultaneously active PDN connections of a UE that are associated with the same APN shall be provided by the
same PDN-GW.
UE support for multiple PDN connections is optional.
If the Control Plane CIoT EPS Optimisation is supported:
- a PDN connection of Non-IP PDN Type may also be served by an SCEF (see TS 23.682 [74]); multiple PDN
connections of Non-IP PDN Type may be served by the same or multiple SCEFs; and
- the MME decides, based on APN Configuration information, whether a PDN connection is served by an SCEF
or a PDN GW.
5.10.2 UE requested PDN connectivity

The UE requested PDN connectivity procedure for an E-UTRAN is depicted in figure 5.10.2-1. The procedure allows
the UE to request for connectivity to an additional PDN over E-UTRAN including allocation of a default bearer, if the
UE already has active PDN connections over E-UTRAN. This procedure may also be used when a UE has set "Attach
without PDN Connectivity is supported" in the Preferred Network behaviour at attach time and the network has
acknowledged its support to the UE. If so, the UE may remain attached without a Default PDN connection and, at any
time, request a PDN connection to be established. This procedure is also used to request for connectivity to an
additional PDN over E-UTRAN, if the UE is simultaneously connected to E-UTRAN and a non-3GPP access and the
UE already has active PDN connections over both accesses. The PDN connectivity procedure may trigger one or
multiple Dedicated Bearer Establishment procedures to establish dedicated EPS bearer(s) for that UE.
An emergency attached UE shall not initiate any PDN Connectivity Request procedure. A normal attached UE shall
request a PDN connection for emergency services when Emergency Service is required and an emergency PDN
connection is not already active.
The UE supporting 15 EPS bearers as defined in clause 4.12 shall not initiate a UE requested PDN connectivity
procedure if it has already 8 EPS bearers established and the UE has not received an Indication for support of 15 EPS
bearers per UE or has received cause #65 "maximum number of EPS bearers reached".
3GPP
Release 15 313 3GPP TS 23.401 V15.10.0 (2019-12)
1. PDN Connectivity Request


(A)
4. IP-CAN Session
Establishment/Modification
First Downlink Data

7. Bearer Setup Request or Downlink NAS transport with PDN Connectivity Accept
8. RRC Connection Reconfiguration or RRC Direct Transfer
10. Bearer Setup Response
11. Direct Transfer
12. PDN Connectivity Complete
First Uplink Data
13.a Modify Bearer request

(B)
13.b Modify Bearer response

First Downlink Data
15. Notify Request

16. Notify Response
Figure 5.10.2-1: UE requested PDN connectivity
NOTE 1: For a PMIP-based S5/S8, procedure steps (A) are defined in TS 23.402 [2]. Steps 3, 4, 5 and 13a/b
NOTE 2: The UE also uses this procedure to request re-establishment of existing PDN connectivity upon handover
from non-3GPP accesses.
NOTE 3: The steps in (B) are executed only upon handover from non-3GPP access or if Presence Reporting Area
Information is received from the MME.
NOTE 4: When using the Control Plane CIoT EPS Optimisation, steps 7 and 8 are modified and 9 and 10 are
skipped.
1. The UE initiates the UE Requested PDN procedure by the transmission of a PDN Connectivity Request (APN,
PDN Type, Protocol Configuration Options, Request Type, Header Compression Configuration) message. If the
UE was in ECM-IDLE mode, this NAS message is preceded by the Service Request procedure if any of the
exiting PDN connections were using the User Plane without CIoT EPS Optimisation, or, if the user plane was
used just with User Plane CIoT EPS Optimisations, a Connection Resume Procedure is executed instead. PDN
type indicates the requested IP version (IPv4, IPv4v6, IPv6, Non-IP).
The MME verifies that the APN provided by UE is allowed by subscription. If the APN provided by the UE is
not allowed by subscription, based on operator policy, the MME may reject the request from the UE with an
appropriate cause, or accept the request by replacing the UE requested APN with a network supported APN. The
3GPP
Release 15 314 3GPP TS 23.401 V15.10.0 (2019-12)
MME uses that network supported APN for the remainder of this procedure, except that the MME provides to
the UE the same APN that the UE requested. If the UE did not provide an APN, the MME shall use the APN
from the default PDN subscription context, and, use this APN for the remainder of this procedure.
Protocol Configuration Options (PCO) are used to transfer parameters between the UE and the Network and are
sent transparently through the MME and the Serving GW. The Protocol Configuration Options may include the
Address Allocation Preference, which indicates that the UE prefers to obtain an IPv4 address only after the
default bearer activation by means of DHCPv4. If the UE has UTRAN or GERAN capabilities, it shall send the
NRSU in the PCO to indicate the support of the network requested bearer control in UTRAN/GERAN. The UE
sends the ETFTU in the PCO to indicate the support of the extended TFT filter format. The Request Type
indicates "initial request" if the UE requests new additional PDN connectivity over the 3GPP access network for
multiple PDN connections, the Request Type indicates "handover" when the UE is performing a handover from
non-3GPP access and the UE has already established connectivity with the PDN over the non-3GPP access.
The UE shall indicate Request Type "Emergency" when it requests a PDN connection for emergency services.
If the message is being sent via a HeNB which has a collocated L-GW, it includes the L-GW address in the
Uplink NAS transport message to the MME.
If a UE indicated Control Plane CIoT EPS Optimisation supported in Preferred Network Behavior and supports
header compression, it shall include the Header Compression Configuration, unless "Non-IP" PDN type is
indicated. The Header Compression Configuration includes the information necessary for the ROHC channel
setup. Optionally, the Header Compression Configuration may also include additional header compression
context setup parameters, if the UE already has the application traffic information, e.g. the target server IP
address.
The UE shall include in the PCO the 3GPP PS Data Off UE Status, which indicates whether the user has
activated or deactivated 3GPP PS Data Off.
2. If the MME receives a PDN Connectivity Request from an emergency attached UE or the PDN Connectivity
Request is for normal services and the mobility or access restrictions do not allow the UE to access normal
services the MME shall reject this request.
If the Request Type indicates "Emergency" and the MME is not configured to support PDN connections for
emergency services the MME shall reject the PDN Connectivity Request with an appropriate reject cause.
If the Request Type is not set to "Emergency", and the UE has indicated support for Attach without PDN
Connectivity, and the network supports Attach without PDN Connectivity, and the PDN Connection Restriction
is set in the subscriber data, then the MME should reject the PDN Connectivity Request with an appropriate
cause value.
If the Request Type indicates "Emergency", the MME derives a PDN GW from the MME Emergency
Configuration Data or the MME selects a PDN GW as described in clause 4.3.12.4 on PDN GW Selection
Function (3GPP accesses) according to the Emergency APN in the MME Emergency Configuration Data. This
selection shall provide a PDN GW from visited PLMN only.
If the Request Type indicates "Emergency" and the MME is configured to support PDN connections for
emergency services, it uses the MME Emergency Configuration Data for the bearer establishment in this step
and ignores any subscription data limitation.
If the Request Type indicates "Handover", the MME uses the PDN GW stored in the Subscription Data retrieved
by the MME during the Update Location performed at attach. If the Request Type indicates "initial request" the
MME selects a PDN GW as described in clause 4.3.8.1 on PDN GW Selection Function (3GPP accesses).
If the UE provided APN is authorized for LIPA according to the user subscription, the MME shall use the CSG
Subscription Data to authorize the connection.
If the subscription context does not indicate that the APN is for a PDN connection to an SCEF the MME
allocates a Bearer Id, and sends a Create Session Request (IMSI, MSISDN, MME TEID for control plane, RAT
type, LTE-M RAT type reporting to PGW flag, PDN GW address, PDN Address, Default EPS Bearer QoS, PDN
Type, subscribed APN-AMBR, APN, EPS Bearer Id, Protocol Configuration Options, Handover Indication, ME
Identity, User Location Information (ECGI), UE Time Zone, User CSG Information, MS Info Change Reporting
support indication, Selection Mode, Charging Characteristics, Trace Reference, Trace Type, Trigger Id, OMC
Identity, Maximum APN Restriction, Dual Address Bearer Flag) message to the Serving GW. If Control Plane
3GPP
Release 15 315 3GPP TS 23.401 V15.10.0 (2019-12)
CIoT EPS Optimisation applies, then the MME shall also indicate S11-U tunnelling of NAS user data and send
its own S11-U IP address and MME DL TEID for DL data forwarding by the SGW.
If the MME determines the PDN connection shall only use the Control Plane CIoT EPS Optimisation, the MME
shall include a Control Plane Only PDN Connection Indicator in Create Session Request.
For PDN type "non-IP", if the APN subscription data indicate a SCEF connection needs to be used, then the
MME allocates an EPS Bearer Identity for the Default Bearer associated with the UE and established connection
to the SCEF address indicated in subscription data according to TS 23.682 [74] and the steps 2,3,4,5,6 are not
executed. The rest of the interactions with the UE apply as specified below.
The RAT type is provided in this message for the later PCC decision. The RAT type shall enable NB-IoT, LTE-
M and WB-E-UTRAN to be differentiated by the PDN-GW The MSISDN is included if the MME has it stored
for that UE. Handover Indication is included if the Request Type indicates "handover". Selection Mode indicates
whether a subscribed APN was selected, or a non-subscribed APN sent by the UE was selected. The P-GW may
use Selection Mode when deciding whether to accept or reject the default bearer activation. For example, if an
APN requires subscription, the P-GW is configured to accept only the default bearer activation that requests a
subscribed APN as indicated by Selection Mode. Charging Characteristics indicates which kind of charging the
bearer context is liable for.
The charging characteristics for the PS subscription and individually subscribed APNs as well as the way of
handling Charging Characteristics and whether to send them or not to the P-GW is defined in TS 32.251 [44].
The MME shall include Trace Reference, Trace Type, Trigger Id, and OMC Identity if S-GW and/or P-GW trace
is activated. The MME shall copy Trace Reference, Trace Type, and OMC Identity from the trace information
received from the HLR or OMC.
The Maximum APN Restriction denotes the most stringent restriction as required by any already active bearer
context. If there are no already active bearer contexts, this value is set to the least restrictive type (see clause 15.4
of TS 23.060 [7]). If the P-GW receives the Maximum APN Restriction, then the P-GW shall check if the
Maximum APN Restriction value does not conflict with the APN Restriction value associated with this bearer
context request. If there is no conflict the request shall be allowed, otherwise the request shall be rejected with
sending an appropriate error cause to the UE.
If the PDN subscription context contains a subscribed IPv4 address and/or IPv6 prefix, the MME indicates it in
the PDN address. The MME may change the requested PDN type according to the subscription data for this APN
as described in clause 5.3.1.1. The MME shall set the Dual Address Bearer Flag when the PDN type is set to
IPv4v6 and all SGSNs which the UE may be handed over to are Release 8 or above supporting dual addressing,
which is determined based on node pre-configuration by the operator.
If there is an APN Rate Control Status in the MME MM Context for the UE, the MME forwards it to the SGW.
3. The Serving GW creates a new entry in its EPS Bearer table and sends a Create Session Request (IMSI,
MSISDN, Serving GW Address for the user plane, Serving GW TEID of the user plane, Serving GW TEID of
the control plane, RAT type, Default EPS Bearer QoS, PDN Type, PDN Address, subscribed APN-AMBR,
APN, Bearer Id, Protocol Configuration Options, Handover Indication, ME Identity, User Location Information
(ECGI), UE Time Zone, User CSG Information, MS Info Change Reporting support indication, PDN Charging
Pause Support indication, Selection Mode, Charging Characteristics, Trace Reference, Trace Type, Trigger Id,
OMC Identity, Maximum APN Restriction, Dual Address Bearer Flag, APN Rate Control Status) message to the
PDN GW indicated in the PDN GW address received in the previous step. After this step, the Serving GW
buffers any downlink packets it may receive from the PDN GW until receives the message in step 13 below. The
MSISDN is included if received from the MME. If the Handover Indication is included, the Serving GW
includes it in the Create Session Request message.
informs the PDN GW this information in Create Session Request. The Serving GW and PDN GW shall indicate
the use of CP only on their CDRs.
P-GWs shall not perform any checks of Maximum APN Restriction if Create Default Bearer Request includes
emergency APN.
If the PDN GW detects that the 3GPP PS Data Off UE Status has changed, the PDN GW shall indicate this event
to the charging system for offline and online charging.
3GPP
Release 15 316 3GPP TS 23.401 V15.10.0 (2019-12)
4. If dynamic PCC is deployed and the Handover Indication is not present, the PDN GW may employ an IP-CAN
Session Establishment procedure as defined in TS 23.203 [6] with the PCRF to get the default PCC rules for the
UE. This may lead to the establishment of a number of dedicated bearers following the procedures defined in
clause 5.4.1 in association with the establishment of the default bearer which is described in Annex F.
The RAT type is provided to the PCRF by the PDN GW if received by the previous message. If the PDN
GW/PCEF is configured to activate predefined PCC rules for the default bearer, the interaction with the PCRF is
not required (e.g. operator may configure to do this) at the moment.
The ETFTU is provided to the PCRF by the PDN GW, if received in the PCO from the UE and the PDN GW
supports the extended TFT filter format. If the PCRF decides that the PDN connection may use extended TFT
filters, it shall return the ETFTN indicator to the PDN GW for inclusion in the protocol Configuration Options
returned to the UE.
If the PCC is configured to support emergency services and dynamic PCC is deployed, the PCRF, based on the
Emergency APN, sets the ARP of the PCC rules to a value that is reserved for emergency services and the
authorization of dynamic PCC rules as described in TS 23.203 [6]. If dynamic PCC is not deployed, the PDN
GW is configured to set the ARP to a value that is reserved for emergency services.
If dynamic PCC is deployed and the Handover Indication is present, the PDN GW executes a PCEF-Initiated
IP-CAN Session Modification procedure with the PCRF as specified in TS 23.203 [6] to report the new IP-CAN
type. Depending on the active PCC rules, the establishment of dedicated bearer for the UE may be required. The
establishment of those bearers shall take place in combination with the default bearer activation as described in
Annex F. This procedure can continue without waiting for a PCRF response. If changes to the active PCC rules
are required, the PCRF may provide them after the handover procedure is finished.
In both cases (Handover Indication is present or not), if dynamic PCC is not deployed, the PDN GW may apply
local QoS policy. This may lead to the establishment of a number of dedicated bearers for the UE following the
procedures defined in clause 5.4.1 in combination with the establishment of the default bearer, which is
described in Annex F.
If the CSG information reporting triggers are received from the PCRF, the PDN GW should set the CSG
Information Reporting Action IE accordingly.
If 3GPP PS Data Off status is received in the PCO from the UE and PDN GW supports 3GPP PS Data Off, the
PDN GW shall provide the 3GPP PS Data Off status to the PCRF. If the PCRF supports 3GPP PS Data Off, it
shall return 3GPP PS Data Off support to the PDN GW for inclusion in the PCO returned to the UE.
If the 3GPP PS Data Off UE Status indicates that 3GPP PS Data Off is activated for the UE, the PDN GW shall
enforce the PCC rules for downlink traffic to be used when 3GPP PS Data Off is activated.
If received, the PDN GW may take the APN Rate Control Status into account when encoding the APN Rate
Control parameters in Protocol Configuration Options and when enforcing the APN Rate Control as described in
clause 4.7.7.3.
5. The P-GW creates a new entry in its EPS bearer context table and generates a Charging Id for the Default
Bearer. The new entry allows the P-GW to route user plane PDUs between the S-GW and the packet data
network, and to start charging. The way the P-GW handles Charging Characteristics that it may have received is
The PDN GW returns a Create Session Response (PDN GW Address for the user plane, PDN GW TEID of the
user plane, PDN GW TEID of the control plane, PDN Type, PDN Address, EPS Bearer Id, EPS Bearer QoS,
Protocol Configuration Options, Charging Id, Prohibit Payload Compression, APN Restriction, Cause, MS Info
Change Reporting Action (Start) (if the PDN GW decides to receive UE's location information during the
session), CSG Information Reporting Action (Start) (if the PDN GW decides to receive UE's User CSG
information during the session), Presence Reporting Area Action (if the PDN GW decides to receive
notifications about a change of UE presence in Presence Reporting Area), PDN Charging Pause Enabled
indication (if PDN GW has chosen to enable the function), APN-AMBR, Delay Tolerant Connection) message
to the Serving GW. The PDN GW takes into account the received PDN type, the Dual Address Bearer Flag and
the policies of operator when the PDN GW selects the PDN type to be used as follows. If the received PDN type
is IPv4v6 and both IPv4 and IPv6 addressing are possible in the PDN but the Dual Address Bearer Flag is not
3GPP
Release 15 317 3GPP TS 23.401 V15.10.0 (2019-12)
set, or only single IP version addressing for this APN is possible in the PDN, the PDN GW selects a single IP
version (either IPv4 or IPv6). If the received PDN type is IPv4 or IPv6, the PDN GW uses the PDN type if it is
supported in the PDN, otherwise an appropriate error cause will be returned. The PDN GW allocates a PDN
Address according to the selected PDN Type If the PDN GW has selected a PDN type different from the
received PDN Type, the PDN GW indicates together with the PDN type IE a reason cause to the UE why the
PDN type has been modified, as described in clause 5.3.1.1. PDN Address may contain an IPv4 address for IPv4
and/or an IPv6 prefix and an Interface Identifier. If the PDN has been configured by the operator so that the PDN
addresses for the requested APN shall be allocated by usage of DHCPv4 only, or if the PDN GW allows the UE
to use DHCPv4 for address allocation according to the Address Allocation Preference received from the UE, the
PDN Address shall be set to 0.0.0.0, indicating that the IPv4 address shall be negotiated by the UE with after
completion of the Default Bearer Activation procedure. For external PDN addressing for IPv6, the PDN GW
obtains the IPv6 prefix from the external PDN using either RADIUS or Diameter client function. In the PDN
Address field of the Create Session Response, the PDN GW includes the Interface Identifier and IPv6 prefix.
The PDN GW sends Router Advertisement to the UE after default bearer establishment with the IPv6 prefix
information for all cases. If the PDN address is contained in the Create Session Request, the PDN GW shall
allocate the IPv4 address and/or IP6 prefix contained in the PDN address to the UE. If Handover Indication
indicates "Handover", the PDN Address Information shall contain the same IP address the UE obtained during
PDN connectivity establishment over the non-3GPP access. The PDN GW derives the BCM based on the NRSU
and operator policy. The PDN GW derives whether the extended TFT filter format is to be used based on the
ETFTU, ETFTN received from the PCRF and operator policy. Protocol Configuration Options contains the
BCM, ETFTN as well as optional PDN parameters that the P-GW may transfer to the UE. These optional PDN
parameters may be requested by the UE, or may be sent unsolicited by the P-GW. Protocol Configuration
Options are sent transparently through the MME.
If the PDN type is Non-IP, the PDN-GW uses the APN and IMSI to determine what local actions to perform
before answering the Serving GW.
The PDN GW includes a Delay Tolerant Connection indication if the PDN GW supports receiving a rejection
cause from the SGW indicating that the UE is temporarily not reachable due to power saving, and holding
mobile terminated procedures until the PDN GW receives a message indicating that the UE is available for end
to end signalling.
When the Handover Indication is present, the PDN GW does not yet send downlink packets to the S-GW; the
downlink path is to be switched at step 13a.
If the PDN GW is an L-GW, it does not forward downlink packets to the S-GW. The packets will only be
forwarded to the HeNB at step 10 via the direct user plane path for Local IP Access.
If the 3GPP PS Data Off UE Status was present in the Create Session Request PCO, and if the network supports
3GPP PS Data Off, the PDN GW shall include the 3GPP PS Data Off Support Indication in the Create Session
Response PCO.
6. The Serving GW returns a Create Session Response (PDN Type, PDN Address, Serving GW address for User
Plane, Serving GW TEID for User Plane, Serving GW TEID for control plane, EPS Bearer Id, EPS Bearer QoS,
PDN GW address and TEID (GTP-based S5/S8) or GRE key (PMIP-based S5/S8) at the PDN GW for uplink
traffic, Protocol Configuration Options, Prohibit Payload Compression, APN Restriction, Cause, MS Info
Change Reporting Action (Start), CSG Information Reporting Action (Start), Presence Reporting Area Action,
APN-AMBR, DTC) message to the MME. The DL TFT for PMIP-based S5/S8 is obtained from interaction
between the Serving GW and the PCRF as described in clause 5.6.1 of TS 23.402 [2], when PCC is deployed;
otherwise, the DL TFT IE is wildcarded, matching any downlink traffic. If the UE indicates the Request Type as
"Handover", this message also serves as an indication to the MME that the S5/S8 bearer setup and update has
been successful. At this step the GTP tunnel(s) over S5/S8 are established
If Control Plane CIoT EPS Optimisation applies, and if MME doesn't include Control Plane Only PDN
TEID for S11-U and additionally the Serving GW IP address and TEID for S1-U in the Create Session
Response.
- Otherwise if separation of S11-U from S1-U is not required, the Serving GW includes the Serving GW IP
3GPP
Release 15 318 3GPP TS 23.401 V15.10.0 (2019-12)
7. If an APN Restriction is received, then the MME shall store this value for the Bearer Context and the MME shall
check this received value with the stored value for the Maximum APN Restriction to ensure there are no
conflicts between values. If the consequence of this check results in the PDN connectivity being rejected, the
MME shall initiate a Bearer Deactivation and return an appropriate error cause. If the PDN Connectivity Request
is accepted, the MME shall determine a (new) value for the Maximum APN Restriction. If there is no previously
stored value for Maximum APN Restriction, then the Maximum APN Restriction shall be set to the value of the
received APN Restriction.
The P-GW shall ignore Maximum APN restriction if the request includes the Emergency APN.
For emergency service MME shall not deactivate bearer(s), if present, to maintain valid APN restriction
combination.
If the MS Info Change Reporting Action (Start) and/or the CSG Information Reporting Action (Start) are
received for this bearer context, then the MME shall store this for the bearer context and the MME shall report to
that P-GW via the S-GW whenever a UE's Location Information and/or User CSG Information change occurs
that meets the P-GW request, as described in clause 15.1.1a of TS 23.060 [7]. If Presence Reporting Area Action
is received for this bearer context, the MME shall store this information for the bearer context and shall report to
that P-GW via the S-GW whenever a change of UE presence in a Presence Reporting Area is detected, as
The MME may need to modify the UE AMBR, which has been assigned to the eNodeB, based on the subscribed
UE-AMBR and the updated set of APN-AMBRs in use. The principles to determine the UE-AMBR are
described in clause 4.7.3.
The MME sends PDN Connectivity Accept Session Management Request (APN, PDN Type, PDN Address, EPS
Bearer Id, Protocol Configuration Options, Header Compression Configuration, Control Plane Only Indicator)
message to the UE. If the PDN connection uses the user plane over the radio, this message is contained in an
S1_MME control message Bearer Setup Request (EPS Bearer QoS, UE-AMBR, PDN Connectivity Accept, S1-
TEID) to the eNodeB. However, if Control Plane CIoT EPS Optimisation applies to the PDN connection, an S1-
AP Downlink NAS transport message is used. The S1-AP Initial Context Setup Request message includes the
TEID at the Serving GW used for user plane and the address of the Serving GW for user plane. If the PDN type
is set to "Non-IP" the MME includes it in the S1-AP Initial Context Setup Request so that the eNodeB disables
header compression. In addition, if the PDN connection is established for Local IP Access, the corresponding S1
Initial Context Setup Request message includes a Correlation ID for enabling the direct user plane path between
the HeNB and the L-GW. If the PDN connection is established for SIPTO at the Local Network with L-GW
function collocated with the (H)eNB, the corresponding S1-AP Initial Context Setup Request includes a SIPTO
Correlation ID for enabling the direct user plane path between the (H)eNB and the L-GW. LIPA and SIPTO do
not apply to Control Plane CIoT EPS Optimisation.
NOTE 5: In this release of the 3GPP specification the Correlation ID and SIPTO Correlation ID is set equal to the
user plane PDN GW TEID (GTP-based S5) or GRE key (PMIP-based S5) that the MME has received in
step 6.
In the PDN Connectivity Accept message, the MME does not include the IPv6 prefix within the PDN Address.
The MME includes the APN-AMBR and the EPS Bearer QoS parameter QCI into the Session Management
Request. Furthermore, if the UE has UTRAN or GERAN capabilities and the network supports mobility to
UTRAN or GERAN, the MME uses the EPS bearer QoS parameters to derive the corresponding PDP context
parameters QoS Negotiated (R99 QoS profile), Radio Priority, Packet Flow Id and TI and includes them in the
Session Management Request. If the UE indicated in the UE Network Capability that it does not support BSS
packet flow procedures, then the MME shall not include the Packet Flow Id. MME will not send the S1 Bearer
Setup Request message until any outstanding S1 Bearer Setup Response message for the same UE has been
received or timed out. If the APN-AMBR has changed the MME may update the UE-AMBR if appropriate. The
MME may include an indication whether the traffic of this PDN Connection is allowed to be offloaded to
WLAN, as described in clause 4.3.23. If the UE has indicated PDN type "Non-IP", the MME and PDN GW shall
not change PDN type.
If the MME or PDN GW has changed the PDN Type, an appropriate reason cause shall be returned to the UE as
If Control Plane CIoT EPS Optimisation applies for an IP PDN connection, and the UE has sent in the PDN
Connectivity Request the Header Compression Configuration, the MME shall include the Header Compression
Configuration in the PDN Connectivity Accept message. The MME also binds the uplink and downlink ROHC
3GPP
Release 15 319 3GPP TS 23.401 V15.10.0 (2019-12)
channels to support header compression feedback signalling. If the UE has included ROHC context setup
parameters in Header Compression Configuration in the PDN Connectivity Request, the MME may
acknowledge ROHC context setup parameters. If the ROHC context is not established during the PDN
connection establishment procedure, before using the compressed format for sending the data, the UE and the
MME need to establish the ROHC context with ROHC IR packet based on Header Compression Configuration.
If the MME based on local policy determines the PDN connection shall only use the Control Plane CIoT EPS
Optimisation, the MME shall include a Control Plane Only Indicator in the Session Management Request. For
PDN connections with an SCEF, the MME shall always include the Control Plane Only Indicator. If there is an
existing SGi PDN connection for this UE for which the MME included a Control Plane Only Indicator, the
MME shall include it also for the additional SGi PDN connection. If the MME did not include a Control Plane
Only Indicator for any of the existing SGi PDN connections of this UE, the MME shall not include it for the
additional SGi PDN connection. A UE receiving the Control Plane Only Indicator, for a PDN connection shall
only use the Control Plane CIoT EPS Optimisation for this PDN connection.
NOTE 6: The MME decision whether to include a Control Plane Only Indicator to an SGi PDN connection for a
UE that previously had no SGi connections will impact other potential subsequent SGi PDN connections
for that UE.
8. If the eNodeB received an S1-AP Initial Context Setup Request, the eNodeB sends RRC Connection
Reconfiguration to the UE including the PDN Connectivity Accept message.
If the eNodeB received an S1-AP Downlink NAS Transport message containing the NAS PDN Connectivity
Accept message, the eNode B sends a RRC Direct Transfer message to the UE and the steps 9 and 10 are not
executed.
The UE shall store the QoS Negotiated, Radio Priority, Packet Flow Id and TI, which it received in the Session
Management Request IE, for use when accessing via GERAN or UTRAN. The UE may provide EPS Bearer
QoS parameters to the application handling the traffic flow. The application usage of the EPS Bearer QoS is
implementation dependent. The UE shall not reject the RRC Connection Reconfiguration on the basis of the EPS
Bearer QoS parameters contained in the Session Management Request.
If the UE receives an IPv4 address set to 0.0.0.0, it may negotiate the IPv4 address with DHCPv4 as specified in
TS 29.061 [38], If the UE receives an IPv6 interface identifier, it may wait for the Router Advertisement from
the network with the IPv6 prefix information or it may send a Router Solicitation if necessary.
NOTE 7: The IP address allocation details are described in clause 5.3.1 on "IP Address Allocation".
9. The UE sends the RRC Connection Reconfiguration Complete to the eNodeB.
10. The eNodeB send an S1-AP Bearer Setup Response to the MME. The S1-AP message includes the TEID of the
eNodeB and the address of the eNodeB used for downlink traffic on the S1_U reference point.
If the Correlation ID or SIPTO Correlation ID is included in the Bearer Setup Request, the eNodeB shall use the
included information to establish a direct user plane path to the L-GW and forward uplink data for Local IP
Access or SIPTO at the Local Network with L-GW function collocated with the (H)eNB accordingly.
11. The UE NAS layer builds a PDN Connectivity Complete message including EPS Bearer Identity. The UE then
sends a Direct Transfer (PDN Connectivity Complete) message to the eNodeB.
12. The eNodeB sends an Uplink NAS Transport (PDN Connectivity Complete) message to the MME.
After the PDN Connectivity Accept message and once the UE (if applicable to the PDN type) has obtained a
PDN Address Information, the UE can then send uplink packets towards the eNodeB which may then be
tunnelled by the MME to the Serving GW and PDN GW, or transferred by the MME to an SCEF (see
TS 23.682 [74]), as per subscription information related to APN discussed above in step 2. If the UE requested
for a dual address PDN type (IPv4v6) to a given APN and was granted a single address PDN type (IPv4 or IPv6)
by the network with a reason cause indicating that only single IP version per PDN connection is allowed, the UE
should request for the activation of a parallel PDN connection to the same APN with a single address PDN type
(IPv4 or IPv6) other than the one already activated. If the UE receives no reason cause in step 8 in response to a
IPv4v6 PDN type and it receives an IPv6 Interface Identifier apart from the IPv4 address or 0.0.0.0 in the PDN
Address field, it considers that the request for a dual address PDN was successful. It can wait for the Router
Advertisement from the network with the IPv6 prefix information or it may send Router Solicitation if necessary.
3GPP
Release 15 320 3GPP TS 23.401 V15.10.0 (2019-12)
13. Upon reception of the Bearer Setup Response message in step 10 and the PDN Connectivity Complete message
in step 12, the MME sends a Modify Bearer Request (EPS Bearer Identity, eNodeB address, eNodeB TEID,
Handover Indication, Presence Reporting Area Information) message to the Serving GW. If the Control Plane
CIoT EPS Optimisation applies and the PDN connection is not served via a SCEF type of connectivity, steps 13
and 14 are executed only if the MME needs to report a change of UE presence in Presence Reporting Area,
otherwise, if the PDN connection is served by SCEF, steps 13,14, 15, and 16 are not executed. If Request Type
indicates "handover", the Handover Indication is also included. If the MME has been requested to report a
change of UE presence in Presence Reporting Area, the MME includes in this message the Presence Reporting
Area Information comprising the PRA identifier(s) and indication(s) on whether the UE is inside or outside the
area(s). When receiving the request for reporting change of UE presence in Presence Reporting Area, and the
MME decides not to activate reporting UE presence in one or more of the received Presence Reporting Area(s),
the MME reports also the inactive Presence Reporting Area(s) in this message.
13a. If the Handover Indication is included in step 13, the Serving GW sends a Modify Bearer Request (Handover
Indication) message to the PDN GW to prompt the PDN GW to tunnel packets from non 3GPP IP access to
3GPP access system and immediately start routing packets to the Serving GW for the default and any dedicated
EPS bearers established. If Presence Reporting Area Information is included in step 13, the Serving GW sends a
Modify Bearer Request (Presence Reporting Area Information) message to the PDN GW.
NOTE 8: The PDN GW forwards the Presence Reporting Area Information to the PCRF, to the OCS or to both as
13b. The PDN GW acknowledges by sending Modify Bearer Response to the Serving GW.
14. The Serving GW acknowledges by sending Modify Bearer Response (EPS Bearer Identity) to the MME. The
Serving GW can then send its buffered downlink packets.
15. After the MME receives Modify Bearer Response in step 14, if Request type does not indicate handover and an
EPS bearer was established and if the subscription data indicates that the user is allowed to perform handover to
non-3GPP accesses and if this is the first PDN connection associated with this APN and if the MME selected a
PDN GW that is different from the PDN GW identity which was previously indicated by the HSS in the PDN
subscription context, the MME shall send a Notify Request including the PDN GW address and the APN to the
HSS for mobility with non-3GPP accesses. The message shall include information that identifies the PLMN in
which the PDN GW is located.
For an unauthenticated or roaming UE, if the Request Type of the UE requested connectivity procedure indicates
"Emergency", the MME shall not send any Notify Request to the HSS. For a non-roaming authenticated UE,
based on operator configuration (e.g. on whether Voice over WLAN is supported or not by the operator), if the
Request Type indicates "Emergency", the MME may send a Notify Request to the HSS including the "PDN GW
currently in use for emergency services", which comprises the PDN GW address and an indication that the PDN
connection is for emergency services. The HSS shall store it as part of the UE context for emergency services.
16. In the case of non-emergency services, the HSS stores the PDN GW identity and the associated APN. In the case
of emergency services, the HSS stores the "PDN GW currently in use for emergency services". Then the HSS
sends a Notify Response to the MME.
NOTE 9: For handover from non-3GPP access, the PDN GW initiates resource allocation deactivation procedure in
the trusted/untrusted non-3GPP IP access as specified in TS 23.402 [2].
5.10.3 UE or MME requested PDN disconnection

The UE or MME requested PDN disconnection procedure for an E-UTRAN is depicted in figure 5.10.3-1. The
procedure allows the UE to request for disconnection from one PDN. Bearers including the default bearer of this PDN
shall be deleted during this procedure. The procedure also allows the MME to initiate the release of a PDN connection.
This procedure is also used as part of the SIPTO function when the MME determines that GW relocation is desirable. In
this situation the MME deactivates the PDN connection(s) relevant to SIPTO-allowed APN(s) using the "reactivation
requested" cause value, and the UE should then re-establish those PDN connection(s).
NOTE 1: The deactivation with reactivation requested does not work with pre-Rel-9 LTE UEs.
It shall be possible to configure the MME to deactivate a PDN connection, for PDN GW relocation due to SIPTO above
RAN, only when UE is in ECM-IDLE mode or during a Tracking Area Update procedure without established RAB(s).
3GPP
Release 15 321 3GPP TS 23.401 V15.10.0 (2019-12)
This procedure is not used to terminate the last PDN connection unless "Attach without PDN Connectivity is supported"
in the Preferred Network behaviour indicated by the UE at attach time is supported by the network and the UE at any
time it requires the last PDN connection to be disconnected. The UE uses the UE-initiated Detach procedure in
clause 5.3.8.2 to disconnect the last PDN connection. The MME uses the MME-initiated Detach procedure in
clause 5.3.8.3 to release the last PDN connection.

1a. PDN Disconnection Request
1b PDN disconnection trigger

(A)
5. IP-CAN Session Termination
7. Deactivate Bearer Request

9a. RRC Connection Reconfiguration Complete
9b. Deactivate Bearer Response
10a. Direct Transfer

10b. Deactivate EPS Bearer Context Accept
Figure 5.10.3-1: UE or MME requested PDN disconnection
based S5/S8.
NOTE 3: If after step 6, the MME determines that PDN being disconnected has no active bearers in the E-UTRAN,
(e.g. because data is transported using Control Plane CIoT EPS Optimisation) steps 7, 8. 10a and 10b are
modified to only transfer the indicated ESM signalling messages and steps 9a and 9b are skipped.
1. The procedure is triggered by either step 1a or step 1b.
1a. The UE initiates the UE requested PDN disconnection procedure by the transmission of a PDN
Disconnection Request (LBI) message. The LBI indicates the default bearer associated with the PDN
connection being disconnected. If the UE was in ECM-IDLE mode, this NAS message is preceded by the
Service Request procedure if any of the exiting PDN connections were using the User Plane without CIoT
EPS Optimisation, or, if the user plane was used just with User Plane CIoT EPS Optimisations, a Resume
Procedure is executed instead.
1b. The MME decides to release the PDN connection. This may be e.g. due to change of subscription, lack of
resources, due to SIPTO in case the PDN connection serves a SIPTO-allowed APN or on receiving a PDN
GW Restart Notification from the Serving GW as specified in TS 23.007 [72]. If the UE is in ECM-IDLE
state and the reason for releasing PDN connection is "reactivation requested" e.g. due to SIPTO, the MME
initiates paging via Network Triggered Service Request procedure in clause 5.3.4.3 from step 3a onwards in
order to inform UE of the request.
2. If the PLMN has configured secondary RAT usage reporting, the MME shall perform step 7 through 10 before
step 2 onwards. If the PDN connection was served by a P-GW, the EPS Bearers in the Serving GW for the
particular PDN connection are deactivated by the MME by sending Delete Session Request (Cause, LBI, User
Location Information (ECGI), Secondary RAT usage data) to the Serving GW. This message indicates that all
bearers belonging to that PDN connection shall be released. If the UE Time Zone has changed, the MME
3GPP
Release 15 322 3GPP TS 23.401 V15.10.0 (2019-12)
includes the UE Time Zone IE in this message. For PDN connection to the SCEF the MME indicates to the
SCEF the connection for the UE is no longer available according to TS 23.682 [74] and steps 2,3,4,5,6 are not
executed. If the MME received Secondary RAT usage data in step 9b, the MME shall include it in this Delete
Session Request message.
3. The Serving GW sends Delete Session Request (Cause, LBI, User Location Information (ECGI), Secondary
RAT usage data) to the PDN GW. The S-GW also includes User Location Information IE and/or UE Time Zone
IE if it is present in step 2. The Serving GW also includes the Secondary RAT usage data in this message if it
was present in step 2 and if PDN GW secondary RAT usage data reporting is active.
4. The PDN GW acknowledges with Delete Session Response (optionally, APN Rate Control Status).
5. The PDN GW employs the PCEF-initiated IP-CAN Session Termination procedure as defined in TS 23.203 [6]
to indicate to the PCRF that the IP-CAN session is released if PCRF is applied in the network. If requested the
TS 23.203 [6].
6. The Serving GW acknowledges with Delete Session Response (optionally, APN Rate Control Status).
7. If the UE is in ECM IDLE state and the PDN disconnection is decided by the MME, the MME shall delete the
corresponding contexts of the PDN connection locally, steps 7 to 10b are skipped except if the MME has decided
to restore certain PDN connections as specified in TS 23.007 [72] or for other reasons e.g. SIPTO. The MME
initiates the deactivation of all Radio Bearers associated with the PDN connection to the eNodeB by sending the
Deactivate Bearer Request message to the eNodeB. The MME shall re-calculate the UE-AMBR (see
clause 4.7.3). This S1-AP message carries the list of EPS bearers to be released, the new UE-AMBR, and a NAS
Deactivate EPS Bearer Context Request (LBI) message. The MME builds a NAS message Deactivate EPS
Bearer Context Request including the EPS Bearer Identity, and includes it in the S1-AP Deactivate Bearer
Request message.
If the network wants to trigger GW relocation (e.g. for SIPTO), the NAS message Deactivate EPS Bearer
Context Request includes the request for reactivation of the same PDN connection via the same APN by the UE.
If the MME released the PDN connection due to failed bearer set up during handover, the UE and the MME
deactivate the failed contexts locally without peer-to peer ESM signalling.
NOTE 4: If the UE is in ECM-IDLE state and the PDN disconnection is decided by the MME, the EPS bearer state
is synchronized between the UE and the network at the next ECM-IDLE to ECM-CONNECTED
transition (e.g. Service Request or TAU procedure).
8. The eNodeB sends the RRC Connection Reconfiguration message including the corresponding bearers to be
released and the NAS Deactivate EPS Bearer Context Request (LBI) message to the UE.
9a. The UE releases all resources corresponding to the PDN connection and acknowledges this by sending the RRC
Connection Reconfiguration Complete message to the eNodeB.
9b. The eNodeB sends an acknowledgement of the deactivation to the MME. If the PLMN has configured secondary
RAT usage reporting and the eNodeB has Secondary RAT usage data to report, the Secondary RAT usage data is
included.
10a. The UE NAS layer builds a Deactivate EPS Bearer Context Accept message. The UE then sends a Direct
Transfer (Deactivate EPS Bearer Context Accept) message to the eNodeB.
If the Deactivate EPS Bearer Context Request message from the MME indicated reactivation requested, the UE
starts the UE initiated PDN connection request procedure as specified in clause 5.10.2 by using the same APN of
the released PDN connection.
10b. The eNodeB sends an Uplink NAS Transport (Deactivate EPS Bearer Context Accept) message to the MME.
The MME determines the Maximum APN Restriction for the remaining PDN connections and stores this new value for
the Maximum APN Restriction.
3GPP
Release 15 323 3GPP TS 23.401 V15.10.0 (2019-12)
5.10.4 MME triggered Serving GW relocation

The MME triggered Serving GW relocation procedure for E-UTRAN is depicted in figure 5.10.4-1. The procedure
allows the MME to trigger Serving GW relocation due to events other than those described in the mobility scenarios
(see clause 5.3.3.1 and clause 5.5.1). Such scenario exists during the establishment of a SIPTO at local network PDN
connection with stand-alone GW or during the establishment of a SIPTO above RAN PDN connection.
UE eNodeB MME Old New PDN GW

Serving GW Serving GW
1. MME determines
the Serving GW
relocation needs to
be performed
Uplink/down link data before S-GW relocation

Down link data
5. Bearer Modify Request/Response
Uplink link data

6a. Delete Session Request
Figure 5.10.4-1: MME triggered Serving GW relocation
1. The Serving GW relocation procedure may be triggered by the MME due to events that may benefit from a
Serving GW relocation other than those described in the mobility events scenarios.
2. If the MME determines that the Serving GW is to be relocated then it selects a new Serving GW according to
clause 4.3.8.2. The MME sends a Create Session Request (bearer context(s) with PDN GW addresses and TEIDs
(for GTP-based S5/S8) or GRE keys (for PMIP-based S5/S8) at the PDN GW(s) for uplink traffic, eNodeB
address(es) and TEIDs for downlink user plane for the existing EPS bearers, the Protocol Type over S5/S8,
Serving Network) message per PDN connection to the new Serving GW. The new Serving GW allocates the
S-GW addresses and TEIDs for the uplink traffic on S1_U reference point (one TEID per bearer). The Protocol
Type over S5/S8 is provided to Serving GW which protocol should be used over S5/S8 interface. If the PDN
GW requested UE's location info, the MME also includes the User Location Information IE in this message. If
the PDN GW requested UE's User CSG information (determined from the UE context), the MME includes the
User CSG Information IE in this message if the User CSG Information has changed.
3. The new Serving GW assigns addresses and TEIDs (one per bearer) for downlink traffic from the PDN GW. The
Serving GW allocates DL TEIDs on S5/S8. It sends a Modify Bearer Request (Serving GW addresses for user
plane and TEID(s), Serving Network) message per PDN connection to the PDN GW(s). The S-GW also includes
User Location Information IE and/or UE Time Zone IE and/or User CSG Information IE if it is present in step 2.
The PDN GW updates its context field and returns a Modify Bearer Response (Charging Id, MSISDN, etc.)
message to the Serving GW. The MSISDN is included if the PDN GW has it stored in its UE context. The PDN
GW starts sending downlink packets to the new GW using the newly received address and TEIDs. These
downlink packets will use the new downlink path via the new Serving GW to the eNodeB. This step is
performed for all connected PDN-GWs for that specific UE.
4. The new Serving GW sends a Create Session Response (Serving GW addresses and uplink TEID(s) for user
plane) message back to the MME. The MME starts a timer, to be used in step 6.
3GPP
Release 15 324 3GPP TS 23.401 V15.10.0 (2019-12)
5. The MME sends a Bearer Modify Request (Serving GW addresses and uplink TEID(s) for user plane, Secondary
RAT usage data request) message to eNodeB. The eNodeB starts using the new Serving GW address(es) and
TEID(s) for forwarding subsequent uplink packets and sends a Bearer Modify Response message to the MME. If
the PLMN has configured secondary RAT usage reporting, the MME may request the eNodeB for Secondary
RAT usage data in the Bearer Modify request message. If the eNodeB has Secondary RAT usage data, it
provides it in the Bearer Modify Response message.
5a. If Secondary RAT usage data is included in the previous message and if PDN GW Secondary RAT usage
reporting is active, the MME uses the Secondary RAT usage data reporting procedure as described in
clause 5.7A.3 figure 5.7A.3-2 to provide this information to the Serving GW and PDN GW. The MME includes
a flag that the Serving GW shall not process this information and forward it to the PDN GW.
6. When the timer has expired after step 4, the MME releases the bearer(s) in the old Serving GW by sending a
Delete Session Request message (Cause, Operation Indication, Secondary RAT usage data). The operation
Indication flag is not set, that indicates to the old Serving GW that the old Serving GW shall not initiate a delete
procedure towards the PDN GW. The old Serving GW acknowledges with Delete Session Response messages.
The MME includes the Secondary RAT usage data if the eNodeB had provided it to the MME in step 5.
If the Serving GW relocation procedure towards a new Serving GW fails, based on operator policy, the MME should go
back to the old Serving GW and disconnects the affected PDN connections (e.g. SIPTO at local network) that are no
longer allowed to remain connected.
5.11 UE Capability Handling

5.11.1 General
The UE Capability information is made up of the UE Radio Capability information and the UE Core Network
Capability information.
The UE Radio Capability for Paging Information is separate from both the UE Radio Capability information and the UE
Core Network Capability information. While some of t the UE Radio Capability for Paging Information may be used to
enhance the paging in the E-UTRAN, other E-UTRAN features are critically dependent upon it (see TS 36.300 [5]).
5.11.2 UE Radio Capability Handling

The UE Radio Capability information contains information on RATs that the UE supports (e.g. power class, frequency
bands, etc). Consequently, this information can be sufficiently large (e.g. >50 octets for a UE supporting a small number
of frequency bands; or multiple kilo bytes for a UE supporting many frequency bands and a large multiplicity of
combinations of these frequency bands) that it is undesirable to send it across the radio interface at every transition from
ECM-IDLE to ECM-CONNECTED. To avoid this radio overhead, the MME stores the UE Capability information
during ECM-IDLE state and the MME shall, if it is available, send its most up-to-date UE Radio Capability information
to the E-UTRAN in the S1 interface INITIAL CONTEXT SETUP REQUEST message unless the UE is performing an
Attach procedure or a Tracking Area Update procedure for the "first TAU following GERAN/UTRAN Attach" or for a
"UE radio capability update".
NOTE 1: The UTRAN Radio Capabilities are excluded from the information stored in the MME owing to issues
with the handling of dynamic UMTS security parameters.
If a UE supports both NB-IoT and WB-E-UTRAN, the UE handles the UE Radio capability information as follows:
- When the UE is camping on NB-IoT the UE provides only NB-IoT UE radio capabilities to the network.
- When the UE is camping on WB-E-UTRAN, the UE provides UE radio capabilities including WB-E-UTRAN
UE radio capabilities but not NB-IoT UE radio capabilities to the network.
In order to handle the distinct UE radio capabilities, the MME stores a separate NB-IoT specific UE Radio Capability
information when the UE provides the UE Radio Capability information while camping on NB-IoT.
When the UE is camping on NB-IoT, the MME sends, if available, the NB-IoT specific UE Radio Capability
information to the E-UTRAN.
3GPP
Release 15 325 3GPP TS 23.401 V15.10.0 (2019-12)
When the UE is camping on WB-E-UTRAN, the MME sends, if available, UE radio capabilities including WB-E-
UTRAN UE radio capabilities but not NB-IoT radio capabilities.
For a UE that supports NR as a Secondary RAT, the UE's NR radio capabilities are contained within the UE Radio
Capability IE.
If the UE is performing an Attach procedure or a Tracking Area Update procedure for the "first TAU following
GERAN/UTRAN Attach" or for "UE radio capability update", the MME shall delete (or mark as deleted) any UE Radio
Capability information that it has stored, and, if the MME sends an S1 interface INITIAL CONTEXT SETUP
REQUEST or UE RADIO CAPABILITY MATCH REQUEST message during that procedure, the MME shall not send
any UE Radio Capability information to the E-UTRAN in that message. This triggers the E-UTRAN to request the UE
Radio Capability from the UE and to upload it to the MME in the S1 interface UE CAPABILITY INFO INDICATION
message. The size of the UE Radio Capability information may be greater than can be carried in single RRC message
but less than the maximum size of messages on the S1 interface. In this case, to obtain the information that it needs the
RAN should send multiple requests to the UE for different sub-sets of UE Radio Capability information (e.g. one
request per RAT). Then the RAN shall combine these subsets (excluding UTRAN and NB-IoT capabilities) into a
single UE Radio Capability IE and upload it to the MME in the S1 interface UE CAPABILITY INFO INDICATION
message.
The MME stores the UE Radio Capability information, and include it in further INITIAL CONTEXT SETUP
REQUEST or UE RADIO CAPABILITY MATCH REQUEST messages in other cases than Attach procedure,
Tracking Area Update procedure for the "first TAU following GERAN/UTRAN Attach" and "UE radio capability
update" procedure.
If the UE is performing a Service Request (or other) procedure and the MME does not have UE Radio Capability
information available (or it is available, but marked as "deleted"), then the MME sends an S1 interface INITIAL
CONTEXT SETUP REQUEST message to the E-UTRAN without any UE Radio Capability information in it. This
triggers the E-UTRAN to request the UE Radio Capability from the UE and upload it to the MME in the S1 interface
UE CAPABILITY INFO INDICATION message.
NOTE 2: This use of the INITIAL CONTEXT SETUP REQUEST message means that for a signalling only
procedure such as a periodic Tracking Area Update, the UE Radio Capability would not be sent to the
E-UTRAN.
NOTE 3: If a "first TAU following GERAN/UTRAN Attach" Tracking Area Update is performed during ECM-
CONNECTED mode, e.g. after an inter RAT handover, no INITIAL CONTEXT SETUP REQUEST is
sent and the UE Radio Capability information in the MME will remain deleted until the next ECM-IDLE
to ECM-CONNECTED transition (or later, e.g. if the next activity from the UE is another Tracking Area
Update).
When the CIoT EPS Optimisations do not apply, if the MME has not stored the UE Radio Capability information, in
order to obtain UE radio capability for paging information, the MME can trigger the retrieval of the UE Radio
Capability information by indicating UE Radio Capability request in DOWNLINK NAS TRANSPORT message during
Attach or TAU procedure.
For the CIoT EPS Optimisations, during the Attach procedure or the Tracking Area Update procedure, e.g. for the "first
TAU following GERAN/UTRAN Attach", if the MME does not send an S1 interface INITIAL CONTEXT SETUP
REQUEST to the E-UTRAN, the MME should obtain the UE Radio Capability information by sending either the
DOWNLINK NAS TRANSPORT message indicating UE Radio Capability request or the CONNECTION
ESTABLISHMENT INDICATION message without UE Radio Capability information included to the E-UTRAN. This
triggers the E-UTRAN to request the UE Radio Capability from the UE and upload it to the MME in the S1 interface
UE CAPABILITY INFO INDICATION message, as specified in TS 36.300 [5]. In subsequent ECM connections, if the
MME does not send an S1 interface INITIAL CONTEXT SETUP REQUEST to the E-UTRAN, the MME sends the
UE Radio Capability to the E-UTRAN in the CONNECTION ESTABLISHMENT INDICATION message or
DOWNLINK NAS TRANSPORT message.
The UE Radio Capability is not provided directly from one CN node to another. It will be uploaded to the MME when
the E-UTRAN requests the UE Radio Capability information from the UE.
During handover via the MME (both intra RAT and inter RAT), the radio capability information for the source and
target 3GPP RATs (with the possible exception of UTRAN and E-UTRAN) are transferred in the "source to target
transparent container". Information on additional 3GPP RATs is optionally transferred in the "source to target
transparent container".
3GPP
Release 15 326 3GPP TS 23.401 V15.10.0 (2019-12)
At handover, transfer of the radio capability information related to the source and/or additional RATs is beneficial as it
avoids the need for the target RAT to retrieve the information from the UE prior to a subsequent inter-RAT handover.
However, there may be situations where the size of the UE Radio Capability may be too large for the information on all
of the UE's RATs to be carried in a single message on one or more of the network interfaces involved in the handover.
Hence, the source RAN shall ensure that the size of the UE Radio Capability information does not cause the size of the
"source to target transparent container" to exceed the limits that can be handled by interfaces involved in the handover
(e.g. Iu interface (TS 25.413 [22]) and, following SRVCC, E interface (TS 29.002 [86])). This may result in some radio
capability information being omitted from the "source to target transparent container" at inter-RAT handover. In this
situation, the UE might be subject to an inter-RAT handover to E-UTRAN via the MME which has the context stored
for that UE, and, the MME may detect that the "source to target transparent container" is smaller than the UE Radio
Capability stored in that UE's context. The MME may then add the full UE Radio Capability as a standalone
Information Element in the S1-AP Handover Request message. As an implementation option, the eNB may use this
MME supplied information to avoid retrieving any missing UE Radio Capability Information from the UE.
In the case that a source RAN node omits some radio capability information from the "source to target transparent
container" at handover, the source RAN node shall ensure that any future target RAN node can detect that that radio
capability information has been omitted.
Owing to issues with dynamic UTRAN security parameters, special rules apply to the handling of the UTRAN radio
capability information at inter-RAT handover (see e.g. the HandoverPreparationInformation message description in
TS 36.331 [37] and the usage of the PS Handover Complete Ack message in TS 43.129 [8] and TS 48.018 [42])
To allow for the addition of future radio technologies, frequency bands, and other enhancements, the MME shall store
the UE Radio Capability Information as defined in TS 23.008 [28].
The E-UTRAN stores the UE Radio Capability information, received in the S1 interface INITIAL CONTEXT SETUP
REQUEST message or obtained from the UE, for the duration of the RRC connection for that UE. Before any handover
attempt from E-UTRAN to UTRAN, the E-UTRAN retrieves the UE's UTRAN Radio Capabilities from the UE.
If the UE's non-UTRAN UE Radio Capability information changes while in ECM-IDLE state (including cases of being
in GERAN/UTRAN coverage), the UE shall perform a Tracking Area Update indicating "UE radio capability update"
when it next returns to E-UTRAN coverage. When the UE is in ECM-IDLE with AS information stored (as defined in
clause 4.11 for User Plane CIOT EPS optimisation), NAS shall trigger AS to establish a new RRC connection and not
resume the existing one in order to send Tracking Area Update indicating "UE radio capability update". As a result of
this, the access stratum in the UE will discard the AS information and establish a new RRC connection as defined in
TS 36.331 [37].
The MME may also request for Voice Support Match Information. If requested, the eNB then derives and provides an
indication to the MME whether the UE radio capabilities are compatible with the network configuration (e.g. whether
the UE supports the frequency bands that the network may rely upon for providing "full" PS voice coverage or whether
the UE supports the SRVCC configuration of the network e.g. E-UTRAN to GERAN) as defined in clause 5.3.14.
5.11.3 UE Core Network Capability

The UE Core Network Capability is split into the UE Network Capability IE (mostly for E-UTRAN access related core
network parameters) and the MS Network Capability IE (mostly for UTRAN/GERAN access related core network
parameters) and contains non radio-related capabilities, e.g. the NAS security algorithms etc. Both the UE Network
Capability and the MS Network Capability are transferred between CN nodes at MME to MME, MME to SGSN, SGSN
to SGSN, and SGSN to MME changes.
In order to ensure that the UE Core Network Capability information stored in the MME is up to date (e.g. to handle the
situation when the USIM is moved into a different device while out of coverage, and the old device did not send the
Detach message; and the cases of inter-RAT Tracking Area Update), the UE shall send the UE Core Network
Capability information to the MME during the Attach and non-periodic Tracking Area Update procedure within the
NAS message.
The MME shall store always the latest UE Core Network Capability received from the UE. Any UE Core Network
Capability that an MME receives from an old MME/SGSN is replaced when the UE provides the UE Core Network
Capability with Attach and the Tracking Area Update signalling. The MME shall remove the stored MS Network
Capability, if MS Network Capability is not included in Attach or non-periodic Tracking Area Update signaling e.g. UE
is only capable of E-UTRAN.
3GPP
Release 15 327 3GPP TS 23.401 V15.10.0 (2019-12)
If the UE's UE Core Network Capability information changes (in either ECM-CONNECTED or in ECM-IDLE state
(including cases of being in GERAN/UTRAN coverage and having ISR activated)), the UE shall perform a Tracking
Area Update ('type' different to 'periodic') when it next returns to E-UTRAN coverage - see clause 5.3.3.0.
If the UE supports multiple user plane radio bearers on the NB-IoT RAT (see TS 36.306 [82], TS 36.331 [37]), then the
UE shall indicate this in the UE Network Capability IE.
If the UE supports dual connectivity with NR (see clause 4.3.2a), then the UE shall indicate its support in a NAS
indicator.
If the UE supports Service Gap Control (see clause 4.3.17.9), then the UE shall indicate this in the UE Network
Capability IE.
To allow for the addition of future features, the MME shall store the UE Network Capability and the MS Network
Capability even if either or both is larger than specified in TS 24.008 [47]/TS 24.301 [46], up to a maximum size of
32 octets for each IE.
5.11.4 UE Radio Capability for Paging Information

Depending upon the features implemented in the E-UTRAN, this procedure may assist the E-UTRAN in optimising the
radio paging procedures, or this procedure can be essential for mobile terminating services to succeed.
Using procedures specified in TS 36.413 [36] , the eNB shall upload the UE Radio Capability for Paging Information to
the MME in the S1 interface UE CAPABILITY INFO INDICATION message (in a separate IE from the UE Radio
Capability). As specified in TS 36.331 [37], the UE Radio Capability for Paging Information may contain UE Radio
Paging Information provided by the UE to the eNB, and other information derived by the eNB (e.g. band support
information) from the UE Radio Capability information.
The UE Radio Capability for Paging Information for NB-IoT and WB-E-UTRAN are separately stored in the MME.
The RAT Type (derived from the UE's Tracking Area Code) is used to determine which RAT the information relates to.
If a UE supports both NB-IoT and WB-E-UTRAN, the UE and eNB handle the UE Radio Capability for Paging
Information as follows:
- when the UE is camping on NB-IoT the UE provides only NB-IoT information to the network;
- when the UE is camping on WB-E-UTRAN, the UE provides only WB-E-UTRAN information to the network.
Typically this information is sent to the MME at the same time as the eNB uploads the UE Radio Capability
information. The MME stores the UE Radio Capability for Paging Information in the MME context. When it needs to
page, the MME provides the UE Radio Capability for Paging Information for that RAT to the eNB as part of the S1
paging message. The eNB may use the UE Radio Capability for Paging Information to enhance the paging towards the
UE and/or to calculate when or how to broadcast paging information or the Wake Up Signal to the UE, see
TS 36.304 [34].
If the UE is performing an Attach procedure or a Tracking Area Update procedure for the "first TAU following
GERAN/UTRAN/ Attach" or for "UE radio capability update", the MME shall delete all UE Radio Capability for
Paging Information that it has stored for that UE.
If the UE Radio Capability for Paging Information changes for either RAT, the UE shall follow the same procedures as
if the UE Radio Capability changes.
In order to handle the situations of connected mode inter-MME change, the UE Radio Capability for Paging
Information is sent to the target MME as part of the MM Context information. The UE Radio Capability for Paging
Information is only applicable for MMEs, i.e. it is not applicable for SGSNs. Therefore, it will not be included by MME
during context transfers towards SGSNs.
5.11.5 UE Radio Capability for Category M Differentiation

This functionality is used by the Core Network to be able to identify traffic to/from Category M UEs for charging
differentiation.
The eNB determines whether a UE is of Category M from the UE's radio capability if UE signals one or more of the
specific Category M. The eNB then indicates to the MME whether the UE is Category M in the "UE Radio Capability
3GPP
Release 15 328 3GPP TS 23.401 V15.10.0 (2019-12)
for Category M Differentiation" information in S1-AP message(s) used to upload the UE Radio Capabilities to the
MME.
Typically this is at the same time as the eNB uploads the UE Radio Capability information. The MME stores the "LTE-
M Indication" in the MME context.
If the UE context in MME contains the "LTE-M Indication" the MME indicates to the S-GW that the RAT type of the
UE is LTE-M in every Create Session Request message and every Modify Bearer Request message, so this is handled
for charging and PCC purposes. If the MME requests the SGW to pass LTE-M RAT type to the PDN GW, based on
operator policy (e.g. based on roaming agreements or based on the need to pass the LTE-M RAT type information to
PGW also), the MME informs the Serving GW that it is requested to relay the LTE-M RAT type to the PGW also.
Otherwise, the Serving GW indicates WB-E-UTRAN RAT type to the PDN GW.
In order to handle the situations of inter-MME change, the LTE-M Indication is sent from the source MME to the target
MME as part of the MM Context information. The UE Radio Capability for Category M Differentiation is only
applicable for MMEs, i.e. it is not applicable for SGSNs. Therefore, it will not be included during context transfers from
and towards SGSNs.
5.12 Warning message delivery

5.12.1 General
Warning message delivery is similar to Cell Broadcast Service defined in TS 23.041 [48], it permits a number of
unacknowledged Warning messages to be broadcast to UEs within a particular area.
The maximum size of the Warning message for E-UTRAN is different from that of UTRAN/GERAN.
When S1-flex is used, the eNodeB may receive duplicated Warning messages.
For details on the Warning system message delivery, see TS 23.041 [48].
5.12.2 Void
5.12.3 Void
5.13 Discontinuous Reception and UE Specific DRX Parameter

handling
During the Attach procedure in E-UTRAN, UTRAN and/or GERAN, the UE can signal its UE Specific DRX
Parameters to the Core Network (MME in the E-UTRAN case and SGSN in UTRAN/GERAN case).
In E-UTRAN and UTRAN, the UE may signal that it wishes to use the DRX cycle length broadcast in the RAN's
System Information. Alternatively, the UE can propose a DRX cycle length for use when not camped on an NB-IoT
cell. The MME shall accept the value proposed by the UE.
In each S1 interface Page Request message, the MME shall send the E-UTRAN relevant information from the UE
Specific DRX Parameters (to help determine the DRX cycle length) and information derived from the IMSI (which
defines when the UE will be awake from its sleep mode). Details are specified in TS 36.304 [34]. The UE Specific
DRX parameter is not used by the E-UTRAN for paging from NB-IoT cells (see TS 36.304 [34]).
NOTE 1: To ease backward compatibility with Pre-Release 8 SGSNs, the UTRAN and E-UTRAN DRX cycle
lengths are encoded in the same field within the TS 24.008 [47] DRX parameter information element.
3GPP
Release 15 329 3GPP TS 23.401 V15.10.0 (2019-12)
At MME to MME, MME to SGSN and SGSN to MME mobility, the UE Specific DRX Parameters are sent from the
old CN node to the new CN node as part of the MM context information and should not be sent by the UE in the
Tracking Area Update message.
NOTE 2: it is assumed that all SGSNs are Release 99 or newer and hence support storage of the Release '99
encoding of the TS 24.008 [47] DRX parameter information element.
During Attach and Tracking Area Update procedures performed on NB-IoT cells, the normal EPS procedures apply,
e.g. the UE can (but need not) provide a UE Specific DRX parameter that applies on WB-E-UTRAN cells.
If a CN node receives UE Specific DRX Parameters in a dedicated message from the UE (e.g. in a Tracking Area
Update or Attach message), then the CN node updates any stored information with the information supplied by the UE
and uses the UE provided information in preference to any information that might be received from another CN node
during the same procedure.
If the UE wishes to alter its GERAN or UTRAN/E-UTRAN UE Specific DRX Parameters while in E-UTRAN, then it
shall send a Tracking Area Update Request message to the MME containing its new UE Specific DRX Parameters. If
ISR had been activated for the UE, then the UE shall deactivate ISR by setting its TIN to "GUTI" so that the UE
performs a Routing Area Update when it next enters GERAN/UTRAN coverage. When the UE performs that Routing
Area Update, the SGSN will receive the updated DRX parameters within the MM context information sent by the MME
and hence the UE should not include them again in the Routing Area Update Request message.
If the UE wishes to alter its E-UTRAN/UTRAN or GERAN DRX Parameters while in GERAN or UTRAN coverage,
then the UE shall send a Routing Area Update Request message to the SGSN containing its new UE DRX Parameters.
If ISR has been activated, the UE shall deactivate ISR by setting its TIN to "P-TMSI" so that the UE performs a
Tracking Area Update when it next returns to E-UTRAN coverage. When the UE performs that Tracking Area Update,
the MME will receive the updated DRX parameters within the MM context information sent by the SGSN and hence
the UE should not include them again in the Tracking Area Update message.
5.13a Extended Idle mode Discontinuous Reception (DRX)

The extended idle mode DRX value range is described in TS 23.682 [74].
A UE and the core network may negotiate the use of extended idle mode DRX as described in TS 23.682 [74]. The
MME includes the extended idle mode DRX cycle length in paging message to assist the eNodeB in paging the UE
For extended idle mode DRX cycle length of 5.12s, the network should follow regular paging strategy as defined in
clause 5.13
For extended idle mode DRX cycle length of 10.24s or longer, the following applies:
If the UE decides to request for extended idle mode DRX, the UE includes an extended idle mode DRX
parameters information element in the attach request and/or TAU request message. The UE may also include the
UE specific DRX parameters for regular idle mode DRX according to clause 5.13. The extended idle mode DRX
parameters information element includes the idle mode DRX length.
The MME decides whether to accept or reject the UE request for enabling extended idle mode DRX as described
in TS 23.682 [74]. In case the MME accepts the extended idle mode DRX, the MME based on operator policies
and, if available, the extended idle mode DRX cycle length value in the subscription data from the HSS, may
also provide different values of the extended idle mode DRX parameters than what was requested by the UE.
The MME taking into account the RAT specific Subscribed Paging Time Window, the UEs current RAT (NB-
IOT or WB-E-UTRAN) and local policy also assigns a Paging Time Window length to be used, and provides
this value to the UE during Attach/TAU procedures together with the extended idle mode DRX cycle length in
extended idle mode DRX parameter. If the MME accepts the use of extended idle mode DRX, the UE shall
apply extended idle mode DRX based on the received extended idle mode DRX length, the UEs current RAT
(NB-IOT or WB-E-UTRAN) and RAT specific Paging Time Window length. If the UE does not receive the
extended idle mode DRX parameters information element in the relevant accept message because the
SGSN/MME rejected its request or because the request was received by SGSN/MME not supporting extended
idle mode DRX, the UE shall apply its regular discontinuous reception as defined in clause 5.13.
3GPP
Release 15 330 3GPP TS 23.401 V15.10.0 (2019-12)
NOTE: The extended idle mode DRX cycle length requested by UE takes into account requirements of
applications running on the UE. Subscription based determination of eDRX cycle length can be used in
those rare scenarios when applications on UE cannot be modified to request appropriate extended idle
mode DRX cycle length. The network accepting extended DRX while providing an extended idle mode
DRX cycle length value longer than the one requested by the UE, can adversely impact reachability
requirements of applications running on the UE.
When the UE has bearers for emergency bearer services, the UE and MME follow regular discontinuous
reception as defined in clause 5.13 and shall not use the extended idle mode DRX. Extended idle mode DRX
parameters may be negotiated while the UE has bearers for emergency bearer services.When the bearers for
emergency bearer services are released, the UE and MME shall reuse the negotiated extended idle mode DRX
parameters in the last TAU/Attach procedure.
The UE shall include the extended idle mode DRX parameters information element in each TAU message if it
still wants to use extended idle mode DRX. At MME to MME, MME to SGSN and SGSN to MME mobility, the
extended idle mode DRX parameters are not sent from the old CN node to the new CN node as part of the MM
context information.
If extended idle mode DRX is enabled, the MME handles paging as defined in TS 23.682 [74].
If the MME is requested to monitor Reachability for Data and the UE is about to become reachable for paging, the
MME sends a Monitoring Report message to the address that was indicated in the related Monitoring Request as
5.14 Configuration Transfer procedure

The purpose of the Configuration Transfer is to enable the transfer of information between two eNodeBs at any time via
S1 interface and the Core Network. An example of application is to exchange the eNodeBs IP addresses in order to be
able to use X2 interface between the eNodeBs for Self-Optimised Networks (SON), as specified in TS 36.413 [36].
5.14.1 Architecture Principles for Configuration Transfer

Configuration Transfer between two eNodeBs follows the principles used by RAN Information Management (RIM)
procedures (see clause 5.15) between UTRAN, E-UTRAN and GERAN i.e. providing a generic mechanism for the
exchange of arbitrary information between applications belonging to the RAN nodes. However Configuration Transfer
is only used for intra-E-UTRAN information exchange whereas RIM procedures are designed for inter-RAT
information exchange involving GERAN/UTRAN. Such a separate procedure allows avoiding impacts to other RAT
access systems when transferred information is added or modified.
The information is transferred via the MME core network node(s). In order to make the information transparent for the
Core Network, the information is included in an E-UTRAN transparent container that includes source and target
eNodeB addresses, which allows the Core Network nodes to route the messages. If the information is to be transferred
between a source eNodeB and a target en-gNB via a target eNodeB for Dual Connectivity with E-UTRAN as Master
RAN node and NR as Secondary RAN node as defined in TS 37.340 [85], the source eNodeB indicates the target en-
gNB and may indicate the connected target eNodeB as described in TS 36.300 [5], and the target eNodeB further
transfers the E-UTRAN transparent container to the en-gNB transparently. The mechanism is depicted in figure 5.14 1.
An example for such transferred information is the SON information, as specified in TS 36.413 [36].
3GPP
Release 15 331 3GPP TS 23.401 V15.10.0 (2019-12)
Configuration Transfer
Signaling
eNodeB MME
S1
Relaying
Configuration
Transfer S10
Signaling
S1
eNodeB MME
Configuration
Relaying Transfer Signaling
Configuration
Transfer X2
Signaling
en-gNB
Figure 5.14-1: inter E-UTRAN Configuration Transfer basic network architecture
The E-UTRAN transparent containers are transferred from the source E-UTRAN node to the destination E-UTRAN
node by use of Configuration Transfer messages.
An ENB Configuration Transfer message is used from the eNodeB to the MME over S1 interface, a MME
Configuration Transfer message is used from the MME to the eNodeB over S1 interface, and a Configuration Transfer
Tunnel message is used to tunnel the E-UTRAN transparent container from a source MME to a target MME over the
S10 interface.
Each Configuration Transfer message carrying the E-UTRAN transparent container is routed and relayed independently
by the core network node(s). Any relation between messages is transparent for the MME, i.e. a request/response
exchange between applications, for example SON applications, is routed and relayed as two independent messages by
the MME. An MME supporting the Configuration Transfer procedures provides addressing, routing and relaying
functions.
5.14.2 Addressing, routing and relaying
5.14.2.1 Addressing
All the Configuration Transfer messages contain the addresses of the source and destination RAN nodes. An eNodeB is
addressed by the Target eNodeB Identifier. For Dual Connectivity with E-UTRAN as Master RAN node and NR as
Secondary RAN node as defined in TS 37.340 [85], the destination RAN node includes the candidate en-gNB Identifier
and may include a target eNodeB Identifier for the target eNodeB which is X2 connected to the candidate en-gNB and a
TAI associated with the en-gNB.
3GPP
Release 15 332 3GPP TS 23.401 V15.10.0 (2019-12)
5.14.2.2 Routing
The following description applies to all the Configuration Transfer messages used for the exchange of the E-UTRAN
transparent container.
The source RAN node sends a message to its MME including the source and destination addresses. The MME uses the
destination address to route the message encapsulated in a GTPv2 message to the correct MME via the S10 interface
(see TS 29.274 [43]).
The MME connected to the target eNodeB decides which RAN node to send the message to, based on the destination
address. For Dual Connectivity with E-UTRAN as Master RAN node and NR as Secondary RAN node as defined in
TS 37.340 [85], target eNodeB decides which candidate en-gNB to send the message to, based on the destination
address.
5.14.2.3 Relaying
The MME performs relaying between GTPv2 messages as described in TS 29.274 [43]. The MME performs relaying
between S1 and S10 messages as described in TS 36.413 [36], TS 23.501 [83] and TS 29.274 [43]. The Target eNodeB
performs relaying between S1 and X2 message as described in TS 36.413 [36] and TS 36.423 [76].
5.14.2.4 Applications using the Configuration Transfer procedures

The RAN node applications, which use the Configuration Transfer procedures, are fully transparent for the MME.
These applications are described in RAN specifications. An example of application is the transfer of information
required for Self-Optimised Networks (SON).
5.15 RAN Information Management (RIM) procedures

5.15.1 General
The RAN Information Management (RIM) procedures provide a generic mechanism for the exchange of arbitrary
information between applications belonging to the RAN nodes. The RAN information is transferred via the MME and
SGSN core network node(s). In order to make the RAN information transparent for the Core Network, the RAN
information is included in a RIM container that shall not be interpreted by the Core Network nodes.
The RIM procedures are optional both in the RAN and the CN nodes. For the Gb interface the use of RIM procedures is
negotiated at start/restart of the Gb link. For the Iu interface there is no negotiation of using RIM procedures or not at Iu
link start/restart.
The RAN information is transferred in RIM containers from the source RAN node to the destination RAN node by use
of messages. Source and destination RAN nodes can be E-UTRAN, UTRAN or GERAN. Each message carrying the
RIM container is routed and relayed independently by the core network node(s). Any relation between messages is
transparent for the MME/SGSN, i.e. a request/response exchange between RIM applications, for example, is routed and
relayed as two independent messages by the MME/SGSN.
The interfaces which will be used are the Gb, the Iu, the S1, Gn and the S3 interfaces. The RAN information in the RIM
container shall be transparent for the Core Network. An MME or SGSN supporting the RIM procedures provides
addressing, routing and relaying functions.
5.15.2 Addressing, routing and relaying
5.15.2.1 Addressing
All the messages used for the exchange of RAN information contain the addresses of the source and destination RAN
nodes. A BSS is addressed by Routing Area Identity (RAI) + Cell Identity (CI) of one of its cells. An eNodeB is
addressed by the Target eNodeB Identifier. An RNC is addressed by Global RNC-Id as defined in TS 23.003 [9].
3GPP
Release 15 333 3GPP TS 23.401 V15.10.0 (2019-12)
5.15.2.2 Routing
The following description applies to all the messages used for the exchange of RAN information.
The source RAN node sends a message to its MME or SGSN including the source and destination addresses. The
SGSN/MME uses the destination address to route the message encapsulated in a GTP message to the correct
MME/SGSN via the S3 or Gn interface.
The MME/SGSN connected to the destination RAN node decides which RAN node to send the message to based on the
destination address.
5.15.2.3 Relaying
The SGSN performs relaying between BSSGP messages, RANAP messages and GTP messages as described in
TS 48.018 [42], TS 25.413 [22], TS 29.060 [14] and TS 29.274 [43]. The MME performs relaying between S1 and
S3/Gn messages as described in TS 36.413 [36] and TS 29.274 [43] / TS 29.060 [14].
5.15.3 Applications using the RIM Procedures

The RAN node applications, which use the RIM procedures, are fully transparent for the MME and SGSN. These
applications are described in RAN specifications. An example between E-UTRAN and GERAN is the Network
Assisted Cell Change described in TS 48.018 [42], TS 25.413 [22] and TS 36.413 [36]. An example between E-
UTRAN and UTRAN is the exchange of SON related information described in TS 36.413 [36]
5.16 MME-initiated procedure on UE's CSG membership change

If the UE is in ECM-CONNECTED state and connected via a CSG cell and the MME detects that the UE's CSG
membership to that cell has expired, the MME shall send an S1AP UE CONTEXT MODIFICATION REQUEST
message to the eNodeB which includes an indication that the CSG membership of the UE has expired. The eNodeB
receiving this indication may initiate a handover to another cell. If the UE is not handed over the eNodeB should initiate
the S1 release procedure with an appropriate cause. The MME initiates S1 release after a configurable time if the UE is
not handed over or released by the CSG cell. If the CSG membership expires for a UE with ongoing emergency bearer
service, no indication that the CSG membership of the UE has expired is sent to the eNodeB and the MME shall
deactivate all non-emergency PDN connections.
If the UE is in ECM-CONNECTED state and connected via a hybrid cell and the MME detects that the UE's CSG
membership to that cell has changed or expired, and the CSG Information Reporting Action indicates User CSG
Information shall be reported to the P-GW then the MME shall modify the last known CSG membership and send a
Change Notification message to the Serving GW with User CSG Information to indicate the CSG membership change.
The Serving GW shall send the Change Notification message with the User CSG Information to the PDN GW. The
MME shall also send the S1AP UE CONTEXT MODIFICATION REQUEST message to the eNodeB which includes
an indication of whether the UE is a CSG member. Based on this information the eNodeB may perform differentiated
treatment for CSG and non-CSG members. MME shall release the impacted LIPA PDN connection if the LIPA CSG
authorization data for this CSG cell is no longer valid due to UE's CSG membership changed or expired.
5.17 Home eNodeB Multicast Packet Forwarding Function

A Home eNodeB L-GW should receive and process multicast group membership report messages (e.g. according to
RFC 3376 [62] / RFC 3810 [63]) sent either by the network accessed by LIPA or by the UE. Based upon these
messages, the L-GW should forward multicast IP datagrams sent by the UE to the network accessed by LIPA, or from
the network accessed by LIPA to the UE, as appropriate.
The UE may implement RFC3376 [62] or RFC 3810 [63] to report multicast groups that the UE seeks to receive.
To make UPnP/DLNA service advertisements sent with an IP TTL=1 available to UEs that employ LIPA, a proxying
function in the L-GW may be implemented, e.g. to retransmit UPnP service advertisements to UEs after changing the
source address. This proxying to the UE shall not be performed if the multicast packet is transmitted with an IPv4 or
IPv6 link-local source address, RFC 3927 [64], RFC 4291 [65].
3GPP
Release 15 334 3GPP TS 23.401 V15.10.0 (2019-12)
5.18 HPLMN Notification with specific indication due to MME

initiated Bearer removal
When initiating a Delete Session Request procedure, the MME shall add an appropriate cause code facilitating the
operator of the P-GW to take appropriate action (e.g. Alarm, O&M action by operator's management network) if
needed.
NOTE: This is for the HPLMN operator to be able to differentiate Delete Session Request procedures due to a
failure case (e.g. due to a QoS parameter mismatch at Initial Attach) from Delete Session Request
procedures that are executed in cases not related to any failure conditions (e.g. due to a Tracking Area
Update). Action taken by the HPLMN operator is outside the scope of 3GPP specification.
5.19 Procedures to support Dedicated Core Networks

5.19.1 NAS Message Redirection Procedure
When DCNs are used, these steps are used to reroute a NAS message (and thereby a UE) from one CN node to another
CN node during Attach, TAU or RAU procedure. These steps are also used by the MME/SGSN or HSS initiated
Dedicated Core Network Reselection procedure in clause 5.19.3.
RAN Node First new MME/SGSN Second new MME/SGSN
1. Reroute NAS Message Request
2. NNSF
3. Initial UE Message/ UL-Unitdata
Figure 5.19.1-1: NAS Message Redirection Procedure
The procedure is started when a first new MME/SGSN decides to move the handling of an Attach Request, TAU
Request or RAU Request to another CN node.
1. The first new MME/SGSN sends a Reroute NAS Message Request (original RAN message, reroute parameters,
Additional GUTI/P-TMSI, UE Usage Type, and optionally the IMSI) to the RAN Node. The reroute parameter is
a MMEGI (for E-UTRAN) or Null-NRI/SGSN Group ID (for UTRAN/GERAN) corresponding to the DCN that
corresponds to the UE Usage Type. A UE provided Additional GUTI/P-TMSI (if available) from the NAS
Request message is included. The MME/SGSN may determine the MMEGI or Null-NRI/SGSN Group ID
corresponding to the DCN using DNS procedures. The original RAN message is the complete PDU received
from the RAN which contains the original NAS Request message and all RAN IEs. The UE Usage Type shall be
included, if available. For the condition to include the IMSI, see step 6 in clause 5.19.2.
2. The RAN node's NNSF selects a new MME/SGSN based on the MMEGI or Null-NRI/SGSN Group ID and
possibly also based on an Additional GUTI/P-TMSI. If Additional GUTI/P-TMSI identifies an MME/SGSN
within the set of valid nodes identified by MMEGI or Null-NRI/SGSN Group ID, it should be the selected node.
Otherwise a valid CN node corresponding to the MMEGI or Null-NRI/SGSN Group ID will be selected. If no
valid MME/SGSN is available within the set of valid nodes identified by MMEGI or Null-NRI/SGSN Group ID,
the RAN node selects an MME/SGSN from the default DCN or selects the MME/SGSN that sent the Reroute
Request, based on operator configuration. The MME/SGSN is selected from the network corresponding to the
selected CN operator.
3. Dependent on RAT, the eNodeB/RNC sends the Initial UE message to the selected MME/SGSN or the BSC
sends the UL-Unitdata message to the selected SGSN. The initial UE message/UL-Unitdata message includes
the NAS Request message, the MMEGI or Null-NRI/SGSN Group ID, UE Usage Type and the IMSI if received
3GPP
Release 15 335 3GPP TS 23.401 V15.10.0 (2019-12)
from the first SGSN/MME in step 1. The MMEGI or Null-NRI/SGSN Group ID indicates that the message is a
rerouted message and the second new MME/SGSN shall not reroute the NAS message. The UE Usage Type
shall be included if received in the Reroute NAS Message Request to be used by the second new MME/SGSN to
select SGW and PDN GW (see clauses 4.3.8.1 and 4.3.8.2).
5.19.2 Attach, TAU and RAU procedure for Dedicated Core Network
When DCNs are used, the Attach, TAU and RAU procedures in this clause apply.
3GPP
Release 15 336 3GPP TS 23.401 V15.10.0 (2019-12)
(first) new old

UE RAN node HSS
MME/SGSN MME/SGSN
1. E-UTRAN Attach Figure 5.3.2.1-1 steps 1-4 or

GPRS/IMSI Attach Figure 22 steps 1-3 in TS 23.060 [7] or
TAU procedure Figure 5.3.3.1-1 steps 1-5 or
Figure 5.3.3.2-1 steps 1-5 or
RAU procedure Figure 5.3.3.3-1 steps 1-4 or
Figure 5.3.3.6-1 steps 1-4 or
Figure 33 steps 1-2 in TS 23.060 [7] or
Figure 33a step 2 in TS 23.060 [7] or
Figure 36a step 2 in TS 23.060 [7] or
Figure 54-2 steps 3-5 in TS 23.060 [7] or
Figure 55-2 steps 3-4 in TS 23.060 [7]
2. Authentication Information Request

3. Authentication Information Answer
4. Attach/TAU/RAU procedure continues from the next step at the (first) new
MME/SGSN as specified in the relevant section.
(second) new
OR
MME/SGSN
6. NAS Message Redirection Procedure 5.19.1
7. The Attach/TAU/RAU procedure starts at the (second) new MME/SGSN from the following step;
E-UTRAN Attach Figure 5.3.2.1-1 step 3 onwards or
GPRS/IMSI Attach Figure 22 step 2 onwards in TS 23.060 [7] or
TAU procedure Figure 5.3.3.1-1 step 4 onwards or
Figure 5.3.3.2-1 step 4 onwards or
RAU procedure Figure 5.3.3.3-1 step 3 onwards or
Figure 5.3.3.6-1 step 3 onwards or
Figure 33 step 2 onwards in TS 23.060 [7] or
Figure 33a step 2 onwards in TS 23.060 [7] or
Figure 36a step 2 onwards in TS 23.060 [7] or
Figure 54-2 step 3 onwards in TS 23.060 [7] or
Figure 55-2 step 3 onwards in TS 23.060 [7]
Figure 5.19.2-1: Attach,TAU and RAU procedure for Dedicated Core Network
1. Attach, TAU, or RAU procedure is initiated as specified in the relevant clauses of this specification and
TS 23.060 [7]. The relevant steps of the procedure as specified in the figure above are executed. The following
modifications apply:
3GPP
Release 15 337 3GPP TS 23.401 V15.10.0 (2019-12)
- In the RRC Connection Complete message transferring the NAS Request message, the UE provides the
DCN-ID, if available. If the UE has a PLMN specific DCN-ID the UE shall provide this value and if no
PLMN specific DCN-ID exist the pre-provisioned default standardized DCN-ID shall be provided, if pre-
provisioned in the UE. The RAN node selects a DCN and a serving MME/SGSN within the network of the
selected core network operator based on the DCN-ID and configuration in the RAN node. The NAS Request
message is sent to the selected node. The DCN-ID is provided by the RAN to the MME/SGSN together with
the NAS Request message.
- E-UTRAN Initial Attach Procedure (clause 5.3.2.1 (Figure 5.3.2.1-1)) and Combined GPRS/IMSI Attach
procedure (TS 23.060 [7] clause 6.5.3 (Figure 22)): In the Identification Response message, the old
MME/SGSN provides UE Usage Type parameter, if available.
- Tracking area update procedure (clause 5.3.3.1 (Figure 5.3.3.1-1) and 5.3.3.2 (Figure 5.3.3.2-1)): In the
Context Response message, the old MME/SGSN provides UE Usage Type parameter, if available.
- Routing area update procedure (clause 5.3.3.3 (Figure 5.3.3.3-1) and 5.3.3.6 (Figure 5.3.3.6-1), TS 23.060 [7]
clauses 6.9.1.2.2 (Figure 33), 6.9.1.2.2a (Figure 33a), 6.9.1.3.2 (Figure 35), 6.9.2.1 (Figure 36), 6.9.2.1a
(Figure 36a), 6.13.1.1.1 (Figure 52), 6.13.2.1.1 (Figure 54), 6.13.2.1.2 (Figure 54-2), 6.13.2.2.1 (Figure 55),
6.13.2.2.2 (Figure 55-2)): In the Context Response message, the old MME/SGSN provides UE Usage Type
parameter, if available.
2. If the (first) new MME/SGSN, i.e. the MME/SGSN that has not received any MMEGI or Null-NRI/SGSN
Group ID from RAN, does not have sufficient information to determine whether it should serve the UE, it sends
an Authentication Information Request message to the HSS requesting UE Usage Type by adding the parameter
"Send UE Usage Type" flag in the message. The MME/SGSN may also request one or more authentication
vectors in addition to the UE Usage Type. The (first) new MME/SGSN has sufficient information in the
following cases and may then skip this step and step 3:
i. The (first) new MME/SGSN has received the UE Usage Type from the old MME/SGSN in the Identification
Response (for Attach) or Context Response (for TAU/RAU) message or Forward Relocation Request (for
Handover).
ii. Based on configuration in the (first) new MME/SGSN and UE context information, the MME/SGSN is able
to determine whether it should serve the UE.
This step and redirection of NAS message (i.e. step 5 onwards) shall not be performed for TAU/RAU procedure
triggered in connected mode, e.g. during handover.
3. The HSS, if supporting DCNs, provides the UE Usage Type in the Authentication Information Answer message,
if any is stored for the UE. The UE Usage Type is returned by the HSS in addition to requested authentication
vectors.
4. If the (first) new MME/SGSN determines that it shall not reroute the NAS message to another CN node, the
MME/SGSN either continues from the designated step as stated in the figure above or depending on operator
configuration rejects the NAS request message and the NAS procedure ends in this step. The NAS message is
rejected with parameters, e.g. backoff timer, such that the UE does not immediately re-initiate the NAS
procedure.
The MME/SGSN sends the DCN-ID, if available, for the DCN to the UE in the NAS Accept message. The UE
updates its stored DCN-ID parameter for the serving PLMN if DCN-ID for serving PLMN is changed.
5. If the (first) new MME/SGSN determines that it should reroute the NAS request message to another CN node,
the procedure is a TAU or RAU procedure and UE context was received from the old MME/SGSN, the (first)
new MME sends a Context Acknowledge message with cause code indicating that the procedure is not
successful. The old MME/SGSN shall continue as if Context Request was never received.
6. If the (first) new MME/SGSN determines that it should reroute the NAS request message to another CN node, it
uses the "NAS Message Redirection Procedure" in clause 5.19.1. The NAS message is re-routed to a (second)
new MME/SGSN. If the IMSI was retrieved unencrypted from the UE by the (first) new MME/SGSN in step 1,
the (first) new MME/SGSN shall include the IMSI in the Reroute Message Request.
7. The (second) new MME/SGSN, i.e. the MME/SGSN that receives the rerouted NAS message from RAN with
MMEGI or Null-NRI/SGSN Group ID, performs NAS procedure as stated for E-UTRAN in this specification
3GPP
Release 15 338 3GPP TS 23.401 V15.10.0 (2019-12)
and for GERAN/UTRAN in TS 23.060 [7] from the steps shown in the figure above. The following
modifications apply:
- E-UTRAN Initial Attach Procedure (clause 5.3.2.1 (Figure 5.3.2.1-1)) and Combined GPRS/IMSI Attach
procedure (TS 23.060 [7] Clause 6.5.3 (Figure 22)): In the Identification Response message, the old
MME/SGSN provides UE Usage Type parameter, if available.
- Tracking area update procedure (clause 5.3.3.1 (Figure 5.3.3.1-1) and 5.3.3.2 (Figure 5.3.3.2-1)): In the
Context Response message, the old MME/SGSN provides UE Usage Type parameter, if available.
- In case the IMSI was received from the first (new) MME/SGSN as part of the NAS Message Redirection
Procedure, the second (new) MME/SGSN does not have to retrieve the IMSI from the UE.
- Routing area update procedure (clause 5.3.3.3 (Figure 5.3.3.3-1) and 5.3.3.6 (Figure 5.3.3.6-1), TS 23.060 [7]
clauses 6.9.1.2.2 (Figure 33), 6.9.1.2.2a (Figure 33a), 6.9.1.3.2 (Figure 35), 6.9.2.1 (Figure 36), 6.9.2.1a
(Figure 36a), 6.13.1.1.1 (Figure 52), 6.13.2.1.1 (Figure 54), 6.13.2.1.2 (Figure 54-2), 6.13.2.2.1 (Figure 55),
6.13.2.2.2 (Figure 55-2)): In the Context Response message, the old MME/SGSN provides UE Usage Type
parameter, if available.
- The MME/SGSN sends the DCN-ID, if available, for the new DCN to the UE in the NAS Accept message.
The UE updates its stored DCN-ID parameter for the serving PLMN if DCN-ID for serving PLMN is
changed.
In case network sharing and the Selected PLMN information is not provided by the UE, the SGSN may also
include the PLMN ID of selected CN operator in the NAS Accept message.
The (second) new MME/SGSN shall not reroute the NAS message to another CN node since the Initial UE
message/UL-Unitdata message from RAN includes MMEGI or Null-NRI/SGSN Group ID. The (second)
new MME/SGSN either completes the NAS procedure as stated above or depending on operator
configuration rejects the NAS request message and the NAS procedure ends. When rejecting the NAS
request, an appropriate cause and backoff time should be included.
In the case of TAU or RAU procedure, the (second) new MME/SGSN may check (e.g. based on the
indication that the NAS message has been rerouted and on local configuration) if the PDN GW (for one or
more PDN connection(s)) of the UE needs to be changed. If the PDN GW needs to be changed, the (second)
new MME/SGSN initiates Detach with reattach required or PDN disconnection with reactivation required
procedure after the completion of the TAU or RAU procedure.
5.19.2a Impacts to Handover Procedures

When DCNs are used, the impacts to the handover procedures are captured as below.
- Forward Relocation Request message: When MME changes during handover, in the step where Forward
Relocation Request message is sent from the Source MME/SGSN to Target MME/SGSN, the source
MME/SGSN also includes the UE Usage Type, if available, in the message. This applies to the following clauses
and step:
- 5.5.1.2.2 S1-based handover, normal: Step 3
- 5.5.2.1.2 Preparation phase (E-UTRAN to UTRAN Iu mode Inter RAT handover): Step 3
- 5.5.2.2.2 Preparation phase (UTRAN Iu mode to E-UTRAN Inter RAT handover): Step 3
- 5.5.2.3.2 Preparation phase (E-UTRAN to GERAN A/Gb mode Inter RAT handover): Step 3
- 5.5.2.4.2 Preparation phase (GERAN A/Gb mode to E-UTRAN Inter RAT handover): Step 3
- Selection of new SGW: In the step, subsequent to the Forward Relocation Request message, in which the target
MME/SGSN determines if the Serving GW is to be relocated, if the target MME/SGSN supports DCN, the target
MME/SGWN also determines if the existing Serving GW supports the DCN for the UE based on UE Usage
Type of the UE, locally configured operator's policies as well as UE related context information available at the
target network, e.g. information about roaming. This applies to the following clauses and step:
- 5.5.1.2.2 S1-based handover, normal: Step 4
3GPP
Release 15 339 3GPP TS 23.401 V15.10.0 (2019-12)
- 5.5.2.1.2 Preparation phase (E-UTRAN to UTRAN Iu mode Inter RAT handover): Step 4
- 5.5.2.2.2 Preparation phase (UTRAN Iu mode to E-UTRAN Inter RAT handover): Step 4
- 5.5.2.3.2 Preparation phase (E-UTRAN to GERAN A/Gb mode Inter RAT handover): Step 4
- 5.5.2.4.2 Preparation phase (GERAN A/Gb mode to E-UTRAN Inter RAT handover): Step 4
- Handover from service area where DCN is not used to an area where DCN is supported: When handover occurs
from a service area where DCN is not used to a service area where DCN is supported and the MME or SGSN
changes, the target MME or SGSN obtains the UE Usage Type information from the HSS during the subsequent
TAU or RAU procedure. If the target MME/SGSN determines that the Serving GW does not support the UE
Usage Type, the target MME/SGSN triggers the Serving GW relocation as part of the handover procedures
described in clause 5.5. If the target MME or SGSN does not serve the UE Usage type, the handover procedure
should complete successfully and then the target MME or SGSN may use the procedure in clause 5.19.3 Step 5
onwards, to change the serving DCN of the UE.
5.19.3 MME/SGSN or HSS initiated Dedicated Core Network Reselection

If DCNs are deployed, this procedure is used by the HSS to update (i.e. add, modify or delete) the UE Usage Type
subscription parameter in the serving node. This procedure may result in change of serving node of the UE. This
procedure may also be used for MME/SGSN intiated serving node change for UEs, e.g. when configuration about the
UE Usage Types served by MME/SGSN is changed. This procedure may also be used after a handover procedure by
the target MME/SGSN to redirect a UE to a serving node of another DCN.
If UE assisted DCN selection feature is supported by the Core Network, the UE is provided with the new DCN-ID.
The subscription change may be applied to a large number of UEs and similar considerations as in the case of
MME/SGSN rebalancing specified in clause 4.3.7.3 should be applied to avoid sudden redirection of UEs that could
overload the core network nodes (and possibly the RAN if paging is needed).
3GPP
Release 15 340 3GPP TS 23.401 V15.10.0 (2019-12)
UE MME/SGSN HSS
3. MME/SGSN pages the UE
4. UE initiates data transfer from idle
5. GUTI Reallocation / P-TMSI Reallocation
6. Release of RAN resources
7. TAU Request / RAU Request
OR
8. TAU Request / RAU Request
9. NAS redirection
Figure 5.19.3-1: MME/SGSN or HSS Initiated Dedicated Core Network Reselection
Steps 1 and 2 apply for HSS initiated Dedicated Core Network Reselection procedure only.
1. The HSS sends an Insert Subscriber Data Request (IMSI, Subscription Data) message to the MME/SGSN. The
Subscription Data includes UE Usage Type information or UE Usage Type withdrawal information.
NOTE 1: In case the UE Usage Type subscription change or withdrawal needs to be applied for a large number of
subscribers, the HSS should stagger the insertion of subscription changes to serving nodes, e.g. based on
OAM.
2. The MME/SGSN updates the stored Subscription Data and acknowledges the Insert Subscriber Data Request
message by returning an Insert Subscriber Data Answer (IMSI) message to the HSS. The procedure ends if the
MME/SGSN can continue to serve the UE.
3. If the MME/SGSN decides to transfer the UE immediately to another CN or if the MME/SGSN determines that
DCN-ID immediately needs to be updated and the UE is in idle-mode, the MME/SGSN pages the UE.
Alternatively the MME waits until the UE becomes active.
If MME/SGSN decides to transfer the UE to another CN either Steps 4 through 7 or Step 8 occur. Steps 4 through 7
occur in case the UE is already in connected mode or UE enters connected mode by initiating data transfer. Step 8
occurs in case the UE is in idle mode and performs a TAU/RAU procedure. If the MME/SGSN determines that only
DCN-ID shall be updated in the UE (i.e. serving CN node is kept) only step 4 and 5 occurs.
4. Either triggered by the paging or by uplink data the UE initiates NAS connection establishment. Alternatively
the UE initiates NAS connection establishment by sending a TAU/RAU Request.
5. When a NAS connection already exists or when a NAS connection is established for initiating data transfer, the
MME/SGSN triggers the GUTI Reallocation/P-TMSI Reallocation procedure. If DCN-ID is available and the
MME/SGSN determines that the UE shall be updated with a new DCN-ID, the new DCN-ID shall be included in
the GUTI Reallocation Command/P-TMSI Reallocation Command.
3GPP
Release 15 341 3GPP TS 23.401 V15.10.0 (2019-12)
If the MME/SGSN determines that a CN node re-selection needs to be performed, a non-broadcast TAI/RAI
shall be included.
6. The MME/SGSN releases RAN resources and UE is moved to idle mode.
NOTE 2: In case a large number of UEs need to be offloaded the MME/SGSN should not release RAN resources
for all UEs immediately to avoid sudden redirection of UEs that could overload the core network nodes
(and possibly the RAN if paging is needed). The MME/SGSN should wait until the release is performed
due to inactivity.
7. The non-broadcast TAI/RAI triggers the UE to immediately start the TAU/RAU procedure. If available, the new
DCN-ID shall be sent from the UE to the RAN.
The MME/SGSN receives the TAU/RAU Request message.
8. The UE performs a TAU/RAU request. The MME/SGSN receives the TAU/RAU Request message.
9. If the UE Usage Type for the UE has been added or modified and if it is not served by the MME/SGSN, or if the
UE Usage Type has been withdrawn from the HSS subscription data and subscriptions without UE Usage Type
are not served by the MME/SGSN, the MME/SGSN triggers the NAS Message redirection procedure of
clause 5.19.1 to redirect the UE. This is followed by step 7 of clause 5.19.2 where the TAU/RAU procedure
completes at the MME of the selected DCN.
3GPP
Release 15 342 3GPP TS 23.401 V15.10.0 (2019-12)
Annex A (informative):
Void
3GPP
Release 15 343 3GPP TS 23.401 V15.10.0 (2019-12)
Annex B (informative):
Void
3GPP
Release 15 344 3GPP TS 23.401 V15.10.0 (2019-12)
Annex C (informative):
Void
3GPP
Release 15 345 3GPP TS 23.401 V15.10.0 (2019-12)
Annex D (normative):
Interoperation with Gn/Gp SGSNs
D.1 General Considerations

This annex specifies interworking between the EPS and 3GPP 2G and/or 3G SGSNs, which provide only Gn and Gp
interfaces but no S3, S4 or S5/S8 interfaces, i.e. these Gn/Gp SGSNs provide no functionality that is introduced
specifically for the EPS or for interoperation with the E-UTRAN.
Interoperation scenarios for operating E-UTRAN with a PLMN maintaining Gn/Gp SGSNs are supported only with a
GTP-based S5/S8.
NOTE: PMIP-based S5/S8 may be used, but does not support handovers between the Gn/Gp SGSN and
MME/S-GW.
The S5/S8 interface for the Operator with Gn/Gp SGSNs will be GTP-based, but can be changed to PMIP-based S5/S8
when the Gn/Gp SGSNs evolve to S4 SGSNs.
For these interoperation scenarios the GERAN/UTRAN has to support interoperation with E-UTRAN.
TS 23.682 [74] defines the Monitoring Events feature, and TS 23.060 [7] specifies that the Monitoring Events feature
for the Gn/Gp SGSN is not supported. Therefore, during interoperation with Gn/Gp SGSNs Monitoring Event
information shall not be expected by the MME/S4-SGSN from a Gn/Gp SGSN, nor shall the MME/S4-SGSN or the
HSS transfer Monitoring Event information to a Gn/Gp SGSN. This applies to all operations defined in this annex.
D.2 Interoperation Scenario
D.2.1 Roaming interoperation scenario

In the roaming scenario the vPLMN operates Gn/Gp 2G and/or 3G SGSNs as well as MME and S-GW for E-UTRAN
access. The hPLMN operates a P-GW.
Roaming and inter access mobility between Gn/Gp 2G and/or 3G SGSNs and an MME/S-GW are enabled by:
- Gn functionality as specified between two Gn/Gp SGSNs, which is provided by the MME, and
- Gp functionality as specified between Gn/Gp SGSN and Gn/Gp GGSN that is provided by the P-GW.
All this Gp and Gn functionality bases on GTP version 1 only.
The architecture for interoperation with Gn/Gp SGSNs in the non-roaming case is illustrated in Figure D.2.1-1.
vPLMN hPLMN
GERAN Gr
Gn/Gp
HSS
UTRAN SGSN
S6a
Gn
S1-MME
MME
PCRF
Gp
Gx Rx
S11
S10
SGi Operator's IP Services
UE E-UTRAN SGW PGW (e.g. IMS, PSS etc.)
S1u S8
Figure D.2.1-1: Roaming architecture for interoperation with Gn/Gp SGSN
3GPP
Release 15 346 3GPP TS 23.401 V15.10.0 (2019-12)
D.2.2 Non-roaming interoperation scenario

In the non-roaming scenario the PLMN operates Gn/Gp 2G and/or 3G SGSNs as well as MME and S-GW for E-
UTRAN access.
Intra PLMN roaming and inter access mobility between Gn/Gp 2G and/or 3G SGSNs and an MME/S-GW are enabled
by:
- Gn functionality as specified between two Gn/Gp SGSNs, which is provided by the MME, and
- Gn functionality as specified between Gn/Gp SGSN and Gn/Gp GGSN that is provided by the P-GW.
All this Gn functionality is based on GTP version 1 only.
The architecture for interoperation with Gn/Gp SGSNs in the non-roaming case is illustrated in Figure D.2.2-1.
GERAN Gr
Gn/Gp
HSS
UTRAN SGSN
S6a
Gn
S1-MME
MME
PCRF
Gn
Rx
S11 Gx
S10
SGi Operator's IP Services
UE E-UTRAN SGW PGW
(e.g. IMS, PSS etc.)
S1u S5
Figure D.2.2-1: Non-roaming Architecture for interoperation with Gn/Gp SGSNs
NOTE: If the Rel-7 SGSN applies Direct Tunnel there is a user plane connection between P-GW and UTRAN.
D.3 Interoperation procedures
D.3.1 General
The interoperation procedures describe information flows for Gn/Gp SGSNs and other EPS network elements. All
messages between Gn/Gp SGSN and MME, between Gn/Gp SGSN and HSS and between Gn/Gp SGSN and P-GW as
well as the therein contained information elements are the same as specified for the adequate TS 23.060 [7] procedures
that are between Gn/Gp SGSNs. These messages and procedure step descriptions are taken from TS 23.060 [7] for
explanatory purposes only. These descriptions are in italic text and shall not be modified by the interoperation
procedures. It cannot be assumed that the messages and procedure step descriptions that are taken from TS 23.060 [7]
will be updated when modifications or corrections are performed for TS 23.060 [7]. If there are any discrepancies for
these messages and procedure step descriptions TS 23.060 [7] takes precedence. The messages between the MME and
any other node than the Gn/Gp SGSN as well as the therein contained information elements are the same as specified in
the main body of this technical specification for the inter RAT Routing Area Update procedure. If there are any
discrepancies for these messages the descriptions from the main body of this Technical Specification take precedence.
An operator that has pre-Rel-8 SGSNs in its network should use separate EPS bearers for IPv4 and IPv6 addressing,
such that both addresses can be maintained when moving to a pre-Rel-8 SGSN from a Rel-8 SGSN or MME (see
clause 5.3.1). This is configured into the SGSN and MME nodes which set the Dual Address Bearer Flag depending on
whether a UE may or may not be handed over to a pre-Rel-8 SGSN, as specified in clauses 5.3.2.1 and 5.10.2.
An operator supporting emergency services shall not have pre-Rel-9 SGSNs in its network where a UE may be handed
over.
3GPP
Release 15 347 3GPP TS 23.401 V15.10.0 (2019-12)
D.3.2 Void
D.3.3 MME to 3G SGSN combined hard handover and SRNS

relocation procedure
The MME to 3G Gn/Gp SGSN Combined Hard Handover and SRNS Relocation procedure is illustrated in
Figure D.3.3-1.
Any steps descriptions that are from inter Gn/Gp SGSNs procedures of TS 23.060 [7] are shown as italic text and
remain unmodified. In those step descriptions an MS stands for UE, old SGSN for old MME and GGSN for P-GW.
The procedure parts between E-UTRAN eNodeB and UE, and between E-UTRAN eNodeB and MME are compliant
with the equivalent procedure parts in clause "5.5 Handover".
If emergency bearer services are ongoing for the UE, handover to the target RNC is performed independent of the
Handover Restriction List. The SGSN checks, as part of the Routing Area Update in the execution phase, if the
handover is to a restricted area and if so SGSN deactivate the non-emergency PDP context as specified in
TS 23.060 [7], clause 9.2.4.2.
3GPP
Release 15 348 3GPP TS 23.401 V15.10.0 (2019-12)
MS Target Serving New Gn/Gp P-GW

Source eNodeB Old MME GW SGSN
RNC
1. Decision to perform
handover to UTRAN
4. Relocation Request
Establishment of Radio Access Bearers
4. Relocation Request Acknowledge

7. Create Indirect Data Forwarding Tunnel Response
8. Handover Command
9. Forwarding of data
11a. RAN Usage data report

11b. Change notification
MS detected by target RNC
12. Relocation Detect

13. RRC message
14. Relocation Complete
15. Forward Relocation Complete
15. Forward Relocation Complete Acknowledge

16. Update PDP Context Request
16. Update PDP Context Response
17. Routeing Area Update C2
C3

18b. Release Resources
Figure D.3.3-1: MME to 3G SGSN combined hard handover and SRNS relocation procedure
1. The source eNodeB decides to initiate a handover to the target access network, UTRAN Iu mode. At this point
both uplink and downlink user data is transmitted via the following: Bearer(s) between UE and source eNodeB,
GTP tunnel(s) between source eNodeB, Serving GW and PDN GW.
2. The source eNodeB sends a Handover Required (S1AP Cause, Target RNC Identifier, Source to Target
Transparent Container) message to the source MME to request the CN to establish resources in the target RNC
and the target SGSN. The bearers that will be subject to data forwarding (if any) are identified by the new SGSN
in a later step (see step 5 below).
3. The old MME sends a Forward Relocation Request message (IMSI, Tunnel Endpoint Identifier Signalling, MM
Context, PDP Context, Target Identification, RAN Transparent Container, RANAP Cause, GCSI) to the new
3GPP
Release 15 349 3GPP TS 23.401 V15.10.0 (2019-12)
SGSN. For relocation to an area where Intra Domain Connection of RAN Nodes to Multiple CN Nodes is used,
the old MME may have multiple new Gn/Gp SGSNs for each relocation target in a pool area, in which case the
old MME will select one of them to become the new Gn/Gp SGSN, as specified in TS 23.236 [30]. PDP context
contains GGSN Address for User Plane and Uplink TEID for Data (to this GGSN Address and Uplink TEID for
Data, the Serving GW and the new SGSN send uplink packets). At the same time a timer is started on the MM
and PDP contexts in the old MME (see Routing Area Update procedure in clause "Location Management
Procedures (Iu mode)"). The old MME does not set any GCSI flag as the MME has no GPRS CAMEL
Subscription Information. The S1AP Cause received from eNodeB is indicated as RANAP Cause. The Source to
Target Transparent Container received from eNodeB is indicated as RAN Transparent Container.
The MM context includes information on the EPS Bearer context(s). The old MME does not include any EPS Bearer
Context information for "Non-IP" bearers or for any SCEF connection. If none of the MS's EPS Bearers can be
supported by the selected new SGSN, the old MME rejects the handover attempt by sending a Handover Preparation
NOTE 1: If the handover is successful, the old MME will signal to the SGW and/or SCEF to release any non-
included EPS Bearers after step 15. The non-included bearers are locally released by the MS following
the PDP context status synchronisation that occurs during the Routing Area Update at step 17.
NOTE 2: The GGSN user plane address and uplink TEID are the old P-GW user plane address and TEID. The
MME maps the EPS bearer parameters to PDP contexts.
4. The new SGSN sends a Relocation Request message (Permanent NAS UE Identity, Cause, CN Domain
Indicator, Source RNC To Target RNC Transparent Container, RAB To Be Setup) to the target RNC. For each
RAB requested to be established, RABs To Be Setup shall contain information such as RAB ID, RAB parameters,
Transport Layer Address, and Iu Transport Association. SGSN shall not establish RABs for PDP contexts with
maximum bitrate for uplink and downlink of 0 kbit/s. The list of RABs requested by the new SGSN may differ
from list of RABs established in the Source RNC contained in the Source-RNC to target RNC transparent
container. The target RNC should not establish the RABs (as identified from the Source-RNC to target RNC
transparent container, Service Handover related information) that did not exist in the source RNC prior to the
relocation. The RAB ID information element contains the NSAPI value, and the RAB parameters information
element gives the QoS profile. The Transport Layer Address is the SGSN Address for user data, and the Iu
Transport Association corresponds to the uplink Tunnel Endpoint Identifier Data. The new SGSN may decide to
establish Direct Tunnel unless it has received a 'set' GCSI flag from the old SGSN. If the new SGSN decides to
establish Direct Tunnel, it provides to the target RNC the GGSN's Address for User Plane and TEID for Uplink
data. If the Access Restriction is present in the MM context, the Service Handover related information shall be
included by the target SGSN for the Relocation Request message in order for RNC to restrict the UE in
connected mode to handover to the RAT prohibited by the Access Restriction.
After all the necessary resources for accepted RABs including the Iu user plane are successfully allocated, the
target RNC shall send the Relocation Request Acknowledge message (Target RNC To Source RNC Transparent
Container, RABs Setup, RABs Failed To Setup) to the new SGSN. Each RAB to be setup is defined by a
Transport Layer Address, which is the target RNC Address for user data, and the Iu Transport Association,
which corresponds to the downlink Tunnel Endpoint Identifier for user data. The transparent container contains
all radio-related information that the MS needs for the handover, i.e. a complete RRC message (e.g., Physical
Channel Reconfiguration in UTRAN case, or Handover From UTRAN, or Handover Command in GERAN Iu
mode case) to be sent transparently via CN and source SRNC to the MS. For each RAB to be set up, the target
RNC may receive simultaneously downlink user packets both from the source SRNC and from the new SGSN.
NOTE 3: This step for the new SGSN is unmodified compared to pre-Rel-8. If the new SGSN decides to establish
Direct Tunnel, it provides to the target RNC the P-GW Address for User Plane and TEID for Uplink data.
The UE acts as the MS; the old eNodeB acts as the source SRNC.
5. When resources for the transmission of user data between target RNC and new SGSN have been allocated and
the new SGSN is ready for relocation of SRNS, the Forward Relocation Response (Cause, RAN Transparent
Container, RANAP Cause, Target-RNC Information) message is sent from the new SGSN to the old SGSN. This
message indicates that the target RNC is ready to receive from source SRNC the forwarded downlink PDUs, i.e.,
the relocation resource allocation procedure is terminated successfully. RAN transparent container and RANAP
Cause are information from the target RNC to be forwarded to the source SRNC. The Target RNC Information,
one information element for each RAB to be set up, contains the RNC Tunnel Endpoint Identifier and RNC IP
address for data forwarding from the source SRNC to the target RNC. The Forward Relocation Response
message is applicable only in case of inter-SGSN SRNS relocation.
3GPP
Release 15 350 3GPP TS 23.401 V15.10.0 (2019-12)
NOTE 4: This step is unmodified compared to pre-Rel-8. The old MME acts as the old SGSN, and the source
eNodeB as the source SRNC.
6. If 'Indirect Forwarding' applies the source MME sends a Create Indirect Data Forwarding Tunnel Request
message (IMSI, MME Tunnel Endpoint Identifier for Control Plane, MME Address for Control plane, Target
RNC Address and TEID(s) for DL user plane) to the Serving GW.
7. The Serving GW returns a Create Indirect Data Forwarding Tunnel Response (Cause, Serving GW DL TEID(s))
message to the source MME. If the Serving GW doesn't support data forwarding, an appropriate cause value
shall be returned.
8. The source MME completes the preparation phase towards source eNodeB by sending the message Handover
Command (Target to Source Transparent Container, Bearers Subject to Data Forwarding List, S1AP Cause).
"Bearers Subject to Data forwarding list" may be included in the message and it shall be a list of 'Address(es)
and TEID(s) for user traffic data forwarding' received from target side in the preparation phase (Step 5) in the
case of direct forwarding or received from the Serving GW in the preparation phase (Step 7) in the case of
indirect forwarding. RANAP Cause as received from new SGSN is indicated as S1AP Cause. RAN Transparent
Container as received from new SGSN is indicated as Target to Source Transparent Container.
9. The source eNodeB initiates data forwarding for bearers specified in the "Bearers Subject to Data Forwarding
List". The data forwarding may go directly to target RNC or alternatively go via the Serving GW if so decided
by source MME in the preparation phase.
10. The source eNodeB will give a command to the UE to handover to the target access network via the message HO
from E-UTRAN Command. This message includes a transparent container including radio aspect parameters that
the target RNC has set-up in the preparation phase. The details of this E-UTRAN specific signalling are
usage data to report, the eNodeB sends the RAN data report message (Secondary RAT usage data) to the MME.
Since the handover is an inter-RAT handover, the MME continues with the Secondary RAT usage data reporting
procedure as in clause 5.7A.3. The reporting procedure in clause 5.7A.3 is only performed if PGW secondary
RAT usage reporting is active.
NOTE 5: The source eNodeB does not send any RAN contexts towards the target RNC.
12. The target RNC shall send a Relocation Detect message to the new SGSN when the relocation execution trigger
is received. For SRNS relocation type "UE Involved", the relocation execution trigger may be received from the
Uu interface; i.e., when target RNC detects the MS on the lower layers. When the Relocation Detect message is
sent, the target RNC shall start SRNC operation.
NOTE 6: This step is unmodified compared to pre-Rel-8.
13. When the MS has reconfigured itself, it sends an RRC message e.g., a Physical Channel Reconfiguration
Complete message to the target SRNC.
The UE locally deactivates ISR by setting its TIN from "RAT-related TMSI" to "GUTI", if any EPS bearer
context activated after the ISR was activated in the UE exists.
14. When the target SRNC receives the appropriate RRC message, e.g. Physical Channel Reconfiguration Complete
message or the Radio Bearer Release Complete message in UTRAN case, or the Handover To UTRAN Complete
message or Handover Complete message in GERAN case, i.e. the new SRNC-ID + S-RNTI are successfully
exchanged with the MS by the radio protocols, the target SRNC shall initiate a Relocation Complete procedure
by sending the Relocation Complete message to the new SGSN. The purpose of the Relocation Complete
procedure is to indicate by the target SRNC the completion of the relocation of the SRNS to the CN.
NOTE 7: This step is unmodified compared to pre-Rel-8. The UE acts as the MS.
15. Upon receipt of Relocation Complete message, if the SRNS Relocation is an inter SGSN SRNS relocation, the
new SGSN signals to the old SGSN the completion of the SRNS relocation procedure by sending a Forward
Relocation Complete message.
A timer in source MME is started to supervise when resources in Source eNodeB and Source Serving GW shall
be released.
3GPP
Release 15 351 3GPP TS 23.401 V15.10.0 (2019-12)
NOTE 8: For the SGSN this step is unmodified compared to pre-Rel-8. The old MME acts as the old SGSN, and
the source eNodeB as the source SRNC.
16. Upon receipt of the Relocation Complete message, the CN shall switch the user plane from the source RNC to
the target SRNC. If the SRNS Relocation is an inter-SGSN SRNS relocation or if Direct Tunnel was established
in intra-SGSN SRNS relocation, the new SGSN sends Update PDP Context Request messages (new SGSN
Address, SGSN Tunnel Endpoint Identifier, QoS Negotiated, serving network identity, CGI/SAI, User CSG
Information, RAT type, MS Info Change Reporting support indication, NRSN, DTI) to the GGSNs concerned.
The SGSN shall send the serving network identity to the GGSN. If Direct Tunnel is established the SGSN
provides to GGSN the RNC's Address for User Plane and TEID for Downlink data and shall include the DTI to
instruct the GGSN to apply Direct Tunnel specific error handling procedure as described in clause 13.8. NRSN
indicates SGSN support of the network requested bearer control. The GGSNs update their PDP context fields
and return an Update PDP Context Response (GGSN Tunnel Endpoint Identifier, Prohibit Payload
Compression, APN Restriction, MS Info Change Reporting Action, CSG Information Reporting Action, BCM)
message. The Prohibit Payload Compression indicates that the SGSN should negotiate no data compression for
this PDP context.
The PDN GW shall include a Charging Id to be used at the SGSN as the Charging Id for reporting usage for this
PDP context. The PDN GW shall include the Charging Id in the offline charging data.
NOTE 9: This step is unmodified compared to pre-Rel-8. The P-GW acts as the GGSN.
17. After the MS has finished the reconfiguration procedure and if the new Routing Area Identification is different
from the old one or if the MS' TIN indicates "GUTI", the MS initiates the Routing Area Update procedure. See
clause "Location Management Procedures (Iu mode)".
For a MS supporting CIoT EPS Optimisations, the MS uses the PDP context status information in the RAU
Accept to identify any non-transferred bearers that it shall locally release.
NOTE 10:It is only a subset of the RA update procedure that is performed, since the MS is in PMM-CONNECTED
state.
NOTE 11:This step is unmodified compared to pre-Rel-8. The UE acts as the MS. The old EPS bearer information
in old MME and Serving GW is removed as part of the Routing Area Update procedure.
18. When the timer started in step 15 expires, the source MME deletes the EPS bearer resources by sending Delete
Session Request (Cause, Operation Indication, Secondary RAT usage data) messages to the Serving GW because
the new SGSN is a Gn/Gp SGSN, which is derived from using GTPv1 for relocation signalling between new
Gn/Gp SGSN and old MME. The new Gn/Gp SGSN does not signal any Serving GW change. The operation
Indication flag is not set, that indicates to the Serving GW that the Serving GW shall not initiate a delete
procedure towards the PDN GW. Secondary RAT usage data was included if it was received in step 11a. The
Source Serving GW acknowledges with Delete Session Response (Cause) messages. If ISR is activated the cause
indicates to the old S-GW that the old S-GW shall delete the bearer resources on the other old CN node by
sending Delete Bearer Request message(s) to that CN node. If resources for indirect forwarding have been
allocated then these are released.
When the timer started in step 15 expires, the source MME sends a Release Resources message to the source
eNodeB. When the Release Resources message has been received and there is no longer any need for the
eNodeB to forward data, the source eNodeB releases its resources.
If the SRNS Relocation is inter-SGSN, then the following CAMEL procedure calls shall be performed (see referenced
procedures in TS 23.078 [29])
NOTE 12:The C1 CAMEL procedure call was omitted intentionally from this procedure since EPS does not support
CAMEL procedure calls. The other CAMEL procedure calls are unmodified compared to pre-Rel-8.
The new SGSN shall determine the Maximum APN restriction based on the received APN Restriction of each PDP
context from the GGSN and then store the new Maximum APN restriction value.
If the SRNS Relocation is intra-SGSN, then the above mentioned CAMEL procedures calls shall not be performed.
3GPP
Release 15 352 3GPP TS 23.401 V15.10.0 (2019-12)
If Routing Area Update occurs, the SGSN shall determine whether Direct Tunnel can be used based on the received
GPRS CAMEL Subscription Information. If Direct Tunnel can not be maintained the SGSN shall re-establish RABs and
initiate the Update PDP Context procedure to update the IP Address and TEID for Uplink and Downlink data.
If Routing Area Update occurs, then the following CAMEL procedure calls shall be performed (see referenced
procedures in TS 23.078 [29]):
C2) CAMEL_GPRS_Routing_Area_Update_Session and CAMEL_PS_Notification.
They are called in the following order:
- The CAMEL_GPRS_Routing_Area_Update_Session procedure is called. The procedure returns as result

"Continue".
- Then the CAMEL_PS_Notification procedure is called. The procedure returns as result "Continue".
C3) CAMEL_GPRS_Routing_Area_Update_Context.
This procedure is called several times: once per PDP context. It returns as result "Continue".
For C2 and C3: refer to Routing Area Update procedure description for detailed message flow.
NOTE 13:Handover Reject is performed as defined in clause 5.5.2.1.4, excluding steps 4 and 7.
D.3.4 3G SGSN to MME combined hard handover and SRNS

relocation procedure
The 3G Gn/Gp SGSN to MME Combined Hard Handover and SRNS Relocation procedure is illustrated in
Figure D.3.4-1.
Any steps descriptions that are from TS 23.060 [7] are shown as italic text and remain unmodified. In those step
descriptions an MS stands for UE, new SGSN for new MME and GGSN for P-GW.
The procedure between E-UTRAN eNodeB and UE, and between E-UTRAN eNodeB and MME are compliant with the
equivalent procedure parts in clause 5.5: Handover.
If emergency bearer services are ongoing for the UE, the MME checks as part of the Tracking Area Update in the
execution phase, if the handover is to a restricted area and if so MME releases the non-emergency bearers as specified
in clause 5.10.3.
3GPP
Release 15 353 3GPP TS 23.401 V15.10.0 (2019-12)
Source Target Old Gn/Gp

MS eNodeB New MME S-GW P-GW HSS
RNC SGSN
1. Decision to handover
6. Handover Request
Establishment of Radio Access Bearers

7. Handover Request Acknowledge
9. Create Indirect Data Forwarding Tunnel Response
C1
11. Relocation Command
12. Forwarding of data

13. RRC message
14. Forward SRNS Context
14. Forward SRNS Context
14. Forward SRNS Context Acknowledge
MS detected by target RNC
15. HO to EUTRAN Complete

15. Handover Notify
20 Iu Release Command 17. Modify Bearer Request
20a. Iu Release Complete 18. Modify Bearer Request/Response
22. Procedure as in TS 23.401, steps 2 to 7 of Figure 5.4.2.2-1

Figure D.3.4-1: 3G Gn/Gp SGSN to MME combined hard handover and SRNS relocation procedure
1. The source RNC decides to initiate a handover to E-UTRAN.
2. The source SRNC sends a Relocation Required message (Relocation Type, Cause, Source ID, Target ID, Source
RNC To Target RNC Transparent Container) to the old SGSN. The source SRNC shall set Relocation Type to
"UE Involved". Source RNC To Target RNC Transparent Container includes the necessary information for
relocation co-ordination, security functionality and RRC protocol context information (including MS
Capabilities).
NOTE 1: This step is unmodified compared to pre-Rel-8. The target eNodeB acts as the target RNC.
NOTE 1a: The Target ID identifies an eNodeB. With Rel-8 Iu functionality this is an eNodeB ID. As an
implementations option for supporting introduction scenarios with pre-Rel8 SGSNs the source RNC may
be configured to use RNC IDs instead of eNodeB IDs to identify a target eNodeB. The Cause is relayed
transparently by the SGSN to the MME and the MME mappes RANAP cause code to an S1AP cause
code. Source RNC to Target RNC Transparent Container carries information for the target eNodeB. This
container is relayed transparently by the SGSN.
3GPP
Release 15 354 3GPP TS 23.401 V15.10.0 (2019-12)
3. The old SGSN determines from the Target ID if the SRNS relocation is intra-SGSN SRNS relocation or inter-
SGSN SRNS relocation. In case of inter-SGSN SRNS relocation the old SGSN initiates the relocation resource
allocation procedure by sending a Forward Relocation Request message (IMSI, Tunnel Endpoint Identifier
Signalling, MM Context, PDP Context, Target Identification, RAN Transparent Container, RANAP Cause,
GCSI) to the new SGSN. For relocation to an area where Intra Domain Connection of RAN Nodes to Multiple
CN Nodes is used, the old SGSN may – if it provides Intra Domain Connection of RAN Nodes to Multiple CN
Nodes -have multiple target SGSNs for each relocation target in a pool area, in which case the old SGSN will
select one of them to become the new SGSN, as specified in TS 23.236 [30]. PDP context contains GGSN
Address for User Plane and Uplink TEID for Data (to this GGSN Address and Uplink TEID for Data, the old
SGSN and the new SGSN send uplink packets). At the same time a timer is started on the MM and PDP contexts
in the old SGSN (see Routing Area Update procedure in clause "Location Management Procedures (Iu mode)").
The Forward Relocation Request message is applicable only in case of inter-SGSN SRNS relocation. The old
SGSN 'sets' the GCSI flag if the MM context contains GPRS CAMEL Subscription Information.
NOTE 2: This step is unmodified compared to pre-Rel-8. The new MME acts as the new SGSN, and the P-GW as
the GGSN. The GGSN user plane address and uplink TEID are the P-GW user plane address and TEID.
The MME maps the PDP context parameters to EPS bearers.
4. The MME selects a Serving GW and sends a Create Session Request (bearer context(s) with PDN GW addresses
and TEIDs for uplink traffic, APN-AMBR, Serving Network, UE Time Zone) message per PDN connection to
the target Serving GW. For relocation from Gn/Gp SGSN, the target MME provides the APN-AMBR if not
received explicitly from the Gn/Gp SGSN based on the mapping from MBR (as specified in Annex E) to the
Serving GW.
5. The Serving GW allocates the S-GW addresses and TEIDs for the uplink traffic on S1_U reference point (one
TEID per bearer). The target Serving GW sends a Create Session Response (Serving GW addresses and uplink
TEID(s) for user plane) message back to the target MME.
6. The new MME requests the target eNodeB to establish the bearer(s) by sending the message Handover Request
(UE Identifier, S1AP Cause, CN Domain Indicator, KeNB, NAS Security Parameters to E-UTRAN, EPS Bearers
to be setup list, Source to Target Transparent Container, Serving GW Address(es) and TEID(s) for User Traffic
Data, Handover Restriction List). S1AP Cause indicates the RANAP Cause as received from SGSN. Source to
Target Transparent Container contains the RAN Transparent Container as received from SGSN. The NAS
Security Parameters to E-UTRAN includes the NAS Integrity Protection and Ciphering algorithm(s), eKSI and
NONCEMME information elements. Handover Restriction List is sent if it is available in the Target MME; it is
If the MME did not receive the UE Network Capability information from the old SGSN, then the MME will not
have received information on the E-UTRAN Integrity Protection and Encryption algorithms that the UE
supports. In this case, the MME can assume that the UE supports both EIA1/EEA1 and EIA2/EEA2.
NOTE 3: The MME derives K'ASME from CK and IK in the MM context and associates it with eKSI, as described in
TS 33.401 [41] and selects NAS Integrity Protection and Ciphering algorithms(s). eKSI and key
derivation parameters are targeted for UE. The MME and UE derive the NAS keys and KeNB from K'ASME.
If the MME shares an EPS security association with the UE, the MME may activate this native EPS
security context by initiating a NAS SMC procedure after having completed the handover procedure.
The MME shall not request the target eNodeB to establish EPS GBR bearers with maximum bitrate set to 0 and
those EPS bearers should not be included in the EPS Bearers to be setup list and should be deactivated by the
MME. For the remaining EPS Bearer Contexts the MME ignores any Activity Status Indicator within an EPS
Bearer Context and requests the target eNodeB to allocate resources for all the remaining EPS Bearer Contexts.
The MME shall compute the UE-AMBR, according to clause 4.7.3, based on explicit APN-AMBR values
received from the Gn/Gp SGSN. If explicit APN-AMBR values are not received by the MME, a local UE-
AMBR shall be included in the 'EPS Bearers be setup list ' IE. The local UE-AMBR is described in clause
Annex E.
"Data forwarding not possible" indication per bearer shall be included in the 'EPS Bearers to be setup list' if the
target MME decides the corresponding bearer will not be subject to data forwarding.
NOTE 4: The MME derives the security parameters from the security parameters received from the SGSN.
NOTE 5: An MME that supports handovers from pre-Rel-8 3G SGSNs derives from the RNC ID received from old
SGSN an eNodeB address.
3GPP
Release 15 355 3GPP TS 23.401 V15.10.0 (2019-12)
7. The target eNodeB allocates the requested resources and returns the applicable parameters to the target MME in
the message Handover Request Acknowledge (Target to Source Transparent Container, EPS Bearers setup list,
EPS Bearers failed to setup list, Cause). The target eNodeB shall ignore it if the number of radio bearers in the
Source to Target Transparent container does not comply with the number of bearers requested by the MME and
allocate bearers as requested by the MME.
The target eNodeB inserts the information provided by the MME (KSI, selected NAS Integrity Protection and
Ciphering algorithm(s), NONCEMME) and selected AS integrity and ciphering algorithm(s) into the UTRAN
RRC message, which is contained in the Target to Source Transparent Container.
8. If 'Indirect Forwarding' and relocation of Serving GW apply the target MME sends a Create Indirect Data
Forwarding Tunnel Request message (IMSI, MME Tunnel Endpoint Identifier for Control Plane, MME Address
for Control plane, Target eNodeB Address and TEID(s) for DL user plane) to the Serving GW. The allocation of
a new Serving GW by steps 4 and 5 the MME shall consider as a Serving GW change.
9. The Serving GW returns a Create Indirect Data Forwarding Tunnel Response (Cause, Serving GW DL TEID(s))
message to the source MME. If the Serving GW doesn't support data forwarding, an appropriate cause value
shall be returned.
10. When resources for the transmission of user data between target RNC and new SGSN have been allocated and
the new SGSN is ready for relocation of SRNS, the Forward Relocation Response (Cause, RAN Transparent
Container, RANAP Cause, Target-RNC Information) message is sent from the new SGSN to the old SGSN. This
message indicates that the target RNC is ready to receive from source SRNC the forwarded downlink PDUs, i.e.,
the relocation resource allocation procedure is terminated successfully. RAN transparent container and RANAP
Cause are information from the target RNC to be forwarded to the source SRNC. The Target RNC Information,
one information element for each RAB to be set up, contains the RNC Tunnel Endpoint Identifier and RNC IP
address for data forwarding from the source SRNC to the target RNC. The Forward Relocation Response
message is applicable only in case of inter-SGSN SRNS relocation.
For each RAB, if the MME has determined no Data forwarding, i.e., the data forwarding from the source RNC to
the target eNodeB is not required, the MME indicates the reserved TEID and IP address parameters to the old
SGSN in the Target RNC Information. The packets received on that reserved TEID and IP address are discarded.
NOTE 6: The new MME acts as the new SGSN, and the target eNodeB as the target SRNC. RANAP Cause
indicates the Cause as received from target eNodeB. RAN Transparent Container contains the Target to
Source Transparent Container as received from eNodeB.
11. The old SGSN continues the relocation of SRNS by sending a Relocation Command message (Target RNC To
Source RNC Transparent Container, RABs To Be Released, RABs Subject To Data Forwarding) to the source
SRNC. The old SGSN decides the RABs to be subject for data forwarding based on QoS, and those RABs shall
be contained in RABs subject to data forwarding. For each RAB subject to data forwarding, the information
element shall contain RAB ID, Transport Layer Address, and Iu Transport Association. These are the same
Transport Layer Address and Iu Transport Association that the target RNC had sent to new SGSN in Relocation
Request Acknowledge message, and these are used for forwarding of downlink N-PDU from the source SRNC to
the target RNC. The source SRNC is now ready to forward downlink user data directly to the target RNC over
the Iu interface. This forwarding is performed for downlink user data only.
NOTE 7: This step is unmodified compared to pre-Rel-8. The target eNodeB acts as the target RNC, and the new
MME acts as the new SGSN. The forwarding of downlink user data from source SRNC may go directly
to target eNodeB or via the Serving GW.
12. The source SRNC may, according to the QoS profile, begins the forwarding of data for the RABs to be subject
for data forwarding.
NOTE 8: The order of steps, starting from step 7 onwards, does not necessarily reflect the order of events. For
instance, source RNC may start data forwarding (step 7), send the RRC message to MS (step 8) and
forward SRNS Context message to the old SGSN (step 9) almost simultaneously.
The data forwarding at SRNS relocation shall be carried out through the Iu interface, meaning that the GTP-
PDUs exchanged between the source SRNC and the target RNC are duplicated in the source SRNC and routed
at the IP layer towards the target RNC. For each radio bearer which uses lossless PDCP the GTP-PDUs related
to transmitted but not yet acknowledged PDCP-PDUs are duplicated and routed at IP layer towards the target
RNC together with their related downlink PDCP sequence numbers. The source RNC continues transmitting
duplicates of downlink data and receiving uplink data.
3GPP
Release 15 356 3GPP TS 23.401 V15.10.0 (2019-12)
Before the serving RNC role is not yet taken over by target RNC and when downlink user plane data starts to
arrive to target RNC, the target RNC may buffer or discard arriving downlink GTP-PDUs according to the
related QoS profile.
NOTE 9: This step is unmodified compared to pre-Rel-8. The target eNodeB acts as the target SRNC. The data
forwarding may go directly to target eNodeB or alternatively go via the Serving GW if so decided by new
MME in the preparation phase.
13. Before sending the RRC message the uplink and downlink data transfer shall be suspended in the source SRNC
for RABs, which require delivery order. The RRC message is for example Physical Channel Reconfiguration for
RNS to RNS relocation, or Intersystem to UTRAN Handover for BSS to RNS relocation, or Handover from
UTRAN Command for BSS relocation, or Handover Command for BSS to BSS relocation. When the source
SRNC is ready, the source RNC shall trigger the execution of relocation of SRNS by sending to the MS the RRC
message provided in the Target RNC to source RNC transparent container, e.g., a Physical Channel
Reconfiguration (UE Information Elements, CN Information Elements) message. UE Information Elements
include among others new SRNC identity and S-RNTI. CN Information Elements contain among others Location
Area Identification and Routing Area Identification.
When the MS has reconfigured itself, it sends an RRC message e.g., a Physical Channel Reconfiguration
Complete message to the target SRNC. If the Forward SRNS Context message with the sequence numbers is
received, the exchange of packets with the MS may start. If this message is not yet received, the target RNC may
start the packet transfer for all RABs, which do not require maintaining the delivery order.
NOTE 10:This step is unmodified compared to pre-Rel-8. This text is valid for the RRC message sent from source
RNC to the UE. When the UE has got access to target eNodeB it sends the HO to E-UTRAN Complete
message. This RRC message received as part of Target to Source Transparent Container, includes
information about the selected security algorithms and related key information. Based on this information,
the UE selects the same algorithms for the NAS if the KSI value indicates that the MME has no security
association with the UE. If the KSI value indicates that the MME has a security association with the UE,
but the UE has lost the security context of the E-UTRAN side (error case), the UE will start Attach
procedure on the E-UTRAN side
14. There is no RAN context transfer during inter RAT handovers with E-UTRAN. If the source RNC originates any
SRNC contexts the MME acknowledges the receipt towards the SGSN and ignores the message content.
NOTE 11:This step is unmodified compared to pre-Rel-8. The new MME acts as the new SGSN, and the target
eNodeB as the target SRNC.
15. When the UE has successfully accessed the target eNodeB, the target eNodeB informs the target MME by
sending the message Handover Notify (TAI+ECGI). The UE shall implicitly derive the EPS bearers for which an
E-RAB was not established from the HO from UTRAN Command and deactivate them locally without an
explicit NAS message at this step.
If Dual Connectivity is activated for the UE, the PSCell ID shall be included in the Handover Notify message.
16. Upon receipt of Handover Notify message, if the SRNS Relocation is an inter SGSN SRNS relocation, the new
SGSN signals to the old SGSN the completion of the SRNS relocation procedure by sending a Forward
Relocation Complete message.
Upon receipt of the Relocation Complete message the new MME starts a timer.
NOTE 12:This step is unmodified compared to pre-Rel-8 except that the Handover Notify message is received
instead of a Relocation Complete message. The new MME acts as the new SGSN.
17. The target MME will now complete the handover procedure by informing the Serving GW that the target MME
is now responsible for all the bearers the UE have established. This is performed in the message Modify Bearer
Request (Cause, Tunnel Endpoint Identifier Control Plane, MME Address for Control Plane, eNodeB
Address(es) and TEID(s) for User Traffic, RAT type, APN-AMBR) per PDN connection. If the PDN GW
requested UE's location information and/or User CSG information (determined from the UE context), the MME
also includes the User Location Information IE and/or User CSG Information IE in this message. If the UE Time
Zone has changed, the MME includes the UE Time Zone IE in this message.
3GPP
Release 15 357 3GPP TS 23.401 V15.10.0 (2019-12)
The MME releases the non-accepted bearers by triggering the bearer release procedure as specified in
18. The Serving GW informs the PDN GW the APN-AMBR and the change of for example the RAT type that e.g.
can be used for charging, by sending the message Modify Bearer Request (APN-AMBR, Serving Network, PDN
Charging Pause Support Indication) per PDN connection. The S-GW also includes User Location Information IE
and/or UE Time Zone IE and/or User CSG Information IE if it is present in step 17. The Serving GW allocates
DL TEIDs on S5/S8 even for non-accepted bearers. The PDN GW must acknowledge the request with the
message Modify Bearer Response (Default bearer id, APN Restriction, PDN Charging Pause Enabled Indication
(if PDN GW has chosen to enable the function)). When the UE moves from Gn/Gp SGSN to the MME, the
PDN GW shall send the APN restriction of each bearer context to the Serving GW.
19. The Serving GW acknowledges the user plane switch to the target MME via the message Modify Bearer
Response (Cause, Tunnel Endpoint Identifier Control Plane, Serving GW Address for Control Plane, Default
bearer id, APN restriction). The Serving GW shall forward the received APN Restriction to the MME. At this
stage the user plane path is established for all bearers between the UE, target eNodeB, Serving GW and PDN
GW.
20. Upon receiving the Relocation Complete message or, if it is an inter-SGSN SRNS relocation, the Forward
Relocation Complete message, the old SGSN sends an Iu Release Command message to the source RNC. When
the RNC data-forwarding timer has expired, the source RNC responds with an Iu Release Complete message.
NOTE 13:This step is unmodified compared to pre-Rel-8.
procedure, specifically it excludes the context transfer procedures between source SGSN and target MME. The
target MME gets the subscribed UE-AMBR value and the subscribed APN-AMBR value from the HSS during
the TA update procedure.
If the Subscription Data received from the HSS (during the TAU) contains information that is necessary for the
E-UTRAN to be aware of (e.g. a restriction in the UE's permission to use NR as a secondary RAT, Unlicensed
Spectrum or a combination of them), or an existing UE context in the MME indicates that the UE is not
permitted to use NR as a secondary RAT, Unlicensed Spectrum or a combination of them, and the MME has not
provided this information to the target eNodeB during step 6 (the Handover Request), then the MME sends an
updated Handover Restriction List in the Downlink NAS Transport message that it sends to E-UTRAN.
22. The target MME calculates UE-AMBR as defined in clause 4.7.3. If this calculated value is different from the
UE-AMBR computed during step 6, or the APN-AMBR mapped from the subscribed MBR is different from the
subscribed APN-AMBR, or the mapped subscribed QoS profile (i.e. the subscribed QoS profile mapped
according to Annex E) of the default bearer is different from the EPS Subscribed QoS profile received from the
HSS, the new MME shall initiate Subscribed QoS Modification procedure as described in clause 5.4.2.2, Figure
5.4.2.2-1.
23. When the timer started in step 16 expires the new MME releases the resources that have been allocated for
If the SRNS Relocation is inter-SGSN, then the following CAMEL procedure calls shall be performed (see referenced
procedures in TS 23.078 [29])
C1) CAMEL_GPRS_PDP_Context_Disconnection, CAMEL_GPRS_Detach and CAMEL_PS_Notification.
- The CAMEL_GPRS_PDP_Context_Disconnection procedure is called several times: once per PDP context.
The procedure returns as result "Continue".
- Then the CAMEL_GPRS_Detach procedure is called once. The procedure returns as result "Continue".
- Then the CAMEL_PS_Notification procedure is called once. The procedure returns as result "Continue".
3GPP
Release 15 358 3GPP TS 23.401 V15.10.0 (2019-12)
If the SRNS Relocation is intra-SGSN, then the above mentioned CAMEL procedures calls shall not be performed.
If Routing Area Update occurs, the SGSN shall determine whether Direct Tunnel can be used based on the received
GPRS CAMEL Subscription Information. If Direct Tunnel can not be maintained the SGSN shall re-establish RABs and
initiate the Update PDP Context procedure to update the IP Address and TEID for Uplink and Downlink data.
If Routing Area Update occurs, then the following CAMEL procedure calls shall be performed (see referenced
procedures in TS 23.078 [29]):
NOTE 14:This CAMEL handling is unmodified compared to pre-Rel-8.
NOTE 15:CAMEL procedure calls C2 and C3 were omitted intentionally from this procedure since EPS does not
support CAMEL procedure calls.
NOTE 16:Handover Reject procedure is performed as defined in clause 5.5.2.2.4.
D.3.5 Routing Area Update

The Routing Area Update procedure takes place when a UE that is registered with an MME selects a UTRAN or
GERAN cell served by a Gn/Gp SGSN. In this case, the UE changes to a Routing Area that the UE has not yet
registered with the network. This procedure is initiated by an idle state or by a connected state UE. The Routing Area
Update procedure is illustrated in Figure D.3.5-1.
Any step descriptions that are taken from TS 23.060 [7] for a Gn/Gp SGSN are shown as italic text and remain
unmodified. In that step descriptions an MS stands for UE, old SGSN for old MME and GGSN for P-GW. The old
MME behaves towards the new Gn/Gp SGSN always like an old Gn/Gp 3G-SGSN, regardless of whether the new
Gn/Gp SGSN is a 2G-SGSN or a 3G-SGSN.
3GPP
Release 15 359 3GPP TS 23.401 V15.10.0 (2019-12)
MS eNodeB new SGSN old MME S-GW P-GW HSS
0. UE changes to UTRAN or GERAN
1. Routeing Area Update Request
2. SGSN Context Request
2. SGSN Context Response

3. Security Functions
4. SGSN Context Acknowledge
old SGSN
7. Update Location
8. Cancel Location
C2
C3
12. Routeing Area Update Complete 13. Change Notification

13. S1-AP: S1 Release
Figure D.3.5-1: Routing Area Update procedure
network or the UE reselects a UTRAN or GERAN cell and the TIN indicates "GUTI". The UE in
1. The MS sends a Routing Area Update Request (old P-TMSI, old RAI, old P-TMSI Signature, Update Type,
follow on request, Classmark, MS Network Capability, additional P-TMSI/RAI, KSI) to the new SGSN. Update
Type shall indicate RA update, periodic RA update, Combined RA / LA Update or Combined RA / LA Update
with IMSI attach requested. The BSS shall add the Cell Global Identity including the RAC and LAC of the cell
where the message was received before passing the message to the SGSN. The SRNC shall add the Routing Area
Identity before forwarding the message to the 3G-SGSN. Classmark contains the MS GPRS multislot
capabilities and supported GPRS ciphering algorithms as defined in TS 24.008 [47]. The SGSN may use, as an
implementation option, the follow-on request indication to release or keep the Iu connection after the completion
of the RA update procedure.
If the UE's TIN indicates "GUTI" and the UE holds a valid GUTI then the UE indicates the GUTI as the old
P-TMSI and old RAI. If the UE's TIN indicates "P-TMSI" or "RAT-related TMSI" and the UE holds a valid
3GPP
Release 15 360 3GPP TS 23.401 V15.10.0 (2019-12)
mapped from a GUTI, then the UE indicates these parameters as additional P-TMSI/RAI. The Gn/Gp SGSN
shall ignore this additional P-TMSI/RAI.
mobility.
KSI is mapped from an eKSI indentifying a KASME if the UE indicates a P-TMSI mapped from GUTI in the
2. The new SGSN sends SGSN Context Request (old RAI, TLLI or old P-TMSI, old P-TMSI Signature, New SGSN
Address) to the old SGSN to get the MM and PDP contexts for the MS. If the new SGSN provides functionality
for Intra Domain Connection of RAN Nodes to Multiple CN Nodes, the new SGSN may derive the old SGSN
from the old RAI and the old P-TMSI (or TLLI) and send the SGSN Context Request message to this old SGSN.
Otherwise, the new SGSN derives the old SGSN from the old RAI. In any case the new SGSN will derive an
SGSN that it believes is the old SGSN. This derived SGSN is itself the old SGSN, or it is associated with the same
pool area as the actual old SGSN and it will determine the correct old SGSN from the P-TMSI (or TLLI) and
relay the message to that actual old SGSN.
NOTE 2: A GUTI mapped to a P-TMSI/RAI provides an old RAI that uniquely identifies an old MME then there is
no need to relay between MME in the old pool, regardless whether the new SGSN supports such
functionality or not. Mapping a GUTI to a P-TMSI and an RAI is specified in Annex H.
The old SGSN validates the old P-TMSI Signature and responds with an appropriate error cause if it does not
match the value stored in the old SGSN. This should initiate the security functions in the new SGSN. If the
security functions authenticate the MS correctly, the new SGSN shall send an SGSN Context Request (old RAI,
TLLI, MS Validated, New SGSN Address) message to the old SGSN. MS Validated indicates that the new SGSN
has authenticated the MS. If the old P-TMSI Signature was valid or if the new SGSN indicates that it has
authenticated the MS, the old SGSN starts a timer. If the MS is not known in the old SGSN, the old SGSN
responds with an appropriate error cause.
If the UE uses power saving functions and the old MME indicates Buffered DL Data Waiting, the new SGSN
invokes data forwarding and user plane setup corresponding to clause 5.3.3.1A.
NOTE 3: For the new SGSN, this step is unmodified compared to pre-Rel-8. The MME (called old SGSN in above
description) needs to provide SGSN functionality.
2b. The old 3G SGSN responds with an SGSN Context Response (MM Context, PDP Contexts) message. For each
PDP context the old 3G-SGSN shall include the GTP sequence number for the next uplink GTP PDU to be
tunnelled to the GGSN and the next downlink GTP sequence number for the next PDU to be sent to the MS.
Each PDP Context also includes the PDCP sequence numbers if PDCP sequence numbers are received from the
old SRNS. The new 3G-SGSN shall ignore the MS Network Capability contained in MM Context of SGSN
Context Response only when it has previously received an MS Network Capability in the Routing Area Request.
The GTP sequence numbers received from the old 3G-SGSN are only relevant if delivery order is required for
the PDP context (QoS profile).
NOTE 4: This step is for the Gn/Gp SGSN unmodified compared to pre-Rel-8. The MME (old SGSN in this step)
maps EPS bearers one-to-one to PDP contexts and provides the Release 99 parameters of the bearer QoS
profile to the new SGSN. The Gn signalling between the new Gn/Gp SGSN and the old CN node has no
capabilities to indicate ISR Activated or ISR Supported. The GTP and PDCP sequence numbers are not
relevant as the network does not configure usage of "delivery order required" and does not configure loss
less UTRAN PDCP as described in clause "compatibility issues".
3GPP
Release 15 361 3GPP TS 23.401 V15.10.0 (2019-12)
For UE using CIoT EPS Optimisation without any activated PDN connection, there is no PDP Context(s)
included in the SGSN Context Response message.
The MME (old SGSN in this step) only transfers the PDP Context(s) that the new SGSN supports. If not
supported, PDP Context(s) of non-IP PDN connection are not transferred to the new SGSN. If the PDP
Context(s) of a PDN connection has not been transferred, the MME shall consider all bearers of that PDN
connection as failed and release that PDN connection by triggering the MME requested PDN disconnection
3. Security functions may be executed. These procedures are defined in clause "Security Function" in
TS 23.060 [7]. Ciphering mode shall be set if ciphering is supported. If the SGSN Context Response message
did not include IMEISV and ADD is supported by the SGSN, the SGSN retrieves the IMEISV from the MS.
If the security functions fail (e.g. because the SGSN cannot determine the HLR address to establish the Send
Authentication Info dialogue), the Inter SGSN RAU Update procedure fails. A reject shall be returned to the MS
with an appropriate cause.
4. The new SGSN sends an SGSN Context Acknowledge message to the old SGSN. The old MME (which is the old
SGSN from the new SGSN's point of view) marks in its context that the information in the GWs and the HSS are
invalid. This triggers the GWs, and the HSS to be updated if the UE initiates a Tracking Area Update procedure
back to the old MME before completing the ongoing Routing Area Update procedure. If the security functions
do not authenticate the MS correctly, then the routing area update shall be rejected, and the new SGSN shall
send a reject indication to the old SGSN. The old MME shall continue as if the SGSN Context Request was
never received.
NOTE 6: The new SGSN's operation is unmodified compared to pre-Rel-8. The old MME/S-GW (old SGSN from
the new SGSN's point of view) does not forward any data towards the new SGSN.
5. Void.
6. The new SGSN sends Update PDP Context Request (new SGSN Address, TEID, QoS Negotiated, serving
network identity, CGI/SAI, User CSG Information, RAT type, MS Info Change Reporting support indication,
NRSN) to the GGSNs concerned. The SGSN shall send the serving network identity to the GGSN. NRSN
indicates SGSN support of the network requested bearer control. The SGSN shall only indicate that it supports
the procedure if it supports it and it is indicated that the MS also supports it in the SGSN Context Response
message as described above. If the NRSN is not included in the Update PDP Context Request message the
GGSN shall, following this procedure, perform a GGSN-Initiated PDP Context Modification to change the BCM
to 'MS-Only' for all PDP-Address/APN-pairs for which the current BCM is 'MS/NW'. The GGSNs update their
PDP context fields and return Update PDP Context Response (TEID, Prohibit Payload Compression, APN
Restriction, MS Info Change Reporting Action, CSG Information Reporting Action, BCM). The Prohibit Payload
Compression indicates that the SGSN should negotiate no data compression for this PDP context.
For UE using CIoT EPS Optimisation without any activated PDN connection, the steps 6 and 13 are skipped.
7. The new SGSN informs the HLR of the change of SGSN by sending Update Location (SGSN Number, SGSN
Address, IMSI, IMEISV, Update Type, Homogenous Support of IMS Voice over PS Sessions) to the HLR.
IMEISV is sent if the ADD function is supported. Update Type indicates "normal update". For "Homogenous
Support of IMS Voice over PS Sessions", see clause 5.3.8A of TS 23.060 [7].
NOTE 10:This step is unmodified compared to pre-Rel-8. Clarification about update type added to show that this is
the trigger for the HSS to cancel only an old SGSN and not also an old MME.
8. The HLR sends Cancel Location (IMSI, Cancellation Type) to any old SGSN with Cancellation Type set to
Update Procedure. The old SGSN removes the MM and EPS bearer contexts. The old SGSN acknowledges with
Cancel Location Ack (IMSI).
NOTE 11:For the Gn/Gp SGSN the HSS interoperation is unmodified compared to earlier standards Releases.
9. The HLR sends Insert Subscriber Data (IMSI, GPRS Subscription Data) to the new SGSN. The new SGSN
validates the UE's presence in the (new) RA. If due to regional subscription restrictions or access restrictions
the MS is not allowed to be attached in the RA, the SGSN rejects the Routing Area Update Request with an
3GPP
Release 15 362 3GPP TS 23.401 V15.10.0 (2019-12)
appropriate cause, and may return an Insert Subscriber Data Ack (IMSI, SGSN Area Restricted) message to the
HLR. If the network supports the MOCN configuration for network sharing, the SGSN may, if the MS is not a
'Network Sharing Supporting MS', in this case decide to initiate redirection by sending a Reroute Command to
the RNS, as described in TS 23.251 [24] instead of rejecting the Routing Area Update Request. If all checks are
successful, the SGSN constructs an MM context for the MS and returns an Insert Subscriber Data Ack (IMSI)
message to the HLR.
10. The HLR acknowledges the Update Location by sending Update Location Ack (IMSI) to the new SGSN.
11. If the new SGSN is a 2G-SGSN: The new SGSN validates the MS's presence in the new RA. If due to roaming
restrictions or access restrictions the MS, is not allowed to be attached in the SGSN, or if subscription checking
fails, the new SGSN rejects the routing area update with an appropriate cause. If all checks are successful, the
new SGSN constructs MM and PDP contexts for the MS. A logical link is established between the new SGSN
and the MS. The new SGSN responds to the MS with Routing Area Update Accept (P-TMSI, P-TMSI Signature,
Receive N-PDU Number, PDP context status). Receive N-PDU Number contains the acknowledgements for
each acknowledged-mode NSAPI used by the MS, thereby confirming all mobile-originated N-PDUs
successfully transferred before the start of the update procedure.
If the new SGSN is a 3G-SGSN: The new SGSN validates the MS's presence in the new RA. If due to roaming
restrictions or access restrictions the MS is not allowed to be attached in the RA, or if subscription checking
fails, the SGSN rejects the routing area update with an appropriate cause. If the network supports the MOCN
configuration for network sharing, the SGSN may, if the MS is not a 'Network Sharing Supporting MS', in this
case decide to initiate redirection by sending a Reroute Command to the RNS, as described in TS 23.251 [24]
instead of rejecting the routing area update. If all checks are successful, the new SGSN establishes MM context
for the MS. The new SGSN responds to the MS with Routing Area Update Accept (P-TMSI, VLR TMSI, P-TMSI
Signature).
For a MS with ongoing emergency bearer services, the new 3G-SGSN accepts the Routing Area Update Request
and deactivates the non-emergency PDP contexts as specified in clause 9.2.4.2 in TS 23.060 [7].
When receiving the RAU Accept message and there is no ISR Activated indication the UE shall set its TIN to
"P-TMSI".
With the PDP context status information, the MS shall deactivate all those bearers contexts locally which are
active in the MS, but are indicated by the SGSN as being inactive.
NOTE 13a: A Gn/Gp SGSN never indicates ISR Activated as it does not support ISR.
NOTE 14:For the SGSN this step is unmodified compared earlier standards Releases. N-PDU numbers are not
relevant as the network does not configure usage of acknowledged mode NSAPIs as described in clause
"compatibility issues".
12. If the new SGSN is a 2G-SGSN: The MS acknowledges the new P-TMSI by returning a Routing Area Update
Complete (Receive N-PDU Number) message to the SGSN. Receive N-PDU Number contains the
acknowledgements for each acknowledged-mode NSAPI used by the MS, thereby confirming all mobile-
terminated N-PDUs successfully transferred before the start of the update procedure. If Receive N-PDU
Number confirms reception of N-PDUs that were forwarded from the old SGSN, these N-PDUs shall be
discarded by the new SGSN. LLC and SNDCP in the MS are reset.
If the new SGSN is a 3G-SGSN: The MS confirms the reallocation of the TMSIs by returning a Routing Area
Update Complete message to the SGSN.
NOTE 15:This step is unmodified compared to pre-Rel-8. N-PDU numbers are not relevant as the network does not
configure usage of acknowledged mode NSAPIs as described in clause "compatibility issues".
13. When the timer started in step 2) expires the old MME releases any RAN and Serving GW resources. If the
PLMN has configured Secondary RAT usage data reporting, the MME first releases RAN resource before
releasing Serving GW resources.
When the MME receives Secondary RAT usage data from eNodeB in the S1 UE Context Release complete
message, the MME continues with the Secondary RAT usage data reporting procedure using change notification
3GPP
Release 15 363 3GPP TS 23.401 V15.10.0 (2019-12)
message as described in clause 5.7A.3. The reporting procedure in clause 5.7A.3 is only performed if PGW
The old MME deletes the EPS bearer resources by sending Delete Session Request (Cause; Operation Indication,
Secondary RAT usage data) messages to the Serving GW. The operation Indication flag is not set, that indicates
to the old Serving GW that the old Serving GW shall not initiate a delete procedure towards the PDN GW.
Secondary RAT usage data is included if it was received from the source eNodeB in the S1 UE Context Release
complete message. The old MME derives from the GTPv1 context transfer signalling that the new SGSN is a
Gn/Gp SGSN and therefore any old S-GW resources are released by the old MME. A Gn/Gp SGSN does not
signal any S-GW change. If the old S-GW has due to ISR a control connection with another CN node (MME or
SGSN) the cause indicates to the old S-GW that the old S-GW shall delete the bearer resources on the other old
CN node by sending Delete Bearer Request message(s) to that other old CN node.
If the old MME has an S1-MME association for the UE, the source MME sends a S1-U Release Command to the
source eNodeB when receiving the SGSN Context Acknowledge message from the new SGSN. The RRC
connection is released by the source eNodeB. The source eNodeB confirms the release of the RRC connection
and of the S1-U connection by sending a S1-U Release Complete message to the source MME. If the PLMN has
configured Secondary RAT usage data reporting and the source eNodeB has Secondary RAT usage data to
report, the source eNodeB includes Secondary RAT usage data in this message.
NOTE 16:The new SGSN may initiate RAB establishment after execution of the security functions, or wait until
completion of the RA update procedure. For the MS, RAB establishment may occur anytime after the
Routing Area Update Request is sent.
In the case of a rejected routing area update operation, due to regional subscription, roaming restrictions, access
restrictions (see TS 23.221 [27] and TS 23.008 [28]) or because the SGSN cannot determine the HLR address to
establish the locating updating dialogue, the new SGSN shall not construct an MM context. A reject shall be returned to
the MS with an appropriate cause and the PS signalling connection shall be released. Upon return to idle, the MS shall
act according to TS 23.122 [10].
If the network supports the MOCN configuration for network sharing, the SGSN may, if the MS is not a 'Network
Sharing Supporting MS', in this case decide to initiate redirection by sending a Reroute Command to the RNS, as
described in TS 23.251 [24] instead of rejecting the routing area update.
If the new SGSN is unable to update the PDP context in one or more GGSNs, the new SGSN shall deactivate the
corresponding PDP contexts as described in clause "SGSN-initiated PDP Context Deactivation Procedure". This shall
not cause the SGSN to reject the routing area update.
The PDP Contexts shall be sent from old to new SGSN in a prioritized order, i.e. the most important PDP Context first
in the SGSN Context Response message. (The prioritization method is implementation dependent, but should be based
on the current activity).
If the new SGSN is unable to support the same number of active PDP contexts as received from old SGSN, the new
SGSN should use the prioritisation sent by old SGSN as input when deciding which PDP contexts to maintain active
and which ones to delete. In any case, the new SGSN shall first update all contexts in one or more GGSNs and then
deactivate the context(s) that it cannot maintain as described in clause "SGSN-initiated PDP Context Deactivation
Procedure". This shall not cause the SGSN to reject the routing area update.
NOTE 17:In case MS was in PMM-CONNECTED state the PDP Contexts are sent already in the Forward
TS 23.060 [7].
If the routing area update procedure fails a maximum allowable number of times, or if the SGSN returns a Routing
Area Update Reject (Cause) message, the MS shall enter IDLE state.
NOTE 18:The C1 CAMEL procedure call was omitted intentionally from this procedure since EPS does not support
CAMEL procedure calls. The other CAMEL procedure calls are unmodified compared to pre-Rel-8.
The CAMEL procedure calls shall be performed, see referenced procedures in TS 23.078 [29]:
C2) CAMEL_GPRS_Routing_Area_Update_Session and CAMEL_PS_Notification.
3GPP
Release 15 364 3GPP TS 23.401 V15.10.0 (2019-12)
- The CAMEL_GPRS_Routing_Area_Update_Session procedure is called. The procedure returns as result

"Continue".
- Then the CAMEL_PS_Notification procedure is called. The procedure returns as result "Continue".
C3) CAMEL_GPRS_Routing_Area_Update_Context.
D.3.6 Gn/Gp SGSN to MME Tracking Area Update

The Gn/Gp SGSN to MME Tracking Area Update procedure is illustrated in Figure D.3.6-1.
Any steps descriptions that are from TS 23.060 [7] are shown as italic text and remain unmodified. In those step
descriptions an MS stands for UE, new SGSN for new MME, old SGSN for old Gn/Gp SGSN, GGSN for P-GW, and
HLR for HSS. The new MME behaves towards the old Gn/Gp SGSN always like a Gn/Gp 3G-SGSN, regardless of
whether the old Gn/Gp SGSN is a 2G-SGSN or a 3G-SGSN.
3GPP
Release 15 365 3GPP TS 23.401 V15.10.0 (2019-12)
RNC Gn/Gp Serving Old PDN

UE eNodeB BSC MME SGSN GW MME GW PCRF HSS
1. Trigger to start
TAU procedure
4. SGSNContext Request
5. SGSN Context Response
6. Security procedures
7. SGSN Context Acknowledge
C1
10. Modify Bearer Request (A)


13.Create Session Response

15. Cancel Location

17. Cancel Location

22. Tracking Area Update Accept
23. Tracking Area Update Complete
Figure D.3.6-1: Gn/Gp SGSN to MME Tracking Area Update procedure
NOTE 1: For a PMIP-based S5/S8, procedure steps (A) are defined in TS 23.402 [2]. Steps 13 and 15 concern GTP
based S5/S8.
2. The UE sends to the eNodeB a Tracking Area Update Request (last visited TAI, P-TMSI Signature, old GUTI,
UE Core Network Capability, Preferred Network behaviour, active flag, EPS bearer status, additional GUTI,
eKSI, NAS sequence number, NAS-MAC, KSI) message together with RRC parameters indicating the Selected
Network and the old GUMMEI.
3GPP
Release 15 366 3GPP TS 23.401 V15.10.0 (2019-12)
then these two elements are indicated as the old GUTI. Mapping a P-TMSI and an RAI to a GUTI is specified in
Annex H.
indicates the native GUTI. If the old GUTI indicates a GUTI mapped from a P-TMSI and RAI, and the UE has a
valid P-TMSI signature, the P-TMSI signature shall be included.
GUTIs that are generated by the UE's mapping of the P-TMSIs allocated by the combined node. Such an
eNodeB configuration may also be used for separate nodes to avoid changing nodes in the pool caused by inter
RAT mobility.
NOTE 2: In the scenario of this flow the UE's TIN indicates "P-TMSI" and therefore the UE indicates a P-TMSI as
the old GUTI.
The last visited TAI is included if the UE has any in order to help the MME to produce a good list of TAIs for
any subsequent TAU Accept message. Selected Network indicates the network that is selected. Active flag is a
request by UE to activate the radio and S1 bearers for all the active EPS Bearers by the TAU procedure. The
EPS bearer status indicates each EPS bearer that is active within the UE. The UE's ISR capability is included in
the UE Core Network Capability element.
If the UE has valid EPS security parameters, the TAU Request message shall be integrity protected by the
NAS-MAC in order to allow validation of the UE by the MME. eKSI, NAS sequence number and NAS-MAC
are included if the UE has valid EPS security parameters. NAS sequence number indicates the sequential number
of the NAS message. KSI is included if the UE indicates a GUTI mapped from a P-TMSI in the information
element "old GUTI".
Selected Network and the RAT (NB-IoT or WB-E-UTRAN). If that GUMMEI is not associated with the
eNodeB, or the GUMMEI is not available, the eNodeB selects the MME as described in clause 4.3.8.3 on "MME
Selection Function".
The eNodeB forwards the TAU Request message together with the TAI+ECGI and RAT type of the cell from
where it received the message and with the Selected Network to the MME.
The RAT type shall distinguish between NB-IoT and WB-E-UTRAN types.
4. The new MME sends SGSN Context Request (old RAI, P-TMSI, old P-TMSI Signature, New SGSN Address)
to the old SGSN to get the MM and PDP contexts for the UE.
The new MME shall support functionality for Intra Domain Connection of RAN Nodes to Multiple CN Nodes,
i.e. the MME derives the old SGSN from the old RAI and the old P-TMSI (or TLLI).
When the internal structure of the pool area where the MS roamed from is not known, the new MME derives the
old SGSN from the old RAI as described at clause 5.8 in TS 23.060 [7]. For this case, the new MME derives an
SGSN that it believes is the old SGSN. This derived SGSN is itself the old SGSN, or it is associated with the
same pool area as the actual old SGSN and it will determine the correct old SGSN from the P-TMSI (or TLLI)
and relay the message to that actual old SGSN.
5. If the old SGSN is a 2G-SGSN: The old 2G-SGSN validates the old P-TMSI Signature and responds with an
appropriate error cause if it does not match the value stored in the old 2G SGSN. This should initiate the
security functions in the new SGSN. If the security functions authenticate the MS correctly, the new SGSN shall
send an SGSN Context Request (old RAI, old PTMSI, MS Validated, New SGSN Address) message to the old
SGSN. MS Validated indicates that the new SGSN has authenticated the MS. If the old P-TMSI Signature was
valid or if the new SGSN indicates that it has authenticated the MS, the old SGSN stops assigning SNDCP
3GPP
Release 15 367 3GPP TS 23.401 V15.10.0 (2019-12)
N-PDU numbers to downlink N-PDUs received, and responds with SGSN Context Response (MM Context, PDP
Contexts). If the MS is not known in the old SGSN, the old SGSN responds with an appropriate error cause. The
old SGSN stores New SGSN Address, to allow the old SGSN to forward data packets to the new SGSN. Each
PDP Context includes the SNDCP Send N-PDU Number for the next downlink N-PDU to be sent in
acknowledged mode to the MS, the SNDCP Receive N-PDU Number for the next uplink N-PDU to be received
in acknowledged mode from the MS, the GTP sequence number for the next downlink N-PDU to be sent to the
MS and the GTP sequence number for the next uplink N-PDU to be tunnelled to the GGSN. The old SGSN starts
a timer and stops the transmission of N-PDUs to the MS. The new SGSN shall ignore the MS Network
Capability contained in MM Context of SGSN Context Response only when it has previously received an MS
Network Capability in the Routing Area Request.
If the old SGSN is a 3G-SGSN: The old 3G-SGSN validates the old P-TMSI Signature and responds with an
appropriate error cause if it does not match the value stored in the old SGSN. This should initiate the security
functions in the new SGSN. If the security functions authenticate the MS correctly, the new SGSN shall send an
SGSN Context Request (IMSI, old RAI, MS Validated) message to the old 3G-SGSN. MS Validated indicates that
the new SGSN has authenticated the MS. If the old P-TMSI Signature was valid or if the new SGSN indicates
that it has authenticated the MS, the old SGSN starts a timer. If the MS is not known in the old SGSN, the old
3G-SGSN responds with an appropriate error cause.
The old 3G SGSN responds with an SGSN Context Response (MM Context, PDP Contexts) message. For each
PDP context the old 3G SGSN shall include the GTP sequence number for the next uplink GTP PDU to be
tunnelled to the GGSN and the next downlink GTP sequence number for the next PDU to be sent to the MS.
Each PDP Context also includes the PDCP sequence numbers if PDCP sequence numbers are received from the
old SRNS. The new 3G-SGSN shall ignore the MS Network Capability contained in MM Context of SGSN
Context Response only when it has previously received an MS Network Capability in the Routing Area Request.
The GTP sequence numbers received from the old 3G-SGSN are only relevant if delivery order is required for
the PDP context (QoS profile).
If the UE uses power saving functions and the DL Data Buffer Expiration Time for the UE has not expired, the
old Gn/Gp-SGSN indicates Buffered DL Data Waiting. When this is indicated, the new MME invokes data
forwarding and user plane setup corresponding to clause 5.3.3.1A.
NOTE 3: In this step, the new "SGSN" shall be understood to be a new "MME" and the old SGSN stores new
SGSN Address, to allow the old SGSN to forward data packets to the new "S-GW or eNodeB". This step
describes both the 2G and 3G SGSN variants due to combining the 2G or 3G SGSN to MME TAU into a
single procedure.
NOTE 4: For the old SGSN, this step is unmodified compared to pre-Rel-8. The MME (called new SGSN in above
description) must provide SGSN functionality which includes mapping PDP contexts to EPS bearer
information. SNDCP, GTP and PDCP sequence numbers are not relevant for the MME as the network
does not configure usage of "delivery order required", does not configure acknowledged mode NSAPIs
(SNDCP) and does not configure loss less UTRAN PDCP as described in clause "compatibility issues".
6. Security functions may be executed. Procedures are defined in clause 5.3.10 on Security Function. If the SGSN
Context Response message from the old SGSN did not include IMEISV, the MME shall retrieve the ME Identity
(the IMEISV) from the UE.
7. If the new MME identifies that the RAT type has changed, the MME checks the subscription information to
reactivation request, or, disconnect the PDN connection without reactivation request. If the MME decides to
deactivate a PDN connection it performs MME-initiated PDN Connection Deactivation procedure after the
tracking area update procedure is completed but before the S1/RRC interface connection is released. Existing
ESM cause values as specified in TS 24.301 [46] (e.g. #39, "reactivation requested"; #66 "Requested APN not
supported in current RAT and PLMN combination"; and for a dedicated bearer, possibly #37 "EPS QoS not
accepted") are used to cause predictable UE behaviour. If all the PDN connections are disconnected and the UE
does not support "attach without PDN connectivity", the MME shall request the UE to detach and reattach.
The new MME sends an SGSN Context Acknowledge message to the old SGSN. This informs the old SGSN that
the new SGSN is ready to receive data packets belonging to the activated PDP contexts. The old SGSN marks in
3GPP
Release 15 368 3GPP TS 23.401 V15.10.0 (2019-12)
its context that the MSC/VLR association and the information in the GGSNs and the HLR are invalid. This
triggers the MSC/VLR, the GGSNs, and the HLR to be updated if the MS initiates a Routing area update
procedure back to the old SGSN before completing the ongoing routing area update procedure.
If the security functions do not authenticate the UE correctly, then the Tracking area update shall be rejected, and
the new MME shall send a reject indication to the old SGSN. The old SGSN shall continue as if the SGSN
Context Request was never received.
NOTE 5: in the italic text of this step, new "SGSN" shall be understood as to be a new "MME". The MME needs to
map PDP contexts received from Gn/Gp SGSN into EPS bearer information. The GGSN address(es) and
TEIDs map to the PDN GW address(es) and TEIDs respectively. . The MME maps PDP contexts to EPS
bearers one-to-one and it translates the release 99 QoS parameters to the EPS bearer QoS parameters.
NOTE 6: The SGSN operation is unmodified compared to pre-Rel-8. The MME indicates reserved TEID and IP
address parameters from an S-GW to the old SGSN so that the old Gn/Gp SGSN can forward data
packets when needed. The S-GW discards any packets received from old Gn/Gp SGSN.
NOTE 7: The Gn signalling between the new MME and the old Gn/Gp SGSN has no capabilities to indicate ISR
Supported or ISR Activated.
If there is no PDP context at all and the CIoT EPS Optimisation without PDN connection is not applied, the
MME rejects the TAU Request.
For UE using CIoT EPS Optimisation without any activated PDN connection, the steps 9, 10, 11, 12 and 13 are
skipped.
8. The old SGSN or the old RNC forward data to the S-GW and the S-GW discards these data.
9. The new MME adopts the bearer contexts received from the SGSN as the UE's EPS bearer contexts to be
maintained by the new MME. The new MME maps the PDP contexts to the EPS bearers 1-to-1 and maps the
Release 99 QoS parameter values of a PDP context to the EPS Bearer QoS parameter values of an EPS bearer as
defined in Annex E. The MME establishes the EPS bearer(s) in the indicated order. The MME deactivates the
EPS bearers which cannot be established.
The MME verifies the EPS bearer status received from the UE with the bearer contexts received from the old
SGSN and releases any network resources related to EPS bearers that are not active in the UE. If the UE has no
PDP context, the MME rejects the TAU Request.
The new MME selects a Serving GW and sends an Create Session Request (IMSI, MME Address and TEID,
PDN GW address and TEID, EPS Bearer QoS, serving network identity, ME Identity, User Location
Information IE, UE Time Zone IE, User CSG Information IE, RAT type, MS Info Change Reporting support
indication, NRS (received from the SGSN)) message per PDN connection to the Serving GW. The MME shall
send the serving network identity to the Serving GW. The new MME does not indicate ISR Activated.
10. The Serving GW creates contexts and informs the PDN GW(s) about the change of the RAT type. The Serving
GW sends a Modify Bearer Request (Serving GW Address and TEID, RAT type, ME Identity, User Location
Information IE, UE Time Zone IE, User CSG Information IE, MS Info Change Reporting support indication,
PDN Charging Pause Support indication) message per PDN connection to the PDN GW(s) concerned.
11. If dynamic PCC is deployed, and RAT type information needs to be conveyed from the PDN GW to the PCRF,
then the PDN GW shall send RAT type information to the PCRF by performing an IP-CAN Session
Modification procedure as defined in TS 23.203 [6].
12. The PDN GW updates its context field and returns a Modify Bearer Response (PDN GW address and TEID,
MSISDN, Default bearer id, Charging Id, MS Info Change Reporting Action (Start) (if the PDN GW decides to
receive UE's location information during the session), CSG Information Reporting Action (Start) (if the PDN
GW decides to receive UE's User CSG information during the session), PDN Charging Pause Enabled indication
(if PDN GW has chosen to enable the function), APN Restriction) message to the Serving GW. The MSISDN is
included if the PDN GW has it stored in its UE context. When the UE moves from Gn/Gp SGSN to the MME,
the PDN GW shall send the APN restriction of each bearer context to the Serving GW.
3GPP
Release 15 369 3GPP TS 23.401 V15.10.0 (2019-12)
13. The Serving GW updates its context and returns an Create Session Response (Serving GW address and TEID for
user plane, PDN GW address and TEID, Serving GW Address and TEID for the control plane, Default bearer id,
APN restriction) message to the new MME. The message also includes MS Info Change Reporting Action
(Start) and/or CSG Information Reporting Action (Start) if they are included in step 12. The Serving GW shall
forward the received APN Restriction to the MME.
When the MME receives the Create Session Response message, the MME checks if there is a "Availability after
DDN Failure" monitoring event or a "UE Reachability" monitoring event configured for the UE in the MME and
in such a case sends an event notification (see TS 23.682 [74] for further information).
14. To ensure the release of all UE resources in the Gn/Gp SGSN the new MME informs the HSS of the change of
the serving core network node by sending an Update Location Request (MME Address, IMSI, ME Identity,
ULR-Flags, MME Capabilities, Homogenous Support of IMS Voice over PS Sessions) message to the HSS. The
ME Identity is included if the SGSN Context Response did not contain the IMEISV. Because of interoperation
with an Gn/Gp SGSN, which the new MME identifies from the GTPv1 Context Response signalling, the ULR-
Flags indicates "Single-Registration-Indication". The MME capabilities indicate the MME's support for regional
access restrictions functionality. For "Homogenous Support of IMS Voice over PS Sessions", see
clause 4.3.5.8A.
15. If the MME changes, then the HSS cancels any old MME. The HSS sends a Cancel Location (IMSI,
Cancellation type) message to the old MME, with a Cancellation Type set to Update Procedure.
16. The old MME removes the MM context.
The old MME releases any local bearer resources and it deletes the EPS bearer resources by sending Delete
Session Request (Cause, Operation Indication) messages to the Serving GW. The operation Indication flag is not
set, that indicates that the S-GW shall not initiate a delete procedure towards the PDN GW. If ISR is activated
then the cause indicates to the old S-GW that the old S-GW shall delete the bearer resources on the other old CN
node by sending Delete Bearer Request message(s) to that CN node.
The old MME acknowledges with a Cancel Location Ack (IMSI) message.
17. The HSS cancels any old SGSN node as the ULR-Flags indicates "Single-Registration-Indication". The HSS
sends a Cancel Location (IMSI, Cancellation Type) message to the old SGSN. The old SGSN removes the
contexts.
If the timer started in step 5 is not running, the old SGSN removes the MM context. Otherwise, the contexts are
removed when the timer expires. It also ensures that the MM context is kept in the old SGSN for the case the UE
initiates another TAU procedure before completing the ongoing TAU procedure to the new MME.
NOTE 9: In all other mobility scenarios a new CN node initiates only cancellation of an old CN node of the same
type via HSS. In this scenario here (Gn/Gp SGSN to MME TAU) the new MME, by indicating single
registration, initiates in addition the cancellation of the old Gn/Gp SGSN via HSS to make sure that any
PDP contexts of the UE are properly released. MME and S4 SGSN release PDP/PDN contexts based on
context transfer signalling.
18. On receipt of Cancel Location, if the MS is PMM CONNECTED in the old SGSN, the old SGSN sends an Iu
Release Command message to the old SRNC.
19. When the data-forwarding timer has expired, the SRNS responds with an Iu Release Complete message.
20. The old SGSN acknowledges with a Cancel Location Ack (IMSI) message.
21. The new MME validates the UE's presence in the (new) TA. If all checks are successful, the MME constructs an
MM context for the UE, the HLR acknowledges the Update Location by sending Update Location Ack (IMSI,
Subscription Data) message to the new MME. If the Update Location is rejected by the HSS, the MME rejects
the TAU Request from the UE with an appropriate cause sent in the TAU Reject message to the UE.
22. If due to regional subscription restrictions or access restrictions the UE is not allowed to access the TA:
- For UEs with ongoing emergency bearer services, the new MME accepts the Tracking Area Update Request
and releases the non-emergency bearers as specified in clause 5.10.3.
- For all other cases, the new MME rejects Tracking Area Update Request with an appropriate cause to the UE
and notifies the HSS of rejection (details of this notification is stage 3 detail).
3GPP
Release 15 370 3GPP TS 23.401 V15.10.0 (2019-12)
The new MME responds to the UE with a Tracking Area Update Accept (GUTI, TAI-list, EPS bearer status,
NAS sequence number, NAS-MAC, ISR Activated, Supported Network Behaviour) message. Restriction list
shall be sent to eNodeB as eNodeB handles the roaming restrictions and access restrictions in the Intra E-
UTRAN case.
If the "active flag" is set in the TAU Request message the user plane setup procedure can be activated in
conjunction with the TAU Accept message. The procedure is described in detail in TS 36.300 [5]. The messages
sequence should be the same as for the UE triggered Service Request procedure specified in clause 5.3.4.1 from
the step when MME establishes the bearer(s). If the active flag is set the MME may provide the eNodeB with
Handover Restriction List. Handover Restriction List is described in clause 4.3.5.7 "Mobility Restrictions". The
EPS bearer status indicates the active bearers in the network. The UE removes any internal resources related to
bearers not marked active in the received EPS bearer status. If the EPS bearer status information was in the TAU
Request, the MME shall indicate the EPS bearer status to the UE.
The MME indicates the CIoT optimisations it supports and prefers in the Supported Network Behaviour
"GUTI".
NOTE 10:In the case of interoperation with Gn/Gp SGSNs, ISR Activated is never indicated by the MME as the
SGSN does not support ISR, which the new MME recognises from Gn interface signalling that does not
support ISR indications.
permitted to use NR as a secondary RAT, Unlicensed Spectrum or a combination of them, then the MME sends
an updated Handover Restriction List in the Downlink NAS Transport message that it sends to E-UTRAN. If the
UE is not allowed to use NR as Secondary RAT, the MME indicates that to the UE in TAU Accept message.
23. If the GUTI was included in the TAU Accept message, the UE acknowledges the message by returning a
Tracking Area Update Complete message to the MME.
in ECM-CONNECTED state, the MME releases the signalling connection with UE, according to clause 5.3.5.
NOTE 11:The new MME may initiate E-RAB establishment (see TS 36.413 [36]) after execution of the security
functions (step 5), or wait until completion of the TA update procedure. For the UE, E-RAB
establishment may occur anytime after the TA update request is sent (step 2).
24. The target MME calculates UE-AMBR as defined in clause 4.7.3. If the local UE-AMBR provided by the MME
as defined in Annex E is different from the corresponding derived UE-AMBR, or the APN-AMBR mapped from
the subscribed MBR is different from the subscribed APN-AMBR, or the mapped subscribed QoS profile (i.e.
the subscribed QoS profile mapped according to Annex E) of the default bearer is different from the EPS
Subscribed QoS profile received from the HSS, the new MME shall initiate Subscribed QoS Modification
procedure as described in clause 5.4.2.2, Figure 5.4.2.2-1.
In the case of a rejected tracking area update operation, due to regional subscription, roaming restrictions, or access
restrictions (see TS 23.221 [27] and TS 23.008 [28]) the new MME should not construct a bearer context. In the case of
receiving the subscriber data from HSS, the new MME may construct an MM context and store the subscriber data for
the UE to optimise signalling between the MME and the HSS. A reject shall be returned to the UE with an appropriate
cause and the S1 connection shall be released. Upon return to idle, the UE shall act according to TS 23.122 [10].
If the new MME is unable to update the bearer context in one or more P-GWs, the new MME shall deactivate the
corresponding bearer contexts as described in clause "MME Initiated Dedicated Bearer Deactivation Procedure". This
shall not cause the MME to reject the tracking area update.
The PDP Contexts shall be sent from old SGSN to new SGSN (MME) in a prioritized order, i.e. the most important
PDP Context first in the SGSN Context Response message. (The prioritization method is implementation dependent, but
should be based on the current activity).
3GPP
Release 15 371 3GPP TS 23.401 V15.10.0 (2019-12)
context from the P-GW and then store the new Maximum APN restriction value.
If there are active EPS GBR bearers with maximum bitrate set to 0, the MME should initiate MME Initiated Dedicated
Bearer Deactivation (as specified in clause 5.4.4.2) to deactivate the related EPS bearer Context.
If the new MME is unable to support the same number of active bearer contexts as received from old SGSN, the new
MME should use the prioritisation sent by old SGSN as input when deciding which bearer contexts to maintain active
and which ones to delete. In any case, the new MME shall first update all contexts in one or more P-GWs and then
deactivate the context(s) that it cannot maintain as described in clause "MME Initiated Dedicated Bearer Deactivation
Procedure". This shall not cause the MME to reject the tracking area update.
NOTE 12:If MS (UE) was in PMM-CONNECTED state the PDP Contexts are sent already in the Forward
TS 23.060 [7].
If the Update Location Ack message indicates a reject, this should be indicated to the UE, and the UE shall not access
non-PS services until a successful location update is performed.
The CAMEL procedure calls shall be performed, see referenced procedures in TS 23.078 [29]:
C1) CAMEL_GPRS_PDP_Context_Disconnection, CAMEL_GPRS_Detach and CAMEL_PS_Notification.
- The CAMEL_GPRS_PDP_Context_Disconnection procedure is called several times: once per PDP context.
The procedure returns as result "Continue".
- Then the CAMEL_GPRS_Detach procedure is called once. The procedure returns as result "Continue".
- Then the CAMEL_PS_Notification procedure is called once. The procedure returns as result "Continue".
NOTE 13:This CAMEL handling is unmodified compared to pre-Rel-8.
NOTE 14:CAMEL procedure calls C2 and C3 were omitted intentionally from this procedure since EPS does not
support CAMEL procedure calls.
D.3.7 E-UTRAN to GERAN A/Gb mode Inter RAT handover

D.3.7.1 General
The interoperation procedures describe information flows for Gn/Gp SGSNs and other EPS network elements. All
messages between SGSN and MME, between SGSN and BSS, between SGSN and HSS and between SGSN and P-GW
(GGSN in TS 43.129 [8]) as well as the therein contained information elements are the same as specified for the
adequate TS 43.129 [8] procedures. These messages and procedure step descriptions are taken from TS 43.129 [8] for
explanatory purposes only. These descriptions are in italic text and shall not be modified by the interoperation
procedures. It cannot be assumed that the messages and procedure step descriptions that are taken from TS 43.129 [8]
will be updated when modifications or corrections are performed for TS 43.129 [8]. If there are any discrepancies for
these messages and procedure step descriptions TS 43.129 [8] takes precedence.
The messages between the MME and any other node than the Gn/Gp SGSN as well as the therein contained information
elements are the same as specified in the main body of this technical specification for the IRAT handover E-UTRAN
to/from GERAN A/Gb mode procedure (clauses 5.5.2.3 and 5.5.2.4). These descriptions are in bold italic text and
should be modified simultaneously when clauses 5.5.2.3 or 5.5.2.4 are updated. If there are any discrepancies, the
procedure step descriptions in clauses 5.5.2.3 or 5.5.2.4 take precedence.
3GPP
Release 15 372 3GPP TS 23.401 V15.10.0 (2019-12)
D.3.7.2 Preparation phase

Source
UE eNodeB Target BSS Source MME New SGSN Serving GW PDN GW HSS
5. Reservation of radio resources in target BSS
6. Target BSS creates the Target BSS to Source BSS Transparent Container
7. PS Handover Request Acknowledge
Figure D.3.7.2-1: E-UTRAN to GERAN A/Gb Inter RAT HO, preparation phase
1. The source eNodeB decides to initiate an Inter RAT Handover to the target GERAN A/Gb mode (2G) system.
At this point both uplink and downlink user data is transmitted via the following: Bearer(s) between UE and
Source eNodeB, GTP tunnel(s) between Source eNodeB, Serving GW and PDN GW.
If the UE has an ongoing emergency bearer service the source eNodeB shall not initiate PS handover to GERAN.
NOTE 1: The process leading to the handover decision is outside of the scope of this specification
2. The source eNodeB sends a Handover Required (Cause, Target System Identifier, Source BSS to Target BSS
Transparent Container) message to the Source MME to request the CN to establish resources in the Target
BSS, Target SGSN and the Serving GW. The bearers that will be subject to data forwarding (if any) are
identified by the new SGSN in a later step (see step 8 below).
The 'Target System Identifier' IE contains the identity of the target global cell Id.
NOTE 2: This step is unmodified compared to clause 5.5.2.3.2. The target SGSN acts as the new SGSN.
3 The old SGSN determines from the Target Cell Identifier that the type of handover is inter-RAT/mode handover.
In case of Inter-RAT/ mode Inter-SGSN PS handover, the old SGSN initiates the PS Handover resource
allocation procedure by sending a Forward Relocation Request (IMSI, Tunnel Endpoint Identifier Control
Plane, RANAP Cause, Target Cell Identifier, MM Context, PDP Contexts, Packet Flow ID, SNDCP XID
parameters, LLC XID parameters, PDP Context Prioritisation, Source BSS To Target BSS Transparent
Container [RN part] in the BSS Container, Source RNC Id, SGSN Address for control plane) message to the new
SGSN. If the old SGSN supports PS handover procedures then it has to allocate a valid PFI according to
clause 4.4.1 during the PDP Context activation procedure. Each PDP context contains the GGSN Address for
User Plane and the Uplink TEID for Data (to this GGSN Address and Uplink TEID for Data the old SGSN and
the new SGSN send uplink packets).
supported by the selected target SGSN, the old SGSN rejects the handover attempt by sending a Handover
Preparation Failure (Cause) message to the Source eNodeB.
NOTE 3: If the handover is successful, the old SGSN will signal to the SGW and/or SCEF to release any non-
released by the MS following the PDP Context Status synchronisation that occurs during the Routing
3GPP
Release 15 373 3GPP TS 23.401 V15.10.0 (2019-12)
TS 29.060 [14]. The relation between GSM and UMTS security parameters is defined in TS 33.102 [40],
The new SGSN selects the ciphering algorithm to use. This algorithm will be sent transparently from the new
SGSN to the MS. The IOV-UI parameter generated in the new SGSN and used, as input to the ciphering
procedure will also be transferred transparently from the new SGSN to the MS.
When the new SGSN receives the Forward Relocation Request message the required PDP, MM, SNDCP and
LLC contexts are established and a new P-TMSI is allocated for the MS. When this message is received by the
new SGSN it begins the process of establishing PFCs for all PDP contexts.
When the new SGSN receives the Forward Relocation Request message it extracts from the PDP Contexts the
NSAPIs and SAPIs and PFIs to be used in the new SGSN. If for a given PDP Context the new SGSN does not
receive a PFI from the old SGSN, it shall not request the target BSS to allocate TBF resources corresponding to
that PDP Context. If none of the PDP Contexts forwarded from the old SGSN has a valid PFI allocated the new
SGSN shall consider this as a failure case and the request for PS handover shall be rejected.
In case when an SAPI and PFI was available at the old SGSN but the new SGSN does not support the same
SAPI and PFI for a certain NSAPI as the old SGSN, the new SGSN shall continue the PS handover procedure
only for those NSAPIs for which it can support the same PFI and SAPI as the old SGSN. All PDP contexts for
which no resources are allocated by the new SGSN or for which it cannot support the same SAPI and PFI (i.e.
the corresponding NSAPIs are not addressed in the response message of the target SGSN), are maintained and
the related SAPIs and PFIs are kept. These PDP contexts may be modified or deactivated by the new SGSN via
explicit SM procedures upon RAU procedure.
The old SGSN shall indicate the current XID parameter settings if available (i.e. those negotiated at the old
SGSN when the MS was in A/Gb mode or received during a previous inter-SGSN PS handover) to the new
SGSN. If the new SGSN can accept all XID parameters as indicated by the old SGSN, the new SGSN shall create
a NAS container for PS HO indicating 'Reset to the old XID parameters'. Otherwise, if the new SGSN cannot
accept all XID parameters indicated by the old SGSN or if no XID parameters were indicated by the old SGSN,
the new SGSN shall create a NAS container for PS HO indicating Reset (i.e. reset to default parameters).
NOTE 4: This step is unmodified compared to pre-Rel-8. The Source eNodeB acts as the source RNC, Source
MME acts as the old SGSN, and the PDN GW acts as the GGSN.
4. The new SGSN sends a PS Handover Request (Local TLLI, IMSI, Cause, Target Cell Identifier, Source BSS to
Target BSS Transparent Container (RN part), PFCs To Be Set Up List, NAS container for PS HO) message to
the target BSS. The new SGSN shall not request resources for PFCs associated with PDP contexts with
maximum bit rate for uplink and downlink of 0 kbit/s or for which the Activity Status Indicator within the PDP
Context indicates that no active RAB exists on the source side.
5. Based upon the ABQP for each PFC the target BSS makes a decision about which PFCs to assign radio
resources. The algorithm by which the BSS decides which PFCs that need resources is implementation specific.
Due to resource limitations not all downloaded PFCs will necessarily receive resource allocation. The target
BSS allocates TBFs for each PFC that it can accommodate.
6. The target BSS shall prepare the Target BSS to Source BSS Transparent Container which contains a PS
Handover Command including the CN part (NAS container for PS HO) and the RN part (PS Handover Radio
Resources).
7. Target BSS shall send the PS Handover Request Acknowledge message (Local TLLI, List of Set Up PFCs,
Target BSS to Source BSS Transparent Container) message to the new SGSN. Upon sending the PS Handover
Request Acknowledge message the target BSS shall be prepared to receive downlink LLC PDUs from the new
SGSN for the accepted PFCs.
Any PDP contexts for which a PFC was not established are maintained in the new SGSN and the related SAPIs
and PFIs are kept. These PDP contexts may be modified or deactivated by the new SGSN via explicit SM
procedures upon the completion of the routing area update (RAU) procedure.
8. The new SGSN passes the assigned list of TEIDs for each PDP context for which a PFC was assigned in the
RAB setup information IE in the Forward Relocation Response (Cause, List of Set Up PFCs, Target BSS to
Source BSS Transparent Container) in the BSS Container, Tunnel Endpoint Identifier Control Plane, SGSN
Address for User Traffic, Tunnel Endpoint Identifier Data II) message to the old SGSN. The NSAPIs of the
3GPP
Release 15 374 3GPP TS 23.401 V15.10.0 (2019-12)
active PDP Contexts received in the Forward Relocation Request message for which the PS handover continues,
i.e. for which resources are allocated for the PFCs in the target BSS, are indicated in this message.
The Tunnel Endpoint Identifier Data II, one information for each PDP context, is the tunnel endpoint of the new
SGSN and is used for data forwarding from the Source eNodeB, via the new SGSN, to the target BSS.
The new SGSN activates the allocated LLC/SNDCP engines as specified in TS 44.064 [23] for an SGSN
originated Reset or 'Reset to the old XID parameters'.
When the old SGSN receives the Forward Relocation Response message and it decides to proceed with the
handover, the preparation phase is finished and the execution phase will follow.
9. If 'Indirect Forwarding' applies, the source MME sends a Create Indirect Data Forwarding Tunnel Request
message (Cause, SGSN Address(es) and TEID(s) for Data Forwarding) to the Serving GW. Cause indicates
that the bearer(s) are subject to data forwarding.
9a. The Serving GW returns a Create Indirect Data Forwarding Tunnel Response (Cause, Serving GW
Address(es) and TEID(s) for Data Forwarding) message to the target MME. If the Serving GW doesn't
support data forwarding, an appropriate cause value shall be returned and the Serving GW Address(es) and
TEID(s) will not be included in the message.
NOTE 5: This step is mostly unmodified compared to pre-Rel-8. The Source MME acts as the old SGSN, and the
PDN GW acts as the GGSN.
3GPP
Release 15 375 3GPP TS 23.401 V15.10.0 (2019-12)
D.3.7.3 Execution phase

Source PDN
UE eNodeB Target BSS Source MME New SGSN Serving GW GW HSS

1. Handover Command
3a. RAN charging data report
3b. Change notification
4. GERAN A/Gb Access Procedures

5. XID Response
Downlink User Plane PDUs
Sending of Direct forwarding of data

uplink data
possible Indirect forwarding of data
6. PS Handover Complete
7. XID Response
12. XID Negotioation for LLC ADM

12a. SABM UA exchange
re-establishment and XID negotiation for LLC ABM)
13. Routing Area Update procedure

14b. Release Resource
15. Delete Indirect Data Forwarding Tunnel Request/Response
Figure D.3.7.3-1: E-UTRAN to GERAN A/Gb mode Inter RAT HO, execution phase
1. The Source MME completes the preparation phase towards Source eNodeB by sending the message Handover
Command (Target BSS to Source BSS Transparent Container (PS Handover Command with RN part and EPC
part), Bearers Subject to Data Forwarding List). The "Bearers Subject to Data forwarding list" may be included
in the message and it shall be a list of 'Address(es) and TEID(s) for user traffic data forwarding' received from
target side in the preparation phase (Forward Relocation Response message (Step 8)).
Source eNodeB initiate data forwarding for the bearers specified in the "Bearers Subject to Data Forwarding
List". The data forwarding goes directly to target SGSN decided in the preparation phase.
2. The Source eNodeB will give a command to the UE to handover to the Target Access System via the message
HO from E-UTRAN Command. This message includes a transparent container including radio aspect
parameters that the Target BSS has set-up in the preparation phase (RN part). This message also includes the
XID and IOV-UI parameters received from the Target SGSN (EPC part).
3GPP
Release 15 376 3GPP TS 23.401 V15.10.0 (2019-12)
Upon the reception of the HO from E-UTRAN Command message containing the Handover Command
message, the UE shall associate its bearer IDs to the respective PFIs based on the relation with the NSAPI
and shall suspend the uplink transmission of the user plane data.
NOTE 1: This step is unmodified compared to clause 5.5.2.3.3. The target SGSN acts as the new SGSN.
NOTE 2: The source eNodeB does not send any RAN context towards the target BSS.
4. The MS executes the handover according to the parameters provided in the message delivered in step 2. The
procedure is the same as in step 6 in clause 5.1.4.2 in TS 43.129 [8] with the additional function of association
of the received PFI and existing RAB Id related to the particular NSAPI as described in clause 4.4.1 in
TS 43.129 [8].
The UE locally deactivates ISR by setting its TIN from "RAT-related TMSI" to "GUTI", if any EPS bearer
context activated after the ISR was activated in the UE exists.
5/7. After accessing the cell using access bursts and receiving timing advance information from the BSS in step 2,
the MS processes the NAS container and then sends one XID Response message to the new SGSN. The MS sends
this message immediately after receiving the Packet Physical Information message containing the timing
advance or, in the synchronised network case, immediately if the PS Handover Access message is not required
to be sent (see clause 6.2 in TS 43.129 [8]).
Upon sending the XID Response message, the MS shall resume the user data transfer only for those NSAPIs for
which there are radio resources allocated in the target cell. For NSAPIs using LLC ADM for which radio
resources were not allocated in the target cell the MS may request for radio resources using the legacy
procedures.
NOTE 3: If the new SGSN indicated Reset (i.e. reset to default parameters) in the NAS container for PS HO
included in the Handover from UTRAN Command message (UTRAN) or the Handover from GERAN Iu
Command message, in order to avoid collision cases the mobile station may avoid triggering XID
negotiation for any LLC SAPI used in LLC ADM, but wait for the SGSN to do so (see step 12). In any
case the mobile station may avoid triggering XID negotiation for any LLC SAPI used in LLC ABM, but
wait for the SGSN to do so (see step 12a).
NOTE 4: This step is unmodified compared to pre-Rel-8. The message "HO from E-UTRAN Command" acts as
the "Handover from UTRAN Command" message (UTRAN) or the "Handover from GERAN Iu
Command" message.
6. Upon reception of the first correct RLC/MAC block (sent in normal burst format) from the MS the target BSS
sends a PS Handover Complete (Local TLLI, Handover Complete Status) message to inform the new SGSN that
the MS has arrived in the target cell. Each uplink N-PDU received by the new SGSN via the target BSS is then
forwarded directly to the GGSN.
A timer in source MME is started to supervise when resources in Source eNodeB and Source Serving GW shall
be released.
NOTE 5: This step is unmodified compared to pre-Rel-8. The PDN GW acts as the GGSN.
8. Upon receiving the PS Handover Complete message, the new SGSN send a Forward Relocation Complete
message to the old SGSN to indicate completion of the PS handover procedures. The old SGSN responds with a
Forward Relocation Complete Acknowledge message.
For all bearers that were not included in the Forward Relocation Request message sent in step 3, the old SGSN
now releases them by sending a Delete Bearer Command to the SGW, or, the appropriate message to the SCEF.
NOTE 6: This step is unmodified compared to pre-Rel-8. The Source MME acts as the old SGSN.
9/11. The new SGSN sends an Update PDP Context Request (new SGSN Address, TEID, QoS Negotiated) message
to the GGSN concerned. The GGSN updates the PDP context fields and returns an Update PDP Context
3GPP
Release 15 377 3GPP TS 23.401 V15.10.0 (2019-12)
Response (TEID) message. From now on the GGSN sends new incoming downlink IP packets to the new SGSN
instead of to the old SGSN.
The PDN GW shall include a Charging Id to be used at the SGSN as the Charging ID for reporting usage for this
PDP context. The PDN GW shall include the Charging Id in the offline charging data.
NOTE 7: This step is unmodified compared to pre-Rel-8. The Source MME acts as the old SGSN, and the
PDN GW acts as the GGSN.
12. If the new SGSN indicated Reset (i.e. reset to default parameters) in the NAS container for PS HO included in
the Handover from UTRAN Command message (UTRAN) or the Handover from GERAN Iu Command message,
then on receipt of the PS Handover Complete the new SGSN initiates an LLC/SNDCP XID negotiation for each
LLC SAPI used in LLC ADM. In this case if the SGSN wants to use the default parameters, it shall send an
empty XID Command. If the new SGSN indicated 'Reset to the old XID parameters' in the NAS container for PS
HO, no further XID negotiation is required for LLC SAPIs used in LLC ADM only.
NOTE 8: This step is unmodified compared to pre-Rel-8. The message "HO from E-UTRAN Command" acts as
the "Handover from UTRAN Command" message (UTRAN) or the "Handover from GERAN Iu
Command" message.
12a. The new SGSN (re-)establishes LLC ABM for the PDP contexts which use acknowledged information
transfer. During the exchange of SABM and UA the SGSN shall perform LLC/SNDCP XID negotiation.
13. The MS sends a Routing Area Update Request (Old P-TMSI, Old RAI, Old P-TMSI signature, Update Type)
message to the new SGSN informing it that the source cell belongs to a new routing area. The MS shall send this
message immediately after message 5, see TS 23.060 [7].
The new SGSN knows that a handover has been performed for this MS and can therefore exclude the SGSN
context procedures which normally are used within the RA Update procedure.
For a MS supporting CIoT EPS Optimisations, the MS uses the PDP context status information in the RAU
Accept to identify any non-transferred bearers that it shall locally release.
For further descriptions of the Routing Area Update procedure see TS 43.129 [8], clauses 5.5.2.3 and 5.6.1.1.1.
NOTE 9: The RAU procedure is performed regardless if the routing area is changed or not, as specified by
TS 43.129 [8].
14. When the timer started at step 8 expires, the source MME sends a Release Resources message to the source
Additionally, the source MME deletes the EPS bearer resources by sending Delete Session Request (Cause,
Operation Indication, Secondary RAT usage data) messages to the Serving GW. The operation Indication flag is
not set, that indicates to the Serving GW that it shall not initiate a delete procedure towards the PDN GW.
Secondary RAT usage data was included if it was received in step 3a. The Serving GW acknowledges with
Delete Session Response (Cause) messages. If ISR is activated then the cause indicates to the old Serving GW
that the old Serving GW shall delete the bearer resources on the other old CN node by sending Delete Bearer
Request message(s) to that CN node.
15. When the timer started in step 8 expires and if resources for indirect forwarding have been allocated then they
are released.
D.3.8 GERAN A/Gb mode to E-UTRAN Inter RAT handover

D.3.8.1 General
See clause D.3.7.1.
3GPP
Release 15 378 3GPP TS 23.401 V15.10.0 (2019-12)
D.3.8.2 Preparation phase

Source Target
UE Old Target MME Serving GW PDN GW HSS
BSS eNodeB
SGSN
5. Handover Request
Figure D.3.8.2-1: GERAN A/Gb mode to E-UTRAN inter RAT HO, preparation phase
1. The source BSS decides to initiate a PS handover. At this point both uplink and downlink user data is
transmitted via the following: TBFs between MS and source BSS, BSSGP PFCs tunnel(s) between source BSS
and old SGSN, GTP tunnel(s) between old SGSN and GGSN.
NOTE 1: The UE acts as MS, and the PDN GW acts as the GGSN.
2. The source BSS sends the message PS handover Required (TLLI, Cause, Source Cell Identifier, Target
eNodeB Identifier, Source to Target Transparent Container (RN part), and active PFCs list) to Source SGSN
to request the CN to establish resources in the Target eNodeB, Target MME and the Serving GW.
NOTE 2: The Source SGSN acts as the Old SGSN.
NOTE 3: As an implementations option for supporting introduction scenarios with pre-Rel8 SGSNs the source BSS
may be configured to use RNC IDs instead of eNodeB IDs to identify a target eNodeB. The Cause is
relayed transparently by the SGSN to the MME and the MME mappes the BSSGP cause code to an S1AP
cause code. Source to Target Transparent Container carries information for the target eNodeB. This
container is relayed transparently by the SGSN.
3. The Source SGSN determines from the 'Target eNodeB Identifier' IE that the type of handover is IRAT PS
Handover to E-UTRAN. The Source SGSN initiates the Handover resource allocation procedure by sending
message Forward Relocation Request (IMSI, Target Identification, MM Context, PDP Context, SGSN
Tunnel Endpoint Identifier for Control Plane, SGSN Address for Control plane, Source to Target
Transparent Container (RN part), Packet Flow ID, SNDCP XID parameters, LLC XID parameters) to the
target MME. This message includes all PDP contexts that are established in the source system indicating the
PFIs and the XID parameters related to those PDP Contexts, and the uplink Tunnel endpoint parameters of
the Serving GW.
The PDP Contexts shall be sent in a prioritized order, i.e. the most important PDP Context first. The
prioritization method is implementation dependent, but should be based on the current activity.
NOTE 3: Assigning the highest priority to the PDP context without TFT could be done to get service continuity
for all ongoing services regardless of the number of supported EPS bearers in the UE and network.
The target MME maps the PDP contexts to the EPS bearers 1-to-1 and maps the Release 99 QoS parameter
values of a PDP context to the EPS Bearer QoS parameter values of an EPS bearer as defined in Annex E.
3GPP
Release 15 379 3GPP TS 23.401 V15.10.0 (2019-12)
The MME establishes the EPS bearer(s) in the indicated order. The MME deactivates the EPS bearers which
cannot be established.
TS 29.060 [14].
For the PDP Context with traffic class equals 'Background', the source SGSN shall indicate via the Activity
Status Indicator IE that EPS bearers shall be established on the target side.
NOTE 4: The Source SGSN acts as the old SGSN.
4. The target MME selects the Serving GW as described under clause 4.3.8.2 on "Serving GW selection function".
The target MME sends a Create Session Request message (IMSI, MME Tunnel Endpoint Identifier for Control
Plane, MME Address for Control plane, PDN GW address(es) for user plane, PDN GW UL TEID(s) for user
plane, PDN GW address for control plane, and PDN GW TEID(s) for control plane, the Protocol Type over
S5/S8, APN-AMBR, Serving Network) per PDN connection to the Serving GW. The Protocol Type over S5/S8
is provided to Serving GW which protocol should be used over S5/S8 interface. For relocation from Gn/Gp
SGSN, the target MME provides the APN-AMBR if not received explicitly from the Gn/Gp SGSN based on the
mapping from MBR (as specified in Annex E) to the Serving GW
4a. The Serving GW allocates its local resources and returns them in a Create Session Response (Serving GW
5. The Target MME will request the Target eNodeB to establish the Bearer(s) by sending the message Handover
Request (UE Identifier, S1AP Cause, Integrity protection information (i.e. IK and allowed Integrity
Protection algorithms), Encryption information (i.e. CK and allowed Ciphering algorithms), EPS Bearers to
be setup list, Source to Target Transparent Container). The Target MME shall not request resources for
which the Activity Status Indicator within a PDP Context indicates that no active bearer exists on the source
side for that PDP Context.
For each EPS bearer requested to be established, 'EPS Bearers To Be Setup' IE shall contain information
such as ID, bearer parameters, Transport Layer Address, "Data forwarding not possible" indication and S1
Transport Association. The Transport Layer Address is the Serving GW Address for user data, and the S1
Transport Association corresponds to the uplink Tunnel Endpoint Identifier Data. "Data forwarding not
possible" indication shall be included if the target MME decides the corresponding bearer will not be subject
to data forwarding.
The target MME shall not request the target eNodeB to establish EPS GBR bearers with maximum bitrate set to
0 and those EPS bearers should not be included in the EPS Bearers to be setup list and should be deactivated by
the MME. For the remaining EPS Bearer Contexts the MME ignores any Activity Status Indicator within an EPS
Bearer Context and requests the target eNodeB to allocate resources for all the remaining EPS Bearer Contexts.
The ciphering and integrity protection keys will be sent transparently from the target eNodeB to the UE in the
Target to Source Transparent Container, and in the message PS Handover Command from source BSS to the
UE. This will then allow data transfer to continue in the new RAT/mode target cell without requiring a new
AKA (Authentication and Key Agreement) procedure.
The MME shall compute the UE-AMBR, as per clause 4.7.3, based on explicit APN-AMBR values received
from the Gn/Gp SGSN. If explicit APN-AMBR values are not received by the MME, a local UE-AMBR shall be
included in the 'EPS Bearers be setup list ' IE. The local UE-AMBR is described in Annex E.
5a. The Target eNodeB allocates the request resources and returns the applicable parameters to the Target MME
in the message Handover Request Acknowledge (Target to Source Transparent Container, EPS Bearers setup
list, EPS Bearers failed to setup list). Upon sending the Handover Request Acknowledge message the target
eNodeB shall be prepared to receive downlink GTP PDUs from the Serving GW for the accepted EPS
bearers.
The target eNodeB shall ignore it if the number of radio bearers in the Source to Target Transparent container
does not comply with the number of bearers requested by the MME and allocate bearers as requested by the
MME.
3GPP
Release 15 380 3GPP TS 23.401 V15.10.0 (2019-12)
6. If 'Indirect Forwarding' applies, the target MME sends a Create Indirect Data Forwarding Tunnel Request
message (Cause, Target eNodeB Address(es), TEID(s) for DL user plane) to the Serving GW. Cause indicates
that the bearer(s) are subject to data forwarding.
6a. The Serving GW returns a Create Indirect Data Forwarding Tunnel Response (Cause, Serving GW
Address(es) and TEID(s) for Data Forwarding) message to the target MME. If the Serving GW doesn't
support data forwarding, an appropriate cause value shall be returned and the Serving GW Address(es) and
TEID(s) will not be included in the message.
7. The Target MME sends the message Forward Relocation Response (Cause, List of Set Up PFCs, MME
Tunnel Endpoint Identifier for Control Plane, BSSGP cause, MME Address for control plane, Target to
Source Transparent Container, Address(es) and TEID(s) for Data Forwarding) to the Source SGSN.
If 'Direct Forwarding' is applicable, then the IEs 'Address(es) and TEID(s) for Data Forwarding' contains the DL
GTP-U tunnel endpoint parameters to the eNodeB. If 'Indirect Forwarding' applies the IEs 'Address(es) and
TEID(s) for Data Forwarding' contain the DL GTP-U tunnel endpoint parameters to the Serving GW.
D.3.8.3 Execution phase

Source Targe PD
UE BSS eNodeB
t Old SGSN Target MME Serving GW HSS
GW
N
Uplink and Downlink User Plane
PDUs
Direct forwarding of data
Indirect forwarding
of data
1. PS HO Required Acknowledge
Ackno
2. PS Handover Command 3. Forward SRNS Context
3a. Forward SRNS Context Ack

6. Handover Notify
Sending of
uplink data
possible 7. Forward Relocation Complete

8 Modify Beare Request
(A)
9a. Modify Bearer Respons
e
Uplink and Downlink User Plane

PDUs
11. BSS Packet Flow Delete Procedure 11. Delete Indirect Data Forwarding Request/Response
Figure D.3.8.3-1: GERAN A/Gb mode to E-UTRAN Inter RAT HO, execution phase
3GPP
Release 15 381 3GPP TS 23.401 V15.10.0 (2019-12)
NOTE 1: For a PMIP-based S5/S8, procedure steps (A) are defined in TS 23.402 [2]. Steps 9 and 9a concern GTP
based S5/S8.
The old SGSN continues to receive downlink and uplink user plane PDUs.
When old SGSN receives the Forward Relocation Response message it may start downlink N-PDU relay and
duplication to the target eNodeB, and the target eNodeB may start blind transmission of downlink user data towards the
UE over the allocated radio channels.
1. The Source SGSN completes the preparation phase towards Source BSS by sending the message PS HO
Required Acknowledge (TLLI, List of Set Up PFCs, Target to Source Transparent Container). This message
includes all PFIs that could be established on the Target side.
Before sending the PS Handover Required Acknowledge message, the source SGSN may suspend downlink
data transfer for any PDP contexts.
Before sending the PS Handover Command message to the UE the source BSS, may try to empty the
downlink BSS buffer for any BSS PFCs.
2. The Source BSS will command the UE to handover to the target eNodeB via the message PS Handover
Command. The access system specific message to UE includes a transparent container including radio aspect
parameters that the Target eNodeB has set-up in the preparation phase.
3. There is no RAN context transfer during inter RAT handovers with E-UTRAN. If the source SGSN originates
any SRNS contexts the MME acknowledges the receipt towards the SGSN and ignores the message content.
4. The UE moves to the E-UTRAN and performs access procedures toward Target eNodeB.
5. When the UE has got access to Target eNodeB it sends the message HO to E-UTRAN Complete. The UE
shall implicitly derive the EPS bearers for which an E-RAB was not established from the PS Handover
Command and deactivate them locally without an explicit NAS message at this step.
6. When the UE has successfully accessed the Target eNodeB, the Target eNodeB informs the Target MME by
sending the message Handover Notify.
Upon receipt of the Handover Notify message the target MME starts a timer if the target MME applies indirect
forwarding.
7. Then the Target MME knows that the UE has arrived to the target side and Target MME informs the old SGSN
by sending the Forward Relocation Complete () message. The old SGSN will also acknowledge that information.
When the Forward Relocation Complete message has been received and there is no longer any need for the Old
SGSN to forward data, the old SGSN stops data forwarding. A timer in old SGSN is started to supervise when
resources shall be released.
8. The Target MME will now complete the Handover procedure by informing the Serving GW (for Serving GW
relocation this will be the Target Serving GW) that the Target MME is now responsible for all the EPS
bearers the UE have established. This is performed in the message Modify Bearer Request (Cause, MME
Tunnel Endpoint Identifier for Control Plane, EPS Bearer ID(s), MME Address for Control Plane, eNodeB
Address(es) and TEID(s) for User Traffic for the accepted EPS bearers, PDN GW addresses and TEIDs (for
GTP-based S5/S8) or GRE keys (for PMIP-based S5/S8) at the PDN GW(s) for uplink traffic and RAT type)
per PDN connection.
In case any EPS bearers are to be released the MME triggers the bearer release procedure as specified in
clause 5.4.4.2. If the Serving GW receives a DL packet for a non-accepted bearer, the Serving GW drops the
DL packet and does not send a Downlink Data Notification to the MME.
NOTE 3: The text regarding "Target Serving GW" shall be ignored.
9. The Serving GW (for Serving GW relocation this will be the Target Serving GW) informs the PDN GW(s) the
sending the message Modify Bearer Request per PDN connection. Serving Network should be included in this
message if it is received in step 4. For Serving GW relocation, the Serving GW allocates DL TEIDs on S5/S8
even for non-accepted bearers. The PDN GW must acknowledge the request with the message Modify Bearer
3GPP
Release 15 382 3GPP TS 23.401 V15.10.0 (2019-12)
Response (APN Restriction). When the UE moves from Gn/Gp SGSN to the MME, the PDN GW shall send
the APN restriction of each bearer context to the Serving GW.
If PCC infrastructure is used, the PDN GW informs the PCRF about the change of, for example, the RAT
type.
The Modify Bearer Response also indicates the identity of the default bearer and the Charging Id towards the
S-GW.
switch to the Target MME via the message Modify Bearer Response (Cause, Serving GW Tunnel Endpoint
Identifier for Control Plane, Serving GW (for Serving GW relocation this will be the Target Serving GW)
Address for Control Plane, Protocol Configuration Options, PDN GW addresses and TEIDs (for GTP-based
S5/S8) or GRE keys (for PMIP-based S5/S8) at the PDN GW(s) for uplink traffic, APN Restriction).The
Serving GW shall forward the received APN Restriction to the MME. At this stage the user plane path is
established for all bearers between the UE, Target eNodeB, Serving GW (for Serving GW relocation this will
be the Target Serving GW) and PDN GW.
In addition, the Modify Bearer Response indicates the identity of the default bearer towards the MME.
11. When the timer started in step 7 expires the Source SGSN will clean-up all its resources towards Source BSS
by performing the BSS Packet Flow Delete procedure.
When the timer started in step 6 expires the target MME releases the resources that have been allocated for
12. The RAN triggers the UE to initiate a Tracking Area Update procedure with the target MME. It is RAN
functionality to provide the ECM CONNECTED UE with the trigger information.
The target MME gets the subscribed UE-AMBR value and the subscribed APN-AMBR value from the HSS
during the TA update procedure.
permitted to use NR as a secondary RAT, Unlicensed Spectrum or a combination of them, and the MME has not
provided this information to the target eNodeB during step 5 of the Handover preparation phase, then the MME
sends an updated Handover Restriction List in the Downlink NAS Transport message that it sends to E-UTRAN.
13. The target MME calculates UE-AMBR as defined in clause 4.7.3. If this calculated value is different from the
UE-AMBR computed during step 6, or the APN-AMBR mapped from the subscribed MBR is different from the
subscribed APN-AMBR, or the mapped subscribed QoS profile (i.e. the subscribed QoS profile mapped
according to Annex E) of the default bearer is different from the EPS Subscribed QoS profile received from the
HSS, the new MME shall initiate Subscribed QoS Modification procedure as described in clause 5.4.2.2, Figure
5.4.2.2-1
3GPP
Release 15 383 3GPP TS 23.401 V15.10.0 (2019-12)
Annex E (normative):
Mapping between EPS and Release 99 QoS parameters
This annex specifies how the QoS parameter values of an EPS bearer are mapped to/from the Release 99 QoS parameter
values of a PDP context in PDN GW, S4-SGSN and MME.
Within this specification, different names are used for the QoS parameters of a PDP context e.g. "R99 QoS profile" and
"R99 QoS parameters", but nevertheless the whole QoS IE as described in TS 24.008 [47] is referred to including the
R99 and R97/98 QoS attributes. This means that the MME performs QoS mapping, populates and forwards both R99
and R97/98 QoS attributes towards the UE in S1 mode, if the UE supports A/Gb mode or Iu mode or both. The MME
also performs QoS mapping, populates and forwards both R99 and R97/98 QoS attributes also on Gn when deployed in
the interoperation scenarios as listed in Annex D, clause D.2. The S4-SGSN performs QoS mapping, populates and
forwards either both R99 and R97/98 QoS attributes or only R97/98 QoS attributes towards the UE in Iu mode and
A/Gb mode. The P-GW performs QoS mapping, populates and forwards both R99 and R97/98 QoS attributes over
Gn/Gp when deployed in the interoperation scenarios as listed in Annex D, clause D.2.
The following mapping rules hold:
- There is a one-to-one mapping between an EPS bearer and a PDP context.
- When EPS bearer QoS parameters are mapped to Release 99 QoS parameters the pre-emption capability and the
pre-emption vulnerability information of the EPS bearer ARP are ignored and the priority of the EPS bearer
parameter ARP is mapped to the Release 99 bearer parameter ARP, as described in table E.1.
Table E.1: Mapping of EPS bearer ARP to Release 99 bearer parameter ARP
EPS Release 99 bearer parameter

Bearer ARP Priority Value ARP Value
1 to H 1
H+1 to M 2
M+1 to 15 3
When Release 99 QoS parameters are mapped to EPS bearer QoS parameters the pre-emption capability and the
pre-emption vulnerability information of the EPS bearer ARP are set based on operator policy in the entity that
performs the mapping. The Release 99 bearer parameter ARP is mapped to the priority level information of the
EPS bearer parameter ARP as described in table E.2.
Table E.2: Mapping of Release 99 bearer parameter ARP to EPS bearer ARP
Release 99 bearer parameter EPS

ARP Value Bearer ARP Priority Value
1 1
2 H+1
3 M+1
The values of H (high priority) and M (medium priority) can be set according to operator requirements to ensure
proper treatment of users with higher priority level information. The minimum value of H is 1. The minimum
value of M is H+1.
From Release 9 onwards, the priority of the EPS bearer parameter ARP is mapped one-to-one to/from the
Evolved ARP parameter of a PDP context, if the network supports this parameter.
NOTE 1: The setting of the values for H and M may be based on the SGSN mapping from the Release 99 bearer
parameter ARP to the ARP parameter that is used for UTRAN/GERAN.
NOTE 2: After a handover from UTRAN/GERAN to E-UTRAN the ARP parameter of the EPS bearer can be
modified by the P-GW to re-assign the appropriate priority level, pre-emption capability and pre-emption
vulnerability setting.
3GPP
Release 15 384 3GPP TS 23.401 V15.10.0 (2019-12)
NOTE 3: A mapping from the EPS bearer parameter ARP to the Release 99 bearer parameter ARP is not required
for a P-GW when connected to an SGSN via Gn/Gp as any change of the bearer ARP parameter may get
overwritten by the SGSN due to subscription enforcement. However, the P-GW should not combine
services with different EPS bearer ARP values onto the same PDP context to enable a modification of the
bearer ARP without impacting the assignment of services to bearers after a handover to E-UTRAN.
- The EPS bearer parameters GBR and MBR of a GBR EPS bearer are mapped one-to-one to/from the Release 99
bearer parameters GBR and MBR of a PDP context associated with Traffic class 'conversational' or 'streaming'.
- When EPS bearer QoS parameters are mapped to Release 99 QoS parameters the Release 99 bearer parameter
MBR of PDP contexts associated with Traffic Class 'interactive' or 'background' is set equal to the value of the
authorized APN-AMBR. If the APN-AMBR is modified while the UE accesses the EPS through E-UTRAN, the
UE shall also set the Release 99 bearer parameter MBR to the new APN-AMBR value for all non-GBR PDP
contexts of this PDN connection. The P-GW shall enforce the APN-AMBR across all PDP contexts with Traffic
Class 'interactive' and 'background' for that APN. The MME or S4-SGSN may attempt to transfer APN-AMBR
and UE-AMBR to a Gn/Gp SGSN
- When Release 99 QoS parameters are mapped to EPS bearer QoS parameters the AMBR for the corresponding
APN shall be set equal to the MBR value of the subscribed QoS profile. At handover from a Gn/Gp SGSN the
MME or S4-SGSN shall provide this APN-AMBR value, if not explicitly received from the Gn/Gp SGSN, to the
Serving GW and the PDN GW for each PDN connection. It is required that the subscribed MBR in the
HLR/HSS is set to the desired APN-AMBR value for all subscribed APNs which may lead to a selection of a
P-GW. The UE derives the APN-AMBR from the value of the MBR of a PDP context created by the PDP
Context Activation Procedure as described in TS 23.060 [7].
NOTE 5: If the pre-Rel-8 UE with the updated subscribed MBR is connected to a GGSN, the GGSN can
downgrade the MBR of the PDP contexts based on either local policy or PCC (where the MBR per QCI
information is provided to the PCEF).
NOTE 6: From Release 9 onwards, the APN-AMBR is available on Gn/Gp.
- For handover from a Gn/Gp SGSN and if the MME does not receive AMBR values from the Gn/Gp SGSN, the
MME provides a local UE-AMBR to the eNodeB until MME gets the EPS subscribed UE-AMBR. When the
MME gets the subscribed UE-AMBR value from the HSS, it calculates the UE-AMBR (UE-AMBR=MIN
(subscribed UE-AMBR, sum APN-AMBR of all active APNs)). Then it compares this value with the local UE-
AMBR and if the local UE-AMBR is different from the corresponding derived UE-AMBR, the MME initiates
HSS Initiated Subscribed QoS Modification procedure to notify the derived UE-AMBR to the eNodeB.
NOTE 7: The local UE-AMBR may be for example based on the summing up of the APN-AMBR values of all
active APNs of the UE or on internal configuration.
- A standardized value of the EPS bearer parameter QCI is mapped one-to-one to/from values of the Release 99
parameters Traffic Class, Traffic Handling Priority, Signalling Indication, and Source Statistics Descriptor as
shown in Table E.3.
NOTE 8: When mapping to QCI=2 or QCI=3, the Release 99 parameter Transfer Delay is used in addition to the
four Release 99 parameters mentioned above.
- When EPS bearer QoS parameters are mapped to Release 99 QoS parameters the setting of the values of the
Release 99 parameters Transfer Delay and SDU Error Ratio is derived from the corresponding QCI's Packet
Delay Budget and Packet Loss Rate, respectively. When Packet Loss Rate parameter is further mapped to
Release 99 QoS parameter Reliability Class (TS 23.107 [59], table 7), the Residual BER is considered <= 2*10-4.
Also when Release 99 QoS parameters are mapped to EPS bearer QoS parameters the values of the Release 99
parameter SDU Error Ratio are ignored.
- The setting of the values of all other Release 99 QoS is based on operator policy pre-configured in the MME and
S4-SGSN.
- In networks that support mobility from E-UTRAN to UTRAN/GERAN, if the UE has indicated support of
UTRAN or GERAN, the EPS network shall provide the UE with the Release 99 QoS parameters in addition to
the EPS bearer QoS parameters within EPS bearer signalling.
3GPP
Release 15 385 3GPP TS 23.401 V15.10.0 (2019-12)
Table E.3: Mapping between standardized QCIs and Release 99 QoS parameter values
Traffic Signalling Source

Traffic
QCI Handling Indication Statistics
Class
Priority Descriptor
1 Conversational N/A N/A Speech
Unknown
2 Conversational N/A N/A
(NOTE 1)
Unknown
3 Conversational N/A N/A
(NOTE 2)
Unknown
4 Streaming N/A N/A
(NOTE 3)
5 Interactive 1 Yes N/A
6 Interactive 1 No N/A
9 Background N/A N/A N/A
NOTE°1: When QCI 2 is mapped to Release 99 QoS parameter values, the Transfer
Delay parameter is set to 150 ms. When Release 99 QoS parameter values
are mapped to a QCI, QCI 2 is used for conversational/unknown if the
Transfer Delay parameter is greater or equal to 150 ms.
NOTE°2: When QCI 3 is mapped to Release 99 QoS parameter values, the Transfer
Delay parameter is set to 80 ms as the lowest possible value, according to
TS 23.107 [59]. When Release 99 QoS parameter values are mapped to a
QCI, QCI 3 is used for conversational/unknown if the Transfer Delay
parameter is lower than 150 ms.
NOTE 3: When QCI 4 is mapped to Release 99 QoS parameter values, it is mapped to
Streaming/Unknown and the SDU Error Ratio is set to 10-5 as the closest
available value according to TS 23.107 [59]. When Release 99 QoS
parameter values are mapped to a QCI, Streaming/Unknown and
Streaming/Speech are both mapped to QCI 4.
3GPP
Release 15 386 3GPP TS 23.401 V15.10.0 (2019-12)
Annex F (normative):
Dedicated bearer activation in combination with the default
bearer activation at Attach and UE requested PDN
connectivity procedures
For WB-E-UTRAN, it shall be possible for the PDN GW to initiate the activation of dedicated bearers (as specified in
clause 5.4.1) as part of the attach procedure (as specified in clause 5.3.2.1) or as part of the UE requested PDN
connectivity procedure (as specified in clause 5.10.2) over WB-E-UTRAN. However, the result of the dedicated bearer
activation procedure shall be logically separate from the Attach procedure, meaning that the result of the Attach
procedure is not dependent on whether the Dedicated bearer activation procedure succeeds or not. On the other hand,
the dedicated bearer activation may only be regarded as successful if the Attach procedure completes successfully.
The messages of the Dedicated bearer activation can be sent together with the messages of the Attach procedure or of
the UE requested PDN connectivity procedure (i.e. Attach accept or PDN Connectivity Accept), as shown in the Figure
and explanation below.
On the S1 and Uu interfaces the messages for the default bearer activation at Attach and UE requested PDN
connectivity procedures and for the Dedicated Bearer Activation procedure are combined into a single message. If the
MME has sent an Attach Accept message towards the eNodeB, and then the MME receives a Create Bearer Request
before the MME receives the Attach Complete message, the MME shall wait for the Attach procedure to complete
before the MME continues with Dedicated Bearer Activation procedure.
It shall be possible that multiple dedicated bearers can simultaneously be activated in the signalling flow shown below.
3GPP
Release 15 387 3GPP TS 23.401 V15.10.0 (2019-12)

1a. Attach Request
Attach procedure until Update Location Ack
1b. PDN Connectivity Request


(A)
4. IP-CAN Session Establishment
5. Create Session Response and

Create Bearer Request(s)
First Downlink Data
6. Create Session Response and

Create Bearer Request(s)
7a. S1-AP: Initial Context Setup Request

(incl. NAS parts for both Attach Accept and Dedicated Bearer Setup Request(s))
7b. S1-AP Bearer Setup Request

(incl. NAS parts for both PDN Connectivity Accept and Dedicated Bearer Setup Request(s))
10a. S1-AP Initial Context Setup Response
10b. S1-AP Bearer Setup Response
11. Direct Transfer

12. Attach (or PDN Connectivity) Complete / Session Management Response
First Uplink Data
13. Modify Bearer Request and

Create Bearer Response(s)
Create Bearer Response(s)

First Downlink Data
15. Notify Request

16. Notify Response
Figure F.1: Dedicated bearer activation in combination with the default bearer activation at attach or
UE requested PDN connectivity
NOTE 1: Parameters related to dedicated bearer activation are written in italics.
Figure F.1 describes the activation of dedicated bearer(s) in combination with the default bearer activation either as part
of the Attach procedure (with specific steps 1a, 7a, 10a) or as part of the UE requested PDN connectivity procedure
(with specific steps 1b, 7b, 10b). The following steps below require special attention:
5. (On the P-GW-S-GW interface) Create Session Response message of the Attach procedure or UE-requested
PDN connectivity procedure is combined with Create Bearer Request message of the Dedicated Bearer
Activation Procedure
3GPP
Release 15 388 3GPP TS 23.401 V15.10.0 (2019-12)
6. (On the S-GW-MME interface) Create Session Response message of the Attach procedure or UE-requested PDN
connectivity procedure is combined with the Create Bearer Request message of the Dedicated Bearer Activation
Procedure
7a. For Attach procedure: If the MME receives a Create Session Response message combined with a Create Bearer
Request message, the MME shall send the S1-AP Initial Context Setup Request message to the eNodeB,
including the NAS parts for both the Attach Accept message of the Attach procedure and the Bearer Setup
Request of the Dedicated Bearer Activation Procedure.
NOTE 2: The MME shall not send a Bearer Setup Request message of a new Dedicated Bearer Activation
procedure to the eNodeB before sending the Attach Accept message of the Attach procedure to the
eNodeB. If the MME has already sent the Attach Accept message of the Attach procedure to the eNodeB,
the MME shall wait for the Attach Complete message to arrive before sending a separate Bearer Setup
Request of a Dedicated Bearer Activation procedure.
7b. For UE requested PDN connectivity procedure: If the MME receives a Create Session Response message
combined with a Create Bearer Request message, the MME shall send the S1-AP Bearer Setup Request message
to the eNodeB, including the NAS parts for both the PDN Connectivity Accept message and the Bearer Setup
Request of the Dedicated Bearer Activation Procedure.
8-9. The radio bearer establishment of the default and dedicated bearer(s) is performed in the same RRC message.
10a. For Attach procedure: The eNodeB sends the S1-AP Initial Context Setup Response message to the MME.
The MME shall be prepared to receive this message either before or after, some or all, of the Uplink NAS Uplink
Transport messages sent in step 12.
10b. For UE requested PDN connectivity procedure: The eNodeB sends the S1-AP Bearer Setup Response
message to the MME.
The MME shall be prepared to receive this message either before or after, some or all, of the Uplink NAS Uplink
Transport messages sent in step 12.
11. For the Attach procedure: The UE sends the eNodeB a Direct Transfer message containing the Attach Complete
(Session Management Response for the Default Bearer) message as response of the attach procedure, and Direct
Transfer messages containing the Session Management Responses of the dedicated bearer setup procedure.
For the UE requested PDN connectivity procedure: The UE NAS layer builds a PDN Connectivity Complete
(Session Management Response) for the Default Bearer Activation and Dedicated Bearer Activation Procedures.
The UE then sends Direct Transfer (PDN Connectivity Complete) message to the eNodeB.
The NAS messages to establish the EPS bearers shall be handled individually by the UE and be sent in separate
RRC Direct Transfer messages.
12. The eNodeB sends an Uplink NAS Transport message to the MME, which contains the NAS messages from the
RRC message in step 11. There may be multiple Uplink NAS Transport messages when the UE sends multiple
RRC messages containing NAS messages in step 11.
13. Upon reception of the response messages in both step 10 and step 12, the Modify Bearer Request message of the
Attach procedure or UE requested PDN connectivity procedure is combined with the Create Bearer Response
message of the Dedicated Bearer Activation Procedure. After that, the Serving GW continues with sending a
Create Bearer Response message to the PDN GW.
3GPP
Release 15 389 3GPP TS 23.401 V15.10.0 (2019-12)
Annex G (informative):
Void
3GPP
Release 15 390 3GPP TS 23.401 V15.10.0 (2019-12)
Annex H (normative):
Mapping between temporary and area identities
The mapping between temporary and area identities is defined in TS 23.003 [9].
3GPP
Release 15 391 3GPP TS 23.401 V15.10.0 (2019-12)
Annex I (informative):
Guidance for contributors to this specification
The following guidance is provided for drafting figures for this specification that contain specific steps which are
different in TS 23.402 [2] due to the PMIP-based S5/S8 interface:
- Message flows to this specification will contain the complete procedures applicable for GTP-based S5/S8 only.
- In this specification, clause(s) of a message flow that is different for PMIP-based S5/S8 interface are shown
surrounded by shaded box indexed by an upper-case letter in ascending order, e.g. "A", "B", "C", etc.
For example, at the bottom of the flow, the following text should be included:
"NOTE: Procedure steps (A) and (B) for an PMIP-based S5/S8 interface are defined in TS 23.402 [2]."
- Further guidance for drafting procedures for TS 23.402 [2] can be found in that specification itself.
3GPP
Release 15 392 3GPP TS 23.401 V15.10.0 (2019-12)
Annex J (informative):
High Level ISR description
J.1 General description of the ISR concept

Idle state Signalling Reduction (ISR) aims at reducing the frequency of TAU and RAU procedures caused by UEs
reselecting between E-UTRAN and GERAN/UTRAN which are operated together. Especially the update signalling
between UE and network is reduced. But also network internal signalling is reduced. To some extent the reduction of
network internal signalling is also available when ISR is not used or not activated by the network.
UMTS described already RAs containing GERAN and UTRAN cells, which also reduces update signalling between UE
and network. The combination of GERAN and UTRAN into the same RAs implies however common scaling,
dimensioning and configuration for GERAN and UTRAN (e.g. same RA coverage, same SGSN service area, no
GERAN or UTRAN only access control, same physical node for GERAN and UTRAN). As an advantage it does not
require special network interface functionality for the purpose of update signalling reduction.
ISR enables signalling reduction with separate SGSN and MME and also with independent TAs and RAs. Thereby the
interdependency is drastically minimized compared with the GERAN/UTRAN RAs. This comes however with ISR
specific node and interface functionality. SGSN and MME may be implemented together, which reduces some interface
functions but results also in some dependencies.
ISR support is mandatory for E-UTRAN UEs that support GERAN and/or UTRAN and optional for the network. ISR
requires special functionality in both the UE and the network (i.e. in the SGSN, MME and Serving GW) to activate ISR
for a UE. For this activation, the MME/SGSN detects whether S-GW supports ISR based on the configuration and
activates ISR only if the S-GW supports the ISR. The network can decide for ISR activation individually for each UE.
Gn/Gp SGSNs do not support ISR functionality. No specific HSS functionality is required to support ISR.
NOTE. A Release 7 HSS needs additional functionality to support the 'dual registration' of MME and SGSN.
Without such an upgrade, at least PS domain MT Location Services and MT Short Messages are liable to
fail.
It is inherent functionality of the MM procedures to enable ISR activation only when the UE is able to register via E-
UTRAN and via GERAN/UTRAN. For example, when there is no E-UTRAN coverage there will be also no ISR
activation. Once ISR is activated it remains active until one of the criteria for deactivation in the UE occurs, or until
SGSN or MME indicate during an update procedure no more the activated ISR, i.e. the ISR status of the UE has to be
refreshed with every update.
When ISR is activated this means the UE is registered with both MME and SGSN. Both the SGSN and the MME have a
control connection with the Serving GW. MME and SGSN are both registered at HSS. The UE stores MM parameters
from SGSN (e.g. P-TMSI and RA) and from MME (e.g. GUTI and TA(s)) and the UE stores session management
(bearer) contexts that are common for E-UTRAN and GERAN/UTRAN accesses. In idle state the UE can reselect
between E-UTRAN and GERAN/UTRAN (within the registered RA and TAs) without any need to perform TAU or
RAU procedures with the network. SGSN and MME store each other's address when ISR is activated.
When ISR is activated and downlink data arrive, the Serving GW initiates paging processes on both SGSN and MME.
In response to paging or for uplink data transfer the UE performs normal Service Request procedures on the currently
camped-on RAT without any preceding update signalling (there are however existing scenarios that may require to
perform a RAU procedure prior to the Service Request even with ISR is activated when GERAN/UTRAN RAs are used
together, as specified in clause 6.13.1.3 of TS 23.060 [7]).
The UE and the network run independent periodic update timers for GERAN/UTRAN and for E-UTRAN. When the
MME or SGSN do not receive periodic updates MME and SGSN may decide independently for implicit detach, which
removes session management (bearer) contexts from the CN node performing the implicit detach and it removes also
the related control connection from the Serving GW. Implicit detach by one CN node (either SGSN or MME)
deactivates ISR in the network. It is deactivated in the UE when the UE cannot perform periodic updates in time. When
ISR is activated and a periodic updating timer expires the UE starts a Deactivate ISR timer. When this timer expires and
the UE was not able to perform the required update procedure the UE deactivates ISR.
3GPP
Release 15 393 3GPP TS 23.401 V15.10.0 (2019-12)
Part of the ISR functionality is also available when ISR is not activated because the MM contexts are stored in UE,
MME and SGSN also when ISR is not active. This results in some reduced network signalling, which is not available
for Gn/Gp SGSNs. These SGSNs cannot handle MM and session management contexts separately. Therefore all
contexts on Gn/Gp SGSNs are deleted when the UE changes to an MME. The MME can keep their MME contexts in
all scenarios.
J.2 Usage of the TIN

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 to be indicated in the next RAU
Request or TAU 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 sets the TIN when
receiving an Attach Accept, a TAU Accept or RAU Accept message as specified in table 4.3.5.6-1.
"ISR Activated" indicated by the RAU/TAU Accept message but the UE not setting the TIN to "RAT-related TMSI" is
a special situation. Here the UE has deactivated ISR due to special situation handling (see clause J.6). By maintaining
the old TIN value the UE remembers to use the RAT 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) remain registered with the
network and valid in the UE.
When ISR is not active the TIN is always set to the temporary ID belonging to the currently used RAT. This guarantees
that always the most recent context data are used, which means during inter-RAT changes there is always context
transfer from the CN node serving the last used RAT. The UE identities, old GUTI IE and additional GUTI IE,
indicated in the next TAU Request message, and old P-TMSI IE and additional P-TMSI/RAI IE, indicated in the next
RAU Request message depend on the setting of TIN and are specified in table 4.3.5.6-2.
The UE indicates also information elements "additional GUTI" or "additional P-TMSI" in the Attach Request, TAU or
RAU Request. These information elements permit the MME/SGSN to find the already existing UE contexts in the new
MME or SGSN, when the "old GUTI" or "old P-TMSI" indicate values that are mapped from other identities.
J.3 ISR activation

The information flow in Figure J.3-1 shows an example of ISR activation. For explanatory purposes the figure is
simplified to show the MM parts only.
The process starts with an ordinary Attach procedure not requiring any special functionality for support of ISR. The
Attach however deletes any existing old ISR state information stored in the UE. With the Attach request message, the
UE sets its TIN to "GUTI". After attach with MME, the UE may perform any interactions via E-UTRAN without
changing the ISR state. ISR remains deactivated. One or more bearer contexts are activated on MME, Serving GW and
PDN GW, which is not shown in the figure.
The first time the UE reselects GERAN or UTRAN it initiates a Routing Area Update. This represents an occasion to
activate ISR. The TIN indicates "GUTI" so the UE indicates a P-TMSI mapped from a GUTI in the RAU Request. The
SGSN gets contexts from MME. When the MME sends the context to the SGSN, the MME includes the ISR supported
indication only if the involved S-GW supports the ISR. After the ISR activated, both CN nodes keep these contexts
because ISR is being activated. The SGSN establishes a control relation with the Serving GW, which is active in
parallel to the control connection between MME and Serving GW (not shown in figure). The RAU Accept indicates
ISR activation to the UE. The UE keeps GUTI and P-TMSI as registered, which the UE memorises by setting the TIN
to "RAT-related TMSI". The MME and the SGSN are registered in parallel with the HSS.
After ISR activation, the UE may reselect between E-UTRAN and UTRAN/GERAN without any need for updating the
network as long as the UE does not move out of the RA/TA(s) registered with the network.
The network is not required to activate ISR during a RAU or TAU. The network may activate ISR at any RAU or TAU
that involves the context transfer between an SGSN and an MME. The RAU procedure for this is shown in Figure J.3-1.
3GPP
Release 15 394 3GPP TS 23.401 V15.10.0 (2019-12)
ISR activation for a UE, which is already attached to GERAN/UTRAN, with a TAU procedure from E-UTRAN works
in a very similar way.
UE MME SGSN HSS

1. Attach Request (old GUTI (real GUTI or mapped from P-TMSI))
2. HSS interactions
3. Attach Accept (GUTI)
MME registered
Attach Accept never indicates
ISR activation,
so UE sets TIN to „GUTI“
Normal Attach procedure, nothing special for ISR
besides deactivation of any potential old ISR states
4. RAU Request (P-TMSI (mapped from GUTI because TIN = “GUTI”))
5. Context Request
6. Context Response (ISR capability)
7. Context Ack (ISR actived)
store SGSN ID store MME ID
8. HSS interactions
9. RAU Accept (P-TMSI, ISR)
SGSN registered
RAU Accept indicates ISR,
so UE sets TIN to „RAT-related
TMSI“, ISR is activated RAU procedure with ISR activation, UE has valid MM
contexts for SGSN and MME, SGSN and MME have
valid MM registration from UE, SGSN and MME are
registered with HSS
Figure J.3-1: ISR Activation example
J.4 Downlink data transfer

Figure J.4-1 shows a downlink data transfer to an idle state UE when ISR is activated. The Serving GW receives
downlink data. Because of activated ISR, the Serving GW has control connections with both MME and SGSN and
sends therefore downlink data notifications to both nodes. MME and SGSN start their paging procedures, which results
in paging of the UE in the registered RA and TA(s) in parallel.
In the example illustrated in Figure J.4-1 it is assumed that the UE camps on E-UTRAN. So the UE responds to paging
as usual with Service Request. This triggers the MME to setup the user plane connection between eNodeB and Serving
GW. The downlink data are transferred to the UE.
When the UE camps on UTRAN/GERAN it performs the paging response as specified for these access systems without
any required update or other signalling before. The downlink data are then transferred via UTRAN/GERAN to the UE.
3GPP
Release 15 395 3GPP TS 23.401 V15.10.0 (2019-12)
UE eNodeB RNC/BSC MME SGSN S-GW P-GW
1. Downlink Data
3a. Paging
2b. Downlink Data Notification
4a. Paging 3b. Paging
4b. Paging
5. Service Request
6. User Plane Setup
7. Downlink Data Transfer
Figure J.4-1: Downlink data transfer with ISR active
J.5 ISR deactivation

Deactivation of ISR for the UE does not require any specific functionality. The status of ISR activation is refreshed in
every RAU and TAU Accept message. If there is no explicit indication of ISR Activated in these messages then ISR is
deactivated and the UE sets its TIN to "GUTI" or "P-TMSI", as specified in Table 4.3.5.6-1. This causes always ISR
deactivation when a UE performs a RAU with a Gn/Gp SGSN of any standards release as these SGSNs never indicate
"ISR Activated" to the UE.
J.6 Handling of special situations

Situations may occur that cause unsynchronized state information in the UE, MME and SGSN. Such situations are:
- 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;
- Missing periodic TA or RA updates, e.g. because the coverage of a RAT is lost or the RAT is no more selected
by the UE (this may result also in implicit detach by SGSN or MME);
- CN node change resulting in context transfer between the same type of CN nodes (SGSN to SGSN or MME to
MME);
- Serving GW change (both with and without UE mobility);
- Change of the UE specific DRX parameters;
- Change of the UE Core Network Capabilities;
- E-UTRAN selection by a UTRAN-connected UE (e.g. when in URA_PCH to release Iu on UTRAN side);
E-UTRAN selection from GERAN READY state;
- GERAN selection by an E-UTRAN-connected UE via Cell Change Order that is not for CS fallback.
There are no ISR specific procedures to handle such situations to avoid additional complexity and error cases. All
special situations that cause context in the UE, MME and SGSN to become asynchronous are handled by ISR
deactivation. The normal RAU/TAU procedures synchronize contexts in MME and SGSN and activate ISR again when
wanted by the network.
3GPP
Release 15 396 3GPP TS 23.401 V15.10.0 (2019-12)
Some specific handling is defined to enable combined MME/SGSN. For this the UE signals at UTRAN RRC level
always an Intra Domain NAS Node Selector (IDNNS) derived from the ID signalled as P-TMSI (also when mapped
from GUTI). At E-UTRAN RRC level the UE indicates the GUMMEI derived from the GUTI that is signalled in the
TAU Request message (also when derived from P-TMSI). This handling is performed by the UE independent from the
network configuration. It is not visible to the UE whether MME and SGSN are combined.
Given the IP-based architecture of EPS and the IP-based applications such establishment and deactivation of the EPS
bearer or PDP context can happen frequently before the UE changes the RAT e.g. a UE asking for delivery of an SMS
(over IP) or starting a VoIP over IMS, an entirely new EPS bearer or PDP context may be established for that purpose.
Then, after the application/service is finished, the newly established EPS bearer or PDP context gets deactivated. In
such particular situation the deactivation of the ISR at the UE and hence performing a RAU or TAU update when the
UE changes the RAT is not needed. Preventing the UE from deactivating the ISR in this case ensures an efficient usage
of the UE's battery power and reduces the unnecessary signalling load that is seen as the key objective to be achieved by
introducing the ISR feature. Thus, UE only locally deactivates ISR when bearer existed at the time of ISR is activated,
or when UE changes RAT with bearers which are created after ISR is activated.
3GPP
Release 15 397 3GPP TS 23.401 V15.10.0 (2019-12)
Annex K (informative):
Isolated E-UTRAN Operation for Public Safety
K.1 General description of the IOPS concept

Isolated E-UTRAN Operation for Public Safety (IOPS) provides the ability to maintain a level of communications for
public safety users, via an IOPS-capable eNB (or set of connected IOPS-capable eNBs), following the loss of backhaul
communications.
The Isolated E-UTRAN mode of operation is also applicable to the formation of a Nomadic EPS deployment, i.e. a
deployment of one or more standalone IOPS-capable eNBs, creating a serving radio access network without backhaul
communications and also providing local IP connectivity and services to public safety users in the absence of normal
EPS infrastructure availability.
This annex provides implementation and deployment guidelines for the operation of public safety networks in the no
backhaul (to Macro EPC) scenario using a Local EPC approach.
K.2 Operation of isolated public safety networks using a

Local EPC
K.2.1 General Description

This approach to the provision of isolated operation (e.g. when there is no S1 connectivity to the macro EPC) assumes
that the IOPS-capable eNB is co-sited with, or can reach, a Local EPC instance which is used in IOPS mode. The Local
EPC instance includes at least MME, SGW/PDN GW and HSS functionality.
A PLMN identity is dedicated to IOPS mode of operation and is broadcast in System Information by the eNB when
IOPS mode is in operation. Only authorized IOPS-enabled UEs can access a PLMN indicated as an IOPS PLMN.
Support of application services over the IOPS network will be based upon the LTE-Uu radio interface and EPS bearer
services supported by the Local EPC. An IOPS network will provide local IP connectivity services, i.e. IP address
assignment and local routing in the IOPS network. During the attachment procedure to the local EPC a local IP address
is assigned to the UE as per the standard procedure when attaching to a Macro EPC. The Local EPC acts as an IP router
among the UEs locally attached to the same IOPS network. When operating in IOPS mode IOPS-enabled UEs only use
the appropriate USIM credentials defined in the UICC, i.e. those defined exclusively for use in an IOPS PLMN.
K.2.2 UE configuration
An IOPS-enabled UE has the dedicated IOPS PLMN identity configured in a separate dedicated USIM application as an
HPLMN along with the Access Class status of 11 or 15, subject to regional/national regulatory requirements and
operator policy.
NOTE: Access Class 15 can be reserved for use by network operator personnel who are responsible for critical
recovery operations of the network.
An IOPS-enabled UE can display information on available PLMNs, including the IOPS PLMN, assisting the user to
activate an appropriate USIM application. Subject to user preferences, e.g. to maintain a group communication, the user
can perform a manual USIM application switch at any time.
When an authorized IOPS-enabled UE, with the dedicated IOPS USIM application activated, selects an IOPS-mode
cell, it selects the dedicated IOPS PLMN identity, attaches to the IOPS PLMN (supported by the Local EPC) and is
authenticated using security procedures as specified in TS 33.401 [41] and the security credentials from the active IOPS
USIM application.
3GPP
Release 15 398 3GPP TS 23.401 V15.10.0 (2019-12)
K.2.3 IOPS network configuration

An IOPS network can comprise either:
- a Local EPC and a single isolated IOPS-capable eNB, which may be co-located or have connectivity to the Local
EPC; or
- a Local EPC and two or more IOPS-capable eNBs, which have connectity to a single Local EPC.
Existing procedures described in TS 36.300 [5] can be used to achieve dynamic configuration of the S1-MME interface.
An IOPS-capable eNB can be pre-provisioned with IP endpoint information, relating to the MMEs of one or more
candidate Local EPC instances. For each local MME in turn the eNB can try to initialize a SCTP association. Once
SCTP connectivity has been established, the eNB and local MME exchange application level configuration data over
the S1-MME application protocol with the S1 Setup Procedure (see TS 36.413 [36]). In line with local operator policies
the eNB can be provisioned with the IP endpoint of a preferred Local EPC MME instance and the IP endpoints of one
or more alternative Local EPC MME instances. The alternative Local EPC instances will be used if an S1-MME path
cannot be established with the local MME of the preferred Local EPC instance.
All Local EPCs deployed by a public safety authority / operator assume the same PLMN-Id. In order to achieve the
broadcast of different TAIs on separate IOPS networks the TACs broadcast by the cells of eNBs connected to different
Local EPCs are distinct to ensure the required UE mobility behaviour (see clause K.2.5). Therefore, the TAC broadcast
by the cells of an eNB operating in IOPS mode will be dependent upon the Local EPC to which the eNB has established
an S1-MME connection.
If the scope of service of a Local EPC is a single eNB, then all cells served by the eNB share the same TAC (assigned
for use in IOPS mode) and neighbouring eNBs that are also operating in IOPS mode with the same dedicated PLMN-Id
are assigned different TACs (resulting in different TAIs) so a TAU attempt is triggered upon mobility.
If multiple eNBs are configured to be served by a single Local EPC, configuration of TAIs for IOPS can be done
according to local operator policies in such a way that a reselection to a cell operating a PLMN in normal mode always
triggers an attach request.
If sharing the same PLMN-Id, it is assumed the TAC assigned to cells in a Nomadic EPS would be different from the
TACs assigned to infrastructure eNBs operating in IOPS mode, so as to trigger a TAU between these systems.
The support by IOPS network entities of S1-flex and/or eMBMS is up to local operator policy and configuration.
K.2.4 IOPS network establishment/termination

The decision by an IOPS-capable eNB to enter IOPS mode of operation is made in accordance with the local policies of
the RAN operator. Such policies can be affected by any RAN sharing agreements that are in place.
In situations when the backhaul to the Macro EPC is lost and an eNB can start IOPS mode of operation based on local
policies, or an eNB is deployed as part of a Nomadic EPS, the following eNB behaviour is expected:
- If the eNB can reach a Local EPC for IOPS mode of operation, the eNB uses the Local EPC.
- If the eNB cannot reach a Local EPC, then the eNB enters a state where UEs do not attempt to select the cells
under its control.
In this release of the specification IOPS networks will be established by the independent actions of each eNB entering
IOPS mode of operation. An IOPS network comprising two or more eNBs will be established as a result of multiple
eNBs entering IOPS mode of operation and establishing S1-MME paths to the local MME of the same Local EPC
instance.
An eNB in IOPS mode of operation, indicates/broadcasts the IOPS PLMN cell(s) as "Not Barred" & "Reserved for
Operator Use", for the IOPS PLMN identity, as defined in TS 36.304 [34]. This "Cell Reserved for Operator Use"
feature will allow the IOPS-enabled UEs to get access to the IOPS network while barring other non-IOPS-enabled UEs
in the same area. The dedicated IOPS USIM application configuration (clause K.2.2) is restricted to use only by users
authorised to access a network in IOPS mode of operation.
3GPP
Release 15 399 3GPP TS 23.401 V15.10.0 (2019-12)
When a backhaul to the Macro EPC is re-established, the S1 connections to the Local EPC are released according to the
local IOPS network policies, to move the UEs to Idle mode, and IOPS mode of operation ceases. The PLMN identity of
the Macro EPC is announced by the eNB so that UEs reselect the normal PLMN and attach afresh to the Macro EPC.
Figure K.2.4-1 provides an example of the basic steps involved in IOPS network establishment, access and termination.
3GPP
Release 15 400 3GPP TS 23.401 V15.10.0 (2019-12)
UE eNB Local EPC Macro EPC
A. Initiation of Isolated E-UTRAN operation
1. Attached to macro EPC andnormal MCPTT service
2. eNB detects loss of backhaul
3. Local EPC
activated
4. Establish S1 link to Local EPC
5. Announce IOPS
mode operation
B. Access Local EPS and services
6. UE detects IOPS PLMN and

USIM application is switched
7. UE selects IOPS PLMN
8. Attach to local EPC and request local PDN connection
9. Access local public safety services
C. Resumption of normal operation

10. eNB detects reinstatement of backhaul
11. UE is detached and local S1 connections released
12. Local EPC

de-activated
13. Establish S1 link to Macro EPC
14. eNB announces

normal operation
15. UE detects normal PLMN and
USIM application is switched
16. UE selects normal PLMN
17. Attach to Macro EPC and request normal PDN connection
Figure K.2.4-1: Example of Local EPC based IOPS operation
1) The UE is attached to the Macro EPC accessing normal application (e.g. MCPTT) services.
3GPP
Release 15 401 3GPP TS 23.401 V15.10.0 (2019-12)
2) The eNB detects loss of the backhaul to the Macro EPC and in accordance with local operator policies decides to
activate IOPS mode of operation. The eNB prevents any UEs from selecting the cell, using a suitable mechanism
such as cell barring, until step 3 and step 4 are completed.
3) Local EPC is activated.
NOTE 1: Steps 1, 2 and 3 are not applicable for the Nomadic EPS case.
4) The eNB establishes an S1 link to the Local EPC.
5) The eNB broadcasts the PLMN identity for IOPS operation with the Local EPC and indicates the IOPS PLMN
cell(s) as "Not Barred" & "reserved" for operator use.
6) The UE detects the IOPS PLMN-Id and a decision is made to switch USIM application and the UE activates the
IOPS USIM application.
NOTE 2: It is out of scope of this specification how the decision is made to switch USIM application.
7) The UE selects the IOPS PLMN-Id.
8) The UE attaches to the Local EPC and obtains a local IP address, if authorised.
9) Public safety services supported by the IOPS network can be accessed at this time.
10)At some point in time the eNB detects that the backhaul to the Macro EPC has been restored.
11)S1 connections to the Local EPC are released according to the IOPS network policies to move the UEs to idle
mode.
12)The eNB stops its IOPS mode of operation and the Local EPC is de-activated.
13)The eNB establishes an S1 link to the Macro EPC.
14)The PLMN-Id of the Macro EPC is announced and the normal TAIs of the Macro EPC are advertised by the
eNB so that UEs reselect the normal PLMN.
15)The UE detects the PLMN-Id of the Macro EPC and a decision is made to switch USIM application and the UE
activates the normal USIM application.
NOTE 3: It is out of scope of this specification how the decision is made to switch USIM application.
16)The UE selects the normal PLMN-Id.
17)The UE attaches as normal to the Macro EPC, if authorised.
K.2.5 UE mobility
A number of distinct UE mobility scenarios can be identified given the following assumptions:
- multiple eNBs can be configured to be served by a single Local EPC;
- a single dedicated PLMN-Id will be advertised by all eNBs operating in IOPS mode (of a given public safety
authority/operator);
- the TACs broadcast by cells (eNBs) served by different Local EPCs will be different.
The mobility scenarios that can be distinguished are:
1. UE transitions from a cell controlled by the normal macro EPC to a cell operating in IOPS mode;
2. UE transitions from a cell operating in IOPS mode to a cell controlled by the normal macro EPC;
3. UE transitions from a cell operating in IOPS mode whose eNB is served by one Local EPC to a cell also
operating in IOPS mode whose eNB is served by a different Local EPC (Inter-IOPS network cell transition);
3GPP
Release 15 402 3GPP TS 23.401 V15.10.0 (2019-12)
4. UE transitions between cells operating in IOPS mode whose eNB(s) are served by the same Local EPC (Intra-
IOPS network cell transition).
The expected mobility behaviour in each of these scenarios is summarised in Table K.2.5-1.
Table K.2.5-1: UE mobility behaviour
ECM STATE
MOBILITY IDLE MODE CONNECTED MODE
TRANSITION
Normal mode cell Cell re-selection and USIM application Radio link failure followed by cell re-selection:
to IOPS mode cell switch: - UE performs radio measurements but
- UE performs cell re-selection based source and target cells are on different
IOPS mode cell to upon radio measurements and no networks. The PLMN-Id of the target cell
Normal mode cell suitable cell is found. is not supported by the subscription
- UE switches USIM application. details in the currently selected USIM
- UE performs cell selection and a application. Handover does not occur.
suitable cell is found. - Radio link failure occurs and UE returns
- UE initiates Attach procedure towards to Idle Mode.
Local/Normal EPC. - UE proceeds as per behaviour for Idle
Mode.
Intra-IOPS network Idle Mode mobility as per normal EPC As per normal EPC Connected mode mobility
cell transition mobility. procedures.
Inter-IOPS network Idle Mode mobility as per normal EPC As per normal EPC Connected mode mobility
cell transition mobility. procedures.
3GPP
Release 15 403 3GPP TS 23.401 V15.10.0 (2019-12)
Annex L (informative):
Optimised EPS Architecture option for CIoT
L.1 Introduction
The EPS Optimised for CIoT includes the support of the following characteristics:
- Ultra low UE power consumption.
- Large number of devices per cell.
- Narrowband spectrum RATs.
- Enhanced coverage level.
The EPS Optimised for CIoT supports traffic patterns that is different as compared to the normal UEs and may support
only sub-set and necessary functionalities as compared with the existing EPS.
An EPS Optimised for CIoT can be enabled by having sub-set of functionalities implemented in single logical entity C-
SGN (CIoT Serving Gateway Node). C-SGN is decribed in L.4. Mobility and Attach procedures are performed as
described in other clauses for corresponding entities MME, S-GW and P-GW.
The Core Network node involved in the EPS Architecture optimised for CIoT can be deployed as DCNs within a
PLMN.
L.2 Non-Roaming Architecture

SGd
SMS-GMSC/
IWMSC/
SMS Router
S6a
HSS
T6a
CIoT Uu S1
SCEF
CIoT
E-UTRAN C -SGN
UE
SGi
CIoT Services
Figure L.2-1: Optimised EPS architecture option for CIoT - Non-roaming architecture
3GPP
Release 15 404 3GPP TS 23.401 V15.10.0 (2019-12)
L.3 Roaming architecture

VPLMN
HPLMN
SGd SMS-GMSC/
IWMSC/
SMS Router
S6a
HSS
T6ai T7
IWK-
SCEF
CIoT Uu S1
SCEF
CIoT
E-UTRAN C-SGN
UE SGi
S8
P-GW CIoT Services
Figure L.3-1: Optimised EPS architecture option for CIoT - Roaming architecture
L.4 C-SGN
The C-SGN (CIoT Serving Gateway Node) is a combined node EPC implementation option that minimizes the number
of physical entities by collocating EPS entities in the control and user planes paths (e.g. MME, S-GW, P-GW), which
may be preferred in CIoT deployments. The external interfaces of C-SGN implementation option are the interfaces of
the respective EPC entity supported by the C-SGN, such as MME, S-GW, and P-GW.
A C-SGN supports sub-set and necessary functionalities compared with the existing EPS core network elements and
also supports at least some of the following CIoT EPS Optimisations:
- Control Plane CIoT EPS Optimisation for small data transmission.
- User Plane CIoT EPS Optimisation for small data transmission.
- Necessary security procedures for efficient small data tranmission.
- SMS without combined attach for NB-IoT only UEs.
- Paging optimisations for coverage enhancements.
- Support for non-IP data transmission via SGi tunnelling and/or SCEF.
- Support for Attach without PDN connectivity.
3GPP
Release 15 405 3GPP TS 23.401 V15.10.0 (2019-12)
Annex M (informative):
Functions and procedures over NB-IoT RAT
In the case of conflict between the information in this Annex and other information in the main body of the present
document, the information in the main body takes precedence.
The following tables list the functions and procedures that are:
- Supported or not supported over NB-IoT RAT, including whether for CP CIoT EPS Optimisation only, UP CIoT
EPS Optimisation only or both.
- Optional for the UE and/or network when using NB-IoT RAT.
NOTE: The tables M-1 to M-5 are ordered by clause number according to the present specification. The table M-
6 is ordered by clause number according to TS 23.682 [74]. The notation "CP/UP/Both" indicates whether
a particular item is supported for CP CIoT EPS Optimisation only, UP CIoT EPS Optimisation only or
both.
3GPP
Release 15 406 3GPP TS 23.401 V15.10.0 (2019-12)
Table M-1: Clause 4 Concepts
Clause Clause title Support

NB-IoT RAT CP/UP/Both UE NW
4.3.3 IP header compression
RoHC (NAS) Yes CP Optional Optional
RoHC (AS) Yes UP Optional Optional
4.3.5 Mobility management functions Yes Both
Inter-RAT idle mode NAS Yes Both
mobility (WB-E_UTRAN,
UTRAN, GERAN)
Reachability management Yes Both ISR Optional ISR
Optional
TA list management (2) Yes Both
ISR Yes Both Optional
Mobility restrictions Yes Both
IMS voice over PS session No N/A N/A N/A
supported indication
Voice domain preference No N/A N/A N/A
and UE usage setting
Preferred and supported Yes Both
network behaviour
4.3.7.1a.2 GTP-C Overload Control Yes CP N/A
4.3.7.4 MME control of overload Yes Both N/A
Extended Access Barring No N/A N/A N/A
4.3.7.4.2.7 Control Plane data specific NAS Yes CP
level congestion control
4.3.12 IMS emergency session No N/A N/A N/A
4.3.13 Closed Subscriber Group No N/A N/A N/A
4.3.17 Support for MTC
Low access priority Yes Both Optional
Non-IP data delivery Yes Both
(NIDD)
NIDD SCEF Yes CP N/A (1) Optional (3)
NIDD SGi Yes Both N/A (1) Optional (3)
4.3.18 Multimedia Priority Service No N/A N/A N/A
4.3.22 Power Save Mode Yes Both Optional Optional
4.3.27a Restriction of use of Enhanced No N/A N/A N/A
Coverage for voice centric UE
4.3.27b Restriction of use of Enhanced No N/A N/A N/A
Coverage for data centric UE
4.3.28 Restriction of use of Enhanced Yes Both Optional
Coverage
4.3.29 3GPP PS Data Off Yes Both Optional Optional
4.7 QoS
PDN connection to SCEF Yes CP Optional
Dedicated bearer No N/A N/A N/A
GBR bearer No N/A N/A N/A
Non-GBR bearer Yes UP
Rate control (Serving Yes CP Optional
PLMN)
Rate control (APN) Yes Both Optional
4.7.8 Inter-UE QoS for NB-IoT UEs Yes Yes N/A Optional
using Control Plane CIoT EPS
Optimisation
4.10 CIoT EPS Optimisation
UP Yes UP Optional Optional
CP Yes CP
NOTE 1: Whether the non-IP PDN connection is provided via SCEF or over SGi is transparent to the UE.
NOTE 2: Required for inter-RAT idle mode mobility.
NOTE 3: At least one of NIDD SCEF and NIDD SGi is required.
3GPP
Release 15 407 3GPP TS 23.401 V15.10.0 (2019-12)
Table M-2: Clause 5.3 Authentication, security and location management

5.3.1 IP address allocation (1) Yes Both Not required
for NIDD
5.3.2 Attach procedure Yes Both
Normal attach Yes Both Optional (2)
Attach without PDN Yes Both Optional (2) Optional
connectivity
Emergency attach No N/A N/A N/A
SMS transfer without Yes Both Optional
Combined Attach
5.3.3 TAU procedure Yes (3) Both
5.3.4 Service request procedures Yes Both (4)
5.3.4A Connection Suspend procedure Yes UP
5.3.4B Data transport in CP CIoT EPS Yes CP
Optimisation
Reliable data delivery with Yes CP N/A Optional
hop-by-hop
acknowledgement
5.3.5 S1 release procedure Yes (5)
5.3.5A Connection resume procedure Yes UP
5.3.6A PDN GW pause of charging Yes Both N/A Optional
procedure
5.3.7 GUTI reallocation procedure Yes Both
5.3.8 Detach procedure Yes (6) Both
5.3.10 Security function Yes Both
AS security Yes UP
NAS security Yes Both
5.3.14 UE radio capability match No (7) N/A N/A N/A
request
NOTE 1: Incl. attach without PDN connectivity.
NOTE 2: At least one of Normal attach and Attach without PDN connectivity is required.
NOTE 3: Incl. inter RAT.
NOTE 4: Also supported with CP CIoT EPS Optimisation when the UE/MME also support S1-U data transfer or UP
CIoT EPS Optimisation.
NOTE 5: Releases the S11-U bearer in case of CP CIoT EPS Optimisation. RRC Connection release is used with
the UE.
NOTE 6: ISR aspects optional.
NOTE 7: IMS Voice not supported over NB-IoT.
Table M-3: Clause 5.4 Session management, QoS and interaction with PCC

5.4.1 Dedicated bearer activation No N/A N/A N/A
5.4.2 Bearer modification with QoS Yes UP Optional Optional
update
5.4.3 PDN GW initiated bearer Yes UP
modification without bearer
QoS update
5.4.4 Bearer deactivation Yes UP
5.4.5 UE-requested bearer resource Yes Both Optional with
modification CP CIoT
EPS
Optimisation
5.4.7 E-UTRAN initiated ERAB No (1) N/A N/A N/A
modification procedure
5.4.8 E-UTRAN initiated UE context No (1) N/A N/A N/A
modification procedure
NOTE 1: Dual connectivity not supported over NB-IoT RAT.
3GPP
Release 15 408 3GPP TS 23.401 V15.10.0 (2019-12)
Table M-4: Clauses 5.5 and 5.6 Handover and NACC

5.5 Handover No
5.5.1 Intra-E-UTRAN handover No N/A N/A N/A
5.5.2 Inter RAT handover No N/A N/A N/A
5.6 Network assisted cell change No N/A N/A N/A
Table M-5: Misc.

5.8 MBMS (3) (3) (3) (3) (3)
5.10 Multiple PDN support and PDN Yes (1) Both
activation for UEs supporting
Attach without PDN connectivity
5.11 UE capability handling Yes Both
5.12 Warning message delivery No N/A N/A N/A
5.13 DRX and UE-specific DRX Yes (2) Both
parameter handling
5.13a Extended idle mode DRX Yes Both Optional Optional
5.15 RAN information management No N/A N/A N/A
procedures
5.16 MME-initiated procedure on No N/A N/A N/A
UE's CSG membership change
5.17 HeNB multicast packet No N/A N/A N/A
forwarding function
NOTE 1: Multiple PDN optional.
NOTE 2: UE-specific DRX not supported in NB-IoT RAT.
NOTE 3: See Table M-6.
Table M-6:MTC/CIoT-related items in TS 23.682 [74]

4.5.14.3 Reliable Data Service Yes CP Optional Optional
4.5.15, 5.14 Support of Packet Flow Yes Both N/A Optional
Description management via
SCEF
4.5.16 MSISDN-less MO-SMS via T4 Yes Both Optional Optional
4.5.18 MBMS user service for UEs Yes Both Optional Optional
using power saving functions
4.5.19 Enhancements to Location Yes Both Optional Optional
Services for CIoT
NOTE: This table lists MTC/CIoT-related items in TS 23.682 [74] not otherwise specified in the present
specification.
3GPP
Release 15 409 3GPP TS 23.401 V15.10.0 (2019-12)
Annex N (informative):
Change history
3GPP
Release 15 410 3GPP TS 23.401 V15.10.0 (2019-12)
Change history
Date Meeting TDoc CR Rev Cat Subject/Comment New
version
2013-06 SP-60 SP-130225 2518 1 A Clarification that IMSVoPS is MMTEL 12.1.0
2013-06 SP-60 SP-130225 2520 2 A Immediate Cancel Location ACK during HSS-initiated detach 12.1.0
procedure
2013-06 SP-60 SP-130324 2521 3 B ISR handling in SIPTO at local network 12.1.0
2013-06 SP-60 SP-130324 2538 3 C Direct user plane path establishment for SIPTO at local network on 12.1.0
eNodeB
2013-06 SP-60 SP-130305 2540 1 A Clarification on operations related to dual priority 12.1.0
2013-06 SP-60 SP-130232 2541 5 D Correct inconsistency with Stage 1 regarding support for emergency 12.1.0
bearer services in the serving network
2013-06 SP-60 SP-130310 2546 5 F Correction to PDN Deactivation for SIPTO@LN 12.1.0
2013-06 SP-60 SP-130232 2557 2 B Individual subscription migration and subscriber troubleshooting 12.1.0
2013-06 SP-60 SP-130232 2559 1 B Addition of End Marker Support for Handover Scenarios with SGW 12.1.0
Relocation
2013-06 SP-60 SP-130310 2561 - F Correction on the applicability of SIPTO@LN at a CSG cell 12.1.0
2013-06 SP-60 SP-130232 2562 3 C Use of Low Access Priority Indication to select MME 12.1.0
2013-06 SP-60 SP-130232 2566 3 F Use of MM backoff timer for voice centric devices 12.1.0
2013-09 SP-61 SP-130375 2528 2 A Interoperation between MME and Gn/Gp SGSN 12.2.0
2013-09 SP-61 SP-130384 2567 2 B Introduction of GTP-c Load Control 12.2.0
2013-09 SP-61 SP-130374 2569 2 A Clarifications on QoS and roaming 12.2.0
2013-09 SP-61 SP-130384 2571 2 B GTP-C overload handling 12.2.0
2013-09 SP-61 SP-130379 2574 2 F Correction of SIPTO at Local Network 12.2.0
2013-09 SP-61 SP-130375 2576 1 A Fix equivalent PLMN list handling 12.2.0
2013-09 SP-61 SP-130385 2578 2 C Addition of a note in general description of inter-RAT HO 12.2.0
2013-09 SP-61 SP-130372 2582 2 A Reporting ULI and TimeZone at Network-initiated bearer release 12.2.0
related procedures
2013-09 SP-61 SP-130378 2584 2 A Avoiding PDN GW relocation when radio and S1 bearers are active 12.2.0
2013-09 SP-61 SP-130379 2585 1 F Correction of Local Home Network 12.2.0
2013-09 SP-61 SP-130379 2587 1 F Clarification on deactivating SIPTO@LN upon idle mode mobility 12.2.0
2013-12 SP-62 SP-130524 2554 4 A DL traffic mapping alignment with TS 23.060. 12.3.0
2013-12 SP-62 SP-130524 2590 1 A Clarification on the handling non-MM message during handover 12.3.0
2013-12 SP-62 SP-130726 2594 12 B Core Network assisted eNodeB parameters tuning 12.3.0
2013-12 SP-62 SP-130524 2597 2 A Handling of uplink packet filters and definition for a valid state of the 12.3.0
TFT setting
2013-12 SP-62 SP-130669 2598 6 B PDN GW and SGW Charging alignment in downlink 12.3.0
2013-12 SP-62 SP-130526 2600 1 F Correction on the conditions for including the Local Home Network 12.3.0
ID
2013-12 SP-62 SP-130526 2602 1 F Clarification for Optimisation of LIPA and SIPTO@LN paging 12.3.0
2013-12 SP-62 SP-130529 2603 9 B Introducing UE Power Saving Mode 12.3.0
2013-12 SP-62 SP-130540 2605 2 F Addition of a note addressing the behavior of network side during 12.3.0
inter-RAT 3GPP PS Handover
2013-12 SP-62 SP-130526 2607 1 F Deactivate ISR for SIPTO@LN 12.3.0
2013-12 SP-62 SP-130526 2610 - F Correction in Local Home Network ID definition 12.3.0
2013-12 SP-62 SP-130526 2611 1 F Corrections in handover and TAU/RAU procedures related to SIPTO 12.3.0
at local network
2013-12 SP-62 SP-130526 2612 - F Correcting reference to the SIPTO@LN clause 12.3.0
2013-12 SP-62 SP-130534 2613 2 F Use of LAPI for MME/SGSN selection during handover 12.3.0
2013-12 SP-62 SP-130523 2616 - A Local deactivation of ISR to resume packet services 12.3.0
2013-12 SP-62 SP-130524 2621 3 A Fix downlink packet delivery failure due to crash with mobility event 12.3.0
2013-12 SP-62 SP-130533 2622 - B HPLMN Notification with specific indication due to MME initiated 12.3.0
Bearer removal
2013-12 SP-62 SP-130534 2623 5 B Reporting ULI and TimeZone at MME-initiated bearer related 12.3.0
procedures
2013-12 SP-62 SP-130533 2624 - F Correction on the network management functions 12.3.0
2013-12 SP-62 SP-130533 2625 2 F Rollback behaviour for EPC 12.3.0
2013-12 SP-62 SP-130583 2627 5 B Introduction of ULI reporting at PCC area level 12.3.0
2013-12 SP-62 SP-130585 2629 3 B Introduction of ULI reporting only when the UE is in 'CONNECTED' 12.3.0
state
2013-12 SP-62 SP-130534 2632 1 F Modification on Inter-RAT Handover from UTRAN/GERAN to E- 12.3.0
UTRAN
2014-03 SP-63 SP-140111 2634 2 F Corrections for the PDN GW pause of charging functionality 12.4.0
2014-03 SP-63 SP-140106 2635 2 F Corrections for presence reporting area based location reporting 12.4.0
2014-03 SP-63 SP-140108 2636 2 F Delayed release of UE IP address during inter-RAT 3GPP PS 12.4.0
Handover
2014-03 SP-63 SP-140106 2637 2 B Presence Reporting Area provided by OCS 12.4.0
2014-03 SP-63 SP-140104 2638 3 F Power Saving Mode applicability 12.4.0
2014-03 SP-63 SP-140111 2641 2 F Fix downlink message delivery failure due to crash with mobility 12.4.0
event
2014-03 SP-63 SP-140098 2644 - A Correction of IETF reference on prefix delegation 12.4.0
2014-06 SP-64 SP-140255 2654 1 A Add PCO handling to the PDN GW initiated bearer modification 12.5.0
3GPP
Release 15 411 3GPP TS 23.401 V15.10.0 (2019-12)
procedure
3GPP
Release 15 412 3GPP TS 23.401 V15.10.0 (2019-12)
2014-06 SP-64 SP-140377 2655 2 F PDN GW pause of charging functionality and inter-operator charging 12.5.0
2014-06 SP-64 SP-140272 2656 1 F Correction of possible PDN GW actions during PDN connection 12.5.0
termination
2014-06 SP-64 SP-140262 2658 3 B Introduction of Dual Connectivity Function 12.5.0
2014-06 SP-64 SP-140256 2660 3 A IRAT handover MME handling 12.5.0
2014-06 SP-64 SP-140251 2663 1 A Correction on priority paging 12.5.0
2014-06 SP-64 SP-140377 2672 - F Handling of MME UE S1AP ID in case of S1 release 12.5.0
2014-06 SP-64 SP-140257 2679 5 F Clarifying when the PDN GW can set ULI reporting, CSG reporting 12.5.0
and PRA reporting
2014-06 SP-64 SP-140263 2680 1 F Clarification on ISR for PSM UE 12.5.0
2014-06 SP-64 SP-140257 2681 1 F Clarifications for presence reporting area based location reporting 12.5.0
2014-06 SP-64 SP-140263 2683 2 F Clarifications for Power Savings Mode 12.5.0
2014-06 SP-64 SP-140263 2684 9 F CN Assistance information for eNB parameters setting 12.5.0
2014-06 SP-64 SP-140256 2689 2 A Clarification on MME behaviour on roaming situation 12.5.0
2014-06 SP-64 SP-140377 2693 3 F Inter PLMN handover for emergency bearer service 12.5.0
2014-06 SP-64 SP-140377 2694 5 F Correction to the MME initiated bearer setup during the TAU 12.5.0
procedure
2014-06 SP-64 SP-140377 2695 1 F PDN GW initiated bearer request message arrival during the TAU 12.5.0
2014-06 SP-64 SP-140257 2696 3 F Correction of ULI reporting only when the UE is in 'CONNECTED' 12.5.0
state
2014-06 SP-64 SP-140270 2697 4 B Traffic steering for RAN-based WLAN interworking solution 12.5.0
2014-06 SP-64 SP-140262 2707 4 B Introduction of Dual Connectivity Operation 12.5.0
2014-06 SP-64 SP-140377 2715 2 F Correction on the description of Location Service function 12.5.0
2014-09 SP-65 SP-140427 2722 1 B Changes and corrections related to GTP-C Load/Overload Control 12.6.0
feature
2014-09 SP-65 SP-140490 2727 4 F Clarifications for PRA reporting 12.6.0
2014-09 SP-65 SP-140424 2735 3 F Update of 'WLAN offloadability' indication via NAS 12.6.0
2014-09 SP-65 SP-140429 2723 1 F Clarification on roaming subscription corresponding to specific RAT 13.0.0
for TS 23.401
2014-09 SP-65 SP-140428 2728 2 B Introducing RAN Congestion Awareness Function 13.0.0
2014-09 SP-65 SP-140428 2733 2 B Introduction of User plane congestion management function 13.0.0
2014-12 SP-66 SP-140688 2731 7 B Paging policy differentiation for IMS voice 13.1.0
2014-12 SP-66 SP-140675 2746 - A Handling of E-UTRAN Inter RAT Handover information at PS 13.1.0
Handover from GERAN
2014-12 SP-66 SP-140686 2747 2 A Paging enhancements for Low Complexity UE 13.1.0
2014-12 SP-66 SP-140680 2752 1 A Correction of the CN assisted eNodeB parameter tuning 13.1.0
2014-12 SP-66 SP-140686 2754 1 A Pending Subscription Change 13.1.0
2014-12 SP-66 SP-140684 2756 - A Support of non-seamless offloading with RAN rules 13.1.0
2014-12 SP-66 SP-140684 2758 1 A Clarification on the RAN assistance parameters based on RAN WGs 13.1.0
agreements
2014-12 SP-66 SP-140674 2759 3 A Clarifications for TFT handling 13.1.0
2014-12 SP-66 SP-140685 2761 1 A Clarifications for Multimedia Priority Services 13.1.0
2014-12 SP-66 SP-140684 2764 1 A Clarification of WLAN offload indication from MME in E-UTRAN 13.1.0
2014-12 SP-66 SP-140678 2769 2 A QoS handling at inter-RAT mobility 13.1.0
2014-12 SP-66 SP-140672 2773 1 A Correction of 'extended wait timers' in RRC signalling 13.1.0
2014-12 SP-66 SP-140685 2779 1 A Correction to the Low Access Priority Indication use by the network 13.1.0
2014-12 SP-66 SP-140689 2780 3 F Adding interoperabilty aspects between RAN and CN for the CN- 13.1.0
based solution
2014-12 SP-66 SP-140669 2786 1 A Handling CS Service Notification received during handover 13.1.0
2014-12 SP-66 SP-140685 2789 1 A Clarification to non-3GPP access to 3GPP access handover 13.1.0
procedure
2014-12 SP-66 SP-140687 2790 2 A E-UTRAN initiated E-RAB modification procedure update 13.1.0
2014-12 SP-66 SP-140689 2797 - C MME - RCAF interface 13.1.0
2014-12 SP-66 SP-140670 2810 1 A UE capability storage in the MME 13.1.0
2015-03 SP-67 SP-150024 2805 5 F Enhancements when determine the list of UEs served by a E- 13.2.0
UTRAN cell
2015-03 SP-67 SP-150109 2812 2 A Paging priority setting in the MME 13.2.0
2015-03 SP-67 SP-150021 2821 1 A Clarify handling of "MS Info Change Reporting Action" at change of 13.2.0
Serving Node for an UE.
2015-03 SP-67 SP-150025 2822 4 B Group specific NAS Level congestion control 13.2.0
2015-03 SP-67 SP-150109 2825 1 A Downlink packet delivery failure during mobility event 13.2.0
2015-03 SP-67 SP-150027 2840 2 C Paging Priority for Push To Talk 13.2.0
2015-03 SP-67 SP-150027 2842 1 F Fixing the MME behaviour for NAS message transfer 13.2.0
2015-06 SP-68 SP-150230 2831 1 A Correcting ESM re-activation attempts at PLMN change when only 13.3.0
one IP version is supported by the network
2015-06 SP-68 SP-150234 2837 11 B Introduce the Dedicated Core Network (DECOR) feature 13.3.0
2015-06 SP-68 SP-150237 2843 2 B APN and group specific NAS Level congestion control 13.3.0
2015-06 SP-68 SP-150236 2850 2 B Update to PSM to support monitoring events 13.3.0
2015-06 SP-68 SP-150236 2851 2 B Support for Monitoring Events 13.3.0
2015-06 SP-68 SP-150237 2853 - C MCC CR Implementation correction: Group specific NAS Level 13.3.0
congestion control
2015-06 SP-68 SP-150239 2857 1 F Paging priority and ARP Priority level: extension of CR2812r2 to 13.3.0
3GPP
Release 15 413 3GPP TS 23.401 V15.10.0 (2019-12)
CR2840r2
3GPP
Release 15 414 3GPP TS 23.401 V15.10.0 (2019-12)
2015-06 SP-68 SP-150229 2861 3 A MS Info Change Reporting Action at change of Serving Node (MME 13.3.0
<--> SGSN): Update of call Flows
2015-06 SP-68 SP-150238 2862 3 B Introducing functions for High latency communication 13.3.0
2015-06 SP-68 SP-150234 2864 3 B Adding support for load re-balancing within DCN 13.3.0
2015-06 SP-68 SP-150239 2865 - F User CSG Information in TAU/RAU with SGW change procedure 13.3.0
2015-06 SP-68 SP-150237 2866 3 F Group specific NAS Level congestion control for multiple APNs 13.3.0
2015-06 SP-68 SP-150236 2871 2 B Monitoring event configuration in the HSS and MME 13.3.0
2015-06 SP-68 SP-150235 2872 2 B HSS and MME updates for AESE 3GPP resource optimisations 13.3.0
based on providing predictable communication patterns of a UE to
the MME
2015-06 SP-68 SP-150230 2876 1 A Dual connectivity handling for the failed E-RAB(s) 13.3.0
2015-06 SP-68 SP-150237 2877 1 F Clarification of Group specific NAS Level congestion control 13.3.0
2015-06 SP-68 SP-150284 2869 2 A Clarification on Network Triggered Service Request 13.3.0
2015-09 SP-69 SP-150502 2883 3 B Introducing eDRX for High latency communication 13.4.0
2015-09 SP-69 SP-150502 2884 - F Non-Applicability of HLCom Monitoring Events feature to Gn/Gp- 13.4.0
SGSN
2015-09 SP-69 SP-150501 2887 1 B Introducing the solution for S/P-GW retransmissions when handling 13.4.0
Network originated control plane procedure
2015-09 SP-69 SP-150501 2889 2 B Introducing extended Idle mode DRX feature to LTE 13.4.0
2015-09 SP-69 SP-150505 2891 - F Add reference to the MME/SGSN selection function 13.4.0
2015-09 SP-69 SP-150505 2892 3 B Paging optimisations 13.4.0
2015-09 SP-69 SP-150490 2894 1 A Adding PSM parameters in the MME/UE contexts 13.4.0
2015-09 SP-69 SP-150502 2895 1 F Clarification of High latency communication 13.4.0
2015-09 SP-69 SP-150496 2898 1 F Corrections for dedicated core network procedures 13.4.0
2015-09 SP-69 SP-150496 2900 1 F Enhanced HO procedrue for DECOR 13.4.0
2015-09 SP-69 SP-150491 2902 - A Correction of Access network selection and traffic steering based on 13.4.0
RAN-assisted WLAN interworking
2015-09 SP-69 SP-150493 2903 2 B Add informative annex containing implementation and deployment 13.4.0
guidelines for IOPS
2015-12 SP-70 SP-150609 2905 3 F Update for UE Reachability Notifications 13.5.0
2015-12 SP-70 SP-150615 2906 2 B UE radio capability for paging optimisation 13.5.0
2015-12 SP-70 SP-150603 2912 4 F Correct inconsistencies in the description of USIM switching 13.5.0
2015-12 SP-70 SP-150606 2915 3 F UE Usage Type in handovers 13.5.0
2015-12 SP-70 SP-150611 2916 9 B Paging for extended idle mode DRX in LTE 13.5.0
2015-12 SP-70 SP-150603 2920 1 F Corrections related to public safety network operator and IOPS 13.5.0
network
2015-12 SP-70 SP-150606 2921 2 F UE Usage Type in Re-route message 13.5.0
2015-12 SP-70 SP-150615 2924 1 F Correction to PDN GW initiated bearer deactivation 13.5.0
2015-12 SP-70 SP-150796 2926 4 F Clarification of QoS modifications restrictions 13.5.0
2015-12 SP-70 SP-150606 2927 2 F Retrieval of UE Usage Type from HSS 13.5.0
2015-12 SP-70 SP-150615 2928 3 F Inclusion of RAN/NAS Cause in Delete Bearer Response 13.5.0
2015-12 SP-70 SP-150611 2929 1 F Clarification on using eDRX in case of emergency bearer services 13.5.0
2015-12 SP-70 SP-150615 2935 3 B Addition of CRLWI support 13.5.0
2015-12 SP-70 SP-150606 2936 1 F Providing IMSI in DÉCOR redirection procedure 13.5.0
2015-12 SP-70 SP-150606 2943 - F Enhanced HO procedrue for DECOR 13.5.0
2015-12 SP-70 SP-150737 2917 3 B Enhanced Coverage for paging in LTE 13.5.0
2016-03 SP-71 SP-160161 2930 11 B Introduction of solution 18 - suspend and resume procedure 13.6.0
2016-03 SP-71 SP-160161 2934 9 B Introducing support for Non-IP data for CIoT 13.6.0
2016-03 SP-71 SP-160161 2941 5 B Introducing CIoT Optimisations 13.6.0
2016-03 SP-71 SP-160161 2942 13 B Introduction of Control Plane CIoT EPS optimisation 13.6.0
2016-03 SP-71 SP-160161 2948 8 B Introduction of support for NB-IoT 13.6.0
2016-03 SP-71 SP-160161 2951 9 B Introduction of attach procedure changes for CIoT EPS Optimisation. 13.6.0
2016-03 SP-71 SP-160156 2953 - A Correction in MME triggered Serving GW relocation procedure 13.6.0
2016-03 SP-71 SP-160161 2954 3 B Detach procedure for CIoT optimisation 13.6.0
2016-03 SP-71 SP-160163 2958 1 F Fix wrong wording on DNS procedure for DECOR 13.6.0
2016-03 SP-71 SP-160161 2959 4 B TAU procedure update for CIoT EPS Optimisation 13.6.0
2016-03 SP-71 SP-160163 2961 1 F Alignment of support for DECOR in shared networks 13.6.0
2016-03 SP-71 SP-160161 2965 2 B CIoT-centric single node EPS architecture 13.6.0
2016-03 SP-71 SP-160164 2966 2 F Handling of a 5.12s eDRX cycle 13.6.0
2016-03 SP-71 SP-160162 2976 2 F List of External Identifiers in the Subscription Data 13.6.0
2016-03 SP-71 SP-160161 2977 2 B UE Capability Handling for Control Plane CIoT EPS optimisation 13.6.0
2016-03 SP-71 SP-160161 2980 4 B Disabling IRAT mobility to and from NB-IOT 13.6.0
2016-03 SP-71 SP-160161 2981 3 B Support for overload control 13.6.0
2016-03 SP-71 SP-160161 2982 2 B HLcom feature update for CP optimisation 13.6.0
2016-03 SP-71 SP-160161 2985 1 B RAU procedure update for CIoT EPS Optimisation 13.6.0
2016-03 SP-71 SP-160161 2986 3 B TAU procedure update with Gn/Gp SGSN for CIoT EPS optimisation 13.6.0
2016-03 SP-71 SP-160161 2988 2 B Handover for non-NB-IoT devices using CIoT optimisations 13.6.0
2016-03 SP-71 SP-160161 2989 1 B DRX handling for NB-IoT 13.6.0
2016-03 - - - - - MCC correction to change positions of (new) clauses 4.10 and 4.11 13.6.1
for more logical clause ordering
2016-06 SP-72 SP-160292 2956 7 B Support of CSG, LIPA, and SIPTO@LN functions for dual 13.7.0
connectivity
3GPP
Release 15 415 3GPP TS 23.401 V15.10.0 (2019-12)
2016-06 SP-72 SP-160298 2964 2 B Priority Treatment based on RRC Establishment Cause 13.7.0
2016-06 SP-72 SP-160286 2992 3 F Alignment of S11-U procedures with stage 3 13.7.0
2016-06 SP-72 SP-160286 2993 3 F Correction of CIoT inter-RAT handover conditions 13.7.0
2016-06 SP-72 SP-160286 2994 4 F Corrections for Header Compression in CP optimisation 13.7.0
2016-06 SP-72 SP-160286 2995 8 F Simultaneous support for CP and UP optimisation 13.7.0
2016-06 SP-72 SP-160286 2996 1 F Paging for CE in CP optimisation 13.7.0
2016-06 SP-72 SP-160286 2997 3 F Support for SMS using CP optimisation 13.7.0
2016-06 SP-72 SP-160286 2998 4 C Active flag handling for Control Plane CIoT Optimisation 13.7.0
2016-06 SP-72 SP-160286 2999 8 F Support for rate control of CIoT data 13.7.0
2016-06 SP-72 SP-160286 3000 1 F IRAT stage 3 reattach alignment 13.7.0
2016-06 SP-72 SP-160298 3002 1 F 'UE reachability' event reports for UEs using extended idle mode 13.7.0
DRX
2016-06 SP-72 SP-160286 3008 1 F Introduction of S11-U TEID for Control Plane CIoT EPS optimisation 13.7.0
2016-06 SP-72 SP-160286 3012 1 F Clarification of the S1 release procedure usage in context of CIOT 13.7.0
CP EPS Optimisation
2016-06 SP-72 SP-160286 3013 1 F Alignment of MME selection in Attach and TAU procedures with 13.7.0
clause 4.3.8.3 'MME selection function'
2016-06 SP-72 SP-160286 3014 1 F Network features need to be consistent across TAI LIST 13.7.0
2016-06 SP-72 SP-160286 3015 4 F RRC layer impacts and System information usage in attach 13.7.0
procedure
2016-06 SP-72 SP-160286 3017 - F Clarification on CIoT EPS Optimisation conflicting terminology 13.7.0
2016-06 SP-72 SP-160286 3022 - F Handover support for Header Compression in CP optimisation 13.7.0
2016-06 SP-72 SP-160289 3023 2 F Pending data and user inactivity 13.7.0
2016-06 SP-72 SP-160286 3026 3 F Support for UP optimisation from CP optimisation in ECM-IDLE state 13.7.0
2016-06 SP-72 SP-160286 3035 2 F Correction on MME overload control for CIOT 13.7.0
2016-06 SP-72 SP-160286 3041 1 F Introduction of Connection Establishment Indication procedure 13.7.0
2016-06 SP-72 SP-160286 3042 - F Updates of handover procedures for CIoT Optimisation 13.7.0
2016-06 SP-72 SP-160286 3046 1 F MME selection for CIoT Optimisation 13.7.0
2016-06 SP-72 SP-160286 3049 1 F TAU trigger for Preferred Network Behaviour change 13.7.0
2016-06 SP-72 SP-160286 3051 - F Handling of Exception Reports in the Core Network 13.7.0
2016-06 SP-72 SP-160299 2971 5 B Addition of eCall for IMS Emergency Services 14.0.0
2016-06 SP-72 SP-160303 3024 2 B UE assisted DCN selection 14.0.0
2016-09 SP-73 SP-160653 3050 8 B Support of Multiple PRAs 14.1.0
2016-09 SP-73 SP-160648 3052 1 B Adding support for NonIP & SCEF in GERAN 14.1.0
2016-09 SP-73 SP-160633 3058 1 A Clarifying PDN GW & SCEF role in APN Rate Control 14.1.0
2016-09 SP-73 SP-160649 3059 1 C Load balancing for MMEs with multiple DCN support 14.1.0
2016-09 SP-73 SP-160633 3062 1 A Clarification of new active flag handling for CP CIoT EPS 14.1.0
Optimisation
2016-09 SP-73 SP-160649 3063 1 B Relation between the Usage Type and DCN ID 14.1.0
2016-09 SP-73 SP-160649 3064 2 B The DCN ID related serving PLMN information 14.1.0
2016-09 SP-73 SP-160633 3068 - A Updates of eDRX for NB-IoT 14.1.0
2016-09 SP-73 SP-160633 3072 1 A Voice related indication for NB-IoT 14.1.0
2016-09 SP-73 SP-160633 3074 1 A Priority handling of NAS signalling and CIoT data over NAS 14.1.0
2016-09 SP-73 SP-160649 3078 1 F Clarification on usage of default standardized or PLMN specific 14.1.0
DCN-ID.
2016-09 SP-73 SP-160633 3083 - A Transfer of cell/TAC's RAT type to MME 14.1.0
2016-09 SP-73 SP-160634 3085 1 A Release Assistance Information for pair of packets 14.1.0
2016-09 SP-73 SP-160652 3087 1 B Handling of handovers for emergency sessions over WLAN 14.1.0
2016-09 SP-73 SP-160659 3088 2 C Operator management of eDRX parameters 14.1.0
2016-09 SP-73 SP-160634 3091 2 A Clarification on S1-U establishment during CP optimisation is in use 14.1.0
2016-09 SP-73 SP-160634 3094 - A Correction of Connection Suspend 14.1.0
2016-09 SP-73 SP-160634 3099 1 A Correction to reporting of MO exception data 14.1.0
2016-09 SP-73 SP-160652 3100 1 B PDN GW selection for emergency services with unauthenticated 14.1.0
UEs
2016-09 SP-73 SP-160658 3101 1 B Adding eNodeB change reporting in Location Change Reporting 14.1.0
Procedure
2016-09 SP-73 SP-160634 3105 2 A Multiple DRB capability handling 14.1.0
2016-09 SP-73 SP-160649 3106 - C DCN Congestion Control 14.1.0
2016-09 SP-73 SP-160649 3107 1 C DCN-ID update 14.1.0
2016-09 SP-73 SP-160634 3109 1 A Clarification on CP only indicator for SGi PDN connections 14.1.0
2016-09 SP-73 SP-160635 3111 1 A Correction on Bearer Synchronization for UP CIoT EPS optimisation 14.1.0
2016-09 SP-73 SP-160635 3112 2 A Control Plane Only PDN Connection Indication in PDN setup 14.1.0
2016-09 SP-73 SP-160635 3120 2 A Handling of S11-U bearer during service request procedure 14.1.0
2016-09 SP-73 SP-160635 3122 1 A Correction of UE-AMBR and APN-AMBR handling for CIoT EPS 14.1.0
Optimisation
2016-09 SP-73 SP-160658 3123 1 B Adding eNodeB change reporting to message flows 14.1.0
2016-09 SP-73 SP-160635 3128 3 A Clarification on NAS level congestion for exception reporting. 14.1.0
2016-09 SP-73 SP-160635 3129 1 A Clarification on EAB and low access priority indication in RRC over 14.1.0
NB-IOT
2016-12 SP-74 SP-160807 3070 4 A NAS PDU retransmission strategy for CIoT Optimisation 14.2.0
2016-12 SP-74 SP-160817 3130 1 F Corrections for allowing seamless handovers of emergency sessions 14.2.0
to WLAN
3GPP
Release 15 416 3GPP TS 23.401 V15.10.0 (2019-12)
2016-12 SP-74 SP-160823 3131 4 C Reliable UE delivery based on hop-by-hop acknowledgements (5c) 14.2.0
2016-12 SP-74 SP-160823 3135 4 B Authorization of use of Coverage Enhancement 14.2.0
2016-12 SP-74 SP-160825 3137 1 F Clarifying the UE behaviour for switch to UP 14.2.0
2016-12 SP-74 SP-160807 3139 - A Correction of handling of resume cause 14.2.0
2016-12 SP-74 SP-160807 3141 1 A APN Rate Control and emergency bearer service 14.2.0
2016-12 SP-74 SP-160823 3143 2 B Control Plane data back-off timer introduction 14.2.0
2016-12 SP-74 SP-160825 3144 2 F Missing indirect forwarding tunnel deletion in TAU with SGW change 14.2.0
2016-12 SP-74 SP-160823 3145 2 B Support for Inter-UE QoS for NB-IoT Control Plane Optimisation 14.2.0
2016-12 SP-74 SP-160807 3148 2 A Aligning specifications - no RAT type in the Initial UE Message 14.2.0
2016-12 SP-74 SP-160807 3151 1 A Correction on MT Data transport using CP CIoT EPS Optimisation 14.2.0
2016-12 SP-74 SP-160823 3152 3 B CIoT_KI7_Sol9 - Overload Start for control plane data 14.2.0
2016-12 SP-74 SP-160818 3153 2 F MME report for set of PRA 14.2.0
2016-12 SP-74 SP-160807 3154 1 A Clarification on APN Rate Control 14.2.0
2016-12 SP-74 SP-160823 3156 2 B UE radio capability handling for UEs supporting NB-IoT and WB-E- 14.2.0
UTRAN
2016-12 SP-74 SP-160808 3158 - A Correction to reporting of MO exception data 14.2.0
2016-12 SP-74 SP-160810 3159 1 A UE Usage Type Withdraw 14.2.0
2016-12 SP-74 SP-160826 3161 4 B Introduction of PS Data Off feature 14.2.0
2016-12 SP-74 SP-160823 3163 2 B Location service message size adaptation according to coverage 14.2.0
level
2016-12 SP-74 SP-160823 3164 2 B Inter-RAT idle mode mobility to and from NB-IoT 14.2.0
2017-03 SP-75 SP-170053 3167 1 F RAB Setup information in the IRAT handover 14.3.0
2017-03 SP-75 SP-170050 3169 2 F Corrections of UE capability information to eNB for CP CIoT UEs 14.3.0
2017-03 SP-75 SP-170050 3170 1 F Correction of CE authorization in TAU 14.3.0
2017-03 SP-75 SP-170050 3171 1 F Support for restriction of Enhanced coverage restriction per RAT 14.3.0
2017-03 SP-75 SP-170050 3172 2 F Enhanced Coverage Restricted parameter in S1-AP in TAU 14.3.0
2017-03 SP-75 SP-170050 3173 1 F Location reporting using Control Plane CIOT EPS Optimisation 14.3.0
2017-03 SP-75 SP-170043 3175 2 A No need to support UE requested bearer resource modification for 14.3.0
CP CIOT
2017-03 SP-75 SP-170043 3177 4 A No support for Serving PLMN Rate Control across multiple PDN 14.3.0
connections
2017-03 SP-75 SP-170043 3179 1 A Indication for support of User Plane CIOT Optimisation to E-UTRAN 14.3.0
2017-03 SP-75 SP-170043 3181 4 A Correction of Serving PLMN rate control 14.3.0
2017-03 SP-75 SP-170050 3188 1 F Restriction of use of Coverage Enhancement clarification for 14.3.0
roaming UEs
2017-03 SP-75 SP-170042 3195 3 A Priority Treatment based on RRC Establishment Cause 14.3.0
2017-03 SP-75 SP-170052 3200 1 C TS 23.401 support for transport level packet marking 14.3.0
2017-03 SP-75 SP-170050 3202 2 F Correction to the Control Plane data back-off timer 14.3.0
2017-03 SP-75 SP-170042 3209 1 A Restriction of CE Mode B with dedicated bearer requirements 14.3.0
2017-06 SP-76 SP-170370 3210 3 F Clarification for PDN GW handling of IMS services at 3GPP PS Data 14.4.0
Off activation
2017-06 SP-76 SP-170361 3214 1 A Correction Serving PLMN Rate Control and APN Rate Control 14.4.0
2017-06 SP-76 SP-170361 3219 1 A Correction of forwarding of MO Exception Data Counter 14.4.0
2017-06 SP-76 SP-170367 3221 2 F Handling of emergency call numbers received from WLAN 14.4.0
2017-06 SP-76 SP-170365 3222 1 F Radio capabilities for eCall Only Mode 14.4.0
2017-06 SP-76 SP-170369 3231 - F Clarification for congestion control for default APN 14.4.0
2017-06 SP-76 SP-170369 3233 - F Removal of UE-AMBR from Inter-UE QoS for NB-IoT UEs using 14.4.0
Control Plane CIoT EPS Optimisation
2017-06 SP-76 SP-170363 3236 2 A Handling of CE Mode B support for "Voice Centric" UEs 14.4.0
2017-06 SP-76 SP-170361 3248 2 A PDN-Connection-Restricted flag 14.4.0
2017-06 SP-76 SP-170372 3252 2 F Voice/Video support for "Data Centric" UEs operating in CE Mode 14.4.0
A/B
2017-06 SP-76 SP-170369 3254 1 F Clarification on mobility support between NB-IoT and GPRS 14.4.0
2017-06 SP-76 SP-170375 3225 5 B TS 23.401 Subscription Control for EPC_DC_NR 15.0.0
2017-06 SP-76 SP-170513 3234 3 B PDN GW selection for 5GC UE 15.0.0
2017-06 SP-76 SP-170375 3257 1 B UE capability handling for EPC_DC_NR 15.0.0
2017-09 SP-77 SP-170728 3255 1 B Updated scope for Dual Connectivity with other RATs 15.1.0
2017-09 SP-77 SP-170728 3258 2 B Per EPS bearer, RAN selection of DC (or non-DC) usage 15.1.0
2017-09 SP-77 SP-170719 3260 2 A Corrections to PDN GW handling of UE Data Off Status 15.1.0
2017-09 SP-77 SP-170723 3262 1 A Alignment with eNB and MME CP Relocation Indication procedures 15.1.0
2017-09 SP-77 SP-170728 3267 5 B Secondary RAT related data usage reporting 15.1.0
2017-09 SP-77 SP-170716 3271 2 A Correction on the condition for stopping Control Plane back-off timer 15.1.0
at the UE
2017-09 SP-77 SP-170728 3272 6 B Indication NR is available to use 15.1.0
2017-09 SP-77 SP-170728 3273 1 B NAS UE indicator for Dual Connectivity with NR 15.1.0
2017-09 SP-77 SP-170715 3277 1 A DCNs without HSS subscription information 15.1.0
2017-09 SP-77 SP-170728 3279 1 F Subscription Control for EPC_DC_NR 15.1.0
2017-09 SP-77 SP-170728 3285 3 B Control of Secondary RAT data volume reporting 15.1.0
2017-09 SP-77 SP-170732 3286 2 F Handling of multiple CP parameter sets 15.1.0
2017-09 SP-77 SP-170729 3289 2 C 23.401 PCEF Support for Data Off phase 2 15.1.0
2017-09 SP-77 SP-170716 3291 1 A Correction for Data Centric UEs 15.1.0
2017-09 SP-77 SP-170728 3299 1 B RAN specification reference for EN-DC 15.1.0
3GPP
Release 15 417 3GPP TS 23.401 V15.10.0 (2019-12)
2017-09 SP-77 SP-170728 3300 1 F Clarification to DC procedure when NR is used as secondary RAT 15.1.0
2017-09 SP-77 SP-170713 3301 2 A No support of dedicated bearers for NB-IoT 15.1.0
2017-09 SP-77 SP-170713 3304 1 A Correction of header compression for CP optimisation 15.1.0
2017-09 SP-77 SP-170728 3306 - B Subscription Control for EPC_DC_NR: handover from Gn/Gp SGSN 15.1.0
2017-09 SP-77 SP-170713 3314 - A Correction of APN rate control enforcement and exceptional MO 15.1.0
data
2017-09 SP-77 SP-170713 3316 - A Correction of forwarding of MO Exception Data Counter 15.1.0
2017-09 SP-77 SP-170726 3319 - A CP only UE support of bearer modification and HC negotiation 15.1.0
2017-12 SP-78 SP-170912 3295 1 A Correction of capability indication for downlink NAS data PDU 15.2.0
acknowledgment
2017-12 SP-78 SP-170909 3321 1 A Correction of APN Rate Control - interoperability with legacy UEs 15.2.0
2017-12 SP-78 SP-170914 3324 1 A Update of TAU procedure with SGW change and data forwarding 15.2.0
2017-12 SP-78 SP-170920 3325 3 C Secondary RAT related data usage reporting improvements 15.2.0
2017-12 SP-78 SP-170920 3326 3 F Secondary RAT related data usage reporting format from RAN 15.2.0
2017-12 SP-78 SP-170920 3327 1 F Secondary RAT related data usage reporting corrections 15.2.0
2017-12 SP-78 SP-170924 3328 4 B Introduction of Service Gap Control 15.2.0
2017-12 SP-78 SP-170921 3331 - C Clarification on UE behavior when receiving single list of Exempt 15.2.0
Services - TS 23.401
2017-12 SP-78 SP-170920 3332 1 F Clarification of the case that HSS provide the Access Restriction 15.2.0
2017-12 SP-78 SP-170926 3335 4 B Enhanced VoLTE performance CR for TS 23.401 15.2.0
2017-12 SP-78 SP-170909 3340 1 A Non-IP protection from broadcast messages 15.2.0
2017-12 SP-78 SP-170920 3342 - F Correction on the update of RAN in subscription change 15.2.0
2017-12 SP-78 SP-170924 3344 1 C Reliable Data Service with PtP SGi Tunneling 15.2.0
2017-12 SP-78 SP-170912 3346 4 A S11-U interface separation from S1-U interface 15.2.0
2017-12 SP-78 SP-170912 3348 3 A Data support for "voice centric" UE supporting CE mode B 15.2.0
2017-12 SP-78 SP-170924 3353 2 F Modify Bearer Request during TAU 15.2.0
2017-12 SP-78 SP-170909 3356 2 A UE CIoT capability in RRC Connection Establishment request for 15.2.0
TAU
2017-12 SP-78 SP-170927 3357 1 B Data volume reporting when secondary RAT is using unlicensed 15.2.0
spectrum
2017-12 SP-78 SP-170927 3358 1 B RAT Restriction when secondary RAT is using unlicensed spectrum 15.2.0
2017-12 SP-78 SP-170924 3359 3 C Use of ARP priority level in addition to QCI for packet handling 15.2.0
2017-12 SP-78 SP-170920 3360 1 F Correcting the condition for selection of PGW and SGW for NR as 15.2.0
secondary RAT
2017-12 SP-78 SP-170920 3362 2 F Corrections to secondary RAT usage data reporting 15.2.0
2017-12 SP-78 SP-170912 3364 2 A Non-overlapping MMECs for CP CIOT EPS Optimisation 15.2.0
2017-12 SP-78 SP-170919 3365 2 B Dual registration supported indicator from MME 15.2.0
2017-12 SP-78 SP-170915 3367 2 A Clarification on PS Data Off status reporting - TS 23.401 15.2.0
2017-12 SP-78 SP-170920 3368 1 F Cleaup related to Secondary RAT related data usage reporting 15.2.0
2017-12 SP-78 SP-170941 3372 3 F Correction to Enhanced Coverage restriction 15.2.0
2017-12 SP-78 SP-170918 3375 1 A CIoT corrections related to PDN Connections 15.2.0
2017-12 SP-78 SP-170924 3376 - D Editorial corrections for CIoT 15.2.0
2018-03 SP-79 SP-180113 3378 1 F Alignment CR for for storing CE mode B UE capability in MME 15.3.0
2018-03 SP-79 SP-180113 3381 2 F Clarification on PRA reporting in ECM-IDLE state 15.3.0
2018-03 SP-79 SP-180085 3391 1 A Addition of EC restriction parameter in S1 AP PAGING message 15.3.0
2018-03 SP-79 SP-180113 3392 2 C MME handling of unsupported APN 15.3.0
2018-03 SP-79 SP-180112 3396 3 B Feature definition for supporting 15 EPS bearers 15.3.0
2018-03 SP-79 SP-180090 3398 1 F Interworking aspects of EPS with 5GS are captured in 23.501 and 15.3.0
23.502
2018-03 SP-79 SP-180111 3403 1 F Alignment with stage-3 reporting and access restriction for 15.3.0
unlicensed spectrum
2018-03 SP-79 SP-180108 3405 1 F Missing identification of step in clause 5.3.8.4 15.3.0
2018-03 SP-79 SP-180089 3407 1 A Correction to eNB CP Relocation Indication procedure 15.3.0
2018-06 SP-80 SP-180498 3350 4 B Additional parameters for NB-IoT UE Uu operation optimisation 15.4.0
2018-06 SP-80 SP-180496 3404 6 B Identification of LTE-M (eMTC) traffic 15.4.0
2018-06 SP-80 SP-180496 3408 5 F Correction of APN Rate Control for PDN connection release and re- 15.4.0
establishment
2018-06 SP-80 SP-180496 3410 3 F Alignment with CT1/RAN on handling of S1AP CONNECTION 15.4.0
ESTABLISHMENT INDICATION
2018-06 SP-80 SP-180497 3411 4 B Subscription for Aerial UE in 3GPP system 15.4.0
2018-06 SP-80 SP-180495 3412 2 F Clarification of using more than eight EPS bearers with EPS 15.4.0
2018-06 SP-80 SP-180496 3413 1 F Alignment with CT WG1 for handling of Connection Resume 15.4.0
Requests at Service Gap
2018-06 SP-80 SP-180472 3416 1 A 3GPP PS Data Off Clarification 15.4.0
2018-06 SP-80 SP-180472 3418 1 A Correction of non-3GPP to E-UTRAN handovers 15.4.0
2018-06 SP-80 SP-180495 3419 2 B UE Capability for supporting 15 EPS bearers 15.4.0
2018-06 SP-80 SP-180495 3420 2 B Network support for increased number of bearers 15.4.0
2018-06 SP-80 SP-180471 3423 5 F Radio efficient handling of large UE radio capabilities at inter-RAT 15.4.0
and SRVCC handover
2018-06 SP-80 SP-180492 3426 3 F Handling of very large UE radio capabilities for the anticipated EN- 15.4.0
DC UEs
2018-06 SP-80 SP-180471 3429 - A Handling of large UE radio capabilities at inter-RAT and SRVCC 15.4.0
3GPP
Release 15 418 3GPP TS 23.401 V15.10.0 (2019-12)
handover
2018-06 SP-80 SP-180495 3430 - C Support for 15 bearers in PGWs across PLMN 15.4.0
2018-06 SP-80 SP-180496 3436 1 B Introducing Early Data Transmission for Control Plane CIoT EPS 15.4.0
optimization
2018-06 SP-80 SP-180496 3438 3 F Applicability of Service Gap Control in idle and connected mode 15.4.0
2018-06 SP-80 SP-180496 3440 4 F MME request for UE Radio Capabilities 15.4.0
2018-06 SP-80 SP-180492 3441 2 F Secondary RAT Usage Reporting with multiple PDN connection 15.4.0
2018-09 SP-81 SP-180729 3443 1 F Negotiation of long periodic TAU timer value 15.5.0
2018-09 SP-81 SP-180729 3444 6 F UE Radio Capability Update using TAU procedure 15.5.0
2018-09 SP-81 SP-180729 3445 5 C Further proposal for subscribed PTW length 15.5.0
2018-09 SP-81 SP-180729 3446 1 F Corrections for ARP priority level 15.5.0
2018-09 SP-81 SP-180729 3448 8 F Clarification on EDT procedure 15.5.0
2018-09 SP-81 SP-180725 3450 1 F Correction on Secondary RAT data usage report 15.5.0
2018-09 SP-81 SP-180729 3451 - F UE radio capabilities - alignment with rSRVCC from GERAN 15.5.0
2018-09 SP-81 SP-180728 3452 5 B Traffic Profile for NB-IoT UE Uu operation optimisation 15.5.0
2018-09 SP-81 SP-180711 3458 1 A Corrections to re-negotiation of header compression configuration 15.5.0
2018-09 SP-81 SP-180729 3459 2 F Correction of APN Rate Control Status in bearer deactivation 15.5.0
2018-12 SP-82 SP-181095 3460 3 F AS RAI system impacts 15.6.0
2018-12 SP-82 SP-181080 3466 1 A Reporting PS Data Off status change when SM back off timer is 15.6.0
running
2018-12 SP-82 SP-181080 3470 1 A PS Data Off supporting non-IP data 15.6.0
2018-12 SP-82 SP-181082 3472 1 A Correction of reference in Control Plane NAS congestion control 15.6.0
2018-12 SP-82 SP-181095 3476 3 F RAT specific subscribed PTW length 15.6.0
2018-12 SP-82 SP-181095 3479 2 F Corrections to Service Gap Control 15.6.0
2018-12 SP-82 SP-181093 3481 2 F End marker and ERAB Modification for Dual Connectivity 15.6.0
2018-12 SP-82 SP-181093 3482 1 F Correction of Secondary RAT periodic reporting description 15.6.0
2018-12 SP-82 SP-181095 3485 1 F Correction of Serving PLMN Rate Control 15.6.0
2019-03 SP-83 SP-190153 3493 - F End marker and ERAB Modification interaction for Dual Connectivity 15.7.0
2019-06 SP-84 SP-190403 3505 4 B Updating LCS procedures for location reporting for multiple cells 15.8.0
2019-06 SP-84 SP-190404 3506 2 C TNL Address discovery for EN-DC 15.8.0
2019-06 SP-84 SP-190403 3513 2 F Secondary Cell ID Reporting - completion and signalling efficiency 15.8.0
2019-06 SP-84 SP-190399 3515 - D Interworking aspects of EPS with 5GS are captured in 23.501 and 15.8.0
23.502
2019-09 SP-85 SP-190603 3529 2 F Location Reporting: LI and signalling load 15.9.0
2019-09 SP-85 SP-190603 3531 1 F Location Reporting: periodic PSCell ID reporting 15.9.0
2019-12 SP-86 SP-191065 3567 2 F System support for NB-IoT Paging across Multiple Carriers and/or 15.10.0
WUS with WB-EUTRAN <-> NB-IoT mobility
3GPP

3GPP TS 23.401: Technical Specification

Uploaded by

Copyright:

Available Formats

3GPP TS 23.401: Technical Specification

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

3GPP TS 23.401: Technical Specification

Uploaded by

Copyright:

Available Formats

3GPP TS 23.401 V15.10.

3GPP support office address

No part may be reproduced except as authorized by written permission.

4.3.7.5 PDN GW control of overload.................................................................................................................46

4.3.20 Relaying function.........................................................................................................................................72

4.6.4 State transition and functions.......................................................................................................................93

5.3.13.2 Insert CSG Subscriber Data procedure................................................................................................218

Annex A (informative): Void.....................................................................................................................340

Annex B (informative): Void......................................................................................................................341

Annex C (informative): Void.....................................................................................................................342

Annex D (normative): Interoperation with Gn/Gp SGSNs.....................................................................343

D.1 General Considerations.......................................................................................................................343

Annex E (normative): Mapping between EPS and Release 99 QoS parameters....................................381

Annex G (informative): Void.....................................................................................................................387

Annex H (normative): Mapping between temporary and area identities...............................................388

Annex I (informative): Guidance for contributors to this specification.................................................389

Annex J (informative): High Level ISR description.................................................................................390

J.1 General description of the ISR concept..............................................................................................390

K.1 General description of the IOPS concept............................................................................................395

Annex L (informative): Optimised EPS Architecture option for CIoT..................................................401

Annex N (informative): Change history....................................................................................................407

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.

TS 23.402 [2] is a companion specification to this specification.

- For a specific reference, subsequent revisions do not apply.

[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

[6] 3GPP TS 23.203: "Policy and charging control architecture".

[8] 3GPP TS 43.129: "Packet-switched handover for GERAN A/Gb mode; Stage 2".

[9] 3GPP TS 23.003: "Numbering, addressing and identification".

[13] 3GPP TS 23.246: "Multimedia Broadcast/Multicast Service (MBMS); Architecture and functional

[15] 3GPP TS 43.051: "GERAN Overall description - Stage 2".

[16] 3GPP TS 25.401: "UTRAN overall description".

[18] IETF RFC 4862: "IPv6 Stateless Address Autoconfiguration".

[19] IETF RFC 2131: "Dynamic Host Configuration Protocol".

[24] 3GPP TS 23.251: "Network Sharing; Architecture and functional description".

[26] IETF RFC 768: "User Datagram Protocol".

[27] 3GPP TS 23.221: "Architectural requirements".

[28] 3GPP TS 23.008: "Organization of subscriber data".

[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".

[35] IETF RFC 4960: "Stream Control Transmission Protocol".

[36] 3GPP TS 36.413: "Evolved Universal Terrestrial Access Network (E-UTRAN); S1 Application

[40] 3GPP TS 33.102: "3G Security; Security architecture".

[41] 3GPP TS 33.401: "3GPP System Architecture Evolution: Security Architecture".

[44] 3GPP TS 32.251: "Telecommunication management; Charging management; Packet Switched

[45] 3GPP TS 24.007: "Mobile radio interface signalling layer 3; General aspects".

[48] 3GPP TS 23.041: "Technical realization of Cell Broadcast Service (CBS)".

[51] 3GPP TS 32.240: "Charging architecture and principles".

[52] 3GPP TS 23.228: "IP Multimedia Subsystem (IMS); Stage 2".

[55] IETF RFC 3168: "The Addition of Explicit Congestion Notification (ECN) to IP".

[57] 3GPP TS 23.271: "Functional stage 2 description of LCS".

[59] 3GPP TS 23.107: "Quality of Service (QoS) concept and architecture".

[61] 3GPP TS 29.303: "Domain Name System Procedures; Stage 3".

[62] IETF RFC 3376: "Internet Group Management Protocol, Version 3".