Method, mobile device and access network node

Abstract

A method performed by a mobile device determines, the method comprising receiving configuration information indicating a time window for measurements for use by a network in a prediction using an artificial intelligence (AI) / machine learning (ML) model transmitting measurement information including at least one measurement result for each reference time point within the time window corresponding to the measurements receiving information indicating at least one condition for handover, derived based on the prediction by the network; and determining whether to initiate the handover by determining whether one or more of the at least one condition have been met.

Description

METHOD, MOBILE DEVICE AND ACCESS NETWORK NODE

[0001] The present disclosure relates to a communication system and to parts thereof.

[0002] 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, 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 artificial intelligence (AI) / machine learning (ML)-based handover and / or beam switching procedures.

[0003] 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 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.

[0004] Under the 3GPP standards, a NodeB (or an eNB in LTE, and gNB in 5G) is the radio access network (RAN) node (or simply 'access node', 'access network node' or 'RAN node') 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 simply RAN) or base station to refer to any such access nodes.

[0005] 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.

[0006] NPL 1: The 'NGMN 5G White Paper' V1.0 by the Next Generation Mobile Networks (NGMN) Alliance, available from https: / / www.ngmn.org / 5g-white-paper.html.

[0007] 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.

[0008] 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.

[0009] It will nevertheless be appreciated that the use of AI / ML models may also be extended to other procedures and methods performed in communication system 1 to further improve the reliability or efficiency of communication in the network, for example, in handover and / or beam switching procedures.

[0010] In the case of handover procedures, typically communication system 1 would employ layer-3 (L3) type handover procedures, or alternatively layer-1 (L1) 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.

[0011] 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.

[0012] In the L1-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.

[0013] It will therefore be appreciated that handover procedures in communication system 1 may benefit from the use of AI / ML models. In particular, such AI / ML models may be used to optimise mobility performance by providing mobility predictions that may, for example, infer when handovers should be performed, and to trigger such handovers. There is therefore a need to devise appropriate mechanisms and procedures to allow for the implementation of network-based AI / ML (or prediction)-based handover procedures.

[0014] Additionally, in the case of beam switching procedures within a single cell, typically communication system 1 will trigger beam switching in response to a detected beam failure event, reduction in beam quality, or the like. However, such beam switching procedures are reactive rather than proactive, which can negatively impact service quality. It will therefore be appreciated that beam switching procedures in communication system 1 may also benefit from the use of AI / ML models. In particular, such AI / ML models may be used to predict a 'best' beam for a future time instance, or to predict a potential future beam failure event, and proactively trigger a beam switch.

[0015] The disclosure has a method performed by a mobile device, the method comprising: receiving configuration information indicating a time window for measurements for use by a network in a prediction using an artificial intelligence (AI) / machine learning (ML) model transmitting measurement information including at least one measurement result for each reference time point within the time window corresponding to the measurements receiving information indicating at least one condition for handover, derived based on the prediction by the network; and determining whether to initiate the handover by determining whether one or more of the at least one condition have been met.

[0016] The disclosure has a method performed by an access network node, the method comprising transmitting configuration information indicating a time window for measurements for use by a network in a prediction using an artificial intelligence (AI) / machine learning (ML) model receiving measurement information including at least one measurement result for each reference time point within the time window corresponding to the measurements; and transmitting information indicating at least one condition for handover, derived based on the prediction by the network, and wherein the at least one condition is used for determining whether to initiate the handover by determining whether one or more of the at least one condition have been met.

[0017] The disclosure has a mobile device comprising means for receiving configuration information indicating a time window for measurements for use by a network in a prediction using an artificial intelligence (AI) / machine learning (ML) model means for transmitting measurement information including at least one measurement result for each reference time point within the time window corresponding to the measurements means for receiving information indicating at least one condition for handover, derived based on the prediction by the network; and means for determining whether to initiate the handover by determining whether one or more of the at least one condition have been met.

[0018] The disclosure has an access network node comprising means for transmitting configuration information indicating a time window for measurements for use by a network in a prediction using an artificial intelligence (AI) / machine learning (ML) model means for receiving measurement information including at least one measurement result for each reference time point within the time window corresponding to the measurements; and means for transmitting information indicating at least one condition for handover, derived based on the prediction by the network, and wherein the at least one condition is used for determining whether to initiate the handover by determining whether one or more of the at least one condition have been met.

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

[0020] 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.

[0021] 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.

[0022] Examples of apparatus and methods will now be described, by way of example, with reference to the accompanying drawings in which:

[0023] Fig. 1 schematically illustrates a mobile ('cellular' or 'wireless') telecommunication system;Fig. 2 illustrates a simplified sequence diagram of a typical L3 mobility (handover) procedure that may be performed in a communication system of the type illustrated in Fig. 1.Fig.3 illustrates a simplified sequence diagram of a typical L1 mobility (handover) procedure that may be performed in a communication system of the type illustrated in Fig. 1.Fig. 4 illustrates a framework in respect of an AI / ML model, and how various entities of the framework may interact with one another.Fig. 5 shows an illustration of a method of training an AI / ML model, and of monitoring the performance of the AI / ML model.Fig. 6A depicts a simplified sequence diagram illustrating a network-based AI / ML (or prediction)-based handover procedure that may be used in the communication system of Fig. 1.Fig. 6B depicts a simplified sequence diagram illustrating a network-based AI / ML (or prediction)-based handover procedure that may be used in the communication system of Fig. 1.Fig. 7A depicts a simplified sequence diagram illustrating a network-based AI / ML (or prediction)-based beam switching procedure that may be used in the communication system of Fig. 1.Fig. 7B depicts a simplified sequence diagram illustrating a network-based AI / ML (or prediction)-based beam switching procedure that may be used in the communication system of Fig. 1.Fig. 8 is a simplified block schematic illustrating the main components of a UE for implementation in the communication system of Fig. 1; andFig. 9 is a simplified block schematic illustrating the main components of a RAN node for implementation in the communication system of Fig. 1.

[0024] Overview 　　An exemplary communication system will now be described in general terms, by way of example only, with reference to Fig. 1.

[0025] Fig. 1 schematically illustrates a mobile ('cellular' or 'wireless') communication system 1 (e.g., communication system 1) to which the examples described herein are applicable.

[0026] In the communication system 1, user equipments (UEs) 3-1, 3-2, 3-3 (e.g., mobile telephones and / or other mobile or stationary devices) can communicate with each other via a (radio) access network ((R)AN) node 5 that operates according to one or more compatible radio access technologies (RATs). In the illustrated example, the RAN node 5 comprises a base station 5 or 'gNB' operating one or more associated cells 9. Communication via the RAN node 5 is typically routed through a core network 7 (e.g., a 5G / 6G or later generations core network or evolved packet core network (EPC)).

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

[0028] Each RAN node 5 controls one or more associated cells 9 either directly, or indirectly via one or more other nodes (such as home RAN nodes, 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.

[0029] 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).

[0030] 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 (such as, for example an Authentication Server Function (AUSF) which facilitates security processes, an AI / ML-based mobility function, or the like).

[0031] The RAN node 5 is 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 interface (e.g. an N1 reference point (analogous to the S1 reference point in LTE)). It will be appreciated that N1 communication is routed transparently via the RAN node 5.

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

[0033] 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.

[0034] The SMF 10-2 is connected to the AMF 10-1 via an appropriate interface (e.g. an 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 also allocates IP addresses to the UEs 3. 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.

[0035] The RAN node 5 of the communication system 1 is configured to operate at least one cell 9 on an associated time-division duplex (TDD) carrier that operates in unpaired spectrum and / or at least one cell 9 on an associated frequency-division duplex (FDD) carrier that operates in paired spectrum.

[0036] The 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.

[0037] 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 a number of 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 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.

[0038] The RAN node 5 also transmits DL physical signals that do not carry any data, such as, 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).

[0039] 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 a number of 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 an UL control / data signal, and / or sounding reference signals (SRS) used for UL channel measurement.

[0040] The UEs 3 and RAN node 5 of the communication system 1 are mutually configured for performing a random-access channel (RACH) procedure for the UE 3 to access the network. Specifically, on detection and selection of a cell 9 (and / or a beam in the case of 5G) the 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. 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 RAN node 5 over a physical random-access channel (PRACH) for initiating the process to obtain synchronization in the uplink (UL). In response, the RAN node 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 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.

[0041] While a four-step contention-based RACH procedure is described it will be appreciated that a 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 by 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.

[0042] 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 id 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).

[0043] Fig. 2 illustrates a simplified sequence diagram of a typical L3 mobility (handover) procedure that may be performed in the communication system 1 of the type illustrated in Fig. 1.

[0044] As shown in Fig. 2 there is provided a UE 3, a source RAN node 5Sin initial communication with the UE 3, and a target RAN node 5Tto which the UE 3 is to be handed over.

[0045] At step S201 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 source RAN node 5Sand / or target 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 source and / or target RAN nodes 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 source RAN node 5Sto the target RAN node 5T.

[0046] In another example, at step S201, 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 source RAN node 5S(not shown) that indicate frequency / time locations and subcarrier spacing (SCSs) of reference signals to be measured.

[0047] In another example, at step S201, the UE 3 may additionally (or alternatively) perform any appropriate inter-radio access technology (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 source RAN node 5S(not shown) that indicate a single carrier frequency (e.g., a E-UTRA frequency).

[0048] At step S202 the UE 3 may transmit a measurement report to the source RAN node 5Sthat provides an indication of the result of the measurements made by the UE 3 at step S201. The measurement report may be transmitted from the UE 3 to the source RAN node 5Sin an appropriate message (e.g., an RRC message). The source RAN node 5Smay use the information provided in the measurement report to determine (not shown) that the UE 3 is to be handed over to the target RAN node 5T. However, it will be appreciated that a determination that handover to the target RAN node 5Tis to be performed may alternatively (or additionally) be based on a measurement performed at the source RAN node 5Sor at the target RAN node 5T. Alternatively, a determination that handover of the UE 3 is to be performed may be based on a factor other than a signal measurement, such as a level of congestion in a cell 9 operated by the source RAN node 5S.

[0049] It will be appreciated that the UE 3 may transmit the measurement reports to the source RAN node 5Sbased on an appropriate reporting configuration previously signalled to the UE 3 by the source RAN node 5S. For example, the source 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 source RAN node 5S. The criterion may be a single event that triggers the UE 3 to send measurement reports to the source RAN node 5S. Alternatively the criterion may configure the UE 3 to send measurement reports to the source RAN node 5Son a periodic basis (i.e., triggered at periodic time intervals).

[0050] The one or more reporting configurations may indicate to the UE 3 a type of reference signal (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 synchronization signal / physical broadcast channel blocks (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 source 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 source RAN node 5S, measurement results per CSI-RS resource, measurement results per cell (or beam) based on CSI-RS resources, CSI-RS resource measurement identifiers, and the like.

[0051] 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 source 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 source 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.

[0052] At step S204 the source RAN node 5Smay transmit a handover request (e.g., a handover command message) to the target RAN node 5T, requesting handover of the UE 3 from the source RAN node 5Sto the target RAN node 5T. The handover request may include an indication of, for example, an identity of the source RAN node 5S, a cause value for the handover, an identity of target RAN node 5T, an identify of a target cell 9 provided by the target 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 / or the like.

[0053] If the handover has been triggered by the measurement report received by the source RAN node 5Sin step S202, then the cause value may indicate, for example, that the handover is desirable for radio reasons. Alternatively, if the handover has been triggered to reduce the load at the source RAN node 5S, the cause value may indicate that the handover is for reducing load in the serving cell 9. The handover request message may also include an indication of the AMF 10-1 that is serving the UE 3.

[0054] At step S206, having received the handover request, the target RAN node 5Tmay perform, based on that handover request, an admission control procedure (that may involve, for example, directly and / or indirectly communicating with one or more nodes or functions of the core network 7). For example, the target RAN node 5Tmay perform a validation procedure that may involve checking that if a connection is established between the UE 3 and the target RAN node 5Tthen current resources are sufficient for the proposed connection.

[0055] At step S208 having received the handover request at step S204 and having performed admission control at step S206, the target RAN node 5Tmay transmit an appropriate response message to the source RAN node 5Sto acknowledge receipt of the handover request. For example, the target RAN node 5Tmay transmit an acknowledgement of the handover request (which may be referred to as a "handover request acknowledgement" message). The handover request acknowledgement message may include an indication of handover configuration information for the handover that is to be forwarded to the UE 3. This may, for example, form part of a handover command (or similar message) to be sent to the UE 3 and may be provided transparently to the source RAN node 5S(e.g., in an appropriate transparent container or the like). The handover request acknowledgement message may also include configuration information that enables the source RAN node 5Sto begin forwarding user plane data for the UE 3 to the target RAN node 5T.

[0056] It will be appreciated that the transmissions at steps S204 and S208 may be performed over a RAN node to RAN node interface (e.g., an Xn interface) between the source RAN node 5Sand the target RAN node 5Tusing messages in accordance with an appropriate application protocol (e.g., an Xn application protocol (XNAP)). Hence, the handover procedure in this example may be referred to as a RAN node to RAN node interface based (e.g., an Xn-based) handover procedure. Steps S201 to S208 may be referred to as a 'handover preparation phase' of a handover procedure.

[0057] At step S210, the source RAN node 5Smay transmit an appropriate handover command message to initiate the handover of the UE 3 from the source RAN node 5Sto the target RAN node 5T. By way of example only, the handover command message may include handover configuration information for the UE 3. The configuration information for the handover may be, for example, an RRC configuration transmitted in an RRC configuration message, an RRC reconfiguration message, or the like.

[0058] At step S212, the UE 3 applies the received configuration for handover and then switches to a cell 9 of the target RAN node 5T(e.g., using a RACH procedure, or the like). The UE 3 detaches from the old cell 9, synchronises to the target cell 9, and completes the RRC handover procedure by sending an indication to the target RAN node 5Tthat the handover is complete. For example, the UE 3 may, at step S214, transmit to the RAN node 5Tan RRC Reconfiguration Complete message. Steps S210, S212, and S214 may be referred to as a 'handover execution phase'. Following the handover execution phase, the UE 3 is operable to transmit uplink transmissions to the target RAN node 5T(e.g., uplink data) and receive downlink transmissions from the target RAN node 5T(e.g., downlink data).

[0059] 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 9 is to be performed based on one or more execution conditions previously configured by the RAN node 5.

[0060] 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 S210). If such a change in conditions occurs, there may be a quality gap between the current cell 9 that the UE 3 is operating on, and the future cell 9 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.

[0061] Being aware of the above issues, layer-1 triggered mobility procedures for handover have been developed that make handover decisions based on more real time measurement reports. An example of such a layer-1 triggered mobility procedure for handover will now be described with reference to Fig. 3.

[0062] Fig. 3 illustrates a simplified sequence diagram of a typical L1 triggered mobility (handover) procedure that may be performed in the communication system 1 of the type illustrated in Fig. 1.

[0063] As shown in Fig. 3 there is provided a UE 3, a source RAN node 5Sin initial communication with the UE 3, and a target RAN node 5Tto which the UE 3 is to be handed over.

[0064] 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 source RAN node 5Sand / or target 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 source and / or target RAN nodes 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 source RAN node 5Sto the target RAN node 5T.

[0065] 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 source RAN node 5S(not shown) that indicate frequency / time locations and SCSs of reference signals to be measured.

[0066] 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 source RAN node 5S(not shown) that indicate a single carrier frequency (e.g., a E-UTRA frequency).

[0067] At step S302 the UE 3 may transmit a measurement report to the 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 source RAN node 5Sin an appropriate message (e.g., an RRC message). The source 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 source RAN node 5Sdecides to (pre)configure the UE 3 for handover / cell switch to each of one or more LTM candidate cells 9 / RAN nodes 5 forming an LTM candidate set. The LTM candidate set includes, for example, at least the cell 9 / RAN node 5 that will ultimately become the target cell 9 / target RAN node 5T.

[0068] It will be appreciated that the UE 3 may transmit the measurement reports to the source RAN node 5Sbased on an appropriate reporting configuration previously signalled to the UE 3 by the source RAN node 5S. For example, the source 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 source RAN node 5S. The criterion may be a single event that triggers the UE 3 to send measurement reports to the source RAN node 5S. Alternatively the criterion may configure the UE 3 to send measurement reports to the source 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 synchronization signal / physical broadcast channel blocks (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 source 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 source 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.

[0069] The one or more reporting configurations may configure the UE 3 to measure and report, to the source 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 the source 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.

[0070] 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 source 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 source 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.

[0071] At step S304 the source 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 (the RAN node 5Tthat ultimately becomes the target) 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 source RAN node 5S, a cause value for the handover, an identity of the target RAN node 5T, an identity of a target cell 9 provided by the target 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 source 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 source 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.

[0072] Furthermore, it will be appreciated that if the handover has been triggered by the measurement report received by the source 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.

[0073] The following procedure will be described from the perspective of the candidate RAN node 5 that 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.

[0074] At step S306, having received handover request, the target RAN node 5Tmay perform, based on that handover request, an admission control procedure. For example, the target 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 target RAN node 5Tthen current resources are sufficient for the proposed connection.

[0075] At step S308 having received the handover request at step S304 and having performed admission control at step S306, the target RAN node 5T.The target 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 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 RAN node 5 (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 source RAN node 5Sto begin forwarding user plane data for the UE 3 to the target RAN node 5T.

[0076] It will be appreciated that the transmissions of at steps S304 and S308 may be performed over an Xn interface between the source RAN node 5Sand the target 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 source 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.

[0077] The source 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 source 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 9, and / or the like).

[0078] 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.

[0079] The UE 3 may, at this stage, perform early synchronization (not shown), in the downlink, with each candidate cell 9 (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 9. Specifically, when UE-based timing advance (TA) measurement is configured, the UE 3 may acquire a respective TA value of each candidate cell 9 by measurement. The UE 3 may perform early TA acquisition with a candidate cell 9 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 source RAN node 5S, following which the UE 3 sends preamble towards the indicated candidate cell 9. In order to minimise the data interruption of the source cell 9 due to CFRA towards a candidate cell 9, 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 9 may be indicated in any cell switch command.

[0080] 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 9 (where possible) and sends, at S314, a corresponding L1 measurement report to the source 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.

[0081] 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).

[0082] At S316, the source RAN node 5Sdecides to execute cell switch to a target cell 9 (i.e., a cell 9 of the target RAN node 5Tin this example). The source 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 9 / target RAN node 5T.

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

[0084] As indicated at S320, the UE 3 can then access the cell 9 using a RACH based or RACH-less procedure. The UE 3 may, for example, perform a random-access procedure towards the target cell 9 if the UE 3 does not have valid TA of the target cell 9. Nevertheless, the UE 3 may access the cell 9 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 target 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 target RAN node 5Thas successfully received its first uplink data.

[0085] 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 9 is to be performed based on one or more execution conditions.

[0086] It can be seen that, in the handover procedure described above with reference to Fig. 3, the handover decision is based on more real time measurement reports via a layer-1 triggered mobility procedure for handover. It will be appreciated however that, whilst such a method has benefits, in such layer-1 triggered mobility procedures the use of L1 measurement reports causes lots of signalling overhead, introducing inefficiencies in the system. Furthermore, as the handover decision is based on instant L1 measurement reports (which have not been L3 filtered by the UE 3), unnecessary handovers and 'ping-pong' handovers may occur.

[0087] AI / ML 　　The communication system 1 supports the use of artificial intelligence (AI) and 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).

[0088] 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 the 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.

[0089] The support for such AI / ML features may involve different levels of collaboration between the network (the RAN node 5 and / or core network 7) and the 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 the 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).

[0090] 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. An example of this type of model is an AI / ML model for beam prediction in time, which can be deployed at the UE side. 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. the UE 3 or the 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), and then is transferred to the UE 3 for use at the UE 3. - 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., the 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. 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 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).

[0091] 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.

[0092] 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.

[0093] The entities include a data collection entity 341, a model training function 343, a model inference function 345, an actor 347, a management function 349, and a model storage entity 351.

[0094] The model storage entity 351 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.

[0095] The data collection entity 341 provides training data to the model training function 343, inference data to the model inference function 345, and monitoring data to the management function 349. The collected data may be, for example, data regarding mobility (e.g. handover of the UE 3, or a location of the UE 3). The data may be obtained, for example, by the UE 3 or the 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 that obtains the data may generate the AI / ML model output).

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

[0097] The model inference function 345 provides AI / ML model inference output (e.g., predictions or decisions), and the actor 347 is a function or node that receives the output from the model inference function 345 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 mobility prediction (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 345 may receive an AI / ML model from the model storage entity 351, and inference data from the data collection entity 341 for use with the AI / ML model. The model inference function 345 may also output monitoring data for use at the management function 349 and receive information indicating an AI / ML to activate or deactivate from the management function 349.

[0098] The management function 349 receives monitoring data from the data collection entity 341 and may also receive monitoring data from the model inference function 345. The management function 349 may transmit, to the model storage entity 351, an indication of an AI / ML model to be transmitted for use at the model inference function 345. The management function 349 may also transmit, to the model training function 343, performance feedback or a retraining request for the AI / ML model.

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

[0100] 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 3 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.

[0101] The data collection by the data collection entity 341 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.

[0102] 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.

[0103] 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).

[0104] 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 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.

[0105] As described above with reference to Fig. 3, each step of the method of Fig. 5 may be executed at a single node of the communication system 1 (including at the UE 3), 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).

[0106] As discussed above with reference to Figs. 4 and 5, information collected by nodes / functions in the communication system 1 (e.g. at a UE 3 and / or RAN node 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.'

[0107] 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 network. For example, a core network node may transmit AI / ML configuration information to the source RAN node 5S(or any other entity of the network that supports an AI / ML-based mobility 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 the source RAN node 5S).

[0108] Single-sided models 　　An AI / ML model may be hosted (stored, for generating inferences) at both the source RAN node 5Sand the UE 3 or may be hosted at only the source RAN node 5S, 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 source RAN node 5S, 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.

[0109] However, even when the model is a single-sided model, it will be appreciated that the model need not necessarily be trained at the source RAN node 5S, a central entity of the communication system 1, or an OAM / OTT server. For example, the model could be trained at another node in the network (e.g. core network node / function), and then transmitted to the source RAN node 5S, a central entity of the communication system 1, or an OAM / OTT server for use at the source RAN node 5S, a central entity of the communication system 1, or an OAM / OTT server. In other words, the AI / ML model may be trained at another network node, and then transferred / deployed to the source RAN node 5S, a central entity of the communication system 1, or an OAM / OTT server.

[0110] Mobility Procedures (with AI / ML enhancement) 　　Whilst each UE 3 and each RAN node 5 are able to perform the mobility procedures described with reference to Figs. 2 and 3, based on real measurements (e.g., of reference signals or the like), each UE 3 and each RAN node 5 may be 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.

[0111] For example, in the L3 triggered mobility procedure described above, after the source RAN node 5Sdecides 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 9) - especially when the UE 3 (or cell 9) 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.

[0112] In respect of LTM based cell switch / handover, whilst the cell switch / handover decision is based on a more 'real-time' measurement reporting (and hence alleviates some potential issues that may occur in an L3 triggered mobility-based handover), 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 9 to handover back to the previous cell 9. Hence, unnecessary handovers and so called 'ping-pong' handovers may occur, thereby increasing measurement report and other signalling overhead significantly.

[0113] The enhanced 'predictive' mobility procedures implemented in the communication system 1 beneficially allow for a more optimal mobility decision to be made by using knowledge of (i.e., predictions of) likely future measurements, the likely future UE mobility and / or likely future handover decisions (e.g., when handover might occur and / or when associated conditions may be met).

[0114] For example, as described in more detail below, in one or more of the enhanced procedures, a source RAN node 5Smay use mobility predictions, and / or the like, generated by an AI / ML model to predict when a handover of a UE 3 from the source RAN node 5Sto a target RAN node 5Tshould be performed.

[0115] Furthermore, as described in more detail below, in one or more of the enhanced procedures, having predicted when a handover should occur, the system may be configured to trigger the handover based on the mobility predictions and / or the like generated by the AI / ML model.

[0116] Moreover, as described in more detail below, in one or more of the enhanced procedures, the mobility predictions, and / or the like, generated by an AI / ML model may be performed on the network-side of the communication system 1. For example, the AI / ML model may be stored at a node of the network with a dedicated AI / ML-based mobility functionality.

[0117] In one or more of the enhanced procedures, as described in more detail below, the mobility predictions, and the like, generated by an AI / ML model may be made using assistance information provided to the network by the UE 3.

[0118] Beneficially, by using AI / ML models to make mobility predictions of a UE 3 and determine when the UE 3 should be handed over from a source RAN node 5Sto a target RAN node 5T, handover failure, ping-pong handovers, beam failure, and the occurrence of unnecessary handovers can be avoided thereby improving the overall performance of the communication system 1.

[0119] In one or more of the enhanced procedures, as described in more detail below, a source RAN node 5Smay use mobility predictions, and / or the like, generated by an AI / ML model to predict when a beam switch for the UE 3 in communication with the source RAN node 5Sshould be performed.

[0120] In one or more of the enhanced procedures, as described in more detail below, the mobility predictions, and / or the like, generated by an AI / ML model to determine when / if a beam switch should occur may be performed on the network-side of the communication system 1. For example, the AI / ML model may be stored at a node of the network with a dedicated AI / ML-based mobility functionality.

[0121] Furthermore, in one or more of the enhanced procedures, as described in more detail below, the mobility predictions, and the like, generated by an AI / ML model to determine when / if a beam switch should occur may be made using assistance information provided to the network by the UE 3.

[0122] Beneficially, by using AI / ML models to make mobility predictions of a UE 3 and determine when the UE 3 should switch the beam on which it is communicating with the source RAN node 5S, the communication system 1 can proactively adjust a beam being used to avoid a potential beam failure and / or ensure the UE 3 is always served by the best beam at a certain serving cell 9.

[0123] Network-based AI / ML (or prediction)-based procedure outlined above will now be discussed in more detail with reference to Figs. 6 & 7.

[0124] AI / ML (or prediction)-based handovers 　　The implementation of a network-based AI / ML (or prediction)-based handover procedure will now be discussed in more detail with reference to Fig. 6.

[0125] Fig. 6a depicts a simplified sequence diagram illustrating a network-based AI / ML (or prediction)-based handover procedure that may be used in the communication system 1 of Fig. 1.

[0126] As shown in Fig. 6a there is provided a source RAN node 5S, a UE 3, and a target RAN node 5Tdeployed in the communication system 1 of Fig. 1. Additionally there may be provided an AI / ML-based mobility functionality 12, which may include an AI / ML model such as that described above with reference to Figs. 4 & 5. It will be appreciated that the AI / ML-based mobility functionality 12 may be provided in an entity of the communication system 1.

[0127] At step S602, the UE 3, which is in RRC_CONNECTED state, may receive from the source RAN node 5San appropriate measurement configuration message (e.g., a new RRC message or a legacy RRC (Re)configuration message) to configure the UE 3 to perform specific measurements and to report those measurements to the network (e.g., the source RAN node 5S). The measurement configuration message, by way of example only, may carry a different set of configuration information (e.g., AI / ML specific measurement configuration information) than conventional measurement configuration messages; for example, measurement configuration messages such as those used in the procedures of Figs. 2 & 3. The AI / ML related measurement configuration information may, for example, configure the UE 3 to provide additional measurement results and / or other information that can be used as an input for a network-sided AI / ML model (inference) for mobility prediction.

[0128] In one example, the measurement configuration message sent by the source RAN node 5Smay configure the UE 3 to perform and report measurements for a part of its serving cell 9, and / or intra-frequency neighbour cells 9, and / or inter-frequency neighbour cells 9 provided by other RAN nodes 5 of the network (e.g., the target RAN node 5T). Additionally, (or alternatively), the measurement configuration message sent by the source RAN node 5Smay configure the UE 3 to perform and report measurements for inter-RAT neighbour cells 9 provided by other RAN nodes 5 of the network (e.g., the target RAN node 5T).

[0129] Additionally (or alternatively), the measurement configuration message may configure the UE 3 with one or more measurement objects to predict measurements for the serving cell 9, and / or neighbouring cells 9 (intra-frequency, inter-frequency, and inter-RAT frequency). Furthermore, the measurement configuration message may configure the UE 3 to record and report measurements for each of those one or more measurement objects to predict measurements for serving cell 9, and / or neighbouring cells 9 at every reference time point within a given time window following a configured time interval.

[0130] It will be appreciated that the appropriate timing window and / or timing interval for performing the measurements for inter-frequency and intra-RAT frequencies may be the same size i.e., they may use the same time window and time interval. Alternatively, however the timing window and timing interval for performing the measurements for inter-frequency and intra-RAT frequencies may be configured to be different from one another. For example, the UE 3 may be configured to perform the measurements for different neighbouring cells 9 on neighbouring frequencies in different time windows and / or different time intervals.

[0131] It will also be appreciated that the measurement configuration message may not configure the UE 3 to perform measurements of specific neighbouring cells 9 if the overheads associated with measurement reports needs to be controlled. For example, the measurement configuration message may only configure a subset of frequencies, neighbouring cells 9 and / or beams.

[0132] In one example, the one or more measurement objects for measurement reporting included in the measurement configuration message to configure the UE 3 may include appropriate information elements (IEs) to indicate frequency / time locations and subcarrier spacings of reference signals to be measured, a RS type to be measured (e.g., one or more synchronisation signals carried by synchronization signal / physical broadcast channel blocks (SS / PBCH blocks (also referred to as 'SSBs')) or CSI-RSs, , and lists of specific beams to be measured (e.g., one or more synchronisation signals carried by SS / PBCH block or CSI-RS). Additionally, where the IEs indicate lists of specific beams to be measured, they may also include appropriate information to indicate to the UE 3 only part of the beams for a particular cell 9 / frequency that are required for UE measurement and report.

[0133] In another example, the one or more measurement objects for measurement reporting included in the measurement configuration message may include other appropriate IEs to indicate one, or a list of, frequencies (e.g., inter-frequency and / or intra-RAT frequencies) to be measured, a RS type (e.g., one or more synchronisation signals carried by SS / PBCH block or CSI-RS) to be measured for each frequency indicated, and lists of specific beams to be measured (e.g., one or more synchronisation signals carried by SS / PBCH block or CSI-RS). Additionally, where the IEs indicate lists of specific beams to be measured, they may also include appropriate information to indicate to the UE 3 only part of the beams for a particular cell 9 / frequency that are required for UE measurement and report.

[0134] By way of example only, the measurement configuration message may also include other appropriate IEs to indicate an appropriate timing window for performing the measurements (e.g., 2000ms). For example, an IE may be provided that tells the UE 3 a time window within which the UE 3 needs to perform and report the measurements to the source RAN node 5Sfor the AI / ML-based mobility functionality 12 to make predictions. The reference time (e.g., start time) of the time window may be the time when the UE 3 receives the measurement configuration message. The time window may be larger (e.g. a multiple of), equal, or smaller than a configured periodicity for UE 3 periodic reporting.

[0135] Alternatively, rather than the measurement configuration message indicating an appropriate timing window for the UE 3 to perform the measurements, the measurement configuration message may include an appropriate IE to configure the UE 3 to perform a specific number of UE measurement instances that should be reported. For example, a UE measurement instance may be configured once within a specific time interval (e.g., once every 200ms). It will be appreciated that such an IE may indicate the measurement interval to the UE 3 from a temporal perspective.

[0136] It will be appreciated that the appropriate timing window and timing interval for performing the measurements for inter-frequency and intra-RAT frequencies may be the same size i.e., they may use the same timing window and timing internal. Alternatively, however the timing window and timing internal for performing the measurements for inter-frequency and intra-RAT frequencies may be configured to be different from one another.

[0137] Additionally (or alternatively), the measurement configuration message to configure the UE 3 may also include other appropriate IEs to indicate a measurement reporting criterion. For example, the measurement configuration message may indicate to the UE 3 the basis on which measurements should be reported to the source RAN node 5S.In one example, the criterion for reporting measurements to the source RAN node 5Smay be a single event that triggers the UE 3 to send measurement reports to the source RAN node 5S. In another example, the criterion may configure the UE 3 to send measurement reports to the source RAN node 5Son a periodic basis (i.e., triggered at periodic time intervals). In yet another example, the criterion may configure the UE 3 to send measurement reports to the source RAN node 5Sonly for a configured number of the highest L3 RSRP cells 9 or the highest L1 RSRP beams. In yet another example, the criterion may configure the UE 3 to send measurement reports to the source RAN node 5Sonly for cells or beams above a configured L1 / L3 RSRP threshold.

[0138] Additionally (or alternatively), the measurement configuration message may also include other appropriate IEs to indicate a format in which the measurements are to be reported to the source RAN node 5S. For example, the measurement configuration message may indicate that the measurements are to be reported to the source RAN node 5Sin a power format (e.g., a Reference Signal Received Power (RSRP) format).

[0139] Additionally (or alternatively), the measurement configuration message may also include other appropriate IEs to indicate the granularity of the measurements to be reported. For example, the measurement configuration message may indicate that the UE 3 is to report measurements to the source RAN node 5Son a per cell basis and / or a per beam basis.

[0140] Additionally (or alternatively), the measurement configuration message may configure the UE 3 to record and report the speed of the UE 3, (and / or the direction in which the UE 3 is currently moving, and / or a current location of the UE 3) at every reference time point of every time interval (or instance) within the given time window configured to the UE 3.

[0141] Additionally (or alternatively), the measurement configuration message may, where appropriate, be the same as a measurement configuration associated with a previous serving RAN node 5 and / or previous serving cell 9 other than the current source RAN node 5S. For example, where the target RAN node 5Tand / or target cell 9 support the same network-sided AI / ML-based mobility functionality 12 as a previous serving RAN node 5 and / or previous serving cell 9 of the UE 3, then the UE 3 may use the same measurement configuration for the target RAN node 5Tthat it previously used for the previous serving RAN node 5. It will be appreciated that in this scenario, the UE 3 may be able to access that measurement configuration when it is within its context information, which in turn may be coordinated between the previous serving RAN node 5 and the target RAN node 5T.

[0142] Additionally (or alternatively), the measurement configuration message may configure the UE 3 to report measurements periodically for the serving cell 9, intra-frequency neighbour cells 9, inter-frequency neighbour cells 9, and / or inter-RAT neighbour cells 9. Alternatively, the measurement configuration message may configure the UE 3 to report measurements based on a certain measurement event.

[0143] Beneficially, by the measurement configuration message configuring the UE 3 as described above, measurements to be performed by the UE 3 may be less than the legacy mobility measurements conducted by the UE 3, since the network may make predictions based on AI / ML.

[0144] Having received the measurement configuration message at step S602, the UE 3 may perform measurements according to the measurement configuration message at step S604. For example, the UE 3 may use the information contained in the measurement configuration message to perform radio measurements for the serving cell 9, and neighbouring cells 9 (intra-frequency, inter-frequency, and inter-RAT frequency) to generate a measurement report (or UE assistance information message) including measurement results for each measurement object and / or other related information indicated in the measurement configuration message, e.g., at every reference time point within the given time window following the configured time interval indicated in the measurement configuration message.

[0145] At step S606, the UE 3 may report the results of the measurements and / or other information according to the measurement configuration message. For example, the UE 3 may report the results of those measurements and / or other information in an appropriate message (e.g., via a UE assistance information message, an appropriate measurement report, or a new RRC message). The UE 3 may transmit the UE assistance information message, the appropriate measurement report, or the new RRC message to the target RAN node 5Tperiodically (if the UE 3 is configured to do so by the measurement configuration message). Alternatively, the UE 3 may transmit the UE assistance information message, the appropriate measurement report, or the new RRC message to the target RAN node 5Tin response to a measurement report event occurring and / or a measurement report condition is met (if the UE 3 is configured to do so by the measurement configuration message).

[0146] Additionally, it will be appreciated that the UE 3 may report the specific measurement report for the purpose of network-sided AI / ML based measurement / mobility prediction together with 'normal' measurement results following legacy radio resource management (RRM) measurements.

[0147] Additionally, message sent by the UE 3 at S606 may carry an ID of an entity of the network that may wish to collect the measurements made by the UE 3 if the UE 3 has been configured as such by the measurement configuration message. For example, where the results of the measurement report are to be used for the purpose of network-sided AI / ML based measurement / mobility prediction, the entity of the network hosting the AI / ML-based mobility functionality 12 may wish to collect the measurements made by the UE 3 and reported to the source RAN node 5Sto enable AI / ML predictions to be made. In this scenario, the UE 3 may report the results of the measurements together with the ID of the entity of the network that wishes to collect the measurements (e.g., the entity hosting the AI / ML-based mobility functionality 12). It will be appreciated that the ID may have initially been indicated to the UE 3 during an RRC configuration procedure, RACH procedure, or the like.

[0148] Upon receiving the measurement report from the UE 3, if the message sent by the UE 3 at S606 contains an ID of a network entity that wishes to collect the measurement report results, then the source RAN node 5Smay send / forward the message to the collection entity identified by the ID.

[0149] By way of example only, the message sent by the UE 3 to the source RAN node 5Sat step S606 may include, amongst other things, for each of the UE's serving cells 9: - An index of the serving cell 9, - The measurement quantity or measurement quantities associated with the measurement results for the serving cell 9 (e.g., in RSRP, RSRQ or SINR), - The physical cell ID (PCID) of the best measured neighbouring cell 9, - A list of the measurement quantity or measurement quantities for serving cell 9 for each reference time point within the configured time window (e.g., in RSRP, RSRQ or SINR), and - A list of the measurement quantity or measurement quantities for the beams for each reference time interval for each serving cell 9 (e.g., in RSRP, RSRQ or SINR). It will be appreciated that in this instance the beams may be identified by SSBs, or CSI-RSs.

[0150] Additionally, (or alternatively), the measurement report sent to the source RAN node 5Sat step S606 by the UE 3 may include, amongst other things, for each of the UE's neighbouring cells 9: - The PCID of the neighbouring cell 9, - A list of the measurement quantity or measurement quantities for the beams (for each reference time interval for the current neighbouring cell 9 (e.g., in RSRP, RSRQ or SINR). It will be appreciated that in this instance the beams may be identified by SSBs, or CSI-RSs, - A list of the measurement quantity or measurement quantities for the neighbour cells 9 for each reference time point within the configured time window (e.g., in RSRP, RSRQ or SINR), and - A list of the measurement quantity or measurement quantities for the beams for each reference time interval for each neighbouring cell 9 (e.g., in RSRP, RSRQ or SINR). It will be appreciated that in this instance the beams may be identified by SSBs, or CSI-RSs.

[0151] When the source RAN node 5Sreceives the message sent by the UE 3 at S606, if the mobility prediction is conducted by the source RAN node 5Sitself, it may run the AI / ML inference for measurement prediction, mobility prediction and / or handover decision for the UE 3.

[0152] Alternatively, if the mobility prediction is conducted by a specific AI / ML-based mobility functionality 12 hosted by a specific entity other than the source RAN node 5S(as shown in Fig. 6), the source RAN node 5S, at step S608a, sends / forwards the message received from the UE 3 (or at least some of the contents of the message) to the entity hosting the AI / ML-based mobility functionality 12. For example, at step S608a, the source RAN node 5Smay identify an ID and / or address of the entity hosting the AI / ML-based mobility functionality 12 (which may be the measurement collection entity previously referred to) from the message sent by the UE 3 at S606.

[0153] Once sent / forwarded to the entity hosting the AI / ML-based mobility functionality 12, the entity hosting the AI / ML-based mobility functionality 12 may, at step S608b, send an appropriate response message to the source RAN node 5Sto acknowledge receipt of the measurement report.

[0154] At step S610, the AI / ML-based mobility functionality 12 hosted at the entity may run the AI / ML inference for measurement prediction and / or mobility prediction for the UE 3 and based on the prediction may make a handover decision. It will be appreciated that all or a subset of the information provided in the UE assistance information or measurement report forward may be provided as an input to the AI / ML model, which in turn outputs appropriate predictions.

[0155] Fig. 6b depicts a continuation of the simplified sequence diagram illustrating the network-based AI / ML (or prediction)-based handover procedure that may be used in the communication system 1 of Fig. 1.

[0156] At step S612 the AI / ML-based mobility functionality 12 hosted by the entity may send the outcome of the AI / ML inference to the source RAN node 5Sof the UE 3. That outcome of the AI / ML inference may include a measurement prediction, a mobility prediction and / or a handover decision for the UE 3. For example, the measurement prediction may include any appropriate information about the one or more serving cells 9 of the source RAN node 5Sand neighbouring cells 9 of a target RAN node 5T.By way of example, the measurement prediction may include indications of a time interval for measurement prediction, a time window for measurement prediction, or a number of prediction instances, and a prediction probability. It will be appreciated that, the source RAN node 5Scould make a or a plurality of handover decision based on one or more reported measurement / mobility predictions.

[0157] The abovementioned handover decision based on the measurement prediction may indicate that the signal strength of a subset of the serving cells 9 (if there are multiple serving cells 9 hosted by the source RAN node 5S) is too weak to continue the communication. In this case, as a follow- up procedure, a subset of the serving cells 9 may be released via RRC Reconfiguration sent from the network to the UE 3.

[0158] Additionally, (or alternatively), the measurement prediction and / or handover decision may include, amongst other things, for the serving cell 9 of the source RAN node 5S: - The index of the serving cell 9 used for the measurement prediction, - A list of the measurement quantity or measurement quantities for the measurement prediction for the serving cell 9 for each future time instance (e.g., in RSRP, RSRQ or SINR), - A PCID of the best predicted neighbour cell 9 for future time instances, and - A list of the measurement quantity or measurement quantities for the measurement prediction for the beams for each reference time interval for the best predicted neighbour cell 9 (e.g., in RSRP, RSRQ or SINR). It will be appreciated that in this instance the beams may be identified by SSBs, or CSI-RSs.

[0159] Additionally, (or alternatively), the measurement prediction and / or handover decision may include, amongst other things, for each neighbour cell 9 of the target RAN node 5Tindicated: - A list of the measurement quantity or measurement quantities for the measurement prediction for each neighbour cell 9 for each future time instance (e.g., in RSRP, RSRQ or SINR), - A frequency of the neighbour cell 9, and - A list of the measurement quantity or measurement quantities for the measurement prediction for the beams or each time instance for the neighbour cell 9 (e.g., in RSRP, RSRQ or SINR). It will be appreciated that in this instance the beams may be identified by SSBs, or CSI-RSs.

[0160] Additionally, (or alternatively), the measurement prediction and / or handover decision may include an indication that a certain mobility event may happen at the UE 3. For example, the measurement prediction may include an indication that a beam failure, a radio-link failure (RLF), a handover failure, a ping-pong handover, a short-time stay handover, an unnecessary handover, or the like, may occur for the UE 3 within a certain time window.

[0161] Additionally, (or alternatively), the measurement prediction and / or handover decision may include an indication of whether and / or when a measurement event will occur based on the measurement reports sent by the UE 3. For example, the AI / ML-based mobility functionality 12 may predict that the measurement of the RSRP for a certain measurement event can stably exceed the handover threshold with a configured time-to-trigger (TTT), which may trigger the source RAN node 5Sto make early handover preparations for the UE 3. In this case, a handover target cell 9 may also be suggested when the AI / ML-based mobility functionality 12 sends the handover decision to the source RAN node 5S.

[0162] Additionally, (or alternatively), the measurement prediction and / or handover decision may include an indication that a certain type of handover (e.g., a standard handover, a conditional handover, or the like) should be performed for the UE 3 to avoid a potential failure event (e.g., a beam failure, a RLF, or the like). In this scenario, the measurement prediction may also include an indication of a target cell 9 of the target RAN node 5Tto which the UE 3 should be handed over.

[0163] Additionally, (or alternatively), the measurement prediction and / or handover decision may include an indication of a period during which the UE 3 should remain in a specific cell 9 (e.g., its current serving cell 9 provided by the source RAN node 5S). Additionally, the measurement prediction may include an indication of a suitable target cell 9 provided by a target RAN node 5Sfor a future handover, or for a future sequence of handovers to avoid unnecessary handover execution. In this scenario, the measurement prediction may also include an indication of a handover target cell 9 or a list of consecutive handover target cells 9 to which the UE 3 should be handed over.

[0164] At step S614a, the source RAN node 5Smay transmit a handover request (e.g., a handover command message) to the target RAN node 5T, requesting handover of the UE 3 from the source RAN node 5Sto the target RAN node 5T. The handover request may include an indication of, for example, an identity of the source RAN node 5S, a cause value for the handover, an identity of target RAN node 5T, an identify of a target cell 9 provided by the target RAN node 5T, UE 3 context information (e.g., a maximum bit rate of the UE 3, or security capabilities of the UE 3), UE history information, and / or the like. It will be appreciated that the source RAN node 5Smay transmit the handover request (e.g., the handover command) to the target RAN node 5Tbased on the prediction outcome and / or handover decision indicated to the source RAN node 5Sby the AI / ML-based mobility functionality 12 at step S610. The handover request may include an indication of the attribute of this handover request (i.e., this is a prediction-based handover) and may include a prediction probability for such handover.

[0165] At step S616, having received the handover request, the target RAN node 5Tmay perform, based on that handover request, an admission control procedure (that may involve, for example, directly and / or indirectly communicating with one or more nodes or functions of the core network 10). For example, the target RAN node 5Tmay perform a validation procedure that may involve checking that if a connection is established between the UE 3 and the target RAN node 5Tthen current resources are sufficient for the proposed connection.

[0166] At step S614b having received the handover request at step S614a and having performed admission control at step S616, the target RAN node 5Tmay transmit an appropriate response message to the source RAN node 5Sto acknowledge receipt of the handover request. For example, the target RAN node 5Tmay transmit an acknowledgement of the handover request (which may be referred to as a "handover request acknowledgement" message). The handover request acknowledgement message may include an indication of handover configuration information for the handover that is to be forwarded to the UE 3. This may, for example, form part of a handover command (or similar message) to be sent to the UE 3 and may be provided transparently to the source RAN node 5S(e.g., in an appropriate transparent container or the like). The handover request acknowledgement message may also include configuration information that enables the source RAN node 5Sto begin forwarding user plane data for the UE 3 to the target RAN node 5T.

[0167] By way of example only, the appropriate response message may be an RRC (re)configuration message, or a new RRC message It will be appreciated that where the appropriate handover command message is an RRC (re)configuration message the message may comprise a normal (e.g., legacy) handover command. Alternatively, where the appropriate handover command message is a new RRC message, the message may comprise a handover command based on the measurement prediction made by the AI / ML-based mobility functionality 12.

[0168] Furthermore, where the appropriate handover command message is a new RRC message, the message may include an indication that the handover command being sent to the UE 3 is a special handover command (e.g., a handover command based on a measurement prediction made by an AI / ML-based mobility functionality 12). The special handover command may, by way of example only, also include a prediction probability, such as the prediction probability discussed above with respect to the AI / ML-based mobility functionality 12.

[0169] Additionally, (or alternatively), where the appropriate handover command message is a new RRC message, the message may include some or all of the measurement prediction results in the command. Additionally, (or alternatively), the message may also include one or more indications of special triggering conditions for triggering a handover procedure of the UE 3 from the source RAN node 5Sto the target RAN node 5T.

[0170] In one example, a special triggering condition indicated in the handover command may be that the UE 3 should be triggered to be handed over to the best target cell 9 within a set of target cells 9 that were indicated in the measurement predictions. For example, since a target cell is indicated in the handover command (e.g., cell B), then a triggering condition may be included in the handover command to indicate that the handover should only be performed if the cell 9 indicated in the handover command is the best target cell 9 within the set of target cells 9 that were indicated in the measurement predictions (e.g., cells A / B / C). It will be appreciated that the 'best' target cell 9 may be based on RSRP values of the respective cells 9. For example, the 'best' target cell may be the cell 9 of the set of target cells 9 that were indicated in the measurement predictions with the highest RSRP value or above a RSRP threshold.

[0171] In the above example, the UE 3 may continue to measure the set of target cells 9 that were indicated in the measurement predictions prior to execution of the handover. Furthermore, in this example, a legacy CHO triggering condition (e.g., the target cell's RSRP should be above a configured threshold) may still apply.

[0172] In another example, a special triggering condition indicated in the handover command may be that measurements (e.g., RSRP measurements) of all the target cells 9 that were indicated in the measurement predictions (e.g., cells A / B / C) should match the corresponding predicted measurements (e.g., predicted RSRP measurements) within a deviation threshold.

[0173] Furthermore, in the examples above, the UE 3 may additionally be configured to verify the handover triggering condition indicated in the handover command message within a specified time period (e.g., based on the expiration of a timer).

[0174] Having received the appropriate handover command message at S618, if one or more of the handover triggering conditions are not met, the UE 3 may decide not to perform a handover procedure (i.e., the UE 3 may skip the execution of the handover procedure indicated in the special handover command). In this scenario, the UE 3 may report the cancellation of the special handover command to the source RAN node 5S.That report of the cancellation may, for example, include a cause value in the report to indicate to the source RAN node 5Sa reason for the cancellation. Additionally, the report of the cancellation may optionally include an indication of a or a plurality of best cell 9 to which the UE 3 could potentially be handed over.

[0175] In response to receiving the report of the cancellation the source RAN node 5Smay send a corresponding cancellation indication / message to the target RAN node 5Tto inform it of the cancellation of the handover. Meanwhile, at the same time, the source RAN node 5Smay initiate a new handover procedure to a new (different) target RAN node 5Tfollowing receipt of the report of the cancellation of the handover from the UE 3.

[0176] It will be appreciated that in the scenario where the AI / ML-based mobility functionality 12 is provided on an entity of the network / communication system 1 that is not the UE 3, source RAN node 5S,or the target RAN node 5T, the source RAN node 5Smay also send an appropriate message to the entity providing the AI / ML-based mobility functionality 12 to inform it of the cancellation of the handover. For example, the source RAN node 5Smay send an appropriate message to the entity providing the AI / ML-based mobility functionality 12 to report that the predictions of the AI / ML-based mobility functionality 12 were incorrect. The AI / ML-based mobility functionality 12 may in turn evaluate the message reporting that the predictions of the AI / ML-based mobility functionality 12 were incorrect to evaluate the performance of the network-sided AI / ML model used.

[0177] If, on the other hand, having received the appropriate handover command message at S618, one or more of the handover triggering conditions are met, then the UE 3, at step S620, may perform a handover procedure to handover the UE 3 from the source RAN node 5Sto the target RAN node 5T. Following the handover procedure, at step S622, the UE 3 may access the new target cell 9 provided by the target RAN node 5T.

[0178] It will be appreciated that in the network-based AI / ML (or prediction)-based handover procedure described above, the measurements to be performed and reported by the UE 3 may be L3 measurements, L1 measurements, or any other type of measurements that can help the network to predict UE mobility and / or to make a handover decision.

[0179] Furthermore, it will be appreciated that in the network-based AI / ML (or prediction)-based handover procedure described above, at S610 an L3 type handover decision, and / or an LTM-type handover decision may be made.

[0180] Performance Monitoring 　　As already indicated above, the entity providing the AI / ML-based mobility functionality 12 may be configured to evaluate messages from the source RAN node 5Sreporting that the predictions of the AI / ML-based mobility functionality 12 were incorrect in order to evaluate the performance of the network-sided AI / ML model used (i.e., to evaluate the appropriateness of the prediction-based mobility decision arrived at by the AI / ML-based mobility functionality 12).

[0181] Furthermore, it will be appreciated that the entity providing the AI / ML-based mobility functionality 12 may be configured to evaluate other appropriate information such as information pertaining to a successful handover to also evaluate the performance of the network-sided AI / ML model used (i.e., to evaluate the appropriateness of the prediction-based mobility decision arrived at by the AI / ML-based mobility functionality 12).

[0182] Such evaluations will now be discussed in further detail. In one example, to check the outcome of the prediction-based mobility decision, appropriate information pertaining to the success of a handover performed may be sent from the target RAN node 5Tto the source RAN node 5Sfollowing completion of the handover of the UE 3 from the source RAN node 5Sto the target RAN node 5T. Additionally, (or alternatively), the UE 3 may send appropriate information pertaining to the success of the execution of the handover performed to the target RAN node 5T. That information may in turn serve as input data to a model training function of the AI / ML-based mobility functionality 12 to further refine the AI / ML model e.g., as described with reference to Figs. 4 & 5.

[0183] Additionally, (or alternatively), the source RAN node 5Smay include an AI / ML transaction ID, or the like, in the handover request message sent to the target RAN node 5Tat step S614a, and / or in the handover command message that the source RAN node 5Ssends to the UE 3 at step S618. At the same time, the appropriate information pertaining to the success of a handover performed that is sent from the target RAN node 5Tto the source RAN node 5Sfollowing completion of the handover of the UE 3 may include a corresponding UE ID and / or AI / ML transaction ID to enable the source RAN node 5Sand / or the AI / ML-based mobility functionality 12 to map each prediction-based mobility decision to the corresponding outcome of the prediction-based mobility decision.

[0184] Furthermore, it will be appreciated that prior to the source RAN node 5Sperforms prediction-based handover of a UE 3 to a target RAN node 5T, the source RAN node 5Smay exchange appropriate information with the target RAN node 5Tvia an appropriate interface (e.g., the so-called 'X2' interface or 'Xn' interface) to indicate to each other their capability to perform AI / ML-based (or prediction based) handovers with neighbouring RAN nodes 5. During this co-ordination, the source RAN node 5Sand / or target RAN node 5Tmay indicate its need to collect outcome information of the handover from its counterpart.

[0185] AI / ML (or prediction)-based beam switching 　　It will be appreciated that when a UE 3 is moving, the network should ideally serve the UE 3 with the best beam. Moreover, the UE 3 may experience a beam failure, which leads to service interruption, since conventional beam failure recovery (BFR) generally does not happen until after beam failure detection (BFD) because it relies on a timer-based operation.

[0186] The network-based AI / ML (or prediction)-based handover procedure described above with reference to Fig. 6A and 6B, may beneficially be adapted for network-based AI / ML (or prediction)-based beam switching procedures. Specifically, the UE 3 can be configured by the network to perform measurements on a set comprising one or more beams for a certain serving cell 9 at one or multiple reference time points within a configured time window, and the UE 3 can then report these configured measurements to the RAN node 5.

[0187] The implementation of an AI / ML model for network-based AI / ML (or prediction)-based beam switching procedures will now be discussed in more detail with reference to Fig. 7A and 7B.

[0188] Fig. 7A depicts a simplified sequence diagram illustrating a network-based AI / ML (or prediction)-based beam switching procedure that may be used in the communication system 1 of Fig. 1.

[0189] It will be appreciated that step S702 to S710 in Fig. 7A and steps S602 to S610 in Fig. 6A are the same (or highly similar) and thus the corresponding description above with reference to S602 to S610 applies also to step S702 to S710.

[0190] Nevertheless, it will also be appreciated that the measurement configuration information included in the measurement configuration message transmitted at step S702 may be different to that included in the measurement configuration message transmitted at step S602. For example, the measurement configuration message transmitted at step S702 may be focussed on beam level measurements and need not, for example, configure the UE 3 to perform and report measurements for non-serving (e.g., neighbouring) cells 9, although such a configuration is possible (e.g., to allow the network to make beam-based predictions, cell-based predictions, or both, based on all or an appropriate subset of the measurement results).

[0191] Accordingly, at step S702, the measurement configuration message sent by the source RAN node 5Smay configure the UE 3 to perform and report measurements for one or more (e.g., a set) of beams for a serving cell 9 of the source RAN node 5Sat one or multiple reference time points within a configured time window.

[0192] It will also be appreciated that the measurement configuration message may not configure the UE 3 to perform measurements of specific beams if the overheads associated with measurement reports needs to be controlled. For example, the measurement configuration message may only configure the UE 3 to measure a subset of beams provided by the source RAN node 5S.

[0193] Having received the measurement configuration message at step S702, the UE 3 may perform measurements according to the measurement configuration message at step S704, as described with reference to step S604 in Fig. 6A.

[0194] Then, at step S706, the UE 3 may report the results of the measurements the UE 3 performed according to the measurement configuration message to the source RAN node 5Sas described with reference to step S606 in Fig. 6A.

[0195] When the source RAN node 5Sreceives the measurement report, if the prediction is conducted by the source RAN node 5Sitself, it may run the AI / ML inference for performing a beam failure or related prediction (a measurement prediction and / or a mobility prediction may also be performed here) for the UE 3. Based on the prediction or predictions the UE 3 may make a beam switch decision.

[0196] Alternatively, if the prediction is conducted by a specific AI / ML-based mobility functionality 12 hosted by an entity of the network other than the source RAN node 5S(as shown in Fig. 7A and 7B), the source RAN node 5S, at step S708a, sends / forwards the message carrying the results and / or other information received from the UE 3 at S706 (or at least some of the contents of the message) to the entity hosting the AI / ML-based mobility functionality 12.

[0197] Once sent / forwarded to the entity hosting the AI / ML-based mobility functionality 12, the entity hosting the AI / ML-based mobility functionality 12 may, at step S708b, send an appropriate response message to the source RAN node 5Sto acknowledge receipt of the measurement report.

[0198] At step S710, the AI / ML-based mobility functionality 12 hosted at the entity may run the AI / ML inference for performing a beam failure or related prediction (a measurement prediction and / or a mobility prediction may also be performed here) for the UE 3. For example, the AI / ML model may predict the best beam for a future time instance, or predict a potential beam failure event, based on the beam measurements reported by the UE 3. It will be appreciated that all or a subset of the information provided in the UE assistance information or measurement report forward may be provided as an input to the AI / ML model, which in turn output appropriate predictions.

[0199] Fig. 7B depicts a continuation of the simplified sequence diagram illustrating the network-based AI / ML (or prediction)-based beam switching procedure that may be used in the communication system 1 of Fig. 1.

[0200] At step S712 the specific AI / ML-based mobility functionality 12 hosted by the entity may send the outcome of the AI / ML inference to the source RAN node 5Sof the UE 3. That outcome of the AI / ML inference may include a beam failure or related prediction (and possibly a measurement prediction and / or a mobility prediction) and / or a beam switch decision for the UE 3. For example, the measurement prediction may include any appropriate information about the serving cell 9 of the source RAN node 5Sincluding, amongst other things, indications of the beams provided by the serving cell 9, and their predicted status at some future time (e.g., predicted quality).By way of example, the measurement prediction may also include indications of a time interval for the prediction or predictions, a time window for the prediction or predictions, or a number of prediction instances, and a prediction probability.

[0201] In one possible procedure, at step S718a the source RAN node 5Smay send an appropriate beam report message to the UE 3 to trigger the UE 3 to switch beams that it is using to communicate with the source RAN node 5S. For example, the beam report message may include an indication of one or more 'best' beams for use at some future time instance based on a prediction made by the AI / ML-based mobility functionality 12.

[0202] Additionally, (or alternatively), the beam report message may include a prediction pertaining to a future beam failure event for the current beam that the source RAN node 5Sand UE 3 are communicating over.

[0203] Additionally, (or alternatively), the beam report message may include a prediction probability of which beams will be the 'best' beams for use at some future time instance and / or a prediction probability of a future beam failure event, such as the prediction probability discussed above with respect to the AI / ML-based mobility functionality 12.

[0204] Additionally, (or alternatively), where the beam report message may also include one or more indications of triggering conditions for triggering a beam switching procedure of the UE 3.

[0205] Having received the beam report message at S718a, if one or more triggering conditions are not met, the UE 3 may decide not switch beams. In this scenario, the UE 3 may report to the source RAN node 5Sthat it will not switch beams.That report may, for example, include a cause value in the report to indicate to the source RAN node 5Sa reason for not switching beams. Additionally, the report may optionally include an indication of a or a plurality of best beam to which the UE 3 could potentially be handed over.

[0206] It will be appreciated that in the scenario where the AI / ML-based mobility functionality 12 is provided on an entity of the network that is not the UE 3, or the source RAN node 5S,the source RAN node 5Smay also send an appropriate message to the entity providing the AI / ML-based mobility functionality 12 to inform it that the UE 3 decided not to perform the beam switch. For example, the source RAN node 5Smay send an appropriate message to the entity providing the AI / ML-based mobility functionality 12 to report that the prediction or predictions of the AI / ML-based mobility functionality 12 were incorrect. The AI / ML-based mobility functionality 12 may in turn evaluate the message reporting that the prediction or predictions were incorrect to evaluate the performance of the network-sided AI / ML model used.

[0207] If, on the other hand, having received the beam report message at S718a, one or more triggering conditions are met, then the UE 3, at step S720a, may perform a beam switching procedure to switch the beam used for communicating with the source RAN node 5S. Following the procedure, at step S722a, the UE 3 may communicate with the source RAN node 5Sover the new beam.

[0208] In another possible procedure, a step S718b the source RAN node 5Smay send an appropriate L3 beam reconfiguration message to the UE 3 to trigger the UE 3 to switch beams that it is communicating over with the source RAN node 5S. For example, the L3 beam reconfiguration message may include an indication of one or more 'best' beams for use at some future time instance based on the measurement prediction made by the AI / ML-based mobility functionality 12.

[0209] Additionally, (or alternatively), the L3 beam reconfiguration message may include a prediction pertaining to a future beam failure event for the current beam that the source RAN node 5Sand UE 3 are communicating over.

[0210] Additionally, (or alternatively), the L3 beam reconfiguration message may include a prediction probability of which beams will be the 'best' beams for use at some future time instance and / or a prediction probability of a future beam failure event, such as the prediction probability discussed above with respect to the AI / ML-based mobility functionality 12.

[0211] Additionally, (or alternatively), L3 beam reconfiguration message may also include one or more indications of triggering conditions for triggering a beam switching procedure of the UE 3.

[0212] Having received the L3 beam reconfiguration message at S718b, if one or more triggering conditions are not met, the UE 3 may decide not switch beams. In this scenario, the UE 3 may report to the source RAN node 5Sthat it will not switch beams.That report may, for example, include a cause value in the L3 beam reconfiguration message to indicate to the source RAN node 5Sa reason for not switching beams. Additionally, the L3 beam reconfiguration message may optionally include an indication of a or a plurality of best beam to which the UE 3 could potentially be handed over.

[0213] It will be appreciated that in the scenario where the AI / ML-based mobility functionality 12 is provided on an entity of the network that is not the UE 3, or the source RAN node 5S,the source RAN node 5Smay also send an appropriate message to the entity providing the AI / ML-based mobility functionality 12 to inform it that the UE 3 decided not to perform the beam switch. For example, the source RAN node 5Smay send an appropriate message to the entity providing the AI / ML-based mobility functionality 12 to report that the prediction or predictions of the AI / ML-based mobility functionality 12 were incorrect. The AI / ML-based mobility functionality 12 may in turn evaluate the message reporting that the prediction or predictions were incorrect to evaluate the performance of the network-sided AI / ML model used.

[0214] If, on the other hand, having received the L3 beam reconfiguration message at S718b, one or more triggering conditions are met, then the UE 3, at step S720b, may perform a beam switching procedure to switch the beam used for communicating with the source RAN node 5S. Following the procedure, at step S722b, the UE 3 may communicate with the source RAN node 5Sover the new beam.

[0215] It will be appreciated that in the network-based AI / ML (or prediction)-based beam switching procedure described above, the measurements to be performed and reported by the UE 3 may be L3 measurements, L1 measurements, or any other type of measurements that can help the network to predict UE mobility and / or to make a beam switch decision.

[0216] Devices of the Communication System User Equipment 　　Fig. 8 is a simplified block schematic illustrating the main components of a UE 3 for implementation in the communication system 1 of Fig. 1.

[0217] 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 antenna 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 3 (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.

[0218] 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 communication control module 43.

[0219] 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 communication 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 communication 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 communication (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.

[0220] 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.

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

[0222] RAN node 　　Fig. 9 is a simplified block schematic illustrating the main components of a RAN node 5 for implementation in the communication system 1 of Fig. 1.

[0223] As shown, the RAN node 5 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 antenna 53 (e.g., a single or multi-panel antenna array / massive antenna), and a core network interface 55 for transmitting signals to and for receiving signals from network nodes in the core network 7. Although not shown, the RAN node 5 may also be coupled to other RAN nodes via an appropriate interface (e.g., the so-called 'X2' interface in LTE or the 'Xn' interface in NR). The RAN node 5 has a controller 57 to control the operation of the RAN node 5. 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 by, in this example, program instructions or software instructions stored within memory 59.

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

[0225] The communication control module 63 is operable to control the communication between the RAN node 5 and UEs 3 and other network entities (e.g., core network nodes) that communicate with the RAN node 5. The communication control module 63 is configured for the overall control of the reception and decoding of uplink communication, 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 communication control module 63 is also configured for the overall control of the transmission of downlink communication 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-persistent scheduling (e.g., SPS). The communication control module 63 is responsible, for example: for determining where to configure the UE 3 to monitor for downlink control information (e.g., the location of search spaces, CORESETs, and associated PDCCH candidates to monitor); for determining the resources to be scheduled for UE transmission / reception of UL / DL communication (including interleaved resources and resources subject to frequency hopping); for managing frequency hopping at the RAN node side; for configuring slots / symbols appropriately (e.g., for UL, DL or full duplex communication, or the like); for configuring bandwidth parts for the UE 3; for providing related configuration signalling to the UE 3; and the like.

[0226] It will be appreciated that the communication control module 63 may include a number of sub-modules ('layers' or 'entities') to support specific functionalities. For example, the communication control module 63 may include, for communicating with a UE 3, a PHY sub-module, a MAC sub-module, an RLC sub-module, a PDCP sub-module, an RRC sub-module, etc. Moreover, the communication control module 63 may include, for communicating with a core network entity such as an MME (or similar node such as an AMF 10-1), an S1 application protocol (S1-AP) sub-module, a stream control transmission protocol (SCTP) sub-module, an IP sub-module, a layer 1 (L1) sub-module, a layer 2 (L2) sub-module, etc (or corresponding sub-modules for communicating with an AMF 10-1).

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

[0228] 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 enhancements embodied therein.

[0229] Whilst the network may include a primary node / function that hosts the AI / ML model and generates the AI / ML model inferences, alternatively the AI / ML model may be distributed amongst various nodes in the network. For example, a plurality of RAN nodes 5 may host the AI / ML model and generate inferences. Whilst this may increase the processing required at some network nodes, when the AI / ML model is distributed amongst the network nodes there is a reduction in the number of inferences that are transmitted between the nodes.

[0230] When the AI / ML model (or a plurality of AI / ML models - the same model need not necessarily be used at each node) is provided at a plurality of RAN nodes, the feedback information can still be provided to each of the RAN nodes that generates inferences using the AI / ML model (for example, to verify the accuracy of the model, as described above).

[0231] Furthermore, while the above description describes a 'one-sided' model, it will nevertheless be appreciated that the AI / ML model may be a 'two-sided' model, in which an AI / ML model is hosted at the UE 3, and a corresponding AI / ML model is hosted at the source RAN node 5S, a central entity of the communication system 1, or an OAM / OTT server. It will also be appreciated the models need not necessarily be hosted at a UE 3 and the source RAN node 5S, a central entity of the communication system 1, or an OAM / OTT server - any other suitable two network nodes could alternatively be used). The AI / ML model hosted at the UE 3 and the AI / ML model hosted at the source RAN node 5S, a central entity of the communication system 1, or an OAM / OTT server may be the same AI / ML model (but need not necessarily be the same model). The UE 3 can use the AI / ML model to generate a first inference, and the source RAN node 5S, a central entity of the communication system 1, or an OAM / OTT server can use the AI / ML model to generate a corresponding second inference. 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 source RAN node 5S, a central entity of the communication system 1, or an OAM / OTT server.

[0232] Other Modifications and Alternatives 　　It will also be appreciated, for example, that description of features of and actions performed by a RAN node / RAN node (or eNB or gNB), apply equally to distributed type RAN nodes / RAN nodes as to non-distributed type RAN nodes / RAN nodes.

[0233] 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.

[0234] In the above description the UE and the RAN node 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.

[0235] 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 RAN node 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 RAN node in order to update their functionalities.

[0236] 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.

[0237] 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.

[0238] 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.

[0239] 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.

[0240] 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.).

[0241] 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.).

[0242] 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.).

[0243] 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.).

[0244] 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.).

[0245] 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.

[0246] 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)).

[0247] 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.

[0248] 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.

[0249] It will be appreciated that IoT technology can be implemented on any communication devices 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.

[0250] 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.

[0251] 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.

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

[0253] For example, the whole or part of the exemplary 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 configuration information indicating a time window for measurements for use by a network in a prediction using an artificial intelligence (AI) / machine learning (ML) model; 　　transmitting measurement information including at least one measurement result for each reference time point within the time window corresponding to the measurements; 　　receiving information indicating at least one condition for handover, derived based on the prediction by the network; and 　　determining whether to initiate the handover by determining whether one or more of the at least one condition have been met. 　　(Supplementary note 2) 　　The method according to supplementary note 1, wherein 　　the configuration information includes information indicating the each reference time point, and 　　the information indicating the each reference time point indicates at least one of: 　　　　a time interval for the measurements, or 　　　　a number of instances for the measurements to be reported. 　　(Supplementary note 3) 　　The method according to supplementary note 1 or 2, wherein 　　the configuration information includes at least one of: 　　　　information indicating at least one beam for the measurements for the prediction, or 　　　　information indicating a respective type of the at least one beam for the measurements for the prediction. 　　(Supplementary note 4) 　　The method according to any one of supplementary notes 1 to 3, wherein 　　the time window is configured for each type of the measurements. 　　(Supplementary note 5) 　　The method according to any one of supplementary notes 1 to 4, wherein 　　the at least one measurement result is included in the measurement information for each beam indicated by the configuration information for at least one of each serving cell or each neighbor cell. 　　(Supplementary note 6) 　　The method according to any one of supplementary notes 1 to 5, wherein 　　the at least one condition indicates a condition time window, and the method comprises: 　　cancelling to initiate the handover in a case where the one or more of the at least one condition cannot be met during the condition time window. 　　(Supplementary note 7) 　　The method according to supplementary note 6, further comprising: 　　transmitting cancellation information for informing the cancelling to initiate the handover, and wherein 　　the cancellation information includes at least one of: 　　　　a cause value, or 　　　　information indicating at least one candidate cell for the handover. 　　(Supplementary note 8) 　　The method according to any one of supplementary notes 1 to 5, further comprising: 　　transmitting information indicating an execution to initiate the handover in a case where the one or more of the at least one condition have been met, for use by the network in training the AI / ML model. 　　(Supplementary note 9) 　　The method according to any one of supplementary notes 1 to 8, wherein 　　the handover includes at least one of: 　　　　a layer 3 conditional handover, 　　　　a lower layer triggered mobility (LTM), or 　　　　a beam switching. 　　(Supplementary note 10) 　　The method according to any one of supplementary notes 1 to 9, wherein 　　the measurements include at least one of: 　　　　layer 1 measurements, or 　　　　layer 3 measurements. 　　(Supplementary note 11) 　　The method according to any one of supplementary notes 1 to 10, wherein 　　the measurement information includes at least one of: 　　　　an identity of an entity which performs the prediction, or 　　　　information indicating mobility of the mobile device. 　　(Supplementary note 12) 　　The method according to any one of supplementary notes 1 to 11, wherein 　　the measurement information is included in assistance information or a measurement report. 　　(Supplementary note 13) 　　The method according to any one of supplementary notes 1 to 12, wherein 　　the network includes at least one of: 　　　　an access network node, 　　　　a central entity for the prediction, or 　　　　an operations, administration and management (OAM) / over-the-top (OTT) server. 　　(Supplementary note 14) 　　The method according to any one of supplementary notes 1 to 13, wherein 　　the prediction is performed based on at least one of; 　　　　temporal based derivation, 　　　　spatial based derivation, or 　　　　frequency based derivation. 　　(Supplementary note 15) 　　A method performed by an access network node, the method comprising: 　　transmitting configuration information indicating a time window for measurements for use by a network in a prediction using an artificial intelligence (AI) / machine learning (ML) model; 　　receiving measurement information including at least one measurement result for each reference time point within the time window corresponding to the measurements; and 　　transmitting information indicating at least one condition for handover, derived based on the prediction by the network, and wherein 　　the at least one condition is used for determining whether to initiate the handover by determining whether one or more of the at least one condition have been met. 　　(Supplementary note 16) 　　A mobile device comprising: 　　means for receiving configuration information indicating a time window for measurements for use by a network in a prediction using an artificial intelligence (AI) / machine learning (ML) model; 　　means for transmitting measurement information including at least one measurement result for each reference time point within the time window corresponding to the measurements; 　　means for receiving information indicating at least one condition for handover, derived based on the prediction by the network; and 　　means for determining whether to initiate the handover by determining whether one or more of the at least one condition have been met. 　　(Supplementary note 17) 　　An access network node comprising: 　　means for transmitting configuration information indicating a time window for measurements for use by a network in a prediction using an artificial intelligence (AI) / machine learning (ML) model; 　　means for receiving measurement information including at least one measurement result for each reference time point within the time window corresponding to the measurements; and 　　means for transmitting information indicating at least one condition for handover, derived based on the prediction by the network, and wherein 　　the at least one condition is used for determining whether to initiate the handover by determining whether one or more of the at least one condition have been met.

[0254] This application is based upon and claims the benefit of priority from Great Britain Patent Application No. 2403025.6, filed on March 1, 2024, the disclosure of which is incorporated herein in its entirety by reference.

[0255] 1 COMMUNICATION SYSTEM 3 USER EQUIPMENT 5 BASE STATION 7 CORE NETWORK 9 CELL 10 CONTROL PLANE FUNCTIONS 11 USER PLANE FUNCTIONS 12 AI / ML-BASED MOBILITY FUNCTIONALITY 20 EXTERNAL DATA NETWORK 31 TRANSCEIVER CIRCUIT 33 ANTENNA 35 USER INTERFACE 37 CONTROLLER 39 MEMORY 41 OPERATING SYSTEM 43 COMMUNICATIONS CONTROL MODULE 51 TRANSCEIVER CIRCUIT 53 ANTENNA 55 CORE NETWORK INTERFACE 57 CONTROLLER 59 MEMORY 51 OPERATING SYSTEM 53 COMMUNICATIONS CONTROL MODULE 341 DATA COLLECTION 343 MODEL TRAINING 345 INFERENCE 347 ACTOR 349 MANAGEMENT 351 MODEL STORAGE

Claims

1. A method performed by a mobile device, the method comprising: 　　receiving configuration information indicating a time window for measurements for use by a network in a prediction using an artificial intelligence (AI) / machine learning (ML) model; 　　transmitting measurement information including at least one measurement result for each reference time point within the time window corresponding to the measurements; 　　receiving information indicating at least one condition for handover, derived based on the prediction by the network; and 　　determining whether to initiate the handover by determining whether one or more of the at least one condition have been met.

2. The method according to claim 1, wherein 　　the configuration information includes information indicating the each reference time point, and 　　the information indicating the each reference time point indicates at least one of: 　　　　a time interval for the measurements, or 　　　　a number of instances for the measurements to be reported.

3. The method according to claim 1 or 2, wherein 　　the configuration information includes at least one of: 　　　　information indicating at least one beam for the measurements for the prediction, or 　　　　information indicating a respective type of the at least one beam for the measurements for the prediction.

4. The method according to any one of claims 1 to 3, wherein 　　the time window is configured for each type of the measurements.

5. The method according to any one of claims 1 to 4, wherein 　　the at least one measurement result is included in the measurement information for each beam indicated by the configuration information for at least one of each serving cell or each neighbor cell.

6. The method according to any one of claims 1 to 5, wherein 　　the at least one condition indicates a condition time window, and the method comprises: 　　cancelling to initiate the handover in a case where the one or more of the at least one condition cannot be met during the condition time window.

7. The method according to claim 6, further comprising: 　　transmitting cancellation information for informing the cancelling to initiate the handover, and wherein 　　the cancellation information includes at least one of: 　　　　a cause value, or 　　　　information indicating at least one candidate cell for the handover.

8. The method according to any one of claims 1 to 5, further comprising: 　　transmitting information indicating an execution to initiate the handover in a case where the one or more of the at least one condition have been met, for use by the network in training the AI / ML model.

9. The method according to any one of claims 1 to 8, wherein 　　the handover includes at least one of: 　　　　a layer 3 conditional handover, 　　　　a lower layer triggered mobility (LTM), or 　　　　a beam switching.

10. The method according to any one of claims 1 to 9, wherein 　　the measurements include at least one of: 　　　　layer 1 measurements, or 　　　　layer 3 measurements.

11. The method according to any one of claims 1 to 10, wherein 　　the measurement information includes at least one of: 　　　　an identity of an entity which performs the prediction, or 　　　　information indicating mobility of the mobile device.

12. The method according to any one of claims 1 to 11, wherein 　　the measurement information is included in assistance information or a measurement report.

13. The method according to any one of claims 1 to 12, wherein 　　the network includes at least one of: 　　　　an access network node, 　　　　a central entity for the prediction, or 　　　　an operations, administration and management (OAM) / over-the-top (OTT) server.

14. The method according to any one of claims 1 to 13, wherein 　　the prediction is performed based on at least one of; 　　　　temporal based derivation, 　　　　spatial based derivation, or 　　　　frequency based derivation.

15. A method performed by an access network node, the method comprising: 　　transmitting configuration information indicating a time window for measurements for use by a network in a prediction using an artificial intelligence (AI) / machine learning (ML) model; 　　receiving measurement information including at least one measurement result for each reference time point within the time window corresponding to the measurements; and 　　transmitting information indicating at least one condition for handover, derived based on the prediction by the network, and wherein 　　the at least one condition is used for determining whether to initiate the handover by determining whether one or more of the at least one condition have been met.

16. A mobile device comprising: 　　means for receiving configuration information indicating a time window for measurements for use by a network in a prediction using an artificial intelligence (AI) / machine learning (ML) model; 　　means for transmitting measurement information including at least one measurement result for each reference time point within the time window corresponding to the measurements; 　　means for receiving information indicating at least one condition for handover, derived based on the prediction by the network; and 　　means for determining whether to initiate the handover by determining whether one or more of the at least one condition have been met.

17. An access network node comprising: 　　means for transmitting configuration information indicating a time window for measurements for use by a network in a prediction using an artificial intelligence (AI) / machine learning (ML) model; 　　means for receiving measurement information including at least one measurement result for each reference time point within the time window corresponding to the measurements; and 　　means for transmitting information indicating at least one condition for handover, derived based on the prediction by the network, and wherein 　　the at least one condition is used for determining whether to initiate the handover by determining whether one or more of the at least one condition have been met.

Images