ETSI AI Conference 2025

Overview of
AI/ML related work in 3GPP

Presented by:

Dr. Juan Montojo

11/02/2025
Outline
• Scope of standardization of AI/ML
• High level assessment of AI/ML in Cellular Networks
• Former & Ongoing AI/ML standards activities in 3GPP
• Scope of AI/ML for NR Air Interface
• Scope for other 3GPP related AI/ML projects
• AI/ML in NG-RAN
• Enhance Network Automation
• Conclusions

Source sample text 2

Standardization of AI/ML: Scope
• Network and Device implementations have been using AI/ML models to solve certain problems as an
implementation choice complementing / replacing conventional methods
• 3GPP embarked in AI/ML projects to:
• improve performance with the understanding that certain implementations would be using AI/ML for solving certain problems,
• provide operator/infrastructure control
• As a matter of principle, the AI/ML models themselves are not standardized
• Most of the standardization work revolves around the following aspects:
• Infrastructure vendor or mobile operator control and performance monitoring of device-side models
• AI/ML model activation, deactivation, swapping
• Air interface extensions or new device measurements enabling AI/ML model training/inference and their generalization
• Standards-based approaches for Data collection (for training) and Model transfer/delivery (e.g., improved models)
• Training: Online vs. offline
• 3GPP has been assuming thus far offline training of models
• AI/ML models are not deployed (commercially) until they have been fully trained & tested (in the field)
• Computation advances in the future may enable online training
• Model fine-tuning / refinement may be the 1st step

• Testability and consistent device behavior is a key concern

3
AI/ML in Cellular Networks
High Level Assessment

• Good for: • Concerns:

• Data Analytics for, e.g., Network optimization • Testability and Consistent device behavior
• Including putting together data coming from different sources • Feasibility of two-sided AI/ML models
• Solving complex problems with no analytical solution • “Finding problems for solutions” because of the AI hype
• Enabling data-driven solutions not necessarily constrained to single
solution for all cases or complex NW optimizations
• Prediction based on data and context awareness
• Optimal Transmit Beam, Channel State Information, Mobility events…

• Not so good for: • Controversies

• Solving (complex) problems with analytical solution • Data ownership and data sharing
• Complexity and Energy consumption (NW & UE) • Standards mechanism for data collection, model
delivery…

4
 Former & Ongoing AI/ML standards activities in 3GPP
2017 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030

5G R15 5G R16 5G R17 5G R18 5G R19 5G R20 ...

SA 2 Enablers for Network Automation for 5G

SA 5 Management Data Analytics Service

RAN 2/3 NR Data collection for SON/MDT

Functional framework and use cases

RAN 3 for AI/ML in RAN

AI/ML over air-interface Work Item:

RAN 1/2/3/4 • CSI, Beam Management, Positioning

AI/ML over air-interface Study Item:

RAN 2 • Mobility

SON: Self Organizing Networks RAN: Radio Access Network

MDT: Minimization of Driving Tests CSI: Channel State Information 5
AI/ML for NR Air Interface: Scope
• General framework for Life Cycle Management (LCM) of one-sided AI/ML models
Training Data Trained/Updated Model
Model Training

Performance
Feedback /
Retraining Request Model Transfer/
Delivery
Data Monitoring Data Request
Management Model Storage
Collection

NW-sided model UE-sided model Two-sided model Inference Management

Output Instruction

• Use cases: Inference Data

Inference
Model Transfer/Delivery

• Beam Management
• Device/network-sided transmit Beam temporal spatial prediction from subset of beam measurements
• Device/network-sided transmit Beam spatial prediction from subset of beam measurements
• Positioning
• Direct positioning: AI/ML model’s output is the positioning coordinates
• Assisted positioning: AI/ML model’s output is used to compute positioning, e.g., refined/curated measurement
• Channel State Information:
• Temporal prediction
• Compression (study): requires two-sided AI/ML model (device and base-station side)
• Mobility (study in Rel-19)
• AI/ML based Radio Resource Management (RRM) measurement and event prediction
• Cell level measurements; Handover failure/Radio Link Failure (RLF) prediction (UE-side only); Measurement events prediction (UE-side only)
6
ML Workflow - Life cycle for UE models
Focus of 3GPP work on AI/ML for NR Air Interface

Model Model Model Model

design creation deployment execution

Data processing Model storage

Define use case Data Trained
Model
• Extraction • Secure registry Deployed
• Data gathering & • Preparation
model • Access control model Management
analysis • Validation • Configure
• Standards vs • Model retrieval
• Activate
implementation • Inference
Model Model
Data collection development Onboarding
• Training • At device or at network Model monitor
• Device • Performance feedback
• Network • Evaluation • Version control
• Validation • Signing/certification • Deactivate/switch
• Additional sources • Fine-tuning
• Target platform(s) • Registration/revocation

Continuous (offline) Training (fine tuning)

Life cycle is for illustrative purposes to help understand the various steps in AI/ML model development and management 7
4
X 3 options for data collection under RAN2 / SA2 / SA5 discussion
3GPP Rel-19 Work Item status - AI/ML for Air Interface

IP transport • Option 1a – Data collection server OTT (outside the MNO)

• User plane
UE Data Collection server
(UE cloud)
• Proprietary solution (no standards impact)

• Option 1b – Data collection server inside the MNO

IP transport • User plane
UE Data Collection server UE cloud
• UE collects training data and transfers it to the server
• Optionally, the server transfers the data to an OTT server (outside the MNO)

• Option 2 – Data collection server in the Core

NAS or IP transport • Control plane (NAS) or user plane [FFS]
• UE collects training data and transfers it to the CN
UE Data Collection server UE cloud
(MNO CORE) • CN transfers the data to a UE-side model training/OTT server

• Option 3 – Data collection server in the RAN (OAM)

RRC or IP transport • Control plane (RRC) or user plane [FFS]
UE gNB Data Collection server UE cloud
• UE collects training data and transfers it to the OAM
(MNO OAM) • OAM transfers the data to a UE-side model training/OTT server

8
High-level Requirements for Data collection
Agreed principles

1. The data collected is secured and data integrity and confidentiality for that data is ensured.
2. User data privacy, anonymity and user consent is respected.
3. The MNO has full control of the standardized data collection transfer process and can manage
data transfer to the server for UE-side data collection, without the need of SLA for this purpose.
This includes initiating, terminating, and fully managing data transfer.
4. MNO has full visibility for standardized data.
5. The design is futureproof and extendable.
FFS/study if and how to handle non-standardized data (i.e. partial visibility).
FFS controllability on data collection
Standardized Solutions should follow the principle of aiming to minimize air interface overhead and
impact to NW operation

9
4 options for model transfer/delivery under RAN2 discussion
3GPP Rel-19 Work Item status - AI/ML for Air Interface

IP transport • Model repository OTT (outside the MNO)

• User plane
UE Model repository
(UE cloud)
• Proprietary solution (no standards impact)

• Model repository inside the MNO

IP or NAS transport
• User plane or control plane (NAS signaling)
Model repository
UE (CORE cloud)
• Trained, tested, and validated models are stored at the CN

• Model repository in the RAN

IP or RRC transport
• Control plane (RRC) or user plane
• Trained, tested, and validated models are stored at the gNB
UE gNB Model repository • Alternatively, the gNB can transfer parameters sets of standardized/known models
(RAN cloud) (primarily for two-side models) [no need for testing and validation of parameter sets]

• Model repository in the OAM

IP or RRC transport
• Control plane (RRC) or user plane
Model repository
UE gNB
(OAM cloud)
• Trained, tested, and validated models are stored at the OAM
• Delivered via the gNB as in model repository in the RAN

10
AI/ML in NG-RAN (Rel-17 SI, Rel-18/19 WI in RAN3)
• Rel-17 studied and identified high value use cases for AI/ML AI/ML Framework defined in TR 37.817
based optimizations for NG-RAN • ML Model
• A data driven algorithm by applying machine learning
• Rel-18 use cases • Rel-19 use cases techniques that generates a set
of outputs consisting of predicted information, based on
• Network Energy Saving • Coverage and Capacity a set of inputs
• Load Balancing Optimization (CCO)
• Data collection
• Mobility Optimization • Network Slicing • Provides input data to Model training and Model
• Rel-18 functional framework • Mobility Optimization for DC inference functions
• Split architecture support • Model training
• Identified functions to support
AI/ML tasks • Continuous MDT collection • Performs the AI/ML model training, validation, and
testing.
• Life Cycle Management out • Also responsible for data preparation (e.g., data pre-
of scope processing and cleaning, formatting, and
transformation) for model training
• Model inference
Feedback • Provides AI/ML model inference output (e.g., predictions
or decisions)
Training data Model
• Also responsible for data preparation (e.g., data pre-
training processing and cleaning, formatting, and
Model transformation) for model inference
Data Model
deployment/ performance • Actor
Collection update feedback • Receives the output from the Model Inference function
Inference data Model Output and triggers or performs corresponding actions. Actor
Actor may trigger actions directed to other entities or to itself
inference
11
Enhanced Network Automation (since Rel-15 in SA2)
• Network Data Analytics Function (NWDAF) • Rel-18 eNA phase 3
• CN function defined in TS 23.503 • Accuracy monitoring
• Only used for network slice analysis in Rel-15 • Roaming support
• Rel-16 enablers for network • ML model storage, removal and retrieval
automation (eNA) • Model Training logical function (MTLF) registration and
• Data collection: provided by NFs of 5GCN discovery
(AMF, SMF, PCF, UDR, NEF), AFs, OAM and • Access to RAN (OAM/MDA)
data repositories
• FL among multiple NWDAFs
• Data exposure: on demand provisioning of
analytics to NFs of the 5GCN, AF and OAM and • Rel-19 eNA phase 4
data repositories
• NWDAF enhancement
• Rel-17 eNA phase 2 • Support Vertical Federated Learning between NWDAF and AF
• NWDAF framework enhancement • ML model training and provision to support UE assisted LMF-based AI/ML
Positioning and NG-RAN assisted LMF-based AI/ML Positioning.
• NWDAF decomposition; Multiple NWDAF architecture
• Efficient data collection and management • UE data collection
• Status – LS sent that SA2 did not reach consensus on the feasibility, for
• UE application layer data collection
any of the options outlined above, to meet RAN requirements
• NWDAF assisted information for specific features
• Rel-16 feature enhancements

12
AI/ML workflow status
3GPP SA5 has specified a simplified AI/ML workflow

• The following AI/ML “use cases” are specified:

• ML model training
• ML model testing
• AI/ML inference emulation
• ML model deployment AI/ML
ML model ML model ML model AI/ML
• ML model loading training testing
inference
emulation
deployment inference

• ML model registration
• AI/ML inference
• AI/ML inference performance management
• AI/ML update control
Sequence of flow
• AI/ML inference capabilities management
• AI/ML inference capability configuration management
• Executing AI/ML inference

13
Conclusions
Main take-aways for AI/ML in 3GPP

• AI/ML is pervasive and its reach in 3GPP is ever increasing

• There are related projects in 3GPP across Working Groups (WGs) in RAN and SA
• 3GPP currently has no single, unified framework to deal with AI/ML
• Part of the problem is that AI/ML has flourished bottom-up in 3GPP
• Each WG developed its own understanding of AI/ML and studied how it can serve its purpose in the best possible way
• AI/ML was not in scope at the inception of 5G
• Ongoing study in SA (led by Deutsche Telekom) on 3GPP AI/ML Consistency Alignment (TR 22.850)

• Standardization impact of AI/ML is somewhat limited

• AI/ML models themselves are not standardized
• Governance, performance monitoring and requirements are the main drivers for AI/ML standardization
• AI/ML is expected to play an important role in 6G
• More in next slide…

Source sample text 14

What does 6G being AI/ML native really mean?
A personal view

• Formal definition of the meaning of “AI/ML native” not agreed

◦ Although everybody talks about it…

• Some possible interpretations:

◦ AI/ML will be available from Day 1 of 6G
• Application of AI/ML based implementations possibly on top of conventional, non-AI/ML based implementations
• Specific air interface extensions may be required to facilitate the inference process

◦ Specifications could leave some leeway for AI/ML based implementations

• Instead of having, e.g., a rigid set of parameter values, and corresponding, e.g., rigid UE behavior…
• Let AI/ML engines come up with a best data-driven fit-to-purpose parameterization for certain functionalities

• 5G-Advanced has assumed offline training

◦ Should 6G consider the possibility for online training of AI/ML models?
◦ Federated learning has also been considered in the context of eNA and may further propagate elsewhere

15
Thank you
Nothing in these materials is an offer to sell any of the components or devices referenced herein.
© Qualcomm Technologies, Inc. and/or its affiliated companies. All Rights Reserved.
Qualcomm and Snapdragon are trademarks or registered trademarks of Qualcomm Incorporated.
Other products and brand names may be trademarks or registered trademarks of their respective owners.

References in this presentation to “Qualcomm” may mean Qualcomm Incorporated,

Qualcomm Technologies, Inc., and/or other subsidiaries or business units within
the Qualcomm corporate structure, as applicable. Qualcomm Incorporated includes our licensing business, QTL,
and the vast majority of our patent portfolio. Qualcomm Technologies, Inc., a subsidiary of Qualcomm Incorporated,
operates, along with its subsidiaries, substantially all of our engineering, research and development functions, and
substantially all of our products and services businesses, including our QCT semiconductor business.
Snapdragon and Qualcomm branded products are products of Qualcomm Technologies, Inc. and/or its subsidiaries.
Qualcomm patented technologies are licensed by Qualcomm Incorporated.

Follow us on:
For more information, visit us at qualcomm.com & qualcomm.com/blog
16