WO2025166800A1 - A method for ai/ml based mobility management - Google Patents

Abstract

This disclosure is directed generally to wireless communication networks and particularly to configuration and provisioning of Artificial Intelligence (AI) and/or Machine Learning (ML) (AI. ML) functionalities and models in both terminal devices and network nodes in wireless communication networks. For example, a network node may configure a terminal device with respect to measurements intended for AI/ML functionalities in terms of measurement time, objects, reporting and the like. The terminal device may preform and report measurements based on such configuration. Alternatively, the terminal device may further preform predictions based on the measurement using terminal side AI/ML functionalities. The network node may receive the measurements and further perform prediction using network side AI/ML functionalities, or alternatively receive predictions and/or measurements from the terminal device. The predictions may then be used manage mobility of the terminal device for a future time.

Description

A METHOD FOR AI/ML BASED MOBILITY MANAGEMENTTECHNICAL FIELD

This disclosure is directed generally to wireless communication networks and particularly to configuration and provisioning of Artificial Intelligence (AI) and/or Machine Learning (ML) functionalities and models in both terminal devices and network nodes in wireless communication networks.

BACKGROUND

In a wireless communication system, determination of adaptive network configuration of communication resources particularly within an over-the-air communication interface may require lengthy and resource-intensive measurement/reporting processes and/or significant amounts of computation power. Such types of configurations of communication resources may include but are not limited to mobility management, radio failure management, beam management, and the like. Correlation between various network conditions and these adaptive resource configurations may be learned via artificial intelligence (AI) techniques and models and utilized to assist in provisioning of the wireless communication. In particularly, it may be beneficial to utilize AI techniques and models to predict network conditions for assisting mobility management in some cases (e.g., when UE’s mobility is high or is among micro cells of high density or with future services) .

SUMMARY

This disclosure is directed generally to wireless communication networks and particularly to configuration and provisioning of Artificial Intelligence (AI) and/or Machine Learning (ML) (AI. ML) functionalities and models in both terminal devices and network nodes in wireless communication networks. For example, a network node may configure a terminal device with respect to measurements intended for AI/ML functionalities in terms of measurement time, objects, reporting and the like. The terminal device may preform and report measurements based on such configuration. Alternatively, the terminal device may further preform predictions based on the measurement using terminal side AI/ML functionalities. The network node may receive the measurements and further perform prediction using network side AI/ML functionalities, or alternatively receive predictions and/or measurements from the terminal device. The predictions may then be used to manage mobility of the terminal device for a future time.

In one example implementation, a method performed by a user equipment (UE) in communication with a network (NW) in a wireless communication network is disclosed. The method may include receiving a measurement configuration from the NW; performing at least one measurement on one or more measurement objects according to the measurement configuration to obtain measurement results;

performing a prediction by processing the measurement results using a UE-side Artificial Intelligence and/or Machine Learning (AI/ML) functionality; transmitting a report based on the measurement results and/or the prediction to the NW; and performing a mobility operation based on the measurement results and/or the prediction.

In the example implementation above, the measurement configuration comprises at least one of: a measurement object list to indicate the one or more measurement objects that the UE needs to measure or perform prediction on; indications of whether AI/ML predictions on the one or more measurement objects or measurement identity are allowed or not; or a reporting configuration list to indicate how to report the measurement results and/or the prediction to the NW.

In any one of the example implementations above, the report comprises or indicates at least one of: a measurement ID for identifying the at least one measurement; a list of cell IDs or indexes; a list of beam IDs or indexes; the measurement results associated with the one or more measurement objects; a timestamp to specify when the event would be triggered; or an indication of whether the measurement results are from AI/ML prediction.

In any one of the example implementations above, the timestamps each comprises: an absolute time value; or a delta time value relative to an absolute time value.

In any one of the example implementations above, performing the mobility operation comprises receiving a handover command or a beam switch command from the NW.

In any one of the example implementations above, the prediction comprises an AI/ML prediction for a future time instance and the handover command is received at the future time instance.

In any one of the example implementations above, the prediction comprises an AI/ML prediction for a future time instance and the handover command or the beam switch command is received with the future time instance.

In any one of the example implementations above, the prediction comprises a predicted RLF of a current beam or all beams within current serving cell.

In any one of the example implementations above, the report comprises or indicates at least one of: a first indication that the predicted RLF would occur in a future time instance; a second indication of one or more reasons for the predicted RLF; a first timestamp specifying when the predicted RLF would occur; a second timestamp specifying when a set of continuous out-of sync indications would occur; a third timestamp specifying when a beam or cell switch is expected by the UE; a beam quality of the current beam at the future time instance; a cell quality of a current serving cell at the future time instance; top K best beams IDs or indexes and corresponding beam qualities at the future time instance; top M best neighboring cell IDs or indexes and corresponding cell qualities at the future time instance; beam IDs or indexes and qualities of top N best beams in each neighboring cell at the future time instance; or a fourth indication of whether the measurement results are from AI/ML predictions.

In any one of the example implementations above, the future time instance comprises a time instance when: a predefined or configured number of continuous out-of-sync condition occurs; an RLF is declared; a current beam quality is sufficiently worse than a best beam; or beams within current serving cell are lower than quality threshold.

In any one of the example implementations above, the mobility operation further comprises declaring an RLF earlier than a predicted future occurrence time of the predicted RLF.

In any one of the example implementations above, the mobility operation further comprises initiating RRC re-establishment earlier that the predicted future occurrence time of the predicted RLF.

In any one of the example implementations above, the UE performs AI/ML predictions on measurement objects or measurement identities corresponding to a first set of radio frequencies and perform actual measurements on measurement objects corresponding to a second set of radio frequencies.

In any one of the example implementations above, explicit flags are included in the measurement configuration to indicate whether the one or more measurement objects are allowed to be predicted via AI/ML or actually measured.

In any one of the example implementations above, the measurement configuration comprises a list of identifiers of measurement objects or measurement identities that are associated with the first set of radio frequencies.

In another example implementation, a method performed by a network (NW) in communication with a user equipment (UE) in a wireless communication network is disclosed. The method may include transmitting a measurement configuration to the UE; receiving a report based on measurement results and/or a prediction obtained by the UE, the measurement results and the prediction being associated with one or more measurement objects, the prediction being generated via a UE-side AI/ML functionality; and performing a mobility operation for the UE based on the measurement results and/or the prediction.

In the example implementation above, the measurement configuration comprises at least one of: a measurement object list to indicate the one or more measurement objects that the UE needs to measure or perform prediction on; indications of whether AI/ML predictions on the one or more measurement objects or measurement identity are allowed or not; or a reporting configuration list to indicate how to report the measurement results and/or the prediction to the NW.

In any one of the example implementations above, the report is transmitted by the UE in response to one or more triggering conditions.

In any one of the example implementations above, the report comprises or indicates at least one of: a measurement ID for identifying the at least one measurement; a list of cell IDs or indexes; a list of beam IDs or indexes; the measurement results associated with the one or more measurement objects; a timestamp to specify when the report is triggered; or an indication of whether the measurement results are from AI/ML prediction.

In any one of the example implementations above, the timestamp each comprises: an absolute time value; or a delta time value relative to an absolute time value.

In any one of the example implementations above, performing the mobility operation comprises transmitting a handover command or a beam switch command to the UE.

In any one of the example implementations above, the prediction comprises an AI/ML prediction for a future time instance and the handover command or the beam switch command is received at the future time instance.

In any one of the example implementations above, the prediction comprises a predicted RLF of a current beam or all beams within current serving cell.

In any one of the example implementations above, the report comprises or indicates at least one of: a first indication that the predicted RLF would occur in a future time instance; a second indication of one or more reasons for the predicted RLF; a first timestamp specifying when the predicted RLF would occur; a second timestamp specifying when a set of continuous out-of sync indications would occur; a third timestamp specifying when a beam or cell switch is expected by the UE; a beam quality of the current beam at the future time instance;

a cell quality of a current serving cell at the future time instance; top K best beams IDs or indexes and corresponding beam qualities at the future time instance; top M best neighboring cell IDs or indexes at the future time instance; beam IDs or indexes and qualities of top N best beams in each neighboring cell at the future time instance; or a fourth indication of whether the measurement results are from AI/ML predictions.

In any one of the example implementations above, the future time instance comprises a time instance when: a predefined or configured number of continuous out-of-sync condition occurs; an RLF is declared; a current beam quality is sufficiently worse than a best beam; or beams within current serving cell are lower than a quality threshold.

In any one of the example implementations above, the measurement configuration configures the UE to perform AI/ML predictions on measurement objects corresponding to a first set of radio frequencies and perform actual measurements on measurement objects corresponding to a second set of radio frequencies.

In any one of the example implementations above, explicit flags are included in the measurement configuration to indicate whether the one or more measurement objects or measurement identities are to be predicted via AI/ML or actually measured.

In any one of the example implementations above, the measurement configuration comprises a list of identifiers of measurement objects or measurement identities that are associated with the first set of radio frequencies.

The UE and the network of any one of the methods above is disclosed. UE and the network may include a processor and a memory, wherein the processor is configured to read computer code from the memory to cause the UE and the network to perform the method of any one of the methods above.

A non-transitory computer-readable program medium with computer code stored thereupon is further disclosed. The computer code, when executed by a processor of the UE and the network of any one of the methods above, is configured to cause the processor to implement any one of the methods above.

The above embodiments and other aspects and alternatives of their implementations are described in greater detail in the drawings, the descriptions, and the claims below.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an example wireless communication network including a wireless access network, a core network, and data networks.

FIG. 2 illustrates an example wireless access network including a plurality of mobile stations/terminals or User Equipments (UEs) and a wireless access network node in communication with one another via an over-the-air radio communication interface.

FIG. 3 shows an example radio access network (RAN) architecture.

FIG. 4 shows an example communication protocol stack in a wireless access network node or wireless terminal device including various network layers.

FIG. 5 illustrates an example procedure for measurement configuration, reporting to supporting mobility management assisted by network side AI/ML predictions.

FIG. 6 illustrates an example UE measurement timing as configured by the network.

FIG. 7 illustrates another example measurement timing as configured by the network.

FIG. 8 illustrates an example measurement configuration signaling structure.

FIG. 9 illustrates example measurement timings for several example measurement objects as configured by the network.

FIG. 10 illustrates an example measurement timing and reporting timing as configured by the network.

FIG. 11 illustrates an example measurement reporting signaling structure.

FIG. 12 illustrates another example measurement reporting signaling structure.

FIG. 13 illustrates an example measurement and reporting timing as configured by the network.

FIG. 14 illustrates an example cell measurements results signaling structure.

FIG. 15 illustrates an example mobility management based on network side AI/ML prediction.

FIG. 16 illustrates another example mobility management based on network side AI/ML prediction.

FIG. 17 illustrates an example bitmap for measurement identity activation/deactivation.

FIG. 18 illustrates an example procedure for measurement configuration, reporting to supporting mobility management assisted by UE side AI/ML predictions.

FIG. 19 illustrates an example measurement configuration signaling structure.

FIG. 20 illustrates an example measurement result reporting signaling structure.

FIG. 21 illustrates an example timing for Radio Link Failure (RLF) declaration as configured by the network.

FIG. 22 illustrates an example signaling structure for reporting RLF prediction information.

FIG. 23 illustrates an example signaling structure of a handover command in a form of an RRC reconfiguration message.

DETAILED DESCRIPTION

The present disclosure will now be described in detail hereinafter with reference to the accompanied drawings, which form a part of the present disclosure, and which show, by way of illustration, specific examples of embodiments. The present disclosure may, however, be embodied in a variety of different forms and, therefore, the covered or claimed subject matter is intended to be construed as not being limited to any of the embodiments to be set forth below.

Throughout the specification and claims, terms may have nuanced meanings suggested or implied in context beyond an explicitly stated meaning. Likewise, the phrase “in one embodiment” or “in some embodiments” as used herein does not necessarily refer to the same embodiment and the phrase “in another embodiment” or “in other embodiments” as used herein does not necessarily refer to a different embodiment. The phrase “in one implementation” or “in some implementations” as used herein does not necessarily refer to the same implementation and the phrase “in another implementation” or “in other implementations” as used herein does not necessarily refer to a different implementation. It is intended, for example, that claimed subject matter includes combinations of exemplary embodiments or implementations in whole or in part.

In general, terminology may be understood at least in part from usage in context. For example, terms, such as “and” , “or” , or “and/or, ” as used herein may include a variety of meanings that may depend at least in part upon the context in which such terms are used. Typically, “or” if used to associate a list, such as A, B or C, is intended to mean A, B, and C, here used in the inclusive sense, as well as A, B or C, here used in the exclusive sense. In addition, the term “one or more” or “at least one” as used herein, depending at least in part upon context, may be used to describe any feature, structure, or characteristic in a singular sense or may be used to describe combinations of features, structures or characteristics in a plural sense. Similarly, terms, such as “a” , “an” , or “the” , again, may be understood to convey a singular usage or to convey a plural usage, depending at least in part upon context. In addition, the term “based on” or “determined by” may be understood as not necessarily intended to convey an exclusive set of factors and may, instead, allow for existence of additional factors not necessarily expressly described, again, depending at least in part on context.

This disclosure is directed generally to wireless communication networks and particularly to configuration and provisioning of Artificial Intelligence (AI) and/or Machine Learning (ML) (AI. ML) functionalities and models in both terminal devices and network nodes in wireless communication networks. For example, a network node may configure a terminal device with respect to measurements intended for AI/ML functionalities in terms of measurement time, objects, reporting and the like. The terminal device may preform and report measurements based on such configuration. Alternatively, the terminal device may further preform predictions based on the measurement using terminal side AI/ML functionalities. The network node may receive the measurements and further perform prediction using network side AI/ML functionalities, or alternatively receive predictions and/or measurements from the terminal device. The predictions may then be used to manage mobility of the terminal device.

Wireless Network Overview

An example wireless communication network, shown as 100 in FIG. 1, may include wireless terminal devices or user equipment (UE) 110, 111, and 112, a carrier network 102, various service applications 140, and other data networks 150. The wireless terminal devices or UEs, may be alternatively referred to as wireless terminals. The carrier network 102, for example, may include access network nodes 120 and 121, and a core network 130. The carrier network 110 may be configured to transmit voice, data, and other information (collectively referred to as data traffic) among UEs 110, 111, and 112, between the UEs and the service applications 140, or between the UEs and the other data networks 150. The access network nodes 120 and 121 may be configured as various wireless access network nodes (WANNs, alternatively referred to as wireless base stations) to interact with the UEs on one side of a communication session and the core network 130 on the other. The term “access network” may be used more broadly to refer a combination of the wireless terminal devices 110, 111, and 112 and the access network nodes 120 and 121. A wireless access network may be alternatively referred to as Radio Access Network (RAN) . The core network 130 may include various network nodes configured to control communication sessions and perform network access management and traffic routing. The service applications 140 may be hosted by various application servers deployed outside of but connected to the core network 130. Likewise, the other data networks 150 may also be connected to the core network 130.

In the example wireless communication network of 100 of FIG. 1, the UEs may communicate with one another via the wireless access network. For example, UE 110 and 112 may be connected to and communicate via the same access network node 120. The UEs may communicate with one another via both the access networks and the core network. For example, UE 110 may be connected to the access network node 120 whereas UE 111 may be connected to the access network node 121, and as such, the UE 110 and UE 111 may communicate to one another via the access network nodes 120 and 121, and the core network 130. The UEs may further communicate with the service applications 140 and the data networks 150 via the core network 130. Further, the UEs may communicate to one another directly via side link communications, as shown by 113.

FIG. 2 further shows an example system diagram of the wireless access network 120 including a WANN 202 serving UEs 110 and 112 via the over-the-air interface 204. The wireless transmission resources for the over-the-air interface 204 include a combination of frequency, time, and/or spatial resource. Each of the UEs 110 and 112 may be a mobile or fixed terminal device installed with mobile access units such as SIM/USIM modules for accessing the wireless communication network 100. The UEs 110 and 112 may each be implemented as a terminal device including but not limited to a mobile phone, a smartphone, a tablet, a laptop computer, a vehicle on-board communication equipment, a roadside communication equipment, a sensor device, a smart appliance (such as a television, a refrigerator, and an oven) , or other devices that are capable of communicating wirelessly over a network. As shown in FIG. 2, each of the UEs such as UE 112 may include transceiver circuitry 206 coupled to one or more antennas 208 to effectuate wireless communication with the WANN 120 or with another UE such as UE 110. The transceiver circuitry 206 may also be coupled to a processor 210, which may also be coupled to a memory 212 or other storage devices. The memory 212 may be transitory or non-transitory and may store therein computer instructions or code which, when read and executed by the processor 210, cause the processor 210 to implement various ones of the methods described herein.

Similarly, the WANN 120 may include a wireless base station or other wireless network access point capable of communicating wirelessly via the over-the-air interface 204 with one or more UEs and communicating with the core network 130. For example, the WANN 120 may be implemented, without being limited, in the form of a 2G base station, a 3G nodeB, an LTE eNB, a 4G LTE base station, a 5G NR base station of a 5G gNB, a 5G central-unit base station, or a 5G distributed-unit base station. Each type of these WANNs may be configured to perform a corresponding set of wireless network functions. The WANN 202 may include transceiver circuitry 214 coupled to one or more antennas 216, which may include an antenna tower 218 in various forms, to effectuate wireless communications with the UEs 110 and 112. The transceiver circuitry 214 may be coupled to one or more processors 220, which may further be coupled to a memory 222 or other storage devices. The memory 222 may be transitory or non-transitory and may store therein instructions or code that, when read and executed by the one or more processors 220, cause the one or more processors 220 to implement various functions of the WANN 120 described herein.

Data packets in a wireless access network such as the example described in FIG. 2 may be transmitted as protocol data units (PDUs) . The data included therein may be packaged as PDUs at various network layers wrapped with nested and/or hierarchical protocol headers. The PDUs may be communicated between a transmitting device or transmitting end (these two terms are used interchangeably) and a receiving device or receiving end (these two terms are also used interchangeably) once a connection (e.g., a radio link control (RRC) connection) is established between the transmitting and receiving ends. Any of the transmitting device or receiving device may be either a wireless terminal device such as device 110 and 120 of FIG. 2 or a wireless access network node such as node 202 of FIG. 2. Each device may both be a transmitting device and receiving device for bi-directional communications.

The core network 130 of FIG. 1 may include various network nodes geographically distributed and interconnected to provide network coverage of a service region of the carrier network 102. These network nodes may be implemented as dedicated hardware network nodes. Alternatively, these network nodes may be virtualized and implemented as virtual machines or as software entities. These network nodes may each be configured with one or more types of network functions which collectively provide the provisioning and routing functionalities of the core network 130.

Returning to wireless radio access network (RAN) , FIG. 3 illustrates an example RAN 340 in communication with a core network 310 and wireless terminals UE1 to UE7. The RAN 340 may include one or more various types of wireless base station or WANNs 320 and 321 which may include but are not limited to gNB, eNodeB, NodeB, or other type of base stations. The RAN 340 may be backhauled to the core network 310. The WANNs 320, for example, may further include multiple separate access network nodes in the form of a Central Unit (CU) 322 and one or more Distributed Unit (DU) 324 and 326. The CU 322 is connected with DU1 324 and DU2 326 via various interfaces, for example, an F1 interface. The F1 interface, for example, may further include an F1-C interface and an F1-U interface, which may be used to carry control plane information and user plane data, respectively. In some embodiments, the CU may be a gNB Central Unit (gNB-CU) , and the DU may be a gNB Distributed Unit (gNB-DU) . While the various implementations described below are provided in the context of a 5G cellular wireless network, the underlying principles described herein are applicable to other types of radio access networks including but not limited to other generations of cellular network, as well as Wi-Fi, Bluetooth, ZigBee, and WiMax networks.

The UEs may be connected to the network via the WANNs 320 over an air interface. The UEs may be served by at least one cell. Each cell is associated with a coverage area. These cells may be alternatively referred to as serving cells. The coverage areas between cells may partially overlap. Each UE may be actively communicating with at least one cell while may be potentially connected or connectable to more than one cell. In the example of FIG. 1, UE1, UE2, and UE3 may be served by cell1 330 of the DU1, whereas UE4 and UE5 may be served by cell2 332 of the DU1, and UE6 and UE7 may be served by cell3 associated with DU2. In some implementations, a UE may be served simultaneously by two or more cells. Each of the UE may be mobile and the signal strength and quality from the various cells at the UE may depend on the UE location and mobility.

In some example implementations, the cells shown in FIG. 3 may be alternatively referred to as serving cells. The serving cells may be grouped into serving cell groups (CGs) . A serving cell group may be either a Master CG (MCG) or Secondary CG (SCG) . Within each type of cell groups, there may be one primary cell and one or more secondary cells. A primary cell in a MSG, for example, may be referred to as a PCell, whereas a primary cell in a SCG may be referred to as PScell. Secondary cells in either an MCG or an SCG may be all referred to as SCell. The primary cells including PCell and PScell may be collectively referred to as spCell (special Cell) . All these cells may be referred to as serving cells or cells. The term “cell” and “serving cell” may be used interchangeably in a general manner unless specifically differentiated. The term “serving cell” may refer to a cell that is serving, will serve, or may serve the UE. In other words, a “serving cell” may not be currently serving the UE. While the various embodiment described below may at times be referred to one of the types of serving cells above, the underlying principles apply to all types of serving cells in both types of serving cell groups.

FIG. 4 further illustrates a simplified view of the various network layers involved in transmitting user-plane PDUs from a transmitting device 402 to a receiving device 404 in the example wireless access network of FIGs. 1-3. FIG. 4 is not intended to be inclusive of all essential device components or network layers for handling the transmission of the PDUs. FIG. 4 illustrates that the data packaged by upper network layers 420 at the transmitting device 402 may be transmitted to corresponding upper layer 430 (such as radio resource control or RRC layer) at the receiving device 304 via Packet Data Convergence Protocol layer (PDCP layer, not shown in FIG. 4) and radio link control (RLC) layer 422 and of the transmitting device, the physical (PHY) layers of the transmitting and receiving devices and the radio interface, as shown as 406, and the media access control (MAC) layer 434 and RLC layer 432 of the receiving device. Various network entities in each of these layers may be configured to handle the transmission and retransmission of the PDUs.

In FIG. 4, the upper layers 420 may be referred as layer-3 or L3, whereas the intermediate layers such as the RLC layer and/or the MAC layer and/or the PDCP layer (not shown in FIG. 4) may be collectively referred to as layer-2, or L2, and the term layer-1 is used to refer to layers such as the physical layer and the radio interface-associated layers. In some instances, the term “low layer” may be used to refer to a collection of L1 and L2, whereas the term “high layer” may be used to refer to layer-3. In some situations, the term “lower layer” may be used to refer to a layer among L1, L2, and L3 that are lower than a current reference layer. Control signaling may be initiated and triggered at each of L1 through L3 and within the various network layers therein. These signaling messages may be encapsulated and cascaded into lower layer packages and transmitted via allocated control or data over-the-air radio resources and interfaces. The term “layer” generally includes various corresponding entities thereof. For example, a MAC layer encompasses corresponding MAC entities that may be created. The layer-1, for example, encompasses PHY entities. The layer-2, for another example encompasses MAC layers/entities, RLC layers/entities, service data adaptation protocol (SDAP) layers and/or PDCP layers/entities.

This disclosure describes techniques that can be implemented for exchanging information between network and UE and/or between network nodes (e.g. from gNB-DU to gNB-CU, from gNB-CU to gNB-DU, from source cell to target cell, from SN to MN, from MN to SN) .

In some embodiments, the network can be an eNB, a ng-eNB, or a gNB; the UE can be configured with single carrier, carrier aggregation (CA) , dual connectivity (DC) . For DC, the MN can be an eNB, a ng-eNB, or a gNB; and the SN can be an eNB, a ng-eNB, or a gNB, but not only limited to 4G, 5G network equipment. AI/ML Assisted Wireless Network Provisioning and Configuration.

AI and ML (alternatively referred to AL generally) may facilitate more efficient configuration and provisioning in wireless networks. At the core of a general AI framework are various AI models. An AI model generally contains a large number of model parameters that are determined through a training process where correlations in a set of training data are learned and embedded in the trained model parameters. The trained model parameters may thus be used to generate inference or predictions from a set of input datasets. AI models are particularly suitable for situations where there is few trackable deterministic or analytical derivation paths between input data and output but correlations in the data may be identified from historical data and may be embedded into the AI models via training processes.

AI models may be constructed and trained for various inference or predictive functionalities. Inferences or predictions generated by these AI models may facilitate various aspect of the provisioning of the over-the-air interface of a wireless network, including but not limited to resource management, allocation, and selection (including spatial, radio frequency, and time resources) , mobility management, and radio link failure management.

AI assisted mobility management and radio link failure management may be particularly beneficial. Specifically, traditional beam, cell, and radio frequency provisioning involved in mobility and radio link failure management is inflexible and consumes much overhead. For example, traditional beam management typically relies on exhaustive beam sweeping and measurements. A UE may be configured to monitor and measure each reference signal and then report the measurement results to NW for the NW to decide the best beam for the UE to switch to during mobility. This process is resource and power intensive and time consuming. Trained AI models that embed learned correlation between various network condition parameters, can at least help reduce the number of measurements (or fewer reference signals) via inferences. For example, some implementations, AI models may help identify inferences of best candidate beams using other network conditions and then only sweep and measure the candidate beams to select the beam for use in current communication.

The traditional non-AI approaches to mobility and/or radio failure management are further only reactive in that they do not take historical time correlations into consideration and thus can only react to current measurements in relation to predetermined or configured threshold values. Such traditional approaches thus cannot predict future network conditions and unable to provide proactive mobility and radio link failure management. As such, in situations where cell quality may change, e.g., degrade, rapidly (e.g., when UE mobility is high) , the network may not be able to know the degraded cell quality in time based on the traditional reactive approaches, leading to frequent handover failure or radio link failure during mobility. Therefore, it may be desirable in at least such situations to implement a proactive rather than reactive scheme. A proactive approach may also be based on AI techniques described above. In an AI-based proactive scheme for mobility and/or radio link failure management, for example, the network can know the beam/cell quality change in advance (even before the change actually happens) via Artificial Intelligence/Machine Learning (AI/ML) algorithm. For example, the UE /NW may be able to predict whether the beams/cells will become worse in a future time instance via temporal-domain prediction.

In some example implementations of AI/ML assisted network provisioning including but not limited to mobility and radio link failure management, AI models may reside on the UE side. In some other implementations, AI model may instead reside on the network (NW) side. AI models may be provided as a service. AI models may be retrained and updated as needed. The UE or the NW may determine what models to retrieve or retain and how they are updated and configured for assisting in the various aspects of wireless communications.

In some example implementations including but not limited to AI-based proactive mobility and/or radio link failure management, inputs to the AI models on either the UE side or the NW side may be obtained from a set of measurements of one or more measurement objects. A measurement object, for example, may be a spatial beam, a frequency channel, a cell, or the like. In some measurement mechanism, the UE may be configured by the NW to perform measurements on each measurement object associated with the measurement identity. For example, measurements may be triggered by one or more predefined or NW-configured conditions being met. For a particular cell, for example, the UE may measure one or more beams of the cell to derive beam quality and cell quality and then reports the results to the NW when some triggering criteria are met. The triggering criteria can be set in forms of either periodical measurement/reporting or a single event triggering or others.

In addition, the UE may be configured to perform AI-based inter-frequency predictions that may also benefit mobile management and radio link failure management. Without AI/ML assisted prediction, the UE would need to perform measurements on each frequency. However, with the assistance of one or more AI/ML algorithms, inter-frequency prediction may be achieved. As a result, there may be no need to actually measure each frequency and as such, the measurement burden can be reduced via predicting measurement results on some un-measured frequencies based on measured results on some other frequencies. For example, cell quality for inter-frequency neighbor cells may be predicted via AI/ML models based on measured cell quality of serving cell and/or intra-frequency neighbor cells. In this way, shorter measurement time gap during the communication sessions may be required or no time gap may be needed at all, and UE throughput may be improved. In addition, even for intra-frequency measurements, it is possible to predict the cell quality of intra-frequency neighbor cell (s) based on the cell quality of the serving cell, or based on the cell quality of the serving cell and other intra-frequency neighbor cells. Such predictions may be referred to as spatial-domain prediction or frequency-domain prediction.

The further disclosure below is directed generally to wireless communication networks and particularly to configuration and provisioning of Artificial Intelligence (AI) and/or Machine Learning (ML) (AI/ML) functionalities and models in both terminal devices and network nodes in wireless communication networks for mobility and/or radio failure management. For example, a network node may configure a terminal device with respect to measurements intended for AI/ML functionalities in terms of measurement time, objects, reporting and the like. The terminal device may preform and report measurements based on such configuration. Alternatively, the terminal device may further preform predictions based on the measurement using terminal side AI/ML functionalities. The network node may receive the measurements and further perform prediction using network side AI/ML functionalities, or alternatively receive predictions and/or measurements from the terminal device. The predictions may then be used to manage mobility of the terminal device for a future time. Radio Resource Management (RRM) and Event Prediction Based on Network Side AI/ML –Overall Implementations.

An example overall RRM measurement and event prediction procedure performed by a UE 502 and a network 504 with network side AI/ML models is shown in FIG. 5, including but not limited to the following example steps:

Step 1: The network 504 may send measurement configurations to the UE 502;

Step 2: The UE 502 may perform the measurements and report the measurement results to the network according to the measurement configuration;

Step 3: The network 504 may then perform AI/ML based predictions (e.g., cell and/or beam prediction) .

Step 4: The Network 504 may perform mobility management based on the predictions and/or the measurement results.

Radio Resource Management (RRM) and Event Prediction Based on Network Side AI/ML –Measurement Configuration

Referring to Step 1 above and in FIG. 5, the purpose of the measurement configuration may be to inform the UE by the network of measurement objects that the UE needs to perform measurement on and/or reporting configuration (e.g., reporting criterion) for the measurements. The measurement configuration may include other additional information. Such measurement configuration may be transmitted by the network to the UE. The term measurement configuration as used in this disclosure broadly include configurations related to measurements by the UE and reporting of measurement results by the UE. In other words, measurement result reporting configuration may be considered as part of the measurement configuration.

In some example implementations, the measurement configuration above may include or indicate one or more of the following:

● Expected measurement timing configuration to indicate when the UE is expected by the network to perform measurement on the measurement objects. For example, the expected measurement time configuration may indicate one or more of the followings:

○ One or more periodicities for the measurements of the measurement objects that are expected to be executed by the UE. In some example implementations, the measurement configuration may also include time offset (s) that the UE should perform measurement within one measurement period for the measurement objects. In some example implementations, the periodicity may be a Layer-1 (L1) measurement periodicity or Layer-3 (L3) measurement periodicity. In some example implementations, a measurement periodicity may be applied to Synchronization Signal Block (SSB) measurements or Channel State Information (CSI) Reference Signal (CSI-RS) measurements or measurements of other reference signals. In some other example implementations, a periodicity and/or offset above may be configured explicitly or implicitly. An implicit configuration may refer to configuration via time configuration of reference signaling or SSB Measurement Timing Configuration (SMTC) ;

○ One or more measurement ON durations for the measurement objects (MOs) to indicate how long in time the UE is expected to perform measurements on certain MO (s) , and/or one or more measurement OFF duration to indicate how long in time the UE is expected to not perform measurements on certain MO (s) . In some example implementations, the UE may be expected to perform measurements for a certain period of time (a measurement ON duration) , then is not expected to perform measurements for a next period of time (ameasurement OFF duration) , and is then expected to perform measurements for another certain period of time again (another measurement ON duration) . In some example implementations, this measurement ON and OFF cycle may be repeated. In some example implementations, within a measurement ON duration, the UE may be expected to perform measurements of a measurement object periodically. In some example implementations, the UE may be expected to perform one or more measurement (s) on each measurement object/identity during the measurement ON duration. In some example implementations, the measurement ON duration above can be applied to SSB measurements or CSI-RS measurements or measurements based on other reference signals. In some example implementations, a configuration granularity of the measurement ON or OFF duration may be per MO level or for all MOs with/without specific indication (e.g., an indication for a measurement object to indicate that it is deactivated for measurement purposes) . A measurement timing example is shown in FIG. 6. FIG. 6 specifically shows measurements 602 during a measurement ON duration 604 followed by a measurement OFF duration 606 for a particular measurement object.

○ One or more numbers of continuous measurements for the measurement objects (e.g., for each MO/cell/beam) . When measurement amount for an MO reaches a corresponding configured number, the UE is expected to not perform additional measurement on this MO in a configured measurement duration (e.g., a measurement OFF duration) . In some example implementations, for continuous measurements, a certain measurement interval or periodical measurements may be allowed. In some example implementations, the number of measurements may be configured at per MO level or for all MOs with/without specific indication (e.g., an indication for a measurement object to indicate that it is deactivated for measurement purposes) . A measurement timing example is shown in FIG. 7. FIG. 7 specifically shows continuous measurements 702 of a particular measurement object up to a configured number of times. Once the number of times (e.g., 3) is reached, as shown by 702, no additional measurements are made in the configured OFF duration 706.

● Beam/cell set measurement configuration to indicate which beam (s) /cell (s) is to be measured and reported. For example, a beam/cell measurement configuration may indicate one or more of the followings:

○ Example Beam/Cell Configuration 1: a number of Top N best beams that the UE is required to measure and report. The Top N best beams may be determined based on a specific measurement quantity (e.g., Reference Signal Received Power (RSRP) , Reference Signal Received Quality (RSRQ) , Signal to Interference &Noise Ratio (SINR) ) that may be configured by the network. In some example implementations, the beam (s) can be SSB (s) and/or CSI-RS (s) , and/or Tracking Reference Signal (s) (TRS’s) , and/or other reference signals. In some example implementations, the number N can be configured differently for different cells (including, e.g., serving cell and neighbor cells) ;

○ Example Beam/Cell Configuration 2: a number of Top N best cells that the UE is required to measure and report. The Top N best cells may be determined based on a specific measurement quantity (e.g., RSRP and/or RSRQ and/or SINR) that may be configured by the network. In some example implementations, a cell can be serving cell and/or intra-frequency neighbor cell and/or inter-frequency neighbor cell and/or inter-RAT neighbor cell.

○ Example Beam/Cell Configuration 3: beam list (s) to indicate which beams are required to be measured and reported by the UE. In some example implementations, a beam can be an SSB and/or a CSI-RS, and/or a TRS, and/or some other reference signal. In some example implementations, the beams may be indicated via one of the following alternative ways: (1) explicit beam list (s) (e.g., by configuring list (s) of beam indexes) ; (2) one or more bitmaps for indicating beams to be measured among a larger set of beams (e.g., a set of 64 beams) ; or (3) the number of beams the UE is required to measure and report by sampling uniformly across all beams within one cell.

○ Configuration 4: cell list (s) to indicate which cells’ cell quality and/or beam quality are required to be measured and reported by the UE. In some example implementations, a cell can be serving cell and /or intra-frequency neighbor cell and/or inter-frequency neighbor cell and/or inter-RAT neighbor cell. In some example implementations, the list (s) can be configured explicitly (e.g., by configuring a list of Physical Cell IDs (PCIs) ) . In some example implementations, each cell may be expressed or represented as a PCI, or an index entry in the pre-configured cell list. In some example implementations, the pre-configured cell list may be carried in a broadcast information (e.g., intraFreqNeighCellList in SIB3) or RRC dedicated signaling (e.g. the pre-configured list in the measConfig) .

● An indication to indicate whether a measurement object/measurement identity is deactivated. Deactivation state for the measurement object/measurement identity refers to a state in which the UE is not required to perform measurement on the frequency associated with this measurement object/measurement identity.

● An indication to indicate whether a measurement object/measurement identity is related to AI/ML functionality. In some example implementations, the indication may be provided at a per MO or per measurement identity level. In some other example implementations, such an indication may be provided for all intra-frequency measurement and/or inter-frequency measurement and/or inter-RAT measurement.

● An indication to indicate whether to include timestamps with the measurement results in the measurement report. A timestamp may be used to indicate when a measurement result is obtained or when a corresponding measurement is performed. In some example implementations, such an indication may be provided at a per MO or per measurement identity level or per reporting configuration level. In some other example implementations, such an indication may be provided for all intra-frequency measurement and/or inter-frequency measurement and/or inter-RAT measurement.

● An indication to indicate the types of the measurement results. A type of measurement results can be one of the followings:

○ L1 measurement results without L1 filtering;

○ L1 measurement results with L1 filtering;

○ L3 measurement results without L3 filtering; or

○ L3 measurement results with L3 filtering;In some example implementations, a granularity of such an indication for types of measurement results may be provided at a per MO level or per measurement identity level or per reporting configuration level or a per cell group level or a per UE level.

● An indication to indicate the reporting quantity. In some example implementations, the reporting quality can be represented in RSRP and/or RSRQ and/or SINR;

● An indication to indicate a sorting quantity if the UE is required to provide historical measurement results at multiple past time instances. In some example implementations, the historical measurement results may be sorted by time/beam/cell.

● A reporting configuration to indicate to the UE when and/or where to report the measurement results. For example, such a reporting configuration may indicate one or more of the followings:

○ A periodicity and/or offset of measurement reporting that the UE is expected to perform. In some example implementations, the periodicity and/or offset can be configured explicitly or implicitly. An example of implicitly configuration may be provided via a time configuration of reference signaling or an SMTC configuration.

○ A value to indicate a number of historical measurement results for each measurement object/measurement identity/cell/beam in to accumulate for reporting. In some example implementations, when the number of obtained historical measurement results for each MO/cell/beam is equal to or reaches the configured value, the UE may then report the measurement results to the network.

○ A frequency domain configuration to indicate where (in carrier frequency) to send measurement results. In some example implementations, the carrier frequency location for sending the measurement results may be indicated via Physical Uplink Control Channel (PUCCH) resource (s) or may be indicated with a start Physical Resource Block (PRB) and a number of continuous PRBs.

● An indication to indicate on which Signaling Radio Bearers (SRBs) and/or Data Radio Bearers (DRBs) the measurement results would be transmitted. In some example implementations, a new SRB/DRB may be introduced to transmit the measurement results. In some example implementations, an SRB or an DRB can be indicated via an SRB identity or an DRB identity.

In some example implementations, the network may send a measurement configuration to the UE via an RRCReconfiguration message or some other RRC message.

An example measurement configuration based on the disclosure above is illustrated in the signaling structure 800 of FIG. 8. The example signaling structure 800 may be referred to as MeasConfig, which may include a list of measurement objects, referred to as measObjectToAddModList. The list may include a plurality of entries associated with a plurality of MOs, each referred to as measObjectToAddMod and each further includes an MO identifier, referred to as measObjectId, and configuration parameter set measObjectNR. The configuration parameter set measObjectNR may include an indication to indicate the MO is deactivated from being measured and reported, the indicator being referred to as MeasDeactivation. The configuration parameter set measObjectNR may further include a list of cells to be measured, referred to as Cell-ToMeasureList and corresponding measurement pattern, referred to as MeasrementPattern, for specifying the measurement ON duration and measurement OFF duration described above. The cell list, for example, may include a list of PCIs.

In the particular example of FIG. 8, for measObject Id =1, the UE is configured to perform measurement as legacy, i.e., the UE is expected to perform measurement periodically, as indicated by MeasDeactivation being configured as “false” (or alliteratively by an absence of the MeasDeactivation signaling) and that no MeasurementPattern parameters are configured.

For measObject Id =2 in FIG. 8, the UE is expected to perform measurements periodically during the measurement ON duration, followed by not perform measurements during the measurement OFF duration, further followed by performing measurements periodically during a second measurement ON duration, and this cycle is repeated, as indicated by the MeasDeactivation being configured as “false” (or alliteratively by an absence of the MeasDeactivation signaling) and values for MeasurementOnDuration and MeasurementOffDuration being configured.

Further for measObject Id =2, the UE is expected to perform measurement on cells with PCI=3, 5, and 9, and report the measurement results to the network, as indicated by the PCIs in the Cell-ToMeasureList.

For measObject Id=3 in FIG. 8, the UE is not expected to perform measurement, as configured by the “true” value for MeasDeactivation.

The measurement behavior of the UE according the example configuration 800 of FIG. 8 above is further illustrated in FIG. 9 with respect to MO1 (measObjectId = 1) , MO2 (measObjectId = 2) , and MO3 (measObjectId = 3) . The dark bars indicate measurement occasions along the time axis 902. The apparent measurement periodicity or interval between measurements in FIG. 9 are illustrated for example purposes only.

Radio Resource Management (RRM) and Event Prediction Based on Network Side AI/ML –Measurement Result Reporting.

Referring to Step 2 of FIG. 5, and based on the measurement configuration from the network as described the above, the UE may perform one or more measurements on the configured beams/cell set, reference signal, channels and the like, and report measurement results to the network if corresponding one or more triggering criteria are met.

In some example implementations, the reported measurement results may indicate to the network one or more of the following:

● a list of cells, e.g., a list of PCIs or cell indexes;

● a list of beam IDs or indexes;

● RSRP/RSRQ/SINR results of the cells and/or beams.

In some example implementations, the reported measurement results above include one of the following:

○ All available measurement results (i.e., including the measurement results for normal cells/beams and the measurement results for cells/beams related to AI/ML functionalities) ;

○ Only measurement results for cell/beams related to AI/ML functionalities;

○ Measurement results for cell/beams related to AI/ML functionality, and the network may further configure whether to include measurement results for normal cells/beams that do not involve AI/ML functionalities. In the example implementations above and herein, the term “normal cells/beams” is used to represent the cells/beams that the UE performs measurement on but that are not related to or do not involve AI/ML operations or functionalities.

● An indication to indicate the types of the measurement results, and a measurement result type can be one of the following:

○ L1 measurement results without L1 filtering;

○ L1 measurement results with L1 filtering;

○ L3 measurement results without L3 filtering;

○ L3 measurement results with L3 filtering;

● Timestamps of measurement result instances, to indicate when the UE obtains the measurement results. In some example implementations, a timestamp can be an absolute time or can be a delta value to a reference time (e.g., the time when the UE obtains the first measurement results) . In some other example implementations, a timestamp may be implemented as a time interval between every two adjacent reported measurement results for a given cell or beam. In other words, the timestamp for a measurement is in reference its preceding measurement time.

In case that the UE is configured to report a list of historical measurement results, for the signaling structure of reported RSRP and/or RSRQ and/or SINR results of a given cell or beam, the reported measurement results may include one of the following:

● A field that indicates an absolute value of these historical measurements, e.g., -100dBm for RSRP, -7dB for SINR;

● A field that indicates an absolute reference value and other fields that indicate delta values relative to the reference value (e.g., the best cell/beam’s value may be the absolute reference value) ;

In some example implementations, the UE may send measurement results to the network in Step 2 of FIG. 5 via L1 signaling or MAC CE or RRC signaling (e.g., in forms of MeasurementReport or UEAssistanceInformation or a new RRC message) .

In some example implementations, a separate/configured SRB/DRB may be used to transmit the measurement results to the network. A configured SRB/DRB may refer to that the network configures on which SRB/DRB UE transmit measurement results. An SRB/DRB so configured may be used to only transmit the measurement results or to transmit measurement results and for other transmission purposes.

An example report for measurement results is illustrated in FIG. 10. The measurement configuration for the example of FIG. 10 includes a measurement ON duration of 480 ms, a measurement OFF duration of 800 ms. Further in the example of FIG. 10, during the on duration, the UE performs measurement on SSBs with index = 0, 5, 9, 18, 27, 29, 35 and 42 beginning at each of t = 40 ms, 190 ms and 370 ms relative to the start of the measurement ON duration, as shown in the measurement report structure of FIG. 11 For example, t=40 ms may correspond to location of an SSB with index 0. Then the UE reports the measurement results to the network (e.g., by reporting measured RSRP values to the NW) .

An example measurement report signaling structure corresponding the measurement and reporting illustration of FIG. 10 is shown in FIG. 11 for reporting absolute time and absolute beam quality measured as RSRP.

Another example measurement report signaling structure corresponding the measurement and reporting illustration of FIG. 10 is shown in FIG. 12 for reporting relative time (relative to the first measurement at 40 ms relative to the beginning of the ON duration) , absolute RSRP value for the first measurement and delta beam quality values for the second and third measurement result of RSRP.

FIG. 13 illustrates measurements performed by the UE on cells with PCI=5, 19 and 25 at each of t=t1, t2, t3 and t4, (four measurement at these times for each of the three cells) and reports the measurement results to the network, corresponding to an example reporting signaling structure shown in FIG. 14.

In another example, the UE is configured to perform normal measurement on the cell 1, cell 3, and perform measurement on the cell 2 for AI/ML related functionality (e.g., the network predicts the measurement results for cell 4 based on the measurement results for cell 2) . When reporting measurement results to the network, the UE may:

Option 1: Only report the measurement results for cell 2 to the network;

Option 2: Report measurement results for cell 1, 2 and 3 to the network;

Option 3: If the network configures the UE in a manner such that the normal measurement results are not included in the AI/ML related measurement results reporting. Then the UE would only report the measurement results for cell 2 to the network;

Option 4: If the network configures the UE in a manner such that the normal measurement results are included in the AI/ML related measurement results reporting, then the UE reports the measurement results for cell 1, 2, and 3 to the network.

Radio Resource Management (RRM) and Event Prediction Based on Network Side AI/ML –Mobility Management Based on AI/ML Prediction Results

Turning to Step 4 of FIG. 5 above, and based on the measurement results/prediction results, the network may perform mobility management, e.g., determining whether and/or when to perform handover and which cell the UE would move to, based on the measurement results reported from the UE and/or AI/ML predictions obtained from the measurement results.

Such subsequent mobility management actions may include one of:

● The network may send a handover command to the UE directly. For example, the handover command may be an RRCReconfiguration message or MobilityFromNRCommand message or a cell switch command MAC CE.

● The network may send the handover command to the UE at a prediction time. For example, in case of a CU-DU split in the base station, if an AI/ML inference is performed on the network side by the CU, CU may transfer to the DU in a source cell of the handover one or more of a handover command, and a timestamp to indicate when the DU is expected to transmit the handover command to the UE. For another example, again in case of a CU-DU split in the base station, CU may transfer to DU in a target cell of the handover of a timestamp to indicate when the source DU transmits the handover command to the UE. The handover command in this situation, again, may be implemented as an RRCReconfiguration message or a MobilityFromNRCommand or a cell switch command MAC CE.

● The network may send the handover command and a prediction time to the UE, and the UE may initiate the handover procedure at the prediction time. For example, in case of a CU-DU split in the base station, CU may transfer to DU in the target cell of the handover a timestamp to indicate when the UE is expected to execute the handover procedure. In such implementations, the timestamp may be an absolute time or a delta to a reference time (e.g., when the target DU receives this timestamp) . Alternatively, the prediction time may be an absolute time or a delta to a reference time (e.g., when the UE receives the handover command) .

In some further example implementations of the handover, the source NG-RAN node may indicate to the target NG-RAN node one or more of the followings:

● RSRP/RSRQ/SINR results of cell and/or beam at the prediction time;

● A timestamp to indicate when source node (e.g., source DU) is expected to transmit the handover command to the UE;

● A timestamp to indicate when UE is expected to execute handover procedure.

FIG. 15 illustrates an example mobility management based on measurements reported from the UE and/or AI/ML prediction generated based on the measurements reported from the UE. As shown in FIG. 15, based on the reported measurement results, the network may predict via the network-side AI/ML functionalities that the UE shall move to cell 2 from cell 1 at t=t2. The network may accordingly send a handover command to the UE at t=t2, as indicated by the dark arrow of FIG. 15.

Another example is illustrated in FIG. 16, where the network may send the handover command and a timestamp for the handover to the UE at t =t0, as shown by 1602, and the UE is expected to execute the handover procedure at t=t2, as predicted by the network. The UE subsequently receives handover command at t=t1, as shown by 1604. The timestamp sent by the network to the UE can be an absolute time (t=t2) for the UE to execute handover, or a delta value to the time the UE receives the handover command (t2-t1) . The UE executes the handover at the predicted time of t=t2, as indicated by 1606.

Radio Resource Management (RRM) and Event Prediction Based on Network Side AI/ML –Measurement Control under AI/ML Operation

In some example implementations, under AI/ML operations, the network may be able to predict measurement results for one or more radio frequencies, but the network may also want the UE to perform actual measurement on some of the frequencies. As such, the network may configure the UE to activate or deactivate one or more measurement identities/measurement objects. Such a procedure may be effectuated by signaling when needed and need not be at a particular timing relation with the various steps described above and in FIG.

5. The measurement configuration as described above may indicate one or more of the following:

● An explicit flag included in measurement object, to indicate whether the UE can deactivate the measurement on the frequency configured by this measurement object. In some example implementations, the UE may execute measurement deactivation as long as the UE receives the RRC configuration. In some other implementations, the UE may execute measurement activation or deactivation when receives a DCI command or a MAC CE from the network.

● An explicit flag included in report configuration, to indicate whether the UE can deactivate the measurement on the frequency that associated with this report configuration. In some example implementations, the UE executes measurement deactivation as long as the UE receives the RRC configuration. In some other example implementations, the UE executes measurement deactivation when receives a DCI command or a MAC CE from the network.

● A list of measurement identities or measurement objects, to indicate whether the UE can deactivate or activate the measurements on the corresponding frequency that associated with the measurement identity or measurement object. The list can be indicated by a bitmap or an explicit list of measurement IDs or measurement object IDs. In some example implementations, the id used for measurement activation or deactivation can be configured explicitly for each measurement identity or measurement object. In some example implementations, one dynamic measurement activation/deactivation flag can be configured for each measurement identity/measurement object, and the first bit of the bitmap refer to the first measurement object with the dynamic flag, the second bit of the bitmap refer to the second measurement object with the dynamic flag, and so on. In some example implementations, this list can be sent to UE via DCI, or MAC CE or RRC; If the list is configured via RRC signaling, the UE can execute measurement deactivation/activation as long as the UE receives the RRC configuration; or the UE can execute measurement deactivation/activation when receives a DCI command or a MAC CE from the network.

● A flag indicates whether the UE can deactivate all inter-frequency measurements; This flag can be sent to UE via DCI, or MAC CE or RRC; If the list is configured via RRC signaling, the UE can execute measurement deactivation/activation as long as the UE receives the RRC configuration, or the UE can execute measurement deactivation/activation when receives a DCI command or a MAC CE from the network.

● A flag indicates whether the UE can deactivate all inter-RAT measurements; This flag can be sent to UE via DCI, or MAC CE or RRC; If the list is configured via RRC signaling, the UE can execute measurement deactivation/activation as long as the UE receives the RRC configuration, or the UE can execute measurement deactivation/activation when receives a DCI command or a MAC CE from the network.

In one example, for a list to indicate whether the corresponding measurement identity is deactivated or not, a possible signaling structure may be:

MeasIdDeactivationList BIT STRING (SIZE (64) ) OPTIONAL Need M

The first (left-most/most significant) bit in the bitmap above may correspond to the measurement identity with MeadId=1, the second bit in the bitmap corresponds to the measurement identity with MeasId =2, and so on. The UE may perform measurements on the measurement identity or object for which the corresponding bit in the bitmap is set to 0.

For example, if the network sends the example MeasIdDeactivationList of FIG. 17 to the UE, the UE is correspondingly expected to perform measurement on the measurement identity with id =1, 2, 5, 7... 64.

Radio Resource Management (RRM) and Event Prediction Based on UE Side AI/ML –Overall Implementations An example overall RRM measurement and event prediction procedure performed by a UE 1802 and a network 1804 with UE side AI/ML models is shown in FIG. 18, including but not limited to the following example steps:

Step 1: The network 1804 may send measurement configurations to the UE 1802;

Step 2: The UE 1802 may perform the measurements according to the measurement configuration and/or perform AI/ML based RRM measurement prediction;

Step 3: The UE 1802 may report the measurement results and/or prediction results to the network;

Step 4: The Network 1804 and UE 182 may perform mobility management based on the predictions and/or the measurement results.

Resource Management (RRM) and Event Prediction Based on UE Side AI/ML –Measurement Configuration, Measurements, and Prediction

Referring to Step 1 above and in FIG. 18, the purpose of the measurement configuration may be to inform the UE by the network of measurement objects that the UE needs to perform measurement on and/or reporting configuration (e.g., reporting criterion) for the measurements. The measurement configuration may include other additional information. Such measurement configuration may be transmitted by the network to the UE. The term measurement configuration as used in this disclosure broadly include configurations related to measurements by the UE and reporting of measurement results by the UE. In other words, measurement result reporting configuration may be considered as part of the measurement configuration.

In some example implementations, the measurement configuration above may include or indicate one or more of the following:

● Measurement object list to indicate which object/frequency point/cell the UE needs to perform measurement/prediction on.

● An indication to indicate whether the prediction on the corresponding measurement object/measurement identity is allowed or not. In some example implementations, the indication above may be provided at a per MO or per measurement identity level. In some other example implementations, such an indication may be provided for all inter-frequency measurements. In some example implementations, the indication is carried via RRC signaling or MAC CE or DCI.

● Reporting configuration list to indicate how to report the measurement results to the network (e.g., reporting quantity) .

● An indication to indicate whether the RLF prediction is allowed to not.

In some other example implementations, the measurement configuration above may be sent to the UE via RRC signaling (e.g. RRCReconfiguration) or MAC CE or DCI.

An example signaling structure for the measurement configuration above is illustrated in FIG. 19, containing a list of measurement objects, each of which is associated with an identifier and a flag (indicated in FIG. 19 as “allowedPrediction” ) . When this flag is set to false or absent, the UE is not allowed to perform prediction on the corresponding MO. If it is set to true, then the UE is allowed to perform prediction on this MO.

Further refer to Step 2 of the FIG. 18, the UE, upon receiving the measurement configuration above, may determine to measure one or more measurement objects according to the measurement configuration. The UE may further perform prediction using corresponding AI/ML model that process the measurements of the measurement object (s) to generate inference (s) or predictions.

Resource Management (RRM) and Event Prediction Based on UE Side AI/ML –Measurement Reporting and Mobility Management

Turning to Step 3 and Step 4 of FIG. 18, the UE may then perform reporting and mobility management in collaboration with the NW based on the predictions generated in Step 2 above.

In some example implementations of Step 3 and Step 4 of FIG. 18, UE reporting of STEP 3 may be triggered by a predetermined or configured set of conditions being met. The reporting, for example, may include measurement results obtained by the UE in Step 2 above according to the measurement configuration received in Step 1. For example, the reported results may indicate one or more of the following:

● Measurement identifiers to identity measurement identity that triggers the measurement reporting;

● list (s) of cells, e.g., a list of PCIs or cell indexes;

● list (s) of beam IDs or indexes;

● RSRP/RSRQ/SINR results of cell and/or beam (measured or predicted) .

In some example implementations, for the result from AI/ML prediction, results corresponding to the prediction time may be sent, whereas for the result from actual measurement, the available results may be be sent.

■ Timestamp (s) to indicate when the event (e.g., event A3, event A5) would be triggered. In some example implementations, a timestamp may indicate an absolute time or a delta time to a reference time (e.g., the time when the network receives the message) .

■ Indication to indicate whether the cell results and/or beam results are from prediction or actual measurement. In some example implementations, the granularity of this indication may be provided at a per measured cell level or per measured beam level. A per measured cell level means that the indication is applicable for the cell, where if this per cell indication is applicable for a measured cell, then whether all results from this cell (including both cell level results and beam level results) are from prediction is indicated via this indication.

In some example implementations, the UE sends measurement results (including prediction and/or actual measurements) to the network via an RRC signaling (e.g., MeasurementReport or UEAssistanceInformation) and/or MAC CE and/or DCI.

An example structure for a reporting message with indications for indicating whether the reported results are from prediction and if so, prediction times is is shown in FIG. 20.

In some example implementations, upon receiving measurement/prediction results, the network may determine whether to initiate the handover procedure and which cell to move to (as part of the mobility management Step 4 of FIG. 18) . The subsequent actions may include one of:

● The network may send a handover command to the UE directly. For example, the handover command may be an RRCReconfiguration message or MobilityFromNRCommand message or a cell switch command MAC CE.

● The network may send the handover command to the UE at the prediction time.

○ Optionally, in case of CU-DU split, if timestamp is sent to the network by the UE via RRC signaling, one or more of the followings need to be transferred from CU to DU in the source cell: the Handover command; and/or the time stamp to indicate when the DU is expected to transmit the handover command;

○ Optionally, in case of CU-DU split, the one or more of the followings may need to be transferred from CU to DU in the target cell: the time stamp to indicate when the source DU is expected to transmit the handover command.

○ Optionally, the handover command can be RRCReconfiguration message or MobilityFromNRCommand message or a cell switch command MAC CE.

● The network may send the handover command and a prediction time to the UE, and the UE may initiate the handover procedure at the prediction time. For example, in case of a CU-DU split in the base station, CU may transfer to DU in the target cell of the handover a timestamp to indicate when the UE is expected to execute the handover procedure. In such implementations, the timestamp may be an absolute time or a delta to a reference time (e.g., when the target DU receives this timestamp) .

In some example implementations, a source NG-RAN node shall indicate to a target NG-RAN node during mobility one or more of the following:

● RSRP/RSRQ/SINR results of cell and/or beam at the prediction time;

● A timestamp to indicate when the source node (e.g., source DU) is expected to transmit the handover command to the UE.

● The timestamp to indicate when UE is expected to execute handover procedure.

In some other example implementations of Step 3 of FIG. 18, based on the prediction results, the UE may activate actual measurement on some of the frequencies. Then if the actual measurement results satisfy predetermined or configured triggering criterion or criteria, the UE reports the measurement results (prediction results and/or actual measurement results) to the network.

In some example implementations for Radio Link Failure (RLF) prediction, if the UE predicts that an RLF would occur at the future time, the UE may send some related information in the reporting message of Step 3 of FIG. 18 to the network. Content of such related information may include or indicate one or more of the following:

● An indication to indicate that an RLF would occur in the future time instance;

● An indication to indicate a reason for the predicted RLF. For example, the reason may indicate untimely beam change or delayed handover, or other reasons.

● A timestamp to specify when the RLF would occur. For example, the timestamp may be indicated via an absolute time or a delta value to a reference time (e.g., the time when the network receives this message) .

● A timestamp to indicate when a first indication of N310 continuous out-of sync indications would occur. Again, as an example, the timestamp can be indicated via an absolute time or a delta value to a reference time (e.g., the time when the network receives this message) .

● A time stamp to indicate when the beam /cell switch action is expected by the UE.

● A beam quality on the current beam at the moment. For example, the reported quantity can be RSRP and/or RSRQ and/or SINR, which may be configured by the network.

● A cell quality for the serving cell at the moment. For example, the reported quantity may be RSRP and/or RSRQ and/or SINR, which may be configured by the network.

● The beam quality on the current beam at the future time instance. For one example, the future time instance can be the time when first out-of-sync indication of N310 continuous out-of-sync indications occurs or the time when RLF is declared or the time when the current beam quality is sufficiently worse than the best beam or other future time instance. For another example, the reported quantity can be RSRP and/or RSRQ and/or SINR, which may be configured by the network.

● A cell quality on the current serving cell at the future time instance. For example, the future time instance can be the time when first out-of-sync indication of N310 continuous out-of-sync indications occurs or the time when RLF is declared or the time when all beams within current serving cell are sufficiently bad (e.g., lower than a threshold) or other future time instance. For another example, the reported quantity can be RSRP and/or RSRQ and/or SINR, which may be configured by the network.

● Top K best beam indexes and the corresponding beam quality at the future time instance. For example, value K may be configured by the network. For another example, the Top K best beams may be determined based on a specific measurement quantity (e.g., RSRP and/or RSRQ and/or SINR) that is configured by the network. For yet another example, the future time instance can be the time when first out-of-sync indication of N310 continuous out-of-sync indications occurs or the time when RLF is declared or the time when the current beam quality is sufficiently worse than the best beam or other future time instance.

● The cell index and cell quality at the future time instance. For example, the UE may report top M best neighbor cell (s) at the future time instance to the network. For another example, value M may be configured by the network. For another example, the Top M best cells are determined based on a specific measurement quantity (e.g., RSRP and/or RSRQ and/or SINR) that is configured by the network. For yet another example, the future time instance can be the time when first out-of-sync indication of N310 continuous out-of-sync indications occurs or the time when RLF is declared or the time when the all beams within current serving cell are sufficiently bad (e.g., lower than a threshold) or other future time instance.

● The beam indexes and beam quality of the top N best beams in each neighbor cell (s) at the future time instance. For example, value N may be configured by the network. For another example, the Top N best cells are determined based on a specific measurement quantity (e.g. RSRP and/or RSRQ and/or SINR) that is configured by the network. For yet another example, the future time instance can be the time when first out-of-sync indication of N310 continuous out-of-sync indications occurs or the time when RLF is declared or the time when the all beams within current serving cell are sufficiently bad (e.g., lower than a threshold) or other future time instance.

● An indication to indicate whether the results are from prediction. For example, the granularity of such an indication can be at a per MO level or at a per measured cell level or at a per beam level.

In some example implementations, these information above can be sent to the network via an L1-signaling or a MAC CE or an RRC signaling (e.g., MeasurementReport or UEAssistanceInformation) .

In the example implementations above, upon receiving such information, the network may indicate one of the following actions:

Option 1: sending beam switch command or handover command to the UE directly;

Option 2: sending beam switch command or handover command to the UE at the prediction time;

Option 3: sending beam switch command or handover command to the UE, and the UE may apply this command at the prediction time.

In some example implementations, the beam switch command above can be sent via an RRC signaling and/or a MAC CE and/or a DCI.

In some example implementations, the handover command can be an RRCReconfiguration message, or a MobilityFromNRCommand or a cell switch command MAC CE.

In some example implementations, the prediction time can be the time when first out-of-sync indication of N310 continuous out-of-sync indications occurs or the time when RLF is declared or the time when beam/cell quality is sufficiently worse than the beam quality for best beam/cell.

In addition, in case of a CU-DU split in the source and/or target base station, if the prediction time is transmitted to the network by the UE via RRC signaling, the CU may transfer to the DU one or more of the following:

● The top K best beam indexes and the corresponding beam quality at the future time instance.

● The time stamp when the network is expected to send beam switch command/handover command to the network.

● The timestamp indicating when the UE is expected to execute beam switch procedure or handover procedure.

In the example implementation above, the prediction time can be the time when first out-of-sync indication of N310 continuous out-of-sync indications occurs or the time when RLF is declared or the time when beam/cell quality is sufficiently worse than the beam quality for best beam/cell or the time when the all beams within current serving cell are sufficiently bad (e.g., lower than a threshold) or other future time instance.

In some example implementations, in case of handover, a source NG-RAN node shall indicate the target NG-RAN node one or more of the following:

● RSRP/RSRQ/SINR results of cell and/or beam at the prediction time;

● A time stamp to indicate when source node (e.g., source DU) is expected to transmit the beam switch command or handover command to the UE.

● A time stamp to indicate when the UE is expected to execute the beam switch procedure or handover procedure.

In some example implementations, in the case that the network doesn’t reply the UE after the UE sent report above, the UE may declare the RLF earlier. Further, in some example implementations, the UE may initiate the RRC re-establishment earlier.

FIG. 21 illustrates an example showing an earlier RLF declaration. As shown in FIG. 21, at the time t (current time) , the UE may predict that an RLF would occur at the time t+8 (See 2102) . Then the UE may report the following information to the network:

● An indication to indicate the RLF would occur;

● A prediction time when the first out-of-sync indication of the N310 continuous out-of-sync indication occurs, e.g, t+2 in FIG. 21;

● Beam/cell results for current beam/cell at t;

● Beam/cell results for top K beam and/or top M cell at t+2;

● An indication to indicate whether the measurement results are from prediction.

A corresponding example reporting signaling structure is further shown in FIG. 22 and an RLF prediction information within a UE assistance information element.

In the example of FIG. 21, the network may send a handover command and prediction time (t=t+2) to the UE. An example signaling structure for the network to send such information is further illustrated in FIG. 23. With such handover command, the UE may proceed to executed handover at t+2.

If the UE already reports the RLF information to the network but has not received a response, the UE can declare the RLF earlier. For example, in FIG. 21, the UE declares the RLF upon receiving N310 consecutive out-of-sync indications at t+5.

Resource Management (RRM) and Event Prediction Based on UE Side AI/ML –Measurement Control under AI/ML Operation

Under UE-side AI operation, the UE is able to predict measurement results for one or more frequencies, but the network may expect the UE to perform actual measurement on some of the frequencies. So, the network may configure whether the UE is allowed to perform prediction on some of the frequencies. Such a procedure may be effectuated by signaling when needed and needs not be at a particular timing relation with various steps described above and in FIG. 18. The configuration may indicate one or more of the following:

● An explicit flag included in measurement object/reporting configuration, to indicate whether the UE can perform the prediction on the frequency associated with this measurement object/reporting configuration;

● A list of measurement identities or measurement objects, to indicate whether the UE can perform prediction on the corresponding frequency associated with the measurement identity or measurement object. In some example implementations, the list above may be indicated via (1) explicit measurement identity/measurement object list (e.g., by configuring a list of measurement object Ids) ; or (2) a bitmap. If the list is configured via an RRC signaling, the UE can execute measurement deactivation/activation as long as the UE receives the RRC configuration, or the UE may execute measurement deactivation/activation when receiving a DCI command or a MAC CE from the network.

● A flag that indicates whether the UE can perform prediction on all inter-RAT measurements and/or inter-frequency measurements. This flag may be sent to UE via DCI, or MAC CE or RRC.

The description and accompanying drawings above provide specific example embodiments and implementations. The described subject matter may, however, be embodied in a variety of different forms and, therefore, covered or claimed subject matter is intended to be construed as not being limited to any example embodiments set forth herein. A reasonably broad scope for claimed or covered subject matter is intended. Among other things, for example, subject matter may be embodied as methods, devices, components, systems, or non-transitory computer-readable media for storing computer codes. Accordingly, embodiments may, for example, take the form of hardware, software, firmware, storage media or any combination thereof. For example, the method embodiments described above may be implemented by components, devices, or systems including memory and processors by executing computer codes stored in the memory.

Throughout the specification and claims, terms may have nuanced meanings suggested or implied in context beyond an explicitly stated meaning. Likewise, the phrase “in one embodiment/implementation” as used herein does not necessarily refer to the same embodiment and the phrase “in another embodiment/implementation” as used herein does not necessarily refer to a different embodiment. It is intended, for example, that claimed subject matter includes combinations of example embodiments in whole or in part.

Reference throughout this specification to features, advantages, or similar language does not imply that all of the features and advantages that may be realized with the present solution should be or are included in any single implementation thereof. Rather, language referring to the features and advantages is understood to mean that a specific feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of the present solution. Thus, discussions of the features and advantages, and similar language, throughout the specification may, but do not necessarily, refer to the same embodiment.

Furthermore, the described features, advantages and characteristics of the present solution may be combined in any suitable manner in one or more embodiments. One of ordinary skill in the relevant art will recognize, in light of the description herein, that the present solution can be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the present solution.

Claims (30)

1. A method performed by a user equipment (UE) in communication with a network (NW) in a wireless communication network, comprising:

   receiving a measurement configuration from the NW;

   performing at least one measurement on one or more measurement objects according to the measurement configuration to obtain measurement results;

   performing a prediction by processing the measurement results using a UE-side Artificial Intelligence and/or Machine Learning (AI/ML) functionality;

   transmitting a report based on the measurement results and/or the prediction to the NW; and

   performing a mobility operation based on the measurement results and/or the prediction.
2. The method of claim 1, wherein the measurement configuration comprises at least one of:

   a measurement object list to indicate the one or more measurement objects that the UE needs to measure or perform prediction on;

   indications of whether AI/ML predictions on the one or more measurement objects or measurement identity are allowed or not; or

   a reporting configuration list to indicate how to report the measurement results and/or the prediction to the NW.
3. The method of claim 1, wherein the report comprises or indicates at least one of:

   a measurement ID for identifying the at least one measurement;

   a list of cell IDs or indexes;

   a list of beam IDs or indexes;

   the measurement results associated with the one or more measurement objects;

   a timestamp to specify when the event would be triggered; or

   an indication of whether the measurement results are from AI/ML prediction.
4. The method of claim 3, wherein the timestamps each comprises:

   an absolute time value; or

   a delta time value relative to an absolute time value.
5. The method of claim 1, wherein performing the mobility operation comprises receiving a handover command or a beam switch command from the NW.
6. The method of claim 5, wherein the prediction comprises an AI/ML prediction for a future time instance and the handover command is received at the future time instance.
7. The method of claim 5, wherein the prediction comprises an AI/ML prediction for a future time instance and the handover command or the beam switch command is received with the future time instance.
8. The method of claim 1, wherein the prediction comprises a predicted RLF of a current beam or all beams within current serving cell.
9. The method of claim 8, wherein the report comprises or indicates at least one of:

   a first indication that the predicted RLF would occur in a future time instance;

   a second indication of one or more reasons for the predicted RLF;

   a first timestamp specifying when the predicted RLF would occur;

   a second timestamp specifying when a set of continuous out-of sync indications would occur;

   a third timestamp specifying when a beam or cell switch is expected by the UE;

   a beam quality of the current beam at the future time instance;

   a cell quality of a current serving cell at the future time instance;

   top K best beams IDs or indexes and corresponding beam qualities at the future time instance;

   top M best neighboring cell IDs or indexes and corresponding cell qualities at the future time instance;

   beam IDs or indexes and qualities of top N best beams in each neighboring cell at the future time instance; or

   a fourth indication of whether the measurement results are from AI/ML predictions.
10. The method of claim 9, wherein the future time instance comprises a time instance when:

    a predefined or configured number of continuous out-of-sync condition occurs;

    an RLF is declared;

    a current beam quality is sufficiently worse than a best beam; or

    beams within current serving cell are lower than quality threshold.
11. The method of claim 8, wherein the mobility operation further comprises declaring an RLF earlier than a predicted future occurrence time of the predicted RLF.
12. The method of claim 11, wherein the mobility operation further comprises initiating RRC re-establishment earlier that the predicted future occurrence time of the predicted RLF.
13. The method of claim 1, wherein the UE performs AI/ML predictions on measurement objects or measurement identities corresponding to a first set of radio frequencies and perform actual measurements on measurement objects corresponding to a second set of radio frequencies.
14. The method of claim 13, wherein explicit flags are included in the measurement configuration to indicate whether the one or more measurement objects are allowed to be predicted via AI/ML or actually measured.
15. The method of claim 13, wherein the measurement configuration comprises a list of identifiers of measurement objects or measurement identities that are associated with the first set of radio frequencies.
16. A method performed by a network (NW) in communication with a user equipment (UE) in a wireless communication network, comprising:

    transmitting a measurement configuration to the UE;

    receiving a report based on measurement results and/or a prediction obtained by the UE, the measurement results and the prediction being associated with one or more measurement objects, the prediction being generated via a UE-side AI/ML functionality; and

    performing a mobility operation for the UE based on the measurement results and/or the prediction.
17. The method of claim 16, wherein the measurement configuration comprises at least one of:

    a measurement object list to indicate the one or more measurement objects that the UE needs to measure or perform prediction on;

    indications of whether AI/ML predictions on the one or more measurement objects or measurement identity are allowed or not; or

    a reporting configuration list to indicate how to report the measurement results and/or the prediction to the NW.
18. The method of claim 1, wherein the report is transmitted by the UE in response to one or more triggering conditions.
19. The method of claim 1, wherein the report comprises or indicates at least one of:

    a measurement ID for identifying the at least one measurement;

    a list of cell IDs or indexes;

    a list of beam IDs or indexes;

    the measurement results associated with the one or more measurement objects;

    a timestamp to specify when the report is triggered; or

    an indication of whether the measurement results are from AI/ML prediction.
20. The method of claim 19, wherein the timestamp each comprises:

    an absolute time value; or

    a delta time value relative to an absolute time value.
21. The method of claim 1, wherein performing the mobility operation comprises transmitting a handover command or a beam switch command to the UE.
22. The method of claim 21, wherein the prediction comprises an AI/ML prediction for a future time instance and the handover command or the beam switch command is received at the future time instance.
23. The method of claim 1, wherein the prediction comprises a predicted RLF of a current beam or all beams within current serving cell.
24. The method of claim 23, wherein the report comprises or indicates at least one of:

    a first indication that the predicted RLF would occur in a future time instance;

    a second indication of one or more reasons for the predicted RLF;

    a first timestamp specifying when the predicted RLF would occur;

    a second timestamp specifying when a set of continuous out-of sync indications would occur;

    a third timestamp specifying when a beam or cell switch is expected by the UE;

    a beam quality of the current beam at the future time instance;

    a cell quality of a current serving cell at the future time instance;

    top K best beams IDs or indexes and corresponding beam qualities at the future time instance;

    top M best neighboring cell IDs or indexes at the future time instance;

    beam IDs or indexes and qualities of top N best beams in each neighboring cell at the future time instance; or

    a fourth indication of whether the measurement results are from AI/ML predictions.
25. The method of claim 24, wherein the future time instance comprises a time instance when:

    a predefined or configured number of continuous out-of-sync condition occurs;

    an RLF is declared;

    a current beam quality is sufficiently worse than a best beam; or

    beams within current serving cell are lower than a quality threshold.
26. The method of claim 1, wherein the measurement configuration configures the UE to perform AI/ML predictions on measurement objects corresponding to a first set of radio frequencies and perform actual measurements on measurement objects corresponding to a second set of radio frequencies.
27. The method of claim 26, wherein explicit flags are included in the measurement configuration to indicate whether the one or more measurement objects or measurement identities are to be predicted via AI/ML or actually measured.
28. The method of claim 26, wherein the measurement configuration comprises a list of identifiers of measurement objects or measurement identities that are associated with the first set of radio frequencies.
29. The UE or the NW of any one of claims 1 to 28, the UE or the NW comprising a processor and a memory, wherein the processor is configured to read computer code from the memory to cause the UE or the NW to perform the method of any one of claims 1 to 28.
30. A computer program product comprising a non-transitory computer-readable program medium with computer code stored thereupon, the computer code, when executed by a processor of the UE or the NW of any one of claims 1 to 28, causing the processor to implement the method of any one of claims 1 to 28.