3GPP TS 23.501 V16.4.

0 (2020-03)
Technical Specification

3rd Generation Partnership Project;

Technical Specification Group Services and System Aspects;
System architecture for the 5G System (5GS);
Stage 2
(Release 16)

The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP.
The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented.
This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this Specification.
Specifications and Reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners' Publications Offices.
Release 16 2 3GPP TS 23.501 V16.4.0 (2020-03)

Keywords
3GPP, Architecture, 5G System, NextGen

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.

© 2020, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC).
All rights reserved.

UMTS™ is a Trade Mark of ETSI registered for the benefit of its members
3GPP™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners
LTE™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners
GSM® and the GSM logo are registered and owned by the GSM Association

3GPP
Release 16 3 3GPP TS 23.501 V16.4.0 (2020-03)

Contents
Foreword........................................................................................................................................................... 16
1 Scope ...................................................................................................................................................... 17
2 References .............................................................................................................................................. 17
3 Definitions and abbreviations................................................................................................................. 21
3.1 Definitions ....................................................................................................................................................... 21
3.2 Abbreviations ................................................................................................................................................... 26
4 Architecture model and concepts ........................................................................................................... 29
4.1 General concepts .............................................................................................................................................. 29
4.2 Architecture reference model ........................................................................................................................... 29
4.2.1 General ....................................................................................................................................................... 29
4.2.2 Network Functions and entities .................................................................................................................. 30
4.2.3 Non-roaming reference architecture ........................................................................................................... 30
4.2.4 Roaming reference architectures ................................................................................................................ 34
4.2.5 Data Storage architectures .......................................................................................................................... 37
4.2.5a Radio Capabilities Signalling optimisation ................................................................................................ 39
4.2.6 Service-based interfaces ............................................................................................................................. 40
4.2.7 Reference points ......................................................................................................................................... 40
4.2.8 Support of non-3GPP access ...................................................................................................................... 42
4.2.8.0 General ................................................................................................................................................. 42
4.2.8.1 General Concepts to Support Trusted and Untrusted Non-3GPP Access ............................................. 43
4.2.8.1A General Concepts to support Wireline Access...................................................................................... 44
4.2.8.2 Architecture Reference Model for Trusted and Untrusted Non-3GPP Accesses .................................. 45
4.2.8.2.1 Non-roaming Architecture .............................................................................................................. 45
4.2.8.2.2 LBO Roaming Architecture ............................................................................................................ 46
4.2.8.2.3 Home-routed Roaming Architecture ............................................................................................... 48
4.2.8.3 Reference Points for Non-3GPP Access ............................................................................................... 50
4.2.8.3.1 Overview......................................................................................................................................... 50
4.2.8.3.2 Requirements on Ta ........................................................................................................................ 51
4.2.8.4 Architecture Reference Model for Wireline Access network ............................................................... 51
4.2.8.5 Access to 5GC from devices that do not support 5GC NAS over WLAN access ................................ 52
4.2.8.5.1 General ............................................................................................................................................ 52
4.2.8.5.2 Reference Architecture ................................................................................................................... 53
4.2.8.5.3 Network Functions .......................................................................................................................... 53
4.2.8.5.4 Reference Points ............................................................................................................................. 53
4.2.9 Network Analytics architecture .................................................................................................................. 54
4.2.10 Architecture Reference Model for ATSSS Support ................................................................................... 54
4.3 Interworking with EPC .................................................................................................................................... 55
4.3.1 Non-roaming architecture .......................................................................................................................... 55
4.3.2 Roaming architecture ................................................................................................................................. 56
4.3.3 Interworking between 5GC via non-3GPP access and E-UTRAN connected to EPC ............................... 58
4.3.3.1 Non-roaming architecture ..................................................................................................................... 58
4.3.3.2 Roaming architecture ............................................................................................................................ 59
4.3.4 Interworking between ePDG connected to EPC and 5GS .......................................................................... 61
4.3.4.1 Non-roaming architecture ..................................................................................................................... 61
4.3.4.2 Roaming architectures .......................................................................................................................... 62
4.3.5 Service Exposure in Interworking Scenarios ............................................................................................. 64
4.3.5.1 Non-roaming architecture ..................................................................................................................... 64
4.3.5.2 Roaming architectures .......................................................................................................................... 65
4.4 Specific services .............................................................................................................................................. 66
4.4.1 Public Warning System .............................................................................................................................. 66
4.4.2 SMS over NAS ........................................................................................................................................... 66
4.4.2.1 Architecture to support SMS over NAS ............................................................................................... 66
4.4.2.2 Reference point to support SMS over NAS .......................................................................................... 68
4.4.2.3 Service based interface to support SMS over NAS .............................................................................. 68
4.4.3 IMS support................................................................................................................................................ 68
4.4.4 Location services ........................................................................................................................................ 68

3GPP
Release 16 4 3GPP TS 23.501 V16.4.0 (2020-03)

4.4.4.1 Architecture to support Location Services............................................................................................ 68

4.4.4.2 Reference point to support Location Services ...................................................................................... 68
4.4.4.3 Service Based Interfaces to support Location Services ........................................................................ 68
4.4.5 Application Triggering Services ................................................................................................................ 69
4.4.6 5G LAN-type Services ............................................................................................................................... 69
4.4.6.1 User plane architecture to support 5G LAN-type service ..................................................................... 69
4.4.6.2 Reference points to support 5G LAN-type service ............................................................................... 69
4.4.7 MSISDN-less MO SMS Service ................................................................................................................ 69
4.4.8 Time Sensitive Communication ................................................................................................................. 70
4.4.8.1 General ................................................................................................................................................. 70
4.4.8.2 Architecture to support Time Sensitive Communication ...................................................................... 70
5 High level features ................................................................................................................................. 71
5.1 General............................................................................................................................................................. 71
5.2 Network Access Control .................................................................................................................................. 71
5.2.1 General ....................................................................................................................................................... 71
5.2.2 Network selection....................................................................................................................................... 71
5.2.3 Identification and authentication ................................................................................................................ 72
5.2.4 Authorisation .............................................................................................................................................. 72
5.2.5 Access control and barring ......................................................................................................................... 72
5.2.6 Policy control ............................................................................................................................................. 73
5.2.7 Lawful Interception .................................................................................................................................... 73
5.3 Registration and Connection Management ...................................................................................................... 73
5.3.1 General ....................................................................................................................................................... 73
5.3.2 Registration Management .......................................................................................................................... 73
5.3.2.1 General ................................................................................................................................................. 73
5.3.2.2 5GS Registration Management states ................................................................................................... 73
5.3.2.2.1 General ............................................................................................................................................ 73
5.3.2.2.2 RM-DEREGISTERED state ........................................................................................................... 73
5.3.2.2.3 RM-REGISTERED state ................................................................................................................ 74
5.3.2.2.4 5GS Registration Management State models .................................................................................. 74
5.3.2.3 Registration Area management............................................................................................................. 75
5.3.2.4 Support of a UE registered over both 3GPP and Non-3GPP access ..................................................... 76
5.3.3 Connection Management ............................................................................................................................ 77
5.3.3.1 General ................................................................................................................................................. 77
5.3.3.2 5GS Connection Management states .................................................................................................... 78
5.3.3.2.1 General ............................................................................................................................................ 78
5.3.3.2.2 CM-IDLE state ............................................................................................................................... 78
5.3.3.2.3 CM-CONNECTED state ................................................................................................................ 78
5.3.3.2.4 5GS Connection Management State models ................................................................................... 79
5.3.3.2.5 CM-CONNECTED with RRC Inactive state .................................................................................. 79
5.3.3.3 NAS signalling connection management .............................................................................................. 81
5.3.3.3.1 General ............................................................................................................................................ 81
5.3.3.3.2 NAS signalling connection establishment ...................................................................................... 82
5.3.3.3.3 NAS signalling connection Release ................................................................................................ 82
5.3.3.4 Support of a UE connected over both 3GPP and Non-3GPP access .................................................... 82
5.3.4 UE Mobility ............................................................................................................................................... 82
5.3.4.1 Mobility Restrictions ............................................................................................................................ 82
5.3.4.1.1 General ............................................................................................................................................ 82
5.3.4.1.2 Management of Service Area Restrictions ...................................................................................... 84
5.3.4.2 Mobility Pattern .................................................................................................................................... 85
5.3.4.3 Radio Resource Management functions ............................................................................................... 86
5.3.4.4 UE mobility event notification ............................................................................................................. 86
5.4 3GPP access specific aspects ........................................................................................................................... 87
5.4.1 UE reachability in CM-IDLE ..................................................................................................................... 87
5.4.1.1 General ................................................................................................................................................. 87
5.4.1.2 UE reachability allowing mobile terminated data while the UE is CM-IDLE ..................................... 88
5.4.1.3 Mobile Initiated Connection Only (MICO) mode ................................................................................ 88
5.4.2 UE reachability in CM-CONNECTED ...................................................................................................... 89
5.4.3 Paging strategy handling ............................................................................................................................ 90
5.4.3.1 General ................................................................................................................................................. 90
5.4.3.2 Paging Policy Differentiation ............................................................................................................... 90

3GPP
Release 16 5 3GPP TS 23.501 V16.4.0 (2020-03)

5.4.3.3 Paging Priority ...................................................................................................................................... 91

5.4.4 UE Radio Capability handling ................................................................................................................... 91
5.4.4.1 UE radio capability information storage in the AMF ........................................................................... 91
5.4.4.1a UE radio capability signalling optimisation (RACS) ........................................................................... 92
5.4.4.2 Void ...................................................................................................................................................... 94
5.4.4.2a UE Radio Capability Match Request .................................................................................................... 94
5.4.4.3 Paging assistance information .............................................................................................................. 95
5.4.4a UE MM Core Network Capability handling .............................................................................................. 95
5.4.4b UE 5GSM Core Network Capability handling ........................................................................................... 96
5.4.5 DRX (Discontinuous Reception) framework ............................................................................................. 96
5.4.6 Core Network assistance information for RAN optimization .................................................................... 96
5.4.6.1 General ................................................................................................................................................. 96
5.4.6.2 Core Network assisted RAN parameters tuning ................................................................................... 97
5.4.6.3 Core Network assisted RAN paging information ................................................................................. 98
5.4.7 NG-RAN location reporting ....................................................................................................................... 98
5.4.8 Support for identification and restriction of using unlicensed spectrum .................................................... 98
5.4.9 Wake Up Signal Assistance ....................................................................................................................... 99
5.5 Non-3GPP access specific aspects ................................................................................................................. 100
5.5.0 General ..................................................................................................................................................... 100
5.5.1 Registration Management ........................................................................................................................ 100
5.5.2 Connection Management .......................................................................................................................... 100
5.5.3 UE Reachability ....................................................................................................................................... 102
5.5.3.1 UE reachability in CM-IDLE ............................................................................................................. 102
5.5.3.2 UE reachability in CM-CONNECTED .............................................................................................. 102
5.6 Session Management ..................................................................................................................................... 102
5.6.1 Overview .................................................................................................................................................. 102
5.6.2 Interaction between AMF and SMF ......................................................................................................... 105
5.6.3 Roaming ................................................................................................................................................... 107
5.6.4 Single PDU Session with multiple PDU Session Anchors ....................................................................... 108
5.6.4.1 General ............................................................................................................................................... 108
5.6.4.2 Usage of an UL Classifier for a PDU Session .................................................................................... 109
5.6.4.3 Usage of IPv6 multi-homing for a PDU Session ................................................................................ 110
5.6.5 Support for Local Area Data Network ..................................................................................................... 112
5.6.6 Secondary authentication/authorization by a DN-AAA server during the establishment of a PDU
Session ..................................................................................................................................................... 114
5.6.7 Application Function influence on traffic routing .................................................................................... 115
5.6.7.1 General ............................................................................................................................................... 115
5.6.7.2 Enhancement of UP path management based on the coordination with AFs ..................................... 120
5.6.8 Selective activation and deactivation of UP connection of existing PDU Session ................................... 121
5.6.9 Session and Service Continuity ................................................................................................................ 122
5.6.9.1 General ............................................................................................................................................... 122
5.6.9.2 SSC mode ........................................................................................................................................... 122
5.6.9.2.1 SSC Mode 1 .................................................................................................................................. 122
5.6.9.2.2 SSC Mode 2 .................................................................................................................................. 123
5.6.9.2.3 SSC Mode 3 .................................................................................................................................. 123
5.6.9.3 SSC mode selection ............................................................................................................................ 123
5.6.10 Specific aspects of different PDU Session types ...................................................................................... 124
5.6.10.1 Support of IP PDU Session type ......................................................................................................... 124
5.6.10.2 Support of Ethernet PDU Session type ............................................................................................... 124
5.6.10.3 Support of Unstructured PDU Session type ....................................................................................... 126
5.6.10.4 Maximum Transfer Unit size considerations ...................................................................................... 127
5.6.11 UE presence in Area of Interest reporting usage by SMF ........................................................................ 127
5.6.12 Use of Network Instance .......................................................................................................................... 129
5.6.13 Always-on PDU session ........................................................................................................................... 129
5.6.14 Support of Framed Routing ...................................................................................................................... 129
5.7 QoS model ..................................................................................................................................................... 130
5.7.1 General Overview .................................................................................................................................... 130
5.7.1.1 QoS Flow ............................................................................................................................................ 130
5.7.1.2 QoS Profile ......................................................................................................................................... 131
5.7.1.2a Alternative QoS Profile ...................................................................................................................... 131
5.7.1.3 Control of QoS Flows ......................................................................................................................... 131
5.7.1.4 QoS Rules ........................................................................................................................................... 132

3GPP
Release 16 6 3GPP TS 23.501 V16.4.0 (2020-03)

5.7.1.5 QoS Flow mapping ............................................................................................................................. 132

5.7.1.6 DL traffic ............................................................................................................................................ 134
5.7.1.7 UL Traffic ........................................................................................................................................... 134
5.7.1.8 AMBR/MFBR enforcement and rate limitation ................................................................................. 135
5.7.1.9 Precedence Value ............................................................................................................................... 135
5.7.2 5G QoS Parameters .................................................................................................................................. 135
5.7.2.1 5QI ...................................................................................................................................................... 135
5.7.2.2 ARP .................................................................................................................................................... 136
5.7.2.3 RQA.................................................................................................................................................... 136
5.7.2.4 Notification control ............................................................................................................................ 136
5.7.2.4.1 General .......................................................................................................................................... 136
5.7.2.4.1a Notification Control without Alternative QoS Profiles ................................................................. 137
5.7.2.4.1b Notification control with Alternative QoS Profiles ....................................................................... 137
5.7.2.4.2 Usage of Notification control with Alternative QoS Profiles at handover .................................... 138
5.7.2.5 Flow Bit Rates .................................................................................................................................... 139
5.7.2.6 Aggregate Bit Rates ............................................................................................................................ 139
5.7.2.7 Default values ..................................................................................................................................... 139
5.7.2.8 Maximum Packet Loss Rate ............................................................................................................... 140
5.7.2.9 Wireline access network specific 5G QoS parameters ....................................................................... 140
5.7.3 5G QoS characteristics ............................................................................................................................. 140
5.7.3.1 General ............................................................................................................................................... 140
5.7.3.2 Resource Type .................................................................................................................................... 141
5.7.3.3 Priority Level ...................................................................................................................................... 141
5.7.3.4 Packet Delay Budget .......................................................................................................................... 141
5.7.3.5 Packet Error Rate ................................................................................................................................ 142
5.7.3.6 Averaging Window ............................................................................................................................ 142
5.7.3.7 Maximum Data Burst Volume............................................................................................................ 143
5.7.4 Standardized 5QI to QoS characteristics mapping ................................................................................... 143
5.7.5 Reflective QoS ......................................................................................................................................... 147
5.7.5.1 General ............................................................................................................................................... 147
5.7.5.2 UE Derived QoS Rule ................................................................................................................... 148
5.7.5.3 Reflective QoS Control ...................................................................................................................... 148
5.7.6 Packet Filter Set ....................................................................................................................................... 149
5.7.6.1 General ............................................................................................................................................... 149
5.7.6.2 IP Packet Filter Set ............................................................................................................................. 150
5.7.6.3 Ethernet Packet Filter Set ................................................................................................................... 150
5.8 User Plane Management ................................................................................................................................ 151
5.8.1 General ..................................................................................................................................................... 151
5.8.2 Functional Description ............................................................................................................................. 151
5.8.2.1 General ............................................................................................................................................... 151
5.8.2.2 UE IP Address Management .............................................................................................................. 151
5.8.2.2.1 General .......................................................................................................................................... 151
5.8.2.2.2 Routing rules configuration .......................................................................................................... 153
5.8.2.2.3 The procedure of Stateless IPv6 Address Autoconfiguration ....................................................... 154
5.8.2.3 Management of CN Tunnel Info ......................................................................................................... 154
5.8.2.3.1 General .......................................................................................................................................... 154
5.8.2.3.2 Void .............................................................................................................................................. 154
5.8.2.3.3 Management of CN Tunnel Info in the UPF ................................................................................. 154
5.8.2.4 Traffic Detection ................................................................................................................................ 155
5.8.2.4.1 General .......................................................................................................................................... 155
5.8.2.4.2 Traffic Detection Information ....................................................................................................... 155
5.8.2.5 Control of User Plane Forwarding ...................................................................................................... 155
5.8.2.5.1 General .......................................................................................................................................... 155
5.8.2.5.2 Data forwarding between the SMF and UPF ................................................................................ 156
5.8.2.5.3 Support of Ethernet PDU Session type ......................................................................................... 156
5.8.2.6 Charging and Usage Monitoring Handling ......................................................................................... 157
5.8.2.6.1 General .......................................................................................................................................... 157
5.8.2.6.2 Activation of Usage Reporting in UPF ......................................................................................... 157
5.8.2.6.3 Reporting of Usage Information towards SMF ............................................................................. 158
5.8.2.7 PDU Session and QoS Flow Policing ................................................................................................. 158
5.8.2.8 PCC Related Functions ....................................................................................................................... 158
5.8.2.8.1 Activation/Deactivation of predefined PCC rules ......................................................................... 158

3GPP
Release 16 7 3GPP TS 23.501 V16.4.0 (2020-03)

5.8.2.8.2 Enforcement of Dynamic PCC Rules ........................................................................................... 159

5.8.2.8.3 Redirection .................................................................................................................................... 159
5.8.2.8.4 Support of PFD Management ....................................................................................................... 160
5.8.2.9 Functionality of Sending of "End marker" ......................................................................................... 160
5.8.2.9.0 Introduction ................................................................................................................................... 160
5.8.2.9.1 UPF Constructing the "End marker" Packets ................................................................................ 160
5.8.2.9.2 SMF Constructing the "End marker" Packets ............................................................................... 161
5.8.2.10 UP Tunnel Management ..................................................................................................................... 161
5.8.2.11 Parameters for N4 session management ............................................................................................. 161
5.8.2.11.1 General .......................................................................................................................................... 161
5.8.2.11.2 N4 Session Context ....................................................................................................................... 162
5.8.2.11.3 Packet Detection Rule ................................................................................................................... 163
5.8.2.11.4 QoS Enforcement Rule ................................................................................................................. 166
5.8.2.11.5 Usage Reporting Rule ................................................................................................................... 169
5.8.2.11.6 Forwarding Action Rule ............................................................................................................... 172
5.8.2.11.7 Usage Report generated by UPF ................................................................................................... 175
5.8.2.11.8 Multi-Access Rule ........................................................................................................................ 176
5.8.2.11.9 Bridge Management Information .................................................................................................. 177
5.8.2.11.10 Port Management Information Container ..................................................................................... 177
5.8.2.11.11 Session Reporting Rule ................................................................................................................. 177
5.8.2.11.12 Session reporting generated by UPF ............................................................................................. 178
5.8.2.12 Reporting of the UE MAC addresses used in a PDU Session ............................................................ 178
5.8.2.13 Support for 5G VN group communication ......................................................................................... 178
5.8.2.13.0 General .......................................................................................................................................... 178
5.8.2.13.1 Support for unicast traffic forwarding of a 5G VN ....................................................................... 179
5.8.2.13.2 Support for unicast traffic forwarding update due to UE mobility ............................................... 181
5.8.2.13.3 Support for user plane traffic replication in a 5G VN ................................................................... 181
5.8.2.14 Inter PLMN User Plane Security functionality ................................................................................... 183
5.8.3 Explicit Buffer Management .................................................................................................................... 183
5.8.3.1 General ............................................................................................................................................... 183
5.8.3.2 Buffering at UPF ................................................................................................................................ 183
5.8.3.3 Buffering at SMF ................................................................................................................................ 184
5.8.4 SMF Pause of Charging ........................................................................................................................... 184
5.9 Identifiers ....................................................................................................................................................... 184
5.9.1 General ..................................................................................................................................................... 184
5.9.2 Subscription Permanent Identifier ............................................................................................................ 184
5.9.2a Subscription Concealed Identifier ............................................................................................................ 185
5.9.3 Permanent Equipment Identifier .............................................................................................................. 185
5.9.4 5G Globally Unique Temporary Identifier ............................................................................................... 185
5.9.5 AMF Name............................................................................................................................................... 186
5.9.6 Data Network Name (DNN)..................................................................................................................... 186
5.9.7 Internal-Group Identifier .......................................................................................................................... 186
5.9.8 Generic Public Subscription Identifier ..................................................................................................... 187
5.9.9 AMF UE NGAP ID .................................................................................................................................. 187
5.9.10 UE Radio Capability ID ........................................................................................................................... 187
5.10 Security aspects ............................................................................................................................................. 188
5.10.1 General ..................................................................................................................................................... 188
5.10.2 Security Model for non-3GPP access ....................................................................................................... 188
5.10.2.1 Signalling Security ............................................................................................................................. 188
5.10.3 PDU Session User Plane Security ............................................................................................................ 188
5.11 Support for Dual Connectivity, Multi-Connectivity ...................................................................................... 190
5.11.1 Support for Dual Connectivity ................................................................................................................. 190
5.12 Charging ........................................................................................................................................................ 190
5.12.1 General ..................................................................................................................................................... 190
5.12.2 Usage Data Reporting for Secondary RAT .............................................................................................. 191
5.12.3 Secondary RAT Periodic Usage Data Reporting Procedure .................................................................... 191
5.13 Support for Edge Computing ......................................................................................................................... 191
5.14 Policy Control ................................................................................................................................................ 192
5.15 Network slicing .............................................................................................................................................. 192
5.15.1 General ..................................................................................................................................................... 192
5.15.2 Identification and selection of a Network Slice: the S-NSSAI and the NSSAI ........................................ 193
5.15.2.1 General ............................................................................................................................................... 193

3GPP
Release 16 8 3GPP TS 23.501 V16.4.0 (2020-03)

5.15.2.2 Standardised SST values .................................................................................................................... 194

5.15.3 Subscription aspects ................................................................................................................................. 194
5.15.4 UE NSSAI configuration and NSSAI storage aspects ............................................................................. 195
5.15.4.1 General ............................................................................................................................................... 195
5.15.4.1.1 UE Network Slice configuration ................................................................................................... 195
5.15.4.1.2 Mapping of S-NSSAIs values in the Allowed NSSAI and in the Requested NSSAI to the S-
NSSAIs values used in the HPLMN ............................................................................................. 197
5.15.4.2 Update of UE Network Slice configuration ........................................................................................ 197
5.15.5 Detailed Operation Overview ................................................................................................................... 198
5.15.5.1 General ............................................................................................................................................... 198
5.15.5.2 Selection of a Serving AMF supporting the Network Slices .............................................................. 198
5.15.5.2.1 Registration to a set of Network Slices ......................................................................................... 198
5.15.5.2.2 Modification of the Set of Network Slice(s) for a UE .................................................................. 202
5.15.5.2.3 AMF Re-allocation due to Network Slice(s) Support ................................................................... 204
5.15.5.3 Establishing a PDU Session in a Network Slice ................................................................................. 204
5.15.6 Network Slicing Support for Roaming ..................................................................................................... 205
5.15.7 Network slicing and Interworking with EPS ............................................................................................ 206
5.15.7.1 General ............................................................................................................................................... 206
5.15.7.2 Idle mode aspects ............................................................................................................................... 206
5.15.7.3 Connected mode aspects ..................................................................................................................... 206
5.15.8 Configuration of Network Slice availability in a PLMN ......................................................................... 207
5.15.9 Operator-controlled inclusion of NSSAI in Access Stratum Connection Establishment ......................... 207
5.15.10 Network Slice-Specific Authentication and Authorization ...................................................................... 208
5.16 Support for specific services .......................................................................................................................... 209
5.16.1 Public Warning System ............................................................................................................................ 209
5.16.2 SMS over NAS ......................................................................................................................................... 210
5.16.2.1 General ............................................................................................................................................... 210
5.16.2.2 SMS over NAS transport .................................................................................................................... 210
5.16.3 IMS support.............................................................................................................................................. 210
5.16.3.1 General ............................................................................................................................................... 210
5.16.3.2 IMS voice over PS Session Supported Indication over 3GPP access ................................................. 210
5.16.3.2a IMS voice over PS Session Supported Indication over non-3GPP access.......................................... 211
5.16.3.3 Homogeneous support for IMS voice over PS Session supported indication ..................................... 211
5.16.3.4 P-CSCF address delivery .................................................................................................................... 212
5.16.3.5 Domain selection for UE originating sessions / calls ......................................................................... 212
5.16.3.6 Terminating domain selection for IMS voice ..................................................................................... 213
5.16.3.7 UE's usage setting ............................................................................................................................... 213
5.16.3.8 Domain and Access Selection for UE originating SMS ..................................................................... 213
5.16.3.8.1 UE originating SMS for IMS Capable UEs supporting SMS over IP ........................................... 213
5.16.3.8.2 Access Selection for SMS over NAS ............................................................................................ 213
5.16.3.9 SMF support for P-CSCF restoration procedure ................................................................................ 214
5.16.3.10 IMS Voice Service via EPS Fallback or RAT fallback in 5GS .......................................................... 214
5.16.3.11 P-CSCF discovery and selection ........................................................................................................ 214
5.16.3.12 HSS discovery and selection .............................................................................................................. 215
5.16.4 Emergency Services ................................................................................................................................. 215
5.16.4.1 Introduction ........................................................................................................................................ 215
5.16.4.2 Architecture Reference Model for Emergency Services ..................................................................... 217
5.16.4.3 Mobility Restrictions and Access Restrictions for Emergency Services ............................................ 217
5.16.4.4 Reachability Management .................................................................................................................. 218
5.16.4.5 SMF and UPF selection function for Emergency Services................................................................. 218
5.16.4.6 QoS for Emergency Services .............................................................................................................. 218
5.16.4.7 PCC for Emergency Services ............................................................................................................. 218
5.16.4.8 IP Address Allocation ......................................................................................................................... 218
5.16.4.9 Handling of PDU Sessions for Emergency Services .......................................................................... 219
5.16.4.9a Handling of PDU Sessions for normal services for Emergency Registered UEs ............................... 219
5.16.4.10 Support of eCall Only Mode .............................................................................................................. 219
5.16.4.11 Emergency Services Fallback ............................................................................................................. 219
5.16.5 Multimedia Priority Services ................................................................................................................... 220
5.16.6 Mission Critical Services ......................................................................................................................... 221
5.17 Interworking and Migration ........................................................................................................................... 222
5.17.1 Support for Migration from EPC to 5GC ................................................................................................. 222
5.17.1.1 General ............................................................................................................................................... 222

3GPP
Release 16 9 3GPP TS 23.501 V16.4.0 (2020-03)

5.17.1.2 User Plane management to support interworking with EPS ............................................................... 224
5.17.2 Interworking with EPC............................................................................................................................. 224
5.17.2.1 General ............................................................................................................................................... 224
5.17.2.2 Interworking Procedures with N26 interface ...................................................................................... 227
5.17.2.2.1 General .......................................................................................................................................... 227
5.17.2.2.2 Mobility for UEs in single-registration mode ............................................................................... 228
5.17.2.3 Interworking Procedures without N26 interface ................................................................................. 229
5.17.2.3.1 General .......................................................................................................................................... 229
5.17.2.3.2 Mobility for UEs in single-registration mode ............................................................................... 230
5.17.2.3.3 Mobility for UEs in dual-registration mode .................................................................................. 230
5.17.2.3.4 Redirection for UEs in connected state ......................................................................................... 231
5.17.2.4 Mobility between 5GS and GERAN/UTRAN .................................................................................... 232
5.17.3 Interworking with EPC in presence of Non-3GPP PDU Sessions ........................................................... 232
5.17.4 Network sharing support and interworking between EPS and 5GS ......................................................... 232
5.17.5 Service Exposure in Interworking Scenarios ........................................................................................... 233
5.17.5.1 General ............................................................................................................................................... 233
5.17.5.2 Support of interworking for Monitoring Events ................................................................................. 233
5.17.5.2.1 Interworking with N26 interface ................................................................................................... 233
5.17.5.2.2 Interworking without N26 interface .............................................................................................. 234
5.17.5.3 Availability or expected level of a service API .................................................................................. 234
5.17.6 Void .......................................................................................................................................................... 234
5.17.7 Configuration Transfer Procedure between NG-RAN and E-UTRAN .................................................... 235
5.17.7.1 Architecture Principles for Configuration Transfer between NG-RAN and E-UTRAN .................... 235
5.17.7.2 Addressing, routing and relaying ........................................................................................................ 236
5.17.7.2.1 Addressing .................................................................................................................................... 236
5.17.7.2.2 Routing ......................................................................................................................................... 236
5.17.7.2.3 Relaying ........................................................................................................................................ 236
5.18 Network Sharing ............................................................................................................................................ 236
5.18.1 General concepts ...................................................................................................................................... 236
5.18.2 Broadcast system information for network sharing .................................................................................. 237
5.18.2a PLMN list handling for network sharing.................................................................................................. 237
5.18.3 Network selection by the UE.................................................................................................................... 238
5.18.4 Network selection by the network ............................................................................................................ 238
5.18.5 Network Sharing and Network Slicing .................................................................................................... 238
5.19 Control Plane Load Control, Congestion and Overload Control ................................................................... 239
5.19.1 General ..................................................................................................................................................... 239
5.19.2 TNLA Load Balancing and TNLA Load Re-Balancing........................................................................... 239
5.19.3 AMF Load Balancing ............................................................................................................................... 239
5.19.4 AMF Load Re-Balancing ......................................................................................................................... 239
5.19.5 AMF Control Of Overload ....................................................................................................................... 240
5.19.5.1 General ............................................................................................................................................... 240
5.19.5.2 AMF Overload Control ...................................................................................................................... 240
5.19.6 SMF Overload Control ............................................................................................................................. 241
5.19.7 NAS level congestion control................................................................................................................... 241
5.19.7.1 General ............................................................................................................................................... 241
5.19.7.2 General NAS level congestion control ............................................................................................... 241
5.19.7.3 DNN based congestion control ........................................................................................................... 243
5.19.7.4 S-NSSAI based congestion control .................................................................................................... 244
5.19.7.5 Group specific NAS level congestion control .................................................................................... 245
5.19.7.6 Control Plane data specific NAS level congestion control ................................................................. 245
5.20 External Exposure of Network Capability ..................................................................................................... 246
5.20a Data Collection from an AF ........................................................................................................................... 247
5.21 Architectural support for virtualized deployments ........................................................................................ 247
5.21.0 General ..................................................................................................................................................... 247
5.21.1 Architectural support for N2 .................................................................................................................... 248
5.21.1.1 TNL associations ................................................................................................................................ 248
5.21.1.2 NGAP UE-TNLA-binding ................................................................................................................. 248
5.21.1.3 N2 TNL association selection ............................................................................................................. 248
5.21.2 AMF Management ................................................................................................................................... 248
5.21.2.1 AMF Addition/Update ........................................................................................................................ 248
5.21.2.2 AMF planned removal procedure ....................................................................................................... 249
5.21.2.2.1 AMF planned removal procedure with UDSF deployed............................................................... 249

3GPP
Release 16 10 3GPP TS 23.501 V16.4.0 (2020-03)

5.21.2.2.2 AMF planned removal procedure without UDSF ......................................................................... 251

5.21.2.3 Procedure for AMF Auto-recovery .................................................................................................... 252
5.21.3 Network Reliability support with Sets ..................................................................................................... 254
5.21.3.1 General ............................................................................................................................................... 254
5.21.3.2 NF Set and NF Service Set ................................................................................................................. 254
5.21.3.3 Reliability of NF instances within the same NF Set ........................................................................... 254
5.21.3.4 Reliability of NF Services .................................................................................................................. 254
5.21.4 Network Function/NF Service Context Transfer...................................................................................... 255
5.21.4.1 General ............................................................................................................................................... 255
5.22 System Enablers for priority mechanism ....................................................................................................... 255
5.22.1 General ..................................................................................................................................................... 255
5.22.2 Subscription-related Priority Mechanisms ............................................................................................... 255
5.22.3 Invocation-related Priority Mechanisms .................................................................................................. 256
5.22.4 QoS Mechanisms applied to established QoS Flows ............................................................................... 257
5.23 Supporting for Asynchronous Type Communication .................................................................................... 257
5.24 3GPP PS Data Off ......................................................................................................................................... 258
5.25 Support of OAM Features .............................................................................................................................. 259
5.25.1 Support of Tracing: Signalling Based Activation/Deactivation of Tracing.............................................. 259
5.25.2 Support of OAM-based 5G VN group management ................................................................................ 259
5.26 Configuration Transfer Procedure ................................................................................................................. 260
5.26.1 Architecture Principles for Configuration Transfer .................................................................................. 260
5.26.2 Addressing, routing and relaying ............................................................................................................. 260
5.26.2.1 Addressing .......................................................................................................................................... 260
5.26.2.2 Routing ............................................................................................................................................... 261
5.26.2.3 Relaying.............................................................................................................................................. 261
5.27 Time Sensitive Communications ................................................................................................................... 261
5.27.0 General ..................................................................................................................................................... 261
5.27.1 TSN Time Synchronization ...................................................................................................................... 261
5.27.1.1 General ............................................................................................................................................... 261
5.27.1.2 Distribution of timing information ..................................................................................................... 262
5.27.1.2.1 Distribution of 5G internal system clock ...................................................................................... 262
5.27.1.2.2 Distribution of TSN clock and time-stamping .............................................................................. 262
5.27.1.3 Support for multiple TSN working domains ...................................................................................... 263
5.27.1a Periodic deterministic QoS ....................................................................................................................... 263
5.27.2 TSC Assistance Information (TSCAI) ..................................................................................................... 264
5.27.3 Support for TSC QoS Flows .................................................................................................................... 265
5.27.4 Hold and Forward Buffering mechanism ................................................................................................. 265
5.27.5 5G System Bridge delay ........................................................................................................................... 265
5.28 Support of integration with TSN.................................................................................................................... 266
5.28.1 5GS TSN bridge management .................................................................................................................. 266
5.28.2 5GS Bridge configuration ........................................................................................................................ 267
5.28.3 Port management information exchange in 5GS ...................................................................................... 268
5.28.3.1 General ............................................................................................................................................... 268
5.28.3.2 Transfer of port management information .......................................................................................... 272
5.28.4 QoS mapping tables ................................................................................................................................. 272
5.29 Support for 5G LAN-type service .................................................................................................................. 273
5.29.1 General ..................................................................................................................................................... 273
5.29.2 5G VN group management ...................................................................................................................... 274
5.29.3 PDU Session management ....................................................................................................................... 275
5.29.4 User Plane handling ................................................................................................................................. 275
5.30 Support for non-public networks ................................................................................................................... 276
5.30.1 General ..................................................................................................................................................... 276
5.30.2 Stand-alone non-public networks ............................................................................................................. 277
5.30.2.1 Identifiers ............................................................................................................................................ 277
5.30.2.2 Broadcast system information ............................................................................................................ 277
5.30.2.3 UE configuration and subscription aspects ......................................................................................... 277
5.30.2.4 Network selection in SNPN access mode ........................................................................................... 278
5.30.2.5 Network access control ....................................................................................................................... 278
5.30.2.6 Cell (re-)selection in SNPN access mode ........................................................................................... 278
5.30.2.7 Access to PLMN services via stand-alone non-public networks ........................................................ 279
5.30.2.8 Access to stand-alone non-public network services via PLMN ......................................................... 279
5.30.3 Public Network Integrated NPN............................................................................................................... 280

3GPP
Release 16 11 3GPP TS 23.501 V16.4.0 (2020-03)

5.30.3.1 General ............................................................................................................................................... 280

5.30.3.2 Identifiers ............................................................................................................................................ 280
5.30.3.3 UE configuration, subscription aspects and storage ........................................................................... 280
5.30.3.4 Network and cell (re-)selection, and access control ........................................................................... 281
5.30.3.5 Support of emergency services in CAG cells ..................................................................................... 282
5.31 Support for Cellular IoT ................................................................................................................................ 282
5.31.1 General ..................................................................................................................................................... 282
5.31.2 Preferred and Supported Network Behaviour .......................................................................................... 283
5.31.3 Selection, steering and redirection between EPS and 5GS....................................................................... 284
5.31.4 Control Plane CIoT 5GS Optimisation..................................................................................................... 284
5.31.4.1 General .......................................................................................................................................... 284
5.31.4.2 Establishment of N3 data transfer during Data Transport in Control Plane CIoT 5GS
Optimisation.................................................................................................................................. 285
5.31.4.3 Control Plane Relocation Indication procedure ............................................................................ 286
5.31.5 Non-IP Data Delivery (NIDD) ................................................................................................................. 286
5.31.6 Reliable Data Service ............................................................................................................................... 286
5.31.7 Power Saving Enhancements ................................................................................................................... 287
5.31.7.1 General ............................................................................................................................................... 287
5.31.7.2 Extended Discontinuous Reception (DRX) for CM-IDLE and CM-CONNECTED with RRC-
INACTIVE ......................................................................................................................................... 287
5.31.7.2.1 Overview....................................................................................................................................... 287
5.31.7.2.2 Paging for extended idle mode DRX in E-UTRA connected to 5GC ........................................... 289
5.31.7.2.3 Paging for a UE registered in a tracking area with heterogeneous support of extended idle
mode DRX .................................................................................................................................... 290
5.31.7.3 MICO mode with Extended Connected Time .................................................................................... 290
5.31.7.4 MICO mode with Active Time ........................................................................................................... 290
5.31.7.5 MICO mode and Periodic Registration Timer Control ....................................................................... 290
5.31.8 High latency communication.................................................................................................................... 291
5.31.9 Support for Monitoring Events................................................................................................................. 292
5.31.10 NB-IoT UE Radio Capability Handling ................................................................................................... 292
5.31.11 Inter-RAT idle mode mobility to and from NB-IoT................................................................................. 292
5.31.12 Restriction of use of Enhanced Coverage ................................................................................................ 292
5.31.13 Paging for Enhanced Coverage ................................................................................................................ 293
5.31.14 Support of rate control of user data .......................................................................................................... 294
5.31.14.1 General ............................................................................................................................................... 294
5.31.14.2 Serving PLMN Rate Control .............................................................................................................. 294
5.31.14.3 Small Data Rate Control ..................................................................................................................... 295
5.31.15 Control Plane Data Transfer Congestion Control..................................................................................... 296
5.31.16 Service Gap Control ................................................................................................................................. 296
5.31.17 Inter-UE QoS for NB-IoT ........................................................................................................................ 298
5.31.18 User Plane CIoT 5GS Optimisation ......................................................................................................... 298
5.31.19 QoS model for NB-IoT ............................................................................................................................ 299
5.31.20 Category M UEs differentiation ............................................................................................................... 299
5.32 Support for ATSSS ........................................................................................................................................ 300
5.32.1 General ..................................................................................................................................................... 300
5.32.2 Multi Access PDU Sessions ..................................................................................................................... 300
5.32.3 Policy for ATSSS Control ........................................................................................................................ 303
5.32.4 QoS Support ............................................................................................................................................. 303
5.32.5 Access Network Performance Measurements .......................................................................................... 304
5.32.5.1 General principles ............................................................................................................................... 304
5.32.5.2 Round Trip Time Measurements ........................................................................................................ 305
5.32.5.3 Access Availability/Unavailability Report ......................................................................................... 306
5.32.5.4 Protocol stack for user plane measurements and measurement reports .............................................. 306
5.32.6 Support of Steering Functionalities .......................................................................................................... 307
5.32.6.1 General ............................................................................................................................................... 307
5.32.6.2 High-Layer Steering Functionalities ................................................................................................... 309
5.32.6.2.1 MPTCP Functionality ................................................................................................................... 309
5.32.6.3 Low-Layer Steering Functionalities ................................................................................................... 310
5.32.6.3.1 ATSSS-LL Functionality .............................................................................................................. 310
5.32.7 Interworking with EPS ............................................................................................................................. 310
5.32.7.1 General ............................................................................................................................................... 310
5.32.7.2 Interworking with N26 Interface ........................................................................................................ 310

3GPP
Release 16 12 3GPP TS 23.501 V16.4.0 (2020-03)

5.32.7.3 Interworking without N26 Interface ................................................................................................... 311

5.32.8 ATSSS Rules ............................................................................................................................................ 311
5.33 Support for Ultra Reliable Low Latency Communication ............................................................................. 313
5.33.1 General ..................................................................................................................................................... 313
5.33.2 Redundant transmission for high reliability communication .................................................................... 314
5.33.2.1 Dual Connectivity based end to end Redundant User Plane Paths ..................................................... 314
5.33.2.2 Support of redundant transmission on N3/N9 interfaces .................................................................... 316
5.33.2.3 Support for redundant transmission at transport layer ........................................................................ 317
5.33.3 QoS Monitoring to Assist URLLC Service .............................................................................................. 318
5.33.3.1 General ............................................................................................................................................... 318
5.33.3.2 Per QoS Flow per UE QoS Monitoring .............................................................................................. 318
5.33.3.3 GTP-U Path Monitoring ..................................................................................................................... 319
5.34 Support of deployments topologies with specific SMF Service Areas .......................................................... 320
5.34.1 General ..................................................................................................................................................... 320
5.34.2 Architecture .............................................................................................................................................. 320
5.34.2.1 SBA architecture ................................................................................................................................ 320
5.34.2.2 Non-roaming architecture ................................................................................................................... 320
5.34.2.3 Roaming architecture .......................................................................................................................... 321
5.34.3 I-SMF selection, V-SMF reselection........................................................................................................ 322
5.34.4 Usage of an UL Classifier for a PDU Session controlled by I-SMF ........................................................ 323
5.34.5 Usage of IPv6 multi-homing for a PDU Session controlled by I-SMF .................................................... 324
5.34.6 Interaction between I-SMF and SMF for the support of traffic offload by UPF controlled by the I-
SMF .......................................................................................................................................................... 324
5.34.6.1 General ............................................................................................................................................... 324
5.34.6.2 N4 information sent from SMF to I-SMF for local traffic offload ..................................................... 325
5.34.7 Event Management ................................................................................................................................... 325
5.34.7.1 UE's Mobility Event Management ..................................................................................................... 325
5.34.7.2 SMF event exposure service ............................................................................................................... 326
5.34.7.3 AMF implicit subscription about events related with the PDU Session ............................................. 326
5.34.8 Support for Cellular IoT ........................................................................................................................... 326
5.35 Support for Integrated access and backhaul (IAB) ........................................................................................ 327
5.35.1 IAB architecture and functional entities ................................................................................................... 327
5.35.2 5G System enhancements to support IAB ................................................................................................ 328
5.35.3 Data handling and QoS support with IAB ................................................................................................ 328
5.35.4 Mobility support with IAB ....................................................................................................................... 329
5.35.5 Charging support with IAB ...................................................................................................................... 329
5.35.6 IAB operation involving EPC .................................................................................................................. 329
5.36 RIM Information Transfer ............................................................................................................................. 329
6 Network Functions ............................................................................................................................... 329
6.1 General........................................................................................................................................................... 329
6.2 Network Function Functional description...................................................................................................... 329
6.2.1 AMF ......................................................................................................................................................... 329
6.2.2 SMF .......................................................................................................................................................... 331
6.2.3 UPF .......................................................................................................................................................... 332
6.2.4 PCF........................................................................................................................................................... 332
6.2.5 NEF .......................................................................................................................................................... 333
6.2.5.1 Support for CAPIF ............................................................................................................................. 334
6.2.5a Intermediate NEF ..................................................................................................................................... 334
6.2.6 NRF .......................................................................................................................................................... 334
6.2.7 UDM ........................................................................................................................................................ 336
6.2.8 AUSF ....................................................................................................................................................... 337
6.2.9 N3IWF ..................................................................................................................................................... 337
6.2.9A TNGF ....................................................................................................................................................... 337
6.2.10 AF ............................................................................................................................................................ 337
6.2.11 UDR ......................................................................................................................................................... 338
6.2.12 UDSF ....................................................................................................................................................... 338
6.2.13 SMSF ....................................................................................................................................................... 338
6.2.14 NSSF ........................................................................................................................................................ 339
6.2.15 5G-EIR ..................................................................................................................................................... 339
6.2.16 LMF ......................................................................................................................................................... 339
6.2.16A GMLC ...................................................................................................................................................... 339

3GPP
Release 16 13 3GPP TS 23.501 V16.4.0 (2020-03)

6.2.17 SEPP......................................................................................................................................................... 339

6.2.18 Network Data Analytics Function (NWDAF) .......................................................................................... 339
6.2.19 SCP........................................................................................................................................................... 340
6.2.20 W-AGF..................................................................................................................................................... 340
6.2.21 UE radio Capability Management Function (UCMF) .............................................................................. 340
6.2.22 TWIF ........................................................................................................................................................ 341
6.3 Principles for Network Function and Network Function Service discovery and selection ............................ 341
6.3.1 General ..................................................................................................................................................... 341
6.3.1.0 Principles for Binding, Selection and Reselection .............................................................................. 342
6.3.1.1 NF Discovery and Selection aspects relevant with indirect communication ...................................... 344
6.3.1.2 Location information .......................................................................................................................... 344
6.3.2 SMF discovery and selection ................................................................................................................... 345
6.3.3 User Plane Function Selection ................................................................................................................. 347
6.3.3.1 Overview ............................................................................................................................................ 347
6.3.3.2 SMF Provisioning of available UPF(s) ............................................................................................... 347
6.3.3.3 Selection of an UPF for a particular PDU Session ............................................................................. 347
6.3.4 AUSF discovery and selection ................................................................................................................. 349
6.3.5 AMF discovery and selection ................................................................................................................... 349
6.3.6 N3IWF selection ...................................................................................................................................... 351
6.3.6.1 General ............................................................................................................................................... 351
6.3.6.2 Stand-alone N3IWF selection ............................................................................................................. 352
6.3.6.3 Combined N3IWF/ePDG Selection .................................................................................................... 352
6.3.6.4 PLMN Selection for emergency services ........................................................................................... 353
6.3.7 PCF discovery and selection .................................................................................................................... 354
6.3.7.0 General principles ............................................................................................................................... 354
6.3.7.1 PCF discovery and selection for a UE or a PDU Session ................................................................... 354
6.3.7.2 Providing policy requirements that apply to multiple UE and hence to multiple PCF ....................... 356
6.3.7.3 Binding an AF request targeting a UE address to the relevant PCF ................................................... 357
6.3.8 UDM discovery and selection .................................................................................................................. 357
6.3.9 UDR discovery and selection ................................................................................................................... 357
6.3.10 SMSF discovery and selection ................................................................................................................. 358
6.3.11 CHF discovery and selection .................................................................................................................... 358
6.3.12 Trusted Non-3GPP Access Network selection ......................................................................................... 359
6.3.12.1 General ............................................................................................................................................... 359
6.3.12.2 Access Network Selection Procedure ................................................................................................. 361
6.3.12a Access Network selection for devices that do not support 5GC NAS over WLAN ................................. 363
6.3.12a.1 General ............................................................................................................................................... 363
6.3.12a.2 Access Network Selection Procedure ................................................................................................. 363
6.3.13 NWDAF discovery and selection ............................................................................................................. 364
6.3.14 NEF Discovery ......................................................................................................................................... 365
6.3.15 UCMF Discovery and Selection............................................................................................................... 365
7 Network Function Services and descriptions ....................................................................................... 365
7.1 Network Function Service Framework .......................................................................................................... 365
7.1.1 General ..................................................................................................................................................... 365
7.1.2 NF Service Consumer - NF Service Producer interactions ...................................................................... 366
7.1.3 Network Function Service discovery ....................................................................................................... 368
7.1.4 Network Function Service Authorization ................................................................................................. 368
7.1.5 Network Function and Network Function Service registration and de-registration ................................. 369
7.2 Network Function Services ............................................................................................................................ 369
7.2.1 General ..................................................................................................................................................... 369
7.2.2 AMF Services........................................................................................................................................... 370
7.2.3 SMF Services ........................................................................................................................................... 371
7.2.4 PCF Services ............................................................................................................................................ 371
7.2.5 UDM Services .......................................................................................................................................... 372
7.2.6 NRF Services ........................................................................................................................................... 373
7.2.7 AUSF Services ......................................................................................................................................... 373
7.2.8 NEF Services ............................................................................................................................................ 374
7.2.8A I-NEF Services ......................................................................................................................................... 375
7.2.9 SMSF Services ......................................................................................................................................... 376
7.2.10 UDR Services ........................................................................................................................................... 376
7.2.11 5G-EIR Services....................................................................................................................................... 376

3GPP
Release 16 14 3GPP TS 23.501 V16.4.0 (2020-03)

7.2.12 NWDAF Services..................................................................................................................................... 376

7.2.13 UDSF Services ......................................................................................................................................... 377
7.2.14 NSSF Services .......................................................................................................................................... 377
7.2.15 BSF Services ............................................................................................................................................ 377
7.2.16 LMF Services ........................................................................................................................................... 377
7.2.16A GMLC Services ........................................................................................................................................ 377
7.2.17 CHF Services ........................................................................................................................................... 378
7.2.18 UCMF Services ........................................................................................................................................ 378
7.2.19 AF Services .............................................................................................................................................. 378
7.3 Exposure ........................................................................................................................................................ 379
8 Control and User Plane Protocol Stacks............................................................................................... 379
8.1 General........................................................................................................................................................... 379
8.2 Control Plane Protocol Stacks ....................................................................................................................... 379
8.2.1 Control Plane Protocol Stacks between the 5G-AN and the 5G Core: N2 ............................................... 379
8.2.1.1 General ............................................................................................................................................... 379
8.2.1.2 AN - AMF .......................................................................................................................................... 380
8.2.1.3 AN - SMF ........................................................................................................................................... 380
8.2.2 Control Plane Protocol Stacks between the UE and the 5GC .................................................................. 381
8.2.2.1 General ............................................................................................................................................... 381
8.2.2.2 UE - AMF ........................................................................................................................................... 382
8.2.2.3 UE – SMF ........................................................................................................................................... 382
8.2.3 Control Plane Protocol Stacks between the network functions in 5GC ................................................... 383
8.2.3.1 The Control Plane Protocol Stack for the service based interface ...................................................... 383
8.2.3.2 The Control Plane protocol stack for the N4 interface between SMF and UPF ................................. 383
8.2.4 Control Plane for untrusted non 3GPP Access ......................................................................................... 384
8.2.5 Control Plane for trusted non-3GPP Access ............................................................................................ 385
8.2.6 Control Plane for W-5GAN Access ......................................................................................................... 385
8.3 User Plane Protocol Stacks ............................................................................................................................ 385
8.3.1 User Plane Protocol Stack for a PDU Session .......................................................................................... 385
8.3.2 User Plane for untrusted non-3GPP Access ............................................................................................. 387
8.3.3 User Plane for trusted non-3GPP Access ................................................................................................. 387
8.3.4 User Plane for W-5GAN Access .............................................................................................................. 387
8.3.5 User Plane for N19-based forwarding of a 5G VN group ........................................................................ 388

Annex A (informative): Relationship between Service-Based Interfaces and Reference Points ........... 389
Annex B (normative): Mapping between temporary identities ................................................................ 391
Annex C (informative): Guidelines and Principles for Compute-Storage Separation ........................... 392
Annex D (informative): 5GS support for Non-Public Network deployment options ............................. 393
D.1 Introduction .......................................................................................................................................... 393
D.2 Support of Non-Public Network as a network slice of a PLMN .......................................................... 393
D.3 Support for access to PLMN services via Stand-alone Non-Public Network and access to Stand-
alone Non Public Network services via PLMN ................................................................................... 394
D.4 Support for UE capable of simultaneously connecting to an SNPN and a PLMN .............................. 395
Annex E (informative): Communication models for NF/NF services interaction .................................. 396
E.1 General ................................................................................................................................................. 396
Annex F (informative): Redundant user plane paths based on multiple UEs per device ...................... 398
Annex G (informative): SCP Deployment Examples ................................................................................ 401
G.1 General ................................................................................................................................................. 401
G.2 An SCP based on service mesh ............................................................................................................ 401
G.2.1 Introduction.................................................................................................................................................... 401
G.2.2 Communication across service mesh boundaries ........................................................................................... 402

3GPP
Release 16 15 3GPP TS 23.501 V16.4.0 (2020-03)

G.3 An SCP based on independent deployment units ................................................................................. 403

G.4 An SCP deployment example based on name-based routing ............................................................... 404
G.4.0 General Information ....................................................................................................................................... 404
G.4.1 Service Registration and Service Discovery .................................................................................................. 405
G.4.2 Overview of Deployment Scenario ................................................................................................................ 406
G.4.3 References...................................................................................................................................................... 406

Annex H (normative): TSN usage guidelines ............................................................................................. 407

H.1 General ................................................................................................................................................. 407
H.2 Signalling of ingress time for time synchronization ............................................................................ 407
Annex I (normative): TSN usage guidelines............................................................................................... 408
I.1 Determination of traffic pattern information ........................................................................................ 408
Annex J (informative): Link MTU considerations .................................................................................... 409
Annex K (informative): Change history ..................................................................................................... 411

3GPP
Release 16 16 3GPP TS 23.501 V16.4.0 (2020-03)

Foreword
This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP).

The contents of the present document are subject to continuing work within the TSG and may change following formal
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an
identifying change of release date and an increase in version number as follows:

Version x.y.z

where:

x the first digit:

1 presented to TSG for information;

2 presented to TSG for approval;

3 or greater indicates TSG approved document under change control.

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
updates, etc.

z the third digit is incremented when editorial only changes have been incorporated in the document.

3GPP
Release 16 17 3GPP TS 23.501 V16.4.0 (2020-03)

1 Scope
The present document defines the Stage 2 system architecture for the 5G System. The 5G System provides data
connectivity and services.

This specification covers both roaming and non-roaming scenarios in all aspects, including interworking between 5GS
and EPS, mobility within 5GS, QoS, policy control and charging, authentication and in general 5G System wide
features e.g. SMS, Location Services, Emergency Services.

ITU-T Recommendation I.130 [11] describes a three-stage method for characterisation of telecommunication services,
and ITU-T Recommendation Q.65 [12] defines Stage 2 of the method.

TS 23.502 [3] contains the stage 2 procedures and flows for 5G System and it is a companion specification to this
specification.

TS 23.503 [45] contains the stage 2 Policy Control and Charging architecture for 5G System and it is a companion
specification to this specification.

2 References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.

- References are either specific (identified by date of publication, edition number, version number, etc.) or
non-specific.

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

- For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same
Release as the present document.

[1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications".

[2] 3GPP TS 22.261: "Service requirements for next generation new services and markets; Stage 1".

[3] 3GPP TS 23.502: "Procedures for the 5G System; Stage 2".

[4] 3GPP TS 23.203: "Policies and Charging control architecture; Stage 2".

[5] 3GPP TS 23.040: "Technical realization of the Short Message Service (SMS); Stage 2".

[6] 3GPP TS 24.011: "Point-to-Point (PP) Short Message Service (SMS) support on mobile radio
interface: Stage 3".

[7] IETF RFC 7157: "IPv6 Multihoming without Network Address Translation".

[8] IETF RFC 4191: "Default Router Preferences and More-Specific Routes".

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

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

[11] ITU-T Recommendation I.130: "Method for the characterization of telecommunication services
supported by an ISDN and network capabilities of an ISDN".

[12] ITU-T Recommendation Q.65: "The unified functional methodology for the characterization of
services and network capabilities".

[13] 3GPP TS 24.301: "Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS):
Stage 3".

[14] IETF RFC 3736: "Stateless DHCP Service for IPv6".

3GPP
Release 16 18 3GPP TS 23.501 V16.4.0 (2020-03)

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

[16] 3GPP TS 22.173: "IMS Multimedia Telephony Service and supplementary services; Stage 1".

[17] 3GPP TS 23.122: "Non-Access-Stratum (NAS) functions related to Mobile Station in idle mode".

[18] 3GPP TS 23.167: "3rd Generation Partnership Project; Technical Specification Group Services
and Systems Aspects; IP Multimedia Subsystem (IMS) emergency sessions".

[19] 3GPP TS 23.003: "Numbering, Addressing and Identification".

[20] IETF RFC 7542: "The Network Access Identifier".

[21] 3GPP TS 23.002: "Network Architecture".

[22] 3GPP TS 23.335: "User Data Convergence (UDC); Technical realization and information flows;
Stage 2".

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

[24] 3GPP TS 22.153: "Multimedia priority service".

[25] 3GPP TS 22.011: "Service Accessibility".

[26] 3GPP TS 23.401: "General Packet Radio Service (GPRS) enhancements for Evolved Universal
Terrestrial Radio Access Network (E-UTRAN) access".

[27] 3GPP TS 38.300: "NR; NR and NG-RAN Overall Description".

[28] 3GPP TS 38.331: "NR; Radio Resource Control (RRC); Protocol Specification".

[29] 3GPP TS 33.501: "Security architecture and procedures for 5G system".

[30] 3GPP TS 36.300: "Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal
Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2".

[31] 3GPP TS 37.340: "Evolved Universal Terrestrial Radio Access (E-UTRA) and NR; Multi-
connectivity; Stage 2".

[32] 3GPP TS 23.214: "Architecture enhancements for control and user plane separation of EPC nodes;
Stage 2".

[33] 3GPP TS 22.101: "3rd Generation Partnership Project; Technical Specification Group Services
and Systems Aspects; Service aspects; Service principles".

[34] 3GPP TS 38.413: "NG-RAN; NG Application Protocol (NGAP)".

[35] 3GPP TS 33.126: "Lawful Interception Requirements".

[36] 3GPP TS 23.682: "Architecture enhancements to facilitate communications with packet data
networks and applications".

[37] 3GPP TS 22.280: "Mission Critical Services Common Requirements (MCCoRe); Stage 1".

[38] 3GPP TS 23.379: "Functional architecture and information flows to support Mission Critical Push
To Talk (MCPTT); Stage 2".

[39] 3GPP TS 23.281: "Functional architecture and information flows to support Mission Critical
Video (MCVideo); Stage 2".

[40] 3GPP TS 23.282: "Functional architecture and information flows to support Mission Critical Data
(MCData); Stage 2".

[41] 3GPP TS 32.240: "Charging management; Charging architecture and principles".

[42] 3GPP TS 38.401: "NG-RAN Architecture description".

[43] 3GPP TS 23.402: "Architecture enhancements for non-3GPP accesses".

3GPP
Release 16 19 3GPP TS 23.501 V16.4.0 (2020-03)

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

[45] 3GPP TS 23.503: "Policy and Charging Control Framework for the 5G System".

[46] 3GPP TS 23.041: "Public Warning System".

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

[48] 3GPP TS 24.502: "Access to the 5G System (5GS) via non-3GPP access networks; Stage 3".

[49] 3GPP TS 29.500: "5G System; Technical Realization of Service Based Architecture; Stage 3".

[50] 3GPP TS 38.304: "NR; User Equipment (UE) procedures in idle mode".

[51] 3GPP TS 36.331: "Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource
Control (RRC); Protocol specification".

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

[53] Void.

[54] IETF RFC 4861: "Neighbor Discovery for IP version 6 (IPv6)".

[55] 3GPP TS 23.271: "Functional stage 2 description of Location Services (LCS)".

[56] 3GPP TS 23.060: "General Packet Radio Service (GPRS); Service description; Stage 2".

[57] IETF RFC 4555: "IKEv2 Mobility and Multihoming Protocol (MOBIKE)".

[58] 3GPP TS 29.510: "5G System: Network function repository services; Stage 3".

[59] 3GPP TS 29.502: "5G System: Session Management Services: Stage 3".

[60] IETF RFC 7296: "Internet Key Exchange Protocol Version 2 (IKEv2) ".

[61] 3GPP TS 23.380: "IMS Restoration Procedures".

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

[63] 3GPP TS 23.292: "IP Multimedia Subsystem (IMS) centralized services; Stage 2".

[64] 3GPP TS 23.222: "Functional architecture and information flows to support Common API
Framework for 3GPP Northbound APIs".

[65] 3GPP TS 29.244: "Interface between the Control Plane and the User Plane Nodes; Stage 3".

[66] 3GPP TS 32.421: "Telecommunication management; Subscriber and equipment trace; Trace
concepts and requirements".

[67] 3GPP TS 32.290: "5G system; Services, operations and procedures of charging using Service
Based Interface (SBI)".

[68] 3GPP TS 32.255: "5G Data connectivity domain charging; Stage 2".

[69] 3GPP TS 38.306: "NR; User Equipment -UE) radio access capabilities".

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

[71] 3GPP TS 29.518: "5G System; Access and Mobility Management Services; Stage 3".

[72] 3GPP TS 23.285: "Architecture enhancements for V2X services".

[73] IETF RFC 2865: "Remote Authentication Dial In User Service (RADIUS)".

[74] IETF RFC 3162: "RADIUS and IPv6".

3GPP
Release 16 20 3GPP TS 23.501 V16.4.0 (2020-03)

[75] 3GPP TS 29.281: "General Packet Radio System (GPRS) Tunnelling Protocol User Plane
(GTPv1-U)".

[76] 3GPP TS 26.238: "Uplink streaming".

[77] 3GPP TR 26.939: "Guidelines on the Framework for Live Uplink Streaming (FLUS)".

[78] International Telecommunication Union (ITU), Standardization Bureau (TSB): "Operational

Bulletin No. 1156"; http://handle.itu.int/11.1002/pub/810cad63-en (retrieved October 5, 2018).

[79] 3GPP TS 28.533: "Management and orchestration; Architecture framework".

[80] 3GPP TS 24.250: "Protocol for Reliable Data Service; Stage 3".

[81] draft-ietf-mptcp-rfc6824bis-18: "TCP Extensions for Multipath Operation with Multiple

Addresses".

Editor's note: The above document cannot be formally referenced until it is published as an RFC.

[82] draft-ietf-tcpm-converters-14: "0-RTT TCP Convert Protocol".

Editor's note: The above document cannot be formally referenced until it is published as an RFC.

[83] IEEE 802.1CB-2017: "IEEE Standard for Local and metropolitan area networks-Frame
Replication and Elimination for Reliability".

[84] 3GPP TS 23.316: "Wireless and wireline convergence access support for the 5G System (5GS)".

[85] WiFi Alliance Technical Committee, Hotspot 2.0 Technical Task Group: "Hotspot 2.0 (Release 2)
Technical Specification".

[86] 3GPP TS 23.288: "Architecture enhancements for 5G System (5GS) to support network data
analytics services".

[87] 3GPP TS 23.273: "5G System (5GS) Location Services (LCS); Stage 2".

[88] 3GPP TS 23.216: "Single Radio Voice Call Continuity (SRVCC); Stage 2".

[89] CableLabs DOCSIS MULPI: "Data-Over-Cable Service Interface Specifications DOCSIS 3.1,
MAC and Upper Layer Protocols Interface Specification".

[90] BBF TR-124 issue 5: "Functional Requirements for Broadband Residential Gateway Devices".

[91] BBF TR-101 issue 2: "Migration to Ethernet-Based Broadband Aggregation".

[92] BBF TR-178 issue 1: "Multi-service Broadband Network Architecture and Nodal Requirements".

[93] BBF WT-456: "AGF Functional Requirements".

[94] BBF WT-457: "FMIF Functional Requirements".

Editor's note: The references to BBF WT-456 and WT-457 will be revised when finalized by BBF.

[95] IEEE P802.1Qcc: "Standard for Local and metropolitan area networks - Bridges and Bridged
Networks - Amendment: Stream Reservation Protocol (SRP) Enhancements and Performance
Improvements".

[96] Void.

[97] IEEE Std 802.1AB-2016: "IEEE Standard for Local and metropolitan area networks -- Station and
Media Access Control Connectivity Discovery".

[98] IEEE P802.1Q: "Standard for Local and metropolitan area networks--Bridges and Bridged
Networks".

[99] 3GPP TS 38.423: "NG-RAN; Xn Application Protocol (XnAP)".

3GPP
Release 16 21 3GPP TS 23.501 V16.4.0 (2020-03)

[100] 3GPP TS 36.413: "Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1
Application Protocol (S1AP)".

[101] 3GPP TS 29.274: "Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control
plane (GTPv2-C); Stage 3".

[102] 3GPP TS 23.632: "User Data Interworking, Coexistence and Migration; stage 2".

[103] 3GPP TS 29.563: "5G System (5GS); HSS services for interworking with UDM; Stage 3".

[104] IEEE Std 802.1AS-Rev/D7.3, August 2018: "IEEE Standard for Local and metropolitan area
networks--Timing and Synchronization for Time-Sensitive Applications".

[105] 3GPP TS 22.104: "Service requirements for cyber-physical control applications in vertical
domains".

[106] IEEE Std 802.11-2012: "IEEE Standard for Information technology - Telecommunications and
information exchange between systems - Local and metropolitan area networks - Specific
requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY)
Specifications".

[107] IEEE 1588-2008: "IEEE Standard for a Precision Clock Synchronization Protocol for Networked
Measurement and Control".

[108] 3GPP TS 28.552: "Management and orchestration; 5G performance measurements".

[109] 3GPP TS 24.193: "Access Traffic Steering, Switching and Splitting; Stage 3".

[110] 3GPP TS 24.526: "User Equipment (UE) policies for 5G System (5GS); Stage 3".

[111] 3GPP TS 22.186: "Enhancement of 3GPP support for V2X scenarios; Stage 1".

[112] 3GPP TR 38.824: "Study on physical layer enhancements for NR ultra-reliable and low latency
case (URLLC)".

[113] IEEE: "Guidelines for Use of Extended Unique Identifier (EUI), Organizationally Unique
Identifier (OUI), and Company ID (CID)", https://standards.ieee.org/content/dam/ieee-
standards/standards/web/documents/tutorials/eui.pdf.

[114] 3GPP TS 32.256: "Charging Management; 5G connection and mobility domain charging; Stage
2".

[115] 3GPP TS 33.210: "Network Domain Security (NDS); IP network layer security".

[116] 3GPP TS 38.415: "PDU Session User Plane Protocol".

[117] 3GPP TS 24.535: "Device-side Time-Sensitive Networking (TSN) Translator (DS-TT) to network-
side TSN Translator (NW-TT) protocol aspects; Stage 3".

[118] 3GPP TS 32.274: "Charging Management; Short Message Service (SMS) charging".

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

3 Definitions and abbreviations

3.1 Definitions
For the purposes of the present document, the terms and definitions given in TR 21.905 [1] and the following apply. A
term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905 [1].

5GLAN Group: A set of UEs using private communication for 5G LAN-type service.

3GPP
Release 16 22 3GPP TS 23.501 V16.4.0 (2020-03)

5G Access Network: An access network comprising a NG-RAN and/or non-3GPP AN connecting to a 5G Core
Network.

5G Core Network: The core network specified in the present document. It connects to a 5G Access Network.

5G LAN-Type Service: A service over the 5G system offering private communication using IP and/or non-IP type
communications.

5G LAN-Virtual Network: A virtual network over the 5G system capable of supporting 5G LAN-type service.

5G QoS Flow: The finest granularity for QoS forwarding treatment in the 5G System. All traffic mapped to the same
5G QoS Flow receive the same forwarding treatment (e.g. scheduling policy, queue management policy, rate shaping
policy, RLC configuration, etc.). Providing different QoS forwarding treatment requires separate 5G QoS Flow.

5G QoS Identifier: A scalar that is used as a reference to a specific QoS forwarding behaviour (e.g. packet loss rate,
packet delay budget) to be provided to a 5G QoS Flow. This may be implemented in the access network by the 5QI
referencing node specific parameters that control the QoS forwarding treatment (e.g. scheduling weights, admission
thresholds, queue management thresholds, link layer protocol configuration, etc.).

5G System: 3GPP system consisting of 5G Access Network (AN), 5G Core Network and UE.

5G-BRG: The 5G-BRG is a 5G-RG defined in BBF.

5G-CRG: The 5G-CRG is a 5G-RG specified in DOCSIS MULPI [89].

5G-RG: A 5G-RG is a RG capable of connecting to 5GC playing the role of a UE with regard to the 5G core. It
supports secure element and exchanges N1 signalling with 5GC. The 5G-RG can be either a 5G-BRG or 5G-CRG.

Access Traffic Steering: The procedure that selects an access network for a new data flow and transfers the traffic of
this data flow over the selected access network. Access traffic steering is applicable between one 3GPP access and one
non-3GPP access.

Access Traffic Switching: The procedure that moves all traffic of an ongoing data flow from one access network to
another access network in a way that maintains the continuity of the data flow. Access traffic switching is applicable
between one 3GPP access and one non-3GPP access.

Access Traffic Splitting: The procedure that splits the traffic of a data flow across multiple access networks. When
traffic splitting is applied to a data flow, some traffic of the data flow is transferred via one access and some other traffic
of the same data flow is transferred via another access. Access traffic splitting is applicable between one 3GPP access
and one non-3GPP access.

Allowed NSSAI: NSSAI provided by the Serving PLMN during e.g. a Registration procedure, indicating the S-NSSAIs
values the UE could use in the Serving PLMN for the current Registration Area.

Allowed Area: Area where the UE is allowed to initiate communication as specified in clause 5.3.2.3.

AMF Region: An AMF Region consists of one or multiple AMF Sets.

AMF Set: An AMF Set consists of some AMFs that serve a given area and Network Slice(s). AMF Set is unique within
an AMF Region and it comprises of AMFs that support the same Network Slice(s). Multiple AMF Sets may be defined
per AMF Region. The AMF instances in the same AMF Set may be geographically distributed but have access to the
same context data.

Application identifier: An identifier that can be mapped to a specific application traffic detection rule.

AUSF Group ID: This refers to one or more AUSF instances managing a specific set of SUPIs. An AUSF Group
consists of one or multiple AUSF Sets.

Binding Indication: Information included by a NF service producer to a NF service consumer in request responses or
notifications to convey the scope within which selection/reselection of target NF/NF Services may be performed, or
information included by the NF service consumer in requests or subscriptions to convey the scope within which
selection/reselection of notification targets or the selection of other service(s) that the NF consumer produces for the
same data context may be performed. See clause 6.3.1.0.

Configured NSSAI: NSSAI provisioned in the UE applicable to one or more PLMNs.

3GPP
Release 16 23 3GPP TS 23.501 V16.4.0 (2020-03)

CHF Group ID: This refers to one or more CHF instances managing a specific set of SUPIs.

Delegated Discovery: This refers to delegating the discovery and associated selection of NF instances or NF service
instances to an SCP.

Direct Communication: This refers to the communication between NFs or NF services without using an SCP.

DN Access Identifier (DNAI): Identifier of a user plane access to one or more DN(s) where applications are deployed.

Emergency Registered: A UE is considered Emergency Registered over an Access Type in a PLMN when registered
for emergency services only over this Access Type in this PLMN.

Endpoint Address: An address in the format of an IP address or FQDN, which is used to determine the host/authority
part of the target URI. This Target URI is used to access an NF service (i.e. to invoke service operations) of an NF
service producer or for notifications to an NF service consumer.

En-gNB: as defined in TS 37.340 [31].

Expected UE Behaviour: Set of parameters provisioned by an external party to 5G network functions on the foreseen
or expected UE behaviour, see clause 5.20.

Fixed Network Residential Gateway: A Fixed Network RG (FN-RG) is a RG that it does not support N1 signalling
and it is not 5GC capable.

Fixed Network Broadband Residential Gateway: A Fixed Network RG (FN-BRG) is a FN-RG specified in
BBF TR-124 [90].

Fixed Network Cable Residential Gateway: A Fixed Network Cable RG (FN-CRG) is a FN-RG with cable modem
specified in DOCSIS MULPI [89].

Forbidden Area: An area where the UE is not allowed to initiate communication as specified in clause 5.3.2.3.

GBR QoS Flow: A QoS Flow using the GBR resource type or the Delay-critical GBR resource type and requiring
guaranteed flow bit rate.

IAB-donor: This is a NG-RAN node that supports Integrated access and backhaul (IAB) feature and provides
connection to the core network to IAB-nodes. It supports the CU function of the CU/DU architecture for IAB defined in
TS 38.401 [42].

IAB-node: A relay node that supports wireless in-band and out-of-band relaying of NR access traffic via NR Uu
backhaul links. It supports the UE function and the DU function of the CU/DU architecture for IAB defined in
TS 38.401 [42].

Indirect Communication: This refers to the communication between NFs or NF services via an SCP.

Initial Registration: UE registration in RM-DEREGISTERED state as specified in clause 5.3.2.

Intermediate SMF (I-SMF): An SMF that is inserted to support a PDU session as the UE is located in an area which
cannot be controlled by the original SMF because the UPF(s) belong to a different SMF Service Area.

Local Area Data Network: a DN that is accessible by the UE only in specific locations, that provides connectivity to a
specific DNN, and whose availability is provided to the UE.

Local Break Out (LBO): Roaming scenario for a PDU Session where the PDU Session Anchor and its controlling
SMF are located in the serving PLMN (VPLMN).

LTE-M: a 3GPP RAT type Identifier used in the Core Network only, which is a sub-type of E-UTRA RAT type, and
defined to identify in the Core Network the E-UTRA when used by a UE indicating Category M.

MA PDU Session: A PDU Session that provides a PDU connectivity service, which can use one access network at a
time, or simultaneously one 3GPP access network and one non-3GPP access network.

Mobility Pattern: Network concept of determining within the AMF the UE mobility parameters as specified in
clause 5.3.2.4.

Mobility Registration Update: UE re-registration when entering new TA outside the TAI List as specified in
clause 5.3.2.

3GPP
Release 16 24 3GPP TS 23.501 V16.4.0 (2020-03)

MPS-subscribed UE: A UE having a USIM with MPS subscription.

NB-IoT UE Priority: Numerical value used by the NG-RAN to prioritise between different UEs accessing via NB-IoT.

NGAP UE association: The logical per UE association between a 5G-AN node and an AMF.

NGAP UE-TNLA-binding: The binding between a NGAP UE association and a specific TNL association for a given
UE.

Network Function: A 3GPP adopted or 3GPP defined processing function in a network, which has defined functional
behaviour and 3GPP defined interfaces.

NOTE 1: A network function can be implemented either as a network element on a dedicated hardware, as a
software instance running on a dedicated hardware, or as a virtualised function instantiated on an
appropriate platform, e.g. on a cloud infrastructure.

Network Instance: Information identifying a domain. Used by the UPF for traffic detection and routing.

Network Slice: A logical network that provides specific network capabilities and network characteristics.

Network Slice instance: A set of Network Function instances and the required resources (e.g. compute, storage and
networking resources) which form a deployed Network Slice.

Non-GBR QoS Flow: A QoS Flow using the Non-GBR resource type and not requiring guaranteed flow bit rate.

NSI ID: an identifier for identifying the Core Network part of a Network Slice instance when multiple Network Slice
instances of the same Network Slice are deployed, and there is a need to differentiate between them in the 5GC.

NF instance: an identifiable instance of the NF.

NF service: a functionality exposed by a NF through a service based interface and consumed by other authorized NFs.

NF service instance: an identifiable instance of the NF service.

NF service operation: An elementary unit a NF service is composed of.

NF Service Set: A group of interchangeable NF service instances of the same service type within an NF instance. The
NF service instances in the same NF Service Set have access to the same context data.

NF Set: A group of interchangeable NF instances of the same type, supporting the same services and the same Network
Slice(s). The NF instances in the same NF Set may be geographically distributed but have access to the same context
data.

NG-RAN: A radio access network that supports one or more of the following options with the common characteristics
that it connects to 5GC:

1) Standalone New Radio.

2) New Radio is the anchor with E-UTRA extensions.

3) Standalone E-UTRA.

4) E-UTRA is the anchor with New Radio extensions.

Non-Allowed Area: Area where the UE is allowed to initiate Registration procedure but no other communication as
specified in clause 5.3.2.3.

Non-Public Network: See definition in TS 22.261 [2].

Non-Seamless Non-3GPP offload: The offload of user plane traffic via non-3GPP access without traversing either
N3IWF/TNGF or UPF.

PCF Group ID: This refers to one or more PCF instances managing a specific set of SUPIs. A PCF Group consists of
one or multiple PCF Sets.

Pending NSSAI: NSSAI provided by the Serving PLMN during a Registration procedure, indicating the S-NSSAI(s)
for which the network slice-specific authentication and authorization procedure is pending.

3GPP
Release 16 25 3GPP TS 23.501 V16.4.0 (2020-03)

PDU Connectivity Service: A service that provides exchange of PDUs between a UE and a Data Network.

PDU Session: Association between the UE and a Data Network that provides a PDU connectivity service.

PDU Session Type: The type of PDU Session which can be IPv4, IPv6, IPv4v6, Ethernet or Unstructured.

Periodic Registration Update: UE re-registration at expiry of periodic registration timer as specified in clause 5.3.2.

Private communication: See definition in TS 22.261 [2].

Public network integrated NPN: A non-public network deployed with the support of a PLMN.

(Radio) Access Network: See 5G Access Network.

RAT type: Identifies a the transmission technology used in the access network for both 3GPP accesses and non-3GPP
Accesses, for example, NR, NB-IOT, Untrusted Non-3GPP, Trusted Non-3GPP, Trusted IEEE 802.11 Non-3GPP
access, Wireline, etc.

Requested NSSAI: NSSAI provided by the UE to the Serving PLMN during registration.

Residential Gateway: The Residential Gateway (RG) is a device providing, for example voice, data, broadcast video,
video on demand, to other devices in customer premises.

Routing Binding Indication: Information included in a request or notification and that can be used by the SCP for
discovery and associated selection to of a suitable target. See clauses 6.3.1.0 and 7.1.2

Routing Indicator: Indicator that allows together with SUCI/SUPI Home Network Identifier to route network
signalling to AUSF and UDM instances capable to serve the subscriber.

SNPN enabled UE: A UE configured to use stand-alone Non-Public Networks.

SNPN access mode: A UE operating in SNPN access mode only selects stand-alone Non-Public Networks over Uu.

Service based interface: It represents how a set of services is provided/exposed by a given NF.

Service Continuity: The uninterrupted user experience of a service, including the cases where the IP address and/or
anchoring point change.

Service Data Flow Filter: A set of packet flow header parameter values/ranges used to identify one or more of the
packet (IP or Ethernet) flows constituting a Service Data Flow.

Service Data Flow Template: The set of Service Data Flow filters in a policy rule or an application identifier in a
policy rule referring to an application detection filter, required for defining a Service Data Flow.

Session Continuity: The continuity of a PDU Session. For PDU Session of IPv4 or IPv6 or IPv4v6 type "session
continuity" implies that the IP address is preserved for the lifetime of the PDU Session.

SMF Service Area: The collection of UPF Service Areas of all UPFs which can be controlled by one SMF.

Stand-alone Non-Public Network: A non-public network not relying on network functions provided by a PLMN

Subscribed S-NSSAI: S-NSSAI based on subscriber information, which a UE is subscribed to use in a PLMN

Time Sensitive Communication (TSC): A communication service that supports deterministic communication and/or
isochronous communication with high reliability and availability. It is about providing packet transport with QoS
characteristics such as bounds on latency, loss, and reliability, where end systems and relay/transmit nodes can be
strictly synchronized.

TSN working domain: Synchronization domain for a localized set of devices collaborating on a specific task or work
function in a TSN network, corresponding to a gPTP domain defined in IEEE 802.1AS [104].

UDM Group ID: This refers to one or more UDM instances managing a specific set of SUPIs. An UDM Group
consists of one or multiple UDM Sets.

UDR Group ID: This refers to one or more UDR instances managing a specific set of SUPIs. An UDR Group consists
of one or multiple UDR Sets.

3GPP
Release 16 26 3GPP TS 23.501 V16.4.0 (2020-03)

UPF Service Area: An area consisting of one or more TA(s) within which PDU Session associated with the UPF can
be served by (R)AN nodes via a N3 interface between the (R)AN and the UPF without need to add a new UPF in
between or to remove/re-allocate the UPF.

Uplink Classifier: UPF functionality that aims at diverting Uplink traffic, based on filter rules provided by SMF,
towards Data Network.

WB-E-UTRA: In the RAN, WB-E-UTRA is the part of E-UTRA that excludes NB-IoT. In the Core Network, WB-E-
UTRA also excludes LTE-M.

Wireline 5G Access Network: The Wireline 5G Access Network (W-5GAN) is a wireline AN that connects to a 5GC
via N2 and N3 reference points. The W-5GAN can be either a W-5GBAN or W-5GCAN.

Wireline 5G Cable Access Network: The Wireline 5G Cable Access Network (W-5GCAN) is the Access Network
defined in CableLabs.

Wireline BBF Access Network: The Wireline 5G BBF Access Network (W-5GBAN) is the Access Network defined
in BBF.

Wireline Access Gateway Function (W-AGF): The Wireline Access Gateway Function (W-AGF) is a Network
function in W-5GAN that provides connectivity to the 5G Core to 5G-RG and FN-RG.

NOTE 2: If one AUSF/PCF/UDR/UDM group consists of multiple AUSF/PCF/UDR/UDM Sets,

AUSF/PCF/UDR/UDM instance from different Set may be selected to serve the same UE. The temporary
data which is not shared across different Sets may be lost, e.g. the event subscriptions stored at one UDM
instance are lost if another UDM instance from different Set is selected and no data shared across the
UDM Sets.

3.2 Abbreviations
For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply. An
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in
TR 21.905 [1].

5GC 5G Core Network

5GLAN 5G Local Area Network
5GS 5G System
5G-AN 5G Access Network
5G-AN PDB 5G Access Network Packet Delay Budget
5G-EIR 5G-Equipment Identity Register
5G-GUTI 5G Globally Unique Temporary Identifier
5G-BRG 5G Broadband Residential Gateway
5G-CRG 5G Cable Residential Gateway
5G GM 5G Grand Master
5G-RG 5G Residential Gateway
5G-S-TMSI 5G S-Temporary Mobile Subscription Identifier
5G VN 5G Virtual Network
5QI 5G QoS Identifier
AF Application Function
AMF Access and Mobility Management Function
AS Access Stratum
ATSSS Access Traffic Steering, Switching, Splitting
ATSSS-LL ATSSS Low-Layer
AUSF Authentication Server Function
BMCA Best Master Clock Algorithm
BSF Binding Support Function
CAG Closed Access Group
CAPIF Common API Framework for 3GPP northbound APIs
CHF Charging Function
CN PDB Core Network Packet Delay Budget
CP Control Plane
DL Downlink

3GPP
Release 16 27 3GPP TS 23.501 V16.4.0 (2020-03)

DN Data Network
DNAI DN Access Identifier
DNN Data Network Name
DRX Discontinuous Reception
DS-TT Device-side TSN translator
ePDG evolved Packet Data Gateway
EBI EPS Bearer Identity
EUI Extended Unique Identifier
FAR Forwarding Action Rule
FN-BRG Fixed Network Broadband RG
FN-CRG Fixed Network Cable RG
FN-RG Fixed Network RG
FQDN Fully Qualified Domain Name
GFBR Guaranteed Flow Bit Rate
GMLC Gateway Mobile Location Centre
GPSI Generic Public Subscription Identifier
GUAMI Globally Unique AMF Identifier
HR Home Routed (roaming)
IAB Integrated access and backhaul
IMEI/TAC IMEI Type Allocation Code
IPUPS Inter PLMN UP Security
I-SMF Intermediate SMF
I-UPF Intermediate UPF
LADN Local Area Data Network
LBO Local Break Out (roaming)
LMF Location Management Function
LoA Level of Automation
LPP LTE Positioning Protocol
LRF Location Retrieval Function
MCX Mission Critical Service
MDBV Maximum Data Burst Volume
MFBR Maximum Flow Bit Rate
MICO Mobile Initiated Connection Only
MPS Multimedia Priority Service
MPTCP Multi-Path TCP Protocol
N3IWF Non-3GPP InterWorking Function
N5CW Non-5G-Capable over WLAN
NAI Network Access Identifier
NEF Network Exposure Function
NF Network Function
NGAP Next Generation Application Protocol
NID Network identifier
NPN Non-Public Network
NR New Radio
NRF Network Repository Function
NSI ID Network Slice Instance Identifier
NSSAA Network Slice-Specific Authentication and Authorization
NSSAI Network Slice Selection Assistance Information
NSSF Network Slice Selection Function
NSSP Network Slice Selection Policy
NW-TT Network-side TSN translator
NWDAF Network Data Analytics Function
PCF Policy Control Function
PDB Packet Delay Budget
PDR Packet Detection Rule
PDU Protocol Data Unit
PEI Permanent Equipment Identifier
PER Packet Error Rate
PFD Packet Flow Description
PNI-NPN Public Network Integrated Non-Public Network
PPD Paging Policy Differentiation
PPF Paging Proceed Flag

3GPP
Release 16 28 3GPP TS 23.501 V16.4.0 (2020-03)

PPI Paging Policy Indicator

PSA PDU Session Anchor
PTP Precision Time Protocol
QFI QoS Flow Identifier
QoE Quality of Experience
RACS Radio Capabilities Signalling optimisation
(R)AN (Radio) Access Network
RG Residential Gateway
RIM Remote Interference Management
RQA Reflective QoS Attribute
RQI Reflective QoS Indication
RSN Redundancy Sequence Number
SA NR Standalone New Radio
SBA Service Based Architecture
SBI Service Based Interface
SCP Service Communication Proxy
SD Slice Differentiator
SEAF Security Anchor Functionality
SEPP Security Edge Protection Proxy
SMF Session Management Function
SMSF Short Message Service Function
SN Sequence Number
SNPN Stand-alone Non-Public Network
S-NSSAI Single Network Slice Selection Assistance Information
SSC Session and Service Continuity
SSCMSP Session and Service Continuity Mode Selection Policy
SST Slice/Service Type
SUCI Subscription Concealed Identifier
SUPI Subscription Permanent Identifier
SV Software Version
TNAN Trusted Non-3GPP Access Network
TNAP Trusted Non-3GPP Access Point
TNGF Trusted Non-3GPP Gateway Function
TNL Transport Network Layer
TNLA Transport Network Layer Association
TSC Time Sensitive Communication
TSCAI TSC Assistance Information
TSN Time Sensitive Networking
TSN GM TSN Grand Master
TSP Traffic Steering Policy
TT TSN Translator
TWIF Trusted WLAN Interworking Function
UCMF UE radio Capability Management Function
UDM Unified Data Management
UDR Unified Data Repository
UDSF Unstructured Data Storage Function
UL Uplink
UL CL Uplink Classifier
UPF User Plane Function
URLLC Ultra Reliable Low Latency Communication
URRP-AMF UE Reachability Request Parameter for AMF
URSP UE Route Selection Policy
VID VLAN Identifier
VLAN Virtual Local Area Network
W-5GAN Wireline 5G Access Network
W-5GBAN Wireline BBF Access Network
W-5GCAN Wireline 5G Cable Access Network
W-AGF Wireline Access Gateway Function

3GPP
Release 16 29 3GPP TS 23.501 V16.4.0 (2020-03)

4 Architecture model and concepts

4.1 General concepts

The 5G System architecture is defined to support data connectivity and services enabling deployments to use techniques
such as e.g. Network Function Virtualization and Software Defined Networking. The 5G System architecture shall
leverage service-based interactions between Control Plane (CP) Network Functions where identified. Some key
principles and concept are to:

- Separate the User Plane (UP) functions from the Control Plane (CP) functions, allowing independent scalability,
evolution and flexible deployments e.g. centralized location or distributed (remote) location.

- Modularize the function design, e.g. to enable flexible and efficient network slicing.

- Wherever applicable, define procedures (i.e. the set of interactions between network functions) as services, so
that their re-use is possible.

- Enable each Network Function and its Network Function Services to interact with other NF and its Network
Function Services directly or indirectly via a Service Communication Proxy if required. The architecture does
not preclude the use of another intermediate function to help route Control Plane messages (e.g. like a DRA).

- Minimize dependencies between the Access Network (AN) and the Core Network (CN). The architecture is
defined with a converged core network with a common AN - CN interface which integrates different Access
Types e.g. 3GPP access and non-3GPP access.

- Support a unified authentication framework.

- Support "stateless" NFs, where the "compute" resource is decoupled from the "storage" resource.

- Support capability exposure.

- Support concurrent access to local and centralized services. To support low latency services and access to local
data networks, UP functions can be deployed close to the Access Network.

- Support roaming with both Home routed traffic as well as Local breakout traffic in the visited PLMN.

4.2 Architecture reference model

4.2.1 General
This specification describes the architecture for the 5G System. The 5G architecture is defined as service-based and the
interaction between network functions is represented in two ways.

- A service-based representation, where network functions (e.g. AMF) within the Control Plane enables other
authorized network functions to access their services. This representation also includes point-to-point reference
points where necessary.

- A reference point representation, shows the interaction exist between the NF services in the network functions
described by point-to-point reference point (e.g. N11) between any two network functions (e.g. AMF and SMF).

Service-based interfaces are listed in clause 4.2.6. Reference points are listed in clause 4.2.7.

Network functions within the 5GC Control Plane shall only use service-based interfaces for their interactions.

NOTE 1: The interactions between NF services within one NF are not specified in this Release of the specification.

NOTE 2: UPF does not provide any services in this Release of the specification, but can consume services provided
by 5GC Control Plane NFs.

NFs and NF services can communicate directly, referred to as Direct Communication, or indirectly via the SCP,
referred to as Indirect Communication. For more information on communication options, see Annex E and clauses
under 6.3.1 and 7.1.2.

3GPP
Release 16 30 3GPP TS 23.501 V16.4.0 (2020-03)

4.2.2 Network Functions and entities

The 5G System architecture consists of the following network functions (NF).

- Authentication Server Function (AUSF)

- Access and Mobility Management Function (AMF)

- Data Network (DN), e.g. operator services, Internet access or 3rd party services

- Unstructured Data Storage Function (UDSF)

- Network Exposure Function (NEF)

- Intermediate NEF (I-NEF)

- Network Repository Function (NRF)

- Network Slice Selection Function (NSSF)

- Policy Control Function (PCF)

- Session Management Function (SMF)

- Unified Data Management (UDM)

- Unified Data Repository (UDR)

- User Plane Function (UPF)

- UE radio Capability Management Function (UCMF)

- Application Function (AF)

- User Equipment (UE)

- (Radio) Access Network ((R)AN)

- 5G-Equipment Identity Register (5G-EIR)

- Network Data Analytics Function (NWDAF)

- CHarging Function (CHF)

NOTE: The functional description of the CHF is specified in TS 32.240 [41].

The 5G System architecture also comprises the following network entities:

- Service Communication Proxy (SCP)

- Security Edge Protection Proxy (SEPP)

The functional descriptions of these Network Functions and entities are specified in clause 6.

- Non-3GPP InterWorking Function (N3IWF)

- Trusted Non-3GPP Gateway Function (TNGF)

- Wireline Access Gateway Function (W-AGF)

- Trusted WLAN Interworking Function (TWIF)

4.2.3 Non-roaming reference architecture

Figure 4.2.3-1 depicts the non-roaming reference architecture. Service-based interfaces are used within the Control
Plane.

3GPP
Release 16 31 3GPP TS 23.501 V16.4.0 (2020-03)

NSSF NEF NRF PCF UDM AF

Nnssf Nnef Nnrf Npcf Nudm Naf

Nausf Namf Nsmf

AUSF AMF SMF SCP

N2 N4

UE (R)AN N3 UPF N6 DN

N9

Figure 4.2.3-1: 5G System architecture

NOTE: If an SCP is deployed it can be used for indirect communication between NFs and NF services as
described in Annex E. SCP does not expose services itself.

Figure 4.2.3-2 depicts the 5G System architecture in the non-roaming case, using the reference point representation
showing how various network functions interact with each other.

NSSF AUSF N13 UDM

N22 N12 N8 N10

AMF N11 SMF N7 PCF N5 AF

N14 N15

N1 N2 N4

UE (R)AN N3 UPF N6 DN

N9

NOTE 1: N9, N14 are not shown in all other figures however they may also be applicable for other scenarios.
NOTE 2: For the sake of clarity of the point-to-point diagrams, the UDSF, NEF and NRF have not been depicted.
However, all depicted Network Functions can interact with the UDSF, UDR, NEF and NRF as necessary.
NOTE 3: The UDM uses subscription data and authentication data and the PCF uses policy data that may be stored
in UDR (refer to clause 4.2.5).
NOTE 4: For clarity, the UDR and its connections with other NFs, e.g. PCF, are not depicted in the point-to-point
and service-based architecture diagrams. For more information on data storage architectures refer to
clause 4.2.5.
NOTE 5: For clarity, the NWDAF and its connections with other NFs, e.g. PCF, are not depicted in the point-to-point
and service-based architecture diagrams. For more information on network data analytics architecture
refer to TS 23.288 [86].

Figure 4.2.3-2: Non-Roaming 5G System Architecture in reference point representation

Figure 4.2.3-3 depicts the non-roaming architecture for UEs concurrently accessing two (e.g. local and central) data
networks using multiple PDU Sessions, using the reference point representation. This figure shows the architecture for

3GPP
Release 16 32 3GPP TS 23.501 V16.4.0 (2020-03)

multiple PDU Sessions where two SMFs are selected for the two different PDU Sessions. However, each SMF may also
have the capability to control both a local and a central UPF within a PDU Session.

NSSF AUSF N13 UDM AF

N8
N22 N12 N10 N5

N10

AMF N11 SMF N7 PCF

N7
N11
N15

N1 N2
SMF N4

UE (R)AN N3 UPF N6 DN
N4
N3
N9

UPF N6 DN

N9

Figure 4.2.3-3: Applying non-roaming 5G System architecture for multiple PDU Session in reference
point representation

Figure 4.2.3-4 depicts the non-roaming architecture in the case of concurrent access to two (e.g. local and central) data
networks is provided within a single PDU Session, using the reference point representation.

3GPP
Release 16 33 3GPP TS 23.501 V16.4.0 (2020-03)

NSSF AUSF N13 UDM

N8
N22 N12 N10

AMF N11 SMF N7 PCF N5 AF

N15

N4
N1 N2 N4

N4

UE (R)AN N3 UPF N9 UPF N6 DN

N9 N9

UPF N6 DN

Figure 4.2.3-4: Applying non-roaming 5G System architecture for concurrent access to two (e.g. local
and central) data networks (single PDU Session option) in reference point representation

Figure 4.2.3-5 depicts the non-roaming architecture for Network Exposure Function, using reference point
representation.

AF AF

N33 AF

N33

API 1 API 2 API 3 ... API n

TRUST DOMAIN

NEF NEF

3GPP 3GPP
Interface
(See
... Interface
(See
Note 2) Note 2)

NF1 NF2 NFn

Figure 4.2.3-5: Non-roaming architecture for Network Exposure Function in reference point
representation

NOTE 1: In figure 4.2.3-5, Trust domain for NEF is same as Trust domain for SCEF as defined in TS 23.682 [36].

3GPP
Release 16 34 3GPP TS 23.501 V16.4.0 (2020-03)

NOTE 2: In figure 4.2.3-5, 3GPP Interface represents southbound interfaces between NEF and 5GC Network
Functions e.g. N29 interface between NEF and SMF, N30 interface between NEF and PCF, etc. All
southbound interfaces from NEF are not shown for the sake of simplicity.

4.2.4 Roaming reference architectures

Figure 4.2.4-1 depicts the 5G System roaming architecture with local breakout with service-based interfaces within the
Control Plane.

I-NEF NSSF NEF NRF PCF AF UDM NRF

Nnef Nnrf Npcf Naf Nudm Nnrf

Ni-nef Nnssf
vSEPP hSEPP
Namf Nsmf Nausf Npcf Nnef
AMF SMF AUSF PCF NEF
N4

VPLMN HPLMN
UE (R)AN N3 UPF N6 DN

N9

Figure 4.2.4-1: Roaming 5G System architecture- local breakout scenario in service-based interface
representation

NOTE 1: In the LBO architecture. The PCF in the VPLMN may interact with the AF in order to generate PCC
Rules for services delivered via the VPLMN. The PCF in the VPLMN uses locally configured policies
according to the roaming agreement with the HPLMN operator as input for PCC Rule generation. The
PCF in VPLMN has no access to subscriber policy information from the HPLMN.

NOTE 2: An SCP can be used for indirect communication between NFs and NF services within theVPLMN, within
the HPLMN, or in within both VPLMN and HPLMN. For simplicity, the SCP is not shown in the
roaming architecture.

Figure 4.2.4-3 depicts the 5G System roaming architecture in the case of home routed scenario with service-based
interfaces within the Control Plane.

I-NEF NSSF NEF NRF PCF UDM NRF NEF NSSF

Ni-nef Nnssf Nnef Nnrf Npcf Nudm Nnrf Nnef Nnssf

vSEPP N32 hSEPP
Namf Nsmf Nsmf Nausf Npcf Naf
AMF SMF SMF AUSF PCF AF
N4

UE (R)AN N3 UPF N9 UPF N6 DN

N9 N9

VPLMN HPLMN

Figure 4.2.4-3: Roaming 5G System architecture - home routed scenario in service-based interface
representation

3GPP
Release 16 35 3GPP TS 23.501 V16.4.0 (2020-03)

NOTE 3: An SCP can be used for indirect communication between NFs and NF services within theVPLMN, within
the HPLMN, or in within both VPLMN and HPLMN. For simplicity, the SCP is not shown in the
roaming architecture.

NOTE 4: UPFs in the home routed scenario can be used also to support the IPUPS functionality (see
clause 5.8.2.14).

Figure 4.2.4-4 depicts 5G System roaming architecture in the case of local break out scenario using the reference point
representation.

AUSF

N13

NSSF
N12
UDM

N22 N8 N10

AMF N11 SMF N7 vPCF N24 hPCF

N15 N5

N4 AF
N1 N2

UE (R)AN N3 UPF N6 DN

N9 VPLMN HPLMN

Figure 4.2.4-4: Roaming 5G System architecture - local breakout scenario in reference point
representation

NOTE 5: The NRF is not depicted in reference point architecture figures. Refer to Figure 4.2.4-7 for details on
NRF and NF interfaces.

NOTE 6: For the sake of clarity, SEPPs are not depicted in the roaming reference point architecture figures.

The following figure 4.2.4-6 depicts the 5G System roaming architecture in the case of home routed scenario using the
reference point representation.

3GPP
Release 16 36 3GPP TS 23.501 V16.4.0 (2020-03)

N31

N12 AUSF

N13

V-NSSF V-PCF UDM H-NSSF

N15
N8
N22 N24
N10

AMF N11 V-SMF N16 H-SMF N7 H-PCF N5 AF

N4 N4
N1 N2

UE (R)AN N3 UPF N9 UPF N6 Data Network

N9 N9
VPLMN HPLMN

Figure 4.2.4-6: Roaming 5G System architecture-Home routed scenario in reference point

representation

For the roaming scenarios described above each PLMN implements proxy functionality to secure interconnection and
hide topology on the inter-PLMN interfaces.

VPLMN
vNRF N27 hNRF
NF

VPLMN HPLMN

Figure 4.2.4-7: NRF Roaming architecture in reference point representation

NOTE 7: For the sake of clarity, SEPPs on both sides of PLMN borders are not depicted in figure 4.2.4-7.

In roaming scenarios, the I-NEF may be deployed. The I-NEF is described in clause 6.2.5a. Figure 4.2.4-8 depicts the
roaming architecture for Network Exposure Function, using reference point representation.

3GPP
Release 16 37 3GPP TS 23.501 V16.4.0 (2020-03)

AMF

N51i

I-NEF N53 NEF

N29i

SMF
VPLMN HPLMN

Figure 4.2.4-8: Roaming architecture for Network Exposure Function in reference point
representation

NOTE 8: The reference architecture in figure 4.2.4-8 supports service based interfaces on the I-NEF.

Operators can deploy UPFs supporting the Inter PLMN UP Security (IPUPS) functionality at the border of their
network to protect their network from invalid inter PLMN N9 traffic in home routed roaming scenarios. The UPFs
supporting the IPUPS functionality in VPLMN and HPLMN are controlled by the V-SMF and the H-SMF of that PDU
Session respectively. A UPF supporting the IPUPS functionality terminates GTP-U N9 tunnels. The SMF can activate
the IPUPS functionality together with other UP functionality in the same UPF, or insert a separate UPF for the IPUPS
functionality in the UP path (which e.g. may be dedicated to be used for IPUPS functionality). Figure 4.2.4-9 depicts
the home routed roaming architecture where a UPF is inserted in the UP path for the IPUPS functionality. Figure 4.2.4-
3 depicts the home routed roaming architecture where the two UPFs perform the IPUPS functionality and other UP
functionality for the PDU Session.

NOTE 9: Operators are not prohibited from deploying the IPUPS functionality as a separate Network Function
from the UPF, acting as a transparent proxy which can transparently read N4 and N9 interfaces. However,
such deployment option is not specified and needs to take at least into account very long lasting PDU
Sessions with infrequent traffic and Inter-PLMN handover.

The IPUPS functionality is specified in clause 5.8.2.14 and TS 33.501 [29].

I-NEF NSSF NEF NRF PCF UDM NRF NEF NSSF

Ni-nef Nnssf Nnef Nnrf Npcf Nudm Nnrf Nnef Nnssf

vSEPP N32 hSEPP
Namf Nsmf Nsmf Nausf Npcf Naf
AMF SMF SMF AUSF PCF AF

UPF UPF UPF

UE (R)AN N3 N9 N9 N9 UPF N6 DN
(IPUPS) (IPUPS)
N9 N9

VPLMN HPLMN

Figure 4.2.4-9: Roaming 5G System architecture - home routed roaming scenario in service-based
interface representation employing UPF dedicated to IPUPS

4.2.5 Data Storage architectures

As depicted in Figure 4.2.5-1, the 5G System architecture allows any NF to store and retrieve its unstructured data
into/from a UDSF (e.g. UE contexts). The UDSF belongs to the same PLMN where the network function is located. CP
NFs may share a UDSF for storing their respective unstructured data or may each have their own UDSF (e.g. a UDSF
may be located close to the respective NF).

3GPP
Release 16 38 3GPP TS 23.501 V16.4.0 (2020-03)

NOTE 1: Structured data in this specification refers to data for which the structure is defined in 3GPP
specifications. Unstructured data refers to data for which the structure is not defined in 3GPP
specifications.

Any NF N18/Nudsf UDSF

Figure 4.2.5-1: Data storage architecture for unstructured data from any NF

NOTE 2: 3GPP will specify (possibly by referencing) the N18/Nudsf interface.

As depicted in Figure 4.2.5-2, the 5G System architecture allows the UDM, PCF and NEF to store data in the UDR,
including subscription data and policy data by UDM and PCF, structured data for exposure and application data
(including Packet Flow Descriptions (PFDs) for application detection, AF request information for multiple UEs) by the
NEF. UDR can be deployed in each PLMN and it can serve different functions as follows:

- UDR accessed by the NEF belongs to the same PLMN where the NEF is located.

- UDR accessed by the UDM belongs to the same PLMN where the UDM is located if UDM supports a split
architecture.

- UDR accessed by the PCF belongs to the same PLMN where the PCF is located.

NOTE 3: The UDR deployed in each PLMN can store application data for roaming subscribers.

UDR
UDM
N35
Subscription Data

Nudr
Policy Data
PCF Data Access Provider
N36
Structured Data
for exposure

NEF Application Data

N37

Figure 4.2.5-2: Data storage architecture

NOTE 4: There can be multiple UDRs deployed in the network, each of which can accommodate different data sets
or subsets, (e.g. subscription data, subscription policy data, data for exposure, application data) and/or
serve different sets of NFs. Deployments where a UDR serves a single NF and stores its data, and, thus,
can be integrated with this NF, can be possible.

NOTE 5: The internal structure of the UDR in figure 4.2.5-2 is shown for information only.

The Nudr interface is defined for the network functions (i.e. NF Service Consumers), such as UDM, PCF and NEF, to
access a particular set of the data stored and to read, update (including add, modify), delete, and subscribe to
notification of relevant data changes in the UDR.

Each NF Service Consumer accessing the UDR, via Nudr, shall be able to add, modify, update or delete only the data it
is authorised to change. This authorisation shall be performed by the UDR on a per data set and NF service consumer
basis and potentially on a per UE, subscription granularity.

3GPP
Release 16 39 3GPP TS 23.501 V16.4.0 (2020-03)

The following data in the UDR sets exposed via Nudr to the respective NF service consumer and stored shall be
standardized:

- Subscription Data,

- Policy Data,

- Structured Data for exposure,

- Application data: Packet Flow Descriptions (PFDs) for application detection and AF request information for
multiple UEs, as defined in clause 5.6.7.

The service based Nudr interface defines the content and format/encoding of the 3GPP defined information elements
exposed by the data sets.

In addition, it shall be possible to access operator specific data sets by the NF Service Consumers from the UDR as well
as operator specific data for each data set.

NOTE 6: The content and format/encoding of operator specific data and operator specific data sets are not subject
to standardization.

NOTE 7: The organization of the different data stored in the UDR is not to be standardized.

4.2.5a Radio Capabilities Signalling optimisation

Figure 4.2.5a-1 depicts the AMF to UCMF reference point and interface. Figure 4.2.5a-2 depicts the related interfaces
in AMF and UCMF for the Radio Capabilities Signalling optimisation in the roaming architecture.

NEF N58 AF

N5 7
6 N5

UCMF

5
N5

AMF
N2

N1

UE RAN

Figure 4.2.5a-1: Radio Capability Signalling optimisation architecture

3GPP
Release 16 40 3GPP TS 23.501 V16.4.0 (2020-03)

NEF AF

Nnef Naf
Nucmf Namf

UCMF AMF

UE RAN

VPLMN HPLMN

NOTE: The AF in the VPLMN (i.e. the one having a relationship with the VPLMN NEF) is the one which provisions
Manufacturer Assigned UE radio capability IDs in the VPLMN UCMF. RACS is a serving PLMN only
feature (it requires no specific support in the roaming agreement with the UE HPLMN to operate).

Figure 4.2.5a-2: Roaming architecture for Radio Capability Signalling optimisation

4.2.6 Service-based interfaces

The 5G System Architecture contains the following service-based interfaces:

Namf: Service-based interface exhibited by AMF.

Nsmf: Service-based interface exhibited by SMF.

Nnef: Service-based interface exhibited by NEF.

Npcf: Service-based interface exhibited by PCF.

Nudm: Service-based interface exhibited by UDM.

Naf: Service-based interface exhibited by AF.

Nnrf: Service-based interface exhibited by NRF.

Nnssf: Service-based interface exhibited by NSSF.

Nausf: Service-based interface exhibited by AUSF.

Nudr: Service-based interface exhibited by UDR.

Nudsf: Service-based interface exhibited by UDSF.

N5g-eir: Service-based interface exhibited by 5G-EIR.

Nnwdaf: Service-based interface exhibited by NWDAF.

Ni-nef: Service-based interface exhibited by I-NEF.

Nchf: Service-based interface exhibited by CHF.

Nucmf: Service-based interface exhibited by UCMF.

NOTE: The Service-based interface exhibited by CHF is defined in TS 32.240 [41].

4.2.7 Reference points

The 5G System Architecture contains the following reference points:

3GPP
Release 16 41 3GPP TS 23.501 V16.4.0 (2020-03)

N1: Reference point between the UE and the AMF.

N2: Reference point between the (R)AN and the AMF.

N3: Reference point between the (R)AN and the UPF.

N4: Reference point between the SMF and the UPF.

N6: Reference point between the UPF and a Data Network.

NOTE 1: The traffic forwarding details of N6 between a UPF acting as an uplink classifier and a local data network
are not specified in this Release of the specification.

N9: Reference point between two UPFs.

The following reference points show the interactions that exist between the NF services in the NFs. These reference
points are realized by corresponding NF service-based interfaces and by specifying the identified consumer and
producer NF service as well as their interaction in order to realize a particular system procedure.

N5: Reference point between the PCF and an AF.

N7: Reference point between the SMF and the PCF.

N8: Reference point between the UDM and the AMF.

N10: Reference point between the UDM and the SMF.

N11: Reference point between the AMF and the SMF.

N12: Reference point between AMF and AUSF.

N13: Reference point between the UDM and Authentication Server function the AUSF.

N14: Reference point between two AMFs.

N15: Reference point between the PCF and the AMF in the case of non-roaming scenario, PCF in the visited
network and AMF in the case of roaming scenario.

N16: Reference point between two SMFs, (in roaming case between SMF in the visited network and the SMF
in the home network).

N16a: Reference point between SMF and I-SMF.

N17: Reference point between AMF and 5G-EIR.

N18: Reference point between any NF and UDSF.

N19: Reference point between two PSA UPFs for 5G LAN-type service.

N22: Reference point between AMF and NSSF.

N23: Reference point between PCF and NWDAF.

N24: Reference point between the PCF in the visited network and the PCF in the home network.

N27: Reference point between NRF in the visited network and the NRF in the home network.

N28: Reference point between PCF and CHF.

N29: Reference point between NEF and SMF.

N29i: Reference point between I-NEF and SMF in the VPLMN.

N30: Reference point between PCF and NEF.

NOTE 2: The functionality of N28 and N29 and N30 reference points are defined in TS 23.503 [45].

N31: Reference point between the NSSF in the visited network and the NSSF in the home network.

3GPP
Release 16 42 3GPP TS 23.501 V16.4.0 (2020-03)

NOTE 3: in some cases, a couple of NFs may need to be associated with each other to serve a UE.

In addition to the reference points above, there are interfaces/reference point(s) between SMF and the CHF. The
reference point(s) are not depicted in the architecture illustrations in this specification.

NOTE 4: The functionality of these interface/reference points are defined in TS 32.240 [41].

N32: Reference point between SEPP in the visited network and the SEPP in the home network.

NOTE 5: The functionality of N32 reference point is defined in TS 33.501 [29].

N33: Reference point between NEF and AF.

N34: Reference point between NSSF and NWDAF.

N35: Reference point between UDM and UDR.

N36: Reference point between PCF and UDR.

N37: Reference point between NEF and UDR.

N38: Reference point between I-SMFs.

N40: Reference point between SMF and the CHF.

NOTE 6: The reference points from N40 up to and including N49 are reserved for allocation and definition in
TS 23.503 [45].

N50: Reference point between AMF and the CBCF.

N51: Reference point between AMF and NEF.

N51i: Reference point between I-NEF and the AMF in the VPLMN.

N52: Reference point between NEF and UDM.

N53: Reference point between the I-NEF and the NEF.

N55: Reference point between AMF and the UCMF.

N56: Reference point between NEF and the UCMF.

N57: Reference point between AF and the UCMF.

NOTE 7: The Public Warning System functionality of N50 reference point is defined in TS 23.041 [46].

The reference points to support SMS over NAS are listed in clause 4.4.2.2.

The reference points to support Location Services are listed in TS 23.273 [87].

The reference points to support SBA in IMS (N5, N70 and N71) are described in TS 23.228 [15].

4.2.8 Support of non-3GPP access

4.2.8.0 General
In this Release of the specification, the following types of non-3GPP access networks are defined:

- Untrusted non-3GPP access networks;

- Trusted non-3GPP access networks; and

- Wireline access networks.

The architecture to support Untrusted and Trusted non-3GPP access networks is defined in clause 4.2.8.2. The
architecture to support Wireline access networks is defined in 4.2.8.2.4 and in TS 23.316 [84].

3GPP
Release 16 43 3GPP TS 23.501 V16.4.0 (2020-03)

4.2.8.1 General Concepts to Support Trusted and Untrusted Non-3GPP Access

The 5G Core Network supports connectivity of UEs via non-3GPP access networks, e.g. WLAN access networks.

Only the support of non-3GPP access networks deployed outside the NG-RAN is described in this clause.

The 5G Core Network supports both untrusted non-3GPP access networks and trusted non-3GPP access networks
(TNANs).

An untrusted non-3GPP access network shall be connected to the 5G Core Network via a Non-3GPP InterWorking
Function (N3IWF), whereas a trusted non-3GPP access network shall be connected to the 5G Core Network via a
Trusted Non-3GPP Gateway Function (TNGF). Both the N3IWF and the TNGF interface with the 5G Core Network
CP and UP functions via the N2 and N3 interfaces, respectively.

A non-3GPP access network may advertise the PLMNs for which it supports trusted connectivity and the type of
supported trusted connectivity (e.g. "5G connectivity"). Therefore, the UEs can discover the non-3GPP access networks
that can provide trusted connectivity to one or more PLMNs. This is further specified in clause 6.3.12 (Trusted Non-
3GPP Access Network selection).

The UE decides to use trusted or untrusted non-3GPP access for connecting to a 5G PLMN by using procedures not
specified in this document. Examples of such procedures are defined in clause 6.3.12.1.

When the UE decides to use untrusted non-3GPP access to connect to a 5G Core Network in a PLMN:

- the UE first selects and connects with a non-3GPP access network; and then

- the UE selects a PLMN and an N3IWF in this PLMN. The PLMN/N3IWF selection and the non-3GPP access
network selection are independent. The N3IWF selection is defined in clause 6.3.6.

When the UE decides to use trusted non-3GPP access to connect to a 5G Core Network in a PLMN:

- the UE first selects a PLMN; and then

- the UE selects a non-3GPP access network (a TNAN) that supports trusted connectivity to the selected PLMN.
In this case, the non-3GPP access network selection is affected by the PLMN selection.

A UE that accesses the 5G Core Network over a non-3GPP access shall, after UE registration, support NAS signalling
with 5G Core Network control-plane functions using the N1 reference point.

When a UE is connected via a NG-RAN and via a non-3GPP access, multiple N1 instances shall exist for the UE i.e.
there shall be one N1 instance over NG-RAN and one N1 instance over non-3GPP access.

A UE simultaneously connected to the same 5G Core Network of a PLMN over a 3GPP access and a non-3GPP access
shall be served by a single AMF in this 5G Core Network.

When a UE is connected to a 3GPP access of a PLMN, if the UE selects a N3IWF and the N3IWF is located in a PLMN
different from the PLMN of the 3GPP access, e.g. in a different VPLMN or in the HPLMN, the UE is served separately
by the two PLMNs. The UE is registered with two separate AMFs. PDU Sessions over the 3GPP access are served by
V-SMFs different from the V-SMF serving the PDU Sessions over the non-3GPP access. The same can be true when
the UE uses trusted non-3GPP access, i.e. the UE may select one PLMN for 3GPP access and a different PLMN for
trusted non-3GPP access.

The PLMN selection for the 3GPP access does not depend on the PLMN that is used for non-3GPP access. In other
words, if a UE is registered with a PLMN over a non-3GPP access, the UE performs PLMN selection for the 3GPP
access independently of this PLMN.

A UE shall establish an IPsec tunnel with the N3IWF or with the TNGF in order to register with the 5G Core Network
over non-3GPP access. Further details about the UE registration to 5G Core Network over untrusted non-3GPP access
and over trusted non-3GPP access are described in clause 4.12.2 and in clause 4.12.2a in TS 23.502 [3], respectively.

It shall be possible to maintain the UE NAS signalling connection with the AMF over the non-3GPP access after all the
PDU Sessions for the UE over that access have been released or handed over to 3GPP access.

N1 NAS signalling over non-3GPP accesses shall be protected with the same security mechanism applied for N1 over a
3GPP access.

3GPP
Release 16 44 3GPP TS 23.501 V16.4.0 (2020-03)

User plane QoS differentiation between UE and N3IWF is supported as described in clause 5.7 and TS 23.502 [3]
clause 4.12.5. QoS differentiation between UE and TNGF is supported as described in clause 5.7 and TS 23.502 [3]
clause 4.12a.5.

4.2.8.1A General Concepts to support Wireline Access

Wireline 5G Access Network (W-5GAN) shall be connected to the 5G Core Network via a Wireline Access Gateway
Function (W-AGF). The W-AGF interfaces the 5G Core Network CP and UP functions via N2 and N3 interfaces,
respectively.

For the scenario of 5G-RG connected via NG RAN the specification for UE defined in this TS, TS 23.502 [3] and
TS 23.503 [45] are applicable as defined for UE connected to 5GC via NG RAN unless differently specified in this TS
and in TS 23.316 [84].

When a 5G-RG is connected via a NG-RAN and via a W-5GAN, multiple N1 instances shall exist for the 5G-RG i.e.
there shall be one N1 instance over NG-RAN and one N1 instance over W-5GAN.

A 5G-RG simultaneously connected to the same 5G Core Network of a PLMN over a 3GPP access and a W-5GAN
access shall be served by a single AMF in this 5G Core Network.

5G-RG shall maintain the NAS signalling connection with the AMF over the W-5GAN after all the PDU Sessions for
the 5G-RG over that access have been released or handed over to 3GPP access.

The 5G-RG connected to 5GC via NG-RAN is specified in TS 23.316 [84].

For the scenario of FN-RG, which is not 5G capable, connected via W-5GAN to 5GC, the W-AGF provides the N1
interface to AMF on behalf of the FN-RG.

An UE connected to a 5G-RG or FN-RG can access to the 5GC via the N3IWF or via the TNGF where the combination
of 5G-RG/FN-RG, W-AGF and UPF serving the 5G-RG or FN-RG is acting respectively as Untrusted Non-3GPP
access network or as a Trusted Non-3GPP access network defined in clause 4.2.8.2; for example a UE is connecting to
5G-RG by means of WLAN radio access and connected to 5GC via N3IWF. The detailed description is specified in
TS 23.316 [84].

The roaming architecture for 5G-BRG, FN-BRG, 5G-CRG and FN-CRG with the W-5GAN is not specified in this
Release. The Home Routed roaming scenario is supported for 5G-RG connected via NG RAN, while Local Breakout
scenario is not supported.

5G Multi-Operator Core Network (5G MOCN) is supported for 5G-RG connected via NG RAN as defined in
clause 5.18

3GPP
Release 16 45 3GPP TS 23.501 V16.4.0 (2020-03)

4.2.8.2 Architecture Reference Model for Trusted and Untrusted Non-3GPP

Accesses

4.2.8.2.1 Non-roaming Architecture

N2 N11
3GPP AMF SMF
Access

N3 N2
N4

N1 N3IWF UPF Data Network

N3 N6
HPLMN NWu
N1 Y2

Non-3GPP
Networks
Untrusted Non-
UE
3GPP Access
Y1

Figure 4.2.8.2.1-1: Non-roaming architecture for 5G Core Network with untrusted non-3GPP access

N2 N11
3GPP AMF SMF
Access

N1
N3
N1 N2
N4

UPF Data Network

N6
HPLMN
N3

Trusted Trusted
Non-3GPP Non-3GPP
UE Access Gateway Tn
NWt Point Function
Yt TNAP
Ta
TNGF

Trusted Non-3GPP
Access Network (TNAN)

Figure 4.2.8.2.1-2: Non-roaming architecture for 5G Core Network with trusted non-3GPP access

NOTE 1: The reference architecture in Figure 4.2.8.2.1-1 and in Figure 4.2.8.2.1-2 only shows the architecture and
the network functions directly connected to non-3GPP access, and other parts of the architecture are the
same as defined in clause 4.2.

NOTE 2: The reference architecture in Figure 4.2.8.2.1-1 and in Figure 4.2.8.2.1-2 supports service based interfaces
for AMF, SMF and other NFs not represented in the figure.

NOTE 3: The two N2 instances in Figure 4.2.8.2.1-1 and in Figure 4.2.8.2.1-2 terminate to a single AMF for a UE
which is simultaneously connected to the same 5G Core Network over 3GPP access and non-3GPP
access.

NOTE 4 The two N3 instances in Figure 4.2.8.2.1-1 and in Figure 4.2.8.2.1-2 may terminate to different UPFs
when different PDU Sessions are established over 3GPP access and non-3GPP access.

3GPP
Release 16 46 3GPP TS 23.501 V16.4.0 (2020-03)

4.2.8.2.2 LBO Roaming Architecture

N2 N11
3GPP AMF SMF
Access

N3 N2
N4

N1 N3IWF UPF Data Network

N3 N6
VPLMN NWu
N1 Y2

Non-3GPP
Networks
Untrusted Non-
UE
3GPP Access
Y1

Figure 4.2.8.2.2-1: LBO Roaming architecture for 5G Core Network with untrusted non-3GPP access -
N3IWF in the same VPLMN as 3GPP access

N2 N11
3GPP AMF SMF
Access

N3
N4

N1 UPF Data Network

N6
VPLMN1

Non-3GPP
Networks Y1
Untrusted Non-
UE
3GPP Access
Nwu

N1 Y2
VPLMN2
or HPLMN
N3IWF UPF Data Network
N3 N6
N2 N4

N11
AMF SMF

Figure 4.2.8.2.2-2: LBO Roaming architecture for 5G Core Network with untrusted non-3GPP access -
N3IWF in a different PLMN from 3GPP access

3GPP
Release 16 47 3GPP TS 23.501 V16.4.0 (2020-03)

N2 N11
3GPP AMF SMF
Access

N1
N3
N1 N2
N4

UPF Data Network

N6
VPLMN
N3

Trusted Trusted
Non-3GPP Non-3GPP
UE Access Gateway Tn
NWt Point Function
Yt TNAP
Ta
TNGF

Trusted Non-3GPP
Access Network (TNAN)

Figure 4.2.8.2.2-3: LBO Roaming architecture for 5G Core Network with trusted non-3GPP access
using the same VPLMN as 3GPP access

N2 N11
3GPP AMF SMF
Access

N3
N1
N4

UPF Data Network

VPLMN1 N6

VPLMN2 or HPLMN
Tn
Yt Trusted Trusted
Non-3GPP Non-3GPP
UPF Data Network
UE Access Gateway
NWt Point N3 N6
Function
TNAP Ta TNGF N2
Trusted Non-3GPP
Access Network (TNAN)
N4
N1
N11
AMF SMF

Figure 4.2.8.2.2-4: LBO Roaming architecture for 5G Core Network with trusted non-3GPP access
using a different PLMN than 3GPP access

NOTE 1: The reference architecture in all above figures only shows the architecture and the network functions
directly connected to support non-3GPP access, and other parts of the architecture are the same as defined
in clause 4.2.

NOTE 2: The reference architecture in all above figures supports service based interfaces for AMF, SMF and other
NFs not represented in the figures.

3GPP
Release 16 48 3GPP TS 23.501 V16.4.0 (2020-03)

NOTE 3: The two N2 instances in Figure 4.2.8.2.2-1 and in Figure 4.2.8.2.2-3 terminate to a single AMF for a UE
which is connected to the same 5G Core Network over 3GPP access and non-3GPP access
simultaneously.

NOTE 4: The two N3 instances in Figure 4.2.8.2.2-1 and in Figure 4.2.8.2.2-3 may terminate to different UPFs
when different PDU Sessions are established over 3GPP access and non-3GPP access.

4.2.8.2.3 Home-routed Roaming Architecture

VPLMN HPLMN

N11 N16
AMF vSMF hSMF
N2

3GPP Access N4 N4

N3 N9 Data
UPF UPF
Network

N2

N1 N3

N3IWF

Non-3GPP Y2
NWu N1
Networks

Y1 Untrusted Non-
UE 3GPP Access

Figure 4.2.8.2.3-1: Home-routed Roaming architecture for 5G Core Network with untrusted non-3GPP
access - N3IWF in the same VPLMN as 3GPP access

3GPP
Release 16 49 3GPP TS 23.501 V16.4.0 (2020-03)

VPLMN1 HPLMN

N11
AMF vSMF
N2

3GPP Access N4

N3 UPF
N16
N1

hSMF
Non-3GPP N9
Networks
Y1 N4
Untrusted Non-
UE 3GPP Access N16
Data
UPF
N1 Network
NWu Y2
N9
VPLMN2 N3
N3IWF UPF

N2
N4
N11
AMF vSMF

Figure 4.2.8.2.3-2: Home-routed Roaming architecture for 5G Core Network with untrusted non-3GPP
access - N3IWF in a different VPLMN than 3GPP access

VPLMN HPLMN

N11
AMF vSMF
N2

3GPP Access N4

N3 UPF
N16
N1

hSMF /
SMF
Non-3GPP N9
Networks
N4
N11

Data
UPF
AMF Network

N2
N3
Y1 Untrusted Non- Y2
UE 3GPP Access N3IWF
N1
NWu

Figure 4.2.8.2.3-3: Home-routed Roaming architecture for 5G Core Network with untrusted non-3GPP
access - N3IWF in HPLMN

3GPP
Release 16 50 3GPP TS 23.501 V16.4.0 (2020-03)

N2 N11
3GPP AMF vSMF hSMF
Access N16

N3
N2
N4 N4
N1

UPF UPF Data Network

N9 N6
N1
N3

VPLMN HPLMN

Trusted Trusted
Non-3GPP Non-3GPP
UE Access Gateway Tn
NWt
Point Function
Yt TNAP Ta TNGF

Trusted Non-3GPP
Access Network (TNAN)

Figure 4.2.8.2.3-4: Home-routed Roaming architecture for 5G Core Network with trusted non-3GPP
access using the same VPLMN as 3GPP access

NOTE 1: The reference architecture in all above figures only shows the architecture and the network functions
directly connected to support non-3GPP access, and other parts of the architecture are the same as defined
in clause 4.2.

NOTE 2: The two N2 instances in Figure 4.2.8.2.3-1 and in Figure 4.2.8.2.3-4 terminate to a single AMF for a UE
which is connected to the same 5G Core Network over 3GPP access and non-3GPP access
simultaneously.

4.2.8.3 Reference Points for Non-3GPP Access

4.2.8.3.1 Overview
The description of the reference points specific for the non-3GPP access:

N2, N3, N4, N6: these are defined in clause 4.2.

Y1 Reference point between the UE and the untrusted non-3GPP access (e.g. WLAN). This depends on the
non-3GPP access technology and is outside the scope of 3GPP.

Y2 Reference point between the untrusted non-3GPP access and the N3IWF for the transport of NWu traffic.

Y4 Reference point between the 5G-RG and the W-AGF which transports the user plane traffic and the N1
NAS protocol. The definition of this interface is outside the scope of 3GPP.

Y5 Reference point between the FN-RG and the W-AGF. The definition of this interface is outside the scope
of 3GPP.

Yt Reference point between the UE and the TNAP. See e.g. Figure 4.2.8.2.1-2.

Yt' Reference point between the N5CW devices and the TWAP. It is defined in clause 4.2.8.5.

NWu Reference point between the UE and N3IWF for establishing secure tunnel(s) between the UE and
N3IWF so that control-plane and user-plane exchanged between the UE and the 5G Core Network is
transferred securely over untrusted non-3GPP access.

NWt Reference point between the UE and the TNGF. A secure NWt connection is established over this
reference point, as specified in TS 23.502 [3], clause 4.12a.2.2. NAS messages between the UE and the
AMF are transferred via this NWt connection.

3GPP
Release 16 51 3GPP TS 23.501 V16.4.0 (2020-03)

Ta A reference point between the TNAP and the TNGF, which is used to support an AAA interface. Ta
requirements are documented in clause 4.2.8.3.2.

Tn A reference point between two TNGFs, which is used to facilitate UE mobility between different TNGFs
(inter-TNGF mobility).

Tn and inter-TNGF mobility are not specified in this Release of the specification.

4.2.8.3.2 Requirements on Ta
Ta shall be able to

- Carry EAP-5G traffic and user location information before the NWt connection is established between the UE
and the TNGF.

- Allow the UE and the TNGF to exchange IP traffic.

In deployments where the TNAP does not allocate the local IP addresses to UE(s), Ta shall be able to:

- Allow the UE to request and receive IP configuration from the TNAN (including a local IP address), e.g. with
DHCP. This is to allow the UE to use an IP stack to establish a NWt connection between the UE and the TNGF.

NOTE: The "local IP address" is the IP address that allows the UE to contact the TNGF; the entity providing this
local IP address is part of TNAN and out of 3GPP scope

In this Release of the specification, Ta is not specified.

4.2.8.4 Architecture Reference Model for Wireline Access network

N2 N11

3GPP Access AMF SMF

N3
N1 N2
N4

UPF Data Network

5G-RG N1
N6
Y4
N3

W-AGF

W-5GAN

Figure 4.2.8.4-1: Non- roaming architecture for 5G Core Network for 5G-RG with Wireline 5G Access
network and NG RAN

The 5G-RG can be connected to 5GC via W-5GAN, NG RAN or via both accesses.

NOTE 1: The reference architecture in figure 4.2.8.4-1 only shows the architecture and the network functions
directly connected to Wireline 5G Access Network, and other parts of the architecture are the same as
defined in clause 4.2.

NOTE 2: The reference architecture in figure 4.2.8.4-1 supports service based interfaces for AMF, SMF and other
NFs not represented in the figure.

3GPP
Release 16 52 3GPP TS 23.501 V16.4.0 (2020-03)

NOTE 3: The two N2 instances in Figure 4.2.8.4-1 apply to a single AMF for a 5G-RG which is simultaneously
connected to the same 5G Core Network over 3GPP access and Wireline 5G Access Network.

NOTE 4 The two N3 instances in Figure 4.2.8. 4-1 may apply to different UPFs when different PDU Sessions are
established over 3GPP access and Wireline 5G Access Network.

N11
AMF SMF

N2
N4

N1 UPF Data Network

N6
N3

Y5
FN-RG W-AGF

W-5GAN

Figure 4.2.8.4-2: Non- roaming architecture for 5G Core Network for FN-RG with Wireline 5G Access
network and NG RAN

The N1 for the FN-RG, which is not 5G capable, is terminated on W-AGF which acts on behalf of the FN-RG.

The FN-RG can only be connected to 5GC via W-5GAN.

NOTE 5: The reference architecture in figure 4.2.8.4-2 only shows the architecture and the network functions
directly connected to Wireline 5G Access Network, and other parts of the architecture are the same as
defined in clause 4.2.

NOTE 6: The reference architecture in figure 4.2.8.4-1 supports service based interfaces for AMF, SMF and other
NFs not represented in the figure.

4.2.8.5 Access to 5GC from devices that do not support 5GC NAS over WLAN
access

4.2.8.5.1 General
The devices that do not support 5GC NAS signalling over WLAN access are referred to as "Non-5G-Capable over
WLAN" devices, or N5CW devices for short. A N5CW device is not capable to operate as a 5G UE that supports 5GC
NAS signalling over a WLAN access network, however, it may be capable to operate as a 5G UE over NG-RAN.

Clause 4.2.8.5 specifies the 5GC architectural enhancements that enable N5CW devices to access 5GC via trusted
WLAN access networks. A trusted WLAN access network is a particular type of a Trusted Non-3GPP Access Network
(TNAN) that supports a WLAN access technology, e.g. IEEE 802.11. Not all trusted WLAN access networks support
5GC access from N5CW devices. To support 5GC access from N5CW devices, a trusted WLAN access network must
support the special functionality specified below (e.g. it must support a TWIF function).

When a N5CW device performs an EAP-based access authentication procedure to connect to a trusted WLAN access
network, the N5CW device may simultaneously be registered to a 5GC of a PLMN. The 5GC registration is performed
by the TWIF function (see next clause) in the trusted WLAN access network, on behalf of the N5CW device. The type
of EAP authentication procedure, which is used during the 5GC registration to authenticate the N5CW device, is
specified in TS 33.501 [29].

3GPP
Release 16 53 3GPP TS 23.501 V16.4.0 (2020-03)

4.2.8.5.2 Reference Architecture

The architecture diagram below is based on the general 5GS architecture diagrams in clause 4.2 and shows the main
network functions required to support 5GC access from N5CW devices. Other network functions are not shown for
simplicity.

N11
AMF SMF

N4

UPF Data Network

N2 N6
N1
N3

Trusted Trusted
N5CW WLAN WLAN
Access Interworking
device
Yt Point Yw Function
TWAP TWIF

Trusted WLAN Access Network

Figure 4.2.8.5.2-1: Non-roaming and LBO Roaming Architecture for supporting 5GC access from
N5CW devices

4.2.8.5.3 Network Functions

Trusted WLAN Access Point (TWAP): It is a particular type of a Trusted Non-3GPP Access Point (TNAP) specified in
clause 4.2.8.2, that supports a WLAN access technology, e.g. IEEE 802.11. This function is outside the scope of the
3GPP specifications.

Trusted WLAN Interworking Function (TWIF): It provides interworking functionality that enables N5CW devices to
access 5GC. The TWIF supports the following functions:

- Terminates the N1, N2 and N3 interfaces.

- Implements the AMF selection procedure.

- Implements the NAS protocol stack and exchanges NAS messages with the AMF on behalf of the N5CW
device.

- On the user plane, it relays protocol data units (PDUs) between the Yw interface and the N3 interface.

- May implement a local mobility anchor within the trusted WLAN access network.

4.2.8.5.4 Reference Points

The Yt' and Yw reference points are both outside the scope of the 3GPP specifications. The Yt' reference point
transports WLAN messages (e.g. IEEE 802.11 messages), while the Yw reference point:

- Shall be able to transport authentication messages between the TNAP and the TWIF for enabling authentication
of a N5CW device;

- Shall allow the N5CW device to request and receive IP configuration from the TWIF, including an IP address,
e.g. with DHCP.

- Shall support the transport of user-plane traffic for the N5CW device.

3GPP
Release 16 54 3GPP TS 23.501 V16.4.0 (2020-03)

The N1, N2 and N3 reference points are the same reference points defined in clause 4.2.7.

4.2.9 Network Analytics architecture

The Network Analytics architecture is defined in TS 23.288 [86].

4.2.10 Architecture Reference Model for ATSSS Support

In order to support the ATSSS feature, the 5G System Architecture is extended as shown in Figure 4.2.10-1, Figure
4.2.10-2 and Figure 4.2.10-3. The additional functionality that is supported by the UE and the network functions shown
in these figures is specified in clause 5.32 below. In summary:

- The UE supports one or more of the steering functionalities specified in clause 5.32.6, e.g. MPTCP functionality
and/or ATSSS-LL functionality. Each steering functionality in the UE enables traffic steering, switching and
splitting across 3GPP access and non-3GPP access, in accordance with the ATSSS rules provided by the
network. The ATSSS-LL functionality is mandatory in the UE for MA PDU Session of type Ethernet.

- The UPF may support MPTCP Proxy functionality, which communicates with the MPTCP functionality in the
UE by using the MPTCP protocol [81].

- The UPF may support ATSSS-LL functionality, which is similar to the ATSSS-LL functionality defined for the
UE. There is no user plane protocol defined between the ATSSS-LL functionality in the UE and the ATSSS-LL
functionality in the UPF. The ATSSS-LL functionality in the UPF is not shown in the following three figures.

NOTE 1: ATSSS-LL functionality is needed in the 5GC for MA PDU Session of type Ethernet.

- In addition, the UPF supports Performance Measurement Functionality (PMF), which may be used by the UE to
obtain access performance measurements (see clause 5.32.5) over the user-plane of 3GPP access and/or over the
user-plane of non-3GPP access.

- The AMF, SMF and PCF are extended with new functionality that is further discussed in clause 5.32.

AMF N11 SMF N7 PCF

N2 N2
N1 N4
N1

MPTCP MPTCP
3GPP Access N3 Proxy
functionality
functionality
UE UPF N6 Data Network

ATSSS-LL
functionality PMF
Non-3GPP Access N3

Figure 4.2.10-1: Non-roaming and Roaming with Local Breakout architecture for ATSSS support

NOTE 2: The interactions between the UE and PCF that may be required for ATSSS control are specified in
TS 23.503 [45].

NOTE 3: A UPF that supports the MPTCP Proxy functionality and the PMF can be connected via an N9 reference
point, instead of the N3 reference point.

Figure 4.2.10-2 shows the 5G System Architecture for ATSSS support in a roaming case with home-routed traffic and
when the UE is registered to the same VPLMN over 3GPP and non-3GPP accesses. In this case, the MPTCP Proxy
functionality and the PMF are located in the H-UPF.

3GPP
Release 16 55 3GPP TS 23.501 V16.4.0 (2020-03)

VPLMN HPLMN

AMF N11 V-SMF N16 H-SMF N7 H-PCF

N2 N1
N4 N4
N1

N2
MPTCP N9 MPTCP
functionality 3GPP Access N3
Proxy
functionality
UE V-UPF N6
H-UPF Data Network

ATSSS-LL
functionality Non-3GPP Access N3 N9 PMF

Figure 4.2.10-2: Roaming with Home-routed architecture for ATSSS support (UE registered to the
same VPLMN)

Figure 4.2.10-3 shows the 5G System Architecture for ATSSS support in a roaming case with home-routed traffic and
when the UE is registered to a VPLMN over 3GPP access and to HPLMN over non-3GPP access (i.e. the UE is
registered to different PLMNs). In this case, the MPTCP Proxy functionality and the PMF are located in the H-UPF.

VPLMN HPLMN

AMF N11 V-SMF N16 H-SMF N7 H-PCF

N2
N4 N4 N11
N1

MPTCP MPTCP
functionality 3GPP Access N3 V-UPF N9 Proxy
functionality
UE N6
H-UPF Data Network

ATSSS-LL
functionality Non-3GPP Access N3 PMF

N2 N1

AMF

Figure 4.2.10-3: Roaming with Home-routed architecture for ATSSS support (UE registered to
different PLMNs)

4.3 Interworking with EPC

4.3.1 Non-roaming architecture
Figure 4.3.1-1 represents the non-roaming architecture for interworking between 5GS and EPC/E-UTRAN.

3GPP
Release 16 56 3GPP TS 23.501 V16.4.0 (2020-03)

HSS +
UDM

N10
PCF
S6a
N8
N7
SMF + N15
S5-C PGW-C
N4
UPF +
N11
PGW-U
S5-U
SGW
S11

N26
MME AMF

S1-MME
S1-U U N3 N2
N1

E-UTRAN NG-RAN

UE UE

Figure 4.3.1-1: Non-roaming architecture for interworking between 5GS and EPC/E-UTRAN

NOTE 1: N26 interface is an inter-CN interface between the MME and 5GS AMF in order to enable interworking
between EPC and the NG core. Support of N26 interface in the network is optional for interworking. N26
supports subset of the functionalities (essential for interworking) that are supported over S10.

NOTE 2: PGW-C + SMF and UPF + PGW-U are dedicated for interworking between 5GS and EPC, which are
optional and are based on UE MM Core Network Capability and UE subscription. UEs that are not
subject to 5GS and EPC interworking may be served by entities not dedicated for interworking, i.e. by
either by PGW or SMF/UPF.

NOTE 3: There can be another UPF (not shown in the figure above) between the NG-RAN and the UPF + PGW-U,
i.e. the UPF + PGW-U can support N9 towards an additional UPF, if needed.

NOTE 4: Figures and procedures in this specification that depict an SGW make no assumption whether the SGW is
deployed as a monolithic SGW or as an SGW split into its control-plane and user-plane functionality as
described in TS 23.214 [32].

4.3.2 Roaming architecture

Figure 4.3.2-1 represents the Roaming architecture with local breakout and Figure 4.3.2-2 represents the Roaming
architecture with home-routed traffic for interworking between 5GS and EPC/E-UTRAN.

3GPP
Release 16 57 3GPP TS 23.501 V16.4.0 (2020-03)

HSS +
UDM

h-PCF
HPLMN
VPLMN N24
N10
v-PCF
S6a N8
N7
SMF +
PGW-C N15
S5-C
N4
UPF +
PGW-U N11
S5-U
S11 SGW

N26 AMF
MME
S1-U U

N3 N2
S1-MME N1

E-UTRAN NG-RAN

UE UE

Figure 4.3.2-1: Local breakout roaming architecture for interworking between 5GS and EPC/E-UTRAN

NOTE 1: There can be another UPF (not shown in the figure above) between the NG-RAN and the UPF + PGW-U,
i.e. the UPF + PGW-U can support N9 towards the additional UPF, if needed.

NOTE 2: S9 interface from EPC is not required since no known deployment exists.

3GPP
Release 16 58 3GPP TS 23.501 V16.4.0 (2020-03)

HSS +
UDM

h-PCF N8
S6a N10
N7

SMF + N24
PGW-C
N4
UPF +
S8-C PGW-U
N16
HPLMN
VPLMN S8-U
v-PCF
SGW N9
v-SMF
N15
S11 N4
N11
UPF

N26
MME AMF
S1-U U

N3 N2
S1-MME

N1
E-UTRAN NG-RAN
RAN

UE UE

Figure 4.3.2-2: Home-routed roaming architecture for interworking between 5GS and EPC/E-UTRAN

4.3.3 Interworking between 5GC via non-3GPP access and E-UTRAN

connected to EPC

4.3.3.1 Non-roaming architecture

Figure 4.3.3-1 represents the non-roaming architecture for interworking between 5GC via non-3GPP access and EPC/E-
UTRAN.

3GPP
Release 16 59 3GPP TS 23.501 V16.4.0 (2020-03)

HSS +
UDM

N10
PCF
S6a
N8
N7
SMF + N15
S5-C PGW-C
N4
UPF +
N11
PGW-U
S5-U
SGW
S11

MME AMF

S1-MME
S1-U U N3 N2
N1

E-UTRAN N3IWF / TNGF

UE UE

Figure 4.3.3.1-1: Non-roaming architecture for interworking between 5GC via non-3GPP access and
EPC/E-UTRAN

NOTE 1: There can be another UPF (not shown in the figure above) between the N3IWF/TNGF and the UPF +
PGW-U, i.e. the UPF + PGW-U can support N9 towards an additional UPF, if needed.

NOTE 2: N26 interface is not precluded, but it is not shown in the figure because it is not required for the
interworking between 5GC via non-3GPP access and EPC/E-UTRAN.

4.3.3.2 Roaming architecture

Figure 4.3.3.2-1 represents the Roaming architecture with local breakout and Figure 4.3.3.2-2 represents the Roaming
architecture with home-routed traffic for interworking between 5GC via non-3GPP access and EPC/E-UTRAN.

3GPP
Release 16 60 3GPP TS 23.501 V16.4.0 (2020-03)

HSS +
UDM

h-PCF
HPLMN
VPLMN N24
N10
v-PCF
S6a N8
N7
SMF +
PGW-C N15
S5-C
N4
UPF +
PGW-U N11
S5-U
S11 SGW

MME AMF
S1-U U

N3 N2
S1-MME N1

E-UTRAN N3IWF / TNGF

UE UE

Figure 4.3.3.2-1: Local breakout roaming architecture for interworking between 5GC via non-3GPP
access and EPC/E-UTRAN

NOTE 1: There can be another UPF (not shown in the figure above) between the N3IWF/TNGF and the UPF +
PGW-U, i.e. the UPF + PGW-U can support N9 towards the additional UPF, if needed.

NOTE 2: S9 interface from EPC is not required since no known deployment exists.

NOTE 3: N26 interface is not precluded, but it not shown in the figure because it is not required for the
interworking between 5GC via non-3GPP access and EPC/E-UTRAN.

3GPP
Release 16 61 3GPP TS 23.501 V16.4.0 (2020-03)

HSS +
UDM

h-PCF N8
S6a N10
N7

SMF + N24
PGW-C
N4
UPF +
S8-C PGW-U
N16
HPLMN
VPLMN S8-U
v-PCF
SGW N9
v-SMF
N15
S11 N4
N11
UPF

MME AMF
S1-U U

N3 N2
S1-MME

E-UTRAN N3IWF / TNGF N1

UE UE

Figure 4.3.3.2-2: Home-routed roaming architecture for interworking between 5GC via non-3GPP
access and EPC/E-UTRAN

NOTE 4: N26 interface is not precluded, but it not shown in the figure because it is not required for the
interworking between 5GC via non-3GPP access and EPC/E-UTRAN.

4.3.4 Interworking between ePDG connected to EPC and 5GS

4.3.4.1 Non-roaming architecture

Figure 4.3.4.1-1 represents the non-roaming architecture for interworking between ePDG/EPC and 5GS.

3GPP
Release 16 62 3GPP TS 23.501 V16.4.0 (2020-03)

HSS +
UDM

N10
PCF
SWx
N8
N7
3GPP AAA S6b SMF +
server N15
PGW-C
N4
SWm UPF +
N11
PGW-U

S2b-C S2b-U

AMF

N3 N2
N1

ePDG NG-RAN

UE UE

Figure 4.3.4.1-1: Non-roaming architecture for interworking between ePDG/EPC and 5GS

NOTE 1: The details of the interfaces between the UE and the ePDG, and between EPC nodes (i.e. SWm, SWx,
S2b and S6b), are documented in TS 23.402 [43].

NOTE 2: Interworking with ePDG is only supported with GTP based S2b. S6b interface is optional (see
TS 23.502 [3] clause 4.11.4.3.6).

4.3.4.2 Roaming architectures

Figure 4.3.4.2-1 represents the Roaming architecture with local breakout and Figure 4.3.4.2-2 represents the Roaming
architecture with home-routed traffic for interworking between ePDG/EPC and 5GS.

3GPP
Release 16 63 3GPP TS 23.501 V16.4.0 (2020-03)

3GPP AAA SWx HSS +

server UDM

h-PCF
HPLMN
VPLMN N24

N10 v-PCF
SWd
N7 N8
3GPP AAA S6b SMF +
proxy PGW-C N15
N4
UPF +
SWm PGW-U N11

S2b-C S2b-U

AMF
N3 N2
N1

NG-RAN
ePDG

UE
UE

Figure 4.3.4.2-1: Local breakout roaming architecture for interworking between ePDG/EPC and 5GS

NOTE 1: The details of the interfaces between the UE and the ePDG, and between EPC nodes (i.e. SWm, SWd,
SWx, S2b and S6b), are documented in TS 23.402 [43].

NOTE 2: Interworking with ePDG is only supported with GTP based S2b. S6b interface is optional (see
TS 23.502 [3] clause 4.11.4.3.6).

3GPP
Release 16 64 3GPP TS 23.501 V16.4.0 (2020-03)

SWx
HSS +
UDM

h-PCF N8

N10 N7
3GPP AAA S6b
SMF + N24
server
PGW-C
N4

SWd UPF +
PGW-U
N16
HPLMN
VPLMN
v-PCF
N9
S2b-C S2b-U v-SMF
3GPP AAA
proxy N15
N4
N11
UPF
SWm

AMF

N3 N2

N1
ePDG NG-RAN
RAN

UE UE

Figure 4.3.4.2-2: Home-routed roaming architecture for interworking between ePDG/EPC and 5GS

NOTE 1: The details of the interfaces between the UE and the ePDG, and between EPC nodes (i.e. SWm, SWd,
SWx, S2b and S6b), are documented in TS 23.402 [43].

NOTE 2: Interworking with ePDG is only supported with GTP based S2b. S6b interface is optional (see
TS 23.502 [3] clause 4.11.4.3.6).

4.3.5 Service Exposure in Interworking Scenarios

4.3.5.1 Non-roaming architecture

Figure 4.3.5.1-1 shows the non-roaming architecture for Service Exposure for EPC-5GC Interworking. If the UE is
capable of mobility between EPS and 5GS, the network is expected to associate the UE with an SCEF+NEF node for
Service Capability Exposure.

3GPP
Release 16 65 3GPP TS 23.501 V16.4.0 (2020-03)

AF/AS AF/AS

N33 AF/AS N33

and T8 and T8
N33 N33
and T8 and T8

API Set API Set

TRUST DOMAIN

SCEF+NEF SCEF+NEF

EPC 5GC
... EPC 5GC
Interface Interface Interface Interface
(See (See (See (See
Note 2) Note 3) Note 2) Note 3)

EPC EPC NF 1 NF 2 EPC EPC NF n-1 NF n

node 1 node 2 node n-1 node n

Figure 4.3.5.1 1: Non-roaming Service Exposure Architecture for EPC-5GC Interworking

NOTE 1: In Figure 4.3.5.1-1, Trust domain for SCEF+NEF is same as Trust domain for SCEF as defined in
TS 23.682 [36].

NOTE 2: In Figure 4.3.5.1-1, EPC Interface represents southbound interfaces between SCEF and EPC nodes e.g.
the S6t interface between SCEF and HSS, the T6a interface between SCEF and MME, etc. All
southbound interfaces from SCEF are defined in TS 23.682 [36] and are not shown for the sake of
simplicity.

NOTE 3: In Figure 4.3.5.1-1, 5GC Interface represents southbound interfaces between NEF and 5GC Network
Functions e.g. N29 interface between NEF and SMF, N30 interface between NEF and PCF, etc. All
southbound interfaces from NEF are not shown for the sake of simplicity.

NOTE 4: Interaction between the SCEF and NEF within the combined SCEF+NEF is required. For example, when
the SCEF+NEF supports monitoring APIs, the SCEF and NEF need to share context and state
information on a UE's configured monitoring events if the UE moves between from EPC and 5GC.

NOTE 5: The north-bound APIs which can be supported by an EPC or 5GC network are discovered by the
SCEF+NEF node via the CAPIF function and/or via local configuration of the SCEF+NEF node.
Different sets of APIs can be supported by the two network types.

4.3.5.2 Roaming architectures

Figure 4.3.5.2-1 represents the roaming architecture for Service Exposure for EPC-5GC Interworking. This architecture
is applicable to both the home routed roaming and local breakout roaming.

3GPP
Release 16 66 3GPP TS 23.501 V16.4.0 (2020-03)

AF/AS AF/AS

N33 AF/AS N33

and T8 and T8
N33 N33
and T8 and T8

API Set API Set

SCEF+NEF SCEF+NEF
TRUST DOMAIN

EPC 5GC Nudm EPC 5GC

S6t S6t
interface interface interface interface Nudm
EPC
nodes
HSS
T7
NFs UDM
N53
... EPC
nodes
HSS NFs UDM

H-PLMN
EPC
V-PLMN
IWK-SCEF I-NEF interface N51 5GC
interface
EPC
EPC AMF NFs
nodes
interface N51i 5GC
interface
EPC
AMF NFs
nodes

Figure 4.3.5.2-1: Roaming Service Exposure Architecture for EPC-5GC Interworking

NOTE: Figure 4.3.5.2-1 does not include all the interfaces, and network elements or network functions that may
be connected to SCEF+NEF.

4.4 Specific services

4.4.1 Public Warning System
The Public Warning System architecture for 5G System is specified in TS 23.041 [46].

4.4.2 SMS over NAS

4.4.2.1 Architecture to support SMS over NAS

Figure 4.4.2.1-1 shows the non-roaming architecture to support SMS over NAS using the Service-based interfaces
within the Control Plane.

to/from to/from
SMS-GMSC/IWMSC SMS-GMSC/IWMSC
SMS Router SMS Router
to/from
IP-SM-GW

SMSF UDM

Nsmsf Nudm

Namf
N1
UE AMF

Figure 4.4.2.1-1: Non-roaming System Architecture for SMS over NAS

Figure 4.4.2.1-2 shows the non-roaming architecture to support SMS over NAS using the reference point representation.

3GPP
Release 16 67 3GPP TS 23.501 V16.4.0 (2020-03)

to/from
UE UDM SMS-GMSC/IWMSC
SMS Router
N8
N1 N21
to/from IP-SM-GW
N20 SMSF to/from
AMF
(SMS Function) SMS-GMSC/IWMSC
SMS Router

Figure 4.4.2.1-2: Non-roaming System Architecture for SMS over NAS in reference point
representation

NOTE 1: SMS Function (SMSF) may be connected to the SMS-GMSC/IWMSC/SMS Router via one of the
standardized interfaces as shown in TS 23.040 [5].

NOTE 2: UDM may be connected to the SMS-GMSC/IWMSC/SMS Router via one of the standardized interfaces
as shown in TS 23.040 [5].

NOTE 3: Each UE is associated with only one SMS Function in the registered PLMN.

NOTE 4: SMSF re-allocation while the UE is in RM-REGISTERED state in the serving PLMN is not supported in
this Release of the specification. When serving AMF is re-allocated for a given UE, the source AMF
includes SMSF identifier as part of UE context transfer to target AMF. If the target AMF, e.g. in the case
of inter-PLMN mobility, detects that no SMSF has been selected in the serving PLMN, then the AMF
performs SMSF selection as specified in clause 6.3.10.

NOTE 5: To support MT SMS domain selection by IP-SM-GW/SMS Router, IP-SM-GW/SMS Router may
connect to SGs MSC, MME and SMSF via one of the standardized interfaces as shown in TS 23.040 [5].

Figure 4.4.2.1-3 shows the roaming architecture to support SMS over NAS using the Service-based interfaces within the
Control Plane.

to/from to/from
SMS-GMSC/IWMSC SMS-GMSC/IWMSC
to/from SMS Router SMS Router
IP-SM-GW

SMSF UDM

Nsmsf Nudm

Namf
N1
UE AMF

VPLMN HPLMN

Figure 4.4.2.1-3: Roaming architecture for SMS over NAS

Figure 4.4.2.1-4 shows the roaming architecture to support SMS over NAS using the reference point representation.

3GPP
Release 16 68 3GPP TS 23.501 V16.4.0 (2020-03)

UE UDM
N8

N1
N21
to/from IP-SM-GW

N20 SMSF to/from

AMF SMS-GMSC/IWMSC
(SMS Function)
SMS Router

VPLMN HPLMN

Figure 4.4.2.1-4: Roaming architecture for SMS over NAS in reference point representation

4.4.2.2 Reference point to support SMS over NAS

N1: Reference point for SMS transfer between UE and AMF via NAS.

Following reference points are realized by service based interfaces:

N8: Reference point for SMS Subscription data retrieval between AMF and UDM.

N20: Reference point for SMS transfer between AMF and SMS Function.

N21: Reference point for SMS Function address registration management and SMS Management Subscription
data retrieval between SMS Function and UDM.

4.4.2.3 Service based interface to support SMS over NAS

Nsmsf: Service-based interface exhibited by SMSF.

4.4.3 IMS support

IMS support for 5GC is defined in TS 23.228 [15].

The 5G System architecture supports N5 interface between PCF and P-CSCF and supports Rx interface between PCF
and P-CSCF, to enable IMS service. See TS 23.228 [15], TS 23.503 [45] and TS 23.203 [4].

NOTE 1: Rx support between PCF and P-CSCF is for backwards compatibility for early deployments using
Diameter between IMS and 5GC functions.

NOTE 2: When service based interfaces are used between the PCF and P-CSCF in the same PLMN, the P-CSCF
performs the functions of a trusted AF in the 5GC.

4.4.4 Location services

4.4.4.1 Architecture to support Location Services

Location Service feature is optional and applicable to both regulatory services and commercial services in this Release
of the specification. The non-roaming and roaming architecture to support Location Services are defined in clause 4.2 of
TS 23.273 [87].

4.4.4.2 Reference point to support Location Services

The reference points to support Location Services are defined in clause 4.4 of TS 23.273 [87].

4.4.4.3 Service Based Interfaces to support Location Services

The Service Based Interfaces to support Location Services are defined in clause 4.5 of TS 23.273 [87].

3GPP
Release 16 69 3GPP TS 23.501 V16.4.0 (2020-03)

4.4.5 Application Triggering Services

See TS 23.502 [3] clause 5.2.6.1.

Application trigger message contains information that allows the network to route the message to the appropriate UE
and the UE to route the message to the appropriate application. The information destined to the application, excluding
the information to route it, is referred to as the Trigger payload. The Trigger payload is implementation specific.

NOTE: The application in the UE may perform actions indicated by the Trigger payload when the Triggered
payload is received at the UE. For example initiation of immediate or later communication with the
application server based on the information contained in the Trigger payload, which includes the PDU
Session Establishment procedure if the related PDU Session is not already established.

4.4.6 5G LAN-type Services

4.4.6.1 User plane architecture to support 5G LAN-type service

The general User Plane architectures described in clause 4.2.3 and clause 4.2.4 apply to 5G LAN-type services, with the
additional options described in this clause.

Figure 4.4.6.1-1 depicts the non-roaming user plane architecture to support 5G LAN-type service using local switch.

UE 1 (R)AN N3 I-UPF N9
PSA UPF
(local
switch)
UE 2 (R)AN N3 I-UPF N9

Figure 4.4.6.1-1: Local-switch based user plane architecture in non-roaming scenario

Figure 4.4.6.1-2 depicts the non-roaming user plane architecture to support 5G LAN-type service using N19 tunnel.

UE 1 (R)AN N3 I-UPF N9 PSA

N19

UE 2 (R)AN N3 I-UPF N9 PSA

Figure 4.4.6.1-2: N19-based user plane architecture in non-roaming scenario

4.4.6.2 Reference points to support 5G LAN-type service

N19: Reference point between two UPFs for direct routing of traffic between different PDU Sessions without
using N6. It has a per 5G VN group granularity.

4.4.7 MSISDN-less MO SMS Service

MSISDN-less MO SMS via T4 is subscription based. The subscription provides the information whether a UE is
allowed to originate MSISDN-less MO SMS.

The UE is pre-configured with the Service Centre address that points to SMS-SC that performs this MO SMS delivery
via NEF delivery procedure. The recipient of this short message is set to the pre-configured address of the AF (i.e.
Address of the destination SME). If UE has multiple GPSIs associated to the same IMSI, the GPSI that is associated
with an SMS may be determined from the UE's IMSI and the Application Port ID value in the TP-User-Data field (see
TS 23.040 [5]). The NEF may obtain the GPSI by querying the UDM with the IMSI and application port ID.

3GPP
Release 16 70 3GPP TS 23.501 V16.4.0 (2020-03)

UE is aware whether the MO SMS delivery status (success or fail) based on the SMS delivery report from SMS-SC.
The network does not perform any storing and forwarding functionality for MO SMS.

See TS 23.502 [3] clause 5.2.6 for a description of NEF Services and Service Operations.

4.4.8 Time Sensitive Communication

4.4.8.1 General
The 5G System is extended to support Time sensitive communication as defined in IEEE P802.1Qcc [95].

In this Release of the specification, integration of 5G System with TSN networks that are based on IEEE TSN
(IEEE P802.1Qcc [95]) is supported. IEEE TSN is a set of standards to define mechanisms for the time-sensitive (i.e.
deterministic) transmission of data over Ethernet networks.

4.4.8.2 Architecture to support Time Sensitive Communication

The 5G System is integrated with the external network as a TSN bridge. This "logical" TSN bridge (see Figure 4.4.8.2-
1) includes TSN Translator functionality for interoperation between TSN System and 5G System both for user plane
and control plane. 5GS TSN translator functionality consists of Device-side TSN translator (DS-TT) and Network-side
TSN translator (NW-TT). 5G System specific procedures in 5GC and RAN, wireless communication links, etc. remain
hidden from the TSN network. To achieve such transparency to the TSN network and the 5GS to appear as any other
TSN Bridge, the 5GS provides TSN ingress and egress ports via DS-TT and NW-TT. DS-TT and NW-TT optionally
support:

- hold and forward functionality for the purpose of de-jittering;

- per-stream filtering and policing as defined in IEEE 802.1Q [98] clause 8.6.5.1.

DS-TT optionally supports link layer connectivity discovery and reporting as defined in IEEE 802.1AB [97] for
discovery of Ethernet devices attached to DS-TT. NW-TT supports link layer connectivity discovery and reporting as
defined in IEEE 802.1AB [97] for discovery of Ethernet devices attached to NW-TT. If a DS-TT does not support link
layer connectivity discovery and reporting, then NW-TT performs link layer connectivity discovery and reporting as
defined in IEEE 802.1AB [97] for discovery of Ethernet devices attached to DS-TT on behalf of DS-TT.

NOTE 1: If NW-TT performs link layer connectivity discovery and reporting on behalf of DS-TT, it is assumed
that LLDP frames are transmitted between NW-TT and UE on the default QoS Flow. Alternatively, SMF
can establish a dedicated QoS Flow matching on the Ethertype defined for LLDP (IEEE 802.1AB [97]).

There are three TSN configuration models defined in IEEE P802.1Qcc [95]. Amongst the three models:

- fully centralized model is supported in this release of the specification;

- fully distributed model is not supported in this release of the specification;

- hybrid model is not supported in this Release of the specification.

NOTE 2: This release only supports interworking with TSN using IEEE 802.1Q [98] clause 8.6.8.4 based
scheduled traffic and IEEE 802.1Q [98] clause 8.6.5.1 based per-stream filtering and policy.

3GPP
Release 16 71 3GPP TS 23.501 V16.4.0 (2020-03)

Logical (TSN) Bridge

Device
side of
Bridge

UDM N52 NEF N 33

N8 N10 N30

AMF N11 SMF N7 PCF N5 TSN AF C -Plane

N2 N4
N1 TSN

System

TSN NW -TT
DS -TT UE (R)AN N3 UPF U -plane
System

N9

Figure 4.4.8.2-1: System architecture view with 5GS appearing as TSN bridge

NOTE 3: Whether DS-TT and UE are combined or are separate is up to implementation.

5 High level features

5.1 General
Clause 5 specifies the high level functionality and features of the 5G System for both 3GPP and Non-3GPP access and
for the interoperability with the EPC defined in TS 23.401 [26].

5.2 Network Access Control

5.2.1 General
Network access is the means for the user to connect to 5G CN. Network access control comprises the following
functionality:

- Network selection,

- Identification and authentication,

- Authorisation,

- Access control and barring,

- Policy control,

- Lawful Interception.

5.2.2 Network selection

In order to determine to which PLMN to attempt registration, the UE performs network selection. The network selection
procedure comprises two main parts, PLMN selection and access network selection. The requirements for the PLMN

3GPP
Release 16 72 3GPP TS 23.501 V16.4.0 (2020-03)

selection are specified in TS 22.011 [25] and the procedures are in TS 23.122 [17]. The access network selection part
for the 3GPP access networks is specified in TS 36.300 [30] for E-UTRAN and in TS 38.300 [27] for the NR.

5.2.3 Identification and authentication

The network may authenticate the UE during any procedure establishing a NAS signalling connection with the UE. The
security architecture is specified in TS 33.501 [29]. The network may optionally perform an PEI check with 5G-EIR.

5.2.4 Authorisation
The authorisation for connectivity of the subscriber to the 5GC and the authorization for the services that the user is
allowed to access based on subscription (e.g. Operator Determined Barring, Roaming restrictions, Access Type and
RAT Type currently in use) is evaluated once the user is successfully identified and authenticated. This authorization is
executed during UE Registration procedure.

5.2.5 Access control and barring

When the UE needs to transmit an initial NAS message, the UE shall request to establish an RRC Connection first and
the NAS shall provide the RRC establishment related information to the lower layer. The RAN handles the RRC
Connection with priority during and after RRC Connection Establishment procedure, when UE indicates priority in
Establishment related information

Under high network load conditions, the network may protect itself against overload by using the Unified Access
Control functionality for 3GPP access specified in TS 22.261 [2], TS 24.501 [47] and TS 38.300 [27] to limit access
attempts from UEs. Depending on network configuration, the network may determine whether certain access attempt
should be allowed or blocked based on categorized criteria, as specified in TS 22.261 [2] and TS 24.501 [47]. The NG-
RAN may broadcast barring control information associated with Access Categories and Access Identities as specified in
TS 38.300 [27].

The NG-RAN node may initiate such Unified Access Control when:

- AMFs request to restrict the load for UEs that access the network by sending OVERLOAD START message
containing conditions defined in clause 5.19.5.2, or

- requested by OAM, or

- triggered by NG-RAN itself.

If the NG-RAN node takes a decision to initiate UAC because of the reception of the N2 interface OVERLOAD
START messages, the NG-RAN should only initiate such procedure if all the AMFs relevant to the request contained in
the OVERLOAD START message and connected to this NG-RAN node request to restrict the load for UEs that access
the network.

If the UE supports both N1 and S1 modes NAS and, as defined in TS 23.401 [26], the UE is configured for Extended
Access Barring (EAB) but is not configured with a permission for overriding Extended Access Barring (EAB), when
the UE wants to access the 5GS it shall perform Unified Access Control checks for Access Category 1 on receiving an
indication from the upper layers as defined in TS 24.501 [47], TS 38.331 [28], TS 36.331 [51].

If the UE supports both N1 and S1 modes NAS and, as defined in TS 23.401 [26], the UE is configured with a
permission for overriding Extended Access Barring (EAB), when the UE wants to access the 5GS it shall ignore
Unified Access Control checks for Access Category 1 on receiving an indication from the upper layers, as defined in
TS 24.501 [47].

NOTE: UE signalling of Low Access Priority indication over N1 in 5GS is not supported in this release of the
specification.

Operator may provide one or more PLMN-specific Operator-defined access category definitions to the UE using NAS
signalling, and the UE handles the Operator-defined access category definitions stored for the Registered PLMN, as
specified in TS 24.501 [47].

3GPP
Release 16 73 3GPP TS 23.501 V16.4.0 (2020-03)

5.2.6 Policy control

Network access control including service authorization may be influenced by Policy control, as specified in clause 5.14.

5.2.7 Lawful Interception

For definition and functionality of Lawful Interception, please see TS 33.126 [35].

5.3 Registration and Connection Management

5.3.1 General
The Registration Management is used to register or deregister a UE/user with the network, and establish the user
context in the network. The Connection Management is used to establish and release the signalling connection between
the UE and the AMF.

5.3.2 Registration Management

5.3.2.1 General
A UE/user needs to register with the network to receive services that requires registration. Once registered and if
applicable the UE updates its registration with the network (see TS 23.502 [3]):

- periodically, in order to remain reachable (Periodic Registration Update); or

- upon mobility (Mobility Registration Update); or

- to update its capabilities or re-negotiate protocol parameters (Mobility Registration Update).

The Initial Registration procedure involves execution of Network Access Control functions as defined in clause 5.2 (i.e.
user authentication and access authorization based on subscription profiles in UDM). As result of the Registration
procedure, the identifier of the serving AMF serving the UE in the access through which the UE has registered will be
registered in UDM.

The registration management procedures are applicable over both 3GPP access and Non-3GPP access. The 3GPP and
Non-3GPP RM states are independent of each other, see clause 5.3.2.4.

5.3.2.2 5GS Registration Management states

5.3.2.2.1 General
Two RM states are used in the UE and the AMF that reflect the registration status of the UE in the selected PLMN:

- RM-DEREGISTERED.

- RM-REGISTERED.

5.3.2.2.2 RM-DEREGISTERED state

In the RM-DEREGISTERED state, the UE is not registered with the network. The UE context in AMF holds no valid
location or routing information for the UE so the UE is not reachable by the AMF. However, some parts of UE context
may still be stored in the UE and the AMF e.g. to avoid running an authentication procedure during every Registration
procedure.

In the RM-DEREGISTERED state, the UE shall:

- attempt to register with the selected PLMN using the Initial Registration procedure if it needs to receive service
that requires registration (see TS 23.502 [3] clause 4.2.2.2).

3GPP
Release 16 74 3GPP TS 23.501 V16.4.0 (2020-03)

- remain in RM-DEREGISTERED state if receiving a Registration Reject upon Initial Registration (see
TS 23.502 [3] clause 4.2.2.2).

- enter RM-REGISTERED state upon receiving a Registration Accept (see TS 23.502 [3] clause 4.2.2.2).

When the UE RM state in the AMF is RM-DEREGISTERED, the AMF shall:

- when applicable, accept the Initial Registration of a UE by sending a Registration Accept to this UE and enter
RM-REGISTERED state for the UE (see TS 23.502 [3] clause 4.2.2.2); or

- when applicable, reject the Initial Registration of a UE by sending a Registration Reject to this UE (see
TS 23.502 [3] clause 4.2.2.2).

5.3.2.2.3 RM-REGISTERED state

In the RM-REGISTERED state, the UE is registered with the network. In the RM-REGISTERED state, the UE can
receive services that require registration with the network.

In the RM-REGISTERED state, the UE shall:

- perform Mobility Registration Update procedure if the current TAI of the serving cell (see TS 37.340 [31]) is not
in the list of TAIs that the UE has received from the network in order to maintain the registration and enable the
AMF to page the UE;

- perform Periodic Registration Update procedure triggered by expiration of the periodic update timer to notify the
network that the UE is still active.

- perform a Mobility Registration Update procedure to update its capability information or to re-negotiate protocol
parameters with the network;

- perform Deregistration procedure (see TS 23.502 [3] clause 4.2.2.3.1), and enter RM-DEREGISTERED state,
when the UE needs to be no longer registered with the PLMN. The UE may decide to deregister from the
network at any time.

- enter RM-DEREGISTERED state when receiving a Registration Reject message or a Deregistration message.
The actions of the UE depend upon the 'cause value' in the Registration Reject or Deregistration message. See
TS 23.502 [3] clause 4.2.2.

When the UE RM state in the AMF is RM-REGISTERED, the AMF shall:

- perform Deregistration procedure (see TS 23.502 [3] clauses 4.2.2.3.2, 4.2.2.3.3), and enter RM-
DEREGISTERED state for the UE, when the UE needs to be no longer registered with the PLMN. The network
may decide to deregister the UE at any time;

- perform Implicit Deregistration at any time after the Implicit Deregistration timer expires. The AMF shall enter
RM-DEREGISTERED state for the UE after Implicit Deregistration;

- when applicable, accept or reject Registration Requests or Service Requests from the UE.

5.3.2.2.4 5GS Registration Management State models

Registration Reject Registration Update Accept

Deregistration
Registration Reject
RM-DEREGISTERED RM-REGISTERED
Registration Accept

Figure 5.3.2.2.4-1: RM state model in UE

3GPP
Release 16 75 3GPP TS 23.501 V16.4.0 (2020-03)

Registration Reject Registration Update Accept

Deregistration
Registration Reject
RM-DEREGISTERED RM-REGISTERED
Registration Accept

Figure 5.3.2.2.4-2: RM state model in AMF

5.3.2.3 Registration Area management

Registration Area management comprises the functions to allocate and reallocate a Registration area to a UE.
Registration area is managed per access type i.e., 3GPP access or Non-3GPP access.

When a UE registers with the network over the 3GPP access, the AMF allocates a set of tracking areas in TAI List to
the UE. When the AMF allocates registration area, i.e. the set of tracking areas in TAI List, to the UE it may take into
account various information (e.g. Mobility Pattern and Allowed/Non-Allowed Area (refer to clause 5.3.4.1)). An AMF
which has the whole PLMN as serving area may alternatively allocate the whole PLMN ("all PLMN") as registration
area to a UE in MICO mode (refer to clause 5.4.1.3).

The 5G System shall support allocating a Registration Area using a single TAI List which includes tracking areas of any
NG-RAN nodes in the Registration Area for a UE.

A single TAI dedicated to Non-3GPP access, the N3GPP TAI, is defined in a PLMN and applies within the PLMN.

When a UE registers with the network over the Non-3GPP access, the AMF allocates a registration area that only
includes the N3GPP TAI to the UE.

When generating the TAI list, the AMF shall include only TAIs that are applicable on the access type (i.e. 3GPP access
or Non-3GPP access) where the TAI list is sent.

NOTE: To prevent extra signalling load resulting from Mobility Registration Update occurring at every RAT
change, it is preferable to avoid generating a RAT-specific TAI list for a UE supporting more than one
RAT.

For all 3GPP Access RATs in NG-RAN and for Non-3GPP Access, the 5G System supports the TAI format as
specified in TS 23.003 [19] consisting of MCC, MNC and a 3-byte TAC only.

The additional aspects for registration management when a UE is registered over one access type while the UE is
already registered over the other access type is further described in clause 5.3.2.4.

To ensure a UE initiates a Mobility Registration procedure when performing inter-RAT mobility to or from NB-IoT, a
Tracking Area shall not contain both NB-IoT and other RATs cells (e.g. WB-E-UTRA, NR), and the AMF shall not
allocate a TAI list that contains both NB-IoT and other RATs Tracking Areas.

For 3GPP access the AMF determines the RAT type the UE is camping on based on the Global RAN Node IDs
associated with the N2 interface and additionally the Tracking Area indicated by NG-RAN. When the UE is accessing
NR using unlicensed bands, as defined in clause 5.4.8, an indication is provided in N2 interface as defined in
TS 38.413 [34].

The AMF may also determine more precise RAT Type information based on further information received from NG-
RAN:

- The AMF may determine the RAT Type to be LTE-M as defined in clause 5.31.20; or

- The AMF may determine the RAT Type to be NR using unlicensed bands, as defined in clause 5.4.8.

For Non-3GPP accesses the AMF determines the RAT type the UE is camping based on the 5G-AN node associated
with N2 interface as follows:

- The RAT type is Untrusted Non-3GPP if the 5G-AN node has a Global N3IWF Node ID;

3GPP
Release 16 76 3GPP TS 23.501 V16.4.0 (2020-03)

- The RAT type is Trusted Non-3GPP if the 5G-AN node has a Global TNGF Node ID; and

- The RAT type is Wireline if the 5G-AN node has a Global W-AGF Node ID.

For Non-3GPP access the AMF may also use the User Location Information provided at N2 connection setup to
determine a more precise RAT Type, e.g. identifying IEEE 802.11 access.

When the 5G-AN node has either a Global N3IWF Node ID, or a Global TNGF Node ID, or a Global W-AGF Node ID,
the Access Type is Non-3GPP Access.

5.3.2.4 Support of a UE registered over both 3GPP and Non-3GPP access

This clause applies to Non-3GPP access network corresponding to the Untrusted Non-3GPP access network, to the
Trusted Non-3GPP and to the W-5GAN. In the case of W-5GAN the UE mentioned in this clause corresponds to the
5G-RG.

For a given serving PLMN there is one RM context for a UE for each access, e.g. when the UE is consecutively or
simultaneously served by a 3GPP access and by a non-3GPP access (i.e. via an N3IWF, TNGF and W-AGF) of the
same PLMN. UDM manages separate/independent UE Registration procedures for each access.

When served by the same PLMN for 3GPP and non-3GPP accesses, an UE is served by the same AMF except in the
temporary situation described in clause 5.17 i.e. after a mobility from EPS while the UE has PDU Sessions associated
with non-3GPP access.

An AMF associates multiple access-specific RM contexts for an UE with:

- a 5G-GUTI that is common to both 3GPP and Non-3GPP accesses. This 5G-GUTI is globally unique.

- a Registration state per access type (3GPP / Non-3GPP)

- a Registration Area per access type: one Registration Area for 3GPP access and another Registration Area for
non 3GPP access. Registration Areas for the 3GPP access and the Non-3GPP access are independent.

- timers for 3GPP access:

- a Periodic Registration timer; and

- a Mobile Reachable timer and an Implicit Deregistration timer.

- timers for non-3GPP access:

- a UE Non-3GPP Deregistration timer; and

- a Network Non-3GPP Implicit Deregistration timer.

The AMF shall not provide a Periodic Registration Timer for the UE over a Non-3GPP access. Consequently, the UE
need not perform Periodic Registration Update procedure over Non-3GPP access. Instead, during the Initial
Registration procedure and Re-registration, the UE is provided by the network with a UE Non-3GPP Deregistration
timer that starts when the UE enters non-3GPP CM-IDLE state.

When the 3GPP access and the non-3GPP access for the same UE are served by the same PLMN, the AMF assigns the
same 5G-GUTI for use over both accesses. Such a 5G-GUTI may be assigned or re-assigned over any of the 3GPP and
Non-3GPP accesses. The 5G-GUTI is assigned upon a successful registration of the UE, and is valid over both 3GPP
and Non-3GPP access to the same PLMN for the UE. Upon performing an initial access over the Non-3GPP access or
over the 3GPP access while the UE is already registered with the 5G System over another access of the same PLMN,
the UE provides the native 5G-GUTI for the other access. This enables the AN to select an AMF that maintains the UE
context created at the previous Registration procedure via the GUAMI derived from the 5G-GUTI, and enables the
AMF to correlate the UE request to the existing UE context via the 5G-GUTI.

If the UE is performing registration over one access and intends to perform registration over the other access in the
same PLMN (e.g. the 3GPP access and the selected N3IWF, TNGF or W-AGF are located in the same PLMN), the UE
shall not initiate the registration over the other access until the Registration procedure over first access is completed.

NOTE: To which access the UE performs registration first is up to UE implementation.

3GPP
Release 16 77 3GPP TS 23.501 V16.4.0 (2020-03)

When the UE is successfully registered to an access (3GPP access or Non-3GPP access respectively) and the UE
registers via the other access:

- if the second access is located in the same PLMN (e.g. the UE is registered via a 3GPP access and selects a
N3IWF, TNGF or W-AGF located in the same PLMN), the UE shall use for the registration to the PLMN
associated with the new access the 5G-GUTI that the UE has been provided with at the previous registration or
UE configuration update procedure for the first access in the same PLMN. Upon successful completion of the
registration to the second access, if the network included a 5G-GUTI in the Registration Accept, the UE shall use
the 5G-GUTI received in the Registration Accept for both registrations. If no 5G-GUTI is included in the
Registration Accept, then the UE uses the 5G-GUTI assigned for the existing registration also for the new
registration.

- if the second access is located in a PLMN different from the registered PLMN of the first access (i.e. not the
registered PLMN), (e.g. the UE is registered to a 3GPP access and selects a N3IWF, TNGF or W-AGF located in
a PLMN different from the PLMN of the 3GPP access, or the UE is registered over Non-3GPP and registers to a
3GPP access in a PLMN different from the PLMN of the N3IWF, TNGF or W-AGF), the UE shall use for the
registration to the PLMN associated with the new access a 5G-GUTI only if it has got one previously received
from a PLMN that is not the same as the PLMN the UE is already registered with. If the UE does not include a
5G-GUTI, the SUCI shall be used for the new registration. Upon successful completion of the registration to the
second access, the UE has the two 5G-GUTIs (one per PLMN).

A UE supporting registration over both 3GPP and Non-3GPP access to two PLMNs shall be able to handle two separate
registrations, including two 5G-GUTIs, one per PLMN, and two associated equivalent PLMN lists.

When a UE 5G-GUTI assigned during a Registration procedure over 3GPP (e.g. the UE registers first over a 3GPP
access) is location-dependent, the same UE 5G-GUTI can be re-used over the Non-3GPP access when the selected
N3IWF, TNGF or W-AGF function is in the same PLMN as the 3GPP access. When an UE 5G-GUTI is assigned
during a Registration procedure performed over a Non 3GPP access (e.g. the UE registers first over a non-3GPP
access), the UE 5G-GUTI may not be location-dependent, so that the UE 5G-GUTI may not be valid for NAS
procedures over the 3GPP access and, in this case, a new AMF is allocated during the Registration procedure over the
3GPP access.

When the UE is registered first via 3GPP access, if the UE registers to the same PLMN via Non-3GPP access, the UE
shall send the GUAMI obtained via 3GPP access to the N3IWF, TNGF or W-AGF, which uses the received GUAMI to
select the same AMF as the 3GPP access.

The Deregistration Request message indicates whether it applies to the 3GPP access the Non-3GPP access, or both.

If the UE is registered on both 3GPP and Non-3GPP accesses and it is in CM-IDLE over Non-3GPP access, then the
UE or AMF may initiate a Deregistration procedure over the 3GPP access to deregister the UE only on the Non-3GPP
access, in which case all the PDU Sessions which are associated with the Non-3GPP access shall be released.

If the UE is registered on both 3GPP and non-3GPP accesses and it is in CM-IDLE over 3GPP access and in CM-
CONNECTED over non-3GPP access, then the UE may initiate a Deregistration procedure over the non-3GPP access
to deregister the UE only on the 3GPP access, in which case all the PDU Sessions which are associated with the 3GPP
access shall be released.

Registration Management over Non-3GPP access is further defined in clause 5.5.1.

5.3.3 Connection Management

5.3.3.1 General
Connection management comprises the functions of establishing and releasing a NAS signalling connection between a
UE and the AMF over N1. This NAS signalling connection is used to enable NAS signalling exchange between the UE
and the core network. It comprises both the AN signalling connection between the UE and the AN (RRC Connection
over 3GPP access or UE-N3IWF connection over untrusted N3GPP access or UE-TNGF connection over trusted
N3GPP access) and the N2 connection for this UE between the AN and the AMF.

3GPP
Release 16 78 3GPP TS 23.501 V16.4.0 (2020-03)

5.3.3.2 5GS Connection Management states

5.3.3.2.1 General
Two CM states are used to reflect the NAS signalling Connection of the UE with the AMF:

- CM-IDLE

- CM-CONNECTED

The CM state for 3GPP access and Non-3GPP access are independent of each other, i.e. one can be in CM-IDLE state
at the same time when the other is in CM-CONNECTED state.

5.3.3.2.2 CM-IDLE state

A UE in CM-IDLE state has no NAS signalling connection established with the AMF over N1. The UE performs cell
selection/cell reselection according to TS 38.304 [50] and PLMN selection according to TS 23.122 [17].

There are no AN signalling connection, N2 connection and N3 connections for the UE in the CM-IDLE state.

If the UE is both in CM-IDLE state and in RM-REGISTERED state, the UE shall, unless otherwise specified in
clause 5.3.4.1:

- Respond to paging by performing a Service Request procedure (see TS 23.502 [3] clause 4.2.3.2), unless the UE
is in MICO mode (see clause 5.4.1.3);

- perform a Service Request procedure when the UE has uplink signalling or user data to be sent (see
TS 23.502 [3] clause 4.2.3.2). Specific conditions apply for LADN, see clause 5.6.5.

When the UE state in the AMF is RM-REGISTERED, UE information required for initiating communication with the
UE shall be stored. The AMF shall be able to retrieve stored information required for initiating communication with the
UE using the 5G-GUTI.

NOTE: In 5GS there is no need for paging using the SUPI/SUCI of the UE.

The UE provides 5G-S-TMSI as part of AN parameters during AN signalling connection establishment as specified in
TS 38.331 [28] and TS 36.331 [51]. The UE shall enter CM-CONNECTED state whenever an AN signalling
connection is established between the UE and the AN (entering RRC Connected state over 3GPP access, or at the
establishment of the UE-N3IWF connectivity over untrusted non-3GPP access or the UE-TNGF connectivity over
trusted non-3GPP access). The transmission of an Initial NAS message (Registration Request, Service Request or
Deregistration Request) initiates the transition from CM-IDLE to CM-CONNECTED state.

When the UE states in the AMF are CM-IDLE and RM-REGISTERED, the AMF shall:

- perform a network triggered Service Request procedure when it has signalling or mobile-terminated data to be
sent to this UE, by sending a Paging Request to this UE (see TS 23.502 [3] clause 4.2.3.3), if a UE is not
prevented from responding e.g. due to MICO mode or Mobility Restrictions.

The AMF shall enter CM-CONNECTED state for the UE whenever an N2 connection is established for this UE
between the AN and the AMF. The reception of initial N2 message (e.g., N2 INITIAL UE MESSAGE) initiates the
transition of AMF from CM-IDLE to CM-CONNECTED state.

The UE and the AMF may optimize the power efficiency and signalling efficiency of the UE when in CM-IDLE state
e.g. by activating MICO mode (see clause 5.4.1.3).

5.3.3.2.3 CM-CONNECTED state

A UE in CM-CONNECTED state has a NAS signalling connection with the AMF over N1. A NAS signalling
connection uses an RRC Connection between the UE and the NG-RAN and an NGAP UE association between the AN
and the AMF for 3GPP access. A UE can be in CM-CONNECTED state with an NGAP UE association that is not
bound to any TNLA between the AN and the AMF. See clause 5.21.1.2 for details on the state of NGAP UE association
for an UE in CM-CONNECTED state. Upon completion of a NAS signalling procedure, the AMF may decide to
release the NAS signalling connection with the UE.

3GPP
Release 16 79 3GPP TS 23.501 V16.4.0 (2020-03)

In the CM-CONNECTED state, the UE shall:

- enter CM-IDLE state whenever the AN signalling connection is released (entering RRC Idle state over 3GPP
access or when the release of the UE-N3IWF connectivity over untrusted non-3GPP access or the UE-TNGF
connectivity over trusted non-3GPP access is detected by the UE), see TS 38.331 [28] for 3GPP access.

When the UE CM state in the AMF is CM-CONNECTED, the AMF shall:

- enter CM-IDLE state for the UE whenever the logical NGAP signalling connection and the N3 user plane
connection for this UE are released upon completion of the AN Release procedure as specified in TS 23.502 [3].

The AMF may keep a UE CM state in the AMF in CM-CONNECTED state until the UE de-registers from the core
network.

A UE in CM-CONNECTED state can be in RRC Inactive state, see TS 38.300 [27]. When the UE is in RRC Inactive
state the following applies:

- UE reachability is managed by the RAN, with assistance information from core network;

- UE paging is managed by the RAN.

- UE monitors for paging with UE's CN (5G S-TMSI) and RAN identifier.

5.3.3.2.4 5GS Connection Management State models

AN signaling connection
released
CM- IDLE CM- CONNECTED
AN signaling connection
established
(Initial NAS message)

Figure 5.3.3.2.4-1: CM state transition in UE

N2 Context released
CM-IDLE CM-CONNECTED
N2 Context established

Figure 5.3.3.2.4-2: CM state transition in AMF

When a UE enters CM-IDLE state, the UP connection of the PDU Sessions that were active on this access are
deactivated.

NOTE: The activation of UP connection of PDU Sessions is documented in clause 5.6.8.

5.3.3.2.5 CM-CONNECTED with RRC Inactive state

RRC Inactive state applies to NG-RAN. UE support for RRC Inactive state is defined in TS 38.306 [69] for NR and
TS 36.306 [70] for E-UTRA connected to 5GC. RRC Inactive is not supported by NB-IoT connected to 5GC.

The AMF shall provide assistance information to the NG-RAN, to assist the NG-RAN's decision whether the UE can be
sent to RRC Inactive state except due to some exceptional cases such as:

- PLMN (or AMF set) does not support RRC Inactive;

- The UE needs to be kept in CM-CONNECTED State (e.g. for tracking).

The "RRC Inactive Assistance Information" includes:

- UE specific DRX values;

3GPP
Release 16 80 3GPP TS 23.501 V16.4.0 (2020-03)

- UE specific extended idle mode DRX values (cycle length and Paging Time Window length);

- The Registration Area provided to the UE;

- Periodic Registration Update timer;

- If the AMF has enabled MICO mode for the UE, an indication that the UE is in MICO mode;

- Information from the UE identifier, as defined in TS 38.304 [50] for NR and TS 36.304 [52] for E-UTRA
connected to 5GC, that allows the RAN to calculate the UE's RAN paging occasions.

The RRC Inactive Assistance Information mentioned above is provided by the AMF during N2 activation with the
(new) serving NG-RAN node (i.e. during Registration, Service Request, Handover) to assist the NG RAN's decision
whether the UE can be sent to RRC Inactive state. If the AMF allocates a new Registration Area to the UE, the AMF
should update the NG-RAN with the new Registration Area by sending the RRC Inactive Assistance Information
accordingly.

RRC Inactive state is part of RRC state machine, and it is up to the RAN to determine the conditions to enter RRC
Inactive state. If any of the parameters included in the RRC Inactive Assistance Information changes as the result of
NAS procedure, the AMF shall update the RRC Inactive Assistance Information to the NG-RAN node.

When the UE is in CM-CONNECTED state, if the AMF has provided RRC Inactive assistance information, the RAN
node may decide to move a UE to CM-CONNECTED with RRC Inactive state.

The state and "endpoints" (in the case of Dual Connectivity configuration) of the N2 and N3 reference points are not
changed by the UE entering CM-CONNECTED with RRC Inactive state. A UE in RRC inactive state is aware of the
RAN Notification area and periodic RAN Notification Area Update timer.

The 5GC network is not aware of the UE transitions between CM-CONNECTED with RRC Connected and CM-
CONNECTED with RRC Inactive state, unless the 5GC network is notified via N2 notification procedure in
TS 23.502 [3] clause 4.8.3.

At transition into CM-CONNECTED with RRC Inactive state, the NG-RAN configures the UE with a periodic RAN
Notification Area Update timer taking into account the value of the Periodic Registration Update timer value indicated
in the RRC Inactive Assistance Information, and uses a guard timer with a value longer than the RAN Notification Area
Update timer value provided to the UE.

If the periodic RAN Notification Area Update guard timer expires in NG-RAN, the NG-RAN shall initiate AN Release
procedure as specified in TS 23.502 [3], clause 4.2.6.

When the UE is in CM-CONNECTED with RRC Inactive state, the UE performs PLMN selection procedures as
defined in TS 23.122 [17] and TS 24.501 [47].

When the UE is CM-CONNECTED with RRC Inactive state, the UE may resume the RRC Connection due to:

- Uplink data pending;

- Mobile initiated NAS signalling procedure;

- As a response to RAN paging;

- Notifying the network that it has left the RAN Notification Area;

- Upon periodic RAN Notification Area Update timer expiration.

If the UE resumes the connection in a different NG-RAN node within the same PLMN or equivalent PLMN, the UE AS
context is retrieved from the old NG-RAN node and a procedure is triggered towards the CN (see TS 23.502 [3],
clause 4.8.2).

NOTE 1: With Dual Connectivity configuration if the UE resumes the RRC connection in the Master RAN node,
the Secondary RAN node configuration is defined in TS 38.300 [27].

If the RAN paging procedure, as defined in TS 38.300 [27], is not successful in establishing contact with the UE the
procedure shall be handled by the network as follows:

3GPP
Release 16 81 3GPP TS 23.501 V16.4.0 (2020-03)

- If NG-RAN has at least one pending NAS PDU for transmission, the RAN node shall initiate the AN Release
procedure (see TS 23.502 [3], clause 4.2.6,) to move the UE CM state in the AMF to CM-IDLE state and
indicate to the AMF the NAS non-delivery.

- If NG RAN has only pending user plane data for transmission, the NG-RAN node may keep the N2 connection
active or initiate the AN Release procedure (see TS 23.502 [3], clause 4.2.6) based on local configuration in NG-
RAN.

NOTE 2: The user plane data which triggers the RAN paging can be lost, e.g. in the case of RAN paging failure.

If a UE in CM-CONNECTED with RRC Inactive state performs cell selection to GERAN/UTRAN/E-UTRAN, it shall
follow idle mode procedures of the selected RAT as specified in clause 5.17.

In addition, a UE in CM-CONNECTED state with RRC Inactive state shall enter CM-IDLE state and initiates the NAS
signalling recovery (see TS 24.501 [47]) in the following cases:

- If RRC resume procedure fails,

If the UE receives Core Network paging,

- If the periodic RAN Notification Area Update timer expires and the UE cannot successfully resume the RRC
Connection,

- In any other failure scenario that cannot be resolved in RRC Inactive state and requires the UE to move to CM-
IDLE state.

When a UE is in CM-CONNECTED with RRC Inactive state, and a trigger to change the UE's NG-RAN UE Radio
Capability information happens, the UE shall move to CM-IDLE state and initiate the procedure for updating UE Radio
Capability defined in clause 5.4.4.1.

When UE is in CM-CONNECTED with RRC Inactive state, if RAN has received Location Reporting Control message
from AMF with the Reporting Type indicating single stand-alone report, the RAN shall perform RAN paging before
reporting the location to AMF.

When UE is in CM-CONNECTED with RRC Inactive state, if RAN has received Location Reporting Control message
from AMF with the Reporting Type indicating continuously reporting whenever the UE changes cell, the RAN shall
send a Location Report message to AMF including UE's last known location with time stamp.

When the UE is CM-CONNECTED with RRC Inactive state. If the AMF receives
Nudm_UEContextManagement_DeregistrationNotification from UDM, the AMF shall initiate AN Release procedure
as specified in TS 23.502 [3], clause 4.2.6.

When UE is in CM-CONNECTED with RRC Inactive state, if RAN has received Location Reporting Control message
from AMF with the Reporting Type of the Area Of Interest based reporting, the RAN shall send a Location Report
message to AMF including UE presence in the Area Of Interest (i.e., IN, OUT, or UNKNOWN) and the UE's last
known location with time stamp.

When the UE is in CM-CONNECTED with RRC Inactive state, if the old NG-RAN node that sents the UE into RRC
Inactive state receives the downlink N2 signalling, it initiates the RAN paging as defined in TS 38.300 [27]. If the UE
resumes the RRC Connection towards a different NG-RAN node, the old NG-RAN node includes the "UE Context
Transfer" indication into a response container to the NF (e.g. AMF or SMF) that generates such N2 downlink signalling.
Then the NF shall reattempt the same procedure when the path switch from the old NG-RAN node to the new NG-RAN
node is complete.

5.3.3.3 NAS signalling connection management

5.3.3.3.1 General
NAS signalling connection management includes the functions of establishing and releasing a NAS signalling
connection.

3GPP
Release 16 82 3GPP TS 23.501 V16.4.0 (2020-03)

5.3.3.3.2 NAS signalling connection establishment

NAS signalling connection establishment function is provided by the UE and the AMF to establish a NAS signalling
connection for a UE in CM-IDLE state. The AMF shall provide the list of recommended cells/ TAs / NG-RAN node
identifiers for paging, if the NG-RAN had provided that information in an earlier AN Release Procedure in the AN (see
clause 4.2.6 of TS 23.502 [3]).

When the UE in CM-IDLE state needs to transmit an NAS message, the UE shall initiate a Service Request, a
Registration or a Deregistration procedure to establish a NAS signalling connection to the AMF as specified in
TS 23.502 [3], clauses 4.2.2 and 4.2.3. If the NAS signalling connection is to be established via an NG-RAN node, but
the AMF detects that this UE has already established a NAS signalling connection via old NG-RAN node, the AMF
shall release the old established NAS signalling connection by triggering AN Release Procedure.

Based on UE preferences, UE subscription, Mobility Pattern and network configuration, the AMF may keep the NAS
signalling connection until the UE de-registers from the network.

5.3.3.3.3 NAS signalling connection Release

The procedure of releasing a NAS signalling connection is initiated by the AN node (either 5G (R)AN node or N3IWF)
or the AMF. The NG-RAN node may include the list of recommended cells/ TAs / NG-RAN node identifiers for
paging, during the AN Release Procedure in the AN (see clause 4.2.6 of TS 23.502 [3]). The AMF stores this
information, if provided by the NG-RAN.

The UE considers the NAS signalling connection is released if it detects the AN signalling connection is released. The
AMF considers the NAS signalling connection is released if it detects the N2 context is released.

5.3.3.4 Support of a UE connected over both 3GPP and Non-3GPP access

The AMF manages two CM states for an UE: a CM state for 3GPP access and a CM state for Non-3GPP access. An N2
interface can serve the UE for either 3GPP access or for Non 3GPP access. UE connected over both 3GPP and Non-
3GPP has got two N2 interfaces, one for each access. A UE may be in any combination of the CM states between 3GPP
and Non-3GPP access, e.g. a UE may be CM-IDLE for one access and CM-CONNECTED for the other access, CM-
IDLE for both accesses or CM-CONNECTED for both accesses.

When the UE CM state in the AMF is CM-IDLE for 3GPP access and CM-CONNECTED for Non-3GPP access, the
AMF shall perform a network triggered Service Request procedure, when it has downlink data to be sent to this UE for
3GPP access, by sending either the Paging Request via 3GPP access or the NAS notification via Non-3GPP access to
this UE (see TS 23.502 [3] clause 4.2.3.3).

Connection Management over Non-3GPP access is further defined in clause 5.5.2.

5.3.4 UE Mobility

5.3.4.1 Mobility Restrictions

5.3.4.1.1 General
Mobility Restrictions restrict mobility handling or service access of a UE. The Mobility Restriction functionality is
provided by the UE (only for mobility restriction categories provided to the UE), the radio access network and the core
network.

Unless otherwise stated, Mobility Restrictions only apply to 3GPP access and wireline access, they do not apply to
other non-3GPP accesses.

Service Area restrictions and handling of Forbidden Areas for CM-IDLE state and, for CM-CONNECTED state when
in RRC Inactive state are executed by the UE based on information received from the core network. Mobility
Restrictions for CM-CONNECTED state when in RRC-Connected state are executed by the radio access network and
the core network.

In CM-CONNECTED state, the core network provides Mobility Restrictions to the radio access network within
Mobility Restriction List.

3GPP
Release 16 83 3GPP TS 23.501 V16.4.0 (2020-03)

Mobility Restrictions consists of RAT restriction, Forbidden Area, Service Area Restrictions, Core Network type
restriction and Closed Access Group information as follows:

- RAT restriction:

Defines the 3GPP Radio Access Technology(ies), a UE is not allowed to access in a PLMN. In a restricted RAT
a UE based on subscription is not permitted access to the network for this PLMN. For CM-CONNECTED state,
when radio access network determines target RAT and target PLMN during Handover procedure, it should take
per PLMN RAT restriction into consideration. The RAT restriction is enforced in the network, and not provided
to the UE.

- Forbidden Area:

In a Forbidden Area, the UE, based on subscription, is not permitted to initiate any communication with the
network for this PLMN. The UE behaviour in terms of cell selection, RAT selection and PLMN selection
depends on the network response that informs the UE of Forbidden Area. A Forbidden Area applies either to
3GPP access or to non-3GPP access.

Further description on Forbidden Area when using wireline access is available in TS 23.316 [84].

NOTE 1: If the N3GPP TAI (see clause 5.3.2.3) is forbidden in a PLMN, non-3GPP Access is forbidden altogether
in this PLMN.

NOTE 2: The UE reactions to specific network responses are described in TS 24.501 [47].

- Service Area Restriction:

Defines areas in which the UE may or may not initiate communication with the network as follows:

- Allowed Area:

In an Allowed Area, the UE is permitted to initiate communication with the network as allowed by the
subscription.

- Non-Allowed Area:

In a Non-Allowed Area a UE is service area restricted based on subscription. The UE and the network are not
allowed to initiate Service Request or SM signalling (except for PS Data Off status change reporting) to
obtain user services (both in CM-IDLE and in CM-CONNECTED states). The UE shall not use the entering
of a Non-Allowed Area as a criterion for Cell Reselection, a trigger for PLMN Selection or Domain selection
for UE originating sessions or calls. The RRC procedures while the UE is in CM-CONNECTED with RRC
Inactive state are unchanged compared to when the UE is in an Allowed Area. The RM procedures are
unchanged compared to when the UE is in an Allowed Area. The UE in a Non-Allowed Area shall respond to
core network paging or NAS Notification message from non-3GPP access with Service Request and RAN
paging.

NOTE 3: When the services are restricted in 5GS due to Service Area Restriction, then it is assumed that the
services will be also restricted in all RATs/Systems at the same location(s) using appropriate mechanisms
available in the other RATs/Systems.

- Core Network type restriction:

Defines whether UE is allowed to connect to 5GC only, EPC only, both 5GC and EPC for this PLMN. The Core
Network type restriction when received applies in the PLMN either to both 3GPP and non-3GPP Access Types
or to non-3GPP Access Type only.

NOTE 4: The Core Network type restriction can be used e.g. in network deployments where the E-UTRAN
connects to both EPC and 5GC as described in clause 5.17.

- Closed Access Group information:

As defined in clause 5.30.3.

For a given UE, the core network determines the Mobility Restrictions based on UE subscription information, UE
location and/or local policy (e.g. if the HPLMN has not deployed 5GC, HPLMN ID of the UE and the operator's policy
are used in the VPLMN for determining the Core Network type restriction). The Mobility Restriction may change due

3GPP
Release 16 84 3GPP TS 23.501 V16.4.0 (2020-03)

to e.g. UE's subscription, location change and local policy. Optionally the Service Area Restrictions or the Non-
Allowed Area may in addition be fine-tuned by the PCF e.g. based on UE location, PEI and network policies. Service
Area Restrictions may be updated during a Registration procedure or UE Configuration Update procedure.

NOTE 5: The subscription management ensure that for MPS service subscriber the Mobility Restrictions is not
included.

If the network sends Service Area Restrictions to the UE, the network sends only either an Allowed Area, or a Non-
Allowed Area, but not both at the same time, to the UE. If the UE has received an Allowed Area from the network, any
TA not part of the Allowed Area is considered by the UE as non-allowed. If the UE has received a Non-Allowed Area
from the network, any TA not part of the Non-Allowed Area is considered by the UE as allowed. If the UE has not
received any Service Area Restrictions, any TA in the PLMN is considered as allowed.

If the UE has overlapping areas between Forbidden Areas, Service Area Restrictions, or any combination of them, the
UE shall proceed in the following precedence order:

- The evaluation of Forbidden Areas shall take precedence over the evaluation of Service Area Restrictions.

The UE and the network shall override any Forbidden Area, Non-Allowed area restrictions and Core Network type
restriction whenever access to the network for regulatory prioritized services like Emergency services and MPS.

The UDM shall provide to the AMF the information defined in TS 23.008 [119] about the subscriber's NR or E-UTRA
access restriction set by the operator determined e.g. by subscription scenario and roaming scenario:

- For NR:

- NR not allowed as primary access.

- NR not allowed as secondary access.

- NR in unlicensed bands not allowed as primary access.

- NR in unlicensed bands not allowed as secondary access.

- For E-UTRA:

- E-UTRA not allowed as primary access.

- E-UTRA not allowed as secondary access.

- E-UTRA in unlicensed bands not allowed as secondary access.

- NB-IoT not allowed as primary access.

- LTE-M not allowed as primary access.

In order to enforce all primary access restrictions, the related access has to be deployed in different Tracking Area
Codes and the subscriber shall not be allowed to access the network in TAs using the particular access.

With all secondary access restrictions, the subscriber shall not be allowed to use this access as secondary access.

5.3.4.1.2 Management of Service Area Restrictions

This clause describes Service Area Restrictions for 3GPP access. For Service Area Restrictions when using wireline
access, see TS 23.316 [84].

A Service Area Restriction may contain one or more (e.g. up to 16) entire Tracking Areas each or the Service Area
Restriction may be set as unlimited (i.e. contain all Tracking Areas of the PLMN). The UE's subscription data in the
UDM includes a Service Area Restriction which may contain either Allowed or Non-Allowed Areas–specified by using
explicit Tracking Area identities and/or other geographical information (e.g., longitude/latitude, zip code, etc). The
geographical information used to specify Allowed or Non-Allowed Area is only managed in the network, and the
network will map it to a list of TAs before sending Service Area Restriction information to the PCF, NG-RAN and UE.

When the AMF assigns a limited allowed area to the UE, the AMF shall provide the UE with Service Area Restrictions
which consist of either Allowed Areas or Non-Allowed Areas. The Allowed Areas included in the Service Area
Restrictions can be pre-configured and/or dynamically assigned by the AMF.

3GPP
Release 16 85 3GPP TS 23.501 V16.4.0 (2020-03)

The Allowed Area may alternatively be configured as unlimited i.e. it may contain all Tracking Areas of the PLMN.
The Registration Area of a UE in the Non-Allowed Area should consist of a set of TAs which belongs to a Non-
Allowed Area of the UE. The Registration Area of a UE in the Allowed Area should consist of a set of TAs which
belongs to an Allowed Area of the UE. The AMF provides the Service Area Restriction in the form of TA(s), which
may be a subset of full list stored in UE's subscription data or provided by the PCF, to the UE during the Registration
procedure.

NOTE: As the finest granularity for Service Area Restrictions are at TA level, subscriptions with limited
geographical extent, like subscriptions for Fixed Wireless Access, will be allocated one or a few TAs and
will consequently be allowed to access services in a larger area than in e.g. a FWA system.

The limited allowed area may also be limited by the AMF by a maximum allowed number of Tracking Areas, even
though this limitation is not sent to the UE. If maximum allowed number of Tracking Areas is used in combination with
Allowed Area, the maximum allowed number of Tracking Areas indicates (to the AMF) the maximum number of TAs
allowed in limited allowed area inside the Allowed Area. If maximum allowed number of Tracking Areas is used in
combination with Non-Allowed Area, the maximum allowed number of Tracking Areas indicates (to the AMF) the
maximum number of TAs allowed in limited allowed area outside of the Non-Allowed Area.

The UDM stores the Service Area Restrictions of a UE as part of the UE's subscription data. The PCF in the serving
network may (e.g. due to varying conditions such as UE's location, application in use, time and date) further adjust
Service Area Restrictions of a UE, either by expanding an Allowed Area or by reducing a Non-Allowed Area or by
increasing the maximum allowed number of Tracking Areas. If NWDAF is deployed, the PCF may use analytics (i.e.
statistics or predictions) on UE mobility from NWDAF (see TS 23.288 [86]) to adjust Service Area Restrictions. The
UDM and the PCF may update the Service Area Restrictions of a UE at any time. For the UE in CM-CONNECTED
state the AMF updates the UE and RAN immediately. For UE in CM-IDLE state the AMF may page the UE
immediately or store the updated service area restriction and update the UE upon next signalling interaction with the
UE, as defined in TS 24.501 [47].

During registration, if the Service Area Restrictions of the UE is not present in the AMF, the AMF fetches from the
UDM the Service Area Restrictions of the UE that may be further adjusted by the PCF. The serving AMF shall enforce
the Service Area Restrictions of a UE. A limited allowed area given by a maximum allowed number of Tracking Areas,
may be dynamically assigned by the AMF adding any not yet visited (by the UE) Tracking Areas to the limited allowed
area until the maximum allowed number of Tracking Areas is reached (i.e. the AMF adds new TAs to the limited
allowed area until the number of TAs is equal to the maximum allowed number of Tracking Areas). The AMF deletes
the list of TAs that have been used up under the maximum allowed number of Tracking Areas quota at every Initial
Registration.

For a UE in CM-CONNECTED state the AMF shall indicate the Service Area Restrictions of this UE to the RAN,
using a Mobility Restriction List.

The UE shall store the received Service Area Restrictions and, if there is previously stored Service Area Restrictions,
replace them with the newly received information. If the Service Area Restrictions include a limited allowed area, the
Service Area Restrictions are applicable for the Tracking areas indicated in Service Area Restrictions. If the Service
Area Restrictions included an unlimited allowed area, the received Service Area Restrictions are applicable for the
registered PLMN and its equivalent PLMN(s) that are available in the Registration Area. The RAN uses the Service
Area Restrictions for target cell selection in Xn and N2 based handover.

Upon change of serving AMF due to mobility, the old AMF may provide the new AMF with the Service Area
Restrictions of the UE that may be further adjusted by the PCF.

The network may perform paging for a UE to update Service Area Restrictions with Generic UE Configuration Update
procedure (see in TS 23.502 [3] clause 4.2.4).

In the case of roaming, the Service Area Restrictions are transferred from the UDM via the serving AMF to the serving
PCF in the visited network. The serving PCF in the visited network may further adjust the Service Area Restrictions.

5.3.4.2 Mobility Pattern

The Mobility Pattern is a concept that may be used by the AMF to characterise and optimise the UE mobility. The AMF
determines and updates Mobility Pattern of the UE based on subscription of the UE, statistics of the UE mobility,
network local policy, and the UE assisted information, or any combination of them. The statistics of the UE mobility
can be historical or expected UE moving trajectory. If NWDAF is deployed, the statistics of the UE mobility can also
be analytics (i.e. statistics or predictions) provided by the NWDAF (see TS 23.288 [86]).

3GPP
Release 16 86 3GPP TS 23.501 V16.4.0 (2020-03)

The Mobility Pattern can be used by the AMF to optimize mobility support provided to the UE, for example,
Registration area allocation.

5.3.4.3 Radio Resource Management functions

To support radio resource management in RAN the AMF provides the parameter 'Index to RAT/Frequency Selection
Priority' (RFSP Index) to RAN across N2. The RFSP Index is mapped by the RAN to locally defined configuration in
order to apply specific RRM strategies, taking into account any available information in RAN. The RFSP Index is UE
specific and applies to all the Radio Bearers. Examples of how this parameter may be used by the RAN:

- to derive UE specific cell reselection priorities to control idle mode camping.

- to decide on redirecting active mode UEs to different frequency layers or RATs.

The HPLMN may set the RFSP Index taking into account the Subscribed S-NSSAIs. The AMF receives the subscribed
RFSP Index from the UDM (e.g., during the Registration procedure). For non-roaming subscribers, the AMF chooses
the RFSP Index in use according to one of the following procedures, depending on operator's configuration:

- the RFSP Index in use is identical to the subscribed RFSP Index, or

- the AMF chooses the RFSP Index in use based on the subscribed RFSP Index, the locally configured operator's
policies, the Allowed NSSAI and the UE related context information available at the AMF, including UE's usage
setting, if received during Registration procedures (see clause TS 23.502 [3]).

NOTE: One example of how the AMF can use the "UE's usage setting," is to select an RFSP value that enforces
idle mode camping on E-UTRA for a UE acting in a "Voice centric" way, in the case voice over NR is not
supported in the specific Registration Area and it contains NR cells.

The AMF may report to the PCF the subscribed RFSP Index received from the UDM for further evaluation as described
in clause 6.1.2.1 in TS 23.503 [45]. When receiving the authorized RFSP Index from the PCF, the AMF shall replace
the subscribed RFSP Index with the authorized RFSP Index.

For roaming subscribers the AMF may choose the RFSP Index in use based on the visited network policy, but can take
input from the HPLMN into account (e.g., an RFSP Index value pre-configured per HPLMN, or a single RFSP Index
value to be used for all roamers independent of the HPLMN).

The RFSP Index in use is also forwarded from source to target RAN node when Xn or N2 is used for intra-NG-RAN
handover.

The AMF stores the subscribed RFSP Index value received and the RFSP Index value in use. During the Registration
procedure, the AMF may update the RFSP Index value in use (e.g. the AMF may need to update the RFSP Index value
in use if the UE related context information in the AMF has changed). When the RFSP Index value in use is changed,
the AMF immediately provides the updated RFSP Index value in use to NG-RAN node by modifying an existing UE
context or by establishing a new UE context in RAN or by being configured to include the updated RFSP Index value in
use in the NGAP DOWNLINK NAS TRANSPORT message if the user plane establishment is not needed. During
inter-AMF mobility procedures, the source AMF forwards both RFSP Index values to the target AMF. The target AMF
may replace the received RFSP Index value in use with a new RFSP Index value in use that is based on the operator's
policies and the UE related context information available at the target AMF.

In order to enable UE idle mode mobility control and priority-based reselection mechanism considering availability of
Network Slices at the network and the Network Slices allowed for a UE, an RFSP is derived as described in
clause 5.3.4.3, considering also the Allowed NSSAI for the UE.

5.3.4.4 UE mobility event notification

5G System supports the functionality of tracking and reporting UE mobility events.

The AMF provides the UE mobility related event reporting to NF that has been authorized to subscribe to the UE
mobility event reporting service. Any NF service consumer such as SMF, NEF or NWDAF that wants to be reported on
the UE location is able to subscribe to the UE mobility event notification service to the AMF with the following
parameters:

- Event reporting type that specifies what to be reported on UE mobility (e.g. UE location, UE mobility on Area of
Interest).

3GPP
Release 16 87 3GPP TS 23.501 V16.4.0 (2020-03)

- Event filters indicating the:

- Area Of Interest that specifies a geographical area within 3GPP system. The Area Of Interest is represented
by a list of Tracking Areas, list of cells or list of (R)AN node identifiers. In the case of LADN, the event
consumer (e.g. SMF) provides the LADN DNN to refer the LADN service area as the Area Of Interest. In the
case of PRA, the event consumer (e.g. SMF or PCF) may provide an identifier for Area Of Interest to refer
predefined area as the Area Of Interest.

- S-NSSAI and optionally the NSI ID(s).

- Event Reporting Information: event reporting mode, number of reports, maximum duration of reporting, event
reporting condition (e.g. when the target UE moved into a specified Area Of Interest, immediate reporting flag).

- Notification Endpoint of NF service consumer to be notified.

- The target of event reporting that indicates a specific UE, a group of UE(s) or any UE (i.e. all UEs). Further
details on the information provided by the NF service consumer are provided in clause 4.15 of TS 23.502 [3].

If an NF service consumer subscribes to the UE mobility event notification service provided by AMF for reporting of
UE presence in Area Of Interest, the AMF tracks UE's location considering UE's CM state and using NG-RAN
procedures (if RRC Inactive state applies to NG-RAN) in order to determine the UE presence in the Area Of Interest, as
described in clause 4.15.4.2 of TS 23.502 [3]. Upon detecting the change of the UE presence in the Area Of Interest, the
AMF notifies the UE presence in the Area Of Interest and the new UE location to the subscribed NF consumer.

When the AMF is changed, the subscription of mobility event is transferred from the old AMF. The new AMF may
decide not to notify the SMF with the current status related to the subscription of mobility event if the new AMF
determines that, based on MM Context of the UE, the event is reported by the old AMF.

In the network deployment where a UE may leave or enter the Area Of Interest without any notification to the 5GC in
CM-CONNECTED state (i.e. in the case that RRC Inactive state applies to the NG-RAN), the AMF may initiate the
NG-RAN location reporting as described in clause 5.4.7 or N2 Notification as described in TS 23.502 [3] clause 4.8.3 to
track the UE presence in the Area Of Interest.

The AMF may provide UE mobility event reporting to PCF, using Policy Control Report Triggers defined in
TS 23.503 [45].

5.4 3GPP access specific aspects

5.4.1 UE reachability in CM-IDLE

5.4.1.1 General
Reachability management is responsible for detecting whether the UE is reachable and providing UE location (i.e.
access node) for the network to reach the UE. This is done by paging UE and UE location tracking. The UE location
tracking includes both UE registration area tracking (i.e. UE registration area update) and UE reachability tracking ((i.e.
UE periodic registration area update)). Such functionalities can be either located at 5GC (in the case of CM-IDLE state)
or NG-RAN (in the case of CM-CONNECTED state).

The UE and the AMF negotiate UE reachability characteristics for CM-IDLE state during Registration procedures.

Two UE reachability categories are negotiated between UE and AMF for CM-IDLE state:

1. UE reachability allowing Mobile Terminated data while the UE is CM-IDLE state.

- The UE location is known by the network on a Tracking Area List granularity

- Paging procedures apply to this category.

- Mobile originating and mobile terminated data apply in this category for both CM-CONNECTED and CM-
IDLE state.

2. Mobile Initiated Connection Only (MICO) mode:

3GPP
Release 16 88 3GPP TS 23.501 V16.4.0 (2020-03)

- Mobile originated data applies in this category for both CM-CONNECTED and CM-IDLE state.

- Mobile terminated data is only supported when the UE is in CM-CONNECTED state.

Whenever a UE in RM-REGISTERED state enters CM-IDLE state, it starts a periodic registration timer according to
the periodic registration timer value received from the AMF during a Registration procedure.

The AMF allocates a periodic registration timer value to the UE based on local policies, subscription information and
information provided by the UE. After the expiry of the periodic registration timer, the UE shall perform a periodic
registration. If the UE moves out of network coverage when its periodic registration timer expires, the UE shall perform
a Registration procedure when it next returns to the coverage.

The AMF runs a Mobile Reachable timer for the UE. The timer is started with a value longer than the UE's periodic
registration timer whenever the CM state for the UE in RM-REGISTERED state changes to CM-IDLE. If the AMF
receives an elapsed time from RAN when RAN initiate UE context release indicating UE unreachable, the AMF should
deduce a Mobile Reachable timer value based on the elapsed time received from RAN and the normal Mobile
Reachable timer value. The AMF stops the Mobile Reachable timer, if the UE CM state in the AMF moves to CM-
CONNECTED state. If the Mobile Reachable timer expires, the AMF determines that the UE is not reachable.

However, the AMF does not know for how long the UE remains not reachable, thus the AMF shall not immediately de-
register the UE. Instead, after the expiry of the Mobile Reachable timer, the AMF should clear the PPF and shall start an
Implicit De-registration timer, with a relatively large value. The AMF shall stop the Implicit De-registration timer and
set the PPF if the AMF moves the UE CM state in the AMF to CM-CONNECTED state.

NOTE: If the UE CM state in the AMF is CM-IDLE, then AMF considers the UE always unreachable if the UE is
in MICO mode (refer to clause 5.4.1.3).

If the PPF is not set, the AMF does not page the UE and shall reject any request for delivering DL signalling or data to
this UE.

If the Implicit De-registration timer expires before the UE contacts the network, the AMF implicitly de-register the UE.

As part of deregistration for a particular access (3GPP or non-3GPP), the AMF shall request the UE's related SMF to
release the PDU Sessions established on that access.

5.4.1.2 UE reachability allowing mobile terminated data while the UE is CM-IDLE

The AMF considers a UE in RM-REGISTERED state to be reachable by CN paging if the UE CM state in the AMF is
CM-IDLE state unless the UE applies MICO mode.

5.4.1.3 Mobile Initiated Connection Only (MICO) mode

A UE may indicate preference for MICO mode during Initial Registration or Mobility Registration Update procedure.
The AMF, based on local configuration, Expected UE Behaviour and/or Network Configuration parameters if available
from the UDM, UE indicated preferences, UE subscription information and network policies, or any combination of
them, determines whether MICO mode is allowed for the UE and indicates it to the UE during Registration procedure.
If NWDAF is deployed, the AMF may also use analytics on UE mobility and/or UE communication generated by
NWDAF (see TS 23.288 [86]) to decide MICO mode parameters. If the UE does not indicate preference for MICO
mode during Registration procedure, the AMF shall not activate MICO mode for this UE.

The UE and the AMF re- negotiate the MICO mode at every subsequent Registration procedure. When the UE is in
CM-CONNECTED, the AMF may deactivate MICO mode by triggering Mobility Registration Update procedure
through UE Configuration Update procedure as described in clause 4.2.4 in TS 23.502 [3].

The AMF assigns a registration area to the UE during the Registration procedure. When the AMF indicates MICO
mode to a UE, the registration area is not constrained by paging area size. If the AMF serving area is the whole PLMN,
based on local policy, and subscription information, may decide to provide an "all PLMN" registration area to the UE.
In that case, re-registration to the same PLMN due to mobility does not apply.

If Mobility Restrictions are applied to a UE in MICO mode, the AMF needs to allocate an Allowed Area/Non-Allowed
Area to the UE as specified in clause 5.3.4.1.

When the AMF indicates MICO mode to a UE, the AMF considers the UE always unreachable while the UE CM state
in the AMF is CM-IDLE. The AMF rejects any request for downlink data delivery for UE in MICO mode and whose

3GPP
Release 16 89 3GPP TS 23.501 V16.4.0 (2020-03)

UE CM state in the AMF is CM-IDLE with an appropriate cause. For MT-SMS over NAS, the AMF notifies the SMSF
that UE is not reachable, then the procedure of the unsuccessful Mobile terminating SMS delivery described in
clause 4.13.3.9 in TS 23.502 [3] is performed. The AMF also defers location services, etc. The UE in MICO mode is
only reachable for mobile terminated data or signalling when the UE is in CM-CONNECTED.

A UE in MICO mode need not listen to paging while in CM-IDLE. A UE in MICO mode may stop any access stratum
procedures in CM-IDLE, until the UE initiates transition from CM-IDLE to CM-CONNECTED due to one of the
following triggers:

- A change in the UE (e.g. change in configuration) requires an update of its registration with the network.

- Periodic registration timer expires.

- MO data pending.

- MO signalling pending (e.g. SM procedure initiated).

If a registration area that is not the "all PLMN" registration area is allocated to a UE in MICO mode, then the UE
determines if it is within the registration area or not when it has MO data or MO signalling, and the UE performs
Mobility Registration Update before the UE initiates the MO data or MO signalling if it is not within the registration
area.

A UE initiating emergency service shall not indicate MICO preference during Registration procedure. When the MICO
mode is already activated in the UE, the UE and AMF shall locally disable MICO mode after PDU Session
Establishment procedure for Emergency Services is completed successfully. The UE and the AMF shall not enable
MICO mode until the AMF accepts the use of MICO mode in the next registration procedure. To enable an emergency
call back, the UE should wait for a UE implementation-specific duration of time before requesting the use of MICO
mode after the release of the emergency PDU session.

In order to enable power saving for MT reachability e.g. for Cellular IoT, enhancements to MICO mode are specified in
clause 5.31.7:

- MICO mode with Extended Connected Time.

- MICO mode with Active Time.

- MICO mode and Periodic Registration Timer Control.

5.4.2 UE reachability in CM-CONNECTED

For a UE in CM-CONNECTED state:

- the AMF knows the UE location on a serving (R)AN node granularity.

- the NG-RAN notifies the AMF when UE becomes unreachable from RAN point of view.

UE RAN reachability management is used by RAN for UEs in RRC Inactive state, see TS 38.300 [27]. The location of
a UE in RRC Inactive state is known by the RAN on a RAN Notification area granularity. A UE in RRC Inactive state
is paged in cells of the RAN Notification area that is assigned to the UEs. The RAN Notification area can be a subset of
cells configured in UE's Registration Area or all cells configured in the UE's Registration Area. UE in RRC Inactive
state performs RAN Notification Area Update when entering a cell that is not part of the RAN Notification area that is
assigned to the UE.

At transition into RRC Inactive state RAN configures the UE with a periodic RAN Notification Area Update timer
value and the timer is restarted in the UE with this initial timer value. After the expiry of the periodic RAN Notification
Area Update timer in the UE, the UE in RRC Inactive state performs periodic RAN Notification Area Update, as
specified in TS 38.300 [27].

To aid the UE reachability management in the AMF, RAN uses a guard timer with a value longer than the RAN
Notification Area Update timer value provided to the UE. Upon the expiry of the periodic RAN Notification Area
Update guard timer in RAN, the RAN shall initiate the AN Release procedure as specified in TS 23.502 [3]. The RAN
may provide the elapsed time since RAN's last contact with the UE to AMF.

3GPP
Release 16 90 3GPP TS 23.501 V16.4.0 (2020-03)

5.4.3 Paging strategy handling

5.4.3.1 General
Based on operator configuration, the 5GS supports the AMF and NG-RAN to apply different paging strategies for
different types of traffic.

In the case of UE in CM-IDLE state, the AMF performs paging and determines the paging strategy based on e.g. local
configuration, what NF triggered the paging and information available in the request that triggered the paging. If
NWDAF is deployed, the AMF may also use analytics (i.e. statistics or predictions) on the UE's mobility as provided by
NWDAF (see TS 23.288 [86]).

In the case of UE in CM-CONNECTED with RRC Inactive state, the NG-RAN performs paging and determines the
paging strategy based on e.g. local configuration, and information received from AMF as described in clause 5.4.6.3
and SMF as described in clause 5.4.3.2.

In the case of Network Triggered Service Request from SMF, the SMF determines the 5QI and ARP based on the
downlink data or the notification of downlink data received from UPF. The SMF includes the 5QI and ARP
corresponding to the received downlink PDU in the request sent to the AMF. If the UE is in CM IDLE, the AMF uses
e.g. the 5QI and ARP to derive different paging strategies as described in TS 23.502 [3], clause 4.2.3.3.

NOTE: The 5QI is used by AMF to determine suitable paging strategies.

5.4.3.2 Paging Policy Differentiation

Paging policy differentiation is an optional feature that allows the AMF, based on operator configuration, to apply
different paging strategies for different traffic or service types provided within the same PDU Session. In this Release of
the specification this feature applies only to PDU Session of IP type.

When the 5GS supports the Paging Policy Differentiation (PPD) feature, the DSCP value (TOS in IPv4 / TC in IPv6) is
set by the application to indicate to the 5GS which Paging Policy should be applied for a certain IP packet. For example,
as defined in TS 23.228 [15], the P-CSCF may support Paging Policy Differentiation by marking packet(s) to be sent
towards the UE that relate to a specific IMS services (e.g. conversational voice as defined in IMS multimedia telephony
service).

It shall be possible for the operator to configure the SMF in such a way that the Paging Policy Differentiation feature
only applies to certain HPLMNs, DNNs and 5QIs. In the case of HR roaming, this configuration is done in the SMF in
the VPLMN.

NOTE 1: Support of Paging Policy Differentiation in the case of HR roaming requires inter operator agreements
including on the DSCP value associated with this feature.

In the case of Network Triggered Service Request and UPF buffering downlink data packet, the UPF shall include the
DSCP in TOS (IPv4) / TC (IPv6) value from the IP header of the downlink data packet and an indication of the
corresponding QoS Flow in the data notification message sent to the SMF. When PPD applies, the SMF determines the
Paging Policy Indicator (PPI) based on the DSCP received from the UPF.

In the case of Network Triggered Service Request and SMF buffering downlink data packet, when PPD applies, the
SMF determines the PPI based on the DSCP in TOS (IPv4) / TC (IPv6) value from the IP header of the received
downlink data packet and identifies the corresponding QoS Flow from the QFI of the received downlink data packet.

The SMF includes the PPI, the ARP and the 5QI of the corresponding QoS Flow in the N11 message sent to the AMF.
If the UE is in CM IDLE, the AMF uses this information to derive a paging strategy, and sends paging messages to NG-
RAN over N2.

NOTE 2: Network configuration needs to ensure that the information used as a trigger for Paging Policy Indication
is not changed within the 5GS.

NOTE 3: Network configuration needs to ensure that the specific DSCP in TOS (IPv4) / TC (IPv6) value, used as a
trigger for Paging Policy Indication, is managed correctly in order to avoid the accidental use of certain
paging policies.

3GPP
Release 16 91 3GPP TS 23.501 V16.4.0 (2020-03)

For a UE in RRC Inactive state the NG-RAN may enforce specific paging policies in the case of NG-RAN paging,
based on 5QI, ARP and PPI associated with an incoming DL PDU. To enable this, the SMF instructs the UPF to detect
the DSCP in the TOS (IPv4) / TC (IPv6) value in the IP header of the DL PDU (by using a DL PDR with the DSCP for
this traffic) and to transfer the corresponding PPI in the CN tunnel header (by using a QER with the PPI value). The
NG-RAN can then utilize the PPI received in the CN tunnel header of an incoming DL PDU in order to apply the
corresponding paging policy for the case the UE needs to be paged when in RRC Inactive state. In the case of Home-
Routed roaming, the V-SMF is responsible of controlling UPF setting of the PPI. In the case of PDU Session with I-
SMF, the I-SMF is responsible of controlling UPF setting of the PPI.

5.4.3.3 Paging Priority

Paging Priority is a feature that allows the AMF to include an indication in the Paging Message sent to NG-RAN that
the UE be paged with priority. The decision by the AMF whether to include Paging Priority in the Paging Message is
based on the ARP value in the message received from the SMF for an IP packet waiting to be delivered in the UPF. If
the ARP value is associated with select priority services (e.g., MPS, MCS), the AMF includes Paging Priority in the
Paging Message. When the NG-RAN receives a Paging Message with Paging Priority, it handles the page with priority.

The AMF while waiting for the UE to respond to a page sent without priority receives another message from the SMF
with an ARP associated with select priority services (e.g., MPS, MCS), the AMF sends another Paging message to the
(R)AN including the Paging Priority. For subsequent messages, the AMF may determine whether to send the Paging
message with higher Paging Priority based on local policy.

For a UE in RRC Inactive state, the NG-RAN determines Paging Priority based on the ARP associated with the QoS
Flow as provisioned by the operator policy, and the Core Network Assisted RAN paging information from AMF as
described in clause 5.4.6.3.

5.4.4 UE Radio Capability handling

5.4.4.1 UE radio capability information storage in the AMF

This clause applies when no radio capability signalling optimisation is used between a UE and the network.

The UE Radio Capability information contains information on RATs that the UE supports (e.g. power class, frequency
bands, etc). Consequently, this information can be sufficiently large that it is undesirable to send it across the radio
interface at every transition of UE CM state in the AMF from CM-IDLE to CM-CONNECTED. To avoid this radio
overhead, the AMF shall store the UE Capability information during CM-IDLE state for the UE and RM-
REGISTERED state for the UE and the AMF shall if it is available, send its most up to date UE Radio Capability
information to the RAN in the N2 REQUEST message.

The AMF deletes the UE radio capability when the UE RM state in the AMF transitions to RM-DEREGISTERED.

The UE Radio Capability is maintained in the core network, even during AMF reselection.

NOTE: The UE Radio Capability is not transferred to EPC during the inter-system mobility.

If the UE's NG-RAN UE Radio Capability information changes while in CM-IDLE state, the UE shall perform the
Registration procedure with the Registration type set to Mobility Registration Update and it also includes "UE Radio
Capability Update". When the AMF receives Mobility Registration Update Request with "UE Radio Capability Update"
requested by the UE, it shall delete any UE Radio Capability information that it has stored for the UE.

If the trigger to change the UE's NG-RAN UE Radio Capability information happens when the UE is in CM-
CONNECTED state, the UE shall first enter CM-IDLE state and then perform the Registration procedure with the
Registration type set to Mobility Registration Update and it also includes "UE Radio Capability Update".

The RAN stores the UE Radio Capability information, received in the N2 message or obtained from the UE, for the
duration of the UE staying in RRC connected or RRC Inactive state.

If a UE supports both NB-IoT and other RATs the UE handles the UE Radio capability information as follows:

- When the UE is camping on NB-IoT the UE provides only NB-IoT UE radio capabilities to the network.

- When the UE is not camping on NB-IoT, the UE provides UE radio capabilities for the RAT but not NB-IoT UE
radio capabilities to the network.

3GPP
Release 16 92 3GPP TS 23.501 V16.4.0 (2020-03)

In order to handle the distinct UE radio capabilities, the AMF stores a separate NB-IoT specific UE Radio Capability
information when the UE provides the UE Radio Capability information while camping on NB-IoT.

When the UE is camping on NB-IoT, the AMF sends, if available, the NB-IoT RAT specific UE Radio Capability
information to the E-UTRAN.

When the UE is not camping on NB-IoT, the AMF sends, if available, UE radio capabilities for the RAT but not NB-
IoT radio capabilities.

5.4.4.1a UE radio capability signalling optimisation (RACS)

With the increase of the size of UE radio capabilities driven e.g. by additional frequency bands and combinations
thereof for E-UTRA and NR, an efficient approach to signal UE Radio Access Capability Information over the radio
interface and other network interfaces is defined with RACS.

In this Release of the specification, RACS does not apply to NB-IOT.

RACS works by assigning an identifier to represent a set of UE radio capabilities. This identifier is called UE Radio
Capability ID. A UE Radio Capability ID can be either UE manufacturer-assigned or PLMN-assigned, as specified in
clause 5.9.10. The UE Radio Capability ID is an alternative to the signalling of the radio capabilities container over the
radio interface, within NG-RAN, from NG-RAN to E-UTRAN, from AMF to NG-RAN and between CN nodes
supporting RACS.

PLMN-assigned UE Radio Capability ID is assigned to the UE using the UE Configuration Update Command, or
Registration Accept as defined in TS 23.502 [3]. The UCMF shall be configured with a Version ID for PLMN-assigned
UE Radio Capability IDs, defined in clause 6.2.21.

The UCMF (UE radio Capability Management Function) stores all UE Radio Capability ID mappings in a PLMN and is
responsible for assigning every PLMN-assigned UE Radio Capability ID in this PLMN, see clause 6.2.21.

In order to be able to interpret the UE Radio Capability ID a Network Function or node may store a local copy of the
mapping between the UE Radio Capability ID and its corresponding UE Radio Capability information i.e. a dictionary
entry. When no mapping is available between a UE Radio Capability ID and the corresponding UE Radio Capability
information in a Network Function or node, this Network Function or node shall be able to retrieve this mapping and
store it.

- An AMF which supports RACS shall store such UE Radio Capability ID mapping at least for all the UEs that it
serves that have a UE Radio Capability ID assigned.

- The NG-RAN performs local caching of the UE Radio Access Capabilities for the UE Radio Capability IDs for
the UEs it is serving, and potentially for other UE Radio Capability IDs according to suitable local policies.

- When the NG-RAN needs to retrieve the mapping of a UE Radio Capability ID to the corresponding UE Radio
Capability information, it queries the AMF using N2 signalling defined in TS 38.413 [34].

- When the AMF needs to obtain a PLMN-assigned UE Radio Capability ID for a UE from the UCMF, it provides
the UE Radio Capability information it has for the current radio configuration of the UE, the IMEI/TAC for the
UE. The UCMF stores the association of this IMEI/TAC with this UE Radio Capability ID.

- When the AMF needs to obtain the UE Radio Capability information associated to a UE Radio Capability ID it
provides the UE Radio Capability ID to the UCMF and the UCMF returns a mapping of the UE Radio Capability
ID to the corresponding UE Radio Capability information.

- UEs, AMFs and RAN nodes which support RACS learn the current value of the Version ID when a new PLMN-
assigned UE Radio Capability ID is received from the UCMF and the Version ID it contains is different from the
ones in their PLMN Assigned UE Radio Capability ID cache. PLMN-assigned UE Radio Capability IDs related
to old values of the Version ID can be removed from cache with priority.

A network may utilise the PLMN-assigned UE Radio Capability ID, without involving the UE, e.g. for use with legacy
UEs.

Mutual detection of the support of the RACS feature happens between NG-RAN nodes at Xn setup and between NG-
RAN and AMF at N2 setup time. To allow for a mix of RACS-supporting and non-RACS-supporting RAN nodes over
the Xn interfaces, the UE Radio Capability ID should be included in the Path Switch signalling during Xn based
handover and Handover Request during N2 based handover between AMF and NG-RAN. In addition, RACS-

3GPP
Release 16 93 3GPP TS 23.501 V16.4.0 (2020-03)

supporting RAN nodes can be discovered across inter-CN node boundaries e.g. using the Configuration Transfer
procedure. The support of RACS by peer AMFs or MMEs is based on configuration in a PLMN or across PLMNs.

A UE that supports WB-E-UTRA and/or NR indicates its support for RACS to AMF using UE MM Core Network
Capability as defined in clause 5.4.4a.

A UE that supports RACS and stores an applicable UE Radio Capability ID for the current UE Radio Configuration in
the PLMN, shall signal the UE Radio Capability ID in the Initial Registration procedure as defined in TS 23.502 [3]. If
both PLMN-assigned for the current PLMN and UE manufacturer-assigned UE Radio Capability IDs are stored in the
UE and applicable in the PLMN, the UE shall signal the PLMN-assigned UE Radio Capability ID in the Registration
Request message.

When a PLMN decides to switch to request a particular type of UE to use UE manufacturer-assigned UE Radio
Capability ID(s):

- The UCMF sends a Nucmf_UECapabilityManagement_Notify message to the AMF including either a list of UE
Radio Capability IDs (if the UE was previously using any PLMN-assigned IDs) or the IMEI/TAC values
corresponding to UE types that are requested to use UE manufacturer-assigned UE Radio Capability ID. These
values are stored in a "UE Manufacturer Assigned operation requested list" in the AMF.

- The AMF uses the Registration Accept message or the UE Configuration Update command message to request
the UE to delete all the PLMN-assigned UE Radio Capability ID(s) for this PLMN if the UE is, respectively,
registering or is registered with PLMN-assigned ID or IMEI/TAC values matching one value in the "UE
Manufacturer Assigned operation requested list".

NOTE 1: It is expected that in a given PLMN the UCMF and AMFs will be configured to either use a UE
manufacturer-assigned operation requested list based on a list of PLMN-assigned UE Radio Capability
IDs or a list of IMEI/TACs, but not both.

NOTE 2: The strategy for triggering of the deletion of PLMN-assigned UE Radio Capability ID(s) in the UE by the
AMF is implementation-specific (e.g. can be used only towards UEs in CM_Connected state).

- a UE that receives indication to delete all the PLMN-assigned UE Radio Capability IDs in the Registration
Accept message, or UE Configuration Update command message, shall delete any PLMN-assigned UE Radio
Capability IDs for this PLMN. The UE proceeds to register with a UE manufacturer-assigned UE Radio
Capability ID that is applicable to the current UE Radio configuration.

- When the "UE Manufacturer Assigned operation requested list" contains PLMN-assigned UE Radio Capability
IDs, the UCMF shall avoid re-assigning PLMN-assigned UE Radio Capability IDs that were added to the "UE
Manufacturer Assigned operation requested list" in the AMFs to any UE.

- The AMF stores a PLMN-assigned ID in the "UE Manufacturer Assigned operation requested list" for a time
duration that is implementation specific, but IMEI/TACs are stored until the UCMF require to remove certain
TACs from the list (i.e. the list of IMEI/TACs which are requested to use UE manufacturer-assigned IDs in the
AMF and UCMF is synchronised at all times).

- The UCMF can request at any time the AMF to remove PLMN-assigned ID(s) or IMEI/TAC(s) values from the
UE manufacturer-assigned operation requested list.

NOTE 3: The AMF can decide to remove a UE Radio Capability ID from the "UE Manufacturer Assigned
operation requested list" list e.g. because no UE with that UE Radio Capability ID has connected to the
network for long time. If later a UE with such UE Radio Capability ID connects to the network, the AMF
contacts the UCMF to resolve the UE Radio Capability ID, and at this point the UCMF can trigger again
the deletion of the UE Radio Capability ID by including this in the "UE Manufacturer Assigned operation
requested list" of the AMF.

The serving AMF stores the UE Radio Capability ID for a UE in the UE context and provides this UE Radio Capability
ID to NG-RAN as part of the UE context information using N2 signalling. During inter PLMN mobility, the new AMF
shall delete the UE Radio Capability ID received from the old AMF, unless the operator policy indicates that all UE
Radio Capability IDs used in the old PLMN is also valid in the new PLMN.

The UE stores the PLMN-assigned UE Radio Capability ID in non-volatile memory when in RM-DEREGISTERED
state and can use it again when it registers in the same PLMN.

3GPP
Release 16 94 3GPP TS 23.501 V16.4.0 (2020-03)

NOTE 4: It is assumed that UE does not need to store the access stratum information (i.e. UE-E-UTRA-Capability
and UE-NR-Capability specified in TS 36.331 [51] and TS 38.331 [28], respectively) that was indicated
by the UE to the network when the PLMN-assigned UE Radio Capability ID was assigned by the
network. However, it is assumed that the UE does store the related UE configuration (e.g. whether or not
GERAN or UTRAN or MBMS is enabled/disabled).

At any given time at most one UE Radio Capability ID is stored in the UE context in CN and RAN.

The number of PLMN-assigned UE Radio Capability IDs that the UE stores in non-volatile memory is left up to UE
implementation. However, to minimise the load (e.g. from radio signalling) on the Uu interface and to provide smoother
inter-PLMN mobility (e.g. at land borders) the UE shall be able to store at least the latest 16 PLMN-assigned UE Radio
Capability IDs (along with the PLMN that assigned them). This number is independent of the UE manufacturer-
assigned UE Radio Capability ID(s) the UE may store.

It shall be possible for a UE to change, e.g. upon change in its usage settings, the set of UE Radio Capabilities in time
and signal the associated UE Radio Capability ID, if available. The UE stores the mapping between the UE Radio
Capability ID and the corresponding UE Radio Capability Information for every UE Radio Capability ID it stores.

If the UE's Radio Capability Information changes and there is no the associated UE Radio Capability ID for the updated
Radio Capability, the UE shall perform capability update procedure as defined in clause 5.4.4.1.

The NG-RAN may apply RRC filtering of UE radio capabilities when it retrieves the UE Radio Capability Information
from the UE as defined in TS 38.331 [28].

NOTE 5: In a RACS supporting PLMN, the filter of UE radio capabilities configured in NG-RAN is preferably as
wide in scope as possible (e.g. PLMN-wide). In this case, it corresponds e.g. to the super-set of bands,
band-combinations and RATs the PLMN deploys and not only to the specific NG-RAN node or region.

NOTE 6: If the filter of UE radio capabilities configured in two NG-RAN nodes is different, during handover
between these two nodes, it is possible that the target NG-RAN node might need to enquire the UE for its
UE Radio Capability Information again and trigger re-allocation of a PLMN-assigned UE Radio
Capability ID leading to extra signalling. Additionally, a narrow filter might reduce the list of candidate
target nodes.

If a UE supports both NB-IoT and other RATs that do support RACS (e.g. WB-E-UTRA and/or NR) then (since there
is no support for RACS in NB-IoT) the UE handles the RACS procedures as follows:

- NB-IoT specific UE Radio Capability Information is handled in UE, NG-RAN and AMF according to
clause 5.4.4.1 and in EPS according to TS 23.401 [26].

- when the UE is not camping on NB-IoT, the RAN provides UE radio capabilities for other RATs but not NB-IoT
UE radio capabilities, according to TS 38.300 [27] and TS 36.300 [30]. As a result the UE Radio Capability ID
that is assigned by the network corresponds only to the UE Radio Capabilities of the non-NB-IoT RATs. The UE
uses the UE Radio Capability IDs assigned only in Mobility Registration Update procedures performed over
non-NB-IoT RATs.

Support for RACS in EPS is defined in TS 23.401 [26].

5.4.4.2 Void

5.4.4.2a UE Radio Capability Match Request

If the AMF requires more information on the UE radio capabilities support to be able to set the IMS voice over PS
Session Supported Indication (see clause 5.16.3), then the AMF may send a UE Radio Capability Match Request
message to the NG-RAN. This procedure is typically used during the Registration Procedure or when AMF has not
received the Voice Support Match Indicator (as part of the 5GMM Context).

NOTE: During the Registration Procedure, if the AMF does not already have the UEs radio capabilities, and if the
RAT where the UE is requires the establishement of AN security context prior to retrieval of radio
capabilities, the AMF needs to initiate "Initial Context Setup" procedure as defined in TS 38.413 [34] to
provide the 5G-AN with security context, before sending a UE Radio Capability Match Request message.

3GPP
Release 16 95 3GPP TS 23.501 V16.4.0 (2020-03)

5.4.4.3 Paging assistance information

The paging assistance information contains UE radio related information that assists the RAN for efficient paging. The
Paging assistance information contains:

a) UE radio capability for paging information:

- The UE Radio Capability for Paging Information contains information derived by the NG-RAN node (e.g.
band support information) from the UE Radio Capability information. The AMF stores this information
without needing to understand its contents.

As the AMF only infrequently -e.g. at Initial Registration) prompts the NG-RAN to retrieve and upload the
UE radio capabilities i.e. UE Radio Capability information to the AMF, and the AMF may be connected to
more than one NG-RAN RAT, it is the responsibility of the NG-RAN to ensure that UE Radio Capability for
Paging Information -which is derived by the NG-RAN node) contains information on all NG-RAN RATs
that the UE supports in that PLMN. To assist the NG-RAN in this task, -and as specified in TS 38.413 [34])
the AMF provides its stored UE Radio Capability for Paging Information in every NG-AP INITIAL
CONTEXT SETUP REQUEST message sent to the NG-RAN.

- The UE Radio Capability for Paging Information is maintained in the core network, even during AMF
reselection.

b) Information On Recommended Cells And RAN nodes For Paging:

- Information sent by the NG-RAN, and used by the AMF when paging the UE to help determining the NG
RAN nodes to be paged as well as to provide the information on recommended cells to each of these RAN
nodes, in order to optimize the probability of successful paging while minimizing the signalling load on the
radio path.

- The RAN provides this information during N2 release.

5.4.4a UE MM Core Network Capability handling

The UE MM Core Network Capability is split into the S1 UE network capability (mostly for E-UTRAN access related
core network parameters) and the Core Network Capability (mostly to include other UE capabilities related to 5GCN or
interworking with EPS) as defined in TS 24.501 [47] and contains non radio-related capabilities, e.g. the NAS security
algorithms etc. The S1 UE network capability is transferred between all CN nodes at AMF to AMF, AMF to MME,
MME to MME, and MME to AMF changes. The 5GMM capability is transferred only at AMF to AMF changes.

In order to ensure that the UE MM Core Network Capability information stored in the AMF is up to date (e.g. to handle
the situation when the USIM is moved into a different device while out of coverage, and the old device did not send the
Detach message; and the cases of inter-RAT Registration Area Update), the UE shall send the UE MM Core Network
Capability information to the AMF during the Initial Registration and Mobility Registration Update procedure within
the NAS message.

The AMF shall store always the latest UE MM Core Network Capability received from the UE. Any UE MM Core
Network Capability that an AMF receives from an old AMF/MME is replaced when the UE provides the UE MM Core
Network Capability with Registration signalling.

If the UE's UE MM Core Network Capability information changes (in either CM-CONNECTED or in CM-IDLE state),
the UE shall perform a Mobility Registration Update procedure when it next returns to NG-RAN coverage. See
clause 4.2.2 of TS 23.502 [3].

The UE shall indicate in the UE 5GMM Core Network Capability if the UE supports:

- Attach in EPC with Request type "Handover" in PDN CONNECTIVITY Request message (TS 23.401 [26],
clause 5.3.2.1).

- EPC NAS.

- SMS over NAS.

- LCS.

- 5G SRVCC from NG-RAN to UTRAN, as specified in TS 23.216 [88].

3GPP
Release 16 96 3GPP TS 23.501 V16.4.0 (2020-03)

- Radio Capabilities Signalling optimisation (RACS).

- Network Slice-Specific Authentication and Authorization.

- Parameters in Supported Network Behaviour for 5G CIoT as described in clause 5.31.2.

- Receiving WUS Assistance Information.

5.4.4b UE 5GSM Core Network Capability handling

The UE 5GSM Core Network Capability is included in PDU Session Establishment/Modification Request.

The UE shall indicate in the UE 5GSM Core Network Capability whether the UE supports:

- "Ethernet" PDU Session Type supported in EPC as PDN Type "Ethernet";

- Reflective QoS;

- Multi-homed IPv6 PDU Session (only if the Requested PDU Type was set to "IPv6" or "IPv4v6");

- ATSSS capability (as referred to clause 5.32.2);

- Transfer of Port Management Information containers.

The 5GSM Core Network Capability is transferred, if needed, from V-SMF to H-SMF during PDU Session
Establishment/Modification procedure.

After the first inter-system change from EPS to 5GS for a PDU session established in EPS, the 5GSM Core Network
Capability is also included in the PDU Session Modification if the Reflective QoS and/or Multi-homed IPv6 PDU
Session is present.

5.4.5 DRX (Discontinuous Reception) framework

The 5G System supports DRX architecture which allows Idle mode DRX cycle is negotiated between UE and the AMF.
The Idle mode DRX cycle applies in CM-IDLE state and in CM-CONNECTED with RRC Inactive state.

If the UE wants to use UE specific DRX parameters, the UE shall include its preferred values consistently in every
Initial Registration and Mobility Registration procedure separately for NR/WB-EUTRA and NB-IoT. During Initial
Registration and Mobility Registration procedures performed on NB-IoT cells, the normal 5GS procedures apply.

The AMF shall determine Accepted DRX parameters based on the received UE specific DRX parameters and the AMF
should accept the UE requested values, but subject to operator policy the AMF may change the UE requested values.

The AMF shall respond to the UE with the Accepted DRX parameters separately for NR/WB-EUTRA and NB-IoT.

For details of DRX parameters, see TS 38.331 [28] and TS 36.331 [51].

The UE shall apply the DRX cycle broadcast in the cell by the RAN unless it has received Accepted DRX parameters
from the AMF in which case the UE shall apply either the DRX cycle broadcast in the cell or the Accepted DRX
parameters, as defined in TS 38.304 [50] and TS 36.304 [52].

The Periodic Registration procedure does not change the UE's DRX settings.

In CM-CONNECTED with RRC Inactive state, the UE applies either the DRX cycle negotiated with AMF, or the DRX
cycle broadcast by RAN or the UE specific DRX cycle configured by RAN, as defined in TS 38.300 [27] and
TS 38.304 [50].

5.4.6 Core Network assistance information for RAN optimization

5.4.6.1 General
Core Network assistance information for RAN aids the RAN to optimize the UE state transition steering and the RAN
paging strategy formulation in RRC Inactive state. The Core Network assistance information includes the information
set, Core Network assisted RAN parameters tuning, which assist RAN optimize the UE RRC state transition and CM

3GPP
Release 16 97 3GPP TS 23.501 V16.4.0 (2020-03)

state transition decision. It also includes the information set, Core Network assisted RAN paging information, which
assist RAN to formulate an optimized paging strategy when RAN paging is triggered.

5.4.6.2 Core Network assisted RAN parameters tuning

Core Network assisted RAN parameters tuning aids the RAN to minimize the UE state transitions and achieve optimum
network behaviour. How the RAN uses the CN assistance information is not defined in this specification.

Core Network assisted RAN parameters tuning may be derived by the AMF per UE in the AMF based on collection of
UE behaviour statistics, Expected UE Behaviour and/or other available information about the UE (such as subscribed
DNN, SUPI ranges, or other information). If the AMF maintains Expected UE Behaviour parameters, Network
Configuration parameters (as described in clause 4.15.6.3 or 4.15.6.3a, TS 23.502 [3]) or SMF derived CN assisted
RAN parameters tuning, the AMF may use this information for selecting the CN assisted RAN parameter values. If the
AMF is able to derive the Mobility Pattern of the UE (as described in clause 5.3.4.2), the AMF may take the Mobility
Pattern information into account when selecting the CN assisted RAN parameter values.

The SMF uses the SMF-Associated parameters (e.g. Expected UE Behaviour parameters or Network Configuration
parameters of the UE) to derive the SMF derived CN assisted RAN parameters tuning. The SMF sends the SMF derived
CN assisted RAN parameters tuning to the AMF during the PDU Session establishment procedure and if the SMF-
Associated parameters change the PDU Session modification procedure is applied. The AMF stores the SMF derived
CN assisted RAN parameters tuning in the PDU Session level context. The AMF uses the SMF derived CN assisted
RAN parameters tuning to determine a PDU Session level "Expected UE activity behaviour" parameters set, which may
be associated with a PDU Session ID, as described below in this clause.

The Expected UE Behaviour parameters or the Network Configuration parameters can be provisioned by external party
via the NEF to the AMF or SMF, as described in clause 5.20.

The CN assisted RAN parameters tuning provides the RAN with a way to understand the UE behaviour for these
aspects:

- "Expected UE activity behaviour", i.e. the expected pattern of the UE's changes between CM-CONNECTED
and CM-IDLE states or the duration of CM-CONNECTED state. This may be derived e.g. from the statistical
information, or Expected UE Behaviour or from subscription information. The AMF derives one or more sets
of the "Expected UE activity behaviour" parameters for the UE as follows:

- AMF may derive and provide to the RAN a UE level of "Expected UE activity behaviour" parameters set
considering the Expected UE Behaviour parameters or Network Configuration parameters received from
the UDM (see clauses 4.15.6.3 or 4.15.6.3a of TS 23.502 [3]) and the SMF derived CN assisted RAN
parameters tuning associated with a PDU Session using Control Plane CIoT 5GS Optimisation. This set
of "Expected UE activity behaviour" parameters is valid for the UE; and

- AMF may provide to the RAN a PDU Session level "Expected UE activity behaviour" parameters set,
e.g. considering the SMF derived CN assisted RAN parameters tuning, per established PDU Session. The
PDU Session level "Expected UE activity behaviour" set of parameters is associated with and valid for a
PDU Session ID. The RAN may consider the PDU Session level "Expected UE activity behaviour"
parameters when the User Plane resources for the PDU Session are activated;

- "Expected HO behaviour", i.e. the expected interval between inter-RAN handovers. This may be derived by
the AMF e.g. from the Mobility Pattern information;

- "Expected UE mobility", i.e. whether the UE is expected to be stationary or mobile. This may be derived e.g.
from the statistical information or Expected UE Behaviour parameters or from subscription information;

- "Expected UE moving trajectory" which may be derived e.g. from the statistical information or Expected UE
Behaviour parameters or from subscription information; or

- "UE Differentiation Information" including the Expected UE Behaviour parameters excluding the Expected
UE moving trajectory (see clause 4.15.6.3 of TS 23.502 [3]) to support Uu operation optimisation for NB-IoT
UE differentiation if the RAT type is NB-IoT.

The AMF decides when to send this information to the RAN as "Expected UE activity behaviour" carried in N2 request
over the N2 interface (see TS 38.413 [34]).

3GPP
Release 16 98 3GPP TS 23.501 V16.4.0 (2020-03)

NOTE: The calculation of the CN assistance information, i.e. the algorithms used and related criteria, and the
decision when it is considered suitable and stable to send to the RAN are vendor specific.

5.4.6.3 Core Network assisted RAN paging information

Core Network assisted RAN paging information aids the RAN to formulate a RAN paging policy and strategy in RRC
Inactive state, besides the PPI and QoS information associated to the QoS Flows as indicated in clause 5.4.3.

CN assisted RAN paging information may be derived by the AMF per UE and/or per PDU Session based on collection
of UE behaviour statistics, Expected UE Behaviour and/or other available information about the UE (such as subscribed
DNN, SUPI ranges, Multimedia priority service), and/or information received from other network functions when
downlink signalling is triggered.

The CN assisted RAN paging information consists of a service priority (values 1 to 256) which provides AN with a way
to understand how important the downlink signalling is. The AMF derives this service priority based on available
information as described above. The method to derive the service priority is implementation depended and can be
controlled by operator.

The Core Network may provide the CN assisted RAN paging information to RAN in different occasions, e.g. during
downlink N1 and N2 message delivery, etc.

5.4.7 NG-RAN location reporting

NG-RAN supports the NG-RAN location reporting for the services that require accurate cell identification (e.g.
emergency services, lawful intercept, charging) or for the UE mobility event notification service subscribed to the AMF
by other NFs. The NG-RAN location reporting may be used by the AMF when the target UE is in CM-CONNECTED
state.

The AMF may request the NG-RAN location reporting with event reporting type (e.g. UE location or UE presence in
Area of Interest), reporting mode and its related parameters (e.g. number of reporting).

If the AMF requests UE location, the NG-RAN reports the current UE location (or last known UE location with time
stamp if the UE is in RRC Inactive state) based on the requested reporting parameter (e.g. one-time reporting or
continuous reporting).

If the AMF requests UE presence in the Area Of Interest, the NG-RAN reports the UE location and the indication (i.e.
IN, OUT or UNKNOWN) when the NG-RAN determines the change of UE presence in Area Of Interest.

After N2 based Handover, if the NG-RAN location reporting information is required, the AMF shall re-request the NG-
RAN location reporting to the target NG-RAN node. For Xn based Handover, the source NG-RAN shall transfer the
requested NG-RAN location reporting information to target NG-RAN node.

The AMF requests the location information of the UE either through independent N2 procedure (i.e. NG-RAN location
reporting as specified in clause 4.10 of TS 23.502 [3]), or by including the request in some specific N2 messages as
specified in TS 38.413 [34].

5.4.8 Support for identification and restriction of using unlicensed

spectrum
Support for NG-RAN using unlicensed spectrum is defined in TS 38.300 [27] and TS 36.300 [27].

For NG-RAN, in the case of NR in stand-alone mode, all cells are in unlicensed spectrum and the NR is used as primary
RAT. NR or E-UTRA cells in unlicensed spectrum, can be used as secondary cells as specified in the Dual Connectivity
architecture defined in clause 5.11 or in addition can be configured to support the Carrier Aggregation Architecture
(CA) defined in TS 38.300 [27] and TS 36.300 [30].

For either case the serving PLMN can enforce Access Restriction for Unlicensed Spectrum (either signalled from the
UDM, or, locally generated by VPLMN policy in the AMF) with the following:

- To restrict the use of NR in unlicensed spectrum as primary RAT, the AMF rejects the UE Registration
procedure with appropriate cause code defined in TS 24.501 [47] if the UE performs initial access from NR

3GPP
Release 16 99 3GPP TS 23.501 V16.4.0 (2020-03)

using unlicensed spectrum. If the UE is accessing through some other allowed RAT, the AMF signals this access
restriction to NG-RAN as part of Mobility Restriction List.

- To restrict the use of use of unlicensed spectrum with NR or E-UTRA as secondary RAT using Dual
Connectivity or Carrier Aggregation Architecture (CA) defined in TS 38.300 [27] and TS 36.300 [30], the AMF
signals this access restriction to NG-RAN as part of Mobility Restriction List.

An NG-RAN node supporting aggregation with unlicensed spectrum using either NR or E-UTRA checks whether the
UE is allowed to use unlicensed spectrum based on received Mobility Restriction List. If the UE is not allowed to use
Unlicensed Spectrum, the NG-RAN node shall restrict the using of unlicensed spectrum, either NR or E-UTRA as
secondary RATs when using either Dual Connectivity or Carrier Aggregation (CA) as defined in TS 38.300 [27] and
TS 36.300 [30].

At inter-RAT handover from E-UTRAN/EPS, the Access Restriction for Unlicensed Spectrum is either already in the
AMF's UE context, or is obtained from the UDM during the subsequent Registration Area Update procedure (i.e. not
from the source MME or source RAN). In both inter-RAT handover cases, any Access Restriction for use of Unlicensed
Spectrum is then signalled to NG-RAN or enforced in AMF.

NOTE: This signalling of the Access Restriction during the Registration Area Update after the inter-RAT
handover procedure means that there is a small risk that unlicensed spectrum resources are transiently
allocated.

When the UE is accessing 5GS using unlicensed spectrum as primary RAT:

- The NG-RAN node shall provide an indication to the AMF in N2 interface that NR access is using unlicensed
spectrum as defined in TS 38.413 [34].

- In order to restrict access to NR in unlicensed spectrum, cells supporting NR in unlicensed spectrum have to be
deployed in Tracking Area(s) different to cells supporting licensed spectrum.

- When the AMF receives an indication from NG-RAN over N2 whether NR in unlicensed spectrum is being used
as defined in TS 38.413 [34], the AMF provides to the SMF an indication that the RAT type is NR with usage of
unlicensed spectrum during PDU Session Establishment or as part of the UP activation and Handover
procedures.

- The PCF will also receive the indication whether the UE is using NR in unlicensed spectrum, when applicable,
from the SMF during SM Policy Association Establishment or SM Policy Association Modification procedure.

- The NFs generating CDRs shall include the indication that the UE is using NR in unlicensed spectrum in their
CDRs.

When the UE is accessing NR or E-UTRA using unlicensed spectrum as secondary RAT, procedures for Usage Data
Reporting for Secondary RAT as defined in clause 5.12.2 can apply.

5.4.9 Wake Up Signal Assistance

To support the Wake Up Signal (WUS), the WUS Assistance Information is used by the NG-eNB to help determine the
WUS group used when paging the UE (see TS 36.300 [5]).

The content of the WUS Assistance Information consists of the paging probability information. The paging probability
information provides a metric on the probability of a UE receiving a paging message based on, e.g., statistical
information.

The UE may in the Registration Request message provide its capability to support receiving WUS Assistance
Information. If WUS Assistance Information is supported by the UE, then the UE in the Registration Request message
may provide the additional UE paging probability information. The AMF may use the UE provided paging probability,
local configuration and/or previous statistical information for the UE, when determining the WUS Assistance
Information. If the UE supports WUS Assistance Information, the AMF may assign WUS Assistance Information to the
UE, even when the UE has not provided the additional UE paging probability information.

If the AMF has determined WUS Assistance Information for the UE, the AMF provides it to the UE in every
Registration Accept message. The AMF stores the WUS Assistance Information parameter in the MM context and
provides it to the NG-eNB when paging the UE.

3GPP
Release 16 100 3GPP TS 23.501 V16.4.0 (2020-03)

UE and AMF shall not signal WUS Assistance Information in Registration Request, Registration Accept messages
when the UE has an active emergency PDU session.

5.5 Non-3GPP access specific aspects

5.5.0 General
This clause describe the specific aspects for untrusted non-3GPP access and trusted non-3GPP access.

5.5.1 Registration Management

This clause applies to Non-3GPP access network corresponding to the Untrusted Non-3GPP access network, to the
Trusted Non-3GPP and to the W-5GAN. In the case of W-5GAN the UE mentioned in this clause corresponds to 5G-
RG or to the W-AGF in the case of FN-RG. In the case of N5CW devices access 5GC via trusted WLAN access
networks, the UE mentioned in this clause corresponds to TWIF.

The UE shall enter RM-DEREGISTERED state and the AMF shall enter RM-DEREGISTERED state for the UE on
non-3GPP access as follows:

- at the UE and at the AMF, after performing an Explicit Deregistration procedure;

- at the AMF, after the Network non-3GPP Implicit Deregistration timer has expired.

- at the UE, after the UE non-3GPP Deregistration timer has expired.

NOTE: This is assumed to leave sufficient time to allow the UE to re-activate UP connections for the established
PDU Sessions over 3GPP or non-3GPP access.

Whenever a UE registered over non-3GPP access enters CM-IDLE state for the non-3GPP access, it starts the UE non-
3GPP Deregistration timer according to the value received from the AMF during a Registration procedure.

Over non-3GPP access, the AMF runs the Network non-3GPP Implicit Deregistration timer. The Network non-3GPP
Implicit Deregistration timer is started with a value longer than the UE's non-3GPP Deregistration timer, whenever the
CM state for the UE registered over non-3GPP access changes to CM-IDLE for the non-3GPP access.

For a UE that is registered over Non-3GPP access, a change of the point of attachment (e.g. change of WLAN AP) shall
not lead the UE to perform a Registration procedure.

A UE shall not provide 3GPP-specific parameters (e.g. indicate a preference for MICO mode) during registration over a
non-3GPP access.

5.5.2 Connection Management

This clause applies to Non-3GPP access network corresponding to the Untrusted Non-3GPP access network, to the
Trusted Non-3GPP and to the W-5GAN. The UE mentioned in this clause corresponds to the 5G-RG in the case of W-
5GAN and to the W-AGF in the case of FN-RG. In the case of N5CW devices access 5GC via trusted WLAN access
networks, the UE mentioned in this clause corresponds to TWIF.

A UE that successfully establishes a Non-3GPP Access Connection to the 5GC over a Non-3GPP access transitions to
CM-CONNECTED state for the Non-3GPP access.

In the case of Untrusted Non-3GPP access to 5GC, the Non-3GPP Access Connection corresponds to an NWu
connection.

In the case of Trusted access to 5GC, the Non-3GPP Access Connection corresponds to an NWt connection.

In the case of N5CW devices access 5GC via trusted WLAN access networks, the Non-3GPP Access Connection
corresponds to an Yt connection.

In the case of Wireline access to 5GC, the Non-3GPP Access Connection corresponds to a Y4 connection and to Y5
connection.

3GPP
Release 16 101 3GPP TS 23.501 V16.4.0 (2020-03)

A UE does not establish multiple simultaneous Non-3GPP Access Connection to the 5GC.

The Non-3GPP Access Connection is released either as a result of an Explicit Deregistration procedure or an AN
Release procedure.

In the case of Untrusted Non-3GPP access, Trusted Non-3GPP access and W-5GAN access to 5GC, the N3IWF,
TNGF, TWIF and W-AGF may in addition explicitly release the NWu, NWt, Yt, Y4 and Y5 signalling connection due
to NWu, NWt, Yt, Y4 and Y5 connection failure, respectively. In the case of NWu and NWt, the release may be
determined by the "dead peer detection" mechanism in IKEv2 defined in RFC 7296 [60]. In the case of Y4 and Y5 the
release may be detected for example by lost of synchronisation of physical link, lost of PPPoE session, etc. Further
details on how NWu, NWt, Yt, Y4 and Y5 connection failure is detected is out of scope of 3GPP specifications.

For W-5GCAN, the W-AGF explicitly releases the N2 connection due to Y4 or Y5 connection failure, as determined by
the "dead peer detection" mechanism in DOCSIS MULPI [89].

The release of the Non-3GPP Access Connection between the UE and the N3IWF, TNGF, TWIF or W-AGF shall be
interpreted as follows:

- By the N3IWF, TNGF, TWIF and W-AGF as a criterion to release the N2 connection.

- By the UE as a criterion for the UE to transition to CM-IDLE. A UE registered over non-3GPP access remains in
RM-REGISTERED state, unless the Non-3GPP Access Connection release occurs as part of a Deregistration
procedure over non-3GPP access in which case the UE enters the RM-DEREGISTERED state. When the UE in
RM-REGISTERED transitions to CM-IDLE, the UE non-3GPP Deregistration timer starts running in the UE.
The UE non-3GPP Deregistration timer stops when the UE moves to CM-CONNECTED state or to the RM-
DEREGISTERED state.

NOTE 1: When moved to CM-IDLE state over one access, the UE can attempt to re-activate UP connections for
the PDU Sessions over other access, per UE policies and depending on the availability of these accesses.

NOTE 2: The release of the NWu, NWt, Yt, Y4 or Y5 at the UE can occur as a result of explicit signalling from the
N3IWF, TNGF, TWIF or W-AGF respectively, e.g. IKE INFORMATION EXCHANGE in the case of
NWu or as a result of the UE detecting NWu, NWt, Yt, Y4 or Y5 connection failure, e.g. as determined
by the "dead peer detection" mechanism in IKEv2 as defined in RFC 7296 [60] for NWu, NWt and Yt or
W-5GAN access specific mechanism for Y4 and Y5. Further details on how the UE detects NWu, NWt,
Yt, Y4 or Y5 connection failure is out of scope of 3GPP specifications.

In the case of Non-3GPP access, when the AMF releases the N2 interface, the N3IWF, TNGF, TWIF and W-AGF shall
release all the resources associated with the UE including the Non-3GPP Access Connection with the UE and its
corresponding N3 resources. A release of the N2 connection by the AMF shall set the CM state for the UE in the AMF
to CM-IDLE.

NOTE 3: It is assumed that a UE configured to receive services from a 5GC over non-3GPP access that is RM-
DEREGISTERED or CM-IDLE over the non-3GPP access will attempt to establish Non-3GPP Access
Connection and transition to CM-CONNECTED state whenever the UE successfully connects to a non-
3GPP access unless prohibited by the network to make a N3GPP Access Connection (e.g. due to network
congestion).

An UE cannot be paged on Non-3GPP access network.

When a UE registered simultaneously over a 3GPP access and a non-3GPP access moves all the PDU Sessions to one
of the accesses, whether the UE initiates a Deregistration procedure in the access that has no PDU Sessions is up to the
UE implementation.

Release of PDU Sessions over the non-3GPP access does not imply the release of N2 connection.

When the UE has PDU Sessions routed over the non-3GPP access and the UE state becomes CM-IDLE for the non-
3GPP access, these PDU Sessions are not released to enable the UE to move the PDU Sessions over the 3GPP access
based on UE policies. The core network maintains the PDU Sessions but deactivates the N3 user plane connection for
such PDU Sessions.

3GPP
Release 16 102 3GPP TS 23.501 V16.4.0 (2020-03)

5.5.3 UE Reachability

5.5.3.1 UE reachability in CM-IDLE

This clause applies to Non-3GPP access network corresponding to the Untrusted Non-3GPP access network, to the
Trusted Non-3GPP and to the W-5GAN. The UE mentioned in this clause corresponds to 5G-RG, in the case of W-
5GAN or to W-AGF in the case of support of FN-RG. In the case of N5CW devices access 5GC via trusted WLAN
access networks, the UE mentioned in this clause corresponds to TWIF.

An UE cannot be paged over Non-3GPP access network.

If the UE states in the AMF are CM-IDLE and RM-REGISTERED for the non-3GPP access, there may be PDU
Sessions that were last routed over the non-3GPP access and without user plane resources. If the AMF receives a
message with a Non-3GPP Access Type indication from an SMF for a PDU Session corresponding to a UE that is CM-
IDLE for non-3GPP access, and the UE is registered over 3GPP access in the same PLMN as the one registered over
non-3GPP access, a Network Triggered Service Request may be performed over the 3GPP access independently of
whether the UE is CM-IDLE or CM-CONNECTED over the 3GPP access. In this case, the AMF provides an indication
that the procedure is related to non-3GPP access, as specified in clause 5.6.8.

NOTE: The UE behaviour upon such network triggered Service Request is specified in clause 5.6.8.

5.5.3.2 UE reachability in CM-CONNECTED

This clause applies to Non-3GPP access network corresponding to the Untrusted Non-3GPP access network, to the
Trusted Non-3GPP and to the W-5GAN. In the case of W-5GAN the UE mentioned in this clause corresponds to 5G-
RG and to W-AGF in the case of support of FN-RG. In the case of N5CW devices access 5GC via trusted WLAN
access networks, the UE mentioned in this clause corresponds to TWIF.

For a UE in CM-CONNECTED state:

- the AMF knows the UE location on a N3IWF, TNGF, TWIF and W-AGF node granularity.

- the N3IWF, TNGF, TWIF and W-AGF releases the N2 connection when UE becomes unreachable from
N3IWF, TNGF, TWIF and W-AGF point of view, i.e. upon Non-3GPP Access Connection release.

5.6 Session Management

5.6.1 Overview
The 5GC supports a PDU Connectivity Service i.e. a service that provides exchange of PDUs between a UE and a data
network identified by a DNN. The PDU Connectivity Service is supported via PDU Sessions that are established upon
request from the UE.

The Subscription Information for each S-NSSAI may contain a Subscribed DNN list and one default DNN. When the
UE does not provide a DNN in a NAS Message containing PDU Session Establishment Request for a given S-NSSAI,
the serving AMF determines the DNN for the requested PDU Session by selecting the default DNN for this S-NSSAI if
a default DNN is present in the UE's Subscription Information; otherwise the serving AMF selects a locally configured
DNN for this S-NSSAI.

The expectation is that the URSP in the UE is always up to date using the procedure defined in TS 23.502 [3]
clause 4.16.12.2 and therefore the UE requested DNN will be up to date.

In order to cover cases that UE operates using local configuration, but also other cases where operator policies can be
used in order to replace an "up to date" UE requested DNN with another DNN used only internally in the network,
during UE Registration procedure the PCF may indicate, to the AMF, the operator policies to be used at PDU Session
Establishment for DNN replacement of a UE requested DNN. PCF may indicate a policy for DNN replacement of UE
requested DNNs not supported by the network, and/or indicate a list of UE requested DNNs per S-NSSAI valid for the
serving network, that are subject for replacement (details are described in TS 23.503 [45]).

If the DNN provided by the UE is not supported by the network and AMF cannot select an SMF by querying NRF, the
AMF shall reject the NAS Message containing PDU Session Establishment Request from the UE with a cause

3GPP
Release 16 103 3GPP TS 23.501 V16.4.0 (2020-03)

indicating that the DNN is not supported unless the PCF provided the policy to perform a DNN replacement of
unsupported DNNs.

If the DNN requested by the UE is indicated for replacement or the DNN provided by the UE is not supported by the
network and the PCF provided the policy to perform DNN replacement of UE requested DNNs not supported by the
network, the AMF shall interact with the PCF to perform a DNN replacement. During PDU Session Establishment
procedure and as a result of DNN replacement, the PCF provides the selected DNN that is applicable for the S-NSSAI
requested by the UE at the PDU Session Establishment. The AMF uses the selected DNN in the query towards the NRF
for the SMF selection, as specified in clause 6.3.2, and provides both requested and selected DNN to the selected SMF.
For PDU Session with Home-routed Roaming whether to perform DNN replacement is based on operator agreements.

NOTE 1: The selected DNN is determined based on operator preferences and can differ from subscribed DNNs.
The matching of selected DNN to S-NSSAI is assumed to be based on network configuration.

Each PDU Session supports a single PDU Session type i.e. supports the exchange of a single type of PDU requested by
the UE at the establishment of the PDU Session. The following PDU Session types are defined: IPv4, IPv6, IPv4v6,
Ethernet, Unstructured.

PDU Sessions are established (upon UE request), modified (upon UE and 5GC request) and released (upon UE and
5GC request) using NAS SM signalling exchanged over N1 between the UE and the SMF. Upon request from an
Application Server, the 5GC is able to trigger a specific application in the UE. When receiving that trigger message, the
UE shall pass it to the identified application in the UE. The identified application in the UE may establish a PDU
Session to a specific DNN, see clause 4.4.5.

SMF may support PDU Sessions for LADN where the access to a DN is only available in a specific LADN service area.
This is further defined in clause 5.6.5.

SMF may support PDU Sessions for a 5G VN group which offers a virtual data network capable of supporting 5G
LAN-type service over the 5G system. This is further defined in clause 5.8.2.13.

The SMF is responsible of checking whether the UE requests are compliant with the user subscription. For this purpose,
it retrieves and requests to receive update notifications on SMF level subscription data from the UDM. Such data may
indicate per DNN and per S-NSSAI of the HPLMN:

- The allowed PDU Session Types and the default PDU Session Type.

- The allowed SSC modes and the default SSC mode.

- QoS Information (refer to clause 5.7): the subscribed Session-AMBR, Default 5QI and Default ARP.

- The static IP address/prefix.

- The subscribed User Plane Security Policy.

- the Charging Characteristics to be associated with the PDU Session. Whether this information is provided by the
UDM to a SMF in another PLMN (for PDU Sessions in LBO mode) is defined by operator policies in the
UDM/UDR.

NOTE 2: The content of the Charging Characteristics as well as the usage of the Charging Characteristics by the
SMF are defined in TS 32.240 [41].

A PDU Session may support:

(a) a single-access PDU Connectivity Service, in which case the PDU Session is associated with a single access type
at a given time, i.e. either 3GPP access or non-3GPP access; or

(b) a multi-access PDU Connectivity Service, in which case the PDU Session is simultaneously associated with both
3GPP access and non-3GPP access and simultaneously associated with two independent N3/N9 tunnels between
the PSA and RAN/AN.

A PDU Session supporting a single-access PDU Connectivity Service is also referred to as single-access PDU Session,
while a PDU Session supporting a multi-access PDU Connectivity Service is referred to as Multi-Access PDU (MA
PDU) Session and it is used to support the ATSSS feature (see clause 5.32 for details).

3GPP
Release 16 104 3GPP TS 23.501 V16.4.0 (2020-03)

A UE that is registered over multiple accesses chooses over which access to establish a PDU Session. As defined in
TS 23.503 [45], the HPLMN may send policies to the UE to guide the UE selection of the access over which to
establish a PDU Session.

NOTE 3: In this Release of the specification, at any given time, a PDU Session is routed over only a single access
network, unless it is an MA PDU Session in which case it can be routed over one 3GPP access network
and one Non 3GPP access network concurrently.

A UE may request to move a single-access PDU Session between 3GPP and Non 3GPP accesses. The decision to move
single-access PDU Sessions between 3GPP access and Non 3GPP access is made on a per PDU Session basis, i.e. the
UE may, at a given time, have some PDU Sessions using 3GPP access while other PDU Sessions are using Non 3GPP
access.

In a PDU Session Establishment Request message sent to the network, the UE shall provide a PDU Session ID. The
PDU Session ID is unique per UE and is the identifier used to uniquely identify one of a UE's PDU Sessions. The PDU
Session ID shall be stored in the UDM to support handover between 3GPP and non-3GPP access when different
PLMNs are used for the two accesses. The UE also provides as described in TS 24.501 [47]:

(a) PDU Session Type.

(b) S-NSSAI of the HPLMN that matches the application (that is triggering the PDU Session Request) within the
NSSP in the URSP rules or within the UE Local Configuration as defined in clause 6.1.2.2.1 of TS 23.503 [45].

NOTE 4: If the UE cannot determine any S-NSSAI after performing the association of the application to a PDU
Session, then it does not indicate any S-NSSAI in the PDU Session Establishment procedure as defined in
clause 5.15.5.3.

(c) S-NSSAI of the Serving PLMN from the Allowed NSSAI, corresponding to the S-NSSAI of the HPLMN (b).

NOTE 5: Generally, in non-roaming scenario the mapping of the Allowed NSSAI to HPLMN S-NSSAIs is not
provided to the UE (because the S-NSSAI of the Serving PLMN (c) has the same value of the S-NSSAI
of the HPLMN (b)), therefore the UE provides in the PDU Session Request only the S-NSSAI of the
Serving PLMN (c). However, if the UE is provided with the mapping of the Allowed NSSAI to HPLMN
S-NSSAIs even in non-roaming scenario, then the UE provides in the PDU Session Request both the S-
NSSAI of the HPLMN (b) and the S-NSSAI from the Allowed NSSAI (c) that maps to the S-NSSAI of
the HPLMN.

NOTE 6: In roaming scenarios the UE provides in the PDU Session Request both the S-NSSAI of the HPLMN (b)
and the S-NSSAI of the VPLMN from the Allowed NSSAI (c) that maps to the S-NSSAI of the HPLMN.

(d) DNN (Data Network Name).

(e) SSC mode (Service and Session Continuity mode defined in clause 5.6.9.2).

Additionally, if the UE supports ATSSS and wants to activate a MA PDU Session, the UE shall provide Request Type
as "MA PDU Request" and shall indicate the supported ATSSS capabilities (see clause 5.32 for details).

3GPP
Release 16 105 3GPP TS 23.501 V16.4.0 (2020-03)

Table 5.6.1-1: Attributes of a PDU Session

PDU Session attribute May be modified later during Notes

the lifetime of the PDU Session
S-NSSAI of the HPLMN No (Note 1) (Note 2)
S-NSSAI of the Serving Yes (Note 1) (Note 2) (Note 4)
PLMN
DNN (Data Network Name) No (Note 1) (Note 2)
PDU Session Type No (Note 1)
SSC mode No (Note 2)
The semantics of Service and
Session Continuity mode is
defined in clause 5.6.9.2
PDU Session Id No
User Plane Security No (Note 3)
Enforcement information
Multi-access PDU No Indicates if the PDU Session
Connectivity Service provides multi-access PDU
Connectivity Service or not.
NOTE 1: If it is not provided by the UE, the network determines the parameter based on default
information received in user subscription. Subscription to different DNN(s) and S-
NSSAI(s) may correspond to different default SSC modes and different default PDU
Session Types
NOTE 2: S-NSSAI(s) and DNN are used by AMF to select the SMF(s) to handle a new session.
Refer to clause 6.3.2.
NOTE 3: User Plane Security Enforcement information is defined in clause 5.10.3.
NOTE 4: The S-NSSAI value of the Serving PLMN associated to a PDU Session can change
whenever the UE moves to a different PLMN, while keeping that PDU Session.

Subscription Information may include a wildcard DNN per subscribed S-NSSAI: when a wildcard DNN is associated
with a subscribed S-NSSAI, the subscription allows, for this S-NSSAI, the UE to establish a PDU Session using any
DNN value.

NOTE 7: The SMF is made aware whether the DNN of a PDU Session being established corresponds to an
explicitly subscribed DNN or corresponds to a wildcard DNN. Thus, the SMF can reject a PDU Session
establishment if the DNN of the PDU Session is not part of explicitly subscribed DNN(s) and local
policies in the SMF require UE to have a subscription to this DNN.

A UE may establish multiple PDU Sessions, to the same data network or to different data networks, via 3GPP and via
and Non-3GPP access networks at the same time.

A UE may establish multiple PDU Sessions to the same Data Network and served by different UPF terminating N6.

A UE with multiple established PDU Sessions may be served by different SMF.

The SMF shall be registered and deregistered on a per PDU Session granularity in the UDM.

The user plane paths of different PDU Sessions (to the same or to different DNN) belonging to the same UE may be
completely disjoint between the AN and the UPF interfacing with the DN.

When the SMF cannot control the UPF terminating the N3 interface used by a PDU Session and SSC mode 2/3
procedures are not applied to the PDU Session, an I-SMF is inserted between the SMF and the AMF and handling of
PDU Session(s) is described in clause 5.34.

NOTE 8: User Plane resources for PDU Sessions of a UE, except for regulatory prioritized service like Emergency
Services and MPS, can be deactivated by the SMF if the UE is only reachable for regulatory prioritized
services.

The SMF serving a PDU session (i.e. Anchor) does not change during lifetime of the PDU session.

5.6.2 Interaction between AMF and SMF

The AMF and SMF are separate Network Functions.

N1 related interaction with SMF is as follows:

3GPP
Release 16 106 3GPP TS 23.501 V16.4.0 (2020-03)

- The single N1 termination point is located in AMF. The AMF forwards SM related NAS information to the SMF
based on the PDU Session ID in the NAS message. Further SM NAS exchanges (e.g. SM NAS message
responses) for N1 NAS signalling received by the AMF over an access (e.g. 3GPP access or non-3GPP access)
are transported over the same access.

- The serving PLMN ensures that subsequent SM NAS exchanges (e.g. SM NAS message responses) for N1 NAS
signalling received by the AMF over an access (e.g. 3GPP access or non-3GPP access) are transported over the
same access.

- SMF handles the Session management part of NAS signalling exchanged with the UE.

- The UE shall only initiate PDU Session Establishment in RM-REGISTERED state.

- When a SMF has been selected to serve a specific PDU Session, AMF has to ensure that all NAS signalling
related with this PDU Session is handled by the same SMF instance.

- Upon successful PDU Session Establishment, the AMF and SMF stores the Access Type that the PDU Session is
associated.

N11 related interaction with SMF is as follows:

- The AMF reports the reachability of the UE based on a subscription from the SMF, including:

- The UE location information with respect to the area of interest indicated by the SMF.

- The SMF indicates to AMF when a PDU Session has been released.

- Upon successful PDU Session Establishment, AMF stores the identification of serving SMF of UE and SMF
stores the identification of serving AMF of UE including the AMF set. When trying to reach the AMF serving
the UE, the SMF may need to apply the behaviour described for "the other CP NFs" in clause 5.21.

N2 related interaction with SMF is as follows:

- Some N2 signalling (such as handover related signalling) may require the action of both AMF and SMF. In such
case, the AMF is responsible to ensure the coordination between AMF and SMF. The AMF may forward the SM
N2 signalling towards the corresponding SMF based on the PDU Session ID in N2 signalling.

- SMF shall provide PDU Session Type together with PDU Session ID to NG-RAN, in order to facilitate NG-
RAN to apply suitable header compression mechanism to packet of different PDU type. Details refer to
TS 38.413 [34].

N3 related interaction with SMF is as follows:

- Selective activation and deactivation of UP connection of existing PDU Session is defined in clause 5.6.8.

N4 related interaction with SMF is as follows:

- When it is made aware by the UPF that some DL data has arrived for a UE without downlink N3 tunnel
information, the SMF interacts with the AMF to initiate Network Triggered Service Request procedure. In this
case, if the SMF is aware that the UE is unreachable or if the UE is reachable only for regulatory prioritized
service and the PDU Session is not for regulatory prioritized service, then the SMF shall not inform DL data
notification to the AMF

The AMF is responsible of selecting the SMF per procedures described in clause 6.3.2. For this purpose, it gets
subscription data from the UDM that are defined in that clause. Furthermore, it retrieves the subscribed UE-AMBR
from the UDM, and optionally dynamic serving network UE-AMBR from PCF based on operator local policy, and
sends to the (R)AN as defined in clause 5.7.2

AMF-SMF interactions to support LADN are defined in clause 5.6.5.

In order to support charging data collection and to fulfill regulatory requirement (in order to provide NPLI - Network
Provided Location Information- as defined in TS 23.228 [15]) related with with the set-up, modification and release of
IMS Voice calls or with SMS transfer the following applies

- At the time of the PDU Session Establishment, the AMF provides the SMF with the PEI of the UE if the PEI is
available at the AMF.

3GPP
Release 16 107 3GPP TS 23.501 V16.4.0 (2020-03)

- When it forwards UL NAS or N2 signalling to a peer NF (e.g. to SMF or to SMSF) or during the UP connection
activation of a PDU Session, the AMF provides any User Location Information it has received from the 5G-AN
as well as the Access Type (3GPP - Non 3GPP) of the AN over which it has received the UL NAS or N2
signalling. The AMF also provides the corresponding UE Time Zone. In addition, in order to fulfill regulatory
requirement (i.e. providing Network Provided Location Information (NPLI), as defined in TS 23.228 [15]) when
the access is non-3GPP, the AMF may also provide the last known 3GPP access User Location Information with
its age, if the UE is still attached to the same AMF for 3GPP access (i.e. valid User Location Information).

The User Location Information, the access type and the UE Time Zone may be further provided by SMF to PCF. The
PCF may get this information from the SMF in order to provide NPLI to applications (such as IMS) that have requested
it.

The User Location Information may correspond to:

- In the case of 3GPP access: Cell-Id. The AMF includes only the Primary Cell-Id even if it had received also the
Cell-Id of the Primary cell in the Secondary RAN node from NG-RAN.

- In the case of Untrusted non-3GPP access: a UE local IP address (used to reach the N3IWF) and optionally UDP
or TCP source port number (if NAT is detected).

- In the case of Trusted non-3GPP access: TNAP/TWAP Identifier, a UE/N5CW device local IP address (used to
reach the TNGF/TWIF) and optionally UDP or TCP source port number (if NAT is detected).

When the UE uses WLAN based on IEEE 802.11 technology to reach the TNGF, the TNAP Identifier shall
include the SSID of the access point to which the UE is attached. The TNAP Identifier shall include at least one
of the following elements, unless otherwise determined by the TWAN operator's policies:

- the BSSID (see IEEE Std 802.11-2012 [106]);

- civic address information of the TNAP to which the UE is attached.

The TWAP Identifier shall include the SSID of the access point to which the NC5W is attached. The TWAP
Identifier shall also include at least one of the following elements, unless otherwise determined by the TWAN
operator's policies:

- the BSSID (see IEEE Std 802.11-2012 [106]);

- civic address information of the TWAP to which the UE is attached.

NOTE 1: The SSID can be the same for several TNAPs/TWAPs and SSID only cannot provide a location, but it
might be sufficient for charging purposes.

NOTE 2: the BSSID associated with a TNAP/TWAP is assumed to be static.

- In the case of W-5GAN access: The User Location Information for W-5GAN is defined in TS 23.316 [84].

When the SMF receives a request to provide Access Network Information reporting while there is no action to carry out
towards the 5G-AN or the UE (e.g. no QoS flow to create / Update / modify), the SMF may request User Location
Information from the AMF.

The interaction between AMF and SMF(s) for the case of a I-SMF insertion, relocation or removal for a PDU session is
described in clause 5.34.

5.6.3 Roaming
In the case of roaming the 5GC supports following possible deployments scenarios for a PDU Session:

- "Local Break Out" (LBO) where the SMF and all UPF(s) involved by the PDU Session are under control of the
VPLMN.

- "Home Routed" (HR) where the PDU Session is supported by a SMF function under control of the HPLMN, by
a SMF function under control of the VPLMN, by at least one UPF under control of the HPLMN and by at least
one UPF under control of the VPLMN. In this case the SMF in HPLMN selects the UPF(s) in the HPLMN and
the SMF in VPLMN selects the UPF(s) in the VPLMN. This is further described in clause 6.3.

3GPP
Release 16 108 3GPP TS 23.501 V16.4.0 (2020-03)

NOTE 1: The use of an UPF in the VPLMN e.g. enables VPLMN charging, VPLMN LI and minimizes the impact
on the HPLMN of the UE mobility within the VPLMN (e.g. for scenarios where SSC mode 1 applies).

Different simultaneous PDU Sessions of an UE may use different modes: Home Routed and LBO. The HPLMN can
control via subscription data per DNN and per S-NSSAI whether a PDU Session is to be set-up in HR or in LBO mode.

In the case of PDU Sessions per Home Routed deployment:

- NAS SM terminates in the SMF in VPLMN.

- The SMF in VPLMN forwards to the SMF in the HPLMN SM related information.

- The SMF in the HPLMN receives the SUPI of the UE from the SMF in the VPLMN during the PDU Session
Establishment procedure.

- The SMF in HPLMN is responsible to check the UE request with regard to the user subscription and to possibly
reject the UE request in the case of mismatch. The SMF in HPLMN obtains subscription data directly from the
UDM.

- The SMF in HPLMN may send QoS requirements associated with a PDU Session to the SMF in VPLMN. This
may happen during the PDU Session Establishment procedure and after the PDU Session is established. The
interface between SMF in HPLMN and SMF in VPLMN is also able to carry (N9) User Plane forwarding
information exchanged between SMF in HPLMN and SMF in VPLMN. The SMF in the VPLMN may check
QoS requests from the SMF in HPLMN with respect to roaming agreements.

In home routed roaming case, the AMF selects an SMF in the VPLMN and a SMF in the HPLMN as described in
clause 6.3.2 and TS 23.502 [3] clause 4.3.2.2.3.3, and provides the identifier of the selected SMF in the HPLMN to the
selected SMF in the VPLMN.

In roaming with LBO, the AMF selects a SMF in the VPLMN as described in clause 6.3.2 and TS 23.502 [3]
clause 4.3.2.2.3.2. In this case, when handling a PDU Session Establishment Request message, the SMF in the VPLMN
may reject the N11 message (related with the PDU Session Establishment Request message) with a proper N11 cause.
This triggers the AMF to select both a new SMF in the VPLMN and a SMF in the HPLMN in order to handle the PDU
Session using home routed roaming.

5.6.4 Single PDU Session with multiple PDU Session Anchors

5.6.4.1 General
In order to support selective traffic routing to the DN or to support SSC mode 3 as defined in clause 5.6.9.2.3, the SMF
may control the data path of a PDU Session so that the PDU Session may simultaneously correspond to multiple N6
interfaces. The UPF that terminates each of these interfaces is said to support PDU Session Anchor functionality. Each
PDU Session Anchor supporting a PDU Session provides a different access to the same DN. Further, the PDU Session
Anchor assigned at PDU Session Establishment is associated with the SSC mode of the PDU Session and the additional
PDU Session Anchor(s) assigned within the same PDU Session e.g. for selective traffic routing to the DN are
independent of the SSC mode of the PDU Session. When a PCC rule including the AF influenced Traffic Steering
Enforcement Control information defined in clause 6.3.1 of TS 23.503 [4] is provided to the SMF, the SMF can decide
whether to apply traffic routing (by using UL Classifier functionality or IPv6 multi-homing) based on DNAI(s) included
in the PCC rule.

NOTE 1: AF influenced Traffic Steering Enforcement Control information can be either determined by the PCF
when requested by AF via NEF as described in clause 5.6.7.1 or statically pre-configured in the PCF.

NOTE 2: Selective traffic routing to the DN supports, for example, deployments where some selected traffic is
forwarded on an N6 interface to the DN that is "close" to the AN serving the UE.

This may correspond to

- The Usage of UL Classifier functionality for a PDU Session defined in clause 5.6.4.2.

- The Usage of an IPv6 multi-homing for a PDU Session defined in clause 5.6.4.3.

3GPP
Release 16 109 3GPP TS 23.501 V16.4.0 (2020-03)

5.6.4.2 Usage of an UL Classifier for a PDU Session

In the case of PDU Sessions of type IPv4 or IPv6 or IPv4v6 or Ethernet, the SMF may decide to insert in the data path
of a PDU Session an "UL CL" (Uplink classifier). The UL CL is a functionality supported by an UPF that aims at
diverting (locally) some traffic matching traffic filters provided by the SMF. The insertion and removal of an UL CL is
decided by the SMF and controlled by the SMF using generic N4 and UPF capabilities. The SMF may decide to insert
in the data path of a PDU Session a UPF supporting the UL CL functionality during or after the PDU Session
Establishment, or to remove from the data path of a PDU Session a UPF supporting the UL CL functionality after the
PDU Session Establishment. The SMF may include more than one UPF supporting the UL CL functionality in the data
path of a PDU Session.

The UE is unaware of the traffic diversion by the UL CL, and does not involve in both the insertion and the removal of
UL CL. In the case of a PDU Session of IPv4 or IPv6 or IPv4v6 type, the UE associates the PDU Session with either a
single IPv4 address or a single IPv6 Prefix or both of them allocated by the network.

When an UL CL functionality has been inserted in the data path of a PDU Session, there are multiple PDU Session
Anchors for this PDU Session. These PDU Session Anchors provide different access to the same DN. In the case of a
PDU Session of IPv4 or IPv6 or IPv4v6 type, only one IPv4 address and/or IPv6 prefix is provided to the UE. The SMF
may be configured with local policies for some (DNN, S-NSSAI) combinations to release the PDU Session when there
is a PSA associated with the IPv4 address allocated to the UE and this PSA has been removed.

NOTE 0: The use of only one IPv4 address and/or IPv6 prefix with multiple PDU Session Anchors assumes that
when needed, appropriate mechanisms are in place to correctly forward packets on the N6 reference
point. The mechanisms for packet forwarding on the N6 reference point between the PDU Session
Anchor providing local access and the DN are outside the scope of this specification.

The UL CL provides forwarding of UL traffic towards different PDU Session Anchors and merge of DL traffic to the
UE i.e. merging the traffic from the different PDU Session Anchors on the link towards the UE. This is based on traffic
detection and traffic forwarding rules provided by the SMF.

The UL CL applies filtering rules (e.g. to examine the destination IP address/Prefix of UL IP packets sent by the UE)
and determines how the packet should be routed. The UPF supporting an UL CL may also be controlled by the SMF to
support traffic measurement for charging, traffic replication for LI and bit rate enforcement (Session-AMBR per PDU
Session).

NOTE 1: When N9 forwarding tunnel exists between source ULCL and target ULCL, the Session-AMBR per PDU
Session can be enforced by the source UL CL UPF.

NOTE 2: The UPF supporting an UL CL may also support a PDU Session Anchor for connectivity to the local
access to the data network (including e.g. support of tunnelling or NAT on N6). This is controlled by the
SMF.

Additional UL CLs (and thus additional PDU Session Anchors) can be inserted in the data path of a PDU Session to
create new data paths for the same PDU Session. The way to organize the data path of all UL CLs in a PDU Session is
up to operator configuration and SMF logic and there is only one UPF supporting UL CL connecting to the (R)AN via
N3 interface, except when session continuity upon UL CL relocation is used.

The insertion of an ULCL in the data path of a PDU Session is depicted in Figure 5.6.4.2-1.

3GPP
Release 16 110 3GPP TS 23.501 V16.4.0 (2020-03)

N11
AMF SMF N4

N1 N2 N4 N4 UPF
N9 N6
PDU session DN
anchor 1

N3 UPF
UE AN Uplink Classifier

N9

UPF N6
PDU session
DN
anchor 2
Local access to the same DN

Figure 5.6.4.2-1: User plane Architecture for the Uplink Classifier

NOTE 3: It is possible for a given UPF to support both the UL CL and the PDU Session Anchor functionalities.

Due to UE mobility the network may need to relocate the UPF acting as UL CL and establish a new PSA for access to
the local DN. To support session continuity during UL CL relocation the network may establish a temporary N9
forwarding tunnel between the source UL CL and target UL CL.

The N9 forwarding tunnel is maintained until all active traffic flowing on it ceases to exist for a configurable period of
time or until the AF informs the SMF that it can release the source PSA providing access to the source local DN.

During the existence of the N9 forwarding tunnel the UPF acting as target UL CL is configured with packet filters that:

- force uplink traffic from existing data sessions between UE and the application in the source local DN into the
N9 forwarding tunnel towards the source UL CL.

- force any traffic related to the application in the target local DN to go to the new local DN via the target PSA.

SMF may send a Late Notification to AF to inform it about the DNAI change as described in TS 23.502 [3]
clause 4.3.6.3. This notification can be used by the AF e.g. to trigger mechanisms in the source local DN to redirect the
ongoing traffic sessions towards an application in the target local DN. SMF can also send late notification to the target
AF instance if associated with this target local DN.

The procedure for session continuity upon UL CL relocation is described in TS 23.502 [3] clause 4.3.5.7.

When an I-SMF is inserted for a PDU Session, the details of UL CL insertion which is controlled by an I-SMF is
described in clause 5.34.4.

5.6.4.3 Usage of IPv6 multi-homing for a PDU Session

A PDU Session may be associated with multiple IPv6 prefixes. This is referred to as multi-homed PDU Session. The
multi-homed PDU Session provides access to the Data Network via more than one PDU Session Anchor. The different
user plane paths leading to the different PDU Session Anchors branch out at a "common" UPF referred to as a UPF
supporting "Branching Point" functionality. The Branching Point provides forwarding of UL traffic towards the
different PDU Session Anchors and merge of DL traffic to the UE i.e. merging the traffic from the different PDU
Session Anchors on the link towards the UE.

The UPF supporting a Branching Point functionality may also be controlled by the SMF to support traffic measurement
for charging, traffic replication for LI and bit rate enforcement (Session-AMBR per PDU Session). The insertion and
removal of a UPF supporting Branching Point is decided by the SMF and controlled by the SMF using generic N4 and
UPF capabilities. The SMF may decide to insert in the data path of a PDU Session a UPF supporting the Branching
Point functionality during or after the PDU Session Establishment, or to remove from the data path of a PDU Session a
UPF supporting the Branching Point functionality after the PDU Session Establishment.

Multi homing of a PDU Session applies only for PDU Sessions of IPv6 type. When the UE requests a PDU Session of
type "IPv4v6" or "IPv6" the UE also provides an indication to the network whether it supports a Multi-homed IPv6
PDU Session.

3GPP
Release 16 111 3GPP TS 23.501 V16.4.0 (2020-03)

The use of multiple IPv6 prefixes in a PDU Session is characterised by the following:

- The UPF supporting a Branching Point functionality is configured by the SMF to spread UL traffic between the
PDU Session Anchors based on the Source Prefix of the PDU (which may be selected by the UE based on
routing information and preferences received from the network).

- IETF RFC 4191 [8] is used to configure routing information and preferences into the UE to influence the
selection of the source Prefix.

NOTE 1: This corresponds to Scenario 1 defined in IETF RFC 7157 [7] "IPv6 Multi-homing without Network
Address Translation". This allows to make the Branching Point unaware of the routing tables in the Data
Network and to keep the first hop router function in the PDU Session Anchors.

- The multi-homed PDU Session may be used to support make-before-break service continuity to support SSC
mode 3. This is illustrated in Figure 5.6.4.3-1.

- The multi-homed PDU Session may also be used to support cases where UE needs to access both a local service
(e.g. local server) and a central service (e.g. the internet), illustrated in Figure 5.6.4.3-2.

- The UE shall use the method specified in TS 23.502 [3], clause 4.3.5.3, to determine if a multi-homed PDU
Session is used to support the service continuity case shown in Figure 5.6.4.3-1, or if it is used to support the
local access to DN case shown in Figure 5.6.4.3-2.

N11
AMF SMF N4

N1 N2 N4 N4 UPF N6
PDU session
anchor 1
N9
N3 UPF make-before-break
UE AN Branching Point
PSA relocation DN
N9
UPF N6
PDU session
anchor 2

Figure 5.6.4.3-1: Multi-homed PDU Session: service continuity case

NOTE 2: It is possible for a given UPF to support both the Branching Point and the PDU Session Anchor
functionalities.

N11
AMF SMF N4

N1 N2 N4 N4 UPF
N9 N6
PDU session DN
anchor 1

N3 UPF
UE AN Branching Point

N9

UPF N6
PDU session
DN
anchor 2
Local access to the same DN

Figure 5.6.4.3-2: Multi-homed PDU Session: local access to same DN

NOTE 3: It is possible for a given UPF to support both the Branching Point and the PDU Session Anchor
functionalities.

3GPP
Release 16 112 3GPP TS 23.501 V16.4.0 (2020-03)

5.6.5 Support for Local Area Data Network

The access to a DN via a PDU Session for a LADN is only available in a specific LADN service area. A LADN service
area is a set of Tracking Areas. LADN is a service provided by the serving PLMN. It includes:

- LADN service applies only to 3GPP accesses and does not apply in Home Routed case.

- The usage of LADN DNN requires an explicit subscription to this DNN or subscription to a wildcard DNN.

- Whether a DNN corresponds to a LADN service is an attribute of a DNN and is per PLMN.

The UE is configured to know whether a DNN is a LADN DNN on a per-PLMN basis, and an association between
application and LADN DNN. The configured association is considered to be a UE local configuration defined in
TS 23.503 [45]. Alternatively, the UE gets the information whether a DNN is a LADN DNN from LADN Information
during (re-)registration procedure as described in this clause.

NOTE 1: No other procedure for configuring the UE to know whether a DNN is a LADN DNN is defined in this
release of the specifications.

NOTE 2: The procedure for configuring the UE to know an association between application and LADN DNN is not
defined in this release of the specifications.

LADN service area and LADN DNN are configured in the AMF on a per DN basis, i.e. for different UEs accessing the
same LADN, the configured LADN service area is the same regardless of other factors (e.g. UE's Registration Area or
UE subscription).

NOTE 3: If a LADN is not available in any TA of an AMF's service area, the AMF is not required to be configured
with any LADN related information for that DNN.

LADN Information (i.e. LADN Service Area Information and LADN DNN) is provided by AMF to the UE during the
Registration procedure or UE Configuration Update procedure. For each LADN DNN configured in the AMF, the
corresponding LADN Service Area Information includes a set of Tracking Areas that belong to the Registration Area
that the AMF assigns to the UE (i.e. the intersection of the LADN service area and the assigned Registration Area). The
AMF shall not create Registration Area based on the availability of LADNs.

NOTE 4: It is thus possible that the LADN Service Area Information sent by the AMF to the UE contains only a
sub-set of the full LADN service area as the LADN service area can contain TA(s) outside of the
registration area of the UE or outside of the area served by the AMF.

When the UE performs a successful (re-)registration procedure, the AMF may provide to the UE, based on local
configuration (e.g. via OAM) about LADN, on UE location, and on UE subscription information received from the
UDM about subscribed DNN(s), the LADN Information for the list of LADN available to the UE in that Registration
Area in the Registration Accept message.

The UE may provide either the LADN DNN(s) to retrieve the LADN Information for the indicated LADN DNN(s) or
an indication of Requesting LADN Information to retrieve the LADN Information for all LADN(s) available in the
current Registration Area.

The list of LADN is determined as follows:

- If neither LADN DNN nor an indication of requesting LADN Information is provided in the Registration
Request message, the list of LADN is the LADN DNN(s) in subscribed DNN list except for wildcard DNN.

- If the UE provides LADN DNN(s) in the Registration Request message, the list of LADN is LADN DNN(s) the
UE requested if the UE subscribed DNN(s) includes the requested LADN DNN or if a wildcard DNN is included
in the UE's subscription data.

NOTE 5: It is assumed that an application can use only one LADN DNN at a time.

- If the UE provides an indication of requesting LADN Information in the Registration Request message, the list
of LADN is all the LADN DNN(s) configured in the AMF if the wildcard DNN is subscribed, or the LADN
DNN(s) which is in subscribed DNN list and no wildcard DNN is subscribed.

The UE considers the retrieved LADN Information valid only for the registered PLMN and the E-PLMN(s) if the
LADN Service Area Information includes Tracking Areas that belong to E-PLMN(s). Additionally, an LADN DNN

3GPP
Release 16 113 3GPP TS 23.501 V16.4.0 (2020-03)

discovered by the UE via the retrieved LADN Information is considered an LADN DNN also in the E-PLMNs of the
Registered PLMN, i.e. the UE can request LADN Information for the discovered LADN DNN in the E-PLMNs.

During the subsequent Registration procedure, if the network does not provide LADN Information for a DNN, the UE
deletes any LADN Information for that DNN.

When the LADN Information for the UE in the 5GC is changed, the AMF shall update LADN Information to the UE
through UE Configuration Update/Registration procedure as described in clause 4.2.4/4.2.2.2.2 in TS 23.502 [3].

When receiving PDU Session Establishment with LADN DNN or Service Request for the established PDU Session
corresponding to LADN, the AMF determines UE presence in LADN service area and forwards it to the SMF if the
requested DNN is configured at the AMF as a LADN DNN.

Based on the LADN Service Area Information in the UE, the UE determines whether it is in or out of a LADN service
area. If the UE does not have the LADN Service Area Information for a LADN DNN, the UE shall consider it is out of
the LADN service area.

The UE takes actions as follows:

a) When the UE is out of a LADN service area, the UE:

- shall not request to activate UP connection of a PDU Session for this LADN DNN;

- shall not establish/modify a PDU Session for this LADN DNN (except for PS Data Off status change
reporting for an established PDU Session);

- need not release any existing PDU Session for this LADN DNN unless UE receives explicit SM PDU
Session Release Request message from the network.

b) When the UE is in a LADN service area, the UE:

- may request a PDU Session Establishment/Modification for this LADN DNN;

- may request to activate UP connection of the existing PDU Session for this LADN DNN.

The SMF supporting a DNN is configured with information about whether this DNN is a LADN DNN or not.

When receiving SM request corresponding an LADN from the AMF, the SMF determines whether the UE is inside
LADN service area based on the indication (i.e. UE Presence in LADN service area) received from the AMF. If the
SMF does not receive the indication, the SMF considers that the UE is outside of the LADN service area. The SMF
shall reject the request if the UE is outside of the LADN service area.

When the SMF receives a request for PDU Session Establishment with the LADN DNN, it shall subscribe to "UE
mobility event notification" for reporting UE presence in Area of Interest by providing LADN DNN to the AMF as
described in clauses 5.6.11 and 5.3.4.4.

Based on the notification about the UE presence in LADN service area notified by AMF (i.e. IN, OUT, or
UNKNOWN), the SMF takes actions as follows based on operator's policy:

a) When SMF is informed that the UE presence in a LADN service area is OUT, the SMF shall:

- release the PDU Session immediately; or

- deactivate the user plane connection for the PDU Session with maintaining the PDU Session and ensure the
Data Notification is disabled and the SMF may release the PDU Session if the SMF is not informed that the
UE moves into the LADN service area after a period.

b) When SMF is informed that the UE presence a LADN service area is IN, the SMF shall:

- ensure that Data Notification is enabled.

- trigger the Network triggered Service Request procedure for a LADN PDU Session to active the UP
connection when the SMF receives downlink data or Data Notification from UPF.

c) When the SMF is informed that the UE presence in a LADN service area is UNKNOWN, the SMF may:

- ensure that Data Notification is enabled.

3GPP
Release 16 114 3GPP TS 23.501 V16.4.0 (2020-03)

- trigger the Network triggered Service Request procedure for a LADN PDU Session to active the UP
connection when the SMF receives downlink data or Data Notification from UPF.

5.6.6 Secondary authentication/authorization by a DN-AAA server during

the establishment of a PDU Session
At PDU Session Establishment to a DN:

- The DN-specific identity (TS 33.501 [29]) of a UE may be authenticated/authorized by the DN.

NOTE 1: the DN-AAA server may belong to the 5GC or to the DN.

- If the UE provides authentication/authorization information corresponding to a DN-specific identity during the

Establishment of the PDU Session, and the SMF determines that Secondary authentication/authorization of the
PDU Session Establishment is required based on the SMF policy associated with the DN, the SMF passes the
authentication/authorization information of the UE to the DN-AAA server via the UPF if the DN-AAA server is
located in the DN. If the SMF determines that Secondary authentication/authorization of the PDU Session
Establishment is required but the UE has not provided a DN-specific identity as part of the PDU Session
Establishment request, the SMF requests the UE to indicate a DN-specific identity using EAP procedures as
described in TS 33.501 [29]. If the Secondary authentication/authorization of the PDU Session Establishment
fails, the SMF rejects the PDU Session Establishment.

NOTE 2: If the DN-AAA server is located in the 5GC and reachable directly, then the SMF may communicate with
it directly without involving the UPF.

- The DN-AAA server may authenticate/authorize the PDU Session Establishment.

- When DN-AAA server authorizes the PDU Session Establishment, it may send DN Authorization Data for the
established PDU Session to the SMF. The DN authorization data for the established PDU Session may include
one or more of the following:

- A DN Authorization Profile Index which is a reference to authorization data for policy and charging control
locally configured in the SMF or PCF.

- a list of allowed MAC addresses for the PDU Session; this shall apply only for PDU Session of Ethernet
PDU type and is further described in clause 5.6.10.2.

- a list of allowed VIDs for the PDU Session; this shall apply only for PDU Session of Ethernet PDU type and
is further described in clause 5.6.10.2.

- DN authorized Session AMBR for the PDU Session. The DN Authorized Session AMBR for the PDU
Session takes precedence over the subscribed Session-AMBR received from the UDM.

- a list of Framed Routes (see clause 5.6.14) for the PDU Session.

SMF policies may require DN authorization without Secondary authentication/authorization. In that case, when
contacting the DN-AAA server for authorization, the SMF provides the GPSI of the UE if available.

Such Secondary authentication/authorization takes place for the purpose of PDU Session authorization in addition to:

- The 5GC access authentication handled by AMF and described in clause 5.2.

- The PDU Session authorization enforced by SMF with regard to subscription data retrieved from UDM.

Based on local policies the SMF may initiate Secondary authentication/authorization at PDU Session Establishment.
The SMF provides the GPSI, if available, in the signalling exchanged with the DN-AAA during Secondary
authentication/authorization.

After the successful Secondary authentication/authorization, a session is kept between the SMF and the DN-AAA.

The UE provides the authentication/authorization information required to support Secondary

authentication/authorization by the DN over NAS SM.

NOTE 3: The way for the UE to acquire such information is not defined.

3GPP
Release 16 115 3GPP TS 23.501 V16.4.0 (2020-03)

When SMF adds a PDU Session Anchor (such as defined in clause 5.6.4) to a PDU Session Secondary
authentication/authorization is not carried out, but SMF policies may require SMF to notify the DN when a new prefix
or address has been added to or removed from a PDU Session or N6 traffic routing information has been changed for a
PDU Session.

When SMF gets notified from UPF with the addition or removal of MAC addresses to/from a PDU Session, the SMF
policies may require SMF to notify the DN-AAA server.

Indication of PDU Session Establishment rejection is transferred by SMF to the UE via NAS SM.

If the DN-AAA sends DN Authorization Data for the authorized PDU Session to the SMF and dynamic PCC is
deployed, the SMF sends the PCF the DN authorized Session AMBR and/or DN Authorization Profile Index in the DN
Authorization Data for the established PDU Session.

If the DN-AAA sends DN Authorization Profile Index in DN Authorization Data to the SMF and dynamic PCC is not
deployed, the SMF uses the DN Authorization Profile Index to refer the locally configured information.

NOTE 4: DN Authorization Profile Index is assumed to be pre-negotiated between the operator and the
administrator of DN-AAA server.

If the DN-AAA does not send DN Authorization Data for the established PDU Session, the SMF may use locally
configured information.

At any time, a DN-AAA server may revoke the authorization for a PDU Session or update DN Authorization Data for a
PDU Session. According to the request from DN-AAA server, the SMF may release or update the PDU Session.

At any time, a DN-AAA server or SMF may trigger Secondary Re-authentication procedure for a PDU Session
established with Secondary Authentication as specified in clause 11.1.3 in TS 33.501 [29].

During Secondary Re-authentication/Re-authorization, if the SMF receives from DN-AAA the DN authorized Session
AMBR and/or DN Authorization Profile Index, the SMF shall report the received value(s) to the PCF.

The procedure for secondary authentication/authorization by a DN-AAA server during the establishment of a PDU
Session is described in TS 23.502 [3] clause 4.3.2.3.

5.6.7 Application Function influence on traffic routing

5.6.7.1 General
The content of this clause applies to non-roaming and to LBO deployments i.e. to cases where the involved entities (AF,
PCF, SMF, UPF) belong to the Serving PLMN or AF belongs to a third party with which the Serving PLMN has an
agreement. AF influence on traffic routing does not apply in the case of Home Routed deployments. PCF shall not
apply AF requests to influence traffic routing to PDU Sessions established in Home Routed mode.

An AF may send requests to influence SMF routeing decisions for traffic of PDU Session. The AF requests may
influence UPF (re)selection and allow routeing user traffic to a local access to a Data Network (identified by a DNAI)

The AF may issue requests on behalf of applications not owned by the PLMN serving the UE.

If the operator does not allow an AF to access the network directly, the AF shall use the NEF to interact with the 5GC,
as described in clause 6.2.10.

The AF may be in charge of the (re)selection or relocation of the applications within the local DN. Such functionality is
not defined. For this purpose, the AF may request to get notified about events related with PDU Sessions.

The AF requests are sent to the PCF via N5 (in the case of requests targeting specific on-going PDU Sessions of
individual UE(s), for an AF allowed to interact directly with the 5GC NFs) or via the NEF. The AF requests that target
existing or future PDU Sessions of multiple UE(s) or of any UE are sent via the NEF and may target multiple PCF(s), as
described in clause 6.3.7.2. The PCF(s) transform(s) the AF requests into policies that apply to PDU Sessions. When the
AF has subscribed to UP path management event notifications from SMF(s) (including notifications on how to reach a
GPSI over N6), such notifications are sent either directly to the AF or via an NEF (without involving the PCF). For AF
interacting with PCF directly or via NEF, the AF requests may contain the information as described in the Table 5.6.7-
1:

3GPP
Release 16 116 3GPP TS 23.501 V16.4.0 (2020-03)

Table 5.6.7-1: Information element contained in AF request

Information Name Applicable for PCF or NEF Applicable for NEF only Category
(NOTE 1)
Traffic Description Defines the target traffic to be The target traffic can be Mandatory
influenced, represented by the represented by AF-Service-
combination of DNN and Identifier, instead of combination
optionally S-NSSAI, and of DNN and optionally S-NSSAI.
application identifier or traffic
filtering information.
Potential Locations of Indicates potential locations of The potential locations of Conditional
Applications applications, represented by a applications can be represented (NOTE 2)
list of DNAI(s). by AF-Service-Identifier.
Target UE Identifier(s) Indicates the UE(s) that the GPSI can be applied to identify Mandatory
request is targeting, i.e. an the individual UE, or External
individual UE, a group of UE Group Identifier can be applied to
represented by Internal Group identify a group of UE.
Identifier (NOTE 3), or any UE
accessing the combination of
DNN, S-NSSAI and DNAI(s).
Spatial Validity Condition Indicates that the request The specified location can be Optional
applies only to the traffic of represented by a list of
UE(s) located in the specified geographic zone identifier(s).
location, represented by areas
of validity.
AF transaction identifier The AF transaction identifier N/A Mandatory
refers to the AF request.
Traffic Routing Routing profile ID and/or N6 N/A Optional
requirements traffic routing information
corresponding to each DNAI
and an optional indication of
traffic correlation.
Application Relocation Indicates whether an N/A Optional
Possibility application can be relocated
once a location of the
application is selected by the
5GC.
UE IP address Indicates UE IP address should N/A Optional
preservation indication be preserved.
Temporal Validity Time interval(s) or duration(s). N/A Optional
Condition
Information on AF Indicates whether the AF N/A Optional
subscription to subscribes to change of UP
corresponding SMF path of the PDU Session and
events the parameters of this
subscription.
NOTE 1: When the AF request targets existing or future PDU Sessions of multiple UE(s) or of any UE and is sent via
the NEF, as described in clause 6.3.7.2, the information is stored in the UDR by the NEF and notified to the
PCF by the UDR.
NOTE 2: The potential locations of applications and traffic routing requirements may be absent only if the request is
for subscription to notifications about UP path management events only.
NOTE 3: Internal Group ID can only be used by an AF controlled by the operator.

For each information element mentioned above in the AF request, the detailed description is as follows:

1) Information to identify the traffic. The traffic can be identified in the AF request by

- Either a DNN and possibly slicing information (S-NSSAI) or an AF-Service-Identifier

- When the AF provides an AF-Service-Identifier i.e. an identifier of the service on behalf of which the AF
is issuing the request, the 5G Core maps this identifier into a target DNN and slicing information (S-
NSSAI)

- When the NEF processes the AF request the AF-Service-Identifier may be used to authorize the AF
request.

3GPP
Release 16 117 3GPP TS 23.501 V16.4.0 (2020-03)

- an application identifier or traffic filtering information (e.g. 5 Tuple). The application identifier refers to an
application handling UP traffic and is used by the UPF to detect the traffic of the application

When the AF request is for influencing SMF routing decisions, the information is to identify the traffic to be
routed.

When the AF request is for subscription to notifications about UP path management events, the information
is to identify the traffic that the events relate to.

2) Information about the N6 traffic routing requirements for traffic identified as defined in 1). This includes:

- Information about the N6 traffic routing requirements that is provided per DNAI: for each DNAI, the N6
traffic routing requirements may contain a routing profile ID and/or N6 traffic routing information.

- an optional indication of traffic correlation, when the information in 4) identifies a group of UEs. This
implies the targeted PDU Sessions should be correlated by a common DNAI in the user plane for the traffic
identified in 1). If this indication is provided by the AF, the 5GC should select a common DNAI for the target
PDU Sessions from the list of DNAI(s) specified in 3).

NOTE 1: The N6 traffic routing requirements are related to the mechanism enabling traffic steering in the local
access to the DN. The routing profile ID refers to a pre-agreed policy between the AF and the 5GC. This
policy may refer to different steering policy ID(s) sent to SMF and e.g. based on time of the day etc.

NOTE 2: The mechanisms enabling traffic steering in the local access to the DN are not defined.

3) Potential locations of applications towards which the traffic routing should apply. The potential location of
application is expressed as a list of DNAI(s). If the AF interacts with the PCF via the NEF, the NEF may map
the AF-Service-Identifier information to a list of DNAI(s). The DNAI(s) may be used for UPF (re)selection.

4) Information on the UE(s). This may correspond to:

- Individual UEs identified using GPSI, or an IP address/Prefix or a MAC address.

- groups of UEs identified by an External Group Identifier as defined in TS 23.682 [36] when the AF interacts
via the NEF, or Internal-Group Identifier (see clause 5.9.7) when the AF interacts directly with the PCF.

- any UE accessing the combination of DNN, S-NSSAI and DNAI(s).

When the PDU Session type is IPv4 or IPv6 or IPv4v6, and the AF provides an IP address and/or an IP
Prefix, or when the PDU Session type is Ethernet and the AF provides a MAC address, this allows the PCF to
identify the PDU Session for which this request applies and the AF request applies only to that specific PDU
Session of the UE. In this case, additional information such as the UE identity may also be provided to help
the PCF to identify the correct PDU Session.

Otherwise the request targets multiple UE(s) and shall apply to any existing or future PDU Sessions that
match the parameters in the AF request.

When the AF request targets an individual UE and GPSI is provided within the AF request, the GPSI is
mapped to SUPI according to the subscription information received from UDM.

When the AF request targets any UE or a group of UE, the AF request is likely to influence multiple PDU
Sessions possibly served by multiple SMFs and PCFs.

When the AF request targets a group of UE it provides one or several group identifiers in its request. The
group identifiers provided by the AF are mapped to Internal-Group identifiers. Members of the group have
this Group Identifier in their subscription. The Internal-Group Identifier is stored in UDM, retrieved by SMF
from UDM and passed by SMF to PCF at PDU Session set-up. The PCF can then map the AF requests with
user subscription and determine whether an AF request targeting a Group of users applies to a PDU Session.

When the AF request is for influencing SMF routing decisions, the information is to identify UE(s) whose
traffic is to be routed.

When the AF request is for subscription to notifications about UP path management events, the information
is to identify UE(s) whose traffic the events relate to.

3GPP
Release 16 118 3GPP TS 23.501 V16.4.0 (2020-03)

When the AF request is for traffic forwarding in a PDU Session serving for TSC, the MAC address used by
the PDU Session is determined by the AF to identify UE whose traffic is to be routed according to the
previously stored binding relationship of the 5GS Bridge and the port number of the traffic forwarding
information received from TSN network.

5) Indication of application relocation possibility. This indicates whether an application can be relocated once a
location of the application is selected by the 5GC. If application relocation is not possible, the 5GC shall ensure
that for the traffic related with an application, no DNAI change takes place once selected for this application.

6) Temporal validity condition. This is provided in the form of time interval(s) or duration(s) during which the AF
request is to be applied.

When the AF request is for influencing SMF routing decisions, the temporal validity condition indicates when
the traffic routing is to apply.

When the AF request is for subscription to notifications about UP path management events, the temporal validity
condition indicates when the notifications are to be generated.

7) Spatial validity condition on the UE(s) location. This is provided in the form of validity area(s). If the AF
interacts with the PCF via the NEF, it may provide a list of geographic zone identifier(s) and the NEF maps the
information to areas of validity based on pre-configuration. The PCF in turn determines area(s) of interest based
on validity area(s).

When the AF request is for influencing SMF routing decisions, the spatial validity condition indicates that the
request applies only to the traffic of UE(s) located in the specified location.

When the AF request is for subscription to notifications about UP path management events, the spatial validity
condition indicates that the subscription applies only to the traffic of UE(s) located in the specified location.

8) Information on AF subscription to corresponding SMF events.

The AF may request to be subscribed to change of UP path associated with traffic identified in the bullet 1)
above. The AF request contains:

- A type of subscription (subscription for Early and/or Late notifications).

The AF subscription can be for Early notifications and/or Late notifications. In the case of a subscription for
Early notifications, the SMF sends the notifications before the (new) UP path is configured. In the case of a
subscription for Late notifications, the SMF sends the notification after the (new) UP path has been
configured.

- Optionally, an indication of "AF acknowledgment to be expected".

The indication implies that the AF will provide a response to the notifications of UP path management events
to the 5GC. The SMF may, according to this indication, determine to wait for a response from the AF before
the SMF configures in the case of early notification, or activates in the case of late notification, the new UP
path as described in clause 5.6.7.2.

The AF subscription can also request to receive information associating the GPSI of the UE with the IP
address(es) of the UE and/or with actual N6 traffic routing to be used to reach the UE on the PDU Session; in
this case the corresponding information is sent by the SMF regardless of whether a DNAI applies to the PDU
Session.

9) An AF transaction identifier referring to the AF request. This allows the AF to update or remove the AF request
and to identify corresponding UP path management event notifications. The AF transaction identifier is
generated by the AF.

When the AF interacts with the PCF via the NEF, the NEF maps the AF transaction identifier to an AF
transaction internal identifier, which is generated by the NEF and used within the 5GC to identify the
information associated to the AF request. The NEF maintains the mapping between the AF transaction identifier
and the AF transaction internal identifier. The relation between the two identifiers is implementation specific.

When the AF interacts with the PCF directly, the AF transaction identifier provided by the AF is used as AF
transaction internal identifier within the 5GC.

3GPP
Release 16 119 3GPP TS 23.501 V16.4.0 (2020-03)

10) Indication of UE IP address preservation. This indicates UE IP address related to the traffic identified in bullet 1)
should be preserved. If this indication is provided by the AF, the 5GC should preserve the UE IP address by
preventing reselection of PSA UPF for the identified traffic once the PSA UPF is selected.

An AF may send requests to influence SMF routeing decisions, for event subscription or for both.

The AF may request to be subscribed to notifications about UP path management events, i.e. a UP path change occurs
for the PDU Session. The corresponding notification about a UP path change sent by the SMF to the AF may indicate
the DNAI and /or the N6 traffic routing information that has changed as described in clause 4.3.6.3 of TS 23.502 [3]. It
may include the AF transaction internal identifier, the type of notification (i.e. early notification or late notification), the
Identity of the source and/or target DNAI, the IP address/prefix of the UE or the MAC address used by the UE, the
GPSI and the N6 traffic routing information related to the 5GC UP.

NOTE 3: The change from the UP path status where no DNAI applies to a status where a DNAI applies indicates
the activation of this AF request; the change from the UP path status where a DNAI applies to a status
where no DNAI applies indicates the de-activation of this AF request.

In the case of IP PDU Session Type, the IP address/prefix of the UE together with N6 traffic routing information
indicates to the AF how to reach over the User Plane the UE identified by its GPSI. N6 traffic routing
information indicates any tunnelling that may be used over N6. The nature of this information depends on the
deployment.

NOTE 4: N6 traffic routing information can e.g. correspond to the identifier of a VPN or to explicit tunnelling
information such as a tunnelling protocol identifier together with a Tunnel identifier.

NOTE 5: In the case of Unstructured PDU Session type the nature of the N6 traffic routing information related to
the 5GC UP is described in clause 5.6.10.3.

In the case of Ethernet PDU Session Type, the MAC address of the UE together with N6 traffic routing
information indicates to the AF how to reach over the User Plane the UE identified by its GPSI. The UE MAC
address (es) is reported by the UPF as described in clause 5.8.2.12. The N6 traffic routing information can be,
e.g. a VLAN ID or the identifier of a VPN or a tunnel identifier at the UPF.

In the case of PDU Session serving for TSC, the SMF informs AF of the 5GS Bridge user plane information as
defined in clause 5.28.1, as well as the association between the MAC address used by the PDU Session, 5GS
Bridge ID and port ID on DS-TT.

When notifications about UP path management events are sent to the AF via the NEF, if required, the NEF maps the UE
identify information, e.g. SUPI, to the GPSI and the AF transaction internal identifier to the AF transaction identifier
before sending the notifications to the AF.

The PCF authorizes the request received from the AF based on information received from the AF, operator's policy, etc.
and determines for each DNAI, a traffic steering policy ID (derived from the routing profile ID provided by the AF)
and/or the N6 traffic routing information (as provided by the AF) to be sent to the SMF as part of the PCC rules. The
traffic steering policy IDs are configured in the SMF or in the UPF. The traffic steering policy IDs are related to the
mechanism enabling traffic steering to the DN.

The DNAIs are related to the information considered by the SMF for UPF selection, e.g. for diverting (locally) some
traffic matching traffic filters provided by the PCF.

The PCF acknowledges a request targeting an individual PDU Session to the AF or to the NEF.

For PDU Session that corresponds to the AF request, the PCF provides the SMF with a PCC rule that is generated based
on the AF request, Local routing indication from the PDU Session policy control subscription information and taking
into account UE location presence in area of interest (i.e. Presence Reporting Area). The PCC rule contains the
information to identify the traffic, information about the DNAI(s) towards which the traffic routing should apply and
optionally, an indication of traffic correlation and/or an indication of application relocation possibility and/or indication
of UE IP address preservation. The PCC rule also contains per DNAI a traffic steering policy ID and/or N6 traffic
routing information, if the N6 traffic routing information is explicitly provided in the AF request. The PCF may also
provide in the PCC rule information to subscribe the AF (or the NEF) to SMF events (UP path changes) corresponding
to the AF request in which case it provides the information on AF subscription to corresponding SMF events received in
the AF request. This is done by providing policies at PDU Session set-up or by initiating a PDU Session Modification
procedure. When initiating a PDU Session set-up or PDU Session Modification procedure, the PCF considers the latest
known UE location to determine the PCC rules provided to the SMF. The PCF evaluates the temporal validity condition

3GPP
Release 16 120 3GPP TS 23.501 V16.4.0 (2020-03)

of the AF request and informs the SMF to activate or deactivate the corresponding PCC rules according to the
evaluation result. When policies specific to the PDU Session and policies general to multiple PDU Sessions exist, the
PCF gives precedence to the PDU Session specific policies over the general policies.

The spatial validity condition is resolved at the PCF. In order to do that, the PCF subscribes to the SMF to receive
notifications about change of UE location in an area of interest (i.e. Presence Reporting Area). The subscribed area of
interest may be the same as spatial validity condition, or may be a subset of the spatial validity condition (e.g. a list of
TAs) based on the latest known UE location. When the SMF detects that UE entered the area of interest subscribed by
the PCF, the SMF notifies the PCF and the PCF provides to the SMF the PCC rules described above by triggering a
PDU Session Modification. When the SMF becomes aware that the UE left the area subscribed by the PCF, the SMF
notifies the PCF and the PCF provides updated PCC rules by triggering a PDU Session Modification. SMF notifications
to the PCF about UE location in or out of the subscribed area of interest are triggered by UE location change
notifications received from the AMF or by UE location information received during a Service Request or Handover
procedure.

When the PCC rules are activated, the SMF may, based on local policies, take the information in the PCC rules into
account to:

- (re)select UP paths (including DNAI(s)) for PDU Sessions. The SMF is responsible for handling the mapping
between the UE location (TAI / Cell-Id) and DNAI(s) associated with UPF and applications and the selection of
the UPF(s) that serve a PDU Session. This is described in clause 6.3.3. If the PDU Session is of IP type and if
Indication of UE IP address preservation is included in the PCC rules, the SMF should preserve the UE IP
address, by not reselecting the related PSA UPF once the PSA UPF is selected, for the traffic identified in the
PCC rule. If the PCC rules are related to a 5G VN group served by the SMF and if the Information about the N6
traffic routing requirements includes an indication of traffic correlation, the SMF should select a common DNAI
for the PDU Sessions of the 5G VN group.

- configure traffic steering at UPF, including activating mechanisms for traffic multi-homing or enforcement of an
UL Classifier (UL CL). Such mechanisms are defined in clause 5.6.4. This may include that the SMF is
providing the UPF with packet handling instructions (i.e. PDRs and FARs) for steering traffic to the local access
to the DN. The packet handling instructions are generated by the SMF using the traffic steering policy ID and/or
the N6 traffic routing information in the PCC rules corresponding to the applied DNAI. In the case of UP path
reselection, the SMF may configure the source UPF to forward traffic to the UL CL/BP so that the traffic is
steered towards the target UPF.

- if Information on AF subscription to corresponding SMF events has been provided in the PCC rule, inform the
AF of the (re)selection of the UP path (UP path change). If the information includes an indication of "AF
acknowledgment to be expected", the SMF may decide to wait for a response from the AF before it activates the
new UP path, as described in clause 5.6.7.2.

When an I-SMF is inserted for a PDU Session, the I-SMF insertion, relocation or removal to a PDU session shall be
transparent (i.e. not aware) to the PCF and to the AF. The processing of the AF influence on traffic routing is described
in clause 5.34 and detail procedure is described in clause 4.23.6 of TS 23.502 [3].

5.6.7.2 Enhancement of UP path management based on the coordination with AFs

In order to avoid or minimize service interruption during PSA relocation for a PDU session of SSC mode 3, or a PDU
session with UL CL or branch point, according to the indication of "AF acknowledgment to be expected" on AF
subscription to corresponding SMF events (DNAI change) in the PCC rules received from the PCF and local
configuration (e.g. DN-related policies) the SMF may wait for a response from the AF after sending a notification (an
early notification or a late notification) to the AF. In the case of late notification, based on the indication of "AF
acknowledgment to be expected" on AF subscription, the SMF may send the notification before activating the UP path
towards a new DNAI (possibly through a new PSA).

NOTE 1: Before the UP path toward the new DNAI is activated, application traffic data (if any exists) is still routed
toward the old DNAI.

The notification sent from the SMF to the AF indicates UP path management events (DNAI change) as described in
clause 5.6.7.1. The AF can confirm the DNAI change indicated in the notification with the SMF by sending a positive
response to the notification to the SMF or reject the DNAI change by sending a negative response.

3GPP
Release 16 121 3GPP TS 23.501 V16.4.0 (2020-03)

NOTE 2: The AF can determine whether application relocation is needed according to the notification of DNAI
change. If not, the AF can send a positive response to the SMF immediately; otherwise, the AF sends the
positive response after application relocation is completed or a negative response if the AF determines
that the application relocation cannot be completed on time (e.g. due to temporary congestion). The AF
decision and behaviours on application relocation are not defined. However, the new DNAI may be
associated with a new AF. In such cases, the SMF and the old AF cancel earlier subscribed UP path
management event notifications, and the new AF subscribes to receive UP path management event
notifications from the SMF.

The AF can include N6 traffic routing information related to the target DNAI in a positive response sent to the SMF.
The SMF configures the N6 traffic routing information from the AF response to the PSA on the UP path.

In the case of early notification, based on the indication of "AF acknowledgment to be expected" on AF subscription,
the SMF does not configure the UP path towards the new DNAI until it receives a positive AF response as specified in
clause 4.3.6.3 of TS 23.502 [3].

In the case of late notification, based on the indication of "AF acknowledgment to be expected" on AF subscription, the
SMF does not activate the UP path towards the new DNAI until it receives a positive AF response as specified in
clause 4.3.5 of TS 23.502 [3].

NOTE 3: After the UP path toward the new DNAI is activated, data is routed toward the new DNAI.

If the SMF receives a negative response at any time, the SMF keeps using the original DNAI and may cancel related
PSA relocation or addition. The SMF may perform DNAI reselection afterwards if needed.

The SMF can assume according to local policy a negative response if a response is expected and but not received from
the AF within a certain time window.

5.6.8 Selective activation and deactivation of UP connection of existing

PDU Session
This clause applies to the case when a UE has established multiple PDU Sessions. The activation of a UP connection of
an existing PDU Session causes the activation of its UE-CN User Plane connection (i.e. data radio bearer and N3
tunnel).

For the UE in the CM-IDLE state in 3GPP access, either UE or Network-Triggered Service Request procedure may
support independent activation of UP connection of existing PDU Session. For the UE in the CM-IDLE state in non-
3GPP access, UE-Triggered Service Request procedure allows the re-activation of UP connection of existing PDU
Sessions, and may support independent activation of UP connection of existing PDU Session.

A UE in the CM-CONNECTED state invokes a Service Request (see TS 23.502 [3] clause 4.2.3.2) procedure to request
the independent activation of the UP connection of existing PDU Sessions.

Network Triggered re-activation of UP connection of existing PDU Sessions is handled as follows:

- If the UE CM state in the AMF is already CM-CONNECTED on the access (3GPP, non-3GPP) associated to the
PDU Session in the SMF, the network may re-activate the UP connection of a PDU Session using a Network
Initiated Service Request procedure.

Otherwise:

- If the UE is registered in both 3GPP and non-3GPP accesses and the UE CM state in the AMF is CM-IDLE in
non-3GPP access, the UE can be paged or notified through the 3GPP access for a PDU Session associated in the
SMF (i.e. last routed) to the non-3GPP access:

- If the UE CM state in the AMF is CM-IDLE in 3GPP access, the paging message may include the access
type associated with the PDU Session in the SMF. The UE, upon reception of the paging message containing
an access type, shall reply to the 5GC via the 3GPP access using the NAS Service Request message, which
shall contain the list of PDU Sessions associated with the received access type and whose UP connections
can be re-activated over 3GPP (i.e. the list does not contain the PDU Sessions whose UP connections cannot
be re-activated on 3GPP based on UE policies and whether the S-NSSAIs of these PDU Sessions are within
the Allowed NSSAI for 3GPP access). If the PDU Session for which the UE has been paged is in the list of
the PDU Sessions provided in the NAS Service Request and the paging was triggered by pending DL data,
the 5GC shall re-activate the PDU Session UP connection over 3GPP access. If the paging was triggered by

3GPP
Release 16 122 3GPP TS 23.501 V16.4.0 (2020-03)

pending DL signalling, the Service Request succeeds without re-activating the PDU session UP connection
over the 3GPP access and the pending DL signalling is delivered to the UE over the 3GPP access;

- If the UE CM state in the AMF is CM-CONNECTED in 3GPP access, the notification message shall include
the non-3GPP Access Type. The UE, upon reception of the notification message, shall reply to the 5GC via
the 3GPP access using the NAS Service Request message, which shall contain the List of Allowed PDU
Sessions that can be re-activated over 3GPP or an empty List of Allowed PDU Sessions if no PDU Sessions
are allowed to be re-activated over 3GPP access.

NOTE: A UE that is in a coverage of a non-3GPP access and has PDU Session(s) that are associated in the UE
(i.e. last routed) to non-3GPP access, is assumed to attempt to connect to it without the need to be paged.

- If the UE is registered in both 3GPP and non-3GPP accesses served by the same AMF and the UE CM state in
the AMF is CM-IDLE in 3GPP access and is in CM-CONNECTED in non 3GPP access, the UE can be notified
through the non-3GPP for a PDU Session associated in the SMF (i.e. last routed) to the 3GPP access. The
notification message shall include the 3GPP Access Type. Upon reception of the notification message, when
3GPP access is available, the UE shall reply to the 5GC via the 3GPP access using the NAS Service Request
message.

In addition to the above, a PDU Session may be established as an always-on PDU Session as described in clause 5.6.13.

The deactivation of the UP connection of an existing PDU Session causes the corresponding data radio bearer and N3
tunnel to be deactivated. The UP connection of different PDU Sessions can be deactivated independently when a UE is
in CM-CONNECTED state in 3GPP access or non-3GPP access. At the deactivation of the UP of a PDU Session using
a N9 tunnel whose end-point is controlled by an I-SMF, the N9 tunnel is preserved. If a PDU Session is an always-on
PDU Session, the SMF should not deactivate a UP connection of this PDU Session due to inactivity.

5.6.9 Session and Service Continuity

5.6.9.1 General
The support for session and service continuity in 5G System architecture enables to address the various continuity
requirements of different applications/services for the UE. The 5G System supports different session and service
continuity (SSC) modes defined in this clause. The SSC mode associated with a PDU Session does not change during
the lifetime of a PDU Session. The following three modes are specified with further details provided in the next clause:

- With SSC mode 1, the network preserves the connectivity service provided to the UE. For the case of PDU
Session of IPv4 or IPv6 or IPv4v6 type, the IP address is preserved.

- With SSC mode 2, the network may release the connectivity service delivered to the UE and release the
corresponding PDU Session(s). For the case of IPv4 or IPv6 or IPv4v6 type, the release of the PDU Session
induces the release of IP address(es) that had been allocated to the UE.

- With SSC mode 3, changes to the user plane can be visible to the UE, while the network ensures that the UE
suffers no loss of connectivity. A connection through new PDU Session Anchor point is established before the
previous connection is terminated in order to allow for better service continuity. For the case of IPv4 or IPv6 or
IPv4v6 type, the IP address is not preserved in this mode when the PDU Session Anchor changes.

NOTE: In this Release of the specification, the addition/removal procedure of additional PDU Session Anchor in
a PDU Session for local access to a DN is independent from the SSC mode of the PDU Session.

5.6.9.2 SSC mode

5.6.9.2.1 SSC Mode 1

For a PDU Session of SSC mode 1, the UPF acting as PDU Session Anchor at the establishment of the PDU Session is
maintained regardless of the access technology (e.g. Access Type and cells) a UE is successively using to access the
network.

In the case of a PDU Session of IPv4 or IPv6 or IPv4v6 type, IP continuity is supported regardless of UE mobility
events.

3GPP
Release 16 123 3GPP TS 23.501 V16.4.0 (2020-03)

In this Release of the specification, when IPv6 multihoming or UL CL applies to a PDU Session of in SSC mode 1, and
the network allocates (based on local policies) additional PDU Session Anchors to such a PDU Session, these additional
PDU Session Anchors may be released or allocated, and the UE does not expect that the additional IPv6 prefix is
maintained during the lifetime of PDU Session.

SSC mode 1 may apply to any PDU Session type and to any access type.

5.6.9.2.2 SSC Mode 2

If a PDU Session of SSC mode 2 has a single PDU Session Anchor, the network may trigger the release of the PDU
Session and instruct the UE to establish a new PDU Session to the same data network immediately. The trigger
condition depends on operator policy e.g. request from Application Function, based on load status, etc. At establishment
of the new PDU Session, a new UPF acting as PDU Session Anchor can be selected.

Otherwise, if a PDU Session of SSC mode 2 has multiple PDU Session Anchors (i.e. in the case of multi-homed PDU
Sessions or in the case that UL CL applies to a PDU Session of SSC mode 2), the additional PDU Session Anchors may
be released or allocated.

SSC mode 2 may apply to any PDU Session type and to any access type.

NOTE: In UL CL mode, the UE is not involved in PDU Session Anchor re-allocation, so that the existence of
multiple PDU Session Anchors is not visible to the UE.

5.6.9.2.3 SSC Mode 3

For PDU Session of SSC mode 3, the network allows the establishment of UE connectivity via a new PDU Session
Anchor to the same data network before connectivity between the UE and the previous PDU Session Anchor is
released. When trigger conditions apply, the network decides whether to select a PDU Session Anchor UPF suitable for
the UE's new conditions (e.g. point of attachment to the network).

In this Release of specification, SSC mode 3 only applies to IP PDU Session type and to any access type.

In the case of a PDU Session of IPv4 or IPv6 or IPv4v6 type, during the procedure of change of PDU Session Anchor,
the following applies:

a. For a PDU Session of IPv6 type, the new IP prefix anchored on the new PDU Session Anchor may be allocated
within the same PDU Session (relying on IPv6 multi-homing specified in clause 5.6.4.3), or

b. The new IP address and/or IP prefix may be allocated within a new PDU Session that the UE is triggered to
establish.

After the new IP address/prefix has been allocated, the old IP address/prefix is maintained during some time indicated
to the UE via NAS signalling (as described in TS 23.502 [3] clause 4.3.5.2) or via Router Advertisement (as described
in TS 23.502 [3] clause 4.3.5.3) and then released.

If a PDU Session of SSC mode 3 has multiple PDU Session Anchors (i.e., in the case of multi-homed PDU Sessions or
in the case that UL CL applies to a PDU Session of SSC mode 3), the additional PDU Session Anchors may be released
or allocated.

5.6.9.3 SSC mode selection

SSC mode selection is done by the SMF based on the allowed SSC modes -including the default SSC mode) in the user
subscription as well as the PDU Session type and if present, the SSC mode requested by the UE.

The operator may provision a SSC mode selection policy (SSCMSP) to the UE as part of the URSP rule -see
TS 23.503 [45] clause 6.6.2). The UE shall use the SSCMSP to determine the type of session and service continuity
mode associated with an application or group of applications for the UE as described in TS 23.503 [45] clause 6.6.2.3.
If the UE does not have SSCMSP, the UE can select a SSC mode based on UE Local Configuration as described in
TS 23.503 [45], if applicable. If the UE cannot select a SSC mode, the UE requests the PDU Session without providing
the SSC mode.

NOTE: The UE can use the SSC Mode Selection component of the URSP rule with match-all traffic descriptor if
there is no SSC mode in the UE local configuration.

3GPP
Release 16 124 3GPP TS 23.501 V16.4.0 (2020-03)

The SSC mode selection policy rules provided to the UE can be updated by the operator by updating the URSP rule.

The SMF receives from the UDM the list of allowed SSC modes and the default SSC mode per DNN per S-NSSAI as
part of the subscription information.

If a UE provides an SSC mode when requesting a new PDU Session, the SMF selects the SSC mode by either accepting
the requested SSC mode or rejecting the PDU Session Establishment Request message with the cause value and the
SSC mode(s) allowed to be used back to UE based on the PDU Session type, subscription and/or local configuration.
Based on that cause value and the SSC mode(s) allowed to be used, the UE may re-attempt to request the establishment
of that PDU Session with the SSC mode allowed to be used or using another URSP rule.

If a UE does not provide an SSC mode when requesting a new PDU Session, then the SMF selects the default SSC
mode for the data network listed in the subscription or applies local configuration to select the SSC mode.

SSC mode 1 shall be assigned to the PDU Session when static IP address/prefix is allocated to the PDU Session based
on the static IP address/prefix subscription for the DNN and S-NSSAI. The SMF shall inform the UE of the selected
SSC mode for a PDU Session.

The UE shall not request and the network shall not assign SSC mode 3 for the PDU Session of Unstructured type or
Ethernet type.

5.6.10 Specific aspects of different PDU Session types

5.6.10.1 Support of IP PDU Session type

The IP address allocation is defined in clause 5.8.1

The UE may acquire following configuration information from the SMF, during the lifetime of a PDU Session:

- Address(es) of P-CSCF(s).

- Address(es) of DNS server(s).

- the GPSI of the UE.

The UE may acquire from the SMF, at PDU Session Establishment, the MTU that the UE shall consider, see
clause 5.6.10.4.

The UE may provide following information to the SMF during the lifetime of a PDU Session:

- an indication of the support of P-CSCF re-selection based on procedures specified in TS 24.229 [62] (clauses
B.2.2.1C and L.2.2.1C).

- PS data off status of the UE.

NOTE: An operator can deploy NAT functionality in the network; the support of NAT is not specified in this
release of the specification.

5.6.10.2 Support of Ethernet PDU Session type

For a PDU Session set up with the Ethernet PDU Session type, the SMF and the UPF acting as PDU Session Anchor
(PSA) can support specific behaviours related with the fact the PDU Session carries Ethernet frames.

Depending on operator configuration related with the DNN, different configurations for how Ethernet traffic is handled
on N6 may apply, for example:

- Configurations with a 1-1 relationship between a PDU Session and a N6 interface possibly corresponding to a
dedicated tunnel established over N6. In this case the UPF acting as PSA transparently forwards Ethernet frames
between the PDU Session and its corresponding N6 interface, and it does not need to be aware of MAC
addresses used by the UE in order to route down-link traffic.

- Configurations, where more than one PDU Session to the same DNN (e.g. for more than one UE) corresponds to
the same N6 interface. In this case the UPF acting as PSA needs to be aware of MAC addresses used by the UE

3GPP
Release 16 125 3GPP TS 23.501 V16.4.0 (2020-03)

in the PDU Session in order to map down-link Ethernet frames received over N6 to the appropriate PDU
Session. Forwarding behaviour of the UPF acting as PSA is managed by SMF as specified in clause 5.8.2.5.

NOTE 1: The "MAC addresses used by the UE" correspond to any MAC address used by the UE or any device
locally connected to the UE and using the PDU Session to communicate with the DN.

Based on operator configuration, the SMF may request the UPF acting as the PDU Session Anchor to respond to
ARP/IPv6 Neighbour Solicitation requests based on local cache information, i.e. the mapping between the UE MAC
address to the UE IP address, and the DN where the PDU Session is connected to, or to redirect the ARP traffic from
the UPF to the SMF. Responding to ARP/IPv6 ND based on local cache information applies to ARP/IPv6 ND received
in both UL and DL directions.

NOTE 2: Responding to ARP/ND from a local cache assumes the UE or the devices behind the UE acquire their IP
address via in-band mechanisms that the SMF/UPF can detect and by this link the IP address to the MAC
address.

NOTE 3: This mechanism is intended to avoid broadcasting or multicasting the ARP/IPv6 ND to every UE.

Ethernet Preamble and Start of Frame delimiter are not sent over 5GS:

- For UL traffic the UE strips the preamble and frame check sequence (FCS) from the Ethernet frame.

- For DL traffic the PDU Session Anchor strips the preamble and frame check sequence (FCS) from the Ethernet
frame.

Neither a MAC nor an IP address is allocated by the 5GC to the UE for a PDU Session.

The PSA shall store the MAC addresses received from the UE, and associate those with the appropriate PDU Session.

The UPF handles VLAN tags (addition/removal) as instructed by the SMF via PDR (Outer header removal) and FAR
(UPF applying Outer header creation of a Forwarding policy). For example:

- The UPF may insert (for uplink traffic) and remove (for downlink traffic) a S-TAG on N6 interface on top of the
C-TAG of the UE.

- The UPF may insert (for uplink traffic) and remove (for downlink traffic) a VLAN tag on the N6 interface while
there is no VLAN in the traffic to and from the UE.

NOTE 4: This can be used for traffic steering to N6-LAN but also for N6-based traffic forwarding related with 5G-
VN service described in clause 5.29.4

Apart from specific conditions related to the support of PDU sessions over W-5GAN defined in TS 23.316 [84], the
UPF shall not remove VLAN tags sent by the UE and the UPF shall not insert VLAN tags for the traffic sent to the UE.

PDU(s) containing a VLAN tag shall be switched only within the same VLAN by a PDU Session Anchor.

The UE may acquire from the SMF, at PDU Session Establishment, the MTU of the Ethernet frames' payload that the
UE shall consider, see clause 5.6.10.4.

NOTE 5: The UE may operate in bridge mode with regard to a LAN it is connecting to the 5GS, thus different
MAC addresses may be used as source address of different frames sent UL over a single PDU Session
(and destination MAC address of different frames sent DL over the same PDU Session).

NOTE 6: Entities on the LAN connected to the 5GS by the UE may have an IP address allocated by the DN but the
IP layer is considered as an application layer which is not part of the Ethernet PDU Session.

NOTE 7: In this Release of the specification, only the UE connected to the 5GS is authenticated, not the devices
behind such UE.

NOTE 8: 5GS does not support the scenario where a MAC address or if VLAN applies a (MAC address, VLAN)
combination is used on more than one PDU Session for the same DNN and S-NSSAI.

NOTE 9: This Release of the specification does not guarantee that the Ethernet network remains loop-free.
Deployments need to be verified on an individual basis that loops in the Ethernet network are avoided.

3GPP
Release 16 126 3GPP TS 23.501 V16.4.0 (2020-03)

NOTE 10: This Release of the specification does not guarantee that the Ethernet network properly and quickly reacts
to topology changes. Deployments need to be verified on an individual basis how they react to topology
changes.

Different Frames exchanged on a PDU Session of Ethernet type may be served with different QoS over the 5GS. Thus,
the SMF may provide to the UPF Ethernet Packet Filter Set and forwarding rule(s) based on the Ethernet frame
structure and UE MAC address(es). The UPF detects and forwards Ethernet frames based on the Ethernet Packet Filter
Set and forwarding rule(s) received from the SMF. This is further defined in clauses 5.7 and 5.8.2.

When a PDU Session of Ethernet PDU type is authorized by a DN as described in clause 5.6.6, the DN-AAA server
may, as part of authorization data, provide the SMF with a list of allowed MAC addresses and/or a list of allowed VIDs
for this PDU Session; the list is limited to a maximum of 16 MAC addresses and/or a maximum of 16 VIDs
accordingly. When such list(s) have been provided for a PDU Session, the SMF sets corresponding filtering rules in the
UPF(s) acting as PDU Session Anchor for the PDU Session. The UPF discards any UL traffic that does not contain one
of these MAC addresses as a source address if the list of allowed MAC addresses is provided. The UPF discards any
UL traffic that does not contain one of these VIDs if the list of allowed VIDs is provided.

In this Release of specification, the PDU Session of Ethernet PDU Session type is restricted to SSC mode 1 and SSC
mode 2.

For a PDU Session established with the Ethernet PDU Session type, the SMF may, upon PCF request, need to ensure
reporting to the PCF of all Ethernet MAC addresses used as UE address in a PDU Session. In this case, as defined in
clause 5.8.2.12, the SMF controls the UPF to report the different MAC addresses used as source address of frames sent
UL by the UE in the PDU Session.

NOTE 11: This relates to whether AF control on a per MAC address is allowed on the PDU Session as defined in
TS 23.503 [45] clause 6.1.1.2.

The PCF may activate or deactivate the reporting of the UE MAC address using the "UE MAC address change" Policy
Control Request Trigger as defined in Table 6.1.3.5-1 of TS 23.503 [45].

The SMF may relocate the UPF acting as the PDU Session Anchor for an Ethernet PDU Session as defined in
clause 4.3.5.8 of TS 23.502 [3]. The relocation may be triggered by a mobility event such as a handover, or may be
triggered independent of UE mobility, e.g. due to load balancing reasons. In order to relocate the PSA UPF, the
reporting of the UE MAC addresses needs to be activated by the SMF.

5.6.10.3 Support of Unstructured PDU Session type

Different Point-to-Point (PtP) tunnelling techniques may be used to deliver Unstructured PDU Session type data to the
destination (e.g. application server) in the Data Network via N6.

Point-to-point tunnelling based on UDP/IP encapsulation as described below may be used. Other techniques may be
supported. Regardless of addressing scheme used from the UPF to the DN, the UPF shall be able to map the address
used between the UPF and the DN to the PDU Session.

When Point-to-Point tunnelling based on UDP/IPv6 is used, the following considerations apply:

- IPv6 prefix allocation for PDU Sessions are performed locally by the (H-)SMF without involving the UE.

- The UPF(s) acts as a transparent forwarding node for the payload between the UE and the destination in the DN.

- For uplink, the UPF forwards the received Unstructured PDU Session type data to the destination in the data
network over the N6 PtP tunnel using UDP/IPv6 encapsulation.

- For downlink, the destination in the data network sends the Unstructured PDU Session type data using
UDP/IPv6 encapsulation with the IPv6 address of the PDU Session and the 3GPP defined UDP port for
Unstructured PDU Session type data. The UPF acting as PDU Session Anchor decapsulates the received data
(i.e. removes the UDP/IPv6 headers) and forwards the data identified by the IPv6 prefix of the PDU Session for
delivery to the UE.

- The (H-)SMF performs the IPv6 related operations but the IPv6 prefix is not provided to the UE, i.e. Router
Advertisements and DHCPv6 are not performed. The SMF assigns an IPv6 Interface Identifier for the PDU
Session. The allocated IPv6 prefix identifies the PDU Session of the UE.

3GPP
Release 16 127 3GPP TS 23.501 V16.4.0 (2020-03)

- For AF influence on traffic routing (described in clause 5.6.7), when the N6 PtP tunnelling is used over the
DNAI and the AF provides, by value, information about N6 traffic routing requirements in the AF request, the
AF provides N6 PtP tunnelling requirements (IPv6 address and UDP port of the tunnel end in the DN) as the N6
traffic routing information associated to the DNAI; when the SMF notifies the AF of UP path management
events, it includes the N6 PtP tunnel information related to the UP (the IPv6 address and the 3GPP defined UDP
port of the tunnel end at the UPF) as N6 traffic routing information in the notification.

In this Release of the specification there is support for maximum one 5G QoS Flow per PDU Session of Type
Unstructured.

In this Release of specification, the PDU Session of Unstructured PDU Session type is restricted to SSC mode 1 and
SSC mode 2.

The UE may acquire from the SMF, at PDU Session Establishment, the MTU that the UE shall consider, see
clause 5.6.10.4.

5.6.10.4 Maximum Transfer Unit size considerations

In order to avoid data packet fragmentation between the UE and the UPF acting as PSA, the link MTU size in the UE
should be set to the value provided by the network as part of the IP configuration. The link MTU size for IPv4 is sent to
the UE by including it in the PCO (see TS 24.501 [47]). The link MTU size for IPv6 is sent to the UE by including it in
the IPv6 Router Advertisement message (see RFC 4861 [54]).

NOTE 1: Ideally the network configuration ensures that for PDU Session type IPv4v6 the link MTU values
provided to the UE via PCO and in the IPv6 Router Advertisement message are the same. In cases where
this condition cannot be met, the MTU size selected by the UE is unspecified.

When using a PDU Session type Unstructured, the maximum uplink packet size, and when using Ethernet, the Ethernet
frames' payload, that the UE should use may be provided by the network as a part of the session management
configuration by encoding it within the PCO (see TS 24.501 [47]).

When using a PDU Session type Unstructured, to provide a consistent environment for application developers, the
network shall use a maximum packet size of at least 128 octets (this applies to both uplink and downlink).

When the MT and the TE are separated, the TE may either be pre-configured to use a specific default MTU size or the
TE may use an MTU size provided by the network via the MT. Thus, it is not always possible to set the MTU value by
means of information provided by the network.

NOTE 2: In network deployments that have MTU size of 1500 octets in the transport network, providing a link
MTU value of 1358 octets (as shown in Figure J-1) to the UE as part of the IP configuration information
from the network will prevent the IP layer fragmentation within the transport network between the UE
and the UPF. For network deployments that uniformly support transport with larger MTU size than 1500
octets (for example with ethernet jumbo frames of MTU size up to 9216 octets), providing a link MTU
value of MTU minus 142 octets to the UE as part of the IP configuration information from the network
will prevent the IP layer fragmentation within the transport network between the UE and the UPF. Link
MTU considerations are discussed further in Annex J.

NOTE 3: As the link MTU value is provided as a part of the session management configuration information, a link
MTU value can be provided during each PDU Session establishment. In this release, dynamic adjustment
of link MTU for scenarios where MTU is not uniform across transport are not addressed.

5.6.11 UE presence in Area of Interest reporting usage by SMF

When a PDU Session is established or modified, or when the user plane path has been changed (e.g. UPF re-
allocation/addition/removal), SMF may determine an Area of Interest, e.g. based on UPF Service Area, subscription by
PCF for reporting UE presence in Presence Reporting Area, etc.

For 3GPP access, the Area of Interest constitutes:

- a list of Tracking Areas and/or;

- Presence Reporting Area ID(s) and optionally the elements for one or more of the Presence Reporting Areas, i.e.
TAs and/or NG-RAN nodes and/or cells identifiers and/or;

3GPP
Release 16 128 3GPP TS 23.501 V16.4.0 (2020-03)

- LADN DNN.

For Non-3GPP access, the Area of Interest constitutes:

- N3GPP TAI (see clause 5.3.2.3).

For UE location change into or out of an "area of interest", the SMF subscribes to "UE mobility event notification"
service provided by AMF for reporting of UE presence in Area of Interest as described in clause 5.3.4.4. The AMF may
send the UE location to the SMF along with the notification, e.g. for UPF selection. Upon reception of a notification
from AMF, the SMF determines how to deal with the PDU Session, e.g. reallocate UPF.

In the case of LADN, the SMF provides the LADN DNN to the AMF to subscribe to "UE mobility event notification"
for reporting UE presence in LADN service area. Upon reception of a notification from the AMF, the SMF determines
how to deal with the PDU Session as described in clause 5.6.5.

For use cases related to policy control and charging decisions, the PCF may subscribe to event reporting from the SMF
or the AMF, for UE presence in a Presence Reporting Area.

A Presence Reporting Area can be:

- A "UE-dedicated Presence Reporting Area", defined in the subscriber profile and composed of a short list of TAs
and/or NG-RAN nodes and/or cells identifiers in a PLMN; or derived from the Area of Interest provided by the
Application Function to the PCF (see clause 5.6.7) and composed of a short list of TAs and/or NG-RAN nodes
and/or cells identifiers in a PLMN; or

- A "Core Network predefined Presence Reporting Area", predefined in the AMF and composed of a short list of
TAs and/or NG-RAN nodes and/or cells identifiers in a PLMN.

In the case of Change of UE Presence in Presence Reporting Area, for core network predefined Presence Reporting
Area, the AMF determines the "area of interest" corresponding to the Presence Reporting Area Identifier(s), provided
by the PCF or the SMF, as a list of TAIs and/or cell identifiers and/or NG-RAN node identifiers based on local
configuration. For UE-dedicated Presence Reporting Areas, the subscription for UE location change notification for an
"area of interest" shall contain the PRA Identifier(s) and the list(s) of TAs, or NG-RAN Node identifier and/or cell
identifiers composing the Presence Reporting Area(s). For Core Network predefined Presence Reporting Areas, the
subscription for UE location change notification for an "area of interest" shall contain the PRA identifier(s).

NOTE 1: If the Presence Reporting Area (PRA) and RAN Notification Area (RNA) are partially overlapping, the
PCF will not get notified for the change of PRA when UE enters or leaves the PRA but remains in the
RNA in CM-CONNECTED with RRC Inactive state, because AMF is not informed.

Each Core Network predefined Presence Reporting Area can be configured with a priority level in the AMF. In order to
prevent overload, the AMF may set the reporting for one or more of the received Presence Reporting Area(s) to inactive
under consideration of the priority configured for each of Core Network predefined Presence Reporting Area(s), while
storing the reporting request for this Presence Reporting Area in the UE context.

NOTE 2: Change of UE presence in Presence Reporting Area reporting does not apply to home routed roaming.

The AMF may be configured with a PRA identifier which refers to a Set of Core Network predefined Presence
Reporting Areas. If the PCF subscribes to change of UE location for an area of interest for a Set of Presence reporting
areas and provides a PRA identifier then the SMF may subscribe for event reporting for this Set of Presence Reporting
Areas by only indicating this PRA Identifier in the area of interest. When the Presence Reporting Area(s) to be reported
belong to a set of Core Network predefined Presence Reporting Areas in which the AMF is requested to report on
change of UE presence, the AMF shall additionally add to the report the PRA Identifier of the Set of Core Network
predefined Presence Reporting Areas.

Upon change of AMF, the PRA identifier(s) and if provided, the list(s) of Presence Reporting Area elements are
transferred for all PDU sessions as part of MM Context information to the target AMF during the mobility procedure. If
one or more Presence Reporting Area(s) was set to inactive, the target AMF may decide to reactivate one or more of the
inactive Presence Reporting Area(s). The target AMF indicates per PDU session to the corresponding SMF/PCF the
PRA identifier(s) and whether the UE is inside or outside the Presence Reporting Area(s) as well as the inactive
Presence Reporting Area(s), if any.

NOTE 3: The target AMF cannot set the Presence Reporting Area(s) received from the source serving node to
inactive.

3GPP
Release 16 129 3GPP TS 23.501 V16.4.0 (2020-03)

The subscription may be maintained during the life of PDU Session, regardless of the UP activation state of PDU
Session (i.e. whether UP connection of the PDU Session is activated or not).

SMF may determine a new area of interest, and send a new subscription to the AMF with the new area of interest.

SMF un-subscribes to "UE mobility event notification" service when PDU Session is released.

5.6.12 Use of Network Instance

The SMF may provide a Network Instance to the UPF in FAR and/or PDR via N4 Session Establishment or N4
Modification procedures.

NOTE 1: a Network Instance can be defined e.g. to separate IP domains, e.g. when a UPF is connected to 5G-ANs
in different IP domains, overlapping UE IP addresses assigned by multiple Data Networks, transport
network isolation in the same PLMN, etc.

NOTE 2: As the SMF can provide over N2 the Network Instance it has selected for the N3 CN Tunnel Info, the 5G
AN does not need to provide Network Instance to the 5GC.

The SMF determines the Network Instance based on local configuration.

The SMF may determine the Network Instance for N3 and N9 interfaces, taking into account e.g. UE location,
registered PLMN ID of UE, S-NSSAI of the PDU Session.

The SMF may determine the Network Instance for N6 interface taking into account e.g. (DNN, S-NSSAI) of the PDU
Session.

The SMF may determine the Network Instance for N19 interface taking into account e.g. the (DNN, S-NSSAI)
identifying a 5G VN group.

NOTE 3: As an example, the UPF can use the Network Instance included in the FAR, together with other
information such as Outer header creation (IP address part) and Destination interface in the FAR, to
determine the interface in UPF (e.g. VPN or Layer 2 technology) for forwarding of the traffic.

5.6.13 Always-on PDU session

An always-on PDU Session is a PDU Session for which User Plane resources have to be activated during every
transition from CM-IDLE mode to CM-CONNECTED state.

Based on an indication from upper layers, a UE may request to establish a PDU Session as an always-on PDU Session.
The SMF decides whether the PDU Session can be established as an always-on PDU Session. In Home Routed roaming
case, based on local policies, the V-SMF shall be involved to determine whether the PDU Session can be established as
an always-on PDU Session.

If the UE requests the 5GC to modify a PDU Session, which was established in EPS, to an always-on PDU Session after
the first inter-system change from EPS to 5GS, the SMF decides whether the PDU Session can be established as an
always-on PDU Session based on the procedure described above.

The UE shall request activation of User Plane resources for always-on PDU Sessions even if there are no pending
uplink data for this PDU Session or when the Service Request is triggered for signalling only or when the Service
Request is triggered for paging response only.

If the UE has one or more established PDU Sessions which are not accepted by the network as always-on PDU Sessions
and the UE has no uplink user data pending to be sent for those PDU Sessions, the UE shall not request for activating
User Plane resources for those PDU sessions.

5.6.14 Support of Framed Routing

Framed Routing allows to support an IP network behind a UE, such that a range of IP addresses or IPv6 prefixes is
reachable over a single PDU session, e.g. for enterprise connectivity. Frame Routes are IP routes behind the UE. The
network does not send Framed Routing information to the UE: devices in the network(s) behind the UE get their IP
address by mechanisms out of the scope of 3GPP specifications. See RFC 2865 [73], RFC 3162 [74].

3GPP
Release 16 130 3GPP TS 23.501 V16.4.0 (2020-03)

A PDU Session may be associated with multiple Frame Routes. Framed Routing is defined only for PDU sessions of
the IP type (IPv4, IPv6, IPv4v6).

Framed Routing information is provided by the SMF to the UPF (acting as PSA) as part of Packet Detection Rule
(PDR, see clause 5.8.2.11.3) related with the network side (N6) of the UPF.

The actual ranges of IPv4 address / IPv6 Prefixes corresponding to a Framed Route may be provided to the SMF by the
DN-AAA server as part of PDU Session Establishment authentication/authorization by a DN-AAA server (as defined in
clause 5.6.6).

The IPv4 address / IPv6 Prefix allocated to the UE as part of the PDU Session establishment (e.g. delivered in NAS
PDU Session Establishment Accept) may belong to one of the Framed Routes associated with the PDU Session or may
be dynamically allocated outside of such Framed Routes.

The actual ranges of IPv4 address / IPv6 Prefixes corresponding to a Framed Route may be defined in the subscription
data associated with a (DNN, S-NSSAI) received by the SMF from the UDM (Session Management Subscription data
defined in Table 5.2.3.3.1-1 of TS 23.502 [3])

If PCC applies to the PDU Session, at PDU Session establishment the SMF reports to the PCF the Framed Routes
corresponding to the PDU Session. In this case, in order to support session binding, the PCF may further report to the
BSF the Framed Routes corresponding to the PDU Session.

5.7 QoS model

5.7.1 General Overview

5.7.1.1 QoS Flow

The 5G QoS model is based on QoS Flows. The 5G QoS model supports both QoS Flows that require guaranteed flow
bit rate (GBR QoS Flows) and QoS Flows that do not require guaranteed flow bit rate (Non-GBR QoS Flows). The 5G
QoS model also supports Reflective QoS (see clause 5.7.5).

The QoS Flow is the finest granularity of QoS differentiation in the PDU Session. A QoS Flow ID (QFI) is used to
identify a QoS Flow in the 5G System. User Plane traffic with the same QFI within a PDU Session receives the same
traffic forwarding treatment (e.g. scheduling, admission threshold). The QFI is carried in an encapsulation header on N3
(and N9) i.e. without any changes to the e2e packet header. QFI shall be used for all PDU Session Types. The QFI shall
be unique within a PDU Session. The QFI may be dynamically assigned or may be equal to the 5QI (see clause 5.7.2.1).

Within the 5GS, a QoS Flow is controlled by the SMF and may be preconfigured, or established via the PDU Session
Establishment procedure (see TS 23.502 [3], clause 4.3.2), or the PDU Session Modification procedure (see
TS 23.502 [3] clause 4.3.3.

Any QoS Flow is characterised by:

- A QoS profile provided by the SMF to the AN via the AMF over the N2 reference point or preconfigured in the
AN;

- One or more QoS rule(s) and optionally QoS Flow level QoS parameters (as specified in TS 24.501 [47])
associated with these QoS rule(s) which can be provided by the SMF to the UE via the AMF over the N1
reference point and/or derived by the UE by applying Reflective QoS control; and

- One or more UL and DL PDR(s) provided by the SMF to the UPF.

Within the 5GS, a QoS Flow associated with the default QoS rule is required to be established for a PDU Session and
remains established throughout the lifetime of the PDU Session. This QoS Flow should be a Non-GBR QoS Flow
(further details are described in clause 5.7.2.7).

A QoS Flow is associated with QoS requirements as specified by QoS parameters and QoS characteristics.

NOTE: The above QoS Flow provides the UE with connectivity throughout the lifetime of the PDU Session.
Possible interworking with EPS motivates the recommendation for this QoS Flow to be of type Non-
GBR.

3GPP
Release 16 131 3GPP TS 23.501 V16.4.0 (2020-03)

5.7.1.2 QoS Profile

A QoS Flow may either be 'GBR' or 'Non-GBR' depending on its QoS profile. The QoS profile of a QoS Flow is sent to
the (R)AN and it contains QoS parameters as described below (details of QoS parameters are described in clause 5.7.2):

- For each QoS Flow, the QoS profile shall include the QoS parameters:

- 5G QoS Identifier (5QI); and

- Allocation and Retention Priority (ARP).

- For each Non-GBR QoS Flow only, the QoS profile may also include the QoS parameter:

- Reflective QoS Attribute (RQA).

- For each GBR QoS Flow only, the QoS profile shall also include the QoS parameters:

- Guaranteed Flow Bit Rate (GFBR) - UL and DL; and

- Maximum Flow Bit Rate (MFBR) - UL and DL; and

- In the case of a GBR QoS Flow only, the QoS profile may also include one or more of the QoS parameters:

- Notification control;

- Maximum Packet Loss Rate - UL and DL.

NOTE: In this Release of the specification, the Maximum Packet Loss Rate (UL, DL) is only provided for a GBR
QoS flow belonging to voice media.

Each QoS profile has one corresponding QoS Flow identifier (QFI) which is not included in the QoS profile itself.

The usage of a dynamically assigned 5QI for a QoS Flow requires in addition the signalling of the complete 5G QoS
characteristics (described in clause 5.7.3) as part of the QoS profile.

When a standardized or pre-configured 5QI is used for a QoS Flow, some of the 5G QoS characteristics may be
signalled as part of the QoS profile (as described in clause 5.7.3).

5.7.1.2a Alternative QoS Profile

The Alternative QoS Profile(s) can be optionally provided for a GBR QoS Flow with Notification control enabled. If
the corresponding PCC rule contains the related information (as described in TS 23.503 [45]), the SMF shall provide, in
addition to the QoS profile, a prioritized list of Alternative QoS Profile(s) to the NG-RAN. If the SMF provides a new
prioritized list of Alternative QoS Profile(s) to the NG-RAN (if the corresponding PCC rule information changes), the
NG-RAN shall replace any previously stored list with it.

An Alternative QoS Profile represents a combination of QoS parameters to which the application traffic is able to adapt
and has the same format as the QoS profile for that QoS Flow.

When the NG-RAN sends a notification to the SMF that the QoS profile is not fulfilled, the NG-RAN shall, if the
currently fulfilled values match an Alternative QoS Profile, include also the reference to the Alternative QoS Profile to
indicate the QoS that the NG-RAN currently fulfils (see clause 5.7.2.4).

5.7.1.3 Control of QoS Flows

The following options are supported to control QoS Flows:

1) For Non-GBR QoS Flows, and when standardized 5QIs or pre-configured 5QIs are used and when the 5QI is
within the range of the QFI (i.e. a value less than 64), the 5QI value may be used as the QFI of the QoS Flow.

(a) A default ARP shall be pre-configured in the AN; or

(b)The ARP and the QFI shall be sent to RAN over N2 at PDU Session Establishment or at PDU Session
Modification and when NG-RAN is used every time the User Plane of the PDU Session is activated; and

3GPP
Release 16 132 3GPP TS 23.501 V16.4.0 (2020-03)

2) For all other cases (including GBR and Non-GBR QoS Flows), a dynamically assigned QFI shall be used. The
5QI value may be a standardized, pre-configured or dynamically assigned. The QoS profile and the QFI of a
QoS Flow shall be provided to the (R)AN over N2 at PDU Session Establishment/Modification and when NG-
RAN is used every time the User Plane of the PDU Session is activated.

Only options 1b and 2 may apply to 3GPP ANs. Options 1a, 1b and 2 may apply to Non-3GPP access.

NOTE: Pre-configured 5QI values cannot be used when the UE is roaming.

5.7.1.4 QoS Rules

The UE performs the classification and marking of UL User plane traffic, i.e. the association of UL traffic to QoS
Flows, based on QoS rules. These QoS rules may be explicitly provided to the UE (i.e. explicitly signalled QoS rules
using the PDU Session Establishment/Modification procedure), pre-configured in the UE or implicitly derived by the
UE by applying Reflective QoS (see clause 5.7.5). A QoS rule contains the QFI of the associated QoS Flow, a Packet
Filter Set (see clause 5.7.6) and a precedence value (see clause 5.7.1.9). An explicitly signalled QoS rule contains a QoS
rule identifier which is unique within the PDU Session and is generated by SMF.

There can be more than one QoS rule associated with the same QoS Flow (i.e. with the same QFI).

When the UE informs the network about the number of supported Packet Filters for signalled QoS rules for the PDU
Session (during the PDU Session Establishment procedure or using the PDU Session Modification procedure as
described in clause 5.17.2.2.2 after the first inter-system change from EPS to 5GS for a PDU Session established in EPS
and transferred from EPS with N26 interface), the SMF shall ensure that the sum of the Packet Filters used by all
signalled QoS rules for a PDU Session does not exceed the number indicated by the UE.

A default QoS rule is required to be sent to the UE for every PDU Session establishment and it is associated with a QoS
Flow. For IP type PDU Session or Ethernet type PDU Session, the default QoS rule is the only QoS rule of a PDU
Session which may contain a Packet Filter Set that allows all UL packets, and in this case, the highest precedence value
shall be used for the QoS rule.

NOTE 2: How the UE evaluates UL packets against the Packet Filter Set in a QoS rule is described in
clause 5.7.1.5.

NOTE 3: The QoS rule pre-configured in the UE is only used together with option 1a for control QoS Flows as
described in clause 5.7.1.3. How to keep the consistency of QFI and Packet Filter Set between UE and
network is out of scope in this release of the specification.

For Unstructured type PDU Session, the default QoS rule does not contain a Packet Filter Set, and in this case the
default QoS rule defines the treatment of all packets in the PDU Session.

As long as the default QoS rule does not contain a Packet Filter Set or contains a Packet Filter Set that allows all UL
packets, Reflective QoS should not be applied for the QoS Flow which the default QoS rule is associated with and the
RQA should not be sent for this QoS Flow.

5.7.1.5 QoS Flow mapping

The SMF performs the binding of SDFs to QoS Flows based on the QoS and service requirements (as defined in
TS 23.503 [45]). The SMF assigns the QFI for a new QoS Flow and derives its QoS profile, corresponding UPF
instructions and QoS Rule(s) from the PCC rules and other information provided by the PCF.

When applicable, the SMF provides the following information to the (R)AN:

- QFI;

- QoS profile as described in clause 5.7.1.2.

- optionally, Alternative QoS Profile(s) as described in clause 5.7.1.2a;

The SMF provides the following information to the UPF enabling classification, bandwidth enforcement and marking
of User Plane traffic (the details are described in clause 5.8):

- a DL PDR containing the DL part of the SDF template and an UL PDR containing the UL part of the SDF
template;

3GPP
Release 16 133 3GPP TS 23.501 V16.4.0 (2020-03)

- the PDR precedence value (see clause 5.7.1.9) for both PDRs is set to the precedence value of the PCC rule;

- QoS related information (e.g. MBR for an SDF, GFBR and MFBR for a GBR QoS Flow) as described in
clause 5.8.2;

- the corresponding packet marking information (e.g. the QFI, the transport level packet marking value (e.g. the
DSCP value of the outer IP header);

- for the DL PDR, optionally, the Reflective QoS Indication.

For each SDF, when applicable, the SMF generates an explicitly signalled QoS rule (see clause 5.7.1.4) according to the
following principles and provides it to the UE together with an add operation:

- A unique (for the PDU Session) QoS rule identifier is assigned;

- The QFI in the QoS rule is set to the QFI of the QoS Flow to which the PCC rule is bound;

- The Packet Filter Set of the QoS rule is generated from the UL SDF filters and optionally the DL SDF filters of
the PCC rule (but only from those SDF filters that have an indication for being signalled to the UE, as defined in
TS 23.503 [45]);

- The QoS rule precedence value is set to the precedence value of the PCC rule for which the QoS rule is
generated;

- for a dynamically assigned QFI, the QoS Flow level QoS parameters (e.g. 5QI, GFBR, MFBR, Averaging
Window, see TS 24.501 [47]) are signalled to UE in addition to the QoS rule(s) associated to the QoS Flow. The
QoS Flow level QoS parameters (i.e. GFBR and MFBR) of an existing QoS Flow may be updated based on the
MBR and GBR information received in the PCC rule (MBR and GBR per SDF are not provided to UE over N1)
or, if the PCF has not indicated differently, when Notification control or handover related signalling indicates
that the QoS parameter the NG-RAN is currently fulfilling for the QoS Flow have changed (see clause 5.7.2.4).

Changes in the binding of SDFs to QoS Flows as well as changes in the PCC rules or other information provided by the
PCF can require QoS Flow changes which the SMF has to provide to (R)AN, UPF and/or UE. In the case of changes in
the explicitly signalled QoS rules associated to a QoS Flow, the SMF provides the explicitly signalled QoS rules and
their operation (i.e. add/modify/delete) to the UE.

NOTE 1: The SMF cannot provide, update or remove pre-configured QoS rules or UE derived QoS rules.

The principle for classification and marking of User Plane traffic and mapping of QoS Flows to AN resources is
illustrated in Figure 5.7.1.5-1.

Application /Service Layer

Data packets from applications
QoS rules
(mapping UL packets to QoS flows
and apply QoS flow marking)
QoS Flow
(all packets marked with
the same QFI)

PDRs
Mapping QoS (classify packets for
flows QoS flow marking
to AN and other actions)
Resources
AN Resources
PDU Session

UE AN UPF

Figure 5.7.1.5-1: The principle for classification and User Plane marking for QoS Flows and mapping
to AN Resources

3GPP
Release 16 134 3GPP TS 23.501 V16.4.0 (2020-03)

In DL, incoming data packets are classified by the UPF based on the Packet Filter Sets of the DL PDRs in the order of
their precedence (without initiating additional N4 signalling). The UPF conveys the classification of the User Plane
traffic belonging to a QoS Flow through an N3 (and N9) User Plane marking using a QFI. The AN binds QoS Flows to
AN resources (i.e. Data Radio Bearers of in the case of 3GPP RAN). There is no strict 1:1 relation between QoS Flows
and AN resources. It is up to the AN to establish the necessary AN resources that QoS Flows can be mapped to, and to
release them. The AN shall indicate to the SMF when the AN resources onto which a QoS Flow is mapped are released.

If no matching DL PDR is found, the UPF shall discard the DL data packet.

In UL:

- For a PDU Session of Type IP or Ethernet, the UE evaluates UL packets against the UL Packet Filters in the
Packet Filter Set in the QoS rules based on the precedence value of QoS rules in increasing order until a
matching QoS rule (i.e. whose Packet Filter matches the UL packet) is found.

- If no matching QoS rule is found, the UE shall discard the UL data packet.

- For a PDU Session of Type Unstructured, the default QoS rule does not contain a Packet Filter Set and allows all
UL packets.

NOTE 2: Only the default QoS rule exist for a PDU Session of Type Unstructured.

The UE uses the QFI in the corresponding matching QoS rule to bind the UL packet to a QoS Flow. The UE then
binds QoS Flows to AN resources.

5.7.1.6 DL traffic
The following characteristics apply for processing of DL traffic:

- UPF maps User Plane traffic to QoS Flows based on the PDRs.

- UPF performs Session-AMBR enforcement as specified in clause 5.7.1.8 and performs counting of packets for
charging.

- UPF transmits the PDUs of the PDU Session in a single tunnel between 5GC and (R)AN, the UPF includes the
QFI in the encapsulation header. In addition, UPF may include an indication for Reflective QoS activation in the
encapsulation header.

- UPF performs transport level packet marking in DL on a per QoS Flow basis. The UPF uses the transport level
packet marking value provided by the SMF (as described in clause 5.8.2.7).

- (R)AN maps PDUs from QoS Flows to access-specific resources based on the QFI and the associated 5G QoS
profile, also taking into account the N3 tunnel associated with the DL packet.

NOTE: Packet Filters are not used for the mapping of QoS Flows onto access-specific resources in (R)AN.

- If Reflective QoS applies, the UE creates a new derived QoS rule as defined in clause 5.7.5.2.

5.7.1.7 UL Traffic
Following characteristics apply for processing of UL traffic:

- UE uses the stored QoS rules to determine mapping between UL User Plane traffic and QoS Flows. UE marks
the UL PDU with the QFI of the QoS rule containing the matching Packet Filter and transmits the UL PDUs
using the corresponding access specific resource for the QoS Flow based on the mapping provided by (R)AN.
For NG-RAN, the UL behaviour is specified in TS 38.300 [27] clause 10.5.2.

- (R)AN transmits the PDUs over N3 tunnel towards UPF. When passing an UL packet from (R)AN to CN, the
(R)AN includes the QFI value, in the encapsulation header of the UL PDU, and selects the N3 tunnel.

- (R)AN performs transport level packet marking in the UL on a per QoS Flow basis with a transport level packet
marking value that is determined based on the 5QI, the Priority Level (if explicitly signalled) and the ARP
priority level of the associated QoS Flow.

3GPP
Release 16 135 3GPP TS 23.501 V16.4.0 (2020-03)

- UPF verifies whether QFIs in the UL PDUs are aligned with the QoS Rules provided to the UE or implicitly
derived by the UE in the case of Reflective QoS).

- UPF and UE perform Session-AMBR enforcement as specified in clause 5.7.1.8 and the UPF performs counting
of packets for charging.

5.7.1.8 AMBR/MFBR enforcement and rate limitation

UL and DL Session-AMBR (see clause 5.7.2.6) shall be enforced by the UPF, if the UPF receives the Session-AMBR
values from the SMF as described in clause 5.8.2.7 and clause 5.8.2.11.4.

For UL Classifier PDU Sessions, UL and DL Session-AMBR (see clause 5.7.2.6) shall be enforced in the SMF selected
UPF that supports the UL Classifier functionality. In addition, the DL Session-AMBR shall be enforced separately in
every UPF that terminates the N6 interface (i.e. without requiring interaction between the UPFs) (see clause 5.6.4).

For multi-homed PDU Sessions, UL and DL Session-AMBR shall be enforced in the UPF that supports the Branching
Point functionality. In addition, the DL Session-AMBR shall be enforced separately in every UPF that terminates the
N6 interface (i.e. without requiring interaction between the UPFs) (see clause 5.6.4).

NOTE: The DL Session-AMBR is enforced in every UPF terminating the N6 interface to reduce unnecessary
transport of traffic which may be discarded by the UPF performing the UL Classifier/Branching Point
functionality due to the amount of the DL traffic for the PDU Session exceeding the DL Session-AMBR.
Discarding DL packets in the UL Classifier/Branching Point could cause erroneous PDU counting for
support of charging

The (R)AN shall enforce UE-AMBR (see clause 5.7.2.6) in UL and DL per UE for Non-GBR QoS Flows.

The UE shall perform UL rate limitation on PDU Session basis for Non-GBR traffic using Session-AMBR, if the UE
receives a Session-AMBR.

MBR per SDF is mandatory for GBR QoS Flows but optional for Non-GBR QoS Flows. The MBR is enforced in the
UPF.

The MFBR is enforced in the UPF in the Downlink for GBR QoS Flows. The MFBR is enforced in the (R)AN in the
Downlink and Uplink for GBR QoS Flows. For non-3GPP access, the UE should enforce MFBR in the Uplink for GBR
QoS Flows.

The QoS control for Unstructured PDUs is performed at the PDU Session level and in this Release of the specification
there is only support for maximum of one 5G QoS Flow per PDU Session of Type Unstructured.

When a PDU Session is set up for transferring unstructured PDUs, SMF provides the QFI which will be applied to any
packet of the PDU Session to the UPF and UE.

5.7.1.9 Precedence Value

The QoS rule precedence value and the PDR precedence value determine the order in which a QoS rule or a PDR,
respectively, shall be evaluated. The evaluation of the QoS rules or PDRs is performed in increasing order of their
precedence value.

5.7.2 5G QoS Parameters

5.7.2.1 5QI
A 5QI is a scalar that is used as a reference to 5G QoS characteristics defined in clause 5.7.4, i.e. access node-specific
parameters that control QoS forwarding treatment for the QoS Flow (e.g. scheduling weights, admission thresholds,
queue management thresholds, link layer protocol configuration, etc.).

Standardized 5QI values have one-to-one mapping to a standardized combination of 5G QoS characteristics as specified
in Table 5.7.4-1.

The 5G QoS characteristics for pre-configured 5QI values are pre-configured in the AN.

3GPP
Release 16 136 3GPP TS 23.501 V16.4.0 (2020-03)

Standardized or pre-configured 5G QoS characteristics, are indicated through the 5QI value, and are not signalled on
any interface, unless certain 5G QoS characteristics are modified as specified in clauses 5.7.3.3, 5.7.3.4, 5.7.3.6, and
5.7.3.7.

The 5G QoS characteristics for QoS Flows with dynamically assigned 5QI are signalled as part of the QoS profile.

NOTE: On N3, each PDU (i.e. in the tunnel used for the PDU Session) is associated with one 5QI via the QFI
carried in the encapsulation header.

5.7.2.2 ARP
The QoS parameter ARP contains information about the priority level, the pre-emption capability and the pre-emption
vulnerability. This allows deciding whether a QoS Flow establishment/modification/handover may be accepted or needs
to be rejected in the case of resource limitations (typically used for admission control of GBR traffic). It may also be
used to decide which existing QoS Flow to pre-empt during resource limitations, i.e. which QoS Flow to release to free
up resources.

The ARP priority level defines the relative importance of a QoS Flow. The range of the ARP priority level is 1 to 15
with 1 as the highest level of priority.

The ARP priority levels 1-8 should only be assigned to QoS Flows for services that are authorized to receive prioritized
treatment within an operator domain (i.e. that are authorized by the serving network). The ARP priority levels 9-15 may
be assigned to QoS Flows for services that are authorized by the home network and thus applicable when a UE is
roaming.

NOTE: This ensures that future releases may use ARP priority level 1-8 to indicate e.g. emergency and other
priority services within an operator domain in a backward compatible manner. This does not prevent the
use of ARP priority level 1-8 in roaming situation in the case that appropriate roaming agreements exist
that ensure a compatible use of these priority levels.

The ARP pre-emption capability defines whether a QoS Flow may get resources that were already assigned to another
QoS Flow with a lower ARP priority level. The ARP pre-emption vulnerability defines whether a QoS Flow may lose
the resources assigned to it in order to admit a QoS Flow with higher ARP priority level. The ARP pre-emption
capability and the ARP pre-emption vulnerability shall be either set to 'enabled' or 'disabled'.

The ARP pre-emption vulnerability of the QoS Flow which the default QoS rule is associated with should be set
appropriately to minimize the risk of a release of this QoS Flow.

The details of how the SMF sets the ARP for a QoS Flow are further described in clause 5.7.2.7.

5.7.2.3 RQA
The Reflective QoS Attribute (RQA) is an optional parameter which indicates that certain traffic (not necessarily all)
carried on this QoS Flow is subject to Reflective QoS. Only when the RQA is signalled for a QoS Flow, the (R)AN
enables the transfer of the RQI for AN resource corresponding to this QoS Flow. The RQA may be signalled to NG-
RAN via the N2 reference point at UE context establishment in NG-RAN and at QoS Flow establishment or
modification.

5.7.2.4 Notification control

5.7.2.4.1 General
The QoS Parameter Notification control indicates whether notifications are requested from the NG-RAN when the
"GFBR can no longer (or can again) be guaranteed" for a QoS Flow during the lifetime of the QoS Flow. Notification
control may be used for a GBR QoS Flow if the application traffic is able to adapt to the change in the QoS (e.g., if the
AF is capable to trigger rate adaptation).

The SMF shall only enable Notification control when the QoS Notification Control parameter is set in the PCC rule
(received from the PCF) that is bound to the QoS Flow. The Notification control parameter is signalled to the NG-RAN
as part of the QoS profile.

3GPP
Release 16 137 3GPP TS 23.501 V16.4.0 (2020-03)

5.7.2.4.1a Notification Control without Alternative QoS Profiles

If, for a given GBR QoS Flow, Notification control is enabled and the NG-RAN determines that the GFBR, the PDB or
the PER of the QoS profile cannot be fulfilled, NG-RAN shall send a notification towards SMF that the "GFBR can no
longer be guaranteed". Furthermore, the NG-RAN shall keep the QoS Flow (i.e. while the NG-RAN is not fulfilling the
requested QoS profile for this QoS Flow), unless specific conditions at the NG-RAN require the release of the NG-RAN
resources for this GBR QoS Flow, e.g. due to Radio link failure or RAN internal congestion. The NG-RAN should try
to fulfil the GFBR, the PDB and the PER of the QoS profile again.

NOTE 1: NG-RAN can decide that the "GFBR can no longer be guaranteed" based on, e.g. measurements like
queuing delay or system load.

Upon receiving a notification from the NG-RAN that the "GFBR can no longer be guaranteed", the SMF may forward
the notification to the PCF, see TS 23.503 [45].

When the NG-RAN determines that the GFBR, the PDB and the PER of the QoS profile can be fulfilled again for a
QoS Flow (for which a notification that the "GFBR can no longer be guaranteed" has been sent), the NG-RAN shall
send a notification, informing the SMF that the "GFBR can be guaranteed" again and the SMF may forward the
notification to the PCF, see TS 23.503 [45]. The NG-RAN shall send a subsequent notification that the "GFBR can no
longer be guaranteed" whenever necessary.

NOTE 2: It is assumed that NG-RAN implementation will apply some hysteresis before determining that the
"GFBR can be guaranteed again" and therefore a frequent signalling of "GFBR can be guaranteed again"
followed by "GFBR can no longer be guaranteed" is not expected.

NOTE 3: If the QoS Flow is modified, the NG-RAN restarts the check whether the "GFBR can no longer be
guaranteed" according to the updated QoS profile. If the Notification control parameter is not included in
the updated QoS profile, the Notification control is disabled.

During a handover, the Source NG-RAN does not inform the Target NG-RAN about whether the Source NG-RAN has
sent a notification for a QoS Flow that the "GFBR can no longer be guaranteed". The Target NG-RAN performs
admission control rejecting any QoS Flows for which resources cannot be permanently allocated. The accepted QoS
Flows are included in the N2 Path Switch Request or N2 Handover Request Acknowledge message from the NG-RAN
to the AMF. The SMF shall interpret the fact that a QoS Flow is listed as transferred QoS Flow in the
Nsmf_PDUSession_UpdateSMContext Request received from the AMF as a notification that "GFBR can be guaranteed
again" for this QoS Flow unless the SMF is also receiving a reference to an Alternative QoS Profile for this QoS Flow
(which is described in clause 5.7.2.4.2). After the handover is successfully completed, the Target NG-RAN shall send a
subsequent notification that the "GFBR can no longer be guaranteed" for such a QoS Flow whenever necessary. If the
SMF has previously notified the PCF that the "GFBR can no longer be guaranteed" and the SMF does not receive an
explicit notification that the "GFBR can no longer be guaranteed" for that QoS Flow from the Target NG-RAN within a
configured time, the SMF shall notify the PCF that the "GFBR can be guaranteed again".

5.7.2.4.1b Notification control with Alternative QoS Profiles

If, for a given GBR QoS Flow, Notification control is enabled and the NG-RAN has received a list of Alternative QoS
Profile(s) for this QoS Flow and supports the Alternative QoS Profile handling, the following shall apply:

1) If the NG-RAN determines that the GFBR, the PDB or the PER of the QoS profile cannot be fulfilled, NG-RAN
shall send a notification towards SMF that the "GFBR can no longer be guaranteed". Before sending a
notification that the "GFBR can no longer be guaranteed" towards the SMF, the NG-RAN shall check whether
the the GFBR, the PDB and the PER that the NG-RAN currently fulfils match any of the Alternative QoS
Profile(s) in the indicated priority order. If there is a match, the NG-RAN shall indicate the reference to the
matching Alternative QoS Profile with the highest priority together with the notification to the SMF.

If there is no match, the NG-RAN shall send a notification that the "GFBR can no longer be guaranteed" towards
the SMF without referencing any of the Alternative QoS Profile(s) (unless specific conditions at the NG-RAN
require the release of the NG-RAN resources for this GBR QoS Flow, e.g. due to Radio link failure or RAN
internal congestion).

2) If a notification that the "GFBR can no longer be guaranteed" has been sent to the SMF and the NG-RAN
determines that the currently fulfilled GFBR, PDB or PER are different (better or worse) from the situation
indicated in the last notification, the NG-RAN shall send a further notification to the SMF and indicate the
currently fulfilled situation.

3GPP
Release 16 138 3GPP TS 23.501 V16.4.0 (2020-03)

NOTE 1: The fulfilled situation is either the QoS Profile, an Alternative QoS Profile, or an indication that the
lowest priority Alternative QoS Profile cannot be fulfilled.

3)- The NG-RAN should always try to fulfil the QoS profile and any Alternative QoS Profile that has higher priority
than the currently fulfilled situation.

NOTE 2: In order to avoid a too frequent signalling to the SMF, it is assumed that NG-RAN implementation can
apply hysteresis (e.g., via a configurable time interval) before notifying the SMF that the currently
fulfilled values match the QoS Profile or a different Alternative QoS Profile of higher priority. It is also
assumed that the PCF has ensured that the QoS values within the different Alternative QoS Profile(s) are
not too close to each other.

4) Upon receiving a notification from the NG-RAN, the SMF may inform the PCF. If it does so, the SMF shall
indicate the currently fulfilled situation to the PCF. See TS 23.503 [45].

5)- If the PCF has not indicated differently, the SMF uses NAS signalling (that is sent transparently through the
RAN) to inform the UE about changes in the QoS parameters (i.e., 5QI, GFBR, MFBR) that the NG-RAN is
currently fulfilling for the QoS Flow after Notification control has occurred.

5.7.2.4.2 Usage of Notification control with Alternative QoS Profiles at handover

During handover, the prioritized list of Alternative QoS Profile(s) (if available) is provided to the Target NG-RAN per
QoS Flow in addition to the QoS profile. If the Target NG-RAN is not able to guarantee the GFBR, the PDB and the
PER included in the QoS profile and if Alternative QoS Profiles are provided to the Target NG-RAN and the Target
NG-RAN supports Alternative QoS Profiles, the Target NG-RAN checks whether the GFBR, the PDB and the PER
values that it can fulfil match any of the Alternative QoS Profile(s) taking the priority order into account. If there is a
match between one of the Alternative QoS Profiles and the GFBR, the PDB and the PER values that Target NG-RAN
can fulfil, the Target NG-RAN shall accept the QoS Flow and indicate the reference to that Alternative QoS Profile to
the Source NG-RAN.

If there is no match to any Alternative QoS Profile, the Target NG-RAN rejects QoS Flows for which the Target NG-
RAN is not able to guarantee the GFBR, the PDB and the PER included in the QoS profile.

After the handover is completed and a QoS Flow has been accepted by the Target NG-RAN based on an Alternative
QoS Profile, the Target NG-RAN shall treat this QoS Flow in the same way as if it had sent a notification that the
"GFBR can no longer be guaranteed" with a reference to that Alternative QoS Profile to the SMF (as described in
clause 5.7.2.4.1b).

If a QoS Flow has been accepted by the Target NG-RAN based on an Alternative QoS Profile, the reference to the
matching Alternative QoS Profile is provided from the Target NG-RAN to the AMF (which forwards the message to
the SMF) during the Xn and N2 based handover procedures as described in TS 23.502 [3]. After the handover is
completed successfully, the SMF shall send a notification to the PCF that the "GFBR can no longer be guaranteed" for a
QoS Flow (see TS 23.503 [45] for details) if the SMF has received a reference to an Alternative QoS Profile and this
reference indicates a change in the previously notified state of this QoS Flow. If the PCF has not indicated differently,
the SMF shall also use NAS signalling (that is sent transparently through the RAN) to inform the UE about the QoS
parameters (i.e. 5QI, GFBR, MFBR) corresponding to the new state of the QoS Flow.

NOTE: A state change for the QoS Flow comprises a change from QoS profile fulfilled to Alternative QoS
Profile fulfilled as well as the state change between fulfilled Alternative QoS Profiles.

If a QoS Flow has been accepted by the Target NG-RAN based on the QoS Profile, the SMF shall interpret the fact that
a QoS Flow is listed as transferred QoS Flow in the message received from the AMF as a notification that "GFBR can
be guaranteed again" for this QoS Flow. After the handover is successfully completed, the Target NG-RAN performs as
described in clause 5.7.2.4.1b. If the SMF has previously notified the PCF that the "GFBR can no longer be guaranteed"
and the SMF does not receive an explicit notification that the "GFBR can no longer be guaranteed" for that QoS Flow
from the Target NG-RAN within a configured time, the SMF shall notify the PCF that the "GFBR can be guaranteed
again".

If a QoS Flow has been accepted by the Target NG-RAN and SMF did not receive from the Target NG-RAN a
reference to any Alternative QoS Profile and the SMF has previously informed the UE about QoS parameters
corresponding to any of the Alternative QoS Profile(s), the SMF shall use NAS signalling to inform the UE about the
QoS parameters corresponding to the QoS Profile.

3GPP
Release 16 139 3GPP TS 23.501 V16.4.0 (2020-03)

5.7.2.5 Flow Bit Rates

For GBR QoS Flows only, the following additional QoS parameters exist:

- Guaranteed Flow Bit Rate (GFBR) - UL and DL;

- Maximum Flow Bit Rate (MFBR) -- UL and DL.

The GFBR denotes the bit rate that is guaranteed to be provided by the network to the QoS Flow over the Averaging
Time Window. The MFBR limits the bit rate to the highest bit rate that is expected by the QoS Flow (e.g. excess traffic
may get discarded or delayed by a rate shaping or policing function at the UE, RAN, UPF). Bit rates above the GFBR
value and up to the MFBR value, may be provided with relative priority determined by the Priority Level of the QoS
Flows (see clause 5.7.3.3).

GFBR and MFBR are signalled to the (R)AN in the QoS Profile and signalled to the UE as QoS Flow level QoS
parameter (as specified in TS 24.501 [47]) for each individual QoS Flow.

NOTE 1: The GFBR is recommended as the lowest acceptable service bitrate where the service will survive.

NOTE 2: For each QoS Flow of Delay Critical GBR resource type, the SMF can ensure that the GFBR of the QoS
Flow can be achieved with the MDBV of the QoS Flow using the QoS Flow binding functionality
described in clause 6.1.3.2.4 in TS 23.503 [45].

NOTE 3: The network can set MFBR larger than GFBR for a particular QoS Flow based on operator policy and the
knowledge of the end point capability, i.e. support of rate adaptation at application / service level.

5.7.2.6 Aggregate Bit Rates

Each PDU Session of a UE is associated with the following aggregate rate limit QoS parameter:

- per Session Aggregate Maximum Bit Rate (Session-AMBR).

The Session-AMBR is signalled to the appropriate UPF entity/ies to the UE and to the (R)AN (to enable the calculation
of the UE-AMBR). The Session-AMBR limits the aggregate bit rate that can be expected to be provided across all Non-
GBR QoS Flows for a specific PDU Session. The Session-AMBR is measured over an AMBR averaging window
which is a standardized value. The Session-AMBR is not applicable to GBR QoS Flows.

Each UE is associated with the following aggregate rate limit QoS parameter:

- per UE Aggregate Maximum Bit Rate (UE-AMBR).

The UE-AMBR limits the aggregate bit rate that can be expected to be provided across all Non-GBR QoS Flows of a
UE. Each (R)AN shall set its UE-AMBR to the sum of the Session-AMBR of all PDU Sessions with active user plane
to this (R)AN up to the value of the received UE-AMBR from AMF. The UE-AMBR is a parameter provided to the
(R)AN by the AMF based on the value of the subscribed UE-AMBR retrieved from UDM or the dynamic serving
network UE-AMBR retrieved from PCF (e.g. for roaming subscriber). The AMF provides the UE-AMBR provided by
PCF to (R)AN if available. The UE-AMBR is measured over an AMBR averaging window which is a standardized
value. The UE-AMBR is not applicable to GBR QoS Flows.

NOTE: The AMBR averaging window is only applied to Session-AMBR and UE-AMBR measurement and the
AMBR averaging windows for Session-AMBR and UE-AMBR are standardised to the same value.

5.7.2.7 Default values

For each PDU Session Setup, the SMF retrieves the subscribed Session-AMBR values as well as the subscribed default
values for the 5QI and the ARP and optionally, the 5QI Priority Level, from the UDM. The subscribed default 5QI
value shall be a Non-GBR 5QI from the standardized value range.

NOTE 1: The 5QI Priority Level can be added to the subscription information to achieve an overwriting of the
standardized or preconfigured 5QI Priority Level e.g. in scenarios where dynamic PCC is not deployed or
the PCF is unavailable or unreachable.

3GPP
Release 16 140 3GPP TS 23.501 V16.4.0 (2020-03)

The SMF may change the subscribed values for the default 5QI and the ARP and if received, the 5QI Priority Level,
based on interaction with the PCF as described in TS 23.503 [45] or, if dynamic PCC is not deployed, based on local
configuration, to set QoS parameters for the QoS Flow associated with the default QoS rule.

For QoS Flow(s) of the PDU Session other than the QoS Flow associated with the default QoS rule, the SMF shall set
the ARP priority level, the ARP pre-emption capability and the ARP pre-emption vulnerability to the respective values
in the PCC rule(s) bound to that QoS Flow (as described in TS 23.503 [45]). If dynamic PCC is not deployed, the SMF
shall apply the subscribed value for the ARP priority level, and shall set the ARP pre-emption capability and the ARP
pre-emption vulnerability based on local configuration.

If dynamic PCC is not deployed, the SMF can have a DNN based configuration to enable the establishment of a GBR
QoS Flow as the QoS Flow that is associated with the default QoS rule. This configuration contains a standardized GBR
5QI as well as GFBR and MFBR for UL and DL.

NOTE 2: Interworking with EPS is not possible for a PDU Session with a GBR QoS Flow as the QoS Flow that is
associated with the default QoS rule.

The SMF may change the subscribed Session-AMBR values (for UL and/or DL), based on interaction with the PCF as
described in TS 23.503 [45] or, if dynamic PCC is not deployed, based on local configuration, to set the Session-AMBR
values for the PDU Session.

5.7.2.8 Maximum Packet Loss Rate

The Maximum Packet Loss Rate (UL, DL) indicates the maximum rate for lost packets of the QoS flow that can be
tolerated in the uplink and downlink direction. This is provided to the QoS flow if it is compliant to the GFBR

NOTE: In this Release of the specification, the Maximum Packet Loss Rate (UL, DL) can only be provided for a
GBR QoS flow belonging to voice media.

5.7.2.9 Wireline access network specific 5G QoS parameters

QoS parameters that are applicable only for or wireline access networks (W-5GAN) are specified in TS 23.316 [84].

5.7.3 5G QoS characteristics

5.7.3.1 General
This clause specifies the 5G QoS characteristics associated with 5QI. The characteristics describe the packet forwarding
treatment that a QoS Flow receives edge-to-edge between the UE and the UPF in terms of the following performance
characteristics:

1 Resource Type (GBR, Delay critical GBR or Non-GBR);

2 Priority Level;

3 Packet Delay Budget (including Core Network Packet Delay Budget);

4 Packet Error Rate;

5 Averaging window (for GBR and Delay-critical GBR resource type only);

6 Maximum Data Burst Volume (for Delay-critical GBR resource type only).

The 5G QoS characteristics should be understood as guidelines for setting node specific parameters for each QoS Flow
e.g. for 3GPP radio access link layer protocol configurations.

Standardized or pre-configured 5G QoS characteristics, are indicated through the 5QI value, and are not signalled on
any interface, unless certain 5G QoS characteristics are modified as specified in clauses 5.7.3.3, 5.7.3.4, 5.7.3.6, and
5.7.3.7.

NOTE: As there are no default values specified, pre-configured 5G QoS characteristics have to include all of the
characteristics listed above.

3GPP
Release 16 141 3GPP TS 23.501 V16.4.0 (2020-03)

Signalled 5G QoS characteristics are provided as part of the QoS profile and shall include all of the characteristics listed
above.

5.7.3.2 Resource Type

The Resource Type determines if dedicated network resources related to a QoS Flow-level Guaranteed Flow Bit Rate
(GFBR) value are permanently allocated (e.g. by an admission control function in a radio base station).

GBR QoS Flows are therefore typically authorized "on demand" which requires dynamic policy and charging control. A
GBR QoS Flow uses either the GBR resource type or the Delay-critical GBR resource type. The definition of PDB and
PER are different for GBR and Delay-critical GBR resource types, and the MDBV parameter applies only to the Delay-
critical GBR resource type.

A Non-GBR QoS Flow may be pre-authorized through static policy and charging control. A Non-GBR QoS Flow uses
only the Non-GBR resource type.

5.7.3.3 Priority Level

The Priority Level associated with 5G QoS characteristics indicates a priority in scheduling resources among QoS
Flows. The lowest Priority Level value corresponds to the highest priority.

The Priority Level shall be used to differentiate between QoS Flows of the same UE, and it shall also be used to
differentiate between QoS Flows from different UEs.

In the case of congestion, when all QoS requirements cannot be fulfilled for one or more QoS Flows, the Priority Level
shall be used to select for which QoS Flows the QoS requirements are prioritised such that a QoS Flow with Priority
Level value N is priorized over QoS Flows with higher Priority Level values (i.e. N+1, N+2, etc).In the case of no
congestion, the Priority Level should be used to define the resource distribution between QoS Flows. In addition, the
scheduler may prioritize QoS Flows based on other parameters (e.g. resource type, radio condition) in order to optimize
application performance and network capacity.

Every standardized 5QI is associated with a default value for the Priority Level -specified in QoS characteristics
Table 5.7.4.1). Priority Level may also be signalled together with a standardized 5QI to the -R)AN, and if it is received,
it shall be used instead of the default value.

Priority Level may also be signalled together with a pre-configured 5QI to the (R)AN, and if it is received, it shall be
used instead of the pre-configured value.

5.7.3.4 Packet Delay Budget

The Packet Delay Budget (PDB) defines an upper bound for the time that a packet may be delayed between the UE and
the UPF that terminates the N6 interface. For a certain 5QI the value of the PDB is the same in UL and DL. In the case
of 3GPP access, the PDB is used to support the configuration of scheduling and link layer functions (e.g. the setting of
scheduling priority weights and HARQ target operating points). For GBR QoS Flows using the Delay-critical resource
type, a packet delayed more than PDB is counted as lost if the data burst is not exceeding the MDBV within the period
of PDB and the QoS Flow is not exceeding the GFBR. For GBR QoS Flows with GBR resource type not exceeding
GFBR, 98 percent of the packets shall not experience a delay exceeding the 5QI's PDB.

The 5G Access Network Packet Delay Budget (5G-AN PDB) is determined by subtracting a static value for the Core
Network Packet Delay Budget (CN PDB), which represents the delay between any UPF terminating N6 (that may
possibly be selected for the PDU Session) and the 5G-AN from a given PDB.

NOTE 1: For a standardized 5QI, the static value for the CN PDB is specified in the QoS characteristics Table
5.7.4-1.

NOTE 2: For a non-standardized 5QI, the static value for the CN PDB is homogeneously configured in the
network.

For GBR QoS Flows using the Delay-critical resource type, in order to obtain a more accurate delay budget PDB
available for the NG-RAN, a dynamic value for the CN PDB, which represents the delay between the UPF terminating
N6 for the QoS Flow and the 5G-AN, can be used. If used for a QoS Flow, the NG-RAN shall apply the dynamic value
for the CN PDB instead of the static value for the CN PDB (which is only related to the 5QI). Different dynamic value
for CN PDB may be configured per uplink and downlink direction.

3GPP
Release 16 142 3GPP TS 23.501 V16.4.0 (2020-03)

NOTE 3: The configuration of transport network on CN tunnel can be different per UL and DL, which can be
different value for CN PDB per UL and DL.

NOTE 4: It is expected that the UPF deployment ensures that the dynamic value for the CN PDB is not larger than
the static value for the CN PDB. This avoids that the functionality that is based on the 5G-AN PDB (e.g.
MDBV, NG-RAN scheduler) has to handle an unexpected value.

The dynamic value for the CN PDB of a Delay-critical GBR 5QI may be configured in the network in two ways:

- Configured in each NG-RAN node, based on a variety of inputs such as different IP address(es) or TEID range
of UPF terminating the N3 tunnel and based on different combinations of PSA UPF to NG-RAN under
consideration of any potential I-UPF, etc;

- Configured in the SMF, based on different combinations of PSA UPF to NG-RAN under consideration of any
potential I-UPF. The dynamic value for the CN PDB for a particular QoS Flow shall be signalled to NG-RAN
(during PDU Session Establishment, PDU Session Modification, Xn/N2 handover and the Service Request
procedures) when the QoS Flow is established or the dynamic value for the CN PDB of a QoS Flow changes,
e.g. when an I-UPF is inserted by the SMF.

If the NG-RAN node is configured locally with a dynamic value for the CN PDB for a Delay-critical GBR 5QI, and
receives a different value via N2 signalling for a QoS Flow with the same 5QI, local configuration in RAN node
determines which value takes precedence.

Services using a GBR QoS Flow and sending at a rate smaller than or equal to the GFBR can in general assume that
congestion related packet drops will not occur.

NOTE 5: Exceptions (e.g. transient link outages) can always occur in a radio access system which may then lead to
congestion related packet drops. Packets surviving congestion related packet dropping may still be subject
to non-congestion related packet losses (see PER below).

Services using Non-GBR QoS Flows should be prepared to experience congestion-related packet drops and delays. In
uncongested scenarios, 98 percent of the packets should not experience a delay exceeding the 5QI's PDB.

The PDB for Non-GBR and GBR resource types denotes a "soft upper bound" in the sense that an "expired" packet, e.g.
a link layer SDU that has exceeded the PDB, does not need to be discarded and is not added to the PER. However, for a
Delay critical GBR resource type, packets delayed more than the PDB are added to the PER and can be discarded or
delivered depending on local decision.

5.7.3.5 Packet Error Rate

The Packet Error Rate (PER) defines an upper bound for the rate of PDUs (e.g. IP packets) that have been processed by
the sender of a link layer protocol (e.g. RLC in RAN of a 3GPP access) but that are not successfully delivered by the
corresponding receiver to the upper layer (e.g. PDCP in RAN of a 3GPP access). Thus, the PER defines an upper bound
for a rate of non-congestion related packet losses. The purpose of the PER is to allow for appropriate link layer protocol
configurations (e.g. RLC and HARQ in RAN of a 3GPP access). For every 5QI the value of the PER is the same in UL
and DL. For GBR QoS Flows with Delay critical GBR resource type, a packet which is delayed more than PDB is
counted as lost, and included in the PER unless the data burst is exceeding the MDBV within the period of PDB or the
QoS Flow is exceeding the GFBR.

5.7.3.6 Averaging Window

Each GBR QoS Flow shall be associated with an Averaging window. The Averaging window represents the duration
over which the GFBR and MFBR shall be calculated (e.g. in the (R)AN, UPF, UE).

Every standardized 5QI (of GBR and Delay-critical GBR resource type) is associated with a default value for the
Averaging window (specified in QoS characteristics Table 5.7.4.1). The averaging window may also be signalled
together with a standardized 5QI to the (R)AN and UPF, and if it is received, it shall be used instead of the default
value.

The Averaging window may also be signalled together with a pre-configured 5QI to the (R)AN, and if it is received, it
shall be used instead of the pre-configured value.

3GPP
Release 16 143 3GPP TS 23.501 V16.4.0 (2020-03)

5.7.3.7 Maximum Data Burst Volume

Each GBR QoS Flow with Delay-critical resource type shall be associated with a Maximum Data Burst Volume
(MDBV).

MDBV denotes the largest amount of data that the 5G-AN is required to serve within a period of 5G-AN PDB.

Every standardized 5QI (of Delay-critical GBR resource type) is associated with a default value for the MDBV
(specified in QoS characteristics Table 5.7.4.1). The MDBV may also be signalled together with a standardized 5QI to
the (R)AN, and if it is received, it shall be used instead of the default value.

The MDBV may also be signalled together with a pre-configured 5QI to the (R)AN, and if it is received, it shall be used
instead of the pre-configured value.

5.7.4 Standardized 5QI to QoS characteristics mapping

Standardized 5QI values are specified for services that are assumed to be frequently used and thus benefit from
optimized signalling by using standardized QoS characteristics. Dynamically assigned 5QI values (which require a
signalling of QoS characteristics as part of the QoS profile) can be used for services for which standardized 5QI values
are not defined. The one-to-one mapping of standardized 5QI values to 5G QoS characteristics is specified in
table 5.7.4-1.

3GPP
Release 16 144 3GPP TS 23.501 V16.4.0 (2020-03)

Table 5.7.4-1: Standardized 5QI to QoS characteristics mapping

3GPP
Release 16 145 3GPP TS 23.501 V16.4.0 (2020-03)

5QI Resource Default Packet Packet Default Default Example Services

Value Type Priority Delay Error Maximum Averaging
Level Budget Rate Data Burst Window
(NOTE 3) Volume
(NOTE 2)
1 20 100 ms 10-2 N/A 2000 ms Conversational Voice
GBR (NOTE 11,
NOTE 13)
2 (NOTE 1) 40 150 ms 10-3 N/A 2000 ms Conversational Video
(NOTE 11, (Live Streaming)
NOTE 13)
3 30 50 ms 10-3 N/A 2000 ms Real Time Gaming,
(NOTE 14) (NOTE 11, V2X messages
NOTE 13) Electricity distribution
– medium voltage,
Process automation -
monitoring
4 50 300 ms 10-6 N/A 2000 ms Non-Conversational
(NOTE 11, Video (Buffered
NOTE 13) Streaming)
65 7 75 ms N/A 2000 ms Mission Critical user
(NOTE 9, (NOTE 7, 10-2 plane Push To Talk
NOTE 12) NOTE 8) voice (e.g., MCPTT)
66 100 ms N/A 2000 ms Non-Mission-Critical
(NOTE 12) 20 (NOTE 10, 10-2 user plane Push To
NOTE 13) Talk voice
67 15 100 ms 10-3 N/A 2000 ms Mission Critical Video
(NOTE 12) (NOTE 10, user plane
NOTE 13)
75
(NOTE 14)
71 56 150 ms 10-6 N/A 2000 ms "Live" Uplink
(NOTE 11, Streaming (e.g.
NOTE 13, TS 26.238 [76])
NOTE 15)
72 56 300 ms 10-4 N/A 2000 ms "Live" Uplink
(NOTE 11, Streaming (e.g.
NOTE 13, TS 26.238 [76])
NOTE 15)
73 56 300 ms 10-8 N/A 2000 ms "Live" Uplink
(NOTE 11, Streaming (e.g.
NOTE 13, TS 26.238 [76])
NOTE 15)
74 56 500 ms 10-8 N/A 2000 ms "Live" Uplink
(NOTE 11, Streaming (e.g.
NOTE 15) TS 26.238 [76])
76 56 500 ms 10-4 N/A 2000 ms "Live" Uplink
(NOTE 11, Streaming (e.g.
NOTE 13, TS 26.238 [76])
NOTE 15)
5 Non-GBR 10 100 ms 10-6 N/A N/A IMS Signalling
NOTE 10,
NOTE 13)
6 (NOTE 1) N/A N/A Video (Buffered
60 300 ms 10-6 Streaming)
(NOTE 10, TCP-based (e.g.,
NOTE 13) www, e-mail, chat, ftp,
p2p file sharing,
progressive video,
etc.)
7 N/A N/A Voice,
70 100 ms 10-3 Video (Live
(NOTE 10, Streaming)
NOTE 13) Interactive Gaming

3GPP
Release 16 146 3GPP TS 23.501 V16.4.0 (2020-03)

8
80 Video (Buffered
Streaming)
300 ms 10-6 N/A N/A TCP-based (e.g.,
(NOTE 13) www, e-mail, chat, ftp,
p2p file sharing,
progressive
9 90 video, etc.)
69 5 60 ms 10-6 N/A N/A Mission Critical delay
(NOTE 9, (NOTE 7, sensitive signalling
NOTE 12) NOTE 8) (e.g., MC-PTT
signalling)
70 55 200 ms 10-6 N/A N/A Mission Critical Data
(NOTE 12) (NOTE 7, (e.g. example services
NOTE 10) are the same as 5QI
6/8/9)
79 65 50 ms 10-2 N/A N/A V2X messages
(NOTE 10,
NOTE 13)
80 68 10 ms 10-6 N/A N/A Low Latency eMBB
(NOTE 5, applications
NOTE 10) Augmented Reality
82 Delay 19 10 ms 10-4 255 bytes 2000 ms Discrete Automation
Critical (NOTE 4) (see TS 22.261 [2])
GBR
83 22 10 ms 10-4 1354 bytes 2000 ms Discrete Automation
(NOTE 4) (NOTE 3) (see TS 22.261 [2]);
V2X messages (UE -
RSU Platooning,
Advanced Driving:
Cooperative Lane
Change with low LoA.
See TS 22.186 [111])
84 24 30 ms 10-5 1354 bytes 2000 ms Intelligent transport
(NOTE 6) (NOTE 3) systems (see
TS 22.261 [2])
85 21 5 ms 10-5 255 bytes 2000 ms Electricity Distribution-
(NOTE 5) high voltage (see
TS 22.261 [2]).
V2X messages
(Remote Driving. See
TS 22.186 [111],
NOTE 16)
86 18 5 ms 10-4 1354 bytes 2000 ms V2X messages
(NOTE 5) (Advanced Driving:
Collision Avoidance,
Platooning with high
LoA. See
TS 22.186 [111])

3GPP
Release 16 147 3GPP TS 23.501 V16.4.0 (2020-03)

NOTE 1: A packet which is delayed more than PDB is not counted as lost, thus not included in the PER.
NOTE 2: It is required that default MDBV is supported by a PLMN supporting the related 5QIs.
NOTE 3: The Maximum Transfer Unit (MTU) size considerations in clause 9.3 and Annex C of TS 23.060 [7] are also
applicable. IP fragmentation may have impacts to CN PDB, and details are provided in clause 5.6.10.
NOTE 4: A static value for the CN PDB of 1 ms for the delay between a UPF terminating N6 and a 5G-AN should be
subtracted from a given PDB to derive the packet delay budget that applies to the radio interface. When a
dynamic CN PDB is used, see clause 5.7.3.4.
NOTE 5: A static value for the CN PDB of 2 ms for the delay between a UPF terminating N6 and a 5G-AN should be
subtracted from a given PDB to derive the packet delay budget that applies to the radio interface. When a
dynamic CN PDB is used, see clause 5.7.3.4.
NOTE 6: A static value for the CN PDB of 5 ms for the delay between a UPF terminating N6 and a 5G-AN should be
subtracted from a given PDB to derive the packet delay budget that applies to the radio interface. When a
dynamic CN PDB is used, see clause 5.7.3.4.
NOTE 7: For Mission Critical services, it may be assumed that the UPF terminating N6 is located "close" to the 5G_AN
(roughly 10 ms) and is not normally used in a long distance, home routed roaming situation. Hence a static
value for the CN PDBof 10 ms for the delay between a UPF terminating N6 and a 5G_AN should be
subtracted from this PDB to derive the packet delay budget that applies to the radio interface.
NOTE 8: In both RRC Idle and RRC Connected mode, the PDB requirement for these 5QIs can be relaxed (but not to
a value greater than 320 ms) for the first packet(s) in a downlink data or signalling burst in order to permit
reasonable battery saving (DRX) techniques.
NOTE 9: It is expected that 5QI-65 and 5QI-69 are used together to provide Mission Critical Push to Talk service (e.g.,
5QI-5 is not used for signalling). It is expected that the amount of traffic per UE will be similar or less
compared to the IMS signalling.
NOTE 10: In both RRC Idle and RRC Connected mode, the PDB requirement for these 5QIs can be relaxed for the first
packet(s) in a downlink data or signalling burst in order to permit battery saving (DRX) techniques.
NOTE 11: In RRC Idle mode, the PDB requirement for these 5QIs can be relaxed for the first packet(s) in a downlink
data or signalling burst in order to permit battery saving (DRX) techniques.
NOTE 12: This 5QI value can only be assigned upon request from the network side. The UE and any application
running on the UE is not allowed to request this 5QI value.
NOTE 13: A static value for the CN PDB of 20 ms for the delay between a UPF terminating N6 and a 5G-AN should be
subtracted from a given PDB to derive the packet delay budget that applies to the radio interface.
NOTE 14: This 5QI is not supported in this Release of the specification as it is only used for transmission of V2X
messages over MBMS bearers as defined in TS 23.285 [72] but the value is reserved for future use.
NOTE 15: For "live" uplink streaming (see TS 26.238 [76]), guidelines for PDB values of the different 5QIs correspond to
the latency configurations defined in TR 26.939 [77]. In order to support higher latency reliable streaming
services (above 500ms PDB), if different PDB and PER combinations are needed these configurations will
have to use non-standardised 5QIs.
NOTE 16: These services are expected to need much larger MDBV values to be signalled to the RAN. Support for such
larger MDBV values with low latency and high reliability is likely to require a suitable RAN configuration, for
which, the simulation scenarios in TR 38.824 [112] may contain some guidance.

NOTE: It is preferred that a value less than 64 is allocated for any new standardised 5QI of non-GBR Resource
Type. This is to allow for option 1 to be used as described in clause 5.7.1.3 (as the QFI is limited to less
than 64).

5.7.5 Reflective QoS

5.7.5.1 General
Reflective QoS enables the UE to map UL User Plane traffic to QoS Flows without SMF provided QoS rules and it
applies for IP PDU Session and Ethernet PDU Session. This is achieved by creating UE derived QoS rules in the UE
based on the received DL traffic. It shall be possible to apply Reflective QoS and non-Reflective QoS concurrently
within the same PDU Session.

For a UE supporting Reflective QoS functionality, the UE shall create a UE derived QoS rule for the uplink traffic
based on the received DL traffic if Reflective QoS function is used by the 5GC for some traffic flows. The UE shall use
the UE derived QoS rules to determine mapping of UL traffic to QoS Flows.

If the 3GPP UE supports Reflective QoS functionality, the UE should indicate support of Reflective QoS to the network
(i.e. SMF) for every PDU Session. For PDU Sessions established in EPS and PDU Sessions transferred from EPS
without N26 interface, the UE indicates Reflective QoS support using the PDU Session Establishment procedure. After
the first inter-system change from EPS to 5GS for PDU Sessions established in EPS and transferred from EPS with N26
interface, the UE indicates Reflective QoS support using the PDU Session Modification procedure as described in
clause 5.17.2.2.2. The UE as well as the network shall apply the information whether or not the UE indicated support of
Reflective QoS throughout the lifetime of the PDU Session.

3GPP
Release 16 148 3GPP TS 23.501 V16.4.0 (2020-03)

NOTE: The logic driving a supporting UE under exceptional circumstances to not indicate support of Reflective
QoS for a PDU Session is implementation dependent.

Under exceptional circumstances, which are UE implementation dependent, the UE may decide to revoke previously
indicated support for Reflective QoS using the PDU Session Modification procedure. In such a case, the UE shall delete
all derived QoS rules for this PDU Session and the network shall stop any user plane enforcement actions related to
Reflective QoS for this PDU Session. In addition, the network may provide signalled QoS rules for the SDFs for which
Reflective QoS was used before. The UE shall not indicate support for Reflective QoS for this PDU Session for the
remaining lifetime of the PDU Session.

If under the same exceptional circumstances mentioned above and while NAS level MM or SM congestion control
timer is running, the UE needs to revoke a previously indicated support for Reflective QoS, the UE performs PDU
Session Release procedure that is exempt from MM and SM congestion control as defined in clause 5.19.7.

5.7.5.2 UE Derived QoS Rule

The UE derived QoS rule contains following parameters:

- One UL Packet Filter (in the Packet Filter Set as defined in clause 5.7.6);

- QFI;

- Precedence value (see clause 5.7.1.9).

Upon receiving DL packet, one UL Packet Filter derived from the received DL packet as described in this clause is used
to identify a UE derived QoS rule within a PDU Session.

For PDU Session of IP type the UL Packet Filter is derived based on the received DL packet as follows:

- When Protocol ID / Next Header is set to TCP or UDP, by using the source and destination IP addresses, source
and destination port numbers, and the Protocol ID / Next Header field itself.

- When Protocol ID / Next Header is set to ESP, by using the source and destination IP addresses, the Security
Parameter Index, and the Protocol ID / Next Header field itself. If the received DL packet is an IPSec protected
packet, and an uplink IPSec SA corresponding to a downlink IPSec SA of the SPI in the DL packet exists, then
the UL Packet Filter contains an SPI of the uplink IPSec SA.

NOTE 1: In this Release of the specification for PDU Sessions of IP type the use of Reflective QoS is restricted to
service data flows for which Protocol ID / Next Header is set to TCP, UDP or ESP.

NOTE 2: The UE does not verify whether the downlink packets with RQI indication match the restrictions on
Reflective QoS.

For PDU Session of Ethernet type the UL Packet Filter is derived based on the received DL packet by using the source
and destination MAC addresses, the Ethertype on received DL packet is used as Ethertype for UL packet. In the case of
presence of 802.1Q [98], the VID and PCP in IEEE 802.1Q [98] header(s) of the received DL packet is also used as the
VID and PCP field for the UL Packet Filter. When double 802.1Q [98] tagging is used, only the outer (S-TAG) is taken
into account for the UL Packet Filter derivation.

NOTE 3: In this Release of the specification for PDU Sessions of Ethernet type the use of Reflective QoS is
restricted to service data flows for which 802.1Q [98] tagging is used.

The QFI of the UE derived QoS rule is set to the value received in the DL packet.

When Reflective QoS is activated the precedence value for all UE derived QoS rules is set to a standardised value.

5.7.5.3 Reflective QoS Control

Reflective QoS is controlled on per-packet basis by using the Reflective QoS Indication (RQI) in the encapsulation
header on N3 (and N9) reference point together with the QFI, together with a Reflective QoS Timer (RQ Timer) value
that is either signalled to the UE upon PDU Session Establishment (or upon PDU Session Modification as described in
clause 5.17.2.2.2) or set to a default value. The RQ Timer value provided by the core network is at the granularity of
PDU session -the details are specified in TS 24.501 [47]).

3GPP
Release 16 149 3GPP TS 23.501 V16.4.0 (2020-03)

When the 5GC determines that Reflective QoS has to be used for a specific SDF belonging to a QoS Flow, the SMF
shall provide the RQA (Reflective QoS Attribute) within the QoS Flow's QoS profile to the NG-RAN on N2 reference
point unless it has been done so before. When the RQA has been provided to the NG-RAN for a QoS Flow and the 5GC
determines that the QoS Flow carries no more SDF for which Reflective QoS has to be used, the SMF should signal the
removal of the RQA (Reflective QoS Attribute) from the QoS Flow's QoS profile to the NG-RAN on N2 reference
point.

NOTE 1: The SMF could have a timer to delay the sending of the removal of the RQA. This would avoid signalling
to the RAN in the case of new SDFs subject to Reflective QoS are bound to this QoS Flow in the
meantime.

When the 5GC determines to use Reflective QoS for a specific SDF, the SMF shall include an indication to use
Reflective QoS for this SDF in the corresponding SDF information provided to the UPF via N4 interface.

When the UPF receives this indication for an SDF, the UPF shall set the RQI in the encapsulation header on the N3
reference point for every DL packet corresponding to this SDF.

When an RQI is received by (R)AN in a DL packet on N3 reference point, the (R)AN shall indicate to the UE the QFI
and the RQI of that DL packet.

Upon reception of a DL packet with RQI:

- if a UE derived QoS rule with a Packet Filter corresponding to the DL packet does not already exist,

- the UE shall create a new UE derived QoS rule with a Packet Filter corresponding to the DL packet; and

- the UE shall start, for this UE derived QoS rule, a timer set to the RQ Timer value.

- otherwise,

- the UE shall restart the timer associated to this UE derived QoS rule; and

- if the QFI associated with the downlink packet is different from the QFI associated with the UE derived QoS
rule, the UE shall update the UE derived QoS rule identified by the UL packet filter derived from the DL
packet as described in clause 5.7.5.2 with the new QFI.

NOTE 2: Non-3GPP ANs does not need N2 signalling to enable Reflective QoS. Non 3GPP accesses are expected
to send transparently the QFI and RQI to the UE. If the UPF does not include the RQI, no UE derived
QoS rule will be generated. If RQI is included to assist the UE to trigger an update of the UE derived QoS
rule, the reception of PDU for a QFI restarts the RQ Timer.

Upon timer expiry associated with a UE derived QoS rule the UE deletes the corresponding UE derived QoS rule.

When the 5GC determines to no longer use Reflective QoS for a specific SDF, the SMF shall remove the indication to
use Reflective QoS in the corresponding SDF information provided to the UPF via N4 interface.

When the UPF receives this instruction for this SDF, the UPF shall no longer set the RQI in the encapsulation header on
the N3 reference point.

The UPF shall continue to accept the UL traffic of the SDF for the originally authorized QoS Flow for an operator
configurable time.

NOTE 3: This means that the detection and QoS enforcement instructions which were applied before the SMF
removed the indication to use Reflective QoS remain active in UL direction while the accounting of the
UL traffic is done according to the new instructions.

NOTE 4: The operator configurable time has to be at least as long as the RQ Timer value to ensure that no UL
packet would be dropped until the UE derived QoS rule is deleted by the UE.

5.7.6 Packet Filter Set

5.7.6.1 General
The Packet Filter Set is used in the QoS rule and the PDR to identify one or more packet (IP or Ethernet) flow(s).

3GPP
Release 16 150 3GPP TS 23.501 V16.4.0 (2020-03)

NOTE 1: A QoS Flow is characterised by PDR(s) and QoS rule(s) as described in clause 5.7.1.1.

NOTE 2: DL Packet Filter in a Packet Filter Set of a QoS rule may be needed by the UE e.g. for the purpose of IMS
precondition.

The Packet Filter Set may contain one or more Packet Filter(s). Every Packet Filter is applicable for the DL direction,
the UL direction or both directions.

NOTE 3: The Packet Filter in the Packet Filter Set of the default QoS rule that allows all UL traffic (also known as
match-all Packet Filter) is described in TS 24.501 [47].

There are two types of Packet Filter Set, i.e. IP Packet Filter Set, and Ethernet Packet Filter Set, corresponding to those
PDU Session Types.

5.7.6.2 IP Packet Filter Set

For IP PDU Session Type, the Packet Filter Set shall support Packet Filters based on at least any combination of:

- Source/destination IP address or IPv6 prefix.

- Source / destination port number.

- Protocol ID of the protocol above IP/Next header type.

- Type of Service (TOS) (IPv4) / Traffic class (IPv6) and Mask.

- Flow Label (IPv6).

- Security parameter index.

- Packet Filter direction.

NOTE 1: A value left unspecified in a Packet Filter matches any value of the corresponding information in a
packet.

NOTE 2: An IP address or Prefix may be combined with a prefix mask.

NOTE 3: Port numbers may be specified as port ranges.

5.7.6.3 Ethernet Packet Filter Set

For Ethernet PDU Session Type, the Packet Filter Set shall support Packet Filters based on at least any combination of:

- Source/destination MAC address.

- Ethertype as defined in IEEE 802.3.

- Customer-VLAN tag (C-TAG) and/or Service-VLAN tag (S-TAG) VID fields as defined in IEEE 802.1Q [98].

- Customer-VLAN tag (C-TAG) and/or Service-VLAN tag (S-TAG) PCP/DEI fields as defined in IEEE
802.1Q [98].

- IP Packet Filter Set, in the case that Ethertype indicates IPv4/IPv6 payload.

- Packet Filter direction.

NOTE 1: The MAC address may be specified as address ranges.

NOTE 2: A value left unspecified in a Packet Filter matches any value of the corresponding information in a
packet.

3GPP
Release 16 151 3GPP TS 23.501 V16.4.0 (2020-03)

5.8 User Plane Management

5.8.1 General
User Plane Function(s) handle the user plane path of PDU Sessions. 3GPP specifications support deployments with a
single UPF or multiple UPFs for a given PDU Session. UPF selection is performed by SMF. The details of UPF
selection is described in clause 6.3.3. The number of UPFs supported for a PDU Session is unrestricted.

For an IPv4 type PDU Session or an IPv6 type PDU Session without multi-homing or an IPv4v6 type PDU Session,
when multiple PDU Session Anchors are used (due to UL CL being inserted), only one IPv4 address and/or IPv6 prefix
is allocated for the PDU Session. For an IPv6 multi-homed PDU Session there are multiple IPv6 prefixes allocated for
the PDU Session as described in clause 5.6.4.3.

If the SMF had requested the UPF to proxy ARP or IPv6 Neighbour Solicitation for an Ethernet DNN, the UPF should
respond to the ARP or IPv6 Neighbour Solicitation Request, itself.

Deployments with one single UPF used to serve a PDU Session do not apply to the Home Routed case and may not
apply to the cases described in clause 5.6.4.

Deployments where a UPF is controlled either by a single SMF or multiple SMFs (for different PDU Sessions) are
supported.

UPF traffic detection capabilities may be used by the SMF in order to control at least following features of the UPF:

- Traffic detection (e.g. classifying traffic of IP type, Ethernet type, or unstructured type)

- Traffic reporting (e.g. allowing SMF support for charging).

- QoS enforcement (The corresponding requirements are defined in clause 5.7).

- Traffic routing (e.g. as defined in clause 5.6.4. for UL CL or IPv6 multi-homing).

5.8.2 Functional Description

5.8.2.1 General
This clause contains detailed functional descriptions for some of the functions provided by the UPF. It is described how
the SMF instructs it's corresponding UP function and which control parameters are used.

5.8.2.2 UE IP Address Management

5.8.2.2.1 General
The UE IP address management includes allocation and release of the UE IP address as well as renewal of the allocated
IP address, where applicable.

- If there is a matching URSP rule or a matching UE Local Configuration containing a PDU Session Type of
"IPv4", "IPv6" or "IPv4v6", then the UE shall set the requested PDU Session Type to the PDU Session Type
contained in the matching URSP rule or in the matching UE Local Configuration, if this PDU Session Type is
supported by the UE's IP stack capabilities. If there is no PDU Session Type value in the matching URSP rule or
in the matching UE Local Configuration, the UE shall not include the requested PDU Session Type in the PDU
Session Establishment Request message.

- Otherwise, if there is no matching URSP rule and no matching UE Local Configuration, the UE shall set the
requested PDU Session Type during the PDU Session Establishment procedure based on its IP stack capabilities
as follows:

- A UE which supports IPv6 and IPv4 shall set the requested PDU Session Type "IPv4v6".

- A UE which supports only IPv4 shall request for PDU Session Type "IPv4".

- A UE which supports only IPv6 shall request for PDU Session Type "IPv6".

3GPP
Release 16 152 3GPP TS 23.501 V16.4.0 (2020-03)

- When the IP version capability of the UE is unknown in the UE (as in the case when the MT and TE are
separated and the capability of the TE is not known in the MT), the UE shall request for PDU Session Type
"IPv4v6".

The SMF selects PDU Session Type of the PDU Session as follows:

- If the SMF receives a request with PDU Session Type set to "IPv4v6", the SMF selects either PDU Session Type
"IPv4" or "IPv6" or "IPv4v6" based on DNN configuration, subscription data and operator policies.

- If the SMF receives a request for PDU Session Type "IPv4" or "IPv6" and the requested IP version is supported
by the DNN the SMF selects the requested PDU Session type.

In its answer to the UE, the SMF may indicate the PDU Session Types not allowed for the combination of (DNN, S-
NNSAI). In this case, the UE shall not request another PDU Session to the same (DNN, S-NNSAI) for PDU Session
Types indicated as not allowed by the network. In the case that the initial PDU Session was established with a PDU
Session Type and the UE needs another single IP version PDU Session Type, the UE may initiate another PDU Session
Establishment procedure to this (DNN, S-NNSAI) in order to activate a second PDU session with that PDU Session
Type.

An SMF shall ensure that the IP address management procedure is based on the selected PDU Session Type. If IPv4
PDU Session Type is selected, an IPv4 address is allocated to the UE. Similarly, if IPv6 PDU Session type is selected,
an IPv6 prefix is allocated. If IPv4v6 PDU Session Type is selected, both an IPv4 address and an IPv6 prefix are
allocated. For Roaming case, the SMF in this clause refers to the SMF controlling the UPF(s) acting as PDU Session
Anchor. i.e. H-SMF in home routed case and V-SMF in local breakout case. For home routed case, V-SMF forwards
the PDU Session Type requested by UE to H-SMF without interpreting it. V-SMF sends back to UE the PDU Session
Type selected by H-SMF. The SMF shall process the UE IP address management related messages, maintain the
corresponding state information and provide the response messages to the UE.

The 5GC and UE support the following mechanisms:

a. During PDU Session Establishment procedure, the SMF sends the IP address to the UE via SM NAS signalling.
The IPv4 address allocation and/or IPv4 parameter configuration via DHCPv4 (according to RFC 2131 [9]) can
also be used once PDU Session is established.

b. /64 IPv6 prefix allocation shall be supported via IPv6 Stateless Auto-configuration according to RFC 4862 [10],
if IPv6 is supported. The details of Stateless IPv6 Address Autoconfiguration are described in clause 5.8.2.2.3.
IPv6 parameter configuration via Stateless DHCPv6 (according to RFC 3736 [14]) may also be supported.

For scenarios with RG connecting to 5GC, additional features for IPv6 address allocation and IPv6 prefix delegation are
supported, as described in TS 23.316 [84].

To allocate the IP address via DHCPv4, the UE may indicate to the network within the Protocol Configuration Options
that the UE requests to obtain the IPv4 address with DHCPv4, or obtain the IP address during the PDU Session
Establishment procedure. This implies the following behaviour both for static and dynamic address allocation:

- The UE may indicate that it requests to obtain an IPv4 address as part of the PDU Session Establishment
procedure. In such a case, the UE relies on the 5GC network to provide IPv4 address to the UE as part of the
PDU Session Establishment procedure.

- The UE may indicate that it requests to obtain the IPv4 address after the PDU Session Establishment procedure
by DHCPv4. That is, when the 5GC network supports DHCPv4 and allows that, it does not provide the IPv4
address for the UE as part of the PDU Session Establishment procedure. The network may respond to the UE by
setting the allocated IPv4 Address to 0.0.0.0. After the PDU Session Establishment procedure is completed, the
UE uses the connectivity with the 5GC and initiates the IPv4 address allocation on its own using DHCPv4.
However, if the 5GC network provides IPv4 address to the UE as part of the PDU Session Establishment
procedure, the UE should accept the IPv4 address indicated in the PDU Session Establishment procedure.

- If the UE sends no IP Address Allocation request, the SMF determines whether DHCPv4 is used between the UE
and the SMF or not, based on per DNN configuration.

If dynamic policy provisioning is deployed, and the PCF was not informed of the IPv4 address at PDU Session
Establishment procedure, the SMF shall inform the PCF about an allocated IPv4 address. If the IPv4 address is released,
the SMF shall inform the PCF about the de-allocation of an IPv4 address.

3GPP
Release 16 153 3GPP TS 23.501 V16.4.0 (2020-03)

In order to support DHCP based IP address configuration, the SMF shall act as the DHCP server towards the UE. The
PDU Session Anchor UPF does not have any related DHCP functionality. The SMF instructs the PDU Session Anchor
UPF serving the PDU Session to forward DHCP packets between the UE and the SMF over the user plane.

When DHCP is used for external data network assigned addressing and parameter configuration, the SMF shall act as
the DHCP client towards the external DHCP server. The UPF does not have any related DHCP functionality. In the case
of DHCP server on the external data network, the SMF instructs a UPF with N6 connectivity to forward DHCP packets
between the UE and the SMF and the external DHCP server over the user plane.

The 5GC may also support the allocation of a static IPv4 address and/or a static IPv6 prefix based on subscription
information in the UDM or based on the configuration on a per-subscriber, per-DNN basis and per-S-NSSAI.

If the static IP address/prefix is stored in the UDM, during PDU Session Establishment procedure, the SMF retrieves
this static IP address/prefix from the UDM. If the static IP address/prefix is not stored in the UDM subscription record,
it may be configured on a per-subscriber, per-DNN and per-S-NSSAI basis in the DHCP/DN-AAA server and the SMF
retrieves the IP address/prefix for the UE from the DHCP/DN-AAA server. This IP address/prefix is delivered to the
UE in the same way as a dynamic IP address/prefix. It is transparent to the UE whether the PLMN or the external data
network allocates the IP address and whether the IP address is static or dynamic.

For IPv4 or IPv6 or IPv4v6 PDU Session Type, during PDU Session Establishment procedure, if UE IP address/prefix
was not already allocated and provided to PCF, the SMF may receive a Subscribers IP Index from the PCF, the SMF
may use this to assist in selecting how the IP address is to be allocated when multiple allocation methods, or multiple
instances of the same method are supported. In the case of Home Routed roaming, the H-SMF may receive the IP index
from the H-PCF.

When Static IP addresses for a PDU session are not used, the actual allocation of the IP Address(es) for a PDU Session
may use any of the following mechanisms:

- The SMF allocates the IP address from a pool that corresponds to the PDU Session Anchor (UPF) that has been
selected

- The UE IP address is obtained from the UPF. In that case the SMF shall interact with the UPF via N4 procedures
to obtain a suitable IP address. The SMF provides the UPF with the necessary information allowing the UPF to
derive the proper IP address (e.g. the network instance).

- In the case that the UE IP address is obtained from the external data network, additionally, the SMF shall also
send the allocation, renewal and release related request messages to the external data network, i.e. DHCP/DN-
AAA server, and maintain the corresponding state information. The IP address allocation request sent to
DHCP/DN-AAA server may include the IP address pool ID to identify which range of IP address is to be
allocated. In this case the SMF is provisioned with separate IP address pool ID(s), and the mapping between IP
address pool ID and UPF Id, DNN, S-NSSAI, IP version. The provision is done by OAM or during the N4
Association Setup procedure.

A given IP address pool is controlled by a unique entity (either the SMF or the UPF or an external server). The IP
address managed by the UPF can be partitioned into multiple IP address pool partition(s), i.e. associated with multiple
IP address pool ID(s).

When the SMF is configured to obtain UE IP addresses from the UPF, the SMF may select a UPF based upon support
of this feature. The SMF determines whether the UPF supports this feature via NRF or via N4 capability negotiation
during N4 Association Setup. If no appropriate UPF support the feature, the SMF may allocate UE IP addresses, if
configured to do so.

The IP address/prefix is released by the SMF (e.g. upon release of the PDU Session), likewise the UPF considers that
any IP address it has allocated within a N4 session are released when this N4 session is released.

5.8.2.2.2 Routing rules configuration

When the UE has an IPv6 multi-homed PDU Session the UE selects the source IPv6 prefix according to IPv6 multi-
homed routing rules pre-configured in the UE or received from network. IPv6 multi-homed routing rules received from
the network have a higher priority than IPv6 multi-homed routing rules pre-configured in the UE

The SMF can generate the IPv6 multi-homed routing rules for a UE based on local configuration or dynamic PCC rules
received from the PCF as defined in TS 23.503 [45]. If dynamic PCC is deployed, the SMF generates the IPv6 multi-
home routing rules for a source IPv6 prefix based on the SDF Templates of those PCC rules which contain the DNAI

3GPP
Release 16 154 3GPP TS 23.501 V16.4.0 (2020-03)

corresponding to the newly assigned IPv6 prefix. The SMF can send IPv6 multi-homed routing rules to the UE to
influence the source IPv6 prefix selection in IPv6 Router Advertisement (RA) messages according to RFC 4191 [8] at
any time during the lifetime of the IPv6 multi-homed PDU Session. Such messages are sent via the UPF.

NOTE: For multiple IPv4 PDU Session and multiple IPv6 PDU Session cases, routing rule based PDU Session
selection is not specified in this Release of the specification.

5.8.2.2.3 The procedure of Stateless IPv6 Address Autoconfiguration

If Stateless IPv6 Address Autoconfiguration is used for IPv6 address allocation to the UE, after PDU Session
Establishment the UE may send a Router Solicitation message to the SMF to solicit a Router Advertisement message.
The SMF sends a Router Advertisement message (solicited or unsolicited) to the UE. The Router Advertisement
messages shall contain the IPv6 prefix.

After the UE has received the Router Advertisement message, it constructs a full IPv6 address via IPv6 Stateless
Address Autoconfiguration in accordance with RFC 4862 [10]. To ensure that the link-local address generated by the
UE does not collide with the link-local address of the UPF and the SMF, the SMF shall provide an interface identifier
(see RFC 4862 [10]) to the UE and the UE shall use this interface identifier to configure its link-local address. For
Stateless Address Autoconfiguration however, the UE can choose any interface identifier to generate IPv6 addresses,
other than link-local, without involving the network. However, the UE shall not use any identifiers defined in
TS 23.003 [19] as the basis for generating the interface identifier. For privacy, the UE may change the interface
identifier used to generate full IPv6 address, as defined in TS 23.221 [23] without involving the network. Any prefix
that the SMF advertises to the UE is globally unique. The SMF shall also record the relationship between the UE's
identity (SUPI) and the allocated IPv6 prefix. Because any prefix that the SMF advertises to the UE is globally unique,
there is no need for the UE to perform Duplicate Address Detection for any IPv6 address configured from the allocated
IPv6 prefix. Even if the UE does not need to use Neighbor Solicitation messages for Duplicate Address Detection, the
UE may, for example, use them to perform Neighbor Unreachability Detection towards the SMF, as defined in
RFC 4861 [54]. Therefore, the SMF shall respond with a Neighbor Advertisement upon receiving a Neighbor
Solicitation message from the UE.

In IPv6 multi-homing PDU session, SMF shall not allocate an interface identifier when a new IPv6 prefix allocated
corresponding to the new PDU Session Anchor.

The above IPv6 related messages (e.g. Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor
Advertisement) are transferred between the SMF and UE via the UPF(s). If the Control Plane CIoT 5GS Optimisation is
enabled for a PDU session, the above IPv6 related messages are transferred between the SMF and UE via the AMF after
PDU Session Establishment, see TS 23.502 [3] clause 4.3.2.2.1 and clause 4.3.2.2.2, using the Mobile Terminated Data
Transport in Control Plane CIoT 5GS Optimisation procedures.

5.8.2.3 Management of CN Tunnel Info

5.8.2.3.1 General
CN Tunnel Info is the Core Network address of a N3/N9 tunnel corresponding to the PDU Session. It comprises the
TEID and the IP address which is used by the UPF on the N3/N9 tunnel for the PDU Session.

The CN Tunnel Info allocation and release is performed by the UPF. The SMF shall indicate to the UPF when the UPF
is required to allocate/release CN Tunnel Info.

5.8.2.3.2 Void

5.8.2.3.3 Management of CN Tunnel Info in the UPF

The UPF shall manage the CN Tunnel Info space. When a new CN Tunnel Info is needed, the SMF shall request over
N4 the UPF to allocate CN Tunnel Info for the applicable N3/N9 reference point. In response, the UPF provides CN
Tunnel Info to the SMF. In the case of PDU Session Release or a UPF is removed from the user plane path of an
existing PDU Session, the SMF shall request UPF to release CN Tunnel Info for the PDU Session. If the corresponding
N4 Session is released the UPF releases the associated CN Tunnel Info.

3GPP
Release 16 155 3GPP TS 23.501 V16.4.0 (2020-03)

5.8.2.4 Traffic Detection

5.8.2.4.1 General
This clause describes the detection process at the UPF that identifies the packets belonging to a session, or a service
data flow.

The SMF is responsible for instructing the UP function about how to detect user data traffic belonging to a Packet
Detection Rule (PDR). The other parameters provided within a PDR describe how the UP function shall treat a packet
that matches the detection information.

5.8.2.4.2 Traffic Detection Information

The SMF controls the traffic detection at the UP function by providing detection information for every PDR.

For IPv4 or IPv6 or IPv4v6 PDU Session type, detection information is a combination of:

- CN tunnel info.

- Network instance.

- QFI.

- IP Packet Filter Set as defined in clause 5.7.6.2.

- Application Identifier: The Application ID is an index to a set of application detection rules configured in UPF.

For Ethernet PDU Session type, detection information is a combination of:

- CN tunnel info.

- Network instance.

- QFI.

- Ethernet Packet Filter Set as defined in clause 5.7.6.3.

In this Release of the specification for Unstructured PDU Session Type, the UPF does not perform-QoS Flow level
traffic detection for QoS enforcement.

Traffic detection information sent by the SMF to the UPF for a PDU Session may be associated with Network instance
for detection and routing of traffic over N6. In the case of IP PDU Session Type, Network Instances can e.g. be used by
the UPF for traffic detection and routing in the case of different IP domains or overlapping IP addresses. In the case of
Ethernet PDU Session Type, different Network Instances can e.g. be configured in the UPF with different ways to
handle the association between N6 and the PDU Sessions.

5.8.2.5 Control of User Plane Forwarding

5.8.2.5.1 General
The SMF controls user-plane packet forwarding for traffic detected by a PDR by providing a FAR with instructions to
the UPF, including:

- Forwarding operation information;

- Forwarding target information.

The details of the forwarding target and operation will depend on the scenario and is described below. The following
forwarding functionality is required by the UPF:

- Apply N3 /N9 tunnel related handling, i.e. encapsulation.

- Forward the traffic to/from the SMF, e.g. as described in Table 5.8.2.5.2-1.

- Forward the SM PDU DN Request Container from SMF to DN-AAA server

3GPP
Release 16 156 3GPP TS 23.501 V16.4.0 (2020-03)

- Forward the traffic according to locally configured policy for traffic steering.

- Forward the traffic according to N4 rules of a 5G VN group for 5G VN group communication.

Data forwarding between the SMF and UPF is transmitted on the user plane tunnel established on N4 interface, defined
in TS 29.244 [65].

5.8.2.5.2 Data forwarding between the SMF and UPF

Scenarios for data forwarding between the SMF and UPF are defined as below:

Table 5.8.2.5.1-1: Scenarios for data forwarding between the SMF and UPF

Scenario description Data forwarding direction

1 Forwarding of user-plane packets between the UPF to SMF
UE and the SMF e.g. DHCP signalling. SMF to UPF
2 Forwarding of packets between the SMF and the UPF to SMF
external DN e.g. with DN-AAA server SMF to UPF
3 Forwarding of packets subject to buffering in the UPF to SMF
SMF. SMF to UPF
4 Forwarding of End Marker Packets constructed SMF to UPF
by the SMF to a downstream node.
5 Forwarding of user data using Control Plane UPF to SMF
CIoT 5GS Optimisation SMF to UPF

5.8.2.5.3 Support of Ethernet PDU Session type

When configuring an UPF acting as PSA for an Ethernet PDU Session Type, the SMF may instruct the UPF to route the
traffic based on detected MAC addresses as follows.

- The UPF learns the MAC address(es) connected via N6 based on the source MAC addresses of the DL traffic
received on a N6 Network Instance.

- The UPF learns the MAC address(es) of UE(s) and devices conncted behind, if any, based on the source MAC
address contained within the UL traffic received on a PDU Session (N3/N9 interface).

- The UPF forwards DL unicast traffic (with a known destination address) on a PDU Session determined based on
the source MAC address(es) used by the UE for the UL traffic.

- The UPF forwards UL unicast traffic (with a known destination address) on a port (PDU Session or N6
interface) determined based on the source MAC address(es) learned beforehand.

- In the case of multicast and broadcast traffic (if the destination MAC address is a broadcast or multicast
address):- for DL traffic received by UPF on a N6 Network Instance the UPF should forward the traffic to
every DL PDU Session (corresponding to any N4 Session) associated with this Network Instance

- for uplink traffic received by UPF over a PDU session on a N3/N9 interface, the UPF should forward the
traffic to the N6 interface and downlink to every PDU session (except toward the one of the incoming traffic)
associated with the same N6 Network Instance

- for uplink and downlink unicast traffic received by UPF, if the destination MAC has not been learnt, the UPF
should forward the traffic to every PDU session associated with the same N6 Network Instance and towards the
N6 interface. In any case the traffic is not replicated on the PDU Session or the N6 interface of the incoming
traffic.

NOTE 1: The UPF can consider a PDU Session or a N6 interface to be active or inactive in order to avoid
forwarding loops. User data traffic is not sent on inactive PDU sessions or inactive N6 interface. This
release of the specification does not further specify how the UPF determines whether a PDU Session or
N6 interface is considered active or inactive.

NOTE 2: This release of the specification supports only a single N6 interface in a UPF associated with the N6
Network Instance.

- if the traffic is received with a VLAN ID, the above criteria apply only towards the N6 interface or PDU session
matching the same VLAN ID, unless the UPF is instructed to remove the VLAN ID in the incoming traffic.

3GPP
Release 16 157 3GPP TS 23.501 V16.4.0 (2020-03)

- if the destination MAC address of traffic refers to the same N6 interface or PDU session on which the traffic has
been received, the frame should be dropped.

In order to handle scenarios where a device behind a UE is moved from one UE to another UE, a MAC address is
considered as no longer associated with a UPF interface when the MAC address has not been detected as Source MAC
address in UL traffic for a pre-defined period of time or it has been detected under a different interface (PDU Session or
N6).

For ARP/IPv6 Neighbour Solicitation traffic, a SMF's request to respond to ARP/IPv6 Neighbour Solicitation based on
local cache information or to redirect such traffic from the UPF to the SMF overrules the traffic forwarding rules
described above.

NOTE 3: Local policies in UPF associated with the Network Instance can prevent local traffic switching in the UPF
between PDU Sessions either for unicast traffic only or for any traffic. In the case where UPF policies
prevent local traffic switching for any traffic (thus for broadcast/multicast traffic) some mechanism such
as responding to ARP/ND based on local cache information or local multicast group handling is needed to
ensure that upper layer protocol can run on the Ethernet PDU sessions.

The SMF may ask to get notified with the source MAC addresses used by the UE.

In order to request the UPF to act as defined above, the SMF may, for each PDU Session corresponding to a Network
Instance, set an Ethernet PDU Session Information in a DL PDR that identifies all (DL) Ethernet packets matching the
PDU session. Alternatively, for unicast traffic the SMF may provide UPF with dedicated forwarding rules related with
MAC addresses notified by the UPF.

5.8.2.6 Charging and Usage Monitoring Handling

5.8.2.6.1 General
The SMF shall support interfaces towards CHF and PCF. The SMF interacts with CHF and PCF based on information
received from other control plane NFs and user plane related information received from the UPF.

QoS Flow level, PDU Session level and subscriber related information remain at the SMF, and only usage information
is requested from the UPF.

5.8.2.6.2 Activation of Usage Reporting in UPF

Triggered by the PCC rules received from the PCF or preconfigured information available at SMF, as well as from the
CHF for online charging via Credit-Control session mechanisms, the SMF shall provide Usage Reporting Rules to the
UPF for controlling how usage reporting is performed.

The SMF shall request the report of the relevant usage information for Usage Monitoring, based on Monitoring Keys
and triggers which are specified in TS 23.503 [45]. Each Usage Reporting Rule requested for usage monitoring control
is associated with the PDR(s) whose traffic is to be accounted under this rule. The SMF shall generate the Usage
Reporting Rule for each Monitoring-key within the active PCC Rule(s), either preconfigured or received from the PCF
and also shall keep the mapping between them. Multiple Usage Reporting Rules may be associated with the same PDR.

The SMF shall request the report of the relevant usage information for offline and online charging, based on Charging
keys and additional triggers which are specified in TS 32.240 [41]. Each Usage Reporting Rule requested for offline or
online charging is associated with the PDR(s) whose traffic is to be accounted under this rule. The SMF shall generate
the Usage Reporting Rule for each Charging key and Sponsor Identity (if applicable) within the active PCC Rule(s),
either preconfigured or received from the PCF, and also shall keep the mapping between them. Multiple Usage
Reporting Rules may be associated with the same PDR.

The SMF function shall also provide reporting trigger events to the UPF for when to report usage information. The
reporting trigger events (e.g. triggers, threshold information etc.) shall be supported for the PDU Session level reporting
as well as on Rule level basis as determined by the SMF. The triggers may be provided as a volume, time or event to
cater for the different charging/usage monitoring models supported by the TS 23.503 [45] for usage monitoring and by
TS 32.240 [41] for offline and online charging. The SMF shall decide on the thresholds value(s) based on allowance
received from PCF, CHF or based on local configuration. Other parameters for instructing the UPF to report usage
information are defined in TS 29.244 [65].

3GPP
Release 16 158 3GPP TS 23.501 V16.4.0 (2020-03)

When the PCC Rule attribute Service Data flow handling while requesting credit (specified in TS 23.503 [45]) indicates
"non-blocking", the SMF shall request the report of the relevant usage information for the Charging key and Sponsor
Identity (if applicable) and provide a default threshold value to the UPF while waiting for the credit from the CHF.

In some cases, the same Usage Reporting Rule can be used for different purposes (for both usage monitoring and
charging), e.g. in the case that the same set of PDR(s), measurement method, trigger event, threshold, etc. apply.
Similarly a reported measurement can be used for different purposes by the SMF.

5.8.2.6.3 Reporting of Usage Information towards SMF

The UPF shall support reporting of usage information to the SMF. The UPF shall be capable to support reporting based
on different triggers, including:

- Periodic reporting with period defined by the SMF.

- Usage thresholds provided by the SMF.

- Report on demand received from the SMF.

The SMF shall make sure that the multiple granularity levels required by the reporting keys in the Usage Reporting
rules satisfy the following aggregation levels without requiring a knowledge of the granularity levels by the UPF:

- PDU Session level reporting;

- Traffic flow (for both charging and usage monitoring) level reporting as defined by the reporting keys in the
Usage Reporting Rule (see the description above).

Based on the mapping between Monitoring key and PCC rule stored at the SMF, the SMF shall combine the reported
information with session and subscriber related information which is available at the SMF, for Usage Monitoring
reporting over the corresponding Npcf interface (N7 reference point).

Based on the mapping between Charging key and Sponsor Identity (if applicable) and PCC rule stored at the SMF, the
SMF shall combine the reported information with session and subscriber related information which is available at the
SMF, for offline and online charging reporting over the corresponding charging interfaces.

This functionality is specified in TS 32.240 [41].

The usage information shall be collected in the UPF and reported to the SMF as defined in 5.8.2.6, based on Monitoring
Keys and triggers which are specified in TS 23.503 [45].

5.8.2.7 PDU Session and QoS Flow Policing

ARP is used for admission control (i.e. retention and pre-emption of the new QoS Flow). The value of ARP is not
required to be provided to the UPF.

For every QoS Flow, the SMF shall determine the transport level packet marking value (e.g. the DSCP in the outer IP
header) based on the 5QI, the Priority Level (if explicitly signalled) and optionally, the ARP priority level and provide
the transport level packet marking value to the UPF.

The SMF shall provide the Session-AMBR values of the PDU Session to the UPF so that the UPF can enforce the
Session-AMBR of the PDU Session across all Non-GBR QoS Flows of the PDU Session.

SMF shall provide the GFBR and MFBR value for each GBR QoS Flow of the PDU Session to the UPF. SMF may also
provide the Averaging window to the UPF, if Averaging window is not configured at the UPF or if it is different from
the default value configured at the UPF.

5.8.2.8 PCC Related Functions

5.8.2.8.1 Activation/Deactivation of predefined PCC rules

A predefined PCC rule is configured in the SMF.

The traffic detection filters, e.g. IP Packet Filter, required in the UP function can be configured either in the SMF and
provided to the UPF, as service data flow filter(s), or be configured in the UPF, as the application detection filter

3GPP
Release 16 159 3GPP TS 23.501 V16.4.0 (2020-03)

identified by an application identifier. For the latter case, the application identifier has to be configured in the SMF and
the UPF.

The traffic steering policy information can be only configured in the UPF, together with traffic steering policy
identifier(s), while the SMF has to be configured with the traffic steering policy identifier(s).

Policies for traffic handling in the UPF, which are referred by some identifiers corresponding to the parameters of a
PCC rule, can be configured in the UPF. These traffic handling policies are configured as predefined QER(s), FAR(s)
and URR(s).

When a predefined PCC rule is activated/deactivated by the PCF, SMF shall decide what information has to be provided
to the UPF to enforce the rule based on where the traffic detection filters (i.e. service data flow filter(s) or application
detection filter), traffic steering policy information and the policies used for the traffic handling in the UPF are
configured and where they are enforced:

- If the predefined PCC rule contains an application identifier for which corresponding application detection filters
are configured in the UPF, the SMF shall provide a corresponding application identifier to the UPF;

- If the predefined PCC rule contains traffic steering policy identifier(s), the SMF shall provide a corresponding
traffic steering policy identifier(s) to the UPF;

- If the predefined PCC rule contains service data flow filter(s), the SMF shall provide them to the UPF;

- If the predefined PCC rule contains some parameters for which corresponding policies for traffic handling in the
UPF are configured in the UPF, the SMF shall activate those traffic handling policies via their rule ID(s).

The SMF shall maintain the mapping between a PCC rule received over Npcf and the flow level PDR rule(s) used on
N4 interface.

5.8.2.8.2 Enforcement of Dynamic PCC Rules

The application detection filters required in the UPF can be configured either in the SMF and provided to the UPF as
the service data flow filter, or be configured in the UP function identified by an application identifier.

When receiving a dynamic PCC rule from the PCF which contains an application identifier and/or parameters for traffic
handling in the UPF:

- if the application detection filter is configured in the SMF, the SMF shall provide it in the service data flow filter
to the UPF, as well as parameters for traffic handling in the UPF received from the dynamic PCC rule;

- otherwise, the application detection filters is configured in UPF, the SMF shall provide to UPF with the
application identifier and the parameters for traffic handling in the UPF as required based on the dynamic PCC
rule.

The SMF shall maintain the mapping between a PCC rule received over Npcf and the flow level PDR(s) used on N4
interface.

5.8.2.8.3 Redirection
The uplink application's traffic redirection may be enforced either in the SMF (as specified in 5.8.2.5 Control of user
plane forwarding) or directly in the UPF. The redirect destination may be provided in the dynamic PCC rule or be
preconfigured, either in the SMF or in the UPF.

When receiving redirect information (redirection enabled/disabled and redirect destination) within a dynamic PCC rule
or being activated/deactivated by the PCF for the predefined redirection policies, SMF shall decide whether to provide
and what information to be provided to the UPF based on where the redirection is enforced and where the redirect
destination is acquired/preconfigured. When redirection is enforced in the UPF and the redirect destination is acquired
from the dynamic PCC rule or is configured in the SMF, SMF shall provide the redirect destination to the UPF. When
redirection is enforced in the SMF, SMF shall instruct the UPF to forward applicable user plane traffic to the SMF.

3GPP
Release 16 160 3GPP TS 23.501 V16.4.0 (2020-03)

5.8.2.8.4 Support of PFD Management

The NEF (PFDF)shall provide PFD(s) to the SMF on the request of SMF (pull mode) or on the request of PFD
management from NEF (push mode), as described in TS 23.503 [45]. The SMF shall provide the PFD(s) to the UPF,
which have active PDR(s) with the Application identifier corresponding to the PFD(s).

The SMF supports the procedures in clause 4.4.3.5 of TS 23.502, for management of PFDs. PFD(s) is cached in the
SMF, and the SMF maintains a caching timer associated to the PFD(s). When the caching timer expires and there's no
active PCC rule that refers to the corresponding Application identifier, the SMF informs the UPF to remove the PFD(s)
identified by the Application identifier using the PFD management message.

When a PDR is provided for an Application identifier corresponding to the PFD(s) that are not already provided to the
UPF, the SMF shall provide the PFD(s) to the UPF (if there are no PFD(s) cached, the SMF retrieves them from the
NEF (PFDF) as specified in TS 23.503 [45]). When any update of the PFD(s) is received from NEF (PFDF) by SMF
(using "push" or "pull" mode), and there are still active PDRs in UPF for the Application ID, the SMF shall provision
the updated PFD set corresponding to the Application identifier to the UPF using the PFD management message.

NOTE 1: SMF can assure not to overload N4 signalling while managing PFD(s) to the UPF, e.g. forwarding the
PFD(s) to the right UPF where the PFD(s) is enforced.

When the UPF receives the updated PFD(s) from either the same or different SMF for the same Application identifier,
the latest received PFD(s) shall overwrite any existing PFD(s) stored in the UPF.

NOTE 2: For the case a single UPF is controlled by multiple SMFs, the conflict of PFD(s) corresponding to the
same application identifier provided by different SMF can be avoided by operator enforcing a well-
planned NEF (PFDF) and SMF/UPF deployment.

When a PFD is removed/modified and this PFD was used to detect application traffic related to an application identifier
in a PDR of an N4 session and the UPF has reported the application start to the SMF as defined in clause 4.4.2.2 of
TS 23.502 [3] for the application instance corresponding to this PFD, the UPF shall report the application stop to the
SMF for the corresponding application instance identifier if the removed/modified PFD in UPF results in that the stop
of the application instance is not being able to be detected.

If the PFDs are managed by local O&M procedures, PFD retrieval is not used; otherwise, the PFDs retrieved from NEF
(PFDF) override any PFDs pre-configured in the SMF. When all the PFDs retrieved from the NEF (PFDF) for an
application identifier are removed, the pre-configured PFDs are used. The SMF shall provide either the PFDs retrieved
from NEF (PFDF) or the pre-configured PFDs for an application identifier to the UPF.

5.8.2.9 Functionality of Sending of "End marker"

5.8.2.9.0 Introduction
Sending of "end marker" is a functionality which involve SMF and UPF in order to assist the reordering function in the
Target RAN. As part of the functionality, constructing of end marker packets can either be done in the SMF or in the
UPF, as described in clauses 5.8.2.9.1 and 5.8.2.9.2. Whether constructing of end marker packets is performed by SMF
or UPF is determined by network configuration.

5.8.2.9.1 UPF Constructing the "End marker" Packets

In the case of inter NG-RAN Handover procedure without UPF change, SMF shall indicate the UPF to switch the N3
path(s) by sending an N4 Session Modification Request message with the new AN Tunnel Info of NG RAN and in
addition, provide an indication to the UPF to send the end marker packet(s) on the old N3 user plane path.

On receiving this indication, the UPF shall construct end marker packet(s) and send it for each N3 GTP-U tunnel
towards the source NG RAN after sending the last PDU on the old path.

In the case of inter NG-RAN Handover procedure with change of the UPF terminating N3, the SMF shall request the
UPF with N9 reference point to the UPF terminating N3 to switch the N9 user plane path(s) by sending an N4 Session
Modification Request message (N4 session ID, new CN Tunnel Info of the UPF terminating N3) and in addition,
provide an indication to this UPF to send the end marker packet(s) on the old path.

On receiving this indication, the UPF shall construct end marker packet(s) and send it for each N9 GTP-U tunnel
towards the source UPF after sending the last PDU on the old path.

3GPP
Release 16 161 3GPP TS 23.501 V16.4.0 (2020-03)

On receiving the end marker packet(s) on N9 GTP-U tunnel, source UPF shall forward the end marker packet(s) and
send it for each N3 GTP-U tunnel towards the source NG RAN.

5.8.2.9.2 SMF Constructing the "End marker" Packets

UPF referred in this clause is the UPF terminates N3 reference point.

It is assumed that the PDU Session for the UE comprises of an UPF that acts as a PDU Session Anchor and an
intermediate UPF terminating N3 reference point at the time of this Handover procedure.

In the case of inter NG-RAN Handover procedure without UPF change, SMF shall indicate the UPF to switch the N3
path(s) by sending an N4 Session Modification Request message (N4 session ID, new AN Tunnel Info of NG RAN).
After sending the last PDU on the old path, UPF shall replace the old AN Tunnel Info with the new one and responds
with an N4 Session Modification Response message to acknowledge the success of path switch.

When the path switch is finished, SMF constructs the end marker packet(s) and sends it to the UPF. UPF then forwards
the packet(s) to the source NG RAN.

In the case of inter NG-RAN Handover procedure with UPF change, SMF shall indicate the PSA UPF to switch the N9
user plane path(s) by sending an N4 Session Modification Request message (N4 session ID, new CN Tunnel Info of
UPF). After sending the last PDU on the old N9 path, PSA UPF shall replace the old CN Tunnel Info with the new one
and responds with an N4 Session Modification Response message to acknowledge the success of path switch.

When the path switch is finished, SMF constructs the end marker packet(s) and sends it to PSA UPF. PSA UPF then
forwards the packet(s) to the source UPF.

5.8.2.10 UP Tunnel Management

5GC shall support per PDU Session tunnelling on N3 between (R)AN and UPF and N9 between UPFs. If there exist
more than one UPF involved for the PDU Session, any tunnel(s) between UPFs (e.g. in the case of two UPFs, between
the UPF that is an N3 terminating point and the UPF for PDU Session Anchor) remains established when a UE enters
CM-IDLE state. In the case of downlink data buffering by UPF, when mobile terminated (MT) traffic arrives at the
PDU Session Anchor UPF, it is forwarded to the UPF which buffer the data packet via N9 tunnel. See clause 5.8.3 for
more details on UPF buffering. In the case of Home Routed roaming, the SMF in HPLMN is not aware of the UP
activation state of a PDU Session.

When the UP connection of the PDU Session is deactivated, the SMF may release the UPF of N3 terminating point. In
that case the UPF (e.g. the Branching Point/UL CL or PDU Session Anchor) connecting to the released UPF of N3
terminating point will buffer the DL packets. Otherwise, when the UPF with the N3 connection is not released, this UPF
will buffer the DL packets.

When the UP connection of the PDU Session is activated due to a down-link data arrived and a new UPF is allocated to
terminate the N3 connection, a data forwarding tunnel between the UPF that has buffered packets and the newly
allocated UPF is established, so that the buffered data packets are transferred from the old UPF that has buffered
packets to the newly allocated UPF via the data forwarding tunnel.

For a PDU Session whose the UP connection is deactivated and the SMF has subscribed the location change
notification, when the SMF is notified of UE's new location from the AMF and detects that the UE has moved out of the
service area of the existing intermediate UPF, the SMF may decide to maintain the intermediate UPF, remove the
established tunnel between UPFs (in the case of removal of the intermediate UPF) or reallocate the tunnel between
UPFs (in the case of reallocation of the intermediate UPF).

5.8.2.11 Parameters for N4 session management

5.8.2.11.1 General
These parameters are used by SMF to control the functionality of the UPF as well as to inform SMF about events
occurring at the UPF.

The N4 session management procedures defined in clause 4.4.1 of TS 23.502 [3] will use the relevant parameters in the
same way for all N4 reference points: the N4 Session Establishment procedure as well as the N4 Session Modification
procedure provide the control parameters to the UPF, the N4 Session Release procedure removes all control parameters

3GPP
Release 16 162 3GPP TS 23.501 V16.4.0 (2020-03)

related to an N4 session, and the N4 Session Level Reporting procedure informs the SMF about events related to the
PDU Session that are detected by the UPF.

The parameters over N4 reference point provided from SMF to UPF comprises an N4 Session ID and may also contain:

- Packet Detection Rules (PDR) that contain information to classify traffic (PDU(s)) arriving at the UPF;

- Forwarding Action Rules (FAR) that contain information on whether forwarding, dropping or buffering is to be
applied to a traffic identified by PDR(s);

- Multi-Access Rules (MAR) that contain information on how to handle traffic steering, switching and splitting for
a MA PDU Session;

- Usage Reporting Rules (URR) contains information that defines how traffic identified by PDR(s) shall be
accounted as well as how a certain measurement shall be reported;

- QoS Enforcement Rules (QER), that contain information related to QoS enforcement of traffic identified by
PDR(s);

- Session Reporting Rules (SRR) that contain information to request the UP function to detect and report events
for a PDU session that are not related to specific PDRs of the PDU session or that are not related to traffic usage
measurement.

- Trace Requirements;

- Port Management Information Container in 5GS;

- Bridge Information.

The N4 Session ID is assigned by the SMF and uniquely identifies an N4 session.

If the UPF indicated support of Trace, the SMF may activate a trace session during a N4 Session Establishment or a N4
Session Modification procedure. In that case it provides Trace Requirements to the UPF. The SMF may deactivate an
on-going trace session using a N4 Session Modification procedure. There shall be at most one trace session activated
per N4 Session at a time.

For the MA PDU Session, the SMF may add an additional access tunnel information during an N4 Session Modification
procedure by updating MAR with addition of an FAR ID which refers to an FAR containing the additional access
tunnel information for the MA PDU session for traffic steering in the UPF. For the MA PDU Session, the SMF may
request Access Availability report per N4 Session, during N4 Session Establishment procedure or N4 Session
Modification procedure.

A N4 Session may be used to control both UPF and NW-TT behaviour in the UPF. A N4 session support and enable
exchange of TSN bridge configuration between the SMF and the UPF:

- Information that the SMF needs for bridge management (clause 5.8.2.11.9);

- Information that 5GS transparently relays between the AF the NW-TT: transparent Port Management
Information Container.

When a N4 Session related with bridge management is established, the UPF allocates a dedicated port number for the
DS-TT side of the PDU Session. The UPF then provides to the SMF following configuration parameters for the N4
Session:

- NW-TT port number;

- DS-TT port number.

After the N4 session has been established, the SMF and UPF may at any time exchange transparent bridge Port
Management Information Container over a N4 session.

5.8.2.11.2 N4 Session Context

N4 Session Context is identified by an N4 Session ID. An N4 Session Context is generated by SMF and UPF
respectively to store the parameters related to an N4 session, including N4 session ID, all PDRs, URRs, QERs and
FARs or MARs used for this N4 session.

3GPP
Release 16 163 3GPP TS 23.501 V16.4.0 (2020-03)

5.8.2.11.3 Packet Detection Rule

The following table describes the Packet Detection Rule (PDR) containing information required to classify a packet
arriving at the UPF. Every PDR is used to detect packets in a certain transmission direction, e.g. UL direction or DL
direction.

3GPP
Release 16 164 3GPP TS 23.501 V16.4.0 (2020-03)

Table 5.8.2.11.3-1: Attributes within Packet Detection Rule

3GPP
Release 16 165 3GPP TS 23.501 V16.4.0 (2020-03)

Attribute Description Comment

N4 Session ID Identifies the N4 session associated to this PDR.
NOTE 5.
Rule ID Unique identifier to identify this rule.
Precedence Determines the order, in which the detection
information of all rules is applied.
Packet Source Contains the values "access side", "core side", Combination of UE IP address
interface "SMF", "N6-LAN", "5G VN internal". (together with Network instance, if
necessary), CN tunnel info,
Detection UE IP address One IPv4 address and/or one IPv6 prefix with prefix packet filter set, application ID,
length (NOTE 3). Ethernet PDU Session
Information. Network Identifies the Network instance associated with the Information and QFI are used for
NOTE 4. instance incoming packet. traffic detection.
(NOTE 1) Source interface identifies the
CN tunnel info CN tunnel info on N3, N9 interfaces, i.e. F-TEID. interface for incoming packets
Packet Filter Details see clause 5.7.6. where the PDR applies, e.g. from
Set access side (i.e. up-link),
Application ID from core side (i.e. down-link),
QoS Flow ID Contains the value of 5QI or non-standardized QFI. from SMF, from N6-LAN (i.e. the
Ethernet PDU Refers to all the (DL) Ethernet packets matching an DN or the local DN), or from "5G
Session Ethernet PDU session, as further described in VN internal" (i.e. local switch).
Information clause 5.6.10.2 and in TS 29.244 [65].
Framed Route Refers to Framed Routes defined in clause 5.6.14. Details like all the combination
Information possibilities on N3, N9 interfaces
are left for stage 3 decision.
Packet Packet Contains UE address indication or N19/N6
replication replication skip indication. If the packet matches the packet
and information replication skip information, i.e., source address of
detection NOTE 7 the packet is the UE address or the packet has
carry on been received on the interface in the packet
information replication skip information, the UP function neither
creates a copy of the packet nor applies the
corresponding processing (i.e., FAR, QER, URR).
Otherwise the UPF performs a copy and applies the
corresponding processing (i.e., FAR, QER, URR).
NOTE 6 Carry on Instructs the UP function to continue the packet
indication detection process, i.e., lookup of the other PDRs
without higher precedence.
Outer header removal Instructs the UP function to remove one or more Any extension header shall be
outer header(s) (e.g. IP+UDP+GTP, IP + possibly stored for this packet.
UDP, VLAN tag), from the incoming packet.
Forwarding Action Rule ID The Forwarding Action Rule ID identifies a
(NOTE 2) forwarding action that has to be applied.
Multi-Access Rule ID The Multi-Access Rule ID identifies an action to be
(NOTE 2) applied for handling forwarding for a MA PDU
Session.
List of Usage Reporting Rule Every Usage Reporting Rule ID identifies a
ID(s) measurement action that has to be applied.
List of QoS Enforcement Rule Every QoS Enforcement Rule ID identifies a QoS
ID(s) enforcement action that has to be applied.
NOTE 1: Needed e.g. if:
- UPF supports multiple DNN with overlapping IP addresses;
- UPF is connected to other UPF or AN node in different IP domains.
- UPF "local switch", N6-based forwarding and N19 forwarding is used for different 5G LAN groups.
NOTE 2: Either a FAR ID or a MAR ID is included, not both.
NOTE 3: The SMF may provide an indication asking the UPF to allocate one IPv4 address and/or IPv6 prefix. When
asking to provide an IPv6 Prefix the SMF provides also an IPv6 prefix length.
NOTE 4: When in the architecture defined in clause 5.34, a PDR is sent over N16a from SMF to I-SMF, the Packet
Detection Information may indicate that CN tunnel info is to be locally determined. This is further defined in
clause 5.34.6.
NOTE 5: In the architecture defined in clause 5.34, the rules exchanged between I-SMF and SMF are not associated with
a N4 Session ID but are associated with a N16a association.
NOTE 6: Needed in the case of support for broadcast/multicast traffic forwarding using packet replication with SMF-
provided PDRs and FARs as described in clause 5.8.2.13.3.2.
NOTE 7: Needed in the case of packet replication with SMF-provided PDRs and FARs as described in
clause 5.8.2.13.3.2, to prevent UPF from sending the broadcast/multicast packets back to the source UE or
source N19/N6.

3GPP
Release 16 166 3GPP TS 23.501 V16.4.0 (2020-03)

5.8.2.11.4 QoS Enforcement Rule

The following table describes the QoS Enforcement Rule (QER) that defines how a packet shall be treated in terms of
bit rate limitation and packet marking for QoS purposes. All Packet Detection Rules that refer to the same QER share
the same QoS resources, e.g. MFBR.

3GPP
Release 16 167 3GPP TS 23.501 V16.4.0 (2020-03)

Table 5.8.2.11.4-1: Attributes within QoS Enforcement Rule

3GPP
Release 16 168 3GPP TS 23.501 V16.4.0 (2020-03)

Attribute Description Comment

N4 Session ID Identifies the N4 session associated to this QER
Rule ID Unique identifier to identify this information.
QoS Enforcement Rule An identity allowing the UP function to correlate Is used to correlate QoS
correlation ID (NOTE 1) multiple Sessions for the same UE and APN. Enforcement Rules for APN-
AMBR enforcement.
Gate status UL/DL Instructs the UP function to let the flow pass or Values are: open, close, close
to block the flow. after measurement report (for
termination action "discard").
Maximum bitrate The uplink/downlink maximum bitrate to be This field may e.g. contain any
enforced for the packets. one of:
- APN-AMBR (for a QER that
is referenced by all relevant
Packet Detection Rules of all
PDN Connections to an APN)
(NOTE 1).
- Session-AMBR (for a QER
that is referenced by all
relevant Packet Detection
Rules of the PDU Session)
- QoS Flow MBR (for a QER
that is referenced by all
Packet Detection Rules of a
QoS Flow)
- SDF MBR (for a QER that is
referenced by the
uplink/downlink Packet
Detection Rule of a SDF)
- Bearer MBR (for a QER that
is referenced by all relevant
Packet Detection Rules of a
bearer) (NOTE 1).
Guaranteed bitrate The uplink/downlink guaranteed bitrate This field contains:
authorized for the packets. - QoS Flow GBR (for a QER
that is referenced by all
Packet Detection Rules of a
QoS Flow)
- Bearer GBR (for a QER that
is referenced by all relevant
Packet Detection Rules of a
bearer) (NOTE 1).
Averaging window The time duration over which the Maximum and This is for counting the packets
Guaranteed bitrate shall be calculated. received during the time duration.
Down-link flow level marking Flow level packet marking in the downlink. For UPF, this is for controlling the
setting of the RQI in the
encapsulation header as
described in clause 5.7.5.3.
QoS Flow ID QoS Flow ID to be inserted by the UPF. The UPF inserts the QFI value in
the tunnel header of outgoing
packets.
Paging Policy Indicator Indicates the PPI value the UPF is required to PPI applies only for DL traffic.
insert in outgoing packets (see clause 5.4.3.2). The UPF inserts the PPI in the
outer header of outgoing PDU.

3GPP
Release 16 169 3GPP TS 23.501 V16.4.0 (2020-03)

Packet rate (NOTE 1) Number of packets per time interval to be This field contains any one of:
enforced. - downlink packet rate for
Serving PLMN Rate Control
(the QER is referenced by all
PDRs of the UE belonging to
PDN connections using CIoT
EPS Optimisations as
described in TS 23.401 [26]).
- uplink/downlink packet rate
for APN Rate Control (the
QER is referenced by all
PDRs of the UE belonging to
PDN connections to the
same APN using CIoT EPS
Optimisations as described in
TS 23.401 [26]).
NOTE 1: This parameter is only used for interworking with EPC.

5.8.2.11.5 Usage Reporting Rule

The following table describes the Usage Reporting Rule (URR) that defines how a packet shall be accounted as well as
when and how to report the measurements.

3GPP
Release 16 170 3GPP TS 23.501 V16.4.0 (2020-03)

Table 5.8.2.11.5-1: Attributes within Usage Reporting Rule

3GPP
Release 16 171 3GPP TS 23.501 V16.4.0 (2020-03)

Attribute Description Comment

N4 Session ID Identifies the N4 session associated to this URR
Rule ID Unique identifier to identify this information. Used by UPF when reporting
usage.
Reporting triggers One or multiple of the events can be activated Applicable events include:
for the generation and reporting of the usage - Start/stop of traffic detection
report. with/without application
instance identifier and
deduced SDF filter reporting;
Deletion of last PDR for a
URR; Periodic measurement
threshold reached;
Volume/Time/Event
measurement threshold
reached; Immediate report
requested; Measurement of
incoming UL traffic;
Measurement of discarded
DL traffic; MAC address
reporting in the UL traffic;
unknown destination MAC/IP
address.
Periodic measurement Defines the point in time for sending a periodic This allows generation of periodic
threshold report for this URR (e.g. timeofday). usage report for e.g. offline
charging.
It can also be used for realizing
the Monitoring time of the usage
monitoring feature.
It can also be used for realizing
the Quota-Idle-Timeout, i.e. to
enable the CP function to check
whether any traffic has passed
during this time.
Volume measurement Value in terms of uplink and/or downlink and/or
threshold total byte-count when the measurement report is
to be generated.
Time measurement threshold Value in terms of the time duration (e.g. in
seconds) when the measurement report is to be
generated.
Event measurement Number of events (identified according to a
threshold locally configured policy) after which the
measurement report is to be generated.
Inactivity detection time Defines the period of time after which the time Timer corresponding to this
measurement shall stop, if no packets are duration is restarted at the end of
received. each transmitted packet.
Event based reporting Points to a locally configured policy which is
identifies event(s) trigger for generating usage
report.
Linked URR ID(s) Points to one or more other URR ID. This enables the generation of a
combined Usage Report for this
and other URRs by triggering
their reporting. See
clause 5.2.2.4, TS 29.244 [65].
Measurement Method Indicates the method for measuring the network
resources usage, i.e. the data volume, duration,
combined volume/duration, or event.
Measurement information Indicates specific conditions to be applied for It is used to request:
measurements - measurement before QoS
enforcement, and/or
- to pause or set to active a
measurement as for the
Pause of charging described
in clause 4.4.4 of
TS 23.502 [3], and/or
- to request reduced reporting
for application start/stop
events.

3GPP
Release 16 172 3GPP TS 23.501 V16.4.0 (2020-03)

5.8.2.11.6 Forwarding Action Rule

The following table describes the Forwarding Action Rule (FAR) that defines how a packet shall be buffered, dropped
or forwarded, including packet encapsulation/decapsulation and forwarding destination.

3GPP
Release 16 173 3GPP TS 23.501 V16.4.0 (2020-03)

Table 5.8.2.11.6-1: Attributes within Forwarding Action Rule

3GPP
Release 16 174 3GPP TS 23.501 V16.4.0 (2020-03)

Attribute Description Comment

N4 Session ID Identifies the N4 session associated to this FAR. NOTE 9.
Rule ID Unique identifier to identify this information.
Action Identifies the action to apply to the packet Indicates whether the packet is
to be forwarded, duplicated,
dropped or buffered.
When action indicates forwarding
or duplicating, a number of
additional attributes are included
in the FAR.
For buffering action, a Buffer
Action Rule is also included and
the action can also indicate that
a notification of the first buffered
and/or a notification of first
discarded packet is requested
(see clause 5.8.3.2).
Network instance Identifies the Network instance associated with NOTE 8.
(NOTE 2) the outgoing packet (NOTE 1).
Destination interface Contains the values "access side", "core side", Identifies the interface for
(NOTE 3) "SMF", "N6-LAN", "5G VN internal" or "5G VN outgoing packets towards the
(NOTE 7) N19". access side (i.e. down-link), the
core side (i.e. up-link), the SMF,
the N6-LAN (i.e. the DN or the
local DN), to 5G VN internal (i.e.
local switch), or to 5G VN N19
(i.e. N19 interface).
Outer header creation Instructs the UP function to add an outer header Contains the CN tunnel info, N6
(NOTE 3) (e.g. IP+UDP+GTP, VLAN tag), IP + possibly tunnel info or AN tunnel info of
UDP to the outgoing packet. peer entity (e.g. NG-RAN,
another UPF, SMF, local access
to a DN represented by a DNAI)
(NOTE 8).
Any extension header stored for
this packet shall be added.
The time stamps should be
added in the GTP-U header if
QoS Monitoring is enabled for
the traffic corresponding to the
PDR(s).
Send end marker packet(s) Instructs the UPF to construct end marker This parameter should be sent
(NOTE 2) packet(s) and send them out as described in together with the "outer header
clause 5.8.1. creation" parameter of the new
CN tunnel info.
Transport level marking Transport level packet marking in the uplink and NOTE 8.
(NOTE 3) downlink, e.g. setting the DiffServ Code Point.
Forwarding policy Reference to a preconfigured traffic steering Contains one of the following
(NOTE 3) policy or http redirection (NOTE 4). policies identified by a TSP ID:
- an N6-LAN steering policy to
steer the subscriber's traffic to
the appropriate N6 service
functions deployed by the
operator, or
- a local N6 steering policy to
enable traffic steering in the
local access to the DN
according to the routing
information provided by an AF
as described in clause 5.6.7.
or a Redirect Destination and
values for the forwarding
behaviour (always, after
measurement report (for
termination action "redirect")).
Request for Proxying in UPF Indicates that the UPF shall perform ARP Applies to the Ethernet PDU
proxying and / or IPv6 Neighbour Solicitation Session type.
Proxying as specified in clause 5.6.10.2.

3GPP
Release 16 175 3GPP TS 23.501 V16.4.0 (2020-03)

Container for header Contains information to be used by the UPF for Only relevant for the uplink
enrichment header enrichment. direction.
(NOTE 2)
Buffering Action Rule Reference to a Buffering Action Rule ID defining
(NOTE 5) the buffering instructions to be applied by the
UPF
(NOTE 6)
NOTE 1: Needed e.g. if:
- UPF supports multiple DNN with overlapping IP addresses;
- UPF is connected to other UPF or NG-RAN node in different IP domains;
- UPF "local switch" and N19 forwarding is used for different 5G LAN groups.
NOTE 2: These attributes are required for FAR action set to forwarding.
NOTE 3: These attributes are required for FAR action set to forwarding or duplicating.
NOTE 4: The TSP ID is preconfigured in the SMF, and included in the FAR according to the description in clauses
5.6.7 and 6.1.3.14 of 23.503 [45] for local N6 steering and 6.1.3.14 of 23.503 [45] for N6-LAN steering. The
TSP ID action is enforced before the Outer header creation actions.
NOTE 5: This attribute is present for FAR action set to buffering.
NOTE 6: The buffering action rule is created by the SMF and associated with the FAR in order to apply a specific
buffering behaviour for DL packets requested to be buffered, as described in clause 5.8.3 and clause 5.2.4
in TS 29.244 [65].
NOTE 7: The use of "5G VN internal" instructs the UPF to send the packet back for another round of ingress
processing using the active PDRs pertaining to another N4 session of the same 5G VN group.
NOTE 8: When in architectures defined in clause 5.34, a FAR is sent over N16a from SMF to I-SMF, the FAR sent
by the SMF may indicate that the I-SMF is to locally determine the value of this attribute in order to build the
N4 FAR rule sent to the actual UPF controlled by the I-SMF. This is further defined in clause 5.34.6.
NOTE 9: In the architecture defined in clause 5.34, the rules exchanged between I-SMF and SMF are not associated
with a N4 Session ID but are associated with a N16a association.

5.8.2.11.7 Usage Report generated by UPF

The UPF sends the usage report to inform the SMF about the measurement of an active URR or about the detection of
application traffic of an active Packet Detection Rule, or about one or both accesses becomes available or unavailable in
a MA-PDU session. For each URR, the usage report may be generated repeatedly, i.e. as long as any one of the valid
event triggers applies. A final usage report is sent for a URR when it is no longer active, i.e. either the URR is removed
or all the references to this URR in any of the Packet Detection Rules belonging to the N4 session.

Following attributes can be included in the usage report:

3GPP
Release 16 176 3GPP TS 23.501 V16.4.0 (2020-03)

Table 5.8.2.11.7-1: Attributes within Usage Report

Attribute Description Comment

N4 Session ID Uniquely identifies a session. Identifies the N4 session
associated to this Usage Report
Rule ID Uniquely identifies the Packet Detection Rule or Packet Detection Rule is only
Usage Reporting Rule within a session which indicated when Reporting trigger
triggered the report. is Detection of 1st DL packet for
a QoS Flow or Start/stop of traffic
detection.
Usage Reporting Rule is
indicated for all other Reporting
triggers.
Reporting trigger Identifies the trigger for the usage report. Applicable values are:
Detection of 1st DL packet for a
QoS Flow; Start/stop of traffic
detection with/without application
instance identifier and deduced
SDF filter reporting; Deletion of
last PDR for a URR; Periodic
measurement threshold reached;
Volume/Time/Event
measurement threshold reached;
Immediate report requested;
Measurement of incoming UL
traffic; Measurement of discarded
DL traffic; MAC address reporting
in the UL traffic; reporting of
unknown destination MAC/IP
address.
Start time Provides the timestamp, in terms of absolute Not sent when Reporting trigger
time, when the collection of the information is Start/stop of traffic detection.
provided within Usage-Information is started.
End time Provides the timestamp, in terms of absolute Not sent when Reporting trigger
time, when the information provided within is Start/stop of traffic detection.
Usage-Information is generated.
Measurement information Defines the measured volume/time/events for Details refer to TS 29.244 [65].
this URR.

5.8.2.11.8 Multi-Access Rule

The following table describes the Multi-Access Rule (MAR) that includes the association to the two FARs for both
3GPP access and non-3GPP access in the case of supporting ATSSS.

3GPP
Release 16 177 3GPP TS 23.501 V16.4.0 (2020-03)

Table 5.8.2.11.8-1: Attributes within Multi-Access Rule

Attribute Description Comment

N4 Session ID Identifies the N4 session associated to this
MAR.
Rule ID Unique identifier to identify this rule.
Steering functionality Indicates the applicable traffic steering
functionality:
Values "MPTCP functionality", "ATSSS-LL
functionality".
Steering mode Values "Active-Standby", "Smallest Delay",
"Load Balancing" or "Priority-based".
Per-Access Forwarding Action The Forwarding Action Rule ID identifies a
Forwarding Rule ID forwarding action that has to be applied.
Action Weight Identifies the weight for the FAR if steering
The weights for all FARs need to
information mode is "Load Balancing" sum up to 100
(NOTE 1) Priority Values "Active or Standby" or "High or Low"
"Active or Standby" for "Active-
for the FAR Standby" steering mode and
"High or Low" for "Priority-based"
steering mode
List of Usage Every Usage Reporting Rule ID identifies a This enables the SMF to request
Reporting Rule measurement action that has to be applied. separate usage reports for
ID(s) different FARs (i.e. different
accesses)
NOTE 1: The Per-Access Forwarding Action information is provided per access type (i.e. 3GPP access or Non-
3GPP access).

5.8.2.11.9 Bridge Management Information

The following table describes the Bridge Management Information (BMI) that includes the information required to
configure a 5GS logical bridge for TSC PDU Sessions.

Table 5.8.2.11.9-1: Bridge Management Information

Attribute Description Comment

NW-TT Port Number Port Number allocated by the NW-TT for the TSC
PDU Session
DS-TT Port Number Port Number allocated by the NW-TT for the DS-
TT for a given TSC PDU Session

5.8.2.11.10 Port Management Information Container

The following table describes the Port Management Information Container (PMIC) that includes information exchanged
transparently via 5GS between TSN AF and NW-TT for TSC PDU Sessions.

Table 5.8.2.11.10-1: Port Management Information Container

Attribute Description Comment

Port Management Information as Information exchanged transparently between
in Table 5.28.3.1-1 NW-TT and TSN AF via 5GS

5.8.2.11.11 Session Reporting Rule

The following table describes the Session Reporting Rule (SRR) that defines the detection and reporting events that the
UPF shall report, that are not related to specific PDRs of the PDU Session, as follows:

- Per QoS flow per UE QoS Monitoring Report, as specified in clause 5.33.3.2.

- Change of 3GPP or non-3GPP access availability, for an MA PDU session.

3GPP
Release 16 178 3GPP TS 23.501 V16.4.0 (2020-03)

Table 5.8.2.11.11-1: Attributes within Session Reporting Rule

Attribute Description Comment

N4 Session ID Identifies the N4 session associated to this SRR.
Rule ID Unique identifier to identify this information. Used by UPF when reporting.
QoS Monitoring per QoS flow Indicates the UPF to apply the QoS Monotoring The IE is defined in
Control Information report for one or more QoS Flows. clause 7.5.2.9 of the
TS 29.244 [65].
Access Availability Control Indicates the UPF to report when an access type The IE is defined in
Information becomes available or unavailable for an MA PDU clause 7.5.2.9 of
Session. TS 29.244 [65].

5.8.2.11.12 Session reporting generated by UPF

The UPF sends the session report to inform the SMF the detected events for a PDU Session that are related to an SRR.

Table 5.8.2.11.12-1: Attributes within Session Reporting

Attribute Description Comment

N4 Session ID Identifies the N4 session associated to the SRR
which triggered the report.
R