Method performed by a mobile device, method performed by an access network node, mobile device and access network node

Abstract

An aspect of this disclosure includes a method of a mobile device. The method includes receiving, from an access network node, first information of model configuration of an artificial intelligence / machine learning (AI / ML) model used for prediction of at least one of a radio link failure (RLF) or a hand over failure (HOF), second information of prediction configuration of the prediction and third information of report configuration of a report correspdonding to the prediction; and transmitting, to the access network node, a report corresponding to the prediction based on the first information, the second information and the third information.

Description

METHOD PERFORMED BY A MOBILE DEVICE, METHOD PERFORMED BY AN ACCESS NETWORK NODE, 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 or equivalents or derivatives thereof (including Long Term Evolution (LTE)-Advanced, Next Generation or 5G / 6G networks, future generations, and beyond). The present disclosure in particular, but not exclusively, relates to the prediction of radio link failure (RLF) events / occurrences using Artificial Intelligence / Machine Learning (AI / ML) models, and triggering, where appropriate, handovers of a User Equipment (UE) from a serving cell to a target cell to avoid the predicted RLF events / occurrences.

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

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

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

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

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

[0009] Furthermore, in an effort to move away from vendor specific deployments, towards deployments in which hardware and software components from different vendors are interoperable and can be mixed and matched, there has been a drive to so-called 'open' interfaces between the various elements of the RAN. In earlier generations the RAN incorporated controllers that were responsible for RAN orchestration and management. With the development of 4G, the overall network architecture became flatter, and the expectation was that, to enable optimal subscriber experience, base stations would use the standardised base station to base station (X2) interface to communicate with each other to handle resource allocation. However, whilst the X2 application protocol was largely standardised, different RAN vendors still produced their own variations of the X2 interface thus making it difficult for a mobile network operator (MNO) to use equipment from more than one RAN vendor in a particular location. More recently there has been a movement back towards the controller concept to allow disaggregation of hardware and software and development of open interfaces between them. This movement is known as 'Open RAN' and whilst it has particular relevance for 5G and future generations it is also applicable to RAN development for earlier generations.

[0010] In the context of 5G, in which many 5G scenarios require low latency, implementation of 5G concepts such as Control and User Plane Separation (CUPS), functional RAN splits and network slicing, require a combination of advanced RAN virtualization and software defined networking (SDN). This has led to the concept of a RAN Intelligent Controller (RIC) being developed as part of the Open RAN movement. The RIC comprises a Non-Real-Time (non-RT) RIC (supporting tasks that require > 1s latency) and a Near-Real Time RIC (latency of <1s).

[0011] The Near-RT RIC is responsible for per-UE controlled load-balancing, radio resource management, interference detection and mitigation. To facilitate this, the Near-RT RIC provides cloud-based infrastructure for controlling a distributed collection of RAN nodes (eNB, gNB, CU, DU) in a particular geographic area via an open "southbound" interface (E2) protocol. The Near-RT RIC also provides open "northbound" interfaces (A1 and O1), to a service management and orchestration (SMO) framework, for operators. The Near-RT RIC hosts micro-service-based applications called xApps that are run by the Near-RT RIC and that can use the E2 interface to collect near real-time information (on a UE basis or a cell basis). These xApps cover functions such as mobility management, admission control, and interference management. The Near-RT RIC also enforces network policies via the E2 interface toward the radios and provides advanced control functionalities with the intention of increasing efficiency and providing improved radio resource management (RRM). These control functionalities make use of analytics and data-driven approaches including advanced machine learning (ML) / artificial intelligence (AI) tools to improve resource management capabilities. The Near-RT RIC's control over the E2 nodes (e.g. eNB, gNB, CU, DU or the like) is steered via the policies and the data provided via the A1 interface from the Non-RT RIC. The RRM functional allocation between the Near-RT RIC and the E2 node is subject to the capability of the E2 node and is controlled by the Near-RT RIC. For example, the near-RT RIC may monitor, suspend / stop, override or control the node via Non-RT RIC enabled policies. The Near-RT RIC may be deployed in a number of ways for example as a virtual network function (VNF), a set of virtual machines (VMs), or as a cloud native function (CNF).

[0012] The Non-RT RIC forms part of the SMO framework and connects to the Near-RT RIC for the management and optimization of the RAN. Network management applications in the Non-RT RIC receive and act on data from the DU and CU provided in a standardised format over the O1 Interface. Non-RT RIC functionality includes configuration management, device management, fault management, performance management, and lifecycle management for all network elements in the network. All new RUs are self-configured by the Non-RT RIC, reducing the need for manual intervention. The provision by the Non-RT RIC of insights into network operations, allows MNOs to better understand and, as a result, better optimize the network by applying pre-determined service and policy parameters. The Non-RT RIC supports intelligent RAN optimisation by providing policy-based guidance, model management and enrichment information to the Near-RT RIC so that the RAN can be optimised efficiently and effectively. The Non-RT RIC can use data analytics and artificial intelligence (AI) / machine learning (ML) training / inference to identify appropriate RAN optimisation actions for which it can use SMO services.

[0013] The separation of functionalities on southbound and northbound interfaces enables more efficient and cost-effective radio resource management for real-time and non-real-time functionalities, as the RIC customizes network optimization for each network environment and use case.

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

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

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

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

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

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

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

[0021] Unfortunately, having accessed a serving cell and begun communications with the network, the UE may, for a variety of different reasons, suffer a radio link failure (RLF) event that disrupts its connection with the network. Such RLF events may occur during a handover (e.g., due to a handover failure (HOF), or the like), or even due to a simple loss of cell connection and cause undesirable service disruption and delays. Having suffered a RLF event the UE has to perform appropriate procedures to access a cell of the network again (e.g., RACH-based, or RACH-less procedures described above).

[0022] It would therefore be beneficial to be able to predict the likelihood of RLF events / occurrences i) within given time windows and / or ii) during handovers, so that the network can pre-emptively trigger a handover of the UE from a serving cell to a new target cell, or in the case of a simple lost connection, to pre-emptively switch the UE from one cell to another, to avoid the occurrence of RLF from the outset. By avoiding the occurrence of RLF events, service disruption and delays can be avoided.

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

[0024] The disclosure has a method performed by a mobile device, the method comprising receiving, from an access network node, first information of model configuration of an artificial intelligence / machine learning (AI / ML) model used for prediction of at least one of a radio link failure (RLF) or a hand over failure (HOF), second information of prediction configuration of the prediction and third information of report configuration of a report correspdonding to the prediction and transmitting, to the access network node, a report corresponding to the prediction based on the first information, the second information and the third information.

[0025] The disclosure has a method performed by an access network node, the method comprising transmitting, to a mobile device, first information of model configuration of an artificial intelligence / machine learning (AI / ML) model used for prediction of at least one of a radio link failure (RLF) or a hand over failure (HOF), second information of prediction configuration of the prediction and third information of report configuration of a report correspdonding to the prediction and eceiving, from the mobile device, a report corresponding to the prediction based on the first information, the second information and the third information.

[0026] The disclosure has a mobile device comprising means for receiving, from an access network node, first information of model configuration of an artificial intelligence / machine learning (AI / ML) model used for prediction of at least one of a radio link failure (RLF) or a hand over failure (HOF), second information of prediction configuration of the prediction and third information of report configuration of a report correspdonding to the prediction and means for transmitting, to the access network node, a report corresponding to the prediction based on the first information, the second information and the third information.

[0027] The disclosure an access network node comprising means for transmitting, to a mobile device, first information of model configuration of an artificial intelligence / machine learning (AI / ML) model used for prediction of at least one of a radio link failure (RLF) or a hand over failure (HOF), second information of prediction configuration of the prediction and third information of report configuration of a report correspdonding to the prediction and means for receiving, from the mobile device, a report corresponding to the prediction based on the first information, the second information and the third information.

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

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

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

[0031] Fig. 1 schematically illustrates a mobile ('cellular' or 'wireless') communication system;Fig. 2 is a simplified sequence diagram illustrating a RAN node-triggered handover procedure that may be implemented in the communication system of Fig. 1;Fig. 3 illustrates a functional framework for artificial intelligence (AI) / machine learning (ML) (AI / ML) models, and how various entities of the framework may interact with one another, that may be implemented in the communication system of Fig. 1;Fig. 4 schematically illustrates a method of training an AI / ML model, and of monitoring the performance of the AI / ML model, that may be implemented in the communication system of Fig. 1;Fig. 5 illustrates a simplified sequence diagram of an example procedure for configuring an AI / ML RLF prediction model stored at a UE in the communication system illustrated in Fig. 1;Fig. 6 illustrates measurement and prediction instances in the temporal domain for two different prediction methodologies that may be implemented in the AI / ML RLF prediction model stored at a UE in the communication system illustrated in Fig. 1;Fig. 7 is a simplified sequence diagram illustrating a RAN node-triggered handover procedure that may be implemented following AI / ML RLF prediction 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.

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

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

[0034] In the communication system 1, user equipments (UEs) 3 (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' 5 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 / later generation core network or evolved packet core network (EPC)) or any other core network.

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

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

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

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

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

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

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

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

[0043] The RAN nodes 5-1, 5-2 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.

[0044] The RAN nodes 5-1, 5-2 are 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.

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

[0046] The RAN nodes 5-1, 5-2 also transmit 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 nodes 5-1, 5-2. 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).

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

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

[0049] 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 3 based on the timing of the received preamble; an uplink grant field indicating the resources to be used in the uplink for a physical uplink shared channel (PUSCH); a frequency hopping flag to indicate whether the UE 3 is to transmit on the PUSCH with or without frequency; a modulation and coding scheme (MCS) field from which the UE 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.

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

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

[0052] <Handovers> 　　The UEs 3 and the RAN nodes 5-1, 5-2 of the communication system 1 are mutually configured for performing handover procedures.

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

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

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

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

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

[0058] An exemplary RAN node triggered handover procedure that may be used in communication system 1, will now be described, by way of example only, with reference to Fig. 2. Fig. 2 is a simplified sequence diagram illustrating a RAN node triggered handover procedure that may be implemented in the communication system 1.

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

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

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

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

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

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

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

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

[0067] As soon as the first RAN node 5-1 receives the response (e.g., the handover request acknowledge message or the like), or as soon as the transmission of the handover command (e.g., the RRC reconfiguration message or the like) is initiated in the downlink, data forwarding may be initiated. A handover execution phase S216 is then initiated, and the UE 3 detaches from the first RAN node 5-1 and synchronises to the second RAN node 5-2 (at S218).

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

[0069] The last phase is the handover completion phase during which the second RAN node 5-2 coordinates with the core network 7 to switch communication to the second RAN node 5-2 (at S222). Once communication has been switched the second RAN node 5-2 initiates a UE context release at the first RAN node 5-1 to release the associated resources of the first RAN node 5-1 (e.g., by sending a UE context release message at S224).

[0070] <Radio Link Failure (RLF)> 　　It will be appreciated that prior to, during, or even after a handover procedure such as that described above with reference to Fig. 2, RLFs may occur.

[0071] For example, if a RLF occurs prior to the UE 3 being successfully handed over from the first RAN node 5-1 to the second RAN node 5-2, the communication system 1 may be said to suffer a handover failure (HOF) known as a 'Too Late Handover' failure. In another example, if a RLF occurs during a handover of the UE 3, or shortly after the completion of a handover of the UE 3 from the first RAN node 5-1 to the second RAN node 5-2, the communication system 1 may be said to suffer a HOF known as a 'Too Early Handover' failure. In yet another example, if a RLF occurs after the UE 3 has been successfully handed over from the first RAN node 5-1 to the second RAN node 5-2 but the second RAN node 5-2 (or the cell it provides to the UE 3) is inappropriate, the communication system 1 may be said to suffer a HOF known as a 'Handover to Wrong Cell' failure.

[0072] Examples of situations where RLFs such as those highlighted above are presented below.

[0073] In one example, while in RRC_CONNECTED mode, the UE 3 typically performs radio link monitoring (RLM) measurements in the active downlink (DL) bandwidth part (BWP) of the cell (e.g., a primary serving cell (PCell)) or cells (e.g., a PCell and a primary secondary serving cell (PSCell)) provided to the UE 3 by a RAN node 5 (e.g., RAN node 5-1) for communication between the UE 3 and the RAN node 5 (e.g., RAN node 5-1).

[0074] The RLM measurements in the active DL BWP of the cell or cells provided to the UE 3 by a RAN node 5 (e.g., RAN node 5-1) may include, for example, measurements of SSBs, CSI-RS, or a combination of SSBs and CSI-RS provided by the RAN node 5 (e.g., RAN node 5-1) to the UE 3 over a cell or cells that the UE 3 and the RAN node communicate.

[0075] Having made those measurements, the UE 3 may detect that radio problems between the UE 3 and the RAN node 5 (e.g., RAN node 5-1) are occurring. For example, the UE 3 may detect radio problems when, based on measurements of the SSBs and / or CSI-RS received from the RAN node 5-1, the UE 3 determines that the reference signal received power (RSRP) and / or the reference signal received quality (RSRQ) of those received SSBs and / or CSI-RS are too low (i.e., they are lower than power and signal quality thresholds configured by the network).

[0076] Having detected that radio problems are occurring between the UE 3 and the RAN node 5 (e.g., RAN node 5-1), the UE 3 may trigger an appropriate radio problem timer (e.g., a T310 timer, or the like) to wait and see whether the radio problems resolve themselves. If, by the time the radio problem timer expires, the detected radio problems persist, the UE 3 may declare a RFL event. It will be appreciated that if, while the radio problem timer is running (e.g., a T310 timer, or the like), a measurement report for a measurement identity for which the timer has been configured is triggered, then the radio problem timer may expire at the point of triggering that measurement report, and the UE 3 may declare a RFL event.

[0077] In another example, the UE 3 may declare a RLF event when the UE 3 is in the process of performing a RACH procedure with a RAN node 5 (e.g., RAN node 5-1, 5-2), and that RACH procedure fails. In yet another example, the UE 3 may declare a RLF event when a radio link control (RLC) failure occurs.

[0078] In yet another example, the UE 3 may declare a RLF event when a communication link between the UE 3 and its current serving RAN node 5 (e.g., RAN node 5-1) fails.

[0079] Once a RLF has been declared by the UE 3, the UE 3 may stay in RRC_CONNECTED mode if the RLF does not relate to the serving cell (e.g., the PCell). Where the RLF has occurred over the serving cell, the UE 3 may select an alternative suitable cell (either provided by the same RAN node 5 or a different RAN node 5 as appropriate) and initiate an appropriate RRC re-establishment procedure. Where the RLF has occurred over the serving cell, if the UE 3 is unable to select a suitable cell, or a suitable cell is not found by the UE 3 within a preconfigured period of time after the RLF is declared, the UE 3 may enter RRC_IDLE mode.

[0080] It will be appreciated that the occurrence of such RLF events reduces the stability of the communication system 1 in general, and also reduces its efficiency given that, when RLF events occur, the UE 3 has to search out new cells to communicate with the network on and perform suitable RRC re-establishment procedures.

[0081] Given the reduction in stability of the communication system 1 caused by RLF events, and the inefficiencies they subsequently cause in the network, it is desirous to develop appropriate procedures and mechanisms that enable the prediction of RLF events, including but not limited to, when they are likely to occur so that, for example, suitable handover procedures can be initiated and completed in advance of the RLF event, thereby reducing the occurrence of such RLF events, and the instabilities and inefficiencies they cause.

[0082] Additionally, it may be beneficial to develop appropriate procedures and mechanisms that enable the triggering of appropriate handover procedures and / or cell switching procedures based on the prediction of RLF events to reduce the occurrence of such RLF events, and the instabilities and inefficiencies they cause.

[0083] New procedures and methods for implementing AI / ML models in a communication system to predict RLF events, and to trigger suitable mobility procedures based on those predictions will now be described, by way of example only, with reference to Figs. 3 to 7.

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

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

[0086] The support for such AI / ML features may involve different levels of collaboration between the network (RAN node 5 and / or core network 7) and 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 a RAN node 5 and the UE 3. Here, the RAN node 5 and the UE 3 are aware of available models (before operation), and the RAN node 5 is only required to activate / deactivate the models residing at the UE 3 when needed. - Level z: Signalling-based collaboration with AI / ML model transfer (e.g., where an AI / ML model is transferred to the UE 3 when needed).

[0087] The AI / ML model types that are supported in the communication system 1 may include, for example: 　　- Single-sided model: A single-sided AI / ML model is an AI / ML model that is deployed (hosted) only at the UE side or at the network side. For example, an AI / ML model may be hosted (stored, for generating inferences) at the UE 3, the RAN node 5, or a central entity of the communication system 1, or an operations, administration, and maintenance (OAM) / over-the-top (OTT) server. When the AI / ML model is used at the UE 3, the RAN node 5, a central entity of the communication system 1, or an OAM / OTT server only, the AI / ML model may be referred to as a 'single-sided' model. An example of this type of 'single-sided' model is an AI / ML model for beam prediction in time, which can be deployed at the UE side. 　　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 - e.g., a central entity of the communication system 1, or an OAM / OTT server - and then transferred to the UE 3 for use at the UE 3. 　　- 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. An inference using a two-sided model is performed jointly across the nodes at which the AI / ML models of the two-sided model are deployed. The joint inference may comprise, for example, a first part of the inference being performed at one node (e.g., the UE 3 or the RAN node 5), and then the remaining part may be performed by the other (e.g., the RAN node 5 or the UE 3). It will be appreciated that whilst the AI / ML model hosted at the different nodes may be the same AI / ML model, they need not necessarily be the same model. One example of this type of model is, for example only, channel state information (CSI) compression, where the UE 3 performs CSI compression and network performs CSI decompression. As with the single-sided model case, the two-sided model (or models) may be trained at any suitable network node, and then transmitted to the UE 3 and the RAN node 5 (or other respective node or nodes).

[0088] 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. 3 and 4.

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

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

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

[0092] 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 5 that obtains the data may generate the AI / ML model output).

[0093] The model training function 343 performs the AI / ML model training, validation, and testing, and may generate model performance metrics as part of a model testing procedure. The model training function 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).

[0094] 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 prediction of mobility (e.g., expected path, route or trajectory, inter-cell, or inter-beam mobility, or expected handover) of the UE 3, or one or more parameters for use in encoding or decoding transmissions between the RAN node 5 and the UE 3. The model inference function 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.

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

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

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

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

[0099] Fig. 4 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. 4, 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.

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

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

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

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

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

[0105] <Implementation of an AI / ML RLF Prediction Model> <Configuring an AI / ML RLF Prediction Model> 　　Fig. 5 illustrates a simplified sequence diagram of an example procedure for configuring an AI / ML RLF prediction model in the communication system 1 illustrated in Fig. 1.

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

[0107] At step S502, the UE 3 reports, in an appropriate message (e.g., a UE capability message, or the like), its capability to generate AI / ML inferences using an AI / ML model located at the UE 3. For example, the message sent to the serving RAN node 5-1 at step S502 may include an appropriate indication of the functionality of the UE 3, including its functionality to support the generation of RLF predictions the using an AI / ML model located at the UE 3 - e.g., predictions as to whether RLF events / occurrences are likely to occur at some future time point, which may take the form of a probability of whether a RLF event / occasion is likely to occur at some future time point.

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

[0109] For example, the message sent at step S502 may include an identity (e.g., ID) of an AI / ML model (or models) stored at the UE 3 that can generate RLF predictions.

[0110] Additionally, (or alternatively), the message sent at step S502 may include, for each AI / ML model stored at the UE 3, a list of observation windows that are supported by the AI / ML model. For example, the message may include, for each AI / ML model, an indication of an observation window (e.g., a timing window) comprising one, or a multiple number of observation windows configured for performing RRM measurements and / or RRM measurement predictions, or the like, which may form part of the input to the AI / ML model for each RLF prediction that is to be made by the model.

[0111] Additionally, (or alternatively), the message sent at step S502 may include, for each AI / ML model provided at the UE 3, a list of prediction windows that are supported by the AI / ML model. For example, the message may include, for each AI / ML model, an indication of a prediction window (e.g., a timing window) which defines a time frame in which the UE 3 can make each RLF prediction. It will be appreciated that the prediction window may follow a specific observation window, or a specific number of observation windows configured for performing RRM measurements, or the like, which may form part of the input fed to the AI / ML model.

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

[0113] In one example, the message may include, for each AI / ML model, an indication that the AI / ML model can perform RLF predictions based on (predicted) measurements (which can be seen as a type of 'indirect' prediction) such as (predicted) RRM measurements, or the like. For example, the message may indicate that, for each AI / ML model, the AI / ML model can perform RLF predictions based on (predicted) layer-1 (L1) RSRP values of SSBs and / or CSI-RS, (predicted) layer-3 (L3) RSRP values of SSBs and / or CSI-RS, (predicted) signal-to-interference and noise ratio (SINR) values, or the like.

[0114] It will be appreciated that in this scenario, the AI / ML model at the UE 3 may generate those predicted RRM measurements using real (e.g., live) RRM measurements as an initial input to the AI / ML model. Once generated, those predicted RRM measurements may be fed back into the AI / ML model (or another AI / ML model at the UE 3) to generate a RLF prediction.

[0115] In another example, the message may include, for each AI / ML model, an indication that the AI / ML model can perform RLF predictions based on historic events including RLF events and / or handover failure that have previously occurred in the communication system 1 (which can be seen as a type of 'direct' prediction). In this scenario, the message sent at S502 may also include an appropriate indication as to whether or not corresponding assistant historic information may be required from the serving RAN node 5-1 for AI / ML model input.

[0116] Additionally (or alternatively), the message sent at step S502 may include, by way of example, appropriate indications of a maximum number of cells that may be used for generating RLF predictions. For example, the message may indicate the maximum number of neighbouring cells (in addition to the serving cell) the UE 3 can make RRM measurements and / or RRM measurement predictions for, for subsequent input to an AI / ML model stored at the UE 3 for generation of RLF predictions. Alternatively, (or additionally), the message may indicate the maximum number of neighbouring cells (in addition to the serving cell) whose historic RLF events can be input to an AI / ML model stored at the UE 3 for generation of RLF predictions.

[0117] Additionally (or alternatively), the message sent at step S502 may include, by way of example, appropriate indications of a maximum number of events that may be used for generating RLF predictions. For example, the message may indicate the maximum number of events (e.g., the number of historic events such as historic RLF events that have occurred before in the communication system 1, or the like) that the UE 3 can use as inputs to an AI / ML model stored at the UE 3 for generation of RLF predictions.

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

[0119] At step S504, the serving RAN node 5-1 sends an appropriate first configuration message (e.g., AI / ML model Configuration for RLF Predictions) to the UE 3 to configure the UE 3 and / or the AI / ML model (or models) stored at the UE 3. For example, based on the UE capability report sent to the serving RAN node 5-1 at step S502, the serving RAN node 5-1 may send a first configuration message to the UE 3 to activate an AI / ML model stored at the UE 3 and / or configure the type of inputs that the UE 3 may use with that AI / ML model for generating RLF predictions.

[0120] For example, the first configuration message may include an appropriate indication or trigger to activate a specific AI / ML model stored at the UE 3. For example, the first configuration message may include an identity (ID) of a specific AI / ML model stored at the UE 3 to activate that specific AI / ML model (i.e., to trigger the UE 3 to use the specific AI / ML model identified in the configuration message for making RLF predictions).

[0121] Additionally, (or alternatively), where the UE capability message sent at step S502 indicates that the AI / ML model can perform RLF predictions based on predicted measurements (which can be seen as a type of 'indirect' prediction) such as predicted RRM measurements, or the like, the first configuration message may configure a variety of different measurement parameters that may be used by the AI / ML model as inputs. For example, the first configuration message may indicate to the UE 3 that it is to use real (e.g., live) measurements associated with the serving cell as an input to the AI / ML model for RLF prediction. By way of example only, such real (e.g., live) measurements may include measured layer-1 (L1) RSRP values of SSBs and / or CSI-RS, measured layer-3 (L3) RSRP values of SSBs and / or CSI-RS, measured signal-to-interference, and noise ratio (SINR) values, or the like.

[0122] It will be appreciated that those measurements may be used by the AI / ML model as an initial set of inputs to predict other measurements associated with some later time (e.g., predicted L1 RSRP values of SSBs and / or CSI-RS, predicted L3 RSRP values of SSBs and / or CSI-RS, predicted SINR values, or the like), which may be subsequently fed back into the AI / ML model (or another AI / ML model) to generate RLF predictions.

[0123] Additionally, (or alternatively), the first configuration message sent at step S504 may indicate to the UE 3 that it is to use real or predicted measurements associated with one or more neighbouring cells as an input to the AI / ML model for RLF prediction. By way of example only, such real (e.g., live) and / or predicted measurements may include measured / predicted L1 RSRP values of SSBs and / or CSI-RS, measured / predicted L3 RSRP values of SSBs and / or CSI-RS, measured / predicted SINR values, or the like, of one or more neighbouring cells. It will be appreciated that in this scenario, the first configuration message may also include a list of those one or more neighbouring cells.

[0124] Additionally, (or alternatively), in the scenario where the UE 3 is to use other predicted measurements (e.g., predicted RRM measurements) as an input to the AI / ML model for RLF prediction, which are generated on initial real (e.g., live) measurements input to the AI / ML model, the first configuration message sent at step S504 may configure a variety of further measurement parameters to assist the UE 3 to perform the necessary initial measurements.

[0125] For example, where the UE 3 is to use other predicted measurements as an input to the AI / ML model for RLF prediction, the AI / ML model may initially generate those other predicted measurements (e.g., predicted L1 RSRP values of SSBs and / or CSI-RS, predicted L3 RSRP values of SSBs and / or CSI-RS, predicted SINR values, or the like), based on real measurements as an initial input to the AI / ML model (e.g., measured L1 RSRP values of SSBs and / or CSI-RS, measured L3 RSRP values of SSBs and / or CSI-RS, measured SINR values, or the like). In that case, the first configuration message sent at step S504 may configure L3 filtering parameters, measurement period parameters, consolidation parameters, and the like, which may be used to assist the UE 3 to make those real measurements for initial input to the AI / ML model.

[0126] By way of example only, the first configuration message sent at step S504 may configure L3 filtering parameters, measurement period parameters, consolidation parameters such as: an intra-frequency measurement period for the FR1 frequency range and / or an intra-frequency measurement period for the FR2 frequency range; an inter-frequency measurement period for the FR1 frequency range and / or an inter-frequency measurement period for the FR2 frequency range; a filter coefficient (e.g., in a FilterCoefficient information element (IE) or the like) for L3 measurement filtering for the FR1 frequency range, a filter coefficient (e.g., in a FilterCoefficient IE or the like) for L3 measurement filtering for the FR2 frequency range; consolidation parameters for the FR1 frequency range and / or FR2 frequency range including, for example, a corresponding parameter to indicate the number of beams which can be used for selection of a highest ranked cell (e.g., nrofSS-BlocksToAverage IE) and / or a corresponding parameter to indicate the minimum threshold for beams which can be used for selection of a highest ranked cell (e.g., absThreshSS-BlocksConsolidation IE); and / or the like.

[0127] Additionally, (or alternatively), the first configuration message sent at step S504 may configure observation windows that are supported by the AI / ML model. For example, the first configuration message may configure an observation window (e.g., a timing window) comprising one, or a multiple number of observation windows configured for performing RRM measurements, or the like, which may form part of the input fed to the AI / ML model for each RLF prediction. It will be appreciated that the first configuration message may configure those observation windows based on a list of observation windows that are supported by the AI / ML model, and which were indicated to the serving RAN node 5-1 in the message it received from the UE 3 at step S502.

[0128] Additionally, (or alternatively), the first configuration message sent at step S504 may configure the UE 3 and / or the AI / ML models stored at the UE 3 to perform direct RLF predictions or indirect RLF predictions.

[0129] Direct RLF predictions may include, for example, those RLF predictions that are made based on historic RLF events and / or handover failure events. For example, the AI / ML model may use information pertaining to historic RLF events and / or handover failure events that have occurred before in the communication system 1 as an input for generating a RLF prediction of whether a RLF event will occur at a future time instance. In this instance, the AI / ML model may also use other information provided by the serving RAN node 5-1 such as assistance historic information.

[0130] Indirect RLF predictions may include, for example, those RLF predictions that are made based on predicted measurements made by the UE 3 (e.g., generated by the AI / ML model (or models) at the UE 3) and input to (fed back into) the AI / ML model (models) at the UE 3. For example, the UE 3 may firstly make RRM measurements, or the like (e.g., measured L1 RSRP values of SSBs and / or CSI-RS, measured L3 RSRP values of SSBs and / or CSI-RS, measured SINR values, or the like) that are input to the AI / ML model (or models). Using those inputs, the AI / ML model (or models) may generate predicted RRM measurements, or the like (e.g., predicted L1 RSRP values of SSBs and / or CSI-RS, predicted L3 RSRP values of SSBs and / or CSI-RS, predicted SINR values, or the like). Those predicted RRM measurements may then subsequently be fed back into the same AI / ML model (or a different AI / ML model stored at the UE 3) to generate RLF predictions.

[0131] It will be appreciated that where the first configuration message sent at step S504 configures the UE 3 and / or the AI / ML models stored at the UE 3 to perform indirect RLF predictions, the indirect RLF predictions may be run jointly at the UE 3 with RRM measurement predictions, or the like as alluded to above.

[0132] Additionally (or alternatively), the first configuration message sent to the UE 3 at step S504 may configure the UE 3 to perform AI / ML model RLF predictions with the assistance of specific (dedicated) RLF parameters (e.g., T310 timers, and the like). It will, nevertheless, be appreciated that, where appropriate the UE 3 may already be preconfigured (e.g., hardcoded, or configured by an earlier message) to perform AI / ML model RLF predictions with the assistance of specific RLF parameters (e.g., T310 timers, and the like).

[0133] It will be appreciated that, the first configuration message sent to the UE 3 at step S504 may configure the UE 3 to perform AI / ML model RLF predictions with the assistance of legacy RLF parameters (e.g., legacy T310 timers, and the like) that are used for RLM. Nevertheless, other appropriate (e.g., RRC) signalling (e.g., an RRC message or the like) may be used to indicate, to the UE 3, that the UE 3 should perform AI / ML model RLF predictions with the assistance of legacy RLF parameters (e.g., legacy T310 timers, and the like) that are used for RLM.

[0134] Additionally (or alternatively), where indirect RLF predictions are to be generated by the AI / ML model (or models) stored at the UE 3, the first configuration message sent to the UE 3 at step S504 may configure other appropriate RLF parameters that may be used as part of the inputs provided to the AI / ML model. By way of example only, the first configuration message may configure: -　　A T310 timer / parameter for input to the AI / ML model (for example, when the T310 timer expires, RLF may be considered to have occurred and may be triggered by the UE 3); -　　An N310 parameter that indicates a maximum number of out-of-sync indications that may be detected by the UE 3 prior to the T310 timer being triggered; and -　　An N311 parameter that indicates a minimum number of in-of-sync indications that have to be detected by the UE 3 prior to the T310 timer being stopped.

[0135] At step S506, the serving RAN node 5-1 sends another appropriate (second) configuration message (e.g., Network-sided Configuration for RLF Predictions) to the UE 3 to configure RLF predictions to be made by the UE 3 using the AI / ML model stored at the UE 3. For example, based on the UE capability report sent to the serving RAN node 5-1 at step S502, the serving RAN node 5-1 may send a second configuration message to the UE 3 at step S506 to configure the type of outputs that the serving RAN node 5-1 (and the network in general) expects from an AI / ML model stored at the UE 3.

[0136] Additionally (or alternatively), in the case of indirect RLF prediction, the second configuration message sent at S506 may configure the UE 3 and / or the AI / ML (or models) at the UE 3 to make model inferences (e.g., RRM measurement predictions, and the like) following the observation of multiple measurements instances (i.e., after the UE 3 has made a certain number of measurements in an observation window), or alternatively following each measurement instance (i.e., after the UE 3 has made a measurement in an observation window). This is further explained below with reference to Fig. 6.

[0137] As shown in Fig. 6 in case A, the UE 3 may be configured (e.g., by the first configuration message sent at step S504) with an observation window in which the UE 3 can make RRM measurements, or the like, for input into an AI / ML model. Having been configured (e.g., by the second configuration message sent at step S506) to make model inferences (e.g., RRM measurements predictions, and the like) following the observation of multiple measurement instances (i.e., after the UE 3 has made a certain number of measurements in an observation window), the AI / ML model may subsequently make a series of model inferences such as generating predicted RRM measurements, or the like, in a prediction window that follows the observation window based on the measurements made in the observation window.

[0138] Nevertheless, it will be appreciated that, as shown in Figure 6 in case B, the UE 3 may not be configured (e.g., by the first configuration message sent at step S504) with a specific observation window in which the UE 3 makes continuous RRM measurements, or the like, for input into an AI / ML model for predictions of future RRM measurements, or the like, (in a later prediction window). In this case, having been configured (e.g., by the second configuration message sent at step S506) to make model inferences (e.g., RRM measurements predictions, and the like) following the observation of each individual measurement instance in an interleaving manner, the AI / ML model may generate a predicted RRM measurements, or the like, immediately after the UE 3 has made each RRM measurement. In other words, the UE 3 interleaves between making RRM measurements and generating predicted RRM measurements. As shown in Figure 6 in case B, in this scenario, the UE 3 may skip some RRM measurements, and generate predicted RRM measurements in the time interval of those skipped RRM measurements instead.

[0139] In the case where the UE 3 is configured (e.g., by the second configuration message sent at step S506) to make model inferences (e.g., RRM measurements predictions, and the like) following the observation of each individual measurement instance in an interleaving manner, the UE 3 may be configured (e.g., by the second configuration message sent at step S506) to send RLF prediction outcomes to the serving RAN node 5-1 (and the network) continuously (i.e., each time the AI / ML model generated a RLF prediction). Alternatively, the UE 3 may be configured (e.g., by the second configuration message sent at step S506) to send RLF prediction outcomes to the serving RAN node 5-1 (and the network) following a specific RLF prediction report window (which may be a single prediction window, or may be a plurality of the prediction windows).

[0140] Additionally (or alternatively), the second configuration message sent at S506 may configure the UE 3, based on the UE capability report sent at S502, with one or more RLF prediction windows, each RLF prediction window, for example, following a corresponding observation window configured by the first configuration message sent at S504. Each RLF prediction window may define a time frame in which the UE 3 can predict RLF events (following a specific observation window). In other words, the UE 3 may run the AI / ML model to predict whether a RLF event will occur within the time window represented by the RLF prediction window. Alternatively, the UE 3 may be configured to predict when RLF events will occur within the time window represented by the RLF prediction window.

[0141] Additionally (or alternatively), the second configuration message sent at S506 may configure the UE 3 to predict, using the AI / ML model, the times of occurrence of RLF events (e.g., within a prediction window) and associated probabilities.

[0142] Additionally (or alternatively), the second configuration message sent at S506 may configure the UE 3 to predict, using the AI / ML model, the occurrence of RLF events with an open time window. In this case, the UE 3 may predict whether RLF events will occur in a certain (configured) time window in the future.

[0143] Additionally (or alternatively), the second configuration message sent at S506 may configure the UE 3 to make measurement event predictions (e.g., RRM measurement predictions, or the like) corresponding to RLF event predictions. This will help the UE 3 to know if there are any suitable handover targets to make a handover to, to avoid the occurrence of a predicted RLF event.

[0144] Additionally (or alternatively), the second configuration message sent at S506 may configure the UE 3 to predict, using the AI / ML model, non-suitable handovers for a given time window. For example, for a given time window the UE 3 may be configured to predict handovers in which the UE 3 could be handed over from its serving cell to a target cell (provided by the serving RAN node 5-1 or some other RAN node 5 of the communication system 1 - e.g., RAN node 5-2) which are not suitable, e.g., handovers that may give rise to RLF events, and thus handover failures.

[0145] Additionally, as well as the second configuration message sent at S506 configuring the UE 3 to predict, using the AI / ML model, non-suitable handovers for a given time window, that same configuration message may also configure the UE 3 to predict suggested (i.e., suitable) handovers for a given time window. For example, for a given time window the UE 3 may be configured to predict handovers in which the UE 3 could be handed over from its serving cell to a target cell which are suitable and unlikely to give rise of RLF events, and thus handover failures. It will be appreciated that the predicted suitable handover may be predicted to replace any predicted handovers that are unsuitable.

[0146] Additionally (or alternatively), the second configuration message sent at S506 may configure the UE 3 to predict, using the AI / ML model, a suggested cell switch (e.g., a switch from the UE's serving cell to a target cell) for a given time window to avoid a predicted RLF event, which may cause UE connection loss (but not handover failure).

[0147] Additionally (or alternatively), the second configuration message sent at S506 may configure the UE 3 with a reference time for the RLF prediction generated by the AI / ML model (or models) stored at the UE 3. That reference time, for example, may be a reference time from which a RLF event is predicted to occur. For example, the RLF prediction generated by the AI / ML model (or models) may indicate that a RLF event is predicted to occur T ms from the configured reference time.

[0148] In this scenario, in one example the reference time may be configured to correspond to the time at which a RLF prediction report is sent by the UE 3 to its serving RAN node 5-1. In another example, the reference time may be configured to correspond to the time at which a received configuration message from the network activates an AI / ML model at the UE 3 for RLF prediction. In yet another example, the reference time may be configured to correspond to the time at which a received configuration message from the network activates an AI / ML model at the UE 3 for measurement prediction (e.g., RRM measurement prediction).

[0149] Additionally (or alternatively), the second configuration message sent at S506 may configure the UE 3 with a time granularity for the RLF predictions generated by the AI / ML model (or models) stored at the UE 3. For example, the time granularity may be configured using a specific numerical value indicated in the second configuration message sent at S506. In another example, the time granularity may be configured using a configured measurement period configured to the UE 3 for perform RRM measurements, or the like (where the UE 3 is configured to perform indirect RLF predictions).

[0150] Alternatively, the time granularity at which an AI / ML model should generate RLF predictions may be fixed at set numerical values which are specified by specification (e.g., N ms). In this scenario it will be appreciated that a configuration message, or a suitable indicator in the first or second configuration messages discussed above, is not needed to set the time granularity.

[0151] Additionally (or alternatively), the second configuration message sent at S506 may configure the UE 3 with a specific timing at which to report RLF predictions to the serving RAN node 5-1. In one example, the UE 3 may be configured to report a RLF prediction outcome when it is immediately available (i.e., immediately after the AI / ML model has generated a RLF prediction). For example, the UE 3 may report a generated RLF prediction to the serving RAN node 5-1 after a fixed period corresponding to the configured observation window.

[0152] In another example, the UE 3 may be configured to report a RLF prediction outcome when the RLF prediction outcome indicates that a RLF event will occur. In other words, the UE 3 will not report the outcome of RLF prediction if the prediction (i.e., the output of the AI / ML model) indicates that no RLF event is due to occur within a specific time window. Thus, the UE 3 may be configured with event triggered reporting of RLF prediction outcomes such that the UE 3 only report RLF prediction outcomes when an actual RLF event is predicted to occur.

[0153] In yet another example, the UE 3 may be configured to only report a RLF prediction outcome if the probability of the occurrence of a predicted RLF event is higher than a threshold (e.g., a percentage value, or the like), otherwise the UE 3 is not expected to report its RLF prediction outcome.

[0154] In yet another example, the UE 3 may be configured to report a RLF prediction outcome following a specific configured RLF prediction report window.

[0155] In the above description, the first and second configuration messages sent at steps S504 and S506 are described as two separate and distinct messages. Nevertheless, it will be appreciated that the contents of the first and second configuration messages as described above may be mixed together into a single configuration message.

[0156] Furthermore, in the above description, the second configuration message sent at step S504 is described as a type of activation message that may be used, amongst other things, to activate a specific AI / ML model stored at a UE 3. Nevertheless, it will be appreciated that an independent model activation message may alternatively be sent to the UE 3 after step S506, when all configurations have been completed, to activate a specific AI / ML model (not shown in Fig. 5).

[0157] Furthermore, although not shown in Fig. 5, it will be appreciated that where the AI / ML model and / or UE 3 are configured to perform indirect RLF measurements, following completion of the configuration procedures in steps S504 and S506, the UE 3 may begin performing real (e.g., live) measurements, such as RRM measurements in a time window corresponding to one or more configured observation windows as described above. Those measurements may subsequently be used as inputs to the AI / ML model.

[0158] At step S508, the UE 3 may (optionally) receive network assistance information from the network (e.g., from the serving RAN node 5-1) via an appropriate RRC message before the UE 3 is able to run an AI / ML model to predict the occurrence of RLF events. For example, in the case where the UE 3 (and the AI / ML model stored at the UE 3) is configured to perform direct RLF event predictions as previously described (e.g., RLF event predictions based on historic RLF events), the UE 3 may need to receive network assistance information from the network (e.g., from the serving RAN node 5-1) for input to the AI / ML model.

[0159] Nevertheless, it will be appreciated that where the UE 3 (and the AI / ML model stored at the UE 3) is configured to perform direct RLF event predictions as previously described and the UE 3 needs to receive network assistance information from the network (e.g., from the serving RAN node 5-1) for input to the AI / ML model, that network assistance information may be sent to the UE 3 as part of step S504, rather than in a dedicated step S508.

[0160] The network assistance information from the network may, for example, include information pertaining to the occurrence of RLF events and / or handover failure (HOF) events that have previously occurred for the UE 3 (or other UEs in the communication system 1). The information pertaining to the occurrence of RLF events and / or HOF events may be collected by the network based on legacy UE reports of RLF indications / events. That information pertaining to the occurrence of RLF events and / or HOF events may not need to be stored at the UE 3 before the network (e.g., the serving RAN node 5-1) configures the UE 3 to perform RLF predictions using an AI / ML model stored at the UE 3.

[0161] Additionally, (or alternatively), the network assistance information from the network sent to the UE 3 may, for example, include RLF predictions generated by AI / ML models stored at other UEs 3 in the communication system 1 (e.g., not the UE 3). In this scenario, those RLF predictions generated at other UEs 3 in the communication system 1 may be used as an input for the AI / ML model of the UE 3 for the generations of its own RLF predictions.

[0162] As an alternative, the UE 3 may be required to store some historical HOF / RLF event information for future RLF prediction. In this case, the network may configure appropriate observation time windows for monitoring for HOF / RLF events and / or for storing the historic HOF / RLF events. Information pertaining to those monitored HOF / RLF events may then be stored at the UE 3 for subsequent use (e.g., input to an AI / ML model for direct RLF prediction) to predict future RLF events. By defining appropriate observation windows for monitoring those HOF / RLF events, the UE 3, beneficially, does not have to store excessively large numbers of historical HOF / RLF events in its memory.

[0163] Additionally, (or alternatively), the network assistance information from the network sent to the UE 3 may, for example, include appropriate information (e.g., RRM measurements, historic RLF events, and the like) pertaining to selected 'reference' UEs 3 in the network which remain at the same location and / or have the same speed / trajectory as the current UE 3 configured to make RLF predictions.

[0164] At step S510, the UE 3 generates an AI / ML model inference (e.g., a RLF event prediction, or the like), using an AI / ML model (or models) stored at the UE 3. As described above, the inputs to the AI / ML model (or models) may include: -　　Real (e.g., live and / or historic) RRM measurements such as L1 RSRP values of SSBs and / or CSI-RS, RSRP values of SSBs and / or CSI-RS, SINR values, or the like for the serving cell of the UE 3 for the generation of predicted RRM measurements, those predicted RRM measurements being subsequently input to the AI / ML model (or models) to generate RLF event predictions; and / or -　　Real (e.g., live and / or historic) RRM measurements such as L1 RSRP values of SSBs and / or CSI-RS, RSRP values of SSBs and / or CSI-RS, SINR values, or the like for one or more neighbouring cells for the generation of predicted RRM measurements, those predicted RRM measurements being subsequently input to the AI / ML model (or models) to generate RLF event predictions; and / or -　　Historic event information such as information pertaining to historic RLF events that have occurred at the UE 3; and / or -　　Network assistance information containing, for example, information pertaining to the occurrence of RLF events and / or HOF events that have previously occurred for the UE 3 (or other UEs 3 in the communication system 1) and / or RLF predictions generated by AI / ML models stored at other UEs 3 in the communication system 1 (e.g., not the UE 3).

[0165] Based on those inputs, the AI / ML model (or models) stored at the UE 3 may generate a RLF prediction as described previously.

[0166] At step S512, the UE 3 may report its generated RLF prediction to the serving RAN node 5-1. For example, the UE 3 may report a model inference generated by the AI / ML model (or models) stored at the UE 3 (e.g., a RLF event prediction, or the like), via an appropriate reporting-like message (e.g., an RRC message, or the like). The reporting of the model inference may be made in a periodic manner (e.g., the report may be sent to the serving RAN node 5-1 each time the UE 3 generates an AI / ML model inference), or alternatively, the model inference may be reported to the serving RAN node 5-1 using an event triggering approach; for example, the model inference may only be reported to the serving RAN node 5-1 when the inference predicts than a RLF event is actually going to occur.

[0167] It will be appreciated that in some scenarios, the configuration messages sent by the serving RAN node 5-1 to the UE 3 may explicitly request that the UE 3 reports its model inferences via specific RRC messaging. In this scenario, the model inference report may be seen as a response message to the request of the serving RAN node 5-1.

[0168] The report sent to the serving RAN node 5-1 at step S512 may include, by way of example only, for each serving cell for which a RLF prediction has been generated by the UE 3 (e.g., a current serving cell of the UE 3 and / or one or more historic serving cells of the UE 3): an ID of the serving cell (e.g., a physical cell ID (PCI) or a cell group ID (CGI) for which a RLF event prediction has been made, an indication of the predicted RLF event / occurrence for the serving cell, an indication of a cause of the predicted RLF event / occurrence (e.g. expiry of a T310 timer, a RLC failure, a random access failure, or the like), and / or, where the predicted RLF event is predicted to occur because of a HOF event, an indication of a cause of the HOF (e.g., too early handover, too late handover, handover to wrong cell).

[0169] Where the report sent at step S512 includes an indication of the predicted RLF event / occurrence for the serving cell of the UE 3 (current and / or historic), the report may more include, in one example, an indication of RLF occurrences within one or a plurality of prediction windows, wherein the indication may include a RLF occurrence probability value for each indicated RLF indication. In this instance, the prediction window may be defined by a lower time boundary and an upper time boundary.

[0170] In another example, where the report sent at step S512 includes an indication of the predicted RLF event / occurrence for the serving cell of the UE 3 (current and / or historic), the report may include an indication of RLF occurrences at one or a plurality of future time instance (e.g., future time instances determined based on a reporting time of the RLF prediction by the UE 3, the reporting time of the RLF prediction by the UE 3 being a reference time from which future instances can be calculated). That indication of one or more RLF occurrences at one or a plurality of future time instance may also include an occurrence probability for each RLF occurrence.

[0171] In yet another example, where the report sent at step S512 includes an indication of the predicted RLF event / occurrence for the serving cell of the UE 3 (current and / or historic), the report may include times of RLF occurrences within a specified prediction window and an occurrence probability for each RLF occurrence.

[0172] Additionally, (or alternatively), the report sent at step S512 may include suggestions of future handover behaviour that may be carried out by the UE 3 to avoid predicted RLF events (and / or HOF events) within a given prediction window. For example, the report may include: an indication of non-suitable handovers of the UE 3 from the serving cell to a target cell (or cells). For example, the report may include an indication of handovers where it is predicted that RLF events will occur during or after the handover, thereby rendering the handover non-suitable.

[0173] For each non-suitable handover of the UE 3 suggested in the report sent at S512, the report may include, by way of example only, an ID of the UE's current serving cell (e.g., a PCI or CGI) that is predicted to experience a RLF event, a lower boundary of a non-suitable handover occasion (e.g., using a time instance of the UE's RLF prediction report as a reference time), an upper boundary of the non-suitable handover occasion (e.g., using a time instance of the UE's RLF prediction report as a reference time), indications of target cells to avoid handing over to during the non-suitable handover occasion (e.g., a set of target cell IDs, or the like), and a probability of the likely success of the suggested non-suitable handover.

[0174] Additionally, (or alternatively), the report sent at S512 may include an indication of suggested (e.g., suitable) handovers of the UE 3 from the serving cell to a target cell (or cells) to replace the non-suitable handovers identified and included in the report.

[0175] For each suitable handover of the UE 3 suggested in the report sent at S512, the report may include, by way of example only, an ID of the UE's current serving cell (e.g., a PCI or CGI) that is predicted to experience a RLF event, a lower boundary of a suitable handover occasion (e.g., using a time instance of the UE's RLF prediction report as a reference time), an upper boundary of the suitable handover occasion (e.g., using a time instance of the UE's RLF prediction report as a reference time), a list of, and / or IDs (e.g., a PCI or CGI) of target cells to attempt handover to during the suitable handover occasion, and a probability of the likely success of the suggested suitable handover.

[0176] Additionally, (or alternatively), the report sent at S512 may include suggestions of cell switches that may be carried out by the UE 3 to avoid predicted RLF events within a given prediction window where those predicted RLF events are due to a failed connection (e.g., RLC failure, or the like). For example, where a RLF event / occurrence is predicted to occur due to the predicted occurrence of a failed radio link rather than a failed handover event, the report sent at S512 may include suggestions of cells to which the UE 3 may switch to in a specified timing window to avoid connection loss with the network. In this scenario, the report sent at S512 may include indication of suggested cell switches for the UE 3 to switch from its serving cell to one or more target cells.

[0177] For each cell switch of the UE 3 suggested in the report sent at S512, the report may include, by way of example only, an ID of the UE's current serving cell (e.g., a PCI or CGI) that is predicted to experience a RLF event, a lower boundary of a suggested cell switch occasion (e.g., using a time instance of the UE's RLF prediction report as a reference time), an upper boundary of the suggested cell switch occasion (e.g., using a time instance of the UE's RLF prediction report as a reference time), indications of target cells to attempt cell switch to during the suitable handover occasion (e.g., a set of target cell IDs, or the like), and a probability of the likely success of the suggested cell switch.

[0178] Having received the report sent at S512, the serving RAN node 5-1 may forward (not shown) all of, or part of that received report on to other (neighbouring) RAN nodes 5 (e.g., RAN node 5-2) of the communication system 1. Those other (neighbouring) RAN nodes 5 (e.g., RAN node 5-2) may subsequently use all of, or part of the forwarded report as an input to AI / ML models stored at other UEs 3 of the communication system 1. For example, other (neighbouring) RAN nodes 5 (e.g., RAN node 5-2) may include all of, or part of, the forwarded report in network assistance information sent to other UEs 3 in the communication system 1.

[0179] <Example UE Report of RLF prediction sent at step S512> 　　The report sent to the serving RAN node 5-1 at step S512 (as described in more detail above) may, by way of example only, include RLF occurrence predictions such as: -　　A probability of 80% that a RLF occurrence / event will occur within a period of 200 ms after the UE 3 has sent the report at step S512; -　　A probability of 50% that a RLF occurrence / event will occur within a period of 300 ms after the UE 3 has sent the report at step S512; -　　A probability of 75% that a RLF occurrence / event will occur within a current prediction window after the UE 3 has sent the report at step S512; and / or -　　A probability of 95% that a RLF occurrence / event will occur within a defined timing window, the defined timing window having a lower time boundary of 100 ms after the UE 3 has sent the report at step S512, and an upper time boundary of 400 ms after the UE 3 has sent the report at step S512.

[0180] Thus, it will be appreciated that the report sent to the serving RAN node 5-1 at step S512 may include indications of prediction probabilities of RLF occurrences within a variety of different specified time periods, which may be defined with respect to when the report is sent to the serving RAN node 5-1.

[0181] The report sent to the serving RAN node 5-1 at step S512 (as described in more detail above) may also include a suggested handover occurrence to avoid RLF occurrences / events such as, by way of example only, a suggested handover occasion within a defined timing window, the defined timing window having a lower time boundary of, for example, 100 ms after the UE 3 has sent the report at step S512, and an upper time boundary of, for example, 400 ms after the UE 3 has sent the report at step S512. In addition, the report may include one or more suggested target cells to which the UE 3 could be handed over, and a probability of the predicted success of the suggested handover or handovers (e.g., a probability of 90%).

[0182] <Additional aspects for indirect RLF prediction> 　　It will be appreciated that in the case of indirect RLF predictions (e.g., AI / ML model RLF predictions based on predicted measurements such as predicted RRM measurements, or the like) described previously, it may be beneficial for the UE 3 to report, to the network (e.g., to the serving RAN node 5-1), an accuracy of the predicted measurements that the AI / ML model of the UE 3 can achieve for each RLF prediction made by the AI / ML model when using predicted measurements as an input.

[0183] In this case, the accuracy of the predicted measurements that the AI / ML model of the UE 3 can achieve may be reported to the network before the network sends its configuration messages (e.g., the first configuration message sent at step S502 and / or the second configuration message set at step S504) to the UE 3.

[0184] Based on the reported accuracy of the predicted measurements that the AI / ML model of the UE 3 can achieve for each RLF prediction made by the AI / ML model when using predicted measurements as an input, the network may decide whether UE 3 should generate RLF predictions using its AI / ML model (or models) using those predicted measurements as inputs (i.e., the network may decide whether UE 3 should generate indirect RLF predictions using its AI / ML model (or models)).

[0185] It will be appreciated that, the network may use the reported accuracy information to decide if it can ask the UE 3 to perform indirect RLF predictions using its AI / ML model (or models). For example, if the measurement prediction accuracy is not sufficient, the network may configure the UE 3 to use (or switch to) direct RLF prediction using its AI / ML model (or models).

[0186] Utilising the AI / ML RLF prediction 　　Once the UE 3 has reported its RLF prediction to the serving RAN node 5-1 at step S512, the communication system 1 may perform an appropriate handover procedure to hand the UE 3 from a serving cell to a target cell to avoid a predicted RLF occasion / event.

[0187] An example RAN node triggered handover procedure that may be implemented following AI / ML RLF prediction in the communication system of Fig. 1 will now be described, by way of example only, with reference to Fig. 7.

[0188] As shown in Fig. 7, there is provided a UE 3, a serving RAN node 5-1 (e.g., operating as source RAN node) which provides a serving cell over which the UE 3 and the serving RAN node 5-1 can communicate, and a second (target) RAN node 5-2 which provides a target cell to which the UE 3 may be handed over.

[0189] At step S702, which is equivalent to step S512 in Fig. 5, the UE 3 may report its generated RLF prediction to the serving RAN node 5-1. For example, the UE 3 may report a model inference generated by the AI / ML model (or models) stored at the UE 3 (e.g., a RLF event prediction, or the like), via an appropriate reporting-like message (e.g., an RRC message, or the like). The reporting of the model inference may be made in a periodic manner (e.g., the report may be sent to the serving RAN node 5-1 each time the UE 3 generates an AI / ML model inference), or alternatively, the model inference may be reported to the serving RAN node 5-1 using an event tigering approach; for example, the model inference may only be reported to the serving RAN node 5-1 when the inference predicts than a RLF event is actually going to occur.

[0190] A detailed description of the possible contents of the report sent to the serving RAN node 5-1 at step S702 is described above with reference to step S512 in Fig. 5. By way of example only however, the report may include an appropriate indication of a predicted occurrence of a RLF event within a prediction time window, along with a probability value corresponding to the probability of the predicted occurrence of the RLF event. The report sent at S702 may also include, where appropriate, a suggested handover for the UE 3 to perform, including an indication of handover occasions and suitable target cells to which the UE 3 should be handed over.

[0191] At step S704 the serving RAN node 5-1 (operating as the source RAN node) decides to handover the UE 3 to the target RAN node 5-2 based on, for example, the RLF prediction report that the serving RAN node 5-1 received from the UE 3 at step S702.

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

[0193] Additionally, the handover request sent at step S706 may also include an appropriate indication that the handover request is a RLF prediction-based handover request (i.e., the handover request has been issued in response to a RLF prediction which indicates that a RLF event is likely to occur at some future time). Furthermore, where the handover request includes an appropriate indication that the handover request is a RLF prediction-based handover request it may also include a probability associated with the requested handover generated by the AI / ML model at the UE 3. For example, the handover request may indicate a probability of the success of the requested handover.

[0194] Additionally, the handover request sent at step S706 may also include appropriate information pertaining to the AI / ML model used at the UE 3 to generate a RLF prediction and / or a suggested handover. For example, the handover request may include an ID of the AI / ML model (or models), and / or indications of characteristics of the AI / ML model (or models) used by the UE 3 to generate RLF predictions and / or suggested handovers. In other words, the handover request may include the same (or similar) information to that which was reported to the serving RAN node 5-1 in the UE capability message that the serving RAN node 5-1 received at step S502 in the procedure depicted in Fig. 5.

[0195] At step S708, admission control may be performed by the target RAN node 5-2. Slice-aware admission control may, for example, be performed if corresponding slice information is sent to the target RAN node 5-2 and if protocol data unit (PDU) sessions are associated with non-supported slices the target RAN node 5-2 may reject such a PDU session.

[0196] At step S710, the target RAN node 5-2 prepares handover and sends an appropriate response (e.g., a handover request acknowledge message or the like) to the serving RAN node 5-1. The response includes an RRC message in a transparent container that is to be sent to the UE 3 as a handover command to instruct / trigger performance of the handover (e.g., an RRC reconfiguration message or the like).

[0197] Additionally, the transparent container in the response message sent at step S710 (e.g., in the RRC message / handover command) may include an appropriate indication of an AI / ML model (or models) stored at the UE 3 (e.g., via AI / ML model IDs) that the target RAN node 5-2 wishes the UE 3 to use for making subsequent RLF predictions. For example, the indication may be used to configure the UE 3 to perform RLF predictions using a different AI / ML model (or models) for subsequent RLF predictions, where the target RAN node 5-2 has different AI / ML model preferences from the serving RAN node 5-1.

[0198] In this scenario, the transparent container in the response message may also comprise (e.g., in the RRC message / handover command) other AI / ML model configuration information and / or network configuration information such as the information contained in the first and / or second configuration messages sent at steps S504 and S508 as described above with reference to Fig. 5 (or a subset of that information). Furthermore, the transparent container in the response message may also comprise (e.g., in the RRC message / handover command) appropriate network assistance information such as that described above with reference to step S508 in Fig. 5 (or a subset of that information).

[0199] The serving RAN node 5-1 may then trigger the handover by sending the handover command (e.g., in an RRC message, or the like) to the UE 3 at S712. That handover command contains the information required to access the target cell (e.g., the target cell ID, the new C-RNTI, the target RAN node security algorithm identifiers for the selected security algorithms and / or the like), and any of the information described above that is included in that handover command.

[0200] Thus, having received the handover command sent at step S712, if the AI / ML model (or models) is indicated in that handover command and the ID of the indicated AI / ML model differs from the ID of the AI / ML model (or models) previously used by the UE 3 to perform RLF prediction, then the UE 3 may switch to the newly indicated AI / ML model (or models) to make RLF predictions once the UE 3 has successfully accessed the target cell provided by the target RAN node 5-2.

[0201] It will be appreciated that the handover command, sent by the serving (source) RAN node 5-1 (e.g., as prepared by the target RAN node 5-2) may be a conditional handover (CHO) command to instruct the UE 3 to switch to one or more target cells. Moreover, the (conditional) handover command may include an appropriate indication that the handover is a RLF prediction-based handover (i.e., the handover has been triggered in response to a RLF prediction which indicates that a RLF event is likely to occur at some future time). Furthermore, where the handover command includes an appropriate indication that the handover is a RLF prediction-based handover it may also include a probability associated with the requested handover generated by the AI / ML model at the UE 3. For example, the handover command may indicate a probability of the success of the requested handover.

[0202] Where the handover command is a CHO command, the CHO command may include a CHO execution condition, for example, that the handover to the target cell (or cells) provided by the target RAN node 5-2 should only be executed if a particular measurement event is triggered. For example, the so-called measurement event 'Event A4' (which triggers when a measurement result (e.g., RSRP or RSRQ) for a neighbour cell (e.g., a target cell) becomes better (greater) than a preconfigured threshold value) may be used for the target cell or cells.

[0203] The serving (source) RAN node 5-1 may send to the UE 3 (e.g., in the handover command sent at S712) the model configuration and / or network configuration for RLF prediction received from target RAN node 5-2 (e.g., in the transparent container / handover acknowledgement sent at S710). The UE 3 may then continue to perform RLF prediction following this configuration when the UE 3 has successfully accessed a target cell of the new target RAN node 5-2.

[0204] For a CHO type handover, at step S714, the UE 3 may perform a check to determine if a handover condition has been met for one or more target cells. Where multiple target cells have been indicated by the serving (source) RAN node 5-1, the UE 3 may choose a target cell which is strongest (e.g., the UE 3 may choose a target cell satisfying the conditions for triggering an A4 event.

[0205] At step S716, the UE 3 may then access a target cell (e.g., that meets the CHO conditions in the case of a CHO type handover). However if, for a CHO type handover, there is no target cell satisfying the CHO conditions (e.g., for triggering an A4 event), then the UE 3 will skip the handover execution and report to the network in a follow-up step (not shown) with an indication of the reason / cause for skipping the handover (e.g., no suitable cell).

[0206] Following step S716, (or during step S716), the UE 3 may send a RLF prediction report (e.g., a RLF prediction report pertaining to the previously serving (source) RAN node 5-1) to the target RAN node 5-2 (if the UE 3 has not already sent that RLF prediction report to the previously serving (source) RAN node 5-1). The target RAN node 5-2 may then send this report to the (previous) serving (source) RAN node 5-1. Alternatively, the UE 3 may drop its previous RLF prediction outcome in accordance with an AI / ML model inference for RLF prediction pertaining to the previously serving (source) RAN node 5-1.

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

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

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

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

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

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

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

[0214] 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 5 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.

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

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

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

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

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

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

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

[0222] 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 5-1, 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 5-1, a central entity of the communication system 1, or an OAM / OTT server - any other suitable two network nodes could alternatively be used.

[0223] The AI / ML model hosted at the UE 3 and the AI / ML model hosted at the source RAN node 5-1, 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 5-1, 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 5-1, a central entity of the communication system 1, or an OAM / OTT server.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0244] 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, from an access network node, first information of model configuration of an artificial intelligence / machine learning (AI / ML) model used for prediction of at least one of a radio link failure (RLF) or a hand over failure (HOF), second information of prediction configuration of the prediction and third information of report configuration of a report correspdonding to the prediction; and 　　transmitting, to the access network node, a report corresponding to the prediction based on the first information, the second information and the third information. 　　(Supplementary note 2) 　　The method according to supplementary note 1, wherein 　　the first information includes information indicating at least one observation window each of which corresponds to a respective time frame during which the mobile device obtains information for input of the prediction. 　　(Supplementary note 3) 　　　　The method according to supplementary note 1 or 2, wherein 　　the first information includes at least one parameter of measurements used for the prediction, and 　　the at least one parameter includes at least one of: 　　　　measured layer 1 (L1) reference signal receved power (RSRP), 　　　　measured layer 3 (L3) RSRP, 　　　　measured signal-to-interference plus noise ratio (SINR), 　　　　predicted L1 RSRP, 　　　　predicted L3 RSRP, 　　　　predicted SINR, 　　　　information indicating at least one neighbour cell for measurements, 　　　　information indicating at least one intra-frequency measurement period, 　　　　information indicating at least one inter-frequency measurement period, 　　　　information indicating filter coefficient for L3 measurement filtering, 　　　　at least one consolidation parameter for measurements. 　　(Supplementary note 4) 　　The method according to any one of supplementary notes 1 to 3, wherein 　　the second information includes at least one of: 　　　　information indicating at least one prediction window each of which corresponds to a respective time frame during which the mobile device predicts events of the at least one of RLF or the HOF, 　　　　information indicating a reference time for the prediction, or 　　　　information indicating a time granularity for the prediction. 　　(Supplementary note 5) 　　The method according to any one of supplementary notes 1 to 4, wherein 　　the third information includes information indicating how to transmit a report for the prediction. 　　(Supplementary note 6) 　　The method according to claim any one of supplementary notes 1 to 5, wherein 　　the report includes at least one of: 　　　　an identifier of a cell corresponding to the at least one of the RLF or the HOF, 　　　　information indicating occurrence of the at least one of the RLF or the HOF, 　　　　information indicating a number of occurrence of the at least one of the RLF or the HOF, 　　　　information of a probability for the at least one of the RLF or the HOF, 　　　　infromation indicating a cause of the at least one of the RLF or the HOF, 　　　　information indicating non suitable handover from a serving cell to a target cell, 　　　　information indicating suggested handover from a serving cell to a target cell, 　　　　information indicating suggested cell switch from a serving cell to a target cell, 　　　　information indicating at least one occasion for the suggested handover or the suggested cell switch, 　　　　an identifier of a target cell corresponding to the suggested handover or the suggested cell switch, or 　　　　information of a probability for the prediction. 　　(Supplementary note 7) 　　The method according to any one of supplementary notes 1 to 6, further comprising: 　　receiving, from the access network node, fourth information of at least one occurred event of at least one of RLF or HOF, and wherein 　　the fourth information is used for the prediction of the at least one of the RLF or the HOF. 　　(Supplementary note 8) 　　The method according to supplementary note 7, further comprising: 　　transmitting, to the access network node, information of accuracy of prediction of measurements, and wherein 　　the prediction of the at least one of the RLF or the HOF includes: 　　　　a direct prediction which is based on measurements, and 　　　　an indirect prediction which is based on the at least one occurred event of the at least one of the RLF or the HOF, and 　　the information of the accuracy of the prediction is used for determining which of the direct prediction or the indirect prediction is to be performed. 　　(Supplementary note 9) 　　The method according to any one of supplementary notes 1 to 8, further comprising: 　　transmitting, to the access network node, information indicating support of the prediction. 　　(Supplementary note 10) 　　The method according to supplementary note 9, wherein 　　the information indicating support of the prediction includes at least one of: 　　　　information indicating functionality for the prediction which the mobile device supports, or 　　　　information corresponding to the AI / ML model used for the prediction, and 　　the information corresponding to the AI / ML model includes at least one of: 　　　　an identifier of the AI / ML model, 　　　　information indicating at least one observation window supported by the AI / ML model, 　　　　information indicating at least one prediction window supported by the AI / ML model, 　　　　information indicating a characteristics of the prediction, 　　　　information indicating a max number of cells for predictions. 　　(Supplementary note 11) 　　The method according to any one of supplementary notes 1 to 10, wherein 　　the report is used by the access network node to determine to perform handover the mobile device to another access network node. 　　(Supplementary note 12) 　　The method according to supplementary note 11, further comprising: 　　receiving, from the another access network node via the access network node, new first information, new second information and new third information. 　　(Supplementary note 13) 　　The method according to supplementary note 12, further comprising: 　　determining whether a condition for handover to the another access network node is met. 　　(Supplementary note 14) 　　The method according to supplementary note 12 or 13, further comprising: 　　transmitting, to the another access network node, a report corresponding to the prediction based on the new first information, the new second information and the new third information. 　　(Supplementary note 15) 　　A method performed by an access network node, the method comprising: 　　transmitting, to a mobile device, first information of model configuration of an artificial intelligence / machine learning (AI / ML) model used for prediction of at least one of a radio link failure (RLF) or a hand over failure (HOF), second information of prediction configuration of the prediction and third information of report configuration of a report correspdonding to the prediction; and 　　receiving, from the mobile device, a report corresponding to the prediction based on the first information, the second information and the third information. 　　(Supplementary note 16) 　　A mobile device comprising: 　　means for receiving, from an access network node, first information of model configuration of an artificial intelligence / machine learning (AI / ML) model used for prediction of at least one of a radio link failure (RLF) or a hand over failure (HOF), second information of prediction configuration of the prediction and third information of report configuration of a report correspdonding to the prediction; and 　　means for transmitting, to the access network node, a report corresponding to the prediction based on the first information, the second information and the third information. 　　(Supplementary note 17) 　　An access network node comprising: 　　means for transmitting, to a mobile device, first information of model configuration of an artificial intelligence / machine learning (AI / ML) model used for prediction of at least one of a radio link failure (RLF) or a hand over failure (HOF), second information of prediction configuration of the prediction and third information of report configuration of a report correspdonding to the prediction; and 　　means for receiving, from the mobile device, a report corresponding to the prediction based on the first information, the second information and the third information.

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

[0246] 1 COMMUNICATION SYSTEM 3 USER EQUIPMENT 5 BASE STATION 7 CORE NETWORK 9 CELL 10 CONTROL PLANE FUNCTIONS 11 USER PLANE FUNCTIONS 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 61 OPERATING SYSTEM 63 COMMUNICATIONS CONTROL MODULE

Claims

1. A method performed by a mobile device, the method comprising: 　　receiving, from an access network node, first information of model configuration of an artificial intelligence / machine learning (AI / ML) model used for prediction of at least one of a radio link failure (RLF) or a hand over failure (HOF), second information of prediction configuration of the prediction and third information of report configuration of a report correspdonding to the prediction; and 　　transmitting, to the access network node, a report corresponding to the prediction based on the first information, the second information and the third information.

2. The method according to claim 1, wherein 　　the first information includes information indicating at least one observation window each of which corresponds to a respective time frame during which the mobile device obtains information for input of the prediction.

3. The method according to claim 1 or 2, wherein 　　the first information includes at least one parameter of measurements used for the prediction, and 　　the at least one parameter includes at least one of: 　　　　measured layer 1 (L1) reference signal receved power (RSRP), 　　　　measured layer 3 (L3) RSRP, 　　　　measured signal-to-interference plus noise ratio (SINR), 　　　　predicted L1 RSRP, 　　　　predicted L3 RSRP, 　　　　predicted SINR, 　　　　information indicating at least one neighbour cell for measurements, 　　　　information indicating at least one intra-frequency measurement period, 　　　　information indicating at least one inter-frequency measurement period, 　　　　information indicating filter coefficient for L3 measurement filtering, 　　　　at least one consolidation parameter for measurements.

4. The method according to any one of claims 1 to 3, wherein 　　the second information includes at least one of: 　　　　information indicating at least one prediction window each of which corresponds to a respective time frame during which the mobile device predicts events of the at least one of RLF or the HOF, 　　　　information indicating a reference time for the prediction, or 　　　　information indicating a time granularity for the prediction.

5. The method according to any one of claims 1 to 4, wherein 　　the third information includes information indicating how to transmit a report for the prediction.

6. The method according to claim any one of claims 1 to 5, wherein 　　the report includes at least one of: 　　　　an identifier of a cell corresponding to the at least one of the RLF or the HOF, 　　　　information indicating occurrence of the at least one of the RLF or the HOF, 　　　　information indicating a number of occurrence of the at least one of the RLF or the HOF, 　　　　information of a probability for the at least one of the RLF or the HOF, 　　　　infromation indicating a cause of the at least one of the RLF or the HOF, 　　　　information indicating non suitable handover from a serving cell to a target cell, 　　　　information indicating suggested handover from a serving cell to a target cell, 　　　　information indicating suggested cell switch from a serving cell to a target cell, 　　　　information indicating at least one occasion for the suggested handover or the suggested cell switch, 　　　　an identifier of a target cell corresponding to the suggested handover or the suggested cell switch, or 　　　　information of a probability for the prediction.

7. The method according to any one of claims 1 to 6, further comprising: 　　receiving, from the access network node, fourth information of at least one occurred event of at least one of RLF or HOF, and wherein 　　the fourth information is used for the prediction of the at least one of the RLF or the HOF.

8. The method according to claim 7, further comprising: 　　transmitting, to the access network node, information of accuracy of prediction of measurements, and wherein 　　the prediction of the at least one of the RLF or the HOF includes: 　　　　a direct prediction which is based on measurements, and 　　　　an indirect prediction which is based on the at least one occurred event of the at least one of the RLF or the HOF, and 　　the information of the accuracy of the prediction is used for determining which of the direct prediction or the indirect prediction is to be performed.

9. The method according to any one of claims 1 to 8, further comprising: 　　transmitting, to the access network node, information indicating support of the prediction.

10. The method according to claim 9, wherein 　　the information indicating support of the prediction includes at least one of: 　　　　information indicating functionality for the prediction which the mobile device supports, or 　　　　information corresponding to the AI / ML model used for the prediction, and 　　the information corresponding to the AI / ML model includes at least one of: 　　　　an identifier of the AI / ML model, 　　　　information indicating at least one observation window supported by the AI / ML model, 　　　　information indicating at least one prediction window supported by the AI / ML model, 　　　　information indicating a characteristics of the prediction, 　　　　information indicating a max number of cells for predictions.

11. The method according to any one of claims 1 to 10, wherein 　　the report is used by the access network node to determine to perform handover the mobile device to another access network node.

12. The method according to claim 11, further comprising: 　　receiving, from the another access network node via the access network node, new first information, new second information and new third information.

13. The method according to claim 12, further comprising: 　　determining whether a condition for handover to the another access network node is met.

14. The method according to claim 12 or 13, further comprising: 　　transmitting, to the another access network node, a report corresponding to the prediction based on the new first information, the new second information and the new third information.

15. A method performed by an access network node, the method comprising: 　　transmitting, to a mobile device, first information of model configuration of an artificial intelligence / machine learning (AI / ML) model used for prediction of at least one of a radio link failure (RLF) or a hand over failure (HOF), second information of prediction configuration of the prediction and third information of report configuration of a report correspdonding to the prediction; and 　　receiving, from the mobile device, a report corresponding to the prediction based on the first information, the second information and the third information.

16. A mobile device comprising: 　　means for receiving, from an access network node, first information of model configuration of an artificial intelligence / machine learning (AI / ML) model used for prediction of at least one of a radio link failure (RLF) or a hand over failure (HOF), second information of prediction configuration of the prediction and third information of report configuration of a report correspdonding to the prediction; and 　　means for transmitting, to the access network node, a report corresponding to the prediction based on the first information, the second information and the third information.

17. An access network node comprising: 　　means for transmitting, to a mobile device, first information of model configuration of an artificial intelligence / machine learning (AI / ML) model used for prediction of at least one of a radio link failure (RLF) or a hand over failure (HOF), second information of prediction configuration of the prediction and third information of report configuration of a report correspdonding to the prediction; and 　　means for receiving, from the mobile device, a report corresponding to the prediction based on the first information, the second information and the third information.

Images