Description
ML Model Re-training is a process defined in 3GPP Release 19 as the training of a previous version of an ML model to generate a new version. This process is a critical component of ML Model Lifecycle Management, addressing the fundamental challenge that ML models degrade over time as the data distribution they were trained on diverges from live network conditions—a phenomenon known as concept drift or data drift.
In the context of 3GPP networks, ML models are used for a variety of tasks including network traffic prediction, QoS optimization, mobility management, energy saving, and anomaly detection. These models are trained on historical network data, but network conditions are dynamic: traffic patterns change with time of day, user behavior evolves, new services are introduced, and network topology may change due to infrastructure updates. As a result, a model that performs well at deployment may see its accuracy decline over weeks or months. Re-training addresses this by using the previous model version as a starting point and training it with updated data to produce a new version that better reflects current conditions.
The re-training process typically involves several steps. First, a trigger event initiates re-training. Triggers can be performance-based (e.g., model accuracy drops below a threshold), schedule-based (e.g., periodic re-training every month), or event-based (e.g., significant network changes). Second, new training data is collected, often from the same sources used for initial training but covering a more recent time period. Third, the previous model version is retrieved and used as the basis for training. This can involve techniques such as fine-tuning, where only some model parameters are updated, or full re-training, where the model is retrained from scratch but initialized with the previous version's parameters. Fourth, the new model version is validated and tested before deployment.
Architecturally, ML Model Re-training is performed by an ML model producer, which may be a management system, an AI/ML entity, or a network function with training capabilities. The producer interacts with data sources (e.g., network data repositories, OAM data) to obtain training data. The re-training process is managed through the ML Model Lifecycle Management framework, which coordinates the transition from the old model version to the new one. This includes notifying consumers of the new version, ensuring that the new version meets performance requirements, and managing the rollout to avoid service disruption.
Key considerations in ML Model Re-training include data quality and representativeness. The new training data must be representative of current network conditions; otherwise, the re-trained model may not improve performance. Additionally, re-training must balance the need for adaptation with the risk of overfitting to recent data. Techniques such as regularization, cross-validation, and ensemble methods are used to mitigate these risks. The frequency of re-training is also a trade-off: too frequent re-training increases computational cost and operational complexity, while too infrequent re-training allows model performance to degrade.
ML Model Re-training is closely related to ML Model Testing, as the new version must be tested before deployment. It also interacts with ML Model Lifecycle Management, which provides the overall framework for managing model versions. In 3GPP networks, re-training is particularly important for use cases such as NWDAF-based analytics, where models must continuously adapt to changing traffic patterns, and for RAN intelligent controllers (RICs) in Open RAN architectures, where ML models optimize radio resource management.
Purpose & Motivation
ML Model Re-training exists to address the inherent limitation of static ML models: they become less accurate over time as the environment they operate in changes. In 3GPP networks, this is a significant problem because network conditions are highly dynamic. Traffic patterns shift, new applications emerge, user mobility patterns change, and network infrastructure evolves. A model trained on data from one period may perform poorly in another, leading to suboptimal network decisions and degraded user experience.
The motivation for standardized re-training procedures comes from the need to operationalize AI/ML in production networks. Without a defined re-training process, network operators would have to manually manage model updates, which is impractical at scale. Standardization ensures that re-training can be automated, coordinated across vendors, and integrated into the overall ML Model Lifecycle Management framework. It also provides a common vocabulary and set of procedures that different vendors can implement consistently.
Previous approaches to model maintenance were fragmented. Some systems used periodic retraining without performance monitoring, leading to unnecessary computation. Others relied on manual intervention, which was slow and error-prone. Release 19's definition of ML Model Re-training as part of the lifecycle management framework provides a structured approach that can be triggered by performance degradation, scheduled events, or network changes, ensuring that models remain accurate and reliable throughout their operational life.
What changed in its specifications
The latest release-to-release comparison of specifications that define ML model re-training. Each summary describes the whole specification, not only this term.
Rel-18 brings only minor changes to TS 21.905: 0 clauses changed, with no change attributed to a release feature.
Full comparison in TR 21.905 →Evolution Across Releases
An overview written from the defining specifications, not a verified change history. For the exact text, open the specifications listed below.
Defining Specifications
3GPP specifications that define or reference ML model re-training, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TR 21.905 vj20 | 3GPP Terminology and Definitions | Rel-19 read |