Special Articles on 3GPP Release 18 Standardization Activities (2)
Advanced Technologies for Network Automation and AI/ML in 3GPP Release 18

Network Automation AI/ML Federated Learning

Bahador Bakhshi, Malla Reddy Sama and Riccardo Guerzoni
DOCOMO Communications Laboratories Europe GmbH

Atsushi Minokuchi
6G-Tech Department

Abstract
Next-generation networks are expected to combine communications with AI/ML. This article describes AI/ML for networks and the network functions for supporting AI/ML applications being considered in 3GPP Rel-18. In particular, the article explains the advances in the new 5GC technologies that will enable these capabilities and discuss how 5GC will accelerate the implementation of intelligent networks and support the deployment of cutting-edge AI/ML services.

01. Introduction

• Artificial Intelligence and Machine Learning (AI/ML)^*1 are ...

  Open

  Artificial Intelligence and Machine Learning (AI/ML)^*1 are rapidly developing technologies with the potential for use in various industries. Since telecommunications must meet requirements concerning increasing network complexity and data-transmission volumes and more-demanding Quality of Service (QoS)^*2, it is a particularly important, promising area for the application of AI/ML. The intertwining of AI/ML and telecommunication networks is expected to bring about major changes in both network operations and user experience.

  The relationship between AI/ML and communication networks is two-fold as described below:

  1. AI/ML can improve the design, operation, and management of networks. ML algorithms analyze network data to predict and prevent failures, optimize resource allocation, automate routine tasks, and ultimately create intelligent autonomous networks. These processes not only improve network efficiency and reliability but also reduce operating costs for mobile carriers.
  2. Communication networks play a key role in supporting AI/ML-based services on the application layer^*3. The high data rates and low-latency communications provided by modern networks are essential for AI/ML-based real-time applications^*4. For example, the effective operation of natural-language-processing systems used by chatbots^*5 and virtual assistants depends on network connectivity. As such applications become more sophisticated, the need for a reliable communications infrastructure will continue to grow.

  In Release 18 (Rel-18), Working Group 2 (WG2) of 3GPP Technical Specification Group Service and System Aspects (TSG SA) (hereinafter referred to as “SA2”) examined the relationships between AI/ML and communication networks mentioned above and defined the following two study items and corresponding work items to address two aspects: “AI for Networks” and “Networks for AI.”

  • Study item 1: In FS_eNA_Ph3^*6, the key issues and their solutions to implement AI/ML for automating the 5G Core network (5GC)^*7 were studied and documented in TR23.700-81 [1].
  • Study item 2: In FS_AIMLsys^*8, the key issues and their solutions for extending 5GC to support AI/ML-based services were studied and documented in TR23.700-80 [2].
  • Work item 1: In eNA_Ph3, the conclusions reached in FS_eNA_Ph3 were specified mainly in TS23.288 [3].
  • Work item 2: In AIMLsys, the solutions studied in FS_AIMLsys were specified mainly in TS23.288 [3], TS23.502 [4], and TS23.503 [5].

  This article first overviews the main functional enhancements that will enable automation of 5GC networks as described in Rel-18. It then explains support for AI/ML-based services by introducing new functions of the 5GC.

  1. AI/ML: Makes inferences using a model or generates models for making inferences by using ML.
  2. QoS: Quality of a communications service. Bandwidth and latency are typical indicators.
  3. Application layer: Layer 7 of the OSI reference model. It defines the functions that applications must provide.
  4. Real-time applications: Applications with immediate updates and feedback (e.g., online games and chat apps).
  5. Chatbot: A program that automatically conduct dialog with people via speech or text chat.
  6. FS_eNA_Ph3: “Study on Enablers for Network Automation for 5G - phase 3.” One of the study items in 3GPP SA2 Rel-18.
  7. 5GC: The fifth-generation core network specified by 3GPP for 5G access technologies.
  8. FS_AIMLsys: “Study on 5G System Support for AI/ML-based Services.” One of the work items in 3GPP SA2 Rel-18.

02. Functional Enhancements for Automation of 5GC Networks in 3GPP Rel-18

• As for 5th Generation mobile communications systems (5G), ...

  Open

  As for 5th Generation mobile communications systems (5G), the Network Data Analytics Function (NWDAF)^*9 was introduced in Rel-15 as a new function for collecting data from various sources, such as network functions and Operations, Administration, Maintenance (OAM)^*10, analyzing the collected data, and providing statistics and predictions based on the analyzed data. The architecture and functionality of the NWDAF were enhanced in releases prior to Rel-18. The architecture for network-data analytics in Rel-17 is shown in Figure 1. The network-data analytics architecture defined in Rel-18 is similar to that defined in Rel-17.

  The architecture supports several important features that facilitate automation of networks. For example, the training and inference functions of ML models are supported by two separate logical network functions, namely, the Model Training Logical Function (MTLF)^*11 and the Analytics Logical Function (AnLF)^*12. Data from Network Functions (NFs)^*13 is collected and coordinated by the Data Collection Coordination Function (DCCF)^*14 in a manner that enables data consumers such as the NWDAF to reduce the resources required for data collection. In addition, the collected data and analytics results are stored in the Analytics Data Repository Function (ADRF)^*15 as a data lake^*16 of the 5GC in a way that enables data consumers to reduce the resources required for data collection significantly.

  In Rel-18, several important analytical functions, that had not been specified in Rel-17, were identified and addressed. These functions include monitoring the accuracy of ML models, Federated Learning (FL) of ML models using multiple NWDAFs, support for exchange of data and analytics results between Public Land Mobile Networks (PLMNs)^*17 for roaming^*18 User Equipment (UE), and traffic analytics of end-to-end transmission delays and Protocol Data Unit (PDU) sessions^*19. The services and functions of NWDAF are explained further in the following sections.

  

  2.1 Accuracy Monitoring

  In general, the main benefit of using AI/ML is to improve the performance and efficiency of a telecommunications network. The effectiveness of AI/ML-based solutions, however, depends on the performance of the ML models. In addition, if the predictions of an ML model are inaccurate, decisions based on those predictions may decrease the performance of a network. To ensure that AI/ML applications remain effective, it is therefore important to monitor and consider the accuracy of ML models. In light of that importance, in Rel-18, two concepts are introduced: monitoring the accuracy of ML models and monitoring the accuracy of the results of analytics.

  The former concept expresses an accuracy index of the ML model provided by the NWDAF (including the MTLF). This index consists of the number of correct predictions out of all predictions made by the ML model and the corresponding number of samples.

  Similarly, the latter concept is a performance index corresponding to a specific analytics, called analytics ID^*20, provided by the NWDAF (including the AnLF). This index is composed of the number of correct predictions out of all predictions for a certain analytics ID and the corresponding number of samples. The analytics will be described later.

  The architecture for accuracy monitoring defined in Rel-18 is shown in Figure 2.

  It provides a new accuracy checking function for the AnLF and MTLF in addition to the de facto functions of AI/ML-based decision making by an NF consumer^*21, inferences by the AnLF, and model training by the MTLF.

  As an example of accuracy monitoring and checking, the accuracy monitoring and checking function of the AnLF compares predictions related to a specific analytics ID with the correct-answer data corresponding to the predictions, thereby making it possible to monitor the accuracy of the analytics results provided by the AnLF to NF consumers. The NF consumers can then provide feedback to the AnLF about the results of the analytics by the AnLF.

  Moreover, if the AnLF detects a problem with accuracy, it can notify the NF consumer to stop or suspend the use of the analytics results provided to it by the AnLF and provide accuracy information about the analytics results to the MTLF. For example, the MTLF can use its accuracy-checking function to monitor the performance of ML models by using the function's logic (which utilizes the accuracy information provided by the AnLF). Using the results of the accuracy monitoring, the MTLF determines whether to retrain the ML model and send the updated model to the AnLF.

  

  2.2 FL among Multiple NWDAFs

  Although the deployment of multiple NWDAFs in 5GC is supported in Rel-17, the NWDAFs do not interact. As a result, when the NWDAFs are training ML models, using only the training data in the database it can access, each NWDAF needs to train its ML model from scratch. This creates the following two problems:

  • Training the same ML model using several NWDAFs wastes computational resources.
  • The inability of NWDAFs to share training data means that the training data for each NWDAF is limited. Consequently, sufficient training data must be collected to achieve acceptable ML model performance, which may take a considerable amount of time.

  To solve the above-described problems, in Rel-18, FL between NWDAFs is introduced. FL is a method for training distributed ML models in which multiple clients jointly train models using their own training data, under the supervision of a central server, without sharing their data.

  A typical FL training procedure consists of the following three steps: (1) the FL server selects multiple FL clients and shares the current version of the ML model; (2) each FL client trains the ML model using local training data and sends updates of the ML model to the FL server; and (3) the FL server collects the ML-model updates from the FL clients and generates a new version called the “global ML model.” These three steps continue until the FL server decides to stop the procedure.

  As shown in Figure 3, FL between NWDAFs is supported by three main procedures stated in the 3GPP specification: (1) registration and discovery procedure, (2) FL training procedure, and (3) FL maintenance procedure.

  1. First, each NWDAF, including the FL server and/or FL client participating in FL training, registers its capabilities in the Network Repository Function (NRF)^*22. Next, the FL server needs to discover suitable FL clients before starting the FL training procedure. To do so, the FL server queries the NRF to discover FL clients and selects FL clients to be used for training from among all FL clients registered with the NRF.
  2. The main FL-training loop is executed by the FL server. First, the FL server shares the current version of the ML model with the selected FL clients. The FL client NWDAFs then train the current ML model using the local training data available to each client and send model updates to the NWDAF of the FL server. Finally, the FL server NWDAF collects the updates and creates a new version of the global ML model.
  3. Furthermore, to ensure that the FL clients can properly participate in FL training (e.g., by ensuring they have sufficient resources and training data), in Rel-18, an FL maintenance procedure is also introduced. This procedure allows FL clients to report training status to the FL server, and the FL server decides to add and/or remove FL clients.

  In Rel-18, Horizontal Federated Learning (HFL)^*23, in particular, is supported. As for HFL, all training participants, such as NWDAFs, have the same feature set of training data; that is, all NWDAFs acting as FL clients collect data with the same features/characteristics from the data sources.

  

  2.3 Exchange of Data and Analytics Results Concerning Roaming

  In Rel-17, the above-mentioned analytical functions are only supported within the same PLMN, and analytical functions from the perspective of the Home PLMN (HPLMN)^*24 is not provided for UEs that roam onto a Visited PLMN (VPLMN)^*25. To solve this problem, Rel-18 supports the exchange of data and analytical between PLMNs. The overall roaming architecture is shown in Figure 4. As for this architecture, a dedicated NWDAF, called a Roaming Exchange NWDAF (RE-NWDAF), is arranged in each PLMN and used to exchange data and analytics results with other PLMNs.

  The overall flow of data and exchange of analytics result in a roaming scenario is described hereafter.

  Under the assumption that the NF consumer in the PLMN (e.g., HPLMN) needs the analytics results, it sends a request (including a specific analytics ID and auxiliary information for selecting the slice to be analyzed) to the H-RE-NWDAF or to another NWDAF deployed^*26 in the HPLMN.

  In the latter case, to provide the analytics results, the deployed NWDAF determines whether it needs data from another PLMN or whether the data must be generated by another PLMN. As a result, a request for data or analytics results is sent to the H-RE-NWDAF. In both cases, the H-RE-NWDAF requests the data or analytics results to be provided through cooperation with the NWDAF of another PLMN (V-NWDAF).

  For that reason, the H-RE-NWDAF searches for the corresponding V-RE-NWDAF via the H-NRF. The H-RE-NWDAF then sends a request for data or analytics results to the corresponding V-RE-NWDAF. In the VPLMN, the V-RE-NWDAF provides the requested data and analytics results to the H-RE-NWDAF. If the V-RE-NWDAF itself cannot provide the requested data or analytics results, it will request another NWDAF in the VPLMN to generate the data or analytics results, which the V-RE-NWDAF will then provide to the H-RE-NWDAF.

  

  2.4 Storing and Retrieving Models

  In Rel-17, the ADRF was a location for storage of analytics results and data; however, in Rel-18, it can also be used as a location for storage of ML models. NWDAFs (containing MTLFs) can store ML models in ADRFs, and the stored models can be retrieved by the NWDAF storing the models or other NWDAFs. That is, the ML models are indirectly shared among NWDAFs.

  The procedure specified in Rel-18 for obtaining the ML model from the ADRF is shown in Figure 5. As for this procedure, after receiving the ML model request from the NF consumer [step (1)], the NWDAF (including the MTLF) checks that the requested model is stored in the ADRF and decides whether to obtain the ML model from the ADRF [step (2)]. Two options are available for responding to the NF consumer: (i) the NWDAF either retrieves the ML model from the ADRF [step (3)] and returns it to the NF consumer [(step (4)] or (ii) it informs the NF consumer of the information required to retrieve the model from the ADRF (ADRF ID, storage information, etc.). The NF consumer then retrieves the model from the ADRF [step (5)].

  

  2.5 Expanded Network Analytics

  Rel-18 introduces a number of new analyses that can be used by various NFs to make more intelligent decisions. These analyses are overviewed as follows.

  1) Analytics of End-to-end Data-volume Transfer Time

  For resource allocation and policy control for time-constrained applications, it is useful to predict end-to-end data transfer latency. A new analytics ID for this latency is introduced in Rel-18.

  To provide this analytics ID, the NWDAF collects (i) information about resources on the Radio Access Network (RAN)^*27 side from OAM, (ii) information about UE communications (such as QoS flow^*28 information) mainly from the Session Management Function (SMF)^*29, and (iii) information on factors affecting end-to-end delay (including application information) from Application Functions (AFs)^*30. On the basis of these pieces of information, statistics and predictions about UpLink (UL)^*31 /DownLink (DL)^*32 data volume and corresponding transfer time under specific conditions—as specified by application ID, UE location information, Data Network Name (DNN)^*33, wireless-technology type, and Single-Network Slice Selection Assistance Information (S-NSSAI)^*34—are provided.

  2) Traffic Analytics of PDU Sessions

  By analyzing the traffic in the PDU session, the NWDAF provides statistics on whether UE traffic over a single or multiple PDU sessions matches the information provided by the service consumer.

  To provide this analytics ID to service consumers, the NWDAF follows two steps: first, mainly from the SMF and User Plane Function (UPF)^*35, it collects traffic-flow information of UE traffic via PDU sessions established for a specific S-NSSAI and DNN. Second, it derives statistics about UEs that route traffic according to information provided by the service consumer (traffic description, S-NSSAI, DNN, etc.) and UEs that route traffic without relying on information provided by the service consumer.

  3) Movement Behavioral Analytics

  Although Rel-17 introduced analytics of UE communication and mobility, this analytics was mainly targeted at specific UEs. For optimizing resource allocation and network operations, it is useful to collect mobility information, such as crowd movements affecting network hotspots^*36, from an unspecified number of UEs, so the movement behavior analytics is introduced in Rel-18. The movement behavior analytics provides statistical or predictive information on the behavior of a group of UEs, such as the number of UEs, movement direction, and movement speed, during a period in the area under analytics.

  To provide this movement behavior analytics, the NWDAF needs to collect information on UE movements in a given region over a certain period of time, primarily from the Access and Mobility management Function (AMF)^*37 and the LoCation Service (LCS)^*38. Using this information, the NWDAF then estimates the number of UEs, etc.

  4) Relative Proximity Analytics

  Analytics of relative proximity of UEs is introduced in Rel-18 as a way to facilitate use cases based on proximity of UEs, such as one UE using information from another UE in close proximity to improve accuracy of location estimation. This analytics ID can be used to help NF consumers on the 5GC network more accurately locate a group of UEs by using statistical and predictive information about the relative proximity of the UEs. Moreover, this analytics allows NF consumers to use the relative proximity of nearby UEs to improve the accuracy of UE location estimation or to identify a UE that is near another one.

  To provide this analytics ID, the NWDAF collects a variety of UE information, such as location, movement, and trajectory, from the OAM, AF, AMF, and LCS.

  5) Analytics of Packet Flow Description (PFD)^*39 Determination

  Determination analytics based on PFD under 5GC was previously performed by the UPF using rules given by the AF; however, it was possible that a UE or AF might generate traffic that did not exactly match the prescribed rules.

  In Rel-18, for supporting traffic generation, the PFD determination analytics is introduced as a way to assist in determining the PFD for known application identifiers.

  For this purpose, the NWDAF analyzes the existing PFD information and U-Plane^*40 traffic and provides the analytics results in the form of new or updated PFD determination statistics (e.g., IP 3-tuple^*41 lists) to NF consumers on the 5GC network. Note that the Network Exposure Function (NEF)^*42 (especially the PFD function^*43 of the NEF) may be a NF consumer that receives the analytics results provided by the NWDAF.

  To provide this PFD determination analytics, the NWDAF collects current traffic-flow information from the UPF and PFD rules defined by the NEF, and it provides new or updated PFD rules after analyzing the input data.

  2.6 AI/ML in Rel-19

  Strengthening the application of AI to 5GC networks continues in Rel-19. Under consideration in Rel-19, study item FS_AIML_CN solves the following four key issues.

  The first issue is the support of the 5GC for applying AI/ML to the RAN side. 3GPP RAN WGs are studying improving the performance of Next-Generation RAN (NG-RAN)^*44 utilizing AI/ML. Various use cases have been identified and documented in TR38.843 [6], including enhanced Channel State Information (CSI)^*45 feedback, beam management, and improved UE positioning accuracy. The use of AI/ML for these use cases may require extensions to 5GC as well as enhancements to RAN, which are being considered as the first key issue of FS_AIML_CN in Rel-19.

  The second issue is support for Vertical Federated Learning (VFL)^*46. As mentioned above, HFL between NWDAFs is supported in Rel-18. The basic assumption of HFL is that all training participants, such as NWDAFs, have the same feature set of training data. In other words, all NWDAFs acting as FL clients must be able to collect data with the same features and/or characteristics from the data sources. However, that requirement is not always the case with FL; that is, depending on the scenario, different NWDAFs may have access to data with different characteristics.

  To handle this case, VFL can be used for joint training even when the training participants, such as NWDAFs, have different features for the same data sample. For example, one participant may have information (features and/or characteristics) about the location and/or movement of a particular UE (data sample), while another participant may have information about the traffic of the same UE.

  This method of training ML models can also be used by the NWDAF and the AF for Quality of Experience (QoE)^*47 -related analytics when the NWDAF does not have access to all details of the user experience on the AF side.

  The third issue is the improvement of QoS and policy control through NWDAF support for the Policy Control Function (PCF)^*48. In Rel-18, to determine QoS parameters for QoS flows, the PCF may subscribe to request analytics results from the NWDAF, such as UE communications; however, it is problematic because the PCF does not consider the impact of past decisions; i.e., the PCF does not consider whether the QoS parameters applied to the QoS flow actually resulted in the expected performance on the UE. Therefore, the support given by the NWDAF to the PCF can be improved by enabling the NWDAF to evaluate QoS parameters applied in the past.

  The fourth issue is detecting excessive signal volume and mitigation of signaling storm using AI/ML. To address this issue, the capabilities of the NWDAF will be extended to provide information to assist other NFs in the 5GC in detecting and/or predicting signal overload so that they can take appropriate countermeasures.

  1. NWDAF: A network function specified in 5GC that collects and provides analyzing various types of data within the network.
  2. OAM: Functions for maintenance and operational management in a network.
  3. MTLF: A logic function unit of the NWDAF that trains and publishes models.
  4. AnLF: A logic function unit of the NWDAF that derives inferences and analytical information.
  5. NFs: Network functions that comprise the 5GC.
  6. DCCF: A network function that collects data and coordinates data collection on behalf of the NWDAF.
  7. ADRF: A repository for storing and publishing data and analytics.
  8. Data lake: A data storage repository.
  9. PLMN: An operator that provide services using a mobile communications system.
  10. Roaming: A mechanism that enables users to use services similar to those provided by their subscribed carriers within the service areas of alliance partner carriers but outside the service areas of their subscribed carriers.
  11. PDU session: A logical connection between a terminal and a data network.
  12. Analytics ID: An ID for identifying the analytics provided by the NWDAF.
  13. NF consumer: An NF that uses a specific function.
  14. NRF: A network function for registration and provision of information of other NFs. It enables discovery of NF producers and NF services by NF consumers and notification when the status of registered NF changes.
  15. HFL: A type of FL in which different samples have common features.
  16. HPLMN: The operator where the user is a subscriber, namely, their home operator.
  17. VPLMN: The operator at the location where a subscriber is roaming (serving operator).
  18. Deploy: Deploying applications, containers, VMs, etc. to their execution environment.
  19. RAN: A network consisting of base stations that control the radio layer, etc., located between the core network and UE.
  20. QoS flow: An IP flow unit that differentiates between QoS classes (communication service quality (allowed latency, packet loss rate, etc.)) in a PDU session tunnel set up between a base station and the core network.
  21. SMF: A 5GC network function that manages sessions.
  22. AF: A network function that provides an application.
  23. UL: Information flow from a UE to a base station.
  24. DL: Information flow from a base station to a UE.
  25. DNN: Destination of a transmission from a UE. Identification name of the data network to which the UE is connected via the core network.
  26. S-NSSAI: An identifier for identifying network slices and used by the 5GC network.
  27. UPF: A network function of the 5G core network. It handles user-packet routing and transmission, packet inspection, and QoS processing.
  28. Hotspot: An indoor office, plaza in front of a train station or other location where concentrated traffic can be generated.
  29. AMF: Logical node that houses the base station (gNB) and provides mobility control, etc. in the 5G core network.
  30. LCS: A service that determines the location of a mobile terminal.
  31. PFD: An information set provided by a third-party service provider that enables detection of application traffic flows.
  32. U-Plane: The part of the signal sent and received in communications. It contains the data sent and received by the user.
  33. IP 3-tuple: A general term for the three pieces of information stored in the IP header, i.e., destination IP address, source IP address, and protocol number.
  34. NEF: A network function specified in 5GC that provides an API to external servers and applications outside of 3GPP specifications.
  35. PFD function: A function of the NEF that manages the PFD in ways such as providing the PFD to the SMF.
  36. NG-RAN: A RAN connecting to the 5G core network using NR or Evolved Universal Terrestrial Radio Access (E-UTRA) as the radio access technology.
  37. CSI: State of the wireless channel connecting the base station and the UE.
  38. VFL: A type of FL in which common samples have different characteristics.
  39. QoE: Service quality derived from the user experience.
  40. PCF: A function of the 5G core network that is responsible for QoS control, policy control, and billing control.

03. Support for AI/ML-based Services in 3GPP Rel-18 5GC

• AI/ML-based services are being rapidly adopted in a variety of fields, ...

  Open

  AI/ML-based services are being rapidly adopted in a variety of fields, including medicine, industry, and education. These services require huge amounts of computational power and communication resources; therefore, communication networks need to adapt to the demands of these services.

  Use cases identified by SA1 to support AI/ML-based services are first described. Then, how the enhanced capabilities of the 5GC network address the specific requirements of these AI/ML applications is examined in detail.

  3.1 Use Cases and Requirements

  As stated in TR22.874 [7], SA1 identified the following three main use cases for AI/ML operations (e.g., ML training and deployment) on the 5GC network.

  1) Splitting AI/ML Operations

  The main focus of splitting the AI/ML operations is the inference phase (i.e., not the ML training phase), and the AI/ML operations and models are split into multiple parts according to the current task and environment, for example, some parts on the UE and other parts on the AF. For example, the computationally and energy-intensive parts of AI/ML inference can be offloaded^*49 to the 5GC network or AF, while the privacy and latency-sensitive parts can remain on the UE.

  1. The amount of data communicated between the UEs and AFs is huge, and some applications may be time sensitive. When handling AI/ML under such conditions, the 5GC network should handle AI/ML. Moreover, information about the 5GC network may have to be exposed to the AF in order to determine the appropriate splitting of the AI/ML operations to be performed by the AF.

  2) Downloading AI/ML Models

  As for AI/ML models, multiple AI/ML applications are expected to run on a UE, and each application may require a unique AI/ML model. Moreover, a single AI/ML application may require different models for different situations. UEs therefore need to switch between various models as tasks and the environment change.

  However, due to the limited storage capacity of UEs and the need for continuous updating (retraining) of models, it is not realistic to store all models directly on the UE; therefore, to enable UEs to adapt to changes in tasks and environment, a mechanism for 5G systems to distribute AI/ML models from AFs to UEs online on demand is needed.

  This online distribution may require a large bandwidth in a short period of time. In particular, real-time applications such as automated driving, in the case of which the UE environment fluctuates in real time, require large models to be distributed in a very short time frame, and that requirement means the 5G system must have a large network capacity. Moreover, in scenarios involving planned periodic updates, such as application updates, ML models stored in a group of UEs must be updated within an appropriate time frame.

  5GC must handle the above-mentioned communication patterns, and handling them is the second use case of AI/ML-based services identified by SA1.

  3) FL over 5G System

  The last use case is the support of FL, including facilitation of FL training, on 5G systems. Unlike the HFL between NWDAFs described above, the FL supported in this use case is executed on the application layer, which includes applications running on AFs and UEs.

  5GC can contribute to the execution of FL in two ways, at least. The first is to facilitate the selection of UEs (i.e., FL clients). The 5GC network provides support information to the AF, which it helps to select suitable UEs to participate in the FL process. The second is the distribution of ML models. As mentioned above, the FL server distributes the current version of the models that the FL clients plan to train. The 5GC network can provide a mechanism for supporting the distribution of ML models to multiple UEs.

  3.2 Expansion of Network Exposure

  As for 5GC, the NEF is responsible for exposing 5GC information to the AF. In the case of AI/ML applications, in Rel-18, in addition to the information exposure already supported in Rel-17, additional information may be exposed to the AF to support the application layer when, for example, determining the appropriate division of AI/ML operations. This additional information includes, for example, the QoS of the group of UEs participating in the FL, the inactivity time of the PDU session collected from the SMF, the amount of traffic, and the UL/DL data rates obtained from the UPF.

  3.3 Support for Forwarding AI/ML Traffic

  As mentioned above, AI/ML applications can have two common traffic patterns: (i) distribution of ML models from the AF to a group of UEs and (ii) planned updates of ML models. To handle these traffic patterns, in 5GC specified in Rel-18, two functional extensions are introduced: support for multi-member AF sessions and policy negotiation called Planned Data Transfer with QoS requirement (PDTQ).

  1) Multi-member AF Sessions

  Prior to Rel-17, an AF could use the Nnef_AFsessionWithQoS service^*50 to make requests that affect the QoS of QoS flows of a particular UE. However, when the AF sends data to multiple UEs, such as distributing the current version of an ML model to a group of UEs participating in FL, the same request must be sent for each UE, and those repetitive requests may impose significant signaling overhead on the 5GC network.

  In Rel-18, the Nnef_AFsessionWithQoS service operation has been extended to accept not only the address of a single UE but also those of a group of UEs. An example of the overall operation of the new service is shown in Figure 6.

  In this example, the AF first requests a session with QoS of 5G network QoS class Identifier (5QI)^*51 of 7 (i.e., specified as best effort) for multiple UEs (UE 2 and 3 in Fig. 6). The request is sent to the NEF along with a list of UEs, and the NEF processes the list and creates an individual request for each UE on the list. The NEF then forwards these requests to the PCF. The necessary Policy and Charging Control (PCC)^*52 rules for the SMF are then derived by the PCF, and the SMF configures the UPF according to the PCC rules. As a result, one request from the AF determines the QoS of two U-Plane traffic paths (QoS flows) that allow the AF to communicate with two UEs.

  When the AF determines the QoS of multiple sessions with a single request, it may also be necessary to monitor session QoS and resource usage. In that case, along with the session QoS, resource consumption by UEs is monitored and reported to the AF.

  2) PDTQ

  5GC has supported Background Data Transfer (BDT)^*53 policy negotiation since Rel-15. BDT allows the AF to negotiate with the 5GC network to transfer data in a future time window. However, BDT could not support QoS requirements that are important for many AI/ML applications.

  To address this limitation, Rel-18 introduced PDTQ, a new policy negotiation. PDTQ allows the AF to specify the QoS required for data transfer. On the basis of this information, the PCF attempts to find an appropriate time window for transferring the requested data while still meeting the specified QoS requirement. To achieve this task, the PCF can leverage the NWDAF's network analytics (e.g., network performance, device-network performance) to predict the availability of network resources. An example of the overall negotiation procedure is shown in Figure 7.

  In this example, in step (1), the AF sends a PDTQ negotiation request—indicating the target UE (UE 3), required QoS (e.g., 5QI = 7), and desired time windows (e.g., T1 and T2)—to the PCF through the NEF.

  In step (2), the PCF requests analytics from the NWDAF to evaluate the availability of network resources within a possible time window. In step (3), based on the analytics results obtained, a list of suitable future time slots that satisfy the QoS requirement with a high probability is provided to the AF through the NEF. Note that the AF starts requesting QoS flows with the necessary QoS requirement before the selected time window starts.

  In step (4), the PCF continues to monitor the network state after policy negotiation, and if it predicts that the time window previously provided to the AF is no longer appropriate (e.g., availability of network resources changes), it can inform the AF of a new time window (e.g., time window T3) before the original time slot starts.

  

  3.4 FL Assistance on the Application Layer

  5GC specified in Rel-18 introduces an extension to facilitate FL on the application layer in the case that the AF acts as the FL server and the UE acts as the FL client.

  To select a UE as a member of the FL-client group, the AF needs to consider many factors such as the location of the UE, the mobility of the UE, and the ability of the UE to connect to the 5G system. Collecting such a large number of parameters is a complex task for the AF and increases the signaling overhead between the 5GC and the AF.

  To address the above-described issues, in Rel-18, the NEF provides a new service called “member UE selection assistance functionality.” This functionality allows external operators to obtain (i) a list of one or more candidate UEs from a list of eligible member UEs provided by the AF and (ii) additional information based on the assistance information generated by the 5G system according to defined filtering criteria.

  The overall procedure, which consists of five steps, is shown in Figure 8. First, the NEF receives a request from the AF, including an initial UE list, and (optionally) a time window, and one or more filtering criteria (e.g., current location and movement direction of the UE, QoS requirement, DNN, preferred access/Radio Access Technology (RAT) type^*54, etc.) [Fig. 8 (step 1)].

  Then, according to the filtering criteria provided by the AF [Fig. 8 (step 2)], the NEF collects the corresponding data of all UEs in the list of interested member UEs from the relevant 5GC NFs (e.g., PCF, NWDAF, AMF, and SMF) [Fig. 8 (step 3)]. The NEF then derives a list of candidate UEs that satisfy the filtering criteria (i.e., UEs in the initial UE list provided by the AF) [Fig. 8 (step 4)].

  Finally, the NEF provides the AF with assistance information for selecting member UEs, including a list of one or more candidate UEs and, if necessary, other additional information such as one or more recommended time windows for executing application operations, QoS of each target UE, and access/RAT type [Fig. 8 (step 5)]. Additionally, the number of UEs per filtering criterion that do not meet the corresponding filtering criterion can be provided.

  

  1. Offload: The transfer of system, service, or network processing to separate but similar services to reduce the processing load of the original service.
  2. Nnef_AFsessionWithQoS Service: A NEF service that provides service requirements and QoS-monitoring requirements to AFs.
  3. 5QI: A numerical index that refers to a list of parameters that define a particular QoS via a 5G network.
  4. PCC: Session management such as QoS control, policy control for service-data flow, and billing control for network usage in 5G systems.
  5. BDT: Policy for receiving data without direct user intervention, usually, for efficiently transferring large amounts of data during periods of low network load.
  6. RAT type: A radio access technology such as NR, LTE, 3G, GSM, and Wi-Fi.

04. Conclusion

• This article described the extensions to the AI/ML functions ...

  Open

  This article described the extensions to the AI/ML functions provided by 5GC as specified in Rel-18. Specifically, two categories of extensions are described: (i) AI/ML methods for optimizing 5GC operations and (ii) 5GC functions to support AI/ML-based services.

  The first category includes extensions to the NWDAF architecture, capabilities, and services, including accuracy-monitoring capability, roaming architecture, FL between multiple NWDAFs, and numerous new analytics. In addition, matters for study concerning AI/ML described in Rel-19 were briefly discussed.

  The second category includes extensions to the 5GC standard for supporting AI/ML operations including division of AI/ML operation, downloads of ML models, and FL on the application layer.

  Since AI/ML is expected to be increasingly utilized in communication networks in the future, NTT DOCOMO will continue to promote standardization activities in SA2.

• REFERENCES

  Open

  1. [1] 3GPP TR23.700-81 V18.0.0: “Study of Enablers for Network Automation for the 5G System (5GS); Phase 3,” Dec. 2022.
  2. [2] 3GPP TR23.700-80 V18.0.0: “Study on 5G System Support for AI/ML-based Services,” Dec. 2022.
  3. [3] 3GPP TS23.288 V18.5.0: “Architecture enhancements for 5G System (5GS) to support network data analytics services,” Mar. 2024.
  4. [4] 3GPP TS23.502 V18.5.0: “Procedures for the 5G System (5GS); Stage 2,” Mar. 2024.
  5. [5] 3GPP TS23.503 V18.5.0: “Policy and charging control framework for the 5G System (5GS); Stage 2,” Mar. 2024.
  6. [6] 3GPP TR38.843 V18.0.0: “Study on Artificial Intelligence (AI)/Machine Learning (ML) for NR air interface,” Dec. 2023.
  7. [7] 3GPP TR22.874 V18.2.0: “5G System (5GS); Study on traffic characteristics and performance requirements for AI/ML model transfer,” Dec. 2021.

VOL.26 NO.3