6.2 Network Function Functional description

23.5013GPPRelease 18System architecture for the 5G System (5GS)TS

6.2.1 AMF

The Access and Mobility Management function (AMF) includes the following functionality. Some or all of the AMF functionalities may be supported in a single instance of an AMF:

– Termination of RAN CP interface (N2).

– Termination of NAS (N1), NAS ciphering and integrity protection.

– Registration management.

– Connection management.

– Reachability management.

– Mobility Management.

– Lawful intercept (for AMF events and interface to LI System).

– Provide transport for SM messages between UE and SMF.

– Transparent proxy for routing SM messages.

– Access Authentication.

– Access Authorization.

– Provide transport for SMS messages between UE and SMSF.

– Security Anchor Functionality (SEAF) as specified in TS 33.501 [29].

– Location Services management for regulatory services.

– Provide transport for Location Services messages between UE and LMF as well as between RAN and LMF.

– EPS Bearer ID allocation for interworking with EPS.

– UE mobility event notification.

– S-NSSAIs per TA mapping notification.

– Support for Control Plane CIoT 5GS Optimisation.

– Support for User Plane CIoT 5GS Optimisation.

– Support for restriction of use of Enhanced Coverage.

– Provisioning of external parameters (Expected UE Behaviour parameters or Network Configuration parameters).

– Support for Network Slice-Specific Authentication and Authorization.

– Support for charging.

– Controlling the 5G access stratum-based time distribution based on UE’s subscription data.

NOTE 1: Regardless of the number of Network functions, there is only one NAS interface instance per access network between the UE and the CN, terminated at one of the Network functions that implements at least NAS security and Mobility Management.

In addition to the functionalities of the AMF described above, the AMF may include the following functionality to support non-3GPP access networks:

– Support of N2 interface with N3IWF/TNGF. Over this interface, some information (e.g. 3GPP Cell Identification) and procedures (e.g. Handover related) defined over 3GPP access may not apply, and non-3GPP access specific information may be applied that do not apply to 3GPP accesses.

– Support of NAS signalling with a UE over N3IWF/TNGF. Some procedures supported by NAS signalling over 3GPP access may be not applicable to untrusted non-3GPP (e.g. Paging) access.

– Support of authentication of UEs connected over N3IWF/TNGF.

– Management of mobility, authentication, and separate security context state(s) of a UE connected via a non-3GPP access or connected via a 3GPP access and a non-3GPP access simultaneously.

– Support as described in clause 5.3.2.3 a co-ordinated RM management context valid over a 3GPP access and a Non 3GPP access.

– Support as described in clause 5.3.3.4 dedicated CM management contexts for the UE for connectivity over non-3GPP access.

– Determine whether the serving N3IWF is appropriate based on the slices supported by the N3IWFs as specified in clause 6.3.6.

NOTE 2: Not all of the functionalities are required to be supported in an instance of a Network Slice.

In addition to the functionalities of the AMF described above, the AMF may include policy related functionalities as described in clause 6.2.8 of TS 23.503 [45].

The AMF uses the N14 interface for AMF re-allocation and AMF to AMF information transfer. This interface may be either intra-PLMN or inter-PLMN (e.g. in the case of inter-PLMN mobility).

In addition to the functionality of the AMF described above, the AMF may include the following functionality to support monitoring in roaming scenarios:

– Normalization of reports according to roaming agreements between VPLMN and HPLMN (e.g. change the location granularity in a report from cell level to a level that is appropriate for the HPLMN); and

– Generation of charging/accounting information for Monitoring Event Reports that are sent to the HPLMN.

In addition to the functionality of the AMF described above, the AMF may provide support for Network Slice restriction and Network Slice instance restriction based on NWDAF analytics.

In addition to the functionalities of the AMF described above, the AMF may provide support for the Disaster Roaming as described in clause 5.40.

In addition to the functionalities of the AMF described above, the AMF may also include following functionalities to support Network Slice Admission Control:

– Support of NSAC for maximum number of UEs as defined in clauses 5.15.11.1 and 5.15.11.3.

In addition to the functionality of the AMF described above, the AMF may include the following functionality to support SNPNs:

– Support for Onboarding of UEs for SNPNs.

In addition to the functionalities of the AMF described above, the AMF may also include following functionalities to support satellite backhaul:

– Support for reporting satellite backhaul category (i.e. GEO, MEO, LEO or OTHERSAT) and its modification based on AMF local configuration to SMF as defined in clause 5.8.2.15.

6.2.2 SMF

The Session Management function (SMF) includes the following functionality. Some or all of the SMF functionalities may be supported in a single instance of a SMF:

– Session Management e.g. Session Establishment, modify and release, including tunnel maintain between UPF and AN node.

– UE IP address allocation & management (including optional Authorization). The UE IP address may be received from a UPF or from an external data network.

– DHCPv4 (server and client) and DHCPv6 (server and client) functions.

– Functionality to respond to Address Resolution Protocol (ARP) requests and / or IPv6 Neighbour Solicitation requests based on local cache information for the Ethernet PDUs. The SMF responds to the ARP and / or the IPv6 Neighbour Solicitation Request by providing the MAC address corresponding to the IP address sent in the request.

– Selection and control of UP function, including controlling the UPF to proxy ARP or IPv6 Neighbour Discovery, or to forward all ARP/IPv6 Neighbour Solicitation traffic to the SMF, for Ethernet PDU Sessions.

– Configures traffic steering at UPF to route traffic to proper destination.

– 5G VN group management, e.g. maintain the topology of the involved PSA UPFs, establish and release the N19 tunnels between PSA UPFs, configure traffic forwarding at UPF to apply local switching, N6-based forwarding or N19-based forwarding.

– Termination of interfaces towards Policy control functions.

– Lawful intercept (for SM events and interface to LI System).

– Support for charging.

– Control and coordination of charging data collection at UPF.

– Termination of SM parts of NAS messages.

– Downlink Data Notification.

– Initiator of AN specific SM information, sent via AMF over N2 to AN.

– Determine SSC mode of a session.

– Support for Control Plane CIoT 5GS Optimisation.

– Support of header compression.

– Act as I-SMF in deployments where I-SMF can be inserted, removed and relocated.

– Provisioning of external parameters (Expected UE Behaviour parameters or Network Configuration parameters).

– Support P-CSCF discovery for IMS services.

– Act as V-SMF with following roaming functionalities:

– Handle local enforcement to apply QoS SLAs (VPLMN).

– Charging (VPLMN).

– Lawful intercept (in VPLMN for SM events and interface to LI System).

– Support for interaction with external DN for transport of signalling for PDU Session authentication/authorization by external DN.

– Instructs UPF and NG-RAN to perform redundant transmission on N3/N9 interfaces.

NOTE: Not all of the functionalities are required to be supported in an instance of a Network Slice.

In addition to the functionalities of the SMF described above, the SMF may include policy related functionalities as described in clause 6.2.2 of TS 23.503 [45].

In addition to the functionality of the SMF described above, the SMF may include the following functionality to support monitoring in roaming scenarios:

– Normalization of reports according to roaming agreements between VPLMN and HPLMN; and

– Generation of charging information for Monitoring Event Reports that are sent to the HPLMN.

The SMF may also include following functionalities to support Edge Computing enhancements (further defined in TS 23.548 [130]):

– Selection of EASDF and provision of its address to the UE as the DNS Server for the PDU session;

– Usage of EASDF services as defined in TS 23.548 [130];

– For supporting the Application Layer Architecture defined in TS 23.558 [134]: Provision and updates of ECS Address Configuration Information to the UE.

The SMF and SMF+ PGW-C may also include following functionalities to support Network Slice Admission Control:

– Support of NSAC for maximum number of PDU sessions as defined in clauses 5.15.11.2, 5.15.11.3 and 5.15.11.5.

– Support of NSAC for maximum number of UEs as defined in clauses 5.15.11.3 and 5.15.11.5.

6.2.3 UPF

The User plane function (UPF) includes the following functionality. Some or all of the UPF functionalities may be supported in a single instance of a UPF:

– Anchor point for Intra-/Inter-RAT mobility (when applicable).

– Allocation of UE IP address/prefix (if supported) in response to SMF request.

– External PDU Session point of interconnect to Data Network.

– Packet routing & forwarding (e.g. support of Uplink classifier to route traffic flows to an instance of a data network, support of Branching point to support multi-homed PDU Session, support of traffic forwarding within a 5G VN group (UPF local switching, via N6, via N19)).

– Packet inspection (e.g. Application detection based on service data flow template and the optional PFDs received from the SMF in addition).

– User Plane part of policy rule enforcement, e.g. Gating, Redirection, Traffic steering).

– Lawful intercept (UP collection).

– Traffic usage reporting.

– QoS handling for user plane, e.g. UL/DL rate enforcement, Reflective QoS marking in DL.

– Uplink Traffic verification (SDF to QoS Flow mapping).

– Transport level packet marking in the uplink and downlink.

– Downlink packet buffering and downlink data notification triggering.

– Sending and forwarding of one or more "end marker" to the source NG-RAN node.

– Functionality to respond to Address Resolution Protocol (ARP) requests and / or IPv6 Neighbour Solicitation requests based on local cache information for the Ethernet PDUs. The UPF responds to the ARP and / or the IPv6 Neighbour Solicitation Request by providing the MAC address corresponding to the IP address sent in the request.

– Packet duplication in downlink direction and elimination in uplink direction in GTP-U layer.

– NW-TT functionality.

– High latency communication, see clause 5.31.8.

– ATSSS Steering functionality to steer the MA PDU Session traffic, refer to clause 5.32.6.

NOTE: Not all of the UPF functionalities are required to be supported in an instance of user plane function of a Network Slice.

– Inter PLMN UP Security (IPUPS) functionality, specified in clause 5.8.2.14.

– event exposure, including exposure of network information, i.e. the QoS monitoring information, as specified in clause 6.4 of TS 23.548 [130] and events as specified in clause 5.2.26.2 of TS 23.502 [3], and exposure of data collected for analytics, as specified in clause 5.2.26.2 of TS 23.502 [3].

6.2.4 PCF

The Policy Control Function (PCF) includes the following functionality:

– Supports unified policy framework to govern network behaviour.

– Provides policy rules to Control Plane function(s) to enforce them.

– Accesses subscription information relevant for policy decisions in a Unified Data Repository (UDR).

NOTE: The PCF accesses the UDR located in the same PLMN as the PCF.

The details of the PCF functionality are defined in clause 6.2.1 of TS 23.503 [45].

6.2.5 NEF

6.2.5.0 NEF functionality

The Network Exposure Function (NEF) supports the following independent functionality:

– Exposure of capabilities and events:

NF capabilities and events may be securely exposed by NEF for e.g. 3rd party, Application Functions, Edge Computing as described in clause 5.13.

NEF stores/retrieves information as structured data using a standardized interface (Nudr) to the Unified Data Repository (UDR).

– Secure provision of information from external application to 3GPP network:

It provides a means for the Application Functions to securely provide information to 3GPP network, e.g. Expected UE Behaviour, 5G-VN group information, time synchronization service information and service specific information. In that case the NEF may authenticate and authorize and assist in throttling the Application Functions.

– Translation of internal-external information:

It translates between information exchanged with the AF and information exchanged with the internal network function. For example, it translates between an AF-Service-Identifier and internal 5G Core information such as DNN, S-NSSAI, as described in clause 5.6.7.

In particular, NEF handles masking of network and user sensitive information to external AF’s according to the network policy.

– Redirecting the AF to a more suitable NEF/L-NEF e.g. when serving an AF request for local information exposure and detecting there is a more appropriate NEF instance to serve the AF’s request.

– The Network Exposure Function receives information from other network functions (based on exposed capabilities of other network functions). NEF stores the received information as structured data using a standardized interface to a Unified Data Repository (UDR). The stored information can be accessed and "re-exposed" by the NEF to other network functions and Application Functions, and used for other purposes such as analytics.

– A NEF may also support a PFD Function: The PFD Function in the NEF may store and retrieve PFD(s) in the UDR and 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].

– A NEF may also support a 5G-VN Group Management Function: The 5G-VN Group Management Function in the NEF may store the 5G-VN group information in the UDR via UDM as described in TS 23.502 [3].

– Exposure of analytics:

NWDAF analytics may be securely exposed by NEF for external party, as specified in TS 23.288 [86].

– Retrieval of data from external party by NWDAF:

Data provided by the external party may be collected by NWDAF via NEF for analytics generation purpose. NEF handles and forwards requests and notifications between NWDAF and AF, as specified in TS 23.288 [86].

– Support of Non-IP Data Delivery:

NEF provides a means for management of NIDD configuration and delivery of MO/MT unstructured data by exposing the NIDD APIs as described in TS 23.502 [3] on the N33/Nnef reference point. See clause 5.31.5.

– Charging data collection and support of charging interfaces.

– Support of UAS NF functionality:

Details are defined in TS 23.256 [136].

– Support of EAS deployment functionality:

Details are defined in TS 23.548 [130].

– Support of SBI-based MO SM transmit for MSISDN-less MO SMS:

Details are defined in TS 23.540 [142].

A specific NEF instance may support one or more of the functionalities described above and consequently an individual NEF may support a subset of the APIs specified for capability exposure.

NOTE: The NEF can access the UDR located in the same PLMN as the NEF.

The services provided by the NEF are specified in clause 7.2.8.

For external exposure of services related to specific UE(s), the NEF resides in the HPLMN. Depending on operator agreements, the NEF in the HPLMN may have interface(s) with NF(s) in the VPLMN.

When a UE is capable of switching between EPC and 5GC, an SCEF+NEF is used for service exposure. See clause 5.17.5 for a description of the SCEF+NEF.

6.2.5.1 Support for CAPIF

When an NEF is used for external exposure, the CAPIF may be supported. When CAPIF is supported, an NEF that is used for external exposure supports the CAPIF API provider domain functions. The CAPIF and associated API provider domain functions are specified in TS 23.222 [64].

6.2.5a Void

6.2.6 NRF

6.2.6.1 General

The Network Repository Function (NRF) supports the following functionality:

– Supports service discovery of NRF services and their endpoint addresses by the NRF bootstrapping service.

– Supports service discovery function. Receive NF Discovery Request from NF instance or SCP, and provides the information of the discovered NF instances (be discovered) to the NF instance or SCP.

– Supports P-CSCF discovery (specialized case of AF discovery by SMF).

– Maintains the NF profile of available NF instances and their supported services.

– Maintains SCP profile of available SCP instances.

– Supports SCP discovery by SCP instances.

– Notifies about newly registered/updated/ deregistered NF and SCP instances along with its potential NF services to the subscribed NF service consumer or SCP.

– Maintains the health status of NFs and SCP.

In the context of Network Slicing, based on network implementation, multiple NRFs can be deployed at different levels (see clause 5.15.5):

– PLMN level (the NRF is configured with information for the whole PLMN),

– shared-slice level (the NRF is configured with information belonging to a set of Network Slices),

– slice-specific level (the NRF is configured with information belonging to an S-NSSAI).

In the context of roaming, multiple NRFs may be deployed in the different networks (see clause 4.2.4):

– the NRF(s) in the Visited PLMN (known as the vNRF) configured with information for the visited PLMN.

– the NRF(s) in the Home PLMN (known as the hNRF) configured with information for the home PLMN, referenced by the vNRF via the N27 interface.

6.2.6.2 NF profile

NF profile of NF instance maintained in an NRF includes the following information:

– NF instance ID.

– NF type.

– PLMN ID in the case of PLMN, PLMN ID + NID in the case of SNPN.

– Network Slice related Identifier(s) e.g. S-NSSAI, NSI ID.

– FQDN or IP address of NF.

– NF capacity information.

– NF priority information.

NOTE 1: This parameter is used for AMF selection, if applicable, as specified in clause 6.3.5. See clause 6.1.6.2.2 of TS 29.510 [58] for its detailed use.

– NF Set ID.

– NF Service Set ID of the NF service instance.

– NF Specific Service authorization information.

– if applicable, Names of supported services.

– Endpoint Address(es) of instance(s) of each supported service.

– Identification of stored data/information.

NOTE 2: This is only applicable for a UDR profile. See applicable input parameters for Nnrf_NFManagement_NFRegister service operation in clause 5.2.7.2.2 of TS 23.502 [3]. This information applicability to other NF profiles is implementation specific.

– Other service parameter, e.g. DNN or DNN list, notification endpoint for each type of notification that the NF service is interested in receiving.

– Location information for the NF instance.

NOTE 3: This information is operator specific. Examples of such information can be geographical location, data centre.

– TAI(s).

– NF load information.

– Routing Indicator, Home Network Public Key identifier, for UDM and AUSF.

– For UDM, AUSF and NSSAAF in the case of access to an SNPN using credentials owned by a Credentials Holder with AAA Server, identification of Credentials Holder (i.e. the realm of the Network Specific Identifier based SUPI).

– For UDM and AUSF, and if UDM/AUSF is used for access to an SNPN using credentials owned by a Credentials Holder, identification of Credentials Holder (i.e. the realm if Network Specific Identifier based SUPI is used or the MCC and MNC if IMSI based SUPI is used); see clause 5.30.2.1.

– For AUSF and NSSAAF in the case of SNPN Onboarding using a DCS with AAA server, identification of DCS (i.e. the realm of the Network Specific Identifier based SUPI).

– For UDM and AUSF, and if UDM/AUSF is used as DCS in the case of SNPN Onboarding, identification of DCS (i.e. the realm if Network Specific Identifier based SUPI, or the MCC and MNC if IMSI based SUPI).

– One or more GUAMI(s), in the case of AMF.

– SMF area identity(ies) in the case of UPF.

– UDM Group ID, range(s) of SUPIs, range(s) of GPSIs, range(s) of internal group identifiers, range(s) of external group identifiers for UDM.

– UDR Group ID, range(s) of SUPIs, range(s) of GPSIs, range(s) of external group identifiers for UDR.

– AUSF Group ID, range(s) of SUPIs for AUSF.

– PCF Group ID, range(s) of SUPIs for PCF.

– HSS Group ID, set(s) of IMPIs, set(s) of IMPU, set(s) of IMSIs, set(s) of PSIs, set(s) of MSISDN for HSS.

– For NWDAF: Supported Analytics ID(s), possibly per service, NWDAF Serving Area information (i.e. list of TAIs for which the NWDAF can provide services and/or data), Supported Analytics Delay per Analytics ID (if available), NF types of the NF data sources, NF Set IDs of the NF data sources, if available, Analytics aggregation capability (if available), Analytics metadata provisioning capability (if available), ML model Filter information parameters S-NSSAI(s) and Area(s) of Interest for the trained ML model(s) per Analytics ID(s) (if available), FL capability type (i.e. FL server or FL client, if available), Time interval supporting FL (if available).

Editor’s note: Whether to register Time interval supporting FL to the NRF is FFS.

NOTE 4: The NWDAF’s Serving Area information is common to all its supported Analytics IDs.

NOTE 5: The Analytics IDs supported by the NWDAF may be associated with a Supported Analytics Delay i.e. the Analytics report can be generated with a time (including data collection delay and inference delay) in less than or equal to the Supported Analytics Delay.

NOTE 6: The determination of Supported Analytics Delay, and how the NWDAF avoid updating its Supported Analytics Delay in NRF frequently is NWDAF implementation specific.

– Event ID(s) supported by AFs, in the case of NEF.

– Event Exposure service supported event ID(s) by UPF.

– Application Identifier(s) supported by AFs, in the case of NEF.

– Range(s) of External Identifiers, or range(s) of External Group Identifiers, or the domain names served by the NEF, in the case of NEF.

NOTE 7: This is applicable when NEF exposes AF information for analytics purpose as detailed in TS 23.288 [86].

NOTE 8: It is expected service authorization information is usually provided by OA&M system, and it can also be included in the NF profile in the case that e.g. an NF instance has an exceptional service authorization information.

NOTE 9: The NRF may store a mapping between UDM Group ID and SUPI(s), UDR Group ID and SUPI(s), AUSF Group ID and SUPI(s) and PCF Group ID and SUPI(s), to enable discovery of UDM, UDR, AUSF and PCF using SUPI, SUPI ranges as specified in clause 6.3 or interact with UDR to resolve the UDM Group ID/UDR Group ID/AUSF Group ID/PCF Group ID based on UE identity, e.g. SUPI (see clause 6.3.1 for details).

– IP domain list as described in clause 6.1.6.2.21 of TS 29.510 [58], Range(s) of (UE) IPv4 addresses or Range(s) of (UE) IPv6 prefixes, Range(s) of SUPIs or Range(s) of GPSIs or a BSF Group ID, in the case of BSF.

– SCP Domain the NF belongs to.

– DCCF Serving Area information, NF types of the data sources, NF Set IDs of the data sources, if available, in the case of DCCF.

– Supported DNAI list, in the case of SMF.

– For SNPN, capability to support SNPN Onboarding in the case of AMF and capability to support User Plane Remote Provisioning in the case of SMF.

– IP address range, DNAI for UPF.

– Additional V2X related NF profile parameters are defined in TS 23.287 [121].

– Additional ProSe related NF profile parameters are defined in TS 23.304 [128].

– Additional MBS related NF profile parameters are defined in TS 23.247 [129].

– Additional UAS related NF profile parameters are defined in TS 23.256 [136].

6.2.6.3 SCP profile

SCP profile maintained in an NRF includes the following information:

– SCP ID.

– FQDN or IP address of SCP.

– Indication that the profile is of an SCP (e.g. NF type parameter set to type SCP).

– SCP capacity information.

– SCP load information.

– SCP priority.

– Location information for the SCP (see locality in clause 6.1.6.2.2 of TS 29.510 [58]).

– Served Location(s) (see servingScope in clause 6.1.6.2.2 of TS 29.510 [58]).

– Network Slice related Identifier(s) e.g. S-NSSAI, NSI ID.

– Remote PLMNs reachable through SCP.

– Endpoint addresses accessible via the SCP.

– NF sets of NFs served by the SCP.

– SCP Domain the SCP belongs to. If an SCP belongs to more than one SCP Domain, the SCP will be able bridge these domains, i.e. sending messages between these domains.

NOTE: Service definition defines optional and mandatory parameters, see TS 23.502 [3].

6.2.7 UDM

The Unified Data Management (UDM) includes support for the following functionality:

– Generation of 3GPP AKA Authentication Credentials.

– User Identification Handling (e.g. storage and management of SUPI for each subscriber in the 5G system).

– Support of de-concealment of privacy-protected subscription identifier (SUCI).

– Access authorization based on subscription data (e.g. roaming restrictions).

– UE’s Serving NF Registration Management (e.g. storing serving AMF for UE, storing serving SMF for UE’s PDU Session).

– Support to service/session continuity e.g. by keeping SMF/DNN assignment of ongoing sessions.

– MT-SMS delivery support.

– Lawful Intercept Functionality (especially in outbound roaming case where UDM is the only point of contact for LI).

– Subscription management.

– SMS management.

– 5G-VN group management handling.

– Support of external parameter provisioning (Expected UE Behaviour parameters or Network Configuration parameters).

– Support for the Disaster Roaming as described in clause 5.40.

– Support for the control of time synchronization service based on subscription data as described in clause 5.27.1.11.

To provide this functionality, the UDM uses subscription data (including authentication data) that may be stored in UDR, in which case a UDM implements the application logic and does not require an internal user data storage and then several different UDMs may serve the same user in different transactions.

NOTE 1: The interaction between UDM and HSS, when they are deployed as separate network functions, is defined in TS 23.632 [102] and TS 29.563 [103] or it is implementation specific.

NOTE 2: The UDM is located in the HPLMN of the subscribers it serves, and access the information of the UDR located in the same PLMN.

6.2.8 AUSF

The Authentication Server Function (AUSF) supports the following functionality:

– Supports authentication for 3GPP access and untrusted non-3GPP access as specified in TS 33.501 [29].

– Supports authentication of UE for a Disaster Roaming service as specified in TS 33.501 [29].

6.2.9 N3IWF

The functionality of N3IWF in the case of untrusted non-3GPP access includes the following:

– Support of IPsec tunnel establishment with the UE: The N3IWF terminates the IKEv2/IPsec protocols with the UE over NWu and relays over N2 the information needed to authenticate the UE and authorize its access to the 5G Core Network.

– Termination of N2 and N3 interfaces to 5G Core Network for control – plane and user-plane respectively.

– Relaying uplink and downlink control-plane NAS (N1) signalling between the UE and AMF.

– Handling of N2 signalling from SMF (relayed by AMF) related to PDU Sessions and QoS.

– Establishment of IPsec Security Association (IPsec SA) to support PDU Session traffic.

– Relaying uplink and downlink user-plane packets between the UE and UPF. This involves:

– De-capsulation/ encapsulation of packets for IPSec and N3 tunnelling

– Enforcing QoS corresponding to N3 packet marking, taking into account QoS requirements associated to such marking received over N2

– N3 user-plane packet marking in the uplink.

– Local mobility anchor within untrusted non-3GPP access networks using MOBIKE per IETF RFC 4555 [57].

– Supporting AMF selection.

6.2.9A TNGF

The functionality of TNGF in the case of trusted non-3GPP access includes the following:

– Terminates the N2 and N3 interfaces.

– Terminates the EAP-5G signalling and behaves as authenticator when the UE attempts to register to 5GC via the TNAN.

– Implements the AMF selection procedure.

– Transparently relays NAS messages between the UE and the AMF, via NWt.

– Handles N2 signalling with SMF (relayed by AMF) for supporting PDU sessions and QoS.

– Transparently relays PDU data units between the UE and UPF(s).

– Implements a local mobility anchor within the TNAN.

6.2.10 AF

The Application Function (AF) interacts with the 3GPP Core Network in order to provide services, for example to support the following:

– Application influence on traffic routing (see clause 5.6.7);

– Accessing Network Exposure Function (see clause 5.20);

– Interacting with the Policy framework for policy control (see clause 5.14);

– Time synchronization service (see clause 5.27.1.8);

– IMS interactions with 5GC (see clause 5.16).

Based on operator deployment, Application Functions considered to be trusted by the operator can be allowed to interact directly with relevant Network Functions.

Application Functions not allowed by the operator to access directly the Network Functions shall use the external exposure framework (see clause 7.3) via the NEF to interact with relevant Network Functions.

The functionality and purpose of Application Functions are only defined in this specification with respect to their interaction with the 3GPP Core Network.

6.2.11 UDR

The Unified Data Repository (UDR) supports the following functionality:

– Storage and retrieval of subscription data by the UDM.

– Storage and retrieval of policy data by the PCF.

– Storage and retrieval of structured data for exposure.

– Application data (including Packet Flow Descriptions (PFDs) for application detection, AF request information for multiple UEs, 5G-VN group information for 5G-VN management).

– Storage and retrieval of NF Group ID corresponding to subscriber identifier (e.g. IMPI, IMPU, SUPI).

The Unified Data Repository is located in the same PLMN as the NF service consumers storing in and retrieving data from it using Nudr. Nudr is an intra-PLMN interface.

NOTE 1: Deployments can choose to collocate UDR with UDSF.

6.2.12 UDSF

The UDSF is an optional function that supports the following functionality:

– Storage and retrieval of information as unstructured data by any NF. Notify a NF consumer if information validity has expired.

– Timer service to any NF.

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.

NOTE 2: Deployments can choose to collocate UDSF with UDR.

6.2.13 SMSF

The SMSF supports the following functionality to support SMS over NAS:

– SMS management subscription data checking and conducting SMS delivery accordingly.

– SM-RP/SM-CP with the UE (see TS 24.011 [6]).

– Relay the SM from UE toward SMS-GMSC/IWMSC/SMS-Router.

– Relay the SM from SMS-GMSC/IWMSC/SMS-Router toward the UE.

– SMS charging.

– Lawful Interception.

– Interaction with AMF and SMS-GMSC for notification procedure that the UE is unavailable for SMS transfer (i.e, notifies SMS-GMSC to inform UDM when UE is unavailable for SMS).

6.2.14 NSSF

The Network Slice Selection Function (NSSF) supports the following functionality:

– Selecting the set of Network Slice instances serving the UE;

– Determining the Allowed NSSAI and, if needed, the mapping to the Subscribed S-NSSAIs;

– Determining the Configured NSSAI and, if needed, the mapping to the Subscribed S-NSSAIs;

– Determining the AMF Set to be used to serve the UE, or, based on configuration, a list of candidate AMF(s), possibly by querying the NRF;

– The NSSF may provide support for Network Slice restriction and Network Slice instance restriction based on NWDAF analytics.

6.2.15 5G-EIR

The 5G-EIR is an optional network function that supports the following functionality:

– Check the status of PEI (e.g. to check that it has not been prohibited).

6.2.16 LMF

The functionality of LMF is defined in clause 4.3.8 of TS 23.273 [87].

6.2.16A GMLC

The functionality of GMLC is defined in clause 4.3.8 of TS 23.273 [87].

6.2.17 SEPP

The Security Edge Protection Proxy (SEPP) is a non-transparent proxy and supports the following functionality:

– Message filtering and policing on inter-PLMN control plane interfaces.

NOTE: The SEPP protects the connection between Service Consumers and Service Producers from a security perspective, i.e. the SEPP does not duplicate the Service Authorization applied by the Service Producers as specified in clause 7.1.4.

– Topology hiding.

Detailed functionality of SEPP, related flows and the N32 reference point, are specified in TS 33.501 [29].

The SEPP applies the above functionality to every Control Plane message in inter-PLMN signalling, acting as a service relay between the actual Service Producer and the actual Service Consumer. For both Service Producer and Consumer, the result of the service relaying is equivalent to a direct service interaction. Every Control Plane message in inter-PLMN signalling between the SEPPs may pass via IPX entities. More details on SEPPs and the IPX entities are described in TS 29.500 [49] and TS 33.501 [29].

6.2.18 Network Data Analytics Function (NWDAF)

The Network Data Analytics Function (NWDAF) includes one or more of the following functionalities:

– Support data collection from NFs and AFs;

– Support data collection from OAM;

– NWDAF service registration and metadata exposure to NFs and AFs;

– Support analytics information provisioning to NFs and AFs;

– Support Machine Learning (ML) model training and provisioning to NWDAFs (containing Analytics logical function).

The details of the NWDAF functionality are defined in TS 23.288 [86].

NOTE 1: Some or all of the NWDAF functionalities can be supported in a single instance of an NWDAF.

NOTE 2: NWDAF functionality beyond its support for Nnwdaf is out of scope of 3GPP.

6.2.19 SCP

The Service Communication Proxy (SCP) includes one or more of the following functionalities. Some or all of the SCP functionalities may be supported in a single instance of an SCP:

– Indirect Communication (see clause 7.1.1 for details).

– Delegated Discovery (see clauses 7.1.1 and 6.3.1 for details).

– Message forwarding and routing to destination NF/NF service.

– Message forwarding and routing to a next hop SCP.

– Communication security (e.g. authorization of the NF Service Consumer to access the NF Service Producer API), load balancing, monitoring, overload control, etc.

– Optionally interact with UDR, to resolve the UDM Group ID/UDR Group ID/AUSF Group ID/PCF Group ID/CHF Group ID/HSS Group ID based on UE identity, e.g. SUPI or IMPI/IMPU (see clause 6.3.1 for details).

NOTE 1: Communication security, e.g. authorization of the NF Service Consumer to access the NF Service Producer’s API is specified in TS 33.501 [29].

NOTE 2: Load balancing, monitoring, overload control functionality provided by the SCP is left up to implementation.

The SCP may be deployed in a distributed manner.

NOTE 3: More than one SCP can be present in the communication path between NF Services.

SCPs can be deployed at PLMN level, shared-slice level and slice-specific level. It is left to operator deployment to ensure that SCPs can communicate with relevant NRFs.

In order to enable SCPs to route messages through several SCPs (i.e. next SCP hop discovery, see clause 6.3.16), an SCP may register its profile in the NRF. Alternatively, local configuration may be used.

6.2.20 W-AGF

The functionality of W-AGF is specified in TS 23.316 [84].

6.2.21 UE radio Capability Management Function (UCMF)

The UCMF is used for storage of dictionary entries corresponding to either PLMN-assigned or Manufacturer-assigned UE Radio Capability IDs. An AMF may subscribe with the UCMF to obtain from the UCMF new values of UE Radio Capability ID that the UCMF assigns for the purpose of caching them locally.

Provisioning of Manufacturer-assigned UE Radio Capability ID entries in the UCMF is performed from an AF that interacts with the UCMF either directly or via the NEF (or via Network Management) using a procedure defined in TS 23.502 [3]. A UCMF that serves both EPS and 5GS shall require provisioning the UE Radio Capability ID with the TS 36.331 [51] format or TS 38.331 [28] format or both the formats of the UE radio capabilities.

The UCMF also assigns the PLMN-assigned UE Radio Capability ID values.

Each PLMN-assigned UE Radio Capability ID is also associated to the TAC of the UE model(s) that it is related to. When an AMF requests the UCMF to assign a UE Radio Capability ID for a set of UE radio capabilities, it indicates the TAC of the UE that the UE Radio Capability information is related to.

The UCMF stores a Version ID value for the PLMN assigned UE Radio Capability IDs so it is included in the PLMN assigned UE Radio Capability IDs it assigns. This shall be configured in the UCMF.

The UCMF may be provisioned with a dictionary of Manufacturer-assigned UE Radio Capability IDs which include a "Vendor ID" that applies to the Manufacturers of these UE, and a list of TACs for which the PLMN has obtained-Manufacturer-assigned UE Radio Capability IDs.

A PLMN-assigned UE Radio Capability IDs is kept in the UCMF storage as long as it is associated with at least a TAC value. When a TAC value is related to a UE model that is earmarked for operation based on Manufacturer assigned UE Radio Capability IDs, this TAC value is disassociated in the UCMF from any PLMN assigned UE Radio Capability IDs.

For the case that the PLMN is configured to store PLMN assigned IDs in the Manufacturer Assigned operation requested list defined in clause 4.4.1a, the UCMF does not remove from storage any PLMN assigned UE Radio Capability ID no longer used, and rather quarantines it to avoid any future reassignment.

A UCMF dictionary entry shall include also the related UE Radio Capability for Paging for each RAT.

6.2.22 TWIF

The functionality of Trusted WLAN Interworking Function (TWIF) is specified in clause 4.2.8.5.3.

6.2.23 NSSAAF

The Network Slice-specific and SNPN Authentication and Authorization Function (NSSAAF) supports the following functionality:

– Support for Network Slice-Specific Authentication and Authorization as specified in TS 23.502 [3] with a AAA Server (AAA-S). If the AAA-S belongs to a third party, the NSSAAF may contact the AAA-S via a AAA proxy (AAA-P).

– Support for access to SNPN using credentials from Credentials Holder using AAA server (AAA-S) as specified in clause 5.30.2.9.2 or using credentials from Default Credentials Server using AAA server (AAA-S) as specified in clause 5.30.2.10.2. If the Credentials Holder or Default Credentials Server belongs to a third party, the NSSAAF may contact the AAA server via a AAA proxy (AAA-P).

NOTE: When the NSSAAF is deployed in a PLMN, the NSSAAF supports Network Slice-Specific Authentication and Authorization, while when the NSSAAF is deployed in a SNPN the NSSAAF can support Network Slice-Specific Authentication and Authorization and/or the NSSAAF can support access to SNPN using credentials from Credentials Holder.

6.2.24 DCCF

The Data Collection Coordination Function (DCCF) supports the following functionality:

– Determining Data Sources that can provide data for a received data request.

– Determining whether data is already being collected from a data source.

– Instructing a Messaging Framework to send data to consumers or notification endpoints.

– Instructing a Messaging Framework to do formatting and processing of the data sent via the Messaging Framework.

– Formatting and processing of data.

– Sending data to consumers or notification endpoints.

– Registering NWDAFs and ADRFs that are already receiving data from a Data Source.

The DCCF functionality is specified in TS 23.288 [86].

6.2.25 MFAF

The Messaging Framework Adaptor Function (MFAF) supports the following functionality:

– Interfacing with a DCCF that controls how a messaging framework will process, format and send data to consumers or notification endpoints.

– Receiving data from Data Sources via services offered by those Data Sources.

– Sending data received from Data Sources to a messaging framework (outside the scope of 3GPP).

– Receiving data from a messaging framework (outside the scope of 3GPP).

– Processing, formatting and sending data to specified consumers or notification endpoints.

NOTE: The internal logic of Messaging Framework is outside the scope of 3GPP, only MFAF and the interface between MFAF and other 3GPP defined NF is under 3GPP scope.

The MFAF functionality is specified in TS 23.288 [86].

6.2.26 ADRF

The Analytics Data Repository Function (ADRF) supports the following functionality:

– Storage and retrieval of analytics generated by NWDAFs and collected data.

The Analytics Data Repository Function (ADRF) is specified in TS 23.288 [86].

6.2.27 MB-SMF

The functionality of MB-SMF is specified in TS 23.247 [129].

6.2.27a MB-UPF

The functionality of MB-UPF is specified in TS 23.247 [129].

6.2.27b MBSF

The functionality of MBSF is specified in TS 23.247 [129].

6.2.27c MBSTF

The functionality of MBSTF is specified in TS 23.247 [129].

6.2.28 NSACF

The Network Slice Admission Control Function (NSACF) supports the following functionality:

– Support of monitoring and controlling the number of registered UEs per network slice.

– Support of monitoring and controlling the number of established PDU Sessions per network slice.

– Support of event based Network Slice status notification and reports to a consumer NF.

The details of the NSACF functionality are defined in clause 5.15.11.

6.2.29 TSCTSF

The Time Sensitive Communication and Time Synchronization Function (TSCTSF) supports the following functionality:

– Associating the time synchronization service request (see clause 5.27.1.8) from the NF consumer to the AF sessions with the PCF (the session between the PCF and TSCTSF).

– Controlling time synchronization service request from the NF consumer, (g)PTP-based time distribution and ASTI-based time distribution based on subscription data. The TSCTSF may be pre-configured with one or several PTP instance configurations. For each PTP instance configuration, it may contain:

– a reference to the PTP instance configuration.

– PTP profile.

– PTP domain.

– Managing the DS-TT and NW-TT via exchange of PMIC and UMIC as described in Annex K.

– Detecting availability of 5GS Bridge information (including user plane node ID that applies also for IP type PDU Sessions) as reported by PCF for both Ethernet and IP type PDU Sessions (including the need to (un)subscribe 5GS Bridge information Notification from PCF).

– Creating the TSC Assistance Container based on individual traffic pattern parameters from the NEF/AF and providing it to the PCF.

– Determining the Requested PDB by subtracting the UE-DS-TT Residence Time from the Requested 5GS Delay provided by the NEF/AF and providing the determined Requested PDB to the PCF.

– Discovering the AMFs serving the list of TA(s) that comprise the spatial validity condition from the NRF and subscribing to the discovered AMF(s) to receive notifications about presence of the UE in an Area of Interest events determined by the list of TA(s) served by the AMF.

– Determining the spatial validity condition from the requested coverage area by the NEF/AF and enforcing time synchronization service for the requested coverage area.

6.2.30 5G DDNMF

The functionality of 5G DDNMF is defined in TS 23.304 [128].

6.2.31 EASDF

The functionality of EASDF is defined in TS 23.548 [130].

6.2.32 TSN AF

The TSN AF supports control plane translator functionality for the integration of the 5GS with a TSN network, this involves e.g.:

– 5GS Bridge management.

– Port and bridge management information exchange with DS-TT or NW-TT.

– Interactions with the CNC for 5GS Bridge configuration and reporting.

– determining the TSC Assistance Container and TSN QoS information by mapping TSN Stream(s) based on IEEE standards. The traffic pattern parameter determination may be based on PSFP (IEEE Std 802.1Q [98]) as specified in Annex I, clause I.1.

6.2.33 NSWOF

The NSWOF interfaces the WLAN access network using the SWa interface as defined in TS 23.402 [43] and interfaces the AUSF using the Nausf SBI performing protocol translation and AUSF discovery (see clause 6.3.4).