How we’re solving the standardization challenges of tomorrow’s AI-driven networks

Artificial intelligence (AI) and machine learning (ML) offer transformative potential when it comes to harnessing the capabilities of 5G Advanced and realizing the potential of future networks. It’s an exciting and rapidly evolving space, with freedom to innovate forming a vital part of its foundation. But in some areas – particularly those which rely on interoperability across different networks – standardization also has a key role to play. Where necessary, defined and agreed standards enable seamless integration, scalability and effective lifecycle management of AI/ML models across diverse network deployments and vendor ecosystems. 

As we discussed in a previous blog post, back when the scope for 3GPP Release 19 was agreed, the application of AI and ML in the 5G Radio Access Network (RAN) and the New Radio (NR) physical layer were identified as focus areas for investigation, due to their importance for specific functions such as beam management, positioning, and channel state information (CSI) enhancements. 

Now, over a year later, we’ll share an update on how this journey is progressing, specifically related to the life cycle management aspects. This includes three key challenges: a) model observability, control and signaling; b) data collection at the device and the network; and c) AI/ML model transfer – plus the innovative solutions or approaches we’ve proposed to overcome them. 

AI-driven opportunities

Before we dive in and share the latest standardization developments, let’s briefly review the key radio network functions being standardized in Rel-19. Operating on the NR air interface (the radio frequency communication link between the device and the network), these were identified as focus areas due to their high potential as AI/ML use cases, and as a result, represent core drivers of this work.

Building a future-proof AI/ML framework

A primary objective of 3GPP Release 18 was the development of a generic AI/ML framework. As a key contributor to this work, Ericsson helped define an architecture that would support existing use cases, while also having the flexibility to address future applications. The general framework agreed upon in 3GPP is a future-proof architecture that supports AI/ML at both the device and network sides.  This framework forms the backbone for AI integration, allowing mobile networks to adopt and scale AI-driven functionalities in diverse applications. The major components of this framework include:

1. Lifecycle Management (LCM): A process responsible for AI/ML-related utilization and maintenance, both at the device and the network. This includes model training, inference (where the model is applied to real data to draw a conclusion), performance monitoring, transfer (when learnings from one task are applied to improve performance in another task), deployment, model transfer (the process of transferring AI/ML models across entities within the network) and model updates.
2. Data collection: The efficient collection of high-quality data essential for training AI/ML models, monitoring model performance and running multiple inference processes.

The agreed functional framework for AI/ML for the NR air interface.

A further focus of work in Release 18 was on the usage of this general framework to address the pilot 5G NR air interface use cases we discussed earlier. More specifically, 3GPP studied the feasibility and need for device-to-base-station signaling, to enable network control and management of AI-based features at the device. As the leader of this work, Ericsson has been driving these discussions and ensuring that the AI/ML framework can be easily integrated into the 5G NR architecture – a task that has posed some intricate challenges requiring significant innovation and expertise to overcome. 

Challenge 1: Enabling model observability and control through signaling 

Ericsson has made significant contributions when it comes to shaping the signaling mechanisms required to manage AI/ML model life cycles across the network. An AI model residing in the device (also known as the user equipment, or UE) is referred to as a UE-sided model. A device may deploy multiple AI models to support a specific feature, such as in AI-based beam management. Each model is trained for certain conditions, including different device speeds, locations or network deployments.

As explained earlier, model training, inference, performance monitoring, transfer and deployment are all part of the LCM framework. The device is expected to manage the LCM of individual UE-sided models for each AI-based feature. Simply put, once a feature is activated, the device is responsible for monitoring each model’s performance individually, selecting the best model and switching between models based on the operating conditions. This is referred to as functionality-based LCM. 

This approach decentralizes LCM-related decisions and operates with minimal intervention from the base station. Despite this, the base station still needs to be informed of the AI features supported and operated by the device, so that it can manage the activation and deactivation of specific functionalities, based on need or performance. And this communication requires signaling. 

Traditionally, non-AI features have utilized two interactions between the network and the device:

1. A device signals its capability to support a feature to the base station.
2. Configuration/activation signals are sent to indicate whether the base station activates the feature and how it should be used.

With the rise of AI-based features, there is a third crucial dimension to consider: applicability. Applicability defines the readiness and relevance of AI/ML models to operate effectively in specific network scenarios. How does the device know which model is best to use? It may need assistance to determine whether there are any applicable AI models, and to decide on the best choice. Applicability of a model depends on several factors, including:

• Performance: AI/ML models may perform well in one scenario but underperform in others, due to a lack of training in the scenario in which the inference is performed. For example, a device's model trained to predict beam quality in one cell may not work effectively in a neighboring cell where the beam shapes or transmit power differ.
• Availability on device: Different models may be trained for different scenarios/conditions, but realistically, the device storage is limited and therefore models may be downloaded on-demand.
• Ability to execute: The model may not be able to run due to constraints on the device side, such as low computational power or battery.

Challenge 2: Transforming data collection from the device and the network

Data collection is crucial for building robust models – both UE-side models and those that run in the network (NW) – NW-side models. UE-side data collection faces significant challenges, largely due to the need to tailor models to the individual device. The models generated depend greatly on the hardware and software configurations of the device, resulting in:

• Device-specific data that cannot be standardized and is often unusable at the network side due to its proprietary and specific nature.
• Challenges training UE-side models at the network, particularly at the RAN level, as it is resource-intensive and often impossible – especially since devices from different vendors with different hardware/software properties might need different models, complicating centralized management.
• Issues exposing device implementations, as proprietary device data required for training cannot always be exposed to the network, due to privacy or operational constraints.

Given these factors, UE-side model training is primarily the responsibility of device vendors. However, to fulfill this responsibility, they must have access to the training data collected by their respective devices. 

Network-side data collection and model training

While training of NW-side models can happen at different parts of the network, in this blog post we focus on base station-centric training. 3GPP already supports various mechanisms for measurement reporting from the device to the network, such as Physical Layer Uplink Control Information (UCI) designed for Layer 1 (L1). Although UCI has been widely used for delay-critical and compact data reports, it is ill-suited for the large, latency-tolerant datasets required for NW-sided model training. 

Challenge 3: Ensuring efficiency while reducing complexity in AI/ML model transfer

Finally, the transfer of AI/ML models between the network and the device has been heavily discussed in 3GPP, which explored various approaches to network-device collaboration and focused on two key alternatives:

1. Model delivery over-the-top: The network is not involved in the storing or training of UE models. Models are delivered directly to the device without network-side management.
2. Model transfer from network to device: The network is involved in the transferring of models to the device for execution. This may imply that the model is also stored and trained by the network, or that the device training entity stores and trains the model and interacts with the network for the actual transferring to the device.

While transferring models from the network to the device may offer control and management benefits, it presents several challenges, especially if the network is also in charge of training and storing the UE-side model:

• Extensive engineering for alignment between network and device vendors, as well as significant standardization efforts to exchange the required information.
• Storing and managing models for numerous devices (across vendors and capabilities) would place a substantial burden on the network’s resources. With countless device variations, a one-model-fits-all approach is impractical.

Communication service providers (CSPs) also have interests when it comes to model transfer, primarily around controlling how model updates and downloads utilize network resources – essential factors for managing network efficiency and ensuring a seamless user experience. 

The journey continues toward 6G

The decisions made today will shape the future of mobile networks and their ability to support a wide range of AI-driven applications, for 5G and beyond. It is predicted that AI/ML will be among the key enablers for 6G. This development of new industry standards under 3GPP Release 18 and 19 is just the beginning – setting the stage for a new era of efficiency, performance, adaptability and intelligent automation powered by AI and ML.

As we see it, these technologies are not just an enhancement - they are a core enabler of the mobile networks of tomorrow, and we can’t wait to see what the next challenges and possibilities will hold. 

Read more

Discover more about telecom industry standardization. 
Read this blog post and learn more about the AI standard for 5G RAN. 
Find out what comes next with the timeline and principles for 6G standardization.
Learn more about the use of AI in telecommunications. 
Explore the possibilities of 5G RAN.