WO2025249257A1

WO2025249257A1 - Method performed by first access network node, method performed by second access network node, first access network node, and second access network node

Info

Publication number: WO2025249257A1
Application number: PCT/JP2025/018317
Authority: WO
Inventors: Abdelrahim MOHAMED
Original assignee: NEC Corp
Current assignee: NEC Corp
Priority date: 2024-05-31
Filing date: 2025-05-21
Publication date: 2025-12-04
Anticipated expiration: 2026-11-30
Also published as: GB202407764D0

Abstract

A method performed by a first access network node is disclosed. The method includes controlling to avoid a handover from the first access network node to a second access network node, based on a failure of a handover from the second access network node to a third access network node after a successful handover from the first access network node to the second access network node.

Description

METHOD PERFORMED BY FIRST ACCESS NETWORK NODE, METHOD PERFORMED BY SECOND ACCESS NETWORK NODE, FIRST ACCESS NETWORK NODE, AND SECOND ACCESS NETWORK NODE

　　The present disclosure relates to a communication system and to parts thereof. The disclosure has particular but not exclusive relevance to wireless communication systems and devices thereof operating according to the 3rd Generation Partnership Project (3GPP) standards or equivalents or derivatives thereof (including Long Term Evolution (LTE)-Advanced, Next Generation or 5G/6G networks, future generations, and beyond). The present disclosure in particular, but not exclusively, relates to handover procedures and automatic neighbour relations (ANR) handover blocking mechanisms.

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

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

　　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.

　　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.

　　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).

　　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.

　　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.

　　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.

　　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).

　　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 (e.g. eNB, gNB, CU, DU or the like) 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).

　　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 machine learning (ML)/artificial intelligence (AI) training/inference to identify appropriate RAN optimisation actions for which it can use SMO services.

　　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.

　　< Cell Access >
　　The coverage in 5G is primarily 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).

　　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.

　　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 RRC connection setup procedure comprising a random access channel (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.

　　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.

　　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.

　　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.

　　However, irrespective of whether a RACH-based and RACH-less procedure is used for handovers, handover failures (e.g., due to radio link failures, and the like) may still occur in the communication system causing service disruption and delays. While efforts have been made to address service disruption and delays caused by handover failures during a direct handover e.g., handing over a UE from a first (source) RAN node to a second (target) RAN node, handover failures during subsequent handovers to a RAN node with which the second RAN node has neighbour relations still has the potential to cause issues.

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

　　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.

　　In one aspect there is provided a method performed by a first access network node, the method comprising:
　　controlling to avoid a handover from the first access network node to a second access network node, based on a failure of a handover from the second access network node to a third access network node after a successful handover from the first access network node to the second access network node.

　　In one aspect there is provided a method performed by a second access network node, the method comprising:
　　performing a handover from a first access network node and the second access network node; and
　　detecting a failure of a handover from the second access network node to a third access network node, wherein
　　a number of failures of the handover from the second access network node to the third access network node after the successful handover from the first access network node to the second access network node is updated by either the first access network node or the second access network node, for use by the first access network node in controlling to avoid a handover from the first access network node to the second access network node.

　　In one aspect there is provided a first access network node comprising:
　　means for controlling to avoid a handover from the first access network node to a second access network node, based on a failure of a handover from the second access network node to a third access network node after a successful handover from the first access network node to the second access network node.

　　In one aspect there is provided a second access network node comprising:
　　means for performing a handover from a first access network node and the second access network node; and
　　means for detecting a failure of a handover from the second access network node to a third access network node, wherein
　　a number of failures of the handover from the second access network node to the third access network node after the successful handover from the first access network node to the second access network node is updated by either the first access network node or the second access network node, for use by the first access network node in controlling to avoid a handover from the first access network node to the second access network node.

　　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.

　　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.

　　According to the present disclosure, it is possible to provide a method performed by a first access network node, a method performed by a second access network node, a first access network node, and a second access network node.

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

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 is a simplified sequence diagram illustrating a handover failure and subsequent re-establishment procedure that may occur in the communication system of Fig. 1; Fig. 4 is a simplified sequence diagram illustrating another handover failure and subsequent re-establishment procedure that may occur in the communication system of Fig. 1; Fig. 5 is a simplified sequence diagram illustrating another handover failure and subsequent re-establishment procedure that may occur in the communication system of Fig. 1; Fig. 6 illustrates an example ANR function that may be provided a RAN node of the communication system of Fig. 1; Fig. 7A is a simplified sequence diagram illustrating a 'Too Late' handover failure detection procedure for handover failures of neighbour-related cells that may occur in the communication system of Fig. 1; Fig. 7B is a simplified sequence diagram illustrating a 'Too Late' handover failure detection procedure for handover failures of neighbour-related cells that may occur in the communication system of Fig. 1; Fig. 8 is a simplified block schematic illustrating the main components of a UE 3 for implementation in the communication system of Fig. 1; and Fig. 9 is a simplified block schematic illustrating the main components of a RAN node 5-1 for implementation in the communication system of Fig. 1.

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

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

　　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 or later generations core network or evolved packet core network (EPC)) or any other core network.

　　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 one or more other RAN nodes 5 and UEs 3.

　　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.

　　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).

　　The core network 7 includes a number of logical nodes (or 'functions') for supporting communication in the communication system 1. In this example, the core network 7 comprises control plane functions (CPFs) 10 and one or more network node entities for the communication of user data (e.g., user plane functions (UPFs) 11). The CPFs 10 include one or more network node entities for the communication of control signalling (e.g., Access and Mobility Management Functions (AMFs) 10-1), one or more network node entities for session management (e.g., Session Management Functions (SMFs) 10-2) and a number of other functions 10-n (such as, for example an Authentication Server Function (AUSF) which facilitates security processes).

　　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.

　　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., N6 reference point) for communication of the user data.

　　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.

　　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.

　　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.

　　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.

　　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.

　　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 node 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).

　　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.

　　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 9 (and/or a beam in the case of 5G), a 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.

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

　　While a four-step contention-based RACH procedure is described it will be appreciated that the UE 3 and a RAN node 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 node 5 to the UE 3. Moreover, the UE 3 and the RAN node 5-1, 5-2 of the communication system 1 may perform a two-step RACH procedure.

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

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

　　In conventional handover procedures (including RACH-less handover procedures) a first RAN node 5-1 (e.g., a source RAN node 5-1) 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 a second RAN node 5-2 (e.g., a target RAN node 5-2) for handover by sending a handover request message to the second RAN node 5-2.

　　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.

　　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.

　　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.

　　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.

　　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.

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

　　At S202, before the handover procedure starts, the first RAN node 5-1 serving and communicating with the UE 3 (i.e., the source RAN node 5-1 of the handover) 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.

　　At step 204, 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.

　　In the handover procedure, a handover preparation phase S206 commences when the first RAN node 5-1 (operating as a source RAN node 5-1) 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., a target RAN node 5-2) based on, for example, measurement results received in a measurement report and/or radio resource management (RRM) information.

　　The first RAN node 5-1 issues, at S210, a handover request, to the second RAN node 5-2. This message will typically pass information to the second RAN node 5-2 necessary to perform the handover in a transparent RRC container. 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.

　　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.

　　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. For example, the response message may include an RRC message that contains, or functions as, a handover command to instruct/trigger performance of the handover (e.g., an RRC reconfiguration message or the like).

　　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).

　　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).

　　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).

　　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).

　　However, it will be appreciated that prior to, during, or even after a handover procedure such as that described above with reference to Fig. 2, handover failure events may occur. For example, radio link failures (RLFs) or the like may occur prior to, during, or shortly after a handover procedure that results in the handover being deemed a 'failed handover'. In such scenarios, the UE 3 may attempt to re-establish a connection with either its original source cell (e.g., a cell provided by first RAN node 5-1), a target cell (e.g., a cell provided by second RAN node 5-2), or a different cell (e.g., a cell provided by another RAN node 5-X).

　　Examples of such handover failures, and subsequent re-establishment procedures, that may typically be used in communication system 1, will now be described, by way of example only, with reference to Figs. 3-7.

　　< 'Too Late' Handover >
　　Fig. 3 is a simplified sequence diagram illustrating a handover failure and subsequent re-establishment procedure that may occur in a communication system 1. The handover in this example is said to be 'too late', and thus the handover failure is a 'too late handover' failure.

　　As shown in Fig. 3, there is provided a UE 3 that has an RRC connection with a first RAN node 5-1 (e.g., a source RAN node 5-1) allowing it to receive from, and transmit to, the first RAN node 5-1. The first RAN node 5-1 may provide a first cell (Cell A) for the UE 3 to communicate over with the RAN node 5-1. Furthermore, the RAN node 5-1 may provide a specific first radio access technology (RAT), e.g., 6G, NR, E-UTRA, LTE, or the like.

　　There is also provided a second RAN node 5-2, which may act as a target RAN node 5-2 for handover purposes. The second RAN node 5-2 may provide a second cell (Cell B) for the UE 3 to be handed over to, allowing the UE 3 to communicate with the RAN node 5-2 over that second cell. Furthermore, the second RAN node 5-2 may provide a second RAT e.g., 6G, NR, E-UTRA, LTE, or the like. The second RAT provided by the second RAN node 5-2 may be a different RAT from the first RAT provided by the first RAN node 5-1.

　　At some time later, but prior to the first RAN node 5-1 deciding to perform a handover procedure, the radio link between the UE 3 and the first RAN node 5-1 may fail (at step S302). For example, a radio link failure (RLF) may occur if, by way of example only, there are interference issues, coverage issues, or the like.

　　Having lost the connection with the first RAN node 5-1 due to interference issues, coverage issues, or the like, the UE 3 may begin necessary procedures to search for a new RAN node 5 with which to communicate. For example, the UE 3 may identify a second RAN node 5-2 with which it wishes to establish a connection (e.g., by scanning for SSBs from neighbouring RAN nodes 5, or the like), and the UE 3 and the second RAN node 5-2 (i.e., a target RAN node 5-2) may begin an appropriate RRC re-establishment procedure S304.

　　Although not shown, it will be appreciated that an appropriate RRC re-establishment procedure may, by way of example only, include the transmission of RRC connection re-establishment request and complete messages, as well as the transmission of RRC (re)configuration messages where appropriate. Furthermore, where the UE 3 has experienced an RLF, the RRC re-establishment complete message may, where appropriate, include a flag to indicate that RLF information (e.g., a RLF report) is available and can be reported by the UE 3 upon request.

　　During the RRC re-establishment procedure (or after completing the RRC re-establishment procedure), the second RAN node 5-2 with which the UE 3 is performing (has performed) the RRC re-establishment procedure may send an appropriate UE information request message to the UE 3 at step S306 to request appropriate UE-related information from the UE 3. For example, the UE information request may request the UE 3 to provide the second RAN node 5-2 (and consequently the network) with a RLF report that outlines the reasons for any RLF that the UE 3 has recently experienced i.e., the reasons for the RLF between the UE 3 and the first RAN node 5-1 at step S302.

　　At step S308, in response to the UE information request at step S306, the UE 3 may send a UE information response message, which may include, amongst other things, a RLF report of the UE 3. That RLF report may include an indication of an identity of the previous RAN node 5-1 with which the UE experienced a RLF (e.g., an ID of the first RAN node 5-1), along with a reason/cause indication for that RLF (e.g., 'too late handover'). It will be appreciated that in order to assist retrieval of relevant information collected at the network-side as part of a UE context, the UE 3 may include a C-RNTI used in its last serving cell.

　　At step S310, having received the RLF report from the UE 3, the second RAN node 5-2 may perform an appropriate failure indication procedure to indicate the RLF between the UE 3 and the first RAN node 5-1 (and there reasons therefore) to other RAN nodes 5 in the area.

　　For example, the second RAN node 5-2 may send appropriate messages to other RAN nodes 5 (which may include the first RAN node 5-1 and one or more additional RAN-nodes 5-X) in the area over an appropriate interface respectively between the second RAN node 5-2 and each other RAN node 5-1, 5-X (e.g., an appropriate base station to base station interface (e.g., the so-called 'X2' interface in LTE or the 'Xn' interface in NR)) that use a same physical cell ID (PCI) signalled by the UE 3 during the re-establishment procedure. That appropriate message may, by way of example only, include a failure cell ID, or the like, to indicate the cell over which the RLF occurred with the UE 3, along with a cell radio-network temporary ID (C-RNTI) allocated to the UE 3 within the cell over which the RLF occurred.

　　Alternatively, the second RAN node 5-2 may perform an appropriate failure indication procedure to indicate the RLF between the UE 3 and the first RAN node 5-1 (and the reasons therefore) via a central entity (e.g., O-RAN RIC) for future reporting to other RAN nodes 5-1, 5-X. For example, the second RAN node 5-2 may send appropriate messages to a central entity over an appropriate interface between the second RAN node 5-2 and the central entity (e.g., an E2 interface, or the like). Subsequently, the central entity may send appropriate messages to other RAN nodes 5-1, 5-X in the area.

　　Upon receiving the message from the second RAN node 5-2 or the central entity, the other RAN nodes 5-1, 5-X may select a UE context, or information from the UE context (e.g., based on the received failure cell ID and C-RNTI indicated in the message), if such a UE context is available. Where a UE context is available, the other RAN node 5-1, 5-X may use an appropriate message authentication code (e.g., provided in a short message authentication code - integrity (ShortMAC-I field)), or the like, to confirm the identity of the identified UE context.

　　It will be appreciated that the second RAN node 5-2 may also perform a failure indication procedure with the first RAN node 5-1 (i.e., the last serving RAN node 5 of the UE 3) to indicate to the first RAN node 5-1 the causes/reasons for the RLF from the UE's perspective. For example, a failure indication procedure may be triggered when the second RAN node 5-2 fetches the RLF report from the UE 3 by either a) triggering the failure indication procedure with the first RAN node 5-1 over an appropriate base station to base station interface (e.g., the so-called 'X2' interface in LTE or the 'Xn' interface in NR), or b) triggering an uplink and downlink RAN configuration transfer procedure over an appropriate base station to core network interface (e.g., the so-called 'NG' interface in NR).

　　< 'Too Early' Handover >
　　In another example, an RLF may occur in a second cell (Cell B) provided by a second RAN node 5-2 after a handover procedure has been executed to hand the UE 3 over from a first RAN node 5-1 to a second RAN node 5-2. In response to such an RLF event, the UE 3 may attempt to re-establish its radio link in a first cell (Cell A) provide by the first RAN node 5-1.

　　Fig. 4 is a simplified sequence diagram illustrating another handover failure and subsequent re-establishment procedure that may occur in the communication system 1. The handover in this example is said to be 'too early', and thus the handover failure is a 'too early handover' failure.

　　As shown in Fig. 4, there is provided a UE 3 that has an RRC connection with a first RAN node 5-1 (e.g., a source RAN node 5-1) allowing it to receive from, and transmit to, the first RAN node 5-1. The first RAN node 5-1 may provide a first cell (Cell A) for the UE 3 to communicate with the RAN node 5-1 over. Furthermore, the RAN node 5-1 provides a first radio access technology (RAT), e.g., 6G RAT, NR, LTE, or the like.

　　There is also provided a second RAN node 5-2, which may act as a target RAN node 5-2 for handover purposes. The second RAN node 5-2 may provide a second cell (Cell B) for the UE 3 to be handed over to, allowing the UE 3 to communicate with the RAN node 5-2 over that second cell. Furthermore, the RAN node 5-1 may provide a second RAT, e.g., 6G RAT, NR, LTE, or the like. The second RAT provided by the second RAN node 5-2 may be a different RAT from the first RAT provided by the first RAN node 5-1.

　　At step S402, the UE 3, the first RAN node 5-1, and the second RAN node 5-2 may perform an appropriate handover procedure to hand the UE 3 over from the first RAN node 5-1 to the second RAN node 5-2. It will be appreciated that such handover procedures may be similar to the handover procedure shown in Fig. 2. For example, during the handover procedure, the first RAN node 5-1 may decide to perform a handover of the UE 3 to the second RAN node 5-2 and may send an appropriate handover request message to the second RAN node 5-2 and an appropriate RRC reconfiguration message, or the like, to the UE 3.

　　Shortly after completion of the handover procedure at step S402 and RRC connection establishment at step S404, the radio link between the UE 3 and the second RAN node 5-2 may fail (at step S406). For example, RLF may occur if, by way of example only, there are interference issues, coverage issues, or the like. Alternatively, during the handover procedure at step S402 and prior to RRC connection establishment at step S404, the radio link between the UE 3 and the second RAN node 5-2 may fail (at step S406).

　　Having lost the connection with the second RAN node 5-2 due to interference issues, coverage issues, or the like, following a completed handover procedure, or alternatively having lost the connection with the second RAN node 5-2 during the handover procedure, the UE 3 may begin necessary procedures to reconnect with the network. For example, the UE 3 may decide that it wishes to re-establish a connection with the first RAN node 5-1 to which it was connected with prior to the handover procedure at step S402. The UE 3 and the first RAN node 5-1 (i.e., a target RAN node 5-2) may begin an appropriate RRC re-establishment procedure S408.

　　During the RRC re-establishment procedure (or after completing the RRC re-establishment procedure), the first RAN node 5-1 with which the UE 3 is performing (has performed) the RRC re-establishment procedure may send an appropriate UE information request message to the UE 3 at step S410 to request appropriate UE-related information from the UE 3. For example, the UE information request may request the UE 3 to provide the first RAN node 5-1 (and consequently the network) with a RLF report that outlines the reasons for any RLF that the UE 3 has recently experienced at step S406 (i.e., the RLF the UE 3 experienced with the second RAN node 5-2).

　　At step S412, in response to the UE information request at step S410, the UE 3 may send a UE information response message, which may include, amongst other things, a RLF report of the UE 3. That RLF report may, amongst other things, include an indication of an identity of the previous RAN node 5 with which the UE experienced a RLF (e.g., an ID of the second RAN node 5-2), along with a reason/cause indication for that RLF (e.g., 'too early handover'). It will be appreciated that in order to assist retrieval of relevant information collected at the network-side as part of a UE context, the UE 3 may include a C-RNTI used in its last serving cell.

　　At step S414, having received the RLF report from the UE 3, the first RAN node 5-1 may perform an appropriate failure indication procedure to indicate the RLF between the UE 3 and the second RAN node 5-2 (and the reasons therefore) to other RAN nodes in the area. For example, the first RAN node 5-1 may send appropriate messages to other RAN nodes (which may include the second RAN node 5-2 and one or more additional RAN-nodes 5-X) in the area over an appropriate interface respectively between the first RAN node 5-1 and each other RAN node 5-2, 5-X (e.g., an appropriate base station to base station interface (e.g., the so-called 'X2' interface in LTE or the 'Xn' interface in NR)) that use a same cell ID (PCI) signalled by the UE 3 during the re-establishment procedure. That appropriate message may, by way of example only, include a failure cell ID, or the like, to indicate the cell over which the RLF occurred with the UE 3, along with a cell radio-network temporary ID (C-RNTI) allocated to the UE 3 within the cell over which the RLF occurred.

　　Alternatively, the first RAN node 5-1 may perform an appropriate failure indication procedure to indicate the RLF between the UE 3 and the second RAN node 5-1 (and the reasons therefore) via a central entity (e.g., O-RAN RIC) for future reporting to other RAN nodes 5-2, 5-X. For example, the first RAN node 5-1 may send appropriate messages to a central entity over an appropriate interface between the first RAN node 5-1 and the central entity (e.g., an E2 interface). Subsequently, the central entity may send appropriate messages to other RAN nodes 5-2, 5-X in the area.

　　Upon receiving the message, the other RAN nodes 5-2, 5-X may select a UE context (or information from the UE context) (e.g., based on the received failure cell ID and C-RNTI indicated in the message), if such a UE context is available. Where a UE context is available, the other RAN node 5-2, 5-X may use an appropriate message authentication code (e.g., provided in a short message authentication code - integrity (ShortMAC-I field)), or the like, to confirm the identity of the identified UE context.

　　It will be appreciated that the first RAN node 5-1 may also perform a failure indication procedure with the second RAN node 5-2 to indicate to the second RAN node 5-2 the causes/reasons for the RLF from the UE's perspective. For example, a failure indication procedure may be triggered when the first RAN node 5-1 fetches the RLF report from the UE 3 by either a) triggering the failure indication procedure with the second RAN node 5-2 over an appropriate base station to base station interface (e.g., the so-called 'X2' interface in LTE or the 'Xn' interface in NR), or b) triggering an uplink and downlink RAN configuration transfer procedure over an appropriate base station to core network interface (e.g., the so-called 'NG' interface in NR).

　　If the cause for the failure is identified as a "Too Early handover", the RAN node 5 controlling the last serving cell (e.g., the second RAN node 5-2) may, include in a handover report message or the like, the C-RNTI used in the source cell of the last completed handover before the failure. If the RAN node 5 (e.g., the first RAN node 5-1) controlling that source cell also provided appropriate mobility information to the UE 3, that mobility information may also be included in the handover report message or the like. If used, that mobility information may be prepared at the RAN node 5 controlling the source cell (e.g., the first RAN node 5-1) and may refer to or identify any handover-related data at that RAN node 5.

　　< 'Handover to Wrong Cell' >
　　In another example, an RLF may occur in a second cell (Cell B) provided by a second RAN node 5-2 after a handover procedure has been executed to hand the UE 3 over from a first RAN node 5-1 to a second RAN node 5-2. In response to such an RLF event, the UE 3 may attempt to establish its radio link in a different cell from the first and second cells (e.g., a third cell C) provide by a third RAN node 5-3.

　　Fig. 5 is a simplified sequence diagram illustrating another handover failure and subsequent re-establishment procedure that may occur in the communication system 1. The handover in this example is said to be to the 'wrong cell', and thus the handover failure is a 'handover to wrong cell' failure.

　　As shown in Fig. 5, there is provided a UE 3 that has an RRC connection with a first RAN node 5-1 (e.g., a source RAN node 5-1) allowing it to receive from, and transmit to, the first RAN node 5-1. The first RAN node 5-1 may provide a first cell (Cell A) for the UE 3 to communicate over with the RAN node 5-1. There is also provided a second RAN node 5-2, which may act as a target RAN node 5-2 for handover purposes. The second RAN node 5-2 may provide a second cell (Cell B) for the UE 3 to be handed over to, allowing the UE 3 to communicate with the RAN node 5-2 over that second cell.

　　At step S502, the UE 3, the first RAN node 5-1, and the second RAN node 5-2 may perform an appropriate handover procedure to hand the UE 3 over from the first RAN node 5-1 to the second RAN node 5-2. It will be appreciated that such handover procedure may be similar to the handover procedure shown in Fig. 2. For example, during the handover procedure, the first RAN node 5-1 may decide to perform a handover of the UE 3 to the second RAN node 5-2 and may send an appropriate handover request message to the second RAN node 5-2 and an appropriate RRC reconfiguration message, or the like, to the UE 3.

　　Shortly after completion of the handover procedure at step S502 and RRC connection establishment at step S504, the radio link between the UE 3 and the second RAN node 5-2 may fail (at step S506). For example, RLF may occur if, by way of example only, there are interference issues, coverage issues, or the like. Alternatively, during the handover procedure at step S502 and prior to RRC connection establishment at step S504, the radio link between the UE 3 and the second RAN node 5-2 may fail (at step S506).

　　Having lost the connection with the second RAN node 5-2 due to interference issues, coverage issues, or the like, shortly following a completed handover procedure, or alternatively having lost the connection with the second RAN node 5-2 during the handover procedure, the UE 3 may begin necessary procedures to search for a new RAN node 5-3 with which to communicate. For example, the UE 3 may decide that it wishes to establish a connection (e.g., by scanning for SSBs, or the like) with a third RAN node 5-3 different from the first RAN node 5-1 and the second RAN node 5-2. For example, where both a handover has been initiated from the first RAN node 5-1 but the initial target RAN node 5-2 (e.g., the second RAN node 5-2) is not appropriate. The UE 3 and a third RAN node 5-3 (i.e., a target RAN node 5-3) may begin an appropriate RRC re-establishment procedure S508.

　　During the RRC re-establishment procedure (or after completing the RRC re-establishment procedure), the third RAN node 5-3 with which the UE 3 is performing (has performed) the RRC establishment procedure may send an appropriate UE information request message to the UE 3 at step S510 to request appropriate UE-related information from the UE 3. For example, the UE information request may request the UE 3 to provide the third RAN node 5-3 (and consequently the network) with a RLF report that outlines the reasons for any RLF that the UE 3 has recently experienced at step S506 (i.e., the RLF the UE 3 experienced with the second RAN node 5-2).

　　At step S512, in response to the UE information request at step S510, the UE 3 may send a UE information response message, which may include, amongst other things, a RLF report of the UE 3. That RLF report may, amongst other things, include an indication of an identity of the previous RAN node 5-2 with which the UE experienced a RLF (e.g., second RAN node 5-2), along with a reason/cause indication for that RLF (e.g., 'handover to wrong cell'). It will be appreciated that in order to assist retrieval of relevant information collected at the network-side as part of a UE context, the UE 3 may include a C-RNTI used in its last serving cell.

　　At step S514, having received the RLF report from the UE 3, the third RAN node 5-3 may perform an appropriate failure indication procedure to indicate the RLF between the UE 3 and the second RAN node 5-2 (and the reasons therefore) to any other RAN nodes 5 in the area. For example, the third RAN node 5-3 may send appropriate messages to other RAN nodes 5 (which may include the second RAN node 5-2, and one or more additional RAN-nodes 5-X) in the area over an appropriate interface respectively between the third RAN node 5-3 and each other RAN node 5-2, 5-X (e.g., an appropriate base station to base station interface (e.g., the so-called 'X2' interface in LTE or the 'Xn' interface in NR)) that use a same PCI signalled by the UE 3 during the re-establishment procedure.

　　Alternatively, the third RAN node 5-3 may perform an appropriate failure indication procedure to indicate the RLF between the UE 3 and the second RAN node 5-2 (and the reasons therefore) via a central entity (e.g., O-RAN RIC) for future reporting to other RAN nodes 5-2, 5-X. For example, the third RAN node 5-3 may send appropriate messages to a central entity over an appropriate interface between the third RAN node 5-3 and the central entity (e.g., an E2 interface). Subsequently, the central entity may send appropriate messages to other RAN nodes 5-2, 5-X in the area.

　　It will be appreciated that the third RAN node 5-3 may also perform a failure indication procedure with the second RAN node 5-2 to indicate to that RAN node 5-2 the causes/reasons for the RLF from the UE's perspective. For example, a failure indication procedure may be triggered when the third RAN node 5-3 fetches the RLF report from the UE 3 by either a) triggering the failure indication procedure with the second RAN node 5-2 over an appropriate base station to base station interface (e.g., the so-called 'X2' interface in LTE or the 'Xn' interface in NR), or b) triggering an uplink and downlink RAN configuration transfer procedure over an appropriate base station to core network interface (e.g., the so-called 'NG' interface in NR).

　　If the cause for the failure is identified as a "Handover to wrong cell", the RAN node 5-2 controlling the last serving cell (e.g., the second RAN node 5-2) may, include in a handover report message or the like, the C-RNTI used in the source cell of the last completed handover before the failure. If the RAN node 5-1 (e.g., the first RAN node 5-1) controlling that source cell also provided appropriate mobility information to the UE 3, that mobility information may also be included in the handover report message or the like. If used, that mobility information may be prepared at the RAN node 5 controlling the source cell (e.g., the first RAN node 5-1) and may refer to or identify any handover-related data at that RAN node 5.

　　'Unnecessary' and 'Ping-pong' Handover
　　In yet another example, a RLF may not occur, however a handover procedure may be performed unnecessarily. For example, the UE 3 may be handed over from a first RAN node 5-1 providing coverage in a first cell (Cell A) that provides a first RAT to the UE 3 (e.g., 6G RAT, NR, LTE, or the like) to a second RAN node 5-2 providing coverage in a second cell (Cell B) that provides a second RAT to the UE 3 (e.g., 6G RAT, NR, LTE or the like) even though the coverage provided by the first RAT is sufficient for the needs of the UE 3.

　　One specific example of an 'Unnecessary' Handover is a so-called 'ping-pong' handover where, despite no RLF occurring, a handover procedure may be performed to hand over the UE 3 from the first RAN node 5-1 to the second RAN node 5-2 before handing the UE 3 back to the first RAN node 5-1 within a predefined period of time despite the coverage provided by the first RAN node 5-1 being sufficient for the needs of the UE 3.

　　< Handover Counters >
　　It will be appreciated that such 'Too late', 'Too early', 'Handover to Wrong Cell', 'unnecessary' and/or 'ping-pong' handovers described can reduce the performance of a communication system 1 and may also result in communication delays and overall system stability issues. It is with this in mind that failure indication procedure described above at steps S310, S414, and S514 have been introduced to provide greater mobility robustness optimisation (MRO). In particular, MRO provides means to distinguish between 'Too late', 'Too early', 'Wrong cell', 'unnecessary' and/or 'ping-pong' handovers from NR coverage related issues and other issues not related to mobility. Part of that failure indication procedure may, by way of example, include adjusting and indicating values of appropriate counters to indicate the occurrence of such 'Too late', 'Too early', 'Handover to Wrong Cell', 'unnecessary' and/or 'ping-pong' handovers to an appropriate function of the communication system 1 to analyse handover failures and to respond accordingly.

　　Those counters may, by way of example, be stored, at a 'source' RAN node 5-1 (e.g., the first RAN node 5-1), a central entity (e.g., an O-RAN), or another RAN node 5 of the communication system 1 that is configured to perform MRO procedures and algorithms. Examples of such appropriate counters are listed below in Table 1.
Table 1 - Example of counters implemented to account for different types of handover failures

　　The counters outlined above may be used to reduce issues associated with handover failures such as those described above with reference to Figs. 3-5. In one example, where a 'Too early handover' failure occurs between the first RAN node 5-1 and the second RAN node 5-2, the HO.IntraSys.TooEarly and/or HO.InterSys.TooEarly counters may be updated (i.e., their value may be appropriately incremented), which may be stored at the first RAN node 5-1. Having incremented those counters, the first RAN node 5-1, using appropriate MRO mechanisms may decide to delay a handover to the second RAN node 5-2 based on the values of those counters. Alternatively, those counters may be stored at an O-RAN of the communication system 1, which may decide, using appropriate MRO mechanisms, whether or not to delay the triggering of a handover procedure with the first RAN node 5-1 based on the values of those counters.

　　In another example, where a 'Too late handover' failure occurs between the first RAN node 5-1 and the second RAN node 5-2, the HO.IntraSys.TooLate and/or HO.InterSys.TooLate counters may be updated (i.e., their value may be appropriately incremented), which may be stored at the first RAN node 5-1. Having incremented those counters, the first RAN node 5-1, using appropriate MRO mechanisms, may decide to trigger a handover to the second RAN node 5-2 earlier than might overwise be the case based on the values of those counters. Alternatively, those counters may be stored at an O-RAN of the communication system 1, which may, using appropriate MRO mechanisms, decide whether or not to trigger a handover procedure with the first RAN node 5-1 at an earlier time than would overwise be the case based on the values of those counters.

　　In yet another example, where a 'Handover to wrong cell' failure occurs between the first RAN node 5-1 and the second RAN node 5-2, the HO.IntraSys.ToWrongCell counter may updated (i.e., their value may be appropriately incremented), which may be stored at the first RAN node 5-1. Having incremented those counters the first RAN node 5-1 may, using appropriate MRO mechanisms, decide to delay a handover to the second RAN node 5-2 based on the values of those counters. Alternatively, those counters may be stored at an O-RAN of the communication system 1, which may, using appropriate MRO mechanisms, decide whether or not to delay the triggering of a handover procedure with the first RAN node 5-1 based on the values of those counters.

　　It will be appreciated by those skilled in the art that the counters HO.InterSys.Unnecessary and HO.InterSys.Ping-pong may be used in a somewhat similar fashion as that described above as so a full description thereof is not given here.

　　By way of example only, appropriate MRO mechanisms that may be used by the first RAN node 5-1 to delay a handover or trigger a handover early may include updating appropriate handover parameters such as a cell individual offset and/or a time-to-trigger value.

　　For example, where the first RAN node 5-1 decides to delay a handover to the second RAN node 5-2, the appropriate MRO mechanisms may include setting a cell individual offset of a neighbor cell (target cell of a 'Too early' handover) to a low value, and/or increasing a value of a time-to-trigger parameter.

　　In another example, where the first RAN node 5-1 decides to trigger a handover to the second RAN node 5-2 early, the appropriate MRO mechanisms may include setting a cell individual offset of a neighbor cell (target cell of a 'Too late' handover) to a high value, and/or decreasing a value of a time-to-trigger parameter.

　　However, while the counters described above may beneficially reduce handover failure events between the first RAN node 5-1 providing a first cell (cell A) and the second RAN node 5-2 providing a second cell (cell B), such counters cannot account for subsequent handover failures that may occur to neighbouring cells of the second cell (cell B) i.e., cells with which cell B has cell neighbour cell relations (NCRs). For example, where there are NCRs between the second cell (cell B) and a third and fourth cell (cell C and D) provided by a third and a fourth RAN node 5-3, 5-4, the counters used to determine how to proceed with a handover between the first cell (cell A) and the second cell (cell B) cannot also take account of handover failures that may occur subsequently in the second cell (cell B) when subsequent handover events to the third or fourth cell (cell C or D) are triggered.

　　As such, even when such counters are used to reduce handover failure events between the first RAN node 5-1 providing the first cell (cell A) and the second RAN node 5-2 providing the second cell (cell B), subsequent handover failures may still occur reducing the overall mobility robustness of the communication system 1.

　　Furthermore, it will be appreciated that for certain UEs 3 (e.g., UEs 3 moving at high speed such as UEs 3 located in a car, train, or the like) ping-pong handovers and subsequent handover failures (e.g., between successive neighbouring cells) can result in many failures occurring over a relatively small period of time causing significant disruption to service provision. There is therefore a need for mechanisms and/or procedures that reduce the number of handover failures experienced by the UE 3 in a communication system 1 to improve service provision in the communication system 1, especially in scenarios where the UE 3 is handed over between successive neighbouring cells.

　　Beneficially, the communication system 1 is configured to support one or more mechanisms and/or procedures that reduce the number of handover failures experienced by the UE 3 in the communication system 1. In particular, the communication system 1 is configured to support one or more mechanisms and/or procedures that use and/or adapt the concept of automatic neighbour relations (ANRs) to reduce the number of handover failures experienced by the UE 3.

　　< Automatic neighbour relations (ANRs) >
　　ANRs are automatically generated neighbour relations that are identified between the cells 9 of one RAN node 5 and the cells 9 of another neighbouring RAN node 5. Those ANRs may be stored in an appropriate table locally at the RAN node 5 and/or the neighbouring RAN node 5 to enable improved mobility, load balancing, dual connectivity (DC), and the like. ANRs are managed by an appropriate ANR function located at the RAN node 5 and/or the neighbouring RAN node 5.

　　Fig. 6 illustrates an example ANR function that may be provided at the first RAN node 5-1. As shown in Fig. 6 there is provided the first RAN node 5-1 that supports an ANR function 60-1, as well as other functions 60-n. Nevertheless, it will be appreciated that the ANR function shown in Fig. 6 and described below may also be provided at any other RAN node 5-2, 5-X of the communication system 1.

　　The ANR function 60-1 provided at the first RAN node 5-1 is configured to manage a Neighbour Cell Relation Table (NCRT) which includes any appropriate information necessary for managing the neighbour relationships between neighbouring cells (e.g., a source cell and one or more target cells). For example, as shown in Fig. 6, the NCRT may include an NCR number (e.g., 1, 2, 3, etc.) which provides a unique identifier of each NCR entry in the NCRT. Each entry in the NCRT may also include a target cell identifier (TCI) of a target cell (e.g., a neighbouring cell provided by the neighbouring RAN node 5-2, 5-X), an indication as to whether the NCR can be removed from the NCRT, an indication as to whether the NCR is to be used by the RAN node 5-1 for handover purposes ('No Handover') and, an indication as to whether a NCR may use an appropriate base station to base station link, or the like, to initiate procedures toward the RAN node 5 providing the target cell ('No base station to base station interface').

　　It will nevertheless be appreciated that the information described above in the NCRT is by way of example only and that any appropriate information may be stored in the table.

　　Located within the ANR function 60-1 is a neighbour detection function 62 that is configured to find new neighbour cells and to add them to the NCRT. For example, as shown in Fig. 6, the neighbour detection function 62 may send appropriate management request messages during an RRC procedure or the like to the UE 3 to instruct the UE 3 to perform measurements on neighbouring cells. Having performed those measurements, the UE 3 may send one or more measurement reports regarding neighbouring cells to the neighbour detection function 62. Upon receipt of those measurement reports, neighbour detection function 62 may send appropriate messages and/or triggers to an NCRT management function 64, which may decide to add one or more neighbour cell relation entries into its NCRT for the neighbour cells that it has received measurement reports on from the UE 3.

　　By maintaining a table of neighbour relationships between cells (e.g., between a source cell and target cells) as described above the first RAN node 5-1 controlling the source cell can identify neighbouring target cells to which the UE 3 may be handed over. Additionally, maintaining such a table of neighbour relations at the first RAN node 5-1 means the first RAN node 5-1 knows the global and physical IDs (e.g., 6G cell global identifier / 6G physical cell identifier, NR cell global identifier (CGI) / NR PCI, E-UTRAN cell global identifier (ECGI) / LTE physical cell identifier) of the target cells, and knows attributes associated with those target cells.

　　The ANR function 60-1 may also be provided with a corresponding neighbour removal function 66 that sends appropriate messages and/or triggers to the NCRT management function 64 to remove one or more neighbour cell relation entries from the NCRT.

　　As shown in Fig. 6, an operation, administration, and maintenance (OAM) function 68 may also be provided that may also manage the NCRT. For example, the OAM function 68 may be able to add and delete NCRs from the NCRT, as well as change attributes of the NCRT and entries therein. The OAM function 68 may also be configured such that it is informed of changes to the NCRT (e.g., changes caused by the NCRT management function 64).

　　Beneficially, by using and/or adapting the concept of ANRs described above the number of handover failures experienced by the UE 3 can be reduced.

　　For example, the communication system 1 may be beneficially configured to allow the blocking of handovers of the UE 3 from the first RAN node 5-1 to the second RAN node 5-2 when that second RAN node 5-2 has previously experienced very high handover failure rates during subsequent handovers (e.g., handovers from the second RAN node 5-2 to another RAN node 5 (e.g., a third RAN node 5-3)) - for example due to the neighbour cell relations of that second (target) RAN node 5-2. For example, handovers of the UE 3 from the first RAN node 5-1 to the second RAN node 5-2 may be blocked where it is determined that subsequent handovers of the UE 3 from the second RAN node 5-2 to another neighbouring RAN node 5 (e.g., a third RAN node 5-3) are highly likely to fail.

　　In response to that determination the UE 3 may, for example, be kept in a cell provided by the first RAN node 5-1 rather than being handed over to a cell provided by the second RAN node 5-2. Alternatively, in response to that determination, the UE 3 may be handed over from a cell provided by the first RAN node 5-1 directly to a cell provided by another RAN node 5 (e.g., a third RAN node 5-3 that neighbours the second RAN node 5-2).

　　There now follows a detailed description a mechanism and/or procedure to reduce the number of handover failures experienced by the UE 3 in a communication system 1 with reference to Fig. 7A and 7B.

　　< ANR Handover (HO) blocking using failure statistics >
　　Figs. 7A and 7B are a simplified sequence diagram illustrating a 'Too Late' handover failure detection procedure for handover failures of neighbour-related cells that may occur in the communication system 1.

　　As shown in Figs. 7A and 7B, there is provided a UE 3, a first RAN node 5-1 with which the UE 3 is initially in communication (e.g., and which acts as the 'original' or 'first' source RAN node 5-1 of the procedure); a second RAN node 5-2 to which the UE 3 is successfully handed over to from the first RAN node 5-1 in the illustrated procedure; and a third RAN node 5-3 to which the UE 3 should be handed over to during the illustrated procedure (but to which handover is not triggered in time, e.g., due to an RLF - i.e., a 'too late' handover).

　　At step S702, having perform a successful handover to (or appropriate connection (re)establishment procedure with) the first RAN node 5-1 (not shown), the UE 3 may perform data transmissions with the first RAN node 5-1. For example, having successfully established a connection with the first RAN node 5-1 over a cell provided by the first RAN node 5.1 (e.g., cell A), the UE 3 and the first RAN node 5-1 may begin transmitting data to each other.

　　Sometime later at step S704, a handover procedure such as that described with reference to Fig. 2 may be triggered. For example, although not shown, the first RAN node 5-1 may make a HO decision and send an appropriate handover request to another RAN node 5-2 (e.g., second RAN node 5-2) to request that a handover of the UE 3 be performed from the first RAN node 5-1 (operating as a source RAN node 5-1) to the second RAN node 5-2 (operating as a target RAN node 5-2).

　　After completing the handover procedure at step S704, the second RAN node 5-2 (i.e., the target RAN node 5-2 of the last successful handover) may store UE mobility history information in its memory at step S706. For example, the second RAN node 5-2 may store in its memory appropriate information pertaining to the UE's mobility history. The stored information may, for example, include: an ID of the UE 3; an ID of the last RAN node 5-1 serving the UE 3 (e.g., the first RAN node 5-1 / source RAN node 5-1 of the last successful handover); an ID of the last cell that the UE 3 visited and communicated over (e.g., an ID of cell A); and/or like. The information that is stored may, for example, be received from the UE 3 and/or the first RAN node 5-1 during the previous handover procedure. By way of example only, that information may be provided to the second RAN node 5-2 in appropriate information elements (IEs) of a handover request message (e.g., UEHistoryInformationFromUE IE, UEHistoryInformation IE, etc.), or the like, sent to the second RAN node 5-2 by the first RAN node 5-1 during the start of a handover procedure such as that shown in Fig. 2. Nevertheless it will be appreciated that such information may also be provided to the second RAN node 5-2 by the UE 3 itself following successful completion of the handover procedure between the UE 3, the first RAN node 5-1, and the second RAN node 5-2.

　　Additionally, any UE mobility history information stored at the second RAN node 5-2 at step S706 may have an appropriate expiry timer applied to it such that the information expires and/or is deleted from the memory of the second RAN node 5-2 after a (pre)configured period.

　　At step S708 (which may occur immediately after the completion of step S704 or step S706, or which may occur sometime after the completion of step S704 or step S706) the UE 3 may perform data transmissions with the second RAN node 5-2 (now operating as a current serving RAN node 5-2).

　　Sometime later, at step S710, an RLF may occur, for example, because the second RAN node 5-2 has failed to trigger handover of the UE 3 to the third RAN node 5-3 in time.

　　Having lost the connection with the second RAN node 5-2 (i.e., the intended source RAN node 5-2 of the 'too late' handover) the UE 3 may begin necessary procedures to search for a new RAN node 5-3 with which to communicate. For example, the UE 3 may identify the third RAN node 5-3 (i.e., the intended target RAN node 5-3 of the 'too late' handover) and may begin an appropriate RRC re-establishment procedure at S712. More particularly, at step S712, the UE 3 may send an appropriate RRC (re-)establishment request to the third RAN node 5-3, which may, by way of example only, include an appropriate message containing a PCI of the previous ('source') cell being provided by the last RAN node 5-2 (e.g., second RAN node 5-2) that the UE 3 was communicating with prior to RLF.

　　It will be appreciated that following the transmission of an appropriate RRC (re-)establishment request to the third RAN node 5-3, an appropriate RRC re-establishment procedure is triggered which may include, by way of example only, the transmission of RRC connection re-establishment message (at step S714) and complete messages (at step S716), as well as the transmission of RRC (re)configuration messages where appropriate (not shown).

　　Furthermore, where the UE 3 has experienced an RLF, the RRC re-establishment complete message may, where appropriate, include a flag to indicate that RLF information (e.g., a RLF report) is available and can be reported by the UE 3 upon request, or alternatively that an RLF report will be reported by the UE 3 within a certain set of resources.

　　During the RRC re-establishment procedure (or after completing the RRC re-establishment procedure), the third RAN node 5-3 may send an appropriate UE information request message to the UE 3 (not shown) to request appropriate UE-related information from the UE 3. For example, the UE information request may request the UE 3 to provide the third RAN node 5-3 (and consequently the network) with a RLF report that outlines the reasons for any RLF that the UE 3 has recently experienced i.e., the reasons for the RLF between the UE 3 and the second RAN node 5-2 at step S710. Additionally, that RLF may include, amongst other things, an indication of an identity of the previous RAN node 5-2 with which the UE 3 experienced a RLF (e.g., second RAN node 5-2). It will be appreciated that in order to assist retrieval of relevant information collected at the network-side as part of a UE context, the UE 3 may include a C-RNTI used in its last serving cell.

　　Having received the RLF report from the UE 3, the third RAN node 5-3 may perform an appropriate failure indication procedure to indicate the RLF between the UE 3 and the second RAN node 5-2 (and the reasons therefore) to any other RAN nodes 5 in the area, e.g., in the form of an appropriate failure report or the like. For example, the third RAN node 5-3 may perform a failure indication procedure with the second RAN node 5-2 (and possibly one or more additional RAN nodes 5) to indicate to the causes/reasons for the RLF from the UE's perspective (step S718). For example, the failure indication procedure may be triggered when the third RAN node 5-3 fetches the RLF report from the UE 3 by either a) triggering the failure indication procedure with the second RAN node 5-2 over an appropriate base station to base station interface (e.g., the so-called 'X2' interface in LTE or the 'Xn' interface in NR), or b) triggering an uplink and downlink RAN configuration transfer procedure over an appropriate base station to core network interface (e.g., the so-called 'NG' interface in NR).

　　Alternatively, the third RAN node 5-3 may perform an appropriate failure indication procedure to indicate the RLF between the UE 3 and the second RAN node 5-2 (and the reasons therefore) via a central entity (e.g., O-RAN RIC) for future reporting to the second RAN node 5-2.

　　Upon receiving the message, the second RAN node 5-2 may select a UE context (or information from the UE context) (e.g., based on the received failure cell ID and C-RNTI indicated in the message), if such a UE context is available. Where a UE context is available, the second RAN node 5-2 may use an appropriate message authentication code (e.g., provided in a short message authentication code - integrity (ShortMAC-I field)), or the like, to confirm the identity of the identified UE context.

　　Having received the failure report at step S718, the second RAN node 5-2 may also increment an appropriate counter (e.g., a 'TooLateHo' counter such as listed in Table 1) at the second RAN node 5-2 corresponding to the number of times a 'too late' handover has occurred at the second RAN node 5-2 with the UE 3 (step S720).

　　The remainder of the 'Too Late' handover failure detection procedure for handover failures of neighbour-related cells is continued in Fig. 7B.

　　As seen at step S722, the second RAN node 5-2 may (as a first option) increment another appropriate counter stored at the second RAN node 5-2 for monitoring handovers that are not triggered in time from a target cell of a successful handover (e.g., a 'TooLateInTargetAfterHO' counter, or the like). This may occur, for example, in response to receiving the failure report at step S718, and/or in response to incrementing the counter at step S720 (e.g., a 'TooLateHo' counter such as listed in Table 1). It can be seen that the newly incremented (e.g., 'TooLateInTargetAfterHO') counter is effectively a counter for the number of unsuccessful subsequent handovers to another RAN node 5-3 (e.g., the third RAN node 5-3 in this example), after a previous successful handover to the RAN node 5-2 incrementing the counter (the second RAN node 5-2 in this example). The newly incremented (e.g., 'TooLateInTargetAfterHO') counter thus beneficially takes account of handover failures with neighbour-related cells and RAN nodes 5 providing those cells.

　　It will be appreciated that the first option may not be appropriate in all scenarios - for example where mobility robustness optimisation (MRO) algorithms for the communication system 1 are executed at the first RAN node 5-1 (as the first RAN node 5-1 is not informed of the value of, and does not maintain, the newly incremented (e.g., 'TooLateInTargetAfterHO') counter). Nevertheless, it will be appreciated that the first option may be suitable in scenarios where the MRO algorithms for the communication system 1 are executed at a central entity such as an O-RAN RIC, or the like.

　　Having incremented the counter (e.g., a 'TooLateInTargetAfterHO' counter, or the like) stored at the second RAN nodes 5-2 (first option), a central entity such as an O-RAN RIC, or the like may be informed (not shown) of the latest value of that counter via an appropriate message, and the central entity may execute appropriate MRO procedures and algorithms.

　　For example, having been informed of the latest value of the counter the central entity (e.g., an O-RAN RIC) may, based on whether the value of the counter is above a (pre)configured threshold, decide to block future handovers of the UE 3 from the first RAN node 5-1 to the second RAN node 5-2 on the basis that subsequent handovers of the UE 3 from the second RAN node 5-2 to other RAN nodes 5 (e.g., the third RAN node 5-3) regularly suffer from handover failure events.

　　To block such handover from the first RAN node 5-1 to the second RAN node 5-2, the central entity, which may host an ANR function 60-1, may update its NCRT by the NCRT management function 64 of the ANR function 60-1 to indicate that handovers to target cells of the second RAN node 5-2 should not be performed (i.e., they are blocked), thereby forcing the UE 3 to either remain in a cell provided by the first RAN node 5-1, or forcing the UE 3 to be handed over to a different RAN node 5 other than the second RAN node 5-2 - for example, the UE 3 may be handed over directly to the third RAN node 5-3 rather than the second RAN node 5-2.

　　In one example, updating the NCRT to indicate that handovers to target cells of the second RAN node 5-2 should not be performed may involve updating an appropriate field in the NCRT (e.g., a HO allowed field, or the like) to indicate whether or not handover to the cell provided by the second RAN node 5-2 is allowed or not.

　　In another example, a measurement configuration can be updated to achieve a blocking-like effect.. For example, where appropriate, a cell individual offset value associated with a cell provided by the second RAN node 5-2 that is to be blocked may be reduced to a very low value to reduce the probability of the UE 3 being handed over from the first RAN node 5-1 to the second RAN node 5-2. Additionally, or alternatively, where appropriate, a time-to-trigger (TTT) value associated with a cell provided by the second RAN node 5-2 that is to be blocked may be increased to a high value to reduce the probability of the UE 3 being handed over from the first RAN node 5-1 to the second RAN node 5-2.

　　It will be appreciated that the field described above are by way of example only and that any other appropriate fields and/or parameters in the NCRT may be updated to reduce the probability of the UE 3 being handed over from the first RAN node 5-1 to the second RAN node 5-2.

　　As seen at step S724 the second RAN node 5-2 may (as a second option which may be in addition to, or as an alternative to, the first option) send its own failure report (or forward the failure report it received) to the first RAN node 5-1.

　　At step S726 the first RAN node 5-1 may (as a second option) increment another appropriate counter stored at the first RAN node 5-1 for monitoring handovers that are not triggered in time from a target cell of a successful handover (e.g., a 'TooLateInTargetAfterHO' counter, or the like). This may occur, for example, in response to receiving the failure report at step S724. It can be seen that the newly incremented (e.g., 'TooLateInTargetAfterHO') counter is effectively a counter for the number of unsuccessful subsequent handovers to another RAN node 5 (e.g., the third RAN node 5-3 in this example), after a previous successful handover to the RAN node 5-2 incrementing the counter (the second RAN node 5-2 in this example). The newly incremented (e.g., 'TooLateInTargetAfterHO') counter thus beneficially takes account of handover failures with neighbour-related cells and RAN nodes 5 providing those cells.

　　It will be appreciated that the second option may be suitable in all scenarios - for example where mobility robustness optimisation (MRO) algorithms for the communication system 1 are executed at the first RAN node 5-1 and/or a central entity such as an O-RAN RIC, or the like.

　　Having incremented the counter (e.g., a 'TooLateInTargetAfterHO' counter, or the like) stored at the first RAN nodes 5-1 (first option), a central entity such as an O-RAN RIC, or the like may be informed (not shown) of the latest value of that counter via an appropriate message, and the central entity may execute appropriate MRO procedures and algorithms. Alternatively, the first RAN node 5-1 itself may execute appropriate MRO procedures and algorithms.

　　Where an O-RAN RIC executes the appropriate MRO procedures and algorithms, by way of example only, having been informed of the latest value of the TooLateInTargetAfterHO counter, the O-RAN RIC may, based on whether the value of the TooLateInTargetAfterHO counter is above a (pre)configured threshold, decide to block future handovers of a UE 3 from the first RAN node 5-1 to the second RAN node 5-2 on the basis that subsequent handovers of the UE 3 from the second RAN node 5-2 regularly suffer from handover failure events.

　　Alternatively, where the first RAN node 5-1 executes the appropriate MRO procedures and algorithms, the first RAN node 5-1 may, based on whether the value of the newly incremented (e.g., TooLateInTargetAfterHO) counter is above a (pre)configured threshold, decide to block future handovers of a UE 3 from the first RAN node 5-1 to the second RAN node 5-2 on the basis that subsequent handovers of the UE 3 from the second RAN node 5-2 regularly suffer from handover failure events.

　　For example, to block such handovers the first RAN node 5-1, which may host an ANR function 60-1, may update its NCRT by the NCRT management function 64 of the ANR function 60-1 to indicate that handovers to target cells of the second RAN node 5-2 should not be performed (i.e., they are blocked), thereby forcing the UE 3 to either remain in a cell provided by the first RAN node 5-1, or forcing the UE 3 to be handed over to a different RAN node 5 (e.g., a third RAN node 5-3) other than the second RAN node 5-2 - for example, the UE 3 may be handed over directly to the third RAN node 5-3 rather than the second RAN node 5-2.

　　In another example, updating the NCRT to indicate that handovers to target cells of the second RAN node 5-2 should not be performed may involve updating any appropriate parameter or parameters in the NCRT in such a way as to block HO. For example, where appropriate, a cell individual offset value associated with a cell provided by the second RAN node 5-2 that is to be blocked may be reduced to a very low value to reduce the probability of the UE 3 being handed over from the first RAN node 5-1 to the second RAN node 5-2. Additionally, or alternatively, where appropriate, a TTT value associated with cell provided by the second RAN node 5-2 that is to be blocked may be increased to a high value to reduce the probability of the UE 3 being handed over from the first RAN node 5-1 to the second RAN node 5-2.

　　It will be appreciated that the field and parameters described above are by way of example only and that any other appropriate fields or parameters in the NCRT may be updated to reduce the probability of the UE 3 being handed over from the first RAN node 5-1 to the second RAN node 5-2.

　　< Maintaining newly incremented (e.g., 'TooLateInTargetAfterHO') counter >
　　The newly incremented counter (e.g., 'TooLateInTargetAfterHO') stored at the second RAN node 5-2, or the first RAN node 5-1 described in the procedures above shown in Fig. 7A and 7B may be maintained at the second RAN node 5-2 or the first RAN node 5-1 for a longer time than the amount of time that other counters such as those listed in Table 1 are maintained. For example, the counter may be maintained at the second RAN node 5-2 or the first RAN node 5-1 for the same amount of time that UE context information may be stored at those RAN nodes 5, i.e. it may be stored at either of those RAN nodes 5 up until the expiration of an appropriate timer (e.g., a Tstore_UE_cntxt timer), or the like.

　　Alternatively, the counter may be maintained at the second RAN node 5-2 or the first RAN node 5-1 until the expiration of another appropriate timer that may be (pre)configured at the first and/or second RAN node 5-1, 5-2.

　　< 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.

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

　　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.

　　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.

　　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.

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

　　< 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.

　　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.

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

　　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.

　　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).

　　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.

　　< 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.

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

　　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.

　　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.

　　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.

　　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.

　　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.

　　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.

　　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.).

　　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.).

　　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.).

　　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.).

　　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.).

　　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.

　　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)).

　　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.

　　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.

　　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.

　　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 2. This list is not exhaustive and is intended to be indicative of some examples of machine type communication applications.

　　　　

　　Table 2

　　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.

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

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

　　This application is based upon and claims the benefit of priority from UK patent application No. 2407764.6, filed on May 31, 2024, the disclosure of which is incorporated herein in its entirety by reference.

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

　　For example, the whole or part of the example embodiments disclosed above can be described as, but not limited to, the following supplementary notes.
(Supplementary note 1)
　　A method performed by a first access network node, the method comprising:
　　controlling to avoid a handover from the first access network node to a second access network node, based on a failure of a handover from the second access network node to a third access network node after a successful handover from the first access network node to the second access network node.
(Supplementary note 2)
　　The method according to supplementary note 1, wherein
　　the controlling is performed using an automatic neighbour relation (ANR) management.
(Supplementary note 3)
　　The method according to supplementary note 2, wherein
　　the ANR management includes updating a neighbour cell relation table.
(Supplementary note 4)
　　The method according to any one of supplementary notes 1 to 3, wherein
　　the controlling is performed by blocking the handover from the first access network node to the second access network node or modifying at least one parameter for the handover to the second access network node.
(Supplementary note 5)
　　The method according to any one of supplementary notes 1 to 4, wherein
　　the controlling is performed based on a number of failures of the handover from the second access network node to the third access network node after the successful handover from the first access network node to the second access network node.
(Supplementary note 6)
　　The method according to supplementary note 5, wherein
　　the number of the failures of the handover from the second access network node to the third access network node after the successful handover from the first access network node to the second access network node is maintained by either the first access network node or the second access network node.
(Supplementary note 7)
　　The method according to supplementary note 6, wherein
　　the number of the failures of the handover from the second access network node to the third access network node after the successful handover from the first access network node to the second access network node is maintained based on a failure report from the third access network node after reestablishment of a connection to a mobile device.
(Supplementary note 8)
　　The method according to any one of supplementary notes 1 to 7, wherein
　　the controlling is initiated by receiving information from a central entity, and
　　the number of the failures of the handover from the second access network node to the third access network node after the successful handover from the first access network node to the second access network node is used by the central entity for use in mobility robustness optimization (MRO).
(Supplementary note 9)
　　The method according to any one of supplementary notes 1 to 8, wherein
　　the controlling is performed based on information of a mobility history of a mobile device for the handover.
(Supplementary note 10)
　　A method performed by a second access network node, the method comprising:
　　performing a handover from a first access network node and the second access network node; and
　　detecting a failure of a handover from the second access network node to a third access network node, wherein
　　a number of failures of the handover from the second access network node to the third access network node after the successful handover from the first access network node to the second access network node is updated by either the first access network node or the second access network node, for use by the first access network node in controlling to avoid a handover from the first access network node to the second access network node.
(Supplementary note 11)
　　A first access network node comprising:
　　means for controlling to avoid a handover from the first access network node to a second access network node, based on a failure of a handover from the second access network node to a third access network node after a successful handover from the first access network node to the second access network node.
(Supplementary note 12)
　　A second access network node comprising:
　　means for performing a handover from a first access network node and the second access network node; and
　　means for detecting a failure of a handover from the second access network node to a third access network node, wherein
　　a number of failures of the handover from the second access network node to the third access network node after the successful handover from the first access network node to the second access network node is updated by either the first access network node or the second access network node, for use by the first access network node in controlling to avoid a handover from the first access network node to the second access network node.

1　　communication system
3, 3-1, 3-2, 3-3　　UEs
5　　radio access network (RAN) node
5-1　　first RAN node
5-2　　second RAN node
5-3　　third RAN node
5-4　　fourth RAN node
7　　core network
9, 9-1, 9-2　　cells
10　　control plane functions (CPFs)
10-1　　access and mobility management Functions (AMFs)
10-2　　session management function (SMF)
11　　user plane functions (UPFs)
20　　external data network
60-1　　ANR function
60-n　　other functions
62　　neighbour detection function
64　　NCRT management function
66　　neighbour removal function
68　　operation, administration, and maintenance (OAM) function
31, 51　　transceiver circuit
33, 53　　antenna
35　　user interface
37, 57　　controller
39, 59　　memory
41, 61　　operating system
43, 63　　communications control module
55　　core network interface

Claims

　　A method performed by a first access network node, the method comprising:
　　controlling to avoid a handover from the first access network node to a second access network node, based on a failure of a handover from the second access network node to a third access network node after a successful handover from the first access network node to the second access network node.
　　The method according to claim 1, wherein
　　the controlling is performed using an automatic neighbour relation (ANR) management.
　　The method according to claim 2, wherein
　　the ANR management includes updating a neighbour cell relation table.
　　The method according to any one of claims 1 to 3, wherein
　　the controlling is performed by blocking the handover from the first access network node to the second access network node or modifying at least one parameter for the handover to the second access network node.
　　The method according to any one of claims 1 to 4, wherein
　　the controlling is performed based on a number of failures of the handover from the second access network node to the third access network node after the successful handover from the first access network node to the second access network node.
　　The method according to claim 5, wherein
　　the number of the failures of the handover from the second access network node to the third access network node after the successful handover from the first access network node to the second access network node is maintained by either the first access network node or the second access network node.
　　The method according to claim 6, wherein
　　the number of the failures of the handover from the second access network node to the third access network node after the successful handover from the first access network node to the second access network node is maintained based on a failure report from the third access network node after reestablishment of a connection to a mobile device.
　　The method according to any one of claims 1 to 7, wherein
　　the controlling is initiated by receiving information from a central entity, and
　　the number of the failures of the handover from the second access network node to the third access network node after the successful handover from the first access network node to the second access network node is used by the central entity for use in mobility robustness optimization (MRO).
　　The method according to any one of claims 1 to 8, wherein
　　the controlling is performed based on information of a mobility history of a mobile device for the handover.
　　A method performed by a second access network node, the method comprising:
　　performing a handover from a first access network node and the second access network node; and
　　detecting a failure of a handover from the second access network node to a third access network node, wherein
　　a number of failures of the handover from the second access network node to the third access network node after the successful handover from the first access network node to the second access network node is updated by either the first access network node or the second access network node, for use by the first access network node in controlling to avoid a handover from the first access network node to the second access network node.
　　A first access network node comprising:
　　means for controlling to avoid a handover from the first access network node to a second access network node, based on a failure of a handover from the second access network node to a third access network node after a successful handover from the first access network node to the second access network node.
　　A second access network node comprising:
　　means for performing a handover from a first access network node and the second access network node; and
　　means for detecting a failure of a handover from the second access network node to a third access network node, wherein
　　a number of failures of the handover from the second access network node to the third access network node after the successful handover from the first access network node to the second access network node is updated by either the first access network node or the second access network node, for use by the first access network node in controlling to avoid a handover from the first access network node to the second access network node.