Method performed by mobile device, method performed by access network node, mobile device, and access network node for performing handover using ai / ML model(s)

Abstract

A method performed by a mobile device is disclosed. The method includes receiving, from an access network node, first information of beam measurement configuration for each candidate cell, second information of report configuration of a report corresponding to prediction of lower layer triggered mobility (LTM) using an artificial intelligence / machine learning (AI / ML) model, and third information of configuration of at least one event for triggering the LTM; measuring at least one beam based on the first information for inferring the AI / ML model for performing the prediction; and transmitting a report for the prediction based on the second information, in a case where one of the at least one event has occurred.

Description

METHOD PERFORMED BY MOBILE DEVICE, METHOD PERFORMED BY ACCESS NETWORK NODE, MOBILE DEVICE, AND ACCESS NETWORK NODE FOR PERFORMING HANDOVER USING AI / ML MODEL(S)

[0001] The present disclosure relates to a communication system and to parts thereof. The disclosure has particular but not exclusive relevance to wireless communication systems and devices thereof operating according to the 3rd Generation Partnership Project (3GPP) standards or equivalents or derivatives thereof (including Long Term Evolution (LTE)-Advanced, Next Generation or 5G / 6G networks, future generations, and beyond). The present disclosure in particular, but not exclusively, relates to the use of Artificial Intelligence / Machine Learning (AI / ML) models to generate lower layer triggered mobility handover (LTM-HO) predictions to enhance typical lower layer triggered mobility (LTM) handover procedures.

[0002] Earlier developments of the 3GPP standards were referred to as the Long-Term Evolution (LTE) of Evolved Packet Core (EPC) network and Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN), also commonly referred as '4G'. More recently, the term '5G' and 'new radio' (NR) has started to be used to refer to an evolving communication technology that is expected to support a variety of applications and services. Various details of 5G networks are described in, for example, the 'NGMN 5G White Paper' V1.0 (NPL 1) by the Next Generation Mobile Networks (NGMN) Alliance, which document is available from https: / / www.ngmn.org / 5g-white-paper.html. 3GPP intends to support 5G by way of the so-called 3GPP Next Generation (NextGen) radio access network (RAN) and the 3GPP NextGen core network.

[0003] Under the 3GPP standards, a NodeB (or e.g., an eNB in LTE, and gNB in 5G) is the radio access network (RAN) node (or simply 'access node', 'access network node' or 'base station') via which communication devices (user equipments or 'UEs') connect to a core network and communicate with other communication devices or remote servers. For simplicity, the present application will use the term access network node, RAN node or base station to refer to any such access nodes.

[0004] For simplicity, the present application will use the term mobile device, user device, or UE to refer to any communication device that is able to connect to the core network via one or more RAN nodes. Although the present application may refer to mobile devices in the description, it will be appreciated that the technology described can be implemented on any communication devices (mobile and / or generally stationary) that can connect to a communication network for sending / receiving data, regardless of whether such communication devices are controlled by human input or software instructions stored in memory.

[0005] In the current 5G architecture, the gNB structure may be split into two or more parts. In some RAN implementations there are two parts, known as the Central Unit (CU or gNB-CU) - sometimes referred to as a 'control unit' - and the Distributed Unit (DU or gNB-DU), connected by an F1 interface. This enables the use of a 'split' architecture in which the typically 'higher' CU layers (for example, but not necessarily or exclusively, Packet Data Convergence Protocol (PDCP) and Radio Resource Control (RRC) layers) and the, 'lower' DU layers (for example, but not necessarily or exclusively, Radio Link Control (RLC), Media (sometimes referred to as 'Medium') Access Control (MAC), and Physical (PHY) layers) are separated between a particular CU, and one or more DUs that are connected to and controlled by that CU via the F1 interface. Thus, for example, the higher layer CU functionality for a number of gNBs may be implemented centrally (for example, by a single processing unit, or in a cloud-based or virtualised system), whilst retaining the lower layer DU functionality locally separately for each gNB.

[0006] In more recently proposed RAN distributed architectures, in addition to the CU and DU, the concept of a Radio Unit (RU) - sometimes referred to as a 'remote unit' - has been introduced. In this architecture the RU is responsible for handling the digital front end (DFE), digital beamforming functionality and, typically, the functionality of the lower parts of the PHY layer, whilst the DU typically handles the higher parts of the PHY layer and the RLC and MAC layers. The CU in this architecture continues to be responsible for controlling one or more DUs (each DU corresponding to a different respective gNB) and to handle higher layer signalling (typically RRC and PDCP layers).

[0007] The actual functional split between the CU and DUs (and potentially RUs where applicable) of these distributed architectures is flexible allowing the functionality to be optimised for different use cases. Effectively, the split architecture enables a 5G network to use a different distribution of protocol stacks between CU and DUs (and potentially RUs) depending on, for example, mid-haul availability and network design.

[0008] The choice of how to split functions in the architecture depends on, among other things, factors related to radio network deployment scenarios, constraints and intended supported use cases. Key considerations include: the need to support a specific quality of service for each service offered and for real / non-real time applications; support of specific user density and load demand in a given geographical area; and available transport networks with different performance levels.

[0009] The coverage in many modern communication systems is often beam-based rather than cell based. There is no cell-level reference channel from where the coverage of the cell could be measured. Instead, each cell has one or more so-called synchronization signal / physical broadcast channel (PBCH) block (SSB) beams. SSB beams form a matrix of beams covering an entire cell area. Each SSB beam carries an SSB comprising a primary synchronization signal (PSS), secondary synchronization signal (SSS), and physical broadcast channel (PBCH).

[0010] The UE searches for and performs measurements on the SSB beams (e.g., of the synchronization signal reference signal received power, 'SS-RSRP,' synchronization signal reference signal received quality, 'SS-RSRQ,' and / or the synchronization signal to noise and interference ratio, 'SS-SINR'). The UE maintains a set of candidate beams which may contain beams from multiple cells. A PCI and beam ID (or SSB index) thus distinguish the SSB beams from each other. Effectively, therefore, the SSB beams are like mini cells which may be within a larger cell. Once a UE has detected and selected a cell (and / or an SSB beam in the case of 5G) it may attempt to access that cell and / or SSB beam using an initial RRC connection setup procedure comprising a random access procedure.

[0011] For example, once a UE has detected and selected a cell (and / or a beam in the case of 5G) it may attempt to access that cell and / or beam using an initial radio resource control (RRC) connection setup procedure comprising a random access (RACH) procedure that typically involves four distinct steps. Alternatively, the UE may attempt to access that cell and / or beam using a so-called two-step RACH procedure. Both the four step and two step RACH procedures are well known to those skilled in the art.

[0012] As those skilled in the art will appreciate, while a contention based PRACH procedure is described, a non-contention based (or 'contention free') procedure may also be used in which a dedicated preamble is assigned by the base station to the UE.

[0013] Random access procedures such as those described may also be used in other contexts including, for example, handover, connection reestablishment, requesting UL scheduling where no dedicated resource for a scheduling-request has been configured for the UE, etc.

[0014] Nevertheless, whilst a RACH procedure may be used to access a target cell of a target RAN node during handover, the UE may attempt to access that cell and / or beam using a so called 'RACH-less' based handover which provides reductions in the data connectivity interruption time at each handover as it removes the need for performing random access when first accessing the target cell, and hence reduces overall handover execution time.

[0015] In the case of handover procedures, typically a communication system would employ layer-3 (L3) type handover procedures, or alternatively layer-1 (L1) / layer-2 (L2) type handover procedures (also known as lower-layer triggered mobility (LTM) handovers to hand a UE over from a source RAN node to a target RAN node.

[0016] In the L3-type case the decision to perform a handover is generally based on measurement reports received by the source RAN node from the UE in advance of the handover. However, depending on the time taken for the UE to transmit those measurement reports, and the time taken for the RAN node to process those measurement reports, the radio signal conditions associated with source and target RAN nodes may have changed. Alternatively, (or additionally), the radio signal conditions associated with source and target RAN nodes may also change during the execution of the handover itself. Accordingly, the handover may fail, or may be inappropriate by the time it is actually triggered.

[0017] In the LTM-type case the decision to perform a handover is generally also based on measurement reports received by the source RAN node from the UE in advance of the handover. Beneficially compared to the L3-type procedure however, the measurement reports are sent on a more 'real-time' basis i.e., the handover decision is taken very soon after the measurement reports are transmitted and processed. However, it will be appreciated that such 'real-time' signalling is achieved at the cost of huge amounts of measurement report overload. Additionally, with such 'real-time' signalling there is a risk that handovers may be triggered unnecessarily due to minor changes in radio signal conditions and may also lead to 'ping-pong' style handovers.

[0018] To improve handover robustness, conditional handover (CHO) procedures have also been introduced. In CHO, the handover is not executed until the UE being handed over (rather than the network) determines that one or more handover execution conditions have been met. As in conventional handover, in CHO, a source RAN node may make the initial handover decision based on measurement reporting by the UE (e.g., a measurement report triggered by a particular measurement reporting event, or periodically, or the like). However, the UE makes the ultimate decision of when to commence handover, e.g., when one or more handover execution conditions have been met. In response to the measurement reports, the source RAN node decides to use CHO for handover and requests a CHO with one or more 'candidate' target RAN nodes by sending each target RAN node a respective CHO request message. In response to a CHO request message, a target RAN node typically sends a CHO response including a configuration of CHO candidate target RAN nodes to the source RAN node.

[0019] The source RAN node then sends a RRC configuration message to the UE, which contains the configurations of the CHO target RAN nodes and of one or more CHO execution conditions. The source RAN node decides on the CHO conditions for the execution of CHO and adds information for configuring the conditions to the RRC message sent to the UE. In response, the UE sends an RRC message to the source RAN node to confirm the RRC configuration at the UE.

[0020] The UE maintains connection with its source RAN node while it evaluates one or more CHO execution conditions for the CHO target RAN nodes. If at least one CHO execution condition is satisfied for a CHO candidate cell, the UE detaches from the source RAN node, applies the corresponding stored configuration for the target RAN node that operates that candidate cell and synchronises to that target RAN node. The UE accesses the target RAN node and completes the handover procedure.

[0021] Nevertheless, the handover procedures mentioned above are based on real measurements (e.g., of reference signals or the like) and are, therefore, reactive-type handovers that are triggered in response to an issue that has already occurred in the communication system (e.g., a radio link failure, or the like). Thus, there is still a risk with these handover procedures that service disruptions may occur, which may, for example be particularly problematic in time-critical systems.

[0022] For example, in an L3 triggered handover procedure after the source RAN node decides to trigger handover based on an L3 measurement report, the radio signal conditions may change before (or during) handover execution. This could potentially lead to there being a significant communication quality gap between when the measurements were performed and when handover execution occurs (e.g., based on UE and / or cell movement, and / or other factors) thereby increasing the chance of a handover failure or incorrect handover (e.g., to a non-optimum target cell) - especially when the UE is moving at speed. Similarly, disparities between the radio signal conditions at measurement and the radio signal conditions at handover may lead to handover occurring at a non-optimum time (e.g., too early, or too late), or unnecessary handover occurring.

[0023] In the case of an LTM handover procedure, whilst the handover decision is based on 'real-time' measurement reporting (and hence alleviates some potential issues that may occur in an L3 triggered handovers), the use of L1 / l2 measurement reporting causes a relatively large amount of signalling overhead. For example, handover decisions based on an instant L1 measurement report (i.e., a measurement report that has not been subject to L3 filtering by the UE), may be rapidly followed by a similar decision in the new cell to handover back to the previous cell. Hence, unnecessary handovers, and so called 'ping-pong' handovers may occur, thereby increasing measurement report overheads, and other signalling overheads, significantly.

[0024] Some recent developments in 3GPP relate to the use of artificial AI and ML, often abbreviated to AI / ML. Predictions or inferences generated using an AI / ML model can be used as part of various methods for improving the reliability or efficiency of communication in the network. For example, AI / ML models can be used to predict the path of a UE based on previous mobility of the UE, used for cell and / or beam management, or used in methods of encoding and transmitting information. An AI / ML model may be hosted at a RAN node, and the RAN node may perform control of communication resources or control related to the status of a UE (e.g., control of UE mobility, or control of a radio resource control (RRC) state of the UE) based on an inference (e.g., determination or prediction) generated using the AI / ML model. The RAN node may also transmit an inference generated using the model to another node in the network, for use at the other node.

[0025] Alternatively, an AI / ML model may be hosted at two nodes of the network, for example at a RAN node and at a UE. In this case, the RAN node and the UE may both make determinations or predictions using the model. For example, the UE may use the model as part of an encoding process for encoding (and / or compressing) channel state information (CSI) for transmission to the RAN node, and the RAN node may use the same model as part of a corresponding decoding (and / or decompression) process for decoding the CSI received from the UE.

[0026] It will nevertheless be appreciated that the use of AI / ML models may also be extended to other procedures and methods performed in a communication system to further improve the reliability or efficiency of communication in the network, for example, in handover and / or beam switching procedures. One possible approach to addressing issues with conventional (L3) triggered, or LTM, type mobility procedures, therefore, is to adapt (or develop new) handover procedures that can be triggered in response to AI / ML model generated inferences, or the like.

[0027] Whilst a number of proposals have been made for the use of AI / ML model inferences in the context of handover procedures, there is still a need for improved AI / ML based methods and techniques.

[0028] NPL 1: NGMN 5G White Paper' V1.0

[0029] The present specification aims to disclose apparatus and methods that at least contribute to addressing one or more of the above needs and / or issues.

[0030] In one aspect there is provided a method performed by a mobile device, the method comprising: 　　receiving, from an access network node, first information of beam measurement configuration for each candidate cell, second information of report configuration of a report corresponding to prediction of lower layer triggered mobility (LTM) using an artificial intelligence / machine learning (AI / ML) model, and third information of configuration of at least one event for triggering the LTM; 　　measuring at least one beam based on the first information for inferring the AI / ML model for performing the prediction; and 　　transmitting a report for the prediction based on the second information, in a case where one of the at least one event has occurred.

[0031] In one aspect there is provided a method performed by an access network node, the method comprising: 　　transmitting, to a mobile device, first information of beam measurement configuration for each candidate cell, second information of report configuration of a report corresponding to prediction of lower layer triggered mobility (LTM) using an artificial intelligence / machine learning (AI / ML) model, and third information of configuration of at least one event for triggering the LTM; and 　　receiving a report for the prediction based on the second information, in a case where one of the at least one event has occurred, and 　　wherein the report is based on measuring, by the mobile device, at least one beam based on the first information for inferring the AI / ML model for performing the prediction.

[0032] In one aspect there is provided a mobile device comprising: 　　means for receiving, from an access network node, first information of beam measurement configuration for each candidate cell, second information of report configuration of a report corresponding to prediction of lower layer triggered mobility (LTM) using an artificial intelligence / machine learning (AI / ML) model, and third information of configuration of at least one event for triggering the LTM; 　　means for measuring at least one beam based on the first information for inferring the AI / ML model for performing the prediction; and 　　means for transmitting a report for the prediction based on the second information, in a case where one of the at least one event has occurred.

[0033] In one aspect there is provided an access network node comprising: 　　means for transmitting, to a mobile device, first information of beam measurement configuration for each candidate cell, second information of report configuration of a report corresponding to prediction of lower layer triggered mobility (LTM) using an artificial intelligence / machine learning (AI / ML) model, and third information of configuration of at least one event for triggering the LTM; and 　　means for receiving a report for the prediction based on the second information, in a case where one of the at least one event has occurred, and 　　wherein the report is based on measuring, by the mobile device, at least one beam based on the first information for inferring the AI / ML model for performing the prediction.

[0034] The various functional means described below that are part of the UE may be provided by a memory and one or more processors that execute instructions stored in the memory. Similarly, the various functional means described below that are part of the access network node may be provided by a memory and one or more processors that execute instructions stored in the memory.

[0035] Various example described below may be implemented by means of a computer program product comprising computer implementable instructions for causing a programmable computer to carry out the any of the methods described below. The computer implementable instructions may be provided as a signal or on a tangible computer readable medium.

[0036] According to the present disclosure, it is possible to provide a method performed by a mobile device, a method performed by a access network node, a mobile deice, and an access network node.

[0037] Examples of the disclosure will now be described, by way of example, with reference to the accompanying drawings in which:

[0038] Fig. 1 schematically illustrates a mobile ('cellular' or 'wireless') communication system;Fig. 2 is a simplified sequence diagram illustrating a RAN node-triggered layer-3 (L3)-type handover procedure that may be implemented in the communication system of Fig. 1;Fig. 3 is a simplified sequence diagram illustrating a RAN node-triggered layer-1 / layer-2 (L1 / L2)-type handover procedure that may be implemented in the communication system of Fig. 1;Fig. 4 illustrates a functional framework for AI / ML models, and how various entities of the framework may interact with one another, that may be implemented in the communication system of Fig. 1;Fig. 5 schematically illustrates a method of training an AI / ML model, and of monitoring the performance of the AI / ML model, which may be implemented in the communication system of Fig. 1;Fig. 6 illustrates a simplified sequence diagram of an example procedure for configuring and using an AI / ML model for LTM-HO prediction stored at a UE in the communication system illustrated in Fig. 1;Fig. 7 illustrates a simplified sequence diagram of another example procedure for configuring and using an AI / ML model for LTM-HO prediction stored at a UE in the communication system illustrated in Fig. 1;Fig. 8 illustrates a simplified sequence diagram of an example procedure for configuring and using an AI / ML model for LTM-HO prediction stored at a RAN node in the communication system illustrated in Fig. 1;Fig. 9 illustrates a simplified sequence diagram of an example procedure for configuring and using an AI / ML model for LTM-HO prediction stored at a RAN node in the communication system illustrated in Fig. 1 with inter-cell coordination;Fig. 10 illustrates a simplified sequence diagram of an example procedure for configuring and using an AI / ML model for LTM-HO prediction stored at a distributed RAN node in the communication system illustrated in Fig. 1;Fig. 11 illustrates a simplified sequence diagram of another example procedure for configuring and using an AI / ML model for LTM-HO prediction stored at a distributed RAN node in the communication system illustrated in Fig. 1;Fig. 12 is a simplified block schematic illustrating the main components of a UE for implementation in the communication system of Fig. 1;Fig. 13 is a simplified block schematic illustrating the main components of a non-distributed RAN node for implementation in the communication system of Fig. 1; andFig. 14 is a schematic block diagram illustrating the main components of a distributed RAN node for the communication system of Fig. 1.

[0039] < Overview > 　　An exemplary communication system will now be described in general terms, by way of example only, with reference to Figs. 1 to 3.

[0040] Fig. 1 schematically illustrates a mobile ('cellular' or 'wireless') communication system 1 to which examples of the present disclosure are applicable.

[0041] In the communication system 1, user equipments (UEs) 3 (3-1, 3-2, 3-3) (e.g., mobile telephones and / or other mobile devices) can communicate with each other via a corresponding (radio) access network ((R)AN) node 5-1, 5-2 that operates according to one or more compatible radio access technologies (RATs). In the illustrated example, each RAN node 5 (5-1, 5-2) comprises a base station 5 that respectively operates one or more associated cells 9 (9-1, 9-2). In the illustrated communication system 1, the coverage provided by each RAN node 5 may be by means of a plurality of beams B (B1, B2 … Br, Br+1 … BN). It will be appreciated that while, for clarity of illustration, only a selection of possible beams B are shown for one of the RAN nodes 5, the set of beams may include any suitable number of beams and each RAN node 5 may operate a respective set of beams or may provide coverage in a non-beamformed manner.

[0042] Communication via each RAN node 5 is typically routed through a core network 7 (e.g., a 5G / 6G and / or later generations' core network or evolved packet core network (EPC)).

[0043] As those skilled in the art will appreciate, whilst three UEs 3 and two RAN nodes 5 are shown in Fig. 1 for illustration purposes, the system, when implemented, will typically include one or more other RAN nodes 5 and UEs 3.

[0044] Each RAN node 5 controls one or more associated cells 9 either directly, or indirectly via one or more other nodes (such as home base stations, relays, remote radio heads, distributed units, and / or the like). It will be appreciated that the RAN nodes 5 may be configured to support 4G, 5G, 6G and / or later generations, and / or any other 3GPP or non-3GPP communication protocols.

[0045] In this example one of the illustrated RAN nodes 5 is a non-distributed RAN node 5-1, while another RAN node 5 is a distributed RAN node 5-2. That distributed RAN node 5-2 forms part of a distributed RAN (which may be referred to as a 'distributed base station'). The RAN node 5-2 of a distributed RAN comprises at least one distributed unit (DU) 5-2DU(e.g., a gNB-DU or the like), and a central unit (CU) 5-2CU(e.g., a gNB-CU or the like). The CU 5-2CUemploys a separated control plane and user plane and so is, itself, split between a control plane function (CU-CP) and a user plane function (CU-UP) which respectively communicate, with the DU 5-2DUvia a first interface (e.g., an F1-C logical interface) and a second interface (e.g., an F1-C logical interface) (the interfaces together forming a combined interface such as an F1 interface (or 'reference point')), and with one another via another interface (e.g., an E1 logical interface). It will be appreciated that while, in this example, the DU 5-2DUincludes the physical and virtual elements required to provide the functionality of the lower parts of the PHY layer and hence communicate with the UEs 3 over the air interface, the distributed RAN node 5-2 may alternatively (or additionally) include one or more separate radio units (RUs) (e.g., providing this functionality of the lower parts of the PHY layer).

[0046] Whilst one non-distributed ('integrated') RAN node 5-1 and one distributed RAN node 5-2 are shown, it will, nevertheless, be appreciated that either (or both) of the RAN nodes 5 may be provided in a distributed or non-distributed form. It will also be appreciated that whilst the term 'RAN node' is generally used herein to refer to a whole base station, the CU 5-2CUand DU 5-2DUare also both parts of a corresponding distributed RAN and are therefore each a distinct 'RAN node' albeit that they each form part of the same RAN, and that each may have only a subset of the functionality provided by a whole base station. References to a RAN node as used herein should, therefore, be understood, accordingly.

[0047] The UEs 3 and their serving RAN node 5 are connected via an appropriate air interface (for example the so-called 'Uu' interface and / or the like). Neighbouring RAN nodes 5 may be connected to each other via an appropriate RAN node to RAN node interface (such as the so-called 'X2' interface, 'Xn' interface and / or the like).

[0048] The core network 7 includes a number of logical nodes (or 'functions') for supporting communication in the communication system 1. In this example, the core network 7 comprises control plane functions (CPFs) 10 and one or more network node entities for the communication of user data (e.g., user plane functions (UPFs) 11). The CPFs 10 include one or more network node entities for the communication of control signalling (e.g., Access and Mobility Management Functions (AMFs) 10-1), one or more network node entities for session management (e.g., Session Management Functions (SMFs) 10-2) and a number of other functions 10-n. Additional functions may include, for example: an Authentication Server Function (AUSF) which facilitates security processes; a Unified Data Management (UDM) entity for managing user specific data (e.g., for access authorization, user registration, and data network profiles); a Policy Control Function (PCF); an Application Function (AF); a Security Anchor Function (SEAF) which is in a serving network and acts as a "middleman" during an authentication process between a UE 3 and its home network; an Authentication credential Repository and Processing Function (ARPF) which maintains the authentication credentials; and / or the like. It will be appreciated that the nodes or functions may have different names in different systems.

[0049] Each RAN node 5 is respectively connected to the core network nodes via appropriate interfaces (or 'reference points') such as an N2 reference point between the RAN node 5 and the AMF 10-1 for the communication of control signalling, and an N3 reference point between the RAN node 5 and each UPF 11 for the communication of user data. The UEs 3 are each connected to the AMF 10-1 via a non-access stratum (NAS) connection over an appropriate reference point (e.g., N1 reference point (analogous to the S1 reference point in LTE)). It will be appreciated, that N1 communications are routed transparently via the RAN node 5.

[0050] Each UPF 11 is connected to an external data network 20 (e.g., an IP network such as the internet) via an appropriate reference point (e.g., an N6 reference point) for communication of the user data.

[0051] The AMF 10-1 performs mobility management related functions, maintains the NAS connection with each UE 3 and manages UE registration. The AMF 10-1 is also responsible for managing paging. The AMF 10-1 receives user information sent through the network and forwards the information to the SMF 10-2.

[0052] The SMF 10-2 is connected to the AMF 10-1 via an appropriate reference point (e.g., N11 reference point). The SMF 10-2 provides session management functionality (that formed part of MME functionality in LTE) and additionally combines some control plane functions (provided by the serving gateway and packet data network gateway in LTE). The SMF 10-2 uses user information provided via the AMF 10-1 to determine what session manager would be best assigned to the user. The SMF 10-2 may be considered effectively to be a gateway from the user plane to the control plane of the network. The SMF 10-2 also allocates IP addresses to each UE 3.

[0053] Each RAN node 5 is also configured for transmission of, and the UEs 3 are configured for the reception of, control information and user data via a number of downlink (DL) physical channels and for transmission of a number of physical signals. The DL physical channels correspond to resource elements (REs) carrying information originated from a higher layer, and the DL physical signals are used in the physical layer and correspond to REs which do not carry information originated from a higher layer.

[0054] The DL physical channels may include, for example, a physical downlink shared channel (PDSCH), a physical broadcast channel (PBCH), and a physical downlink control channel (PDCCH). The PDSCH carries data sharing the PDSCH's capacity on a time and frequency basis. The PDSCH can carry a variety of items of data including, for example, user data, UE-specific higher layer control messages mapped down from higher channels, system information blocks (SIBs), and paging. The PDCCH carries downlink control information (DCI) for supporting several functions including, for example, scheduling the downlink transmissions on the PDSCH and also the uplink data transmissions on a physical uplink shared channel (PUSCH). The PBCH provides at least the UEs 3 with the Master Information Block (MIB). It also, in conjunction with the PDCCH, supports the synchronisation of time and frequency, which aids cell acquisition, selection and re-selection. Specifically, a UE 3 may receive a Synchronization Signal / Physical Broadcast Channel (PBCH) Block (SSB) (also referred to as an 'SS / PBCH block'), and the UE 3 may assume that reception occasions of a PBCH, primary synchronization signal (PSS) and secondary synchronization signal (SSS) are in consecutive symbols and form that SSB. The RAN node 5 may transmit several SSBs corresponding to different DL beams. The total number of SSBs may be confined, for example, within a 5ms duration as an SS burst.

[0055] The DL physical signals may include, for example, reference signals (RSs) and synchronization signals (SSs). A reference signal (sometimes known as a pilot signal) is a signal with a predefined special waveform known to both the UE 3 and the RAN node 5. The reference signals may include, for example, cell specific reference signals, UE-specific reference signal (UE-RS), downlink demodulation signals (DMRS), and channel state information reference signal (CSI-RS).

[0056] Similarly, the UEs 3 are configured for transmission of, and the RAN node 5 is configured for the reception of, control information and user data via several uplink (UL) physical channels corresponding to REs carrying information originated from a higher layer, and UL physical signals which are used in the physical layer and correspond to REs which do not carry information originated from a higher layer. The physical channels may include, for example, the PUSCH, a physical uplink control channel (PUCCH), and / or a physical random access channel (PRACH). The UL physical signals may include, for example, demodulation reference signals (DMRS) for a UL control / data signal, and / or sounding reference signals (SRS) used for UL channel measurement.

[0057] When the UE 3 initially establishes a radio resource control (RRC) connection with a RAN node 5 via a cell 9 it registers with an appropriate core network node (e.g., AMF 10-1, MME). The UE 3 is in the so-called RRC connected state and an associated UE context is maintained by the network. When the UE 3 is in the so-called RRC idle state, or is in the RRC inactive state, it selects an appropriate cell for camping so that the network is aware of the approximate location of the UE 3 (although not necessarily on a cell level).

[0058] The UEs 3 and the RAN nodes 5 of the communication system 1 are mutually configured for performing a random access channel (RACH) procedure for the UEs 3 to access the network. Specifically, on detection and selection of a cell 9 (and / or a beam in the case of 5G) a UE 3 is able to attempt access to that cell 9 and / or beam using an initial radio resource control (RRC) connection setup procedure comprising a random access procedure with a corresponding RAN node 5.

[0059] Prior to attempting initial access, the UE 3 chooses random access resources (including, for example, a preamble) to use to initiate the RACH procedure. The UE 3 sends the selected preamble (e.g., in 'Msg1') to the base station 5 over a physical random access channel (PRACH) for initiating the process to obtain synchronization in the uplink (UL). In response, the base station 5 responds with a random access response (RAR) (or 'Msg2'). The RAR indicates reception of the preamble and includes: a timing-alignment (TA) command for adjusting the transmission timing of the UE 3 based on the timing of the received preamble; an uplink grant field indicating the resources to be used in the uplink for a physical uplink shared channel (PUSCH); a frequency hopping flag to indicate whether the UE 3 is to transmit on the PUSCH with or without frequency; a modulation and coding scheme (MCS) field from which the UE 3 can determine the MCS for the PUSCH transmission; and a transmit power control (TPC) command value for setting the power of the PUSCH transmission. The UE 3 then sends a third message ('Msg3') to the network over a physical uplink shared channel (PUSCH) based on the information in the RAR. The specific message sent by the UE 3 in this step, and the content of the message, depends on the context in which the random access procedure is being used. In the example of initial radio RRC connection setup, however, Msg3 typically comprises an RRC Setup request or similar message carrying a temporary randomly generated UE identifier. The network responds with a fourth message ('Msg4') which carries the randomly generated UE identifier received in Msg3 for contention purposes to resolve any collisions between different UEs 3 using the same preamble sequence. When successful, Msg4 also transfers the UE 3 to a connected state.

[0060] While a four-step contention-based RACH procedure is described it will be appreciated that the UE 3 and the RAN node 5 of the communication system 1 may also perform a non-contention based (or 'contention free') procedure in which a dedicated preamble is assigned the RAN node 5 to the UE 3. Moreover, the UE 3 and the RAN node 5 of the communication system 1 may perform a two-step RACH procedure.

[0061] It will be appreciated that while the UE 3 can trigger initiation of the RACH procedure itself (e.g., when the UE 3 needs to connect to the network), initiation of the RACH procedure may be by the network. For example, a RACH procedure may be initiated via a message sent via downlink control information (DCI) with an appropriate DCI format (e.g., 1_0) in a physical downlink control channel (PDCCH) - such a message is commonly known as a PDCCH order. A RACH procedure may be also initiated by the RAN node 5 when handover is required (e.g., using a handover command message, or the like).

[0062] < Different Types of Handovers - Layer 3 (L3) Handover > 　　The UEs 3 and the RAN nodes 5 of the communication system 1 are mutually configured for performing handover procedures.

[0063] In conventional (e.g., layer-3 (L3)) handover procedures (including RACH-less handover procedures) the first RAN node 5S(e.g., operating as a source RAN node 5S) may initially decide to initiate a handover based on measurement reporting by the UE 3 (e.g., a measurement report triggered by a particular measurement reporting event, or periodically). In response, the first RAN node 5Sinitiates preparation of the second RAN node 5T(e.g., operating as a target RAN node 5T) for handover by sending a handover request message to the second RAN node 5T.

[0064] Assuming the second RAN node 5Tdecides to allow the handover request (e.g., based on appropriate admission control), the second RAN node 5Tthen prepares handover and sends a handover request acknowledgement message to the first RAN node 5S. This handover request acknowledgement message includes an RRC message generated by the second RAN node 5Tfor instructing modification / reconfiguration of the UE's RRC connection for the purposes of handover.

[0065] The first RAN node 5Sthen initiates a handover execution phase by sending the RRC reconfiguration message (including the mobility control information) to the UE 3. The UE 3 receives the RRC reconfiguration message and is thus commanded by the first RAN node 5Sto perform the handover. The UE 3 derives second RAN node 5Tspecific keys and configures the selected security algorithms to be used in the target cell. After receiving the RRC reconfiguration message, the UE 3 will attempt to access a primary cell (PCell) of the second RAN node 5Tat the first available physical uplink shared channel (PUSCH) occasion.

[0066] To confirm the handover the UE 3 may send an RRC reconfiguration complete message to the second RAN node 5T. The RRC reconfiguration complete message includes a cell radio network temporary identifier (C-RNTI), e.g., along with an uplink buffer status report, and / or uplink data, whenever possible. The second RAN node 5Tverifies the C-RNTI sent in the RRC reconfiguration complete message. The second RAN node 5Tcan then begin sending data to the UE 3 after scheduling appropriate downlink resources using the PDCCH.

[0067] The handover procedure is completed for the UE 3 when the UE 3 receives a UE contention resolution identity MAC control element (MAC CE) from the second RAN node 5Tor the UE 3 receives a PDCCH addressed to its C-RNTI from the second RAN node 5Tafter sending the initial uplink transmission.

[0068] An exemplary RAN node triggered handover procedure that may be used in communication system 1, will now be described, by way of example only, with reference to Fig. 2.

[0069] Fig. 2 is a simplified sequence diagram illustrating a RAN node L3 triggered handover procedure that may be implemented in the communication system. 1.

[0070] Referring to Fig. 2, the RAN node triggered handover procedure in this case concerns a handover of a UE 3 between the first RAN node 5S(e.g., operating as a source RAN node 5S) and the second RAN node 5T(e.g., operating as a target RAN node 5T).

[0071] At S202, before the handover procedure starts, the first RAN node 5Sis serving and communicating with the UE 3 (i.e., the source base station of the handover) and will typically have a UE context for the UE 3 stored in its memory. This may include, for example, information regarding roaming and access restrictions which were provided either at establishment of the connection between the UE 3 and the first RAN node 5Sor at the last tracking area update.

[0072] At step S204, the first RAN node 5Smay configure measurement procedures that are to be performed by the UE 3, and the UE 3 may transmit appropriate measurement reports to the first RAN node 5Sin accordance with the configured measurement procedures.

[0073] In the handover procedure, a handover preparation phase S206 commences when the first RAN node 5S(operating as the source RAN node 5S) decides to initiate handover. Specifically, at step S208 the first RAN node 5Sdecides to handover the UE 3 to a second RAN node 5T(e.g., the target RAN node 5T) based on, for example, measurement results received in a measurement report and / or radio resource management (RRM) information.

[0074] The first RAN node 5Sissues, at S210, a handover request, to the second RAN node 5T. This message will typically pass to the second RAN node 5T, information necessary to perform the handover. That necessary information may be used for preparing the handover at the target side. The necessary information may include, for example, the target cell ID, security information, a cell radio network temporary identifier (C-RNTI) of the UE 3 at the first RAN node 5S, RRM configuration information (e.g., including UE inactive time), basic access stratum (AS) configuration information including antenna information and downlink carrier frequency, current quality of service (QoS) flow to data radio bearer (DRB) mapping rules applied to the UE 3, the SIB1 from the first RAN node 5S, the UE capabilities for different RATs, protocol data unit (PDU) session related information, and / or UE reported measurement information including beam-related information if available.

[0075] While not shown, it will be appreciated that, admission control may be performed by the second RAN node 5T. Slice-aware admission control may, for example, be performed if corresponding slice information is sent to the second RAN node 5Tand if protocol data unit (PDU) sessions are associated with non-supported slices the second RAN node 5Tmay reject such a PDU session.

[0076] The second RAN node 5Tprepares handover and sends an appropriate response (e.g., a handover request acknowledge message or the like) to the first RAN node 5Sat S212. The response may include an RRC message in a transparent container that is to be sent to the UE 3 as a handover command to instruct / trigger performance of the handover (e.g., an RRC reconfiguration message or the like).

[0077] The first RAN node 5Striggers the handover by sending the RRC message (e.g., the RRC reconfiguration message or the like) to the UE 3 at S214. This RRC message contains the information required to access the target cell (e.g., the target cell ID, the new C-RNTI, the second RAN node security algorithm identifiers for the selected security algorithms and / or the like).

[0078] As soon as the first RAN node 5Sreceives the response (e.g., the handover request acknowledge message or the like), or as soon as the transmission of the handover command (e.g., the RRC reconfiguration message or the like) is initiated in the downlink, data forwarding may be initiated.

[0079] A handover execution phase S216 is then initiated, and the UE 3 detaches from the first RAN node 5Sand synchronises to the second RAN node 5T(at S218).

[0080] The UE 3 synchronises to a target cell of the second RAN node 5Tand completes the handover procedure by sending an appropriate RRC message (e.g., an RRC Reconfiguration Complete message) to the second RAN node 5T(at S220).

[0081] The last phase is the handover completion phase during which the second RAN node 5Tcoordinates with the core network 7 to switch communication to the second RAN node 5T(at S222). Once communication has been switched the second RAN node 5Tinitiates a UE context release at the first RAN node 5Sto release the associated resources of the first RAN node 5S(e.g., by sending a UE context release message at S224).

[0082] It will be appreciated that mobility methods and handover procedures for the UE 3 are not restricted to the example illustrated in Fig. 2. For example, the UE 3 may be configured to perform a conditional handover (CHO) in which the UE 3 determines whether handover of the UE 3 to a candidate cell is to be performed based on one or more execution conditions previously configured by the RAN node 5.

[0083] In the handover procedure described above with reference to Fig. 2, the handover decision is based on the 'beforehand' measurement reports from the UE 3 i.e., the system decides to perform the handover sometime after it has received measurement reports from the UE 3. However, it will be appreciated that after the handover decision is made, the radio signal conditions may change either before or during handover execution (e.g., at around step S214). If such a change in conditions occurs, there may be a quality gap between the current cell that the UE 3 is operating on, and the future cell to which it is going to switch, thereby increasing the chances of a handover failure, or the occurrence of an inappropriate handover. As a result of such changes in conditions, the handover may be performed too early, too late, or may even become unnecessary. It will be appreciated that this issue is particularly pertinent when the UE 3 moves at high speeds.

[0084] Being aware of the above issues, layer-1 / layer-2 (L1 / L2) triggered mobility procedures for handover (also referred to as lower-layer triggered mobility (LTM) handovers) have been developed that make handover decisions based on more 'real time' measurement reports. An example of such a LTM handover will now be described with reference to Fig. 3.

[0085] < Different Types of Handovers - LTM Handover > 　　Fig. 3 illustrates a simplified sequence diagram of a RAN node triggered LTM-type handover procedure that may be implemented in the communication system. 1.

[0086] As shown in Fig. 3 there is provided a UE 3, a first (e.g., source) RAN node 5Sin initial communication with the UE 3, and a second (e.g., target) RAN node 5Tto which the UE 3 is to be handed over.

[0087] At step S301 the UE 3 may perform measurements. For example, the measurements may be measurements of one or more reference signals (RSs) and / or other signals transmitted by the first RAN node 5Sand / or second RAN node 5Tin a corresponding cell 9. In one example, the measurements may be measurements of a signal strength of a signal transmitted by the first / second RAN node 5S / 5Tto the UE 3, that can be used as part of a determination that the UE 3 is to be handed over from the first (source) RAN node 5Sto the second (target) RAN node 5T.

[0088] In another example, at step S301, the UE 3 may additionally (or alternatively) perform any appropriate intra-frequency and inter-frequency measurements, which may be specified to the UE 3 via appropriate measurement objects in a configuration message sent to the UE 3 by the first RAN node 5S(not shown) that indicate frequency / time locations and SCSs of reference signals to be measured.

[0089] In another example, at step S301, the UE 3 may additionally (or alternatively) perform any appropriate inter-RAT measurements, which may be specified to the UE 3 via appropriate measurement objects in a configuration message sent to the UE 3 by the first RAN node 5S(not shown) that indicate a single carrier frequency (e.g., a E-UTRA frequency).

[0090] At step S302 the UE 3 may transmit a measurement report to the first (source) RAN node 5Sthat provides an indication of the result of the measurements made by the UE 3. The measurement report may be transmitted from the UE 3 to the first RAN node 5Sin an appropriate message (e.g., an RRC message). The first RAN node 5Smay use the information provided in the measurement report to determine (not shown) that LTM needs to be configured and to initiate LTM preparation (this decision may be referred to as an LTM handover decision). Specifically, the first RAN node 5Sdecides to (pre)configure the UE 3 for handover / cell switch to each of one or more LTM candidate cells / RAN nodes 5 forming an LTM candidate set. The LTM candidate set includes, for example, at least the cell / second RAN node 5Tthat will ultimately become the target cell / target RAN node 5T.

[0091] It will be appreciated that the UE 3 may transmit the measurement reports to the first RAN node 5Sbased on an appropriate reporting configuration previously signalled to the UE 3 by the first RAN node 5S. For example, the first RAN node 5Smay have previously provided the UE 3 with one or more reporting configurations that indicate a criterion to trigger the UE 3 to send measurement reports to the first RAN node 5S. The criterion may be a single event that triggers the UE 3 to send measurement reports to the first RAN node 5S. Alternatively the criterion may configure the UE 3 to send measurement reports to the first RAN node 5Son a periodic basis (i.e., triggered at periodic time intervals). The one or more reporting configurations may indicate to the UE 3 a type of RS that the UE 3 is to measure for beam and / or cell measurement results. For example, the one or more reporting configurations may indicate to the UE 3 that it is to measure the one or more synchronisation signals (e.g., secondary synchronisation signals) carried by SS / PBCH blocks (also referred to as 'SSBs'), CSI-RSs, or the like. By way of example only, the one or more reporting configurations may configure the UE 3 to measure and report, to the first RAN node 5S, measurement results per SS / PBCH block, measurement results per cell (or beam) based on SS / PBCH blocks, SS / PBCH block indexes, and the like. Furthermore, by way of example only, the one or more reporting configurations may configure the UE 3 to measure and report, to the first RAN node 5S, measurement results per CSI-RS resource, measurement results per cell (or per beam) based on CSI-RS resources, CSI-RS resource measurement identifiers, and the like.

[0092] The one or more reporting configurations may configure the UE 3 to measure and report, to the first RAN node 5S, SSB-based L1-RSRP measurements for beam selection. For example, the one or more reporting configurations may configure the UE 3 to measure and report, to first RAN node 5S, indexes of SSB resource sets configured for L1 mobility measurement reporting (e.g., SSBRI), L1 measurement quantities for each beam (e.g., RSPR), and / or differential L1 measurement quantities for each beam (e.g., differential RSPR), and / or the like.

[0093] Additionally (or alternatively) the one or more reporting configurations may indicate to the UE 3 a format in which the measurement results are to be presented to the first RAN node 5S. For example, the one or more reporting configurations may indicate to the UE 3 the quantity of measurements per cell and / or per beam to include in each measurement report sent to the first RAN node 5S. The one or more reporting configurations may also indicate to the UE 3 other appropriate associated information such as the maximum number of cells and the maximum number beams per cell to report.

[0094] At step S304 the first RAN node 5Smay transmit a handover request to each candidate RAN node 5 (i.e., each RAN node 5 that may become a target of the handover / cell switch in the future). In Fig. 3, whilst a single candidate RAN node 5 (second RAN node 5Tthat ultimately becomes the target RAN node 5T) is shown there may (but do not have to) be a plurality of candidate RAN nodes 5. The handover request may include an indication of, for example, an identity of the first RAN node 5S, a cause value for the handover, an identity of the second RAN node 5T, an identity of a target cell provided by the second RAN node 5T, UE context information (e.g., a maximum bit rate of the UE 3, or security capabilities of the UE 3), UE history information, and the like. For example, the handover request may include, amongst other things, a target cell ID, security information, a C-RNTI of the UE 3 at the first RAN node 5S, RRM configuration information (e.g., including UE inactive time), basic AS configuration information including antenna information and downlink carrier frequency, current QoS flow to DRB mapping rules applied to the UE 3, the SIB1 from the first RAN node 5S, the UE capabilities for different RATs, PDU session related information, and / or UE reported measurement information including beam-related information if available.

[0095] Furthermore, it will be appreciated that if the handover has been triggered by the measurement report received by the first RAN node 5Sin step S302, then the cause value included in the handover request may indicate, for example, that the handover is desirable for radio reasons.

[0096] The following procedure will be described from the perspective of the candidate (second) RAN node 5Tthat ultimately becomes the target RAN node 5T. It will, nevertheless, be appreciated that a similar procedure will be performed at each candidate RAN node 5 as part of the procedure to configure the UE 3 for LTM.

[0097] At step S306, having received handover request, the second RAN node 5Tmay perform, based on that handover request, an admission control procedure. For example, the second RAN node 5Tmay perform a validation procedure that may involve performing a check that if a connection is established between the UE 3 and the second RAN node 5Tthen current resources are sufficient for the proposed connection.

[0098] At step S308 having received the handover request at step S304 and having performed admission control at step S306, the second RAN node 5Tprepares handover with its lower layers (L1 and L2) (e.g., including reserving corresponding resources for the UE 3) and sends, to the first (source) RAN node 5S, an appropriate response (e.g., a handover request acknowledge message or the like). The handover request acknowledge message may include a transparent container comprising a message (e.g., an RRC message) to be sent to the UE 3 and that is to be used as an 'LTM candidate configuration' message to configure LTM handover / cell switch for that specific candidate (second) RAN node 5T(e.g., as a handover command to instruct performance of the handover). The message to be sent to the UE 3 may, for example, be an RRC reconfiguration message or the like. The handover request acknowledgement message may also include appropriate configuration information that enables the first RAN node 5Sto begin forwarding user plane data for the UE 3 to the second RAN node 5T.

[0099] It will be appreciated that the transmissions of at steps S304 and S308 may be performed over an Xn interface between the first RAN node 5Sand the second RAN node 5T(and therefore the handover procedure in this example may be referred to as an Xn-based handover procedure). Steps S301 to S308 may be referred to as a 'handover preparation phase' of a handover procedure. At step S310, the first RAN node 5Stransmits the respective LTM candidate configuration to the UE 3 received from each candidate RAN node 5 in an appropriate (e.g. RRC) message (e.g., an RRC reconfiguration message) comprising an appropriate LTM configuration information element (IE) including the respective LTM candidate configuration for each candidate RAN node 5 (of which there may be one or more). Each LTM candidate configuration in the LTM configuration IE may, for example, be a complete candidate configuration or may be a delta configuration relative to a reference configuration.

[0100] The first RAN node 5Smay also include as part of the LTM configuration, LTM measurement configuration information for configuring L1 measurements to be reported. The measurement configuration information may, for example, be configured for configuring the UE 3 to provide an SSB based L1-RSRP measurement report for beam selection. The first RAN node 5Smay also include as part of the LTM configuration, LTM report configuration information for configuring L1 measurement reporting. The report configuration information may, for example, configure reporting to be periodic (on the PUCCH), aperiodic, semipersistent (on the PUCCH or the PUSCH), and / or the like. The report configuration information may, for example, configure the content of the report (e.g., how many cells are reported within a single L1 measurement report instance, how many reference signals per cell are reported within a single L1 measurement report instance, whether the UE 3 should include an L1 measurement report associated to the current special cell, and / or the like).

[0101] Having received those LTM candidate configurations, the UE 3 stores the LTM candidate configurations and responds to the message carrying the LTM configuration (not shown) with an appropriate response message (e.g., an RRC reconfiguration complete message or the like) to effectively indicate that the LTM configuration has been completed at the UE 3.

[0102] The UE 3 may, at this stage, perform early synchronization (not shown), in the downlink, with each candidate cell (i.e., before receiving any corresponding cell switch (or 'handover') command). The UE 3 may also, at this stage, perform early synchronization (not shown), in the uplink, with each candidate cell. Specifically, when UE-based timing advance (TA) measurement is configured, the UE 3 may acquire a respective TA value of each candidate cell by measurement. The UE 3 may perform early TA acquisition with a candidate cell in accordance with a request by the network (i.e., before receiving any corresponding cell switch (or 'handover') command). This may, for example, be done via a contention free random access (CFRA) triggered by a PDCCH order from the first RAN node 5S, following which the UE 3 sends preamble towards the indicated candidate cell. In order to minimise the data interruption of the source cell due to CFRA towards a candidate cell, the UE 3 need not receive random access response from the network for the purpose of TA value acquisition and the TA value of the candidate cell may be indicated in any cell switch command.

[0103] An LTM execution / completion phase is then initiated during which the UE 3 performs, at S312, the configured L1 measurements for the configured candidate cells (where possible) and sends, at S314, a corresponding L1 measurement report to the first RAN node 5Sin accordance with the report configuration information. L1 measurement may be performed as long as the LTM configuration (i.e., the RRC reconfiguration) provided at S310 is applicable.

[0104] When the UE 3 sends a report configured to provide SSB based L1-RSRP measurements, the L1 measurement report may include, for example, an SSB resource set index ('SSBRI'), which is an index of an SSB resource set configured for L1 mobility measurement reporting. This report may include, for example, a set of one or more L1-RSRP measurement results for each cell 9. Each reported L1-RSRP value may, for example, be an absolute (e.g., 7-bit) value, or differential reporting may be used in which one or more L1-RSRP values are reported as differential (e.g., 4-bit) values relative to another reported 'reference' absolute (e.g. 7-bit) value of L1-RSRP (e.g., the reference value may be the highest (or lowest) reported L1-RSRP).

[0105] At S316, the first RAN node 5Sdecides to execute cell switch to a target cell (i.e., a cell of the second RAN node 5Tin this example). The first RAN node 5Smay then initiate transmission, at S318, of an LTM cell switch command (e.g., as a MAC CE for triggering a cell switch (or handover)) including a candidate configuration index corresponding to the target cell / second RAN node 5T.

[0106] The UE 3 then detaches (not shown) from the source cell of the first (source) RAN node 5Sand switches to the target cell of the second (target) RAN node 5Tby applying the corresponding LTM candidate configuration indicated by candidate configuration index.

[0107] As indicated at S320, the UE 3 can then access the cell using a RACH based or RACH-less procedure. The UE 3 may, for example, perform a random access procedure towards the target cell if the UE 3 does not have valid TA of the target cell. Nevertheless, the UE 3 may access the cell without performing a random access procedure where the UE 3 has a valid TA. The UE 3 can complete the LTM cell switch procedure by sending an appropriate message (e.g., an RRC reconfiguration complete message) to the second RAN node 5T. If the UE 3 has performed a random access procedure the UE 3 may consider that LTM cell switch execution has been successfully completed when the random access procedure has successfully completed. For RACH-less LTM, on the other hand, the UE 3 may consider that the LTM cell switch execution has successfully completed when the UE 3 determines that the second RAN node 5Thas successfully received its first uplink data.

[0108] It will be appreciated that mobility methods and handover procedures for the UE 3 are not restricted to the example illustrated in Fig. 3. For example, the UE 3 may be configured to perform a CHO in which the UE 3 determines whether handover of the UE 3 to a candidate cell is to be performed based on one or more execution conditions.

[0109] < AI / ML > 　　The communication system 1 supports the use of artificial intelligence (AI) / machine learning (ML), often abbreviated to AI / ML in accordance with recent developments in cellular communication technology (e.g., as part of the work of the 3GPP) that those skilled in the art will be familiar with. These AI / ML features make use of trained AI / ML models to make one or more predictions or inferences, from a set of one or more input vectors, which can be used in the network (e.g., for improving the reliability or efficiency of communication in the network).

[0110] In respect of the communication system 1, for example, AI / ML models could potentially be trained and used for predicting the path of a UE 3 based on previous mobility of the UE 3, used for beam management, or used in methods of encoding and transmitting information. An AI / ML model may be hosted at a RAN node 5 (or any other suitable network node), and the RAN node 5 may perform control of communication resources for UEs 3 it serves, and / or perform control related to the status of a UE 3 (e.g. control of UE mobility, or control of a radio resource control, RRC, state of the UE 3) based on an inference (e.g. determination or prediction) generated using the AI / ML model. The RAN node 5 may also transmit an inference generated using the model to another node in the network, for use at the other node. An AI / ML model may also be hosted the UE 3, or at a plurality of locations within the network, for example at both the RAN node 5 and at the UE 3. For example, the RAN node 5 and the UE 3 may both make determinations and / or predictions using the same model or different models.

[0111] The support for such AI / ML features may involve different levels of collaboration between the network (RAN node 5 and / or core network 7) and a UE 3 served by the network when deploying and using such AI / ML features. For example, three possible 'network-UE collaboration levels' that may be supported are: 　　Level x: Involving no collaboration between the network and the UE 3. Specifically, level x is an implementation-based AI / ML operation without any dedicated AI / ML-specific enhancement. 　　Level y: Signalling-based collaboration without AI / ML model transfer. For example, this level is applicable when model training is performed offline, and models are registered to both a RAN node 5 and the UE 3. Here, the RAN node 5 and the UE 3 are aware of available models (before operation), and the RAN node 5 is only required to activate / deactivate the models residing at the UE 3 when needed. 　　Level z: Signalling-based collaboration with AI / ML model transfer (e.g., where an AI / ML model is transferred to the UE 3 when needed).

[0112] The AI / ML model types that are supported in the communication system 1 may include, for example: 　　Single-sided model: A single-sided AI / ML model is an AI / ML model that is deployed (hosted) only at the UE side or at the network side. For example, an AI / ML model may be hosted (stored, for generating inferences) at a UE 3, RAN node 5, or a central entity of the communication system 1, or an operations, administration, and maintenance (OAM) / over-the-top (OTT) server. When the AI / ML model is used at the UE 3, the RAN node 5, a central entity of the communication system 1, or an OAM / OTT server only, the AI / ML model may be referred to as a 'single-sided' model. An example of this type of 'single-sided' model is an AI / ML model for beam prediction in time, which can be deployed at the UE side.

[0113] However, even when the model is a single-sided model, it will be appreciated that the model need not necessarily be trained at the node at which it is deployed (e.g., a UE 3 or a RAN node 5). For example, the model could be trained at the RAN node 5 (or at another node in the network such as a core network node / function - e.g., a central entity of the communication system 1, or an OAM / OTT server - and then transferred to the UE 3 for use at the UE 3.

[0114] Two-sided model: A 'two-sided' model is an AI / ML model (or model pair) that has one AI / ML model hosted at one node (e.g., the UE 3), and a corresponding AI / ML model hosted at another node (e.g., a RAN node 5) - it will be appreciated that any pair of network nodes may be used. Such a two-sided model may also be referred to as a 'paired' AI / ML model. An inference using a two-sided model is performed jointly across the nodes at which the AI / ML models of the two-sided model are deployed. The joint inference may comprise, for example, a first part of the inference being performed at one node (e.g., the UE 3 or RAN node 5), and then the remaining part may be performed by the other (e.g., the RAN node 5 or UE 3). It will be appreciated that whilst the AI / ML model hosted at the different nodes may be the same AI / ML model, they need not necessarily be the same model. One example of this type of model is, for example only, channel state information (CSI) compression, where the UE 3 performs CSI compression and network performs CSI decompression. As with the single-sided model case, the two-sided model (or models) may be trained at any suitable network node, and then transmitted to the UE 3 and the RAN node 5 (or other respective node or nodes).

[0115] A general discussion of how AI / ML may be implemented in the communication system 1 will now be provided, by way of example only, with reference to Figs. 4 and 5.

[0116] Fig. 4 illustrates a functional framework for AI / ML models, and how various entities of the framework may interact with one another, that may be implemented in the communication system 1.

[0117] The entities include a data collection entity 441, a model training function 443, a model inference function 445, an actor 447, a management function 449, and a model storage entity 451.

[0118] The model storage entity 451 may be a reference point for protocol terminations for model transfer and delivery. The AI / ML models could be stored at any suitable node in the network.

[0119] The data collection entity 441 provides training data to the model training function 343, inference data to the model inference function 445, and monitoring data to the management function 449. The collected data may be, for example, data regarding mobility (e.g., handover of a UE 3, or a location of the UE 3). The data may be obtained, for example, by the UE 3 or a RAN node 5 (e.g., by receiving a measurement report from the UE 3, or by receiving data from another RAN node 5 or a core network node / function) and transmitted to another RAN node 5 or core network node that generates the AI / ML model inference output (or alternatively, the same RAN node 5 that obtains the data may generate the AI / ML model output).

[0120] The model training function 443 performs the AI / ML model training, validation, and testing, and may generate model performance metrics as part of a model testing procedure. The model training function 443 may output a trained AI / ML model to the model storage entity 451 (though it will be appreciated that the output model may be stored at locations other than model storage entity 451).

[0121] The model inference function 445 provides AI / ML model inference output (e.g., predictions or decisions), and the actor 447 is a function or node that receives the output from the model inference function 445 and triggers or performs corresponding actions (e.g., the RAN node 5 that increases / reduces its transmit power or initiates a handover procedure for the UE 3). The AI / ML model inference output may be, for example, a prediction of mobility (e.g., expected path, route or trajectory, inter-cell, or inter-beam mobility, or expected handover) of the UE 3, or one or more parameters for use in encoding or decoding transmissions between the RAN node 5 and the UE 3. The model inference function 445 may receive an AI / ML model from the model storage entity 451, and inference data from the data collection entity 441 for use with the AI / ML model. The model inference function 445 may also output monitoring data for use at the management function 449 and receive information indicating an AI / ML to activate or deactivate from the management function 449.

[0122] The management function 449 receives monitoring data from the data collection entity 441 and may also receive monitoring data from the model inference function 445. The management function 449 may transmit to the model storage entity 451, an indication of an AI / ML model to be transmitted for use at the model inference function 445. The management function 449 may also transmit to the model training function 443, performance feedback or a retraining request for the AI / ML model.

[0123] The functions illustrated in Fig. 3 may be co-located at a single node of the communication system 1 (e.g., at the RAN node 5 or core network node / function) or may be distributed amongst a plurality of network nodes (e.g., a plurality of the RAN nodes 5).

[0124] By way of example only, terms referred to by 3GPP in the context of this framework include: 　　AI / ML model training: A process to train an AI / ML Model [by learning the input / output relationship] in a data driven manner and obtain the trained AI / ML Model for inference. Model training can be performed offline or online or combination of both. 　　AI / ML model validation: A subprocess of training, to evaluate the quality of an AI / ML model using a dataset different from one used for model training, which helps selecting model parameters that generalize beyond the dataset used for model training. 　　AI / ML model testing: A subprocess of training, to evaluate the performance of a final AI / ML model using a dataset different from one used for model training and validation. Differently from AI / ML model validation, testing does not assume subsequent tuning of the model. 　　AI / ML model Inference: A process of using a trained AI / ML model to produce a set of outputs based on a set of inputs. 　　Data collection: A process of collecting data by the network nodes, management entity, or UE for the purpose of AI / ML model training, data analytics and inference. 　　Model monitoring: A procedure that monitors the inference performance of the AI / ML model. 　　Model activation: Enable an AI / ML model for a specific function. 　　Model deactivation: Disable an AI / ML model for a specific function. 　　Model switching: Deactivating a currently active AI / ML model and activating a different AI / ML model for a specific function. 　　Supervised learning: A process of training a model from input and its corresponding labels. 　　Unsupervised leaning: A process of training a model without labelled data. 　　Semi-supervised learning: A process of training a model with a mix of labelled data and unlabelled data. 　　Reinforcement Learning (RL): A process of training an AI / ML model from input (also referred to as 'state') and a feedback signal (also referred to as 'reward') resulting from the model's output (also referred to as 'action') in an environment the model is interacting with.

[0125] The data collection by the data collection entity 441 may be performed at various nodes of the communication system 1 (e.g., at one or more RAN nodes 5 or UEs 3). Particularly advantageous methods of obtaining, at the UE 3, data for an AI / ML model, and transmitting the AI / ML data from the UE 3 to the RAN node 5, will be described in more detail later.

[0126] Fig. 5 schematically illustrates of a method of training an AI / ML model, and of monitoring the performance of the AI / ML model. As illustrated in Fig. 5, stored data / features may first be extracted in a data extraction step. In the data validation step, a determination of whether to proceed with training or retraining the AI / ML model is made (e.g., based on the extracted data). In the data preparation stage, the data is prepared for use in training the AI / ML model. For example, the data may be cleaned (e.g., filtered), subject to a transformation, or modified in any other suitable manner. The data may also be divided in training data, validation data and test data sets in the data preparation stage.

[0127] In the model training step, the AI / ML model is trained (or retrained) using training data prepared in the data preparation step. It will be appreciated that any suitable training method can be used to train the AI / ML model (e.g., a method that comprises supervised learning or unsupervised learning). In the model evaluation step, the AI / ML model is evaluated (e.g., a prediction accuracy of the AI / ML model is evaluated) using a test data set (which may be generated in the data preparation step). In the model validation step, a determination of whether the AI / ML model is suitable for deployment in the communication system 1 is made (e.g., based on the results of the model evaluation step).

[0128] In the model serving step, the AI / ML model is deployed for use in the communication system 1. AI / ML model deployment may comprise compiling a trained AI / ML model, packaging the model into an executable format, and delivering the AI / ML model to a target device. For example, the AI / ML model may be transmitted to the RAN node 5 and / or the UE 3, for use at the RAN node 5 and / or the UE 3 to generate predictions or determinations using the AI / ML model as part of a prediction service step, as illustrated in Fig. 4. In the performance monitoring step, the performance of the deployed AI / ML model is monitored. The predictive performance of the AI / ML model may be monitored by comparing predictions generated using the model with one or more measurements. For example, when the AI / ML model is used to predict a location of the UE 3, the prediction accuracy of the AI / ML model may be assessed using a measurement of an actual location of the UE 3. If the AI / ML model is used for predicting future measurement results (e.g., the measured Reference Signal Received Power (RSRP) of reference signals) at some point in time, the prediction accuracy of the AI / ML model may be assessed using actual measurement results acquired by the UE 3 when that point in time is reached. If the AI / ML model is used for determining parameters for use in encoding and decoding data transmitted between the RAN node 5 and the UE 3, the model may be assessed based on the performance of the encoding and / or decoding processes. In the retraining trigger step, retraining of the AI / ML model is triggered (e.g., because the prediction accuracy of the AI / ML model has fallen below an acceptable threshold accuracy, or because a performance of a method that uses inferences from the AI / ML model has fallen below an acceptable threshold performance), and the method returns to the data extraction step.

[0129] Each step of the method of Fig. 5 may be executed at a single node of the communication system 1 (including at the RAN node 5), or alternatively steps of the method may be distributed between a plurality of different nodes (or indeed one or more of these steps may be performed online or offline).

[0130] As discussed above with reference to Figs. 4 and 5, information collected by nodes / functions in the communication system 1 (e.g., at the UE 3 and / or the RAN nodes 5) can be used as training data for an AI / ML model and used as inference data for use in generating one or more model inferences using the AI / ML model. The information used as training data, monitoring data, and / or to generate the one or more model inferences may be referred to as 'AI / ML information' or 'AI / ML data.'

[0131] < Configuration information for AI / ML > 　　Configuration information for an AI / ML model (which may be referred to as "AI / ML configuration information") may be exchanged between nodes in the communication system 1. For example, a core network node may transmit AI / ML configuration information to a RAN node 5 (or any other entity of the network that supports an AI / ML-based prediction functionality) that hosts an AI / ML model. The AI / ML configuration information may include a list of supported use cases for the AI / ML model (the AI / ML model need not necessarily be for predicting UE mobility). The supported use cases may be, for example: energy saving; traffic steering; anomaly detection; quality of experience (QoE) optimisation; mobility robustness optimisation (MRO); RAN slice service level agreement (SLA) assurance; massive multiple-input multiple-output (MIMO) beamforming optimisation; network slice subnet instance (NSSI) resource allocation; optimisation coverage and capacity optimisation (CCO); mobility load balancing (MLB); RACH optimisation; or UE transmission power optimisation. The AI / ML configuration information may include an indication of a particular AI / ML model to use for a particular use case. The AI / ML configuration information may also include an indication of whether feedback is required (e.g., from another network node). The feedback may include, for example, communication performance feedback (e.g., indicating a communication performance for communication between a UE 3 and a RAN node 5).

[0132] < AI / ML Enhanced Mobility > 　　Whilst the mobility procedures described with reference to Figs. 2 and 3, based on real measurements (e.g., of reference signals or the like), are appropriate in many cases it will be appreciated that both conventional (e.g., L3) and LTM handovers are reactive-type handovers that are triggered in response to an actual issue or event that occurs in the communication system 1 (e.g., a radio link failure, or the like). Hence, there remains a risk that service disruptions may occur, which may, for example be particular problematic in time-critical systems.

[0133] Beneficially, the communication system 1 is configured to support one or more handover enhancements - in particular for LTM handovers - that enable the handovers to be made pre-emptively i.e., before a radio link failure (RLF), or service disruption, or the like occurs. Specifically, the communication system 1 is beneficially configured to make use of AI / ML models to provide enhanced 'predictive' mobility procedures based on predictions (e.g., of measurements, mobility, and / or handover decisions). Such predictive procedures have the prospect of providing a number of different benefits including a reduction in handover related issues.

[0134] Specifically, the communication system 1 is beneficially configured to support a UE-sided AI / ML model for making LTM handover related inferences and associated predictions. To facilitate this, the communication system 1 includes one or more enhancements for supporting: configuration of an AI / ML model at a UE 3 for making appropriate LTM handover based inferences; for configuring the predictions to be made by the UE 3 based on the UE sided LTM handover based inferences made using the AI / ML model configured at the UE 3; and for reporting, by the UE 3, of the outcome of LTM handover based prediction based on the UE-sided AI / ML model inferences.

[0135] The communication system 1 is also beneficially configured to support a base station-sided AI / ML model for making LTM handover related inferences and associated predictions. To facilitate this, the communication system 1 includes one or more enhancements for supporting: configuration of measurements to be made by the UE 3 for input to an AI / ML model at a RAN node 5 for making appropriate LTM handover-based predictions; and for configuring how the UE 3 reports results of the measurements configuration for input to the AI / ML model at the RAN node 5 for making appropriate LTM handover-based predictions.

[0136] For example, the communication system 1 may support AI / ML model inferences to be generated by an AI / ML model implemented in the communication system 1 that may enable the UE 3 and / or the RAN nodes 5 to predict / determine when best to perform LTM handovers (and / or to which RAN node 5 the UE 3 should be handed over). Beneficially this can help to reduce signalling overheads, and the risk of 'ping-pong' handovers.

[0137] Moreover the communication system 1 may support an AI / ML model that makes spatial and temporal beam predictions. For example, temporal beam predictions within a serving cell (or a possible target cell) may be used to predict the best or top-K beams or beam pairs in the time domain in order to improve UE throughput. Furthermore, temporal beam predictions within a serving cell (or a possible target cell) to predict the best or top-K beams or beam pairs in the time domain may be generated based on measurements of a smaller (subset) of beams. For example, a small set of beams associated with the serving cell (or a possible target cell) may be measured, and those measurements may be used as an input to an AI / ML model to predict the best or top-K beams or beam pairs in the time domain of a larger set of beams associated with the serving cell (or a possible target cell). This in turn may beneficially reduce the amount of reference signal (RS) signalling that needs to be carried out, as well as reducing the measurement effort of, and power consumption levels at, the UE 3. Based on the predicted best or top-K beams or beam pairs in the time domain generated by the AI / ML model, the communication system 1 may thus, beneficially, be able to determine a best target cell of a set of LTM candidate cells to which the UE 3 should be handed over.

[0138] Additionally (or alternatively), the communication system 1 may be adapted to incorporate an AI / ML model that may be able to make direct LTM-HO predictions (e.g., directly inferred predictions of a best target cell of a set of LTM candidate cells to which the UE 3 should be handed over) using historical LTM-HO information / parameters (e.g., historical LTM-HO target cells, CSI reference signal resource indicator (CRI), or SSB beam index information, as indicated in an SSB, and transmission configuration indicator (TCI) state information) that may be collected and input to the AI / ML model.

[0139] A number of enhanced procedures and techniques for implementing AI / ML models in the communication system 1 to make LTM handover (LTM-HO) predictions, and to trigger suitable mobility procedures based on those predictions will now be described, by way of example only, with reference to Figs. 6 to 11.

[0140] < Implementation of an AI / ML LTM-HO Prediction Model > 　　< Configuring and using an AI / ML LTM-HO prediction model - Model located at UE > 　　Fig. 6 illustrates a simplified sequence diagram of an example procedure for configuring and using an AI / ML model for LTM-HO prediction stored at a UE 3 in the communication system 1 illustrated in Fig. 1.

[0141] As shown in Fig. 6, there is provided a UE 3 that has an RRC connection with a serving RAN node 5S(e.g., operating as a source RAN node 5S) allowing the UE 3 to receive from, and transmit to, the serving RAN node 5S. The serving RAN node 5Smay provide a first cell for the UE 3 to communicate over with the serving RAN node 5S. Furthermore, the serving RAN node 5Smay support a specific first radio access technology (RAT) e.g., NR, E-UTRAN, LTE, or the like (or a plurality of different RATs).

[0142] At step S602 the UE 3 reports, in an appropriate message (e.g., a UE capability message, or the like), its capability to generate AI / ML inferences / predictions using an AI / ML model located at the UE 3. For example, the message sent to the serving RAN node 5Sat step S602 may include an appropriate indication of the functionality of the UE 3, including its functionality to support the generation of LTM-HO predictions using an AI / ML model located at the UE 3.

[0143] The message sent at step S602 may also include other appropriate information corresponding to the AI / ML model (or models) stored at the UE 3 and which will be used by the UE 3 to generate LTM-HO predictions. Examples of the other appropriate information corresponding to the AI / ML model (or models) that may be included in the message sent to the serving RAN node 5Sat step S602 are summarised below.

[0144] For example, the message sent at step S602 may include a respective identity (e.g., ID) of each AI / ML model stored at the UE 3 that can generate LTM-HO predictions.

[0145] Additionally (or alternatively), the message sent at step S602 may, by way of example, include appropriate information to indicate characteristics of the LTM-HO predictions that can be made using the AI / ML model. For example, the message may include an appropriate indication of how the AI / ML model will generate LTM-HO predictions, and upon what basis those LTM-HO predictions will be made.

[0146] In one example, the message may include, for each UE-sided AI / ML model, an indication that the LTM-HO prediction made using the AI / ML model is based on predicted L1 measurements (e.g., RSRP values of SSBs and / or CSI-RS measurements, or the like) associated with beams of one or more candidate cells. For example, the message may include, for each UE-sided AI / ML model, a respective indication that the LTM-HO predictions are based on 'spatial-domain' based L1 measurement predictions or 'time-domain' based L1 measurement predictions for downlink transmitter beams. For example, the message may include, for one or more UE-sided AI / ML models, an indication that the LTM-HO predictions are based on spatial-domain based L1 measurement predictions in a first set of beams (Set A) based on measurement results of second set of beams (Set B) that provide different spatial coverage to the beams of set A (this may be referred to as beam management (BM) Case1 - 'BM-Case1'). Similarly, the message may include, for one or more UE-sided AI / ML models, an indication that the LTM-HO predictions are based on time-domain based L1 measurement predictions for downlink transmitter beams in a first set of beams (Set A) based on historic measurement results of a second set of beams (Set B) that are temporally separated from the beams of set A (this may be referred to as beam management (BM) Case1 - 'BM-Case2').

[0147] In another example, the message may include, for one or more AI / ML models, an indication that the AI / ML model can perform LTM-HO predictions based on historic LTM-HO events. For example, the message may indicate that, for each AI / ML model, the AI / ML model can perform LTM-HO predictions based historic LTM-HO events that have occurred in the past in the communication system 1. Those historic LTM-HO events may be, by way of example only, historic LTM-HO events associated with one or more candidate cells to which the UE 3 could be handed over.

[0148] It will be appreciated that where the AI / ML model performs LTM-HO predictions based on historic LTM-HO events, the AI / ML model may make LTM-HO predictions pertaining to a specific cell for which it has historic LTM-HO event information for an LTM-HO that occurred under similar circumstances, for example that shares the same or similar 'reference' configuration (e.g., the historic LTM-HO events and the LTM-HO predictions are associated with a cell 9 in a same location, and / or the same UE speed / trajectory).

[0149] Beneficially, the UE capability message sent at S602 to the serving RAN node 5Sassists the serving RAN node 5Sto send appropriate configuration messages to the UE 3 to configure the UE 3 and / or the AI / ML model (or models) stored at the UE 3. For example, the UE capability message sent at S602 enables the serving RAN node 5Sto send appropriate configuration messages to the UE 3 to: 　　- Activate one or more AI / ML models at the UE 3 for performing LTM-HO predictions; 　　- Configure the AI / ML model at the UE 3 for performing LTM-HO predictions; 　　- Configure the types of inputs that can be used with those AI / ML models; and 　　- Indicate the types of outputs that the serving RAN node 5S(and thus the network) expect the AI / ML model to generate.

[0150] At step S604, the serving RAN node 5Ssends an appropriate configuration message (e.g., AI / ML model Configuration for LTM-HO Predictions, or the like) to the UE 3 to configure the UE 3 and / or the AI / ML model (or models) stored at the UE 3.

[0151] For example, based on the UE capability report sent to the serving RAN node 5Sat step S602, the serving RAN node 5Smay send the configuration message to the UE 3 at step S604 to activate an AI / ML model (or models) stored at the UE 3. By way of example, the configuration message may include an appropriate indication or trigger to activate a specific AI / ML model (or models) stored at the UE 3 such as an identity (ID) of a specific AI / ML model (or models) stored at the UE 3 - i.e., to trigger the UE 3 to use the specific AI / ML model (or models) identified in the configuration message for making LTM-HO predictions.

[0152] The configuration message sent at step S604 may also include a list of candidate cells (or a list of a subset of candidate cells), to which the UE 3 may be handed over in the future, for which the activated AI / ML model is to be used for making LTM-HO based inferences / predictions.

[0153] It will be appreciated that the serving RAN node 5Smay select a suitable AI / ML model ID based on UE measurements of one or more neighbouring candidate cells' RS transmissions, and that the selected AI / ML model need not be supported by another (e.g., HO target) RAN node 5 that provides a target cell, albeit that a unified AI / ML model may be beneficial (especially in the context of beam management).

[0154] Additionally, the configuration message sent to the UE 3 at step S604 may configure the type of inputs that the UE 3 may use with that AI / ML model (or models) for generating LTM-HO related inferences / predictions, and / or the type of outputs (inferences) that the UE 3 may generate using that AI / ML model (or models) for purposes of LTM-HO prediction.

[0155] For example, the configuration message sent at step S604 may include an appropriate beam measurement configuration for each of the one or more candidate cells. By way of example, for BM-case 1 (mentioned above), the beam measurement configuration may comprise a appropriate a single common resource configuration ID (e.g., a CSI resource configuration ID, or the like) may be assigned to both the first set of beams (Set A) and the second set of beams (set B) to link the different sets of beams for the purposes of LTM-HO related inference / prediction (e.g., a CSI-ResourceConfigID IE may be used to link the beams of Set A to those of Set B within a CSI-ResourceConfig IE).

[0156] The configuration message may also include an appropriate measurement report configuration. For example, the configuration message sent at step S604 may include a measurement report configuration that configures the type of measurements (real 'measured' and / or predicted) that the UE 3 is to report for the purposes of LTM-HO prediction. For example, the measurement report configuration may include an information element for configuring the UE 3 to provide a dedicated 'predicted' measurement report comprising a predicted set of results for predicted measurements of CSI RSs for the purposes of LTM-HO prediction (e.g., a 'Predicted-LTM-CSI-ReportConfig' IE or the like). Nevertheless, the measurement report configuration may configure the UE 3 to provide a 'combined' measurement report comprising both real and predicted measurements for different respective resource sets, for example by indicating whether respective reported values for each resource set should be measured or predicted (e.g., by indicating if the reported value is 'measured' or 'predicted' for each corresponding LTM-CSI-SSB-ResourceSet IE in an LTM-CSI-ReportConfig IE).

[0157] The configuration message sent at step S604 may also configure one or more appropriate observation windows for which real measurements are to be reported for the purposes of LTM-HO prediction. For example, the configuration message may configure an observation window (e.g., a timing window) comprising one, or a multiple number of observation windows configured for performing L1 measurements (e.g., real L1 RSRP values of SSBs and / or CSI-RS), or the like, which may form part of the input fed to the AI / ML model for each LTM-HO prediction.

[0158] The configuration message sent at S604 may also configure the UE 3 with one or more LTM-HO prediction windows for which predicted measurements are to be reported - each LTM-HO prediction window may, for example, follow a corresponding observation window configured by the configuration message. Each LTM-HO prediction window may define a time frame for which the UE 3 can make LTM-HO predictions (e.g., following a specific observation window).

[0159] Furthermore, in the case of UE-sided AI / ML model inferences / prediction based on L1 measurements for the assisting LTM-HO prediction the configuration message may also include a variety of different measurement parameters for configuring one or more AI / ML model outputs for supporting the LTM-HO prediction. For example, where the output from the AI / ML model comprises beam measurement results for the serving RAN node 5Sto determine an LTM-HO target cell, the measurement parameters included in the configuration message may configure the UE 3 to report: 　　- Measured (e.g., real) L1 quantities (e.g., L1-RSRPs) and corresponding SSBRI / CRI / beam index associated with the M largest L1 measurement values for each candidate cell, L, of one or more candidate cells (where M is configured by the serving RAN node 5S); 　　Predicted Top-K L1 measurements (e.g., the highest K L1-RSRPs) and corresponding SSBRI / CRI / beam index for each candidate cell; 　　The measurement parameters included in the configuration message may configure one or more conditions that the above measurements values have to meet to be reported, for example: 　　- Whether only values within an X dB gap to the largest L1 measurement value (e.g., L1-RSRP value) are reported, up to K beams and N cells; and / or 　　- Whether only values above a L1 measurement (e.g., L1-RSRP) value threshold are reported.

[0160] It will be appreciated that the parameters L, M, N, K, X, and L1 measurement value threshold are configurable by the serving RAN node 5S.

[0161] It will be appreciated that the UE-sided AI / ML model may be used to predict the occurrence of LTM measurement events. Where a UE-sided AI / ML model is used to make such a LTM measurement event prediction, the prediction may be made together with a prediction of the beam measurements. Alternatively, the LTM measurement event prediction may be performed independently, in which case the serving RAN node 5Smay determine an LTM handover target cell based only on the prediction of the occurrence of one or more particular LTM measurement events. For both cases, the LTM measurement event configuration may be configured by the configuration message sent by the serving RAN node 5Sin step S604. To this end the configuration message may include one or more threshold values that define when the conditions for triggering the LTM event have been fulfilled.

[0162] In the case of UE-sided AI / ML model inferences / prediction based on historic LTM-HO events, the measurement parameters included in the configuration message may configure the UE 3 to report: 　　- An N number of top candidate cells associated with the historic LTM-HO events and their corresponding TCI state, where N may be equal to one; and 　　- An N number of top predicted candidate cells to which the UE 3 may be handed over and their corresponding TCI state, where N may be equal to one in which case the top predicted candidate cell may, in effect, be the determined target cell.

[0163] At step S606 the UE 3 and serving RAN node 5Smay engage in an appropriate handover preparation procedure where necessary (e.g., similar to steps S302 to S310 of Fig. 3). For example, the serving RAN node 5Smay provide the UE 3 with an LTM measurement configuration (e.g., similar to that described with reference to Fig. 3, S310). The LTM measurement configuration may, for example, comprise an LTM measurement event configuration, or the like, associated with each possible LTM measurement event that may occur (e.g., LTM measurement events that the AI / ML model may be able to make inference / predictions about). The following LTM measurement events may be configured within the LTM measurement event configuration for the serving cell (or a special cell where the serving cell is a special cell (SpCell)): 　　- Event LTM1: Beam of the serving cell becomes better than absolute threshold; 　　- Event LTM2: Beam of the serving cell becomes worse than absolute threshold; 　　- Event LTM3: Beam of the candidate cell becomes amount of offset better than beam of the serving cell; 　　- Event LTM4: Beam of the candidate cell becomes better than absolute threshold; 　　- Event LTM5: Beam of the serving cell becomes worse than absolute threshold1 AND Beam of the candidate cell becomes better than another absolute threshold2.

[0164] By way of example only, a beam (or beams) of the serving cell provided by the serving RAN node 5Sand a neighbouring cell (e.g., a candidate cell) provided by another RAN node 5 may be used for the purposes of determining the occurrence of any of the above LTM measurement events. It will be appreciated that the one or more beams used determine the occurrence of any of the above LTM measurement events, those beams may be the best (or top N) beams of the respective cells.

[0165] It will be appreciated that the configuration of the LTM measurement events may be applicable to both measured and predicted beams. For example, beams that are used to determine the occurrence of any of the above LTM measurement events may be measured beams, or beams for which measurement inferences / predictions are made.

[0166] At step S608, the serving RAN node 5Smay send an activation message, or the like, to the UE 3 to activate one or more AI / ML models at the UE 3 for performing LTM-HO predictions. It will be appreciated that such an activation message may only be sent if an appropriate activation has not already been sent to the UE 3 in the configuration message sent to the UE 3 at step S604. The activation message sent at step S608 may, for example, include an ID of an AI / ML model (or models) that the UE 3 is to use for making LTM-HO predictions. Additionally, that activation message may include a list of candidate cells (or a list of a subset of candidate cells), to which the UE 3 may be handed over in the future, for which the activated AI / ML model is to be used for making LTM-HO based inferences / predictions.

[0167] At step S610, the activated AI / ML model (or models) may generate a model inference / prediction based on inputs to the AI / ML model (or models). For example, where the AI / ML model inputs comprise real (e.g., live, or historic) L1 measurements of beams associated with one or more candidate cells, the AI / ML model (or models) may generate a model inference comprising predicted L1 measurements associated with the one or more candidate cells.

[0168] Alternatively, where the AI / ML model inputs comprise real (e.g., historic) LTM-HO events associated with one or more candidate cells, the AI / ML model (or models) may generate a model inference comprising an indication of a top N number of candidate cells that may be used by the UE 3 for handover.

[0169] At step S612, the UE 3 reports its AI / ML-generated model inferences to the serving RAN node 5Sin an appropriate reporting message (e.g., UE report of AI / ML prediction, or the like). For example, the UE 3 may report predicted L1 beam measurement results, an LTM-HO target cell prediction, and / or a predicted fulfilment of a certain LTM measurement event. It will be appreciated that at step S612 the UE 3 may report its AI / ML-generated model inferences to the serving RAN node 5Sin an appropriate reporting message via uplink control information (UCI), in a PUSCH, in a periodic manner or event triggered manner.

[0170] In more detail, where the AI / ML model inputs comprise real (e.g., live, or historic) L1 measurements of beams associated with one or more candidate cells, the UE report to the serving RAN node 5Smay include, by way of example only: 　　- The real (e.g., live, or historic) measured L1 measurements and corresponding SSBRI / CRI / beam index associated with the M largest L1 measurement values (M is configured by the serving RAN node 5S); and / or 　　- The predicted Top-K L1 measurements and corresponding SSBRI / CRI / beam index for each candidate cell.

[0171] When the corresponding condition is configured, the UE report may include only values within an X dB gap to the largest L1 measurement value, up to K beams and N cells L.

[0172] Similarly, when the corresponding condition is configured, the UE report may include only values above an L1 measurement value threshold.

[0173] Alternatively, where the AI / ML model inputs comprise historic LTM-HO events, the UE report to the serving RAN node 5Smay include, by way of example only: 　　- An N number of top candidate cells associated with the historic LTM-HO events and their corresponding TCI state, where N may be equal to one; and 　　- An N number of top predicted candidate cells to which the UE 3 may wish to hand over and their corresponding TCI state where N may be equal to one (and the top predicted candidate cell is effectively the determined target cell).

[0174] In further detail, the appropriate reporting message sent to the serving RAN node 5Sat step S612 may also include, by way of example only, a cell indicator field to indicate a predicted LTM-HO target cell (i.e., one of the one or more candidate cells). The reporting message may also include an indication of the corresponding measured / predicted L1 measurements (e.g., L1-RSRPs), SSBRI (or CRI), and TCI state ID values for one or more candidate target cells.

[0175] Additionally (or alternatively), in the case of BM-Case #1 for LTM-HO predictions, the appropriate reporting message sent to the serving RAN node 5Sat step S612 may include, by way of example only, for each L1 measurement value (e.g., L1 RSRP value) reported for top-K beams in the appropriate reporting message, an appropriate indication of whether the L1 measurement value reported is either a predicted L1 measurement value - for example where the corresponding beam is not configured for measurement by the UE 3 - or a (real) measured L1 measurement value - for example where the corresponding beam is configured for measurement by the UE 3.

[0176] It can been in summary therefore that the following information may be carried by the UE report for LTM-HO prediction in step S612: 　　- A cell indicator field for the predicted LTM-HO target cell; 　　- Indication of the corresponding measured / predicted L1-RSRP, SSBRI (or CRI) and TCI state ID values for the candidate target cell(s); 　　- If the UE report is based on the UE-sided model for BM-Case 1, for the RSRP of each reported Top K beam(s), indicating also if it is predicted L1-RSRP, if the beam is not configured for measurement; or measured L1-RSRP if the beam is configured for corresponding measurement; 　　- The number of reported beams for each candidate cell, if only values within X dB gap to the largest value of L1-RSRP are reported, up to K beams and N cells; 　　- The number of reported cells, if only candidate cells with L1-RSRP values above a threshold are reported; 　　- The predicted fulfilment of a certain LTM measurement event. The UE 3 may report the outcome of its prediction at each time instance when a UE report is triggered; or alternatively, the UE 3 only reports the prediction when there is a positive prediction on the occurrence of the LTM-HO event; 　　- The prediction time window for which the prediction is valid.

[0177] Additionally (or alternatively), the appropriate reporting message sent to the serving RAN node 5Sat step S612 may include, by way of example only, a number of reported beams for each candidate cell if only values within X dB gap to the largest L1 measurement value are reported, up to K beams and N cells.

[0178] Additionally (or alternatively), the appropriate reporting message sent to the serving RAN node 5Sat step S612 may include, by way of example only, a number of reported cells, if only candidate cells with L1 measurements values above a threshold are reported.

[0179] Additionally (or alternatively), the appropriate reporting message sent to the serving RAN node 5Sat step S612 may include, by way of example only, a predicted fulfilment of a certain LTM measurement event. For example, the UE 3 may report a predicted fulfilment of a certain LTM measurement event at each time instance when a UE report is triggered. Alternatively, the UE 3 may only report a predicted fulfilment of a certain LTM measurement event when there is a positive prediction in respect of the occurrence of a related LTM-HO event.

[0180] Additionally (or alternatively), the appropriate reporting message sent to the serving RAN node 5Sat step S612 may include, by way of example only, a prediction window within which the prediction indicated in the appropriate reporting message is valid.

[0181] Additionally (or alternatively), the appropriate reporting message sent to the serving RAN node 5Sat step S612 may include, by way of example only, appropriate confidence information to indicate to the serving RAN node 5Sa probability (e.g., accuracy indication, or the like) of the predicted L1 measurement and / or an LTM-HO target cell. For example, confidence information may be indicated to the serving RAN node 5Sby a quantised 2-bit that corresponds to a specific index as shown in Table 1 below:

[0182] Table 1: A table of an index that may be included in reporting message to indicate a probability (confidence information) associated with a predicted L1 measurement and / or an LTM-HO target cell

[0183] Additionally (or alternatively), the appropriate reporting message sent to the serving RAN node 5Sat step S612 may include, by way of example only, a number of contiguous time windows during which the predicted target cell is the best candidate cell for LTM-HO and within which handover conditions are highly likely to be met. The inclusion of such an indication may beneficially reduce the chances of 'ping-pong' handovers.

[0184] At step S614, the serving RAN node 5Smay send a cell switch command such as an LTM cell switch command (e.g., as a MAC CE for triggering a cell switch (or handover)) including a candidate configuration index corresponding to the target cell / second RAN node 5Tacting as a target RAN node 5T(e.g., a target cell indicator, or the like), and an indication of a TCI status of that target cell. The UE 3 then detaches (not shown) from the source cell of the first (source) RAN node 5Sand switches to the target cell of the second (target) RAN node 5Tby applying the corresponding LTM candidate configuration indicated by candidate configuration index.

[0185] At step S616, the UE 3 can then access the cell by performing an LTM handover e.g., by using a RACH-based or RACH-less procedure. The UE 3 may, for example, perform a random access procedure towards the target cell if the UE 3 does not have valid TA of the target cell. Nevertheless, the UE 3 may access the cell without performing a random access procedure where the UE 3 has a valid TA. The UE 3 can complete the LTM cell switch procedure by sending an appropriate message (e.g., an RRC reconfiguration complete message) to the second RAN node 5T. If the UE 3 has performed a random access procedure the UE 3 may consider that LTM cell switch execution has been successfully completed when the random access procedure has successfully completed. For RACH-less LTM, on the other hand, the UE 3 may consider that the LTM cell switch execution has successfully completed when the UE 3 determines that the second RAN node 5Thas successfully received its first uplink data.

[0186] As already alluded to above with reference to Fig. 6, an AI / ML model at the UE 3 which is selected by the serving RAN node 5Sfor LTM-HO inferences / predictions need not be supported by another (e.g., HO target) RAN node 5Tthat provides a target cell. However, it will nevertheless be appreciated that in certain circumstances the serving RAN node 5S(also referred to as a source RAN node 5S) and another (e.g., HO target) RAN node 5Tmay beneficially support a same UE-sided AI / ML model for LTM-HO inferences / predictions.

[0187] An example procedure for configuring and using a 'unified' AI / ML model for LTM-HO prediction stored at a UE 3 which is supported by both a serving RAN node 5Sand another RAN node 5T(e.g., a target RAN node 5T) will now be described with reference to Fig. 7.

[0188] Fig. 7 illustrates a simplified sequence diagram of another example procedure for configuring and using an AI / ML model for LTM-HO prediction stored at a UE 3 in the communication system 1 illustrated in Fig. 1.

[0189] As shown in Fig. 7, there is provided a UE 3 that has an RRC connection with a source cell 9-1 (provided for example by a serving RAN node 5Soperating as a source RAN node 5S) allowing the UE 3 to receive from, and transmit to, the serving RAN node 5S. Furthermore, the serving RAN node 5Smay support a specific first radio access technology (RAT) e.g., NR, E-UTRAN, LTE, or the like (or a plurality of different RATs).

[0190] It will be appreciated that step S701 of Fig. 7 corresponds with step S602 of Fig. 6 and thus the description above with reference to step S602 of Fig. 6 applies equally to step S701 of Fig. 7.

[0191] At step S702, the information provided to the source cell 9-1 at step S701 may be forwarded to a target cell 9-2. For example, the serving RAN node 5Sproviding the source cell 9-1 may forward to a target cell 9-2 provided by a target RAN node 5Tindications of the functionality of the UE 3 and / or a model ID of the AI / ML model (or models) that the UE 3 supports.

[0192] At step S703, the target RAN node 5Tmay provide the serving RAN node 5San indication of an ID of one or more A / ML models that are supported by the target RAN node 5Tand / or the functionalities of that target RAN node 5T. It will be appreciated that exchanging this type of information between the serving RAN node 5Sand the target RAN node 5Tmay be beneficial as beam prediction based AI / ML models are generally cell specific (depending on a cell antenna configuration), and hence the target cell 9-2 provided by the target RAN node 5Twill have the best knowledge on which AI / ML model will work best for beam measurement predictions for that target cell 9-2.

[0193] It will be appreciated that step S704 of Fig. 7 corresponds with step S604 of Fig. 6 and thus the description above with reference to steps S604 of Fig. 6 applies equally to step S704 of Fig. 7. However, unlike at step S604, it will be appreciated that at step S704 the configuration message sent to the UE 3 may, by way of example, include an appropriate indication or trigger to activate a specific AI / ML model (or models) stored at the UE 3 which is supported by both the serving RAN node 5Sand the target RAN node 5T.

[0194] It will be appreciated that steps S706 to S716 of Fig. 7 corresponds with steps S606 to S616 of Fig. 6 and thus the description above with reference to steps S606 to S616 of Fig. 6 applies equally to steps S706 to S716 of Fig. 7.

[0195] For completeness, it will also be appreciated that in the scenario where the source RAN node 5Sand the target RAN node 5Tof Fig. 7 are distributed RAN nodes 5-2, each with their own RAN node CU 5-2CUand corresponding RAN node DUs 5-2DU(e.g., source RAN node CU 5S-2CU, source RAN node DU 5S-2DU, target RAN node CU 5T-2CU, and target RAN node DU 5T-2DU), a variation of the procedure of Fig. 7 may be used that facilitates information exchange between different components of the distributed RAN nodes 5-2.

[0196] For example, in the case of a distributed RAN, at step S701, the UE 3 may send its UE capability report to the source RAN node CU 5S-2CUwhich may include a model ID of the AI / ML model (or models) that the UE 3 supports. The model ID of the AI / ML model (or models) that the UE 3 supports may then be subsequently forwarded, by the source RAN node CU 5S-2CUto the target RAN node CU 5T-2CU.

[0197] It will be appreciated that the target RAN node CU 5T-2CUmay be aware (have knowledge) of AI / ML model (or models) for LTM-HO prediction that are supported by one or more target RAN node DUs5T-2DUof the distributed target RAN node 5T-2. If not, the target RAN node CU 5T-2CUmay send an appropriate indication to the target RAN node DU5T-2DUto indicate all of the AI / ML models supported by the UE 3, and the target RAN node DU5T-2DUmay indicate, to the target RAN node CU 5T-2CU, which of those AI / ML models that are supported by the UE 3 the target RAN node DU5T-2DUalso supports.

[0198] The target RAN node CU 5T-2CUmay then indicate, to the source RAN node CU 5S-2CU, one or more AI / ML models that can be enabled at the UE 3 for LTM-HO prediction (i.e., the target RAN node CU 5T-2CUmay indicate one or more AI / ML models supported at the UE 3 that are also supported by the target (distributed) RAN node 5T-2). In response, the source RAN node CU 5S-2CUmay configure the UE 3 to use one (or more) of the indicated AI / ML model (or models) for LTM-HO inference / prediction (i.e., the source RAN node CU 5S-2CUmay configure the UE 3 with one or more AI / ML models that are supported by both the serving (distributed) RAN node 5S-2 and the target (distributed) RAN node 5T-2).

[0199] < Using an AI / ML LTM-HO prediction model - Model located at RAN Node > 　　Fig. 8 illustrates a simplified sequence diagram of an example procedure for configuring and using an AI / ML model for LTM-HO prediction stored at a RAN node 5 in the communication system illustrated in Fig. 1.

[0200] As shown in Fig. 8, there is provided a UE 3 that has an RRC connection with a source cell 9-1 (provided by example by a serving RAN node 5Soperating as a source RAN node 5S) allowing the UE 3 to receive from, and transmit to, the serving RAN node 5S. Furthermore, the serving RAN node 5Smay support a specific first radio access technology (RAT) e.g., NR, E-UTRAN, LTE, or the like (or a plurality of different RATs).

[0201] At step S802 an appropriate reconfiguration message (e.g., an RRC reconfiguration message, or the like), may be sent by a serving RAN node 5Sover a source cell 9-1 to the UE 3. For example, in the case of RAN node-sided AI / ML model inferences / prediction using L1 measurements made by the UE 3, the reconfiguration message may (re)configure the UE 3 with L1 measurement parameters that may be used by the UE 3 to make L1 measurements which may subsequently be reported to the serving RAN node 5Sfor input into the AI / ML model (or models) stored at the serving RAN node 5S.

[0202] Additionally (or alternatively), the reconfiguration message sent at step S802 may configure the UE 3 with a list of candidate cell that the UE 3 should perform L1 measurements for, and to which the UE 3 may handover.

[0203] Additionally (or alternatively), the reconfiguration message sent at step S802 may include a beam measurement configuration, or the like, for each candidate cell indicated to the UE 3 in the configuration message. For example, the reconfiguration message may provide a beam measurement configuration that indicates, for each candidate cell, the beams on which L1 measurements should be made by the UE 3.

[0204] Additionally (or alternatively), the reconfiguration message sent at step S802 may include a measurement report configuration (e.g., an LTM-CSI-ReportConfig IE, or the like). For example, the configuration message may include a measurement report configuration that configures the type of measurements (e.g., real measurements) that the UE 3 is to report for the purposes of LTM-HO prediction. For example, the measurement report configuration may include an information element for configuring the UE 3 to provide real measurements for different respective resource sets.

[0205] Additionally (or alternatively), the reconfiguration message sent at step S802 may configure observation windows that are supported by the AI / ML model. For example, the configuration message may configure one or more observation window (e.g., a timing window) configured for the UE 3 to perform L1 measurements (e.g., real L1 RSRP values of SSBs and / or CSI-RS), or the like, which may form part of the input fed to the AI / ML model for each LTM-HO prediction.

[0206] Additionally, the reconfiguration message sent at S802 may configure the UE 3 with one or more LTM-HO prediction windows, each LTM-HO prediction window, for example, following a corresponding observation window configured by the configuration message. Each LTM-HO prediction window may define a time frame in which the UE 3 does not need to perform L1 measurements or L1 measurement reporting. It will be appreciated that the observation windows and prediction windows configured at the UE 3 thus define the time frame within which the UE 3 should perform L1 measurements and report those L1 measurements.

[0207] At step S804, the UE 3 may send an appropriate response message to the serving RAN node 5Sover the serving cell 9-1 to confirm / acknowledge receipt of the configuration message sent at step S802.

[0208] At step S806, the UE 3 may optionally report to the serving RAN node 5S, real (e.g., live) L1 measurement results that the UE 3 have made during an observation window configured at the UE 3 by the configuration message sent at step S802. For example, the UE 3 may report, in a reporting message, sent to the serving RAN node 5SL1 measurements (e.g., L1-RSRPs, or the like) and a corresponding SSBRI / CRI / beam index associated with the M largest measured values for each candidate cell, wherein M and a quantisation of reported L1-RSRP values may be configured by the serving RAN node 5S.

[0209] It will be appreciated that the L1 measurement results may be reported by the UE 3 in the reporting message sent to the serving RAN node 5Svia a L1 PUCCH or PUSCH during a configured observation window.

[0210] It will also be appreciated that the L1 measurement results may be reported by the UE 3 reporting message sent to the serving RAN node 5Sat step S806 in accordance with either event triggered LTM measurement reporting, or periodic LTM measurement reporting.

[0211] The UE 3 thus may report the measurement results (when in observation window as configured by the network) for AI / ML model input to RAN node sided model for LTM-HO prediction via L1 PUCCH / PUSCH: 　　- Measured L1-RSRPs and corresponding SSBRI / CRI / beam index with largest M measured value(s) for each candidate cell L, where M and the quantisation of reported L1-RSRP values may be configured by the RAN node 5S.

[0212] The UE 3 may perform measurements and report measurement values or measurement events during the observation window. The UE 3 does not need to perform measurements for the duration of each prediction window.

[0213] At step S808, the AI / ML model (or models) at the serving RAN node 5Smay generate a model inference / prediction based on inputs to the AI / ML model (or models). For example, where the AI / ML model inputs comprise real L1 measurements of beams associated with one or more candidate cells indicated to the UE 3, the AI / ML model (or models) may generate a model inference / prediction comprising predicted L1 measurements associated with the one or more candidate cells, and / or e.g., a best or top-K beams or beam pairs in the time domain of a set of beams associated with the one or more candidate cells.

[0214] It will be appreciated that steps S810 to S812 of Fig. 8 corresponds with steps S614 to S616 of Fig. 6 and thus the description above with reference to steps S614 to S616 of Fig. 6 applies equally to steps S810 to S812 of Fig. 8.

[0215] < Using an AI / ML LTM-HO prediction model - Model located at RAN Node with inter-cell coordination > 　　Fig. 9 illustrates a simplified sequence diagram of an example procedure for configuring and using an AI / ML model for LTM-HO prediction stored at a serving RAN node 5Sin the communication system 1 illustrated in Fig. 1 with inter-cell coordination.

[0216] As shown in Fig. 9, there is provided a UE 3 that has an RRC connection with a source cell 9-1 (provided by the serving RAN node 5Soperating as a source RAN node 5S) allowing the UE 3 to receive from, and transmit to, the serving RAN node 5S, and a target cell 9-2 (provided by a target RAN node 5T) to which the UE 3 may be handed over. Furthermore, the serving RAN node 5Sand the target RAN node 5Tmay support a specific first radio access technology (RAT) e.g., NR, E-UTRAN, LTE, or the like (or a plurality of different RATs).

[0217] At step S902, LTM handover history information (e.g., information pertaining to historic LTM handover events) associated with the UE 3 and neighbour cells provided by neighbouring RAN nodes 5 (e.g., target RAN node 5T) may be collected by the serving RAN node 5S. Once collected, that LTM handover history information may be stored at the serving RAN node 5Sfor use as input to an AI / ML model (or models) stored at the serving RAN node 5Sfor LTM-HO prediction.

[0218] At step S904, signalling coordination may occur between the serving RAN node 5Sand neighbouring RAN nodes 5 (e.g., target RAN node 5T) over an appropriate interface prior to the serving RAN node 5Ssending an appropriate reconfiguration message to the UE 3.

[0219] The appropriate reconfiguration message sent to the UE 3 by the serving RAN node 5Sat step S904 may, for example, configure the UE 3 with a list of candidate cell that the UE 3 should perform L1 measurements for, and to which the UE 3 may handover.

[0220] Additionally (or alternatively), the reconfiguration message sent to the UE 3 by the serving RAN node 5Sat step S904 may include a beam measurement configuration, or the like, for each candidate cell indicated to the UE 3 in the configuration message. For example, the reconfiguration message may provide a beam measurement configuration that indicates, for each candidate cell, the beams on which L1 measurements should be made by the UE 3.

[0221] Additionally (or alternatively), the reconfiguration message sent at step S904 may include a measurement report configuration (e.g., an LTM-CSI-ReportConfig IE, or the like). For example, the configuration message may include a measurement report configuration that configures the type of measurements (e.g., real measurements) that the UE 3 is to report for the purposes of LTM-HO prediction. For example, the measurement report configuration may include an information element for configuring the UE 3 to provide real measurements for different respective resource sets.

[0222] It will be appreciated that step S906 of Fig. 9 corresponds with step S808 of Fig. 8 and thus the description above with reference to step S808 of Fig. 8 applies equally to step S906 of Fig. 9.

[0223] It will also be appreciated that steps S908 to S910 of Fig. 9 corresponds with steps S614 to S616 of Fig. 6 and thus the description above with reference to steps S614 to S616 of Fig. 6 applies equally to steps S908 to S910 of Fig. 9.

[0224] < AI / ML LTM-HO prediction model in a Distributed RAN node > 　　Fig. 10 illustrates a simplified sequence diagram of an example procedure for configuring and using an AI / ML model for LTM-HO prediction stored at a serving RAN node 5Sthat is distributed (i.e., it comprises a serving RAN node CU 5S-2CUand one or more serving RAN node DUs 5S-2DU) in the communication system 1 illustrated in Fig. 1.

[0225] As shown in Fig. 10, there is provided a UE 3 that has an RRC connection with a serving RAN node DU 5S-2DUallowing the UE 3 to receive from, and transmit to, the serving RAN node DU 5S-2DU. Furthermore, the serving RAN node DU 5S-2DUmay support a specific first radio access technology (RAT) e.g., NR, E-UTRAN, LTE, or the like (or a plurality of different RATs). The serving RAN node DU 5S-2DUis connected to the serving RAN node CU 5S-2CUover an appropriate interface (e.g., connected by an F1 interface).

[0226] In case of the CU-DU split RAN architecture shown in Fig. 10, the AI / ML model may be located at the serving RAN node DU 5S-2DUfor LTM-HO prediction / inference. It will be appreciated that in this scenario, the LTM-HO predictions / inferences may be generated in a manner similar to that described above with respect to Fig 8, albeit that the serving RAN node 5Sis distributed. Accordingly, it will be appreciated that as the serving RAN node 5Shas a CU-DU split RAN architecture, appropriate CU-DU coordination procedures may need to be implemented. An example of such a CU-DU coordination procedure that may be implemented is shown in Fig. 10.

[0227] At step S1002, the serving RAN node CU 5S-2CUmay configure a list of LTM candidate cells to the UE 3 to which the UE 3 may be handed over. Having being configured with that list of LTM candidate cells, the UE 3 may perform appropriate L1 measurements associated with one or more beams of those LTM candidate cells in a manner similar to that already described above with respect to the procedure of Fig 8 (see e.g., step S802).

[0228] At step S1004, having made those appropriate L1 measurements, the UE 3 may send those measurements to the serving RAN node DU 5S-2DUvia an appropriate L1 measurement report, or the like, in a manner similar to that already described above with respect to the procedure of Fig 8 (see e.g., step S806).

[0229] At step S1006, the serving RAN node DU 5S-2DUmay input those L1 measurements into the AI / ML model (or models) stored at the serving RAN node DU 5S-2DUfor AI / ML LTM-HO prediction / inference, which may, for example, include indications of a predicted target cell and / or a predicted target beam, and / or the like, in a manner similar to that already described above with respect to the procedure of Fig 8 (see e.g., step S808).

[0230] At step S1008, the serving RAN node DU 5S-2DUmay notify the serving RAN node CU 5S-2CUof the LTM-HO prediction / inference generated by the AI / ML model (or models) at the serving RAN node DU 5S-2DU.The serving RAN node DU 5S-2DUmay notify the serving RAN node CU 5S-2CUof the LTM-HO prediction / inference in an appropriate message which may, for example, also include a probability of the prediction and a predicted time window for which LTM-HO prediction remains valid.

[0231] At step S1008, the serving RAN node DU 5S-2DUmay send an appropriate LTM cell switch command to the UE 3 in a manner similar to that already described above with respect to the procedure of Fig 8 (see e.g., step S810).

[0232] Fig. 11 illustrates a simplified sequence diagram of another example procedure for configuring and using an AI / ML model for LTM-HO prediction stored at a serving RAN node 5Sthat is distributed (i.e., it comprises a serving RAN node CU 5S-2CUand one or more serving RAN node DUs 5S-2DU) in the communication system 1 illustrated in Fig. 1.

[0233] As shown in Fig. 11, there is provided a UE 3 that has an RRC connection with a serving RAN node DU 5S-2DUallowing the UE 3 to receive from, and transmit to, the serving RAN node DU 5S-2DU. Furthermore, the serving RAN node DU 5S-2DUmay support a specific first radio access technology (RAT) e.g., NR, E-UTRAN, LTE, or the like (or a plurality of different RATs). The serving RAN node DU 5S-2DUis connected to the serving RAN node CU 5S-2CUover an appropriate interface (e.g., connected by an F1 interface).

[0234] In case of the CU-DU split RAN architecture shown in Fig. 11, the AI / ML model may be located at the serving RAN node DU 5S-2DUfor LTM-HO predictions / inferences. It will be appreciated that in this scenario, the LTM-HO predictions / inferences may be generated in a manner similar to that described above with respect to Fig. 8. However, it will nevertheless be appreciated that as the serving RAN node 5Shas a CU-DU split RAN architecture, an appropriate CU-DU coordination procedure may need to be implemented. An example of such a CU-DU coordination procedure that may be implemented is shown in Fig. 11.

[0235] At step S1102 the UE 3 may send an appropriate L1 measurement report to the serving RAN node DU 5S-2DUincluding L1 measurements made by the UE 3. Additionally, the L1 measurement report may include other appropriate information e.g., UE trajectory information, UE speed information, and the like.

[0236] At step S1104 the serving RAN node DU 5S-2DU, which hosts the AI / ML model (or models), may use that L1 measurements, UE trajectory information, UE speed information, and the like, provided by the UE 3 as an input to the AI / ML model (or models) for generating beam / cell predictions, L1 measurement predictions, or the like, in a manner similar to that already described above with respect to the procedure of Fig 8 (e.g., step S808).

[0237] At step S1106, the serving RAN node 5S-2DUmay forward its AI / ML model generated predictions / inferences to the serving RAN node CU 5S-2CU. Optionally, the serving RAN node DU 5S-2DUmay also send, to the serving RAN node CU 5S-2CU, probability information pertaining to the AI / ML model generated predictions / inferences and a predicted time window within which the AI / ML model generated predictions are remain valid.

[0238] At step S1108, the serving RAN node CU 5S-2CUmay send an appropriate configuration message (e.g., an LTM candidate configuration, or the like) to the UE 3 to configure candidate cells at the UE 3 to which the UE 3 may perform a handover. Those candidate cells configured at the UE 3 correspond to the candidate cells associated with the beams / cells for which predictions / inferences were made at step S1104.

[0239] At step S1110, the UE 3 performs L1 measurements on the configured candidate cells and sends those L1 measurements to the serving RAN node DU 5S-2DUin an appropriate reporting message in a manner similar to that already described above with respect to the procedure of Fig. 8 (see e.g., step S806).

[0240] At step S1112, based on the L1 measurements made by the UE 3, and L1 measurement predictions / inferences generated by the serving RAN node DU 5S-2DU, the serving RAN node DU 5S-2DUmay make an LTM decision as to whether to handover the UE 3 to a particular one of the candidate cells indicated to the UE 3 at step S1108.

[0241] At step S1114, the serving RAN node DU 5S-2DUmay send an appropriate LTM cell switch command to the UE 3 in a manner similar to that already described above with respect to the procedure of Fig 8 (see e.g., step S810).

[0242] < Devices of the Communication System > 　　< User Equipment > 　　Fig. 12 is a schematic block diagram illustrating the main components of a UE 3 as shown in Fig. 1.

[0243] As shown, the UE 3 has a transceiver circuit 31 that is operable to transmit signals to and to receive signals from a RAN node 5 via one or more antennas 33 (e.g., comprising one or more antenna elements). The UE 3 has a controller 37 to control the operation of the UE 3. The controller 37 is associated with a memory 39 and is coupled to the transceiver circuit 31. Although not necessarily required for its operation, the UE 3 might, of course, have all the usual functionality of a conventional UE (e.g., a user interface 35, such as a touch screen / keypad / microphone / speaker and / or the like for, allowing direct control by and interaction with a user) and this may be provided by any one or any combination of hardware, software, and firmware, as appropriate. Software may be pre-installed in the memory 39 and / or may be downloaded via the communication system 1 or from a removable data storage device (RMD), for example.

[0244] The controller 37 is configured to control overall operation of the UE 3 by, in this example, program instructions or software instructions stored within memory 39. As shown, these software instructions include, among other things, an operating system 41, and a communications control module 43.

[0245] The communication control module 43 is operable to control the communication between the UE 3 and its serving RAN node or RAN nodes 5 (and other communication devices connected to the RAN node 5, such as further UEs and / or core network nodes). The communication control module 43 is configured for the overall handling of uplink communications via associated uplink channels (e.g., via a physical uplink control channel (PUCCH), random access channel (RACH), and / or a physical uplink shared channel (PUSCH)) including both dynamic and semi-static signalling (e.g., SRS). The communication control module 43 is also configured for the overall handling of receipt of downlink communications via associated downlink channels (e.g., of DCI via a physical downlink control channel (PDCCH) and / or a physical downlink shared channel (PDSCH)) including both dynamic and semi-persistent scheduling (e.g., SPS). The communication control module 43 is responsible, for example: for determining where to monitor for downlink control information; for determining the resources to be used by the UE 3 for transmission / reception of UL / DL communications (including interleaved resources and resources subject to frequency hopping); for managing frequency hopping at the UE side; for determining how slots / symbols are configured (e.g., for UL, DL or full duplex communication, or the like); for determining which bandwidth parts are configured for the UE 3; for determining how uplink transmissions should be encoded and the like.

[0246] It will be appreciated that the communication control module 43 may include a number of sub-modules ('layers' or 'entities') to support specific functionalities. For example, the communication control module 43 may include a PHY sub-module, a MAC sub-module, an RLC sub-module, a PDCP sub-module, an RRC sub-module, etc.

[0247] The communication control module 43 is configured, in particular, to control the UE's communications, where applicable, in accordance with any of the methods described herein.

[0248] < RAN node (non-distributed) > 　　Fig. 13 is a schematic block diagram illustrating the main components of a RAN node 5-1 for the communication system 1 shown in Fig. 1. As shown, the RAN node 5-1 has a transceiver circuit 51 for transmitting signals to and for receiving signals from the communication devices (such as UEs 3) via one or more antennas 53 (e.g., a single or multi-panel antenna array / massive antenna), and a core network interface 55 (e.g., comprising the N2, N3 and other reference points / interfaces) for transmitting signals to and for receiving signals from network nodes in the core network 7. Although not shown, the RAN node 5-1 may also be coupled to other RAN nodes 5 via an appropriate interface (e.g., the so-called 'Xn' interface in NR). The RAN node 5-1 has a controller 57 to control the operation of the RAN node 5-1. The controller 57 is associated with a memory 59. Software may be pre-installed in the memory 59 and / or may be downloaded via the communication system 1 or from a removable data storage device (RMD), for example. The controller 57 is configured to control the overall operation of the RAN node 5-1 by, in this example, program instructions or software instructions stored within memory 59.

[0249] As shown, these software instructions include, among other things, an operating system 61, and a communications control module 63.

[0250] The communications control module 63 is operable to control the communication between the RAN node 5-1 and UEs 3 and other network entities that are connected to the RAN node 5-1. The communications control module 63 is configured for the overall control of the reception and decoding of uplink communications, via associated uplink channels (e.g., via a physical uplink control channel (PUCCH), a random access channel (RACH), and / or a physical uplink shared channel (PUSCH)) including both dynamic and semi-static signalling (e.g., SRS). The communications control module 63 is also configured for the overall handling the transmission of downlink communications via associated downlink channels (e.g., via a physical downlink control channel (PDCCH) and / or a physical downlink shared channel (PDSCH)) including both dynamic and semi-static signalling (e.g., CSI-RS, SSBs etc.). The communications control module 63 is also responsible, for example, for determining and scheduling the resources to be used by the UE 3 for receiving in DL / transmitting in UL, for configuring slots / symbols appropriately (e.g., for UL, DL, flexible, full duplex communication, or the like), for configuring one or more bandwidth parts for the UE 3, and for providing related configuration signalling to the UE 3.

[0251] It will be appreciated that the communications control module 63 may include a number of sub-modules (or 'layers') to support specific functionalities. For example, the communications control module 63 may include a PHY sub-module, a MAC sub-module, an RLC sub-module, a PDCP sub-module, an SDAP sub-module, an IP sub-module, an RRC sub-module, etc.

[0252] The communication control module 63 is configured, in particular, to control the RAN node's communications, where applicable, in accordance with any of the methods described herein.

[0253] < RAN node (distributed) > 　　Fig. 14 is a simplified block schematic illustrating the main components of a distributed RAN node 5-2 comprising a distributed type of base station for implementation in the communication system 1 of Fig. 1. As shown, the RAN node 5-2 includes a central unit (RAN node CU) 5-2CUand a distributed unit (RAN node DU) 5-2DU(although it may include other RAN node DUs 5-2DUas described above). Each unit 5-2CU, 5-2DUincludes respective transceiver circuitry 51c, 51d.

[0254] The transceiver circuitry 51d of the distributed unit 5-2DUis operable to transmit signals to and to receive signals from UEs 3 via an air interface 53d and one or more antennas and is also operable to transmit signals to and to receive signals from the central unit 5-2CUvia an interface, for example the distributed unit side of an F1 interface (which may be provided over a satellite radio interface).

[0255] The transceiver circuitry 51c of the central unit 5-2CUis operable to transmit signals to and to receive signals from functions of the core network 7 and / or other RAN nodes 5 via a network interface 55c. The network interface typically includes an N2 and / or N3 interfaces for communicating with the core network and a RAN node to RAN node (e.g., Xn) interface for communicating with other RAN nodes 5. The transceiver circuitry 51c of the central unit 5-2CUis also operable to transmit signals to and to receive signals from one or more distributed units 5-2DU, for example the central unit side of the F1 interface provided.

[0256] The transceiver circuitry 51c of the central unit 5-2CUis operable to transmit signals to and to receive signals from functions of the core network 7 and / or other RAN nodes 5 via a network interface 55c. The network interface typically includes an N2 and / or N3 interfaces for communicating with the core network and a RAN node to RAN node (e.g., Xn) interface for communicating with other RAN nodes 5. The transceiver circuitry 51c of the central unit 5-2CUis also operable to transmit signals to and to receive signals from one or more distributed units 5-2DU, for example the central unit side of the F1 interface provided.

[0257] Each unit 5-2CU, 5-2DUincludes a respective controller 57c, 57d which controls the operation of the corresponding transceiver circuitry 51c, 51d in accordance with software stored in the respective memories 59c and 59d of the central unit 5-2CUand the distributed unit 5-2CU. The software of each unit may be pre-installed in the memory 59c, 59d and / or may be downloaded via the communication system 1 or from a removable data storage device (RMD), for example. The software of each unit includes, among other things, a respective operating system 61c, 61d, and a respective communications control module 63c, 63d.

[0258] Each communications control module 63c, 63d is operable to control the communication of its corresponding unit 5-2CU, 5-2DUincluding the communication from one unit to the other. The communications control module 63d of the distributed unit 5-2DUcontrols communication between the distributed unit 5-2DUand the UEs 3, and the communications control module 63c of the central unit 5-2CUcontrols communication between the central unit 5-2CUand other network entities that are connected to the distributed RAN node 5-2DU.

[0259] The communications control modules 63c, 63d also respectively control the part played by the central unit 5-2CUand distributed unit 5-2DUin the flow of uplink and downlink user traffic and control data to be received from and transmitted to the communications devices served by the RAN node 5-2 including, for example, control data for managing operation of the UEs 3. Each communication control module 63c, 63d is responsible, for example, for controlling the respective part played by the central unit 5-2CUand distributed unit 5-2DUin the reception and decoding of uplink communications, via associated uplink channels (e.g., via a physical uplink control channel (PUCCH), a random access channel (RACH), and / or a physical uplink shared channel (PUSCH)) including both dynamic and semi-static signalling (e.g., SRS). Each communication control module 63c, 63d is responsible, for example, for controlling the respective part played by the central unit 5-2CUand distributed unit 5-2DUin the overall handling the transmission of downlink communications via associated downlink channels (e.g., via a physical downlink control channel (PDCCH) and / or a physical downlink shared channel (PDSCH)) including both dynamic and semi-static signalling (e.g., CSI-RS, SSBs etc.). Each communication control module 63c, 63d is responsible, for example, for controlling the respective part played by the central unit 5-2CUand distributed unit 5-2DUin determining and scheduling the resources to be used by the UE 3 for receiving in DL / transmitting in UL, for configuring slots / symbols appropriately (e.g., for UL, DL, flexible, full duplex communication, or the like), for configuring one or more bandwidth parts for the UE 3, and for providing related configuration signalling to the UE 3.

[0260] It will be appreciated that each communication control module 63c, 63d may include a number of sub-modules (or 'layers') to support specific functionalities supported by the by the central unit 5-2CUand distributed unit 5-2DU. For example, a communications PHY sub-module, a MAC sub-module, an RLC sub-module, a PDCP sub-module, an SDAP sub-module, an IP sub-module, an RRC sub-module, etc may be distributed between the central unit 5-2CUand distributed unit 5-2DUappropriately depending on where the functional split is configured between the central unit 5-2CUand distributed unit 5-2DU.

[0261] Each communication control module 63c, 63d is configured, in particular, to control the respective communications of the central unit 5-2CUand distributed unit 5-2DU, where applicable, in accordance with any of the methods described herein.

[0262] < Modifications and Alternatives > 　　Detailed examples been described above. As those skilled in the art will appreciate, a number of modifications and alternatives can be made to the above examples whilst still benefiting from the concepts embodied therein.

[0263] It will be appreciated that description of features of and actions performed by a RAN node (base station), apply equally to distributed type base stations as to non-distributed type base stations.

[0264] It will also be appreciated that whilst information elements having specific names have been described differently named information elements but having a similar purpose may be used.

[0265] In the above description the UE and the base station are described for ease of understanding as having a number of discrete functional components or modules. Whilst these modules may be provided in this way for certain applications, for example where an existing system has been modified to implement the disclosed enhancements, in other applications, for example in systems designed with the inventive features in mind from the outset, these modules may be built into the overall operating system or code and so these modules may not be discernible as discrete entities.

[0266] In the above examples, a number of software modules were described. As those skilled in the art will appreciate, the software modules may be provided in compiled or un-compiled form and may be supplied to the UE or base station as a signal over a computer network, or on a recording medium. Further, the functionality performed by part, or all, of this software may be performed using one or more dedicated hardware circuits. However, the use of software modules is preferred as it facilitates the updating of the UE or the base station in order to update their functionalities.

[0267] Each controller may comprise any suitable form of processing circuitry including (but not limited to), for example: one or more hardware implemented computer processors; microprocessors; central processing units (CPUs); arithmetic logic units (ALUs); input / output (IO) circuits; internal memories / caches (program and / or data); processing registers; communication buses (e.g. control, data and / or address buses); direct memory access (DMA) functions; hardware or software implemented counters, pointers and / or timers; and / or the like. Various other modifications will be apparent to those skilled in the art and will not be described in further detail here.

[0268] The User Equipment (or "UE," "mobile station," "mobile device" or "wireless device") in the present disclosure is an entity connected to a network via a wireless interface. It should be noted that the present disclosure is not limited to a dedicated communication device and can be applied to any device having a communication function as explained in the following paragraphs.

[0269] The terms "User Equipment" or "UE" (as the term is used by 3GPP), "mobile station", "mobile device", and "wireless device" are generally intended to be synonymous with one another, and include standalone mobile stations, such as terminals, cell phones, smart phones, tablets, cellular IoT devices, IoT devices, and machinery. It will be appreciated that the terms "mobile station" and "mobile device" also encompass devices that remain stationary for an extended period of time.

[0270] A UE may, for example, be an item of equipment for production or manufacture and / or an item of energy related machinery (for example equipment or machinery such as: boilers; engines; turbines; solar panels; wind turbines; hydroelectric generators; thermal power generators; nuclear electricity generators; batteries; nuclear systems and / or associated equipment; heavy electrical machinery; pumps including vacuum pumps; compressors; fans; blowers; oil hydraulic equipment; pneumatic equipment; metal working machinery; manipulators; robots and / or their application systems; tools; moulds or dies; rolls; conveying equipment; elevating equipment; materials handling equipment; textile machinery; sewing machines; printing and / or related machinery; paper converting machinery; chemical machinery; mining and / or construction machinery and / or related equipment; machinery and / or implements for agriculture, forestry and / or fisheries; safety and / or environment preservation equipment; tractors; precision bearings; chains; gears; power transmission equipment; lubricating equipment; valves; pipe fittings; and / or application systems for any of the previously mentioned equipment or machinery etc.).

[0271] A UE may, for example, be an item of transport equipment (for example transport equipment such as: rolling stocks; motor vehicles; motorcycles; bicycles; trains; buses; carts; rickshaws; ships and other watercraft; aircraft; rockets; satellites; drones; balloons etc.).

[0272] A UE may, for example, be an item of information and communication equipment (for example information and communication equipment such as: electronic computer and related equipment; communication and related equipment; electronic components etc.).

[0273] A UE may, for example, be a refrigerating machine, a refrigerating machine applied product, an item of trade and / or service industry equipment, a vending machine, an automatic service machine, an office machine or equipment, a consumer electronic and electronic appliance (for example a consumer electronic appliance such as: audio equipment; video equipment; a loud speaker; a radio; a television; a microwave oven; a rice cooker; a coffee machine; a dishwasher; a washing machine; a dryer; an electronic fan or related appliance; a cleaner etc.).

[0274] A UE may, for example, be an electrical application system or equipment (for example an electrical application system or equipment such as: an x-ray system; a particle accelerator; radio isotope equipment; sonic equipment; electromagnetic application equipment; electronic power application equipment etc.).

[0275] A UE may, for example, be an electronic lamp, a luminaire, a measuring instrument, an analyser, a tester, or a surveying or sensing instrument (for example a surveying or sensing instrument such as: a smoke alarm; a human alarm sensor; a motion sensor; a wireless tag etc.), a watch or clock, a laboratory instrument, optical apparatus, medical equipment and / or system, a weapon, an item of cutlery, a hand tool, or the like.

[0276] A UE may, for example, be a wireless-equipped personal digital assistant or related equipment (such as a wireless card or module designed for attachment to or for insertion into another electronic device (for example a personal computer, electrical measuring machine)).

[0277] A UE may be a device or a part of a system that provides applications, services, and solutions described below, as to "internet of things (IoT)," using a variety of wired and / or wireless communication technologies.

[0278] Internet of Things devices (or "things") may be equipped with appropriate electronics, software, sensors, network connectivity, and / or the like, which enable these devices to collect and exchange data with each other and with other communication devices. IoT devices may comprise automated equipment that follow software instructions stored in an internal memory. IoT devices may operate without requiring human supervision or interaction. IoT devices might also remain stationary and / or inactive for an extended period of time. IoT devices may be implemented as a part of a (generally) stationary apparatus. IoT devices may also be embedded in non-stationary apparatus (e.g., vehicles) or attached to animals or persons to be monitored / tracked.

[0279] It will be appreciated that IoT technology can be implemented on any communication devices that can connect to a communication system for sending / receiving data, regardless of whether such communication devices are controlled by human input or software instructions stored in memory.

[0280] It will be appreciated that IoT devices are sometimes also referred to as Machine-Type Communication (MTC) devices or Machine-to-Machine (M2M) communication devices. It will be appreciated that a UE may support one or more IoT or MTC applications. Some examples of MTC applications are listed in the following table. This list is not exhaustive and is intended to be indicative of some examples of machine type communication applications.

[0281] Table 2

[0282] Further, the above-described UE categories are merely examples of applications of the technical ideas and exemplary examples described in the present document. Needless to say, these technical ideas and examples are not limited to the above-described UE and various modifications can be made thereto.

[0283] Various other modifications will be apparent to those skilled in the art and will not be described in further detail here.

[0284] Although the present disclosure has been described with reference to the example embodiments, the present disclosure is not limited to the above. Various changes that can be understood by those skilled in the art can be made to the configuration and details of the present disclosure within the scope of the disclosure.

[0285] This application is based upon and claims the benefit of priority from UK patent application No. 2410524.9, filed on July 18, 2024, the disclosure of which is incorporated herein in its entirety by reference.

[0286] The program can be stored and provided to the computer device using any type of non-transitory computer readable media. Non-transitory computer readable media include any type of tangible storage media. Examples of non-transitory computer readable media include magnetic storage media (such as floppy disks, magnetic tapes, hard disk drives, etc.), optical magnetic storage media (e.g. magneto-optical disks), CD-ROM (Read Only Memory), CD-R, CD-R / W, and semiconductor memories (such as mask ROM, PROM (Programmable ROM), EPROM (Erasable PROM), flash ROM, RAM (Random Access Memory), etc.). The program may be provided to the computer device using any type of transitory computer readable media. Examples of transitory computer readable media include electric signals, optical signals, and electromagnetic waves. Transitory computer readable media can provide the program to the computer device via a wired communication line, such as electric wires and optical fibers, or a wireless communication line.

[0287] For example, the whole or part of the example embodiments disclosed above can be described as, but not limited to, the following supplementary notes. (Supplementary note 1) 　　A method performed by a mobile device, the method comprising: 　　receiving, from an access network node, first information of beam measurement configuration for each candidate cell, second information of report configuration of a report corresponding to prediction of lower layer triggered mobility (LTM) using an artificial intelligence / machine learning (AI / ML) model, and third information of configuration of at least one event for triggering the LTM; 　　measuring at least one beam based on the first information for inferring the AI / ML model for performing the prediction; and 　　transmitting a report for the prediction based on the second information, in a case where one of the at least one event has occurred. (Supplementary note 2) 　　The method according to supplementary note 1, wherein 　　the second information includes information indicating a reported value is a measured value or a predicted value for each resource set of the beam measurement. (Supplementary note 3) 　　The method according to supplementary note 1 or 2, wherein 　　the second information includes information including at least one of: 　　　　information indicating a gap value from a largest value of L1 RSRP, the gap value indicating at least one L1 RSRP to be reported, 　　　　information indicating a maximum value of L1 RSRPs to be reported, 　　　　information indicating a maximum value of candidate cells, 　　　　information indicating a maximum value of beams to be reported, 　　　　information indicating a maximum value of cells to be reported, or 　　　　information indicating a threshold value of L1 RSRPs to be reported. (Supplementary note 4) 　　The method according to any one of supplementary notes 1 to 3, wherein 　　the report includes information including at least one of: 　　　　information indicating support the prediction of the LTM; 　　　　information indicating the AI / ML model and information indicating characteristics corresponding to the AI / ML model; 　　　　information indicating at least one measured layer-1 (L1) reference signal received power (RSRP) and a corresponding beam index with a predetermined number of measurement values from largest for the each candidate cell, 　　　　information indicating a predetermined number of predicted L1 RSRPs from largest and a corresponding beam index for the each candidate cell, or 　　　　information indicating a measured candidate cell and a corresponding transmission configuration indicator (TCI) state, 　　　　information indicating a predicted candidate cell and a corresponding transmission configuration indicator (TCI) state, 　　　　information indicating the number of beams reported, 　　　　information indicating the number of cells reported, 　　　　information indicating a prediction time window for which the prediction is valid, 　　　　information indicating a predicted fulfillment of one or more of the at least one event, 　　　　information indicating a confidence on a probability of the prediction, or 　　　　information indicating a time window during which the predicted candidate cell is the best candidate cell for the LTM. (Supplementary note 5) 　　The method according to any one of supplementary notes 1 to 4, wherein 　　the report is transmitted in at least one of: 　　　　uplink control information (UCI), 　　　　a physical uplink control channel (PUCCH), or 　　　　a physical uplink shared channel (PUSCH). (Supplementary note 6) 　　The method according to any one of supplementary notes 1 to 5, further comprising: 　　receiving, from the access network node, information including at least one of: 　　　　information indicating an observation window for the prediction, 　　　　information indicating a prediction window for the prediction, 　　　　information indicating the AI / ML model to be activated, and 　　　　information indicating at least a part of the each candidate cell. (Supplementary note 7) 　　The method according to any one of supplementary notes 1 to 6, further comprising: 　　transmitting, to the access network node, information indicating support of a functionality of the prediction. (Supplementary note 8) 　　The method according to supplementary note 7, wherein 　　the information indicating support of the functionality of the prediction includes including at least one of: 　　　　an indication of the support for the prediction, 　　　　information indicating at least one AI / ML model for the prediction, or 　　　　information indicating characteristics of the prediction. (Supplementary note 9) 　　The method according to supplementary note 7 or 8, wherein 　　the information indicating support of a functionality of the prediction is transmitted from the access network node to another respective access network node corresponding to the each candidate cell. (Supplementary note 10) 　　The method according to supplementary note 9, wherein 　　further information indicating at least one of a functionality or AI / ML model which can be enabled on the mobile device for the prediction is transmitted from the another respective access network node to the access network node, and 　　the second information is based on the further information. (Supplementary note 11) 　　The method according to any one of supplementary notes 1 to 10, wherein 　　the inferring is performed by the mobile device. (Supplementary note 12) 　　The method according to any one of supplementary notes 1 to 10, wherein 　　the inferring is performed by the access network node. (Supplementary note 13) 　　The method according to supplementary note 12, wherein 　　the access network node receives, from a neighbour access network node, information indicating a handover history, and 　　the inferring is performed using the handover history. (Supplementary note 14) 　　The method according to supplementary note 12 or 13, wherein 　　the access network node receives, from a neighbour access network node, information used for determining at least one of the first information or the second information. (Supplementary note 15) 　　The method according to any one of supplementary notes 12 to 14, wherein 　　the access network node includes a central unit and a distributed unit, 　　the receiving the first information and the second information is performed by receiving from the central unit, 　　the transmitting the report is performed by the transmitting to the distributed unit, 　　the inferring is performed by the distributed unit, and 　　a result of the prediction is transmitted from the distributed unit to the central unit. (Supplementary note 16) 　　A method performed by an access network node, the method comprising: 　　transmitting, to a mobile device, first information of beam measurement configuration for each candidate cell, second information of report configuration of a report corresponding to prediction of lower layer triggered mobility (LTM) using an artificial intelligence / machine learning (AI / ML) model, and third information of configuration of at least one event for triggering the LTM; and 　　receiving a report for the prediction based on the second information, in a case where one of the at least one event has occurred, and 　　wherein the report is based on measuring, by the mobile device, at least one beam based on the first information for inferring the AI / ML model for performing the prediction. (Supplementary note 17) 　　A mobile device comprising: 　　means for receiving, from an access network node, first information of beam measurement configuration for each candidate cell, second information of report configuration of a report corresponding to prediction of lower layer triggered mobility (LTM) using an artificial intelligence / machine learning (AI / ML) model, and third information of configuration of at least one event for triggering the LTM; 　　means for measuring at least one beam based on the first information for inferring the AI / ML model for performing the prediction; and 　　means for transmitting a report for the prediction based on the second information, in a case where one of the at least one event has occurred. (Supplementary note 18) 　　An access network node comprising: 　　means for transmitting, to a mobile device, first information of beam measurement configuration for each candidate cell, second information of report configuration of a report corresponding to prediction of lower layer triggered mobility (LTM) using an artificial intelligence / machine learning (AI / ML) model, and third information of configuration of at least one event for triggering the LTM; and 　　means for receiving a report for the prediction based on the second information, in a case where one of the at least one event has occurred, and 　　wherein the report is based on measuring, by the mobile device, at least one beam based on the first information for inferring the AI / ML model for performing the prediction.

[0288] 1　　communication system 3, 3-1, 3-2, 3-3　　UEs 5, 5-1, 5-2　　radio access network (RAN) node 5S　　source RAN node, first RAN node 5T　　target RAN node, second RAN node 5-2CU　　central unit (CU) 5-2DU　　distributed unit (DU) 7　　core network 9　　cell 9-1　　source cell 9-2　　target cell 10　　control plane functions (CPFs) 10-1　　access and mobility management Functions (AMFs) 10-2　　session management functions (SMFs) 11　　user plane functions (UPFs) 20　　external data network 31, 51, 51c, 51d　　transceiver circuit 33, 53, 53d　　antenna 35　　user interface 37, 57, 57c, 57d　　controller 39, 59, 59c, 59d　　memory 41, 61, 61c, 61d　　operating system 43, 63, 63c, 63d　　communications control module 55　　core network interface 55c　　network interface

Claims

1. A method performed by a mobile device, the method comprising: 　　receiving, from an access network node, first information of beam measurement configuration for each candidate cell, second information of report configuration of a report corresponding to prediction of lower layer triggered mobility (LTM) using an artificial intelligence / machine learning (AI / ML) model, and third information of configuration of at least one event for triggering the LTM; 　　measuring at least one beam based on the first information for inferring the AI / ML model for performing the prediction; and 　　transmitting a report for the prediction based on the second information, in a case where one of the at least one event has occurred.

2. The method according to claim 1, wherein 　　the second information includes information indicating a reported value is a measured value or a predicted value for each resource set of the beam measurement.

3. The method according to claim 1 or 2, wherein 　　the second information includes information including at least one of: 　　　　information indicating a gap value from a largest value of L1 RSRP, the gap value indicating at least one L1 RSRP to be reported, 　　　　information indicating a maximum value of L1 RSRPs to be reported, 　　　　information indicating a maximum value of candidate cells, 　　　　information indicating a maximum value of beams to be reported, 　　　　information indicating a maximum value of cells to be reported, or 　　　　information indicating a threshold value of L1 RSRPs to be reported.

4. The method according to any one of claims 1 to 3, wherein 　　the report includes information including at least one of: 　　　　information indicating support the prediction of the LTM; 　　　　information indicating the AI / ML model and information indicating characteristics corresponding to the AI / ML model; 　　　　information indicating at least one measured layer-1 (L1) reference signal received power (RSRP) and a corresponding beam index with a predetermined number of measurement values from largest for the each candidate cell, 　　　　information indicating a predetermined number of predicted L1 RSRPs from largest and a corresponding beam index for the each candidate cell, or 　　　　information indicating a measured candidate cell and a corresponding transmission configuration indicator (TCI) state, 　　　　information indicating a predicted candidate cell and a corresponding transmission configuration indicator (TCI) state, 　　　　information indicating the number of beams reported, 　　　　information indicating the number of cells reported, 　　　　information indicating a prediction time window for which the prediction is valid, 　　　　information indicating a predicted fulfillment of one or more of the at least one event, 　　　　information indicating a confidence on a probability of the prediction, or 　　　　information indicating a time window during which the predicted candidate cell is the best candidate cell for the LTM.

5. The method according to any one of claims 1 to 4, wherein 　　the report is transmitted in at least one of: 　　　　uplink control information (UCI), 　　　　a physical uplink control channel (PUCCH), or 　　　　a physical uplink shared channel (PUSCH).

6. The method according to any one of claims 1 to 5, further comprising: 　　receiving, from the access network node, information including at least one of: 　　　　information indicating an observation window for the prediction, 　　　　information indicating a prediction window for the prediction, 　　　　information indicating the AI / ML model to be activated, and 　　　　information indicating at least a part of the each candidate cell.

7. The method according to any one of claims 1 to 6, further comprising: 　　transmitting, to the access network node, information indicating support of a functionality of the prediction.

8. The method according to claim 7, wherein 　　the information indicating support of the functionality of the prediction includes including at least one of: 　　　　an indication of the support for the prediction, 　　　　information indicating at least one AI / ML model for the prediction, or 　　　　information indicating characteristics of the prediction.

9. The method according to claim 7 or 8, wherein 　　the information indicating support of a functionality of the prediction is transmitted from the access network node to another respective access network node corresponding to the each candidate cell.

10. The method according to claim 9, wherein 　　further information indicating at least one of a functionality or AI / ML model which can be enabled on the mobile device for the prediction is transmitted from the another respective access network node to the access network node, and 　　the second information is based on the further information.

11. The method according to any one of claims 1 to 10, wherein 　　the inferring is performed by the mobile device.

12. The method according to any one of claims 1 to 10, wherein 　　the inferring is performed by the access network node.

13. The method according to claim 12, wherein 　　the access network node receives, from a neighbour access network node, information indicating a handover history, and 　　the inferring is performed using the handover history.

14. The method according to claim 12 or 13, wherein 　　the access network node receives, from a neighbour access network node, information used for determining at least one of the first information or the second information.

15. The method according to any one of claims 12 to 14, wherein 　　the access network node includes a central unit and a distributed unit, 　　the receiving the first information and the second information is performed by receiving from the central unit, 　　the transmitting the report is performed by the transmitting to the distributed unit, 　　the inferring is performed by the distributed unit, and 　　a result of the prediction is transmitted from the distributed unit to the central unit.

16. A method performed by an access network node, the method comprising: 　　transmitting, to a mobile device, first information of beam measurement configuration for each candidate cell, second information of report configuration of a report corresponding to prediction of lower layer triggered mobility (LTM) using an artificial intelligence / machine learning (AI / ML) model, and third information of configuration of at least one event for triggering the LTM; and 　　receiving a report for the prediction based on the second information, in a case where one of the at least one event has occurred, and 　　wherein the report is based on measuring, by the mobile device, at least one beam based on the first information for inferring the AI / ML model for performing the prediction.

17. A mobile device comprising: 　　means for receiving, from an access network node, first information of beam measurement configuration for each candidate cell, second information of report configuration of a report corresponding to prediction of lower layer triggered mobility (LTM) using an artificial intelligence / machine learning (AI / ML) model, and third information of configuration of at least one event for triggering the LTM; 　　means for measuring at least one beam based on the first information for inferring the AI / ML model for performing the prediction; and 　　means for transmitting a report for the prediction based on the second information, in a case where one of the at least one event has occurred.

18. An access network node comprising: 　　means for transmitting, to a mobile device, first information of beam measurement configuration for each candidate cell, second information of report configuration of a report corresponding to prediction of lower layer triggered mobility (LTM) using an artificial intelligence / machine learning (AI / ML) model, and third information of configuration of at least one event for triggering the LTM; and 　　means for receiving a report for the prediction based on the second information, in a case where one of the at least one event has occurred, and 　　wherein the report is based on measuring, by the mobile device, at least one beam based on the first information for inferring the AI / ML model for performing the prediction.

Images