Special Articles on 3GPP Release 17 Standardization Activities
Overview of 5G Core Network Advanced Technologies in 3GPP Release 17 —System Architecture—

Edge Computing Network Slicing Network Automation

Atsushi Minokuchi and Yuji Suzuki
Core Network Development Department

Srisakul Thakolsri, Riccardo Guerzoni, Malla Reddy Sama and Tugce Erkilic Civelek
DOCOMO Communications Laboratories Europe GmbH

Abstract
In 3GPP Release 15, the 5G core network architecture was designed with a service-based architecture across network functions and interfaces, to achieve modularity, reusability, and self-containment of network functions. These basic functions have been further enhanced in Release 16 and Release 17, to fill gaps and missing elements required in industry. This article provides an overview of technical areas that have been enhanced in Release 17, focusing on support for edge computing, network slicing, network automation and non-public networks.

01. Introduction

• The 5G System (5GS)^*1 is composed of the 5G Core network ...

  Open

  The 5G System (5GS)^*1 is composed of the 5G Core network (5GC)^*2, the 5G Radio Access Network (RAN)^*3 and user devices (User Equipment (UE)^*4). The 5GC design principles have a Service Based Architecture (SBA)^*5, in which all network functions and interfaces are self-contained and can be reused. This enables network operators to use the concept of network slicing^*6 to customize the core network^*7 and functionality for specific use cases.

  Release 16 (Rel-16) advanced the 5GC in various areas. For example, (1) service framework^*8 extensions, (2) new network functions for Network Slice Specific Authentication and Authorization (NSSAA)^*9, (3) new network functions for network data analysis based on collected data to enable network automation, and (4) introduction of Non-Public Networks (NPN)^*10, which enable dedicated networks to be built by third parties and mobile communications providers within a specific area, providing integrated connectivity, optimized services, and safe means of communications.

  Rel-17 has extensions for edge computing^*11, network slicing, network automation, and NPN, which are described in this article.

  To support edge computing, 5GC Rel-17 added many broad extensions to the basic specification from Rel-15, including new functions supporting (re)discovery of Edge Application Servers (EAS)^*12, EAS redeployment, and publishing 5GC functions to EAS, and support for the 3rd Generation Partnership Project (3GPP)^*13 application layer architecture.

  Network slicing is a basic 5GS function, and Rel-17 introduced support for network slice admission control, control and limitation of network slice data rates, and subscription based restrictions on simultaneously registered network slices, as well as functional extensions to support transmission based on the particular frequency bands of a network slice.

  For network data analysis, Rel-17 specifications included functions for Artificial Intelligence and Machine Learning (AI/ML)^*14 within the NetWork Data Analytics Function (NWDAF)^*15. It also specifies new functions for data collection and distributing the results of analysis, and for storing collected data and analysis results. Network data analytics functions were also enhanced with support for collection of data from UE, network structures with multiple NWDAF, determination of Radio Access Technology (RAT)/Frequency Selection Priority (RFSP)^*16 by support of NWDAF and network slice load analysis.

  Rel-17 also extends NPN to support having authentication information owned by a different entity than is the Standalone NPN (SNPN)^*17, to support Internet protocol Multimedia Subsystem (IMS)^*18 voice and emergency services, and to provide for SNPN UE on-boarding^*19.

  This article describes these extensions.

  1. 5GS: The 5G network system, consisting of the core network (see ^*7), RAN (see ^*3), and communications devices.
  2. 5GC: The 5th generation core network (see ^*7) specified by the 3GPP (see ^*13) for 5G access technology.
  3. RAN: A network situated between the core network and the mobile devices, composed of radio base stations, radio channels control equipment and other components.
  4. UE: A device enabling users to access network services over the radio interface specified by 3GPP.
  5. SBA: In the 5GC network architecture, groups of Network Functions (NF) are defined, and NFs use each others' services through uniform Service Based Interfaces (SBI).
  6. Network slicing: A function introduced in the 5GC, which partitions the various communications resources on the network into slices according to use and provides communications services satisfying various requirements on each slice.
  7. Core network: A network composed of exchange functions, subscriber information management equipment and other components. Mobile devices communicate with the core network through the access network.
  8. Service framework: A general-purpose framework that makes up an SBA.
  9. NSSAA: Authentication and authorization for a specific network slice based on subscriber information. Information regarding NSSAA for a network slice is stored in the AMF (see ^*51), and is transferred between AMF when the AMF changes due to movement of the mobile device.
  10. NPN: A network built for use by a specific user or group alone. Provided either within a public mobile communications network or built separately from the public mobile communications networks.
  11. Edge computing: An approach in which data processing and management functions are distributed and located closer to the edge of the system, reducing traffic, delay, and processing load on higher-level nodes.
  12. EAS: Application software permanently running in a hosting environment.
  13. 3GPP: An organization that creates standards for mobile communications systems.
  14. AI/ML: Makes inferences using a model, or generates models for making inferences using ML (see ^*59).
  15. NWDAF: A network function specified for 5GC that returns the results of collecting and analyzing various types of data within the network.
  16. RFSP: Information the core network sends to the gNB (see ^*83), so the gNB can support radio resource management for each device.
  17. SNPN: One form of NPN, built independently of public mobile communications networks.
  18. IMS: A call-control and communications format standardized by 3GPP, which implements multimedia services, integrating fixed and mobile network communications services, IP technology, and Session Initiation Protocol (SIP), which is used for Internet telephony.
  19. On-boarding: Configuring a device with authentication information through the network.

02. Support for Edge Computing

• The 3GPP 5G system architecture for Rel-15 ...

  Open

  The 3GPP 5G system architecture for Rel-15 and beyond introduced functions supporting edge computing. In Rel-17, these functions were extended, introducing a dedicated Technical Specification (TS) 23.548 [1], and revising TS 23.501 [2], 23.502 [3], and 23.503 [4].

  3GPP TS23.558 (Rel-17) [5] was standardized by the 3GPP Service & System Aspects (SA)*20 Working Group 6 (WG6), and this technical specification describes the application layer architecture for implementing edge applications.

  2.1 Support for Edge Computing in Rel-15

  TS23.548 summarizes three connectivity models (Figure 1) supported by the 5G network architecture to enable edge computing, as specified by 3GPP SA WG2:

  1. Distributed anchor points
     Selects an anchor User Plane Function (UPF)^*21 near the UE and establishes a Protocol Data Unit (PDU) session^*22 for edge computing.
  2. Session breakout
     Uses an UpLink CLassifier (ULCL)/Branching Point (BP)^*23 to selectively allocate edge computing traffic to the local UPF.
  3. Multiple PDU sessions
     Uses multiple PDU sessions separately for edge computing applications and other applications. An edge computing application will use a PDU session connected to a local site anchor UPF, and other applications will use a PDU session connected to an anchor UPF at the central site.

  

  Figure 1  Connection models

  2.2 Support for Edge Computing in Rel-17

  1) Support for EAS (Re-)Discovery

  The 5GC supports EAS discovery and rediscovery for the three connection models mentioned above. These functions are intended to translate the Fully Qualified Domain Name (FQDN)^*24 of the EAS to the Internet Protocol (IP) address of the EAS that is closest to the UE on the network. This is done by notifying the Domain Name System (DNS)^*25 server of the source IP address and/or the Extension mechanisms for DNS (EDNS) Client Subnet (ECS)^*26 option (specified in RFC 7871 [6]) in the DNS query^*27 (Figure 2). 3GPP SA WG2 specified the following additional functions as the basis for these functions.

  

  Figure 2  EAS discovery supported by 5GS Rel-17

  (1) EAS discovery through distributed anchor points.

  With the distributed anchor point connection model, when the 5GC establishes a PDU session, it selects a DNS resolver/server based on the UE location and configures it in the UE. The EAS discovery procedure is performed based on this information. When the UE sends a DNS query through the local PDU Session Anchor (PSA) UPF to the DNS resolver/server, one of the following is performed.

  • The DNS query is treated by the DNS resolver. The DNS resolver adds the DNS ECS option and sends the DNS query to the authoritative DNS server.
  • The DNS query is resolved by the DNS server closest to the PSA UPF. However, in some cases the DNS server considers the source IP address in the DNS query.

  (2) EAS discovery based on session breakout

  With the session breakout connection model, EAS discovery is performed based on the following:

  • Dynamic session breakout: Rel-17 introduces a new function to support EAS Discovery Function (EASDF)^*28, enabling session breakout (Up-Link CLassifier/Branching Point: ULCL/BP) to be established dynamically. The EASDF forwards the DNS query received from the UE to the DNS server (local or central site). Then, the EASDF receives the DNS response and notifies the Session Management Function (SMF)^*29 with information included in the DNS response (e.g. EAS IP address). Based on this information, the SMF changes the route to include the local anchor UPF and the ULCL/BP.
    The EASDF configuration can be controlled from the application layer. The application layer can provide the EAS deployment configuration to the 5GC control plane^*30, including a list of FQDN supported by the application, and the range of IP addresses corresponding to local accesses to each data network and related DNS server identifiers.
  • Pre-established session breakout: Static session breakout is established by performing EAS discovery with a pre-defined DNS resolver/server.

  (3) EAS discovery with multiple PDU sessions

  With multiple PDU sessions, EAS discovery is performed using a UE Route Selection Policy (URSP) rule. The URSP rule is configured in the UE by the 5GC control plane and UE application traffic is mapped to the appropriate PDU session. URSP rules can be used with the multiple PDU session connection model and also with any other edge connection model.

  TS23.548 also describes the method for generating URSP rules based on service parameters received by the 5GC control plane from the application layer. For example, using a destination FQDN or IP address specified by the application layer, when the UE detects traffic for that address, it can establish a dedicated PDU session (with a specific data network or slice).

  2) Support for Edge Relocation

  TS23.548 describes procedures for edge relocation: for EAS change and/or PSA UPF relocation. Specific examples include the following:

  • Packet buffering to reduce packet loss^*31
    Procedure for buffering UL traffic to prevent packet loss when the EAS is relocated.
  • Edge relocation involving Application Function (AF)^*32 change
    Procedure for handling scenarios when the AF changes, due to change in EAS deployed on the local part of the data network, or relocation of the central application server.
  • Edge relocation using EAS IP replacement
    Procedure for the local PSA UPF to replace EAS IP address or port number for traffic related to an application using edge computing.
  • AF request for simultaneous connectivity to source and target PSA
    Procedure to enable an AF to request the network for a connection to both source PSA and target PSA simultaneously, when relocating an edge.
  • Edge relocation considering user plane^*33 latency requirements
    Procedure for the AF to notify the network of user-plane latency requirements, and to determine whether edge relocation is necessary for the SMF to satisfy those requirements.
  • Edge relocation triggered by AF.
    Procedure for EAS relocation due to AF internal trigger (e.g.: if the EAS load is unbalanced or the EAS cannot be used due to maintenance work) or when there is a user-plane path change notification to the AF from the SMF.

  2.3 Application Layer Architecture for Implementing Edge Applications

  3GPP TS23.558 describes the application layer architecture standardized by the 3GPP SA WG6 (SA6) to support edge applications. There is an explicit division between the 5G core architecture described above, specified by 3GPP SA WG2, and the application layer architecture specified by SA6.

  An overview of the architecture introduced by SA6 for implementing edge applications is shown in Figure 3 [5]. As shown in this figure, SA6 application layer components can use 3GPP core network functions and services published by the Network Exposure Function (NEF)^*34 through the EDGE-2, 7, and 8 interfaces specified by SA6.

  

  Figure 3  Application layer architecture

  To enable the UE to obtain the application layer configuration, the 5GC can perform provisioning^*35 of the Edge Configuration Server (ECS)^*36 identifier. The role of the ECS in the SA6 architecture is to provide the support functions needed so the UE Edge Enabler Client (EEC)^*37 can connect with the Edge Enabler Server (EES)^*38 on the edge data network.

  The ECS and the EES belong to the Edge Computing Service Provider (ECSP)^*39 and the EAS belongs to the Application Service Provider (ASP)^*40. The ECSP and ASP can be either a Mobile Network Operator (MNO)^*41 or a third-party provider.

  Some of the Rel-17 procedures specified in TS23.558 are as follows:

  1) Service Provisioning

  The Edge Configuration Server (ECS) can configure the Edge Enabler Client (EEC) with necessary information such as Edge Enabler Server (EES) addresses. This process is called service provisioning, and enables end users to consume edge computing services.

  The service provisioning procedures support both a request/response model and a subscription/notification model. For the request/response model, the EEC sends a service provisioning request to the ECS, and the ECS responds with the edge data network configuration information for the request. For the subscription/notification model, the EEC first subscribes to the ECS, and the ECS sends notifications to the EEC when trigger conditions are met, such as when service provisioning information is updated. After service provisioning, the EEC accesses the EES, and performs registration and other operations.

  2) Registration

  To support edge computing services, edge computing entities (e.g.: EAS, EES, ECS, EEC) need to interact with each other. Registration is the process by which these entities distribute their information to each other.

  Rel-17 supports three types of registration, which are EEC registration with EES (via EDGE-1), EAS registration with EES (via EDGE-3), and EES registration with ECS (via EDGE-6). Each of the entities: EEC, EAS, and EES; have procedures to register, update, and delete their registration. EEC registration with EES also supports a procedure to migrate the EEC context^*42. This procedure transfers EEC related information (EEC context) from the EES where it was originally registered to a different EES. This procedure would normally be used when a UE moves to a new location, to continue using the edge computing service with a different EES that is closer to the current location of the UE.

  3) Service Continuity

  SA6 also specifies several procedures to support service continuity besides the EEC context migration procedure described above. Service continuity procedures are intended for UE migration, EAS overload, or EAS graceful shutdown^*43 due to maintenance. Between service continuity procedures, application client information (application context) on the Source EAS (S-EAS) is transferred to the Target EAS (T-EAS). The service continuity procedure that exchanges application contexts between EAS is called Application Context Relocation (ACR).

  Service continuity can be divided into five different scenarios, according to the role of each entity related to the service continuity state and ACR. In each scenario, the application context is transferred from the S-EAS to the T-EAS, and after the ACR procedure, the T-EAS provides the service to the UE.

  1. 3GPP SA: The group within 3GPP that handles standardization related to service requirements, architecture, security, codecs, and network management.
  2. UPF: A network function of the 5G core network. This function handles packet routing and transmission, packet inspection and Quality of Service (QoS) processing.
  3. PDU session: The logical connection between the UE and the data network.
  4. ULCL/BP: ULCL and BP are UPF functions that selectively allocate uplink traffic between two N6 interfaces related to the same data network.
  5. FQDN: Specifies an exact location in the tree hierarchy of the DNS (see *25), specifying all domain levels.
  6. DNS: A system that associates host names and IP addresses on IP networks.
  7. ECS: Information optionally sent with a DNS query indicating the subnet to which the sender of the DNS query belongs.
  8. DNS query: A request sent to a DNS server to translate a domain name to an IP address.
  9. EASDF: The functional component that performs EAS discovery using DNS.
  10. SMF: The 5GC network function that manages sessions.
  11. Control plane: The set of network functions that process control tasks such as registering devices (UE) and configuring data transmission routes.
  12. Packet loss: When a data packet does not arrive at its destination due to data error, congestion or other cause.
  13. AF: A network function that provides an application.
  14. User plane: The part of the signal, sent and received in communication, which contains the data sent and received by the user.
  15. NEF: An NF that provides APIs for obtaining internal 5GC information or controlling within the 5GC from applications outside of 5GC.
  16. Provisioning: Various settings and tasks required to procure and operate resources needed to run an application, such as terminals, servers, and network resources.
  17. ECS: A functional component that manages configuration needed for edge computing.
  18. EEC: The functional component on the device for implementing an edge computing service.
  19. EES: The functional component on the server for implementing an edge computing service.
  20. ECSP: A provider of an edge computing service, which provides both ECS and EES.
  21. ASP: An operator of an application providing an EAS.
  22. MNO: An operator of a mobile network.
  23. Context: Specific device or client information that is used when a network function or application handles that device or client.
  24. Graceful shutdown: Planned shutdown.

03. Network Slicing Enhancements

• 3GPP provided network slicing functions in Rel-15 ...

  Open

  3GPP provided network slicing functions in Rel-15 and later specifications. These functions developed from the Dedicated core network (Decor)^*44 of the Evolved Packet System (EPS)^*45. Using network slicing, various business needs can be satisfied, even if the service requirements for different customers conflict, by separating logical network segments. Later, the Global System for Mobile communications Association (GSMA)^*46 studied improvements to control network slice resource use by customers, with the results summarized in the Networks Group document NG.116 [7]. In Rel-17, 3GPP introduced many functions into the 5GC to support parameters defined in NG.116 in particular, to improve the potential for commercial implementations of network slicing.

  3.1 Network Slice Admission Control

  Network Slice Admission Control (NSAC)^*47 ensures that the number of UEs and PDU sessions accommodated by a network slice does not exceed that specified in the Generic Slice Template (GST)^*48, based on the associated Service Level Agreement (SLA)^*49. The NSAC Function (NSACF) provides monitoring and control of the number of UE and PDU sessions on each network slice. The allocated amounts, depending on configuration, can be dependent or not dependent on the access type (either 3GPP access type or non-3GPP access type). The NSACF is also able to notify AF and other NF of the current number of UEs and PDU sessions on each network slice, through event-based notifications.

  An NSACF can be developed in various ways upon deployment. For example, an NSACF can be made for the use of a particular network slice only, or it can be applied to multiple network slices. A single Public Land Mobile Network (PLMN)^*50 can be made to have only one NSACF, or a PLMN can have multiple NSACF, with service provision areas defined for each, to support a PLMN with a broad operating area.

  To ensure accurate monitoring and control of usage of the allocated amount, the Access and Mobility management Function (AMF)^*51 and SMF must be aware of the network slices influenced by an NSAC. New requests from UE must also be checked by the NSACF before the AMF and SMF accept the requests. If the allocation amount is reached, the AMF rejects the requested network slice. To avoid increasing latency of the UE registration procedure due to checking the allocated amount with the NSACF, an operator can also use the optional Early Admission Control (EAC)^*52 function. Using this function, the AMF can send the registration accept to the UE before checking with the NSACF.

  3.2 Data Rate Control and Limiting within a Network Slice

  Figure 4 shows what was possible before Rel-17 and what is possible with Rel-17. With Rel-15 and 16, it was only possible to control or limit the total bit rate for a single UE on all network slices, but Rel-17 introduced the UE Slice Maximum Bit Rate (UE-Slice-MBR), which enables the total bit rate of all Guaranteed-Bit-Rate (GBR)^*53 and non-GBR data flows for all PDU sessions on a particular network slice and particular UE to be controlled and limited.

  

  Figure 4  Per-UE slice-specific total maximum bit rate

  For this operation, the AMF obtains the UE-Slice-MBR from the Unified Data Management (UDM)^*54 and provides it to the RAN, and the RAN limits the bit-rate.

  With Rel-17, it is also possible to control and limit the data rate for all UEs within the same network slice. To support this functionality, a User Data Repository (UDR)^*55 stores the maximum data rate for all UEs on the network slice and the remaining data rate for the network slice. A Policy Control Function (PCF)^*56 refers to this information and ensures that the current data rate does not exceed the maximum value permitted for the network slice.

  3.3 Access Restrictions for Simultaneous Registration of Network Slices

  Even if a UE subscribes for access to different network slices, there are cases when the 5GC must prevent simultaneous access to the multiple services they provide, due to network organization, regulations, or the SLA. To support such prevention, the UDM function stores the Network Slice Simultaneous Registration Group (NSSRG)^*57 information as part of the subscriber information, and provides it to the AMF, so the AMF can enforce such prevention.

  3.4 Network-slice-specific Frequency Band Redirection

  For non-uniform network deployments, particular geographic locations may have different network slices configured to use different frequency bands. However, prior to Rel-17, UE was not aware of the frequency bands on which network slices were operating. For this reason, if a UE that initially registered on a network slice operating on a particular frequency band later tries to register on another network slice operating on a different frequency band, it could be the case that the other network slice cannot be used in the current tracking area, and the request from the UE will always be denied. With Rel-17, the AMF sends target Network Slice Selection Assistance Information (NSSAI)^*58 to the RAN, so it can direct the UE to a cell that supports a network slice indicated there.

  1. Decor: An EPS (see ^*45) function that enables the RAN to select the core network assigned to the device.
  2. EPS: Generic term for an IP-based packet network specified by 3GPP for LTE or other access technologies.
  3. GSMA: An organization active in the development of the entire mobile telecommunications industry, and which consists of MNOs and mobile telecommunications industry-related members from around the world.
  4. NSAC: A function in 5GS Rel-17 and later, that enables operators to monitor and control the number of registered devices and PDU sessions for each network slice.
  5. GST: Sets of attributes that characterize a network slice or a service provided by a network slice. Specified in GSMA NG.116.
  6. SLA: The agreement between the service provider and the service consumer.
  7. PLMN: Operators in each country are identified by a country code and operator ID.
  8. AMF: Equipment in 5GC that serves the UE in particular area.
  9. EAC: A function that allows setting of whether the limit on number of devices for each network slice is checked before or after Allowed NSSAI (i.e. the network slices the device can use in the current cell) is decided.
  10. GBR: Guaranteed bit rate.
  11. UDM: An information management equipment in 5GC that stores and provides information including subscriber information, UE contexts (area of attach, and session information).
  12. UDR: A repository in 5GC.
  13. PCF: A function of the 5G core network responsible for controlling policy, such as QoS and billing control.
  14. NSSRG: Included as part of subscriber information, provides information on prevention on simultaneous use of a network slice.
  15. NSSAI: Information supporting selection of network slices.

04. Network Analytics Enhancements

• 4.1 NWDAF Enhancements

  Open

  To support intelligent network automation, the 5GS supports AI and ML^*59 technologies.

  In Rel-15, NWDAF was introduced as an independent core network function. In Rel-16, all 5GC functions related to network data analysis, centered on NWDAF, were specified in detail in a dedicated document, TS23.288 [8]. Application Programming Interfaces (API)^*60 were also defined in detail in TS29.520 [9]. The goal of these specifications was to provide network data analysis that would enable network automation on 5GS.

  As shown in Figure 5, NWDAF collects data from NF (e.g.: AMF, SMF, PCF), AF, Operations, Administration, Maintenance (OAM)^*61, and other components. NWDAF analyzes the input network data from NF, AF, OAM, and other components and provides the results. In Rel-16, inference and model training functions were implemented in a single NWDAF, but further details were not specified. With Rel-17, the NWDAF was partitioned into the following:

  

  Figure 5  NWDAF function overview

  • Model Training Logical Function (MTLF): Trains ML models and shares the trained ML models with the Analytics Logical Function (AnLF) through a newly defined service (Nnwdaf_MLModel).
  • AnLF: Performs inference and derives statistics and prediction data as analysis results, based on requests from NF, AF, and OAM, which use the analysis results.

  MTLF and AnLF can run separately as standalone functions, or be combined in a single NWDAF.

  4.2 New Set of Functions Introduced

  Rel-17 also introduced the following new set of functions to the analytical framework, as shown in Figure 6.

  

  Figure 6  New NFs introduced in Rel-17 and their service names

  • Data Collection Coordination Function (DCCF)^*62: A central entity that manages all data requests. For example, data consumers send data requests to the DCCF rather than directly to the data source. The DCCF determines whether another data consumer has already requested the same data and if it has already been requested and is available, the DCCF sends it directly to the consumer. If the data is not available, the DCCF begins collecting the data from the data source.
  • Messaging framework: Processes data received from a data source and sends the data to all data consumer notification end points^*63 specified by either data consumers or a DCCF [8]. Note that the messaging framework is not standardized in 3GPP specifications. 3GPP specifications describe a Messaging Framework Adaptor NF (MFAF)^*64, which is a service that enables the 5GS to interact with the messaging framework. The internal logic of the messaging framework is outside of the 3GPP scope.
  • Analytics Data Repository Function (ADRF): A storage function that allows data consumers to store and retrieve data and analytics. ADRF can be considered as the 5GS data warehouse^*65/data lake^*66. For example, ADRF could be implemented based on the open-source Hadoop^*67 platform.

  4.3 Introduction of New Analytics Items

  Network data analytics as defined in Rel-16 was further extended in Rel-17, adding five new analytics items to the existing items. These items are: “session management congestion control experience analytics,” which provides statistical data on enforcement of the session management congestion control, so that it can be applied fairly to UEs; “redundant transmission experience related analytics,” which provides statistical data and estimation of the effectiveness of redundant transmission, used to decide whether to use redundant transmission for Ultra-Reliable and Low Latency Communications (URLLC)^*68 services; “WLAN performance analytics,” which determines Wireless Local Area Network (WLAN) performance for UE; “Dispersion analytics,” which enables ranking of locations and network slices needing attention by the proportion of activity (amount of data, control messages, etc.) by a UE in each location or slice, and identification of UE that uses a particular location or network slice frequently; and “DN performance analytics,” which determines the user performance for a particular edge computing application.

  1. ML: A technology that enables a computer to learn useful judgment rules through statistical processing from sample data.
  2. API: Interface specification used for information exchange between 5GC equipment.
  3. OAM: Functions for maintenance and operational management on a network.
  4. DCCF: A network function that collects and coordinates collection of data for one or more NWDAF.
  5. End point: A URI to access an API.
  6. MFAF: A network function that enables the 5GS to link to a messaging framework using the Nmfaf function.
  7. Data warehouse: A storage repository for storing processed data.
  8. Data lake: A storage repository for storing data before it is processed.
  9. Hadoop: A platform implemented parallel distributed processing. Hadoop is a registered trademark of the Apache Software Foundation.
  10. URLLC: A service requiring both high reliability and low latency simultaneously.

05. Non-public Network Enhancements

• Rel-16, 3GPP introduced the concept of SNPN, ...

  Open

  In Rel-16, 3GPP introduced the concept of SNPN, which is a private network usually operated by an enterprise other than a PLMN operator, to support use cases such as process or factory automation. Rel-17 extended two aspects of authentication methods for SNPN, to support the following use cases in professional audio and video production [10].

  1. When an event sponsor deploys an SNPN at an event venue. Broadcast station equipment connects through the SNPN as a UE. Different companies do broadcasting and audio-visual production for each event, and each company will bring in the equipment that they need. To support such use cases, a mechanism was specified by which an external enterprise rather than the SNPN can authenticate a UE.
  2. When a new device is brought into a studio that uses an SNPN. For this use case, a mechanism was specified where the SNPN allows a UE to retrieve an appropriate credential by initially using a default credential.

  The mechanisms to support these use cases are described below.

  Rel-17 also provides for cases where a PLMN operator uses an SNPN for radio access, and specifies support for emergency call on an SNPN. It also specifies support for a Public Warning System (PWS)^*69 on an SNPN, in conformance with large-scale private network regulations in some European nations.

  5.1 Mechanisms Enabling an External Enterprise to Authenticate UE

  An external enterprise called a Credential Holder (CH)^*70 can perform the primary authentication of a UE with either of the two mechanisms described below.

  1) For CH with an Authentication Authorization Accounting (AAA) Server^*71

  The NF related to this case are shown in Figure 7. The CH deploys an AAA server, which functions as an Extensible Authentication Protocol (EAP) server^*72. The SNPN deploys a Network Slice specific and SNPN Authentication and Authorization Function (NSSAAF)^*73 and the NSSAAF processes messages transmitted between the AUthentication Server Function (AUSF)^*74 and the AAA server.

  

  Figure 7  Primary authentication by a CH with an AAA server

  This scenario supports authentication methods including Improved EAP-Authentication and Key Agreement (EAP-AKA')^*75, EAP-Transport Layer Security (EAP-TLS)^*76, and EAP-Tunneled Transport Layer Security (EAP-TTLS)^*77. Note that EAP-TTLS does not require UE authentication information.

  In the UE registration procedure, the AUSF receives a SUbscription-Concealed Identifier (SUCI)^*78 from the UE and provides it to the UDM. The UDM decodes the SUCI into a SUbscription Permanent Identifier (SUPI)^*79 in Network Access Identifier (NAI) format, checks the subscriber information and determines that the primary authentication is dependent on the CH AAA server. The UDM provides this information to the AUSF and the AUSF sends an EAP message to the NSSAAF. The NSSAAF forwards the EAP message to the CH AAA server and converts the protocol as necessary. The CH AAA server functions as the EAP server, resuming the primary authentication procedure.

  2) For CH without an AAA Server, Using AUSF and UDM

  The NF related to this case are shown in Figure 8. The SNPN or PLMN is the CH. A procedure similar to roaming^*80 is used for primary authentication.

  

  Figure 8  Primary authentication by CH without an AAA server, using AUSF and UDM

  5.2 Mechanism for UE to Obtain Suitable Authentication Information

  For this scenario, the SNPN that facilitates provision of authentication information to the UE is called the ONboarding SNPN (ON-SNPN), and the SNPN that owns the authentication information is called the Subscription Owner SNPN (SO-SNPN). The ON-SNPN and SO-SNPN can be the same, or different. The server that provides the SO-SNPN authentication information is called the ProVisioning Server (PVS)^*81. The NF related to this mechanism are shown in Figure 9. The PVS is deployed at N6^*82.

  

  Figure 9  UE onboarding facilitated by an ON-SNPN

  Default authentication information and ON-SNPN selection information are configured on the UE. The ON-SNPN gNodeB (gNB)^*83 broadcasts that onboarding is permitted. A UE receiving this selects an ON-SNPN, accesses the ON-SNPN using the default authentication information, and information indicating that the access is for onboarding is included in the Radio Resource Control (RRC)^*84 message. When a UE registers, the request type is configured as SNPN onboarding. The OAM sets onboarding configuration data on the AMF of the ON-SNPN beforehand. In some cases, the IP address or FQDN of the PVS is set on the UE beforehand. If it is not set, the ON-SNPN SMF provides the information to the UE using Protocol Configuration Options (PCO)^*85 when the PDU session is established. The UE obtains authentication information from the PVS and can use it to access the SO-SNPN. If the ON-SNPN AMF times out, the UE registration is revoked.

  As described above, the ON-SNPN can depend on the CH for primary authentication with the default authentication information. The NF related to this case are shown in Figure 10. The CH AAA server is called the Default Credential Server (DCS)^*86. The UDM is not involved in this procedure. The AUSF sends the EAP message directly to the NSSAAF.

  

  Figure 10  UE onboarding assisted by an ON-SNPN and DCS

  1. PWS: Has a different name in each country, but in Japan it is the system that issues emergency earthquake alert.
  2. CH: When building an SNPN, the component that authenticates devices and the other components can be handled by different entities. CH means the former component or an entity that operates it.
  3. AAA server: A generic term referring to a server that manages authentication, authorization and accounting.
  4. EAP server: An end-point server for extended authentication protocols using an authentication framework that supports multiple authentication methods.
  5. NSSAAF: An NF handling network-slice-specific or SNPN authentication and authorization. In this article, it refers to the function that is related to the latter and used to forward authentication related messages.
  6. AUSF: An NF that takes the role of authentication server.
  7. EAP-AKA': An extension to the authentication and key-sharing system standardized by the IETF for 3G mobile communications systems.
  8. EAP-TLS: An authentication protocol specified by IETF that issues a digital certificate on both the client side and server side to enable mutual authentication.
  9. EAP-TTLS: An authentication method that uses ID and password configured in mobile device.
  10. SUCI: An encrypted form of the information identifying a subscriber (SUPI, see ^*79) used by the 5GS.
  11. SUPI: Information used in the 5GS to identify subscribers.
  12. Roaming: A mechanism that enables users to use services similar to their subscribed carriers within the service areas of alliance partner telecommunications carriers, but outside the service areas of their subscribed telecommunications carriers.
  13. PVS: A server that provides an authentication credential (information to be stored in the device that is used in the authentication process).
  14. N6: A reference point between a UPF and a DN.
  15. gNB: A radio base station that supports the 5G radio system.
  16. RRC: A Layer 3 protocol for controlling radio resources in a radio network.
  17. PCO: Transmits the various protocol options in the bearer-established signal.
  18. DCS: A server that authenticates default credentials that are pre-configured in a device.

06. Conclusion

• This article described 5GC enhancements made ...

  Open

  This article described 5GC enhancements made in Rel-17 with a focus on edge computing, network slicing, network automation, and NPN. Since the beginning of 2022, 3GPP SA WG2 has begun research on Rel-18, to make further enhancements to 5G. The goal of some of the research on Rel-18 is to further extend functions described in this article. NTT DOCOMO will continue to contribute to 5G-Advanced standardization at 3GPP, and to the further expansion of mobile telecommunications.

• REFERENCES

  Open

  1. [1] 3GPP TS23.548 V17.3.0: “5G System Enhancements for Edge Computing; Stage 2,” Jun. 2022.
  2. [2] 3GPP TS23.501 V17.5.0: “System architecture for the 5G System (5GS),” Jun. 2022.
  3. [3] 3GPP TS23.502 V17.5.0: “Procedures for the 5G System (5GS),” Jun. 2022.
  4. [4] 3GPP TS23.503 V17.5.0: “Policy and charging control framework for the 5G System (5GS); Stage 2,” Jun. 2022.
  5. [5] 3GPP TS23.558 V17.4.0: “Architecture for enabling Edge Applications,” Jun. 2022.
  6. [6] IETF RFC7871: “Client Subnet in DNS Queries,” May 2016.
  7. [7] GSMA NG.116 V1.0: “Generic Network Slice Template,” May 2019.
  8. [8] 3GPP TS23.288 V17.5.0: “Network Data Analytics Services; Stage 2,” Jun. 2022.
  9. [9] 3GPP TS29.520 V17.7.0: “Network Data Analytics Services; Stage 3,” Jun. 2022.
  10. [10] 3GPP TR22.827 V17.1.0: “Study on Audio-Visual Service Production; Stage 1,” Jan. 2020.

VOL.24 NO.3