Methods of configuring a set of operational modes for support of ML functionality in a wireless communication system

Abstract

This application describes a method of using pre-configured AI / ML (Artificial Intelligence / Machine Learning) based operation modes per ML functionality in a wireless mobile communication system including base stations (e.g., gNB, TN, NTN) and mobile stations (e.g., UE). When AI / ML models are applied to the radio access network, ML operations using model activation in the LCM phase can degrade due to ML conditions. Therefore, model operations (e.g., model training / inference / monitoring / update) can be established between the network and the UE by configuring applicable operation modes for ML functionality.

Description

Technical Field

[0001] This disclosure relates to a set of ML-based and non-ML-based operating modes, wherein techniques are proposed for pre-configuring and signaling specific information regarding the operating modes and ML functionality applicable to radio access networks. Background Technology

[0002] Within 3GPP (3rd Generation Partnership Project), one of the selected research projects as part of the approved Release 18 package is AI / ML (Artificial Intelligence / Machine Learning), as described in the relevant document (RP-213599) submitted at 3GPP TSG (Technical Specification Group) RAN (Radio Access Networks) meeting #94e. The formal title of the AI / ML research project is "Study on AI / ML for NR Air Interface." The goal of this research project is to establish a common AI / ML framework and areas where AI / ML-based technologies and use cases can yield benefits. According to 3GPP, the primary objective of this research project is to study an AI / ML framework for the air interface by considering performance, complexity, and potential specification impacts from the target use cases. Specifically, AI / ML models, terminology, and descriptions used to establish the general and specific characteristics of the framework are included as one of the key work areas. Regarding the AI / ML framework, various aspects are being researched, and one key project concerns the lifecycle management of AI / ML models, which mandates multiple stages including model training, deployment, inference, monitoring, and updates. Furthermore, in 3GPP, a two-sided (AI / ML) model is defined as a paired AI / ML model on which joint inference is performed, where joint inference includes AI / ML inference jointly performed across the UE and network. Conversely, for a one-sided (AI / ML) model, a UE-side (AI / ML) model is defined as one whose inference is entirely performed at the UE, and a network-side (AI / ML) model is defined as one whose inference is entirely performed at the network. Currently, the AI / ML specification work is in the work project discussion phase for version 19. Earlier, in 3GPP TR 37.817 Release 17, titled "Study onenhancement for Data Collection for NR and EN-DC," UE (User Equipment) mobility was also considered as one of the AI / ML use cases, and one of the scenarios for model training / inference was that both functions reside within the RAN node. Subsequently, in Release 18, a new work project, "Artificial Intelligence (AI) / Machine Learning (ML) for NG-RAN," was launched to specify data collection enhancements and signaling support within the existing NG-RAN interface and architecture.Regarding the aforementioned positive standardization efforts, RAN-based AI / ML models are considered crucial for both the network and the UE to meet any desired model operations (e.g., model training, inference, selection, handover, updates, monitoring, etc.). Model information can be signaled to pair the network-side model and the UE-side model for various lifecycle management (LCM) operations.

[0003] However, the signaling overhead for indicating model information can be very high, especially when processing model-based LCM between the base station (BS / gNB) and multiple UEs. Model training is one of the most critical parts of model deployment in LCM, and currently there are no defined specifications for signaling methods and network-UE behavior to establish the datasets required for model updates / retraining, as any activated model can be affected by model / data drift. When ML conditions change, the enabled AI / ML model may suffer performance degradation due to data / model drift. In such cases, model retraining / update may be necessary. For example, when a trained ML model is deployed in the RAN, model inference performance can easily degrade if the target ML conditions do not perfectly match the true ML conditions measured for a specific model operation.

[0004] US 2023069342 describes how to assist in determining model update timing while taking into account model update costs.

[0005] US 2023022737 explains the support for generating machine learning models when a machine learning model changes.

[0006] US 2019012876 provides estimates, forecasts, and recommendations for computing systems.

[0007] US 2019332895 shows that the monitored state will determine changes such as those made to the currently used trained ML model.

[0008] EP 4075348 describes the control of a machine learning model based on a joint learning method performed by nodes of a decentralized distributed database.

[0009] US 2021019612 provides a self-healing system that can automatically provide diagnostics and can also automatically provide measures if the performance predicted by the model changes over time.

[0010] This application describes a method for using pre-configured AI / ML (Artificial Intelligence / Machine Learning) based operating modes according to ML functionality in a wireless mobile communication system, which includes base stations (e.g., gNB, TN, NTN) and mobile stations (e.g., UE). When an AI / ML model is applied to a radio access network, ML operations performed using model activation during the LCM phase may degrade due to ML conditions. Therefore, model operations (e.g., model training / inference / monitoring / updating) can be established between the network and the UE by configuring an applicable operating mode for ML functionality. Attached Figure Description

[0011] Figure 1 This is an example table showing the mapping between operating modes and ML functionality.

[0012] Figure 2 This is an example table of operating mode options.

[0013] Figure 3 This is an exemplary flowchart for configuring mapping relationships on the network side.

[0014] Figure 4 This is an exemplary flowchart of operating mode switching on the UE side.

[0015] Figure 5 This is an exemplary signaling process for the UE to autonomously decide on the switching of operating modes.

[0016] Figure 6 This is an exemplary signaling procedure by which the network determines the switching of operating modes. Detailed Implementation

[0017] The detailed description set forth below with reference to the accompanying drawings is intended as a description of various configurations and is not intended to represent only configurations in which the concepts described herein can be practiced. The detailed description includes specific details for the purpose of providing a thorough understanding of the various concepts. However, it will be apparent to those skilled in the art that these concepts can be practiced without these specific details. In particular, although terms from 3GPP 5G NR may be used in this disclosure to exemplify embodiments herein, this should not be construed as limiting the scope of the invention.

[0018] Some embodiments of the ideas contemplated herein will now be described more fully with reference to the accompanying drawings. However, other embodiments are also included within the scope of the subject matter disclosed herein, and the disclosed subject matter should not be construed as being limited to the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

[0019] Generally, all terms used herein should be interpreted according to their ordinary meaning in the relevant art, unless a different meaning is expressly given and / or implied in the context of their use. Unless otherwise expressly stated, all references to a / an / said element, device, component, means, step, etc., should be interpreted openly as referring to at least one instance of that element, device, component, means, step, etc. The steps of any method disclosed herein need not be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step, and / or it implies that a step must follow or precede another step. Where appropriate, any feature of any embodiment in the embodiments disclosed herein may be applied to any other embodiment. Similarly, any advantage of any embodiment in the embodiments may be applied to any other embodiment, and vice versa. Other objects, features, and advantages of the appended embodiments will become apparent from the following description.

[0020] In some embodiments, the more general term "network node" may be used, and this term may correspond to any type of radio network node or any network node that communicates with a UE (directly or via another node) and / or another network node. Examples of network nodes are NodeB, MeNB, ENB, network nodes belonging to MCG or SCG, base stations (BS), multi-standard radio (MSR) radio nodes (such as MSR BS), eNodeB, gNodeB, network controller, radio network controller (RNC), base station controller (BSC), repeater, donor node controlling repeater, base transceiver station (BTS), access point (AP), transport point, transport node, RRU, RRH, nodes in distributed antenna system (DAS), core network nodes (e.g., mobile switching center (MSC), mobility management entity (MME), etc.), operations and maintenance (O&M), operations support system (OSS), self-optimizing network (SON), location nodes (e.g., evolved servicing mobile location center (E-SMLC)), minimized drive test (MDT), test equipment (physical node or software), etc.

[0021] In some embodiments, the non-limiting terms User Equipment (UE) or Wireless Device may be used, and the term may refer to any type of wireless device that communicates with a network node and / or with another UE in a cellular or mobile communication system. Examples of UEs are target devices, device-to-device (D2D) UEs, machine-type UEs or UEs capable of machine-to-machine (M2M) communication, PDAs, PADs, tablet computers, mobile terminals, smartphones, laptop embedded devices (LEE), laptop mounted devices (LME), USB dongles, UE class M1, UE class M2, ProSe UE, V2V UE, V2X UE, etc.

[0022] Additionally, terms such as base station / gNodeB and UE should be considered non-restrictive and, in particular, do not imply any hierarchical relationship between the two; generally, "gNodeB" can be considered device 1 and "UE" can be considered device 2, and the two devices communicate with each other via a radio channel. Furthermore, in the following text, a transmitter or receiver can be a gNodeB (gNB) or a UE.

[0023] As those skilled in the art will understand, aspects of the embodiments can be embodied as a system, device, method, or program product. Therefore, embodiments can take the form of purely hardware embodiments, purely software embodiments (including firmware, resident software, microcode, etc.), or embodiments combining software and hardware aspects.

[0024] For example, the disclosed embodiments may be implemented as hardware circuitry including custom-designed very large-scale integration (“VLSI”) circuitry or gate arrays, off-the-shelf semiconductors (such as logic chips, transistors, or other discrete components). The disclosed embodiments may also be implemented in programmable hardware devices (such as field-programmable gate arrays, programmable array logic, programmable logic devices, etc.). As another example, the disclosed embodiments may include one or more physical or logical blocks of executable code, which may, for example, be organized as objects, procedures, or functions.

[0025] Furthermore, embodiments may take the form of a program product embodied in one or more computer-readable storage devices that store machine-readable code, computer-readable code, and / or program code (hereinafter referred to as code). The storage device may be tangible, non-transitory, and / or non-transferable. The storage device may not contain signals. In one embodiment, the storage device uses only signals to access the code.

[0026] Any combination of one or more computer-readable media may be used. A computer-readable medium may be a computer-readable storage medium. A computer-readable storage medium may be a storage device for storing code. A storage device may be, for example, but not limited to, electronic, magnetic, optical, electromagnetic, infrared, holographic, micromechanical, or semiconductor systems, devices, or apparatuses, or any suitable combination of the foregoing.

[0027] More specific examples of storage devices (a non-exhaustive list) will include the following: electrical connections having one or more wires, portable computer floppy disks, hard disks, random access memory (“RAM”), read-only memory (“ROM”), erasable programmable read-only memory (“EPROM” or flash memory), portable optical disc read-only memory (“CD-ROM”), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing. In the context of this document, a computer-readable storage medium can be any tangible medium that can contain or store programs for use by or in conjunction with an instruction execution system, device, or apparatus.

[0028] The code used to perform the operations of the embodiments can be any number of lines and can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Python, Ruby, Java, Smalltalk, C++, etc., as well as conventional procedural programming languages ​​such as the "C" programming language, and / or machine languages ​​such as assembly language. The code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer via any type of network, including a local area network ("LAN"), a wireless LAN ("WLAN"), or a wide area network ("WAN"), or can be connected to an external computer (e.g., via the Internet through an Internet service provider ("ISP").

[0029] Furthermore, the features, structures, or characteristics described in the embodiments can be combined in any suitable manner. Numerous specific details, such as examples of programming, software modules, user selection, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., are provided in the following description to provide a thorough understanding of the embodiments. However, those skilled in the art will recognize that the embodiments can be practiced without one or more of the specific details in the details or using other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the embodiments. References to “an embodiment,” “embodiment,” or similar language throughout the specification mean that a particular feature, structure, or characteristic described in connection with that embodiment is included in at least one embodiment. Therefore, unless expressly stated otherwise, the phrases “in one embodiment,” “in an embodiment,” and similar language appearing throughout the specification may, but not necessarily all, refer to the same embodiment, but rather mean “one or more, but not all, embodiments.” Unless expressly stated otherwise, the terms “comprising,” “including,” “having,” and variations thereof mean “including, but not limited to,” “including.” Unless expressly stated otherwise, an enumeration list of items does not imply that any or all of the items are mutually exclusive. Unless otherwise expressly stated, the terms “a,” “an,” and “the / said” also mean “one or more.”

[0030] The following description refers to schematic flowcharts and / or schematic block diagrams of methods, apparatus, systems, and program products according to embodiments. It should be understood that each block of the schematic flowcharts and / or schematic block diagrams, and combinations of blocks of the schematic flowcharts and / or schematic block diagrams, can be implemented by code. This code can be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to produce a machine such that instructions executable via the processor of the computer or other programmable data processing apparatus create means for implementing the functions / actions specified in the flowcharts and / or block diagrams.

[0031] The code may also be stored in a storage device that can instruct a computer, other programmable data processing device or other device to operate in a particular manner, such that the instructions stored in the storage device produce an article of art, which includes instructions that implement the functions / actions specified in the flowchart and / or block diagram.

[0032] The code may also be loaded onto a computer, other programmable data processing device or other apparatus to cause a series of operational steps to be performed on the computer, other programmable device or other apparatus, thereby producing a computer-implemented process, such that the code executing on the computer or other programmable device provides a process for implementing the functions / actions specified in the flowchart and / or block diagram.

[0033] The flowcharts and / or block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of devices, systems, methods, and program products according to various embodiments. In this regard, each block in the flowcharts and / or block diagrams may represent a module, segment, or portion of code, which includes one or more executable instructions for implementing a specified logical function.

[0034] It should also be noted that in some alternative implementations, the functions indicated within the boxes may not appear in the order shown in the figures. For example, depending on the functionality involved, two boxes shown consecutively may actually be executed substantially simultaneously, or these boxes may sometimes be executed in reverse order. Other steps and methods that are functionally, logically, or effectively equivalent to one or more boxes or portions thereof in the illustrated figures are conceivable.

[0035] While various arrow and line types may be used in flowcharts and / or block diagrams, they should be understood not to limit the scope of the corresponding embodiments. In fact, some arrows or other connectors may be used only to indicate the logical flow of the depicted embodiment. For example, an arrow may indicate a wait or monitoring period of unspecified duration between enumeration steps in a depicted embodiment. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, may be implemented by a system based on dedicated hardware or a combination of dedicated hardware and code that performs the specified function or action.

[0036] The description of the elements in each figure can be referenced to the elements in the preceding figures. In all figures, similar designations refer to similar elements, including alternative embodiments of similar elements.

[0037] The detailed description set forth below with reference to the accompanying drawings is intended as a description of various configurations and is not intended to represent only configurations in which the concepts described herein may be practiced. The detailed description includes specific details for the purpose of providing a thorough understanding of the various concepts. However, it will be apparent to those skilled in the art that these concepts may be practiced without these specific details. For example, although 3GPP terms, such as 5G NR, may be used in this disclosure to exemplify embodiments herein, this should not be construed as limiting the scope of this disclosure.

[0038] This disclosure relates to a wireless communication system, which may be, for example, a 5G NR wireless communication system. More specifically, it refers to a RAN (Radio Access Network) within the wireless communication system for exchanging data with a UE via radio signals. For example, the RAN may transmit data to the UE (Downlink DL), such as data received from the core network (CN). The RAN may also receive data from the UE (Uplink UL), which may be forwarded to the CN.

[0039] In the illustrated example, the RAN includes a base station (BS). Of course, the RAN may include more than one BS to increase the coverage of the wireless communication system. Depending on the implemented wireless communication standard, each of these BSs may be referred to as an NB, eNodeB (or eNB), gNodeB (or gNB in ​​the case of a 5G NR wireless communication system), access point, etc.

[0040] The UE is located within the coverage of the BS. The coverage of the BS corresponds, for example, to an area where the UE can decode the PDCCH transmitted by the BS.

[0041] Examples of wireless devices suitable for implementing any of the methods discussed in this disclosure at the UE correspond to devices that provide wireless connectivity to a RAN (Radio Range) of a wireless communication system and can be used to exchange data with said RAN. Such wireless devices may be included in the UE. The UE may be, for example, a cellular phone, a wireless modem, a wireless communication device, a handheld device, a laptop computer, etc. The UE may also be an Internet of Things (IoT) device, such as a wireless camera, a smart sensor, a smart meter, smart glasses, a (manned or unmanned) vehicle, a GPS device, etc., or any other device capable of running applications that require the exchange of data with a remote receiver via a wireless device.

[0042] The wireless device includes one or more processors and one or more memories. The one or more processors may include, for example, a central processing unit (CPU), a digital signal processor (DSP), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), etc. The one or more memories may include any type of computer-readable volatile and non-volatile memory (magnetic hard disk, solid-state drive, optical disk, electronic storage, etc.). The one or more memories may store a computer program product in the form of a set of program code instructions to be executed by the one or more processors to implement all or part of the steps of a method for exchanging data executed on the UE side according to any embodiment of the embodiments disclosed herein.

[0043] The wireless device may also include a main radio (MR) unit. The MR unit corresponds to the main wireless communication unit of the wireless device, which is used to exchange data with the BS of the RAN using radio signals. The MR unit may implement one or more wireless communication protocols and may be, for example, a 3G, 4G, 5G, NR, WiFi, WiMax, or other transceivers. In a preferred embodiment, the MR unit corresponds to a 5G NR wireless communication unit.

[0044] The following explanation provides a detailed description of the mechanism for pre-configuring and signaling specific information about online model training by configuring a set of UE behaviors. AI / ML-based technologies are currently applied to many different applications, and based on observed potential benefits, 3GPP has also begun its technology research for application to multiple use cases. The AI / ML lifecycle can be broken down into several phases, such as data collection / preprocessing, model training, model testing / validation, model deployment / update, and model monitoring, each of which is equally important for achieving the target performance of any particular model. One of the challenging issues when applying AI / ML models to any use case or application is managing the AI / ML model lifecycle. This is primarily because data / model drift occurs during model deployment / inference, and it can lead to performance degradation of the AI / ML model. Fundamentally, dataset statistics change after the model is deployed, and the model's inference capabilities are also affected by unseen data as input. Similarly, the statistical properties of the dataset and the relationship between the inputs and outputs of the trained model can change with drift.

[0045] In this context, model training or retraining is one of the key issues in maintaining model performance, as model performance, such as inference and / or training, depends on different model execution environments with varying configuration parameters. To address this issue, collaboration between the UE and gNB is crucial for tracking model performance and reconfiguring models to correspond to different environments. Since model performance cannot be consistently maintained due to drift, AI / ML models require model monitoring after deployment, followed by providing update feedback to retrain / update the model or select an alternative model. When deploying a wireless communication network with AI / ML models enabled, it is then important to consider how to handle active AI / ML models for the wireless device using reconfiguration during operations such as model training, inference, and updates. ML operations performed using model activation during the LCM phase may degrade due to dynamic ML conditions, and therefore, depending on channel conditions and / or ML capability status, fallback operations such as non-ML modes may be even better. In this approach, a set of operational modes supporting ML functionality is configurable, such that each ML functionality can be supported by one or more ML models or model IDs. The list of operating modes may include ML mode, non-ML mode, and hybrid mode (e.g., ML-assisted non-ML mode, non-ML-assisted ML mode). The mapping relationship between operating modes and ML functionality can be sent via system information or dedicated RRC signaling. One or more ML models or model IDs may also be associated together with the mapping relationship information. Based on changing implementation conditions (e.g., ML application, LCM stage, environmental conditions, device ML conditions, model specific information, etc.), the frequency level of operating mode switching can be event-triggered or periodic. If applicable, operating mode switching may support ML degradation or threshold-based model complexity adjustment (e.g., switching scenarios from ML mode to hybrid mode). The initial operating mode settings for activation can be managed by the network side. Updates to UE ML capabilities or ML conditions can be fed back to the network side to determine the activation of any specific operating mode.

[0046] For example, dataset / model ID is part of the requirements for preparing to activate ML mode. If applicable, the choice of operation mode for any specific ML functionality and / or model can be prioritized in advance among multiple available modes. In non-ML mode or hybrid mode operation, any available collected datasets for model input can also be used for online training of the specific model. The mapping between operation modes and ML functionality can be pre-configured. Mode_Set #i can contain one or more available operation modes, which can also be prioritized by indication. If applicable, the set of models for MF#i can also be associated in the mapping information. Any changes / updates to the mapping information can be provided via L1 / L2 or RRC signaling. For ML-assisted non-ML modes in hybrid mode, the non-ML mode is activated with the support of degraded ML operations such as model complexity tuning and / or collection of smaller datasets for use. For non-ML-assisted ML modes in hybrid mode, the ML mode is activated with the support of parallel non-ML operations. Any available collected datasets for model input can be used for online training of the specific model.

[0047] Figure 1 An exemplary table illustrating the mapping between operation modes and ML functionalities is shown. In this example, the mapping between operation modes and ML functionalities can be pre-configured. Mode_Set #i may contain one or more available operation modes, which can also be prioritized by indication. If applicable, the set of models for MF #i can also be associated in the mapping information. The set of supported operation modes for ML functionalities can be configured such that each ML functionality can be supported by one or more ML models or model IDs.

[0048] Figure 2 An exemplary table of operation mode options is shown. In this example, the list of operation modes may include ML mode, non-ML mode, and hybrid mode (e.g., ML-assisted non-ML mode, non-ML-assisted ML mode). For ML-assisted non-ML mode in hybrid mode, the non-ML mode is activated with the support of degraded ML operations such as model complexity tuning and / or collection of smaller datasets for use. For non-ML-assisted ML mode in hybrid mode, the ML mode is activated with the support of parallel non-ML operations. Any available collected dataset for model input can be used for online training of a specific model. In non-ML mode or hybrid mode operation, any available collected dataset for model input can also be used for online training of a specific model.

[0049] Figure 3An exemplary flowchart for configuring mapping relationships on the network side is shown. In this example, a set of operational modes for supporting ML functionality can be configured on the network side, such that each ML functionality can be supported by one or more ML models or model IDs.

[0050] Figure 4 An exemplary flowchart for switching operating modes on the UE side is shown. In this example, the applicable operating mode can be switched based on pre-configured mapping information provided by the network side. Where applicable, the operating mode switching can support ML degradation or threshold-based model complexity adjustments (e.g., a switch from ML mode to hybrid mode). The initial operating mode setting for activation can be managed by the network side. Updates to UE ML capabilities or ML conditions can be fed back to the network side to determine the activation of any particular operating mode.

[0051] Figure 5 An exemplary signaling flow for a UE to autonomously decide on an operating mode switch is illustrated. In this example, after the network side provides mapping information, the UE can autonomously activate any specific operating mode and can also autonomously perform an operating mode switch.

[0052] Figure 6 An exemplary signaling flow for the network to determine an operating mode switch is illustrated. In this example, when the active operating mode state is reported, the network side instructs an operating mode switch, allowing the UE to perform the operating mode switch based on the instruction message.

Claims

1. A method for configuring a set of operating modes for supporting ML functionality in a wireless communication system, the method comprising: • Determine the mapping relationship between operating modes and ML functionality; • Define the operation mode; • If applicable, associate the set of model IDs with the mapping information; • Provide mapping relationship information to the UE.

2. The method according to claim 1, wherein, Each ML functionality can be supported by one or more ML models or model IDs.

3. The method according to any one of the preceding claims, wherein, The list of operating modes can include ML mode, non-ML mode and hybrid mode, wherein the hybrid mode can be ML-assisted non-ML mode and / or non-ML-assisted ML mode.

4. The method according to any one of the preceding claims, wherein, The mapping between operating modes and ML functionality can be sent via system information or dedicated RRC signaling.

5. The method according to any one of the preceding claims, wherein, One or more ML models or model IDs can be associated together with the mapping relationship information.

6. The method according to any one of the preceding claims, wherein, Based on the changing implementation conditions, the frequency level of operation mode switching can be event-triggered or periodic. The changing implementation conditions can be ML application and / or LCM stage, environmental conditions and / or device ML conditions and / or model specific information.

7. The method according to any one of the preceding claims, wherein, If applicable, the operation mode switching can support ML degradation or threshold-based model complexity adjustment, such as switching from ML mode to hybrid mode.

8. The method according to any one of the preceding claims, wherein, The initial operating mode settings used for activation can be managed by the network side.

9. The method according to any one of the preceding claims, wherein, UE ML capabilities or ML condition updates can be fed back to the network side to determine the activation of any specific operating mode.

10. The method according to any one of the preceding claims, wherein, Dataset / model ID is part of the requirements for preparing to activate ML mode.

11. The method according to any one of the preceding claims, wherein, If applicable, the choice of operating mode for any particular ML functionality and / or model can be prioritized in advance among multiple available modes.

12. The method according to any one of the preceding claims, wherein, In non-ML mode or hybrid mode operation, any available collected dataset for model input can be used for online training of a specific model.

13. The method according to any one of the preceding claims, wherein, One or more available operating modes belonging to a specific set of operating modes can be prioritized by indication.

14. The method according to any one of the preceding claims, wherein, If applicable, a set of models for a specific ML functionality can be associated in mapping relationship information.

15. The method according to any one of the preceding claims, wherein, Any changes / updates to the mapping information can be provided via L1 / L2 or RRC signaling.

16. The method according to any one of the preceding claims, wherein, Non-ML mode (ML-assisted non-ML mode in hybrid mode) is activated with the support of degraded ML operations such as model complexity tuning and / or collection of smaller datasets for use.

17. The method according to any one of the preceding claims, wherein, The ML mode (non-ML-assisted ML mode in the hybrid mode) is activated with the support of parallel non-ML operations.

18. The method according to any one of the preceding claims, wherein, Any available collected dataset used as model input can be used for online training of a specific model.

19. An apparatus for configuring a set of operating modes for supporting ML functionality in a wireless communication system, the apparatus comprising a wireless transceiver, a processor coupled to a memory, the memory storing computer program instructions configured to implement the steps of claims 1 to 18.

20. A user equipment comprising the device according to claim 19.

21. A gNB comprising the device according to claim 19.

22. A wireless communication system for configuring a set of operating modes supporting ML functionality, wherein, The wireless communication system includes at least one user equipment according to claim 20 and at least one gNB according to claim 21, wherein each of the user equipment and the gNB includes a processor coupled to a memory in which computer program instructions are stored, the instructions being configured to implement the steps as claimed in claims 1 to 18.

Images