Coordination of self-organizing network functions in heterogenous communication systems

Abstract

A method for coordinating self-optimization network (SON) functions in a heterogenous communication system includes transmitting, from a first network node to a second network node, a first message that includes one of a request or indication to coordinate handling of one or more SON functions. The method further includes receiving, at the first network node and from the second network node, a second message that indicates whether the second network node agrees to the request to coordinate handling of the one or more SON functions. The first network node may be at least one of: compliant with a different communication standard than the second network node, or of a different node type than the second network node.

Description

COORDINATION OF SELF-ORGANIZING NETWORK FUNCTIONS IN HETEROGENOUS COMMUNICATION SYSTEMSRELATED APPLICATION

[0001] The present application priority to U.S. Provisional Patent Application No. 63 / 686,536, filed August 23, 2024, entitled “COORDINATION OF SELF-ORGANIZING NETWORK FUNCTIONS IN HTEROGENOUS COMMUNICATION SYSTEMS,” the disclosure of which is hereby incorporated herein by reference in its entirety.TECHNICAL FIELD

[0002] The present disclosure is related to wireless communication systems and, more specifically, to coordination of self-organizing network functions in heterogenous communication systems.BACKGROUND

[0003] Self-organizing network (SON) is an automation technology that enables the network to perform self-management functions, such as setting itself up, managing network resources, managing network configurations, and / or the like, in order to achieve optimal network performance (e.g., better capacity, speeds, reliability, etc.). SON functionalities include, for example, self-configuration, self-optimization, and self-healing.

[0004] In particular, network self-optimization aids in enhanced network performance through near real time optimization of radio and network configurations. It is valuable throughout the lifetime of the network and includes SON functionalities such as Mobility Load Balancing (MLB), Mobility Robustness Optimization (MRO), Coverage and Capacity Optimization (CCO), Random Access Channel (RACH) optimization (RO), Network Slice Resource Allocation Optimization, Network Energy Saving Optimization, Massive MIMO Beam-based MRO, QoE optimization, and the like.

[0005] While the 3rdGeneration Partnership Project (3GPP) specifies definitions for the SON functionality, the specifications leave realization of the SON functionality up to implementation. As a result, the implementation of SON functions can vary within different parts of a communication system and / or between different communication systems.SUMMARY

[0006] Some embodiments provide a method for coordinating self-optimization network (SON) functions in a heterogenous communication system that includes a first network node that is compliant with a first communication standard and a second network node that is compliant with a second communication standard. The method includes transmitting, from the first network node to the second network node, a first message that includes one of a request or indication to coordinate handling of one or more SON functions. The method further includes receiving, at the first network node and from the second network node, a second message that indicates whether the second network node agrees to the request to coordinate handling of the one or more SON functions.

[0007] Some embodiments provide another method for coordinating self-optimization network (SON) functions in a heterogenous communication system that includes a first network node that is compliant with a first communication standard and a second network node that is compliant with a second communication standard. The method includes receiving, at the first network node and from the second network node, a first message that includes one of a request or indication to coordinate handling of one or more SON functions. The method further includes transmitting, from the first network node to the second network node, a second message that indicates whether the second network node agrees to the request to coordinate handling of the one or more SON functions.

[0008] Some embodiments provide a network node for coordinating SON functions in a heterogenous communication system. The network node comprises processing circuitry configured to cause the network node to transmit, to a second network node, a first message that includes one of a request or indication to coordinate handling of one or more SON functions. The processing circuitry is further configured to cause the network node to receive, from the second network node, a second message that indicates whether the second network node agrees to the request to coordinate handling of the one or more SON functions.

[0009] Some embodiments provide another network node for coordinating SON functions in a heterogenous communication system. The network node comprises processing circuitry configured to cause the network node to receive, from a second network node, a first message that includes one of a request or indication to coordinate handling of one or more SON functions. The processing circuitry is further configured to cause the network node to transmit, to the second network node, a second message that indicates whether the network node agrees to the request to coordinate handling of the one or more SON functions.BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The accompanying drawings, which are included to provide a further understanding of the disclosure and are incorporated in and constitute a part of this application, illustrate certain non-limiting embodiments of inventive concepts. In the drawings:

[0011] Figure 1 illustrates an example 5G radio access network (NG-RAN) architecture, according to various embodiments.

[0012] Figure 2 illustrates a block diagram of an example overall architecture for separation of a gNB-CU-Control Plane (gNB-CU-CP) and gNB-CU-User Plane (gNB-CU- UP) in a gNB, according to various embodiments.

[0013] Figure 3 illustrates an example open radio access network (0-RAN) architecture, according to various embodiments.

[0014] Figure 4 is a block diagram illustrating example control loops involving various 0-RAN functionalities, according to various embodiments.

[0015] Figure 5A illustrates a flow chart of example steps for performing selfoptimization in Non-RT RIC, according to some embodiments.

[0016] Figure 5B illustrates a flow chart of example steps for performing selfoptimization in Near-RT RIC, according to some embodiments.

[0017] Figure 5C illustrates a flow chart of example steps for performing selfoptimization in E2 Nodes, according to some embodiments.

[0018] Figure 6 illustrates an example overview of steps for coordinating SON functionality in a heterogenous communication system, according to various embodiments.

[0019] Figure 7A illustrates an example flow diagram for a SON coordination procedure initiated by an O-RAN network node, according to some embodiments.

[0020] Figure 7B illustrates an example flow diagram for a SON coordination procedure initiated by an O-RAN network node, according to some other embodiments.

[0021] Figure 7C illustrates an example flow diagram for a SON coordination procedure initiated by an O-RAN network node, according to some other embodiments.

[0022] Figure 7D illustrates an example flow diagram for a SON coordination procedure initiated by an O-RAN network node, according to some other embodiments.

[0023] Figure 8A illustrates an example flow diagram for a SON coordination procedure initiated by a 3 GPP network node, according to some embodiments.

[0024] Figure 8B illustrates an example flow diagram for a SON coordination procedure initiated by a 3 GPP network node, according to some other embodiments.

[0025] Figure 8C illustrates an example flow diagram for a SON coordination procedure initiated by a 3 GPP network node, according to some other embodiments.

[0026] Figure 8D illustrates an example flow diagram for a SON coordination procedure initiated by a 3 GPP network node, according to some other embodiments.

[0027] Figure 8E illustrates an example flow diagram for a SON coordination procedure initiated by a 3 GPP network node, according to some other embodiments.

[0028] Figure 8F illustrates an example flow diagram for a SON coordination procedure initiated by a 3 GPP network node, according to some other embodiments.

[0029] Figure 8G illustrates an example flow diagram for a SON coordination procedure initiated by a 3 GPP network node, according to some other embodiments.

[0030] Figure 8H illustrates an example flow diagram for a SON coordination procedure initiated by a 3 GPP network node, according to some other embodiments.

[0031] Figure 81 illustrates an example flow diagram for a SON coordination procedure initiated by a 3 GPP network node, according to some other embodiments.

[0032] Figure 8J illustrates an example flow diagram for a SON coordination procedure initiated by a 3 GPP network node, according to some other embodiments.

[0033] Figure 9 illustrates an example method performed by a network node for coordinating SON functions in a heterogenous network, according to various embodiments.

[0034] Figure 10 illustrates an example method 1000 performed by a network node for coordinating SON functions in a heterogenous network, according to various embodiments.

[0035] Figure 11 illustrates a block diagram of an example communication system in accordance with some embodiments.

[0036] Figure 12 illustrates a block diagram of an example user equipment in accordance with some embodiments.

[0037] Figure 13 illustrates a block diagram of an example network node in accordance with some embodiments.

[0038] Figure 14 illustrates a block diagram of an example virtualization environment in which functions implemented by some embodiments may be virtualized.DETAILED DESCRIPTION

[0001] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. In the following description, numerousspecific details are set forth to provide a more thorough understanding of the various embodiments. However, it will be apparent to one skilled in the art that the inventive concepts may be embodied in many different forms and may be practiced without one or more of these specific details. Rather, the embodiments described herein are provided so that this disclosure will be thorough and complete, and will fully convey the scope of present inventive concepts to those skilled in the art. It should also be noted that these embodiments are not mutually exclusive. Components from one embodiment may be tacitly assumed to be present / used in another embodiment.Radio Access Network (RAN) Logical Architecture

[0002] Figure 1 illustrates an example 5G radio access network (NG-RAN) architecture, according to various embodiments. As shown in Figure 1, NG-RAN 100 consists of a set of base stations (gNBs) 102(1) and 102(2), connected to a 5G Core (5GC) 110 through an NG interface 120.

[0003] A given gNB may consist of a gNB Centralized Unit (gNB-CU) 104 and one or more gNB Distributed Units (gNB-DUs), such as gNB-DU 106(1) and 106(2). A gNB- CU 104 and a gNB-DU 106 are connected via an Fl interface 140. As shown, each gNB- DU 106 is connected to only one gNB-CU 104. A given gNB can support frequency division duplex (FDD) mode, time division duplex (TDD) mode or dual mode operation. A pair of gNBs can be interconnected through an Xn interface, such as Xn-C 130 shown in Figure 1.

[0004] Additionally, the NG-RAN can also include of a set of one or more nextgeneration evolved Node Bs (ng-eNBs) (not shown). The set of ng-eNBs may be connected to the 5GC 110 through an Sl-U interface. An ng-eNB may consist of an ng-eNB-CU and one or more ng-eNB-DU(s). An ng-eNB-CU and an ng-eNB-DU are connected via W1 interface. The ng-eNBs may be connected to other nodes (e.g., another ng-eNB or a gNB 102) via an X2-C interface. Those skilled in the art will understand that the techniques described herein also apply to ng-eNBs and the associated interfaces.

[0005] The NG interfaces 120, Xn-C interface 130, and Fl interfaces 140, shown in Figure 1, are logical interfaces. For NG-RAN, the NG and Xn-C interfaces for a gNB that consists of a gNB-CU and one or more gNB-DUs, terminate in the gNB-CU. The gNB- CU and connected gNB-DUs are only visible to other gNBs and the 5GC as a gNB. Referring to Figure 1, while Xn-C 130 connects gNB 102(1) and gNB-CU 104, the gNB- CU 104 and gNB-DUs 106 are visible to the gNB 102(1) as gNB 102(2). Similarly, witharchitectures that utilize Sl-U and / or X2-C interfaces for a gNB consisting of a gNB-CU and gNB-DUs and / or for an ng-eNB consisting of a ng-eNB-CU and ng-eNB-DUs, the interfaces terminate in the gNB-CU and ng-eNB-CU, respectively.

[0006] Figure 2 illustrates a block diagram of an example overall architecture for separation of a gNB-CU-Control Plane (gNB-CU-CP) and gNB-CU-User Plane (gNB-CU- UP) in a gNB 102, according to various embodiments. As shown in Figure 2, a gNB 102 can consist of a gNB-CU-CP 202, multiple gNB-CU-UPs 204, and multiple gNB-DUs 106. A gNB-CU-CP 202 is a logical node hosting the radio resource control (RRC) and control plane portion of the packet data convergence protocol (PDCP) of a gNB-CU, such as gNB- CU 104. A gNB-CU-UP 204 is a logical node that hosts the user plane portion of the PDCP protocol of the gNB-CU 104.

[0007] As shown in Figure 2, a gNB-CU-CP 202 is connected to a gNB-DU 106 through an Fl-C interface 210. A gNB-CU-UP 204 is connected to a gNB-DU 106 through an Fl-U interface 220. A gNB-CU-UP 204 is connected to a gNB-CU-CP 202 through an El interface 230. One gNB-DU 106 is connected to only one gNB-CU-CP 202. One gNB- CU-UP 204 is connected to only one gNB-CU-CP 202. One gNB-DU 106 can be connected to multiple gNB-CU-UPs 204 that are under the control of the same gNB-CU-CP 202. One gNB-CU-UP 204 can be connected to multiple gNB-DUs 106 under the control of the same gNB-CU-CP 202.

[0008] The architecture shown in Figures 1-2 and described above is what 3GPP has defined for 5G (see, e.g., 3GPP Technical Specification 38.401 vl8.2.0). However, other standardization groups, such as the 0-RAN Alliance, have extended or modified this architecture. For example, as discussed in further detail below, 0-RAN architecture further splits a gNB-DU into two nodes that are connected by a fronthaul interface. The lower node of the split gNB-DU (also referred to herein as an 0-RU) contains the physical layer (PHY) protocol and the radio frequency (RF) parts, while the upper node of the split gNB- DU (also referred to herein as an 0-DU) hosts the Radio Link Control (RLC) and Medium Access Control (MAC).O-RAN Logical Architecture

[0009] Figure 3 illustrates an example open radio access network (0-RAN) architecture, according to various embodiments. In the 0-RAN architecture, the following logical nodes and interfaces are defined: Near-Real-Time RAN Intelligent Controller (Near-RT RIC); Non-Real-Time RAN Intelligent Controller (Non-RT RIC); E2 Node; O-RAN Central Unit - Control Plane (O-CU-CP); 0-RAN Central Unit - User Plane (O-CU- UP); and 0-RAN Distributed Unit.

[0010] A Near-Real-Time RAN Intelligent Controller (Near-RT RIC) is an 0-RAN Network Function (NF) that enables near-real-time control and optimization of RAN elements and resources via fine-grained data collection and actions over E2 interface. It may include AI / ML (Artificial Intelligence / Machine Learning) workflow including model training, inference, and updates.

[0011] A Non-Real-Time RAN Intelligent Controller (Non-RT RIC) comprises functionality within O-RAN service management and orchestration (SMO) that drives the content carried across an Al interface. The Non-RT RIC is comprised of the Non-RT RIC Framework and the Non-RT RIC Applications (rApps) whose services are defined below.

[0012] E2 is a logical interface connecting the Near-RT RIC with an E2 Node. The E2 interface is a control plane interface that provides support for Near-RT RIC Services using E2 Application Protocol and E2 Services Models.

[0013] An E2 Node is logical node that terminates an E2 interface. In some version of the technical specifications, O-RAN nodes terminating E2 interface are:• For NR access: O-CU-CP, O-CU-UP, O-DU, or any combination thereof• For E-UTRA access: O-eNB

[0014] An O-RAN Central Unit - Control Plane (O-CU-CP) is a logical node hosting the RRC and the control plane part of the Packet Data Convergence Protocol (PDCP). The O-CU-CP includes the following functions: terminate the NG-c, X2-c, Xn-c, Fl-c, and El interfaces as well as the RRC and PDCP (for SRB) protocols towards the UE; terminate E2 interface to Near-RT RIC; terminate NG-c interface to 5GC; terminate X2-c interface to O- eNB (in case O-eNB is an O-RAN eNB), eNB, or to en-gNB in EN-DC; and terminate Xn- c to O-CU-UP, O-eNB (in case O-eNB is an O-RAN ng-eNB), gNB, or to ng-eNB.

[0015] An O-RAN Central Unit - User Plane (O-CU-UP) is a logical node hosting the user plane part of the PDCP protocol and the Service Data Adaptation Protocol (SDAP).

[0016] An O-RAN Distributed Unit (O-DU) is a logical node hosting RLC / MAC / High-PHY layers based on a lower layer functional split. The O-DU is an O- RAN Network Function, NF, in the O-RAN Architecture. An O-DU, combined with one or more O-RU(s) connected to it, supports and is fully compatible with the functions of a gNB-DU as defined by 3GPP technical specifications (e.g., TS 38.401 vl8.2.0). The O- DU may be implemented either by virtualized or non-virtualized methods. The O-DUterminates the E2 and the Fl interface, and the Open Fronthaul interface (also known as LLS interface) as well as the RLC, MAC, and High-PHY functions of the radio interface towards the UE.

[0017] Al is the interface between the Non-RT RIC in SMO and the Near-RT RIC function O-RAN NF. The Al interface supports three types of services: Policy Management Service, Enrichment Information Service, and ML Model Management Service.

[0018] The 01 interface is used by SMO for the management of the O-RAN NFs.

[0019] Figure 4 is a block diagram illustrating example control loops involving various O-RAN functionalities, according to various embodiments. As shown in Figure 4, the O- RAN architecture supports at least the following control loops involving different O-RAN functionalities: Non-Real Time (Non-RT) control loops, Near-Real Time (Near-RT) control loops, and Real Time (RT) control loops.E2 Service Model in O-RAN

[0020] The O-RAN technical specifications describe O-RAN E2 general aspects and principles (E2GAP) according to which the Near-RT RIC may use the following RIC services provided by an E2 node: REPORT, INSERT, CONTROL, POLICY, and QUERY. (See, 0-RAN.WG3.E2GAP-R003-v05.00)

[0021] REPORT: Near-RT RIC uses a RIC Subscription and / or RIC Subscription Modification procedures to request that E2 Node sends a REPORT message to Near-RT RIC and the associated procedure continues in the E2 Node after each occurrence of a defined RIC Subscription procedure Event Trigger.

[0022] INSERT: Near-RT RIC uses a RIC Subscription and / or RIC Subscription Modification procedures to request that E2 Node sends an INSERT message to Near-RT RIC and suspends the associated procedure in the E2 Node after each occurrence of a defined RIC Subscription procedure Event Trigger.

[0023] CONTROL: Near-RT RIC sends a CONTROL message to E2 Node to initiate a new associated procedure or resume a previously suspended associated procedure in the E2 Node.

[0024] POLICY: Near-RT RIC uses a RIC Subscription and / or RIC Subscription Modification procedures to request that E2 Node executes a specific POLICY during functioning of the E2 Node after each occurrence of a defined RIC Subscription procedure Event Trigger.

[0025] QUERY: Near-RT RIC sends a QUERY message to the E2 node to retrieve RAN-related and / or UE-related information from the E2 Node.Heterogenous Communication Systems

[0026] Depending on the system components, in some instances, a wireless communication system can be a heterogenous communication system. A heterogenous communication system is a communication system that includes network nodes that are compliant with different communication standards and / or includes network nodes that are of different node types. That is, a heterogenous communication system includes at least one of: network nodes that are compliant with different communication standards or network nodes that are of different node types. For the purpose of illustrating a clear example, embodiments are described herein where the communication standards are 3 GPP and O-RAN, and the node types are Near-RT RIC, Non-RT RIC, and E2 node. However, one skilled in the art will understand that the disclosed techniques may be used to coordinate SON functions for any suitable communication standards and / or network node types.

[0027] In some embodiments, the heterogenous communication system includes at least one network node that is compliant with one communication standard, and at least another network node is compliant with a second communication standard. For example, a first network node in the heterogenous communication system could be O-RAN compliant (e.g., a Near-RT RIC) while a second network node in the heterogenous communication system could be 3GPP compliant (e.g., a O-CU, O-DU, gNB-CU, or gNB- DU).

[0028] In some embodiments, the network nodes of the heterogenous communication system are compliant with a single communication standard, but the heterogenous communication system includes at least one network node of a first type and at least another network node of a second type. For example, two network nodes can both be O-RAN compliant, but a first network node is a Near-RT RIC and a second network node is Non- RT RIC.

[0029] According to the O-RAN architecture, a Near-RT RIC is a network node compliant with O-RAN standard (and not with 3 GPP standard), while an E2 node can be seen as equivalent (from the point of view of supporting 3 GPP specific interfaces) to a logical node defined in the 3GPP standard, such as a gNB-CU or a gNB-DU. It should be noted that in some cases, an E2 node can also be compliant with the O-RAN standard (e.g.,an E2 interface can exist between a gNB-CU / gNB-DU and a Near-RT RIC). Alternatively, a 3GPP specific node (e.g., gNB-CU or gNB-DU) could also be extended with support of a proprietary interface towards the Near-RT RIC.Self-Organizing Network Functionality

[0030] Self-organizing network (SON) is an automation technology that enables the network to perform self-management functions, such as setting itself up, managing network resources, managing network configurations, and / or the like, in order to achieve optimal network performance (e.g., better capacity, speeds, reliability, etc.). SON functionalities include, for example, self-configuration, self-optimization, and self-healing.

[0031] In particular, network self-optimization aids in enhanced network performance through near real time optimization of radio and network configurations. SON functionalities include, for example, Mobility Load Balancing (MLB), Mobility Robustness Optimization (MRO), Coverage and Capacity Optimization (CCO), Random Access Channel (RACH) optimization (RO), Network Slice Resource Allocation Optimization, Network Energy Saving Optimization, Massive MIMO Beam-based MRO, QoE optimization, and the like.

[0032] The Open Radio Access Network (O-RAN) technical specification describes some network self-optimization use cases at a high level. For example, the technical specification relating to O-RAN Service Management and Orchestration (SMO) describes that the self-optimization (MLB, MRO, CCO, RO) SON functionality is configured in (individual) Non-Real Time RAN Intelligent Controller (Non-RT RIC), Near-Real Time (Near-RT) RIC, or E2 Node.

[0033] In particular, with respect to the Non-RT RIC, the O-RAN specifications describe that the Non-RT RIC:• Supports setup of SON function and configuration of relevant SON data inputs from SMO.• Configures and collects of cell load related information, handover (HO) related reports, CCO related measurement reports (RLF (Radio Link Failure), MDT (Minimization Drive Test), RCEF (RRC Connection Establishment Failure), etc.), RACH performance reports for constructing relevant AI / ML models to assist in the self-optimization SON functionality.• Supports AI / ML model training and inference based on the input data received.• Re-configures inter-site / inter-RAT cell re-selection parameters, HO related parameters, CCO related control parameters, and RACH parameters based on AI / ML output• Generates relevant Al policies to execute any RRM function for the configured SON function.

[0034] With respect to the Near-RT RIC, the 0-RAN specifications describe that the Near-RT RIC:• Supports setup of SON function and configuration of relevant SON data inputs from SMO.• Configures and collects of load reports, HO related reports (HO failure and RLF), CCO related measurement reports (RLF, MDT, RCEF), RACH performance reports from E2 Nodes over E2 interface.• Supports AI / ML model training and inference based on the input data received via 01 and E2• Re-Configures HO related, Cell reselection parameters, CCO related control parameters and RACH parameters based on AI / ML output.• Supports initiation of radio resource management (RRM) functions like HO initiation, trigger Cell reselection at E2 Node via E2 policies or controls based on AI / ML output.• Supports conversion of Al policy into relevant E2 actions for executing RRM function for a specific SON function.

[0035] With respect to the E2 Node, the 0-RAN specifications describe that the E2 Node:• Supports setup of SON function and configuration of relevant SON data inputs from SMO.• Reports Measurement Report (MR), HO related information, coverage information, RACH performance over E2 / O1 interface• Supports reconfiguration of HO related parameters, Cell reselection parameters, CCO related parameters, RACH parameters based on inputs via E2 or 01 interface.• Supports initiation of RRM functions like HO initiation, Cell reselection, etc. based on inputs received via E2 / O1 interface.

[0036] The Near-RT RIC in O-RAN can subscribe to RIC services provided by an E2 node. For the self-optimization use case, three deployment options are defined in the O- RAN specifications. The three deployment options are illustrated in Figures 5A-C.

[0037] Figure 5A illustrates a flow chart of example steps for performing selfoptimization in Non-RT RIC, according to some embodiments. In Deployment Option 1, shown in Figure 5A, the Near-RT RIC requests E2 services corresponding to Al policies.

[0038] Figure 5B illustrates a flow chart of example steps for performing selfoptimization in Near-RT RIC, according to some embodiments. In Deployment Option 2, shown in in Figure 5B, the Near-RT RIC collects data, infers a new configuration, and sends the new configuration to E2 nodes.

[0039] Figure 5C illustrates a flow chart of example steps for performing selfoptimization in E2 Nodes, according to some embodiments. In Deployment Option 3, shown in Figure 5C, the E2 nodes receives input for executing SON functions from SMO and / or Non-Real Time RIC, and / or the Near-RT RIC.

[0040] Furthermore, according to 3GPP specifications and / or discussions for 3GPP Rel-19, SON functions such as those for the self-optimization use cases (e.g., CCO, MRO, MLB, etc.) can reside in an E2 node (e.g., gNB-CU or gNB-DU). Additionally, an AI / ML model inference function can be deployed at E2 node. The AI / ML model inference function can be used to make or assist the E2 node in making, decisions regarding network management / optimization actions that should be taken, e.g., to produce as output predictions concerning a CCO issue, future coverage states, changes in the mobility handover trigger points, decisions to offload traffic from one gNB to another gNB, optimization of RACH resources, and / or the like.

[0041] There currently exist certain challenges relating to network self-optimization. In particular, as seen above, the various technical specifications describe self-optimization use cases at a high level. As a result, the actual implementation of SON functionality can vary, for example, between network nodes that are compliant with different communication standards and / or between network nodes of different types.

[0042] In one example, a given network can include both Near-RT RIC as well as E2 nodes. In the O-RAN architecture, a Near-RT RIC is a network node that is compliant with the O-RAN standard (and not with 3 GPP standard). An E2 node is a network node, such as a gNB-CU or a gNB-DU, that is assumed compliant with the 3GPP standard (with an Fl interface defined between gNB-CU and gNB-DU). However, because these network nodes are compliant with different standards, they also are likely to implement SON functionalityin different ways. As a result, the network nodes could make different, possibly conflicting, determinations (e.g., actions, configuration changes, resource allocation changes, and / or the like).

[0043] As an example, one problem that can arise is when different optimization decisions are made by Near-RT RIC and E2 nodes. The different optimization decisions could target or affect the same E2 nodes, but with different or conflicting actions. For example, a Near-RT RIC could make a first set of optimization decisions for a set of E2 nodes (e.g., multiple gNBs). One or more of the E2 nodes (e.g., a node for which Near-RT RIC made an optimization decision) could have already initiated an action, or applied a change in radio parameters, that contradicts the decisions taken by the Near-RT RIC. Similarly, one or more E2 nodes could infer (e.g., using AI / ML) a decision or a change in radio parameters that should be applied at a future time. The decision or change could conflict with decisions taken by or inferred by the Near-RT RIC (e.g., a decision taken prior to when the E2 node performs an action or makes a change). As a result, in both of the above examples, if the Near-RT RIC and the E2 nodes make a decision that conflicts or contradicts one another, then various actions or changes made by the Near-RT RIC and / or the E2 node(s) can end up overridden or negated.

[0044] As another example, assume that a first AI / ML model deployed at an E2 node produces output that indicates that a given CCO issue will occur at a given time in the future (e.g., one minute, ten minutes, one hour, etc. from the current time). The E2 node receives the output produced by the first AI / ML model and uses the output when determining whether any action(s) should be taken (e.g., modifying the coverage of certain cells and / or beams). Additionally, a second AI / ML model deployed at a Near-RT RIC produces output that differs from the prediction output by the first AI / ML model (e.g., indicates a different issue will occur at a different time in the future, the same / similar issue will occur at a different time, a different issue will occur at the same / similar time, etc.). The output from the other AI / ML model could also be provided to the E2 node as input that is used when determining action(s) that should be taken. However, the action that the E2 node determines should be taken based on the output of the first AI / ML model may be different from the action that the E2 node determines should be taken based on the output of the second AI / ML model. Nothing precludes that the new input, received from the Near-RT RIC, will produce a different (potentially contradicting) decision at the E2 node. In such cases, the E2 node does not (and is unable to) determine which is the appropriate decisionto take — the one derived internally by the E2 node or the one received from the Near-RT RIC.

[0045] Furthermore, there is no support in either the 3GPP or O-RAN specifications to address situations like those discussed above. The issues discussed above can arise, in particular, when the E2 node is a RAN node deployed in a split architecture, such as a gNB consisting of one gNB-CU and one or more gNB-DUs. The gNB-CU or the gNB-DU could take decisions and / or apply parameter changes that might be communicated within the 3GPP system (e.g., over Fl), but the decisions and / or changes are not visible to a Near-RT RIC.

[0046] In light of the above, the resulting inefficiencies caused by conflicting or different optimization determinations are detrimental to the goal of finding and / or maintaining optimized radio and network configurations.

[0047] Certain aspects of the disclosure and their embodiments may provide solutions to these or other challenges. In particular, the present disclosure enables coordination of Self Optimization Network (SON) functions (Coordinated SON), between network nodes in a heterogeneous communication system. As discussed in further detail below, the network nodes of the heterogenous communication system perform a SON coordination procedure to determine which node(s) will be responsible for managing which SON function(s) and / or for which node(s). For a given SON function, the responsible node manages the given SON function on behalf of one or more designated network nodes. Additionally or alternately, the SON coordination procedure determines an order of precedence between nodes for a given SON function. For a given SON function, if a first network node has greater precedence over a second network node, then decisions made by the first network node are followed instead of decisions made by the second network node. Similarly, actions taken by the first network node (which has greater precedence) can override or overrule actions that are taken or to be taken by the second network node (which has lower precedence).

[0048] For example, with respect to a heterogenous communication system that includes Near-RT RIC and E2 Nodes, the techniques described herein enable a Near-RT RIC and one or more E2 nodes (e.g., gNB-CUs and / or gNB-DUs) to coordinate on how to handle SON functionality in the heterogeneous communication system.

[0049] In some embodiments, the Near-RT RIC acts as a central node, and the gNB- CUs / gNB-DUs connected to the Near-RT RIC are a set of E2 nodes forming a cluster. (An E2 node is connected to a Near-RT RIC if there is an E2 interface defined between them,or at least between the gNB-CU and the Near-RT RIC). When one or more E2 nodes are added to the cluster, a SON coordination setup is executed between the Near-RT RIC and one or more E2 nodes in the cluster. In some embodiments, the SON coordination setup is executed for all E2 nodes in the cluster. In some embodiments, the SON coordination setup is executed for the one or more E2 nodes that were added to the cluster. In some embodiments, the SON coordination setup is executed for newly added nodes that can be involved in at least one task of a SON function. That is, if a given node is not involved in any tasks for any SON functions, then the SON coordination setup may not be executed for the given node.

[0050] The SON coordination setup procedure determines the approach that will be followed by the nodes in the cluster when performing tasks related to one or more SON functionalities (e.g. modifying coverage of cells and / or beams of E2 nodes in the cluster, updating parameters related to traffic steering, optimizing random access resources in a cell of one or more E2 nodes, and / or the like). Similarly, when the configuration of a cluster is modified (for example, from an SMO such as an E2 node being removed, configuration parameters and policies affecting an E2 node being modified, etc.), an SON coordination update procedure is performed to update the SON coordination and / or release the coordination between an E2 node and the Near-RT RIC. In various embodiments, releasing the coordination between an E2 node and the Near-RT RIC could be a result of updating the SON coordination.

[0051] The Near-RT RIC coordinates decisions / configuration parameters which can affect one or multiple E2 nodes. In some embodiments, the Near-RT RIC determines actions and / or configuration parameters mandatory for the E2 nodes, i.e., the E2 nodes to which such actions / parameters refer to are mandated to execute the action(s) or to apply the configuration parameters. In some embodiments, the Near-RT RIC determines actions and / or configuration parameters recommended for the E2 nodes, i.e., the E2 nodes to which such actions / parameters refer to are recommended to execute the action(s) or to apply the configuration parameters, but the E2 nodes can decide to execute a different action or to apply a (possibly slight) different parameter. In some embodiments, the E2 nodes determines action(s) and / or configuration parameters and informs the Near-RT RIC about it(them). The Near-RT RIC can consider action(s) and / or configuration parameters) of other E2 nodes and either mandate or recommend alternative action(s) and / or configuration parameter(s). In some embodiments, the Near-RT RIC is informed / made aware of actions taken by the E2 nodes or configuration parameters applied.

[0052] Certain embodiments may provide one or more of the following technical advantage(s). One advantage of the proposed solution is that, using the disclosed techniques, conflicting decisions / actions taken by two network nodes in a heterogeneous communication system can be avoided. In particular, when the network nodes are compliant with two different communication standards (e.g., O-RAN and 3 GPP), or when network nodes are of different node types (e.g., E2 and Near-RT RIC), SON operations between the network nodes are coordinated such that the actions / decisions taken by network nodes that are compliant with another standard or by network nodes of another type, whichever the case may be, are taken into account when determining actions / making decisions.

[0053] As a result, the handling of SON functionalities whose operation spans the heterogeneous communication system is more efficient compared to systems where conflicting actions / decisions can be made at different network nodes. For example, using the disclosed techniques, the system can avoid performing the same operation multiple times using different controllers (e.g., E2 and Near-RT RIC), taking actions / decisions that contradict or undo actions / decisions that were previously taken or will be taken in the future, and the like. Because the system is able to more effectively perform selfoptimization functions, the network performance of the system is also improved (via the self-optimization).Collaborative Management of SON Functions in Heterogenous Communication Systems

[0054] The disclosed techniques are directed towards collaborative management of SON functions by network nodes in a heterogenous communication system. In some embodiments, a heterogenous communication system is a communication system that includes at least a first network node that is compliant with a first communication standard and a second network node that is compliant with a second communication standard. That is, the heterogenous communication system includes a plurality of network nodes that are compliant with different communication standards.

[0055] Additionally, the heterogenous communication system can be considered to include at least two communication systems (or subsystems) — a first communication system that is compliant with the first communication standard and a second communication system that is compliant with the second communication standard. In someembodiments, the first communication system is compliant with O-RAN and the second communication system is compliant with 3GPP NG-RAN.

[0056] For the purpose of illustrating a clear example, embodiments are described herein where the communication system includes network nodes that are compliant with 3 GPP NG-RAN and network nodes that are compliant with O-RAN. However, one skilled in the art will understand that the disclosed techniques can be used in a communication system that includes network nodes that are compliant with any number (greater than two) of different communication standards and / or any type(s) of communication system standards.

[0057] Additionally, in other embodiments, a heterogenous communication system could be a communication system that includes at least a first network node of a first node type and a second network node of second node type. That is, the network nodes can be compliant with the same communication standard but are different types of nodes. For example, a first and second network node could both be O-RAN compliant, but the first network node could be a Near-RT RIC and the second network node a Non-RT RIC. While embodiments are described herein where the communication system includes network nodes that are compliant with different communication standards, one skilled in the art will understand that the disclosed techniques can be similarly applied to a communication system where network nodes are complaint with the same standard but are of different node types.

[0058] In various embodiments, SON coordination procedures are managed between network nodes belonging to the different standards in the communication system (e.g., between Near-RT RIC and E2 nodes). As discussed above, a cluster comprises a Near-RT RIC and one or more E2 nodes that are connected to the Near-RT RIC. When one or more E2 nodes are added to a given cluster, a SON coordination setup is executed between the Near-RT RIC and the E2 node(s) in the cluster. The SON coordination setup determines the approach that is followed in performing tasks related to one or more SON functionalities (e.g. modifying coverage of cells and / or beams of E2 nodes in the cluster, or updating parameters related to traffic steering, or to optimize random access resources in a cell of one or more E2 nodes). Alternately, in some embodiments, the SON coordination setup can be performed at a later time, for instance, upon configuration, deconfiguration, activation, and / or deactivation of one or more SON functions from an 0AM node or an SMO node.

[0059] Similarly, when the configuration of the cluster is modified (e.g., from an SMO), an update of the SON coordination can be performed or the SON coordination between a given E2 node and the Near-RT RIC could be released. Modification of the cluster configuration could occur, for example, when an E2 node is removed from the cluster, or when configuration parameters and / or policies affecting an E2 node are modified.

[0060] In some embodiments, the coordinated handling of SON functions in this environment is optionally preceded by a network node (e.g., E2 or Near-RT RIC) indicating (e.g., publishing, notifying, messaging, and / or the like) to another network node the SON function(s) for which coordinated handling is possible / allowed / desirable. In some embodiments, this indication is in response to an explicit query / request from an interested network node. In some embodiments, the indication is sent unsolicited by the network node (i.e., without having received a request / query).

[0061] In some embodiments, the SON coordination procedure enables at least one of the following approaches for handling one or more SON functions:• The Near-RT RIC determines actions and / or configuration parameters mandatory for the E2 nodes, i.e., the E2 nodes to which such actions / parameters refer to are mandated to execute the action(s) or to apply the configuration parameters.• The Near-RT RIC determines actions and / or configuration parameters recommended for the E2 nodes, i.e., the E2 nodes to which such actions / parameters refer to are recommended to execute the action(s) or to apply the configuration parameters, and the E2 nodes can decide to execute a different action or to apply a (possibly slight) different parameter.• The E2 nodes determines action(s) and / or configuration parameters and informs the Near-RT RIC about it(them). The Near-RT RIC can consider action(s) and / or configuration parameters) of other E2 nodes and either mandate or recommend alternative action(s) and / or configuration param eter(s).

[0062] Non-limiting examples of SON functions that may be handled by a given node include:Coverage and Capacity Optimization (CCO)Mobility Load Balancing (MLB)• Mobility Robustness Optimization (MRO)• Random Access Channel Optimization (RO)• Quality of Experience (QoE) Optimization• Network Energy Saving (NES)• Massive MIMO Beam-based MRO• Network Slice Resource Allocation Optimization

[0063] Figure 6 illustrates an example overview of steps for coordinating SON functionality in a heterogenous communication system, according to various embodiments. The heterogenous communication system could include a network node A, network node B, and network node C that are compliant with multiple communication standards, such as an O-RAN standard and a 3 GPP standard. For the purpose of illustrating a clear example, in Figure 6, network node A represents a Near-RT RIC; network node B represents a gNB- CU with E2 support, and network node C represents one of the one or more gNB-DUs with E2 support that are controlled by the gNB-CU. The Near-RT RIC communicates with the gNB-CU and gNB-DU via an E2 interface. The gNB-CU and gNB-DU communicate via an Fl interface.

[0064] Although specific types of nodes are shown in Figure 6, other alternatives are possible for the various network nodes, depending on the implementation. For example, network node A, network node B and network node C could be different types of network nodes within the same communication systems. For instance, assuming a communication system compliant with an O-RAN standard, the network node A could be a Near-RT RIC or xApp, while the network nodes B and C could be E2 nodes. In one example, the network node B could be E2 node such as O-CU-CP (also referred to herein as an O-CU), and the network node C could be an E2 node such as an O-DU connected to an O-CU. Additionally, as shown in Figure 6, the E2 interface could be replaced by a proprietary interface or a standard interface extension.

[0065] The approach shown in Figure 6 includes a step 610 (query / notification) and a step 620) (E2 SON coordination setup / response). At step 610, the query / notification step, knowledge of SON functions for which coordination is possible and / or desired by the network node(s) is exchanged. At step 610, the SON coordination setup / response step, a procedure for configuring interoperability for one or more SON functionalities is performed. In some embodiments, the step 610 could also involve a hybrid procedure where Near-RT RIC sends and / or receives signaling message only to / from the gNB-CU orthe gNB-DU, and the rest is done over Fl. As explained in further detail below and illustrated by Figures 7A-8J, the step 610 in Figure 6 is realized with messages M5, M15, M12, and M16. The step 620 in Figure 6 is realized with messages Ml, M2, M3, M4, M6, M7, M8, M9, MIO, Ml 1, M13 and M14.

[0066] It is noted that from a logical point of view, two network nodes that terminate the same interface (e.g., Fl-c, Xn-c) can be expected to provide the same level of functional support over that interface. Therefore, from an outside / high-level perspective, it can be assumed that the support over Fl-c of an O-DU (an E2 logical node, or an O-RAN logical node) and a gNB-DU (a 3 GPP logical node) are considered equivalent. The same assumption can be made for logical nodes supporting an Xn-c interface. That is, an O-CU- CP node (an E2 logical node, or an O-RAN logical node) can be considered equivalent to a gNB-CP (a 3 GPP logical node).

[0067] Furthermore, a network node that is compliant with 3GPP is not required (by 3GPP) to support any O-RAN specific interfaces (e.g., E2). Support for O-RAN specific interfaces is optional and may vary depending on the implementation. For example, a gNB- CU-CP or a gNB-DU are not required, under 3 GPP specifications, to be compliant with an E2 interface. However, there can be implementations of network nodes implementing a gNB-CU-CP or gNB-DU that support both 3 GPP interfaces and O-RAN specific interfaces.

[0068] In contrast, a network node that is considered compliant with O-RAN also supports 3GPP interfaces (e.g., Fl and Xn) in addition to O-RAN specific interfaces. From an outside / high-level perspective, a network node that implements an O-CU-CP (supporting Fl and Xn) can be said to provide the same functional support of a gNB-CU- CP (or a gNB-CU) if mapped to the 3 GPP architecture, and can provide the functional support of an O-CU-CP if mapped to the O-RAN architecture. Furthermore, since an O- RAN O-CU (or an O-RAN O-CU-CP) supports the Xn interface, it can be said that such network node provides the same level of support of a gNB in terms of 3GPP specifications. Similarly, a network node implementing a logical O-DU supports both Fl and E2 interfaces. Therefore, from the outside world, it can be said that such network node can provide the same functional support of a gNB-DU if mapped to the 3GPP architecture, and it can provide the functional support of an O-DU if mapped to the O-RAN architecture.

[0069] In light of the above, a person skilled in the art will understand that any suitable functionally equivalent nodes (i.e., nodes that provide the same functional support) can be used when implementing the techniques discussed herein.O-RAN Initiated SON Coordination

[0070] In some embodiments, a first network node (e.g., Network Node A) is compliant with an O-RAN standard, such as a Near Real-Time RAN intelligent controller (Near-RT RIC), while a second and third network node (e.g., Network Nodes B and C) are compliant with a 3GPP standard. Additionally, in some instances, one of the network nodes (that are compliant with 3GPP) can be served / controlled by another network node. For instance, as shown in Figure 6, Network Node B is a gNB-CU and Network Node C is a gNB-DU that is served / controlled by the gNB-CU.

[0071] In some embodiments, a network node A initiates a first SON Coordination procedure towards a network node B. The network node A can be, for example, a Near- RT RIC, the network node B can be a gNB-CU, and the signaling interface between the network node A and the network node B can be an E2 interface. Additionally, in some embodiments, an additional SON Coordination procedure can be executed, either between the network node A and network node C directly, or between the network node B and a network node C.

[0072] In some embodiments, a network node A initiates a second SON Coordination procedure towards a network node C. The network node C could be, for example, a network node that is controlled / served by the network node B. As an example, the network node C could be a gNB-DU (connected to the network node B via Fl), and the interface between the network node A and the network node C could be an E2 interface. This embodiment is described in further detail below with respect to Figure 7A (Scenario 1 A).

[0073] Additionally, in some embodiments, one or more other network nodes send, to the network node A, indications of SON functions for which coordinated handling is requested / possible / desirable. This embodiment is described in further detail below with respect to Figure 7B (Scenario IB).

[0074] In some embodiments, upon receiving a request for a SON Coordination from the network node A or upon terminating a SON Coordination procedure with the network node A, the network node B, initiates a second SON Coordination procedure towards a network node C that is controlled / served by the network node B. For example, the network node C can be a gNB-DU (connected to the network node B via Fl), and the network node C may have an interface towards the network node A such as an E2 interface. This embodiment is described in further detail below with respect to Figure 7C (Scenario 1C).

[0075] Additionally, in some embodiments, the network node B and / or the network node C can send to the network node A and / or to one another indications of SON functionsfor which coordinated handling is requested / possible / desirable. This embodiment is described in further detail below with respect to Figure 7D (Scenario ID).3GPP Initiated SON Coordination

[0076] As discussed above, in various embodiments, the network node A is compliant with an O-RAN standard, such as a Near Real-Time RAN intelligent controller (Near-RT RIC), while the network nodes B and C are compliant with a 3 GPP standard. Additionally, the network node C is served / controlled by the network node B. For instance, the network node B could be a gNB-CU and the network node C could be a gNB-DU that is served / controlled by the gNB-CU.

[0077] In some embodiments, the network node B and / or the network node C initiates the SON Coordination procedure. That is, the SON Coordination procedure is initiated by a network node that is 3GPP complaint, instead of by a network node that is O-RAN compliant.

[0078] In one embodiment, a first SON Coordination procedure is executed between the network node B (e.g., a node compliant with 3GPP standard) and the network node A (e.g., a node compliant with O-RAN standard). Additionally, another SON Coordination procedure is performed between the network node A and a network node C (e.g., a node that is served / controlled by the network node B) and / or between the network node C and the network node A. This embodiment is described in further detail below with respect to Figure 8A (Scenario 2A). Additionally, in one embodiment, the network node A sends, to the network node B and / or network node C, indication(s) of SON functions for which coordinated handling is requested / possible / desirable. This embodiment is described in further detail below with respect to Figure 8B (Scenario 2B).

[0079] In one embodiment, a gNB-CU and / or gNB-DU(s) controlled by a gNB-CU initiates SON Coordination procedure(s) towards a Near-RT RIC. This embodiment is described in further detail below with respect to Figure 8C (Scenario 2C). Additionally, in one embodiment, the Near-RT RIC sends, to the gNB-CU and / or gNB-DU(s), indication(s) of SON functions for which coordinated handling is requested / possible / desirable. This embodiment is described in further detail below with respect to Figure 8D (Scenario 2D).

[0080] In one embodiment, a first SON Coordination procedure is executed between the network node B and the network node C (i.e., between two network nodes that are compliant with the 3 GPP standard). The SON Coordination procedure can either be initiated by the network node B (e.g., alternative 2e.l shown in the figure below) or by thenetwork node C (e.g., alternative 2e.2 shown in the figure below). Additionally, a second SON Coordination procedure is performed between the network node B and the network node A and / or between the network node C and the network node A. Although the steps are shown in an order in the example below, the order of execution between the first SON Coordination procedure (between 3 GPP nodes) and the second SON Coordination procedure (between 3GPP and O-RAN nodes) can be swapped. This embodiment is described in further detail below with respect to Figure 8E (Scenario 2E). Additionally, in one embodiment, the network node A sends, to the network node B and / or network node C, indication(s) of SON functions for which coordinated handling is requested / possible / desirable. This embodiment is described in further detail below with respect to Figure 8F (Scenario 2F).

[0081] In one embodiment, the network node B initiates the SON Coordination procedure towards the network node A, which in turn triggers a request for SON Coordination procedure(s) towards the network node C(s). In some embodiments, the request is triggered by the network node B after initiating the SON coordination procedure towards the network node A. In some embodiments, the request is triggered by the network node A in response to receiving a message initiating the SON Coordination procedure from the network node B. These embodiments are described in further detail below with respect to Figure 8G (Scenario 2G). Additionally, the network node A can send, to the network node B and / or the network node C, indication(s) of SON functions for which coordinated handling is requested / possible / desirable. This embodiment is described in further detail below with respect to Figure 8H (Scenario 2H).

[0082] In one embodiment, the network node C initiates the SON Coordination procedure towards the network node A, which in turn triggers a request for SON Coordination procedure(s) towards the network node B(s). In some embodiments, the request is triggered by the network node C after initiating the SON coordination procedure towards the network node A. In some embodiments, the request is triggered by the network node A in response to receiving a message initiating the SON Coordination procedure from the network node C. These embodiments are described in further detail below with respect to Scenario 21. Additionally, the network node A can send, to the network node B and / or the network node C, indication(s) of SON functions for which coordinated handling is requested / possible / desirable. This embodiment is described in further detail below with respect to Figure 8J (Scenario 2J).O-RAN Initiated SON Coordination Procedure - Scenario 1A

[0083] In Scenario 1A, the coordination is initiated from a network node compliant with the first communication standard. The signaling interface between the first and the second communication systems (e.g., E2AP) is used for coordination. In some embodiments, the first communication standard is O-RAN and the network node that is initiating the coordination is the Near-RT RIC.

[0084] Figure 7A illustrates an example flow diagram for a SON coordination procedure initiated by an O-RAN network node, according to some embodiments. In particular, Figure 7A illustrates operations performed by Network Nodes A, B, and C for Scenario 1A. In Figure 7A, Network Node A is a Near-RT RIC, Network Node B is a gNB-CU, and Network Node C is a gNB-DU. Although the steps (messages) are shown in an order, in various embodiments, the steps can be performed in a different order and / or in parallel. For example, the order of messages M1-M2 and M3-M4 could be swapped.

[0085] As shown in Figure 7A, a Near-RT RIC sends a message Ml to a gNB-CU. The message Ml includes a SON Coordination request to manage coordinated handling of one or more SON functions (e.g., setup, update, release, pause, resume, etc.). The one or more SON functions determine / perform actions and / or change / adjust configuration parameters that affect the gNB-CU.

[0086] In some embodiments, the SON Coordination request indicates, for one or more SON function, coordination information associated with the SON function. Coordination information could include, for example, one or more of: a level of granularity to which the coordination applies (e.g., cluster, node, gNB-CU, gNB-DU, cell, beam, UE, DRB, QoS flow, PDU session, PDU set, network slice(s), etc.); one or more UEs or groups of UEs associated with the SON function; action(s) pertaining to the SON function that are subject to coordination (e.g., CCO issue detection, CCO issue resolution, mobility setting change, mobility load balancing, RACH resource optimization, QoE optimization, Network slice resource allocation optimization, network energy saving optimization, Massive MIMO, beam-based MRO, etc.); which network node takes precedence in decision-making / action- taking / parameter-setting, or an order of precedence for a plurality of network nodes; policies related to the SON function; allowed ranges for configuration parameters; information requested as feedback to assess the outcome of the SON function (e.g., UE performance, cell level performance, etc.); timing information (e.g., reference time scale / interval for execution of the SON function, reference time scale / interval for collectingrequested information, etc.); radio configuration related information (e.g., range of possible values for various configuration parameters); and / or the like.

[0087] The gNB-CU receives the message Ml from the Near-RT RIC. In response, the gNB-CU transmits a message M2 to the Near-RT RIC. The message M2 acknowledges the SON Coordination request. In some embodiments, the acknowledgement indicates whether the gNB-CU accepts or rejects the SON Coordination request. For instance, the acknowledgement can contain a list of SON functions for which the gNB-CU accepts the SON coordination request and / or a list of SON function for which the gNB-CU rejects the SON coordination request.

[0088] In some embodiments, if the gNB-CU does not accept SON coordination for any of the SON functions, then the gNB-CU sends a message (e.g., as part of message M2, instead of the message M2, or in addition to the message M2) indicating that it rejects the SON Coordination request for all SON functions.

[0089] In some other embodiment, the message M2 indicates a partial acknowledgement (or partial success). For example, the message M2 could explicitly indicate one or more SON functions for which coordination is not accepted. Additionally, the message M2 could, either explicitly or implicitly, indicate that coordination of one or more other SON functions is accepted. For example, by including a list of SON functions for which SON coordination was not accepted (rejected), the message M2 could implicitly indicate that SON coordination was accepted for the remaining (requested in message Ml and unlisted in message M2) SON functions.

[0090] If the gNB-CU accepts the SON Coordination request, then the gNB-CU performs (or refrains from performing) SON functions in accordance with the information specified in the SON Coordination request. For example, assume the SON Coordination request specifies a network node that takes precedence for a given SON function, either explicitly (e.g., specified by the coordination information in the request) or implicitly (e.g., because the request originated from the Near-RT RIC, the Near-RT RIC has priority). If the gNB-CU makes a determination relating to the given SON function but also receives a determination / action / parameter change / etc. from the specified network node, then the gNB-CU gives precedence to the determination / action / parameter change / etc. received from the specified network node.

[0091] Additionally, as shown in Figure 7A, the Near-RT RIC sends to one or more of the gNB-DUs controlled by the gNB-CU a message M3. A message M3 includes a SON Coordination request to manage coordinated handling of one or more SON functions (e.g.,setup, update, release, pause, resume, etc.). The one or more SON functions determine / perform actions and / or change / adjust configuration parameters that affect the gNB-DU. In some embodiments, similar to message Ml, the message M3 includes coordination information associated with the one or more SON functions.

[0092] A gNB-DU receives the message M3 from the Near-RT RIC. In response, the gNB-DU transmits a message M4 to the Near-RT RIC. The message M4 acknowledges the SON Coordination request. In some embodiments, the acknowledgement indicates whether the gNB-DU accepts or rejects the SON Coordination request. If the gNB-DU accepts the SON Coordination request, then the gNB-DU performs (or refrains from performing) SON functions in accordance with the information specified in the SON Coordination request. For instance, the acknowledgement can contain a list of SON functions for which the gNB-DU accepts the SON coordination request and / or a list of SON function for which the gNB-DU rejects the SON coordination request.

[0093] In some embodiments, if the gNB-DU does not accept SON coordination for any of the SON functions, then the gNB-DU sends a message (e.g., as part of message M2, instead of the message M2, or in addition to the message M2) indicating that it rejects the SON Coordination request for all SON functions.

[0094] In some other embodiment, the message M4 indicates a partial acknowledgement (or partial success). For example, the message M4 could explicitly indicate one or more SON functions for which coordination is not accepted. Additionally, the message M4 could, either explicitly or implicitly, indicate that coordination of one or more other SON functions is accepted. For example, by including a list of SON functions for which SON coordination was not accepted (rejected), the message M4 could implicitly indicate that SON coordination was accepted for the remaining (requested in message M3 and unlisted in message M4) SON functions.

[0095] In some embodiments, the message M3 is the same as message Ml. That is, messages M3 and Ml contain the same information / contents.

[0096] In some embodiment, both message M3 and message Ml are used for coordination of a certain SON function, and the content of message M3 is different from the content of message Ml. For example, a SON function (e.g., CCO) requires the coordination of certain parameters and / or actions between the Near-RT RIC and the gNB- CU, and the coordination of other parameters and / or actions between the Near-RT RIC and the gNB-DU.

[0097] In some embodiments, the message M4 is the same as message M2. That is, messages M4 and M2 contain the same information / contents.

[0098] In some embodiments, both message M4 and message M2 are used for coordination of a certain SON function, but the content of message M4 is different from the content of message M2. For example, a SON function (e.g., CCO) requires the coordination of certain parameters and / or actions between the Near-RT RIC and the gNB- CU, and the coordination of other parameters and / or actions between the Near-RT RIC and the gNB-DU.O-RAN Initiated SON Coordination Procedure - Scenario IB

[0099] In Scenario IB, the coordination is also initiated from a network node that is compliant with the first communication standard. In some embodiments, the first communication standard is O-RAN and the network node that is initiating the coordination is the Near-RT RIC.

[0100] Figure 7B illustrates an example flow diagram for a SON coordination procedure initiated by an O-RAN network node, according to some other embodiments. In particular, Figure 7B illustrates operations performed by Network Nodes A, B, and C for Scenario IB. In Figure 7B, Network Node A is a Near-RT RIC, Network Node B is a gNB- CU, and Network Node C is a gNB-DU. Although the steps (messages) are shown in an order, in various embodiments, the steps can be performed in a different order and / or in parallel. For example, the order of the messages M1-M2 and M3-M4 could be swapped. As another example, the message M5 from the gNB-DU to the Near-RT RIC could be sent before messages Ml or M2.

[0101] As shown in Figure 7B, Scenario IB is similar to Scenario 1A, except that before executing the steps described above for Scenario 1A, a network node B (e.g., the gNB-CU) and / or one or more network nodes C (e.g., one or more of the gNB-DUs controlled by the gNB-CU) sends a network node A (e.g., the Near-RT RIC) a message M5.

[0102] The message M5 publishes / indicates / notifies the network node A of one or more SON functions for which a coordinated handling is relevant (e.g., allowed, possible, and / or desirable by the node that is transmitting the message).

[0103] In some embodiments, the SON functions specified in the SON coordination request message M1 / M3 include the one or more SON functions indicated in the messageM5, or at least a portion thereof. That is, the network node A transmits a SON coordination request for the SON functions where the network node(s) B and / or C have indicated that coordinated handling is relevant. In some embodiments, the SON functions specified in the SON coordination request include only the relevant SON functions indicated in the message M5.

[0104] In some embodiments, the SON functions specified in the SON coordination request include one or more additional SON functions that were not indicated in the message M5, e.g., one or more SON functions that network node A determined are relevant, that are indicated by a message received from a different network node, and / or the like. For example, network node A could determine one or more SON functions for which SON coordination is desirable or needed. As another example, network node A could receive or obtain from another network node (e.g., 0AM or SMO) one or more SON functions for which SON coordination is desirable or needed. The network node A could determine the one or more SON functions that are subject to coordination based on one or more of: the SON functions indicated in one or more messages M5, SON functions determined to be relevant by the network node A itself, SON functions determined to be relevant by another network node (e.g., 0AM or SMO).

[0105] In some embodiments, the message M5 is preceded by a message Ml 5 that is used by network node A to request / query which SON function(s) are relevant for coordinated handling. In such cases, network node A transmits the message Ml 5 to network node B and / or network node C. In response to receiving the message Ml 5, network node B and / or C, whichever the case may be, transmits the message M5 to network node A.O-RAN Initiated SON Coordination Procedure - Scenario 1C

[0106] In Scenario 1C, the coordination is initiated from a network node compliant with the first communication standard. In some embodiments, the first communication standard is O-RAN and the network node that is initiating the coordination is the Near-RT RIC.

[0107] To achieve the coordination, the signaling interface between the first and the second communication standards (e.g., E2AP) is used between a network node compliant with the first communication standard and a second node compliant with the second communication standard (e.g., the Near-RT RIC and the gNB-CU, respectively), and the signaling interface of the second communication standard (e.g., F1AP) is used betweennetwork nodes compliant with the second communication standard (e.g., between the gNB- CU and one or more gNB-DU(s)).

[0108] Figure 7C illustrates an example flow diagram for a SON coordination procedure initiated by an O-RAN network node, according to some other embodiments. In particular, Figure 7C illustrates operations performed by Network Nodes A, B, and C for Scenario 1C. In Figure 7C, Network Node A is aNear-RT RIC, Network Node B is a gNB- CU, and Network Node C is a gNB-DU. Although the steps (messages) are shown in an order, in various embodiments, the steps can be performed in a different order and / or in parallel. For example, the message M6 can be sent before or after sending M2. Additionally, the message M2 can be sent by network node B before or after receiving M7.

[0109] As shown in Figure 7C, the Near-RT RIC sends a message Ml to the gNB-CU. The message Ml includes a SON Coordination request to manage coordinated handling of one or more SON functions (e.g., setup, update, release, pause, resume, etc.). The one or more SON functions determine / perform actions and / or change / adjust configuration parameters that affect the gNB-CU. In some embodiments, the SON Coordination request includes coordination information for the one or more SON functions.

[0110] The gNB-CU receives the message Ml from the Near-RT RIC. In response, the gNB-CU transmits a message M2 to the Near-RT RIC. The message M2 acknowledges the SON Coordination request. In some embodiments, the acknowledgement indicates whether the gNB-CU accepts or rejects the SON Coordination request.

[0111] Additionally, as shown in Figure 7C, the gNB-CU sends a message M6 to one or more of the gNB-DU(s) under its control. The message M6 includes a SON Coordination request to manage coordinated handling of one or more SON functions (e.g., setup, update, release, pause, resume, etc.). The one or more SON functions determine / perform actions and / or adjust / change configuration parameters that affect a gNB-DU.

[0112] The one or more gNB-DU(s) controlled by the gNB-CU receive the message M6. In response, each gNB-DU transmits a message M7 to the gNB-CU. The message M7 acknowledges the SON Coordination request. In some embodiments, the acknowledge indicates whether the gNB-DU that is transmitting the message accepts or rejects the SON Coordination request. If the gNB-DU accepts the SON Coordination request, then the gNB-DU performs (or refrains from performing) SON functions in accordance with the information specified in the SON Coordination request.

[0113] In some embodiments, if the gNB-CU does not accept SON coordination for any of the SON functions, then the gNB-CU sends a message (e.g., as part of message M2, instead of the message M2, or in addition to the message M2) indicating that it rejects the SON Coordination request for all SON functions.

[0114] In some embodiments, if the gNB-DU does not accept SON coordination for any of the SON functions, then the gNB-DU sends a message (e.g., as part of message M7, instead of the message M7, or in addition to the message M7) indicating that it rejects the SON Coordination request for all SON functions.

[0115] In some other embodiment, the message M7 indicates a partial acknowledgement (or partial success). For example, the message M7 could explicitly indicate one or more SON functions for which coordination is not accepted. Additionally, the message M7 could, either explicitly or implicitly, indicate that coordination of one or more other SON function is accepted. For example, by including a list of SON functions for which SON coordination was not accepted (rejected), the message M7 could implicitly indicate that SON coordination was accepted for the remaining (requested in message M6 and unlisted in message M7) SON functions.

[0116] In some embodiments, the content of message M6 is the same as the content of message Ml. In some embodiments, only part of the content of message Ml is signaled (possibly in different format or encoding) in message M6. In some embodiments, the message Ml (or a portion thereof) is encapsulated in message M6.

[0117] Similarly, in some embodiments, the content of message M7 is the same as the content of message M2. In some embodiments, only part of the content of message M7 is signaled (possibly in a different format or encoding) in message M2. In some embodiments, the message M7 (or portion thereof) is encapsulated in message M2.O-RAN Initiated SON Coordination Procedure - Scenario ID

[0118] In Scenario ID, the coordination is also initiated from a network node that is compliant with the first communication standard. In some embodiments, the first communication standard is O-RAN and the network node that is initiating the coordination is the Near-RT RIC.

[0119] Figure 7D illustrates an example flow diagram for a SON coordination procedure initiated by an O-RAN network node, according to some other embodiments. In particular, Figure 7D illustrates operations performed by Network Nodes A, B, and C for Scenario ID. In Figure 7D, Network Node A is a Near-RT RIC, Network Node B is agNB-CU, and Network Node C is a gNB-DU. Although the steps (messages) are shown in an order, in various embodiments, the steps can be performed in a different order and / or in parallel. For example, the message M6 can be sent before or after sending M2. Similarly, the message M2 can be sent by network node B before or after receiving M7. As another example, the message M5 could be sent from network node C prior to or at the same time as the message M5 from network node B.

[0120] As shown in Figure 7D, Scenario ID is similar to Scenario 1C, except that before executing the steps described above for Scenario 1C, the network node B (e.g., the gNB-CU) and / or one or more of the network nodes C (e.g., one or more of the gNB-DUs controlled by the gNB-CU) sends the network node A (e.g., the Near-RT RIC) a message M5.

[0121] The message M5 publishes / indicates / notifies the network node A of one or more SON functions for which a coordinated handling is relevant (e.g., allowed, possible, and / or desirable by the node that is transmitting the message). In some embodiments, the one or more SON functions indicated in the message M5 are the SON functions specified in the SON coordination request message M1 / M3. That is, network node A transmits a SON coordination request for the SON functions where network nodes B and / or C have indicated that coordinated handling is relevant.

[0122] In some embodiments, the message M5 is preceded by a message Ml 5 that is used by network node A to request / query which SON function(s) are relevant for coordinated handling. In such cases, network node A transmits the message Ml 5 to network node B and / or network node C. In response to receiving the message Ml 5, network node B and / or C, whichever the case may be, transmits the message M5 to network node A.3GPP Initiated SON Coordination Procedure - Scenario 2A

[0123] In Scenario 2A, the coordination is initiated from a network node compliant with the second communication standard. In some embodiments, the second communication standard is 3GPP and the network node that is initiating the coordination is an E2 node, such as a gNB-CU and / or a gNB-DU that is controlled by the gNB-CU. Additionally, in some embodiments, the first communication standard is O-RAN.

[0124] To achieve the coordination, the signaling interface between the first and the second communication standards is used between network nodes compliant with the firstcommunication standard and network nodes compliant with the second communication standard (e.g., E2AP between the Near-RT RIC and the gNB-CU). The signaling interface of the second communication standard is used between network nodes compliant with the second communication standard (e.g., F1AP between the gNB-CU and one or more gNB- DU(s)).

[0125] Figure 8A illustrates an example flow diagram for a SON coordination procedure initiated by a 3 GPP network node, according to some embodiments. In particular, Figure 8A illustrates operations performed by Network Nodes A, B, and C for Scenario 2A. In Figure 8A, Network Node A is a Near-RT RIC, Network Node B is a gNB-CU, and Network Node C is a gNB-DU. Although the steps (messages) are shown in an order, in various embodiments, the steps can be performed in a different order and / or in parallel. For example, the order of messages M8-M9 and M10-M11 could be swapped.

[0126] As shown in Figure 8A, the gNB-CU sends a message M8 to the Near-RT RIC. The message M8 includes a SON Coordination request to manage coordinated handling of one or more SON functions (e.g., setup, update, release, pause, resume, etc.). The one or more SON functions determine / perform actions and / or change / adjust configuration parameters that affect the gNB-CU and / or one or more of the gNB-DUs controlled by the gNB-CU. In some embodiments, the SON Coordination request includes coordination information associated with the one or more SON functions.

[0127] The Near-RT RIC receives the message M8 from the gNB-CU. In response, the Near-RT RIC transmits a message M9 to the gNB-CU. The message M9 acknowledges the SON Coordination request. In some embodiments, the acknowledgement indicates whether the Near-RT RIC accepts or rejects the SON Coordination request.

[0128] If the Near-RT RIC accepts the SON Coordination request, then the Near RT- RIC performs (or refrains from performing) SON functions in accordance with the information specified in the SON Coordination request. For example, assume the SON Coordination request specifies a network node that takes precedence for a given SON function, either explicitly (e.g., specified by the coordination information in the request) or implicitly (e.g., because the request originated from the gNB-CU, the gNB-CU has priority). If the Near-RT RIC makes a determination relating to the given SON function but also receives a determination / action / parameter change / etc. from the specified network node, then the Near-RT RIC gives precedence to the determination / action / parameter change / etc. received from the specified network node.

[0129] Additionally, as shown in Figure 8A, one or more of the gNB-DUs controlled by the gNB-CU sends the Near-RT RIC a message MIO. A message MIO includes a SON Coordination request to manage coordinated handling of one or more SON functions (e.g., setup, update, release, pause, resume, etc.). The one or more SON functions determine / perform actions and / or change / adjust configuration parameters that affect the gNB-DU and / or other the gNB-CU controlling the gNB-DU and / or other gNB-DU(s) controlled by the same gNB-CU. In some embodiments, similar to message M8, the message MIO includes coordination information associated with the one or more SON functions.

[0130] The Near-RT RIC receives a message MIO from each of the one or more gNB- DUs. In response, the Near-RT RIC transmits a corresponding message Ml 1 to each of the one or more gNB-DUs. The message Mi l acknowledges the SON Coordination request. In some embodiments, the acknowledgement indicates whether the Near-RT RIC accepts or reject the SON Coordination request. If the Near-RT RIC accepts the SON Coordination request, then the Near-RT RIC performs (or refrains from performing) SON functions in accordance with the information specified in the SON Coordination request.

[0131] In some embodiment, the message M9 and / or the message Mi l indicates a partial acknowledgement (or partial success). For example, the message M9 and / or message Mi l could explicitly indicate one or more SON functions for which coordination is not accepted. Additionally, the message M9 and / or message Ml 1 could, either explicitly or implicitly, indicate that coordination of one or more other SON functions is accepted. For example, by including a list of SON functions for which SON coordination was not accepted (rejected), the message M9 and / or message Mi l could implicitly indicate that SON coordination was accepted for the remaining (requested in message M8 and unlisted in message M9 and / or requested in message M10 and unlisted in message Mi l) SON functions.

[0132] In some embodiments, if the Near-RT RIC does not accept SON coordination for any of the SON functions, then the Near-RT RIC sends a message (e.g., as part of message M9, instead of the message M9, or in addition to the message M9, or as part of message Ml 1, instead of message Mi l, or in addition to the message Ml 1) indicating that it rejects the SON Coordination request for all SON functions.

[0133] In some embodiments, the message M10 is the same as message M8. That is, messages M10 and M8 contain the same information / contents.

[0134] In some embodiment, both message MIO and message M8 are used for coordination of a certain SON function, and the content of message MIO is different from the content of message M8. For example, a SON function (e.g., CCO) requires the coordination of certain parameters and / or actions between the Near-RT RIC and the gNB- CU, and the coordination of other parameters and / or actions between the Near-RT RIC and the gNB-DU.

[0135] In some embodiments, the message Ml 1 is the same as message M9. That is, messages Ml 1 and M9 contain the same information / contents.

[0136] In some embodiment, both message Mi l and message M9 are used for coordination of a certain SON function, but the content of message Ml 1 is different from the content of message M9. For example, a SON function (e.g., CCO) requires the coordination of certain parameters and / or actions between the Near-RT RIC and the gNB- CU, and the coordination of other parameters and / or actions between the Near-RT RIC and the gNB-DU.3GPP Initiated SON Coordination Procedure - Scenario 2B

[0137] In Scenario 2B, the coordination is also initiated from a network node that is compliant with the second communication standard. In some embodiments, the second communication standard is 3GPP and the network node that is initiating the coordination is an E2 node, such as a gNB-CU and / or a gNB-DU that is controlled by the gNB-CU. Additionally, in some embodiments, the first communication standard is O-RAN.

[0138] Figure 8B illustrates an example flow diagram for a SON coordination procedure initiated by a 3GPP network node, according to some other embodiments. In particular, Figure 8B illustrates operations performed by Network Nodes A, B, and C for Scenario 2B. In Figure 8B, Network Node A is a Near-RT RIC, Network Node B is a gNB- CU, and Network Node C is a gNB-DU. Although the steps (messages) are shown in an order, in various embodiments, the steps can be performed in a different order and / or in parallel. For example, the order of the messages M8-M9 and M10-M11 could be swapped. As another example, the message M12 from the Near-RT RIC could be sent before messages M8 or M9.

[0139] As shown in Figure 8B, Scenario 2B is similar to Scenario 2A, except that before executing the steps described above for Scenario 2A, the Near-RT RIC sends a message M12 to network node(s) B and / or C (e.g., to the gNB-CU and / or one or more of the gNB-DUs controlled by the gNB-CU).

[0140] The message M12 publishes / indicates / notifies network node(s) B and / or C of one or more SON functions for which a coordinated handling is relevant (e.g., allowed, possible, and / or desirable by the node that is transmitting the message). In some embodiments, the one or more SON functions indicated in the message Ml 2 are the SON functions specified in the SON coordination request message M8 / M10. That is, network node B and / or C transmits a SON coordination request for the SON functions where network node A has indicated that coordinated handling is relevant.

[0141] In some embodiments, the message M12 is preceded by a message M16 that is used by network node(s) B and / or C to request / query which SON function(s) are relevant for coordinated handling. In such cases, network node(s) B and / or C transmit the message Ml 6 to network node A. In response to receiving the message Ml 6, network node A transmits the message M12 to network node(s) B and / or C, whichever the case may be.3GPP Initiated SON Coordination - Scenario 2C

[0142] In Scenario 2C, the coordination is initiated from a network node compliant with the second communication standard. In some embodiments, the second communication standard is 3GPP and the network node that is initiating the coordination is an E2 node, such as a gNB-CU and / or a gNB-DU that is controlled by the gNB-CU. Additionally, in some embodiments, the first communication standard is O-RAN.

[0143] To achieve the coordination, the signaling interface between the first and the second communication standards is used between network nodes compliant with the first communication standard and network nodes compliant with the second communication standard (e.g., E2AP between the Near-RT RIC and the gNB-CU). The signaling interface of the second communication standard is used between network nodes compliant with the second communication standard (e.g., F1AP between the gNB-CU and one or more gNB- DU(s)).

[0144] In Scenario 2C, unlike in Scenario 2A and 2B, a gNB-DU does not initiate a SON Coordination procedure by transmitting a message directly to the Near-RT RIC. In the embodiment shown in Scenario 2C, a gNB-DU controlled by the gNB-CU initiates a SON Coordination procedure towards the Near-RT RIC with a signaling that reaches the Near-RT RIC via the gNB-CU. That is, the gNB-CU acts as a relay between the gNB-DU and the Near-RT RIC. In some embodiments, a gNB-DU initiates the SON coordination procedure towards the controlling gNB-CU. The gNB-CU determines that SONcoordination procedure towards the Near-RT RIC should be trigger and, subsequently, triggers the SON coordination towards the Near-RT RIC .

[0145] Figure 8C illustrates an example flow diagram for a SON coordination procedure initiated by a 3GPP network node, according to some other embodiments. In particular, Figure 8C illustrates operations performed by Network Nodes A, B, and C for Scenario 2C. In Figure 8C, Network Node A is a Near-RT RIC, Network Node B is a gNB- CU, and Network Node C is a gNB-DU. Although the steps (messages) are shown in an order, in various embodiments, the steps can be performed in a different order and / or in parallel. For example, the order of messages M8-M9 and M10-M11 could be swapped. As another example, message M8 can be sent before or after sending message M14. Similarly, message M14 can be sent before or after receiving message M9.

[0146] As shown in Figure 8C, the gNB-CU sends a message M8 to the Near-RT RIC. The message M8 includes a SON Coordination request to manage coordinated handling of one or more SON functions (e.g., setup, update, release, pause, resume, etc.). The one or more SON functions determine / perform actions and / or change / adjust configuration parameters that affect the gNB-CU. In some embodiments, the SON Coordination request includes coordination information associated with the one or more SON functions.

[0147] The Near-RT RIC receives the message M8 from the gNB-CU. In response, the Near-RT RIC transmits a message M9 to the gNB-CU. The message M9 acknowledges the SON Coordination request. In some embodiments, the acknowledgement indicates whether the Near-RT RIC accepts or rejects the SON Coordination request. If the Near- RT RIC accepts the SON Coordination request, then the Near RT-RIC performs (or refrains from performing) SON functions in accordance with the information specified in the SON Coordination request.

[0148] In some embodiments, if the Near-RT RIC does not accept SON coordination for any of the SON functions, then the Near-RT RIC sends a message (e.g., as part of message M9, instead of the message M9, or in addition to the message M9) indicating that it rejects the SON Coordination request for all SON functions.

[0149] In some embodiment, the message M9 indicates a partial acknowledgement (or partial success). For example, the message M9 could explicitly indicate one or more SON functions for which coordination is not accepted. Additionally, the message M9 could, either explicitly or implicitly, indicate that coordination of one or more other SON functions is accepted. For example, by including a list of SON functions for which SON coordination was not accepted (rejected), the message M9 could implicitly indicate thatSON coordination was accepted for the remaining (requested in message M8 and unlisted in message M9) SON functions.

[0150] Additionally, as shown in Figure 8C, one or more of the gNB-DUs controlled by the gNB-CU each send a message M13 to the gNB-CU. A message M13 includes a SON Coordination request to manage coordinated handling of one or more SON functions (e.g., setup, update, release, pause, resume, etc.). The one or more SON functions determine / perform actions and / or change / adjust configuration parameters that affect the gNB-DU. In some embodiments, similar to message M8, the message Ml 3 includes coordination information associated with the one or more SON functions.

[0151] The gNB-CU receives the message M13 and forwards the request in M13 to the Near-RT RIC in a message M8.

[0152] The Near-RT RIC receives the message M8 including the request from the gNB-DU. In response, the Near-RT RIC transmits a response to the request in a message M9 to the gNB-CU. The message M9 acknowledges the SON Coordination request from the gNB-DU. In some embodiments, the acknowledgement indicates whether the Near-RT RIC accepts the SON Coordination request.

[0153] The gNB-CU receives the message M9 and forwards the response provided by the Near-RT RIC to the gNB-DU in a message M14.

[0154] In some embodiments, the content of a message M8 that is forwarding the request in message M13 is the same as the content of the message M13. In some embodiments, message M13 (or a portion thereof) is encapsulated in the message M8.

[0155] In some embodiments, the content of a message M9 that includes a response from the Near-RT RIC is the same as the message M14 relaying the response to the gNB- DU. In some embodiments, the message M9 (or a portion thereof) is encapsulated in the message M14.

[0156] In some embodiment, both message M8 and message Ml 3 are used for coordination of a certain SON function, and the content of message M8 is different from the content of message M13. For example, a SON function (e.g., CCO) requires the coordination of certain parameters and / or actions between the gNB-DU and the Near-RT RIC, and the coordination of other parameters and / or actions between the gNB-CU and the Near-RT RIC. For the same reason, in some embodiment, both message M9 and message M14 are used for coordination of certain SON function, and the content of message M9 and message M14 are different.3GPP Initiated SON Coordination Procedure - Scenario 2D

[0157] In Scenario 2D, the coordination is also initiated from a network node that is compliant with the second communication standard. In some embodiments, the second communication standard is 3GPP and the network node that is initiating the coordination is an E2 node, such as a gNB-CU and / or a gNB-DU that is controlled by the gNB-CU. Additionally, in some embodiments, the first communication standard is O-RAN.

[0158] Figure 8D illustrates an example flow diagram for a SON coordination procedure initiated by a 3GPP network node, according to some other embodiments. In particular, Figure 8D illustrates operations performed by Network Nodes A, B, and C for Scenario 2D. In Figure 8D, Network Node A is a Near-RT RIC, Network Node B is a gNB-CU, and Network Node C is a gNB-DU. Although the steps (messages) are shown in an order, in various embodiments, the steps can be performed in a different order and / or in parallel. For example, the message M8 can be sent before or after sending message M14. Also, message M14 can be sent before or after receiving message M9.

[0159] As shown in Figure 8D, Scenario 2D is similar to Scenario 2C, except that before executing the steps described above for Scenario 2C, the Near-RT RIC sends a message M12 to network node(s) B and / or C (e.g., to the gNB-CU and / or one or more of the gNB-DUs controlled by the gNB-CU).

[0160] The message M12 publishes / indicates / notifies the network node(s) of one or more SON functions for which a coordinated handling is relevant (e.g., allowed, possible, and / or desirable by the node that is transmitting the message). In some embodiments, the one or more SON functions indicated in the message M12 are the SON functions specified in the SON coordination request message M8 / M10. That is, a network node transmits a SON coordination request for the SON functions where network node A has indicated that coordinated handling is relevant.

[0161] In some embodiments, the message M12 is preceded by a message M16 that is used by network node(s) B and / or C to request / query which SON function(s) are relevant for coordinated handling. In such cases, the network node(s) transmit the message Ml 6 to network node A. In response to receiving the message Ml 6, network node A transmits the message M12 to the network node(s) B and / or C, whichever the case may be.3GPP Initiated SON Coordination Procedure - Scenario 2E

[0162] In Scenario 2E, the coordination is initiated from a network node compliant with the second communication standard. In some embodiments, the second communication standard is 3GPP and the network node that is initiating the coordination is an E2 node, such as a gNB-CU and / or a gNB-DU that is controlled by the gNB-CU. Additionally, in some embodiments, the first communication standard is O-RAN.

[0163] In some embodiments, the SON coordination procedure is initiated by a gNB- CU. The gNB-CU triggers the SON Coordination procedure towards one or more gNB- DUs controlled by the gNB-CU, as well as towards a network node that is compliant with the first communication standard (e.g., Near-RT RIC when the first communication standard is O-RAN). Optionally, in some embodiments, the gNB-CU triggers a first SON Coordination procedure and triggers a second SON Coordination procedure based on the output of the first SON Coordination procedure. For example, the gNB-CU could trigger a first SON Coordination procedure towards one or more gNB-DUs controlled by the gNB- CU. If the one or more gNB-DUs accept the SON Coordination request, then the gNB-CU could trigger a second SON Coordination procedure towards the Near-RT RIC. If the one or more gNB-DUs reject the SON Coordination request, then the gNB-CU could avoid triggering the second SON Coordination procedure.

[0164] Figure 8E illustrates an example flow diagram for a SON coordination procedure initiated by a 3GPP network node, according to some other embodiments. In particular, Figure 8E illustrates operations performed by Network Nodes A, B, and C for Scenario 2E. In Figure 8E, Network Node A is a Near-RT RIC, Network Node B is a gNB- CU, and Network Node C is a gNB-DU. Although the steps (messages) are shown in an order, in various embodiments, various steps can be performed in a different order and / or in parallel. For example, message M8 could be sent before or after receiving message M7.

[0165] As shown in Figure 8E, in one approach, the gNB-CU sends a message M6 to one or more gNB-DUs controlled by the gNB-CU. The message M8 includes a SON Coordination request to manage coordinated handling of one or more SON functions (e.g., setup, update, release, pause, resume, etc.). The one or more SON functions determine / perform actions and / or change / adjust configuration parameters that affect the gNB-CU and / or the gNB-DUs. In some embodiments, the SON Coordination request includes coordination information associated with the one or more SON functions.

[0166] The one or more gNB-DUs receive the message M6 from the gNB-CU. In response, each gNB-DU transmits a message M7 to the gNB-CU. The message M7acknowledges the SON Coordination request. In some embodiments, the acknowledgement indicates whether the corresponding gNB-DU accepts or rejects the SON Coordination request. If a gNB-DU accepts the SON Coordination request, then the gNB-DU performs (or refrains from performing) SON functions in accordance with the information specified in the SON Coordination request.

[0167] As shown in Figure 8E, in an alternate approach, one or more of the gNB-DUs controlled by the gNB-CU each send a message M13 to the gNB-CU. A message M13 includes a SON Coordination request to manage coordinated handling of one or more SON functions (e.g., setup, update, release, pause, resume, etc.). Alternately, the message Ml 3 indicates that SON Coordination is required / requested for the one or more SON functions. The one or more SON functions determine / perform actions and / or change / adjust configuration parameters that affect the gNB-DU. In some embodiments, similar to message M6, the message Ml 3 includes coordination information associated with the one or more SON functions.

[0168] The gNB-CU receives the message(s) M13 from the one or more gNB-DUs. In response, the gNB-CU transmits a message M14 to each of the one or more gNB-DUs. The message M14 acknowledges / confirms the SON Coordination for the one or more SON functions.

[0169] Additionally, the gNB-CU sends a message M8 to the Near-RT RIC. The message M8 includes a SON Coordination request to manage coordinated handling of one or more SON functions (e.g., setup, update, release, pause, resume, etc.). The one or more SON functions determine / perform actions and / or change / adjust configuration parameters that affect the gNB-CU and / or the one or more gNB-DUs controlled by the gNB-CU. In some embodiments, the SON Coordination request includes coordination information associated with the one or more SON functions.

[0170] The Near-RT RIC receives the message M8 from the gNB-CU. In response, the Near-RT RIC transmits a message M9 to the gNB-CU. The message M9 acknowledges the SON Coordination request. In some embodiments, the acknowledgement indicates whether the Near-RT RIC accepts or rejects the SON Coordination request. If the Near- RT RIC accepts the SON Coordination request, then the Near RT-RIC performs (or refrains from performing) SON functions in accordance with the information specified in the SON Coordination request.

[0171] In some embodiment, the message M7 and / or the message M14 and / or the message M9 indicates a partial acknowledgement (or partial success). For example, themessage M7 and / or message M14 and / or message M9 could explicitly indicate one or more SON functions for which coordination is not accepted. Additionally, the message M7 and / or message M14 and / or message M9 could, either explicitly or implicitly, indicate that coordination of one or more other SON functions is accepted. For example, by including a list of SON functions for which SON coordination was not accepted (rejected), the message M7 and / or message M14 and / or message M9 could implicitly indicate that SON coordination was accepted for the remaining (requested in message M6 and unlisted in message M7 and / or requested in message M13 and unlisted in message M14 and / or requested in message M8 and unlisted in message M9) SON functions.3GPP Initiated SON Coordination Procedure - Scenario 2F

[0172] In Scenario 2F, the coordination is also initiated from a network node that is compliant with the second communication standard. In some embodiments, the second communication standard is 3GPP and the network node that is initiating the coordination is a gNB-CU. Additionally, in some embodiments, the first communication standard is O- RAN.

[0173] Figure 8F illustrates an example flow diagram for a SON coordination procedure initiated by a 3GPP network node, according to some other embodiments. In particular, Figure 8F illustrates operations performed by Network Nodes A, B, and C for Scenario 2F. In Figure 8F, Network Node A is a Near-RT RIC, Network Node B is a gNB- CU, and Network Node C is a gNB-DU. Although the steps (messages) are shown in an order, in various embodiments, the steps can be performed in a different order and / or in parallel.

[0174] As shown in Figure 8F, Scenario 2F is similar to Scenario 2E, except that before executing the steps described above for Scenario 2E, the Near-RT RIC sends a message M12 to network node(s) B and / or C (e.g., to the gNB-CU and / or one or more of the gNB- DUs controlled by the gNB-CU).

[0175] The message M12 publishes / indicates / notifies network node(s) B and / or C of one or more SON functions for which a coordinated handling is relevant (e.g., allowed, possible, and / or desirable by the node that is transmitting the message). In some embodiments, the one or more SON functions indicated in the message Ml 2 are the SON functions specified in the SON coordination request message(s) (e.g., message M6 / M8 / M13). That is, a network node transmits a SON coordination request for the SON functions where network node A has indicated that coordinated handling is relevant.

[0176] In some embodiments, the message M12 is preceded by a message M16 that is used by network node(s) B and / or C to request / query which SON function(s) are relevant for coordinated handling. In such cases, the network node(s) transmit the message Ml 6 to network node A. In response to receiving the message Ml 6, network node A transmits the message M12 to network node(s) B and / or C, whichever the case may be.3GPP Initiated SON Coordination Procedure - Scenario 2G

[0177] In Scenario 2G, the coordination is also initiated from a network node that is compliant with the second communication standard. In some embodiments, the second communication standard is 3GPP and the network node that is initiating the coordination is a E2 node (e.g., gNB-CU or gNB-DU). Additionally, in some embodiments, the first communication standard is O-RAN.

[0178] In some embodiments, the procedure is initiated by the gNB-CU. The gNB- CU triggers a SON Coordination procedure towards the Near-RT RIC. Optionally, in response to the gNB-CU triggering the SON Coordination procedure, the Near-RT RIC triggers a SON Coordination procedure towards the one or more gNB-DUs controlled by the gNB-CU.

[0179] Figure 8G illustrates an example flow diagram for a SON coordination procedure initiated by a 3GPP network node, according to some other embodiments. In particular, Figure 8G illustrates operations performed by Network Nodes A, B, and C for Scenario 2G. In Figure 8G, Network Node A is a Near-RT RIC, Network Node B is a gNB-CU, and Network Node C is a gNB-DU. Although the steps (messages) are shown in an order, in various embodiments, the steps can be performed in a different order and / or in parallel.

[0180] As shown in Figure 8G, the gNB-CU sends a message M8 to the Near-RT RIC. The message M8 includes a SON Coordination request to manage coordinated handling of one or more SON functions (e.g., setup, update, release, pause, resume, etc.). The one or more SON functions determine / perform actions and / or change / adjust configuration parameters that affect the gNB-CU. In some embodiments, the SON Coordination request includes coordination information associated with the one or more SON functions.

[0181] The Near-RT RIC receives the message M8 from the gNB-CU. In response, the Near-RT RIC transmits a message M9 to the gNB-CU. The message M9 acknowledges the SON Coordination request. In some embodiments, the acknowledgement indicates whether the Near-RT RIC accepts or rejects the SON Coordination request. If the Near-RT RIC accepts the SON Coordination request, then the Near RT-RIC performs (or refrains from performing) SON functions in accordance with the information specified in the SON Coordination request.

[0182] Additionally, as shown in Figure 8G, the Near-RT RIC sends to one or more of the gNB-DUs controlled by the gNB-CU a message M3. A message M3 includes a SON Coordination request to manage coordinated handling of one or more SON functions (e.g., setup, update, release, pause, resume, etc.). The one or more SON functions determine / perform actions and / or change / adjust configuration parameters that affect the gNB-DU. In some embodiments, similar to message Ml, the message M3 includes coordination information associated with the one or more SON functions. In some embodiments, the Near-RT RIC sends one or more messages M3 in response to receiving the message M8 from the gNB-CU.

[0183] A gNB-DU receives the message M3 from the Near-RT RIC. In response, the gNB-CU transmits a message M4 to the Near-RT RIC. The message M4 acknowledges the SON Coordination request. In some embodiments, the acknowledgement indicates whether the gNB-DU accepts or rejects the SON Coordination request.

[0184] In some embodiment, the message M9 and / or the message M4 indicates a partial acknowledgement (or partial success). For example, the message M9 and / or message M4 could explicitly indicate one or more SON functions for which coordination is not accepted. Additionally, the message M9 and / or message M4 could, either explicitly or implicitly, indicate that coordination of one or more other SON functions is accepted. For example, by including a list of SON functions for which SON coordination was not accepted (rejected), the message M9 and / or message M4 could implicitly indicate that SON coordination was accepted for the remaining (requested in message M8 and unlisted in message M9 and / or requested in message M3 and unlisted in message M4) SON functions.

[0185] In some embodiments, if the Near-RT RIC does not accept SON coordination for any of the SON functions, then the Near-RT RIC sends a message (e.g., as part of message M9, instead of the message M9, or in addition to the message M9) indicating that it rejects the SON Coordination request for all SON functions.

[0186] In some embodiments, if the gNB-DU does not accept SON coordination for any of the SON functions, then the gNB-DU sends a message (e.g., as part of message M4, instead of the message M4, or in addition to the message M4) indicating that it rejects the SON Coordination request for all SON functions.3GPP Initiated SON Coordination Procedure - Scenario 2H

[0187] In Scenario 2H, the coordination is also initiated from a network node that is compliant with the second communication standard. In some embodiments, the second communication standard is 3GPP and the network node that is initiating the coordination is a E2 node (e.g., gNB-CU or gNB-DU). Additionally, in some embodiments, the first communication standard is O-RAN.

[0188] Figure 8H illustrates an example flow diagram for a SON coordination procedure initiated by a 3GPP network node, according to some other embodiments. In particular, Figure 8H illustrates operations performed by Network Nodes A, B, and C for Scenario 2H. In Figure 8H, Network Node A is a Near-RT RIC, Network Node B is a gNB-CU, and Network Node C is a gNB-DU. Although the steps (messages) are shown in an order, in various embodiments, the steps can be performed in a different order and / or in parallel.

[0189] As shown in Figure 8H, Scenario 2H is similar to Scenario 2G, except that before executing the steps described above for Scenario 2G, the Near-RT RIC sends a message M12 to network node(s) B and / or C (e.g., to the gNB-CU and / or one or more of the gNB-DUs controlled by the gNB-CU).

[0190] The message M12 publishes / indicates / notifies the network node(s) of one or more SON functions for which a coordinated handling is relevant (e.g., allowed, possible, and / or desirable by the node that is transmitting the message). In some embodiments, the one or more SON functions indicated in the message M12 are the SON functions specified in the SON coordination request message M8 / M3. That is, a network node transmits a SON coordination request for the SON functions where network node A has indicated that coordinated handling is relevant.

[0191] In some embodiments, the message M12 is preceded by a message M16 that is used by network node(s) B and / or C to request / query which SON function(s) are relevant for coordinated handling. In such cases, the network node(s) transmit the message Ml 6 to network node A. In response to receiving the message Ml 6, network node A transmits the message M12 to the network node(s) B and / or C, whichever the case may be.3GPP Initiated SON Coordination Procedure - Scenario 21

[0192] In Scenario 21, the coordination is also initiated from a network node that is compliant with the second communication standard. In some embodiments, the secondcommunication standard is 3GPP and the network node that is initiating the coordination is a E2 node (e.g., gNB-CU or gNB-DU). Additionally, in some embodiments, the first communication standard is O-RAN.

[0193] In some embodiments, the procedure is initiated by a gNB-DU. The gNB-DU triggers a SON Coordination procedure towards the Near-RT RIC. In some embodiments, the gNB-DU also triggers a SON Coordination procedure towards the gNB-CU that controlls the gNB-DU. In some embodiments, in response to the gNB-DU triggering the SON Coordination procedure, the Near-RT RIC triggers a SON Coordination procedure towards the gNB-CU controlling the gNB-DU.

[0194] Figure 81 illustrates an example flow diagram for a SON coordination procedure initiated by a 3GPP network node, according to some other embodiments. In particular, Figure 81 illustrates operations performed by Network Nodes A, B, and C for Scenario 21. In Figure 81, Network Node A is a Near-RT RIC, Network Node B is a gNB- CU, and Network Node C is a gNB-DU. Although the steps (messages) are shown in an order, in various embodiments, the steps can be performed in a different order and / or in parallel.

[0195] As shown in Figure 81, a gNB-DU controlled by the gNB-CU sends the Near- RT RIC a message MIO. A message MIO includes a SON Coordination request to manage coordinated handling of one or more SON functions (e.g., setup, update, release, pause, resume, etc.). The one or more SON functions determine / perform actions and / or change / adjust configuration parameters that affect the gNB-DU. In some embodiments, the message MIO includes coordination information associated with the one or more SON functions.

[0196] The Near-RT RIC receives a message M10 from the gNB-DUs. In response, the Near-RT RIC transmits a corresponding message Ml 1 to the gNB-DUs. The message Mi l acknowledges the SON Coordination request. In some embodiments, the acknowledgement indicates whether the Near-RT RIC accepts the SON Coordination request. If the Near-RT RIC accepts the SON Coordination request, then the Near-RT RIC performs (or refrains from performing) SON functions in accordance with the information specified in the SON Coordination request.

[0197] As shown in Figure 81, in some embodiments, the gNB-DU also initiates a SON Coordination Procedure towards the controlling gNB-CU by transmitting a message Ml 3. A message Ml 3 includes a SON Coordination request to manage coordinated handling ofthe one or more SON functions The gNB-CU responds / acknowledges the SON Coordination request by transmitting a message M14.

[0198] In some embodiment, the message Mi l and / or the message M14 indicates a partial acknowledgement (or partial success). For example, the message Mi l and / or message M14 could explicitly indicate one or more SON functions for which coordination is not accepted. Additionally, the message Mi l and / or message M14 could, either explicitly or implicitly, indicate that coordination of one or more other SON functions is accepted. For example, by including a list of SON functions for which SON coordination was not accepted (rejected), the message Mi l and / or message M14 could implicitly indicate that SON coordination was accepted for the remaining (requested in message MIO and unlisted in message Mi l and / or requested in message M13 and unlisted in message M14) SON functions.

[0199] In some embodiments, if the Near-RT RIC does not accept SON coordination for any of the SON functions, then the Near-RT RIC sends a message (e.g., as part of message Ml 1, instead of the message Ml 1, or in addition to the message Ml 1) indicating that it rejects the SON Coordination request for all SON functions.

[0200] In some embodiments, if the gNB-CU does not accept SON coordination for any of the SON functions, then the gNB-CU sends a message (e.g., as part of message M14, instead of the message M14, or in addition to the message M14) indicating that it rejects the SON Coordination request for all SON functions.

[0201] In other embodiments, the Near-RT RIC could initiate the SON Coordination Procedure towards the gNB-CU in response to receiving the message M10.

[0202] In some embodiments, the content of the message M10 is the same as the content of the message Ml 3. Similarly, in some embodiments, the content of the message Mi l is the same as the content of the message Ml 4.

[0203] In some embodiment, both message M10 and message M13 (and similarly both message Mi l and message Ml 4) are used for coordination of a certain SON function, and the content of message M10 is different from the content of message Ml 3 (and similarly the content of message Ml 1 is different from the content of message Ml 4). For example, a SON function (e.g., CCO) requires the coordination of certain parameters and / or actions between the Near-RT RIC and the gNB-CU, and the coordination of other parameters and / or actions between the Near-RT RIC and the gNB-DU.3GPP Initiated SON Coordination - Scenario 2J

[0204] In Scenario 2J, the coordination is also initiated from a network node that is compliant with the second communication standard. In some embodiments, the second communication standard is 3GPP and the network node that is initiating the coordination is a gNB-DU. Additionally, in some embodiments, the first communication standard is O- RAN.

[0205] Figure 8J illustrates an example flow diagram for a SON coordination procedure initiated by a 3GPP network node, according to some other embodiments. In particular, Figure 8J illustrates operations performed by Network Nodes A, B, and C for Scenario 2J. In Figure 8J, Network Node A is a Near-RT RIC, Network Node B is a gNB- CU, and Network Node C is a gNB-DU. Although the steps (messages) are shown in an order, in various embodiments, the steps can be performed in a different order and / or in parallel.

[0206] As shown in Figure 8J, Scenario 2J is similar to Scenario 21, except that before executing the steps described above for Scenario 2E, the Near-RT RIC sends a message M12 to network node(s) B and / or C (e.g., to the gNB-CU and / or one or more of the gNB- DUs controlled by the gNB-CU).

[0207] The message M12 publishes / indicates / notifies the network node(s) of one or more SON functions for which a coordinated handling is relevant (e.g., allowed, possible, and / or desirable by the node that is transmitting the message). In some embodiments, the one or more SON functions indicated in the message M12 are the SON functions specified in the SON coordination request message(s) (e.g., message M10 / M13). That is, a network node transmits a SON coordination request for the SON functions where network node A has indicated that coordinated handling is relevant.

[0208] In some embodiments, the message M12 is preceded by a message M16 that is used by the network node(s) B and / or C to request / query which SON function(s) are relevant for coordinated handling. In such cases, the network node(s) transmit the message Ml 6 to network node A. In response to receiving the message Ml 6, network node A transmits the message M12 to the network node(s) B and / or C, whichever the case may be.Message Content DetailsMessage Ml

[0209] The message Ml is used to convey signaling elements to initiate an operation for managing in a coordinated manner SON functions among at least two network nodes compliant with two different communication systems.

[0210] The message Ml can include one or more of the following elements:• A request to setup / update / release / pause / resume of coordination for at least one SON function among at least two network nodes compliant with two different communication systems (e.g., one compliant with O-RAN, one compliant with 3 GPP)• Identifier(s) of one or more SON function(s)• Identifier(s) of a node initiating the procedure (e.g., a Near-RT RIC Identity)• Identifier(s) of a node terminating the procedure (e.g., a gNB-CU-ID or a gNB-DU)• A request that a certain network node (e.g., the network node sending the message) takes precedence in decision / actions and / or parameter setting related to the management of a specific SON function (or SON functions in general). This can be explicit or implicit (e.g., the sending of Ml can be used as an implicit indication that the sender wants to take precedence)• Identifier of the network node (e.g., a gNB-CU-ID, or a gNB-DU-ID, or Near-RT RIC Identity) and / or communication system (e.g., O-RAN, or 3GPP) and / or network node type (e.g., gNB-CU, or gNB-DU, or Near-RT RIC) which takes precedence in decisions / actions and / or parameter setting related to the management of a specific SON function (or SON functions in general)• An E2AP Identifier associated to a Near-RT RIC• An E2AP Identifier associated to a gNB-CU• An E2AP Identifier associated to a gNB-DU• An E2AP Identifier associated to a gNB• One or more level of granularity to which the coordination (and / or the SON function) can refer to (e.g., cluster of nodes, node, gNB-CU, gNB-DU, cell, beam, UE, DRB, QoS flow, PDU Session, PDU Set, network slice, set of network slices, etc.)• Identifiers of one or more ues or group of ues associated to the SON function• Action(s) pertaining to a certain SON function (e.g., CCO issue detection, CCO issue resolution, mobility setting change, mobility load balancing, RACH resource optimization, etc.) That are subject to coordination• An identifier of an action pertaining to a certain SON function• Policies related to a certain SON function (e.g., targets to be achieved)• Allowed ranges for configuration parameters• A list of information requested as feedback to assess the outcome of the SON function (e.g., UE performance, cell level performance, etc.)• Timing information, e.g., indication of a reference time scale / interval related to the execution of the SON function (e.g., seconds, tenth of seconds, minutes, etc), or a reference time scale / interval related to the collection of feedback for the SON function• Radio configuration related information, e.g., a range of possible values for configuration parameter “X” used in SON function “A” (as an example, “X” could be an elevation angle, or an azimuth, or a cell individual offset, while “A” could be “CCO”, or “MLB”, or “MRO”)Message M2

[0211] The message M2 is used to convey signaling elements to confirm / accept (or refuse) an operation for managing in a coordinated manner SON functions among two or more network nodes that are compliant with two different communication standards.

[0212] The message M2 can include one or more of the following elements:• Identifier(s) of one or more SON function(s) associated with the request of coordination received in Ml• An outcome of the request (e.g., acknowledge, refuse)• Identifier(s) of a node initiating the procedure (e.g., a gNB-CU-ID)• Identifier(s) of a node terminating the procedure (e.g., a Near-RT RIC Identity)• Identifier of the network node (e.g., a gNB-CU-ID, or a gNB-DU-ID, or Near-RT RIC Identity) and / or communication system (e.g., O-RAN, or 3GPP) and / or network node type (e.g., gNB-CU, or gNB-DU, or Near-RT RIC) which takes precedence in decisions / actions and / or parameter setting related to the management of a specific SON function (or SON functions in general)• A response confirming which network node is the one that takes precedence in decision / actions and / or parameter setting related to the management of a specific SON function (or SON functions in general). This can be explicit or implicit (e.g., the sending of Ml can be used as an implicit indication that the sender of M2 accepts that the network node indicated in the request in Ml is the one who takes precedence)• An E2AP Identifier associated to a Near-RT RIC• An E2AP Identifier associated to a gNB-CU• An E2AP Identifier associated to a gNB-DU• One or more level of granularity to which the coordination is accepted or refused (e.g., cluster of nodes, node, gNB-CU, gNB-DU, cell, beam, UE, DRB, QoS flow, PDU Session, PDU Set, etc.)• A list of information that can be provided (or not provided) as feedback to assess the outcome of the SON function (e.g., UE performance, cell level performance, etc.)• An identifier of an action pertaining to a certain SON function• An indication, e.g., a cause value, indicating the reason for failing the requestMessage M3

[0213] The message M3 has the same purpose of message Ml and the content of the two messages can be the same. The two messages are introduced to take into account the differences in the logical architecture between the two communication systems between which the procedure is executed.

[0214] In particular, Ml is between a network node of a first communication system using a first communication standard and a network node of a second communication system using a second communication standard, where no parent (controlling) node isdefined for the network node of the second communication system (e.g., between a Network Node A and a Network Node B). In contrast, M3 is between a network node of the first communication system and a network node of the second communication system that has one parent (controlling) node (e.g., between a Network Node A and a Network Node C).

[0215] From an architectural point of view, a network node B can control several network nodes C, but a given network node C is only controlled by one (single) network node B. Therefore, in Scenario 1A above, to achieve coordination for a RAN node comprising one network node B and N network nodes C, only one Ml message is needed, while A M3 messages are needed.Message M4

[0216] The message M4 has the same purpose of message M2 and the content of the two messages can be the same. As for Ml and M3, the two messages are introduced to take into account the differences in the logical architecture between the two communication systems (different communication standards) between which the procedure is executed.Message M5

[0217] The message M5 has the purpose to notify (or publish, or indicate) that a network node compliant with the second communication standard (e.g., in a second communication system) is available / allows / willing to perform management of SON functions in coordination with a node compliant with the first communication standard (e.g., in a first communication system).

[0218] The message M5 can comprise one or more of the following elements:• Identifier(s) of one or more SON function(s)■ Identifier(s) of a node initiating the procedure■ Identifier(s) of a node terminating the procedure■ Identifier of the node responsible for the coordination of a specific SON function■ An E2AP Identifier associated to a Near-RT RIC■ An E2AP Identifier associated to a gnb-CU■ An E2AP Identifier associated to a gnb-DU■ One or more level of granularity to which the coordination can refer to (e.g., cluster of nodes, node, gNB-CU, gNB-DU, cell, beam, UE, DRB,QoS flow, PDU Session, PDU Set, network slice, set of network slices, etc.)Message M6

[0219] The message M6 has the same purpose of message Ml and the content of the two messages can be the same. Apart from that, the difference between the two messages is in the signaling protocol used for their implementation. For instance, Ml is implemented as an E2AP message, M6 as an Fl AP message.Message M7

[0220] The message M7 has the same purpose of message M2 and the content of the two messages can be the same. Apart from that, the difference between the two is in the signaling protocol used for their implementation. For instance, M2 is implemented as an E2AP message, M7 as an F1AP message.Message M8

[0221] The message M8 has the same purpose of message Ml and the content of the two messages can be the same. The two messages are introduced to take into account the differences in the logical architecture between the two communication systems (different communication standards) between which the procedure is executed.Message M9

[0222] The message M9 has the same purpose of message M2 and the content of the two messages can be the same. The two messages are introduced to take into account the differences in the logical architecture between the two communication systems (different communication standards) between which the procedure is executed.Message Ml 0

[0223] The message M10 has the same purpose of message M8 and the content of the two messages can be the same. The two messages are introduced to take into account the differences in the logical architecture between the two communication systems (using different communication standards) between which the procedure is executed.

[0224] In particular, M8 is between a network node of a first communication system using a first communication standard and a network node of a second communicationsystem using a second communication standard, where no parent (controlling) node is defined for the network node of the second communication system (e.g., between a Network Node A and a Network Node B). In contrast, 10 is between a network node of the first communication system and a network node of the second communication system that has one parent (controlling) node (e.g., between a Network Node A and a Network Node C).

[0225] From an architectural point of view, a network node B can control several network nodes C, but a given network node C is only controlled by one (single) network node B. Therefore, in Scenario 2 A above, to achieve coordination for a RAN node comprising one network node B and N network nodes C, only one M8 message is needed, while 7VM10 messages are needed.Message Mil

[0226] The message Ml 1 has the same purpose of message M9 and the content of the two messages can be the same.Message M12

[0227] The message M12 has the purpose to notify (or publish, or indicate) that a node of compliant with the first communication standard (e.g., in a first communication system) is available / allows / willing to perform management of SON functions in coordination with a node compliant with the second communication standard (e.g., in a second communication system). The content of M12 can be the same as the content of message M5.Message Ml 3

[0228] The message Ml 3 has the same purpose of message M6 and the content of the two messages can be the same. The difference between the two is that M6 is sent from a network node B to a network node C, while M13 is sent in the opposite direction (i.e., from network node C to network node B).Message Ml 4

[0229] The message M14 has the same purpose of message M7 and the content of the two messages can be the same. The difference between the two is that M7 is sent from anetwork node C to a network node B, while M14 is sent in the opposite direction (i.e., from network node B to network node C).Message Ml 5

[0230] The message Ml 5 has the purpose to query / request a network node in order to retrieve a list of one or more SON functions for which coordination between network nodes compliant with two different communication standards (e.g., O-RAN and 3GPP) is available / allowed / enabled / desirable.

[0231] The message Ml 5 can comprise one or more of:• Identity(ies) of one or more network nodes (e.g., a gNB-CU ID, a gNB- DU ID, a Near-RT RIC ID)• Identity(ies) of one or more SON function(s)• Identity(ies) of one or more actions related to SON functions that can be subject to coordination• One or more parameters (and / or range of parameters) related to a certain SON function that can be subject to coordination.Message Ml 6

[0232] The message M16 has the same purpose of message M15 and the content of the two messages can be the same. The difference between the two is that the two messages are sent in opposite directions. That is, message Ml 5 is sent from a network node A to a network node C (e.g., Near-RT RIC to a gNB-DU), and message M16 is sent from a network node C to a network node A (e.g., gNB-DU to Near-RT RIC).Method Overview

[0233] Figure 9 illustrates an example method 900 performed by a network node for coordinating SON functions in a heterogenous network, according to various embodiments. The method includes, at a step 910, transmitting, from a first network node to a second network node, a first message that includes a request or indication to coordinate handling of one or more SON functions. In some embodiments, the first network node is compliant with a first communication standard and the second network node is compliant with a second communication standard. In some embodiments, the first network node and thesecond network node are compliant with a same communication standard, but the first network node is of a first node type and the second network node is of a second node type.

[0234] In some embodiments, the request or the indication indicates at least one of which network node included in the heterogenous communication system should handle the one or more SON functions, which network node included in the heterogenous communication system has precedence for the one or more SON functions, or an order of precedence for network nodes to handle the one or more SON functions.

[0235] In some embodiments, prior to transmission of the first message, the first network node receives an indication of one or more relevant SON functions that should be coordinated. Alternately, in some embodiments, prior to transmission of the first message, the first network node transmits to the second network node an indication of the one or more relevant SON functions. The one or more SON functions associated with the first message comprise the one or more relevant SON functions.

[0236] The method 900 further includes, at a step 920, receiving, at the first network node and from the second network node, a second message that indicates whether the second network node agrees to the request to coordinate handling of the one or more SON functions.

[0237] In various embodiments, the first network node can repeat the method 900 with one or more additional network nodes. For example, the first network node could transmit a second request or indication to coordinate SON functions to a third network node. The SON functions associated with the second request or indication could be the same SON functions as the first request or indication, include some or all of the SON functions associated with the first request (e.g., a subset or superset), or could be a different set of SON functions than the SON functions associated with the first request (i.e., no common SON functions).

[0238] In various embodiments, the first network node can cause the second network node to transmit or forward the first request or indication to the third network node (e.g., by transmitting a third message that includes the first request or indication). In some embodiments, for such cases, the third network node could be a network node that is controlled by the second network node.

[0239] In various embodiments, the first network node can also receive requests or indications from other network nodes. For example, the first network node could receive a third message that includes a second request or indication to coordinate SON functions from a third network node.

[0240] Figure 10 illustrates an example method 1000 performed by a network node for coordinating SON functions in a heterogenous network, according to various embodiments. The method includes, at a step 1010, receiving, at a first network node and from a second network node, a first message that includes a request or an indication to coordinate handling of one or more SON functions. In some embodiments, the first network node is compliant with a first communication standard and the second network node is compliant with a second communication standard. In some embodiments, the first network node and the second network node are compliant with a same communication standard, but the first network node is of a first node type and the second network node is of a second node type.

[0241] In some embodiments, the request or the indication indicates at least one of which network node included in the heterogenous communication system should handle the one or more SON functions, which network node included in the heterogenous communication system has precedence for the one or more SON functions, or an order of precedence for network nodes to handle the one or more SON functions

[0242] In some embodiments, prior to transmission of the first message, the first network node receives an indication of one or more relevant SON functions for the SON coordination procedure. Alternately, in some embodiments, prior to transmission of the first message, the first network node transmits to the second network node an indication of one or more relevant SON functions that should be coordinated. The one or more SON functions associated with the first message comprise the one or more relevant SON functions.

[0243] The method 1000 further includes, at a step 1020, transmitting, from the first network node to the second network node, a second message that indicates whether the first network node agrees to the request to coordinate handling of the one or more SON functions.

[0244] In various embodiments, the first network node can repeat the method 1000 with one or more additional network nodes. For example, the first network node could receive a second request or indication to coordinate SON functions from a third network node. The SON functions associated with the second request or indication could be the same SON functions as the first request or indication, include some or all of the SON functions associated with the first request (e.g., a subset or superset), or could be a different set of SON functions than the SON functions associated with the first request (i.e., no common SON functions).

[0245] In various embodiments, the first network node can also transmit requests or indications to other network nodes. For example, the first network node could transmit a third message that includes a second request or indication to coordinate SON functions to a third network node. In response, the first network node would receive a fourth message indicating whether the third network node agrees to the second request. The SON functions associated with the second request or indication could be the same SON functions as the first request or indication, include some or all of the SON functions associated with the first request (e.g., a subset or superset), or could be a different set of SON functions than the SON functions associated with the first request (i.e., no common SON functions). As another example, the first network node could transmit or forward the first request or indication to the third network node (e.g., by including the first request or indication in a third message).Further Extensions of the Methods

[0246] In some embodiments, messages used to realize SON coordination between O- RAN and 3 GPP can be exchanged among network nodes other than the ones mentioned above (gNB-DU, gNB-CU, Near-RT RIC). Non-limiting examples of messages for SON coordination between O-RAN and 3GPP that can be exchanged include:• Between a gNB-CU-CP and a gNB-CU-UP• Between a gNB-DU and a gNB-CU-UP,• Between a gNB-CU-UP and Near-RT RIC,• Between two gNB-DUs,• Between two gNB-CU-UPs.

[0247] In some embodiments, different variations in the sequence of procedures (compared to those described above) can be used to realize the SON coordination between O-RAN and 3GPP. Non-limiting examples of variations in the sequence of procedures include:• A first SON coordination procedure between gNB-CU-CP and a gNB-CU- UP, followed by a second SON coordination procedure between the gNB- CU-CP and the Near-RT RIC (or in the reverse order)• A first SON coordination procedure between a gNB-CU-CP and a gNB- CU-DU, followed by a second SON coordination procedure between the gNB-CU-CP and a gNB-CU-UP, followed by a third SON coordinationprocedure between the gNB-CU-CP and a Near-RT RIC (or other combination of the above in a different order)

[0248] In the examples described above, the network node that is initiating the SON coordination procedure transmits a request (e.g., in Message Ml) to the receiving node. In such embodiments, the receiving node transmits a response (e.g., acknowledgement Message M2) to the initiating node. However, in other embodiments, the network node that is initiating the SON coordination procedure transmits a notification or indication to the receiving node (rather than a request). That is, step 620 shown in Figure 6 comprises a SON coordination procedure consisting of a single message comprising one or more notifications or indications or commands, rather than a SON coordination procedure consisting of two messages comprising a request and a response. In such cases, the initiating node does not expect a response / acknowledgement / failure, and the node that receives the one or more notification(s) / indication(s) / command(s) does not transmit a message containing an acknowledgement / response / failure to the initiating node.

[0249] In some embodiments, a given network node indicates to or notifies one or more other network nodes that the given node will be responsible for SON coordination. In response to receiving the indication(s) / notification(s) / command(s), the one or more other network nodes defer to the given node for SON function(s) specified in the indication(s) / notification(s) / command(s). As an example, assume a heterogenous communication system, or a portion thereof, is configured such that if a certain node (e.g., a Near RT-RIC) is involved in a given SON feature, then the node is the de-facto controller (or the ‘master’, or the node whose decisions / actions / setting takes precedence over decisions / actions / settings of other nodes) for the given SON feature (e.g., it is clear that priority / conflict resolution / etc. can only be done by the Near RT-RIC). When the SON coordination step is performed, the node simply notifies the other nodes that it is responsible for coordination.

[0250] Referring to the example described above with respect to Figure 7A and Scenario 1A, assume network node A is assuming responsibility for coordinating a given SON function. Network node A transmits a message Ml that includes a notification / indication / command (rather than a request) that coordination of the given SON function will be handled by network node A. Network node B receives the message Ml, but does not transmit a message M2 back to network node A. Similarly, network node A could transmit a message M3 to network node C, where the message M3 includes an indication / notification / command that coordination of the given SON function will behandled by network node A. Additionally or alternately, the message M3 could include an indication / notification / command that decisions for network nodes C need to be confirmed by a network node B (or vice versa). In such cases, the network node C also does not transmit a message M4 in response.

[0251] Similar approaches could also be applied to other messages / response pairings shown above (e.g., M6 / M7, M8 / M9, M10 / M11, etc.).Implementation Examples

[0252] Examples of implementation for the messages and procedures described in the solution are presented herein. The messages carrying the services included in the E2 Service Model mentioned below (INSERT, CONTROL, QUERY) can be one or more of the messages Ml through M16 described above.

[0253] As shown below, the implementation of the disclosed messages and procedures can include modifications / extensions to the different communication standards (e.g., O- RAN and 3GPP). Although specific modifications are described herein, those skilled in the art will understand that different / al ternate modifications / extensions could be used to implement the same functionality.Extensions to the E2 Service Model

[0254] In the following example, the INSERT service support as defined in Section 6.2.2 of the O-RAN TS “E2 Service Model (E2SM), RAN Control” is extended to request the Near-RT RIC to control SON functionalities. A modification of the O-RAN TS is shown below to illustrate the extension. The (New) designation notes the elements that are newly added by this example.6.2.2 INSERT serviceThe “RAN Control” RAN Function provides selective support of the following INSERT services:Fundamental level:Radio Bearer Control request, used for requesting the RIC to control DRB QoS modification, QoS flow to DRB (re)mapping, Logical channel(re)configuration, Radio bearer admission control, Split bearer and PDCP duplication control, etc.• Radio Resource Allocation Control request, used for requesting the RIC to control Discontinuous Reception (DRX), Scheduling request (SR), Semi- Persistent Scheduling (SPS), Configured Grant, Channel Quality Indicator (CQI) table, Slice level PRB quota, etc.• Connected Mode Mobility Control request, used for requesting the RIC to control operations of Handover (HO), Conditional handover (CHO), Dual Active Protocol Stack (DAPS) HO, etc.• Radio Access Control request, used for requesting the RIC to control parameters related to RACH back-off, RRC connection reject, RRC connection release, Access barring, UE admission, etc.• Dual Connectivity (DC) Control request, used for requesting the RIC to control operations of Dual Connectivity (DC) including Change of bearer termination point (MN or SN) and / or bearer types, etc.• Carrier Aggregation (CA) Control request, used for requesting the RIC to control operations of Carrier Aggregation (CA) involving secondary cell re-selection.• Idle Mode Mobility Control request, used for requesting the RIC to control intra-frequency, inter-frequency, inter-RAT cell reselection priority, idle timers, etc.• (New) Coverage and Capacity Optimization, CCO, Control request, used for requesting the RIC to control configuration of cells and / or SSB beams.• (New) Mobility Load Balancing, MLB, Control request, used for requesting the RIC to control steering of traffic among cells.• (New) RACH Optimization, RO, Control request, used for requesting the RIC to control Random Access configuration for cells.Integrated level:• Multiple Actions Control request, used for requesting the RIC to command multiple actions of the selected fundamental level INSERT services.

[0255] As shown above, the INSERT service can be extended to include CCO control request, MLB control request, and RO control request in order to support the disclosed techniques.

[0256] In the following example, the CONTROL service support as defined in Section 6.2.3 of the 0-RAN TS “E2 Service Model (E2SM), RAN Control” is extended to be used by the Near-RT RIC to control SON functionalities. A modification of the 0-RAN TS is shown below to illustrate the extension. The (New) designation notes the elements that are newly added by this example.6.2.3 CONTROL serviceThe “RAN Control” RAN Function provides selective support of the following CONTROL services:Fundamental level:• Radio Bearer Control, used for DRB QoS modification, QoS flow to DRB (re)mapping, Logical channel (re)configuration, Radio bearer admission control, Split bearer and PDCP duplication control, etc.• Radio Resource Allocation Control, used to control Discontinuous Reception (DRX), Scheduling request (SR), Semi-Persistent Scheduling (SPS), Configured Grant, Channel Quality Indicator (CQI) table, Slice level PRB quota, etc.• Connected Mode Mobility Control, used to control operations of Handover (HO), Conditional handover (CHO), Dual Active Protocol Stack (DAPS) HO, etc.• Radio Access Control, used for modification of RACH back-off, RRC connection reject, RRC connection release, Access barring, UE admission, etc.• Dual Connectivity (DC) Control, used to control operations of Dual Connectivity (DC) including Change of bearer termination point (MN or SN) and / or bearer types, etc.• Carrier Aggregation (CA) Control, used to control operations of Carrier Aggregation (CA).• Idle Mode Mobility Control, used for modification of intra-frequency, inter-frequency, inter-RAT cell reselection priority, idle timers, etc.• UE identification, information and assignment: used to assign UE to RAN UE group, to obtain information on UE, and to complete UE identification based on partial information.• Measurement Report (MR) Configuration Control, used to control configuration of RRC measurement objects, reporting objects, etc.• (New) Coverage and Capacity Optimization, CCO, Control, used to control cells and / or SSB beams coverage configuration to address CCO issues (detected or predicted).• (New) Mobility Load Balancing, MLB, Control, used to control traffic steering among cells.• (New) Mobility Robustness Optimization, MRO Control, used to control self-optimization of mobility trigger points for cells.Integrated level:• Multiple Actions Control, used to command multiple actions of the selected fundamental level CONTROL services in one message.

[0257] As shown above, the CONTROL service can be extended to include CCO control, MLB control, and RO control in order to support the disclosed techniques.

[0258] In the following example of implementation, the CONTROL service description (in the 0-RAN TS) is extended to indicate the ability of RIC to control SON functionality for CCO.6.5 CONTROL service descriptionThe E2SM-RC CONTROL service requirements defined in Clause 6.2.3 are offered using a set of CONTROL Styles. Each style corresponds to a set of “CONTROL Action”, where each “CONTROL Action” deals with a specific functionality and has a set of associated RAN parameters, provided in a mapping table. All CONTROL Service styles are implemented using a set of IES constituting a “RIC Control Request Header” and a “RIC Control Request Message” to deliver RAN Control-related CONTROL services and the optional “RIC Control Outcome” to carry control process outcome information from theE2 Node. A “CONTROL Action” containing one or more RAN parameters and their associated values can either be sent from the RIC, either asynchronously to the E2 node or as a response to a previous “INSERT Indication” from the E2 node.Referring to the previous example in Clause 6.4, the RIC sends a “CONTROL action” that accepts / denies the incoming “INSERT Indication” requesting for “Handover Control”, along with the value of the “Target Primary Cell”. As another example, the RIC can also asynchronously send a “CONTROL action” asking the E2 node to configure the UE in Carrier Aggregation mode and setup one or more secondary cells to the UE, whose values are assigned by the RIC via the “CONTROL action”.(New) As another example, the RIC can also asynchronously send a “CONTROL action” asking the E2 node to modify the configuration of cells or beams of an E2 node to solve a CCO issue, whose values are assigned by the RIC via the “CONTROL action”.

[0259] As shown above, the CONTROL service description is extended to include an example of RIC performing a SON function, i.e., asking an E2 node to solve a CCO issue.

[0260] As a further example of implementation of E2SM, the supported RIC CONTROL services can be extended to indicate the ability of RIC to control SON functionalities for CCO, MLB, and RACH Optimization. A modification of the O-RAN TS is shown below to illustrate the extension.7.6 Supported RIC CONTROL Services7.6.1 CONTROL Service Style Types

[0261] As shown above, the RIC CONTROL service types are extended to include services types 11, 12, and 13 corresponding to CCO control, MLB control, and RO control, respectively, in support of the disclosed techniques.

[0262] Additionally, a possible implementation of CONTROL Service Style for SON functionality related to CCO is shown below. For the purpose of illustrating a clear example, assume the below description is an extension / addition to the 0-RAN TS and describes the new control types (11, 12, and 13) shown above.7.6.xx CONTROL Service Style 11 : SON - CCO Control 7.6.xx.l CONTROL Service Style descriptionThis CONTROL Service style provides a mechanism to recommend or mandate coverage configuration for cell and beams to address a detected / predicted CCO issue, using the RIC Control Message IE and the RIC Control Header IE.Applications of this service include: • Recommend a coverage configuration for cells and beams affected by a detected or CCO issue.• Recommend a coverage configuration for cells and beams predicted to be affected by a predicted CCO issue.The supported RAN control actions and the corresponding RAN parameters are as follows:

[0263] In the following example, the QUERY service support as defined in the O-RAN TS “E2 Service Model (E2SM), RAN Control” is extended to acquire information on SON related function to achieve coordination between the Near-RT RIC and E2 Nodes. A modification of the O-RAN TS is shown below to illustrate the extension. The (New) designation notes the elements that are newly added to the TS by this example.6.2.5 QUERY serviceThe “RAN Control” RAN Function provides support of the following QUERY services:E2 Node related Information retrieval between Near-RT RIC and E2 Node for any data required at Near-RT RICUE related Information retrieval between Near-RT RIC and E2 Node for any data required at Near-RT RIC(New) E2 Node SON function related information retrieval between Near-RT RIC and E2 Node for SON function coordination between Near-RT RIC and E2 Node.Extensions to the E2AP

[0264] An example of implementation of message Ml is proposed below, wherein the RIC Action Type IE within the RIC SUBSCRIPTION REQUEST E2AP message is extended with new value to indicate that the action requested by the Near-RT RIC concerns the coordination of SON functionality(ies) together with the E2 node. A modification of the O-RAN TS is shown below to illustrate the extension. The (New) designation notes the elements that are newly added by this example.9.1.1.1 RIC SUBSCRIPTION REQUESTThis message is sent by the Near-RT RIC to an E2 Node to create a new RIC Subscription in the E2 Node.Direction: Near-RT RICE2 Node.9.2.11 RIC Action TypeThis IE defines the type of RIC Service Action to be executed.Example Systems and Devices

[0265] Figure 11 shows an example of a communication system 1100 in accordance with some embodiments.

[0266] In the example, the communication system 1100 includes a telecommunication network 1102 that includes an access network 1104, such as a radio access network (RAN), and a core network 1106, which includes one or more core network nodes 1108. The access network 1104 includes one or more access network nodes, such as network nodes 1110a and 1110b (one or more of which may be generally referred to as network nodes 1110), or any other similar 3rdGeneration Partnership Project (3GPP) access nodes or non-3GPP access points. Moreover, as will be appreciated by those of skill in the art, a network node is not necessarily limited to an implementation in which a radio portion and a baseband portion are supplied and integrated by a single vendor. Thus, it will be understood that network nodes include disaggregated implementations or portions thereof. For example, insome embodiments, the telecommunication network 1102 includes one or more Open-RAN (O-RAN) network nodes. An O-RAN network node is a node in the telecommunication network 1102 that supports an O-RAN specification (e.g., a specification published by the O-RAN Alliance, or any similar organization) and may operate alone or together with other nodes to implement one or more functionalities of any node in the telecommunication network 1102, including one or more network nodes 1110 and / or core network nodes 1108.

[0267] Examples of an O-RAN network node include an open radio unit (O-RU), an open distributed unit (O-DU), an open central unit (O-CU), including an O-CU control plane (O-CU-CP) or an O-CU user plane (O-CU-UP), a RAN intelligent controller (near- real time or non-real time) hosting software or software plug-ins, such as a near-real time control application (e.g., xApp) or a non-real time control application (e.g., rApp), or any combination thereof (the adjective “open” designating support of an O-RAN specification). The network node may support a specification by, for example, supporting an interface defined by the O-RAN specification, such as an Al, Fl, Wl, El, E2, X2, Xn interface, an open fronthaul user plane interface, or an open fronthaul management plane interface. Moreover, an O-RAN access node may be a logical node in a physical node. Furthermore, an O-RAN network node may be implemented in a virtualization environment (described further below) in which one or more network functions are virtualized. For example, the virtualization environment may include an O-Cloud computing platform orchestrated by a Service Management and Orchestration Framework via an O-2 interface defined by the O- RAN Alliance or comparable technologies. The network nodes 1110 facilitate direct or indirect connection of user equipment (UE), such as by connecting UEs 1112a, 1112b, 1112c, and 1112d (one or more of which may be generally referred to as UEs 1112) to the core network 1106 over one or more wireless connections.

[0268] 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, the communication system 1100 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. The communication system 1100 may include and / or interface with any type of communication, telecommunication, data, cellular, radio network, and / or other similar type of system.

[0269] The UEs 1112 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and / or operable to communicate wirelessly with the network nodes 1110 and other communication devices. Similarly, the network nodes 1110 are arranged, capable, configured, and / or operable to communicate directly or indirectly with the UEs 1112 and / or with other network nodes or equipment in the telecommunication network 1102 to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as administration in the telecommunication network 1102.

[0270] In the depicted example, the core network 1106 connects the network nodes 1110 to one or more host computing systems, such as host 1116. 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. The core network 1106 includes one more core network nodes (e.g., core network node 1108) 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 1108. 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).

[0271] The host 1116 may be under the ownership or control of a service provider other than an operator or provider of the access network 1104 and / or the telecommunication network 1102. The host 1116 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.

[0272] As a whole, the communication system 1100 of Figure 11 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.

[0273] In some examples, the telecommunication network 1102 is a cellular network that implements 3GPP standardized features. Accordingly, the telecommunications network 1102 may support network slicing to provide different logical networks to different devices that are connected to the telecommunication network 1102. For example, the telecommunications network 1102 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.

[0274] In some examples, the UEs 1112 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 1104 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network 1104. Additionally, a UE may be configured for operating in single- or multi -RAT or multistandard 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).

[0275] In the example, the hub 1114 communicates with the access network 1104 to facilitate indirect communication between one or more UEs (e.g., UE 1112c and / or 1112d) and network nodes (e.g., network node 1110b). In some examples, the hub 1114 may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, the hub 1114 may be a broadband router enabling access to the core network 1106 for the UEs. As another example, the hub 1114 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 1110, or by executable code, script, process, or other instructions in the hub 1114. As another example,the hub 1114 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, the hub 1114 may be a content source. For example, for a UE that is a VR device, display, loudspeaker, or other media delivery device, the hub 1114 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub 1114 then provides to the UE either directly, after performing local processing, and / or after adding additional local content. In still another example, the hub 1114 acts as a proxy server or orchestrator for the UEs, in particular if one or more of the UEs are low energy loT devices.

[0276] The hub 1114 may have a constant / persistent or intermittent connection to the network node 1110b. The hub 1114 may also allow for a different communication scheme and / or schedule between the hub 1114 and UEs (e.g., UE 1112c and / or 1112d), and between the hub 1114 and the core network 1106. In other examples, the hub 1114 is connected to the core network 1106 and / or one or more UEs via a wired connection. Moreover, the hub 1114 may be configured to connect to an M2M service provider over the access network 1104 and / or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with the network nodes 1110 while still connected via the hub 1114 via a wired or wireless connection. In some embodiments, the hub 1114 may be a dedicated hub - that is, a hub whose primary function is to route communications to / from the UEs from / to the network node 1110b. In other embodiments, the hub 1114 may be a non-dedicated hub - that is, a device which is capable of operating to route communications between the UEs and network node 1110b, but which is additionally capable of operating as a communication start and / or end point for certain data channels.

[0277] Figure 12 shows a UE 1200 in accordance with some embodiments. The UE 1200 presents additional details of some embodiments of the UE 1112 of Figure 1. As used herein, a UE refers to a device capable, configured, arranged and / or operable to communicate wirelessly with network nodes and / or other UEs. Examples of a UE include, but are not limited to, a smart phone, mobile phone, cell phone, voice over IP (VoIP) phone, wireless local loop phone, desktop computer, personal digital assistant (PDA), wireless cameras, gaming console or device, music storage / playback device, wearable terminal device, wireless endpoint, mobile station, tablet, laptop, laptop-embedded equipment (LEE), laptop-mounted equipment (LME), an Augmented Reality (AR) or Virtual Reality (VR) device, wireless customer-premise equipment (CPE), vehicle, vehicle-mounted or vehicle embedded / integrated wireless device, etc. Other examples include any UEidentified by the 3rd Generation Partnership Project (3GPP), including a narrow band internet of things (NB-IoT) UE, a machine type communication (MTC) UE, and / or an enhanced MTC (eMTC) UE.

[0278] A UE may support device-to-device (D2D) communication, for example by implementing a 3 GPP standard for sidelink communication, Dedicated Short-Range Communication (DSRC), vehi cl e-to- vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle-to-everything (V2X). In other examples, a UE may not necessarily have a user in the sense of a human user who owns and / or operates the relevant device. Instead, a UE may represent a device that is intended for sale to, or operation by, a human user but which may not, or which may not initially, be associated with a specific human user (e.g., a smart sprinkler controller). Alternatively, a UE may represent a device that is not intended for sale to, or operation by, an end user but which may be associated with or operated for the benefit of a user (e.g., a smart power meter).

[0279] The UE 1200 includes processing circuitry 1202 that is operatively coupled via a bus 1204 to an input / output interface 1206, a power source 1208, a memory 1210, a communication interface 1212, and / or any other component, or any combination thereof. Certain UEs may utilize all or a subset of the components shown in Figure 12. The level of integration between the components may vary from one UE to another UE. Further, certain UEs may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0280] The processing circuitry 1202 is configured to process instructions and data and may be configured to implement any sequential state machine operative to execute instructions stored as machine-readable computer programs in the memory 1210. The processing circuitry 1202 may be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, field-programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), etc.); programmable logic together with appropriate firmware; one or more stored computer programs, general-purpose processors, such as a microprocessor or digital signal processor (DSP), together with appropriate software; or any combination of the above. For example, the processing circuitry 1202 may include multiple central processing units (CPUs).

[0281] In the example, the input / output interface 1206 may be configured to provide an interface or interfaces to an input device, output device, or one or more input and / or output devices. Examples of an output device include a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, an emitter, a smartcard, another output device,or any combination thereof. An input device may allow a user to capture information into the UE 1200. Examples of an input device include a touch-sensitive or presence-sensitive display, a camera (e.g., a digital camera, a digital video camera, a web camera, etc.), a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, a smartcard, and the like. The presence-sensitive display may include a capacitive or resistive touch sensor to sense input from a user. A sensor may be, for instance, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, an optical sensor, a proximity sensor, a biometric sensor, etc., or any combination thereof. An output device may use the same type of interface port as an input device. For example, a Universal Serial Bus (USB) port may be used to provide an input device and an output device.

[0282] In some embodiments, the power source 1208 is structured as a battery or battery pack. Other types of power sources, such as an external power source (e.g., an electricity outlet), photovoltaic device, or power cell, may be used. The power source 1208 may further include power circuitry for delivering power from the power source 1208 itself, and / or an external power source, to the various parts of the UE 1200 via input circuitry or an interface such as an electrical power cable. Delivering power may be, for example, for charging of the power source 1208. Power circuitry may perform any formatting, converting, or other modification to the power from the power source 1208 to make the power suitable for the respective components of the UE 1200 to which power is supplied.

[0283] The memory 1210 may be or be configured to include memory such as random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disks, optical disks, hard disks, removable cartridges, flash drives, and so forth. In one example, the memory 1210 includes one or more application programs 1214, such as an operating system, web browser application, a widget, gadget engine, or other application, and corresponding data 1216. The memory 1210 may store, for use by the UE 1200, any of a variety of various operating systems or combinations of operating systems.

[0284] The memory 1210 may be configured to include a number of physical drive units, such as redundant array of independent disks (RAID), flash memory, USB flash drive, external hard disk drive, thumb drive, pen drive, key drive, high-density digital versatile disc (HD-DVD) optical disc drive, internal hard disk drive, Blu-Ray optical disc drive, holographic digital data storage (HDDS) optical disc drive, external mini-dual inline memory module (DIMM), synchronous dynamic random access memory (SDRAM),external micro-DIMM SDRAM, smartcard memory such as tamper resistant module in the form of a universal integrated circuit card (UICC) including one or more subscriber identity modules (SIMs), such as a USIM and / or ISIM, other memory, or any combination thereof. The UICC may for example be an embedded UICC (eUICC), integrated UICC (iUICC) or a removable UICC commonly known as ‘SIM card.’ The memory 1210 may allow the UE 1200 to access instructions, application programs and the like, stored on transitory or non- transitory memory media, to off-load data, or to upload data. An article of manufacture, such as one utilizing a communication system may be tangibly embodied as or in the memory 1210, which may be or comprise a device-readable storage medium.

[0285] The processing circuitry 1202 may be configured to communicate with an access network or other network using the communication interface 1212. The communication interface 1212 may comprise one or more communication subsystems and may include or be communicatively coupled to an antenna 1222. The communication interface 1212 may include one or more transceivers used to communicate, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another UE or a network node in an access network). Each transceiver may include a transmitter 1218 and / or a receiver 1220 appropriate to provide network communications (e.g., optical, electrical, frequency allocations, and so forth). Moreover, the transmitter 1218 and receiver 1220 may be coupled to one or more antennas (e.g., antenna 1222) and may share circuit components, software or firmware, or alternatively be implemented separately.

[0286] In the illustrated embodiment, communication functions of the communication interface 1212 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communications such as Bluetooth, near-field communication, location-based communication such as the use of the global positioning system (GPS) to determine a location, another like communication function, or any combination thereof. Communications may be implemented in according to one or more communication protocols and / or standards, such as IEEE 802.11, Code Division Multiplexing Access (CDMA), Wideband Code Division Multiple Access (WCDMA), GSM, LTE, New Radio (NR), UMTS, WiMax, Ethernet, transmission control protocol / internet protocol (TCP / IP), synchronous optical networking (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), and so forth.

[0287] Regardless of the type of sensor, a UE may provide an output of data captured by its sensors, through its communication interface 1212, via a wireless connection to a network node. Data captured by sensors of a UE can be communicated through a wireless connection to a network node via another UE. The output may be periodic (e.g., once every 15 minutes if it reports the sensed temperature), random (e.g., to even out the load from reporting from several sensors), in response to a triggering event (e.g., when moisture is detected an alert is sent), in response to a request (e.g., a user initiated request), or a continuous stream (e.g., a live video feed of a patient).

[0288] As another example, a UE comprises an actuator, a motor, or a switch, related to a communication interface configured to receive wireless input from a network node via a wireless connection. In response to the received wireless input the states of the actuator, the motor, or the switch may change. For example, the UE may comprise a motor that adjusts the control surfaces or rotors of a drone in flight according to the received input or to a robotic arm performing a medical procedure according to the received input.

[0289] A UE, when in the form of an Internet of Things (loT) device, may be a device for use in one or more application domains, these domains comprising, but not limited to, city wearable technology, extended industrial application and healthcare. Non-limiting examples of such an loT device are a device which is or which is embedded in: a connected refrigerator or freezer, a TV, a connected lighting device, an electricity meter, a robot vacuum cleaner, a voice controlled smart speaker, a home security camera, a motion detector, a thermostat, a smoke detector, a door / window sensor, a flood / moisture sensor, an electrical door lock, a connected doorbell, an air conditioning system like a heat pump, an autonomous vehicle, a surveillance system, a weather monitoring device, a vehicle parking monitoring device, an electric vehicle charging station, a smart watch, a fitness tracker, a wearable for tactile augmentation or sensory enhancement, a water sprinkler, an animal- or item-tracking device, a sensor for monitoring a plant or animal, an industrial robot, an Unmanned Aerial Vehicle (UAV), and any kind of medical device, like a heart rate monitor or a remote controlled surgical robot. A UE in the form of an loT device comprises circuitry and / or software in dependence of the intended application of the loT device in addition to other components as described in relation to the UE 1200 shown in Figure 12.

[0290] As yet another specific example, in an loT scenario, a UE may represent a machine or other device that performs monitoring and / or measurements, and transmits the results of such monitoring and / or measurements to another UE and / or a network node. TheUE may in this case be an M2M device, which may in a 3GPP context be referred to as an MTC device. As one particular example, the UE may implement the 3GPP NB-IoT standard. In other scenarios, a UE may represent a vehicle, such as a car, a bus, a truck, a ship and an airplane, or other equipment that is capable of monitoring and / or reporting on its operational status or other functions associated with its operation.

[0291] In practice, any number of UEs may be used together with respect to a single use case. For example, a first UE might be or be integrated in a drone and provide the drone’ s speed information (obtained through a speed sensor) to a second UE that is a remote controller operating the drone. When the user makes changes from the remote controller, the first UE may adjust the throttle on the drone (e.g. by controlling an actuator) to increase or decrease the drone’s speed. The first and / or the second UE can also include more than one of the functionalities described above. For example, a UE might comprise the sensor and the actuator, and handle communication of data for both the speed sensor and the actuators.

[0292] Figure 13 shows a network node 1300 in accordance with some embodiments. As used herein, network node refers to equipment capable, configured, arranged and / or operable to communicate directly or indirectly with a UE and / or with other network nodes or equipment, in a telecommunication network. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs) and NR NodeBs (gNBs)), 0-RAN nodes or components of an 0-RAN node (e.g., 0-RU, 0-DU, O-CU).

[0293] 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, distributed units (e.g., in an 0-RAN access node) 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).

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

[0295] The network node 1300 includes a processing circuitry 1302, a memory 1304, a communication interface 1306, and a power source 1308. The network node 1300 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 the network node 1300 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, the network node 1300 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate memory 1304 for different RATs) and some components may be reused (e.g., a same antenna 1310 may be shared by different RATs). The network node 1300 may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node 1300, 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 1300.

[0296] The processing circuitry 1302 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 1300 components, such as the memory 1304, to provide network node 1300 functionality.

[0297] In some embodiments, the processing circuitry 1302 includes a system on a chip (SOC). In some embodiments, the processing circuitry 1302 includes one or more of radio frequency (RF) transceiver circuitry 1312 and baseband processing circuitry 1314. In some embodiments, the radio frequency (RF) transceiver circuitry 1312 and the baseband processing circuitry 1314 may be on separate chips (or sets of chips), boards, or units, suchas radio units and digital units. In alternative embodiments, part or all of RF transceiver circuitry 1312 and baseband processing circuitry 1314 may be on the same chip or set of chips, boards, or units.

[0298] The memory 1304 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 the processing circuitry 1302. The memory 1304 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 capable of being executed by the processing circuitry 1302 and utilized by the network node 1300. The memory 1304 may be used to store any calculations made by the processing circuitry 1302 and / or any data received via the communication interface 1306. In some embodiments, the processing circuitry 1302 and memory 1304 is integrated.

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

[0300] In certain alternative embodiments, the network node 1300 does not include separate radio front-end circuitry 1318, instead, the processing circuitry 1302 includes radio front-end circuitry and is connected to the antenna 1310. Similarly, in some embodiments, all or some of the RF transceiver circuitry 1312 is part of the communication interface 1306. In still other embodiments, the communication interface 1306 includes one or more ports or terminals 1316, the radio front-end circuitry 1318, and the RF transceiver circuitry 1312, as part of a radio unit (not shown), and the communication interface 1306 communicates with the baseband processing circuitry 1314, which is part of a digital unit (not shown).

[0301] The antenna 1310 may include one or more antennas, or antenna arrays, configured to send and / or receive wireless signals. The antenna 1310 may be coupled to the radio front-end circuitry 1318 and may be any type of antenna capable of transmitting and receiving data and / or signals wirelessly. In certain embodiments, the antenna 1310 is separate from the network node 1300 and connectable to the network node 1300 through an interface or port.

[0302] The antenna 1310, communication interface 1306, and / or the processing circuitry 1302 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, the antenna 1310, the communication interface 1306, and / or the processing circuitry 1302 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.

[0303] The power source 1308 provides power to the various components of network node 1300 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). The power source 1308 may further comprise, or be coupled to, power management circuitry to supply the components of the network node 1300 with power for performing the functionality described herein. For example, the network node 1300 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 the powersource 1308. As a further example, the power source 1308 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.

[0304] Embodiments of the network node 1300 may include additional components beyond those shown in Figure 13 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, the network node 1300 may include user interface equipment to allow input of information into the network node 1300 and to allow output of information from the network node 1300. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for the network node 1300. In some embodiments providing a core network node, such as core network node 108 of FIG. 11, some components, such as the radio front-end circuitry 1318 and the RF transceiver circuitry 1312 may be omitted.

[0305] Figure 14 is a block diagram illustrating a virtualization environment 1400 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 1400 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. In some embodiments, the virtualization environment 1400 includes components defined by the O-RAN Alliance, such as an O-Cloud environment orchestrated by a Service Management and Orchestration Framework via an O-2 interface. Virtualization may facilitate distributed implementations of a network node, UE, core network node, or host.

[0306] Applications 1402 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) are run in the virtualization environment Q400 to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein.

[0307] Hardware 1404 includes processing circuitry, memory that stores software and / or instructions 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 1406 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 1408a and 1408b (one or more of which may be generally referred to as VMs 1408), and / or perform any of the functions, features and / or benefits described in relation with some embodiments described herein. The virtualization layer 1406 may present a virtual operating platform that appears like networking hardware to the VMs 1408.

[0308] The VMs 1408 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 1406. Different embodiments of the instance of a virtual appliance 1402 may be implemented on one or more of VMs 1408, 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.

[0309] In the context of NFV, a VM 1408 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, nonvirtualized machine. Each of the VMs 1408, and that part of hardware 1404 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 1408 on top of the hardware 1404 and corresponds to the application 1402.

[0310] Hardware 1404 may be implemented in a standalone network node with generic or specific components. Hardware 1404 may implement some functions via virtualization. Alternatively, hardware 1404 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 1410, which, among others, oversees lifecycle management of applications 1402. In some embodiments, hardware 1404 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 otherhardware 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 1412 which may alternatively be used for communication between hardware nodes and radio units.

[0311] Although the computing devices described herein (e.g., UEs, network nodes) may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and / or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and / or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.

[0312] In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer-readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by suchfunctionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and / or by end users and a wireless network generally.

Claims

CLAIMS1. A method for coordinating self-optimization network (SON) functions in a heterogenous communication system, the method comprising: transmitting, from a first network node that is compliant with a first communication standard to a second network node that is compliant with a second communication standard, a first message that includes one of a request or an indication to coordinate handling of one or more SON functions; receiving, at the first network node and from the second network node, a second message that indicates whether the second network node agrees to the request to coordinate handling of the one or more SON functions.

2. The method of claim 1, wherein the request or the indication indicates at least one of: which network node included in the heterogenous communication system should handle the one or more SON functions, which network node included in the heterogenous communication system has precedence for the one or more SON functions, or an order of precedence for network nodes to handle the one or more SON functions.

3. The method of claim 1, further comprising: prior to transmitting the first message to the second network node, receiving, from at least one of the second network node or a third network node that is connected to the second network node, a third message that includes an indication of one or more relevant SON functions; wherein the request or the indication to coordinate handling of the one or more SON functions is based on the indication of the one or more relevant SON functions.

4. The method of claim 1, further comprising: prior to transmitting the first message to the second network node, transmitting, to the second network node, a third message that includes an indication of one or more relevant SON functions; wherein the request or the indication to coordinate handling of the one or more SON functions is based on the indication of the one or more relevant SON functions.

5. The method of embodiment 1, wherein the first communication standard is OpenRadio Access Network (O-RAN) and second communication standard is Third Generation Partnership Project (3 GPP).

6. The method of claim 5, further comprising: transmitting, from the first network node to a third network node that is controlled by the second network node, a third message that includes one of a second request or a second indication to coordinate handling of one or more SON functions; receiving, at the first network node and from the third network node, a fourth message that indicates whether the third network node agrees to the second request to coordinate handling of the one or more SON functions.

7. The method of claim 5, further comprising: causing the second network node to transmit the first request to a third network node that is controlled by the second network node.

8. The method of claim 1, wherein the first communication standard is Third Generation Partnership Project (3GPP) and the second communication standard is Open Radio Access Network (O-RAN).

9. The method of claim 8 further comprising: receiving, at the first network node and from a third network node that is controlled by the first network node, a third message that includes one of a second request or a second indication to coordinate handling of the one or more SON functions; forwarding the second request or the second indication to the second network node; receiving a response to the second request from the second network node, wherein the response indicates whether the second network node agrees to the second request; and forwarding the response to the second request to the third network node.

10. The method of claim 8, further comprising: transmitting, from the first network node to a third network node that is controlled by the first network node, a third message that includes the request or the indication to coordinate handling of one or more SON functions; and receiving, at the first network node and from the third network node, a fourthmessage that indicates whether the third network node agrees to the request to coordinate handling of the one or more SON functions.

11. The method of claim 8, further comprising: receiving, at the first network node and from a third network node that is controlled by the first network node, a third message that includes the request or the indication to coordinate handling of one or more SON functions; transmitting, from the first network node and from the third network node, a fourth message that indicates whether the third network node agrees to the request to coordinate handling of the one or more SON functions.

12. The method of claim 8, further comprising: transmitting, from the first network node to a third network node that controls the first network node, a third message that includes one of a second request or a second indication to coordinate handling of one or more SON functions; receiving, at the first network node and from the third network node, a fourth message that indicates whether the third network node agrees to the second request to coordinate handling of the one or more SON functions.

13. A method for coordinating self-optimization network (SON) functions in a heterogenous communication system, the method comprising: receiving, at a first network node that is compliant with a first communication standard and from a second network node that is compliant with a second communication standard, a first message that includes one of a request or an indication to coordinate handling of one or more SON functions; transmitting, to the second network node, a second message that indicates whether the first network node agrees to the request to coordinate handling of the one or more SON functions.

14. The method of claim 13, wherein the request or the indication indicates at least one of: which network node included in the heterogenous communication system should handle the one or more SON functions, which network node included in the heterogenous communication system has precedence for the one or more SON functions, or an order of precedence for network nodes to handle the one or more SON functions.

15. The method of claim 13, further comprising: prior to receiving the first message from the second network node, transmitting, to the second network node, a third message that includes an indication of one or more relevant SON functions; wherein the one or more SON functions comprise the one or more relevant SON functions.

16. The method of claim 13, wherein the first communication standard is Third Generation Partnership Project (3GPP) and the second communication standard is Open Radio Access Network (O-RAN).

17. The method of claim 16, further comprising: transmitting, from the first network node to a third network node that is controlled by the first network node, a third message that includes one of a second request or a second indication to coordinate handling of one or more SON functions; receiving, at the first network node and from the third network node, a fourth message that indicates whether the third network node agrees to the second request to coordinate handling of the one or more SON functions.

18. The method of claim 13, wherein the first communication standard is Open Radio Access Network (O-RAN) and second communication standard is Third Generation Partnership Project (3 GPP).

19. The method of claim 18, further comprising: receiving, at the first network node and from a third network node that is controlled by the second network node, a third message that includes one of a second request or a second indication to coordinate handling of one or more SON functions; transmitting, to the third network node, a fourth message that indicates whether the first network node agrees to the second request to coordinate handling of the one or more SON functions.

20. The method of claim 18, further comprising: transmitting, from the first network node to a third network node that is controlled bythe second network node, a third message that includes one of a second request or a second indication to coordinate handling of one or more SON functions; receiving, at the first network node and from the third network node, a fourth message that indicates whether the third network node agrees to the second request to coordinate handling of the one or more SON functions.

21. A first network node for coordinating self-optimization network (SON) functions in a heterogenous communication system, the network node comprising: processing circuitry configured to perform any of the steps of any of the embodiments 1-20; power supply circuitry configured to supply power to the processing circuitry.

Images