Ran intelligent controller (RIC) and method therefor

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

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

[0002] 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) as more intelligent, open, virtualized, and fully interoperable. The 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 related technical specifications (see, for example, Non-Patent Documents 1-3). Meanwhile, the 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 related technical specifications (see, for example, Non-Patent Document 4).

[0003] 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 that logically terminates the A1 interface and exposes a set of R1 services to rApps via the R1 interface. The A1 termination allows the Non-RT RIC framework and 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.

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

[0005] O1-related services are provided by the SMO framework and / or the Non-RT RIC framework and enable rApps to obtain information about alarms, obtain performance information related to the network, obtain the current configuration of the network, provision changes to the network's configuration, and obtain additional information related to the network.

[0006] 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. O1 terminations allow the SMO framework to exchange messages with Near-RT RICs and E2 nodes over the O1 interface.

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

[0008] 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 action 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 the specific functions hosted by the xApps. The set of platform functions includes, among other functions, interface terminations. The interface terminations include E2 termination, A1 termination, and O1 termination, which provide termination for the E2 interface, A1 interface, and O1 interface, respectively.

[0009] 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 thereof. For Evolved Universal Terrestrial Radio Access (E-UTRA) access, the E2 node includes one or more O-RAN eNodeBs (O-eNBs).

[0010] 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. xApps may consist of one or more microservices. xApps are used to provide radio resource management via a standardized E2 interface and E2 service model (E2SM). For example, xApps receive data from the RAN and calculate and send back control actions as needed.

[0011] O-RAN ALLIANCE Working Group 2, "O-RAN Non-RT RIC Architecture 2.0", O-RAN.WG2.Non-RT-RIC-ARCH-TS-v02.00, July 2022O-RAN ALLIANCE Working Group 2, "O-RAN Non-RT RIC & A1 Interface: Use Cases and Requirements 6.0", O-RAN.WG2.Use-Case-Requirements-v06.00, July 2022O-RAN ALLIANCE Working Group 2, "O-RAN A1 interface: General Aspects and Principles 2.03", O-RAN.WG2.A1GAP-v02.03, October 2021O-RAN ALLIANCE Working Group 3, "O-RAN Near-Real-time RAN Intelligent Controller Near-RT RIC Architecture 2.01", O-RAN.WG3.RICARCH-v02.01, March 2022

[0012] 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.), but on a larger timescale. 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 controlled by the xApps. The Non-RT RIC, Near-RT RIC, or both must provide orchestration that avoids conflicts between xApps and rApps that control the same objects (e.g., RAN nodes, cells, or User Equipments (UEs)).

[0013] To enhance the above-mentioned orchestration, 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 support this is to enable the Near-RT RIC to know about rApps running in Non-RT RICs. However, existing O-RAN technical specifications do not prescribe signaling for the Near-RT RIC to obtain information about rApps that may conflict with xApps from Non-RT RICs.

[0014] One of the objectives to be achieved by the embodiments disclosed in this specification is to provide an apparatus, a method, and a program that contribute to enabling a Near-RT RIC to detect a conflict or a potential conflict between rApps and xApps. It should be noted that this objective is merely one of multiple objectives to be achieved by the multiple embodiments disclosed in this specification. Other objectives, objects, 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 multiple objectives to be achieved by the multiple embodiments disclosed in this specification. Other objectives, objects, and novel features will be apparent from the description in this specification or the accompanying drawings.

[0015] 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 configured to send application-related information about one or more first applications running within the first RIC to a second RIC interposed between the first RIC and one or more RAN nodes.

[0016] 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 interposed between the first RIC and one or more RAN nodes.

[0017] A third aspect is directed to a second RIC interposed between a first RIC and one or more RAN nodes, the second RIC including at least one memory and at least one processor coupled to the at least one memory, the at least one processor configured to receive, from the first RIC, application-related information about one or more first applications running within the first RIC.

[0018] A fourth aspect is directed to a method performed by a second RIC interposed 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.

[0019] In a fifth aspect, a program includes a group 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.

[0020] According to the above-described aspects, it is possible to provide an apparatus, a method, and a program that contribute to enabling a Near-RT RIC to detect a conflict or a possibility of a conflict between Apps and xApps.

[0021] FIG. 1 illustrates an architecture relating to the A1 and O1 interfaces according to one or more embodiments. FIG. 2 illustrates a sequence diagram of an example of the operation of an SMO framework, a Non-RT RIC, and a Near-RT RIC according to one or more embodiments. FIG. 3 illustrates a sequence diagram of an example of the operation of a Non-RT RIC and a Near-RT RIC according to one or more embodiments. FIG. 4 illustrates a flowchart of an example of the operation of a Near-RT RIC according to one or more embodiments. FIG. 5 illustrates an example of a format of rApp-related information according to one or more embodiments. FIG. 6 illustrates a sequence diagram of an example of the operation of an SMO framework, a Non-RT RIC, and a Near-RT RIC according to one or more embodiments. FIG. 7 illustrates a sequence diagram of an example of the operation of a Non-RT RIC and a Near-RT RIC according to one or more embodiments. FIG. 8 illustrates a sequence diagram of an example of the operation of an SMO framework, a Non-RT RIC, and a Near-RT RIC according to one or more embodiments. FIG. 9 illustrates a sequence diagram of an example of the operation of a Non-RT RIC and a Near-RT RIC according to one or more embodiments. FIG. 10 illustrates an example of a format of xApp-related information according to one or more embodiments. FIG. 11 illustrates a sequence diagram of an example of the operation of a Non-RT RIC and a Near-RT RIC according to one or more embodiments. FIG. 2 is a block diagram illustrating an example configuration of an SMO framework, a Non-RT RIC, and a Near-RT RIC according to one or more embodiments.

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

[0023] The multiple embodiments described below can be implemented independently or in appropriate combination. These multiple embodiments have different novel features. Therefore, these multiple embodiments contribute to solving different purposes or problems and to achieving different effects.

[0024] The following embodiments are described primarily for the Non-RT RIC and Near-RT RIC according to the O-RAN technical specifications, but may also be applied to other systems that support technologies similar to the O-RAN Non-RT RIC and Near-RT RIC.

[0025] As used herein, depending on the context, "if" may be interpreted 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 interpreted to have the same meaning, depending on the context.

[0026] First, the configuration and operation of several elements common to several embodiments will be described. FIG. 1 shows an example 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 be simply referred to as 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 dedicated hardware, or as a virtualized function instantiated on an application platform.

[0027] The SMO framework 1 includes a Non-RT RIC 2 and also 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 termination, O2 termination, and external terminations. The O1 termination allows 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 termination allows 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 related O-RAN functions, supporting software components, and appropriate management and orchestration functions. Related O-RAN functions include, for example, Near-RT RICs and E2 nodes. External terminations allow the SMO framework 1 or the Non-RT RIC framework 21 to exchange messages with external entities over interfaces outside the O-RAN scope.

[0028] 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 that logically terminates the A1 interface and exposes 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.

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

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

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

[0032] The Near-RT RIC 3 is a logical function that enables near-real-time control and optimization of RAN elements and resources through granular (e.g., UE-based, Cell-based) data collection and action 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 an E2 termination, an A1 termination, and an O1 termination, which provide termination for the E2 interface, the A1 interface, and the O1 interface, respectively. The set of platform functions further includes other functions, such as a messaging infrastructure, xApp subscription management, and conflict mitigation.

[0033] 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 that exposes one or more RAN functions to the Near-RT RIC 3 and hosted xApps 32. 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 include, for example, Key Performance Measurement (KPM), RAN control (RC), or Network Interface (NI), or any combination thereof.

[0034] 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 thereof, while for Evolved Universal Terrestrial Radio Access (E-UTRA) access, the E2 node 4 may include one or more O-RAN eNodeBs (O-eNBs).

[0035] 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 via a standardized E2 interface and E2 service model (E2SM). For example, each xApp receives data from the E2 node 4, calculates control actions as needed, and sends them back to the E2 node 4.

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

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

[0038] 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 the rApp-related information to the SMO framework 1 (or SMO framework function 11). By way of example and not limitation, a message containing or carrying 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, a message containing or carrying rApp-related information and sent to the Near-RT RIC 3 may be referred to as an INDICATION message.

[0039] 3, Non-RT RIC 2 sends rApp-related information directly to Near-RT RIC 3 via the A1 interface (step 301). By way of example and not limitation, a message containing or carrying rApp-related information and sent to Near-RT RIC 3 may be referred to as an INDICATION message.

[0040] 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 shows 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 directly or via the SMO framework 1 (or 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 mediation or orchestration between the rApps and the xApps.

[0041] 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 a parameter update or RAN control request from these rApps. 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 conflicts or potential conflicts between xApp(s) and these rApp(s) in response to a parameter update or RAN control by the rApp(s) being initiated, performed, or modified.

[0042] The rApp-related information may include information indicating the target or content of control performed or requested by an rApp running 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 also be referred to by other terms, such as a wireless terminal, a mobile terminal, a mobile station, or a wireless transmit receive unit (WTRU). The Near-RT RIC 3 may determine whether the target of control by the rApp(s) indicated by the rApp-related information (e.g., a RAN node, a RAN configuration parameter, a cell, a network slice, or a UE) overlaps with the target 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).

[0043] Additionally or alternatively, the rApp-related information may indicate priority information (rApp priority) associated with each of one or more rApps. This priority information (rApp priority) may be used by the Near-RT RIC 3 to compare with priority information (xApp priority) associated with xApps 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 grant control performed or requested by the xApp. This operation may be performed by the Near-RT RIC platform 31. Alternatively, this operation may be performed by the Near-RT RIC 3 by executing a specific xApp for mediation or orchestration between rApps and xApps.

[0044] For example, if there is a conflict or possibility of a 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. Because the control period of the xApp is generally shorter than that of the rApp, if the Near-RT RIC 3 executes the control of the xApp as is, the control by the xApp will be given priority over the control by the rApp.

[0045] 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 determines 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 influence of the control by the rApp is relatively small, and limit the control by the xApp to only the selected UEs.

[0046] FIG. 5 shows a specific example of rApp-related information. In the example of FIG. 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 associated with attributes (e.g., control targets, control contents) or features requested or specified by the Near-RT RIC 3 in the rApp Info List IE 501.

[0047] The 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 the identifier of each cell, and a Control Parameter IE 508 that indicates cell-related parameters controlled by the rApp.

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

[0049] The configuration example shown in Fig. 5 may be modified as appropriate. For example, if all rApps have the same predetermined priority, or if rApps always take priority over xApps, the Use Case Priority Level IE 504 indicating the 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).

[0050] The operation of the Non-RT RIC 2 and Near-RT RIC 3 described in this embodiment allows 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).

[0051] The following describes an example of a procedure for subscribing to a notification service for rApp-related information provided by the Non-RT RIC 2. Figures 6 to 8 show an example of a procedure for subscribing to a notification service for rApp-related information.

[0052] In the example of Figure 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 called 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 called a SUBSCRIPTION RESPONSE message. Steps 605 and 606 are similar to steps 201 and 202 of FIG. 2 .

[0053] In contrast, in the example of Figure 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). This message may be referred to as a SUBSCRIPTION RESPONSE message. Step 703 is similar to step 301 of Figure 3.

[0054] Steps 801 and 802 in Figure 8 are similar to steps 601 and 602 in Figure 6. That is, 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). On the other hand, step 803 in Figure 8 is similar to step 702 in Figure 7. That is, the Non-RT RIC 2 sends a notification indicating that the subscription request has been approved (or successfully processed) directly to the Non-RT RIC 2 via the A1 interface. Step 804 is similar to step 301 in Figure 3.

[0055] When a subscription to a notification service for rApp-related information is no longer needed, 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 using signaling similar to that of the procedure for subscribing to a notification service described using 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 the subscription deletion to the Near-RT RIC 3 via the A1 interface or via the O1 interface and SMO Framework 1.

[0056] Second Embodiment A configuration example of a system according to this embodiment may be the same as the example shown in Fig. 1. This embodiment provides an improvement over the signaling described in the first embodiment.

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

[0058] 9 shows an example of the operation of the Non-RT RIC 2 and the Near-RT RIC 3. In step 901, the Near-RT RIC 3 requests detailed information related 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 from the Non-RT RIC 2 via the A1 interface. The name of the message carrying the request may be a QUERY APPINFORMATION message. The message in step 901 includes information about one or more xApps running in the Near-RT RIC 3.

[0059] In step 902, the Non-RT RIC 2 responds to the Near-RT RIC 3 with a message containing detailed information. The name of the message may be a QUERY APPIMFORMATION RESPONSE message. More specifically, the Non-RT RIC 2 identifies one or more rApps that conflict or may 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.

[0060] 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, if there is or may be a 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 or may be a 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 the control by the rApp does not conflict with the control by the xApp.

[0061] 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 about one or more xApps to the Non-RT RIC 2 and request the Non-RT RIC 2 to return information about one or more rApps that conflict or may conflict with these one or more xApps. In response to the request from the Near-RT RIC 3, the Non-RT RIC 2 may send information about one or more rApps that may conflict with one or more specific xApps to the Near-RT RIC 3. The return message (step 902) sent from the Non-RT RIC 2 to the Near-RT RIC 3 may include, for example, all of the information elements shown in FIG. 5.

[0062] 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 the control of the rApp(s), or about one or more xApps for which the Near-RT RIC 3 wishes to avoid conflicts with the rApp(s).

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

[0064] 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 that indicates the identifier of each cell, and a Control Parameter IE 1008 that indicates 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 resides that is affected by the control of the xApp.

[0065] The configuration example shown in Fig. 10 may be modified as appropriate. For example, if all xApps have the same predetermined priority, or if rApps always take priority over xApps, the Use Case Priority Level IE 1004 indicating the 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).

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

[0067] Third Embodiment A configuration example of a system according to this embodiment may be the same as the example shown in Fig. 1. This embodiment provides an improvement over the signaling described in the first embodiment.

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

[0069] 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 related to the control content and / or targets affected by the control of rApps that may conflict with one or more specific xApps from the Non-RT RIC 2 via the A1 interface. The name of the message carrying the request may be a QUERY APPINFORMATION 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 requested control or performed 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 within the Near-RT RIC 3.

[0070] In step 1102, the Non-RT RIC 2 responds to the Near-RT RIC 3 with a message containing detailed information. The name of the message may be a 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 performed by or affected by the requested control of 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 indicating the identified one or more xApps to the Near-RT RIC 3. The format of the detailed information sent in step 902 may be similar to the xApp-related information 1000 shown in FIG. 10.

[0071] The Near-RT RIC 3 may perform processing to avoid conflicts between rApp(s) and xApp(s) based on the received rApp 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 also consider rApp-related information received in the procedure of FIG. 2 or 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 an 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 an rApp with which it may conflict, 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.

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

[0073] Next, exemplary configurations of the SMO framework 1, Non-RT RIC 2, and Near-RT RIC 3 according to the above-described embodiments will be described below. Fig. 12 is a block diagram showing an exemplary 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 Fig. 12.

[0074] In the example of Figure 12, the 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 also 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, a network adapter, or any combination thereof.

[0075] One or both of the memory 1220 and the mass storage 1230 may include a computer-readable medium having stored thereon one or more sets of instructions, which may be located partially or completely in memory within one or more processors 1210. These instructions, when executed on 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 above embodiments.

[0076] As described with reference to FIG. 12 , each of the processors included in the SMO framework 1, the Non-RT RIC 2, and the 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) that, when loaded into a computer, cause the computer to perform one or more functions described in the embodiments. The programs may be stored in 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) disc or other optical disk storage, magnetic cassette, magnetic tape, magnetic disk storage, or other magnetic storage device. The programs may also be transmitted on a transitory computer-readable medium or 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.

[0077] The above-described embodiments are merely examples of application of the technical ideas obtained by the inventors of the present invention. In other words, the technical ideas are not limited to the above-described embodiments, and various modifications are possible.

[0078] For example, some or all of the above embodiments can be described as, but are not limited to, the following supplementary notes.

[0079] (Supplementary Note 1) A first Radio Access Network (RAN) Intelligent Controller (RIC) comprising: at least one memory; and at least one processor coupled to the at least one memory, wherein the at least one processor is configured to send application-related information about one or more first applications running in the first RIC to a second RIC disposed between the first RIC and one or more Radio Access Network (RAN) nodes. (Supplementary Note 2) The first RIC of Supplementary Note 1, wherein 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 running in the second RIC. (Supplementary Note 3) The first RIC of Supplementary Note 1 or 2, wherein the application-related information includes information indicating a target or content of control performed or requested by each of the one or more first applications. (Supplementary Note 4) The first RIC of Supplementary Note 1 or 2, wherein the application-related information indicates 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. (Supplementary Note 5) The first RIC of any one of Supplements 1 to 4, wherein the application-related information indicates first priority information associated with each of the one or more first applications. (Supplementary Note 6) The first RIC of Supplementary Note 5, wherein the first priority information is used by the second RIC to compare with second priority information associated with a second application running in the second RIC.(Supplementary Note 7) The first RIC of any one of Supplements 1 to 6, wherein 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. (Supplementary Note 8) The first RIC of any one of Supplements 1 to 7, wherein 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. (Supplementary Note 9) The first RIC of any one of Supplements 1 to 7, wherein the at least one processor is configured to send the application-related information indirectly to the second RIC via a second interface between a Service Management and Orchestration (SMO) framework including the first RIC and the second RIC. (Supplementary Note 10) The first RIC of any one of Supplements 1 to 9, wherein the at least one processor is configured to receive a subscription request from the second RIC to request the application-related information. (Supplementary Note 11) The first RIC of Supplementary Note 10, wherein the at least one processor is configured to receive the subscription request directly from the second RIC via a first interface between the first RIC and the second RIC. (Supplementary Note 12) The first RIC of Supplementary Note 10, wherein the at least one processor is configured to receive the subscription request indirectly from the second RIC via a second interface between the second RIC and a Service Management and Orchestration (SMO) framework that includes the first RIC.(Supplementary Note 13) The first RIC of any one of Supplements 1 to 12, wherein the at least one processor is configured to: receive a request from the second RIC including information about one or more second applications running in the second RIC, and in response to the request, send to the second RIC detailed information about one or more first applications running in the first RIC that conflict or may conflict with the one or more second applications. (Supplementary Note 14) The first RIC of any one of Supplements 1 to 12, wherein the at least one processor is configured to: in response to a request from the second RIC, send to the second RIC information indicating one or more second applications running in the second RIC that are affected by control performed or requested by the one or more first applications. (Supplementary Note 15) The first RIC according to any one of Supplements 1 to 14, wherein the first RIC is an Open Radio Access Network (O-RAN) Non-Real-Time (Non-RT) RIC, and the second RIC is an O-RAN Near-Real-Time (Near-RT) RIC. (Supplementary Note 16) A second Radio Access Network (RAN) Intelligent Controller (RIC) disposed between the first RIC and one or more Radio Access Network (RAN) nodes, comprising: at least one memory; and at least one processor coupled to the at least one memory, wherein the at least one processor is configured to receive, from the first RIC, application-related information about one or more first applications running in the first RIC. (Supplementary Note 17) The second RIC of Supplementary Note 16, wherein the at least one processor is configured to determine, based on the application-related information, 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.(Supplementary Note 18) The second RIC according to Supplementary Note 16 or 17, wherein the application-related information includes information indicating a target or content of control performed or requested by each of the one or more first applications. (Supplementary Note 19) The second RIC according to Supplementary Note 16 or 17, wherein the application-related information indicates 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 requested by each first application. (Supplementary Note 20) The second RIC according to any one of Supplements 16 to 19, wherein the application-related information indicates first priority information associated with each of the one or more first applications. (Supplementary Note 21) The second RIC of Supplementary Note 20, wherein the at least one processor is configured to compare the first priority information with second priority information associated with a second application running in the second RIC and determine whether to grant control performed or requested by the second application. (Supplementary Note 22) The second RIC of any one of Supplements 16 to 21, wherein 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. (Supplementary Note 23) The second RIC of any one of Supplements 16 to 21, wherein the at least one processor is configured to receive the application-related information indirectly from the first RIC via a second interface between the second RIC and a Service Management and Orchestration (SMO) framework including the first RIC. (Supplementary Note 24) The second RIC according to any one of Supplementary Notes 16 to 23, wherein the at least one processor is configured to send a subscription request to the first RIC to request the application-related information.(Supplementary Note 25) The second RIC of Supplementary Note 24, wherein the at least one processor is configured to send the subscription request directly to the first RIC via a first interface between the first RIC and the second RIC. (Supplementary Note 26) The second RIC of Supplementary Note 24, wherein the at least one processor is configured to send the subscription request indirectly to the first RIC via a second interface between the second RIC and a Service Management and Orchestration (SMO) framework including the first RIC. (Supplementary Note 27) The second RIC of any one of Supplements 16 to 26, wherein the at least one processor is configured to: send a request to the first RIC including information about one or more second applications running in the second RIC; and receive from the first RIC detailed information about one or more first applications running in the first RIC that conflict or may conflict with the one or more second applications. (Supplementary Note 28) The second RIC according to any one of Supplements 16 to 26, wherein the at least one processor is configured to request the first RIC to send information indicating 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. (Supplementary Note 29) The second RIC according to any one of Supplements 16 to 28, wherein the first RIC is an Open Radio Access Network (O-RAN) Non-Real-Time (Non-RT) RIC, and the second RIC is an O-RAN Near-Real-Time (Near-RT) RIC.(Supplementary Note 30) A method performed by a first Radio Access Network (RAN) Intelligent Controller (RIC), comprising sending application-related information about one or more first applications running in the first RIC to a second RIC located between the first RIC and one or more radio access network (RAN) nodes. (Supplementary Note 31) A method performed by a second Radio Access Network (RAN) Intelligent Controller (RIC), located between a first RIC and one or more radio access network (RAN) nodes, comprising receiving, from the first RIC, application-related information about one or more first applications running in the first RIC. (Supplementary Note 32) A program causing a computer to perform a method for a first Radio Access Network (RAN) Intelligent Controller (RIC), comprising sending application-related information about one or more first applications running in the first RIC to a second RIC located between the first RIC and one or more radio access network (RAN) nodes. (Supplementary Note 33) A program 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 method comprising receiving, from the first RIC, application-related information about one or more first applications running within the first RIC.

[0080] This application claims priority based on Japanese Patent Application No. 2022-154361, filed September 28, 2022, the disclosure of which is incorporated herein in its entirety.

[0081] 1 SMO Framework 2 Non-RT RIC 3 Near-RT RIC 4 E2 Node 1110 Processor 1120 Memory 1130 Mass Storage

Claims

1. a first Radio Access Network (RAN) Intelligent Controller (RIC), means for 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; The first RIC.

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; The first RIC of claim 1 .

3. the application-related information indicating first priority information associated with each of the one or more first applications; A first RIC according to claim 1 or 2.

4. the sending means 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 a radio access network (RAN) control. A first RIC according to claim 1 or 2.

5. A method for receiving a request from the second RIC, the request including information about one or more second applications executing within the second RIC; means for transmitting, in response to said request, detailed information to said second RIC about one or more first applications operating within said first RIC that conflict or may conflict with said one or more second applications; Further comprising: A first RIC according to claim 1 or 2.

6. The method further comprises: in response to a request from the second RIC, sending information to the second RIC indicating 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 claim 1 or 2.

7. A second Radio Access Network (RAN) Intelligent Controller (RIC) disposed between the first RIC and one or more Radio Access Network (RAN) nodes, comprising: means for receiving, from the first RIC, application-related information about one or more first applications running within the first RIC; Second RIC.

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

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

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