Handling of ai / ml configured and collected measurements upon mobility

Abstract

Methods are disclosed for a UE to handle disposition of AI / ML related measurements and data collected but not yet transmitted to the network, in the event of terminating or losing a network connection This may include a mobility operation (e.g., handover); an RRC state transition; a radio link failure; or a change of PSCell. In accordance with configuration information specifying measurements and data collection for AI / ML model training, received from a source network node, the UE handles the AI / ML data according to one of several procedures. The UE may deleted it; send it to a target RAN node with which it reestablishes a network connection; continue to perform AI / ML measurements; indicate to the target RAN node the availability of previously collected data; or indicate to the target RAN node whether the AI / ML measurement configuration was configured by the source node.

Description

[0001] HANDLING OF AI / ML CONFIGURED AND COLLECTED MEASUREMENTS UPON MOBILITY

[0002] RELATED APPLICATIONS

[0003] This application claims priority to U.S. Provisional patent Application Serial Number 63 / 547317 filed 3 November 2023, the entire contents of which are incorporated herein by reference.

[0004] TECHNICAL FIELD

[0005] The present disclosure relates generally to wireless communication networks, and in particular to systems and methods for handling AI / ML related measurements and data collected by a UE but not yet transmitted to the network, in the event of a mobility operation.

[0006] BACKGROUND

[0007] Artificial Intelligence (Al) and Machine Learning (ML) have been investigated, both in academia and industry, as promising tools to optimize the design of the air-interface in wireless communication networks. Example use cases include using autoencoders for Channel State Information (CSI) compression to reduce the feedback overhead and improve channel prediction accuracy; using deep neural networks for classifying Line-of-Sight (LOS) and Non-LOS (NLOS) conditions to enhance the positioning accuracy; using reinforcement learning for beam selection at the network side and / or the User Equipment (UE) side to reduce the signaling overhead and beam alignment latency; and using deep reinforcement learning to learn an optimal precoding policy for complex Multiple Input Multiple Output (MIMO) precoding problems.

[0008] In 3rd Generation Partnership Project (3GPP) New Radio (NR) standardization work, a new release 18 study item on AI / ML for the NR air interface started in May 2022. This study item will explore the benefits of augmenting the air-interface with features enabling improved support of AI / ML based algorithms for enhanced performance and / or reduced complexity / overhead. Through studying a few selected use cases (CSI feedback, beam management, and positioning), this study item aims at laying the foundation for future airinterface use cases leveraging AI / ML techniques.

[0009] SUMMARY

[0010] Aspects of the present disclosure present a method at a User Equipment (UE) for data collection by a UE, and for reporting, for AI / ML model training purposes, the collected data to a target RAN network node or to any other target mobile network node, such as the OAM. The target RAN node may be the target node of a successful mobility operation; the node to which the UE reestablishes its connection after experiencing a radio link failure or a handover failure; the node to which the UE recovers its connection upon successful fast master cell group (MCG) link recovery; or the node to which the UE reconnects after transiting from RRCJDLE or RRCJNACTIVE mode to RRC_CONNECTED.

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

[0012] In a second step, the UE performs the AI / ML measurement collection according to the measurement configuration information provided by the first node, wherein the data collection implies the UE is logging the collected data in its memory.

[0013] In a third step, one of the following operations is performed: a mobility operation; an RRC state transition; a radio link failure; or a change of PSCell.

[0014] In a fourth step, in response to the operation of step 3, the data collected based on the AI / ML measurement configuration that is logged but not yet sent to the network (or not being retrieved by the network), is handled according to one of several procedures. The UE may deleted it; send it to the target RAN node; continue to perform AI / ML measurements; indicate to the target RAN node the availability of previously collected data; or indicate to the target RAN node whether the AI / ML measurement configuration was configured by the source node.

[0015] Aspects of the present disclosure further present methods for a source RAN node and a target RAN node, wherein the two nodes communicate regarding the status of collected but not yet transmitted AI / ML measurements at the UE.

[0016] One aspect relates to a method, performed by a UE operative in a wireless communication network, of handling information related to AI / ML. Configuration information specifying measurements and data collection for AI / ML model training is received from a source network node. AI / ML related measurements and data collection are performed according to the configuration information, and the collected data is stored. A network connection to the source network node is terminated or lost. The AI / ML related measurements and data collected but not yet transmitted to the network are handled according to the configuration information.

[0017] Another aspect relates to User Equipment (UE) operative 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 operatively connected to the communication circuitry. The processing circuitry is configured to perform the method described above.

[0018] Yet another embodiment relates to a method, performed by a source network node operative in a wireless communication network, of managing information related to AI / ML. A UE is served. Configuration information specifying measurements and data collection for AI / ML model training is transmitted to the UE. A network connection to the UE is terminated or lost. The configuration information specifying measurements and data collection by the UE for AI / ML model training is transmitted to a target network node to which the UE subsequently connects.

[0019] Still another aspect relates to a source network node operative 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 method described above.

[0020] Still another aspect relates to a method, performed by a target network node operative in a wireless communication network, of managing information related to AI / ML. A UE is served after the UE terminated or lost a network connection to a source network node. AI / ML related measurements and data collected the UE acquired while connected to the source network node, but which has not yet transmitted to the network are received from the UE. The AI / ML related measurements and data collected by the UE are transmitted to the source network node.

[0021] Still another aspect relates to a target network node operative 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 method described above.

[0022] BRIEF DESCRIPTION OF THE DRAWINGS

[0023] FIG. 1 is a block diagram showing ML model training and inference pipelines, and their interactions within a model lifecycle management procedure.

[0024] FIG. 2 is a block diagram showing a functional framework for studying different NW-UE collaboration levels for the Al for PHY use cases.

[0025] FIG. 3 is a block diagram of Autoencoder (AE)-based CSI reporting, using linked UE- side and NW-side ML models.

[0026] FIG. 4 is a signaling diagram showing the overall method of UE handling of AI / ML configured and collected measurements upon mobility operations / events.

[0027] FIG. 5 is a signaling diagram of a UL handling collected AI / ML data following a mobility operation by deleting it.

[0028] FIG. 6 is a signaling diagram of a UL handling collected AI / ML data following a mobility operation by transmitting the AI / ML data to the target network node.

[0029] FIG. 7 is a signaling diagram of a UL handling collected AI / ML data following a mobility operation by continuing to log AI / ML data.

[0030] FIG. 8 is a flow diagram of a method, performed by a UE, of handling AI / ML information. FIG. 9 is a flow diagram of a method, performed by a source network node, of controlling AI / ML information.

[0031] FIG. 10 is a flow diagram of a method, performed by a target network node, of controlling AI / ML information.

[0032] FIG. 11 is a hardware block diagram of a wireless device.

[0033] FIG. 12 is a hardware block diagram of a network node.

[0034] DETAILED DESCRIPTION

[0035] A network node can be a RAN node, an OAM, a Core Network node, an 0AM, an SMO, a Network Management System (NMS), a Non-Real Time RAN Intelligent Controller (Non-RT RIC), a Real-Time RAN Intelligent Controller (RT-RIC), a gNB, eNB, en-gNB, ng-eNB, gNB- CU, gNB-CU-CP, gNB-CU-UP, eNB-CU, eNB-CU-CP, eNB-CU-UP, lAB-node, lAB-donor DU, lAB-donor-CU, IAB-DU, IAB-MT, O-CU, O-CU-CP, O-CU-UP, O-DU, O-RU, O-eNB, a UE, an M2M device, an MTC device, or an NB-loT device.

[0036] References to “network nodes” herein should be understood such that a network node may be a physical node or a function or logical entity of any kind, e.g., a software entity implemented in a data center or a cloud, e.g. , using one or more virtual machines, and two network nodes may well be implemented as logical software entities in the same data center or cloud.

[0037] The terms model training, model optimizing, model optimization, model updating are herein used interchangeably with the same meaning unless explicitly specified otherwise.

[0038] The terms model changing, modify, or similar are herein used interchangeably with the same meaning unless explicitly specified otherwise. In particular, they refer to the fact that the type, structure, parameters, or connectivity of an AI / ML model may have changed compared to a previous format / configuration of the AI / ML model.

[0039] As used herein, the term “model” refers to one or more data structures and / or algorithms used to generate a prediction from collected input data. The terms “model,” “ML model,” “Al model,” “AI / ML model,” and “Al and / or ML model,” “AI / ML policy,” “AI / ML algorithm,” as well as the terms model, policy, or algorithm, should be considered to have equivalent meanings and are used interchangeably, unless explicitly specified otherwise. An AI / ML model can be defined as a functionality or part of a functionality that is deployed / implemented in a first node, e.g., a User Equipment (UE, also referred to as a Wireless Device, or WD), in the case of a UE-sided model. An AI / ML model can be defined as a feature or part of a feature that is 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 feature version may be changed by the first node. The methods provided with the present invention are independent with respect to specific AI / ML model types or learning problems / setting (e.g., supervised learning, unsupervised learning, reinforcement learning, hybrid learning, centralized learning, federated learning, distributed learning, etc.).

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

[0041] Such algorithms may exploit functional approximation models, hereafter 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.).

[0042] Examples of reinforcement learning algorithms may include deep reinforcement learning (such as deep Q-network (DQN), proximal policy optimization (PPO), double Q- learning), actor-critic algorithms (such as Advantage actor-critic algorithms, e.g., A2C or A3C, actor-critic with experience replay, etc), policy gradient algorithms, off-policy learning algorithms, etc.

[0043] An AI / ML-model may correspond to a function which receives one or more inputs (e.g. measurements, configuration(s)) and provide as outcome one or more prediction(s) / estimates of a certain type (e.g. time-domain and / or spatial domain predictions of beam measurements). In one example, an ML-model may correspond to a function receiving as input the measurement of a reference signal at time instance to (e.g. transmitted in beam-X) and provide as outcome the prediction of the reference signal in timer t0+T.

[0044] In another example, an ML-model may correspond to a function receiving as input the measurement of a reference signal X (e.g., transmitted in beam-x), such as an SSB whose index is ‘x’, and provide as outcome the prediction of other reference signals transmitted in different beams, e.g., reference signal Y (e.g., transmitted in beam-x), such as an SSB whose index is ‘x’.

[0045] Another example is an ML-model for aid in CSI estimation - in such a setup, a joint ML- model will comprise a specific ML-model at a UE and an ML-model on the NW side. Jointly both ML-models provide joint network functionality. The function of the ML-model at the UE would be to compress a channel input and the function of the ML-model at the NW side would be to decompress the received output from the UE.

[0046] It is further possible to apply something similar for positioning, wherein the input may for example be a channel impulse in some form related to a certain reference point (typically a TP (transmit point)) in time. The purpose on the NW side would be to detect different peaks within the impulse response, that reflects the multipath experienced by the radio signals arriving at the UE side. For positioning, another example is to input multiple sets of measurements into an ML network and based on that derive an estimated position of the UE. Another example of an ML-model would be an ML-model to be able to aid the UE in channel estimation or interference estimation for channel estimation. The channel estimation could for example be for the PDSCH and be associated with specific set of reference signals patterns that are transmitted from the NW to the UE. The ML-model will then be part of the receiver chain within the UE and may not be directly visible within the reference signal pattern as such that is configured / scheduled to be used between the NW and UE. Another example of an ML-model for CSI estimation is to predict a suitable CQI, PMI, Rl, CRI (CSI-RS resource indicator) or similar value into the future.

[0047] An AI / ML model may be described in terms of the time / frequency / spatial domain. In this case, the output of the AI / ML model may be in a different time instance, or at a different frequency location, or at a different spatial direction, or a combination of time / frequency / space, than those of the model input. In one example (time domain), an ML- model may correspond to a function receiving as input the measurement of a reference signal at time instance to (e.g., transmitted in beam-X) and provide as outcome the prediction of the reference signal in time instance t0+T. In another example (spatial domain), an ML-model may correspond to a function receiving as input the measurement of a reference signal X (e.g., transmitted in beam-x), such as an SSB whose index is ‘x’, and provide as outcome the estimation / prediction of the link quality of other reference signals transmitted in different beams e.g., reference signal Y (e.g. transmitted in beam-y).

[0048] An AI / ML model may be described in terms of model structure. In this case, the ML model may be fully contained within the UE, or split between the UE and network. One example of a split structure is an ML-model for aid in CSI estimation, where a possible setup of the ML-model is a split model, which comprise a specific sub-ML-model within a UE and an sub-ML-model within the NW side which collaborate to generate a desired outcome for the overall ML model. The function of the sub-ML-model at the UE would be to compress a channel input and the function of the sub-ML-model at the NW side would be to decompress the received output from the UE. It is further possible to apply something similar for positioning wherein the input may be a channel impulse in some form related to a certain reference point in time. The purpose on the NW side would be to detect different peaks within the impulse response, that corresponds to different reception directions of radio signals at the UE side.

[0049] One example of an ML-model contained within the UE is ML-enhanced positioning, e.g., an ML-model implemented in the UE takes as input multiple sets of measurements (each corresponding to a DL signal from a different network node), and based on that derives an estimated position of the UE.

[0050] In terms of utility for physical layer, the ML-model can be used for many functions, including: channel estimation, Line Of Sight LOS / Non-Line Of Sight NLOS classification, beam selection, position estimation of the UE, link adaption, etc. For example, an ML-model may aid the UE in channel estimation, which may or may not incorporate interference estimation. The channel estimation could for example be for the PDSCH and be associated with specific set of reference signals patterns that are transmitted from the NW to the UE. The ML-model will then be part of the receiver chain within the UE and may not be directly visible within the reference signal pattern as such that is configured / scheduled to be used between the NW and UE. Another example of an ML-model for CSI estimation is to predict a suitable CQI, PMI, Rl, or similar value into the future. The future may be a certain number of slots after the UE has performed the last measurement or targeting a specific slot in time within the future.

[0051] Functional framework for AI / ML model LCM

[0052] Building the Al model, or any ML model, includes several development steps where the actual training of the Al model is just one step in a training pipeline. An important part in Al development is the ML model lifecycle management (LCM). This is illustrated in FIG. 1 , which is an illustration of a training pipeline 10 and inference pipeline 20, and their interactions within a model lifecycle management procedure 1. The model lifecycle management 30 typically consists of several components.

[0053] A training (re-training) pipeline 10 may include Data Ingestion 11 , Data Pre-Processing 12, Model Training 13, Model Evaluation 14, and Model Registration 15.

[0054] Data ingestion 11 refers to gathering raw (training) data from a data storage. After data ingestion 11 , there may also be a step that controls the validity of the gathered data.

[0055] Data pre-processing 12 refers to some feature engineering applied to the gathered data, e.g., it may include data normalization and possibly a data transformation required for the input data to the Al model.

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

[0057] Model evaluation 14 refers to benchmarking the performance to some model baseline. The iterative steps of model training and model evaluation continues until the acceptable level of performance is achieved.

[0058] Model registration 15 refers to registering the Al model, including any corresponding Al- metadata that provides information on how the Al model was developed, and possibly Al model evaluations performance outcomes.

[0059] A model deployment stage 16 makes the trained (or re-trained) Al model part of the inference pipeline 20.

[0060] An inference pipeline 20 may include Data Ingestion 21 , Data Pre-Processing 22, Model Operation 23, and Data and Model Monitoring 24.

[0061] Data ingestion 21 refers to gathering raw (inference) data from a data storage.

[0062] Data pre-processing stage 22 is typically identical to corresponding processing 12 that occurs in the training pipeline 10. Model operation 23 refers to using the trained and deployed model in an operational mode.

[0063] Data & model monitoring 24 refers to validating that the inference data are from a distribution that aligns well with the training data, as well as monitoring model outputs for detecting any performance, or operational, drifts.

[0064] A drift detection stage 25 informs about any drifts in the model operations.

[0065] FIG. 2 depicts a functional framework 30 that can be used for studying different network (NW) - User Equipment (UE) collaboration levels for the Al for physical network layer (PHY) use cases. Data collection 32 refers to the collection and storage of data to be used in training 10 and inference 20 pipelines, which are described above with reference to FIG. 1 . Management 34 refers to management of the entire model creation, training, inference, updating, and deployment process 1. Once AI / MI models are (re)trained, they are maintained in model storage 36.

[0066] UE-NW collaboration levels for one- and two-sided AI / ML models

[0067] The AI / ML models being discussed in the Rel-18 study item on AI / ML for the NR air interface can be categorized into two types.

[0068] A one-sided AI / ML model can be a UE-sided AI / ML model whose inference is performed entirely at the UE, or a NW-sided AI / ML model whose inference is performed entirely at the NW.

[0069] A two-sided AI / ML model refers to paired AI / ML Models over which joint inference is performed across the UE and the NW, i.e., the first part of the inference is firstly performed by UE and then the remaining part is performed by gNB, or vice versa.

[0070] FIG. 3 shows an example use case of autoencoder (AE)-based CSI feedback / report, where an encoder 42 (UE-part of the two-sided AE model 40) is operated at a UE to compress the estimated wireless channel 41 , and the output of the encoder 42 (the compressed wireless channel information estimates) is reported 43 from the UE to a gNB. The gNB uses a decoder 44 (NW-part of the two-sided AE model 40) to reconstruct the estimated wireless channel information 45.

[0071] Functionality based LCM and Model-ID based LCM

[0072] For UE-side models and UE-part of two-sided models, functionality based LCM and model-ID based LCM are discussed in 3GPP Rel-18.

[0073] In functionality-based LCM, the network indicates activation, deactivation, fallback, or switching of AI / ML functionality via 3GPP signaling (e.g., RRC, MAC-CE, or DCI). Models may not be identified at the Network, and the UE may perform model-level LCM. Whether and how much awareness / interaction the NW should have about model-level LCM requires further study. For functionality identification, there may be either one or more than one Functionalities defined within an AI / ML-enabled feature, whereby AI / ML-enabled Feature refers to a Feature where AI / ML may be used. Note: the UE may have one AI / ML model for the functionality, or the UE may have multiple AI / ML models for the functionality.

[0074] For AI / ML functionality identification and functionality-based LCM of UE-side models and / or UE-part of two-sided models, functionality refers to an AI / ML-enabled Feature / FG enabled by configuration(s), where configuration(s) is(are) supported based on conditions indicated by UE capability. Correspondingly, functionality-based LCM operates based on, at least, one configuration of AI / ML-enabled Feature / FG or specific configurations of an AI / ML- enabled Feature / FG.

[0075] After functionality identification, necessity, mechanisms, for UE to report updates on applicable functionality(es) among [configured / identified] functionality(es), where the applicable functionalities may be a subset of all [configured / identified] functionalities are studied. Applicable functionalities / models can be reported by the UE.

[0076] In model-ID-based LCM, models are identified at the Network, and Network / UE may activate / deactivate / select / switch individual AI / ML models via model ID.

[0077] For AI / ML model identification and model-ID-based LCM of UE-side models and / or UE- part of two-sided models, model-ID-based LCM operates based on identified models, where a model may be associated with specific configurations / conditions associated with UE capability of an AI / ML-enabled Feature / FG and additional conditions (e.g., scenarios, sites, and datasets) as determined / identified between UE-side and NW-side.

[0078] From RAN1 perspective, an AI / ML model identified by a model ID may be logical, and how it maps to physical AI / ML model(s) may be up to implementation. When distinction is necessary for discussion purposes, companies may use the term a logical AI / ML model to refer to a model that is identified and assigned a model ID, and physical AI / ML model(s) to refer to an actual implementation of such a model.

[0079] After model identification, necessity, mechanisms, for UE to report updates on applicable UE part / UE-side model(s), where the applicable models may be a subset of all identified models are studied.

[0080] For AI / ML model identification of UE-side or UE-part of two-sided models, model identification is categorized in the following types: Type A, and to variants of Type B.

[0081] A Type A Model is identified to NW (if applicable) and UE (if applicable) without over- the-air signaling. The model may be assigned with a model ID during the model identification, which may be referred or used in over-the-air signaling after model identification.

[0082] A Type B Models are identified via over-the-air signaling. There are two sub-types of Type B.

[0083] For Type B1 , model identification is initiated by the UE, and the NW assists the remaining steps (if any) of the model identification, and the model may be assigned with a model ID during the model identification. For Type B2, model identification initiated by the NW, and the UE responds (if applicable) for the remaining steps (if any) of the model identification, and the model may be assigned with a model ID during the model identification.

[0084] Note that this study does not imply that model identification is necessary.

[0085] Once models are identified, the UE can indicate supported AI / ML model IDs for a given AI / ML-enabled Feature / FG in a UE capability report as starting point. Note: model identification using capability report is not precluded for type B1 and type B2.

[0086] Model ID [in RAN1 discussion] may or may not be globally unique, and different types of model IDs may be created for a single model for various LCM purposes. Note: Details can be studied in the Wl phase.

[0087] For functionality / model-ID based LCM, once functionalities / models are identified, the same or similar procedures may be used for their activation, deactivation, switching, fallback, and monitoring.

[0088] How to handle the impact of the UE’s internal conditions such as memory, battery, and other hardware limitations on functionality / model operations and AI / ML-enabled Feature is to be studied.

[0089] UE-side model training

[0090] There are several methods for the UE-side model monitoring. In one approach the training of a UE-side model is performed at the UE itself, i.e., the UE performs both the training and the inference. However, this approach might be too complex in practice or possibly not feasible given the limited computational resources of the UE, and the large computational complexity that the training operation might imply. Also, if models are dependent on location and / or region, a single UE would not cover an entire coverage area, so that models the UE trains by itself would always be limited to the areas the UE moves around, so that every time the UE enters a new area its trained AI / ML models could be outdated. Hence, alternative approaches for training UE-sided models include the possibility that a network node, e.g. , a radio access node like a gNB or a Core Network (CN) node (e.g., the Network Data Analytics Function, or NWDAF), collects data from a UE and trains an AI / ML model that at some point should be delivered / transferred to that UE or other UEs, which will then apply it. Further, an Over-the-Top (OTT) server, outside 3GPP, may be in charge of performing the training. This server could be for example a UE-vendor specific server. This latter approach might be a reasonable candidate because in order to have optimal performances, the trained data set should fit the inference operations at the device, which may depend on UE-vendor specific implementations (e.g., software / hardware properties / capabilities).

[0091] Irrespective of whether the UE-side model training is performed by a node outside the RAN, e.g., in a core network node, or even outside the 3GPP network, a certain amount of data needs to be collected by the UE, in order to enable such a node to perform model training. This is because for many use cases, such as Al-based CSI compression, Al-based CSI prediction, Al-based beam management, Al-based positioning, Al-based mobility predictions, Al-based traffic predictions, etc., the training node needs to receive inputs from the UE. Hence, one can envisage a protocol in which the UE does training (e.g., upon receiving a triggering from the training node) for a certain amount of time, it collects data, and once the data collection is completed, it transfers the collected data to the training node.

[0092] The following table showing the mapping between functionalities and entities was agreed in 3GPP R2-2308286.

[0093] NW-side model training

[0094] Related to NW-side model training, it has been assumed so far in 3GPP that the gNB and / or the Operations, Administration and Maintenance (OAM) will be in charge of that. If the gNB is responsible, it is assumed that the gNB may configure the UE with a set of resources, e.g., CSI-RS resources or SSB resource sets in which the UE should collect measurements for a certain amount of time. Then the UE will report what it measured to the gNB, e.g., via RRC signaling. Then the training can be performed in the gNB itself, or in another node controlled by the gNB-vendor, e.g., an OTT server handled by the gNB-vendor.

[0095] A similar approach would apply for the case in which the OAM does the NW-side training. In this case, the OAM may request the gNB to provide to the UE a certain configuration according to which the UE should perform certain measurements, and collect data. Once the data collection is completed, the UE will transfer the collected data to the OAM, e.g., using the MDT framework such as the immediate MDT or the logged MDT.

[0096] The following table showing the mapping between functionalities and entities was agreed in 3GPP R2-2308286.

[0097] Certain challenges exist. While performing data collection, the UE collects and stores measurements in its memory, until those collected measurements are transmitted to the gNB, e.g., periodically, or upon fulfilling of certain configured events, or on demand upon gNB- request.

[0098] It can happen, however, that while collecting such measurements, the UE performs a mobility procedure (e.g., a handover (HO) or a reconfiguration with sync), or experience a radio link failure, while having residual stored AI / ML based collected measurements that are not yet transmitted to the NW. In such case, it is not clear how the UE would handle such residual collected measurements not yet transmitted to the NW.

[0099] According to methods described herein the UE is connected to the network (e.g., it may receive and transmit data and / or control information), i.e., in RRC_CONNECTED state, and, being configured to perform a specific function by using an AI / ML-model (which may be referred as an AI / ML-model functionality, e.g., beam measurement predictions in timedomain). The specific functionality or function of an AI / ML model can for example be for one of the following examples, which could also be grouped to as a functionality area (one or more AI / ML-model functionality per area).

[0100] The AI / ML-model may assist in CSI reporting.

[0101] The AI / ML-model may perform Beam Management (BM). In one option, there is a BM functionality of an AI / ML-model(s) wherein an AI / ML model (e.g., at the UE) performs the inference of one or more time-domain predictions related to beam management. For example, the UE is configured by the network to report (e.g., on PUCCH and / or PUSCH) one or more time-domain predictions of SSB and / or CSI-RS and / or PTRS measurements, e.g., by receiving a reporting configuration for AI / ML.

[0102] In another option, there is a BM functionality of an AI / ML-model(s) wherein an AI / ML model (e.g., at the UE) performs the inference of one or more spatial-domain predictions related to beam management.

[0103] In yet another option, there is a BM functionality of an AI / ML-model(s) wherein an AI / ML model (e.g., at the UE) performs the inference of both time and spatial-domain predictions related to beam management.

[0104] The UE is considered to be configured with a AI / ML functionality when at least one action related to that functionality is configured, e.g., the UE is configured to report predictions of beam measurement to one of its configured serving cell(s) and / or CSI(s) and / or SSB(s) of a serving cell,

[0105] The AI / ML-model may assist in Radio Resource Management (RRM) measurement.

[0106] One example is mobility measurement, i.e., RSRP, RSRQ, RSSI, but also aspects related to radio link failure, e.g., RLF predictions. Further, RLM related timers (T310) and counters (N310 and N311) related predictions could also be considered here.

[0107] Another example is the measurement framework defined in 3GPP TS 38.331 § 5.5, comprising how the UE perform measurements (e.g., measurement configuration), what triggers measurement reports (e.g., event-triggered reports, periodic reports), and content to be included in measurement reports.

[0108] The AI / ML-model may perform or assist in link adaptation, HARQ transmission, data transmission or reception, power control, UE positioning, Random Access transmissions, or energy efficiency (e.g., DRX settings).

[0109] The methods disclosed above may be applicable to the AI / ML model(s) associated to an AI / ML model functionality, or to the AI / ML model functionalities interchangeably.

[0110] Method at the UE for handling the AI / ML measurements and measurement configuration information upon mobility

[0111] FIG. 4 depicts signaling and steps for the overall method, performed at a User Equipment (UE), for the data collection from the UE using an L3 configuration and reporting for AI / ML model training purpose. In FIG. 4, the specific example of a reconfiguration with sync is used as the mobility operation.

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

[0113] In a second step, the UE performs the AI / ML measurement collection according to the measurement configuration information provided by the first node, wherein the data collection implies the UE is logging the collected data in its memory.

[0114] In a third step, one of the following operations is performed: a mobility operation; an RRC state transition; a radio link failure; or a change of PSCell.

[0115] A mobility operation can be one of: a normal handover or a reconfiguration with sync or a Mobility from NR to another RAN (e.g. , LTE); a conditional handover / reconfiguration with sync execution based on a triggered event; or an LTM event i.e., Layer1 / Layer2 based mobility or a cell switch).

[0116] The RRC state transition may be from the RRC_CONNECTED mode to RRCJDLE or RRCJNACTIVE; or from RRCJDLE or RRCJNACTIVE to RRC_CONNECTED mode.

[0117] The radio link failure may be experienced in the SpCell. A change of PSCell may be via a reconfiguration with sync procedure, or a conditional reconfiguration with sync procedure, or a LTM procedure.

[0118] In a fourth step, in response to the operation of step 3, the data collected based on the AI / ML measurement configuration that is logged but not yet sent to the network (or not being retrieved by the network), is handled according to one of several procedures. The UE may deleted it; send it to the target RAN node; continue to perform AI / ML measurements; indicate to the target RAN node the availability of previously collected data; or indicate to the target RAN node whether the AI / ML measurement configuration was configured by the source node.

[0119] UE deletes collected but not transmitted AI / ML measurement data

[0120] FIG. 5 depicts the case that the UE deletes the collected AI / ML measurements. In some aspects, the UE also deletes the received AI / ML configuration.

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

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

[0123] In case of mobility operations, the source node may indicate as part of the RRC reconfiguration with sync whether the UE should delete the collected and not yet transmitted AI / ML measurements and / or the AI / ML measurement configuration information.

[0124] Whether to send this indication to the UE may depend on whether the target node supports retrieval of the collected data from the UE, or whether the AI / ML measurement configuration configured by the source node is valid also in the target node. For example, the source node may indicate to the target node as part of the HO preparation, that the UE has collected and not yet transmitted AI / ML measurements available, 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 transmission of the collected data in the target node and / or if the UE should keep or release the AI / ML measurement configuration provided by the source node. In another embodiment, the target node may then indicate to the UE, e.g., in the HO command, whether the UE can perform transmission of the collected data in the target node and / or if the UE should keep or release the AI / ML measurement configuration provided by the source node.

[0125] In case of radio link failure, or handover failure, the indication may be transmitted by the target node in which the UE successfully reestablishes, e.g., in the RRCReestablishment, or in a subsequent RRCReconfiguration. This indication may be transmitted by the target node, in response to receiving from the source node, during a context fetch retrieval procedure, information indicating that the UE had collected data available at the moment of radio link failure, or handover failure.

[0126] In case of transition from RRC_CONNECTED to RRCJDLE or RRCJnactive, the source node may provide the indication, e.g., as part of the RRCRelease.

[0127] In one aspect, the source node provides an indication of whether to delete the collected AI / ML measurements and / or the AI / ML measurement configuration 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 the collected and not yet transmitted AI / ML measurements and / or the AI / ML measurement configuration information. Alternatively, the source node may indicate the area scope in which the UE should keep the collected and not yet transmitted AI / ML measurements and / or the AI / ML measurement configuration information. The UE then keeps or deletes the AI / ML measurements and / or the AI / ML measurement configuration information in response to whether the target node belongs to the area scope.

[0128] In one aspect, if the mobility command includes a full configuration (FullConfig), the UE deletes both the AI / ML measurement configuration and the collected AI / ML based measurement reports.

[0129] UE keeps the collected AI / ML measurements and sends the report to the target RAN node FIG. 6 depicts the case that the UE stores and sends the AI / ML based measurement reports to the target RAN node, which forwards them back to the source node upon mobility, and the UE deletes the AI / ML measurement configuration.

[0130] In one aspect, the UE indicates the availability of the measurements logged ( / .e., measurement collected but not yet transmitted) based on the AI / ML configuration, to the target RAN node upon connecting to target RAN node, via RRC signaling, e.g., an RRCReconfigurationComplete message.

[0131] In another aspect, the UE indicates to the target RAN node that the available measurements are based on a configuration configured by the first / source RAN node before transmitting the measurements, so the target RAN node can forward the measurements back to the first / source node.

[0132] The UE may send the measurements logged based on the AI / ML configuration to the target RAN node upon receiving a request from the target RAN node after the UE connects to the target RAN node. For example, in case of mobility operations the source node may indicate as part of the HO preparation procedure that the UE has collected data logged that are not yet transmitted to the source node. The target node may then indicate to the UE, e.g., as part of the HO command, to continue the transmission of collected data upon successfully completing the HO to the target node. In case of reestablishment, the target node to which the UE reestablishes its connection may indicate to the UE to send the logged measurements upon receiving from the UE, e.g. in the RRCReconfigurationComplete message, upon successful reestablishment, that the UE has available measurements.

[0133] The target RAN node, upon receiving the AI / ML based collected measurement, may send the retrieved measurements to the source RAN node.

[0134] UE continues to perform the AI / ML measurements

[0135] FIG. 7 depicts the case that the UE keeps the AI / ML measurement collection configuration and continues logging the AI / ML based data collection in the target cell and sending AI / ML based measurement reports to the target RAN node, which forwards them back to the source node.

[0136] In this aspect, the UE continues to perform the AI / ML measurements based on the received AI / ML measurement configuration from the source RAN node, after connecting to the target node, in case the received AI / ML measurement configuration is valid also for the target node. In this aspect, the UE keeps the received AI / ML measurement configuration, upon performing the mobility operation.

[0137] In one variant of this aspect, the UE performs this step if the AI / ML configuration includes an area scope indicating that UE shall continue the measurement in an area including the target cell.

[0138] In this aspect, the source RAN node may send the configured AI / ML configuration to the target RAN node upon mobility.

[0139] In another aspect, the source RAN node signals to the target RAN node the AI / ML configuration configured at the UE, either as part of the UE RRC context or as part of explicit inter-RAN node application protocol interfaces, such as Xn or NG interfaces.

[0140] In yet another aspect, upon connecting to target RAN node, the UE indicates the availability of the collected, but not yet transmitted, AI / ML measurements to the target RAN node.

[0141] In still another aspect, upon connecting to target RAN node, the UE indicates to the target RAN node whether an AI / ML measurement configuration was configured by the source node to the UE.

[0142] Additional Aspects

[0143] In some further aspects, the UE includes the AI / ML training data availability indication in an RRC measurement report that is sent to the source node. The UE includes such an indication (or sets the indication to TRUE) in a measurement report when the UE has at least one measurement to be reported as part of the training data for AI / ML model training. In some embodiments, this indication can be individually set per model ID and / or per AI / ML functionality ID or AI / ML training data collection configuration ID. In one variant, the UE includes such an indication in every transmitted RRC measurement report as long as the UE has at least one AI / ML model training configuration configured at the UE.

[0144] In another variant, the UE includes such an indication in the RRC measurement report only if the corresponding measurement report’s configuration includes a configuration requesting the UE to include the status of the AI / ML model training data availability at the UE. Such a configuration can be individually requested per model ID and / or per AI / ML functionality ID or AI / ML training data collection configuration ID.

[0145] In yet another variant, the UE includes such an indication in the RRC measurement report only if the corresponding measurement report’s configuration includes a configuration associated to reconfiguration with sync. For example, if the corresponding measurement configuration includes T312 timer usage to be set to TRUE, then the UE includes the AI / ML model training data availability status in the measurement report if the UE has the T312 timer running at the time of transmitting the measurement report or if the T312 is initiated at the start of the transmission of this measurement report.

[0146] In one aspect, upon receiving such an indication in the measurement report, the source node fetches the corresponding AIML training data from the UE.

[0147] In one aspect, upon receiving such an indication in the measurement report, the source node forwards the indication to the target node as part of the Handover Preparation Request message. The target node then uses this information in sending a second indication to the UE, to indicate whether to delete / keep the measurements before entering the target cell. This second indication can be configured by the target cell as part of the 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 the handover / reconfiguration with sync procedure towards the target cell, then the UE checks whether the target node has indicated the UE to delete the stored AIML model training data or keep the same and the UE shall act accordingly. The second indication can be individually set per model ID and / or per AIML functionality ID or AIML training data collection configuration ID.

[0148] Methods and Apparatuses

[0149] FIG. 8 depicts a method 100, performed by a User Equipment (UE) operative in a wireless communication network, of handling information related to Artificial Intelligence (Al) or Machine Learning (ML). Configuration information specifying measurements and data collection for AI / ML model training is received from a source network node (block 102). AI / ML related measurements and data collection are performed according to the configuration information, and the collected data is stored (block 104). A network connection to the source network node is terminated or lost (block 106). The AI / ML related measurements and data collected but not yet transmitted to the network are handled according to the configuration information (block 108).

[0150] FIG. 9 depicts a method 200, performed by a source network node operative in a wireless communication network, of controlling information related to AI / ML. A UE is served (block 202). Configuration information specifying measurements and data collection for AI / ML model training is transmitted to the UE (block 204). A network connection to the UE is terminated or lost (block 206). The configuration information specifying measurements and data collection by the UE for AI / ML model training is transmitted to a target network node to which the UE subsequently connects (block 208).

[0151] FIG. 10 depicts a method 300, performed by a target network node operative in a wireless communication network, of controlling information related to AI / ML. A UE is served after the UE terminated or lost a network connection to a source network node (block 302). AI / ML related measurements and data collected the UE acquired while connected to the source network node, but which has not yet transmitted to the network are received from the UE (block 304). The AI / ML related measurements and data collected by the UE are transmitted to the source network node (block 306).

[0152] Figure 11 depicts a wireless device 50, such as a UE, operative in a wireless communication network and configured handle the disposition of AI / ML related measurements and data collected but not yet transmitted to the network as described herein. As used herein, a UE 50 is any type of device capable of communicating with a base station, another UE 50, or other network node, over radio signals. A UE 50 may therefore refer to a cellphone or smartphone, a machine-to-machine (M2M) device, a machine-type communications (MTC) device, a Narrowband Internet of Things (NB loT) device, etc. Despite its name, a UE 50 does not necessarily have a “user” in the sense of an individual person owning and / or operating the device. A UE 50 may also be referred to as a radio device, a radio communication device, a wireless communication device, a wireless terminal, or simply a terminal — unless the context indicates otherwise, the use of any of these terms is intended to include device-to-device UEs or devices, machine-type devices, or devices capable of machine-to-machine communication, sensors equipped with a radio network device, wireless-enabled table computers, mobile terminals, smart phones, laptop-embedded equipped (LEE), laptop-mounted equipment (LME), USB dongles, wireless customer-premises equipment (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 UEs 50, but may be configured to transmit and / or receive data without direct human interaction.

[0153] The UE 50 includes processing circuitry 52, memory 54, and communication circuitry 56. The processing circuitry 52 is configured to perform methods according to aspects described herein, such as by executing software code stored in memory 54. The processing circuitry 52 is operatively connected to communication circuitry 56, which includes radio circuits, such a Radio Frequency (RF) transceiver connected to one or more antennas 58, to effect wireless communication across an air interface to one or more base stations, access points, or other UEs 50. As indicated by the dashed lines, the antenna(s) 58 may protrude externally from the UE 50, or the antenna(s) 58 may be internal. In some aspects, the UE 50 includes a user interface (not shown), which may include features such as a display, touchscreen, keyboard or keypad, microphone, speaker, and the like). In some embodiments, such as in many M2M, MTC, or NB loT scenarios, the UE 50 may include only a minimal, or no, user interface.

[0154] Figure 12 depicts a network node 60 operative in the wireless communication network and configured as a base station. The network node 60 is configured to control a UE’s 50 handling of AI / ML related measurements and data collected but not yet transmitted to the network as described herein. As known in the art, a base station 60 provides wireless communication services to one or more UEs 50 in a geographic region (known as a cell or sector). The network node 60 may assume the role of a source network node or a target network node, as described herein. The network node 60 includes processing circuitry 62, memory 64, and communication circuitry 66. The processing circuitry 62 is configured to perform methods according to aspects described herein, such as by executing software code stored in memory 64. The processing circuitry 62 is operatively connected to communication circuitry 66, which includes circuitry configured to communicate with other network nodes, such as by a wired or wireless interface. The communication circuitry 66 additionally includes radio circuits, such as an RF transceiver, and is connected to one or more antennas 68, to effect wireless communication across an air interface to one or more UEs. As indicated by the continuation lines in the antenna feed line of FIG. 12, the antenna(s) 68 may be physically located separately from the network node 60, such as mounted on a tower, building, or the like.

[0155] In all aspects described herein, the processing circuitry 52, 62 may comprise any sequential state machine operative to execute machine instructions stored as machine- readable computer programs in the memory, 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 a microprocessor or Digital Signal Processor (DSP), together with appropriate software; or any combination of the above. Although depicted as being contained in the wireless device 50 or network node 60, the processing circuitry 52, 62 may in some aspects be located remotely. In some aspects, the processing circuitry 52, 62 may comprise virtualized servers located at one or more data centers, commonly referred to as the ’’cloud.” The blocks 52, 62 labeled ’’processing circuitry” include memory 54, 64, as well as other circuitry, such as power control circuitry, co-processors, dedicated hardware (en / decryption, graphics processing, user interface control), and the like.

[0156] In all embodiments described herein, the memory 54, 64 may comprise any nontransitory machine-readable media known in the art or that may be developed, including but not limited to magnetic media (e.g. , floppy disc, hard disc drive, etc.), optical media (e.g., CD-ROM, DVD-ROM, etc.), solid state media (e.g., SRAM, DRAM, DDRAM, ROM, PROM, EPROM, Flash memory, solid state disc, etc.), or the like.

[0157] In all embodiments described herein, the communication circuits 56, 66 may comprise a transceiver interface used to communicate with one or more other nodes over a communication network according to one or more communication protocols known in the art or that may be developed, such as Ethernet, TCP / IP, SONET, ATM, or the like. The UE communication circuits 56, and in the case the network node 60 implements a base station, the communication circuits 66 implement RF transceiver functionality appropriate to the wireless communication network links (e.g., RF signaling conforming to 3GPP specifications, Wi-Fi, or the like).

[0158] Example implementation upon receiving an RRC Reconfiguration including a Full Configuration

[0159] The UE shall (the underlined parts relating to aspects of the present disclosure): 1> release / clear all current dedicated radio configurations except for the following:

[0160] - the MCG C-RNTI;

[0161] - the AS security configurations associated with the master key;

[0162] - the SRB1 / SRB2 configurations and DRB / multicast MRB configurations as configured by radioBearerConfig or radioBearerConfig2.

[0163] NOTE 1: Radio configuration is not just the resource configuration but includes other configurations like MeasConfig. Radio configuration also includes the RLC bearer configurations as configured by RLC-BearerConfig, PC5 Relay RLC channel as configured by SL-RLC- ChannelConfig, and Uu Relay RLC channel as configured by Uu-RelayRLC-ChannelConfig. In case NR-DC or NE-DC is configured, this also includes the entire NR or E-UTRA SCG configuration which are released according to the MR-DC release procedure as specified in 5.3.5.10. NOTE la: For NR sidelink communication / discovery, the radio configuration includes the sidelink RRC configuration received from the network, but does not include the sidelink RRC reconfiguration and sidelink UE capability received from other UEs via PC5-RRC. In addition, the UE considers the new NR sidelink configurations as full configuration, in case of state transition and change of system information used for NR sidelink communication / discovery .

[0164] NOTE lb: To establish the RLC bearer of SRB(s) after release due to fullConfig, the network can include the srb-Identity within srb-ToAddModList (i.e. the UE applies RLC default configuration) and / or provide rlc-BearerToAddModList of concerned SRB(s) explicitly.

[0165] - the logged measurement configuration;

[0166] 1> if the spCellConfig in the masterCellGroup includes the reconfigurationWithSync.

[0167] 2> release / clear all current common radio configurations;

[0168] 2> release / clear all current measurements collected based on AI / ML measurement configurations;

[0169] 2> release / clear all the stored AI / ML measurement configurations;

[0170] 2> if sl-PathSwitchConfig was included in reconfigurationWithSync.

[0171] 3> use the default values specified in 9.2.3 for timer T311;

[0172] 2> else:

[0173] 3> use the default values specified in 9.2.3 for timers T310, T311 and constants N310, N311 ;

[0174] 1> else (full configuration after re-establishment or during RRC resume):

[0175] 2> if the UE is acting as L2 U2N Remote UE:

[0176] 3> use value for timer T311, as included in ue-TimersAndConstants received in SIB I

[0177] 2> else:

[0178] 3> use values for timers T301, T310, T311 and constants N310, N311, as included in ue- TimersAndConstants received in SI BP.

[0179] 1> if no measConfigAppLayerld is included:

[0180] 2> inform upper layers about the release of all application layer measurement configurations;

[0181] 2> discard any received application layer measurement report from upper layers;

[0182] 2> consider itself not to be configured to send application layer measurement report. 1> if the UE is acting as L2 U2N Remote UE at the target side during reconfiguration with sync, or after re-establishment, or during RRC resume:

[0183] 2> apply the default configuration of SL-RLC1 as specified in clause 9.2.4 and associate it with the SRB1;

[0184] 1> else:

[0185] 2> apply the default LI parameter values as specified in corresponding physical layer specifications except for the following:

[0186] - parameters for which values are provided in SIB1-,

[0187] 2> apply the default MAC Cell Group configuration as specified in 9.2.2;

[0188] 2> for each srb-Identity value included in the srb-ToAddModList (SRB reconfiguration):

[0189] 3> establish an RLC entity for the corresponding SRB;

[0190] 3> apply the default SRB configuration defined in 9.2.1 for the corresponding SRB;

[0191] NOTE 2: This is to get the SRBs (SRB1 and SRB2 for reconfiguration with sync and SRB2 for resume and reconfiguration after re-establishment) to a known state from which the reconfiguration message can do further configuration.

[0192] 1> for each pdu-Session that is part of the current UE configuration:

[0193] 2> release the SDAP entity (clause 5.1.2 in TS 37.324

[0024] );

[0194] 2> release each DRB associated to the pdu-Session as specified in 5.3.5.6.4;

[0195] NOTE 3: This will retain the pdu-Session but remove the DRBs including drb-identity of these bearers from the current UE configuration. Setup of the DRBs within the AS is described in clause 5.3.5.6.5 using the new configuration. The pdu-Session acts as the anchor for associating the released and re-setup DRB. In the AS the DRB re-setup is equivalent with a new DRB setup (including new PDCP and logical channel configurations).

[0196] 1> for each mbs-Sessionld that is part of the current UE configuration and associated to a multicast MRB:

[0197] 2> release the SDAP entity (clause 5.1.2 in TS 37.324

[0024] );

[0198] 2> release each multicast MRB associated to the mbs-Sessionld as specified in 5.3.5.6.6; NOTE 4: This will retain the mbs-Sessionld but remove the multicast MRBs including mrb-identity of these bearers from the current UE configuration. Setup of the multicast MRBs within the AS is described in clause 5.3.5.6.7 using the new configuration. The mbs-Sessionld acts as the anchor for associating the released and re-setup multicast MRB. In the AS the multicast MRB re-setup is equivalent with a new multicast MRB setup (including new PDCP and logical channel configurations).

[0199] 1> for each pdu-Session that is part of the current UE configuration but not added with same pdu- Session in the drb-ToAddModList'.

[0200] 2> if the procedure was triggered due to reconfiguration with sync:

[0201] 3> indicate the release of the user plane resources for the pdu-Session to upper layers after successful reconfiguration with sync;

[0202] 2> else:

[0203] 3> indicate the release of the user plane resources for the pdu-Session to upper layers immediately;

[0204] 1> for each mbs-Sessionld that is part of the current UE configuration but not added with the same mbs-Sessionld in the mrb-ToAddModList'.

[0205] 2> if the procedure was triggered due to reconfiguration with sync:

[0206] 3> indicate the release of the user plane resources for the mbs-Sessionld to upper layers after successful reconfiguration with sync;

[0207] 2> else:

[0208] 3> indicate the release of the user plane resources for the mbs-Sessionld to upper layers immediately.

[0209] Advantages of Aspects of the Present Disclosure

[0210] Aspects of the present disclosure enable a UE to handle unretrieved AI / ML measurements and the configured AI / ML measurement configuration information upon mobility procedures such as a handover, an RRC reconfiguration with sync, or a L1 / L2 mobility procedure. This allows the collected AI / ML data to be salvaged and used for ML model training, avoiding a waste of UE power in having collected the data.

[0211] In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain 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 the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer- readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and / or by end users and a wireless network generally.

[0212] The present invention may, of course, be carried out in other ways than those specifically set forth herein without departing from essential characteristics of the invention.

[0213] The present embodiments are to be considered in all respects as illustrative and not restrictive, and all changes coming within the meaning and equivalency range of the appended embodiments are intended to be embraced therein.

Claims

CLAIMSWhat is claimed is:

1. A method (100), performed by a User Equipment, UE (50), operative in a wireless communication network, of handling information related to Artificial Intelligence, Al, or Machine Learning, ML, the method (100) comprising: receiving (102), from a source network node (60), configuration information specifying measurements and data collection for AI / ML model training; performing (104) AI / ML related measurements and data collection according to the configuration information, and storing the collected data; terminating or losing (106) a network connection to the source network node (60); and handling (108) the AI / ML related measurements and data collected but not yet transmitted to the network according to the configuration information.

2. The method (100) of claim 1 wherein terminating or losing (106) a network connection to the source network node (60) comprises performing a mobility operation.

3. The method (100) of claim 2 wherein the mobility operation is one of a handover, a reconfiguration with sync, and a mobility to a different Radio Access Network.

4. The method (100) of claim 2 wherein the mobility operation is a handover or reconfiguration with synch execution based on a triggered event.

5. The method (100) of claim 2 wherein the mobility operation is a lower layer triggered mobility.

6. The method (100) of claim 1 wherein terminating or losing (106) a network connection to the source network node (60) comprises performing an RRC state transition, in either direction, between RRC_CONNECTED mode and one of RRCJDLE and RRCJNACTIVE modes.

7. The method (100) of claim 1 wherein terminating or losing (106) a network connection to the source network node (60) comprises experiencing a radio link failure.

8. The method (100) of claim 1 wherein handling (108) the AI / ML related measurements and data collected but not yet transmitted to the network according to the configuration information comprises deleting one or both of the AI / ML related measurements and datacollected but not yet transmitted to the network and the configuration information specifying measurements and data collection for AI / ML model training.

9. The method (100) of claim 8 wherein the configuration information specifying measurements and data collection for AI / ML model training indicates whether to delete either or both of of the AI / ML related measurements and data collected but not yet transmitted to the network and the configuration information specifying measurements and data collection for AI / ML model training upon terminating or losing the network connection to the source network node (60).

10. The method (100) of claim 9 wherein the indication whether to delete either or both of of the AI / ML related measurements and data collected but not yet transmitted to the network and the configuration information specifying measurements and data collection for AI / ML model training is conditional on an identity or location of a target node (60).11 . The method (100) of claim 8 wherein terminating or losing (106) a network connection to the source network node (60) comprises the source node (60) performing an RRC reconfiguration with sync, and wherein the source node (60) indicates whether to delete either or both of of the AI / ML related measurements and data collected but not yet transmitted to the network and the configuration information specifying measurements and data collection for AI / ML model training as part of the RRC reconfiguration with sync.

12. The method (100) of claim 8 wherein terminating or losing (106) a network connection to the source network node (60) comprises transitioning from RRC_CONNECTED mode and one of RRCJDLE and RRCJNACTIVE modes, and wherein the source network node (60) indicates whether to delete either or both of of the AI / ML related measurements and data collected but not yet transmitted to the network and the configuration information specifying measurements and data collection for AI / ML model training as part of an RRCRelease.

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

14. The method (100) of claim 13 wherein terminating or losing (106) a network connection to the source network node (60) comprises performing a handover, and wherein the target node (60) indicates whether to delete either or both of of the AI / ML related measurements and data collected but not yet transmitted to the network and the configuration informationspecifying measurements and data collection for AI / ML model training as part of a handover command.

15. The method (100) of claim 13 wherein terminating or losing (106) a network connection to the source network node (60) comprises a radio link failure or failed handover, and wherein the target node (60) indicates whether to delete either or both of of the AI / ML related measurements and data collected but not yet transmitted to the network and the configuration information specifying measurements and data collection for AI / ML model training as part of an RRCReestablishment, or in a subsequent RRCReconfiguration.

16. The method (100) of claim 13 wherein handling (108) the AI / ML related measurements and data collected but not yet transmitted to the network according to the configuration information comprises: transmitting the AI / ML related measurements and data collected but not yet transmitted to the network to the target network node (60).

17. The method (100) of claim 16 further comprising deleting the configuration information specifying measurements and data collection for AI / ML model training.

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

19. The method (100) of claim 16 wherein transmitting the AI / ML related measurements and data collected but not yet transmitted to the network to the target network node (60) is performed in response to a request for the AI / ML related measurements and data collected but not yet transmitted to the network from the target network node (60).

20. The method (100) of claim 13 wherein handling (108) the AI / ML related measurements and data collected but not yet transmitted to the network according to the configuration information comprises: continuing to perform AI / ML related measurements and data collection according to the configuration information.21 . The method (100) of claim 20 wherein the configuration information specifying measurements and data collection for AI / ML model training indicates and area scope, and wherein the target node (60) is within the area.

22. The method (100) of claim 13 wherein handling (108) the AI / ML related measurements and data collected but not yet transmitted to the network according to the configuration information comprises: indicating to the target network node (60) an availability of previously collected AI / ML related measurements and data.

23. The method (100) of claim 13 wherein handling (108) the AI / ML related measurements and data collected but not yet transmitted to the network according to the configuration information comprises: indicating to the target RAN node (60) whether the AI / ML measurement configuration was configured by the source network node (60).

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

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

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

27. The method (100) of either of claims 25 or 26 wherein the indication of AI / ML related measurements and data availability or configuration requesting a status of the AI / ML related measurements and data availability is per ML-model ID or per-AI / ML functionality ID or 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 AI / ML related measurements and data collected but not yet transmitted to the network in a transmitted RRC measurement report only if the corresponding measurement report’s configuration includes a configuration associated to reconfiguration with sync.

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

30. The method (100) of claim 24, further comprising: in response to transmitting an indication of the availability of AI / ML related measurements and data collected but not yet transmitted to the network in an RRC measurement report, receiving, from the target network node (60), an indication whether to delete or keep the AI / ML related measurements and data before entering a target cell.31 . User Equipment (50), operative in a wireless communication network implementing Artificial Intelligence, Al, or Machine Learning, ML, characterized by: communication circuitry (56) configured to communicate with one or more network nodes (60); and processing circuitry (52) operatively connected to the communication circuitry (56), the processing circuitry (52) configured to perform the method (100) of any of claims 1-30.

32. A method (200), performed by a source network node (60) operative in a wireless communication network, of managing information related to Artificial Intelligence, Al, or Machine Learning, ML, the method (200) comprising: serving (202) a User Equipment, UE (50); transmitting (204), to the UE (50), configuration information specifying measurements and data collection for AI / ML model training; terminating or losing (206) a network connection to the UE (50); and transmitting (208), to a target network node (60) to which the UE (50) subsequently connects, the configuration information specifying measurements and data collection by the UE (50) for AI / ML model training.

33. A source network node (60), operative in a wireless communication network implementing Artificial Intelligence, Al, or Machine Learning, ML, characterized by: communication circuitry (66) configured to communicate with a User Equipment, UE (50), and one or more network nodes (60); and processing circuitry (62) operatively connected to the communication circuitry (66), the processing circuitry (62) configured to perform the method (200) of claim 32.

34. A method (300), performed by a target network node (60) operative in a wireless communication network, of managing information related to Artificial Intelligence, Al, or Machine Learning, ML, the method (300) comprising: serving (302) a User Equipment, UE (50), after the UE (50) terminated or lost a network connection to a source network node (60); receiving (304), from the UE (50), AI / ML related measurements and data collected the UE (50) acquired while connected to the source network node (60), but which has not yet transmitted to the network; and transmitting (306), to the source network node (60), the AI / ML related measurements and data collected by the UE (50).

35. A target network node (60), operative in a wireless communication network implementing Artificial Intelligence, Al, or Machine Learning, ML, characterized by: communication circuitry (66) configured to communicate with one or more network nodes (60); and processing circuitry (62) operatively connected to the communication circuitry (66), the processing circuitry (62) configured to perform the method (300) of claim 34.

Images