Functionality-based lifecycle management

Description

Functionality-based lifecycle management is a Rel-19 concept introduced to manage the lifecycle of machine learning (ML) functionalities in 3GPP networks. It defines a signalling procedure where the network explicitly indicates to the UE (or other network nodes) whether to activate, deactivate, fallback, or switch a specific ML functionality. This control is exercised through standard 3GPP signalling mechanisms, including Radio Resource Control (RRC) messages, Medium Access Control Control Elements (MAC-CE), and Downlink Control Information (DCI). The procedure operates based on at least one configuration of an ML-enabled Feature or Feature Group, or on specific configurations thereof. This allows the network to dynamically adapt ML usage according to changing conditions, such as traffic load, channel state, or UE capabilities.

The architecture behind functionality-based lifecycle management involves several key components. First, ML-enabled Features and Feature Groups are defined as logical entities that encapsulate specific ML algorithms or models. Each feature or group can have multiple configurations, representing different operational modes or parameter sets. The network, typically via the gNB, maintains control over which configuration is active. When the network decides to change the ML functionality state, it sends a signalling message to the UE. For example, an RRC message might activate a particular ML feature, while a MAC-CE could quickly deactivate it to save power. DCI can be used for fast switching in the physical layer. The UE must support the reception and processing of these signals, and it must apply the requested state change to its ML operations.

The procedure supports four main actions: activation, deactivation, fallback, and switching. Activation turns on an ML feature that was previously inactive. Deactivation turns it off, potentially reverting to a non-ML baseline. Fallback allows the network to instruct the UE to revert to a legacy, non-ML algorithm if the ML performance degrades or if conditions change. Switching changes from one ML configuration to another, possibly to adapt to a different use case or to load a different model. These actions can be triggered by various events, such as changes in radio conditions, network slicing requirements, or energy-saving policies.

Functionality-based lifecycle management is crucial for the practical deployment of ML in 5G-Advanced networks. It provides a standardized way for the network to control ML usage, ensuring interoperability between vendors and enabling dynamic optimization. Without such a mechanism, ML features would be static and unable to adapt to real-time network dynamics. This procedure also helps manage UE power consumption, as ML computations can be intensive; deactivation when not needed saves battery. Furthermore, it supports fallback to ensure robustness and reliability, which is essential for critical services.

The concept is defined in 3GPP TS 21.905, which is the vocabulary for 3GPP specifications. As ML is increasingly integrated into 5G and future 6G systems, lifecycle management will become a fundamental capability. It aligns with the broader trend of network automation and intelligence, where the network not only configures radio parameters but also manages the AI/ML models that optimize them. This term is part of the Rel-19 work on AI/ML for NR air interface, and it is expected to evolve as more ML use cases are standardized.

Purpose & Motivation

Functionality-based lifecycle management exists to provide a standardized, network-controlled mechanism for managing machine learning functionalities in 3GPP networks. As ML becomes integral to 5G-Advanced and 6G, there is a need to dynamically control when and how ML models are used. Previous approaches lacked a unified way to activate, deactivate, or switch ML features via standard signalling. This procedure solves that by defining explicit signalling actions, enabling the network to adapt ML usage in real time. It also addresses the need for fallback to non-ML algorithms to ensure reliability and interoperability. The motivation is to make ML deployment practical, efficient, and robust, while minimizing UE power consumption and ensuring consistent behavior across vendors.