Ran intelligent controller (RIC) and method thereof

Abstract

To enable a Non-RT RAN Intelligent Controller (RIC) to specify Near-RT RAN Intelligent Controller (RIC) applications (xApps) to be used for A1 policy enforcement.SOLUTION: A first RIC sends a request for policy enforcement to a first RIC and a second RIC located between one or more radio access network nodes, via an interface between the first RIC and the second RIC, the request or policy includes an identifier specifying an application hosted in the second RIC and selected or assigned for enforcement of the policy.SELECTED DRAWING: Figure 3

Description

[Technical field]

[0001] The present disclosure relates to a logic function, controller, or system for the control and optimization of a radio access network. [Background technology]

[0002] The Open Radio Access Network (O-RAN) Alliance is a community of mobile communication operators, vendors, and research and academic institutions, whose mission is to reconstruct radio access networks (RANs) to be more intelligent, open, virtualized, and fully interoperable. The O-RAN Alliance is conducting technical studies on architectures including Non-Real-Time (Non-RT) RAN Intelligent Controller (RIC) and Near-RT RIC, and is providing technical specifications related to these (see, for example, non-patent documents 1-10).

[0003] The Non-RT RIC is a logical function within the Service Management and Orchestration (SMO) framework (see, for example, non-patent documents 1-7). 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 polices, 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 configuration of the network, and obtain additional information related to the network.

[0006] The SMO framework provides various logical functions that are not anchored within the 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. The O2 terminations allow the SMO framework to exchange messages with the O-Cloud platform over the O2 interface.

[0007] The O-Cloud platform is a cloud computing platform consisting of a collection of physical infrastructure nodes that meet O-RAN requirements hosting relevant O-RAN functions, supporting software components, and appropriate management and orchestration functions (see, for example, Non-Patent Documents 1 and 9). Relevant O-RAN functions include, for example, Near-RT RIC and E2 nodes. The O-Cloud platform is also simply called O-Cloud. External termination allows the SMO framework or the Non-RT RIC framework to exchange messages with external entities over interfaces outside the scope of O-RAN.

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

[0009] The Near-RT RIC is a logical function that enables near real-time control and optimization of RAN elements and resources through fine-grained data collection and actions over the E2 interface (see, for example, Non-Patent Documents 1 and 8). The Near-RT RIC hosts a set of applications called Near-RT RIC applications (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 and provision of Near-RT RIC Application Programming Interfaces (APIs). The interface terminations include E2 terminations, A1 terminations, and O1 terminations, which provide termination of the E2 interface, the A1 interface, and the O1 interface, respectively.

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

[0011] Near-RT RIC APIs include A1-related APIs, E2-related APIs, and Management APIs, among other APIs. A1-related APIs enable xApps to access A1-related functions related to A1 policy enforcement and transfer of A1 enrichment information. Management APIs include Machine Learning (ML) model-related APIs for xApps and Fault, Configuration, Accounting, Performance, and Security (FCAPS)-related APIs. FCAPS-related APIs include xApp Registration API and Configuration API. xApp Registration API supports registration of xApp to Near-RT RIC platform after it is deployed. Configuration API supports transfer of configurations from SMO to xApp.

[0012] xApps are applications designed to run in the Near-RT RIC. xApps run 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. xApps can be deployed in the Near-RT RIC by the SMO and can be registered in the Near-RT RIC via the xApp registration API of the Near-RT RIC (see, for example, non-patent documents 8 and 10).

[0013] In the following, A1 policy management over the A1 interface is described (see, for example, non-patent documents 4-6). The Non-RT RIC defines the A1 policy that is provided to the Near-RT RIC over the A1 interface. The A1 policy is a declarative policy that includes statements about policy objectives and policy resources that are applied to User Equipment (UE) and cells. The objective of the A1 policy is to guide the performance of the RAN towards the overall goal expressed in the RAN intent. In other words, the objective of the A1 policy is to enable the Non-RT RIC function of the SMO to guide the Near-RT RIC function, and thus the RAN, to better meet the RAN intent. The RAN intent is an expression of high-level operational or business goals that the RAN should achieve, and allows the operator to specify the desired Service Level Agreements (SLAs) that the RAN should meet for all users or a class of users in a particular area in a certain period of time.

[0014] The Non-RT RIC manages the A1 policy based on A1 policy feedback and network conditions provided via O1. The Non-RT RIC uses O1 observables to continuously evaluate the impact of the A1 policy towards achieving the RAN intent and decides to issue or update the goals represented by the A1 policy based on its internal conditions. The Near-RT RIC acts based on its internal capabilities or applications, the configuration received via O1, and the temporary A1 policy received via A1.

[0015] The type of A1 policy is identified by a policy type identifier (PolicyTypeId). Different policy types have different PolicyTypeIds. Based on the PolicyTypeId, a schema is identified and used for the creation, validation, formulation, and status query of A1 policies of that type.

[0016] An A1 policy is identified by a policy identifier (PolicyId) assigned by the Non-RT RIC, which is locally unique within the Non-RT RIC and is sent in a policy request operation carrying representations of the A1 policy.

[0017] An A1 policy consists of a scope identifier and one or more policy statements. The scope identifier represents the subjects to which the policy statements apply (e.g., UEs, QoS flows, or cells). Policy statements express goals to the Near-RT RIC and cover policy objectives and policy resources.

[0018] More specifically, an A1 policy is identified by a policy identifier (policyId) and represented as a JavaScript Object Notation (JSON) object called a policy object (PolicyObject). A policy object contains a scope identifier and at least one policy statement. At least one policy statement may contain one or more policy objective statements and / or one or more policy resource statements. The policy identifier (policyId) is assigned by the A1 Policy Management Service (A1-P) consumer, i.e., a Non-RT RIC, at the time of policy creation. Policy feedback for a particular A1 policy is subscribed to by providing a callback Uniform Resource Identifier (URI) at the time of policy creation. [Prior art documents] [Non-patent literature]

[0019] [Non-Patent Document 1] O-RAN ALLIANCE Working Group 1, "O-RAN Architecture Description 9.0", O-RAN.WG1.OAD-R003-v09.00, June 2023 [Non-Patent Document 2] O-RAN ALLIANCE Working Group 2, "O-RAN Non-RT RIC & A1 interface: Use Cases and Requirements 7.0", O-RAN.WG2.Use-Case-Requirements-v07.00, June 2023 [Non-Patent Document 3] O-RAN ALLIANCE Working Group 2, "O-RAN Non-RT RIC Architecture 3.0", O-RAN.WG2.Non-RT-RIC-ARCH-R003-v03.00, June 2023

Non-licensed Document 4

Non-licensed Document 5

Non-licensed Document 6

Non-licensed Document 7

Non-licensed literature 9

[0020] According to current O-RAN technical specifications (e.g., Non-Patent Documents 4-6), a Non-RT RIC can request the Near-RT RIC to create (or set up) an A1 policy via the A1 interface. However, the Non-RT RIC cannot specify to the Near-RT RIC the xApp to be used for enforcing or achieving the A1 policy with respect to the creation of the A1 policy.

[0021] Enabling a Non-RT RIC to specify an xApp to be used for A1 policy enforcement may be beneficial for a canary release of an xApp, as an example. A Non-RT RIC can place an xApp in a Near-RT RIC via an O1 interface (or an O2 interface). A Non-RT RIC can also request a Near-RT RIC via an A1 interface to create an A1 policy that will be assigned to the xApp. The Near-RT RIC can select the xApp for enforcement of the A1 policy and assign the A1 policy to the xApp. When a new version of the xApp is subsequently released, it may be preferable to employ a canary release to reduce the risk of introducing the new version of the xApp. Specifically, it may be preferable for the new version xApp to enforce the new A1 policy only for a part (e.g., cell C) of the scope (e.g., cells A, B, and C) of the A1 policy assigned to the old version xApp, while continuing to enforce the updated A1 policy in the scope (e.g., cells A and B) in which the old version xApp was updated. However, the Non-RT RIC cannot specify to the Near-RT RIC the xApp to be used to enforce or achieve the A1 policy when creating the A1 policy. Therefore, even if the Non-RT RIC (or SMO) places both the old version xApp and the new version xApp on the Near-RT RIC, the updated A1 policy (e.g., scoped to cells A and B) and the new A1 policy (e.g., scoped to cell C) are not necessarily assigned to these two versions of xApp as the Non-RT RIC desires.

[0022] Allowing the Non-RT RIC to specify the xApp used for A1 policy enforcement may be useful for other purposes as well as the canary release of xApps described above. Specifically, this may be broadly useful to allow multiple A1 policies of the same policy type to be assigned to different xApps as intended by the Non-RT RIC. Here, different xApps refers to multiple xApps that are separately deployed and registered in the Near-RT RIC. As described with respect to the canary release, the different xApps may be older and newer versions of the same xApp software. Alternatively, the different xApps may be multiple xApps created by different software vendors for the same or similar RAN optimization purposes. Alternatively, the different xApps may be different application instances of the same version xApp running on different virtual machines, containers, or pods.

[0023] One of the objectives that the embodiments disclosed in this specification aim to achieve is to provide an apparatus, a method, and a program that contribute to enabling a Non-RT RIC to specify an xApp to be used for A1 policy enforcement. It should be noted that this objective is only one of the objectives that the embodiments disclosed in this specification aim to achieve. Other objectives or problems and novel features will become apparent from the description of this specification or the accompanying drawings. [Means for solving the problem]

[0024] In a first aspect, a first RIC is configured to send a first request for enforcement of a first policy to a second RIC located between the first RIC and one or more RAN nodes via a first interface between the first RIC and the second RIC, the first request or the first policy including a first identifier specifying an application hosted in the second RIC and selected or assigned for enforcement of the first policy.

[0025] In a second aspect, a method performed by a first RIC includes sending a first request for enforcement of a first policy to a second RIC located between the first RIC and one or more RAN nodes via a first interface between the first RIC and the second RIC, the first request or the first policy including a first identifier specifying an application hosted at the second RIC and selected or assigned for enforcement of the first policy.

[0026] In a third aspect, a second RIC disposed between a first RIC and one or more RAN nodes is configured to receive a first request for enforcement of a first policy from the first RIC via a first interface between the first RIC and the second RIC, the first request or the first policy including a first identifier specifying an application hosted in the second RIC and to be selected or assigned for enforcement of the first policy.

[0027] In a fourth aspect, a method performed by a second RIC interposed between a first RIC and one or more RAN nodes includes receiving from the first RIC a first request for enforcement of a first policy via a first interface between the first RIC and the second RIC, the first request or the first policy including a first identifier specifying an application hosted at the second RIC and to be selected or assigned for enforcement of the first policy.

[0028] In a fifth aspect, a program includes a set of instructions (software code) for causing a computer to carry out the method according to the second or fourth aspect above when the program is loaded into the computer. Effect of the Invention

[0029] According to the above-described aspects, it is possible to provide an apparatus, a method, and a program that contribute to enabling a Non-RT RIC to specify an xApp to be used for A1 policy enforcement. [Brief description of the drawings]

[0030] [Figure 1] FIG. 1 illustrates an example of an O-RAN logical architecture, in accordance with one or more embodiments. [Diagram 2] A diagram illustrating an example of the functionality of a Non-RT RIC and a Near-RT RIC with respect to A1 policy management, in accordance with one or more embodiments. [Diagram 3] 1 is a sequence diagram illustrating an example of the operation of a Non-RT RIC and a Near-RT RIC, in accordance with one or more embodiments. [Figure 4] FIG. 13 illustrates an example of an A1 policy structure, in accordance with one or more embodiments. [Diagram 5] FIG. 11 illustrates an example of a format for a policy object, in accordance with one or more embodiments. [Figure 6] 1 is a sequence diagram illustrating an example of the operation of a Non-RT RIC and a Near-RT RIC, in accordance with one or more embodiments. [Figure 7] 1 is a sequence diagram illustrating an example of the operation of a Non-RT RIC and a Near-RT RIC, in accordance with one or more embodiments. [Figure 8] FIG. 2 illustrates an example of the operation of a Non-RT RIC, in accordance with one or more embodiments. [Figure 9A] FIG. 1 is a sequence diagram illustrating an example of operation of the SMO framework, a Non-RT RIC, and a Near-RT RIC, in accordance with one or more embodiments. [Figure 9B] FIG. 1 is a sequence diagram illustrating an example of operation of the SMO framework, a Non-RT RIC, and a Near-RT RIC, in accordance with one or more embodiments. [Figure 9C]FIG. 1 is a sequence diagram illustrating an example of operation of the SMO framework, a Non-RT RIC, and a Near-RT RIC, in accordance with one or more embodiments. [Figure 9D] FIG. 1 is a sequence diagram illustrating an example of operation of the SMO framework, a Non-RT RIC, and a Near-RT RIC, in accordance with one or more embodiments. [Figure 10] FIG. 2 illustrates an example of the operation of a Non-RT RIC, in accordance with one or more embodiments. [Figure 11] FIG. 2 illustrates an example of the operation of a Non-RT RIC, in accordance with one or more embodiments. [Figure 12] FIG. 2 illustrates an example of the operation of a Non-RT RIC, in accordance with one or more embodiments. [Figure 13] 1 is a block diagram illustrating an example configuration of a Non-RT RIC and a Near-RT RIC, in accordance with one or more embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0031] In the following, specific embodiments will be described in detail with reference to the drawings. In each drawing, the same or corresponding elements are denoted by the same reference numerals, and duplicated descriptions will be omitted as necessary for clarity of explanation.

[0032] Each of the embodiments described below may be used alone, or two or more of the embodiments may be appropriately combined. These embodiments may have different novel features. Therefore, these embodiments may contribute to achieving different objectives or solving different problems, and may contribute to achieving different effects.

[0033] Each drawing is merely an example for describing one or more embodiments. Each drawing may relate not only to one particular embodiment, but to one or more other embodiments. As can be understood by those skilled in the art, various features or steps described with reference to any one drawing may be combined with features or steps shown in one or more other drawings to create an embodiment not explicitly shown or described, for example. Not all features or steps shown in any one drawing are necessary to describe an exemplary embodiment, and some features or steps may be omitted. The order of steps described in any drawing may be changed as appropriate.

[0034] The following embodiments are described primarily with respect to the Non-RT RIC and Near-RT RIC according to the O-RAN technical specifications, however, these embodiments may be applied to other systems supporting similar technologies to the O-RAN Non-RT RIC and Near-RT RIC.

[0035] As used herein, depending on the context, "if" may be interpreted to mean "when," "while," "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.

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

[0037] The SMO framework 1 includes the 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, an O1 termination, an O2 termination, and an external termination. The O1 termination enables the SMO framework 1 to exchange messages with a Near-RT RIC 3 and one or more E2 nodes 4 over an O1 interface. The O2 termination enables the SMO framework 1 to exchange messages with the O-Cloud over an O2 interface. The external termination enables the SMO framework 1 or the Non-RT RIC framework 21 to exchange messages with external entities over an interface outside the scope of the O-RAN.

[0038] The O-Cloud is a cloud computing platform consisting of a collection of physical infrastructure nodes that meet O-RAN requirements hosting relevant O-RAN functions, supporting software components, and appropriate management and orchestration functions. The O-Cloud may be referred to as a virtualized or cloud platform. The relevant O-RAN functions include, for example, Near-RT RIC and E2 node. That is, the functions of Near-RT RIC 3 and E2 node 4 shown in Figure 1 can be implemented as RAN network function applications running on the O-Cloud platform. The O-Cloud may provide Deployment Management Services (DMS), Infrastructure Management Services (IMS), HW Accelerator Manager, and Acceleration Abstraction Layer (AAL) functions. The DMS provides APIs to manage the lifecycle of virtualized (or containerized or cloudified) RAN network functions (e.g., Near-RT RIC, O-CU, O-DU). The O-Cloud platform may use virtual machines (VMs) built and managed using OpenStack or the like, or containers built and managed using Kubernetes or the like, or both, to implement virtualized (or containerized or cloudified) RAN network functions.

[0039] 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 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 enables 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.

[0040] 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 in the enforcement status of A1 policies.

[0041] The 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 from the network (e.g., Near-RT RIC 3 and E2 nodes 4), to provision configuration changes in the network, to obtain performance information related to the network, and to obtain additional information related to the network.

[0042] 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 functionality exposed by the Non-RT RIC 2 to provide value-added services to support and facilitate optimization and operation of the network (e.g., Near-RT RIC 3 and E2 nodes 4), such as A1 policy guidance, A1 enrichment information, configuration management, and data analytics.

[0043] 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 (eg, UE basis, Cell basis) data collection and actions over 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, among other functions, interface terminations and provision of Near-RT RIC APIs. The interface terminations include an E2 termination, an A1 termination, and an O1 termination, which provide termination of the E2 interface, the A1 interface, and the O1 interface, respectively.

[0044] 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 include, for example, Key Performance Measurement (KPM), RAN control (RC), or Network Interface (NI), or any combination thereof.

[0045] For NR access, the E2 node 4 may include one or more O-CU-CPs, one or more O-CU-UPs, one or more O-DUs, or any combination thereof, whereas for E-UTRA access, the E2 node 4 may include one or more O-eNBs.

[0046] The Near-RT RIC APIs include A1-related APIs, E2-related APIs, and management APIs, among other APIs. The A1-related APIs enable xApps 32 to access A1-related functionality related to A1 policy enforcement and transfer of A1 enrichment information. The management APIs include ML model-related APIs and FCAPS-related APIs for xApps 32. The FCAPS-related APIs include an xApp registration API and a configuration API. The xApp registration API supports registration of each of the xApps 32 to the Near-RT RIC platform 31 after each of the xApps 32 has been deployed. The configuration API supports transfer of configurations from the SMO 1 to each of the xApps 32.

[0047] 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 and calculates and sends control actions back to the E2 node 4 as needed.

[0048] Some of the xApps 32 may be containerized ML applications, each of which includes a trained ML model and performs inference using the ML model. The Non-RT RIC 2 may generate such xApps, i.e., containerized ML applications, and deploy them to the Near-RT RIC 3 using the O1 or O2 interface. That is, the ML model may be deployed as an xApp or may be placed in an xApp instance and may be updated via xApp software updates. The Near-RT RIC 3 may act as an ML model inference host. The Non-RT RIC 2 or the SMO 1 may act as an ML model training host.

[0049] In the following, A1 policy management over the A1 interface is described. FIG. 2 shows an example of the functionality of the Non-RT RIC 2 and Near-RT RIC 3 with respect to the A1 Policy Management Service (A1-P). The A1 interface uses the A1 Application Protocol (A1AP). The A1AP provides APIs for services defined in the A1 interface, including A1-P. With respect to A1-P, the Non-RT RIC 2 includes or provides an A1-P consumer 25, while the Near-RT RIC 3 includes or provides an A1-P producer 35. Requests are sent from the A1-P consumer 25, and responses and notifications are sent from the A1-P producer 35. The terms consumer and producer do not imply a direction of data transfer over the A1 interface.

[0050] The Non-RT RIC 2 defines the A1 policy that is provided to the Near-RT RIC 3 over the A1 interface. The A1 policy is a declarative policy that includes statements about policy objectives and policy resources that are applied to UEs and cells. The purpose of the A1 policy is to guide the performance of the RAN towards the overall goal expressed in the RAN intent. In other words, the purpose of the A1 policy is to enable the Non-RT RIC 2 in the SMO 1 to guide the Near-RT RIC 3, and thus the RAN, to better meet the RAN intent. The RAN intent is an expression of high-level operational or business goals that the RAN should achieve and allows the operator to specify the desired SLAs that the RAN should meet for all users or a class of users in a particular area for a certain period of time.

[0051] The Non-RT RIC 2 manages the A1 policies based on A1 policy feedback and network conditions provided via O1. The Non-RT RIC 2 continuously evaluates the impact of the A1 policies towards achieving the RAN intent, for example using O1 observables, and decides to issue or update the goals represented in the A1 policies based on its internal conditions. The Near-RT RIC 3 acts based on its internal functions or applications (xApps 32), configuration received via O1, and temporary A1 policies received via A1.

[0052] The type of A1 policy is identified by a policy type identifier (PolicyTypeId). Different policy types have different PolicyTypeIds. Based on the PolicyTypeId, a schema is identified and used for the creation, validation, formulation, and status query of A1 policies of that type.

[0053] The A1 policy is identified by a policy identifier (PolicyId) assigned by the Non-RT RIC 2. The policy identifier (PolicyId) is locally unique within the Non-RT RIC 2 and is sent in a policy request operation carrying representations of the A1 policy.

[0054] An A1 policy consists of a scope identifier and one or more policy statements. The scope identifier represents the subject to which the policy statements apply (e.g., one or more UEs, one or more QoS flows, or one or more cells). Policy statements express goals to the Near-RT RIC 3 and cover policy objectives and policy resources.

[0055] More specifically, an A1 policy is identified by a policy identifier (policyId) and represented as a JSON object called a policy object (PolicyObject). A policy object contains a scope identifier and at least one policy statement. The at least one policy statement may contain one or more policy objective statements or one or more policy resource statements or both. The policy identifier (policyId) is assigned by the A1 Policy Management Service (A1-P) Consumer 25, i.e., the Non-RT RIC 2, at the time of policy creation. Policy feedback for a particular A1 policy is subscribed to by providing a callback URI at the time of policy creation.

[0056] Identifiers that can be used as scope identifiers in the A1 policy are defined as data types. A scope identifier can be composed of a single or a combination of these data types. Specifically, a scope identifier can be a UE identifier (Ueid), a UE group identifier (GroupId), a slice identifier (SliceId), a QoS identifier (QosId), or a cell identifier (CellId), or any combination thereof.

[0057] Creation and enforcement of A1 policies can be done on a per-policy basis. Thus, an operation to create multiple A1 policies can be a sequence of operations to create a single A1 policy. The operation to create a single A1 policy is based on an HTTP PUT. The A1 policy to be created is identified by a URI containing a policyId in the request line of the PUT request. The message body of the PUT request contains a policy object (PolicyObject). The procedure for creating a single A1 policy is as follows: The A1-P Consumer 25 (i.e., Non-RT RIC 2) generates a policyId and sends an HTTP PUT request to the A1-P Producer 35 (i.e., Near-RT RIC 3). The target URI identifies the resource (policyId) under which to create the new policy. The message body carries the PolicyObject. The A1-P Producer 35 returns an HTTP PUT response. On success, "201 Created" is returned, the location header carries the URI of the new policy, and the message body carries the PolicyObject. On failure, an appropriate error code is returned and the message body may contain additional error information. Note that the A1-P consumer 25 can request policy status updates for the created policy by including notificationDestination as a query parameter in a PUT request.

[0058] Similar to creating an A1 policy, updating an A1 policy can be done on a per-policy basis. Thus, an operation to update multiple A1 policies can be a sequence of operations to create a single A1 policy. An operation to update a single A1 policy is based on an HTTP PUT. The policy to be updated is identified by a URI containing a policyId in the request line of the PUT request. The message body of the PUT request contains the PolicyObject for the policy to be updated.

[0059] Note that the above description of existing operations, procedures, and signaling on the A1 interface for A1 policy management is based on the O-RAN technical specifications at the time of filing of this application. Several embodiments described below provide improvements to these existing operations, procedures, and signaling for A1 policy management. Therefore, some of the existing operations, procedures, and signaling related to the A1 policy management described above may be appropriately modified in the following embodiments. Additionally or alternatively, the following embodiments may provide additional operations, procedures, or signaling in addition to or instead of the existing operations, procedures, and signaling related to the A1 policy management described above.

[0060] <First embodiment> An example of the configuration of the system according to this embodiment may be similar to the example shown in Figures 1 and 2. This embodiment provides an improvement in creating (and updating) the A1 policy.

[0061] 3 shows an example of the operation of the Non-RT RIC 2 and the Near-RT RIC 3. In step 301, the Non-RT RIC 2 sends a request to create an A1 policy to the Near-RT RIC 3 via the A1 interface. The request may be an HTTP PUT request message. The request includes the A1 policy (specifically, a policy object) to be created.

[0062] The request of step 301 or the A1 policy (or policy object) included in the request includes an identifier that specifies the xApp to be selected or assigned for enforcement of the A1 policy. The identifier may be referred to as xApp identification information. The identifier may be an identifier (i.e., xApp ID) assigned by the Near-RT RIC 3 to distinguish between multiple xApps 32 registered with the Near-RT RIC 3. In some implementations, the identifier may distinguish between multiple xApps that include different ML models. Additionally or alternatively, the identifier may distinguish between applications running on different virtual machines, containers, or pods. Note that a pod is the smallest deployable unit that can be created by software such as Kubernetes to manage containerized applications. A pod contains one or more application containers, provides shared storage and network resources for the containers, and specifies how the containers should be run. A pod models an application-specific "logical host" and contains one or more relatively tightly coupled application containers.

[0063] The A1 policy creation request of step 301 causes the Near-RT RIC 3 to select or allocate an xApp associated with the identifier (e.g., xApp ID) specified by the request of step 301 or the A1 policy for enforcing the A1 policy. In one example, in response to receiving the request of step 301, the A1 termination function in the Near-RT RIC platform 31 may send an xApp selection request containing the received A1 policy (and identifier) ​​to an xApp repository function in the Near-RT RIC platform 31, thereby triggering execution of an xApp selection process. The xApp repository function may determine whether the xApp specified by the received identifier is suitable for enforcing the A1 policy. If the xApp specified by the received identifier is suitable for enforcing the A1 policy, the xApp repository function may notify the A1 termination function of the xApp as a candidate xApp. The A1 termination function may then select the candidate xApp as the target of an A1 POLICY SETUP REQUEST message. The A1 POLICY SETUP REQUEST message includes at least the A1 policy received from the Non-RT RIC 2 in step 301 .

[0064] 3, when the Non-RT RIC 2 creates an A1 policy, it can inform the Near-RT RIC 3 of the xApps that the Non-RT RIC 2 wants selected or assigned for enforcement of the A1 policy. This allows the Non-RT RIC 2 to specify the xApps to be used for A1 policy enforcement.

[0065] In addition to when creating the A1 policy, when Non-RT RIC 2 requests Near-RT RIC 3 to update the A1 policy, Non-RT RIC 2 may present to Near-RT RIC 3 the identifier of the xApp selected or assigned for the enforcement of the updated A1 policy. However, display of the xApp identifier when updating the A1 policy may be omitted. This is because the A1 policy is already mapped to a specific xApp when it is updated. Specifically, the A1 policy is mapped to a specific xApp when it is created. If the A1 policy has already been assigned or mapped to the xApp specified by Non-RT RIC 2 when it created the A1 policy, Non-RT RIC 2 does not need to explicitly specify the xApp when updating the A1 policy.

[0066] Allowing the Non-RT RIC 2 to specify the xApp used for A1 policy enforcement may be beneficial for various purposes. This may be broadly beneficial to allow multiple A1 policies of the same policy type to be assigned to different xApps by the Near-RT RIC 3 as intended by the Non-RT RIC 2. Here, different xApps refers to multiple xApps separately deployed and registered in the Near-RT RIC 3. The different xApps may be older and newer versions of the same xApp software. Alternatively, the different xApps may be multiple xApps created by different software vendors for the same or similar RAN optimization purpose. Alternatively, the different xApps may be different xApps for similar RAN optimization purposes. Alternatively, the different xApps may be different application instances of the same version xApp running on different virtual machines, containers, or pods.

[0067] <Second embodiment> A configuration example of the system according to this embodiment may be similar to the example shown in Figures 1 and 2. This embodiment provides details regarding the creation (and update) of the A1 policy described in the first embodiment.

[0068] Fig. 4 shows an example of the structure of an A1 policy. In the example of Fig. 4, one A1 policy 400 is extended so as to include a target xApp identifier 403 in addition to one scope identifier 401 and one or more policy statements 402. The target xApp identifier 403 indicates an xApp that the Non-RT RIC 2 desires to be selected or assigned for the enforcement of the A1 policy 400. In other words, in the example of Fig. 4, the A1 policy 400 itself includes an identifier of an xApp that the Non-RT RIC 2 desires to be selected or assigned for the enforcement of the A1 policy 400 (e.g., an xApp ID already assigned by the Near-RT RIC 3).

[0069] FIG. 5 shows a specific example of the structure or format of a policy object (PolicyObject). The policy object 500 necessarily includes one scope identifier 501. The policy object 500 may include one or more policy objective statements 502, or one or more policy resource statements 503, or both. Furthermore, the policy object 500 may include a target xApp identifier 504. The target xApp identifier 504 indicates an xApp that the Non-RT RIC 2 desires to be selected or assigned for the enforcement of the A1 policy expressed in the policy object 500. In other words, in the example of FIG. 5, the policy object 500 representing the A1 policy includes an identifier of an xApp that the Non-RT RIC 2 desires to be selected or assigned for the enforcement of the A1 policy (e.g., an xApp ID already assigned by the Near-RT RIC 3).

[0070] 6 shows a more specific example of the policy creation operation shown in FIG. 3. Step 601 corresponds to step 301 in FIG. 3. In step 601, the Non-RT RIC 2 sends an HTTP PUT request message to the Near-RT RIC 3. The URI of the HTTP PUT request message in step 601 is similar to the URI of the HTTP PUT request message for creating an existing A1 policy. Specifically, the URI includes a policy type identifier (PolicyTypeId) representing the type of the A1 policy to be created and a policy identifier (policyId) for identifying the A1 policy to be created.

[0071] Meanwhile, the policy object included in the message body of the HTTP PUT request message in step 601 is extended to include a target xApp identifier (TargetxAppIdentifer). In other words, in the example of Fig. 6, the A1 policy itself, specifically the policy object describing the A1 policy, can include the identifier of the xApp (e.g., the xApp ID already assigned by Near-RT RIC 3) that Non-RT RIC 2 wishes to be selected or assigned for enforcement of the A1 policy.

[0072] In step 602, the Near-RT RIC 3 returns an HTTP PUT response to the Non-RT RIC 2. If successful, "201 Created" is returned and the message body carries a PolicyObject. The operation of step 602 may be similar to that of existing A1 policy creation.

[0073] 4-6, the Non-RT RIC 2 may include in the A1 policy itself an identifier of an xApp that the Non-RT RIC 2 wishes to be selected or assigned for enforcement of the A1 policy. This contributes to clarifying the signaling details to enable the Non-RT RIC 2 to specify the xApp to be used for A1 policy enforcement.

[0074] <Third embodiment> A configuration example of the system according to this embodiment may be similar to the example shown in Figures 1 and 2. This embodiment provides details regarding the creation (and update) of the A1 policy described in the first embodiment.

[0075] FIG. 7 shows another specific example of the policy creation operation shown in FIG. 3. Step 701 corresponds to step 301 in FIG. 3. In step 701, the Non-RT RIC 2 sends an HTTP PUT request message to the Near-RT RIC 3. The URI of the HTTP PUT request message in step 701 is extended so that a target xApp identifier (TargetxAppId) can be specified. The target xApp identifier (TargetxAppId) indicates an identifier of an xApp (e.g., an xApp ID already assigned by the Near-RT RIC 3) that the Non-RT RIC 2 desires to be selected or assigned for the enforcement of the A1 policy. Meanwhile, the message body of the HTTP PUT request message in step 701 is similar to the message body of the HTTP PUT request message for creating an existing A1 policy. Specifically, the message body includes a policy object similar to the existing one. The policy object includes one scope identifier and one or more policy statements. In other words, in the example of FIG. 7, in an A1 policy create request, an A1 policy (policy object) may be associated with a target xApp identifier in addition to a policy identifier and a policy type identifier.

[0076] In step 702, the Near-RT RIC 3 returns an HTTP PUT response to the Non-RT RIC 2. If successful, "201 Created" is returned and the message body carries a PolicyObject. The operation of step 702 may be similar to that of existing A1 policy creation.

[0077] 7, the Non-RT RIC 2 can associate the A1 policy (policy object) with the target xApp identifier in addition to the policy identifier and policy type identifier in the A1 policy creation request, which contributes to clarifying the signaling details to enable the Non-RT RIC 2 to specify the xApp to be used for A1 policy enforcement.

[0078] <Fourth embodiment> A configuration example of the system according to this embodiment may be similar to the example shown in Figures 1 and 2. This embodiment provides details regarding the creation (and update) of the A1 policy described in the first embodiment.

[0079] FIG. 8 and FIGS. 9A to 9D show an example of a procedure for performing a canary release of an xApp using the operation described with reference to FIG. 3. In the state shown at the top of FIG. 8, the Near-RT RIC 3 assigns the old version xApp 32A registered in the Near-RT RIC 3 for enforcement of the A1 policy 801. This assignment can be performed based on the operation described with reference to FIG. 3. Specifically, the Non-RT RIC 2 transmits a creation request for the A1 policy 801, specifying the Policy ID "AAAA" and the xApp ID "0001", to the Near-RT RIC 3. The creation request indicates that the scope is cells A, B, and C. Based on the creation request, the Near-RT RIC 3 assigns the old version xApp 32A identified by the xApp ID "0001" for enforcement of the A1 policy 801.

[0080] Next, in step 821, in order to perform a canary release of the new version xApp 32B only for cell C, the Non-RT RIC 2 requests the Near-RT RIC 3 to update the existing A1 policy 801 for the old version xApp 32A and assign a new A1 policy 802 to the new version xApp 32B. Specifically, the Non-RT RIC 2 transmits an update request for the A1 policy 801 specifying the Policy ID "AAAA" to the Near-RT RIC 3. The update request indicates that the scope of the A1 policy 801 is changed to cells A and B. The update request does not need to specify the xApp ID "0001" because the A1 policy 801 has already been mapped to a specific xApp 32A. The Non-RT RIC 2 sends a creation request for the A1 policy 802, specifying the policy ID "BBBB" and the xApp ID "0002", to the Near-RT RIC 3. The creation request indicates that the scope is cell C. Based on the creation request, the Near-RT RIC 3 allocates the new version xApp 32B identified by the xApp ID "0002" for implementing the A1 policy 802. This enables a canary release of the new version xApp 32B in cell C.

[0081] Once verification of the new version xApp 32B by the canary release is complete, step 822 may be performed. In step 822, the Non-RT RIC 2 deletes the A1 policy 801 for the old version xApp 32A, and updates the A1 policy 802 assigned to the new version xApp 32B. Specifically, the Non-RT RIC 2 updates the A1 policy 802 so as to add cells A and B, which were included in the scope of the deleted A1 policy 801, to the scope of the A1 policy 802. This completes the transition from the old version xApp 32A to the new version xApp 32B.

[0082] 9A to 9D show an example of details of the canary release procedure described with reference to FIG. 8. The SMO 1 including the Non-RT RIC 2 and the Near-RT RIC 3 can obtain the initial state shown at the top of FIG. 8 by performing steps 901 to 910. In step 901, the SMO framework function 11 places the old version xApp 32A in the Near-RT RIC 3 via the O1 interface or the O2 interface. In step 902, the old version xApp 32A sends an xApp registration request to the management function component of the Near-RT RIC platform 31 via the xApp registration API, and passes related information required for managing the App.

[0083] In steps 903 and 904, the Near-RT RIC platform 31 performs a registration process for the old version xApp 32A. Specifically, the Near-RT RIC platform 31 performs authentication and validity checks, and if the checks pass, assigns an xApp ID of "0001" to the old version xApp 32A, generates an xApp Managed Object Instance (MOI), and enters the xApp ID and initial xApp settings in the xApp MOI. In step 904, the management function component of the Near-RT RIC platform 31 sends a registration response to the old version xApp 32A.

[0084] In step 905, if the SMO 1 subscribes to configuration management notifications from the Near-RT RIC 3, the O1 termination function of the Near-RT RIC platform 31 (or the O2 termination function of the O-cloud) may format and send a Notify MOI Creation to the SMO 1 to notify the SMO 1 that an MOI has been created for the previous version xApp 32A. At this time, the Near-RT RIC platform 31 may inform the SMO 1 of the xApp ID "0001" assigned to the previous version xApp 32A.

[0085] In step 906, Non-RT RIC 2 requests Near-RT RIC 3 to create or set up an A1 policy to be assigned to previous version xApp 32A. To specify the xApp that Non-RT RIC 2 wants to be selected or assigned for enforcement of the A1 policy, the request indicates the xApp ID "0001" that was assigned by Near-RT RIC 3 to previous version xApp 32A. Following the example of FIG. 8, the request may specify Policy ID "AAAA" and indicate that the scope is cells A, B, and C.

[0086] In step 907, the Near-RT RIC platform 31 selects an xApp to which to assign a new A1 policy. The Near-RT RIC platform 31 selects the old version xApp 32A associated with the xApp ID "0001" specified in the policy creation request in step 906. In step 908, the Near-RT RIC platform 31 sends an A1 POLICY SETUP REQUEST message to the selected old version xApp 32A. The A1 POLICY SETUP REQUEST message includes at least the A1 policy received from the Non-RT RIC 2 in step 906.

[0087] In step 909, if old version xApp 32A completes the A1 policy setup, old version xApp 32A sends an A1 POLICY SETUP RESULT message to Near-RT RIC platform 31. Here, the A1 POLICY SETUP RESULT message indicates success. In step 910, Near-RT RIC platform 31 sends a response message to Non-RT RIC 2 via the A1 interface.

[0088] Next, the SMO 1 including the Non-RT RIC 2 and the Near-RT RIC 3 can obtain the second state shown in Fig. 8 by performing steps 911 to 924. In step 911, the SMO framework function 11 places the new version xApp 32B in the Near-RT RIC 3 via the O1 interface or the O2 interface. In step 912, the new version xApp 32B sends an xApp registration request to the management function component of the Near-RT RIC platform 31 via the xApp registration API, and passes related information required for managing the App.

[0089] In steps 913 and 914, the Near-RT RIC platform 31 performs a registration process for the new version xApp 32B. Specifically, the Near-RT RIC platform 31 performs an authentication and validity check, and if the check passes, assigns an xApp ID "0002" to the new version xApp 32B, generates an xApp MOI, and enters the xApp ID and initial xApp settings in the xApp MOI. In step 914, the management function component of the Near-RT RIC platform 31 sends a registration response to the new version xApp 32B.

[0090] In step 915, if SMO 1 subscribes to configuration management notifications from Near-RT RIC 3, the O1 termination function of Near-RT RIC platform 31 (or the O2 termination function of the O-cloud) may format and send a Notify MOI Creation to SMO 1 to notify SMO 1 that an MOI has been created for new version xApp 32B. At this time, Near-RT RIC platform 31 may inform SMO 1 of the xApp ID “0002” assigned to new version xApp 32B.

[0091] In step 916, the Non-RT RIC 2 requests the Near-RT RIC platform 31 to update the A1 policy already assigned to the old version xApp 32A. According to the example of FIG. 8, this policy update request may specify Policy ID “AAAA” and indicate that the scope is updated from cells A, B, and C to cells A and B. The policy update request may or may not indicate the xApp ID “0001” of the old version xApp 32A. The A1 policy with Policy ID “AAAA” has already been mapped to the old version xApp 32A in the Near-RT RIC platform 31. Therefore, the Near-RT RIC platform 31 can select the old version xApp 32A based on Policy ID “AAAA” even if it does not receive the xApp ID “0001”.

[0092] In step 917, the Near-RT RIC platform 31 sends an A1 POLICY UPDATE REQUEST message to the selected previous version xApp 32A. The A1 POLICY UPDATE REQUEST message includes at least the A1 policy received from the Non-RT RIC 2 in step 916.

[0093] In step 918, once old version xApp 32A has completed updating the A1 policy, old version xApp 32A sends an A1 POLICY UPDATE RESULT message to Near-RT RIC platform 31. Here, the A1 POLICY UPDATE RESULT message indicates success. In step 919, Near-RT RIC platform 31 sends a response message to Non-RT RIC 2 via the A1 interface.

[0094] In step 920, Non-RT RIC 2 requests Near-RT RIC 3 to create or set up an A1 policy to be assigned to new version xApp 32B. To specify the xApp that Non-RT RIC 2 wants selected or assigned for enforcement of the A1 policy, the request indicates the xApp ID "0002" that has been assigned by Near-RT RIC 3 to new version xApp 32B. Following the example of FIG. 8, the request may specify Policy ID "BBBB" and indicate that the scope is cell C.

[0095] In step 921, the Near-RT RIC platform 31 selects an xApp to which to assign a new A1 policy. The Near-RT RIC platform 31 selects the new version xApp 32B associated with the xApp ID "0002" specified in the policy creation request in step 920. In step 922, the Near-RT RIC platform 31 sends an A1 POLICY SETUP REQUEST message to the selected new version xApp 32B. The A1 POLICY SETUP REQUEST message includes at least the A1 policy received from the Non-RT RIC 2 in step 920.

[0096] In step 923, if new version xApp 32B completes the A1 policy setup, new version xApp 32B sends an A1 POLICY SETUP RESULT message to Near-RT RIC platform 31. Here, the A1 POLICY SETUP RESULT message indicates success. In step 924, Near-RT RIC platform 31 sends a response message to Non-RT RIC 2 via the A1 interface.

[0097] Thereafter, the SMO 1 including the Non-RT RIC 2 and the Near-RT RIC 3 can obtain the third state illustrated in FIG. 8 by performing steps 925 to 932. In step 925, the Non-RT RIC 2 requests the Near-RT RIC platform 31 to update the A1 policy already assigned to the new version xApp 32B. According to the example of FIG. 8, this policy update request may specify Policy ID “BBBB” and indicate that the scope is updated from cell C to cells A, B, and C. The policy update request may or may not indicate the xApp ID “0002” of the new version xApp 32B. The A1 policy with Policy ID “BBBB” has already been mapped to the new version xApp 32B in the Near-RT RIC platform 31. Therefore, the Near-RT RIC platform 31 can select the new version xApp 32B based on the Policy ID "BBBB" even without receiving the xApp ID "0002".

[0098] In step 926, the Near-RT RIC platform 31 sends an A1 POLICY UPDATE REQUEST message to the selected new version xApp 32B. The A1 POLICY UPDATE REQUEST message includes at least the A1 policy received from the Non-RT RIC 2 in step 925.

[0099] In step 927, once new version xApp 32B has completed updating the A1 policy, new version xApp 32B sends an A1 POLICY UPDATE RESULT message to Near-RT RIC platform 31. Here, the A1 POLICY UPDATE RESULT message indicates success. In step 928, Near-RT RIC platform 31 sends a response message to Non-RT RIC 2 via the A1 interface.

[0100] In step 929, the Non-RT RIC 2 requests the Near-RT RIC platform 31 to delete the A1 policy already assigned to the old version xApp 32A. According to the example of FIG. 8, this policy deletion request may specify Policy ID "AAAA". The policy deletion request may or may not indicate the xApp ID "0001" of the old version xApp 32A. The A1 policy with Policy ID "AAAA" has already been mapped to the old version xApp 32A in the Near-RT RIC platform 31. Therefore, the Near-RT RIC platform 31 can select the old version xApp 32A based on Policy ID "AAAA" even if it does not receive the xApp ID "0001".

[0101] In step 930, the Near-RT RIC platform 31 sends an A1 POLICY DELETE REQUEST message to the selected previous version xApp 32A. The A1 POLICY DELETE REQUEST message includes at least the A1 Policy ID “AAAA” received from the Non-RT RIC 2 in step 929.

[0102] In step 931, once old version xApp 32A has completed deleting the A1 policy, old version xApp 32A sends an A1 POLICY DELETE RESULT message to Near-RT RIC platform 31. Here, the A1 POLICY DELETE RESULT message indicates success. In step 932, Near-RT RIC platform 31 sends a response message to Non-RT RIC 2 via the A1 interface.

[0103] 9A to 9D may be changed as appropriate. For example, steps 916 to 919 may be performed after or in parallel with steps 920 to 924. Steps 925 to 928 may be performed after or in parallel with steps 929 to 932.

[0104] The operations described with reference to Figure 8 and Figures 9A to 9D can contribute to facilitating the canary release of xApps, at least by Non-RT RIC 2 specifying to Near-RT RIC 3 the xApps to be used for A1 policy enforcement when creating the A1 policy.

[0105] As previously explained, allowing the Non-RT RIC 2 to specify the xApps used for A1 policy enforcement can be useful for a variety of purposes, not just for canary releases of xApps. This can be broadly useful to allow multiple A1 policies of the same policy type to be assigned to different xApps by the Near-RT RIC 3, as intended by the Non-RT RIC 2.

[0106] In the state illustrated in FIG. 10, the Near-RT RIC 3 allocates the xApp 32C of vendor A registered in the Near-RT RIC 3 for enforcement of the A1 policy 1001. This allocation can be performed based on the operation described with reference to FIG. 3. Specifically, the Non-RT RIC 2 transmits a creation request for the A1 policy 1001, specifying the policy ID “AAAA” and the xApp ID “0001”, to the Near-RT RIC 3. In one example, the creation request indicates that the scope is cells A, B, and C, and indicates a threshold value of 50% as the policy objective or policy resource value. Based on the creation request, the Near-RT RIC 3 allocates the xApp 32C of vendor A identified by the xApp ID “0001” for enforcement of the A1 policy 1001.

[0107] In addition, in the state illustrated in FIG. 10, the Near-RT RIC 3 allocates the xApp 32D of vendor B registered in the Near-RT RIC 3 for enforcement of the A1 policy 1002. This allocation can also be performed based on the operation described with reference to FIG. 3. The Non-RT RIC 2 transmits a creation request for the A1 policy 1002, specifying the policy ID “BBBB” and the xApp ID “0002”, to the Near-RT RIC 3. In one example, the creation request indicates that the scope is cells A, B, and C, and indicates a threshold of 30% as the policy objective or policy resource value. Based on the creation request, the Near-RT RIC 3 allocates the xApp 32D of vendor B identified by the xApp ID “0002” for enforcement of the A1 policy 1002.

[0108] The state shown in Fig. 10 can be obtained by performing steps similar to steps 901 to 915 and 920 to 924 in Fig. 9, for example. According to the operation described with reference to Fig. 10, the Non-RT RIC 2 can control the Near-RT RIC 3 to assign different A1 policies having the same policy type and the same or different policy statements to multiple xApps created by different software vendors in accordance with the intention of the Non-RT RIC 2. Specifically, for example, different thresholds can be set as policy objectives or policy resource values ​​for each of multiple xApps created by different software vendors. This allows optimization of the entire network.

[0109] In the state illustrated in FIG. 11 , the Near-RT RIC 3 allocates the xApp 32E for Quality of Service (QoS) optimization registered in the Near-RT RIC 3 for enforcement of the A1 policy 1101. This allocation can be performed based on the operation described with reference to FIG. 3. Specifically, the Non-RT RIC 2 transmits a creation request for the A1 policy 1101, specifying the Policy ID “AAAA” and the xApp ID “0001”, to the Near-RT RIC 3. In one example, the creation request indicates that the scope is cells A, B, and C, and indicates a threshold value of 50% as the policy objective or policy resource value. Based on the creation request, the Near-RT RIC 3 allocates the xApp 32E for QoS optimization identified by the xApp ID “0001” for enforcement of the A1 policy 1101.

[0110] In addition, in the state illustrated in FIG. 11, the Near-RT RIC 3 allocates the xApp 32F for Quality of Experience (QoE) optimization registered in the Near-RT RIC 3 for the enforcement of the A1 policy 1102. This allocation can also be performed based on the operation described with reference to FIG. 3. The Non-RT RIC 2 transmits a creation request for the A1 policy 1102 specifying the Policy ID “BBBB” and the xApp ID “0002” to the Near-RT RIC 3. In one example, the creation request indicates that the scope is cells A, B, and C, and indicates a threshold of 30% as the policy objective or policy resource value. Based on the creation request, the Near-RT RIC 3 allocates the xApp 32F for QoE optimization identified by the xApp ID “0002” for the enforcement of the A1 policy 1102.

[0111] The state shown in Fig. 11 can be obtained by performing steps similar to steps 901 to 915 and 920 to 924 in Fig. 9, for example. According to the operation described with reference to Fig. 11, the Non-RT RIC 2 can control the Near-RT RIC 3 to assign different A1 policies having the same policy type and the same or different policy statements to different xApps for similar RAN optimization purposes in accordance with the intention of the Non-RT RIC 2. Specifically, for example, different thresholds can be set as policy objectives or policy resource values ​​for each of multiple xApps for similar RAN optimization purposes. This allows optimization of the entire network.

[0112] In the state illustrated in FIG. 12, the Near-RT RIC 3 assigns the xApp 32G registered in the Near-RT RIC 3 and operating in pod A to enforce the A1 policy 1201. This assignment can be performed based on the operation described with reference to FIG. 3. Specifically, the Non-RT RIC 2 transmits a creation request for the A1 policy 1201, specifying the Policy ID “AAAA” and the xApp ID “0001”, to the Near-RT RIC 3. In one example, the creation request indicates that the scope is cells A, B, and C, and indicates a threshold value of 50% as the policy objective or policy resource value. Based on the creation request, the Near-RT RIC 3 assigns the xApp 32G, identified by the xApp ID “0001”, operating in pod A to enforce the A1 policy 1201.

[0113] In addition, in the state illustrated in FIG. 12, the Near-RT RIC 3 allocates the xApp 32H registered in the Near-RT RIC 3 and operating in pod B for enforcement of the A1 policy 1202. This allocation can also be performed based on the operation described with reference to FIG. 3. The Non-RT RIC 2 transmits a creation request for the A1 policy 1202, specifying the policy ID “BBBB” and the xApp ID “0002”, to the Near-RT RIC 3. In one example, the creation request indicates that the scope is cells D, E, and F, and indicates a threshold of 50% as the value of the policy objective or policy resource. Based on the creation request, the Near-RT RIC 3 allocates the xApp 32H, identified by the xApp ID “0002”, operating in pod B for enforcement of the A1 policy 1202.

[0114] The state shown in FIG. 12 can be obtained by performing steps similar to steps 901 to 915 and 920 to 924 in FIG. 9, for example. According to the operation described with reference to FIG. 12, the Non-RT RIC 2 can control the Near-RT RIC 3 to assign different A1 policies having the same policy type and the same or different scopes to different application instances of the same version of xApp running on different virtual machines, containers, or pods according to the intention of the Non-RT RIC 2. This contributes to facilitating load balancing among xApps. Specifically, for example, as shown in FIG. 12, the A1 policy 1201 of xApp 32G and the A1 policy 1202 of xApp 32H, which have different cell scopes, can be controlled independently, thereby limiting the areas in which each A1 policy is enforced within the same time. This also makes it possible to reduce the hardware resources of the Near-RT RIC 3. This not only reduces the energy consumption of the Near-RT RIC 3, but also reduces the risk of bugs.

[0115] Next, a configuration example of the Non-RT RIC 2 and the Near-RT RIC 3 according to the above-mentioned embodiments will be described below. Fig. 13 is a block diagram showing a configuration example of the Non-RT RIC 2. The Near-RT RIC 3 may also have a similar configuration to the configuration shown in Fig. 13.

[0116] In the example of Figure 13, Non-RT RIC 2 is implemented as a computer system. The computer system includes one or more processors 1310, memory 1320, and mass storage 1330, which communicate with each other via a bus 1370. The one or more processors 1310 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 1340, one or more input devices 1350, and one or more peripherals 1360. The one or more peripherals 1360 may include a modem, or a network adapter, or any combination thereof.

[0117] One or both of the memory 1320 and the mass storage 1330 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 the one or more processors 1310. These instructions, when executed in the one or more processors 1310, cause the one or more processors 1310 to provide the functionality of the Non-RT RIC 2 described in the above embodiments.

[0118] As described with reference to FIG. 13, each of the processors included in the Non-RT RIC 2 and the Near-RT RIC 3 according to the above-described embodiment can execute one or more programs including instructions for making a computer execute the algorithm described with reference to the drawings. The programs include instructions (or software codes) for making a computer execute one or more functions described in the embodiment when the programs are loaded into a computer. 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) 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, the transitory computer-readable medium or the communication medium includes electrical, optical, acoustic, or other forms of propagated signals.

[0119] The above-described embodiment is merely an example of the application of the technical idea obtained by the inventor of the present invention. In other words, the technical idea is not limited to the above-described embodiment, and various modifications are possible.

[0120] For example, some or all of the above embodiments may be described as, but are not limited to, the following appendices. Some or all of the elements (e.g., configurations and functions) described in the appendices directed to an apparatus (e.g., the first RIC or the second RIC) may naturally be described as appendices directed to a method and a program. For example, some or all of the elements described in appendices 2-13 dependent on appendices 1 may also be described as appendices dependent on appendices 27 and 29 due to the same dependency relationship as appendices 2-13. Similarly, some or all of the elements described in appendices 15-26 dependent on appendices 14 may also be described as appendices dependent on appendices 28 and 30 due to the same dependency relationship as appendices 15-26. Some or all of the elements described in any appendice may be applied to various hardware, software, recording means for recording software, systems, and methods.

[0121] (Appendix 1) a first Radio Access Network (RAN) Intelligent Controller (RIC), means for sending a first request for enforcement of a first policy to a second RIC disposed between the first RIC and one or more RAN nodes via a first interface between the first RIC and the second RIC; the first request or the first policy includes a first identifier that specifies an application hosted in the second RIC and that is to be selected or assigned for enforcement of the first policy; 1st RIC. (Appendix 2) the first identifier is an identifier assigned by the second RIC to distinguish between a plurality of applications configured to run on the second RIC and registered with the second RIC; The first RIC as set forth in Appendix 1. (Appendix 3) The first identifier distinguishes between a plurality of applications that include different machine learning models. 1. A first RIC as described in Appendix 1 or 2. (Appendix 4) The first identifier distinguishes between applications running on different virtual machines, containers, or pods. 4. The first RIC according to any one of appendix 1 to 3. (Appendix 5) the first request causes the second RIC to select or assign an application associated with the first identifier to enforce the first policy. 5. The first RIC according to any one of appendix 1 to 4. (Appendix 6) the sending means is adapted to further send, via the first interface to the second RIC, a second request for enforcement of a second policy; the second request or the second policy includes a second identifier that specifies an application hosted at the second RIC and that is to be selected or assigned for enforcement of the second policy; the second policy is of the same policy type as the first policy; the second identifier is associated with an application registered with the second RIC separately from the application with which the first identifier is associated; 6. The first RIC according to any one of appendix 1 to 5. (Appendix 7) the first policy and the second policy specify different scopes from each other; The first RIC as set forth in Appendix 6. (Appendix 8) the first policy and the second policy specify different policy statements. 1. A first RIC as described in Appendix 6 or 7. (Appendix 9) The first policy includes a policy statement, a scope identifier representing a scope to which the policy statement applies, and the first identifier. 9. The first RIC according to any one of appendix 1 to 8. (Appendix 10) the first request requests the creation or update of the first policy; 10. The first RIC according to any one of appendixes 1 to 9. (Appendix 11) 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; the first interface is an A1 interface; the first policy is an A1 policy; The application is a Near-RT RIC application (xApps); 11. The first RIC according to any one of appendix 1 to 10. (Appendix 12) means for deploying the application to the second RIC via a second interface between a Service Management and Orchestration (SMO) framework including the first RIC and the second RIC; 12. The first RIC according to any one of appendix 1 to 11. (Appendix 13) The second interface is an O1 interface or an O2 interface. The first RIC described in Appendix 12. (Appendix 14) a second Radio Access Network (RAN) Intelligent Controller (RIC) disposed between the first RIC and one or more RAN nodes, means for receiving, from the first RIC, a first request for enforcement of a first policy via a first interface between the first RIC and the second RIC; the first request or the first policy includes a first identifier that specifies an application hosted in the second RIC and that is to be selected or assigned for enforcement of the first policy; Second RIC. (Appendix 15) the first identifier is an identifier assigned by the second RIC to distinguish between a plurality of applications configured to run on the second RIC and registered with the second RIC; The second RIC as set forth in Appendix 14. (Appendix 16) The first identifier distinguishes between applications that include or use different machine learning models. 1. A second RIC as described in Appendix 14 or 15. (Appendix 17) The first identifier distinguishes between applications running on different virtual machines, containers, or pods. 17. The second RIC according to any one of appendix 14 to 16. (Appendix 18) means for selecting or assigning, in response to receiving the first request, an application associated with the first identifier for enforcing the first policy; 18. The second RIC according to any one of appendix 14 to 17. (Appendix 19) the receiving means is adapted to further receive, at the second RIC via the first interface, a second request for enforcement of a second policy; the second request or the second policy includes a second identifier that specifies an application hosted at the second RIC and that is to be selected or assigned for enforcement of the second policy; the second policy is of the same policy type as the first policy; the second identifier is associated with an application registered with the second RIC separately from the application with which the first identifier is associated; 19. The second RIC according to any one of appendix 14 to 18. (Appendix 20) the first policy and the second policy specify different scopes from each other; The second RIC as set forth in Appendix 19. (Appendix 21) the first policy and the second policy specify different policy statements. 2. A second RIC as described in Appendix 19 or 20. (Appendix 22) The first policy includes a policy statement, a scope identifier representing a scope to which the policy statement applies, and the first identifier. 22. The second RIC according to any one of appendixes 14 to 21. (Appendix 23) the first request requests the creation or update of the first policy; 23. The second RIC according to any one of appendix 14 to 22. (Appendix 24) 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; the first interface is an A1 interface; the first policy is an A1 policy; The application is a Near-RT RIC application (xApps); 24. The second RIC according to any one of appendixes 14 to 23. (Appendix 25) means for supporting deployment of the application from the first RIC via a second interface between a Service Management and Orchestration (SMO) framework including the first RIC and the second RIC; 25. The second RIC according to any one of appendixes 14 to 24. (Appendix 26) The second interface is an O1 interface or an O2 interface. The second RIC as set out in Appendix 25. (Appendix 27) 1. A method performed by a first Radio Access Network (RAN) Intelligent Controller (RIC), comprising: sending a first request for enforcement of a first policy to a second RIC disposed between the first RIC and one or more Radio Access Network (RAN) nodes via a first interface between the first RIC and the second RIC; the first request or the first policy includes a first identifier that specifies an application hosted in the second RIC and that is to be selected or assigned for enforcement of the first policy; method. (Appendix 28) 1. A method performed by a second Radio Access Network (RAN) Intelligent Controller (RIC) disposed between a first RIC and one or more RAN nodes, comprising: receiving a first request for enforcement of a first policy from the first RIC via a first interface between the first RIC and the second RIC; the first request or the first policy includes a first identifier that specifies an application hosted in the second RIC and that is to be selected or assigned for enforcement of the first policy; method. (Appendix 29) A program for causing a computer to perform a method for a first Radio Access Network (RAN) Intelligent Controller (RIC), comprising: The method includes controlling a first RIC to transmit a first request for enforcement of a first policy to a second RIC disposed between the first RIC and one or more Radio Access Network (RAN) nodes via a first interface between the first RIC and the second RIC; the first request or the first policy includes a first identifier that specifies an application hosted in the second RIC and that is to be selected or assigned for enforcement of the first policy; method. (Appendix 30) 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 RAN nodes, the program comprising: The method includes controlling the second RIC to receive, from the first RIC, a first request for enforcement of a first policy via a first interface between the first RIC and the second RIC; the first request or the first policy includes a first identifier that specifies an application hosted in the second RIC and that is to be selected or assigned for enforcement of the first policy; method. [Explanation of symbols]

[0122] 1. SMO 2 Non-RT RIC 3 Near-RT RIC 4 E2 Node 1310 Processor 1320 Memory 1330 Mass Storage

Claims

1. a first Radio Access Network (RAN) Intelligent Controller (RIC), means for sending a first request for enforcement of a first policy to a second RIC disposed between the first RIC and one or more RAN nodes via a first interface between the first RIC and the second RIC; the first request or the first policy includes a first identifier that specifies an application hosted in the second RIC and that is to be selected or assigned for enforcement of the first policy; First RIC.

2. the first identifier is an identifier assigned by the second RIC to distinguish between a plurality of applications configured to run on the second RIC and registered with the second RIC; The first RIC of claim 1 .

3. the first identifier distinguishes between a plurality of applications that include different machine learning models; A first RIC according to claim 1 or 2.

4. the first identifier distinguishes between applications running on different virtual machines, containers, or pods; A first RIC according to claim 1 or 2.

5. the first request causes the second RIC to select or assign an application associated with the first identifier to enforce the first policy. A first RIC according to claim 1 or 2.

6. the sending means is adapted to further send, via the first interface to the second RIC, a second request for enforcement of a second policy; the second request or the second policy includes a second identifier that specifies an application hosted at the second RIC and that is to be selected or assigned for enforcement of the second policy; the second policy is of the same policy type as the first policy; the second identifier is associated with an application registered with the second RIC separately from the application with which the first identifier is associated; A first RIC according to claim 1 or 2.

7. the first policy and the second policy specify different scopes from each other; The first RIC of claim 6.

8. the first policy and the second policy specify different policy statements. The first RIC of claim 6.

9. The first policy includes a policy statement, a scope identifier representing a scope to which the policy statement applies, and the first identifier. A first RIC according to claim 1 or 2.

10. the first request requests the creation or update of the first policy; A first RIC according to claim 1 or 2.

11. 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; the first interface is an A1 interface; the first policy is an A1 policy; The application is a Near-RT RIC application (xApps); A first RIC according to claim 1 or 2.

12. means for deploying the application to the second RIC via a second interface between a Service Management and Orchestration (SMO) framework including the first RIC and the second RIC; A first RIC according to claim 1 or 2.

13. The second interface is an O1 interface or an O2 interface. The first RIC of claim 12.

14. a second Radio Access Network (RAN) Intelligent Controller (RIC) disposed between the first RIC and one or more RAN nodes, means for receiving, from the first RIC, a first request for enforcement of a first policy via a first interface between the first RIC and the second RIC; the first request or the first policy includes a first identifier that specifies an application hosted in the second RIC and that is to be selected or assigned for enforcement of the first policy; Second RIC.

15. the first identifier is an identifier assigned by the second RIC to distinguish between a plurality of applications configured to run on the second RIC and registered with the second RIC; The second RIC of claim 14.

16. The first identifier distinguishes between applications that include or use different machine learning models. A second RIC according to claim 14 or 15.

17. the first identifier distinguishes between applications running on different virtual machines, containers, or pods; A second RIC according to claim 14 or 15.

18. means for selecting or assigning, in response to receiving the first request, an application associated with the first identifier for enforcing the first policy. A second RIC according to claim 14 or 15.

19. The receiving means is adapted to further receive, from the second RIC via the first interface, a second request for enforcement of a second policy; the second request or the second policy includes a second identifier that specifies an application hosted at the second RIC and that is to be selected or assigned for enforcement of the second policy; the second policy is of the same policy type as the first policy; the second identifier is associated with an application registered with the second RIC separately from the application with which the first identifier is associated; A second RIC according to claim 14 or 15.

20. the first policy and the second policy specify different scopes from each other; 20. The second RIC of claim 19.

21. the first policy and the second policy specify different policy statements.

20. The second RIC of claim 19.

22. The first policy includes a policy statement, a scope identifier representing a scope to which the policy statement applies, and the first identifier. A second RIC according to claim 14 or 15.

23. the first request requests the creation or update of the first policy; A second RIC according to claim 14 or 15.

24. 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; the first interface is an A1 interface; the first policy is an A1 policy; The application is a Near-RT RIC application (xApps); A second RIC according to claim 14 or 15.

25. means for supporting deployment of the application from the first RIC via a second interface between a Service Management and Orchestration (SMO) framework including the first RIC and the second RIC; A second RIC according to claim 14 or 15.

26. The second interface is an O1 interface or an O2 interface.

26. The second RIC of claim 25.

27. 1. A method performed by a first Radio Access Network (RAN) Intelligent Controller (RIC), comprising: sending a first request for enforcement of a first policy to a second RIC disposed between the first RIC and one or more Radio Access Network (RAN) nodes via a first interface between the first RIC and the second RIC; the first request or the first policy includes a first identifier that specifies an application hosted in the second RIC and that is to be selected or assigned for enforcement of the first policy; method.

28. 1. A method performed by a second Radio Access Network (RAN) Intelligent Controller (RIC) disposed between the first RIC and one or more RAN nodes, the method comprising: receiving a first request for enforcement of a first policy from the first RIC via a first interface between the first RIC and the second RIC; the first request or the first policy includes a first identifier that specifies an application hosted in the second RIC and that is to be selected or assigned for enforcement of the first policy; method.

29. A program for causing a computer to perform a method for a first Radio Access Network (RAN) Intelligent Controller (RIC), comprising: The method includes controlling a first RIC to transmit a first request for enforcement of a first policy to a second RIC disposed between the first RIC and one or more Radio Access Network (RAN) nodes via a first interface between the first RIC and the second RIC; the first request or the first policy includes a first identifier that specifies an application hosted in the second RIC and that is to be selected or assigned for enforcement of the first policy; method.

30. 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 RAN nodes, the program comprising: The method comprises controlling the second RIC to receive from the first RIC, via a first interface between the first RIC and the second RIC, a first request for enforcement of a first policy; the first request or the first policy includes a first identifier that specifies an application hosted in the second RIC and that is to be selected or assigned for enforcement of the first policy; method.

Images