WO2024070119A1

WO2024070119A1 - Ran intelligent controller (ric) and method therefor

Info

Publication number: WO2024070119A1
Application number: PCT/JP2023/025086
Authority: WO
Inventors: 克紀伊達
Original assignee: 日本電気株式会社
Priority date: 2022-09-28
Filing date: 2023-07-06
Publication date: 2024-04-04

Abstract

A first RAN intelligent controller (RIC) (2) transmits, to a second RIC (3) disposed between the first RIC (2) and one or more radio access network nodes (4), application-related information relating to one or more first applications running in the first RIC (2). This can contribute, for example, to making it possible for a Near-RT RIC to detect competition or possibility of competition between applications (rApps) running in a non-RT RIC and applications (xApps) running in the Near-RT RIC.

Description

RAN Intelligent Controller (RIC) and its method

The present disclosure relates to interfaces between multiple logical functions, controllers, or systems related to control and optimization of a radio access network.

The Open Radio Access Network (O-RAN) Alliance is a community of mobile operators, vendors, and research and academic institutions whose mission is to reimagine radio access networks (RANs) to be more intelligent, open, virtualized, and fully interoperable. O-RAN Working Group 2 (WG2) is conducting technical studies on the Non-Real-Time (Non-RT) RAN Intelligent Controller (RIC) and the A1 interface, and is providing technical specifications related to these (see, for example, non-patent literature 1-3). Meanwhile, O-RAN Working Group 3 (WG3) is conducting technical studies on the Near-Real-Time (Near-RT) RIC and the E2 interface, and is providing technical specifications related to these (see, for example, non-patent literature 4).

The Non-RT RIC is a logical function within the Service Management and Orchestration (SMO) framework. The SMO framework is sometimes simply referred to as SMO. The Non-RT RIC consists of the Non-RT RIC framework and Non-RT RIC applications (rApps). The Non-RT RIC framework contains functionality to logically terminate the A1 interface and expose a set of R1 services to the rApps via the R1 interface. The A1 termination allows the Non-RT RIC framework and the Near-RT RIC to exchange messages over the A1 interface. The set of R1 services includes, among other services, A1-related services and O1-related services.

A1-related services include, among other services, creating, updating, querying, and deleting A1 polices, querying the enforcement status of A1 policies, and subscription to event notifications related to A1 policies, including notification of changes to the enforcement status of A1 policies.

O1 related services are provided by either or both of the SMO and Non-RT RIC frameworks. O1 related services enable rApps to get information about alarms, get performance information related to the network, get the current configuration of the network, provision changes to the network configuration, and get additional information related to the network.

The SMO framework provides various logical functions that are not anchored within a Non-RT RIC. These logical functions include, among other functions, O1 terminations, O2 terminations, and external terminations. The O1 terminations allow the SMO framework to exchange messages with Near-RT RICs and E2 nodes over the O1 interface.

rApps are applications designed to run within the Non-RT RIC. rApps execute within the Non-RT RIC as part of the SMO framework. rApps leverage functionality exposed by the Non-RT RIC to provide value-added services to support and facilitate RAN optimization and operations, such as policy guidance, enrichment information, configuration management, and data analytics.

The Near-RT RIC is a logical function that enables near real-time control and optimization of RAN elements and resources through granular data collection and actions over the E2 interface. The Near-RT RIC hosts a set of applications called xApps and provides a set of commonly used platform functions to support specific functions hosted by the xApps. The set of platform functions includes, among other functions, interface terminations. The interface terminations include E2 terminations, A1 terminations, and O1 terminations, which provide termination for the E2 interface, A1 interface, and O1 interface, respectively.

The E2 interface connects the Near-RT RIC to one or more E2 nodes. The E2 node is a logical node that terminates the E2 interface. The E2 node is a RAN node that exposes one or more RAN functions to the Near-RT RIC and hosted xApps. For NR access, the E2 node includes one or more O-RAN Central Units - Control Plane (O-CU-CPs), one or more O-RAN Central Units - User Plane (O-CU-UPs), one or more O-RAN Distributed Units (O-DUs), or any combination of these. On the other hand, for Evolved Universal Terrestrial Radio Access (E-UTRA) access, the E2 node includes one or more O-RAN eNodeBs (O-eNBs).

xApps are applications designed to run within the Near-RT RIC. xApps execute in the Near-RT RIC as part of the RAN (O-RAN). xApps are independent of the Near-RT RIC and can be provided by third parties. An xApp may consist of one or more microservices. An xApp is used to provide radio resource management over a standardized E2 interface and E2 Service Model (E2SM). For example, an xApp receives data from the RAN and computes and sends back control actions as required.

The inventors have considered avoiding conflicts between rApps and xApps running at different locations in the network. In some implementations, rApps support the same control functions that xApps provide (e.g., traffic steering, scheduling control, handover management, etc.) on a larger time scale. Additionally or alternatively, rApps may be used to derive and apply control policies that affect more RAN nodes, cells, or User Equipments (UEs) than those that are subject to or affected by the xApps. There is a need for an orchestration in which a Non-RT RIC or a Near-RT RIC, or both, avoid conflicts between xApps and rApps that control the same entities (e.g., RAN nodes, cells, or User Equipments (UEs)).

To enhance the orchestration described above, it may be desirable for the Near-RT RIC to be able to detect conflicts or potential conflicts between rApps and xApps. One way to assist with this is to enable the Near-RT RIC to know about rApps running in the Non-RT RIC. However, existing O-RAN technical specifications do not prescribe signaling for the Near-RT RIC to obtain information from the Non-RT RIC about rApps that may conflict with xApps.

One of the objectives that the embodiments disclosed in this specification aim to achieve is to provide an apparatus, method, and program that contribute to enabling Near-RT RIC to detect conflicts or potential conflicts between rApps and xApps. It should be noted that this objective is merely one of several objectives that the embodiments disclosed in this specification aim to achieve. Other objectives or problems and novel features will be apparent from the description in this specification or the accompanying drawings. It should be noted that this objective is merely one of several objectives that the embodiments disclosed in this specification aim to achieve. Other objectives or problems and novel features will be apparent from the description in this specification or the accompanying drawings.

In a first aspect, a first RIC includes at least one memory and at least one processor coupled to the at least one memory. The at least one processor is configured to send application-related information about one or more first applications operating within the first RIC to a second RIC disposed between the first RIC and one or more RAN nodes.

In a second aspect, a method performed by a first RIC includes sending application-related information about one or more first applications operating within the first RIC to a second RIC disposed between the first RIC and one or more RAN nodes.

A third aspect is directed to a second RIC disposed between a first RIC and one or more RAN nodes. The second RIC includes at least one memory and at least one processor coupled to the at least one memory. The at least one processor is configured to receive, from the first RIC, application-related information about one or more first applications operating within the first RIC.

A fourth aspect is directed to a method performed by a second RIC disposed between a first RIC and one or more RAN nodes, the method including receiving, from the first RIC, application-related information about one or more first applications operating within the first RIC.

In a fifth aspect, the program includes a set of instructions (software code) that, when loaded into a computer, causes the computer to perform the method according to the second or fourth aspect described above.

According to the above-mentioned aspects, it is possible to provide an apparatus, method, and program that contribute to enabling Near-RT RIC to detect conflicts or potential conflicts between Apps and xApps.

FIG. 2 illustrates an architecture relating to the A1 and O1 interfaces according to one or more embodiments. A sequence diagram showing an example of operation of an SMO framework, a Non-RT RIC, and a Near-RT RIC in accordance with one or more embodiments. A sequence diagram showing an example of operation of a Non-RT RIC and a Near-RT RIC in accordance with one or more embodiments. A flowchart illustrating an example of the operation of a Near-RT RIC in accordance with one or more embodiments. FIG. 2 illustrates an example of a format for rApp-related information according to one or more embodiments. A sequence diagram showing an example of operation of an SMO framework, a Non-RT RIC, and a Near-RT RIC in accordance with one or more embodiments. A sequence diagram showing an example of operation of a Non-RT RIC and a Near-RT RIC in accordance with one or more embodiments. A sequence diagram showing an example of operation of an SMO framework, a Non-RT RIC, and a Near-RT RIC in accordance with one or more embodiments. A sequence diagram showing an example of operation of a Non-RT RIC and a Near-RT RIC in accordance with one or more embodiments. FIG. 2 illustrates an example format of xApp related information according to one or more embodiments. A sequence diagram showing an example of operation of a Non-RT RIC and a Near-RT RIC in accordance with one or more embodiments. A block diagram illustrating example configurations of an SMO framework, a Non-RT RIC, and a Near-RT RIC in accordance with one or more embodiments.

Below, specific embodiments will be described in detail with reference to the drawings. In each drawing, the same or corresponding elements are given the same reference numerals, and duplicate explanations will be omitted as necessary for clarity of explanation.

The multiple embodiments described below can be implemented independently or in appropriate combination. These multiple embodiments have novel features that are different from each other. Therefore, these multiple embodiments contribute to solving different purposes or problems and to achieving different effects.

The embodiments described below are primarily intended for Non-RT RICs and Near-RT RICs that conform to O-RAN technical specifications. However, these embodiments may also be applied to other systems that support technologies similar to O-RAN Non-RT RICs and Near-RT RICs.

As used herein, depending on the context, "if" may be construed to mean "when," "at or around the time," "after," "upon," "in response to determining," "in accordance with a determination," or "in response to detecting." These expressions may be construed to have the same meaning, depending on the context.

First, the configuration and operation of several elements common to several embodiments will be described. FIG. 1 shows an example of the configuration of a system according to several embodiments. In the example of FIG. 1, the system includes an SMO framework 1, a Near-RT RIC 3, and one or more E2 nodes 4. The SMO framework 1 may simply be referred to as an SMO. Each element (network function) shown in FIG. 1 can be implemented, for example, as a network element on dedicated hardware, as a software instance running on the dedicated hardware, or as a virtualization function instantiated on an application platform.

The SMO framework 1 includes a Non-RT RIC 2 and further provides various logical functions 11 that are not anchored by the Non-RT RIC 2. These SMO framework functions 11 include, among other functions, O1 terminations, O2 terminations, and external terminations. The O1 terminations enable the SMO framework 1 to exchange messages with a Near-RT RIC 3 and one or more E2 nodes 4 over the O1 interface. The O2 terminations enable the SMO framework 1 to exchange messages with the O-Cloud over the O2 interface. The O-Cloud is a cloud computing platform consisting of a collection of physical infrastructure nodes meeting O-RAN requirements that host relevant O-RAN functions, supporting software components, and appropriate management and orchestration functions. Relevant O-RAN functions include, for example, Near-RT RICs and E2 nodes. The external terminations enable the SMO framework 1 or the Non-RT RIC framework 21 to exchange messages with external entities over interfaces outside the scope of O-RAN.

The Non-RT RIC 2 is a logical function within the SMO framework 1. The Non-RT RIC 2 includes a Non-RT RIC framework 21 and Non-RT RIC applications (rApps) 22. The Non-RT RIC framework 21 can also be referred to as Non-RT RIC framework functions. The Non-RT RIC framework 21 includes functionality to logically terminate the A1 interface and expose a set of R1 services to the rApps 22. The A1 termination allows the Non-RT RIC framework 21 and the Near-RT RIC 3 to exchange messages over the A1 interface. The set of R1 services includes, among other services, A1-related services and O1-related services.

O1 related services are provided by the SMO framework 1 and the Non-RT RIC framework 21. The O1 related services enable rApps 22 to obtain information about alarms, obtain performance information related to the network, obtain the current configuration of the network (e.g., RAN node 4), provision changes to the configuration of the network (e.g., RAN node 4), and obtain additional information related to the network (e.g., RAN node 4).

rApps 22 are applications designed to run within the Non-RT RIC 2. rApps 22 execute within the Non-RT RIC 2 as part of the SMO Framework 1. rApps 22 leverage the functionality exposed by the Non-RT RIC 22 to provide value-added services to support and facilitate RAN optimization and operations, such as policy guidance, enrichment information, configuration management, and data analytics.

The Near-RT RIC 3 is a logical function that enables near real-time control and optimization of RAN elements and resources through fine-grained (e.g., UE basis, Cell basis) data collection and actions on the E2 interface. The Near-RT RIC 3 hosts xApps 32 and includes the Near-RT RIC platform 31. The Near-RT RIC platform 31 may also be referred to as the Near-RT RIC platform function. The Near-RT RIC platform 31 provides a set of commonly used platform functions to support specific functions hosted by the xApps 32. The set of platform functions includes interface terminations. The interface terminations include E2 terminations, A1 terminations, and O1 terminations, which provide terminations for the E2 interface, the A1 interface, and the O1 interface, respectively. The set of platform functions further includes other functions, such as messaging infrastructure, xApp subscription management, and conflict mitigation.

The E2 interface connects the Near-RT RIC 3 to one or more E2 nodes 4. The E2 node 4 is a logical node that terminates the E2 interface. The E2 node 4 is a RAN node and exposes one or more RAN functions to the Near-RT RIC 3 and hosted xApps 32. The RAN functions are defined by each E2 node 4. Each E2 node 4 provides a list of the RAN functions it supports to the Near-RT RIC 3. The RAN functions provided by each E2 node 4 may include, for example, Key Performance Measurement (KPM), RAN control (RC), or Network Interface (NI), or any combination of these.

For NR access, the E2 node 4 may include one or more O-RAN Central Units - Control Plane (O-CU-CPs), one or more O-RAN Central Units - User Plane (O-CU-UPs), one or more O-RAN Distributed Units (O-DUs), or any combination of these. Meanwhile, for Evolved Universal Terrestrial Radio Access (E-UTRA) access, the E2 node 4 may include one or more O-RAN eNodeBs (O-eNBs).

xApps 32 are applications designed to run within the Near-RT RIC 3. xApps 32 execute in the Near-RT RIC 3 as part of the RAN (O-RAN). xApps 32 are independent of the Near-RT RIC 3 and can be provided by a third party. Each xApp can consist of one or more microservices. Each xApp is used to provide radio resource management over a standardized E2 interface and E2 service model (E2SM). For example, each xApp receives data from E2 node 4 and calculates and sends control actions back to E2 node 4 as needed.

In some implementations, rApps 22 support the same control functions provided by xApps 32 (e.g., traffic steering, scheduling control, handover management, etc.) on a larger time scale. Additionally or alternatively, rApps 22 may be used to derive and apply control policies that affect more RAN nodes, cells, or User Equipments (UEs) than those subject to or affected by xApps 32.

First Embodiment
An example of the configuration of the system according to this embodiment may be similar to the example shown in Fig. 1. This embodiment provides improved signaling between the Non-RT RIC 2 and the Near-RT RIC 3, either directly or via the SMO framework 1 (or SMO framework function 11).

2 and 3 show examples of the operation of the Non-RT RIC 2 and the Near-RT RIC 3. In the example of FIG. 2, the Non-RT RIC 2 sends rApp-related information to the Near-RT RIC 3 via the SMO framework 1 (or SMO framework function 11). More specifically, in step 201, the Non-RT RIC 2 sends rApp-related information to the SMO framework 1 (or SMO framework function 11). By way of example and not limitation, the message containing or carrying the rApp-related information and sent to the SMO framework 1 (or SMO framework function 11) may be referred to as an INDICATION TRANSFER message. In step 202, the SMO framework 1 (or SMO framework function 11) sends the received rApp-related information to the Near-RT RIC 3 via the O1 interface. By way of example and not limitation, the message containing or carrying the rApp-related information and sent to the Near-RT RIC 3 may be referred to as an INDICATION message.

In contrast, in the example of FIG. 3, the Non-RT RIC 2 sends rApp-related information directly to the Near-RT RIC 3 via the A1 interface (step 301). By way of example and not limitation, a message that contains or carries rApp-related information and is sent to the Near-RT RIC 3 may be referred to as an INDICATION message.

As shown in FIG. 4, the rApp-related information may be used by the Near-RT RIC 3 to determine whether there is a conflict or a potential conflict between one or more rApps running in the Non-RT RIC 2 and one or more xApps running in the Near-RT RIC 3. FIG. 4 illustrates an example of the operation of the Near-RT RIC 3. In step 401, the Near-RT RIC 3 receives rApp-related information from the Non-RT RIC 2, either directly or via the SMO framework 1 (or the SMO framework function 11). In step 401, the Near-RT RIC 3 determines whether there is a conflict or a potential conflict between one or more rApps and one or more xApps based on the rApp-related information. The operation of step 401 may be performed by the Near-RT RIC platform 31. Alternatively, the operation of step 401 may be performed by the Near-RT RIC 3 by executing a specific xApp for reconciliation or orchestration between the rApps and the xApps.

The Non-RT RIC 2 may send rApp-related information about one or more rApps executing within the Non-RT RIC 2 to the Near-RT RIC 3 in response to the rApps requesting a parameter update or RAN control. In other words, when one or more rApps executing within the Non-RT RIC 2 perform a parameter update or RAN control, the Non-RT RIC 2 may send rApp-related information about these rApps to the Near-RT RIC 3. The parameter update may be an update of a RAN configuration parameter. The RAN configuration parameter may relate to, for example, traffic steering, scheduling control, or handover management. Such operation enables the Near-RT RIC 3 to timely determine a conflict or potential conflict between the xApp(s) and these rApp(s) in response to a parameter update or RAN control by the rApp(s) being initiated, performed, or modified.

The rApp-related information may include information indicating the target or content of the control performed or requested by the rApp executing in the Non-RT RIC 2. More specifically, the rApp-related information may indicate at least one RAN node, at least one RAN configuration parameter, at least one cell, at least one network slice, or at least one UE, or any combination thereof, that is subject to or affected by the control performed or requested by the rApp. The UE may be referred to by other terms such as a radio terminal, a mobile terminal, a mobile station, or a wireless transmit receive unit (WTRU). The Near-RT RIC 3 may determine whether the targets of control by the rApp(s) indicated by the rApp-related information (e.g., RAN node, RAN configuration parameter, cell, network slice, or UE) overlap with the targets of control by the xApp(s). If these control targets overlap, the Near-RT RIC 3 may detect a conflict or potential conflict between the xApp(s) and the rApp(s).

Additionally or alternatively, the rApp related information may indicate priority information (rApp priority) associated with each of the one or more rApps. The priority information (rApp priority) may be used by the Near-RT RIC 3 to compare with priority information (xApp priority) associated with an xApp running within the Near-RT RIC 3. The Near-RT RIC 3 may compare the rApp priority with the xApp priority to determine whether to allow or not allow control performed or requested by the xApp. This operation may be performed by the Near-RT RIC platform 31. Alternatively, the operation may be performed by the Near-RT RIC 3 by executing a specific xApp for mediation or orchestration between the rApps and the xApps.

For example, if there is a conflict or potential conflict between an rApp and an xApp and the priority of the rApp is lower than the priority of the xApp, the Near-RT RIC 3 may execute the control requested by the xApp. In other words, the Near-RT RIC 3 (e.g., Near-RT RIC platform 31) may allow control by the xApp. Since the control period of an xApp is generally shorter than that of an rApp, by having the Near-RT RIC 3 execute the control of the xApp as is, the result is that the control by the xApp is given priority over the control by the rApp.

In contrast, if there is a conflict or potential conflict between an rApp and an xApp and the priority of the rApp is higher than the priority of the xApp, the Near-RT RIC 3 may not exercise control by the xApp until it is determined that the control by the rApp does not conflict with the control by the xApp. Alternatively, the Near-RT RIC 3 may select one or more target UEs on which the impact of the control by the rApp is relatively small, and limit the control by the xApp to only the selected UEs.

Figure 5 shows a specific example of rApp-related information. In the example of Figure 5, rApp-related information 500 includes an rApp Info List Information Element (IE) 501. The rApp Info List IE 501 is a list of information items related to one or more rApps. The Non-RT RIC 2 may include information items related to all rApps running within the Non-RT RIC 2 in the rApp Info List IE 501. Alternatively, the Non-RT RIC 2 may include information items related to one or more rApps in the rApp Info List IE 501 that are associated with attributes (e.g., control target, control content) or characteristics requested or specified by the Near-RT RIC 3.

rApp Info List IE 501 includes an rApp ID IE 502 and an ImpactInfo IE 505 for each rApp. The rApp ID IE 502 indicates an identifier or identification information that identifies the rApp. The ImpactInfo IE 505 indicates one or more targets that are subject to or affected by the control performed or required by the rApp. In the example of FIG. 5, the ImpactInfo IE 505 includes an Impacted Cell List IE 506. The Impacted Cell List IE 506 indicates a list of one or more cells that are subject to or affected by the control performed or required by the rApp. More specifically, the Impacted Cell List IE 506 includes a Cell Global ID IE 507 that indicates an identifier for each cell, and a Control Parameter IE 508 that indicates a cell-related parameter that is controlled by the rApp.

Optionally, for each rApp, the rApp Info List IE 501 may include one or both of an rApp Status IE 503 and a Use Case Priority Level IE 504. The rApp Status IE 503 indicates whether the rApp is activated or deactivated. The Use Case Priority Level IE 504 indicates the priority of the rApp (rApp Priority).

The configuration example shown in FIG. 5 may be modified as appropriate. For example, if all rApps have the same predefined priority, or if rApps are always prioritized over xApps, the Use Case Priority Level IE 504 indicating rApp priority may be omitted. In addition to or instead of the Impacted Cell List IE 506, the ImpactInfo IE 505 may indicate a list of other control targets (e.g., one or more RAN nodes, one or more network slices, or one or more UEs).

The operation of the Non-RT RIC 2 and Near-RT RIC 3 described in this embodiment enables the Near-RT RIC 3 to know about rApps running within the Non-RT RIC 2. This can contribute to enabling the Near-RT RIC 3 to detect conflicts or potential conflicts between rApp(s) and xApp(s).

Below, an example of the procedure for subscribing to the notification service for rApp-related information provided by Non-RT RIC 2 is described. Figures 6 to 8 show an example of the procedure for subscribing to the notification service for rApp-related information.

In the example of FIG. 6, the Near-RT RIC 3 sends a subscription request requesting app-related information to the Non-RT RIC 2 via the SMO framework 1 (or SMO framework function 11). More specifically, in step 601, the Near-RT RIC 3 sends the subscription request to the SMO framework 1 (or SMO framework function 11) via the O1 interface. By way of example and not limitation, the message containing the subscription request and sent to the SMO framework 1 may be referred to as a SUBSCRIPTION REQUEST message. In step 602, the SMO framework 1 (or SMO framework function 11) sends the received subscription request to the Non-RT RIC 2. By way of example and not limitation, the message containing the subscription request and sent to the Non-RT RIC 2 may be referred to as a SUBSCRIPTION REQUEST TRANSFER message. In step 603, Non-RT RIC 2 sends a notification to SMO framework 1 (or SMO framework function 11) indicating that the subscription request has been approved (or processed successfully). The message containing the notification and sent to SMO framework 1 may be referred to as a SUBSCRIPTION RESPONSE TRANSFER message. In step 604, SMO framework 1 sends a notification to Near-RT RIC 3 via the O1 interface indicating that the subscription request has been approved (or processed successfully). The message containing the notification and sent to Near-RT RIC 3 may be referred to as a SUBSCRIPTION RESPONSE message.

Steps

605 and 606 are similar to

steps

201 and 202 of FIG. 2.

In contrast, in the example of FIG. 7, Near-RT RIC 3 sends a subscription request requesting app-related information to Non-RT RIC 2 over the A1 interface (step 701). By way of example and not limitation, the message containing the subscription request and sent to Non-RT RIC 2 may be referred to as a SUBSCRIPTION REQUEST message. In step 702, Non-RT RIC 2 sends a notification to Non-RT RIC 2 over the A1 interface indicating that the subscription request has been approved (or successfully processed). The message may be referred to as a SUBSCRIPTION RESPONSE message. Step 703 is similar to step 301 of FIG. 3.

Steps

801 and 802 in FIG. 8 are similar to

steps

601 and 602 in FIG. 6. That is, Near-RT RIC 3 sends a subscription request requesting app-related information to Non-RT RIC 2 via SMO framework 1 (or SMO framework function 11). On the other hand, step 803 in FIG. 8 is similar to step 702 in FIG. 7. That is, Non-RT RIC 2 sends a notification indicating that the subscription request has been approved (or successfully processed) directly to Non-RT RIC 2 via the A1 interface. Step 804 is similar to step 301 in FIG. 3.

When a subscription to a notification service for rApp-related information is no longer required, the Near-RT RIC 3 may perform a procedure to deactivate or delete the subscription. The procedure for deleting a subscription to a notification service may be performed with signaling similar to that of the procedure for subscribing to a notification service described with reference to Figures 6 to 8. Specifically, the Near-RT RIC 3 may send a request for subscription deletion to the Non-RT RIC 2 via the A1 interface or via the O1 interface and SMO framework 1. The Non-RT RIC 2 may send a completion notification of subscription deletion to the Near-RT RIC 3 via the A1 interface or via the O1 interface and SMO framework 1.

Second Embodiment
An example of the configuration of the system according to this embodiment may be similar to the example shown in Figure 1. This embodiment provides an improvement over the signaling described in the first embodiment.

In this embodiment, in addition to the rApp-related information described in the first embodiment, the Near-RT RIC 3 obtains more detailed information from the Non-RT RIC 2 about the control performed or requested by one or more rApps. If the Near-RT RIC 3 detects a conflict or potential conflict between an rApp(s) and an xApp(s) based on the rApp-related information described in the first embodiment, the Near-RT RIC 3 may request more detailed information from the Non-RT RIC 2 about the control content or control target or both of the rApp(s).

Figure 9 shows an example of the operation of Non-RT RIC 2 and Near-RT RIC 3. In step 901, Near-RT RIC 3 requests detailed information from Non-RT RIC 2 via the A1 interface relating to the control content and/or targets affected by the control of one or more rApps that may conflict with one or more specific xApps. The name of the message carrying the request may be a QUERY APPINFOMATION message. The message of step 901 contains information about one or more xApps running in Near-RT RIC 3.

In step 902, the Non-RT RIC 2 responds to the Near-RT RIC 3 with a message containing detailed information. The message may be named a QUERY APPIMFORMATION RESPONSE message. More specifically, the Non-RT RIC 2 identifies one or more rApps that conflict or may potentially conflict with one or more xApps presented by the Near-RT RIC 3. The Non-RT RIC 2 sends information about the identified one or more rApps to the Near-RT RIC 3.

The Near-RT RIC 3 may perform processing to avoid conflicts between rApp(s) and xApp(s) based on the information of the received rApps. For example, if there is a conflict or possible conflict between an rApp and an xApp and the priority of the rApp is lower than the priority of the xApp, the Near-RT RIC 3 may execute the control requested by the xApp. In contrast, if there is a conflict or possible conflict between an rApp and an xApp and the priority of the rApp is higher than the priority of the xApp, the Near-RT RIC 3 may not execute control by the xApp until it is determined that control by the rApp does not conflict with control by the xApp.

FIG. 10 shows an example of the detailed information sent in step 901. In the example of FIG. 10, the detailed information includes xApp-related information 1000. That is, in some implementations, the Near-RT RIC 3 may send information of one or more xApps to the Non-RT RIC 2 and request the Non-RT RIC 2 to return information of one or more rApps that conflict or may conflict with the one or more xApps. In response to the request from the Near-RT RIC 3, the Non-RT RIC 2 may send information of one or more rApps to the Near-RT RIC 3 that may conflict with one or more specific xApps. The return message sent from the Non-RT RIC 2 to the Near-RT RIC 3 (step 902) may include, for example, all of the information elements shown in FIG. 5.

The xApp related information 1000 includes an xApp Info List IE 1001. The xApp Info List IE 1001 is a list of information items about one or more xApps that may be affected by control of the rApp(s). Alternatively, the xApp Info List IE 1001 is a list of information items about one or more xApps that the Near-RT RIC 3 wishes to avoid conflicting with the rApp(s).

The xApp Info List IE 1001 includes, for each xApp, an xApp ID IE 1002, an xApp Status IE 1003, a Use Case Priority Level IE 1004, and an ImpactInfo IE 1005. The xApp ID IE 1002 indicates an identifier or identification information that identifies the xApp. The xApp Status IE 1003 indicates whether the xApp is activated or deactivated.

The Use Case Priority Level IE 1004 indicates the priority of the xApp (xApp priority). The ImpactInfo IE 1005 indicates one or more targets that are subject to or affected by the control performed or requested by the xApp. In the example of FIG. 10, the ImpactInfo IE 1005 includes an Impacted Cell List IE 1006. The Impacted Cell List IE 1006 indicates a list of one or more cells that are subject to or affected by the control performed or requested by the xApp. More specifically, the Impacted Cell List IE 1006 includes a Cell Global ID IE 1007 indicating an identifier of each cell, and a Control Parameter IE 1008 indicating cell-related parameters controlled by the xApp. The Cell Global ID IE 1007 is information that identifies a cell in which a UE or user is located that is affected by the control of the xApp.

The configuration example shown in FIG. 10 may be modified as appropriate. For example, if all xApps have the same predefined priority, or if rApps always take priority over xApps, the Use Case Priority Level IE 1004 indicating xApp priority may be omitted. In addition to or instead of the Impacted Cell List IE 1006, the ImpactInfo IE 1005 may indicate a list of other control targets (e.g., one or more RAN nodes, one or more network slices, or one or more UEs).

The operation of the Non-RT RIC 2 and Near-RT RIC 3 described in this embodiment enables the Near-RT RIC 3 to obtain more detailed information from the Non-RT RIC 2 about the control being performed or requested by one or more rApps.

Third Embodiment
An example of the configuration of the system according to this embodiment may be similar to the example shown in Figure 1. This embodiment provides an improvement over the signaling described in the first embodiment.

FIG. 11 shows an example of the operation of the Non-RT RIC 2 and the Near-RT RIC 3. In step 1101, the Near-RT RIC 3 requests detailed information from the Non-RT RIC 2 via the A1 interface relating to the control of rApps that may conflict with one or more specific xApps and/or targets affected by the control. The name of the message carrying the request may be a QUERY APPINFOMATION message. The Near-RT RIC 3 may request the Non-RT RIC 2 to send information indicating one or more xApps that are affected by the control performed or requested by one or more rApps. The request may specify one or more rApps. Additionally or alternatively, the request may include information about one or more xApps running in the Near-RT RIC 3.

In step 1102, the Non-RT RIC 2 responds to the Near-RT RIC 3 with a message including the detailed information. The message may be named QUERY APPIMFORMATION RESPONSE message. The detailed information includes xApp-related information. More specifically, in response to the request from the Near-RT RIC 3, the Non-RT RIC 2 identifies one or more xApps that are affected by the control performed or requested by one or more rApps. The Non-RT RIC 2 may identify xApp(s) that need to be suspended to avoid conflicts with the rApp(s). The Non-RT RIC 2 sends information to the Near-RT RIC 3 indicating the identified one or more xApps. The format of the detailed information sent in step 902 may be similar to the xApp-related information 1000 shown in FIG. 10.

The Near-RT RIC 3 may perform processing to avoid conflicts between rApp(s) and xApp(s) based on the received rApps information. For example, the Near-RT RIC 3 may suspend processing of one or more xApps indicated in the message of step 1102. The Near-RT RIC 3 may further consider rApp-related information received in the procedure of FIG. 2 or FIG. 3 prior to the procedure of FIG. 11. For example, if the priority of the xApp indicated in the message of step 1102 is higher than the priority of the rApp with which it may conflict, the Near-RT RIC 3 may execute the control requested by the xApp without interruption. In contrast, if the priority of the xApp indicated in the message of step 1102 is lower than the priority of the rApp with which it may conflict, the Near-RT RIC 3 may not perform control by the xApp until it is determined that the control by the rApp does not conflict with the control by the xApp.

The following describes example configurations of the SMO framework 1, Non-RT RIC 2, and Near-RT RIC 3 according to the above-mentioned embodiments. Figure 12 is a block diagram showing an example configuration of the Non-RT RIC 2. The SMO framework 1 and Near-RT RIC 3 may also have a configuration similar to that shown in Figure 12.

In the example of FIG. 12, Non-RT RIC 2 is implemented as a computer system. The computer system includes one or more processors 1210, memory 1220, and mass storage 1230, which communicate with each other via a bus 1270. The one or more processors 1210 may include, for example, a Central Processing Unit (CPU) or a Graphics Processing Unit (GPU) or both. The computer system may include other devices, such as one or more output devices 1240, one or more input devices 1250, and one or more peripherals 1260. The one or more peripherals 1260 may include a modem, or a network adapter, or any combination thereof.

One or both of memory 1220 and mass storage 1230 may include a computer-readable medium having stored thereon one or more sets of instructions. These instructions may be located partially or completely in memory within one or more processors 1210. These instructions, when executed in one or more processors 1210, cause the one or more processors 1210 to provide the functionality of the Non-RT RIC 2 described in the embodiments above.

As described with reference to FIG. 12, each of the processors in the SMO framework 1, Non-RT RIC 2, and Near-RT RIC 3 according to the above-described embodiments can execute one or more programs including instructions for causing a computer to perform the algorithms described with reference to the drawings. The programs include instructions (or software code) for causing a computer to perform one or more functions described in the embodiments when loaded into the computer. The programs may be stored on a non-transitory computer-readable medium or a tangible storage medium. By way of example and not limitation, computer-readable media or tangible storage media include random-access memory (RAM), read-only memory (ROM), flash memory, solid-state drive (SSD) or other memory technology, CD-ROM, digital versatile disk (DVD), Blu-ray (registered trademark) disk or other optical disk storage, magnetic cassette, magnetic tape, magnetic disk storage or other magnetic storage device. The programs may be transmitted on a transitory computer-readable medium or a communication medium. By way of example and not limitation, transitory computer-readable media or communication media include electrical, optical, acoustic, or other forms of propagated signals.

The above-mentioned embodiments are merely examples of the application of the technical ideas obtained by the inventors. In other words, the technical ideas are not limited to the above-mentioned embodiments, and various modifications are of course possible.

For example, some or all of the above embodiments can be described as follows, but are not limited to the following:

(Appendix 1)
a first Radio Access Network (RAN) Intelligent Controller (RIC),
At least one memory;
at least one processor coupled to the at least one memory;
Equipped with
The at least one processor is configured to send application-related information about one or more first applications operating within the first RIC to a second RIC disposed between the first RIC and one or more Radio Access Network (RAN) nodes.
First RIC.
(Appendix 2)
the application-related information is used by the second RIC to determine whether there is a conflict or potential conflict between the one or more first applications and one or more second applications executing within the second RIC;
2. The first RIC described in Appendix 1.
(Appendix 3)
the application-related information includes information indicating a subject or content of control performed or requested by each of the one or more first applications;
2. A first RIC as described in

claim

1 or 2.
(Appendix 4)
the application-related information being indicative of at least one Radio Access Network (RAN) node, at least one RAN configuration parameter, at least one cell, at least one network slice, or at least one User Equipment (UE), or any combination thereof, that is subject to or affected by control performed or required by each first application;
2. A first RIC as described in

claim

1 or 2.
(Appendix 5)
the application-related information indicating first priority information associated with each of the one or more first applications;
5. The first RIC according to any one of claims 1 to 4.
(Appendix 6)
the first priority information is used by the second RIC to compare with second priority information associated with a second application executing within the second RIC;
5. The first RIC described in Appendix 5.
(Appendix 7)
the at least one processor is configured to send the application-related information to the second RIC in response to the one or more first applications requesting a parameter update or radio access network (RAN) control.
7. The first RIC according to any one of claims 1 to 6.
(Appendix 8)
the at least one processor is configured to send the application-related information directly to the second RIC via a first interface between the first RIC and the second RIC;
8. The first RIC according to any one of claims 1 to 7.
(Appendix 9)
the at least one processor is configured to indirectly send the application-related information to the second RIC via a second interface between a Service Management and Orchestration (SMO) framework that includes the first RIC and the second RIC.
8. The first RIC according to any one of claims 1 to 7.
(Appendix 10)
the at least one processor is configured to receive a subscription request from the second RIC to request the application-related information.
10. The first RIC according to any one of claims 1 to 9.
(Appendix 11)
the at least one processor is configured to receive the join request directly from the second RIC via a first interface between the first RIC and the second RIC;
11. The first RIC of claim 10.
(Appendix 12)
the at least one processor is configured to receive the subscription request indirectly from the second RIC via a second interface between a Service Management and Orchestration (SMO) framework that includes the first RIC and the second RIC.
11. The first RIC of claim 10.
(Appendix 13)
The at least one processor
receiving a request from the second RIC that includes information about one or more second applications executing within the second RIC;
in response to said request, sending to said second RIC detailed information about one or more first applications operating within said first RIC that conflict or may conflict with said one or more second applications;
It is configured as follows:
13. The first RIC of any one of claims 1 to 12.
(Appendix 14)
the at least one processor is configured to, in response to a request from the second RIC, send information to the second RIC indicative of one or more second applications operating within the second RIC that are affected by control performed or requested by the one or more first applications.
13. The first RIC of any one of claims 1 to 12.
(Appendix 15)
the first RIC is an Open Radio Access Network (O-RAN) Non-Real-Time (Non-RT) RIC;
The second RIC is an O-RAN Near-Real-Time (Near-RT) RIC.
15. The first RIC of any one of claims 1 to 14.
(Appendix 16)
a second Radio Access Network (RAN) Intelligent Controller (RIC) disposed between the first RIC and one or more Radio Access Network (RAN) nodes,
At least one memory;
at least one processor coupled to the at least one memory;
Equipped with
the at least one processor is configured to receive, from the first RIC, application-related information about one or more first applications running within the first RIC;
Second RIC.
(Appendix 17)
the at least one processor is configured to determine, based on the application-related information, whether there is a conflict or a potential conflict between the one or more first applications and one or more second applications executing within the second RIC.
17. The second RIC according to claim 16.
(Appendix 18)
the application-related information includes information indicating a subject or content of control performed or requested by each of the one or more first applications;
18. A second RIC as described in Appendix 16 or 17.
(Appendix 19)
the application-related information being indicative of at least one Radio Access Network (RAN) node, at least one RAN configuration parameter, at least one cell, at least one network slice, or at least one User Equipment (UE), or any combination thereof, that is subject to or affected by control performed or required by each first application;
18. A second RIC as described in Appendix 16 or 17.
(Appendix 20)
the application-related information indicating first priority information associated with each of the one or more first applications;
20. The second RIC of any one of claims 16 to 19.
(Appendix 21)
the at least one processor is configured to compare the first priority information with second priority information associated with a second application executing in the second RIC to determine whether to grant control exercised or requested by the second application.
21. The second RIC of claim 20.
(Appendix 22)
the at least one processor is configured to receive the application-related information directly from the first RIC via a first interface between the first RIC and the second RIC;
22. The second RIC of any one of claims 16 to 21.
(Appendix 23)
the at least one processor is configured to indirectly receive the application-related information from the first RIC via a second interface between a Service Management and Orchestration (SMO) framework that includes the first RIC and the second RIC.
22. The second RIC of any one of claims 16 to 21.
(Appendix 24)
the at least one processor is configured to send a subscription request to the first RIC to request the application-related information.
24. The second RIC of any one of claims 16 to 23.
(Appendix 25)
the at least one processor is configured to send the join request directly to the first RIC via a first interface between the first RIC and the second RIC;
25. The second RIC of claim 24.
(Appendix 26)
the at least one processor is configured to indirectly send the join request to the first RIC via a second interface between a Service Management and Orchestration (SMO) framework that includes the first RIC and the second RIC.
25. The second RIC of claim 24.
(Appendix 27)
The at least one processor
sending a request to the first RIC that includes information about one or more second applications executing within the second RIC;
receiving detailed information from the first RIC about one or more first applications operating within the first RIC that conflict or may conflict with the one or more second applications;
It is configured as follows:
27. The second RIC of any one of claims 16 to 26.
(Appendix 28)
the at least one processor is configured to request the first RIC to send information indicative of one or more second applications operating within the second RIC that are affected by control performed or requested by the one or more first applications;
27. The second RIC of any one of claims 16 to 26.
(Appendix 29)
the first RIC is an Open Radio Access Network (O-RAN) Non-Real-Time (Non-RT) RIC;
The second RIC is an O-RAN Near-Real-Time (Near-RT) RIC.
29. The second RIC of any one of claims 16 to 28.
(Appendix 30)
1. A method performed by a first Radio Access Network (RAN) Intelligent Controller (RIC), comprising:
sending application-related information about one or more first applications operating within the first RIC to a second RIC disposed between the first RIC and one or more Radio Access Network (RAN) nodes.
Method.
(Appendix 31)
1. A method performed by a second Radio Access Network (RAN) Intelligent Controller (RIC) disposed between a first RIC and one or more Radio Access Network (RAN) nodes, the method comprising:
receiving, from the first RIC, application-related information about one or more first applications running within the first RIC;
Method.
(Appendix 32)
A program for causing a computer to perform a method for a first Radio Access Network (RAN) Intelligent Controller (RIC), comprising:
The method includes sending application-related information about one or more first applications operating within the first RIC to a second RIC disposed between the first RIC and one or more Radio Access Network (RAN) nodes.
program.
(Appendix 33)
A program for causing a computer to perform a method for a second Radio Access Network (RAN) Intelligent Controller (RIC) disposed between a first RIC and one or more Radio Access Network (RAN) nodes, the program comprising:
The method comprises receiving, from the first RIC, application-related information about one or more first applications running within the first RIC;
program.

This application claims priority based on Japanese Patent Application No. 2022-154361, filed on September 28, 2022, the entire disclosure of which is incorporated herein by reference.

1. SMO Framework 2. Non-RT RIC
3 Near-RT RIC
4 E2 node 1110 Processor 1120 Memory 1130 Mass storage

Claims

a first Radio Access Network (RAN) Intelligent Controller (RIC),
At least one memory;
at least one processor coupled to the at least one memory;
Equipped with
The at least one processor is configured to send application-related information about one or more first applications operating within the first RIC to a second RIC disposed between the first RIC and one or more Radio Access Network (RAN) nodes.
First RIC.
the application-related information is used by the second RIC to determine whether there is a conflict or potential conflict between the one or more first applications and one or more second applications executing within the second RIC;
The first RIC of claim 1 .
the application-related information includes information indicating a subject or content of control performed or requested by each of the one or more first applications;
A first RIC according to claim 1 or 2.
the application-related information being indicative of at least one Radio Access Network (RAN) node, at least one RAN configuration parameter, at least one cell, at least one network slice, or at least one User Equipment (UE), or any combination thereof, that is subject to or affected by control performed or required by each first application;
A first RIC according to claim 1 or 2.
the application-related information indicating first priority information associated with each of the one or more first applications;
A first RIC according to any one of claims 1 to 4.
the first priority information is used by the second RIC to compare with second priority information associated with a second application executing within the second RIC;
The first RIC of claim 5.
the at least one processor is configured to send the application-related information to the second RIC in response to the one or more first applications requesting a parameter update or radio access network (RAN) control.
A first RIC according to any one of claims 1 to 6.
the at least one processor is configured to send the application-related information directly to the second RIC via a first interface between the first RIC and the second RIC;
A first RIC according to any one of claims 1 to 7.
the at least one processor is configured to indirectly send the application-related information to the second RIC via a second interface between a Service Management and Orchestration (SMO) framework that includes the first RIC and the second RIC.
A first RIC according to any one of claims 1 to 7.
the at least one processor is configured to receive a subscription request from the second RIC to request the application-related information.
A first RIC according to any one of claims 1 to 9.
the at least one processor is configured to receive the join request directly from the second RIC via a first interface between the first RIC and the second RIC;
The first RIC of claim 10.
the at least one processor is configured to receive the subscription request indirectly from the second RIC via a second interface between a Service Management and Orchestration (SMO) framework that includes the first RIC and the second RIC.
The first RIC of claim 10.
The at least one processor
receiving a request from the second RIC that includes information about one or more second applications executing within the second RIC;
in response to said request, sending to said second RIC detailed information about one or more first applications operating within said first RIC that conflict or may conflict with said one or more second applications;
It is configured as follows:
A first RIC according to any one of claims 1 to 12.
the at least one processor is configured to, in response to a request from the second RIC, send information to the second RIC indicative of one or more second applications operating within the second RIC that are affected by control performed or requested by the one or more first applications.
A first RIC according to any one of claims 1 to 12.
the first RIC is an Open Radio Access Network (O-RAN) Non-Real-Time (Non-RT) RIC;
The second RIC is an O-RAN Near-Real-Time (Near-RT) RIC.
A first RIC according to any one of claims 1 to 14.
a second Radio Access Network (RAN) Intelligent Controller (RIC) disposed between the first RIC and one or more Radio Access Network (RAN) nodes,
At least one memory;
at least one processor coupled to the at least one memory;
Equipped with
the at least one processor is configured to receive, from the first RIC, application-related information about one or more first applications running within the first RIC;
Second RIC.
the at least one processor is configured to determine, based on the application-related information, whether there is a conflict or a potential conflict between the one or more first applications and one or more second applications executing within the second RIC.
The second RIC of claim 16.
the application-related information includes information indicating a subject or content of control performed or requested by each of the one or more first applications;
A second RIC according to claim 16 or 17.
the application-related information being indicative of at least one Radio Access Network (RAN) node, at least one RAN configuration parameter, at least one cell, at least one network slice, or at least one User Equipment (UE), or any combination thereof, that is subject to or affected by control performed or required by each first application;
A second RIC according to claim 16 or 17.
the application-related information indicating first priority information associated with each of the one or more first applications;
A second RIC according to any one of claims 16 to 19.
the at least one processor is configured to compare the first priority information with second priority information associated with a second application executing in the second RIC to determine whether to grant control exercised or requested by the second application.
The second RIC of claim 20.
the at least one processor is configured to receive the application-related information directly from the first RIC via a first interface between the first RIC and the second RIC;
A second RIC according to any one of claims 16 to 21.
the at least one processor is configured to indirectly receive the application-related information from the first RIC via a second interface between a Service Management and Orchestration (SMO) framework that includes the first RIC and the second RIC.
A second RIC according to any one of claims 16 to 21.
the at least one processor is configured to send a subscription request to the first RIC to request the application-related information.
A second RIC according to any one of claims 16 to 23.
the at least one processor is configured to send the join request directly to the first RIC via a first interface between the first RIC and the second RIC;
25. The second RIC of claim 24.
the at least one processor is configured to indirectly send the join request to the first RIC via a second interface between a Service Management and Orchestration (SMO) framework that includes the first RIC and the second RIC.
25. The second RIC of claim 24.
The at least one processor
sending a request to the first RIC that includes information about one or more second applications executing within the second RIC;
receiving detailed information from the first RIC about one or more first applications operating within the first RIC that conflict or may conflict with the one or more second applications;
It is configured as follows:
A second RIC according to any one of claims 16 to 26.
the at least one processor is configured to request the first RIC to send information indicative of one or more second applications operating within the second RIC that are affected by control performed or requested by the one or more first applications;
A second RIC according to any one of claims 16 to 26.
the first RIC is an Open Radio Access Network (O-RAN) Non-Real-Time (Non-RT) RIC;
The second RIC is an O-RAN Near-Real-Time (Near-RT) RIC.
A second RIC according to any one of claims 16 to 28.
1. A method performed by a first Radio Access Network (RAN) Intelligent Controller (RIC), comprising:
sending application-related information about one or more first applications operating within the first RIC to a second RIC disposed between the first RIC and one or more Radio Access Network (RAN) nodes.
Method.
1. A method performed by a second Radio Access Network (RAN) Intelligent Controller (RIC) disposed between a first RIC and one or more Radio Access Network (RAN) nodes, the method comprising:
receiving, from the first RIC, application-related information about one or more first applications running within the first RIC;
Method.
A non-transitory computer-readable medium having stored thereon a program for causing a computer to perform a method for a first Radio Access Network (RAN) Intelligent Controller (RIC), comprising:
The method includes sending application-related information about one or more first applications operating within the first RIC to a second RIC disposed between the first RIC and one or more Radio Access Network (RAN) nodes.
Non-transitory computer-readable medium.
A non-transitory computer-readable medium having stored thereon a program that causes a computer to perform a method for a second Radio Access Network (RAN) Intelligent Controller (RIC) disposed between a first RIC and one or more Radio Access Network (RAN) nodes, the method comprising:
The method comprises receiving, from the first RIC, application-related information about one or more first applications running within the first RIC;
Non-transitory computer-readable medium.