Handling of ai / ml configuration and collected measurements at mobility

Abstract

Methods are disclosed for UE handling of arrangements of AI / ML related measurements and data collected but not yet transferred to the network in case of termination or loss of network connection. This can include mobility operations (e.g., handover); RRC state transitions; radio link failure; or change of PSCell. From configuration information received from a source network node specifying measurement and data collection for AI / ML model training, the UE handles the AI / ML data according to one of several procedures. The UE can delete it; send it to a target RAN node (with which the UE reestablishes network connection); continue performing AI / ML measurements; indicate to the target RAN node availability of previously collected data; or indicate to the target RAN node whether the source node configured AI / ML measurement configuration.

Description

[0001] Related applications This application claims priority to U.S. Provisional Patent Application No. 63 / 547317, filed November 3, 2023, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This disclosure generally relates to wireless communication networks, and more particularly to systems and methods for processing AI / ML-related measurements and data collected by a UE but not yet transmitted to the network during mobility operations. Background Technology

[0003] Artificial intelligence (AI) and machine learning (ML) have been studied in both academia and industry as promising tools for optimizing air interface design in wireless communication networks. Example use cases include: using autoencoders for channel state information (CSI) compression to reduce feedback overhead and improve channel prediction accuracy; using deep neural networks for line-of-sight (LOS) and non-LOS (NLOS) condition classification to enhance positioning accuracy; using reinforcement learning for beam selection on the network side and / or user equipment (UE) side to reduce signaling overhead and beam alignment delay; and using deep reinforcement learning to learn optimal precoding strategies for complex multiple-input multiple-output (MIMO) precoding problems.

[0004] In the 3GPP New Radio (NR) standardization work, the new version 18 research project on AI / ML for the NR air interface was initiated in May 2022. This research project will explore the benefits of enhancing the air interface through features that enable improved support for AI / ML-based algorithms to enhance performance and / or reduce complexity / overhead. By studying several selected use cases (CSI feedback, beam management, and positioning), this research project aims to lay the foundation for future air interface use cases leveraging AI / ML technologies. Summary of the Invention

[0005] This disclosure proposes a method at a user equipment (UE) for data collection by the UE and for reporting the collected data to a target RAN network node or any other target mobile network node, such as OAM, for AI / ML model training purposes. The target RAN node can be a target node for successful mobility operation; a node with which the UE re-establishes its connection after experiencing a radio link failure or handover failure; a node with which the UE restores its connection upon successful primary cell group (MCG) fast link recovery; or a node with which the UE reconnects after transitioning from RRC_IDLE or RRC_INACTIVE mode to RRC_CONNECTED.

[0006] The method comprises four basic steps. In the first step, the UE receives one or more configuration information items from the first serving / source RAN node. The one or more configuration information items instruct the UE to perform and / or collect measurements for AI / ML model training.

[0007] In the second step, the UE performs AI / ML measurement collection based on the measurement configuration information provided by the first node. Data collection means that the UE records the collected data in its memory.

[0008] In the third step, perform one of the following operations: mobility operation; RRC state transition; radio link failure; or PSCell change.

[0009] In the fourth step, in response to the actions in step 3, data collected based on the AI / ML measurement configuration, which has been recorded but not yet sent to the network (or not retrieved by the network), is processed according to one of several procedures. The UE may delete it; send it to the target RAN node; continue performing AI / ML measurements; indicate to the target RAN node the availability of the previously collected data; or indicate to the target RAN node whether the source node has configured an AI / ML measurement configuration.

[0010] This disclosure further proposes a method for a source RAN node and a target RAN node, wherein the two nodes communicate about the status of AI / ML measurements collected by the UE but not yet transmitted.

[0011] One aspect relates to a method for processing AI / ML-related information performed by a UE operable in a wireless communication network. This involves receiving configuration information from a source network node specifying measurement and data collection for AI / ML model training. AI / ML-related measurement and data collection is performed according to the configuration information, and the collected data is stored. The network connection to the source network node is terminated or lost. The collected AI / ML-related measurements and data, but not yet transmitted to the network, are processed according to the configuration information.

[0012] On the other hand, this relates to a user equipment (UE) operable in a wireless communication network implementing AI / ML. The UE includes communication circuitry configured to communicate with one or more network nodes, and processing circuitry operably connected to the communication circuitry. The processing circuitry is configured to perform the methods described above.

[0013] Another embodiment relates to a method for managing AI / ML-related information, performed by an operable source network node in a wireless communication network. This serves the UE. Configuration information specifying measurements and data collection for AI / ML model training is transmitted to the UE. The network connection to the UE is terminated or lost. Configuration information specifying measurements and data collection performed by the UE for AI / ML model training is transmitted to a target network node to which the UE subsequently connects.

[0014] Another aspect involves a source network node operable in a wireless communication network implementing AI / ML. The source network node includes communication circuitry configured to communicate with one or more network nodes, and processing circuitry operatively connected to the communication circuitry. The processing circuitry is configured to perform the methods described above.

[0015] Another aspect involves a method for managing AI / ML-related information, performed by an operable target network node in a wireless communication network. This method serves the UE after the UE terminates or loses its network connection to the source network node. It receives AI / ML-related measurements and data collected by the UE when it connected to the source network node but which have not yet been transmitted to the network. It then transmits the AI / ML-related measurements and data collected by the UE to the source network node.

[0016] Another aspect involves a target network node operable in a wireless communication network implementing AI / ML. The target network node includes communication circuitry configured to communicate with one or more network nodes, and processing circuitry operatively connected to the communication circuitry. The processing circuitry is configured to perform the methods described above. Attached Figure Description

[0017] Figure 1 This is a block diagram illustrating the ML model training and inference pipeline and its interactions within the model lifecycle management process.

[0018] Figure 2 This is a block diagram illustrating a functional framework for AI research on different NW-UE collaboration levels for PHY use cases.

[0019] Figure 3 This is a block diagram of a CSI report based on an autoencoder (AE) using linked UE-side and NW-side ML models.

[0020] Figure 4 This is a signaling diagram illustrating the overall approach by which the UE handles AI / ML configuration and collected measurements during mobility operations / events.

[0021] Figure 5 This is a signaling diagram showing how the UE handles the collected AI / ML data after a mobility operation by deleting it.

[0022] Figure 6 This is a signaling diagram showing how the UE processes AI / ML data by transmitting the collected AI / ML data to the target network node after a mobility operation.

[0023] Figure 7 This is a signaling diagram showing how the UE processes the collected AI / ML data by continuing to record AI / ML data after a mobility operation.

[0024] Figure 8 This is a flowchart of the method for handling AI / ML information executed by the UE.

[0025] Figure 9 This is a flowchart of the method for controlling AI / ML information executed by the source network node.

[0026] Figure 10 This is a flowchart of a method for controlling AI / ML information executed by the target network node.

[0027] Figure 11 This is a hardware block diagram of a wireless device.

[0028] Figure 12 This is a hardware block diagram of a network node. Detailed Implementation

[0029] Network nodes can be RAN nodes, OAM, core network nodes, OAM, SMO, network management system (NMS), non-real-time RAN intelligent controller (Non-RT RIC), real-time RAN intelligent controller (RT-RIC), gNB, eNB, en-gNB, ng-eNB, gNB-CU, gNB-CU-CP, gNB-CU-UP, eNB-CU, eNB-CU-CP, eNB-CU-UP, IAB nodes, IAB donor DU, IAB donor CU, IAB-DU, IAB-MT, O-CU, O-CU-CP, O-CU-UP, O-DU, O-RU, O-eNB, UE, M2M device, MTC device, or NB-IoT device.

[0030] The reference to "network node" in this article should be understood as follows: a network node can be a physical node or a function or any kind of logical entity, such as a software entity implemented in a data center or cloud (e.g., using one or more virtual machines), and two network nodes can be well implemented as logical software entities in the same data center or cloud.

[0031] Unless otherwise explicitly stated, the terms model training, model optimizing, model optimization, and model updating are used interchangeably and have the same meaning in this document.

[0032] Unless otherwise expressly specified, the terms model change, modification, or similar terms are used interchangeably and have the same meaning in this document. In particular, they refer to the fact that the type, structure, parameters, or connectivity of the AI / ML model may have changed compared to the previous format / configuration of the AI / ML model.

[0033] As used herein, the term "model" refers to one or more data structures and / or algorithms used to generate predictions from collected input data. Unless otherwise expressly specified, the terms "model," "ML model," "AI model," "AI / ML model," and "AI and / or ML model," "AI / ML strategy," "AI / ML algorithm," and the terms model, strategy, or algorithm should be considered equivalent and used interchangeably. An AI / ML model can be defined as a feature or part of a functionality deployed / implemented in a first node, for example, in the case of a UE-side model, where the first node is the user equipment (UE, also known as a wireless device or WD). An AI / ML model can be defined as a feature or part of a feature implemented / supported in a first node. This first node can indicate the feature version to a second node. If the ML model is updated, the first node can change the feature version.

[0034] The method provided by this invention is independent of specific AI / ML model types or learning problems / settings (e.g., supervised learning, unsupervised learning, reinforcement learning, hybrid learning, centralized learning, federated learning, distributed learning, etc.).

[0035] Non-limiting examples of AI / ML algorithms may include supervised learning algorithms, deep learning algorithms, reinforcement learning type algorithms (such as DQN, A2C, A3C, etc.), contextual multi-armed slot machine algorithms, autoregressive algorithms, etc., or combinations thereof.

[0036] Such algorithms can utilize functional approximation models, hereinafter referred to as AI / ML models, such as neural networks (e.g., feedforward neural networks, deep neural networks, recurrent neural networks, convolutional neural networks, etc.).

[0037] Examples of reinforcement learning algorithms may include deep reinforcement learning (such as deep Q-networks (DQN), proximal policy optimization (PPO), double Q learning), actor-commentator algorithms (such as superior actor-commentator algorithms, such as A2C or A3C, actor-commentator algorithms with experience replay, etc.), policy gradient algorithms, off-policy learning algorithms, etc.

[0038] AI / ML models can correspond to functions that receive one or more inputs (e.g., measurements, configurations, etc.) and provide one or more predictions / estimates of a specific type (e.g., time-domain and / or spatial-domain predictions of beam measurements) as a result. In one example, an ML model can correspond to a function that receives (e.g., transmitted in beam-X) a measurement of a reference signal at time instance t0 as input and provides a prediction of the reference signal at time time t0+T as a result.

[0039] In another example, the ML model may correspond to the measurement of a reference signal X (such as an SSB indexed 'x') received (e.g., transmitted in beam-x) as input, and as output the prediction of other reference signals (e.g., reference signal Y (such as an SSB indexed 'x') transmitted in different beams).

[0040] Another example is the ML model used to assist CSI estimation—in such a setup, the joint ML model would include a specific ML model for the UE and an ML model on the NW side. The two ML models jointly provide joint network functionality. The function of the ML model on the UE would be to compress the channel input, and the function of the ML model on the NW side would be to decompress the output received from the UE.

[0041] It is further possible to apply a similar scheme to positioning, where the input could be, for example, some form of channel pulse related to a specific time-varying reference point (typically the TP (transmission point)). The objective on the NW side would be to detect different peaks within the impulse response, reflecting the multipath experienced by the radio signal arriving at the UE. Another example for positioning is to input multiple sets of measurements into the ML network and derive the estimated location of the UE based on these.

[0042] Another example of an ML model would be one that assists the UE in channel estimation or interference estimation for channel estimation. Channel estimation can be, for example, for PDSCH and is associated with a specific set of reference signal patterns transmitted from the NW to the UE. In this case, the ML model would be part of the receiver chain within the UE and might not be directly visible within the reference signal patterns when configured / scheduled for use between the NW and the UE. Another example of an ML model used for CSI estimation is one that predicts appropriate future CQI, PMI, RI, CRI (CSI-RS resource indicator), or similar values.

[0043] AI / ML models can be described from the perspectives of time domain, frequency domain, and spatial domain. In this context, the output of the AI / ML model can be located in different time instances (compared to those model inputs), or at different frequency locations, or in different spatial directions, or a combination of time / frequency / space. In one example (time domain), an ML model might correspond to the function of taking a measurement of a reference signal received (e.g., transmitted in beam-X) at time instance t0 as input and providing a prediction of the reference signal at time instance t0+T as the result. In another example (spatial domain), an ML model might correspond to the function of taking a measurement of a reference signal X (e.g., an SSB indexed 'x') received (e.g., transmitted in beam-x) as input and providing an estimation / prediction of the link quality of other reference signals transmitted in different beams (e.g., reference signal Y, transmitted in beam-y).

[0044] AI / ML models can be described from the perspective of model structure. In this case, the ML model can be entirely contained within the UE or split between the UE and the network. An example of a split structure is an ML model used to assist CSI estimation, where the possible setup of the ML model is a split model that includes a specific sub-ML model within the UE and a sub-ML model on the NW side, which work together to generate the desired result for the overall ML model. The function of the sub-ML model in the UE would be to compress the channel input, and the function of the sub-ML model on the NW side would be to decompress the output received from the UE. It is further possible to apply a similar scheme to positioning, where the input can be some form of channel pulse related to a specific time reference point. The goal on the NW side would be to detect different peaks within the impulse response, which correspond to different reception directions of the radio signal on the UE side.

[0045] An example of an ML model included in a UE is ML-enhanced localization. For instance, an ML model implemented in a UE takes multiple sets of measurements (each corresponding to DL signals from different network nodes) as input and derives the estimated location of the UE based on these.

[0046] In terms of physical layer utility, ML models can be used for many functions, including channel estimation, line-of-sight (LOS) / non-line-of-sight (NLOS) classification, beam selection, UE location estimation, link adaptation, etc. For example, an ML model can assist the UE in channel estimation, which may or may not be incorporated into interference estimation. Channel estimation can be, for example, for PDSCH and is associated with a specific set of reference signal patterns transmitted from the NW to the UE. The ML model would then be part of the receiver chain within the UE and may not be directly visible within the reference signal patterns when configured / scheduled for use between the NW and the UE. Another example of an ML model used for CSI estimation is predicting appropriate future CQI, PMI, RI, or similar values. The future could be a specific number of time slots after the UE performed its last measurement, or it could point to a specific time slot in the future.

[0047] Functional framework for LCM in AI / ML models Building an AI model, or any ML model, involves several development steps, with the actual training of the AI ​​model being just one step in the training pipeline. A crucial part of AI development is ML model lifecycle management (LCM). This is in... Figure 1 As shown in the figure, Figure 1 This is a diagram of the training pipeline 10 and the inference pipeline 20, and their interactions within the model lifecycle management procedure 1. Model lifecycle management 30 typically consists of several components.

[0048] The training (retraining) pipeline 10 may include data ingestion 11, data preprocessing 12, model training 13, model evaluation 14, and model registration 15.

[0049] Data ingestion 11 refers to collecting raw (training) data from the data store. Following data ingestion 11, there may be steps to control the validity of the collected data.

[0050] Data preprocessing 12 refers to some feature engineering applied to the collected data, such as data normalization and possibly other data transformations required for the input data to the AI ​​model.

[0051] Model training 13 refers to the actual model training steps.

[0052] Model evaluation (14) refers to benchmarking performance against a certain model baseline. The iterative steps of model training and model evaluation continue until an acceptable performance level is reached.

[0053] Model registration 15 refers to registering an AI model, which includes any corresponding AI metadata that provides information on how the AI ​​model was developed, as well as possible AI model evaluation performance results.

[0054] Model deployment phase 16 integrates the trained (or retrained) AI model into the inference pipeline 20.

[0055] The inference pipeline 20 may include data ingestion 21, data preprocessing 22, model operation 23, and data and model monitoring 24.

[0056] Data ingestion 21 refers to the collection of raw (inference) data from data storage.

[0057] The data preprocessing stage 22 is typically the same as the corresponding process 12 that occurs in the training pipeline 10.

[0058] Model operation 23 refers to using a trained and deployed model in operation mode.

[0059] Data and model monitoring 24 refers to verifying that the inference data comes from a distribution that is well aligned with the training data, and monitoring the model output to detect any performance or operational drift.

[0060] The drift detection phase 25 notifies the model of any drift during operation.

[0061] Figure 2 This describes a functional framework 30 that can be used for AI research targeting different network (NW)-user equipment (UE) collaboration levels for physical network layer (PHY) use cases. Data collection 32 refers to the collection and storage of data to be used in the training 10 and inference 20 pipelines, as referenced above. Figure 1 The following is a description. Management 34 refers to the management of the entire process of model creation, training, inference, updating, and deployment 1. Once AI / ML models are (re)trained, they are maintained in model storage 36.

[0062] UE-NW Collaboration Level for One-sided and Two-sided AI / ML Models The AI / ML models discussed in the Rel-18 research project on AI / ML for NR air interface can be divided into two types.

[0063] A single-sided AI / ML model can be a UE-side AI / ML model in which its inference is entirely performed by the UE, or an NW-side AI / ML model in which its inference is entirely performed by the NW.

[0064] Two-sided AI / ML models refer to paired AI / ML models on which joint inference is performed across the UE and NW. That is, the first part of the inference is performed by the UE first, and then the remaining part is performed by the gNB, and vice versa.

[0065] Figure 3An example use case for CSI feedback / reporting based on an autoencoder (AE) is shown, wherein the UE operates encoder 42 (the UE portion of the dual-sided AE model 40) to compress the estimated radio channel 41, and the output of encoder 42 (the compressed radio channel information estimate) is reported from the UE to the gNB from UE 43. The gNB uses decoder 44 (the NW portion of the dual-sided AE model 40) to reconstruct the estimated radio channel information 45.

[0066] Functional LCM and Model ID-based LCM For the UE portion of both the UE-side model and the dual-side model, 3GPP Rel-18 discusses functional-based LCM and model ID-based LCM.

[0067] In function-based LCM, the network instructs the activation, deactivation, fallback, or switching of AI / ML functionality via 3GPP signaling (e.g., RRC, MAC-CE, or DCI). The model may not be identified at the network level, and the UE may perform model-level LCM. Whether the NW should have awareness / interaction with model-level LCM, and to what extent, requires further investigation. For functionality identification, there may be one or more functions defined within AI / ML-enabled features, where AI / ML-enabled features refer to features that can use AI / ML. Note: A UE may have one AI / ML model for a given functionality, or multiple AI / ML models for that functionality.

[0068] For the function-based LCM of the UE portion of the AI / ML functional identifier and the UE-side model and / or dual-side model, functionality refers to an AI / ML-enabled feature / FG enabled by one or more configurations, where one or more configurations are supported based on conditions indicated by UE capabilities. Correspondingly, the function-based LCM operates based on at least one configuration of an AI / ML-enabled feature / FG or some specific configurations of AI / ML-enabled features / FGs.

[0069] Following the functional identification, the study examines the necessity and mechanism for updating the UE report regarding the applicable functionalities among the [configured / identified] (one or more) functionalities, where the applicable functionalities can be a subset of all [configured / identified] functionalities. The applicable functionalities / models can be reported by the UE.

[0070] In model ID-based LCM, the model is identified at the network, and the network / UE can activate / deactivate / select / switch individual AI / ML models via the model ID.

[0071] For the model ID-based LCM of the UE portion of the AI / ML model identifier and the UE-side model and / or dual-side model, the model ID-based LCM operates based on the identified model, wherein the model may be associated with specific configurations / conditions that are associated with the UE capabilities of the AI / ML enabled features / FGs and additional conditions (e.g., scene, site, and dataset) determined / identified between the UE side and the NW side.

[0072] From RAN1's ​​perspective, the AI / ML model identified by the model ID can be logical, and how it maps to one or more physical AI / ML models can depend on the implementation. When it is necessary to distinguish between them for discussion purposes, companies may use the term "logical AI / ML model" to refer to the model that is identified and assigned a model ID, and the term "one or more physical AI / ML models" to refer to the actual implementation of such a model.

[0073] Following model identification, the necessity and mechanism for updating the UE report regarding (one or more) applicable UE part / UE-side models are investigated, where the applicable models may be a subset of all identified models.

[0074] For the AI / ML model identifier of the UE portion of the UE-side model or dual-side model, the model identifier is divided into the following types: Type A and variants to Type B.

[0075] Type A models are identified to the NW (if applicable) and UE (if applicable) without over-the-air signaling. A model ID can be assigned to the model during model identification, and the model ID can be referenced or used in over-the-air signaling after model identification.

[0076] Type B models are identified via over-the-air signaling. Type B has two subtypes.

[0077] For type B1, model identification is initiated by the UE, and the NW assists in the remaining steps of model identification (if any), and a model ID can be assigned to the model during model identification.

[0078] For type B2, the model identification is initiated by the NW, and the UE responds to the remaining steps of the model identification (if any) and may assign a model ID to the model during the model identification process.

[0079] Note that this study does not imply that model labeling is necessary.

[0080] Once the model is identified, the UE can use it as a starting point to indicate the AI / ML model ID supported by the given AI / ML enabled feature / FG in the UE capability report. Note: For types B1 and B2, the use of the model identifier in the capability report is not excluded.

[0081] Model IDs [discussed in RAN1] may or may not be globally unique, and different types of model IDs can be created for individual models for various LCM purposes. Note: Details can be explored in the WI phase.

[0082] For LCMs based on functional / model IDs, once the functional / model is identified, the same or similar procedures can be used for its activation, deactivation, switching, rollback, and monitoring.

[0083] How to handle the impact of the UE's internal conditions (such as memory, battery, and other hardware limitations) on functional / model operation and AI / ML enabled features remains to be studied.

[0084] UE-side model training Several methods exist for training UE-side models. One approach involves training the UE-side model at the UE itself; that is, the UE performs both training and inference. However, given the UE's limited computational resources and the potentially enormous computational complexity of training operations, this approach may be overly complex or impractical in practice. Furthermore, if the model is location- and / or region-dependent, a single UE will not cover the entire coverage area, meaning the model trained by the UE will always be limited to the area the UE moves in, and thus the AI / ML model it trains may become outdated each time the UE enters a new area. Therefore, alternative methods for training UE-side models include the possibility that network nodes (e.g., radio access nodes like gNBs or core network (CN) nodes, such as network data analytics functions or NWDAFs) collect data from the UE and train an AI / ML model, which should be delivered / transferred to that UE or other UEs at some point, and then applied by those UEs. Alternatively, outside of 3GPP, an over-the-top (OTT) server can be responsible for performing the training. This server can be, for example, a UE vendor-specific server. The latter approach may be a reasonable candidate because, for optimal performance, the training dataset should be suitable for inference operations at the device, which may depend on the UE vendor-specific implementation (e.g., software / hardware attributes / capabilities).

[0085] Regardless of whether UE-side model training is performed by a node outside the RAN (e.g., within a core network node) or even outside the 3GPP network, a certain amount of data needs to be collected by the UE to enable such a node to perform model training. This is because for many use cases, such as AI-based CSI compression, AI-based CSI prediction, AI-based beam management, AI-based positioning, AI-based mobility prediction, and AI-based traffic prediction, the training node needs to receive input from the UE. Therefore, a protocol can be envisioned whereby (e.g., upon receiving a trigger from the training node) the UE trains for a certain period of time, collects data, and once data collection is complete, it transfers the collected data to the training node.

[0086] The following table, which shows the mapping between functionality and entities, was agreed upon in 3GPP R2-2308286.

[0087] NW-side model training Regarding NW-side model training, 3GPP has so far assumed that the gNB and / or Operation, Administration and Maintenance (OAM) will be responsible for it. If the gNB is responsible, it is assumed that the gNB can configure a resource set for the UE, such as a CSI-RS resource set or an SSB resource set, in which the UE should collect measurements for a certain amount of time. The UE will then report its measurements to the gNB, for example, via RRC signaling. Training can then be performed either within the gNB itself or in another node controlled by the gNB vendor (e.g., an OTT server handled by the gNB vendor).

[0088] A similar approach would be applicable to situations where OAM performs NW-side training. In this case, OAM can request the gNB to provide the UE with a specific configuration, and the UE should perform specific measurements and collect data according to that configuration. Once data collection is complete, the UE can transfer the collected data to OAM, for example, using an MDT framework (such as Immediate MDT or Recorded MDT).

[0089] The following table, which shows the mapping between functionality and entities, was agreed upon in 3GPP R2-2308286.

[0090] There are some challenges. When performing data collection, the UE collects measurements and stores them in its memory until those collected measurements (e.g., periodically, or when certain configured events are met, or on demand according to gNB requests) are transmitted to the gNB.

[0091] However, it is possible that while collecting such measurements, the UE performs mobility procedures (e.g., handover (HO) or reconfiguration with synchronization) or experiences a radio link failure, while having remaining stored AI / ML-based measurements that have not yet been transmitted to the NW. In this case, it is unclear how the UE will handle these remaining collected measurements that have not yet been transmitted to the NW.

[0092] According to the method described herein, the UE is connected to a network (e.g., it can receive and transmit data and / or control information), i.e., it is in the RRC_CONNECTED state and is configured to perform a specific function (which may be referred to as an AI / ML model functionality, e.g., beam measurement prediction in the time domain) by using an AI / ML model. A specific functionality or feature of the AI / ML model may be used, for example, for one of the following examples, and may also be grouped into functional regions (each region having one or more AI / ML model functionalities).

[0093] AI / ML models can assist in CSI reporting.

[0094] AI / ML models can perform beam management (BM). In one option, there is BM functionality for one or more AI / ML models, where the AI / ML model (e.g., in the UE) performs inference of one or more temporal predictions related to beam management. For example, the network configures the UE to report one or more temporal predictions of SSB and / or CSI-RS and / or PTRS measurements (e.g., on PUCCH and / or PUSCH), for example, by receiving reporting configurations for AI / ML.

[0095] In another option, there is BM functionality of one or more AI / ML models, wherein the AI / ML models (e.g., in the UE) perform inference of one or more spatial domain predictions related to beam management.

[0096] In another remaining option, there is BM functionality for one or more AI / ML models, where the AI / ML model (e.g., in the UE) performs both temporal and spatial domain prediction inference related to beam management.

[0097] When a UE is configured to perform at least one action related to AI / ML functionality (e.g., the UE is configured to report a prediction of beam measurement for one or more of its configured serving cells and / or one or more of the serving cell's CSI and / or one or more SSBs), the UE is considered to be configured with that AI / ML functionality.

[0098] AI / ML models can assist in radio resource management (RRM) measurements.

[0099] One example is mobility measurements (i.e., RSRP, RSRQ, RSSI), and there are also aspects related to radio link failures (e.g., RLF prediction). Additionally, predictions related to RLM-related timers (T310) and counters (N310 and N311) can also be considered here.

[0100] Another example is the measurement framework defined in 3GPP TS 38.331 §5.5, which includes how the UE performs measurements (e.g., measurement configuration), what triggers measurement reports (e.g., event-triggered reports, periodic reports), and what should be included in the measurement reports.

[0101] AI / ML models can perform or assist in link adaptation, HARQ transmission, data transmission or reception, power control, UE positioning, random access transmission, or energy efficiency (e.g., DRX settings).

[0102] The methods disclosed above can be interchangeably applied to one or more AI / ML models associated with AI / ML model functionality, or to AI / ML model functionality.

[0103] Methods for UE to handle AI / ML measurements and measurement configuration information during mobility Figure 4 The signaling and steps describe the overall approach performed at the User Equipment (UE) for data collection from the UE using L3 configuration and for reporting purposes for AI / ML model training. Figure 4 In this context, a specific example of reconfiguration with synchronization is used as a mobility operation.

[0104] In the first step, the UE receives one or more configuration information from the first serving / source RAN node. The one or more configuration information instructs the UE to perform and / or collect measurements for AI / ML model training.

[0105] In the second step, the UE performs AI / ML measurement collection based on the measurement configuration information provided by the first node. Data collection means that the UE records the collected data in its memory.

[0106] In the third step, perform one of the following operations: mobility operation; RRC state transition; radio link failure; or PSCell change.

[0107] Mobility operations can be one of the following: normal handover or reconfiguration with synchronization or mobility from NR to another RAN (e.g., LTE); conditional handover / reconfiguration with synchronization based on a triggering event; or LTM event (i.e., mobility or cell handover based on Layer 1 / Layer 2).

[0108] RRC state transitions can be from RRC_CONNECTED mode to RRC_IDLE or RRC_INACTIVE; or from RRC_IDLE or RRC_INACTIVE to RRC_CONNECTED mode.

[0109] A radio link failure may occur in SpCell.

[0110] Changes to PSCell can be made via a synchronized reconfiguration procedure, a synchronized conditional reconfiguration procedure, or an LTM procedure.

[0111] In the fourth step, in response to the actions in step 3, data collected based on the AI / ML measurement configuration, which has been recorded but not yet sent to the network (or not retrieved by the network), is processed according to one of several procedures. The UE may delete it; send it to the target RAN node; continue performing AI / ML measurements; indicate to the target RAN node the availability of the previously collected data; or indicate to the target RAN node whether the source node has configured an AI / ML measurement configuration.

[0112] UE deletes AI / ML measurement data that has been collected but not yet transmitted. Figure 5 This describes a scenario where the UE deletes collected AI / ML measurements. In some cases, the UE also deletes received AI / ML configurations.

[0113] In one aspect, when performing a mobility operation (step 3), the source node instructs the UE whether to delete the collected AI / ML measurements and / or AI / ML measurement configuration information.

[0114] In one aspect, when performing a mobility operation (step 3), the target node, as part of an HO command, instructs the UE whether to delete the collected AI / ML measurements and / or AI / ML measurement configuration information.

[0115] In the case of mobility operations, the source node may, as part of a synchronized RRC reconfiguration, indicate to the UE whether it should delete collected but not yet transmitted AI / ML measurements and / or AI / ML measurement configuration information.

[0116] Whether to send this instruction to the UE may depend on whether the target node supports retrieving collected data from the UE, or whether the AI / ML measurement configuration configured by the source node is also valid in the target node. For example, as part of HO preparation, the source node may indicate to the target node that the UE has collected, yet-to-be-transmitted, available AI / ML measurements and / or that the UE is configured with an AI / ML measurement configuration. The target node may then indicate to the source node whether the UE can perform the transmission of collected data in the target node, and / or whether the UE should retain or release the AI / ML measurement configuration provided by the source node. In another embodiment, the target node may (e.g., in an HO command) indicate to the UE whether the UE can perform the transmission of collected data in the target node, and / or whether the UE should retain or release the AI / ML measurement configuration provided by the source node.

[0117] In the event of a radio link failure or handover failure, this indication may be transmitted by the target node in which the UE (e.g., during RRC Reestablishment or subsequent RRC Reconfiguration) has been successfully rebuilt. This indication may also be transmitted by the target node in response to receiving information from the source node during the context retrieval procedure indicating that the UE had collected data available at the time of the radio link failure or handover failure.

[0118] In the case of transitioning from RRC_CONNECTED to RRC_IDLE or RRC_Inactive, the source node may provide this indication (e.g., as part of RRCLease).

[0119] In one aspect, the source node provides an indication of whether to delete collected AI / ML measurements and / or AI / ML measurement configurations as part of the AI / ML measurement configuration information. For example, as part of the AI / ML measurement configuration information, the source node may indicate one or more target nodes for which the UE should delete or not delete collected but not yet transmitted AI / ML measurements and / or AI / ML measurement configuration information. Alternatively, the source node may indicate a region within which the UE should retain collected but not yet transmitted AI / ML measurements and / or AI / ML measurement configuration information. The UE retains or deletes the AI / ML measurements and / or AI / ML measurement configuration information in response to whether a target node belongs to that region.

[0120] In one aspect, if the mobility command contains a full configuration, the UE removes both the AI / ML measurement configuration and the collected AI / ML-based measurement reports.

[0121] The UE retains the collected AI / ML measurements and sends the reports to the target RAN node. Figure 6Describe the following scenario: The UE stores an AI / ML-based measurement report and sends the report to the target RAN node. The target RAN node forwards the report back to the source node during mobility, and the UE deletes the AI / ML measurement configuration.

[0122] In one aspect, when a UE connects to a target RAN node, it indicates to the target RAN node via RRC signaling (e.g., an RRCReconfigurationComplete message) the availability of measurements based on AI / ML configuration records (i.e., collected but not yet transmitted measurements).

[0123] In another scenario, the UE first indicates to the target RAN node that the available measurement is based on the configuration configured by the first / source RAN node, and then transmits the measurement, so that the target RAN node can forward the measurement back to the first / source node.

[0124] When a UE receives a request from a target RAN node after connecting to it, the UE can send measurements based on AI / ML configuration records to the target RAN node. For example, in the case of mobility operations, the source node can indicate to the UE, as part of the HO preparation procedure, that it has collected, recorded data that has not yet been transmitted to the source node. The target node can then instruct the UE (e.g., as part of an HO command) to continue transmitting the collected data upon successful completion of the HO to the target node. In the case of reconstruction, the UE re-establishes its connection with the target node, and upon successful reconstruction (e.g., in an RRCReconfigurationComplete message) receives a request from the UE that the UE has available measurements, it can instruct the UE to send the recorded measurements.

[0125] When the target RAN node receives measurements collected based on AI / ML, it can send the retrieved measurements to the source RAN node.

[0126] UE continues to perform AI / ML measurements Figure 7 Describe the following scenario: The UE retains the AI / ML measurement collection configuration and continues to record AI / ML-based data collection in the target cell, and sends AI / ML-based measurement reports to the target RAN node, which then forwards them back to the source node.

[0127] In this respect, if the received AI / ML measurement configuration is also valid for the target node, the UE continues to perform AI / ML measurements based on the AI / ML measurement configuration received from the source RAN node after connecting to the target node. In this respect, the UE retains the received AI / ML measurement configuration when performing mobility operations.

[0128] In one variant of this, the UE performs this step if the AI / ML configuration includes an area range instructing the UE to continue measurements in the area containing the target cell.

[0129] In this regard, during mobility, the source RAN node can send the configured AI / ML configuration to the target RAN node.

[0130] On the other hand, the source RAN node will signal the target RAN node with the AI / ML configuration configured by the UE, either as part of the UE RRC context or as part of the explicit application protocol interface between RAN nodes (such as the Xn or NG interface).

[0131] In another aspect, when connected to a target RAN node, the UE indicates to the target RAN node the availability of AI / ML measurements that have been collected but not yet transmitted.

[0132] In another aspect, when connecting to the target RAN node, the UE indicates to the target RAN node whether the source node has configured the AI / ML measurement configuration for the UE.

[0133] Additional aspects In some other aspects, the UE includes an AI / ML training data availability indication in the RRC measurement report sent to the source node. The UE includes such an indication (or sets the indication to "true") in the measurement report when it has at least one measurement to be reported as part of the training data used for training AI / ML models. In some embodiments, this indication can be set separately for each model ID and / or each AI / ML functionality ID or AI / ML training data collection configuration ID.

[0134] In one variant, the UE includes such an indication in each transmitted RRC measurement report, provided that the UE has at least one AI / ML model training configuration in the UE's configuration.

[0135] In another variant, the UE includes such an indication in the RRC measurement report only if the configuration of the corresponding measurement report includes a configuration requesting the UE to include a condition regarding the availability of AI / ML model training data at the UE. Such a configuration can be requested separately for each model ID and / or each AI / ML functionality ID or AI / ML training data collection configuration ID.

[0136] In another variant, the UE includes such an indication in the RRC measurement report only if the configuration of the corresponding measurement report includes a configuration associated with reconfiguration with synchronization. For example, if the corresponding measurement configuration includes the use of a T312 timer set to "true", the UE includes the AI / ML model training data availability status in the measurement report if the T312 timer is running when the UE transmits the measurement report, or if T312 is started at the start of this measurement report transmission.

[0137] In one aspect, upon receiving such an indication in a measurement report, the source node obtains the corresponding AI / ML training data from the UE.

[0138] In one aspect, upon receiving such an indication in a measurement report, the source node forwards the indication as part of a handover preparation request message to the target node. The target node then uses this information to send a second indication to the UE, indicating whether to delete / retain the measurements before entering the target cell. This second indication can be configured by the target cell as part of a HO command, which is sent from the target node to the UE via the source node. Upon receiving such a second indication, if the UE performs a handover / reconfiguration procedure toward the target cell, the UE checks whether the target node has instructed the UE to delete or retain the stored AI / ML model training data, and the UE should act accordingly. The second indication can be set separately for each model ID and / or each AI / ML functionality ID or AI / ML training data collection configuration ID.

[0139] Methods and equipment Figure 8 A method 100 is described, performed by a user equipment (UE) operable in a wireless communication network, for processing information related to artificial intelligence (AI) or machine learning (ML). The method includes: receiving configuration information from a source network node specifying measurement and data collection for AI / ML model training (box 102); performing AI / ML-related measurement and data collection according to the configuration information and storing the collected data (box 104); terminating or losing network connection to the source network node (box 106); and processing the collected AI / ML-related measurement and data, but not yet transmitted to the network, according to the configuration information (box 108).

[0140] Figure 9A method 200 describes the control of AI / ML-related information performed by an operable source network node in a wireless communication network. It serves the UE (box 202). Configuration information specifying measurements and data collection for AI / ML model training is transmitted to the UE (box 204). The network connection to the UE is terminated or lost (box 206). Configuration information specifying measurements and data collection performed by the UE for AI / ML model training is transmitted to a target network node to which the UE subsequently connects (box 208).

[0141] Figure 10 A method 300 is described, which describes the control of AI / ML-related information performed by an operable target network node in a wireless communication network. This method serves the UE after the UE terminates or loses its network connection to the source network node (box 302). It receives from the UE AI / ML-related measurements and data collected when the UE connected to the source network node but not yet transmitted to the network (box 304). It then transmits the AI / ML-related measurements and data collected by the UE to the source network node (box 306).

[0142] Figure 11 This describes a wireless device 50, such as a UE, that is operable in a wireless communication network and (as described herein) configured to handle AI / ML-related measurements and data collected but not yet transmitted to the network. As used herein, UE 50 is any type of device capable of communicating via radio signals with a base station, another UE 50, or other network nodes. Therefore, UE 50 may refer to a cellular phone or smartphone, a machine-to-machine (M2M) device, a machine-type communication (MTC) device, a narrowband Internet of Things (NB-IoT) device, etc. Despite its name, UE 50 does not necessarily have a "user" in the personal sense of owning and / or operating the device. UE 50 may also be referred to as a radio device, radio communication device, wireless communication device, wireless terminal, or simply terminal—unless the context otherwise indicates, the use of any of these terms is intended to include device-to-device UE or device, machine-type device, or device capable of machine-to-machine communication, sensor equipped with a radio network, wirelessly enabled desktop computer, mobile terminal, smartphone, laptop embedded device (LEE), laptop mounted device (LME), USB dongle, wireless client device (CPE), etc. In the discussion herein, the terms machine-to-machine (M2M) device, machine-type communication (MTC) device, wireless sensor, and sensor may also be used. It should be understood that these devices may be UE 50, but may be configured to transmit and / or receive data without direct human interaction.

[0143] UE 50 includes processing circuitry 52, memory 54, and communication circuitry 56. Processing circuitry 52 is configured to perform methods according to aspects described herein (e.g., by executing software code stored in memory 54). Processing circuitry 52 is operatively connected to communication circuitry 56, which includes radio circuitry (e.g., radio frequency (RF) transceivers connected to one or more antennas 58) to enable wireless communication across an air interface with one or more base stations, access points, or other UE 50s. As indicated by the dashed lines, antenna(s) 58 may protrude outwards from UE 50, or antenna(s) 58 may be located internally. In some aspects, UE 50 includes a user interface (not shown), which may include features such as a display, touchscreen, keyboard or keypad, microphone, speaker, etc. In some embodiments, such as in many M2M, MTC, or NB-IoT scenarios, UE 50 may include only a minimal user interface, or no user interface at all.

[0144] Figure 12 A network node 60, operable in a wireless communication network and configured as a base station, is depicted. Network node 60 (as described herein) is configured to control the disposal of AI / ML-related measurements and data collected by UE 50 but not yet transmitted to the network. As known in the art, base station 60 provides wireless communication services to one or more UEs 50 within a geographical area (referred to as a cell or sector). As described herein, network node 60 may act as a source network node or a target network node. Network node 60 includes processing circuitry 62, memory 64, and communication circuitry 66. Processing circuitry 62 is configured to perform methods according to aspects described herein (e.g., by executing software code stored in memory 64). Processing circuitry 62 is operatively connected to communication circuitry 66, which includes circuitry configured to communicate with other network nodes (e.g., via wired or wireless interfaces). Communication circuitry 66 additionally includes radio circuitry (such as an RF transceiver) and is connected to one or more antennas 68 to enable wireless communication with one or more UEs across an air interface. Figure 12 As indicated by the continuous lines in the antenna feed, one or more antennas 68 may be physically separated from network node 60, such as by mounting on a tower, building, etc.

[0145] In all aspects described herein, processing circuitry 52, 62 may include any sequential state machine operable to execute machine instructions stored in memory as a machine-readable computer program, such as one or more hardware-implemented state machines (e.g., in discrete logic, FPGA, ASIC, etc.); programmable logic together with appropriate firmware; one or more stored-program general-purpose processors, such as microprocessors or digital signal processors (DSPs), together with appropriate software; or any combination of the foregoing. Although depicted as being contained within wireless device 50 or network node 60, processing circuitry 52, 62 may, in some aspects, be remotely located. In some aspects, processing circuitry 52, 62 may include virtualized servers located in one or more data centers (commonly referred to as “cloud”). Boxes 52, 62 labeled “processing circuitry” contain memories 54, 64 and other circuitry, such as power control circuitry, coprocessors, dedicated hardware (encryption / decryption, graphics processing, user interface control), etc.

[0146] In all embodiments described herein, the memories 54, 64 may include any non-transitory machine-readable medium known or developed in the art, including but not limited to magnetic media (e.g., floppy disks, hard disks, etc.), optical media (e.g., CD-ROMs, DVD-ROMs, etc.), solid-state media (e.g., SRAM, DRAM, DDRAM, ROM, PROM, EPROM, flash memory, solid-state drives, etc.), and so on.

[0147] In all embodiments described herein, communication circuits 56 and 66 may include transceiver interfaces for communicating with one or more other nodes over a communication network according to one or more communication protocols known or developed in the art, such as Ethernet, TCP / IP, SONET, ATM, etc. UE communication circuit 56 and (in the case where network node 60 implements a base station) communication circuit 66 implement RF transceiver functionality suitable for wireless communication network links (e.g., RF signaling conforming to 3GPP specifications, Wi-Fi, etc.).

[0148] Example implementation when receiving an RRC reconfiguration containing the complete configuration The UE should (the underlined portion relates to aspects of this disclosure): 1> Release / clear all current dedicated radio configurations except the following: - MCG C-RNTI; - AS security configuration associated with the master key; - As it is radioBearerConfig or radioBearerConfig2 Configure SRB1 / SRB2 and DRB / Multicast MRB. Note 1: Radio configuration is not only resource configuration, but also includes other configurations (such as...). MeasConfig The radio configuration also includes, for example, [the following]. RLC-BearerConfig The configured RLC bearer configuration, such as by SL-RLC-ChannelConfig Configured PC5 trunk RLC channel, and as by Uu-RelayRLC-ChannelConfig Configured Uu relay RLC channels. If NR-DC or NE-DC is configured, this also includes the entire NR or E-UTRA SCG configuration released according to the MR-DC release procedure as specified in 5.3.5.10. Note 1a: For NR pass-through link communication / discovery, the radio configuration includes the pass-through link RRC configuration received from the network, but does not include the pass-through link UE capabilities and pass-through link RRC reconfiguration received from other UEs via PC5-RRC. Furthermore, in the event of a state transition or changes to the system information used for NR pass-through link communication / discovery, the UE will treat the new NR pass-through link configuration as the complete configuration. Note 1b: In order to be in the by fullConfig Following the release, an RLC bearer (one or more) of SRBs are established, and the network can... srb-ToAddModList Contains srb-Identity (That is, the UE applies the default RLC configuration) and / or explicitly provides the relevant (one or more) SRBs. rlc-BearerToAddModList . - Recorded measurement configuration; 1> If masterCellGroup In spCellConfig Include reconfigurationWithSync : 2> Release / clear all current public radio configurations; 2> Release / clear all current measurements collected based on AI / ML measurement configuration; 2> Release / clear all stored AI / ML measurement configurations; 2> If in reconfigurationWithSync It includes sl-PathSwitchConfig : 3> Use the default values ​​specified in 9.2.3 for timer T311; 2> Otherwise: 3> Use the default values ​​specified in 9.2.3 for timers T310, T311 and constants N310, N311; 1> Otherwise (full configuration after reconstruction or during RRC recovery): 2> If the UE is acting as an L2 U2N remote UE: 3> Use as in SIB1 Received in ue-TimersAndConstants The value of timer T311 included; 2> Otherwise: 3> Use as in SIB1 Received in ue-TimersAndConstantsIt includes the values ​​of timers T301, T310, T311 and constants N310 and N311; 1> If not included measConfigAppLayerId : 2> Release all application layer measurement configurations to higher layers; 2> Discard any application layer measurement reports received from higher layers; 2> It is believed that it is not configured to send application layer measurement reports. 1> If the UE is acting as an L2 U2N remote UE on the target side during reconfiguration with synchronization, or after reconstruction, or during RRC recovery: 2> Apply the default configuration of SL-RLC1 as specified in Section 9.2.4 and associate it with SRB1; 1> Otherwise: 2> Apply the default L1 parameter values ​​specified in the corresponding physical layer specification, except for the following: - exist SIB1 The parameter provides its value; 2> Apply the default MAC cell group configuration as specified in 9.2.2; 2> For those included srb-ToAddModList Each in (SRB reconfiguration) srb-Identity value: 3> Create an RLC entity for the corresponding SRB; 3> Apply the default SRB configuration defined in 9.2.1 for the corresponding SRB application; Note 2: This is to bring the SRBs (SRB1 and SRB2 for reconfiguration with synchronization, and SRB2 for recovery and reconfiguration after reconstruction) to a known state from which the reconfiguration message can be further configured. 1> For each UE that is part of the current UE configuration pdu-Session : 2> Release the SDAP entity (section 5.1.2 of TS 37.324

[24] ); 2> As specified in 5.3.5.6.4, release and pdu-Session Each associated DRB; Note 3: This will be preserved pdu-Session However, removing the UE configuration containing these bearers... drb- identity The DRB. Section 5.3.5.6.5 describes how to establish a DRB within an AS using a new configuration. pdu-Session It serves as an anchor point for associated release and reconstruction of DRBs. In AS, DRB reconstruction is equivalent to the establishment of a new DRB (including a new PDCP and logical channel configuration). 1> For each UE that is part of the current UE configuration and associated with the multicast MRB mbs-SessionId : 2> Release the SDAP entity (section 5.1.2 of TS 37.324

[24] ); 2> As specified in 5.3.5.6.6, release and mbs-SessionId Each associated multicast MRB; Note 4: This will be preserved mbs-SessionId However, removing the UE configuration containing these bearers... mrb- identity Multicast MRB. Section 5.3.5.6.7 describes the establishment of a multicast MRB within an AS using a new configuration. mbs- SessionId It serves as an anchor point for associated release and reconstruction of multicast MRBs. In AS, multicast MRB reconstruction is equivalent to the establishment of a new multicast MRB (including a new PDCP and logical channel configuration). 1> For those that are part of the current UE configuration but not in the same way pdu-Session Add on drb- ToAddModList Each of them pdu-Session : 2> If the procedure is triggered due to a reconfiguration with synchronization: 3> After a successful reconfiguration with synchronization, indicate to higher layers the instructions for use. pdu-Session Release of user plane resources; 2> Otherwise: 3> Immediately instruct higher management to use pdu-Session Release of user plane resources; 1> For those that are part of the current UE configuration but not in the same way mbs-SessionId Add on mrb- ToAddModList Each of them mbs-SessionId : 2> If the procedure is triggered due to a reconfiguration with synchronization: 3> After a successful reconfiguration with synchronization, indicate to higher layers the instructions for use. mbs-SessionId Release of user plane resources; 2> Otherwise: 3> Immediately instruct higher management to use mbs-SessionId Release of user plane resources.

[0149] Advantages of this disclosure This disclosure enables the UE to handle unretrieved AI / ML measurements and configured AI / ML measurement configuration information during mobility procedures such as handover, RRC reconfiguration with synchronization, or L1 / L2 mobility procedures. This allows collected AI / ML data to be salvaged and used for ML model training, avoiding wasted UE power during data collection.

[0150] In some embodiments, some or all of the functionality described herein may be provided by processing circuitry that executes instructions stored in memory, which in some embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as by hard-wired provision. In any of those particular embodiments, the processing circuitry may be configured to perform the described functionality regardless of whether instructions stored on a non-transitory computer-readable storage medium are executed. The benefits provided by such functionality are not limited to the processing circuitry or other components of the computing device alone, but are enjoyed by the computing device as a whole and / or by the end user and wireless network as a whole.

[0151] This invention may, of course, be implemented in other ways than those specifically set forth herein, without departing from the essential characteristics of the invention. The embodiments presented are to be regarded in all respects as illustrative rather than restrictive, and all variations falling within the meaning and equivalent scope of the appended embodiments are intended to be embraced therein.

Claims

1. A method (100) performed by a user equipment (UE) (50) operable in a wireless communication network for processing information related to artificial intelligence (AI) or machine learning (ML), the method (100) comprising: Receive (102) configuration information from the source network node (60) specifying measurement and data collection for AI / ML model training; Perform (104) AI / ML related measurements and data collection according to the configuration information, and store the collected data; Terminate or lose (106) the network connection to the source network node (60); as well as The AI / ML related measurements and data collected according to the configuration information processing (108) but not yet transmitted to the network.

2. The method (100) as described in claim 1, wherein, Terminating or losing (106) the network connection to the source network node (60) includes performing a mobility operation.

3. The method (100) as described in claim 2, wherein, The mobility operation is one of the following: handover, reconfiguration with synchronization, and mobility to different radio access networks.

4. The method (100) as described in claim 2, wherein, The mobility operation is performed based on a switching or reconfiguration with synchronization triggered by an event.

5. The method (100) as claimed in claim 2, wherein, The mobility operation is a lower-level triggered mobility operation.

6. The method (100) as claimed in claim 1, wherein, Terminating or losing (106) the network connection to the source network node (60) includes performing an RRC state transition in either direction between RRC_CONNECTED mode and one of RRC_IDLE and RRC_INACTIVE modes.

7. The method (100) as claimed in claim 1, wherein, Termination or loss (106) of network connection to the source network node (60) includes experiencing a radio link failure.

8. The method (100) as claimed in claim 1, wherein, The AI / ML related measurements and data collected but not yet transmitted to the network according to the configuration information processing (108) includes the deletion of one or both of the following: the AI / ML related measurements and data collected but not yet transmitted to the network, and the configuration information specifying the collection of measurements and data for AI / ML model training.

9. The method (100) as claimed in claim 8, wherein, The configuration information specifying the measurement and data collection for AI / ML model training indicates whether to delete any one or both of the following when the network connection to the source network node (60) is terminated or lost: the AI / ML related measurements and data collected but not yet transmitted to the network, and the configuration information specifying the measurement and data collection for AI / ML model training.

10. The method (100) of claim 9, wherein, Depending on the identity or location of the target node (60), indicate whether to delete any one or both of the following: the AI / ML related measurements and data collected but not yet transmitted to the network, and the configuration information specifying the collection of measurements and data for AI / ML model training.

11. The method (100) of claim 8, wherein, Terminating or losing (106) the network connection to the source network node (60) includes: the source node (60) performing a synchronized RRC reconfiguration, wherein, as part of the synchronized RRC reconfiguration, the source node (60) indicates whether to delete any one or both of the following: the AI / ML related measurements and data collected but not yet transmitted to the network, and the configuration information specifying the collection of measurements and data for AI / ML model training.

12. The method (100) of claim 8, wherein, Terminating or losing (106) the network connection to the source network node (60) includes: switching from RRC_CONNECTED mode to one of RRC_IDLE and RRC_INACTIVE modes, and wherein, as part of RRCRelease, the source network node (60) indicates whether to delete any or both of the following: the AI / ML related measurements and data collected but not yet transmitted to the network, and the configuration information specifying the collection of measurements and data for AI / ML model training.

13. The method (100) of claim 1, further comprising, after terminating or losing (106) the network connection to the source network node (60): Connect to the target network node (60) in the wireless communication network.

14. The method (100) as claimed in claim 13, wherein, Terminating or losing (106) the network connection to the source network node (60) includes: performing a switch, and wherein, as part of the switch command, the target node (60) indicates whether to delete any one or both of the following: the AI / ML related measurements and data collected but not yet transmitted to the network, and the configuration information specifying the collection of measurements and data for AI / ML model training.

15. The method (100) as claimed in claim 13, wherein, Termination or loss (106) of network connection to the source network node (60) includes: switching due to radio link failure or failure, and wherein, as part of RRCReestablishment or in subsequent RRCReconfiguration, the target node (60) indicates whether to delete any one or both of the following: the AI / ML related measurements and data collected but not yet transmitted to the network, and the configuration information specifying the collection of measurements and data for AI / ML model training.

16. The method (100) of claim 13, wherein, The AI / ML related measurements and data collected according to the configuration information processing (108) but not yet transmitted to the network include: The collected AI / ML related measurements and data, which have not yet been transmitted to the network, are transmitted to the target network node (60).

17. The method (100) of claim 16, further comprising: Delete the configuration information that specifies the measurement and data collection used for AI / ML model training.

18. The method (100) of claim 16, further comprising: The AI / ML related measurements and data collected but not yet transmitted to the network are indicated to the target network node (60) based on configuration information received from the source network node (60) specifying the collection of measurements and data for AI / ML model training.

19. The method (100) of claim 16, wherein, In response to a request from the target network node (60) for the collected AI / ML related measurements and data that have not yet been transmitted to the network, the process of transmitting the collected AI / ML related measurements and data that have not yet been transmitted to the network to the target network node (60) is executed.

20. The method (100) of claim 13, wherein, The AI / ML related measurements and data collected according to the configuration information processing (108) but not yet transmitted to the network include: Continue to perform AI / ML related measurements and data collection based on the configuration information.

21. The method (100) of claim 20, wherein, The configuration information specifies the region range for measurement and data collection used for AI / ML model training, and the target node (60) is located within the region.

22. The method (100) as claimed in claim 13, wherein, The AI / ML related measurements and data collected according to the configuration information processing (108) but not yet transmitted to the network include: Indicate the availability of previously collected AI / ML related measurements and data to the target network node (60).

23. The method (100) as claimed in claim 13, wherein, The AI / ML related measurements and data collected according to the configuration information processing (108) but not yet transmitted to the network include: Indicate to the target RAN node (60) whether the source network node (60) is configured with AI / ML measurement configuration.

24. The method (100) of claim 13, further comprising, after performing (104) AI / ML related measurements and data collection and before terminating or losing (106) the network connection to the source network node (60): The RRC measurement report indicates the availability of AI / ML-related measurements and data collected but not yet transmitted to the network; and The RRC measurement report is transmitted to the source node (60).

25. The method (100) as claimed in claim 24, wherein, Provided that the UE (50) has at least one AI / ML model training configuration configured in the UE (50), the UE (50) includes an indication of the availability of collected but not yet transmitted AI / ML related measurements and data in each transmitted RRC measurement report.

26. The method (100) as claimed in claim 24, wherein, The UE (50) includes an indication of the availability of AI / ML related measurements and data collected at the UE (50) but not yet transmitted to the network in the transmitted RRC measurement report only if the configuration of the corresponding measurement report includes a configuration requesting the UE (50) to include a status of the availability of AI / ML related measurements and data collected at the UE (50) but not yet transmitted to the network.

27. The method (100) as described in any one of claims 25 or 26, wherein, The indication or request for the availability of AI / ML related measurements and data is configured for each ML model ID, each AI / ML functionality ID, or each AI / ML training data collection configuration ID.

28. The method (100) of claim 24, wherein, The UE (50) includes an indication of the availability of collected, but not yet transmitted to, AI / ML related measurements and data in the transmitted RRC measurement report only if the configuration of the corresponding measurement report includes a configuration associated with reconfiguration with synchronization.

29. The method (100) of claim 24, further comprising: In response to an indication in the RRC measurement report regarding the availability of collected but not yet transmitted AI / ML related measurements and data, a request for AI / ML related measurements and data is received from the source network node (60); and AI / ML related measurements and data are transmitted to the source network node (60).

30. The method (100) of claim 24, further comprising: In response to an indication in the RRC measurement report regarding the availability of collected but not yet transmitted AI / ML related measurements and data, an indication is received from the target network node (60) regarding whether to delete or retain the AI / ML related measurements and data before entering the target cell.

31. A user equipment (50) operable in a wireless communication network implementing artificial intelligence (AI) or machine learning (ML), characterized in that: A communication circuit (56) configured to communicate with one or more network nodes (60); as well as A processing circuit (52), operably connected to the communication circuit (56), is configured to perform the method (100) as claimed in any one of claims 1 to 30.

32. A method (200) for managing information related to artificial intelligence (AI) or machine learning (ML) performed by an operable source network node (60) in a wireless communication network, the method (200) comprising: Serving (202) User Equipment (UE) (50); Transmit (204) configuration information specifying measurement and data collection for AI / ML model training to the UE (50); Terminate or lose (206) the network connection to the UE (50); as well as The configuration information specifying the measurements and data collection performed by the UE (50) for AI / ML model training is transmitted (208) to the target network node (60) to which the UE (50) subsequently connects.

33. A source network node (60) operable in a wireless communication network implementing artificial intelligence (AI) or machine learning (ML), characterized in that: A communication circuit (66) configured to communicate with a user equipment (UE) (50) and one or more network nodes (60); as well as A processing circuit (62), operably connected to the communication circuit (66), is configured to perform the method (200) as claimed in claim 32.

34. A method (300) for managing information related to artificial intelligence (AI) or machine learning (ML) performed by an operable target network node (60) in a wireless communication network, the method (300) comprising: After the user equipment (UE) (50) terminates or loses its network connection to the source network node (60), the UE (50) is served (302). Receive (304) from the UE (50) AI / ML related measurements and data collected by the UE (50) when it connects to the source network node (60) but not yet transmitted to the network; and Transmit (306) the AI / ML related measurements and data collected by the UE (50) to the source network node (60).

35. A target network node (60) operable in a wireless communication network implementing artificial intelligence (AI) or machine learning (ML), characterized in that: A communication circuit (66) configured to communicate with one or more network nodes (60); as well as A processing circuit (62), operably connected to the communication circuit (66), is configured to perform the method (300) as claimed in claim 34.

Images