no1111

3GPP TS 24.301 V16.8.0 (2021-03)

Technical Specification

3rd Generation Partnership Project;

Technical Specification Group Core Network and Terminals;

Non-Access-Stratum (NAS) protocol
for Evolved Packet System (EPS);
Stage 3

(Release 16)

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-VJYxrWFB-1640135278133)(media/853fb87c480a030fbccdff6b4a87b895.jpeg)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-5vbab1kT-1640135278136)(media/ca6ad1ac71b640e80f3a13a13edde329.png)]

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
Organisational Partners and shall not be implemented.
This Specification is provided for future development work within 3GPP only. The
Organisational 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 Organisational Partners’ Publications Offices.

Keywords

UMTS, GSM, EPS, GPRS, stage 3, radio, layer 3, user equipment, network, LTE

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.

© 2021, 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

Contents

Foreword 21

1 Scope 22

2 References 22

3 Definitions and abbreviations 26

3.1 Definitions 26

3.2 Abbreviations 32

4 General 34

4.1 Overview 34

4.2 Linkage between the protocols for EPS mobility management and EPS session
management 34

4.2A Handling of NAS signalling low priority indication 35

4.3 UE mode of operation 35

4.3.1 General 35

4.3.2 Change of UE mode of operation 37

4.3.2.1 General 37

4.3.2.2 Change of UE’s usage setting 39

4.3.2.3 Change of voice domain preference for E-UTRAN 40

4.3.2.4 Change or determination of IMS registration status 41

4.3.2.5 Change of configuration regarding the use of SMS. 43

4.4 NAS security 44

4.4.1 General 44

4.4.2 Handling of EPS security contexts 44

4.4.2.1 General 44

4.4.2.2 Establishment of a mapped EPS security context during intersystem
handover 46

4.4.2.3 Establishment of secure exchange of NAS messages 46

4.4.2.4 Change of security keys 49

4.4.2.5 Derivation of keys at CS to PS SRVCC handover from A/Gb mode to S1 mode
or from Iu mode to S1 mode 49

4.4.3 Handling of NAS COUNT and NAS sequence number 50

4.4.3.1 General 50

4.4.3.2 Replay protection 51

4.4.3.3 Integrity protection and verification 51

4.4.3.4 Ciphering and deciphering 52

4.4.3.5 NAS COUNT wrap around 52

4.4.4 Integrity protection of NAS signalling messages 52

4.4.4.1 General 52

4.4.4.2 Integrity checking of NAS signalling messages in the UE 53

4.4.4.3 Integrity checking of NAS signalling messages in the MME 53

4.4.5 Ciphering of NAS signalling messages 55

4.5 Disabling and re-enabling of UE’s E-UTRA capability 56

4.6 Applicability of procedures 59

4.6.1 Relay nodes 59

4.7 EPS mobility management and EPS session management in NB-S1 mode 59

4.8 EPS mobility management and EPS session management in WB-S1 mode for IoT 59

4.9 Disabling and re-enabling of UE’s NB-IoT capability 60

5 Elementary procedures for EPS mobility management 61

5.1 Overview 61

5.1.1 General 61

5.1.2 Types of EMM procedures 61

5.1.3 EMM sublayer states 63

5.1.3.1 General 63

5.1.3.2 EMM sublayer states in the UE 63

5.1.3.2.1 General 63

5.1.3.2.2 Main states 63

5.1.3.2.2.1 EMM-NULL 63

5.1.3.2.2.2 EMM-DEREGISTERED 63

5.1.3.2.2.3 EMM-REGISTERED-INITIATED 63

5.1.3.2.2.4 EMM-REGISTERED 63

5.1.3.2.2.5 EMM-DEREGISTERED-INITIATED 64

5.1.3.2.2.6 EMM-TRACKING-AREA-UPDATING-INITIATED 64

5.1.3.2.2.7 EMM-SERVICE-REQUEST-INITIATED 64

5.1.3.2.3 Substates of state EMM-DEREGISTERED 65

5.1.3.2.3.1 General 65

5.1.3.2.3.2 EMM-DEREGISTERED.NORMAL-SERVICE 65

5.1.3.2.3.3 EMM-DEREGISTERED.LIMITED-SERVICE 65

5.1.3.2.3.4 EMM-DEREGISTERED.ATTEMPTING-TO-ATTACH 65

5.1.3.2.3.5 EMM-DEREGISTERED.PLMN-SEARCH 65

5.1.3.2.3.6 EMM-DEREGISTERED.NO-IMSI 65

5.1.3.2.3.7 EMM-DEREGISTERED.ATTACH-NEEDED 65

5.1.3.2.3.8 EMM-DEREGISTERED.NO-CELL-AVAILABLE 65

5.1.3.2.3.9 EMM-DEREGISTERED.eCALL-INACTIVE 65

5.1.3.2.4 Substates of state EMM-REGISTERED 66

5.1.3.2.4.1 General 66

5.1.3.2.4.2 EMM-REGISTERED.NORMAL-SERVICE 66

5.1.3.2.4.3 EMM-REGISTERED.ATTEMPTING-TO-UPDATE 66

5.1.3.2.4.4 EMM-REGISTERED.LIMITED-SERVICE 66

5.1.3.2.4.5 EMM-REGISTERED.PLMN-SEARCH 66

5.1.3.2.4.6 EMM-REGISTERED.UPDATE-NEEDED 66

5.1.3.2.4.7 EMM-REGISTERED.NO-CELL-AVAILABLE 66

5.1.3.2.4.8 EMM-REGISTERED.ATTEMPTING-TO-UPDATE-MM 67

5.1.3.2.4.9 EMM-REGISTERED.IMSI-DETACH-INITIATED 67

5.1.3.3 EPS update status 67

5.1.3.4 EMM sublayer states in the MME 67

5.1.3.4.1 EMM-DEREGISTERED 67

5.1.3.4.2 EMM-COMMON-PROCEDURE-INITIATED 67

5.1.3.4.3 EMM-REGISTERED 67

5.1.3.4.4 EMM-DEREGISTERED-INITIATED 68

5.1.4 Coordination between EMM and GMM 68

5.1.5 Coordination between EMM and MM 69

5.2 Behaviour of the UE in state EMM-DEREGISTERED and state EMM-REGISTERED 69

5.2.1 General 69

5.2.2 UE behaviour in state EMM-DEREGISTERED 70

5.2.2.1 General 70

5.2.2.2 Primary substate selection 70

5.2.2.2.1 Selection of the substate after power on 70

5.2.2.3 Detailed description of UE behaviour in state EMM-DEREGISTERED 70

5.2.2.3.1 NORMAL-SERVICE 70

5.2.2.3.2 LIMITED-SERVICE 71

5.2.2.3.3 ATTEMPTING-TO-ATTACH 71

5.2.2.3.4 PLMN-SEARCH 71

5.2.2.3.5 NO-IMSI 71

5.2.2.3.6 ATTACH-NEEDED 72

5.2.2.3.7 NO-CELL-AVAILABLE 72

5.2.2.3.8 eCALL-INACTIVE 72

5.2.2.4 Substate when back to state EMM-DEREGISTERED from another EMM state 72

5.2.3 UE behaviour in state EMM-REGISTERED 73

5.2.3.1 General 73

5.2.3.2 Detailed description of UE behaviour in state EMM-REGISTERED 73

5.2.3.2.1 NORMAL-SERVICE 73

5.2.3.2.2 ATTEMPTING-TO-UPDATE 73

5.2.3.2.3 LIMITED-SERVICE 74

5.2.3.2.4 PLMN-SEARCH 74

5.2.3.2.5 UPDATE-NEEDED 75

5.2.3.2.6 NO-CELL-AVAILABLE 75

5.2.3.2.7 ATTEMPTING-TO-UPDATE-MM 75

5.2.3.2.8 IMSI-DETACH-INITIATED 75

5.3 General on elementary EMM procedures 76

5.3.1 EMM modes and NAS signalling connection 76

5.3.1.1 Establishment of the NAS signalling connection 76

5.3.1.2 Release of the NAS signalling connection 77

5.3.1.2.1 General 77

5.3.1.2.2 UE is using EPS services with control plane CIoT EPS optimization 80

5.3.1.3 Suspend and resume of the NAS signalling connection 80

5.3.2 Lists of forbidden tracking areas 81

5.3.3 List of forbidden PLMNs for attach in S101 mode 81

5.3.3a Forbidden PLMNs for EPS services 82

5.3.4 Equivalent PLMNs list 82

5.3.5 Handling of the periodic tracking area update timer and mobile reachable
timer (S1 mode only) 82

5.3.6 Handling of timer T3402 84

5.3.7 Handling of the Local Emergency Numbers List and the Extended Local
Emergency Numbers List 84

5.3.7a Specific requirements for UE configured to use timer T3245 86

5.3.7b Specific requirements for UE when receiving non-integrity protected
reject messages 86

5.3.8 Abnormal cases in the UE 89

5.3.9 Handling of NAS level mobility management congestion control 89

5.3.9A Handling of congestion control for transport of user data via the control
plane 90

5.3.10 Access class control 90

5.3.11 Power saving mode 91

5.3.12 Extended idle-mode DRX cycle 92

5.3.13 Interaction between power saving mode and extended idle mode DRX cycle 92

5.3.14 Dedicated core network 92

5.3.15 CIoT EPS optimizations 93

5.3.16 Restriction on use of enhanced coverage 94

5.3.17 Service Gap Control 95

5.3.18 Restricted local operator services 96

5.3.19 Core Network selection and redirection for UEs using CIoT optimizations
97

5.3.19.1 Core network selection 97

5.3.19.2 Redirection of the UE by the core network 97

5.3.20 UE radio capability signalling optimisation 97

5.3.21 Wake-up signal assistance 99

5.4 EMM common procedures 100

5.4.1 GUTI reallocation procedure 100

5.4.1.1 General 100

5.4.1.2 GUTI reallocation initiation by the network 100

5.4.1.3 GUTI reallocation completion by the UE 101

5.4.1.4 GUTI reallocation completion by the network 101

5.4.1.5 Abnormal cases in the UE 101

5.4.1.6 Abnormal cases on the network side 102

5.4.2 Authentication procedure 103

5.4.2.1 General 103

5.4.2.2 Authentication initiation by the network 103

5.4.2.3 Authentication response by the UE 104

5.4.2.4 Authentication completion by the network 105

5.4.2.5 Authentication not accepted by the network 105

5.4.2.6 Authentication not accepted by the UE 106

5.4.2.7 Abnormal cases 107

5.4.3 Security mode control procedure 112

5.4.3.1 General 112

5.4.3.2 NAS security mode control initiation by the network 112

5.4.3.3 NAS security mode command accepted by the UE 115

5.4.3.4 NAS security mode control completion by the network 117

5.4.3.5 NAS security mode command not accepted by the UE 117

5.4.3.6 Abnormal cases in the UE 117

5.4.3.7 Abnormal cases on the network side 118

5.4.4 Identification procedure 118

5.4.4.1 General 118

5.4.4.2 Identification initiation by the network 118

5.4.4.3 Identification response by the UE 119

5.4.4.4 Identification completion by the network 119

5.4.4.5 Abnormal cases in the UE 119

5.4.4.6 Abnormal cases on the network side 119

5.4.5 EMM information procedure 121

5.4.5.1 General 121

5.4.5.2 EMM information procedure initiation by the network 121

5.4.5.3 EMM information procedure in the UE 121

5.4.5.4 Abnormal cases on the network side 121

5.5 EMM specific procedures 121

5.5.1 Attach procedure 121

5.5.1.1 General 121

5.5.1.2 Attach procedure for EPS services 123

5.5.1.2.1 General 123

5.5.1.2.2 Attach procedure initiation 123

5.5.1.2.3 EMM common procedure initiation 127

5.5.1.2.4 Attach accepted by the network 128

5.5.1.2.4A Attach successful for EPS services and not accepted for SMS services
133

5.5.1.2.5 Attach not accepted by the network 134

5.5.1.2.5A Attach for emergency bearer services not accepted by the network 140

5.5.1.2.5B Attach for initiating a PDN connection for emergency bearer services
not accepted by the network 142

5.5.1.2.5B1 Attach by a UE transferring an emergency PDU session using a
standalone PDN CONNECTIVITY REQUEST message 143

5.5.1.2.5C Attach for access to RLOS not accepted by the network 143

5.5.1.2.6 Abnormal cases in the UE 144

5.5.1.2.6A Abnormal cases in the UE, SMS services not accepted 148

5.5.1.2.7 Abnormal cases on the network side 148

5.5.1.3 Combined attach procedure for EPS services and non-EPS services (S1 mode
only) 150

5.5.1.3.1 General 150

5.5.1.3.2 Combined attach procedure initiation 150

5.5.1.3.3 EMM common procedure initiation 150

5.5.1.3.4 Combined attach accepted by the network 150

5.5.1.3.4.1 General 150

5.5.1.3.4.2 Combined attach successful 151

5.5.1.3.4.3 Combined attach successful for EPS services only 152

5.5.1.3.5 Combined attach not accepted by the network 153

5.5.1.3.6 Abnormal cases in the UE 159

5.5.1.3.7 Abnormal cases on the network side 160

5.5.2 Detach procedure 160

5.5.2.1 General 160

5.5.2.2 UE initiated detach procedure 161

5.5.2.2.1 UE initiated detach procedure initiation 161

5.5.2.2.2 UE initiated detach procedure completion for EPS services only 162

5.5.2.2.3 UE initiated combined detach procedure completion 162

5.5.2.2.4 Abnormal cases in the UE 163

5.5.2.2.5 Abnormal cases on the network side 165

5.5.2.3 Network initiated detach procedure 165

5.5.2.3.1 Network initiated detach procedure initiation 165

5.5.2.3.2 Network initiated detach procedure completion by the UE 166

5.5.2.3.3 Network initiated detach procedure completion by the network 170

5.5.2.3.4 Abnormal cases in the UE 170

5.5.2.3.5 Abnormal cases on the network side 171

5.5.3 Tracking area updating procedure (S1 mode only) 172

5.5.3.1 General 172

5.5.3.2 Normal and periodic tracking area updating procedure 174

5.5.3.2.1 General 174

5.5.3.2.2 Normal and periodic tracking area updating procedure initiation 174

5.5.3.2.3 EMM common procedure initiation 181

5.5.3.2.4 Normal and periodic tracking area updating procedure accepted by the
network 182

5.5.3.2.4A Tracking area updating successful for EPS services and not accepted
for SMS services 191

5.5.3.2.5 Normal and periodic tracking area updating procedure not accepted by
the network 192

5.5.3.2.5A Tracking area updating procedure for initiating a PDN connection for
emergency bearer services not accepted by the network 199

5.5.3.2.5B Tracking area updating for access to RLOS not accepted by the network
200

5.5.3.2.6 Abnormal cases in the UE 200

5.5.3.2.6A Abnormal cases in the UE, SMS services not accepted 206

5.5.3.2.7 Abnormal cases on the network side 207

5.5.3.3 Combined tracking area updating procedure 208

5.5.3.3.1 General 208

5.5.3.3.2 Combined tracking area updating procedure initiation 208

5.5.3.3.3 EMM common procedure initiation 211

5.5.3.3.4 Combined tracking area updating procedure accepted by the network 211

5.5.3.3.4.1 General 211

5.5.3.3.4.2 Combined tracking area updating successful 212

5.5.3.3.4.3 Combined tracking area updating successful for EPS services only 213

5.5.3.3.5 Combined tracking area updating procedure not accepted by the network
215

5.5.3.3.6 Abnormal cases in the UE 223

5.5.3.3.7 Abnormal cases on the network side 224

5.5.4 eCall inactivity procedure 224

5.5.5 Tracking area update request message (for N1 mode only) 224

5.5.6 Attach request message (for N1 mode only) 225

5.6 EMM connection management procedures (S1 mode only) 225

5.6.1 Service request procedure 225

5.6.1.1 General 225

5.6.1.2 Service request procedure initiation 229

5.6.1.2.1 UE is not using EPS services with control plane CIoT EPS optimization
229

5.6.1.2.2 UE is using EPS services with control plane CIoT EPS optimization 229

5.6.1.3 EMM common procedure initiation 230

5.6.1.4 Service request procedure accepted by the network 230

5.6.1.4.1 UE is not using EPS services with control plane CIoT EPS optimization
230

5.6.1.4.2 UE is using EPS services with control plane CIoT EPS optimization 232

5.6.1.5 Service request procedure not accepted by the network 236

5.6.1.5A Service request procedure for initiating a PDN connection for emergency
bearer services not accepted by the network 245

5.6.1.5B Service request procedure for UE attached for access to RLOS not
accepted by the network 246

5.6.1.6 Abnormal cases in the UE 246

5.6.1.7 Abnormal cases on the network side 254

5.6.2 Paging procedure 255

5.6.2.1 General 255

5.6.2.2 Paging for EPS services 255

5.6.2.2.1 Paging for EPS services through E-UTRAN using S-TMSI 255

5.6.2.2.1.1 General 255

5.6.2.2.1.2 Abnormal cases on the network side 257

5.6.2.2.1.3 Abnormal cases in the UE 257

5.6.2.2.2 Paging for EPS services through E-UTRAN using IMSI 257

5.6.2.3 Paging for CS fallback to A/Gb or Iu mode 258

5.6.2.3.1 General 258

5.6.2.3.2 Abnormal cases in the UE 259

5.6.2.3.3 Abnormal cases on the network side 259

5.6.2.4 Paging for SMS 260

5.6.3 Transport of NAS messages procedure 260

5.6.3.1 General 260

5.6.3.2 UE initiated transport of NAS messages 261

5.6.3.3 Network initiated transport of NAS messages 261

5.6.3.4 Abnormal cases in the UE 261

5.6.3.5 Abnormal cases on the network side 261

5.6.4 Generic transport of NAS messages procedure 262

5.6.4.1 General 262

5.6.4.2 UE initiated generic transport of NAS messages 262

5.6.4.3 Network initiated transport of NAS messages 262

5.6.4.4 Abnormal cases in the UE 262

5.6.4.5 Abnormal cases on the network side 263

5.7 Reception of an EMM STATUS message by an EMM entity 263

6 Elementary procedures for EPS session management 263

6.1 Overview 263

6.1.1 General 263

6.1.2 Types of ESM procedures 264

6.1.3 ESM sublayer states 265

6.1.3.1 General 265

6.1.3.2 ESM sublayer states in the UE 265

6.1.3.2.1 BEARER CONTEXT INACTIVE 265

6.1.3.2.2 BEARER CONTEXT ACTIVE 266

6.1.3.2.3 PROCEDURE TRANSACTION INACTIVE 266

6.1.3.2.4 PROCEDURE TRANSACTION PENDING 266

6.1.3.3 ESM sublayer states in the MME 266

6.1.3.3.1 BEARER CONTEXT INACTIVE 266

6.1.3.3.2 BEARER CONTEXT ACTIVE PENDING 266

6.1.3.3.3 BEARER CONTEXT ACTIVE 266

6.1.3.3.4 BEARER CONTEXT INACTIVE PENDING 267

6.1.3.3.5 BEARER CONTEXT MODIFY PENDING 267

6.1.3.3.6 PROCEDURE TRANSACTION INACTIVE 267

6.1.3.3.7 PROCEDURE TRANSACTION PENDING 267

6.1.4 Coordination between ESM and SM 268

6.1.4A Coordination between ESM and 5GSM 269

6.1.5 Coordination between ESM and EMM for supporting ISR 269

6.2 IP address allocation 269

6.2.1 General 269

6.2.2 IP address allocation via NAS signalling 269

6.2A IP header compression 271

6.3 General on elementary ESM procedures 271

6.3.1 Services provided by lower layers 271

6.3.2 Principles of address handling for ESM procedures 271

6.3.3 Abnormal cases in the UE 274

6.3.4 Abnormal cases in the network 275

6.3.5 Handling of APN based congestion control 275

6.3.5A Handling of group specific session management congestion control 276

6.3.6 Handling of network rejection not due to APN based congestion control 276

6.3.7 Handling of WLAN offload control 276

6.3.8 Handling of serving PLMN rate control 277

6.3.9 Handling of APN rate control 277

6.3.10 Handling of 3GPP PS data off 278

6.3.11 Handling of Reliable Data Service 279

6.3.12 Handling of Ethernet PDN type 279

6.4 Network initiated ESM procedures 279

6.4.1 Default EPS bearer context activation procedure 279

6.4.1.1 General 279

6.4.1.2 Default EPS bearer context activation initiated by the network 279

6.4.1.3 Default EPS bearer context activation accepted by the UE 280

6.4.1.4 Default EPS bearer context activation not accepted by the UE 281

6.4.1.5 Abnormal cases in the UE 282

6.4.1.6 Abnormal cases on the network side 282

6.4.2 Dedicated EPS bearer context activation procedure 282

6.4.2.1 General 282

6.4.2.2 Dedicated EPS bearer context activation initiated by the network 283

6.4.2.3 Dedicated EPS bearer context activation accepted by the UE 283

6.4.2.4 Dedicated EPS bearer context activation not accepted by the UE 285

6.4.2.5 Abnormal cases in the UE 286

6.4.2.6 Abnormal cases on the network side 286

6.4.3 EPS bearer context modification procedure 287

6.4.3.1 General 287

6.4.3.2 EPS bearer context modification initiated by the network 287

6.4.3.3 EPS bearer context modification accepted by the UE 288

6.4.3.4 EPS bearer context modification not accepted by the UE 289

6.4.3.5 Abnormal cases in the UE 291

6.4.3.6 Abnormal cases on the network side 291

6.4.4 EPS bearer context deactivation procedure 292

6.4.4.1 General 292

6.4.4.2 EPS bearer context deactivation initiated by the network 292

6.4.4.3 EPS bearer context deactivation accepted by the UE 293

6.4.4.4 Abnormal cases in the UE 295

6.4.4.5 Abnormal cases on the network side 295

6.4.4.6 Local EPS bearer context deactivation without NAS signalling 296

6.5 UE requested ESM procedures 297

6.5.0 General 297

6.5.1 UE requested PDN connectivity procedure 298

6.5.1.1 General 298

6.5.1.2 UE requested PDN connectivity procedure initiation 299

6.5.1.3 UE requested PDN connectivity procedure accepted by the network 301

6.5.1.4 UE requested PDN connectivity procedure not accepted by the network 302

6.5.1.4.1 General 302

6.5.1.4.2 Handling of network rejection due to ESM cause #26 304

6.5.1.4.3 Handling of network rejection due to ESM cause other than ESM cause
#26 307

6.5.1.4A Handling the maximum number of active EPS bearer contexts 313

6.5.1.4B Void 313

6.5.1.4C Handling the maximum number of active user plane radio bearers in NB-S1
mode 313

6.5.1.5 Abnormal cases in the UE 313

6.5.1.6 Abnormal cases on the network side 314

6.5.1.7 Handling PDN connectivity request for UE configured for dual priority
315

6.5.2 UE requested PDN disconnect procedure 315

6.5.2.1 General 315

6.5.2.2 UE requested PDN disconnection procedure initiation 316

6.5.2.3 UE requested PDN disconnection procedure accepted by the network 316

6.5.2.4 UE requested PDN disconnection procedure not accepted by the network 316

6.5.2.5 Abnormal cases in the UE 317

6.5.2.6 Abnormal cases on the network side 317

6.5.3 UE requested bearer resource allocation procedure 318

6.5.3.1 General 318

6.5.3.2 UE requested bearer resource allocation procedure initiation 318

6.5.3.3 UE requested bearer resource allocation procedure accepted by the
network 319

6.5.3.4 UE requested bearer resource allocation procedure not accepted by the
network 319

6.5.3.4.1 General 319

6.5.3.4.2 Handling of network rejection due to ESM cause #26 321

6.5.3.4.3 Handling of network rejection due to ESM cause other than ESM cause
#26 322

6.5.3.4A Handling the maximum number of active EPS bearer contexts 325

6.5.3.5 Abnormal cases in the UE 325

6.5.3.6 Abnormal cases on the network side 325

6.5.4 UE requested bearer resource modification procedure 326

6.5.4.1 General 326

6.5.4.2 UE requested bearer resource modification procedure initiation 326

6.5.4.3 UE requested bearer resource modification procedure accepted by the
network 328

6.5.4.4 UE requested bearer resource modification procedure not accepted by the
network 329

6.5.4.4.1 General 329

6.5.4.4.2 Handling of network rejection due to ESM cause #26 331

6.5.4.4.3 Handling of network rejection due to ESM cause other than ESM cause
#26 333

6.5.4.5 Abnormal cases in the UE 335

6.5.4.6 Abnormal cases on the network side 336

6.5.5 Handling session management request for UE configured for dual priority
336

6.6 Miscellaneous procedures 337

6.6.1 Exchange of protocol configuration options 337

6.6.1.1 General 337

6.6.1.2 ESM information request procedure 338

6.6.1.2.1 General 338

6.6.1.2.2 ESM information request initiated by the network 338

6.6.1.2.3 ESM information request completion by the UE 338

6.6.1.2.4 ESM information request completion by the network 338

6.6.1.2.5 Abnormal cases in the UE 338

6.6.1.2.6 Abnormal cases on the network side 338

6.6.1.3 Exchange of protocol configuration options in other messages 339

6.6.2 Notification procedure 339

6.6.2.1 General 339

6.6.2.2 Notification procedure initiation by the network 339

6.6.2.3 Notification procedure in the UE 339

6.6.2.4 Abnormal cases on the network side 340

6.6.3 Remote UE Report procedure 340

6.6.3.1 General 340

6.6.3.2 Remote UE Report initiated by the UE 340

6.6.3.3 Remote UE Report completion by the network 340

6.6.3.4 Remote UE Report completion by the UE 341

6.6.3.5 Abnormal cases in the UE 341

6.6.3.6 Abnormal cases on the network side 341

6.6.4 Transport of user data via the control plane procedure 341

6.6.4.1 General 341

6.6.4.2 UE initiated transport of user data via the control plane 341

6.6.4.3 Network initiated transport of user data via the control plane 342

6.6.4.4 Abnormal cases in the UE 342

6.6.4.5 Abnormal cases on the network side 343

6.7 Reception of an ESM STATUS message by an ESM entity 343

7 Handling of unknown, unforeseen, and erroneous protocol data 344

7.1 General 344

7.2 Message too short 345

7.3 Unknown or unforeseen procedure transaction identity or EPS bearer identity
345

7.3.1 Procedure transaction identity 345

7.3.2 EPS bearer identity 346

7.4 Unknown or unforeseen message type 348

7.5 Non-semantical mandatory information element errors 348

7.5.1 Common procedures 348

7.5.2 EPS mobility management 349

7.5.3 EPS session management 349

7.6 Unknown and unforeseen IEs in the non-imperative message part 349

7.6.1 IEIs unknown in the message 349

7.6.2 Out of sequence IEs 349

7.6.3 Repeated IEs 350

7.7 Non-imperative message part errors 350

7.7.1 Syntactically incorrect optional IEs 350

7.7.2 Conditional IE errors 350

7.8 Messages with semantically incorrect contents 350

8 Message functional definitions and contents 351

8.1 Overview 351

8.2 EPS mobility management messages 352

8.2.1 Attach accept 352

8.2.1.1 Message definition 352

8.2.1.2 GUTI 354

8.2.1.3 Location area identification 354

8.2.1.4 MS identity 354

8.2.1.5 EMM cause 354

8.2.1.6 T3402 value 354

8.2.1.7 T3423 value 354

8.2.1.8 Equivalent PLMNs 354

8.2.1.9 Emergency number list 354

8.2.1.9A Extended emergency number list 354

8.2.1.10 EPS network feature support 354

8.2.1.11 Additional update result 355

8.2.1.12 T3412 extended value 355

8.2.1.13 T3324 value 355

8.2.1.14 Extended DRX parameters 355

8.2.1.15 DCN-ID 355

8.2.1.16 SMS services status 355

8.2.1.17 Non-3GPP NW provided policies 355

8.2.1.18 T3448 value 355

8.2.1.19 Network policy 355

8.2.1.20 T3447 value 356

8.2.1.21 Ciphering key data 356

8.2.1.22 UE radio capability ID 356

8.2.1.23 UE radio capability ID deletion indication 356

8.2.1.24 Negotiated WUS assistance information 356

8.2.1.25 Negotiated DRX parameter in NB-S1 mode 356

8.2.2 Attach complete 356

8.2.3 Attach reject 357

8.2.3.1 Message definition 357

8.2.3.2 ESM message container 357

8.2.3.3 T3346 value 357

8.2.3.4 T3402 value 357

8.2.3.5 Extended EMM cause 357

8.2.4 Attach request 357

8.2.4.1 Message definition 357

8.2.4.2 Old P-TMSI signature 360

8.2.4.3 Additional GUTI 360

8.2.4.4 Last visited registered TAI 360

8.2.4.5 DRX parameter 360

8.2.4.6 MS network capability 360

8.2.4.7 Old location area identification 360

8.2.4.8 TMSI status 360

8.2.4.9 Mobile station classmark 2 360

8.2.4.10 Mobile station classmark 3 360

8.2.4.11 Supported Codecs 361

8.2.4.12 Additional update type 361

8.2.4.13 Voice domain preference and UE’s usage setting 361

8.2.4.14 Device properties 361

8.2.4.15 Old GUTI type 361

8.2.4.16 MS network feature support 361

8.2.4.17 TMSI based NRI container 361

8.2.4.18 T3324 value 361

8.2.4.19 T3412 extended value 361

8.2.4.20 Extended DRX parameters 361

8.2.4.21 UE additional security capability 361

8.2.4.22 UE status 361

8.2.4.23 Additional information requested 362

8.2.4.24 N1 UE network capability 362

8.2.4.25 UE radio capability ID availability IE 362

8.2.4.26 Requested WUS assistance information 362

8.2.4.27 DRX parameter in NB-S1 mode 362

8.2.5 Authentication failure 362

8.2.5.1 Message definition 362

8.2.5.2 Authentication failure parameter 362

8.2.6 Authentication reject 363

8.2.7 Authentication request 363

8.2.8 Authentication response 363

8.2.9 CS service notification 364

8.2.9.1 Message definition 364

8.2.9.2 CLI 364

8.2.9.3 SS Code 364

8.2.9.4 LCS indicator 365

8.2.9.5 LCS client identity 365

8.2.10 Detach accept 365

8.2.10.1 Detach accept (UE originating detach) 365

8.2.10.2 Detach accept (UE terminated detach) 365

8.2.11 Detach request 365

8.2.11.1 Detach request (UE originating detach) 365

8.2.11.2 Detach request (UE terminated detach) 366

8.2.11.2.1 Message definition 366

8.2.11.2.2 EMM cause 366

8.2.12 Downlink NAS Transport 366

8.2.13 EMM information 367

8.2.13.1 Message definition 367

8.2.13.2 Full name for network 367

8.2.13.3 Short name for network 368

8.2.13.4 Local time zone 368

8.2.13.5 Universal time and local time zone 368

8.2.13.6 Network daylight saving time 368

8.2.14 EMM status 368

8.2.15 Extended service request 369

8.2.15.1 Message definition 369

8.2.15.2 CSFB response 369

8.2.15.3 EPS bearer context status 369

8.2.15.4 Device properties 369

8.2.16 GUTI reallocation command 370

8.2.16.1 Message definition 370

8.2.16.2 TAI list 370

8.2.16.3 DCN-ID 370

8.2.16.4 UE radio capability ID 370

8.2.16.5 UE radio capability ID deletion indication 370

8.2.17 GUTI reallocation complete 371

8.2.18 Identity request 371

8.2.19 Identity response 371

8.2.20 Security mode command 372

8.2.20.1 Message definition 372

8.2.20.2 IMEISV request 372

8.2.20.3 Replayed nonceUE 373

8.2.20.4 NonceMME 373

8.2.20.5 HashMME 373

8.2.20.6 Replayed UE additional security capability 373

8.2.20.7 UE radio capability ID request 373

8.2.21 Security mode complete 373

8.2.21.1 Message definition 373

8.2.21.2 IMEISV 373

8.2.21.3 Replayed NAS message container 374

8.2.21.4 UE radio capability ID 374

8.2.22 Security mode reject 374

8.2.23 Security protected NAS message 374

8.2.24 Service reject 375

8.2.24.1 Message definition 375

8.2.24.2 T3442 value 375

8.2.24.3 T3346 value 375

8.2.24.4 T3448 value 375

8.2.25 Service request 375

8.2.26 Tracking area update accept 376

8.2.26.1 Message definition 376

8.2.26.2 T3412 value 378

8.2.26.3 GUTI 378

8.2.26.4 TAI list 378

8.2.26.5 EPS bearer context status 378

8.2.26.6 Location area identification 378

8.2.26.7 MS identity 378

8.2.26.8 EMM cause 378

8.2.26.9 T3402 value 378

8.2.26.10 T3423 value 378

8.2.26.11 Equivalent PLMNs 379

8.2.26.12 Emergency number list 379

8.2.26.12A Extended emergency number list 379

8.2.26.13 EPS network feature support 379

8.2.26.14 Additional update result 379

8.2.26.15 T3412 extended value 379

8.2.26.16 T3324 value 379

8.2.26.17 Extended DRX parameters 379

8.2.26.18 DCN-ID 379

8.2.26.19 SMS services status 380

8.2.26.20 Non-3GPP NW provided policies 380

8.2.26.21 T3448 value 380

8.2.26.22 Network policy 380

8.2.26.23 T3447 value 380

8.2.26.24 Ciphering key data 380

8.2.26.25 UE radio capability ID 380

8.2.26.26 UE radio capability ID deletion indication 380

8.2.26.27 Negotiated WUS assistance information 380

8.2.26.28 Negotiated DRX parameter in NB-S1 mode 381

8.2.27 Tracking area update complete 381

8.2.28 Tracking area update reject 381

8.2.28.1 Message definition 381

8.2.28.2 T3346 value 381

8.2.28.3 Extended EMM cause 382

8.2.29 Tracking area update request 382

8.2.29.1 Message definition 382

8.2.29.2 Non-current native NAS key set identifier 384

8.2.29.3 GPRS ciphering key sequence number 384

8.2.29.4 Old P-TMSI signature 384

8.2.29.5 Additional GUTI 384

8.2.29.6 NonceUE 384

8.2.29.7 UE network capability 384

8.2.29.8 Last visited registered TAI 384

8.2.29.9 DRX parameter 385

8.2.29.10 UE radio capability information update needed 385

8.2.29.11 EPS bearer context status 385

8.2.29.12 MS network capability 385

8.2.29.13 Old location area identification 385

8.2.29.14 TMSI status 385

8.2.29.15 Mobile station classmark 2 385

8.2.29.16 Mobile station classmark 3 385

8.2.29.17 Supported Codecs 385

8.2.29.18 Additional update type 385

8.2.29.19 Voice domain preference and UE’s usage setting 385

8.2.29.20 Old GUTI type 385

8.2.29.21 Device properties 386

8.2.29.22 MS network feature support 386

8.2.29.23 TMSI based NRI container 386

8.2.29.24 T3324 value 386

8.2.29.25 T3412 extended value 386

8.2.29.26 Extended DRX parameters 386

8.2.29.27 UE additional security capability 386

8.2.29.28 UE status 386

8.2.29.29 Additional information requested 386

8.2.29.30 N1 UE network capability 386

8.2.29.31 UE radio capability ID availability IE 386

8.2.29.32 DRX parameter in NB-S1 mode 386

8.2.29.33 Requested WUS assistance information 387

8.2.30 Uplink NAS Transport 387

8.2.31 Downlink generic NAS transport 387

8.2.31.1 Message definition 387

8.2.31.2 Additional information 388

8.2.32 Uplink generic NAS transport 388

8.2.32.1 Message definition 388

8.2.32.2 Additional information 388

8.2.33 CONTROL PLANE SERVICE REQUEST 388

8.2.33.1 Message definition 388

8.2.33.2 ESM message container 389

8.2.33.3 NAS message container 389

8.2.33.4 EPS bearer context status 389

8.2.33.5 Device properties 389

8.2.34 Service Accept 389

8.2.34.1 Message definition 389

8.2.34.2 EPS bearer context status 390

8.2.34.3 T3448 value 390

8.3 EPS session management messages 390

8.3.1 Activate dedicated EPS bearer context accept 390

8.3.1.1 Message definition 390

8.3.1.2 Protocol configuration options 391

8.3.1.3 NBIFOM container 391

8.3.1.4 Extended protocol configuration options 391

8.3.2 Activate dedicated EPS bearer context reject 391

8.3.2.1 Message definition 391

8.3.2.2 Protocol configuration options 391

8.3.2.3 NBIFOM container 392

8.3.2.4 Extended protocol configuration options 392

8.3.3 Activate dedicated EPS bearer context request 392

8.3.3.1 Message definition 392

8.3.3.2 Transaction identifier 393

8.3.3.3 Negotiated QoS 393

8.3.3.4 Negotiated LLC SAPI 393

8.3.3.5 Radio priority 393

8.3.3.6 Packet flow identifier 394

8.3.3.7 Protocol configuration options 394

8.3.3.8 WLAN offload indication 394

8.3.3.9 NBIFOM container 394

8.3.3.10 Extended protocol configuration options 394

8.3.3.11 Extended EPS QoS 394

8.3.4 Activate default EPS bearer context accept 394

8.3.4.1 Message definition 394

8.3.4.2 Protocol configuration options 395

8.3.4.3 Extended protocol configuration options 395

8.3.5 Activate default EPS bearer context reject 395

8.3.5.1 Message definition 395

8.3.5.2 Protocol configuration options 396

8.3.5.3 Extended protocol configuration options 396

8.3.6 Activate default EPS bearer context request 396

8.3.6.1 Message definition 396

8.3.6.2 Transaction identifier 397

8.3.6.3 Negotiated QoS 397

8.3.6.4 Negotiated LLC SAPI 398

8.3.6.5 Radio priority 398

8.3.6.6 Packet flow identifier 398

8.3.6.7 APN-AMBR 398

8.3.6.8 ESM cause 398

8.3.6.9 Protocol configuration options 398

8.3.6.10 Connectivity type 398

8.3.6.11 WLAN offload indication 398

8.3.6.12 NBIFOM container 398

8.3.6.13 Header compression configuration 398

8.3.6.14 Control plane only indication 399

8.3.6.15 Extended protocol configuration options 399

8.3.6.16 Serving PLMN rate control 399

8.3.6.17 Extended APN aggregate maximum bit rate 399

8.3.7 Bearer resource allocation reject 399

8.3.7.1 Message definition 399

8.3.7.2 Protocol configuration options 400

8.3.7.3 Back-off timer value 400

8.3.7.4 Re-attempt indicator 400

8.3.7.5 NBIFOM container 400

8.3.7.6 Extended protocol configuration options 400

8.3.8 Bearer resource allocation request 401

8.3.8.1 Message definition 401

8.3.8.2 Protocol configuration options 401

8.3.8.3 Device properties 401

8.3.8.4 NBIFOM container 401

8.3.8.5 Extended protocol configuration options 402

8.3.8.6 Extended EPS QoS 402

8.3.9 Bearer resource modification reject 402

8.3.9.1 Message definition 402

8.3.9.2 Protocol configuration options 402

8.3.9.3 Back-off timer value 403

8.3.9.4 Re-attempt indicator 403

8.3.9.5 NBIFOM container 403

8.3.9.6 Extended protocol configuration options 403

8.3.10 Bearer resource modification request 403

8.3.10.1 Message definition 403

8.3.10.2 Required traffic flow QoS 404

8.3.10.3 ESM cause 404

8.3.10.4 Protocol configuration options 404

8.3.10.5 Device properties 404

8.3.10.6 NBIFOM container 404

8.3.10.7 Header compression configuration 405

8.3.10.8 Extended protocol configuration options 405

8.3.10.9 Extended EPS QoS 405

8.3.11 Deactivate EPS bearer context accept 405

8.3.11.1 Message definition 405

8.3.11.2 Protocol configuration options 406

8.3.11.3 Void 406

8.3.11.4 Extended protocol configuration options 406

8.3.12 Deactivate EPS bearer context request 406

8.3.12.1 Message definition 406

8.3.12.2 Protocol configuration options 406

8.3.12.3 T3396 value 407

8.3.12.4 WLAN offload indication 407

8.3.12.5 NBIFOM container 407

8.3.12.6 Extended protocol configuration options 407

8.3.12A ESM dummy message 407

8.3.13 ESM information request 407

8.3.14 ESM information response 408

8.3.14.1 Message definition 408

8.3.14.2 Access point name 408

8.3.14.3 Protocol configuration options 408

8.3.14.4 Extended protocol configuration options 409

8.3.15 ESM status 409

8.3.16 Modify EPS bearer context accept 409

8.3.16.1 Message definition 409

8.3.16.2 Protocol configuration options 410

8.3.16.3 NBIFOM container 410

8.3.16.4 Extended protocol configuration options 410

8.3.17 Modify EPS bearer context reject 410

8.3.17.1 Message definition 410

8.3.17.2 Protocol configuration options 411

8.3.17.3 NBIFOM container 411

8.3.17.4 Extended protocol configuration options 411

8.3.18 Modify EPS bearer context request 411

8.3.18.1 Message definition 411

8.3.18.2 New EPS QoS 412

8.3.18.3 TFT 412

8.3.18.4 New QoS 412

8.3.18.5 Negotiated LLC SAPI 413

8.3.18.6 Radio priority 413

8.3.18.7 Packet flow identifier 413

8.3.18.8 APN-AMBR 413

8.3.18.9 Protocol configuration options 413

8.3.18.10 WLAN offload indication 413

8.3.18.11 NBIFOM container 413

8.3.18.12 Header compression configuration 413

8.3.18.13 Extended protocol configuration options 413

8.3.18.14 Extended APN-AMBR 413

8.3.18.15 Extended EPS QoS 414

8.3.18A Notification 414

8.3.19 PDN connectivity reject 414

8.3.19.1 Message definition 414

8.3.19.2 Protocol configuration options 415

8.3.19.3 Back-off timer value 415

8.3.19.4 Re-attempt indicator 415

8.3.19.5 Extended protocol configuration options 415

8.3.20 PDN connectivity request 416

8.3.20.1 Message definition 416

8.3.20.2 ESM information transfer flag 416

8.3.20.3 Access point name 416

8.3.20.4 Protocol configuration options 417

8.3.20.5 Device properties 417

8.3.20.6 NBIFOM container 417

8.3.20.7 Header compression configuration 417

8.3.20.8 Extended protocol configuration options 417

8.3.21 PDN disconnect reject 417

8.3.21.1 Message definition 417

8.3.21.2 Protocol configuration options 418

8.3.21.3 Extended protocol configuration options 418

8.3.22 PDN disconnect request 418

8.3.22.1 Message definition 418

8.3.22.2 Protocol configuration options 419

8.3.22.3 Extended protocol configuration options 419

8.3.23 Remote UE report 419

8.3.23.1 Message definition 419

8.3.23.2 Remote UE Context Connected 420

8.3.23.3 Remote UE Context Disconnected 420

8.3.23.4 ProSe Key Management Function Address 420

8.3.24 Remote UE report response 420

8.3.24.1 Message definition 420

8.3.25 ESM DATA TRANSPORT 421

8.3.25.1 Message definition 421

8.3.25.2 Release assistance indication 421

9 General message format and information elements coding 422

9.1 Overview 422

9.2 Protocol discriminator 423

9.3 Security header type and EPS bearer identity 423

9.3.1 Security header type 423

9.3.2 EPS bearer identity 424

9.4 Procedure transaction identity 424

9.5 Message authentication code 425

9.6 Sequence number 425

9.7 NAS message 425

9.8 Message type 425

9.9 Other information elements 427

9.9.1 General 427

9.9.2 Common information elements 428

9.9.2.0 Additional information 428

9.9.2.0A Device properties 428

9.9.2.1 EPS bearer context status 428

9.9.2.2 Location area identification 429

9.9.2.3 Mobile identity 429

9.9.2.4 Mobile station classmark 2 429

9.9.2.5 Mobile station classmark 3 429

9.9.2.6 NAS security parameters from E-UTRA 429

9.9.2.7 NAS security parameters to E-UTRA 430

9.9.2.8 PLMN list 431

9.9.2.9 Spare half octet 431

9.9.2.10 Supported codec list 431

9.9.3 EPS Mobility Management (EMM) information elements 431

9.9.3.0A Additional update result 431

9.9.3.0B Additional update type 432

9.9.3.1 Authentication failure parameter 433

9.9.3.2 Authentication parameter AUTN 433

9.9.3.3 Authentication parameter RAND 433

9.9.3.4 Authentication response parameter 433

9.9.3.4A Ciphering key sequence number 434

9.9.3.4B SMS services status 434

9.9.3.5 CSFB response 435

9.9.3.6 Daylight saving time 435

9.9.3.7 Detach type 435

9.9.3.8 DRX parameter 436

9.9.3.9 EMM cause 436

9.9.3.10 EPS attach result 437

9.9.3.11 EPS attach type 438

9.9.3.12 EPS mobile identity 438

9.9.3.12A EPS network feature support 440

9.9.3.13 EPS update result 444

9.9.3.14 EPS update type 444

9.9.3.15 ESM message container 445

9.9.3.16 GPRS timer 445

9.9.3.16A GPRS timer 2 446

9.9.3.16B GPRS timer 3 446

9.9.3.17 Identity type 2 446

9.9.3.18 IMEISV request 446

9.9.3.19 KSI and sequence number 446

9.9.3.20 MS network capability 446

9.9.3.20A MS network feature support 446

9.9.3.21 NAS key set identifier 447

9.9.3.22 NAS message container 447

9.9.3.23 NAS security algorithms 448

9.9.3.24 Network name 448

9.9.3.24A Network resource identifier container 449

9.9.3.25 Nonce 449

9.9.3.25A Paging identity 449

9.9.3.26 P-TMSI signature 450

9.9.3.26A Extended EMM cause 450

9.9.3.27 Service type 450

9.9.3.28 Short MAC 451

9.9.3.29 Time zone 451

9.9.3.30 Time zone and time 452

9.9.3.31 TMSI status 452

9.9.3.32 Tracking area identity 452

9.9.3.33 Tracking area identity list 453

9.9.3.34 UE network capability 457

9.9.3.35 UE radio capability information update needed 462

9.9.3.36 UE security capability 463

9.9.3.37 Emergency Number List 466

9.9.3.37A Extended emergency number list 466

9.9.3.38 CLI 468

9.9.3.39 SS Code 469

9.9.3.40 LCS indicator 469

9.9.3.41 LCS client identity 469

9.9.3.42 Generic message container type 470

9.9.3.43 Generic message container 470

9.9.3.44 Voice domain preference and UE’s usage setting 471

9.9.3.45 GUTI type 471

9.9.3.46 Extended DRX parameters 471

9.9.3.47 Control plane service type 472

9.9.3.48 DCN-ID 472

9.9.3.49 Non-3GPP NW provided policies 472

9.9.3.50 HashMME 472

9.9.3.51 Replayed NAS message container 473

9.9.3.52 Network policy 474

9.9.3.53 UE additional security capability 474

9.9.3.54 UE status 477

9.9.3.55 Additional information requested 477

9.9.3.56 Ciphering key data 477

9.9.3.57 N1 UE network capability 481

9.9.3.58 UE radio capability ID availability 482

9.9.3.59 UE radio capability ID request 483

9.9.3.60 UE radio capability ID 483

9.9.3.61 UE radio capability ID deletion indication 483

9.9.3.62 WUS assistance information 483

9.9.3.63 NB-S1 DRX parameter 485

9.9.4 EPS Session Management (ESM) information elements 486

9.9.4.1 Access point name 486

9.9.4.2 APN aggregate maximum bit rate 486

9.9.4.2A Connectivity type 488

9.9.4.3 EPS quality of service 488

9.9.4.4 ESM cause 494

9.9.4.5 ESM information transfer flag 497

9.9.4.6 Linked EPS bearer identity 497

9.9.4.7 LLC service access point identifier 498

9.9.4.7A Notification indicator 498

9.9.4.8 Packet flow identifier 499

9.9.4.9 PDN address 499

9.9.4.10 PDN type 500

9.9.4.11 Protocol configuration options 501

9.9.4.12 Quality of service 501

9.9.4.13 Radio priority 501

9.9.4.13A Re-attempt indicator 501

9.9.4.14 Request type 502

9.9.4.15 Traffic flow aggregate description 502

9.9.4.16 Traffic flow template 502

9.9.4.17 Transaction identifier 502

9.9.4.18 WLAN offload acceptability 502

9.9.4.19 NBIFOM container 503

9.9.4.20 Remote UE context list 503

9.9.4.21 PKMF address 506

9.9.4.22 Header compression configuration 506

9.9.4.23 Control plane only indication 509

9.9.4.24 User data container 509

9.9.4.25 Release assistance indication 510

9.9.4.26 Extended protocol configuration options 510

9.9.4.27 Header compression configuration status 510

9.9.4.28 Serving PLMN rate control 511

9.9.4.29 Extended APN aggregate maximum bit rate 511

9.9.4.30 Extended quality of service 513

10 List of system parameters 516

10.1 General 516

10.2 Timers of EPS mobility management 517

10.3 Timers of EPS session management 526

Annex A (informative): Cause values for EPS mobility management 528

A.1 Causes related to UE identification 528

A.2 Cause related to subscription options 528

A.3 Causes related to PLMN specific network failures and
congestion/authentication failures 529

A.4 Causes related to nature of request 530

A.5 Causes related to invalid messages 531

Annex B (informative): Cause values for EPS session management 532

B.1 Causes related to nature of request 532

B.2 Protocol errors (e.g., unknown message) class 535

Annex C (normative): Storage of EMM information 536

Annex D (normative): Establishment cause (S1 mode only) 537

D.1 Mapping of NAS procedure to RRC establishment cause (S1 mode only) 537

Annex E (informative): Guidelines for enhancements to MS network capability IE
and UE network capability IE 547

Annex F (normative): Application specific Congestion control for Data
Communication (ACDC) 548

Annex G (informative): Change history 549

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.

1 Scope

The present document specifies the procedures used by the protocols for mobility
management and session management between User Equipment (UE) and Mobility
Management Entity (MME) in the Evolved Packet System (EPS). These protocols
belong to the non-access stratum (NAS).

The EPS Mobility Management (EMM) protocol defined in the present document
provides procedures for the control of mobility when the User Equipment (UE) is
using the Evolved UMTS Terrestrial Radio Access Network (E-UTRAN). The EMM
protocol also provides control of security for the NAS protocols.

The EPS Session Management (ESM) protocol defined in the present document
provides procedures for the handling of EPS bearer contexts. Together with the
bearer control provided by the access stratum, this protocol is used for the
control of user plane bearers.

For both NAS protocols the present document specifies procedures for the support
of inter-system mobility between EUTRAN and other 3GPP or non-3GPP access
networks:

- For inter-system mobility between E-UTRAN and GERAN, UTRAN or NG-RAN, this
includes rules for a mapping between parameters and procedures used by the NAS
protocols defined in the present document and the NAS protocols specified in
3GPP TS 24.008 [13] for GERAN and UTRAN, and 3GPP TS 24.501 [54] for NG-RAN.

- For inter-system mobility between E-UTRAN and generic non-3GPP access
networks, this includes specific NAS procedures to maintain IP connectivity to
the PDN Gateway and to provide parameters needed by the UE when using mobility
management based on Dual-Stack Mobile IPv6 (see 3GPP TS 24.303 [14]) or MIPv4
(see 3GPP TS 24.304 [15]).

The present document is applicable to the UE and to the Mobility Management
Entity (MME) in the EPS.

The present document is also applicable to the relay node in the EPS (see 3GPP
TS 23.401 [10]).

The present document also specifies NAS signalling enhancement for the support
of efficient transport of IP, non-IP, Ethernet and SMS data of CIoT capable
devices.

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

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

[1A] 3GPP TS 22.011: “Service accessibility”.

[1B] Void.

[1C] 3GPP TS 22.278: “Service requirements for the Evolved Packet System (EPS)”.

[2] 3GPP TS 23.003: “Numbering, addressing and identification”.

[3] 3GPP TS 23.038: “Alphabets and language-specific information”.

[4] 3GPP TS 23.060: “General Packet Radio Service (GPRS); Service Description;
Stage 2”.

[5] 3GPP TS 23.107: “Quality of Service (QoS) concept and architecture”.

[6] 3GPP TS 23.122: “Non-Access-Stratum functions related to Mobile Station (MS)
in idle mode”.

[7] 3GPP TS 23.203: “Policy and charging control architecture”.

[8] 3GPP TS 23.216: “Single Radio Voice Call Continuity (SRVCC); Stage 2”.

[8A] 3GPP TS 23.221: “Architectural requirements”.

[8B] 3GPP TS 23.251: “Network Sharing; Architecture and Functional Description”.

[9] 3GPP TS 23.272: “Circuit Switched Fallback in Evolved Packet System; Stage
2”.

[10] 3GPP TS 23.401: “GPRS enhancements for E-UTRAN access”.

[11] 3GPP TS 23.402: “GPRS architecture enhancements for non-3GPP accesses”.

[11A] 3GPP TS 23.682: “Architecture enhancements to facilitate communications
with packet data networks and applications”.

[12] 3GPP TS 24.007: “Mobile radio interface signalling layer 3; General
aspects”.

[13] 3GPP TS 24.008: “Mobile Radio Interface Layer 3 specification; Core Network
Protocols; Stage 3”.

[13A] 3GPP TS 24.011: “Point-to-Point Short Message Service (SMS) support on
mobile radio interface”.

[13B] 3GPP TS 24.167: “3GPP IMS Management Object (MO); Stage 3”.

[13C] 3GPP TS 24.171: “NAS Signalling for Control Plane LCS in Evolved Packet
System (EPS)”.

[13D] 3GPP TS 24.229: “IP multimedia call control protocol based on Session
Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3”.

[13E] 3GPP TS 24.173: “IMS Multimedia telephony communication service and
supplementary services; Stage 3”.

[14] 3GPP TS 24.303: “Mobility Management based on DSMIPv6; User Equipment (UE)
to network protocols; Stage 3”.

[15] 3GPP TS 24.304: “Mobility management based on Mobile IPv4; User Equipment
(UE) - foreign agent interface; Stage 3”.

[15A] 3GPP TS 24.368: “Non-Access Stratum (NAS) configuration Management Object
(MO)”.

[15B] 3GPP TS 25.304: “User Equipment (UE) procedures in idle mode and
procedures for cell reselection in connected mode”.

[15C] 3GPP TS 29.002: “Mobile Application Part (MAP) specification”.

[15D] 3GPP TS 24.341: “Support of SMS over IP networks; Stage 3”.

[16] 3GPP TS 29.061: “Interworking between the Public Land Mobile Network (PLMN)
supporting packet based services and Packet Data Networks (PDN)”.

[16A] 3GPP TS 29.118: “Mobility Management Entity (MME) – Visitor Location
Register (VLR) SGs interface specification”.

[16B] 3GPP TS 29.212: “Policy and Charging Control (PCC); Reference points”.

[16C] 3GPP TS 29.272: “Evolved Packet System (EPS); Mobility Management Entity
(MME) and Serving GPRS Support Node (SGSN) related interfaces based on Diameter
protocol”.

[16D] 3GPP TS 29.274: “Evolved Packet System (EPS); Evolved General Packet Radio
Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C); Stage 3”.

[17] 3GPP TS 31.102: “Characteristics of the Universal Subscriber Identity
Module (USIM) application”.

[18] 3GPP TS 33.102: “3G security; Security architecture”.

[19] 3GPP TS 33.401: “3GPP System Architecture Evolution; Security
architecture”.

[20] 3GPP TS 36.300: “Evolved Universal Terrestrial Radio Access (E-UTRA) and
Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall
description”.

[21] 3GPP TS 36.304: “Evolved Universal Terrestrial Radio Access (E-UTRA); User
Equipment (UE) procedures in idle mode”.

[22] 3GPP TS 36.331: “Evolved Universal Terrestrial Radio Access (E-UTRA); Radio
Resource Control (RRC) protocol specification”.

[22A] 3GPP TS 36.355: “Evolved Universal Terrestrial Radio Access (E-UTRA); LTE
Positioning Protocol (LPP)”.

[23] 3GPP TS 36.413: “Evolved Universal Terrestrial Access Network (E-UTRAN); S1
Application Protocol (S1AP)”.

[23A] 3GPP TS 45.008: “Radio Access Network; Radio subsystem link control”.

[24] Void.

[24A] IETF RFC 3633: “IPv6 Prefix Options for Dynamic Host Configuration
Protocol (DHCP) version 6”.

[25] Void.

[26] Void.

[27] Void.

[28] Void.

[29] ISO/IEC 10646: “Information technology – Universal Multiple-Octet Coded
Character Set (UCS)”.

[30] ITU-T Recommendation E.212: “The international identification plan for
mobile terminals and mobile users”.

[31] 3GPP TS 23.303: “Proximity-based services (ProSe); Stage 2”.

[32] 3GPP TS 24.334: “Proximity-services (ProSe) User Equipment (UE) to
Proximity-services (ProSe) Function Protocol aspects; Stage 3”.

[33] 3GPP TS 23.380: “IMS restoration procedures”.

[34] 3GPP TS 23.161: “Network-Based IP Flow Mobility (NBIFOM); Stage 2”.

[35] 3GPP TS 24.105: “Application specific Congestion control for Data
Communication (ACDC) Management Object (MO)”.

[36] 3GPP TS 24.161: “Network-Based IP Flow Mobility (NBIFOM); Stage 3”.

[37] IETF RFC 5795: “The RObust Header Compression (ROHC) Framework”.

[38] 3GPP TS 36.323: “Evolved Universal Terrestrial Radio Access (E-UTRA);
Packet Data Convergence Protocol (PDCP) specification”.

[39] IETF RFC 6846: “RObust Header Compression (ROHC): A Profile for TCP/IP
(ROHC-TCP)”.

[40] IETF RFC 3095: “RObust Header Compression (ROHC): Framework and four
profiles: RTP, UDP, ESP and uncompressed”.

[41] IETF RFC 3843: “RObust Header Compression (ROHC): A Compression Profile for
IP”.

[42] IETF RFC 4815: “RObust Header Compression (ROHC): Corrections and
Clarifications to RFC 3095”.

[43] IETF RFC 5225: “RObust Header Compression (ROHC) Version 2: Profiles for
RTP, UDP, IP, ESP and UDP Lite”.

[44] 3GPP TS 36.306: “Evolved Universal Terrestrial Radio Access (E-UTRA); User
Equipment (UE) radio access capabilities”.

[45] 3GPP TS 23.167: “IP Multimedia Subsystem (IMS) emergency sessions”.

[46] 3GPP TS 22.101: “Service aspects; Service principles”.

[47] 3GPP TS 23.285: “Architecture enhancements for V2X services”.

[48] 3GPP TS 24.302: “Access to the 3GPP Evolved Packet Core (EPC) via non-3GPP
access networks; Stage 3”.

[49] 3GPP TS 36.321: “Evolved Universal Terrestrial Radio Access (E-UTRA);
Medium Access Control (MAC) protocol specification”.

[50] 3GPP TS 24.623: “Extensive Markup Language (XML) Configuration Access
Protocol (XCAP) over the Ut interface for Manipulating Supplementary Services”.

[51] 3GPP TS 24.250: “Protocol for Reliable Data Service; Stage 3”.

[52] 3GPP TR 38.913: “Study on Scenarios and Requirements for Next Generation
Access Technologies”.

[53] 3GPP TS 38.323: “NR; Packet Data Convergence Protocol (PDCP)
specification”.

[54] 3GPP TS 24.501: “Non-Access-Stratum (NAS) protocol for 5G System (5GS);
Stage 3”.

[55] IETF RFC 5031: “A Uniform Resource Name (URN) for Emergency and Other
Well-Known Services”.

[56] 3GPP TS 33.501: “Security architecture and procedures for 5G System”.

[57] 3GPP TS 23.040: “Technical realization of the Short Message Service (SMS)”.

[58] 3GPP TS 23.501: “System Architecture for the 5G System; Stage 2”.

[59] 3GPP TS 23.502: “Procedures for the 5G System”.

3 Definitions and abbreviations

3.1 Definitions

For the purposes of the present document, the terms and definitions given in
3GPP 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 3GPP
TR 21.905 [1].

The term “mobile station” (MS) in the present document is synonymous with the
term “user equipment” (UE) as defined in 3GPP TR 21.905 [1].

1x CS fallback capable UE: A UE that uses a CS infrastructure for a voice
call and other CS-domain services by falling back to cdma2000® 1x access network
if the UE is served by EUTRAN when a CS service is requested.

5G-EA: 5GS encryption algorithms. The term 5G-EA, 5G-EA0, 128-5G-EA1-3 and
5G-EA4-7 used in the present document corresponds to the term NEA, NEA0, NEA1-3
and NEA4-7 defined in 3GPP TS 33.501 [56].

5G-IA: 5GS integrity algorithms. The term 5G-IA, 5G-IA0, 128-5G-IA1-3 and
5G-IA4-7 used in the present document corresponds to the term NIA, NIA0, NIA1-3
and NIA4-7 defined in 3GPP TS 33.501 [56].

Aggregate maximum bit rate: The maximum bit rate that limits the aggregate
bit rate of a set of non-GBR bearers of a UE. Definition derived from 3GPP TS
23.401 [10].

APN based congestion control: Congestion control in session management where
the network can reject session management requests from UEs or deactivate PDN
connections when the associated APN is congested.

Attached for emergency bearer services: A UE is attached for emergency
bearer services if it has only a PDN connection for emergency bearer services
established.

Attached for access to RLOS: A UE is attached for access to RLOS if the UE
requested access to RLOS during the attach procedure and has a PDN connection
for RLOS established after completion of attach procedure.

Chosen PLMN: The same as selected PLMN as specified in 3GPP TS 23.122 [6].

Control plane CIoT EPS optimization: signalling optimizations to enable
efficient transport of user data (IP, non-IP, Ethernet or SMS) over control
plane via the MME including optional header compression of IP data.

User plane CIoT EPS optimization: signalling optimizations to enable
efficient transport of user data (IP, non-IP or Ethernet) over the user plane.

UE supporting CIoT EPS optimizations: A UE that supports control plane CIoT
EPS optimization or user plane CIoT EPS optimization and one or more other CIoT
EPS optimizations when the UE is in S1 mode.

Attached for EPS services with CP-CIoT EPS optimization: A UE supporting
CIoT EPS optimizations is attached for EPS services, and control plane CIoT EPS
optimization along with one or more other CIoT EPS optimizations have been
accepted by the network.

Attached for EPS services with User plane CIoT EPS optimization: A UE
supporting CIoT EPS optimizations is attached for EPS services, and user plane
CIoT EPS optimization along with one or more other CIoT EPS optimizations have
been accepted by the network.

Attached for EPS services with CIoT EPS optimization: A UE is attached for
EPS services with CP-CIoT EPS optimization or attached for EPS services with
user plane CIoT EPS optimization.

CS fallback cancellation request: A request received from the MM sublayer to
cancel a mobile originating CS fallback.

CS fallback capable UE: A UE that uses a CS infrastructure for a voice call
and other CS-domain services by falling back to A/Gb or Iu mode if the UE is
served by EUTRAN when a CS service is requested.

CSG cell: A cell in which only members of the CSG can get normal service.
Depending on local regulation, the CSG cell can provide emergency bearer
services also to subscribers who are not member of the CSG. Definition derived
from 3GPP TS 23.401 [10].

CSG ID: A CSG ID is a unique identifier within the scope of one PLMN defined
in 3GPP TS 23.003 [2] which identifies a Closed Subscriber Group (CSG) in the
PLMN associated with a cell or group of cells to which access is restricted to
members of the CSG.

CSG selection: A UE supporting CSG selection selects CSG cell either
automatically based on the list of allowed CSG identities or manually based on
user selection of CSG on indication of list of available CSGs. Definition
derived from 3GPP TS 23.122 [6].

Dedicated bearer: An EPS bearer that is associated with uplink packet
filters in the UE and downlink packet filters in the PDN GW where the filters
only match certain packets. Definition derived from 3GPP TS 23.401 [10].

Default bearer: An EPS bearer that gets established with every new PDN
connection. Its context remains established throughout the lifetime of that PDN
connection. A default EPS bearer is a non-GBR bearer. Definition derived from
3GPP TS 23.401 [10].

Emergency EPS bearer context: A default EPS bearer context which was
activated with request type “emergency” or “handover of emergency bearer
services”, or any dedicated EPS bearer context associated to this default EPS
bearer context.

EMM context: An EMM context is established in the UE and the MME when an
attach procedure is successfully completed.

EMM-CONNECTED mode: A UE is in EMM-CONNECTED mode when a NAS signalling
connection between UE and network is established. The term EMM-CONNECTED mode
used in the present document corresponds to the term ECM-CONNECTED state used in
3GPP TS 23.401 [10].

EMM-IDLE mode: A UE is in EMM-IDLE mode when no NAS signalling connection
between UE and network exists or when RRC connection suspend has been indicated
by lower layers. The term EMM-IDLE mode used in the present document corresponds
to the term ECM-IDLE state used in 3GPP TS 23.401 [10].

EPS security context: In the present specification, EPS security context is
used as a synonym for EPS NAS security context specified in 3GPP TS 33.401 [19].

EPS services: Services provided by PS domain. Within the context of this
specification, EPS services is used as a synonym for GPRS services in 3GPP TS
24.008 [13].

Evolved packet core network: The successor to the 3GPP Release 7
packet-switched core network, developed by 3GPP within the framework of the 3GPP
System Architecture Evolution (SAE).

Evolved packet system: The evolved packet system (EPS) or evolved 3GPP
packet-switched domain consists of the evolved packet core network and the
evolved universal terrestrial radio access network. Definition derived from 3GPP
TS 23.401 [10].

GBR bearer: An EPS bearer that uses dedicated network resources related to a
guaranteed bit rate (GBR) value, which are permanently allocated at EPS bearer
establishment/modification. Definition derived from 3GPP TS 23.401 [10].

General NAS level mobility management congestion control: The type of
congestion control that is applied at a general overload or congestion situation
in the network, e.g. lack of processing resources.

Group specific session management congestion control: Type of congestion
control at session management level that is applied to reject session management
requests from UEs belonging to a particular group when one or more group
congestion criteria as specified in 3GPP TS 23.401 [10] are met.

Highest ranked ACDC category: The ACDC category with the lowest value as
defined in 3GPP TS 24.105 [35].

Initial NAS message: A NAS message is considered as an initial NAS message,
if this NAS message can trigger the establishment of a NAS signalling
connection. For instance, the ATTACH REQUEST message is an initial NAS message.

IPv4v6 capability: Capability of the IP stack associated with a UE to
support a dual stack configuration with both an IPv4 address and an IPv6 address
allocated.

Kilobit: 1000 bits.

Last Visited Registered TAI: A TAI which is contained in the TAI list that
the UE registered to the network and which identifies the tracking area last
visited by the UE.

Linked Bearer Identity: This identity indicates to which default bearer the
additional bearer resource is linked.

LIPA PDN connection: A PDN connection, for which the default EPS bearer
context or default PDP context was activated with an APN authorized to use LIPA.
The network authorizes an APN for using LIPA based on the subscription profile
(see 3GPP TS 29.272 [16C]) and subsequently the network considers this PDN
connection a LIPA PDN connection.

Lower layer failure: A failure reported by the AS to the NAS that cannot be
corrected on AS level. When the AS indicates a lower layer failure to NAS, the
NAS signalling connection is not available.

Mapped EPS security context: A mapped security context to be used in EPS.
Definition derived from 3GPP TS 33.401 [19].

Mapped GUTI: A GUTI which is mapped from a P-TMSI and an RAI allocated
previously by an SGSN. Mapping rules are defined in 3GPP TS 23.003 [2].
Definition derived from 3GPP TS 23.401 [10].

Megabit: 1,000,000 bits.

Message header: A standard L3 message header as defined in 3GPP TS 24.007
[12].

MME area: An area containing tracking areas served by an MME.

MO MMTEL voice call is started: the MO-MMTEL-voice-started indication was
received from upper layers (see 3GPP TS 24.173 [13E]) and after reception of the
MO-MMTEL-voice-started indication, the MO-MMTEL-voice-ended indication has not
been received.

MO MMTEL video call is started: the MO-MMTEL-video-started indication was
received from upper layers (see 3GPP TS 24.173 [13E]) and after reception of the
MO-MMTEL-video-started indication, the MO-MMTEL-video-ended indication has not
been received.

MO SMSoIP is started: the MO-SMSoIP-attempt-started indication was received
from upper layers (see 3GPP TS 24.341 [15D]) and after reception of the
MO-SMSoIP-attempt-started indication, the MO-SMSoIP-attempt-ended indication has
not been received.

NAS level mobility management congestion control: Congestion control
mechanism in the network in mobility management. “NAS level mobility management
congestion control” consists of “subscribed APN based congestion control” and
“general NAS level mobility management congestion control”.

NAS signalling connection: A peer to peer S1 mode connection between UE and
MME. A NAS signalling connection consists of the concatenation of an RRC
connection via the “LTE-Uu” interface and an S1AP connection via the S1
interface. Additionally, for the purpose of optimized handover or idle mode
mobility from cdma2000® HRPD access to EUTRAN (see 3GPP TS 23.402 [11]), the NAS
signalling connection can consist of a concatenation of an S101AP connection and
a signalling tunnel over a cdma2000® HRPD access network.

NOTE 1: cdma2000® is a registered trademark of the Telecommunications Industry
Association (TIA-USA).

NAS signalling connection recovery: A mechanism initiated by the NAS to
restore the NAS signalling connection on indication of “RRC connection failure”
by the lower layers.

Native GUTI: A GUTI previously allocated by an MME. Definition derived from
3GPP TS 23.401 [10].

Non-access stratum protocols: The protocols between UE and MSC or SGSN that
are not terminated in the UTRAN, and the protocols between UE and MME that are
not terminated in the E-UTRAN. Definition derived from 3GPP TR 21.905 [1].

Non-emergency EPS bearer context: Any EPS bearer context which is not an
emergency EPS bearer context.

Non-EPS services: Services provided by CS domain. Within the context of this
specification, non-EPS services is used as a synonym for non-GPRS services in
3GPP TS 24.008 [13]. A UE which camps on E-UTRAN can attach to both EPS services
and non-EPS services.

Non-GBR bearer: An EPS bearer that uses network resources that are not
related to a guaranteed bit rate (GBR) value. Definition derived from 3GPP TS
23.401 [10].

PDN address: An IP address assigned to the UE by the Packet Data Network
Gateway (PDN GW).

PDN connection for emergency bearer services: A PDN connection for which the
default EPS bearer context or default PDP context was activated with request
type “emergency” or “handover of emergency bearer services”.

PDN connection for RLOS: A PDN connection for which the default EPS bearer
context was activated with request type “RLOS”.

Plain NAS message: A NAS message with a header including neither a message
authentication code nor a sequence number.

Persistent EPS bearer context: either a non-emergency EPS bearer context
representing a GBR bearer with QoS equivalent to QoS of teleservice 11 and where
there is a radio bearer associated with that context, or an emergency EPS bearer
context where there is a radio bearer associated with that context.

NOTE 2: An example of a persistent EPS bearer context is a non-emergency EPS
bearer context with QCI = 1 where there is a radio bearer associated with that
context.

Procedure Transaction Identity: An identity which is dynamically allocated
by the UE for the UE requested ESM procedures. The procedure transaction
identity is released when the procedure is completed.

RAT-related TMSI: When the UE is camping on an E-UTRAN cell, the RAT-related
TMSI is the GUTI; when it is camping on a GERAN or UTRAN cell, the RAT-related
TMSI is the P-TMSI.

Registered PLMN: The PLMN on which the UE is registered. The identity of the
registered PLMN is provided to the UE within the GUTI.

Relay node: A network element in the E-UTRAN, wirelessly connected to an
eNode B and providing relaying function to UEs served by the E-UTRAN. Definition
derived from 3GPP TS 23.401 [10].

Removal of eCall only mode restriction: All the limitations as described in
3GPP TS 22.101 [46] for the eCall only mode do not apply any more.

RLOS EPS bearer context: A default RLOS EPS bearer context which was
activated with request type “RLOS”, or any dedicated EPS bearer context
associated to this default EPS bearer context.

The label (S1 mode only) indicates that this subclause or paragraph applies
only to a system which operates in S1 mode, i.e. with a functional division that
is in accordance with the use of an S1 interface between the radio access
network and the core network. The S1 mode includes WB-S1 mode and NB-S1 mode. In
a multi-access system this case is determined by the current serving radio
access network.

In NB-S1 mode: Indicates this paragraph applies only to a system which
operates in NB-S1 mode. For a multi-access system this case applies if the
current serving radio access network provides access to network services via
E-UTRA by NB-IoT (see 3GPP TS 36.300 [20], 3GPP TS 36.331 [22], 3GPP TS 36.306
[44]).

In WB-S1 mode: Indicates this paragraph applies only to a system which
operates in WB-S1 mode. For a multi-access system this case applies if the
system operates in S1 mode, but not in NB-S1 mode.

In WB-S1/CE mode: Indicates this paragraph applies only when a UE, which is
a CE mode B capable UE (see 3GPP TS 36.306 [44]), is operating in CE mode A or B
in WB-S1 mode.

SCEF PDN Connection: A PDN connection established between the UE and the
Service Capability Exposure Function (SCEF) for transmitting the UE’s non-IP
data related to a specific application.

SGi PDN Connection: A PDN connection established between the UE and the
Packet Gateway (P-GW) for transmitting the UE’s IP, non-IP or Ethernet data
related to a specific application.

S101 mode: Applies to a system that operates with a functional division that
is in accordance with the use of an S101 interface. For the definition of the
S101 reference point, see 3GPP TS 23.402 [11].

SIPTO at the local network PDN connection: A PDN connection, for which the
default EPS bearer context or default PDP context was activated with an APN
authorized to use SIPTO at the local network and it was activated such that the
traffic of the PDN connection will be using an L-GW. The network authorizes an
APN for using SIPTO at the local network based on the subscription profile (see
3GPP TS 29.272 [16C]) and subsequently the network considers this PDN connection
a SIPTO at the local network PDN connection. SIPTO at the local network PDN
connection can be of IP, non-IP or Ethernet PDN type.

SIPTO at the local network PDN connection with a collocated L-GW: A SIPTO at
the local network PDN connection which is established to a L-GW function
collocated with the (H)(e)NodeB. The core-network entity (i.e. the MME or the
SGSN) can be aware of whether the SIPTO at the local network PDN connection with
a collocated L-GW is used when the PDN connection is established.

SIPTO at the local network PDN connection with a stand-alone GW: A SIPTO at
the local network PDN connection which is established to a stand-alone GW (with
collocated L-GW and S-GW). The core-network entity (i.e. the MME or the SGSN)
can be aware of whether the SIPTO at the local network PDN connection with a
stand-alone GW is used when the PDN connection is established.

"SMS only": A subset of services which includes only Short Message Service.
A UE camping on E-UTRAN can attach to both EPS services and “SMS only”.

SMS over NAS: refers to SMS in MME or SMS over SGs.

SMS over S102: refers to SMS which uses 1xCS procedures in EPS as defined in
3GPP TS 23.272 [9].

Subscribed APN based congestion control: Congestion control in mobility
management where the network can reject attach requests from UEs with a certain
APN in the subscription.

TAI list: A list of TAIs that identify the tracking areas that the UE can
enter without performing a tracking area updating procedure. The TAIs in a TAI
list assigned by an MME to a UE pertain to the same MME area.

Traffic flow aggregate: A temporary aggregate of packet filters that are
included in a UE requested bearer resource allocation procedure or a UE
requested bearer resource modification procedure and that is inserted into a
traffic flow template (TFT) for an EPS bearer context by the network once the UE
requested bearer resource allocation procedure or UE requested bearer resource
modification procedure is completed.

UE configured for dual priority: A UE which provides dual priority support
is configured for NAS signalling low priority and also configured to override
the NAS signalling low priority indicator (see 3GPP TS 24.368 [15A], 3GPP TS
31.102 [17]).

UE configured to use AC11 – 15 in selected PLMN: A UE configured with at
least one access class in the range 11-15 on the USIM, and the access class is
applicable in the selected PLMN according to 3GPP TS 22.011 [1A].

UE’s availability for voice calls in the IMS: The indication of this
availability or non-availability is provided by the upper layers of the UE as
specified in 3GPP TS 24.229 [13D] in the annex relevant to the IP-Connectivity
Access Network in use or determined in the NAS layer, as specified in subclause
4.3.1. If availability is indicated, the UE uses the IM CN Subsystem and can
terminate or originate requests for SIP sessions including an audio component
with codecs suited for voice.

UE’s usage setting: This is a UE setting that indicates whether the UE has
preference for voice services over data services or vice-versa. If a UE has
preference for voice services, then the UE’s usage setting is “voice centric”.
If a UE has preference for data services, then the UE’s usage setting is “data
centric”. A UE whose setting is “data centric” may still require access to voice
services. A UE whose setting is “voice centric” may still require access to data
services. This definition is derived from 3GPP TS 23.221 [8A] and it applies to
voice capable UEs. If the UE is capable of both S1 mode and N1 mode, there is a
single UE’s usage setting which applies to both 5GS and EPS (see 3GPP TS 24.501
[54]).

UE using EPS services with control plane CIoT EPS optimization: A UE that is
attached for EPS services with the control plane CIOT EPS optimization accepted
by the network.

For the purposes of the present document, the following terms and definitions
given in 3GPP TS 23.221 [8A] apply:

Restricted local operator services

For the purposes of the present document, the following terms and definitions
given in 3GPP TS 23.401 [10] apply:

APN rate control status

Cellular IoT (CIoT)

DCN-ID

eCall only mode

NarrowBand-IoT

Dedicated core network

PDN connection

Service Gap Control

UE paging probability information

For the purposes of the present document, the following terms and definitions
given in 3GPP TS 23.272 [9] apply:

CS fallback

SMS in MME

SMS over SGs

For the purposes of the present document, the following terms and definitions
given in 3GPP TS 23.682 [11A] apply:

SCEF

For the purposes of the present document, the following terms and definitions
given in 3GPP TS 24.008 [13] apply:

A/Gb mode

Access domain selection

Default PDP context

Extended idle-mode DRX cycle

Iu mode

Power saving mode

PS signalling connection

RR connection

TFT

For the purposes of the present document, the following terms and definitions
given in 3GPP TS 33.102 [18] apply:

UMTS security context

For the purposes of the present document, the following terms and definitions
given in 3GPP TS 33.401 [19] apply:

Current EPS security context

Full native EPS security context

KASME

K’ASME

Mapped security context

Native EPS security context

Non-current EPS security context

Partial native EPS security context

Data via MME

For the purposes of the present document, the following terms and definitions
given in 3GPP TS 23.122 [6] apply:

Country

EHPLMN

HPLMN

Shared Network

Suitable Cell

VPLMN

Limited Service State

For the purposes of the present document, the following terms and definitions
given in 3GPP TS 23.216 [8] apply:

SRVCC

vSRVCC

For the purposes of the present document, the following terms and definitions
given in 3GPP TS 22.011 [1A] apply:

Extended Access Barring

Application specific Congestion control for Data Communication (ACDC)

For the purposes of the present document, the following terms and definitions
given in 3GPP TS 23.003 [10] apply:

Local Home Network Identifier

For the purposes of the present document, the following terms and definitions
given in 3GPP TS 23.303 [31] apply:

ProSe direct communication

ProSe direct discovery

ProSe UE-to-Network Relay

For the purposes of the present document, the following terms and definitions
given in 3GPP TS 24.161 [36] apply:

Multi-access PDN connection

NBIFOM

For the purposes of the present document, the following terms and definitions
given in 3GPP TS 23.167 [45] apply:

eCall over IMS

For the purposes of the present document, the following terms and definitions
given in 3GPP TS 24.501 [54] apply:

5GMM-CONNECTED mode

5GMM-DEREGISTERED

5GMM-DEREGISTERED-INITIATED

5GMM-IDLE mode

5GMM-NULL

5GMM-REGISTERED

5GMM-REGISTERED-INITIATED

5GMM-SERVICE-REQUEST-INITIATED

Applicable UE radio capability ID for the current UE radio configuration in
the selected network

Control plane CIoT 5GS optimization

N1 mode

NB-N1 mode

UE operating in single-registration mode in a network supporting N26 interface
User plane CIoT 5GS optimization

3.2 Abbreviations

For the purposes of the present document, the abbreviations given in 3GPP 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 3GPP TR 21.905 [1].

5G-GUTI 5G-Globally Unique Temporary Identifier

5GMM 5GS Mobility Management

5GS 5G System

ACDC Application specific Congestion control for Data Communication

AKA Authentication and Key Agreement

AMBR Aggregate Maximum Bit Rate

APN Access Point Name

APN-AMBR APN Aggregate Maximum Bit Rate

ARP Allocation Retention Priority

BCM Bearer Control Mode

CIoT Cellular IoT

CP-CIoT Control Plane CIoT

CP-EDT Control Plane EDTCSG Closed Subscriber Group

E-UTRA Evolved Universal Terrestrial Radio Access

E-UTRAN Evolved Universal Terrestrial Radio Access Network

EAB Extended Access Barring

ECM EPS Connection Management

eDRX Extended idle-mode DRX cycle

EDT Early Data Transmission

EENLV Extended Emergency Number List Validity

eKSI Key Set Identifier for E-UTRAN

EMM EPS Mobility Management

eNode B Evolved Node B

EPC Evolved Packet Core Network

EPS Evolved Packet System

ESM EPS Session Management

GBR Guaranteed Bit Rate

GUMMEI Globally Unique MME Identifier

GUTI Globally Unique Temporary Identifier

HeNB Home eNode B

HRPD High Rate Packet Data

IoT Internet of Things

IP-CAN IP-Connectivity Access Network

ISR Idle mode Signalling Reduction

kbps Kilobits per second

KSI Key Set Identifier

L-GW Local PDN Gateway

LHN-ID Local Home Network Identifier

LIPA Local IP Access

M-TMSI M-Temporary Mobile Subscriber Identity

Mbps Megabits per second

MBR Maximum Bit Rate

MME Mobility Management Entity

MMEC MME Code

MT-EDT Mobile Terminated-Early Data Transmission

NB-IoT Narrowband IoT

NR New Radio

NSSAI Network Slice Selection Assistance Information

PD Protocol Discriminator

PDN GW Packet Data Network Gateway

ProSe Proximity-based Services

PSM Power Saving Mode

PTI Procedure Transaction Identity

QCI QoS Class Identifier

QoS Quality of Service

RACS Radio Capability Signalling Optimisation

RLOS Restricted Local Operator Services

ROHC RObust Header Compression

RRC Radio Resource Control

S-NSSAI Single NSSAI

S-TMSI S-Temporary Mobile Subscriber Identity

S101-AP S101 Application Protocol

S1AP S1 Application Protocol

SAE System Architecture Evolution

SCEF Service Capability Exposure Function

SGC Service Gap Control

SIPTO Selected IP Traffic Offload

TA Tracking Area

TAC Tracking Area Code

TAI Tracking Area Identity

TFT Traffic Flow Template

TI Transaction Identifier

TIN Temporary Identity used in Next update

URN Uniform Resource Name

V2X Vehicle-to-Everything

WUS Wake-Up Signal

4 General

4.1 Overview

The non-access stratum (NAS) described in the present document forms the highest
stratum of the control plane between UE and MME at the radio interface
(reference point “LTE-Uu”; see 3GPP TS 23.401 [10]).

Main functions of the protocols that are part of the NAS are:

- the support of mobility of the user equipment (UE); and

- the support of session management procedures to establish and maintain IP
connectivity between the UE and a packet data network gateway (PDN GW).

NAS security is an additional function of the NAS providing services to the NAS
protocols, e.g. integrity protection and ciphering of NAS signalling messages.

For the support of the above functions, the following procedures are supplied
within this specification:

- elementary procedures for EPS mobility management in clause 5; and

- elementary procedures for EPS session management in clause 6.

Complete NAS transactions consist of specific sequences of elementary
procedures. Examples of such specific sequences can be found in 3GPP TS 23.401
[10].

The NAS for EPS follows the protocol architecture model for layer 3 as described
in 3GPP TS 24.007 [12]; however, due to the objective of EPS to provide the
subscriber with a “ready-to-use” IP connectivity and an “always-on” experience,
the protocol supports a linkage between mobility management and session
management procedures during the attach procedure (see subclause 4.2).

Signalling procedures for the control of NAS security are described as part of
the EPS mobility management in clause 5. In addition to that, principles for the
handing of EPS security contexts and for the activation of ciphering and
integrity protection, when a NAS signalling connection is established, are
provided in subclause 4.4.

4.2 Linkage between the protocols for EPS mobility management and EPS session management

During the EPS attach procedure, the network can activate a default EPS bearer
context (i.e. if the UE requests PDN connectivity in the attach request).
Additionally, the network can activate one or several dedicated EPS bearer
contexts in parallel for PDN connections of IP or Ethernet PDN type. To this
purpose the EPS session management messages for the default EPS bearer context
activation can be transmitted in an information element in the EPS mobility
management messages. In this case, the UE and the network execute the attach
procedure, the default EPS bearer context activation procedure, and the
dedicated EPS bearer context activation procedure in parallel. The UE and
network shall complete the combined default EPS bearer context activation
procedure and the attach procedure before the dedicated EPS bearer context
activation procedure is completed. If EMM-REGISTERED without PDN connection is
not supported by the UE or the MME, then the success of the attach procedure is
dependent on the success of the default EPS bearer context activation procedure.
If the attach procedure fails, then the ESM procedures also fail.

A UE using EPS services with control plane CIoT EPS optimization can initiate
transport of user data via the control plane. For this purpose a UE in EMM-IDLE
mode can initiate the service request procedure and transmit the ESM DATA
TRANSPORT message in an information element in the CONTROL PLANE SERVICE REQUEST
message.

Except for the attach procedure and the service request procedure, during EMM
procedures the MME shall suspend the transmission of ESM messages. During the
service request procedure the MME may suspend the transmission of ESM messages.

Except for the attach procedure and the service request procedure for UE
initiated transport of user data via the control plane, during EMM procedures
the UE shall suspend the transmission of ESM messages.

4.2A Handling of NAS signalling low priority indication

A UE configured for NAS signalling low priority (see 3GPP TS 24.368 [15A], 3GPP
TS 31.102 [17]) indicates this by including the Device properties IE in the
appropriate NAS message and setting the low priority indicator to “MS is
configured for NAS signalling low priority”, except for the following cases in
which the UE shall set the low priority indicator to “MS is not configured for
NAS signalling low priority”:

- the UE is performing an attach for emergency bearer services;

- the UE has a PDN connection for emergency bearer services established and is
performing EPS mobility management procedures, or is establishing a PDN
connection for emergency bearer services;

- the UE configured for dual priority is requested by the upper layers to
establish a PDN connection with the low priority indicator set to “MS is not
configured for NAS signalling low priority”;

- the UE configured for dual priority is performing EPS session management
procedures related to the PDN connection established with low priority indicator
set to “MS is not configured for NAS signalling low priority”;

- the UE configured for dual priority has a PDN connection established by
setting the low priority indicator to “MS is not configured for NAS signalling
low priority” and is performing EPS mobility management procedures;

- the UE is performing a service request procedure for a CS fallback emergency
call or 1xCS fallback emergency call;

- the UE is a UE configured to use AC11 – 15 in selected PLMN; or

- the UE is responding to paging.

The network may use the NAS signalling low priority indication for NAS level
mobility management congestion control and APN based congestion control.

If the NAS signalling low priority indication is provided in a PDN CONNECTIVITY
REQUEST message, the MME stores the NAS signalling low priority indication
within the default EPS bearer context activated due to the PDN connectivity
request procedure.

4.3 UE mode of operation

4.3.1 General

A UE attached for EPS services shalloperate in one of the following operation
modes:

- PS mode 1 of operation: the UE registers only to EPS services, and UE’s usage
setting is “voice centric”;

- PS mode 2 of operation: the UE registers only to EPS services, and UE’s usage
setting is “data centric”;

- CS/PS mode 1 of operation: the UE registers to both EPS and non-EPS services,
and UE’s usage setting is “voice centric”; and

- CS/PS mode 2 of operation: the UE registers to both EPS and non-EPS services,
and UE’s usage setting is “data centric”.

A UE configured to use CS fallback, shall operate in CS/PS mode 1 or CS/PS mode
2. Such UE may also be configured to use IMS, in which case the voice domain
preference for E-UTRAN as defined in 3GPP TS 24.167 [13B] shall be used for the
selection of the domain for originating voice communication services.

NOTE 1: The domain selected for originating voice communication services can be
ignored by attempting a CS emergency call.

Upon request from upper layers to establish a CS emergency call:

- if the UE needs to initiate a CS fallback emergency call but it is unable to
perform CS fallback, the UE shall attempt to select GERAN or UTRAN radio access
technology, and a UE with “IMS voice not available” should disable the E-UTRA
capability (see subclause 4.5) to allow a potential callback, and then progress
the CS emergency call establishment;

- if the UE needs to initiate a 1xCS fallback emergency call but it is unable to
perform 1xCS fallback, the UE shall attempt to select cdma2000® 1x radio access
technology to establish the call.

NOTE 2: Unable to perform CS fallback or 1xCS fallback means that either the UE
was not allowed to attempt CS fallback or 1xCS fallback, or CS fallback or 1xCS
fallback attempt failed.

A UE configured to use SMS over SGs shall operate in CS/PS mode 1 or CS/PS mode
2.

The behaviour of the UE in CS/PS mode 1 of operation, upon failure to access the
CS domain or upon reception of a “CS fallback not preferred” or “SMS only”
indication, will depend on the availability of voice over IMS. In the present
document, “IMS voice not available” refers to one of the following conditions:

a) the UE is not configured to use IMS;

b) the UE is not configured to use IMS voice, i.e. when the voice domain
preference for E-UTRAN, as defined in 3GPP TS 24.167 [13B], indicates that voice
communication services are allowed to be invoked only over the CS domain;

c) the UE is configured to use IMS voice, but the network indicates in the
ATTACH ACCEPT message or the TRACKING AREA UPDATE ACCEPT message that IMS voice
over PS sessions are not supported; or

d) the UE is configured to use IMS voice, the network indicates in the ATTACH
ACCEPT message or the TRACKING AREA UPDATE ACCEPT message that IMS voice over PS
sessions are supported, but the upper layers:

- provide no indication that the UE is available for voice call in the IMS
within a manufacturer determined period of time; or

- indicate that the UE is not available for voice calls in the IMS.

NOTE 3: If conditions a, b and c evaluate to false, the upper layers need time
to attempt IMS registration. In the event an indication from the upper layers
that the UE is available for voice calls in the IMS takes longer than the
manufacturer determined period of time (e.g. due to delay when attempting IMS
registration or due to delay obtaining an EPS bearer context for SIP
signalling), the NAS layer assumes the UE is not available for voice calls in
the IMS.

Other conditions may exist but these are implementation specific.

In the present document, “IMS voice available” refers to the conditions a, b, c
and d, and other implementation specific conditions for “IMS voice not
available” evaluate to false.

4.3.2 Change of UE mode of operation

4.3.2.1 General

The UE mode of operation can change as a result of e.g.:

- a change of UE’s usage setting for a CS voice capable UE;

- a change of voice domain preference for E-UTRAN as defined in 3GPP TS 24.167
[13B] for a CS voice capable UE;

- a change in the UE’s availability for voice calls in the IMS; or

- a change in UE configuration regarding the use of SMS as defined in 3GPP TS
24.167 [13B].

Figure 4.3.2.1.1 and figure 4.3.2.1.2 illustrate the transitions between
different UE mode of operations when UE’s usage settings, voice domain
preference for E-UTRAN or configuration regarding SMS changes.

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-715sC26I-1640135278144)(media/ae0484bcb9d916aedb887478dcec1cf4.emf)]

NOTE 1: The UE may transit from CS/PS mode 1 to PS mode 1 or from CS/PS mode 2
to PS mode 2 if “CS domain not available” is received. After the transition to
PS mode 1 or PS mode 2 due to “CS domain not available”, the UE can transit back
to CS/PS mode 1 or CS/PS mode 2, e.g. due to change of PLMN which is not in the
list of the equivalent PLMNs.

NOTE 2: Not all possible transitions are shown in this figure.

Figure 4.3.2.1.1: Change of UE mode of operation for a CS voice capable UE

NOTE: Not all possible transitions are shown in this figure.

Figure 4.3.2.1.2: Change of UE mode of operation for a UE with no CS voice
capability

4.3.2.2 Change of UE’s usage setting

Whenever the UE’s usage setting changes, the UE dependent on its mode of
operation shall execute procedures according to table 4.3.2.2.1 and table
4.3.2.2.2:

a) The UE is operating in PS mode 1 or PS mode 2

Table 4.3.2.2.1: Change of UE’s usage setting for a UE in PS mode 1 or PS mode 2

UE’s usage setting change	Procedure to execute
From data centric to voice centric and “IMS voice not available”	Disable the E-UTRA capability if voice domain selection results in a selection to a different RAT (see subclause 4.5), or combined tracking area update with IMSI attach if voice domain selection results in attempt to stay in E-UTRAN.
From voice centric to data centric and E-UTRA is disabled	Re-enable the E-UTRA capability (see subclause 4.5)

b) The UE is operating in CS/PS mode 1 or CS/PS mode 2

Table 4.3.2.2.2: Change of UE’s usage setting for a UE in CS/PS mode 1 or CS/PS
mode 2

UE’s usage setting change	Procedure to execute
From data centric to voice centric, “CS fallback is not available” and “IMS voice not available” (NOTE 1)	Disable the E-UTRA capability (see subclause 4.5)
From data centric to voice centric, “IMS voice not available” and the UE received a “CS fallback not preferred” or “SMS only” indication during the last successful combined attach or combined tracking area updating procedure	Disable the E-UTRA capability (see subclause 4.5)
From voice centric to data centric and E-UTRA is disabled	Re-enable the E-UTRA capability (see subclause 4.5)
NOTE 1: “CS fallback is not available” includes EMM causes #16, #17, and #18

4.3.2.3 Change of voice domain preference for E-UTRAN

Whenever the voice domain preference for E-UTRAN changes, the UE dependent on
its mode of operation shall execute procedures according to table 4.3.2.3.1 and
table 4.3.2.3.2:

a) The UE is operating in PS mode 1 or PS mode 2

Table 4.3.2.3.1: Change of voice domain preference for E-UTRAN for a UE in PS
mode 1 or PS mode 2

Voice domain preference for E-UTRAN change	Procedure to execute
From “IMS PS voice only” to “CS voice only” or “CS voice preferred, IMS PS Voice as secondary”	Transit from PS mode 1 to CS/PS mode 1 or from PS mode 2 to CS/PS mode 2. Combined tracking area update with IMSI attach
From “IMS PS voice preferred, CS Voice as secondary” to “CS voice only” or “CS voice preferred, IMS PS Voice as secondary”	Transit from PS mode 1 to CS/PS mode 1 or from PS mode 2 to CS/PS mode 2. Combined tracking area update with IMSI attach

b) The UE is operating in CS/PS mode 1 or CS/PS mode 2

Table 4.3.2.3.2: Change of voice domain preference for E-UTRAN for a UE in CS/PS
mode 1 or CS/PS mode 2

Voice domain preference for E-UTRAN change	Procedure to execute
From any configuration to “IMS PS voice only”, UE is configured to prefer SMS over IP networks and the UE is available for voice calls in the IMS.	May: - transit from CS/PS mode 1 to PS mode 1 or from CS/PS mode 2 to PS mode 2; and - detach for non-EPS services
From any configuration to “CS voice only”, UE is in CS/PS mode 1 of operation and “CS fallback is not available”(NOTE 1)	Disable the E-UTRA capability (see subclause 4.5)
From any configuration to “CS voice only”, UE is in CS/PS mode 1 of operation and the UE received a “CS fallback not preferred” or “SMS only” indication during the last successful combined attach or combined tracking area updating procedure.	Disable the E-UTRA capability (see subclause 4.5)
From “CS voice only” to any configuration and E-UTRA capability was disabled due to change of voice domain preference for E-UTRAN.	Re-enable the E-UTRA capability (see subclause 4.5). If an RR or RRC connection exists, the UE shall delay re-enabling the E-UTRA capability until the RR or RRC connection is released.
NOTE 1: “CS fallback is not available” includes EMM causes #16, #17, and #18

4.3.2.4 Change or determination of IMS registration status

Whenever the UE’s availability for voice calls in the IMS is determined or
changes (e.g. whenever the IMS registration status is determined or changes),
the UE dependent on its mode of operation shall execute procedures according to
table 4.3.2.4.1, 4.3.2.4.2 or 4.3.2.4.3:

a) The UE is operating in PS mode 1

Table 4.3.2.4.1: Change of IMS registration status for a UE in PS mode 1

Change of IMS registration status	Procedure to execute
UE is not available for voice calls in the IMS indication and voice domain preference for E-UTRAN is “IMS PS voice preferred, CS Voice as secondary”	Transit to CS/PS mode 1. Combined tracking area update with IMSI attach
UE is not available for voice calls in the IMS indication, SMS configuration is set to prefer to use SMS over IP networks, and voice domain preference for E-UTRAN is “IMS PS voice only”	Disable the E-UTRA capability (see subclause 4.5)
UE is not available for voice calls in the IMS indication, SMS configuration is set to prefer to use SMS over IP networks, and UE is not CS voice capable	May disable the E-UTRA capability (see subclause 4.5)

NOTE 1: If the UE in PS mode 1 transits to CS/PS mode 1 according to table
4.3.2.4.1, then the UE can return to PS mode 1 when the upper layer indicates
the status of being available for voice over PS.

b) The UE is operating in PS mode 2

Table 4.3.2.4.2: Change of IMS registration status for a UE in PS mode 2

Change of IMS registration status	Procedure to execute
UE is not available for voice calls in the IMS indication and voice domain preference for E-UTRAN is “IMS PS voice preferred, CS Voice as secondary”	Transit to CS/PS mode 2. Combined tracking area update with IMSI attach
Unsuccessful IMS registration indication from upper layers, SMS configuration is set to prefer to use SMS over IP networks, and voice domain preference for E-UTRAN is “IMS PS voice only”	Transit to CS/PS mode 2. Combined tracking area update with “SMS only”
Unsuccessful IMS registration indication from upper layers, SMS configuration is set to prefer to use SMS over IP networks, and UE is not CS voice capable	Transit to CS/PS mode 2. Combined tracking area update with “SMS only”

NOTE 2: If the UE in PS mode 2 transits to CS/PS mode 2 according to table
4.3.2.4.2, then the UE can return to PS mode 2 when the upper layer indicates
the status of being available for voice over PS.

c) The UE is operating in CS/PS mode 1

Table 4.3.2.4.3: Change of IMS registration status for a UE in CS/PS mode 1

Change of IMS registration status	Procedure to execute
UE is not available for voice calls in the IMS indication, and any of: - “CS fallback is not available” (NOTE 1); or - the UE received a “CS fallback not preferred” or “SMS only” indication during the last successful combined attach or combined tracking area updating procedure	Disable the E-UTRA capability (see subclause 4.5)
UE is not available for voice calls in the IMS indication, UE is in state EMM-REGISTERED.ATTEMPTING-TO-UPDATE-MM and timer T3402 is running	May disable the E-UTRA capability (see subclause 4.5)
NOTE 1: “CS fallback is not available” includes EMM causes #16, #17, and #18

4.3.2.5 Change of configuration regarding the use of SMS.

Whenever the UE’s configuration on use of SMS changes, the UE dependent on its
mode of operation shall execute procedures according to table 4.3.2.5.1 and
table 4.3.2.5.2:

a) The UE is operating in PS mode 1 or PS mode 2

Table 4.3.2.5.1: Change of configuration regarding the use of SMS in PS mode 1
or PS mode 2

SMS configuration change	Procedure to execute
Change to “SMS service is not preferred to be invoked over IP networks” or the UE is unable to use SMS using IMS (see 3GPP TS 24.229 [13D]).	Transit from PS mode 1 to CS/PS mode 1 or from PS mode 2 to CS/PS mode 2. Combined tracking area update with IMSI attach, (with or without “SMS only”)

b) The UE is operating in CS/PS mode 1 or CS/PS mode 2

Table 4.3.2.5.2: Change of configuration regarding the use of SMS in CS/PS mode
1 or CS/PS mode 2

SMS configuration change	Procedure to execute
Change to “SMS service is preferred to be invoked over IP networks”, the UE is able to use SMS using IMS (see 3GPP TS 24.229 [13D]), and UE has no CS voice capability	May: - transit from CS/PS mode 1 to PS mode 1 or from CS/PS mode 2 to PS mode 2; and - detach for non-EPS services
Change to “SMS service is preferred to be invoked over IP networks”, UE is able to use SMS using IMS (see 3GPP TS 24.229 [13D]), and the voice domain preference for E-UTRAN is “IMS PS voice only”	May: - transit from CS/PS mode 1 to PS mode 1 or from CS/PS mode 2 to PS mode 2; and - detach for non-EPS services

4.4 NAS security

4.4.1 General

This clause describes the principles for the handling of EPS security contexts
in the UE and in the MME and the procedures used for the security protection of
EPS NAS messages between UE and MME. Security protection involves integrity
protection and ciphering of the EMM and ESM NAS messages.

The signalling procedures for the control of NAS security are part of the EMM
protocol and are described in detail in clause 5.

NOTE: The use of ciphering in a network is an operator option. In this
subclause, for the ease of description, it is assumed that ciphering is used,
unless explicitly indicated otherwise. Operation of a network without ciphering
is achieved by configuring the MME so that it always selects the “null ciphering
algorithm”, EEA0.

4.4.2 Handling of EPS security contexts

4.4.2.1 General

The security parameters for authentication, integrity protection and ciphering
are tied together in an EPS security context and identified by a key set
identifier for E-UTRAN (eKSI). The relationship between the security parameters
is defined in 3GPP TS 33.401 [19].

Before security can be activated, the MME and the UE need to establish an EPS
security context. Usually, the EPS security context is created as the result of
an EPS authentication procedure between MME and UE. Alternatively:

- during inter-system handover from A/Gb mode to S1 mode or from Iu mode to S1
mode, the MME and the UE derive a mapped EPS security context from a UMTS
security context that has been established while the UE was in A/Gb mode or Iu
mode; or

- during CS to PS SRVCC handover from A/Gb mode to S1 mode or from Iu mode to S1
mode, the MME and the UE derive a mapped EPS security context from a CS UMTS
security context that has been established while the UE was in A/Gb mode or Iu
mode.

The EPS security context is taken into use by the UE and the MME, when the MME
initiates a security mode control procedure or during the inter-system handover
procedure from A/Gb mode to S1 mode or Iu mode to S1 mode. The EPS security
context which has been taken into use by the network most recently is called
current EPS security context. This current EPS security context can be of type
native or mapped, i.e. originating from a native EPS security context or mapped
EPS security context.

The key set identifier eKSI is assigned by the MME either during the EPS
authentication procedure or, for the mapped EPS security context, during the
inter-system handover procedure. The eKSI consists of a value and a type of
security context parameter indicating whether an EPS security context is a
native EPS security context or a mapped EPS security context. When the EPS
security context is a native EPS security context, the eKSI has the value of
KSIASME, and when the current EPS security context is of type mapped, the eKSI
has the value of KSISGSN.

The EPS security context which is indicated by an eKSI can be taken into use to
establish the secure exchange of NAS messages when a new NAS signalling
connection is established without executing a new EPS authentication procedure
(see subclause 4.4.2.3) or when the MME initiates a security mode control
procedure. For this purpose the initial NAS messages (i.e. ATTACH REQUEST,
TRACKING AREA UPDATE REQUEST, DETACH REQUEST, SERVICE REQUEST, EXTENDED SERVICE
REQUEST, and CONTROL PLANE SERVICE REQUEST) and the SECURITY MODE COMMAND
message contain an eKSI in the NAS key set identifier IE or the value part of
eKSI in the KSI and sequence number IE indicating the current EPS security
context used to integrity protect the NAS message.

In the present document, when the UE is required to delete an eKSI, the UE shall
set the eKSI to the value “no key is available” and consider also the associated
keys KASME or K’ASME, EPS NAS ciphering key and EPS NAS integrity key invalid
(i.e. the EPS security context associated with the eKSI as no longer valid).

NOTE: In some specifications the term ciphering key sequence number might be
used instead of the term Key Set Identifier (KSI).

The UE and the MME need to be able to maintain two EPS security contexts
simultaneously, i.e. a current EPS security context and a non-current EPS
security context, since:

- after an EPS re-authentication, the UE and the MME can have both a current EPS
security context and a non-current EPS security context which has not yet been
taken into use (i.e. a partial native EPS security context); and

- after an inter-system handover from A/Gb mode to S1 mode or Iu mode to S1
mode, the UE and the MME can have both a mapped EPS security context, which is
the current EPS security context, and a non-current native EPS security context
that was created during a previous access in S1 mode or S101 mode.

The number of EPS security contexts that need to be maintained simultaneously by
the UE and the MME is limited by the following requirements:

- After a successful EPS (re-)authentication, which creates a new partial native
EPS security context, the MME and the UE shall delete the non-current EPS
security context, if any.

- When a partial native EPS security context is taken into use through a
security mode control procedure, the MME and the UE shall delete the previously
current EPS security context.

- When the MME and the UE create an EPS security context using null integrity
and null ciphering algorithm during an attach procedure for emergency bearer
services, or a tracking area updating procedure for a UE that has a PDN
connection for emergency bearer services (see subclause 5.4.3.2), the MME and
the UE shall delete the previous current EPS security context.

- When a new mapped EPS security context or EPS security context created using
null integrity and null ciphering algorithm is taken into use during the
inter-system handover from A/Gb mode to S1 mode or Iu mode to S1 mode, the MME
and the UE shall not delete the previously current native EPS security context,
if any. Instead, the previously current native EPS security context shall become
a non-current native EPS security context, and the MME and the UE shall delete
any partial native EPS security context.

If no previously current native EPS security context exists, the MME and the UE
shall not delete the partial native EPS security context, if any.

- When the MME and the UE derive a new mapped EPS security context during
inter-system handover from A/Gb mode to S1 mode or Iu mode to S1 mode, the MME
and the UE shall delete any existing current mapped EPS security context.

- When a non-current full native EPS security context is taken into use by a
security mode control procedure, then the MME and the UE shall delete the
previously current mapped EPS security context.

- When the UE or the MME moves from EMM-REGISTERED to EMM-DEREGISTERED state, if
the current EPS security context is a mapped EPS security context and a
non-current full native EPS security context exists, then the non-current EPS
security context shall become the current EPS security context. Furthermore, the
UE and the MME shall delete any mapped EPS security context or partial native
EPS security context.

The UE shall mark the EPS security context on the USIM or in the non-volatile
memory as invalid when the UE initiates an attach procedure as described in
subclause 5.5.1 or when the UE leaves state EMM-DEREGISTERED for any other state
except EMM-NULL.

The UE shall store the current native EPS security context as specified in annex
C and mark it as valid only when the UE enters state EMM-DEREGISTERED from any
other state except EMM-NULL or when the UE aborts the attach procedure without
having left EMM-DEREGISTERED.

4.4.2.2 Establishment of a mapped EPS security context during intersystem handover

In order for the UE to derive a mapped EPS security context for an inter-system
change from A/Gb mode or Iu mode to S1 mode in EMM-CONNECTED mode, the MME shall
generate a KSISGSN, create a nonceMME and generate the K’ASME using the created
nonceMME as indicated in 3GPP TS 33.401 [19]. The MME shall include the selected
NAS algorithms, nonceMME and generated KSISGSN (associated with the K’ASME) in
the NAS security transparent container for handover to E-UTRAN. The MME shall
derive the EPS NAS keys from K’ASME.

When the UE receives the command to perform handover to E-UTRAN, the UE shall
derive K’ASME, as indicated in 3GPP TS 33.401 [19], using the nonceMME received
in the NAS security transparent container. Furthermore, the UE shall associate
the derived K’ASME with the received KSISGSN and derive the EPS NAS keys from
K’ASME.

When the UE has a PDN connection for emergency bearer services and has no
current UMTS security context, the MME shall set EIA0 and EEA0 as the selected
NAS security algorithms in the NAS security transparent container for handover
to E-UTRAN. The MME shall create a locally generated K’ASME. The MME shall set
the KSI value of the associated security context to “000” and the type of
security context flag to “mapped security context” in the NAS security
transparent container for handover to E-UTRAN.

When the UE receives the command to perform handover to E-UTRAN and has a PDN
connection for emergency bearer services, if EIA0 and EEA0 as the selected NAS
security algorithms are included in the NAS security transparent container for
handover to E-UTRAN, the UE shall create a locally generated K’ASME. The UE
shall set the KSI value of the associated security context to the KSI value
received.

If the inter-system change from A/Gb mode or Iu mode to S1 mode in EMM-CONNECTED
mode is not completed successfully, the MME and the UE shall delete the new
mapped EPS security context.

The establishment of a mapped EPS security context during inter-system change
from N1 mode to S1 mode in EMM-CONNECTED mode is specified in 3GPP TS 24.501
[54] subclause 4.4.2.4.

4.4.2.3 Establishment of secure exchange of NAS messages

Secure exchange of NAS messages via a NAS signalling connection is usually
established by the MME during the attach procedure by initiating a security mode
control procedure. After successful completion of the security mode control
procedure, all NAS messages exchanged between the UE and the MME are sent
integrity protected using the current EPS security algorithms, and except for
the messages specified in subclause 4.4.5, all NAS messages exchanged between
the UE and the MME are sent ciphered using the current EPS security algorithms.

During inter-system handover from A/Gb mode to S1 mode or Iu mode to S1 mode,
secure exchange of NAS messages is established between the MME and the UE by:

- the transmission of NAS security related parameters encapsulated in the AS
signalling from the MME to the UE triggering the inter-system handover (see 3GPP
TS 33.401 [19]). The UE uses these parameters to generate the mapped EPS
security context; and,

- after the handover, the transmission of a TRACKING AREA UPDATE REQUEST message
from the UE to the MME. The UE shall send this message integrity protected using
the mapped EPS security context, but unciphered. From this time onward, all NAS
messages exchanged between the UE and the MME are sent integrity protected using
the mapped EPS security context, and except for the messages specified in
subclause 4.4.5, all NAS messages exchanged between the UE and the MME are sent
ciphered using the mapped EPS security context.

During inter-system change from N1 mode to S1 mode in EMM-CONNECTED mode, secure
exchange of NAS messages is established between the MME and the UE by:

- the transmission of NAS security related parameters encapsulated in the AS
signalling from the AMF to the UE triggering the inter-system handover (see 3GPP
TS 33.501 [56]). The UE uses these parameters to generate the mapped EPS
security context (see subclause 8.6.1 of 3GPP TS 33.501 [56]); and

- after the handover, the transmission of a TRACKING AREA UPDATE REQUEST message
from the UE to the MME. The UE shall send this message integrity protected using
the mapped EPS security context, but unciphered. From this time onward, all NAS
messages exchanged between the UE and the MME are sent integrity protected using
the mapped EPS security context, and except for the messages specified in
subclause 4.4.5, all NAS messages exchanged between the UE and the MME are sent
ciphered using the mapped EPS security context.

During inter-system change from N1 mode to S1 mode in EMM-IDLE mode, if the UE
is operating in the single-registration mode and:

1. if the tracking area updating procedure is initiated as specified in 3GPP TS
   24.501 [54], the UE shall transmit a TRACKING AREA UPDATE REQUEST message
   integrity protected with the current 5G NAS security context and the UE shall
   derive a mapped EPS security context (see subclause 8.6.1 of 3GPP TS 33.501
   [56]). The UE shall set the uplink and downlink NAS COUNT counters to the uplink
   and downlink NAS COUNT counters of the current 5G NAS security context
   respectively. The UE shall include the eKSI indicating the 5G NAS security
   context value in the TRACKING AREA UPDATE REQUEST message.

After receiving the TRACKING AREA UPDATE REQUEST message including the eKSI, the
MME forwards the TRACKING AREA UPDATE REQUEST message to the source AMF, if
possible, to obtain the mapped EPS security context from the AMF as specified in
3GPP TS 33.501 [56]. The MME shall store the mapped EPS NAS security context
with the uplink and downlink NAS COUNT counters associated with the derived
K’ASME key set to the uplink and downlink NAS COUNT counters of the mapped EPS
NAS security context respectively. The MME re-establishes the secure exchange of
NAS messages by either:

- replying with a TRACKING AREA UPDATE ACCEPT message that is integrity
protected and ciphered using the mapped EPS security context. From this time
onward, all NAS messages exchanged between the UE and the MME are sent integrity
protected and except for the messages specified in subclause 4.4.5, all NAS
messages exchanged between the UE and the MME are sent ciphered; or

- initiating a security mode control procedure. This can be used by the MME to
take a non-current EPS security context into use or to modify the current EPS
security context by selecting new NAS security algorithms; or

2. if the attach procedure is initiated as specified in 3GPP TS 24.501 [54] and:

a) if the UE has received an “interworking without N26 interface not supported”
indication from the network and the UE has a valid 5G NAS security context, the
UE shall send an ATTACH REQUEST message integrity protected with the current 5G
NAS security context and the UE shall derive a mapped EPS security context (see
subclause 8.6.1 of 3GPP TS 33.501 [56]). The UE shall set the uplink and
downlink NAS COUNT counters to the uplink and downlink NAS COUNT counters of the
current 5G NAS security context respectively. The UE shall include the eKSI
indicating the 5G NAS security context value in the ATTACH REQUEST message.

After receiving the ATTACH REQUEST message including the eKSI, the MME forwards
the ATTACH REQUEST message to the source AMF, if possible, to obtain the mapped
EPS security context from the AMF as specified in 3GPP TS 33.501 [56]. The MME
shall store the mapped EPS NAS security context with the uplink and downlink NAS
COUNT counters associated with the derived K’ASME key set to the uplink and
downlink NAS COUNT counters of the mapped EPS NAS security context respectively.
The MME re-establishes the secure exchange of NAS messages by either:

- replying with an ATTACH ACCEPT message that is integrity protected and
ciphered using the mapped EPS NAS security context. From this time onward, all
NAS messages exchanged between the UE and the MME are sent integrity protected
and except for the messages specified in subclause 4.4.5, all NAS messages
exchanged between the UE and the MME are sent ciphered; or

- initiating a security mode control procedure. This can be used by the MME to
modify the current EPS security context by selecting new NAS security
algorithms; or

b) otherwise:

i) if the UE has a valid native EPS security context, the UE shall send an
ATTACH REQUEST message integrity protected with the native EPS security context.
The UE shall include the eKSI indicating the native EPS security context value
in the ATTACH REQUEST message.

After receiving the ATTACH REQUEST message including the eKSI, the MME shall
check whether the eKSI included in the initial NAS message belongs to an EPS
security context available in the MME, and shall verify the MAC of the NAS
message. If the verification is successful, the MME re-establishes the secure
exchange of NAS messages by either:

- replying with an ATTACH ACCEPT message that is integrity protected and
ciphered using the current EPS security context. From this time onward, all NAS
messages exchanged between the UE and the MME are sent integrity protected and
except for the messages specified in subclause 4.4.5, all NAS messages exchanged
between the UE and the MME are sent ciphered; or

- initiating a security mode control procedure. This can be used by the MME to
modify the current EPS security context by selecting new NAS security
algorithms; or

ii) if the UE has no valid native EPS security context, the UE shall send an
ATTACH REQUEST message without integrity protection and encryption.

The secure exchange of NAS messages shall be continued after S1 mode to S1 mode
handover. It is terminated after inter-system handover from S1 mode to A/Gb mode
or Iu mode or when the NAS signalling connection is released.

When a UE in EMM-IDLE mode establishes a new NAS signalling connection and has a
valid current EPS security context, secure exchange of NAS messages can be
re-established in the following ways:

1. Except for the cases described in items 3 and 4 below, the UE shall transmit
   the initial NAS message integrity protected with the current EPS security
   context, but unciphered. The UE shall include the eKSI indicating the current
   EPS security context value in the initial NAS message. The MME shall check
   whether the eKSI included in the initial NAS message belongs to an EPS security
   context available in the MME, and shall verify the MAC of the NAS message. If
   the verification is successful, the MME may re-establish the secure exchange of
   NAS messages:

- by replying with a NAS message that is integrity protected and ciphered using
the current EPS security context. From this time onward, all NAS messages
exchanged between the UE and the MME are sent integrity protected and except for
the messages specified in subclause 4.4.5, all NAS messages exchanged between
the UE and the MME are sent ciphered; or

- by initiating a security mode control procedure. This can be used by the MME
to take a non-current EPS security context into use or to modify the current EPS
security context by selecting new NAS security algorithms; or

2. If the initial NAS message was a SERVICE REQUEST message or EXTENDED SERVICE
   REQUEST message, secure exchange of NAS messages is triggered by the indication
   from the lower layers that the user plane radio bearers are successfully set up.
   After successful completion of the procedure, all NAS messages exchanged between
   the UE and the MME are sent integrity protected and except for the messages
   specified in subclause 4.4.5, all NAS messages exchanged between the UE and the
   MME are sent ciphered.

3. If the UE has no current EPS security context and performs a tracking area
   updating procedure after an inter-system change in idle mode from A/Gb mode to
   S1 mode or Iu mode to S1 mode, the UE shall send the TRACKING AREA UPDATE
   REQUEST message without integrity protection and encryption. The UE shall
   include a nonce and a GPRS ciphering key sequence number for creation of a
   mapped EPS security context. The MME creates a fresh mapped EPS security context
   and takes this context into use by initiating a security mode control procedure
   and this context becomes the current EPS security context in both the UE and the
   MME. This re-establishes the secure exchange of NAS messages.

4. If the initial NAS message is a CONTROL PLANE SERVICE REQUEST message, the UE
   shall send the message integrity protected. If an ESM message container
   information element or a NAS message container information element is included
   the message shall be sent partially ciphered (see subclause 4.4.5) , otherwise
   the message shall be sent unciphered. Secure exchange of NAS messages is
   re-established in the UE:

- by the indication from the lower layers that the user plane radio bearers are
successfully set up;

- upon receipt of a NAS message (e.g. a SERVICE ACCEPT message or ESM DATA
TRANSPORT message) that is integrity protected and ciphered using the current
EPS security context; or

- upon receipt of a SECURITY MODE COMMAND message that has successfully passed
the integrity check.

4.4.2.4 Change of security keys

When the MME initiates a re-authentication to create a new EPS security context,
the messages exchanged during the authentication procedure are integrity
protected and ciphered using the current EPS security context, if any.

Both UE and MME shall continue to use the current EPS security context, until
the MME initiates a security mode control procedure. The SECURITY MODE COMMAND
message sent by the MME includes the eKSI of the new EPS security context to be
used. The MME shall send the SECURITY MODE COMMAND message integrity protected
with the new EPS security context, but unciphered. When the UE responds with a
SECURITY MODE COMPLETE, it shall send the message integrity protected and
ciphered with the new EPS security context.

The MME can also modify the current EPS security context or take the non-current
native EPS security context, if any, into use, by sending a SECURITY MODE
COMMAND message including the eKSI of the EPS security context to be modified
and including a new set of selected NAS security algorithms. In this case the
MME shall send the SECURITY MODE COMMAND message integrity protected with the
modified EPS security context, but unciphered. When the UE replies with a
SECURITY MODE COMPLETE message, it shall send the message integrity protected
and ciphered with the modified EPS security context.

4.4.2.5 Derivation of keys at CS to PS SRVCC handover from A/Gb mode to S1 mode or from Iu mode to S1 mode

At change from A/Gb mode to S1 mode or from Iu mode to S1 mode due to CS to PS
SRVCC handover (see 3GPP TS 23.216 [8]), the UE shall derive a mapped EPS
security context for the PS domain from the UMTS security context for the CS
domain.

At change from A/Gb mode to S1 mode due to CS to PS SRVCC handover, ciphering
may be started and integrity protection shall be started (see 3GPP TS 36.331
[22]) without any new authentication procedure.

NOTE 1: CS to PS SRVCC handover from A/Gb mode to S1 mode or from Iu mode to S1
mode is not supported if the current CS security context is a GSM security
context.

NOTE 2: For emergency calls, CS to PS SRVCC handover from A/Gb mode to S1 mode
or from Iu mode to S1 mode is not supported.

In order to derive a mapped EPS security context for a CS to PS SRVCC handover
from A/Gb mode or Iu mode to S1 mode, the MSC creates a NONCEMSC and generates
the CK’PS and IK’PS using the CS UMTS integrity key, the CS UMTS ciphering key
and the created NONCEMSC as specified in annex B.6 in 3GPP TS 33.102 [18]. The
MSC associates the CK’PS and IK’PS with a KSI’PS. The KSI’PS is set to the value
of the KSICS associated with the CS UMTS integrity key and the CS UMTS ciphering
key. The MSC transfers the CK’PS, IK’PS and the KSI’PS to the MME. The MME shall
create a mapped EPS security context by setting the K’ASME to the concatenation
of the CK’PS and IK’PS received from the MSC (i.e. CK’PS || IK’PS). The MME
shall associate the K’ASME with a KSISGSN. The MME shall set KSISGSN to the
value of the KSI’PS received from the MSC. The MME shall include the selected
NAS algorithms, NONCEMME and generated KSISGSN (associated with the K’ASME) in
the NAS security transparent container for the handover to E-UTRAN. The MME
shall derive the EPS NAS keys from K’ASME.

When the UE receives the command to perform CS to PS SRVCC handover to S1 mode,
the ME shall generate the CK’PS and IK’PS using the CS UMTS integrity key, the
CS UMTS ciphering key and the received NONCEMSC value in the transparent
container in the CS to PS SRVCC handover command as specified in annex B.6 in
3GPP TS 33.102 [18]. The ME shall ignore the NONCEMME value received in the NAS
Security Transparent Container in the CS to PS SRVCC handover command.

NOTE 3: The NONCEMME value received in the NAS Security Transparent Container
for the handover to E-UTRAN is not used by the ME or MME in any key derivation
in this handover.

The ME shall create the key K’ASME by concatenating the derived CK’PS and IK’PS
(i.e. CK’PS || IK’PS.). The ME shall associate the derived key K’ASME with a
KSISGSN.The ME shall set the KSISGSN associated to K’ASME to the KSISGSN value
received in the NAS Security Transparent Container from the network.

NOTE 4: Although this case is related to the MSC server enhanced for SRVCC, the
name KSISGSN is kept to avoid introducing a new name for the same domain.

The ME shall derive the EPS NAS keys (CK’ and IK’) from the K’ASME as specified
in 3GPP TS 33.401 [19]. The ME shall apply these derived EPS NAS security keys
(CK’ and IK’), reset the uplink and downlink NAS COUNT values for the mapped EPS
security context (i.e. to the value 0), and replace an already established
mapped EPS security context for the PS domain, if any, in the ME, when the CS to
PS SRVCC handover from A/Gb mode or Iu mode has been completed successfully. If
the already established current EPS security context is of type native, then it
shall become the non-current native EPS security context and overwrite any
existing non-current native EPS security context in the ME.

The network shall replace an already established mapped EPS security context for
the PS domain, if any, when the CS to PS SRVCC handover from A/Gb mode or Iu
mode has been completed successfully. If the already established current EPS
security context is of type native, then it shall become the non-current native
EPS security context and overwrite any existing non-current native EPS security
context in the MME.

If the CS to PS SRVCC handover from A/Gb mode or Iu mode has not been completed
successfully, the UE and the network shall delete the new derived mapped EPS
security context for the PS domain. Additionally, the network shall delete an
already established mapped EPS security context for the PS domain, if any, if
the eKSI of the already established EPS security context is equal to the KSISGSN
of the new derived EPS security context for the PS domain.

4.4.3 Handling of NAS COUNT and NAS sequence number

4.4.3.1 General

Each EPS security context shall be associated with two separate counters NAS
COUNT: one related to uplink NAS messages and one related to downlink NAS
messages. The NAS COUNT counters use 24 bit internal representation and are
independently maintained by UE and MME. The NAS COUNT shall be constructed as a
NAS sequence number (8 least significant bits) concatenated with a NAS overflow
counter (16 most significant bits).

When NAS COUNT is input to NAS ciphering or NAS integrity algorithms it shall be
considered to be a 32-bit entity which shall be constructed by padding the
24-bit internal representation with 8 zeros in the most significant bits.

The value of the uplink NAS COUNT that is stored or read out of the USIM or
non-volatile memory as described in annex C, is the value that shall be used in
the next NAS message.

The value of the downlink NAS COUNT that is stored or read out of the USIM or
non-volatile memory as described in annex C, is the largest downlink NAS COUNT
used in a successfully integrity checked NAS message.

The NAS sequence number part of the NAS COUNT shall be exchanged between the UE
and the MME as part of the NAS signalling. After each new or retransmitted
outbound security protected NAS message, the sender shall increase the NAS COUNT
number by one, except for the initial NAS messages if the lower layers indicated
the failure to establish the RRC connection (see 3GPP TS 36.331 [22]).
Specifically, on the sender side, the NAS sequence number shall be increased by
one, and if the result is zero (due to wrap around), the NAS overflow counter
shall also be incremented by one (see subclause 4.4.3.5). The receiving side
shall estimate the NAS COUNT used by the sending side. Specifically, if the
estimated NAS sequence number wraps around, the NAS overflow counter shall be
incremented by one.

After the derivation of a NAS token due to an inter-system change from S1mode to
A/Gb mode or Iu mode in idle mode as specified in 3GPP TS 24.008 [13], the UE
shall increase the uplink NAS COUNT by one.

When the MME receives a NAS token via SGSN during an idle mode inter-system
change from S1 mode to A/Gb mode or Iu mode, the MME shall check the NAS token
as specified in 3GPP TS 33.401 [19], subclause 9.1.1, and update its uplink NAS
COUNT with the uplink NAS COUNT value used for the successful check of the NAS
token.

NOTE 1: The MME does not check the NAS token if it is received via SGSN during a
connected mode inter-system change from S1 mode to A/Gb mode or Iu mode.

During the handover from UTRAN/GERAN to E-UTRAN, when a mapped EPS security
context is derived and taken into use, the MME shall set both the uplink and
downlink NAS COUNT counters of this EPS security context to zero. The UE shall
set both the uplink and downlink NAS COUNT counters to zero.

When a mapped EPS security context is derived as specified in 3GPP TS 33.501
[56] and taken into use in the following cases:

- during the inter-system change from N1 mode to S1 mode in 5GMM-CONNECTED mode;
or

- during the inter-system change from N1 mode to S1 mode in EMM-IDLE mode for
the UE operating in single-registration mode in a network supporting N26
interface,

the MME shall store the mapped EPS NAS security context with the uplink and
downlink NAS COUNT counters associated with the derived K’ASME key set to the
uplink and downlink NAS COUNT counters of the mapped EPS NAS security context
respectively. The UE shall set the uplink and downlink NAS COUNT counters to the
uplink and downlink NAS COUNT counters of the current 5G NAS security context
respectively.

During the handover from E-UTRAN to UTRAN/GERAN the MME signals the current
downlink NAS COUNT value in a NAS security transparent container (see subclause
9.9.2.6).

During handover to or from E-UTRAN, the MME shall increment downlink NAS COUNT
by one after it has created a NAS security transparent container (see subclause
9.9.2.6 and 9.9.2.7).

NOTE 2: During the handover from UTRAN/GERAN to E-UTRAN, the NAS security
transparent container (see subclause 9.9.2.7) is treated as an implicit SECURITY
MODE COMMAND message for the UE and the MME, and therefore the MME regards the
sending of the NAS security transparent container as the sending of an initial
SECURITY MODE COMMAND message in order to derive and take into use a mapped EPS
security context for the purpose of the NAS COUNT handling.

In some NAS messages only 5 of the 8 NAS sequence number bits are transmitted.
When this is the case, the receiver shall estimate the remaining 3 most
significant bits of the sequence number.

4.4.3.2 Replay protection

Replay protection shall be supported for received NAS messages both in the MME
and the UE. However, since the realization of replay protection does not affect
the interoperability between nodes, no specific mechanism is required for
implementation.

Replay protection must assure that one and the same NAS message is not accepted
twice by the receiver. Specifically, for a given EPS security context, a given
NAS COUNT value shall be accepted at most one time and only if message integrity
verifies correctly.

Replay protection is not applicable when EIA0 is used.

4.4.3.3 Integrity protection and verification

The sender shall use its locally stored NAS COUNT as input to the integrity
protection algorithm.

The receiver shall use the NAS sequence number included in the received message
(or estimated from the 5 bits of the NAS sequence number received in the
message) and an estimate for the NAS overflow counter as defined in subclause
4.4.3.1 to form the NAS COUNT input to the integrity verification algorithm.

The algorithm to calculate the integrity protection information is specified in
3GPP TS 33.401 [19], and the integrity protection shall include octet 6 to n of
the security protected NAS message, i.e. the sequence number IE and the NAS
message IE. The integrity protection of the SERVICE REQUEST message is defined
in subclause 9.9.3.28. In addition to the data that is to be integrity
protected, the constant BEARER ID, DIRECTION bit, NAS COUNT and NAS integrity
key are input to the integrity protection algorithm. These parameters are
described in 3GPP TS 33.401 [19].

After successful integrity protection validation, the receiver shall update its
corresponding locally stored NAS COUNT with the value of the estimated NAS COUNT
for this NAS message.

Integrity verification is not applicable when EIA0 is used.

4.4.3.4 Ciphering and deciphering

The sender shall use its locally stored NAS COUNT as input to the ciphering
algorithm.

The receiver shall use the NAS sequence number included in the received message
(or estimated from the 5 bits of the NAS sequence number received in the
message) and an estimate for the NAS overflow counter as defined in subclause
4.4.3.1 to form the NAS COUNT input to the deciphering algorithm.

The input parameters to the NAS ciphering algorithm are the constant BEARER ID,
DIRECTION bit, NAS COUNT, NAS encryption key and the length of the key stream to
be generated by the encryption algorithm. When an initial plain NAS message for
transport of user data via control plane (i.e. CONTROL PLANE SERVICE REQUEST
message) is to be partially ciphered, the length of the key stream is set to the
length of the part of the initial plain NAS message (i.e. the value part of the
ESM message container IE or the value part of the NAS message container) that is
to be ciphered.

4.4.3.5 NAS COUNT wrap around

If, when increasing the NAS COUNT as specified above, the MME detects that
either its downlink NAS COUNT or the UE’s uplink NAS COUNT is “close” to wrap
around, (close to 224), the MME shall take the following actions:

- If there is no non-current native EPS security context with sufficiently low
NAS COUNT values, the MME shall initiate a new AKA procedure with the UE,
leading to a new established EPS security context and the NAS COUNT being reset
to 0 in both the UE and the MME when the new EPS security context is activated;

- Otherwise, the MME can activate a non-current native EPS security context with
sufficiently low NAS COUNT values or initiate a new AKA procedure as specified
above.

If for some reason a new KASME has not been established using AKA before the NAS
COUNT wraps around, the node (MME or UE) in need of sending a NAS message shall
instead release the NAS signalling connection. Prior to sending the next uplink
NAS message, the UE shall delete the eKSI indicating the current EPS security
context.

When the EIA0 is used as the NAS integrity algorithm, the UE and the MME shall
allow NAS COUNT wrap around. If NAS COUNT wrap around occurs, the following
requirements apply:

- the UE and the MME shall continue to use the current security context;

- the MME shall not initiate the EPS AKA procedure;

- the MME shall not release the NAS signalling connection; and

- the UE shall not perform a local release of the NAS signalling connection.

4.4.4 Integrity protection of NAS signalling messages

4.4.4.1 General

For the UE, integrity protected signalling is mandatory for the NAS messages
once a valid EPS security context exists and has been taken into use. For the
network, integrity protected signalling is mandatory for the NAS messages once a
secure exchange of NAS messages has been established for the NAS signalling
connection. Integrity protection of all NAS signalling messages is the
responsibility of the NAS. It is the network which activates integrity
protection.

The use of “null integrity protection algorithm” EIA0 (see subclause 9.9.3.23)
in the current security context is only allowed for an unauthenticated UE for
which establishment of emergency bearer services or access to RLOS is allowed.
For setting the security header type in outbound NAS messages, the UE and the
MME shall apply the same rules irrespective of whether the “null integrity
protection algorithm” or any other integrity protection algorithm is indicated
in the security context.

If the “null integrity protection algorithm” EIA0 has been selected as a
integrity protection algorithm, the receiver shall regard the NAS messages with
the security header indicating integrity protection as integrity protected.

Details of the integrity protection and verification of NAS signalling messages
are specified in 3GPP TS 33.401 [19].

When a NAS message needs to be sent both ciphered and integrity protected, the
NAS message is first ciphered and then the ciphered NAS message and the NAS
sequence number are integrity protected by calculating the MAC. The same applies
when an initial NAS message needs to be sent partially ciphered and integrity
protected.

NOTE: NAS messages that are ciphered or partially ciphered with the “null
ciphering algorithm” EEA0 are regarded as ciphered or partially ciphered,
respectively (see subclause 4.4.5).

When a NAS message needs to be sent only integrity protected and unciphered, the
unciphered NAS message and the NAS sequence number are integrity protected by
calculating the MAC.

When during the EPS attach procedure or service request procedure an ESM message
is piggybacked in an EMM message, there is only one sequence number IE and one
message authentication code IE, if any, for the combined NAS message.

4.4.4.2 Integrity checking of NAS signalling messages in the UE

Except the messages listed below, no NAS signalling messages shall be processed
by the receiving EMM entity in the UE or forwarded to the ESM entity, unless the
network has established secure exchange of NAS messages for the NAS signalling
connection:

- EMM messages:

- IDENTITY REQUEST (if requested identification parameter is IMSI);

- AUTHENTICATION REQUEST;

- AUTHENTICATION REJECT;

- ATTACH REJECT (if the EMM cause is not #25);

- DETACH ACCEPT (for non switch off);

- TRACKING AREA UPDATE REJECT (if the EMM cause is not #25);

- SERVICE REJECT (if the EMM cause is not #25).

NOTE: These messages are accepted by the UE without integrity protection, as in
certain situations they are sent by the network before security can be
activated.

All ESM messages are integrity protected.

Once the secure exchange of NAS messages has been established, the receiving EMM
or ESM entity in the UE shall not process any NAS signalling messages unless
they have been successfully integrity checked by the NAS. If NAS signalling
messages, having not successfully passed the integrity check, are received, then
the NAS in the UE shall discard that message. The processing of the SECURITY
MODE COMMAND message that has not successfully passed the integrity check is
specified in subclause 5.4.3.5. If any NAS signalling message is received as not
integrity protected even though the secure exchange of NAS messages has been
established by the network, then the NAS shall discard this message.

4.4.4.3 Integrity checking of NAS signalling messages in the MME

Except the messages listed below, no NAS signalling messages shall be processed
by the receiving EMM entity in the MME or forwarded to the ESM entity, unless
the secure exchange of NAS messages has been established for the NAS signalling
connection:

- EMM messages:

- ATTACH REQUEST;

- IDENTITY RESPONSE (if requested identification parameter is IMSI);

- AUTHENTICATION RESPONSE;

- AUTHENTICATION FAILURE;

- SECURITY MODE REJECT;

- DETACH REQUEST;

- DETACH ACCEPT;

- TRACKING AREA UPDATE REQUEST.

NOTE 1: The TRACKING AREA UPDATE REQUEST message is sent by the UE without
integrity protection, if the tracking area updating procedure is initiated due
to an inter-system change in idle mode and no current EPS security context is
available in the UE. The other messages are accepted by the MME without
integrity protection, as in certain situations they are sent by the UE before
security can be activated.

NOTE 2: The DETACH REQUEST message can be sent by the UE without integrity
protection, e.g. if the UE is attached for emergency bearer services or access
to RLOS and there is no shared EPS security context available, or if due to user
interaction an attach procedure is cancelled before the secure exchange of NAS
messages has been established. For these cases the network can attempt to use
additional criteria (e.g. whether the UE is subsequently still performing
periodic tracking area updating or still responding to paging) before marking
the UE as EMM-DEREGISTERED.

All ESM messages are integrity protected except a PDN CONNECTIVITY REQUEST
message if it is sent piggybacked in ATTACH REQUEST message and NAS security is
not activated.

Once a current EPS security context exists, until the secure exchange of NAS
messages has been established for the NAS signalling connection, the receiving
EMM entity in the MME shall process the following NAS signalling messages, even
if the MAC included in the message fails the integrity check or cannot be
verified, as the EPS security context is not available in the network:

- ATTACH REQUEST;

- IDENTITY RESPONSE (if requested identification parameter is IMSI);

- AUTHENTICATION RESPONSE;

- AUTHENTICATION FAILURE;

- SECURITY MODE REJECT;

- DETACH REQUEST;

- DETACH ACCEPT;

- TRACKING AREA UPDATE REQUEST;

- SERVICE REQUEST;

- EXTENDED SERVICE REQUEST;

- CONTROL PLANE SERVICE REQUEST.

NOTE 3: These messages are processed by the MME even when the MAC that fails the
integrity check or cannot be verified, as in certain situations they can be sent
by the UE protected with an EPS security context that is no longer available in
the network.

If an ATTACH REQUEST message is received without integrity protection or fails
the integrity check and it is not an attach request for emergency bearer
services and it is not an attach request for access to RLOS, the MME shall
authenticate the subscriber before processing the attach request any further.
Additionally, if the MME initiates a security mode control procedure, the MME
shall include a HASHMME IE in the SECURITY MODE COMMAND message as specified in
subclause 5.4.3.2. For the case when the attach procedure is for emergency
bearer services see subclause 5.5.1.2.3 and subclause 5.4.2.5.

If a DETACH REQUEST message fails the integrity check, the MME shall proceed as
follows:

- If it is not a detach request due to switch off, and the MME can initiate an
authentication procedure, the MME should authenticate the subscriber before
processing the detach request any further.

- If it is a detach request due to switch off, or the MME does not initiate an
authentication procedure for any other reason, the MME may ignore the detach
request and remain in state EMM-REGISTERED.

NOTE 4: The network can attempt to use additional criteria (e.g. whether the UE
is subsequently still performing periodic tracking area updating or still
responding to paging) before marking the UE as EMM-DEREGISTERED.

If a TRACKING AREA UPDATE REQUEST message is received without integrity
protection or fails the integrity check and the UE provided a nonceUE, GPRS
ciphering key sequence number, P-TMSI and RAI in the TRACKING AREA UPDATE
REQUEST message, the MME shall initiate a security mode control procedure to
take a new mapped EPS security context into use; otherwise, if the UE has only a
PDN connection for non-emergency bearer services established and the PDN
connection is not for RLOS, the MME shall initiate an authentication procedure.
Additionally, if the MME initiates a security mode control procedure, the MME
shall include a HASHMME IE in the SECURITY MODE COMMAND message as specified in
subclause 5.4.3.2. For the case when the UE has a PDN connection for emergency
bearer services or for RLOS see subclause 5.5.3.2.3 and subclause 5.4.2.5.

If a SERVICE REQUEST, EXTENDED SERVICE REQUEST or CONTROL PLANE SERVICE REQUEST
message fails the integrity check and the UE has only PDN connections for
non-emergency bearer services established and the PDN connections are not for
RLOS, the MME shall send the SERVICE REJECT message with EMM cause #9 “UE
identity cannot be derived by the network” and keep the EMM-context and EPS
security context unchanged. For the case when the UE has a PDN connection for
emergency bearer services or RLOS and integrity check fails, the MME may skip
the authentication procedure even if no EPS security context is available and
proceed directly to the execution of the security mode control procedure as
specified in subclause 5.4.3. After successful completion of the service request
procedure, the network shall deactivate all non-emergency EPS bearers locally
which are not EPS bearers for RLOS. The emergency EPS bearers shall not be
deactivated. The network may deactivate the EPS bearers for RLOS.

Once the secure exchange of NAS messages has been established for the NAS
signalling connection, the receiving EMM or ESM entity in the MME shall not
process any NAS signalling messages unless they have been successfully integrity
checked by the NAS. If any NAS signalling message, having not successfully
passed the integrity check, is received, then the NAS in the MME shall discard
that message. If any NAS signalling message is received, as not integrity
protected even though the secure exchange of NAS messages has been established,
then the NAS shall discard this message.

4.4.5 Ciphering of NAS signalling messages

The use of ciphering in a network is an operator option subject to MME
configuration. When operation of the network without ciphering is configured,
the MME shall indicate the use of “null ciphering algorithm” EEA0 (see subclause
9.9.3.23) in the current security context for all UEs. For setting the security
header type in outbound NAS messages, the UE and the MME shall apply the same
rules irrespective of whether the “null ciphering algorithm” or any other
ciphering algorithm is indicated in the security context.

When the UE establishes a new NAS signalling connection, it shall send the
initial NAS message

- partially ciphered, if it is a CONTROL PLANE SERVICE REQUEST message including
an ESM message container information element or a NAS message container
information element; and

- unciphered, if it is any other initial NAS message.

The UE shall partially cipher the CONTROL PLANE SERVICE REQUEST message by
ciphering the value part of the ESM message container IE or the value part of
the NAS message container, using the ciphering algorithm of the current EPS
security context.

The UE shall send the ATTACH REQUEST message always unciphered.

The UE shall send the TRACKING AREA UPDATE REQUEST message always unciphered.

Except for the CONTROL PLANE SERVICE REQUEST message including an ESM message
container information element or a NAS message container information element,
the UE shall start the ciphering and deciphering of NAS messages when the secure
exchange of NAS messages has been established for a NAS signalling connection.
From this time onward, unless explicitly defined, the UE shall send all NAS
messages ciphered until the NAS signalling connection is released, or the UE
performs intersystem handover to A/Gb mode or Iu mode.

The MME shall start ciphering and deciphering of NAS messages as described in
subclause 4.4.2.3. From this time onward, except for the SECURITY MODE COMMAND
message, the MME shall send all NAS messages ciphered until the NAS signalling
connection is released, or the UE performs intersystem handover to A/Gb mode or
Iu mode.

Once the encryption of NAS messages has been started between the MME and the UE,
the receiver shall discard the unciphered NAS messages which shall have been
ciphered according to the rules described in this specification. The MME shall
discard any CONTROL PLANE SERVICE REQUEST message including an ESM message
container information element or a NAS message container information element
which has not been partially ciphered according to the rules described above.

If the “null ciphering algorithm” EEA0 has been selected as a ciphering
algorithm, the NAS messages with the security header indicating ciphering are
regarded as ciphered.

Details of ciphering and deciphering of NAS signalling messages are specified in
3GPP TS 33.401 [19].

4.5 Disabling and re-enabling of UE’s E-UTRA capability

The UE shall only disable the E-UTRA capability when in EMM-IDLE mode.

When the UE supports both N1 mode and S1 mode then the UE’s capability to access
the 5GCN via E-UTRA shall not be affected, if the UE’s E-UTRA capability is
disabled or enabled.

When the UE is disabling the E-UTRA capability not due to redirection to 5GCN
required, it should proceed as follows:

a) select another RAT (GERAN, UTRAN, or NG-RAN if the UE has not disabled its N1
mode capability for 3GPP access as specified in 3GPP TS 24.501 [54]) of the
registered PLMN or a PLMN from the list of equivalent PLMNs;

b) if another RAT of the registered PLMN or a PLMN from the list of equivalent
PLMNs cannot be found, or the UE does not have a registered PLMN, then perform
PLMN selection as specified in 3GPP TS 23.122 [6]. As an implementation option,
instead of performing PLMN selection, the UE may select another RAT of the
chosen PLMN. If disabling of E-UTRA capability was not due to UE initiated
detach procedure for EPS services only, the UE may re-enable the E-UTRA
capability for this PLMN selection; or

c) if no other allowed PLMN and RAT combinations are available, then the UE may
re-enable the E-UTRA capability and remain registered for EPS services in
E-UTRAN of the registered PLMN. If the UE chooses this option, then it may
periodically attempt to select another PLMN and RAT combination that can provide
non-EPS services. How this periodic scanning is done, is UE implementation
dependent.

When the UE is disabling the E-UTRA capability upon receiving reject cause #31
“Redirection to 5GCN required” as specified in subclauses 5.5.1.2.5, 5.5.1.3.5,
5.5.3.2.5, 5.5.3.3.5 and 5.6.1.5, it should proceed as follows:

i) If the UE is in NB-S1 mode:

1. if lower layers do not provide an indication that the current E-UTRA cell is
   connected to 5GCN or lower layers do not provide an indication that the current
   E-UTRA cell supports CIoT 5GS optimizations that are supported by the UE, search
   for a suitable NB-IoT cell connected to 5GCN according to 3GPP TS 36.304 [21];

2. if lower layers provide an indication that the current E-UTRA cell is
   connected to 5GCN and the current E-UTRA cell supports CIoT 5GS optimizations
   that are supported by the UE then perform a core network selection to select
   5GCN as specified in 3GPP TS 24.501 [54] subclause 4.8.4A.1; or

3. if lower layers cannot find a suitable NB-IoT cell connected to 5GCN or there
   is no suitable NB-IoT cell connected to 5GCN which supports CIoT 5GS
   optimizations that are supported by the UE, the UE may re-enable the E-UTRA
   capability, and indicate to lower layers to remain camped in E-UTRA connected to
   EPC of the previously registered PLMN and proceed with the appropriate EMM
   procedure.

ii) If the UE is in WB-S1 mode:

1. if lower layers do not provide an indication that the current E-UTRA cell is
   connected to 5GCN or lower layers do not provide an indication that the current
   E-UTRA cell supports CIoT 5GS optimizations that are supported by the UE, search
   for a suitable E-UTRA cell connected to 5GCN according to 3GPP TS 36.304 [21];

2. if lower layers provide an indication that the current E-UTRA cell is
   connected to 5GCN and the current E-UTRA cell supports CIoT 5GS optimizations
   that are supported by the UE, then perform a core network selection to select
   5GCN as specified in 3GPP TS 24.501 [54] subclause 4.8.4A.1; or

3. if lower layers cannot find a suitable E-UTRA cell connected to 5GCN or there
   is no suitable E-UTRA cell connected to 5GCN which supports CIoT 5GS
   optimizations that are supported by the UE, the UE may re-enable the E-UTRA
   capability, and indicate to lower layers to remain camped in E-UTRA connected to
   EPC of the previously registered PLMN and proceed with the appropriate EMM
   procedure.

The UE shall re-enable the E-UTRA capability when performing a PLMN selection
unless:

- the disabling of E-UTRA capability was due to UE initiated detach procedure
for EPS services only; or

- the UE has already re-enabled the E-UTRA capability when performing bullets b)
or c) above.

If due to handover, the UE moves to a new PLMN in A/Gb, Iu, or N1 mode which is
not in the list of equivalent PLMNs and not a PLMN memorized by the UE for which
E-UTRA capability was disabled, and the disabling of E-UTRA capability was not
due to UE initiated detach procedure for EPS services only, the UE shall
re-enable the E-UTRA capability after the RR/RRC connection is released.

If UE that has disabled its E-UTRA capability due to IMS voice not available and
CS fallback not available re-enables it when PLMN selection is performed, then
it should memorize the identity of the PLMNs where E-UTRA capability was
disabled and use that stored information in subsequent PLMN selections as
specified in 3GPP TS 23.122 [6].

The UE may support “E-UTRA Disabling for EMM cause #15” and implement the
following behaviour:

- if the “E-UTRA Disabling Allowed for EMM cause #15” parameter as specified in
3GPP TS 24.368 [15A] or 3GPP TS 31.102 [17] is present and set to enabled; and

- if the UE receives an ATTACH REJECT or TRACKING AREA UPDATE REJECT message
including both EMM cause #15 “no suitable cells in tracking area” and an
Extended EMM cause IE with value “E-UTRAN not allowed”;

then the UE shall disable the E-UTRA capability, memorize the identity of the
PLMN where the E-UTRA capability was disabled and use that stored information in
subsequent PLMN selections as specified in 3GPP TS 23.122 [6].

When the UE supporting the A/Gb and/or Iu mode together with the S1 mode needs
to stay in A/Gb or Iu mode, in order to prevent unwanted handover or cell
reselection from UTRAN/GERAN to E-UTRAN, the UE shall disable the E-UTRA
capability and:

- The UE shall not set the E-UTRA support bits of the MS Radio Access capability
IE (see 3GPP TS 24.008 [13], subclause 10.5.5.12a), the E-UTRA support bits of
Mobile Station Classmark 3 IE (see 3GPP TS 24.008 [13], subclause 10.5.1.7), the
PS inter-RAT HO from GERAN to E-UTRAN S1 mode capability bit and the ISR support
bit of the MS network capability IE (see 3GPP TS 24.008 [13], subclause
10.5.5.12) in the ATTACH REQUEST message and the ROUTING AREA UPDATE REQUEST
message after it selects GERAN or UTRAN;

- the UE shall use the same value of the EPC capability bit of the MS network
capability IE (see 3GPP TS 24.008 [13], subclause 10.5.5.12) in the ATTACH
REQUEST message and the ROUTING AREA UPDATE REQUEST message; and

- the UE NAS layer shall indicate the access stratum layer(s) of disabling of
the E-UTRA capability.

When the UE supporting N1 mode together with S1 mode needs to stay in N1 mode,
in order to prevent unwanted handover or cell reselection from NG-RAN to
E-UTRAN, the UE shall disable the E-UTRA capability and:

- the UE shall set the S1 mode bit to “S1 mode not supported” in the 5GMM
Capability IE of the REGISTRATION REQUEST message (see 3GPP TS 24.501 [54]);

- the UE shall not include the S1 UE network capability IE in the REGISTRATION
REQUEST message (see 3GPP TS 24.501 [54]); and

- the UE NAS layer shall indicate the access stratum layer(s) of disabling of
the E-UTRA capability.

If the UE is disabling its E-UTRA capability before selecting to GERAN, UTRAN or
NG-RAN radio access technology, the UE shall not perform the detach procedure of
subclause 5.5.2.1.

If the UE is required to disable the E-UTRA capability and select GERAN, UTRAN
or NG-RAN radio access technology, and the UE is in the EMM-CONNECTED mode:

- if the UE has a persistent EPS bearer context and the ongoing prodedure is not
a detach procedure, then the UE shall wait until the radio bearer associated
with the persistent EPS bearer context has been released;

- otherwise, the UE shall locally release the established NAS signalling
connection and enter the EMM-IDLE mode before selecting GERAN, UTRAN or NG-RAN
radio access technology.

If the E-UTRA capability was disabled due to the attempt to select GERAN or
UTRAN radio access technology progressing the CS emergency call establishment
(see subclause 4.3.1), the criteria to enable the E-UTRA capability again is UE
implementation specific.

If the E-UTRA capability was disabled due to the UE initiated detach procedure
for EPS services only (see subclause 5.5.2.2.2), upon request of the upper
layers to re-attach for EPS services the UE shall enable the E-UTRA capability
again. If the E-UTRA capability was disabled due to receipt of EMM cause #14
“EPS services not allowed in this PLMN”, then the UE shall enable the E-UTRA
capability when the UE powers off and powers on again or the USIM is removed. If
E-UTRA capability was disabled for any other reason, the UE shall enable the
E-UTRA capability in the following cases:

- the UE mode of operation changes from CS/PS mode 1 of operation to CS/PS mode
2 of operation;

- the UE mode of operation changes from PS mode 1 of operation to PS mode 2 of
operation; or

- the UE powers off and powers on again or the USIM is removed;

As an implementation option, the UE may start a timer for enabling E-UTRA when
the UE’s attach attempt counter or tracking area updating attempt counter
reaches 5 and the UE disables E-UTRA capability for cases described in
subclauses 5.5.1.2.6, 5.5.1.3.4.3, 5.5.1.3.6, 5.5.3.2.6, 5.5.3.3.4.3 and
5.5.3.3.6. The UE should memorize the identity of the PLMNs where E-UTRA
capability were disabled. On expiry of this timer:

- if the UE is in Iu mode or A/Gb mode and is in idle mode as specified in 3GPP
TS 24.008 [13] on expiry of the timer, the UE should enable the E-UTRA
capability;

- if the UE is in Iu mode or A/Gb mode and an RR connection exists, the UE shall
delay enabling E-UTRA capability until the RR connection is released;

- if the UE is in Iu mode and a PS signalling connection exists but no RR
connection exists, the UE may abort the PS signalling connection before enabling
E-UTRA capability;

- if the UE is in N1 mode and is in 5GMM-IDLE mode as specified in 3GPP TS
24.501 [54], on expiry of the timer, the UE should enable the E-UTRA capability;
and

- if the UE is in N1 mode and is in 5GMM-CONNECTED mode as specified in 3GPP TS
24.501 [54], on expiry of the timer, the UE shall delay enabling the E-UTRA
capability until the N1 NAS signalling connection is released.

If the UE attempts to establish an emergency bearer service in a PLMN where the
E-UTRA capability was disabled due to the UE’s attach attempt counter or
tracking area updating attempt counter have reached 5, the UE may enable the
E-UTRA capability for that PLMN memorized by the UE.

For other cases, it is up to the UE implementation when to enable the E-UTRA
capability.

NOTE: If the UE is not operating in CS/PS mode 1 operation, the value of the
timer for enabling E-UTRA capability is recommended to be not larger than the
default value of T3402.

4.6 Applicability of procedures

4.6.1 Relay nodes

A relay node shall support all procedures that are mandatory for a UE supporting
S1 mode only.

There is also functionality which is only applicable to a relay node, in which
case the specification uses the term “relay node” instead of “UE”.

4.7 EPS mobility management and EPS session management in NB-S1 mode

A UE in NB-S1 mode (see 3GPP TS 36.331 [22]) shall calculate the value of the
applicable NAS timer:

- indicated in table 10.2.1 plus 240s; and

- indicated in table 10.3.1 plus 180s.

The timer value obtained is used as described in the appropriate procedure
subclause of this specification. The NAS timer value shall be calculated at
start of a NAS procedure and shall not re-calculate the use of the NAS timer
value until the NAS procedure is completed, restarted or aborted.

When an MME that supports NB-S1 mode performs NAS signaling with a UE, which is
using NB-S1 mode, the MME shall calculate the value of the applicable NAS timer:

- indicated in table 10.2.2 plus 240s; and

- indicated in table 10.3.2 plus 180s.

The timer value obtained is used as described in the appropriate procedure
subclause of this specification. The NAS timer value shall be calculated at
start of a NAS procedure and shall not re-calculate the use of the NAS timer
value until the NAS procedure is completed, restarted or aborted.

NOTE: If the tracking area updating procedure is initiated in EMM-CONNECTED
mode, the MME can stop any running implementation specific supervision timer if
it is started when sending an ESM DATA TRANSPORT message to the UE.

4.8 EPS mobility management and EPS session management in WB-S1 mode for IoT

In WB-S1 mode, a UE operating in category CE can operate in either CE mode A or
CE mode B (see 3GPP TS 36.306 [44]). If a UE that supports CE mode B and
operates in WB-S1 mode the UE’s usage setting is not set to “voice centric” (see
3GPP TS 23.401 [10]), and

a) the use of enhanced coverage is not restricted for the UE; or

b) CE mode B is not restricted for the UE (see 3GPP TS 23.401 [10]);

the UE shall apply the value of the applicable NAS timer indicated in tables
10.2.1 and indicated in table 10.3.1 for WB-S1/CE mode.

A UE that supports CE mode B and operates in WB-S1 mode shall not apply the
value of the applicable NAS timer indicated in table 10.2.1 and table 10.3.1 for
WB-S1/CE mode before receiving an indication from the network that the use of
enhanced coverage is not restricted as described in this subclause.

The NAS timer value obtained is used as described in the appropriate procedure
subclause of this specification. The NAS timer value shall be calculated at
start of a NAS procedure, and shall not be re-calculated until the NAS procedure
is completed, restarted or aborted.

The support of CE mode B by a UE is indicated to the MME by lower layers and
shall be stored by the MME. When an MME that supports WB-S1 mode performs NAS
signaling with a UE, which supports CE mode B and operates in WB-S1 mode and the
MME determines that

a) the use of enhanced coverage is not restricted for the UE; or

b) CE mode B is not restricted for the UE (see 3GPP TS 23.401 [10])

the MME shall calculate the value of the applicable NAS timer indicated in
tables 10.2.2 and indicated in table 10.3.2 for WB-S1/CE mode.

The NAS timer value obtained is used as described in the appropriate procedure
subclause of this specification. The NAS timer value shall be calculated at
start of a NAS procedure and shall not be re-calculated until the NAS procedure
is completed, restarted or aborted.

4.9 Disabling and re-enabling of UE’s NB-IoT capability

If the UE supports disabling and re-enabling of UE’s NB-IoT capability and the
UE in NB-S1 mode is disabling the NB-IoT capability, it should proceed as
follows:

a) select E-UTRAN of the registered PLMN or a PLMN from the list of equivalent
PLMNs;

b) if E-UTRAN of the registered PLMN or a PLMN from the list of equivalent PLMNs
cannot be found, select another RAT (GERAN, UTRAN, or NG-RAN if the UE has not
disabled its N1 mode capability for 3GPP access as specified in 3GPP TS 24.501
[54]) of the registered PLMN or a PLMN from the list of equivalent PLMNs;

c) if another RAT of the registered PLMN or a PLMN from the list of equivalent
PLMNs cannot be found, or the UE does not have a registered PLMN, then perform
PLMN selection as specified in 3GPP TS 23.122 [6]. As an implementation option,
instead of performing PLMN selection, the UE may select another RAT of the
chosen PLMN; or

d) if no other allowed PLMN and RAT combinations are available, then the UE may
re-enable the NB-IoT capability and remain registered for EPS services in NB-IoT
of the registered PLMN. If the UE chooses this option, then it may periodically
attempt to select another PLMN and RAT combination that can provide non-EPS
services. How this periodic scanning is done, is UE implementation dependent.

If the the NB-IoT capability is disabled, the UE shall re-enable the NB-IoT
capability when:

- performing a PLMN selection unless the UE has already re-enabled the NB-IoT
capability when performing bullets c) or d) above; or

- the UE powers off and powers on again or the USIM is removed.

If the UE in NB-S1 mode receives an ATTACH REJECT or TRACKING AREA UPDATE REJECT
message including both EMM cause #15 “no suitable cells in tracking area” and
an Extended EMM cause IE with value “NB-IoT not allowed” after the UE requests
access to the NB-IoT, in order to prevent unwanted cell reselection from GERAN,
UTRAN, E-UTRAN or NG-RAN to NB-IoT, the UE may:

- disable the NB-IoT capability:

- indicate the access stratum layer(s) of disabling of the NB-IoT capability;
and

- memorize the identity of the PLMN where the NB-IoT capability was disabled and
use that stored information in subsequent PLMN selections as specified in 3GPP
TS 23.122 [6].

NOTE: The UE can only disable the NB-IoT capability when in EMM-IDLE mode.

If the UE in NB-S1 mode is required to disable the NB-IoT capability and select
E-UTRAN radio access technology, and the UE is in the EMM-CONNECTED mode, the UE
shall locally release the established NAS signalling connection and enter the
EMM-IDLE mode before selecting E-UTRAN radio access technology.

As an implementation option, the UE may start a timer for enabling the NB-IoT
capability. On expiry of this timer, the UE may enable the NB-IoT capability.
06 [44]). If a UE that supports CE mode B and
operates in WB-S1 mode the UE’s usage setting is not set to “voice centric” (see
3GPP TS 23.401 [10]), and

a) the use of enhanced coverage is not restricted for the UE; or

b) CE mode B is not restricted for the UE (see 3GPP TS 23.401 [10]);

the UE shall apply the value of the applicable NAS timer indicated in tables
10.2.1 and indicated in table 10.3.1 for WB-S1/CE mode.

A UE that supports CE mode B and operates in WB-S1 mode shall not apply the
value of the applicable NAS timer indicated in table 10.2.1 and table 10.3.1 for
WB-S1/CE mode before receiving an indication from the network that the use of
enhanced coverage is not restricted as described in this subclause.

The NAS timer value obtained is used as described in the appropriate procedure
subclause of this specification. The NAS timer value shall be calculated at
start of a NAS procedure, and shall not be re-calculated until the NAS procedure
is completed, restarted or aborted.

The support of CE mode B by a UE is indicated to the MME by lower layers and
shall be stored by the MME. When an MME that supports WB-S1 mode performs NAS
signaling with a UE, which supports CE mode B and operates in WB-S1 mode and the
MME determines that

a) the use of enhanced coverage is not restricted for the UE; or

b) CE mode B is not restricted for the UE (see 3GPP TS 23.401 [10])

the MME shall calculate the value of the applicable NAS timer indicated in
tables 10.2.2 and indicated in table 10.3.2 for WB-S1/CE mode.

The NAS timer value obtained is used as described in the appropriate procedure
subclause of this specification. The NAS timer value shall be calculated at
start of a NAS procedure and shall not be re-calculated until the NAS procedure
is completed, restarted or aborted.

4.9 Disabling and re-enabling of UE’s NB-IoT capability

If the UE supports disabling and re-enabling of UE’s NB-IoT capability and the
UE in NB-S1 mode is disabling the NB-IoT capability, it should proceed as
follows:

a) select E-UTRAN of the registered PLMN or a PLMN from the list of equivalent
PLMNs;

b) if E-UTRAN of the registered PLMN or a PLMN from the list of equivalent PLMNs
cannot be found, select another RAT (GERAN, UTRAN, or NG-RAN if the UE has not
disabled its N1 mode capability for 3GPP access as specified in 3GPP TS 24.501
[54]) of the registered PLMN or a PLMN from the list of equivalent PLMNs;

c) if another RAT of the registered PLMN or a PLMN from the list of equivalent
PLMNs cannot be found, or the UE does not have a registered PLMN, then perform
PLMN selection as specified in 3GPP TS 23.122 [6]. As an implementation option,
instead of performing PLMN selection, the UE may select another RAT of the
chosen PLMN; or

d) if no other allowed PLMN and RAT combinations are available, then the UE may
re-enable the NB-IoT capability and remain registered for EPS services in NB-IoT
of the registered PLMN. If the UE chooses this option, then it may periodically
attempt to select another PLMN and RAT combination that can provide non-EPS
services. How this periodic scanning is done, is UE implementation dependent.

If the the NB-IoT capability is disabled, the UE shall re-enable the NB-IoT
capability when:

- performing a PLMN selection unless the UE has already re-enabled the NB-IoT
capability when performing bullets c) or d) above; or

- the UE powers off and powers on again or the USIM is removed.

If the UE in NB-S1 mode receives an ATTACH REJECT or TRACKING AREA UPDATE REJECT
message including both EMM cause #15 “no suitable cells in tracking area” and
an Extended EMM cause IE with value “NB-IoT not allowed” after the UE requests
access to the NB-IoT, in order to prevent unwanted cell reselection from GERAN,
UTRAN, E-UTRAN or NG-RAN to NB-IoT, the UE may:

- disable the NB-IoT capability:

- indicate the access stratum layer(s) of disabling of the NB-IoT capability;
and

- memorize the identity of the PLMN where the NB-IoT capability was disabled and
use that stored information in subsequent PLMN selections as specified in 3GPP
TS 23.122 [6].

NOTE: The UE can only disable the NB-IoT capability when in EMM-IDLE mode.

If the UE in NB-S1 mode is required to disable the NB-IoT capability and select
E-UTRAN radio access technology, and the UE is in the EMM-CONNECTED mode, the UE
shall locally release the established NAS signalling connection and enter the
EMM-IDLE mode before selecting E-UTRAN radio access technology.

As an implementation option, the UE may start a timer for enabling the NB-IoT
capability. On expiry of this timer, the UE may enable the NB-IoT capability.