EP4690711A1

EP4690711A1 - Determining legitimate target cells for user equipment (ue) mobility operations

Info

Publication number: EP4690711A1
Application number: EP23932247.2A
Authority: EP
Inventors: Konstantinos Vandikas; Prajwol Kumar NAKARMI; Stefan Engström
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2023-04-07
Filing date: 2023-07-20
Publication date: 2026-02-11
Also published as: WO2024210781A1

Abstract

Embodiments include methods for determining legitimate candidate cells for UE operations in a RAN. Such methods include determining a graph representation of a plurality of cells in the RAN based on a plurality of UE measurement reports. The graph representation includes the plurality of cells as graph nodes and relations between respective pairs of cells as graph edges. Such methods include training a graph neural network (GNN) model based on the graph representation and cell information for the plurality of cells. Such methods include receiving, from a UE, a first measurement report including radio-related measurements of the UE's serving cell and of a plurality of neighbor cells to the serving cell, and based on the first measurement report and the trained GNN model, determining whether one or more of the plurality of neighbor cells is a legitimate candidate for an operation by the UE in the RAN.

Description

DETERMINING LEGITIMATE TARGET CELLS FOR USER EQUIPMENT (UE) MOBILITY OPERATIONS

TECHNICAL FIELD

The present disclosure relates generally to cellular communication networks, and more specifically to techniques for improving the capability of a radio access network (RAN) to determine legitimate cells for user equipment (UE) operations (e.g., handover), using graph neural network (GNN) models.

BACKGROUND

Long-Term Evolution (LTE) is an umbrella term for so-called fourth generation (4G) radio access technologies developed within the Third-Generation Partnership Project (3GPP) and initially standardized in Release 8 (Rel-8) and Release 9 (Rel-9), also known as Evolved UTRAN (E-UTRAN). LTE is targeted at various licensed frequency bands and is accompanied by improvements to non-radio aspects commonly referred to as System Architecture Evolution (SAE), which includes Evolved Packet Core (EPC) network. LTE continues to evolve through subsequent releases.

Currently the fifth generation (“5G”) of cellular systems, also referred to as New Radio (NR), is being standardized within the Third-Generation Partnership Project (3GPP). NR is developed for maximum flexibility to support multiple and substantially different use cases. These include enhanced mobile broadband (eMBB), machine type communications (MTC), ultra-reliable low latency communications (URLLC), side-link device-to-device (D2D), and several other use cases.

Seamless mobility is a key feature of all 3GPP radio access technologies (RATs), including 5G/NR and earlier generations such as 4G/LTE. In general, a radio access network (RAN) configures a UE to perform and report radio resource management (RRM) measurements to assist network-controlled mobility decisions, such as for handover from a serving cell to a neighbor cell. Seamless handovers ensure that the UE moves around in the coverage area of different cells without excessive interruption to data transmission.

However, there will be scenarios when the network fails to handover the UE to the “correct” neighbor cell in time, which can cause the UE to declare radio link failure (RLF) or handover failure (HOF). An RLF reporting procedure was introduced as part of mobility robustness optimization (MRO) in LTE Release 9 (Rel-9) and is also used in 5G. In this procedure, a UE logs relevant information at the time of RLF and later reports such information to the network via a target cell to which the UE ultimately connects (e.g., after reestablishment). The reported information can include RRM measurements of various neighbor cells prior to the mobility operation (e.g., handover), as well as a physical cell identity (PCI) associated with each measurement. PCI is a short cell identifier that is unique within a small geographic area but may be reused further away. Each cell also has a globally unique identity called a cell global identity (CGI), but this is not reported with UE RRM measurements.

Such UE-reported information can be used by Self-Organizing Network (SON) functionality, which is an automation technology used to improve the planning, configuration, management, optimization, and healing of mobile RANs. SON functionality can broadly be categorized as either self-optimization, self-configuration, or self-healing. Self-optimization employs UE and network measurements to auto-tune the RAN. This occurs when RAN nodes are in an operational state, after the node’s RF transmitter interface is switched on. Self-configuration operations include optimization and adaptation, which are generally performed before the RAN nodes are in operational state. Self-healing enables automatic detection and removal of failures and automatic adjustment of parameters.

SON features include MRO, dynamic configuration, automatic neighbor relations (ANR), mobility load balancing (MLB), random access channel (RACH) optimization, capacity and coverage optimization (CCO), and mobility settings change. SON features are described in 3GPP TS 38.300 (v!7.3.0) for NR networks and in 3GPP TS 36.300 (v!7.3.0) for LTE networks.

ANR functionality resides in each RAN node and manages a Neighbor Cell Relation Table (NCRT). ANR for each RAN node includes a Neighbor Detection Function (NDF) that finds new neighbor cells (e.g., based on measurement reports from UEs) and adds them to the NCRT, as well as a Neighbor Removal Function (NRF) that removes outdated NCRs. NDF and NRF are not standardized by 3GPP (i.e., implementation specific). When a RAN node detects anew neighbor cell, the RAN node attempts to establish or set up an interface (e.g., X2 for LTE, Xn for 5G) to another RAN node that serves the detected neighbor cell.

SUMMARY

Even so, ANR can be vulnerable to a false (or illegitimate) node attempting to impersonate a legitimate RAN node. For example, an illegitimate node can operate with multiple illegitimate PCIs, for which UEs will report RRM measurements to legitimate RAN nodes, causing them to attempt to establish interfaces with the illegitimate node. This can strain limited inter-node signaling resources of the legitimate RAN nodes. Also, reports of a neighbor cell with a conflicting (i.e., illegitimate) PCI can cause a RAN node providing the legitimate cell with that same PCI to restart this cell, resulting in dropped connections for all UEs served by this cell. Moreover, illegitimate PCIs can hijack UE handovers, leading to excessive RLF reports that need to be addressed by legitimate RAN nodes. Solutions to these problems, issues, and/or difficulties are needed.

An object of embodiments of the present disclosure is to improve robustness of ANR and related functionality in RANs, such as by providing, enabling, and/or facilitating solutions to overcome exemplary problems summarized above and described in more detail below.

Embodiments include methods (e.g., procedures) for determining legitimate candidate cells for UE operations in a radio access network (RAN, e.g., E-UTRAN, NG-RAN).

These exemplary methods can include determining a graph representation of a plurality of cells in the RAN based on a plurality of UE measurement reports. The graph representation includes the plurality of cells as graph nodes and relations between respective pairs of the cells as graph edges. These exemplary methods can also include training a graph neural network (GNN) model based on the graph representation and cell information for each of the plurality of cells. These exemplary methods can also include receiving from a UE a first measurement report that includes radio-related measurements of the UE’s serving cell and of a plurality of neighbor cells to the UE’s serving cell. These exemplary methods can also include, based on the first measurement report and the trained GNN model, determining whether one or more of the plurality of neighbor cells is a legitimate candidate for an operation by the UE in the RAN.

In some embodiments, the graph representation includes one or more of the following: a positive graph representing relations that exist between respective pairs of cells, and a negative graph representing relations that do not exist between respective pairs of cells. In some embodiments, the GNN model includes a graph convolutional (Gconv) input layer coupled to a multi-layer neural network configured to perform regression or classification.

Other embodiments include network nodes or functions (NNFs, e.g., RAN nodes, CN functions, SMO functions, NM nodes, etc.) configured to perform operations corresponding to any of the exemplary methods described herein. Other embodiments include non-transitory, computer-readable media storing program instructions that, when executed by processing circuitry, configure such NNFs to perform operations corresponding to any of the exemplary methods described herein. Other embodiments include a computer program product comprising program instructions that, when executed by processing circuitry, configure such NNFs to perform operations corresponding to any of the exemplary methods described herein.

Other embodiments include a network analytics system configured to determine legitimate candidate cells for user equipment, UE, operations in a RAN. The network analytics system includes a training function configured to determine a graph representation of a plurality of cells in the RAN based on UE radio-related measurements of the plurality of cells. The graph representation includes the plurality of cells as graph nodes and relations between respective pairs of the cells as graph edges. The training function is also configured to train a graph neural network (GNN) model based on the graph representation and one or more of the following: the configuration parameters for each of the cells, and mobility statistics for respective pairs of the cells.

The network analytics system also includes a measurement collection function configured to obtain the UE radio-related measurements used to determine the graph representation and subsequently receive from a UE a first measurement report that includes radio-related measurements of the UE’s serving cell and of a plurality of neighbor cells to the UE’s serving cell. The network analytics system also includes an inference function configured to determine, based on the first measurement report and the trained GNN model, whether one or more of the plurality of neighbor cells is a legitimate candidate for an operation by the UE in the RAN.

These and other embodiments described herein can provide various advantages, benefits, and/or solutions to problems. For example, embodiments can be used to “sanitize” cell relation tables maintained locally in each RAN node or globally in OAM. Furthermore, embodiments can be applied on-demand to determine invalid cell relations for individual cells, thereby preventing addition of illegitimate cells to cell relations tables and UE handover attempts to such cells. At the same time, embodiments can have little or no impact on ANR activity and UE handover to legitimate new cells. Once trained, embodiments can be applied automatically with little or no further manual intervention, e.g., based on a policy that does not strain network resources. In this manner, RAN operation can be improved by avoiding interactions with illegitimate UEs, cells, and RAN nodes.

These and other objects, features, and advantages of embodiments of the present disclosure will become apparent upon reading the following Detailed Description in view of the Drawings briefly described below.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 shows a high-level view of an exemplary 4G/LTE network architecture.

Figure 2 shows a high-level view of an exemplary 5G/NR network architecture.

Figures 3-4 show logical architectures for a gNB arranged in a split CU/DU architecture.

Figure 5 shows an exemplary protocol stack for the Xn-C interface between gNBs.

Figure 6 shows an exemplary ANR function of a RAN node.

Figure 7 shows an example network analytics system according to some embodiments of the present disclosure.

Figure 8 shows an exemplary graph neural network (GNN) according to some embodiments of the present disclosure. Figures 9A and 9B show positive and negative graphs, respectively, representing exemplary relations between four cells in a RAN.

Figures 10-12 show signaling diagrams for various scenarios involving handover of a UE from a source cell provided by a source RAN node to a target cell provided by a target RAN node.

Figure 13 shows an exemplary edge explainability graph, according to some embodiments of the present disclosure.

Figure 14 shows a high-level diagram of an Open RAN (O-RAN) architecture in which some embodiments of the present disclosure can be implemented.

Figure 15 (which includes Figures 15A-B) shows an exemplary method (e.g, procedure) for determining legitimate target cells for UE mobility operations in a RAN, according to various embodiments of the present disclosure.

Figure 16 shows a communication system according to various embodiments of the present disclosure.

Figure 17 shows a network node according to various embodiments of the present disclosure.

Figure 18 shows a host computing system according to various embodiments of the present disclosure.

Figure 19 is a block diagram of a virtualization environment in which functions implemented by some embodiments of the present disclosure may be virtualized.

DETAILED DESCRIPTION

Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Other embodiments, however, are contained within the scope of the subject matter disclosed herein, the disclosed subject matter should not be construed as limited to only the embodiments set forth herein; rather, these embodiments are provided as examples to convey the scope of the subject matter to those skilled in the art.

Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and/or is implied from the context in which it is used. All references to a/an/the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any methods and/or procedures disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and/or where it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein can be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments can apply to any other embodiments, and vice versa. Other objects, features, and advantages of the enclosed embodiments will be apparent from the following description.

Furthermore, the following terms are used throughout the description given below:

• Radio Access Node: As used herein, a “radio access node” (or equivalently “radio network node,” “radio access network node,” or “RAN node”) can be any node in a radio access network (RAN) of a cellular communications network that operates to wirelessly transmit and/or receive signals. Some examples of a radio access node include, but are not limited to, a base station (e.g, a New Radio (NR) base station (gNB) in a 3GPP Fifth Generation (5G) NR network or an enhanced or evolved Node B (eNB) in a 3GPP LTE network), base station distributed components (e.g., CU and DU), a high-power or macro base station, a low-power base station (e.g, micro, pico, femto, or home base station, or the like), an integrated access backhaul (IAB) node (or component thereof such as MT or DU), a transmission point, a remote radio unit (RRU or RRH), and a relay node.

• Core Network Node: As used herein, a “core network node” is any type of node in a core network. Some examples of a core network node include, e.g., a Mobility Management Entity (MME), a serving gateway (SGW), a Packet Data Network Gateway (P-GW), etc. A core network node can also be a node that implements a particular core network function (NF), such as an access and mobility management function (AMF), a session management function (SMF), a user plane function (UPF), a Service Capability Exposure Function (SCEF), or the like.

• Wireless Device: As used herein, a “wireless device” (or “WD” for short) is any type of device that is capable, configured, arranged and/or operable to communicate wirelessly with network nodes and/or other wireless devices. Communicating wirelessly can involve transmitting and/or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and/or other types of signals suitable for conveying information through air. Unless otherwise noted, the term “wireless device” is used interchangeably herein with the term “user equipment” (or “UE” for short), with both of these terms having a different meaning than the term “network node”.

• Radio Node: As used herein, a “radio node” can be either a “radio access node” (or equivalent term) or a “wireless device.”

• Network Node: As used herein, a “network node” is any node that is either part of the radio access network (e.g, a radio access node or equivalent term) or of the core network (e.g, a core network node discussed above) of a cellular communications network. Functionally, a network node is equipment capable, configured, arranged, and/or operable to communicate directly or indirectly with a wireless device and/or with other network nodes or equipment in the cellular communications network, to enable and/or provide wireless access to the wireless device, and/or to perform other functions (e.g, administration) in the cellular communications network.

The above definitions are not meant to be exclusive. In other words, various ones of the above terms may be explained and/or described elsewhere in the present disclosure using the same or similar terminology. Nevertheless, to the extent that such other explanations and/or descriptions conflict with the above definitions, the above definitions should control.

Note that the description given herein focuses on a 3GPP cellular communications system and, as such, 3GPP terminology or terminology similar to 3GPP terminology is oftentimes used. However, the concepts disclosed herein are not limited to a 3GPP system. Furthermore, although the term “cell” is used herein, it should be understood that (particularly with respect to 5G NR) beams may be used instead of cells and, as such, concepts described herein apply equally to both cells and beams.

An overall exemplary architecture of a network comprising LTE and SAE is shown in Figure 1. The evolved UMTS terrestrial RAN (E-UTRAN, 199) includes one or more evolved Node B’s (eNBs, e.g., 105, 110, 115) and one or more user equipment (UEs, e.g., 120). The E- UTRAN is responsible for radio-related functions in the network, including radio bearer control, radio admission control, radio mobility control, scheduling, and dynamic allocation of resources to UEs in uplink (UL) and downlink (DL), as well as security of the communications with the UE. These functions reside in the eNBs (e.g., 105, 110, 115). Each eNB serves a geographic coverage area including one or more cells, such as cells 106, 111, and 116 served by eNBs 105, 110, and 115, respectively.

The eNBs in the E-UTRAN communicate with each other via X2 interfaces and with the evolved packet core network (EPC, 198) via SI interfaces. Specifically, the eNBs communicate with mobility management entities (MMEs) and serving gateways (SGWs) in the EPC, denoted collectively as MME/S-GWs 134 and 138 in Figure 1. In general, the MME handles overall control of UEs (i.e., control plane) and S-GWs handle UE data flows within the EPC and to external data networks (i.e., user plane). More specifically, the S-GW handles all Internet Protocol (IP) data packets (between UE and EPC, and serves as a local mobility anchor for data bearers when the UE moves between cells and eNBs.

Figure 2 shows a high-level view of an exemplary 5G network architecture, including NG- RAN 299 and 5GC 298. As shown in the figure, NG-RAN 299 can include gNBs (e.g., 210a,b) and ng-eNBs (e.g, 220a, b) that are interconnected via respective Xn interfaces. The gNBs and ng-eNBs are also connected via NG interfaces to 5GC 298, more specifically to the Access and Mobility Management Functions (AMFs, e.g. , 230a,b) via respective NG-C interfaces and to User Plane Functions (UPFs, e.g., 240a, b) via respective NG-U interfaces. Moreover, the AMFs can communicate with one or more policy control functions (PCFs, e.g., 250a, b) and network exposure functions (NEFs, e.g., 260a, b).

Each of the gNBs can support the NR radio interface including frequency division duplexing (FDD), time division duplexing (TDD), or a combination thereof. Each of ng-eNBs can support the LTE radio interface. Unlike conventional LTE eNBs, however, ng-eNBs connect to the 5GC via the NG interface. Each of the gNBs and ng-eNBs can serve a geographic coverage area including one or more cells, such as cells 21 la-b and 221a-b shown in Figure 2. Depending on the cell in which it is located, a UE 205 can communicate with the gNB or ng-eNB serving that cell via the NR or LTE radio interface, respectively. Although Figure 2 shows gNBs and ng-eNBs separately, it is also possible that a single NG-RAN node provides both types of functionality.

Each gNB shown in Figure 2 may be logically divided into a Central Unit (CU or gNB- CU) and one or more Distributed Units (DU or gNB-DU). CUs are logical nodes that host higher- layer protocols and perform various gNB functions such as controlling the operation of DUs, which are logical nodes that host lower layer protocols. Figure 3 shows a logical architecture for a gNB arranged in the split CU/DU architecture, such as gNBs 210a-b in Figure 2. This logical architecture separates the CU into CP and UP functionality, called CU-C and CU-U respectively. Furthermore, each of the NG, Xn, and Fl interfaces is split into a CP interface (e.g., NG-C) and a UP interface (e.g., NG-U). Note that the terms “Central Entity” and “Distributed Entity” in Figure 3 refer to physical network nodes.

Figure 4 shows another exemplary gNB logical architecture that includes two gNB-DUs, a gNB-CU-CP, and multiple gNB-CU-UPs. The gNB-CU-CP may be connected to the gNB-DU through the Fl-C interface, and the gNB-CU-UP may be connected to the gNB-DU through the Fl-U interface and to the gNB-CU-CP through the El interface. Each gNB-DU may be connected to only one gNB-CU-CP, and each gNB-CU-UP may be connected to only one gNB-CU-CP. One gNB-DU may be connected to multiple gNB-CU-UPs under the control of the same gNB-CU-CP. Also, one gNB-CU-UP may be connected to multiple DUs under the control of the same gNB- CU-CP. When referring herein to an operation performed by a “CU”, it should be understood that this operation can be performed by any entities within the CU (e.g., CU-CP, gNB-CU-CP) unless stated otherwise.

Figure 5 shows an exemplary protocol stack for the Xn-C interface between gNBs. The radio network layer (RNL) portion at the top is based on the XnAP protocol, while the transport network layer (TNL) portion at the bottom is based on Stream Control Transmission Protocol (SCTP) and Internet Protocol (IP). These transport protocols are above implementation-specific data link and physical layers. Since SCTP is a point-to-point protocol, each gNB has a separate Xn interface to each of the neighboring gNBs that it communicates with.

As specified in 3GPP TS 38.423 (17.3.0), the XnAP protocol for the Xn interface includes mobility procedures and global procedures. One of the global procedures is the Xn Setup procedure for establishing an Xn interface between two peer RAN nodes (e.g., gNBs). In this procedure, one of the RAN nodes sends an Xn Setup Request message that includes a complete (or partial, if supported) list of cells served by that node. If the Xn setup is accepted, the peer RAN node responds with an Xn Setup Response message that a complete (or partial, if supported) list of cells served by the peer RAN node.

Before performing an Xn Setup procedure with a peer RAN node, a RAN node can obtain an address of the peer RAN node in multiple ways. First, addresses of various peer RAN nodes can be manually configured in the RAN node’s memory. Second, the RAN node can be triggered to obtain the address of a peer RAN node based on one or more unrecognized cell identities from measurement reports of UEs served by the RAN node. The RAN node can send these cell identities to a domain name service (DNS), tor an operational support system (OSS) associated with the 5G network, or to the peer RAN node via the core network. In any case, the receiving entity may respond with the associated address(es) of the peer RAN node(s) serving these cells. This second technique is often referred to as “automatic Xn establishment.”

Automatic Xn establishment is related to functionality called “automatic neighbor relations” (ANR), which resides in each gNB and manages a Neighbor Cell Relation Table (NCRT). ANR functionality includes a Neighbor Detection Function (NDF) that finds new neighbor cells based on measurement reports from UEs and adds them to the NCRT. ANR functionality also includes a Neighbor Removal Function (NRF) that removes outdated NCRs. NDF and NRF are not standardized by 3GPP (i.e., implementation specific).

In general, a RAN (e.g., NG-RAN) configures a UE to perform and report radio resource management (RRM) measurements to assist network-controlled mobility decisions, such as for handover from a serving cell to a neighbor cell. The reported information can include RRM measurements of serving cell and neighbor cells, as well as a physical cell identity (PCI) associated with each measurement. PCI is a short cell identifier that is unique within a small geographic area but may be reused further away. Each cell also has a globally unique identity called a cell global identity (CGI), which is normally not reported with UE RRM measurements, but can be separately requested to be reported by the UE.

Figure 6 shows an exemplary ANR function of a gNB. Note that the ANR function includes an NCRT management function that is responsible for managing the NCRT for each cell based on inputs from a neighbor detection function (NDF), a neighbor removal function (NRF), and OAM, as well as for providing NCR reports to 0AM. Information exchanged during an Xn Setup procedure can be used to populate NCRTs for a gNB’s source cells. Even so, NCRs are cell- to-cell relations while an Xn connection is set up between two gNBs. Also, NCRs are unidirectional while an Xn connection is bidirectional.

An NCR from a source cell to a target cell means that a gNB controlling the source cell knows the global and physical IDs of the target cell e(.g., NR CGI/NR PCI or ECGI/PCI) and has an entry in its NCRT for the source cell that identifies the target cell. Additionally, each NCRT entry includes various attributes associated with the corresponding target cell, which are defined by OAM or set to default values by the gNB associated with the NCRT source cell. The NCRT shown in Figure 6 includes some exemplary attributes for target cells. In addition to setting target cell attributes, OAM can add and delete NCRs from an NCRT.

ANR is a subset of Self-Organizing Network (SON) functionality, which is an automation technology used to improve the planning, configuration, management, optimization, and healing of mobile RANs. SON functionality can broadly be categorized as either self-optimization, selfconfiguration, or self-healing. Self-optimization employs UE and network measurements to autotune the RAN. This occurs when RAN nodes are in an operational state, after the node’s RF transmitter interface is switched on. Self-configuration operations include optimization and adaptation, which are generally performed before the RAN nodes are in operational state. Self- healing enables automatic detection and removal of failures and automatic adjustment of parameters. SON features are described in 3GPP TS 38.300 (v!7.3.0) for NR networks and in 3GPP TS 36.300 (v!7.3.0) for LTE networks.

Even so, SON has various vulnerabilities when an illegitimate or rogue RAN nodes (also referred to herein as “false base station”) is introduced into a RAN. These illegitimate RAN nodes can transmit multiple illegitimate cells, each of which has an illegitimate PCI.

For example, illegitimate nodes can exploit the fact that UE's RRM measurements are considered true and not verified by the receiving RAN node. Thus, a RAN node receiving UE measurements including an unrecognized PCI will automatically consider it a new, legitimate cell and initiate ANR for that cell. This can result in various problems, issues, and/or difficulties for UEs and RANs.

First, initiation of ANR for illegitimate PCIs can strain limited inter-node signaling resources of legitimate RAN nodes. This can be particularly problematic when an illegitimate node uses multiple PCIs that are reported by UEs.

Second, UE reports that include a neighbor cell with a conflicting (i.e., illegitimate) PCI can cause a RAN node that provides the legitimate cell with the same PCI to restart cells. This results in an outage of the legitimate cell with the conflicting PCI, and possibly all cells provided by the RAN node. All UEs connections with these cells are dropped in response to the outage, causing significant connection reestablishment signaling with the RAN.

Third, if an illegitimate RAN node is able to setup connections with legitimate RAN nodes, the illegitimate RAN node may be able to cause the other RAN nodes to initiate handover of UEs to the illegitimate PCIs. Even though these handovers are likely to fail because the illegitimate RAN node lacks the necessary security credentials, this will cause RLF reports by UEs that legitimate RAN nodes must address. This can occupy RAN node processing and signaling resources that could otherwise be used for legitimate operations.

The paper “LTE Network Automation under Threat” by Shaik, et al., describes operating a false base station around legitimate UEs, resulting in many of the issues summarized above. Similar attacks can be made by operating an illegitimate UE that reports false measurements and PCIs to the RAN.

One technique to address some of these problems is requiring authentication and authorization of nodes during connection establishment. This can prevent connection establishment to illegitimate RAN nodes that lack necessary credentials, even if the illegitimate RAN nodes have access to the transport network of the RAN.

Even so, this does not fully address the strain on RAN node signaling and processing resources caused by an illegitimate RAN node. In other words, even if authentication is required, the legitimate RAN nodes still must handle UE measurement reports with illegitimate PCIs and initiate connection establishment with the illegitimate RAN nodes. This could be addressed to some extent by limiting connection establishment rate or total number of established inter-node connections, but these limits would negatively affect connection establishment with legitimate RAN nodes.

Moreover, in the event of a PCI conflict, the legitimate RAN node could forego restarting or defer until some later time. However, this strategy could also affect a RAN node’s ability to deal with actual PCI conflicts that are not due to illegitimate RAN nodes. For example, UE mobility into the conflicting PCI will continue to be disturbed until a restart is taken.

To summarize, existing techniques for detecting false base stations using measurement reports and network configuration relay on cell identifiers (e.g., PCIs) that can be easily spoofed by an attacker. As such, it is challenging for RAN nodes to detect false base stations that use PCIs that may appear to be legitimate but are actually spoofed and/or illegitimate.

Accordingly, embodiments of the present disclosure provide flexible and efficient techniques that can more accurately determine false cell relations taking into consideration structural data about the cells, their configurations, and how they relate to nearby cells. This structural data can be represented in a graph-like format, thereby facilitating the application of artificial intelligence/machine learning (AI/ML) to classify cell relations.

For example, some embodiments can use a graph neural network (GNN) to predict a likelihood of specific cell relations. If a relation between a known-valid first cell and a second cell with unknown validity is predicted to be unlikely, then a RAN node can forego or avoid UE handovers to the second cell and/or connection setup to a (possibly illegitimate) RAN node that provides the second cell. On the other hand, if a relation between a known-valid first cell and a third cell with unknown validity is predicted to be unlikely, then a RAN node can perform UE handovers to the third cell and/or connection setup to a RAN node that provides the third cell.

Embodiments can be used in various ways. For example, embodiments can be used to “sanitize” cell relation tables maintained locally in each RAN node, or globally in an Operations Administration and Management (O&M) node. Furthermore, embodiments can also be applied on-demand to determine invalid cell relations for individual cells, thereby preventing adding illegitimate cells to cell relations tables and UE handover attempts to such cells. At the same time, embodiments can have little or no impact on ANR activity and UE handover to legitimate new cells. Moreover, once trained, embodiments can be applied automatically with little or no further manual intervention, e.g., based on a policy that does not strain network resources. In this manner, RAN operation can be improved by avoiding interactions with false, illegitimate, and/or rogue cells and RAN nodes.

In the following description, the terms “nodes” and “edges” are components of a graph neural network (GNN) applied to relations between cells in a RAN. In this context, a “node” represents a cell provided by a (legitimate or illegitimate) RAN node (e.g., eNB, gNB) and an “edge” between two nodes represents a relation between two cells represented by the two nodes. For avoidance of confusion, the term “RAN node” will be used in a manner consistent with its definition elsewhere herein.

Some embodiments of the present disclosure include a network analytics system that comprises the following components or functions: measurement collection function, cell configuration database, training function, inference function, and cell manager. Figure 7 shows an example network analytics system (700) according to these embodiments. The respective functions of the network analytics system are described below.

The measurement collection function (710) collects and aggregates the data used by the training function and the inference function. Most often, this data includes UE measurements of serving and neighbor cells, such as reference signal received power (RSRP) and reference signal received quality (RSRQ). This data can be the same as, or similar to, UE measurement data used in ANR to construct relations between cells in the RAN. Thus, the measurement collection function may preferably be part of the RAN (e.g., in the various RAN nodes), but may also be part of the core network (e.g., 5GC), OAM, or a combination thereof. More generally, the measurement collection function can reside in any part(s) of the network that facilitate collection and aggregation of UE measurements.

The cell configuration database (750) contains the configuration(s) of various cells, including cell-specific parameters such as actual configured maximum transmit power for a cell (configuedMaxTxPower), maximum capable transmit power for a cell (maximumTransmissionPower), angular tilt of the antenna for a cell (antennaTilt), etc. The cell configuration database can reside centrally in OAM or can be distributed in the various RAN nodes, with each RAN node maintaining the portion concerning its served cells. The dashed outline indicates that the cell configuration database is optional.

The training function (720) uses inputs from the measurement collection function and the cell configuration database (if present) to construct an adjacency matrix, a feature space for nodes, and a feature space for edges. The adjacency matrix captures cell relations, as explained in more detail below. The feature space for nodes is a table that captures the configurations for the cells represented by the respective nodes. The feature space for edges is a matrix that contains numbers of handovers between cells. Using this information as training inputs, the training function constructs a GNN that can predict the likelihood of an edge between two nodes, i.e., a valid relation between two cells. The training function can reside centrally in OAM or CN, or can be distributed in the various RAN nodes in a similar manner as the cell configuration database. As some specific examples, the training function can reside in a network data analytics function (NWDAF) in the 5GC or in a management data analytics function (MDAF) in OAM.

The interference function (730) uses the GNN produced by the training function to predict the feasibility or likelihood of a relation between two specific cells. Put differently, after the GNN is trained using a training dataset, the inference function applies the GNN to other data (e.g., subsequent measurements) provided by the measurement collection function. The inference function can reside centrally in OAM or CN, or can be distributed in the various RAN nodes in a similar manner as the cell configuration database. As some specific examples, the inference function can reside in an NWDAF or in an MDAF.

The cell management function (740) uses the output of the inference function to perform (or refrain from performing) various actions related to ANR, UE mobility, and/or other UE operations in the RAN. For example, if a cell relation to a potential target cell for UE handover is predicted to be unlikely, then the cell management function can cancel the pending UE handover to the target cell and instead select a target cell having a more likely cell relation for the UE handover. In some embodiments, the various components or functions can be operated based on a policy. For example, even if the training function has created a GNN applicable to an entire RAN, the operation of the inference function may be limited to specific areas and/or specific times (e.g., in which illegitimate behavior previously occurred).

As mentioned above, embodiments utilize a GNN for predicting the cell relation. In general, a GNN is a neural network with a graph convolution input layer. Figure 8 shows an exemplary GNN (800) that can be used with some embodiments of the present disclosure. The Gconv layer (810) is in front of a multi-layer neural network (820) consisting of a first dense layer (821), a second dense layer (822), and a softmax layer (823). For example, the multi-layer neural network can be a multi-layer perceptron (MLP). The task of Gconv layer is to produce a latent state space representation of the cells of the RAN. The output of the Gconv layer is input to the multi-layer neural network, which leams to distinguish real/legitimate cell relations from phony/illegitimate cell relations during the training phase.

The Gconv layer can be implemented by different graph convolutional techniques such as GAT, GIN, GCN, Graphs AGE, etc. For example, Graphs AGE is an inductive framework that leverages node attribute information to efficiently generate representations on previously unseen data. More information about GraphSAGE can be found at https://snap.stanford.edu/graphsage/. Alternately, an extension of GraphSAGE (called “WeightedGraphSage”) with weighted edges can be used, with edge weight related to and/or based on number of handovers and/or handover success rate between the two cells represented by the nodes connected by the edge.

Figure 9A shows an exemplary graph representing a RAN with four cells (1-4). Every node (circle) represents a cell and every edge (line) represents a valid cell relation. For example, a UE connected to a cell 1 can receive radio signals from cells 2-3 with a high enough RSRP to generate handovers to these two cells (e.g., HOI, HO3). However, a UE connected to a cell 1 cannot receive radio signals from cell 4 with a high enough RSRP to generate handover to that cell. Thus, there are edges between node 1 and nodes 2-3, but no edge between node 1 and node 4. Other edges (or lack thereof) follow the same convention.

In practice a graph is typically represented as an NxN adjacency matrix, where N is the number of cells/nodes. A “1” in row i=l ...N, column j=l...N indicates an edge between nodes i and j while a “0” indicates no edge between nodes i and j. For example, the adjacency matrix for Figure 9A is given in tabular form below. Figure 9A is also referred to as a “positive graph” since edges represent actual cell relations. Since a goal is to train the GNN to determine whether or not an edge (or cell relation) exists, training requires additional information about edges (cell relations) that do not exist. This information is shown in Figure 9B, which is also referred to as a “negative graph”. The adjacency matrix for Figure 9B can be obtained by inverting zeros and ones from the table above, resulting in the following tabular form:

In addition to the adjacency matrices, other inputs to the GNN are vectors of configuration parameters for each cell, which can be obtained from the cell configuration database mentioned above. This can include one or more of the following for each cell, which are merely non-limiting examples of relevant parameters:

• Handover success rate, i.e., number of successful handovers to/from the cell vs. number of handovers attempted to/from the cell;

• Frequency band of cell;

• Absolute radio frequency channel number (ARFCN) used either for cell DL or cell UL (or both if TDD);

• Maximum distance of served UEs, as observed over a period of time in the cell (e.g., based on UE timing advance);

• Median or average distance of served UEs, as observed over a period of time in the cell (e.g., based on UE timing advance);

• Cell range (e.g., maximum distance) for random access by UEs;

• RRC connection establishment success rate, i.e., number of RRC connections successfully establishment in the cell vs. number of RRC connection establishments attempted in the cell;

• DL and/or UL channel bandwidths for the cell;

• Cell DL channel throughput, e.g., in bits/sec;

• Tracking area code (TAC) associated with the cell;

• Latitude/longitude/altitude of the cell antenna;

• Boresight direction (i.e., azimuth and tilt) and beamwidth (e.g., -3dB from max power) for the cell antenna; • Nominal power for physical UL control channel (PUCCH) and/or physical UL shared channel (PUSCH) in the cell, which are used in closed loop power control between UE and RAN node to overcome slow fading and are often unique/distinct for each cell; and

• Number of scheduling request (SR) messages from UEs on the cell’s PUCCH.

Given the adjacency matrix and cell vectors, the training function trains an AI/ML model to distinguish legitimate from illegitimate cell relations. Subsequently, the training function can determine a cross entropy loss between the predictions on the measurements and the positive graph (e.g., Figure 9A). The positive graph can be considered “ground truth” since it is not polluted by “fake” measurements. The cross entropy gives a measure of prediction performance of the trained model.

In some embodiments, the edges that have a small number of handovers (e.g., relative to M edges with most handovers) may be removed, which addresses unlikely cell relations that are ephemeral, malicious, or due to unknown external environmental factors. Alternatively, edges can be weighted prior to training based on numbers and/or success rates of handovers, as mentioned previously.

Embodiments are further illustrated by Figures 10-12, which show signaling diagrams related to various scenarios involving handover of a UE (1020) from a source cell provided by a source RAN node (1010) to atarget cell provided by atarget RAN node (1030). Each handover scenario involves one or more training phases followed by an operational phase. Although the operations in Figures 10-12 are given numerical labels, this is done to facilitate explanation rather than to imply or require any particular operational order, unless expressly stated otherwise.

Figure 10 shows a signaling diagram of a procedure of a localized solution, according to some embodiments of the present disclosure. This procedure involves training and operational phases for the source RAN node using information available to the source RAN node, such as UE measurement reports collected during operations 1-3. Although Figure 10 shows a single UE providing measurement reports, this is merely representative of any number of UEs providing measurement reports in this operation.

In operations 4-5, the source RAN node creates a positive graph (e.g., Figure 9A) and/or a negative graph (e.g., Figure 9B) from the collected information. Note that it may be sufficient to create one of these two graphs, since information contained in the other (non-created) graph may be derived from the created graph. In operation 6, the source RAN node trains the GNN predictor using the graphs created in operations 4-5 as well as other available information such as neighbor cell configurations and handover statistics (e.g., counts, rates) for neighbor cells. The GNN predictor is trained for each cell served by the source RAN node. Operations 4-6 are performed by the training function mentioned above in relation to other embodiments.

In the subsequent operational phase, one or more additional measurement reports are collected from a UE operating in the source cell (operations 7-9). In operation 10, these measurement reports are converted into a positive graph (g) indicating which neighbor cells are handover candidates for the UE.

Operation 11 is performed by the inference function mentioned above in relation to other embodiments. In operation 11, the positive graph (g) is input to the trained GNN predictor together with other available information such as neighbor cell configurations and handover statistics (e.g., counts, rates) for neighbor cells. The output of the GNN predictor is likelihood of each neighbor cell associated with an edge in the positive graph (operation 10) being a legitimate handover candidate for the UE. These likelihoods are provided to the argmax function, which determines the most likely legitimate handover candidate. In this example, the target cell served by the target RAN node is determined to be the most likely legitimate handover candidate for the UE. Note that the inputs to argmax could be further restricted to those cells whose UE measurements (e.g., RSRP, RSRQ) make them feasible handover candidates.

Operations 12-19 proceed according to conventional handover procedures in a RAN (e.g., E-UTRAN or NG-RAN), with the UE being handed over to the target cell served by the target RAN node.

Figure 11 shows a signaling diagram of a procedure for another localized solution, according to other embodiments of the present disclosure. Operations 1-6 of this procedure are a training phase for the source RAN node using information available to the source RAN node, similar to the training phase described in relation to Figure 10. The result of operation 6 is a first version (vl) of the trained GNN predictor.

Operations 7-12 of this procedure are a second training phase for the source RAN node using additional information available to the source RAN node. The result of operation 12 is a second version (v2) of the trained GNN predictor. For example, vl and v2 can be trained using UE measurements during different periods of operation (e.g., day 1, day 2). In the example shown in Figure 11, one of the UE measurements used to train v2 is “poisonous”, which causes GNN predictor v2 to incorrectly predict the likelihood or feasibility of one or more cell relations. Such “poisonous” measurements could be provided, for example, intentionally by a rogue UE or unintentionally by a legitimate UE based on measurements of invalid cells provided by an illegitimate RAN node.

During the subsequent operational phase, operations 13-16 are similar to operations 7-10 in Figure 10. In operation 17, the positive graph (g) is input to vl and v2 of the GNN predictor together with other available information such as neighbor cell configurations and handover statistics (e.g., counts, rates) for neighbor cells. The output of each version of the GNN predictor is the likelihood of each neighbor cell associated with an edge in the positive graph being a legitimate handover candidate for the UE. As mentioned above, the “poisonous” UE measurements used to train GNN predictor v2 may cause that model to incorrectly predict the likelihood or feasibility of one or more cell relations.

These likelihoods from both versions are provided to the argmax function, which determines the neighbor cell (e.g., represented by an index) most likely to be a legitimate handover candidate. In this example, the target cell served by the target RAN node is determined to be the most likely legitimate handover candidate for the UE. By combining the output of all available models (or versions), the source RAN node can obtain the cell relation with the greatest likelihood. Note that the inputs to argmax could be further restricted to those cells whose UE measurements (e.g., RSRP, RSRQ) make them feasible handover candidates.

Although the procedures shown in Figures 10-11 are based on GNN predictors trained and used locally by RAN nodes, another possibility is for an 0AM function to train and use GNN predictors associated with all cells in a RAN. Figure 12 (which includes Figures 12A-B) shows a procedure according to these embodiments. In particular, the procedure shown in Figure 12 is similar to Figure 11 in that it involves two versions of a GNN predictor: a first version (vl) trained and used by 0AM (1040), and a second version (v2) trained and used by a source RAN node. The second version may be considered a local version for cells served by the source RAN node, while the first version may be considered a global version for all cells in the RAN (including the cells served by the source RAN node).

Operations 1-3 of this procedure are a training phase for the global version (vl) using information available to the 0AM. These operations are similar to operations 4-6 of the training phase described in relation to Figure 10. Operations 4-9 of this procedure are a second training phase for the source RAN node using information available to the source RAN node. These operations are similar to operations 7-12 of the second training phase described in relation to Figure 11. The result of operation 12 is a second version (v2) of the trained GNN predictor.

In the example shown in Figure 12, one of the UE measurements used to train v2 is “poisonous”, which causes GNN predictor v2 to incorrectly predict the likelihood or feasibility of one or more cell relations. Such “poisonous” measurements could be provided, for example, intentionally by an illegitimate UE or unintentionally by a legitimate UE based on measurements of invalid cells provided by an illegitimate RAN node.

Operations 10-14 are similar to operations 7-11 of Figure 10, with the output of operation 14 being a local prediction of the most likely target cell for handover according to v2 of the GNN predictor used locally by the source RAN node. In operation 15, the source RAN node sends a request to OAM for a global prediction of the most likely legitimate target cell for handover according to vl of the GNN predictor used locally by OAM, which is returned to the source RAN node in operation 16. In operation 17, the source RAN node uses argmax to determine the most likely legitimate handover candidate based on both versions of the GNN predictor.

In this example, the target cell served by the target RAN node is determined to be the most likely legitimate handover candidate for the UE. By combining the output of both models (or versions), the source RAN node can obtain the cell relation with the greatest likelihood. Operations 18-25 proceed according to conventional handover procedures in a RAN (e.g., E- UTRAN or NG-RAN), with the UE being handed over to the target cell served by the target RAN node.

In some embodiments, edge explainability techniques can be applied to determine and/or compare the importance of each edge (or cell relation) in different versions of a GNN predictor (e.g., vl and v2 in the above-described embodiments). One benefit of a neural network such as the MLP shown in Figure 8 is that it creates a “black box” of parameters, like fake additional data points, on which the model can base its predictions. In other words, the hidden layers allow a model to make associations among the various data points to predict better results. Explainability for a model such as shown in Figure 8 describes what each node in each NN layer represents and how important it is to the model s predictive performance.

Edge explainability can be implemented via Integrated Gradients technique with attribution based on the weights of each edge. Integrated Gradients is an interpretability or explainability technique that visualizes a NN’s input feature importance based on how the feature contributes to the model's prediction. Integrated Gradient computes the gradient of the model’s prediction output to its input features and requires no modification to the original NN. Integrated Gradients can be applied to any differentiable model including image, text, and/or structured data. More information about Integrated Gradients is available in “Axiomatic Attribution for Deep Networks” by M. Sundararajan, et al., published in Proceedings of the 34th International Conference on Machine Learning, 2017.

Integrated Gradients involves attribution of a model’s features to its predictions, which in this application can be based on weights associated with each edge (cell relation). Each weight indicates the importance of an edge (cell relation) in predictions of the model, which in this case is likelihood of other edges (cell relations). Significant attribution changes between two versions of a model indicate the inclusion of new cells that affect other cells. These newly included cells may be valid (e.g., part of a planned coverage upgrade) or invalid (e.g., provided by a rogue or illegitimate RAN node).

Figure 13 shows an example explainability graph for an exemplary 16-cell RAN, where each node of the graph represents one of the 16 cells. The graph includes a total of 12 lines between nodes, which indicates cell relations that have some importance on the prediction of relations among the 16 cells. The width of each line indicates a degree of importance, with widest lines indicating the highest importance and dashed lines indicating the lowest importance. Note that node 5 can be considered an “orphan cell” since it has no relations with other cells.

Changes in explainability graphs associated with different versions of the same model can indicate the introduction of a new cell that is affecting handovers within the network. For example, if an edge that didn’t appear (i.e., zero weight) in an earlier version appears with a non-zero weight in a later version, this indicates the edge (cell relation) is affecting predictions of other cell relations to some degree. Moreover, if the edge is associated with a node (cell) that was not present in the earlier version, this can indicate a new cell that captures some handovers in the RAN. The introduction of this new cell may be planned or due to an illegitimate RAN node or UE that is attempting to hijack handovers in the RAN.

In other embodiments, cell relation predictions of the GNN model may be used to determine whether to set up a connection (e.g., X2, Xn) to another RAN node. As a variant of the example scenario shown in Figure 10, the source RAN node may determine based on UE measurement reports (operation 9) that it does not have a connection established with another RAN node that serves a neighbor cell included in the UE measurement reports. The source RAN node then proceeds with building the positive graph (g) including the reported neighbor cell (operation 10) and predicting the likelihood (or feasibility) of this neighbor cell as a handover candidate for the UE. If the neighbor cell is determined to be a legitimate candidate, the source RAN node proceeds with connection setup towards the other RAN node that provides the neighbor cell. Otherwise, the source RAN node refrains from setting up a connection with the other RAN node.

Embodiments of the present disclosure can also be implemented in cloud based infrastructure. This can be particularly beneficial for a global model for all cells in a RAN, which can require significant computational resources.

Open RAN (O-RAN) ALLIANCE is a community of mobile operators and RAN vendors working towards an open, intelligent, virtualized, operationally efficient, and fully interoperable RANs. To achieve these goals, the community has defined an O-RAN Architecture with key functions and interfaces. Various specifications published by O-RAN work groups (WGs). For example, O-RAN WG1 is concerned with use cases and overall architecture. One general principle is that O-RAN architecture and interface specifications shall be consistent with 3 GPP architecture and interface specifications, to the extent possible.

Figure 14 shows an exemplary O-RAN architecture in which various embodiments can be implemented. The Al, 01, and 02 interfaces connect the Service Management and Orchestration function (SMO, 1410) to O-RAN network functions (NFs) and cloud infrastructure management (O-Cloud, 1450). These O-RAN NFs include Open Centralized Units (O-CUs, 1420), Open Distributed Units (O-DUs, 1430), and Open Radio Units (O-RUs, 1440). Additionally, there is an interface between SMO and external information sources.

The O-RAN Architecture also includes the following three control loops with respective latencies:

• Real Time (RT) Control Loop (<10 ms), typically in O-RU/O-DU;

• Near-RT RIC Control Loop (10-1000 ms), in O-CU; and

• Non-RT RIC Control Loop (>1000 ms), shown as sub-block 1412 in SMO.

Use cases for Non-RT RIC and Near-RT RIC control loops are fully defined by O-RAN, but O- RAN only defines relevant interactions with other O-RAN nodes or functions for the RT control loop (which performs radio scheduling, HARQ, beamforming, etc.).

The Non-RT RIC provides the Al interface to the Near-RT RIC. One task of Non-RT RIC is to provide policy-based guidance, machine learning (ML) model management, and enrichment information to support intelligent RAN optimization by the Near-RT RIC (e.g., for radio resource management, RRM). The Non-RT RIC can also perform intelligent RRM in longer, non-RT intervals (e.g., greater than 1 second).

The Non-RT RIC can use data analytics and artificial intelligence (AI)/ML training and inference to determine RAN optimizations, for which it can leverage SMO services such as data collection from and provisioning to the O-RAN nodes. These actions are performed by Non-RT RIC RAN Applications (rApps, e.g., 1411), which are exposed to Non-RT RIC functionality and services via the R1 interface in SMO.

In the exemplary architecture shown in Figure 14, the training function and the inference function can be implemented as respective rApps in the SMO. In this manner, these functions can collect data needed for training and inference from the RAN via the Al interface. This could be done for local or global models, as discussed above. Even so, rApps are expected to have one-way communication latency to the O-RAN NFs of >500ms. To reduce this latency, the inference function can be implemented in the O-DU and/or O-CU, with the training function remaining as an rApp in the SMO.

Various features of the embodiments described above correspond to various operations illustrated in Figure 15, which depicts an exemplary method (e.g., procedure) for determining legitimate target cells for UE mobility operations in a RAN, according to various embodiments of the present disclosure. In other words, various features of the operations described below correspond to various embodiments described above. Although Figure 15 shows specific blocks in a particular order, the operations of the exemplary method can be performed in a different order than shown and can be combined and/or divided into blocks having different functionality than shown. Optional blocks or operations are indicated by dashed lines.

The following description is based on the exemplary method being performed by a network node or function (NNF) in the RAN or in another part of a communication network (e.g., 5G network) that includes the RAN. For example, the NNF can be a service management and orchestration (SMO) system for a RAN, an analytics-related core network (CN) node such as NWDAF, an OAM system (or management node therein), or an application running in a host computing system external to the network (e.g., public or private cloud environment).

The exemplary method can include the operations of block 1510, where the NNF can determine a graph representation of a plurality of cells in the RAN based on a plurality of UE measurement reports. The graph representation includes the plurality of cells as graph nodes and relations between respective pairs of the cells as graph edges. The exemplary method can also include the operations of block 1520, where the NNF can train a graph neural network (GNN) model based on the graph representation and cell information for each of the plurality of cells. The exemplary method can also include the operations of block 1540, where the NNF can receive, from a UE, a first measurement report that includes radio-related measurements of the UE’s serving cell and of a plurality of neighbor cells to the UE’s serving cell. The exemplary method can also include the operations of block 1550, where based on the first measurement report and the trained GNN model, the NNF can determine whether one or more of the plurality of neighbor cells is a legitimate candidate for an operation by the UE in the RAN.

In some embodiments, the graph representation (e.g., determined in block 1510) includes one or more of the following: a positive graph representing relations that exist between respective pairs of cells (e.g., Figure 9A), and a negative graph representing relations that do not exist between respective pairs of cells (e.g., Figure 9B). In some embodiments, the GNN model includes a graph convolutional (Gconv) input layer coupled to a multi-layer perceptron (MLP). Figure 8 shows an example of these embodiments.

In some embodiments, for each of the plurality of cells, the cell information used to train the GNN model (e.g., in block 1520) includes configuration parameters and/or mobility statistics. In some of these embodiments, for each of the plurality of cells, the cell information comprises one or more of the following configuration parameters: • frequency band, frequency channel number, and/or frequency bandwidth of the cell;

• maximum and/or average observed distance of UEs served by the cell;

• maximum distance for UE random access to the cell;

• downlink data throughput for the cell;

• tracking area code associated with the cell;

• geographical coordinates of the cell antenna;

• boresight direction and beamwidth of the cell antenna;

• nominal uplink power settings used in the cell for closed loop transmit power control of UE; in the cell;

• maximum downlink transmit power capability for the cell;

• configured maximum downlink transmit power for the cell; and

• number of scheduling request (SR) messages from UEs on the cell’s physical uplink control channel (PUCCH).

In some of these embodiments, for each of the plurality of cells, the cell information comprises one or more of the following mobility statistics:

• RRC connection establishment success rate for UEs in the cell;

• number of successful RRC connection establishments by UEs in the cell;

• number of RRC connection establishments attempted by UEs in the cell; and

• one or more of the following for each of a plurality of neighbor cells of the cell: o success rate for UE handovers to the cell from the neighbor cell; o number of successful UE handovers to the cell from the neighbor cell; o number of attempted UE handovers to the cell from the neighbor cell; o success rate for UE handovers from the cell to the neighbor cell o number of successful UE handovers from the cell to the neighbor cell; and o number of attempted UE handovers from the cell to the neighbor cell.

In some of these embodiments, determining whether one or more of the plurality of neighbor cells is a legitimate candidate for the UE operation in block 1550 includes the following operations, labelled with corresponding sub-block numbers:

• (1551) determining a first graph representation of the serving cell and the plurality of neighbor cells based on the radio-related measurements in the first measurement report;

• (1552) based on applying the trained GNN model using the first graph representation as an input, determining respective likelihoods for the plurality of neighbor cells being legitimate candidates for the UE operation. In some variants of these embodiments, one or more of the following are also used as inputs to the trained GNN model: the configuration parameters for each of the cells, and the mobility statistics for respective pairs of the cells. In some variants of these embodiments, the exemplary method can also include the following operations performed by the NNF, labelled with corresponding block numbers:

• (1560) selecting, as the candidate for the UE operation, the neighbor cell with the highest likelihood from among neighbor cells whose radio-related measurements satisfy one or more criteria for signal strength or quality; and

• (1580) initiating the UE operation towards the selected candidate.

In some further variants of these embodiments, the UE operation in the RAN is one of the following: handover from the serving cell to the candidate as a target cell, addition of the candidate for carrier aggregation, addition of the candidate for dual connectivity, and release of the serving cell with re-direct to the candidate.

In some further variants of these embodiments, selecting the neighbor cell with the highest likelihood in block 1560 includes the operations of sub-block 1561, where the NNF can obtain, from a second NNF, respective second likelihoods for the plurality of neighbor cells being legitimate candidates for the UE operation. In such case, selecting the neighbor cell with the highest likelihood in block 1560 is based on the determined likelihoods and the obtained second likelihoods. Figure 12 operations 16-17 are an example of these variants. As further examples, the second NNF can be any of the following:

• a RAN node that provides at least a portion of the plurality of neighbor cells,

• an analytics node or function coupled to the RAN,

• a service management and orchestration (SMO) function associated with the RAN, or

• an 0AM node or function coupled to the RAN.

In other further variants of these embodiments, the exemplary method can also include the operations of blocks 1525-1530, where the NNF can determine a further graph representation of the plurality of cells in the RAN based on a plurality of further UE measurement reports different from the UE measurement reports used to determine the graph representation, and train a second GNN model based on the further graph representation and the cell information for each of the plurality of cells. Figure 11 operations 10-12 are examples of these variants.

In some of these variants, determining whether one or more of the plurality of neighbor cells is a legitimate mobility candidate for the UE in block 1550 includes the operations of subblock 1553, where based on applying the trained second GNN model using the further graph representation as an input, determining respective second likelihoods for the plurality of neighbor cells being legitimate candidates for the UE operation. In such case, selecting the mobility candidate is based on the determined first likelihoods and the determined second likelihoods. Figure 11 operation 17 is an example of these embodiments.

In some of these variants, the exemplary method can also include the operations of block 1590, where the NNF can determine a first explainability graph for the trained GNN model (e.g., from block 1520) and a second explainability graph for the trained second GNN model (e.g., from block 1530). The exemplary method can also include the operations of block 1595, where the NNF can determine a change in cell composition of the RAN based on one or more of the following differences between the first and second explainability graphs:

• a graph node that appears in only one of the explainability graphs,

• a graph edge that appears in only one of the explainability graphs, and

• a change in weight associated with a graph edge that appears in both explainability graphs.

In some embodiments, the method is performed by a RAN node and a first one of the neighbor cells indicated in the first measurement report is not included in a neighbor relations table (NRT) maintained by the RAN node. In addition, the exemplary method also includes the operations of block 1570, where based on the determination of whether the first neighbor cell is a legitimate candidate for the UE operation (e.g., in block 1550) the RAN node can selectively establish a connection with a second RAN node that serves the first neighbor cell. In some of these embodiments, selectively establishing a connection with a second RAN node that serves the first neighbor cell in block 1570 includes the following operations, labelled with corresponding sub-block numbers:

• (1571) establishing the connection with the second RAN node when the first neighbor cell is determined to be a legitimate candidate for the UE operation; and

• (1572) refraining from establishing the connection with the second RAN node when the first neighbor cell is determined not to be a legitimate candidate for the UE operation.

In various embodiments, the exemplary method can be performed by any of the following:

• a RAN node (e.g., eNB, gNB, etc.);

• an analytics node or function coupled to the RAN (e.g., NWDAF);

• a service management and orchestration (SMO) function associated with the RAN;

• an 0AM node or function coupled to the RAN; and

• a host in a cloud computing environment external to the RAN.

In some embodiments, the RAN is arranged according to an Open RAN (O-RAN) architecture and the exemplary method is performed by one or more of the following in the O- RAN architecture: a non-real-time RAN intelligent controller (RIC); a near-real-time RIC; one or more open distributed units (O-DUs); and one or more open radio units (O-RUs). Although various embodiments are described herein above in terms of methods, apparatus, devices, computer-readable medium and receivers, the person of ordinary skill will readily comprehend that such methods can be embodied by various combinations of hardware and software in various systems, communication devices, computing devices, control devices, apparatuses, non-transitory computer-readable media, etc.

Figure 16 shows an example of a communication system 1600 in accordance with some embodiments. In this example, communication system 1600 includes a telecommunication network 1602 that includes an access network 1604 (e.g., RAN) and a core network 1606, which includes one or more core network nodes 1608. In some embodiments, telecommunication network 1602 can also include one or more Network Management (NM) nodes 1618, which can be part of an operation support system (OSS), a business support system (BSS), and/or an 0AM system. The NM nodes can monitor and/or control operations of other nodes in access network 1604 and core network 1606. Although not shown in Figure 16, NM node 1618 is configured to communicate with other nodes in access network 1604 and core network 1606 for these purposes.

Access network 1604 includes one or more access network nodes, such as network nodes 1610a-b (one or more of which may be generally referred to as network nodes 1610), or any other similar 3GPP access node or non-3GPP access point. Network nodes 1610 facilitate direct or indirect connection of UEs, such as by connecting UEs 1612a-d (one or more of which may be generally referred to as UEs 1612) to core network 1606 over one or more wireless connections.

Example wireless communications over a wireless connection include transmitting and/or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and/or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Moreover, in different embodiments, communication system 1600 may include any number of wired or wireless networks, network nodes, UEs, and/or any other components or systems that may facilitate or participate in the communication of data and/or signals whether via wired or wireless connections. Communication system 1600 may include and/or interface with any type of communication, telecommunication, data, cellular, radio network, and/or other similar type of system.

UEs 1612 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and/or operable to communicate wirelessly with network nodes 1610 and other communication devices. Similarly, network nodes 1610 are arranged, capable, configured, and/or operable to communicate directly or indirectly with UEs 1612 and/or with other network nodes or equipment in telecommunication network 1602 to enable and/or provide network access, such as wireless network access, and/or to perform other functions, such as administration in telecommunication network 1602. In the depicted example, core network 1606 connects network nodes 1610 to one or more hosts, such as host 1616. These connections may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directly coupled to hosts. Core network 1606 includes one more core network nodes (e.g., core network node 1608) that are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the UEs, network nodes, and/or hosts, such that the descriptions thereof are generally applicable to the corresponding components of the core network node 1608. Example core network nodes include functions of one or more of a Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier De-concealing function (SIDF), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and/or a User Plane Function (UPF).

Host 1616 may be under the ownership or control of a service provider other than an operator or provider of the access network 1604 and/or telecommunication network 1602, and may be operated by the service provider or on behalf of the service provider. Host 1616 may host a variety of applications to provide one or more service. Examples of such applications include live and pre-recorded audio/video content, data collection services such as retrieving and compiling data on various ambient conditions detected by a plurality of UEs, analytics functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server.

In some embodiments, access network 1604 can include a service management and orchestration (SMO) system or node 1620, which can monitor and/or control operations of the access network nodes 1610. This arrangement can be used, for example, when access network 1604 utilizes an Open RAN (O-RAN) architecture. SMO system 1620 can be configured to communicate with core network 1606 and/or host 1616, as shown in Figure 16.

In some embodiments, one or more of network node 1610, core network node 1608, host 1616, network management node 1618, and SMO system 1620 can be configured to perform various operations of exemplary methods (e.g., procedures) for determining legitimate target cells for UE mobility operations in a RAN, such as described above in relation to Figure 15.

As a whole, communication system 1600 of Figure 16 enables connectivity between the UEs, network nodes, and hosts. In that sense, the communication system may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE), and/or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g., 6G); wireless local area network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (WiFi); and/or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and/or any low-power wide-area network (LPWAN) standards such as LoRa and Sigfox.

In some examples, telecommunication network 1602 is a cellular network that implements 3GPP standardized features. Accordingly, telecommunication network 1602 may support network slicing to provide different logical networks to different devices that are connected to telecommunication network 1602. For example, telecommunication network 1602 may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and/or Massive Machine Type Communication (mMTC)/Massive loT services to yet further UEs.

In some examples, UEs 1612 are configured to transmit and/or receive information without direct human interaction. For instance, a UE may be designed to transmit information to the access network 1604 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network 1604. Additionally, a UE may be configured for operating in single- or multi -RAT or multi-standard mode. For example, a UE may operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, i.e., being configured for multi-radio dual connectivity (MR-DC), such as E-UTRAN (Evolved-UMTS Terrestrial Radio Access Network) New Radio - Dual Connectivity (EN-DC).

In the example, hub 1614 communicates with the access network 1604 to facilitate indirect communication between one or more UEs (e.g., UE 1612c and/or 1612d) and network nodes (e.g., network node 1610b). In some examples, hub 1614 may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, hub 1614 may be a broadband router enabling access to core network 1606 for the UEs. As another example, hub 1614 may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be received from the UEs, network nodes 1610, or by executable code, script, process, or other instructions in hub 1614. As another example, hub 1614 may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, hub 1614 may be a content source. For example, for a UE that is a VR headset, display, loudspeaker or other media delivery device, hub 1614 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which hub 1614 then provides to the UE either directly, after performing local processing, and/or after adding additional local content. In still another example, hub 1614 acts as a proxy server or orchestrator for the UEs, in particular in if one or more of the UEs are low energy loT devices.

Figure 17 shows a network node 1700 in accordance with some embodiments. Examples of network nodes include, but are not limited to, access points (e.g., radio access points) and base stations (e.g., radio base stations, Node Bs, eNBs, and gNBs).

Base stations may be categorized based on the amount of coverage they provide (or, stated differently, their transmit power level) and so, depending on the provided amount of coverage, may be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. A base station may be a relay node or a relay donor node controlling a relay. A network node may also include one or more (or all) parts of a distributed radio base station such as centralized digital units and/or remote radio units (RRUs), sometimes referred to as Remote Radio Heads (RRHs). Such remote radio units may or may not be integrated with an antenna as an antenna integrated radio. Parts of a distributed radio base station may also be referred to as nodes in a distributed antenna system (DAS).

Other examples of network nodes include multiple transmission point (multi-TRP) 5G access nodes, multi-standard radio (MSR) equipment such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base transceiver stations (BTSs), transmission points, transmission nodes, multi-cell/multicast coordination entities (MCEs), Operation and Maintenance (O&M) nodes, Operations Support System (OSS) nodes, Self-Organizing Network (SON) nodes, positioning nodes (e.g., Evolved Serving Mobile Location Centers (E-SMLCs)), and/or Minimization of Drive Tests (MDTs).

In some embodiments, network node 1700 can be configured to perform various operations of exemplary methods (e.g., procedures) for determining legitimate target cells for UE mobility operations in a RAN, such as described above in relation to Figure 15.

Network node 1700 includes a processing circuitry 1702, a memory 1704, a communication interface 1706, and a power source 1708. Network node 1700 may be composed of multiple physically separate components (e.g., a NodeB component and a RNC component, or a BTS component and a BSC component, etc.), which may each have their own respective components. In certain scenarios in which network node 1700 comprises multiple separate components (e.g., BTS and BSC components), one or more of the separate components may be shared among several network nodes. For example, a single RNC may control multiple NodeBs. In such a scenario, each unique NodeB and RNC pair, may in some instances be considered a single separate network node. In some embodiments, network node 1700 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate memory 1704 for different RATs) and some components may be reused (e.g., a same antenna 1710 may be shared by different RATs). Network node 1700 may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node 1700, for example GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z- wave, LoRaWAN, Radio Frequency Identification (RFID) or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chip or set of chips and other components within network node 1700.

Processing circuitry 1702 may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and/or encoded logic operable to provide, either alone or in conjunction with other network node 1700 components, such as memory 1704, to provide network node 1700 functionality.

In some embodiments, processing circuitry 1702 includes a system on a chip (SOC). In some embodiments, processing circuitry 1702 includes one or more of radio frequency (RF) transceiver circuitry 1712 and baseband processing circuitry 1714. In some embodiments, the radio frequency (RF) transceiver circuitry 1712 and baseband processing circuitry 1714 may be on separate chips (or sets of chips), boards, or units, such as radio units and digital units. In alternative embodiments, part or all of RF transceiver circuitry 1712 and baseband processing circuitry 1714 may be on the same chip or set of chips, boards, or units.

Memory 1704 may comprise any form of volatile or non-volatile computer-readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (for example, a hard disk), removable storage media (for example, a flash drive, a Compact Disk (CD) or a Digital Video Disk (DVD)), and/or any other volatile or non-volatile, non-transitory device-readable and/or computer-executable memory devices that store information, data, and/or instructions that may be used by processing circuitry 1702. Memory 1704 may store any suitable instructions, data, or information, including a computer program, software, an application including one or more of logic, rules, code, tables, and/or other instructions (collectively denoted computer program product 1704a) capable of being executed by processing circuitry 1702 and utilized by network node 1700. Memory 1704 may be used to store any calculations made by processing circuitry 1702 and/or any data received via communication interface 1706. In some embodiments, processing circuitry 1702 and memory 1704 is integrated.

Communication interface 1706 is used in wired or wireless communication of signaling and/or data between a network node, access network, and/or UE. As illustrated, communication interface 1706 comprises port(s)/terminal(s) 1716 to send and receive data, for example to and from a network over a wired connection. Communication interface 1706 also includes radio frontend circuitry 1718 that may be coupled to, or in certain embodiments a part of, antenna 1710. Radio front-end circuitry 1718 comprises filters 1720 and amplifiers 1722. Radio front-end circuitry 1718 may be connected to an antenna 1710 and processing circuitry 1702. The radio front-end circuitry may be configured to condition signals communicated between antenna 1710 and processing circuitry 1702. Radio front-end circuitry 1718 may receive digital data that is to be sent out to other network nodes or UEs via a wireless connection. Radio front-end circuitry 1718 may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters 1720 and/or amplifiers 1722. The radio signal may then be transmitted via antenna 1710. Similarly, when receiving data, antenna 1710 may collect radio signals which are then converted into digital data by radio front-end circuitry 1718. The digital data may be passed to processing circuitry 1702. In other embodiments, the communication interface may comprise different components and/or different combinations of components.

In certain alternative embodiments, network node 1700 does not include separate radio front-end circuitry 1718, instead, processing circuitry 1702 includes radio front-end circuitry and is connected to antenna 1710. Similarly, in some embodiments, all or some of RF transceiver circuitry 1712 is part of communication interface 1706. In still other embodiments, communication interface 1706 includes one or more ports or terminals 1716, radio front-end circuitry 1718, and RF transceiver circuitry 1712, as part of a radio unit (not shown), and communication interface 1706 communicates with baseband processing circuitry 1714, which is part of a digital unit (not shown).

Antenna 1710 may include one or more antennas, or antenna arrays, configured to send and/or receive wireless signals. Antenna 1710 may be coupled to radio front-end circuitry 1718 and may be any type of antenna capable of transmitting and receiving data and/or signals wirelessly. In certain embodiments, antenna 1710 is separate from network node 1700 and connectable to network node 1700 through an interface or port.

Antenna 1710, communication interface 1706, and/or processing circuitry 1702 may be configured to perform any receiving operations and/or certain obtaining operations described herein as being performed by the network node. Any information, data and/or signals may be received from a UE, another network node and/or any other network equipment. Similarly, antenna 1710, communication interface 1706, and/or processing circuitry 1702 may be configured to perform any transmitting operations described herein as being performed by the network node. Any information, data and/or signals may be transmitted to a UE, another network node and/or any other network equipment. Power source 1708 provides power to the various components of network node 1700 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). Power source 1708 may further comprise, or be coupled to, power management circuitry to supply the components of network node 1700 with power for performing the functionality described herein. For example, network node 1700 may be connectable to an external power source (e.g., the power grid, an electricity outlet) via an input circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry of power source 1708. As a further example, power source 1708 may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry. The battery may provide backup power should the external power source fail.

Embodiments of network node 1700 may include additional components beyond those shown in Figure 17 for providing certain aspects of the network node’s functionality, including any of the functionality described herein and/or any functionality necessary to support the subject matter described herein. For example, network node 1700 may include user interface equipment to allow input of information into network node 1700 and to allow output of information from network node 1700. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for network node 1700.

Figure 18 is a block diagram of a host 1800, which may be an embodiment of host 1516 of Figure 15, in accordance with various aspects described herein. As used herein, host 1800 may be or comprise various combinations hardware and/or software, including a standalone server, a blade server, a cloud-implemented server, a distributed server, a virtual machine, container, or processing resources in a server farm. Host 1800 may provide one or more services to one or more UEs.

Host 1800 includes processing circuitry 1802 that is operatively coupled via a bus 1804 to an input/output interface 1806, a network interface 1808, a power source 1810, and a memory 1812. Other components may be included in other embodiments. Features of these components may be substantially similar to those described with respect to the devices of previous figures, such as Figure 11, such that the descriptions thereof are generally applicable to the corresponding components of host 1800.

Memory 1812 may include one or more computer programs including one or more host application programs 1814 and data 1816, which may include user data, e.g., data generated by a UE for host 1800 or data generated by host 1800 for a UE. Embodiments of host 1800 may utilize only a subset or all of the components shown. Host application programs 1814 may be implemented in a container-based architecture and may provide support for video codecs (e.g., Versatile Video Coding (VVC), High Efficiency Video Coding (HEVC), Advanced Video Coding (AVC), MPEG, VP9) and audio codecs (e.g., FLAC, Advanced Audio Coding (AAC), MPEG, G.711), including transcoding for multiple different classes, types, or implementations of UEs (e.g., handsets, desktop computers, wearable display systems, heads-up display systems). Host application programs 1814 may also provide for user authentication and licensing checks and may periodically report health, routes, and content availability to a central node, such as a device in or on the edge of a core network. Accordingly, host 1800 may select and/or indicate a different host for over-the-top services for a UE. Host application programs 1814 may support various protocols, such as the HTTP Live Streaming (HLS) protocol, Real-Time Messaging Protocol (RTMP), Real- Time Streaming Protocol (RTSP), Dynamic Adaptive Streaming over HTTP (MPEG-DASH), etc.

In some embodiments, host 1800 can be configured to perform various operations of exemplary methods (e.g., procedures) for determining legitimate target cells for UE mobility operations in a RAN, such as described above in relation to Figure 15.

Figure 19 is a block diagram illustrating a virtualization environment 1900 in which functions implemented by some embodiments may be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any device described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 1900 hosted by one or more of hardware nodes, such as a hardware computing device that operates as a network node, UE, core network node, or host. Further, in embodiments in which the virtual node does not require radio connectivity (e.g., a core network node or host), then the node may be entirely virtualized.

Applications 1902 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) are run in the virtualization environment 1900 to implement some of the features, functions, and/or benefits of some of the embodiments disclosed herein. In some embodiments, one or more applications 1902 can be configured to perform various operations of exemplary methods (e.g, procedures) for determining legitimate target cells for UE mobility operations in a RAN, such as described above in relation to Figure 15.

Hardware 1904 includes processing circuitry, memory that stores software and/or instructions (collectively denoted computer program product 1904a) executable by hardware processing circuitry, and/or other hardware devices as described herein, such as a network interface, input/output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers 1906 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 1908a-b (one or more of which may be generally referred to as VMs 1908), and/or perform any of the functions, features and/or benefits described in relation with some embodiments described herein. The virtualization layer 1906 may present a virtual operating platform that appears like networking hardware to the VMs 1908.

VMs 1908 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 1906. Different embodiments of the instance of a virtual appliance 1902 may be implemented on one or more of VMs 1908, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment.

In the context of NFV, VM 1908 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each VM 1908, and that part of hardware 1904 that executes that VM, be it hardware dedicated to that VM and/or hardware shared by that VM with others of the VMs, forms separate virtual network elements. Still in the context of NFV, a virtual network function is responsible for handling specific network functions that run in one or more VMs 1908 on top of hardware 1904 and corresponds to application 1902.

Hardware 1904 may be implemented in a standalone network node with generic or specific components. Hardware 1904 may implement some functions via virtualization. Alternatively, hardware 1904 may be part of a larger cluster of hardware (e.g., such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration 1910, which, among others, oversees lifecycle management of applications 1902. In some embodiments, hardware 1904 is coupled to one or more radio units that each include one or more transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In some embodiments, some signaling can be provided with the use of a control system 1912 which may alternatively be used for communication between hardware nodes and radio units.

The foregoing merely illustrates the principles of the disclosure. Various modifications and alterations to the described embodiments will be apparent to those skilled in the art in view of the teachings herein. It will thus be appreciated that those skilled in the art will be able to devise numerous systems, arrangements, and procedures that, although not explicitly shown or described herein, embody the principles of the disclosure and can be thus within the spirit and scope of the disclosure. Various embodiments can be used together with one another, as well as interchangeably therewith, as should be understood by those having ordinary skill in the art.

The term unit, as used herein, can have conventional meaning in the field of electronics, electrical devices and/or electronic devices and can include, for example, electrical and/or electronic circuitry, devices, modules, processors, memories, logic solid state and/or discrete devices, computer programs or instructions for carrying out respective tasks, procedures, computations, outputs, and/or displaying functions, and so on, as such as those that are described herein.

Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include Digital Signal Processor (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as Read Only Memory (ROM), Random Access Memory (RAM), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according to one or more embodiments of the present disclosure.

As described herein, device and/or apparatus can be represented by a semiconductor chip, a chipset, or a (hardware) module comprising such chip or chipset; this, however, does not exclude the possibility that a functionality of a device or apparatus, instead of being hardware implemented, be implemented as a software module such as a computer program or a computer program product comprising executable software code portions for execution or being run on a processor. Furthermore, functionality of a device or apparatus can be implemented by any combination of hardware and software. A device or apparatus can also be regarded as an assembly of multiple devices and/or apparatuses, whether functionally in cooperation with or independently of each other. Moreover, devices and apparatuses can be implemented in a distributed fashion throughout a system, so long as the functionality of the device or apparatus is preserved. Such and similar principles are considered as known to a skilled person. Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. It will be further understood that terms used herein should be interpreted as having a meaning that is consistent with their meaning in the context of this specification and the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

In addition, certain terms used in the present disclosure, including the specification and drawings, can be used synonymously in certain instances (e.g., “data” and “information”). It should be understood, that although these terms (and/or other terms that can be synonymous to one another) can be used synonymously herein, there can be instances when such words can be intended to not be used synonymously.

Claims

1. A computer-implemented method for determining legitimate candidate cells for user equipment, UE, operations in a radio access network, RAN, the method comprising: determining (1510) a graph representation of a plurality of cells in the RAN based on a plurality of UE measurement reports, wherein the graph representation includes the plurality of cells as graph nodes and relations between respective pairs of the cells as graph edges; training (1520) a graph neural network (GNN) model based on the graph representation and cell information for each of the plurality of cells; receiving (1540), from a UE, a first measurement report that includes radio-related measurements of the UE’s serving cell and of a plurality of neighbor cells to the UE’s serving cell; and based on the first measurement report and the trained GNN model, determining (1550) whether one or more of the plurality of neighbor cells is a legitimate candidate for an operation by the UE in the RAN.

2. The method of claim 1, wherein the graph representation includes one or more of the following: a positive graph representing relations that exist between respective pairs of cells, and a negative graph representing relations that do not exist between respective pairs of cells.

3. The method of any of claims 1-2, wherein the GNN model includes a graph convolutional, Gconv, input layer coupled to a multi-layer neural network configured to perform regression or classification.

4. The method of any of claims 1-3, wherein for each of the plurality of cells, the cell information used to train the GNN model includes one or more of the following: configuration parameters, and mobility statistics.

5. The method of claim 4, wherein for each of the plurality of cells, the cell information comprises one or more of the following configuration parameters: frequency band, frequency channel number, and/or frequency bandwidth of the cell; maximum and/or average observed distance of UEs served by the cell; maximum distance for UE random access to the cell; downlink data throughput for the cell; tracking area code associated with the cell; geographical coordinates of the cell antenna; boresight direction and beamwidth of the cell antenna; nominal uplink power settings used in the cell for closed loop transmit power control of UE; in the cell; maximum downlink transmit power capability for the cell; configured maximum downlink transmit power for the cell; and number of scheduling request, SR, messages from UEs on the cell’s physical uplink control channel, PUCCH.

6. The method of any of claims 4-5, wherein for each of the plurality of cells, the cell information comprises one or more of the following mobility statistics: radio resource control, RRC, connection establishment success rate for UEs in the cell ; number of successful RRC connection establishments by UEs in the cell; number of RRC connection establishments attempted by UEs in the cell; and one or more of the following for each of a plurality of neighbor cells of the cell: success rate for UE handovers to the cell from the neighbor cell; number of successful UE handovers to the cell from the neighbor cell; number of attempted UE handovers to the cell from the neighbor cell; success rate for UE handovers from the cell to the neighbor cell number of successful UE handovers from the cell to the neighbor cell; and number of attempted UE handovers from the cell to the neighbor cell.

7. The method of any of claims 3-6, wherein determining whether one or more of the plurality of neighbor cells is a legitimate candidate for the UE operation comprises: determining a first graph representation of the serving cell and the plurality of neighbor cells based on the radio-related measurements in the first measurement report; and based on applying the trained GNN model using the first graph representation as an input, determining respective likelihoods for the plurality of neighbor cells being legitimate candidates for the UE operation.

8. The method of claim 7, wherein one or more of the following are also used as inputs to the trained GNN model: the configuration parameters for each of the cells, and the mobility statistics for respective pairs of the cells.

9. The method of any of claims 7-8, further comprising: selecting (1560), as the candidate for the UE operation, the neighbor cell with the highest likelihood from among neighbor cells whose radio-related measurements satisfy one or more criteria for signal strength or quality; and initiating (1580) the UE operation towards the selected candidate.

10. The method of claim 9, wherein the UE operation in the RAN is one of the following: handover from the serving cell to the candidate as a target cell, addition of the candidate for carrier aggregation, addition of the candidate for dual connectivity, and release of the serving cell with re-direct to the candidate.

11. The method of any of claims 9-10, wherein: selecting (1560) the neighbor cell with the highest likelihood comprises obtaining (1561), from a second network node function, NNF, respective second likelihoods for the plurality of neighbor cells being legitimate candidates for the UE operation; and selecting (1560) the neighbor cell with the highest likelihood is based on the determined likelihoods and the obtained second likelihoods.

12. The method of claim 11, wherein the second NNF is one of the following: a RAN node that provides at least a portion of the plurality of neighbor cells, an analytics node or function coupled to the RAN, a service management and orchestration, SMO, function associated with the RAN, or an operations, administration, and maintenance, 0AM, node or function coupled to the RAN.

13. The method of any of claims 9-10, further comprising: determining (1525) a further graph representation of the plurality of cells in the RAN based on a plurality of further UE measurement reports different from the UE measurement reports used to determine the graph representation; and training (1530) a second GNN model based on the further graph representation and the cell information for each of the plurality of cells.

14. The method of claim 13, wherein determining (1550) whether one or more of the plurality of neighbor cells is a legitimate mobility candidate for the UE further comprises, based on applying the trained second GNN model using the further graph representation as an input, determining (1552) respective second likelihoods for the plurality of neighbor cells being legitimate candidates for the UE operation.

15. The method of claim 14, wherein selecting (1560) the neighbor cell with the highest likelihood is based on the determined first likelihoods and the determined second likelihoods.

16. The method of any of claims 13-15, further comprising: determining (1590) a first explainability graph for the trained GNN model and a second explainability graph for the trained second GNN model; and determining (1595) a change in cell composition of the RAN based on one or more of the following differences between the first and second explainability graphs: a graph node that appears in only one of the explainability graphs, a graph edge that appears in only one of the explainability graphs, and a change in weight associated with a graph edge that appears in both explainability graphs.

17. The method of any of claims 1-8, wherein: the method is performed by a RAN node; a first one of the neighbor cells indicated in the first measurement report is not included in a neighbor relations table (NRT) maintained by the RAN node; and the method further comprises, based on the determination of whether the first neighbor cell is a legitimate candidate for the UE operation, selectively establishing (1570) a connection with a second RAN node that serves the first neighbor cell.

18. The method of claim 17, wherein selectively establishing (1570) a connection with a second RAN node that serves the first neighbor cell comprises: establishing (1571) the connection with the second RAN node when the first neighbor cell is determined to be a legitimate candidate for the UE operation; and refraining from establishing (1572) the connection with the second RAN node when the first neighbor cell is determined not to be a legitimate candidate for the UE operation.

19. The method of any of claims 1-18, wherein the method is performed by one of the following: a RAN node; an analytics node or function coupled to the RAN, a service management and orchestration, SMO, function associated with the RAN; an operations, administration, and maintenance, OAM, node or function coupled to the RAN; and a host in a cloud computing environment external to the RAN.

20. The method of claim 1-18, wherein the RAN is arranged according to an Open RAN, O- RAN, architecture and the method is performed by one or more of the following in the 0-RAN architecture: a non-real-time RAN intelligent controller, RIC; a near-real-time RIC; one or more open distributed units, O-DUs; and one or more open radio units, O-RUs.

21. A network node or function, NNF (1010, 1608, 1610, 1616, 1618, 1620, 1700, 1800, 1902) configured to determine legitimate candidate cells for user equipment, UE, operations in a radio access network, RAN (199, 299, 1604), the NNF comprising: communication interface circuitry (1701, 1808, 1904) configured to communicate with UEs (920, 1512) and with other NNFs (1030, 1040, 1608, 1618, 1620) in or associated with the RAN; and processing circuitry (1702, 1802, 1904) operably coupled to the communication interface circuitry, whereby the processing circuitry and the communication interface circuitry are configured to: determine a graph representation of a plurality of cells in the RAN based on a plurality of UE measurement reports, wherein the graph representation includes the plurality of cells as graph nodes and relations between respective pairs of the cells as graph edges; train a graph neural network, GNN, model based on the graph representation and cell information for each of the plurality of cells; receive, from a UE, a first measurement report that includes radio-related measurements of the UE’s serving cell and of a plurality of neighbor cells to the UE’s serving cell; and based on the first measurement report and the trained GNN model, determine whether one or more of the plurality of neighbor cells is a legitimate candidate for an operation by the UE in the RAN.

22. The NNF of claim 21, wherein the processing circuitry and the communication interface circuitry are further configured to perform operations corresponding to any of the methods of claims 2-20.

23. A network node or function, NNF (1010, 1608, 1610, 1616, 1618, 1620, 1700, 1800, 1902) configured to determine legitimate candidate cells for user equipment, UE, operations in a radio access network, RAN (199, 299, 1604), the NNF being further configured to: determine a graph representation of a plurality of cells in the RAN based on a plurality of UE measurement reports, wherein the graph representation includes the plurality of cells as graph nodes and relations between respective pairs of the cells as graph edges; train a graph neural network, GNN, model based on the graph representation and cell information for each of the plurality of cells; receive, from a UE (920, 1512), a first measurement report that includes radio-related measurements of the UE’s serving cell and of a plurality of neighbor cells to the UE’s serving cell; and based on the first measurement report and the trained GNN model, determine whether one or more of the plurality of neighbor cells is a legitimate candidate for an operation by the UE in the RAN.

24. The NNF of claim 23, being further configured to perform operations corresponding to any of the methods of claims 2-20.

25. A network analytics system (800) configured to determine legitimate candidate cells for user equipment, UE, operations in a radio access network, RAN (199, 299, 1604), the network analytics system comprising: a training function (820) configured to: determine a graph representation of a plurality of cells in the RAN based on UE radio-related measurements of the plurality of cells, wherein the graph representation includes the plurality of cells as graph nodes and relations between respective pairs of the cells as graph edges; and train a graph neural network (GNN) model based on the graph representation and one or more of the following: the configuration parameters for each of the cells, and mobility statistics for respective pairs of the cells; a measurement collection function (810) configured to: obtain the UE radio-related measurements used to determine the graph representation, and subsequently receive, from a UE, a first measurement report that includes radiorelated measurements of the UE’s serving cell and of a plurality of neighbor cells to the UE’s serving cell; and an inference function (830) configured to determine, based on the first measurement report and the trained GNN model, whether one or more of the plurality of neighbor cells is a legitimate candidate for an operation by the UE in the RAN.

26. The network analytics system of claim 25, further comprising a cell configuration database (750) arranged to store one or more configuration parameters for each of the plurality of cells, wherein the cell information used to train the GNN model includes the configuration parameters stored in the cell configuration database.

27. The network analytics system of any of claims 25-26, further comprising a cell management function (740) configured to initiate the UE operation towards a neighbor cell determined to be a legitimate candidate.

28. The network analytics system of any of claims 25-27, being further configured to perform operations corresponding to any of the methods of claims 2-20.

29. A non-transitory, computer-readable medium (1704, 1812, 1904) storing computerexecutable instructions that, when executed by processing circuitry (1702, 1802, 1904), configure a network node or function, NNF (1010, 1608, 1610, 1616, 1618, 1620, 1700, 1800, 1902) arranged to determine legitimate candidate cells for user equipment, UE, operations in a radio access network, RAN (199, 299, 1604) to perform operations corresponding to any of the methods of claims 1-20.

30. A computer program product (1704a, 1814, 1904a) comprising computer-executable instructions that, when executed by processing circuitry (1702, 1802, 1904), configure a network node or function, NNF (1010, 1608, 1610, 1616, 1618, 1620, 1700, 1800, 1902) arranged to determine legitimate candidate cells for user equipment, UE, operations in a radio access network, RAN (199, 299, 1604) to perform operations corresponding to any of the methods of claims 1-20.