Ran intelligent controller (RIC) and method therefor

Abstract

A first radio access network (RAN) intelligent controller (RIC) (1) receives, from a second RIC (3) disposed between the first RIC (1) and one or more RAN nodes (4), feedback concerning the status of implementation of a plurality of policies each including one or more policy statements, by means of a single message. This contributes to, for example, reduction of the amount of traffic or the number of transactions required for feedback concerning the status of implementation of the plurality of policies each including one or more policy statements.

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 A1 interface, and is providing related technical specifications (see, for example, Non-Patent Documents 1-5).

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

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

[0009] The following describes A1 policy management over the A1 interface. The Non-RT RIC defines the A1 policy, which 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 apply to UEs and cells. The purpose of the A1 policy is to guide RAN performance toward the overall goal expressed in the RAN intent. In other words, the purpose of the A1 policy is to enable the Non-RT RIC function in the SMO to guide the Near-RT RIC function, and ultimately the RAN, to better meet the RAN intent. The RAN intent is an expression of the high-level operational or business goals that the RAN should achieve, allowing operators to specify the desired Service Level Agreements (SLAs) that the RAN should meet for all users or a class of users in a specific area over a given period of time.

[0010] 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 expressed in the A1 policy based on its internal conditions. The Near-RT RIC acts based on its internal functions or applications, the configuration received via O1, and the temporary A1 policy received via A1.

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

[0012] A1 policies are 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.

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

[0014] 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 include 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 specific A1 policy is subscribed to by providing a callback Uniform Resource Identifier (URI) at the time of policy creation.

[0015] Identifiers that can be used as scope identifiers in an A1 policy are defined as data types in Non-Patent Document 5 (A1 Type Definitions Specification). The scope identifier can be composed of a single or a combination of these data types, as described in more detail in the policy type definitions in Non-Patent Document 5. Specifically, the 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.

[0016] A1 policy creation and enforcement is performed on a per-policy basis. Therefore, multiple A1 policies are created by repeating the operation to create a single A1 policy. The operation to create a single A1 policy is based on 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 (i.e., Non-RT RIC) generates a policyId and sends an HTTP PUT request to the A1-P producer (i.e., Near-RT RIC). The target URI identifies the resource (policyId) under which to create the new policy. The message body carries the PolicyObject. The A1-P producer returns an HTTP PUT response. If successful, "201 Created" is returned, the location header carries the URI of the new policy, and the message body carries the PolicyObject. In case of failure, an appropriate error code is returned and the message body may contain additional error information. Note that A1-P consumers can request policy status updates for created policies by including notificationDestination as a query parameter in a PUT request. This is related to the feedback policy operation described below.

[0017] The operation to query the enforcement status of a single A1 policy is based on HTTP GET. The A1 policy for which the status is to be read is identified by a URI containing a policyId, while the message body is empty. The response by an A1-P producer returns a PolicyStatusObject, which indicates the enforcement status of the A1 policy and, if the enforcement status is NOT_ENFORCED, also provides brief information about the cause of non-enforcement.

[0018] Similar to creating an A1 policy, updating an A1 policy is done on a per-policy basis. Therefore, updating multiple A1 policies is done by repeatedly updating a single A1 policy. The operation to update a single A1 policy is based on 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.

[0019] The feedback policy operation requires an A1-P producer (i.e., a Near-RT RIC) to have a reduced-capability HTTP client for sending HTTP POST requests and receiving HTTP POST responses. Correspondingly, an A1-P consumer (i.e., a Non-RT RIC) is required to have a reduced-capability HTTP server for receiving HTTP POST requests and sending HTTP POST responses. An A1-P producer uses the feedback policy operation to notify an A1-P consumer of changes in the enforcement status of an A1 policy. The operation to provide policy feedback is based on an HTTP POST. The URI in the request line of the POST request contains the target resource for policy notification handling. In other words, the policy feedback notification is sent to the notification handling URI. The notification content is represented by a policy status object (PolicyStatusObject) included in the message body of the POST request. The PolicyStatusObject contains information about the policy enforcement status change and its cause. This procedure is used to notify when the policy enforcement status changes between "enforced" and "not enforced."

[0020] According to Non-Patent Document 5 (A1 Type Definitions Specification), a policy status object (PolicyStatusObject) must include an enforceStatus attribute. The enforceStatus attribute indicates the enforcement status of the A1 policy. The enforceStatus attribute is an enumeration type and indicates ENFORCED or NOT_ENFORCED. ENFORCED indicates that the policy is enforced, and NOT_ENFORCED indicates that the policy is not enforced. Furthermore, when the enforceStatus attribute is NOT_ENFORCED, the PolicyStatusObject includes an enforceReason attribute. The enforceReason attribute indicates a brief reason for the enforcement status change (or a brief reason why a notification is sent). The enforceReason attribute is an enumeration type and indicates SCOPE_NOT_APPLICABLE, STATEMENT_NOT_APPLICABLE, or OTHER_REASON. SCOPE_NOT_APPLICABLE indicates that the provided scope is no longer applicable for enforcing the policy. STATEMENT_NOT_APPLICABLE indicates that the policy statement(s) are not applicable due to other changes. OTHER_REASON is set in the enforceReason attribute if the policy cannot be enforced for reasons other than the scope or statement becoming inapplicable.

[0021] 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 2022; O-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 2022; O-RAN ALLIANCE Working Group 2, "O-RAN A1 interface: General Aspects and Principles 2.03", O-RAN.WG2.A1GAP-v02.03, October 2021; O-RAN ALLIANCE Working Group 2, "O-RAN A1 interface: Application Protocol 3.02", O-RAN.WG2.A1AP-v03.02, July 2022; O-RAN ALLIANCE Working Group 2, "O-RAN A1 interface: Type Definitions 3.0", O-RAN.WG2.A1TD-v03.00, July 2022

[0022] The inventors have studied the operations, procedures, and signaling on the A1 interface for A1 policy management and found various issues. One of these issues relates to feedback of the implementation status of A1 policies. Specifically, it is desirable to be able to reduce the traffic on the A1 interface between a Non-RT RIC and a Near-RT RIC, specifically the number of HTTP transactions, required for feedback of the implementation status of multiple A1 policies. As described above, according to the current O-RAN WG2 technical specifications, policy feedback is an HTTP POST request sent for each policy. That is, policy feedback is sent for each A1 policy. In other words, policy feedback is sent for each policy identifier, scope identifier, or policy object. Therefore, when multiple A1 policies are created and implemented for each UE, the amount of policy feedback traffic may increase. Specifically, multiple HTTP transactions are generated for multiple policy feedbacks for multiple A1 policies whose implementation status has changed.

[0023] As an example, consider a case where multiple scope identifiers of multiple A1 policies specify different UE identifiers within a cell, and the policy statements of these multiple A1 policies become inapplicable at the same time. In this case, the Near-RT RIC must execute multiple feedback policy operations or procedures corresponding to the multiple A1 policies to transmit multiple policy feedbacks. As another example, consider a case where multiple scope identifiers of multiple A1 policies specify the same UE identifier along with one or more other identifiers (e.g., slice identifiers or QoS identifiers), and a change in the UE identifier causes all of the multiple A1 policies to become inapplicable. Even in this case, the Near-RT RIC must execute multiple feedback policy operations or procedures corresponding to the multiple A1 policies to transmit multiple policy feedbacks.

[0024] Another problem encountered by the inventors relates to the creation of A1 policies. Specifically, it is desirable to be able to reduce the traffic on the A1 interface between a Non-RT RIC and a Near-RT RIC, specifically the number of HTTP transactions, required to create multiple A1 policies. As described above, according to the current O-RAN WG2 technical specifications, the A1 policy creation operation is performed for each A1 policy. Therefore, for example, when an A1 policy is created for each UE, the amount of traffic required for policy creation increases. In other words, a large number of HTTP transactions are generated to create multiple A1 policies.

[0025] Yet another problem the inventors have encountered relates to providing more detailed information about non-enforcement of A1 policies on the A1 interface. According to the current O-RAN WG2 technical specifications, when the policy enforcement status changes from "enforced" to "not enforced," the Near-RT RIC can send an HTTP POST request message containing a policy status object (PolicyStatusObject) in its message body to the non-RT RIC for policy feedback. Also, according to the current O-RAN WG2 technical specifications, the non-RT RIC can send an HTTP GET request message to the Near-RT RIC to inquire about the policy status, i.e., the enforcement status of the A1 policy. In response, the Near-RT RIC can send an HTTP GET response message containing a PolicyStatusObject in its message body to the non-RT RIC.

[0026] However, although a PolicyStatusObject can include an enforceReason attribute when the enforceStatus attribute is NOT_ENFORCED, the enforceReason attribute can only indicate "SCOPE_NOT_APPLICABLE," "STATEMENT_NOT_APPLICABLE," or "OTHER_REASON." Therefore, after receiving a feedback or query response from a Near-RT RIC carrying a PolicyStatusObject whose enforceStatus attribute indicates "NOT_ENFORCED," the Non-RT RIC must collect detailed information from the E2 node or the Near-RT RIC via the O1 interface. Collecting information over the O1 interface generally requires a longer response time than collecting information over the A1 interface. Therefore, there is a long delay between when the Non-RT RIC learns that the A1 policy is not being enforced and when it updates and (re)enforces the A1 policy based on the information collected via the O1 interface. This may make it difficult to dynamically update the A1 policy to keep up with rapid changes in the wireless environment, for example.

[0027] As an example, consider the case where an A1 policy with a scope identifier including a UE identifier is created, and then a Non-RT RIC receives feedback or an inquiry response from a Near-RT RIC indicating that the A1 policy is not being enforced and the reason is "SCOPE_NOT_APPLICABLE." In this case, the Non-RT RIC may be able to infer that the UE identifier has changed. However, the Non-RT RIC cannot learn the new value of the UE identifier through feedback or an inquiry response on the A1 interface or other procedures related to A1 policy management. Therefore, the Non-RT RIC must inquire about the new value of the UE identifier from the E2 node or the Near-RT RIC via the O1 interface.

[0028] As another example, consider the case where a Non-RT RIC receives feedback or a query response from a Near-RT RIC indicating that the A1 policy is not being enforced and the reason is "STATEMENT_NOT_APPLICABLE." In this case, the Non-RT RIC cannot know which of multiple policy statements is not applicable through the feedback or query response on the A1 interface or other procedures related to A1 policy management. Similarly, the Non-RT RIC cannot know the specific reason why a policy statement is not applicable through the feedback or query response on the A1 interface or other procedures related to A1 policy management. Therefore, the Non-RT RIC must query the Near-RT RIC or the E2 node for these details via the O1 interface.

[0029] 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 solving at least one of the problems, including the problems described above. 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 objectives and novel features will become apparent from the description of this specification or the accompanying drawings.

[0030] In a first aspect, a first RIC includes 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, in a single message, feedback regarding implementation of a plurality of policies, each policy including one or more policy statements, from a second RIC interposed between the first RIC and one or more RAN nodes.

[0031] In a second aspect, a method performed by a first RIC includes receiving, in a single message, feedback from a second RIC interposed between the first RIC and one or more RAN nodes regarding the implementation status of a plurality of policies, each of the policies including one or more policy statements.

[0032] 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 send feedback regarding enforcement of a plurality of policies, each including one or more policy statements, to the first RIC in a single message.

[0033] 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 sending feedback regarding implementation of a plurality of policies, each including one or more policy statements, to the first RIC in a single message.

[0034] In a fifth aspect, a first RIC includes 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 a request for creation of multiple policies, each including one or more policy statements, in a single request message to a second RIC interposed between the first RIC and one or more RAN nodes.

[0035] In a sixth aspect, a method performed by a first RIC includes sending a request for creation of multiple policies, each including one or more policy statements, in a single request message to a second RIC interposed between the first RIC and one or more RAN nodes.

[0036] A seventh 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, in a single request message from the first RIC, a request for creation of multiple policies, each policy including one or more policy statements.

[0037] An eighth aspect is directed to a method performed by a second RIC interposed between a first RIC and one or more RAN nodes, the method being configured to receive, in a single request message, a request from the first RIC for creation of multiple policies, each policy including one or more policy statements.

[0038] In a ninth aspect, a first RIC includes 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, over an A1 interface, from a second RIC interposed between the first RIC and one or more RAN nodes, details regarding a cause of non-enforcement of an A1 policy, the details regarding the cause of non-enforcement of the A1 policy indicating (a) a new, modified value of at least one identifier included in a scope identifier associated with the A1 policy, or (b) a reason why one or more policy statements of the A1 policy are inapplicable, or a combination thereof.

[0039] In a tenth aspect, a method performed by a first RIC includes receiving, over an A1 interface, from a second RIC interposed between the first RIC and one or more RAN nodes, details regarding a cause of non-enforcement of an A1 policy, the details regarding the cause of non-enforcement of the A1 policy indicating (a) a new changed value of at least one identifier included in a scope identifier associated with the A1 policy, or (b) a reason why one or more policy statements of the A1 policy are inapplicable, or a combination thereof.

[0040] An eleventh aspect is directed to a second RIC interposed between a first RIC and one or more RAN nodes. The second RIC includes at least one memory and at least one processor coupled to the at least one memory. The at least one processor is configured to send details regarding a cause of non-enforcement of an A1 policy to the first RIC over an A1 interface. The details regarding the cause of non-enforcement of the A1 policy indicate (a) a changed new value of at least one identifier included in a scope identifier associated with the A1 policy, or (b) a reason why one or more policy statements of the A1 policy are inapplicable, or a combination thereof.

[0041] A twelfth 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 sending details regarding a cause of non-enforcement of an A1 policy to the first RIC over an A1 interface, the details regarding the cause of non-enforcement of the A1 policy indicating (a) a new changed value of at least one identifier included in a scope identifier associated with the A1 policy, or (b) a reason why one or more policy statements of the A1 policy are inapplicable, or a combination thereof.

[0042] A thirteenth aspect is directed to a program, which includes a set of instructions (software code) that, when loaded into a computer, causes the computer to perform the method according to the second, fourth, sixth, eighth, tenth, or twelfth aspect.

[0043] According to the above-described aspects, it is possible to provide an apparatus, a method, and a program that contribute to solving at least one of a number of problems related to operations, procedures, and signaling on the A1 interface for A1 policy management, including the problems described above.

[0044] FIG. 1 is a diagram illustrating an architecture related to the A1, O1, and E2 interfaces according to an embodiment. FIG. 2 is a diagram illustrating an example of the functions of a Non-RT RIC and a Near-RT RIC related to A1 policy management according to an embodiment. FIG. 3 is a diagram illustrating an example of the structure of an A1 policy according to an embodiment. FIG. 4 is a sequence diagram illustrating an example of the operation of a Non-RT RIC and a Near-RT RIC according to an embodiment. FIG. 5 is a sequence diagram illustrating an example of the operation of a Non-RT RIC and a Near-RT RIC according to an embodiment. FIG. 6 is a sequence diagram illustrating an example of the operation of a Non-RT RIC and a Near-RT RIC according to an embodiment. FIG. 7 is a sequence diagram illustrating an example of the operation of a Non-RT RIC and a Near-RT RIC according to an embodiment. FIG. 1 is a sequence diagram showing an example of the operation of a Non-RT RIC and a Near-RT RIC according to an embodiment. FIG. 2 is a sequence diagram showing an example of the operation of a Non-RT RIC and a Near-RT RIC according to an embodiment. FIG. 3 is a sequence diagram showing an example of the operation of a Non-RT RIC and a Near-RT RIC according to an embodiment. FIG. 4 is a sequence diagram showing an example of the operation of a Non-RT RIC and a Near-RT RIC according to an embodiment. FIG. 5 is a diagram showing an example of the format of a policy status object according to an embodiment. FIG. 6 is a diagram showing an example of the format of a policy status object according to an embodiment. FIG. 7 is a sequence diagram showing an example of the operation of a Non-RT RIC and a Near-RT RIC according to an embodiment.1 is a sequence diagram showing an example of the operation of the SMO framework, Non-RT RIC, Near-RT RIC, and E2 node according to an embodiment. FIG. 2 is a block diagram showing an example of the configuration of the Non-RT RIC and Near-RT RIC according to an embodiment.

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

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

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

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

[0049] 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 a Non-RT RIC 1, an SMO framework 2, a Near-RT RIC 3, and one or more E2 nodes 4. The SMO framework 2 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.

[0050] The Non-RT RIC 1 is a logical function within the SMO or SMO Framework 2. The Non-RT RIC 1 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. 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.

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

[0052] O1-related services are provided by the SMO Framework 2 and the Non-RT RIC Framework. O1-related services 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.

[0053] The SMO Framework 2 provides various logical functions that are not anchored within the Non-RT RIC 1. These logical functions include, among other functions, O1 termination, O2 termination, and external terminations. O1 termination allows the SMO Framework 2 to exchange messages with Near-RT RICs 3 and E2 nodes 4 over the O1 interface. O2 termination allows the SMO Framework 2 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 termination allows the SMO Framework 2 or the Non-RT RIC Framework to exchange messages with external entities over interfaces outside the O-RAN scope.

[0054] 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 over the E2 interface. The Near-RT RIC hosts a set of applications called xApps and provides a set of commonly used platform functions to support specific functions hosted by the xApps. The set of platform functions includes database and Shared Data Layer (SDL), xApp subscription management, conflict mitigation, messaging infrastructure, interface termination, and Application Programming Interface (API) enablement. Interface termination includes E2 termination, A1 termination, and O1 termination, which provide termination of the E2 interface, A1 interface, and O1 interface, respectively.

[0055] 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. For NR access, the E2 node 4 includes one or more O-CU-CPs, one or more O-CU-UPs, one or more O-DUs, or any combination thereof. For E-UTRA access, the E2 node 4 includes one or more O-eNBs.

[0056] The following describes A1 policy management over the A1 interface. Figure 2 shows an example of the functionality of the Non-RT RIC 1 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 Application Programming Interfaces (APIs) for services defined in the A1 interface, including A1-P. With respect to A1-P, the Non-RT RIC 1 contains or provides an A1-P consumer 11, while the Near-RT RIC 3 contains or provides an A1-P producer 31. Requests are sent from the A1-P consumer, and responses and notifications are sent from the A1-P producer. The terms consumer and producer do not imply the direction of data transfer over the A1 interface.

[0057] The Non-RT RIC 1 defines the A1 policy, which is provided to the Near-RT RIC 3 over the A1 interface. The A1 policy is a declarative policy that includes statements regarding policy objectives and policy resources that apply to UEs and cells. The purpose of the A1 policy is to guide RAN performance toward the overall goal expressed in the RAN intent. In other words, the purpose of the A1 policy is to enable the Non-RT RIC 1 within the SMO or Framework 2 to guide the Near-RT RIC 3, and ultimately the RAN, to better meet the RAN intent. The RAN intent is an expression of the high-level operational or business goals that the RAN should achieve, allowing the operator to specify the desired SLAs that the RAN should meet for all users or a class of users in a specific area over a given period of time.

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

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

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

[0061] As shown in Figure 3, one A1 policy 300 consists of a scope identifier 301 and one or more policy statements 302. The scope identifier 301 indicates the target to which the policy statements 302 apply (e.g., UE(s), QoS flow(s), or cell(s)). The policy statements 302 express goals to the Near-RT RIC 3 and cover policy objectives and policy resources.

[0062] 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 includes a scope identifier (e.g., scope identifier 301) and at least one policy statement (e.g., statement 302). The at least one policy statement may include 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 11, i.e., the non-RT RIC 1, when the policy is created. Policy feedback for a specific A1 policy is subscribed to by providing a callback uniform resource identifier (URI) when the policy is created.

[0063] Identifiers that can be used as scope identifiers in an A1 policy are defined as data types in Non-Patent Document 5 (A1 Type Definitions Specification). The scope identifier can be composed of a single or a combination of these data types, as described in more detail in the policy type definitions in Non-Patent Document 5. Specifically, the 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.

[0064] Creation and enforcement of A1 policies can be performed on a per-policy basis. Therefore, 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 11 (i.e., the non-RT RIC 1) generates a policyId and sends an HTTP PUT request to the A1-P producer 31 (i.e., the near-RT RIC 3). The target URI identifies the resource (policyId) under which to create a new policy. The message body carries the PolicyObject. The A1-P producer 31 returns an HTTP PUT response. If successful, "201 Created" is returned, the location header carries the URI of the new policy, and the message body carries the PolicyObject. If unsuccessful, an appropriate error code is returned, and the message body may contain additional error information. Note that the A1-P consumer 11 can request policy status updates for the created policy by including notificationDestination as a query parameter in the PUT request. This is related to the feedback policy operation described below.

[0065] The enforcement status of an A1 policy can be queried on a per-policy basis. The operation to query the enforcement status of a single A1 policy is based on HTTP GET. The A1 policy for which the status is to be read is identified by a URI containing a policyId, while the message body is empty. The response by the A1-P producer 31 returns a policy status object (PolicyStatusObject). The PolicyStatusObject indicates the enforcement status of the A1 policy and, if the enforcement status is NOT_ENFORCED, also provides concise information about the cause of non-enforcement.

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

[0067] A feedback policy is an operation that requires the A1-P producer 31 (i.e., the Near-RT RIC 3) to have a reduced-capability HTTP client for sending HTTP POST requests and receiving HTTP POST responses. Correspondingly, the A1-P consumer 11 (i.e., the Non-RT RIC 1) is required to have a reduced-capability HTTP server for receiving HTTP POST requests and sending HTTP POST responses. The A1-P producer 31 may use the feedback policy operation to notify the A1-P consumer 11 of changes in the policy enforcement status for an A1 policy. The operation to provide policy feedback is based on an HTTP POST. The URI in the request line of the POST request contains the target resource for policy notification handling. In other words, the policy feedback notification is sent to the notification handling URI. The notification content is represented by a policy status object (PolicyStatusObject) included in the message body of the POST request. The PolicyStatusObject contains information about the policy enforcement status change and its cause. This procedure is used to notify when the policy enforcement status changes between "enforced" and "not enforced."

[0068] According to Non-Patent Document 5 (A1 Type Definitions Specification), a policy status object (PolicyStatusObject) must include an enforceStatus attribute. The enforceStatus attribute indicates the enforcement status of the A1 policy. The enforceStatus attribute is an enumeration type and indicates ENFORCED or NOT_ENFORCED. ENFORCED indicates that the policy is enforced, and NOT_ENFORCED indicates that the policy is not enforced. Furthermore, when the enforceStatus attribute is NOT_ENFORCED, the PolicyStatusObject includes an enforceReason attribute. The enforceReason attribute indicates a brief reason for the enforcement status change (or a brief reason why a notification is sent). The enforceReason attribute is an enumeration type and indicates SCOPE_NOT_APPLICABLE, STATEMENT_NOT_APPLICABLE, or OTHER_REASON. SCOPE_NOT_APPLICABLE indicates that the provided scope is no longer applicable for enforcing the policy. STATEMENT_NOT_APPLICABLE indicates that the policy statement(s) are not applicable due to other changes. OTHER_REASON is set in the enforceReason attribute if the policy cannot be enforced for reasons other than the scope or statement becoming inapplicable.

[0069] 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. The following embodiments 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 above-described A1 policy management may be modified as appropriate 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 above-described A1 policy management.

[0070] First Embodiment A configuration example of a system according to this embodiment may be similar to the example shown in Figures 1 and 2. This embodiment provides improved feedback of the implementation status of the A1 policy.

[0071] 4 shows an example of the operation of the Non-RT RIC 1 and Near-RT RIC 3 according to this embodiment. In step 401, the Near-RT RIC 3 sends feedback regarding the implementation status of multiple A1 policies to the Non-RT RIC 1 in a single message over the A1 interface. The Non-RT RIC 1 receives feedback regarding the implementation status of multiple A1 policies from the Near-RT RIC 3 in a single message over the A1 interface. The single message may be an HTTP POST request message.

[0072] The feedback regarding the implementation status of multiple A1 policies notifies the Non-RT RIC 1 of changes in the implementation status of each A1 policy. In other words, the feedback regarding the implementation status of multiple A1 policies indicates changes in the implementation status of each A1 policy. As already described, each A1 policy includes a scope identifier (e.g., scope identifier 301) and one or more policy statements (e.g., policy statement 302). The reason for a change in the implementation status of each A1 policy may be SCOPE_NOT_APPLICABLE, STATEMENT_NOT_APPLICABLE, or OTHER_REASON. Multiple A1 policy implementation status feedbacks merged into a single message may indicate different reasons for the change or the same reason for the change. In other words, the reasons for the changes in the implementation status of multiple A1 policies may be the same or may be partially or completely different.

[0073] The multiple A1 policies that are the subject of implementation status feedback using a single message can be determined by various methods or criteria. In a first example, the multiple A1 policies may be any multiple A1 policies that the Non-RT RIC 1 has requested the Near-RT RIC 3 to create or set up. In a second example, each of the multiple A1 policies may have the same scope identifier. In a third example, the scope identifiers of each of the multiple A1 policies may each include at least one common identifier (e.g., a UE identifier or a cell identifier). In a fourth example, each of the multiple A1 policies may include the same set of one or more policy statements. In a fifth example, the set of policy statements of each of the multiple A1 policies may each include at least one common policy statement.

[0074] In a sixth example, these multiple A1 policies may be multiple A1 policies that the Non-RT RIC 1 indicated at the time of policy creation that they are associated with each other. In other words, the Non-RT RIC 1 may explicitly or implicitly indicate to the Near-RT RIC 3 at the time of creation that multiple A1 policies can be associated with each other for feedback. The multiple A1 policies for which the Near-RT RIC 3 notifies the Non-RT RIC 1 of changes in their implementation status in a single message may be a subset of the set of A1 policies associated by the Non-RT RIC 1 at the time of policy creation.

[0075] To imply the association of such multiple A1 policies for policy feedback to the Near-RT RIC 3, the Non-RT RIC 1 may create or set up these multiple A1 policies in a single HTTP transaction with the Near-RT RIC 3. Improvements for creating multiple A1 policies in a single HTTP transaction are described below.

[0076] Alternatively, to imply the association of such multiple A1 policies with respect to policy feedback to the Near-RT RIC 3, the Non-RT RIC 1 may provide the Near-RT RIC 3 with the same policy group identifier in multiple HTTP transactions for creating multiple A1 policies. In other words, a new policy group identifier may be defined to achieve this. An improved policy creation operation using the policy group identifier will be described later.

[0077] Alternatively, in order to imply the association of such multiple A1 policies regarding policy feedback to the Near-RT RIC 3, the Non-RT RIC 1 may provide the same callback URI or Notification Destination to the Near-RT RIC 3 in multiple HTTP transactions for creating multiple A1 policies. Details of such policy creation operations will also be described later.

[0078] The following provides an example of the structure of a single message (step 401 in FIG. 4) indicating feedback on the implementation status of multiple A1 policies. In one example, this single message may include multiple scope identifiers, each of which is included in a respective one of the multiple A1 policies. Additionally or alternatively, the single message may include multiple policy identifiers, each of which indicates a respective one of the multiple A1 policies. Additionally or alternatively, the single message may include multiple other identifiers, each of which is associated with a respective one of the multiple A1 policies.

[0079] 5 shows an example in which a single message includes multiple scope identifiers for multiple A1 policies. In step 501, the Near-RT RIC 3 sends an HTTP POST request message to the Non-RT RIC 1. The message body of the HTTP POST request message in step 501 includes an array of policy status objects (PolicyStatusObject). In addition to the enforceStatus and enforceReason attributes, each policy status object additionally includes a scope attribute indicating a scope identifier. This associates each policy status object with one corresponding A1 policy. In step 502, the Non-RT RIC 1 returns an HTTP POST response with "204 No Content". The message body is empty.

[0080] 6 shows another example in which a single message includes multiple scope identifiers for multiple A1 policies. In step 601, the Near-RT RIC 3 sends an HTTP POST request message to the Non-RT RIC 1. The message body of the HTTP POST request message in step 601 includes an array of scope identifiers (scope) and an array of policy status objects. The multiple scope identifiers in the array of scope identifiers may be in one-to-one correspondence with the multiple policy status objects in the array of policy status objects according to the order of the instances in the two arrays. Each policy status object includes an enforceStatus attribute, as with the existing one, and may conditionally include an enforceReason attribute. In step 602, the Non-RT RIC 1 returns an HTTP POST response with "204 No Content." The message body is empty.

[0081] 7 shows an example in which a single message includes multiple policy identifiers for multiple A1 policies. In step 701, the Near-RT RIC 3 sends an HTTP POST request message to the Non-RT RIC 1. The message body of the HTTP POST request message in step 701 includes an array of policy status objects. In addition to the enforceStatus and enforceReason attributes, each policy status object additionally includes a policyId attribute indicating the policy identifier. This associates each policy status object with one corresponding A1 policy. In step 702, the Non-RT RIC 1 returns an HTTP POST response with "204 No Content". The message body is empty.

[0082] 8 shows another example in which a single message includes multiple policy identifiers for multiple A1 policies. In step 801, the Near-RT RIC 3 sends an HTTP POST request message to the Non-RT RIC 1. The message body of the HTTP POST request message in step 801 includes an array of policy identifiers (policyId) and an array of policy status objects. The multiple policy identifiers in the array of policy identifiers may be in one-to-one correspondence with the multiple policy status objects in the array of policy status objects according to the order of the instances in the two arrays. Each policy status object includes an enforceStatus attribute, as with the existing one, and may conditionally include an enforceReason attribute. In step 802, the Non-RT RIC 1 returns an HTTP POST response with "204 No Content." The message body is empty.

[0083] The following provides an improvement to the operation of creating multiple A1 policies. In one example, as described above, a new operation or procedure may be defined for creating multiple A1 policies in a single HTTP transaction. This operation or procedure may be referred to, for example, but not limited to, a Create multiple polices operation, a Multiple policies Create operation, or a Multiple policies creation operation. FIG. 9 shows an example of the Create multiple polices operation. In step 901, the Non-RT RIC 1 sends a request to create multiple policies to the Near-RT RIC 3 in a single request message. The request message may be an HTTP PUT request message. The request message may include multiple scope identifiers, each of which is included in a respective one of the multiple A1 policies. The request message may include multiple policy identifiers corresponding to the multiple A1 policies. The request message may include a policy group identifier assigned by the Non-RT RIC 1 to the multiple A1 policies.

[0084] 10 shows a more specific example of the Create multiple polices operation. In step 1001, Non-RT RIC 1 sends an HTTP PUT request message to Near-RT RIC 3. To indicate that this is an operation on multiple A1 policies within one policy group, the (resource) URI in the request line of the HTTP PUT request message in step 1001 is extended to indicate the policy group identifier. Specifically, in the example of FIG. 10, the HTTP PUT request (1001) indicates "URI: ... / policytypes / {policyTypeId} / policygroups / {policyGroupId}", to which the policyGroupId has been added.

[0085] Additionally, the message body of the HTTP PUT request message in step 1001 includes an array of policy objects. Similar to the existing ones, each policy object includes a scope attribute and one or more statements attributes. The one or more statements attributes may include any combination of the qosObjectives, qoeObjectives, ueLevelObjectives, sliceSlaObjectives, lbObjectives, tspResources, sliceSlaResources, and lbResources attributes. In addition to these attributes similar to the existing ones, each policy object additionally includes a policyId attribute indicating a policy identifier. This associates each policy object with one corresponding A1 policy.

[0086] In step 1002, the Near-RT RIC 3 returns an HTTP PUT response to the Non-RT RIC 1. If successful, "201 Created" is returned, and the message body carries an array of PolicyObjects. The location header of the HTTP PUT response may indicate the URI of the policy group.

[0087] 11 shows another more specific example of the Create multiple polices operation. In step 1101, Non-RT RIC 1 sends an HTTP PUT request message to Near-RT RIC 3. As in the example of FIG. 10, the URI of the HTTP PUT request message in step 1101 is extended to indicate a policy group identifier. The message body of the HTTP PUT request message in step 1101 includes an array of policy identifiers (policyId) and an array of policy objects. The multiple policy identifiers in the array of policy identifiers may be in one-to-one correspondence with the multiple policy objects in the array of policy objects according to the order of the instances in the two arrays.

[0088] In step 1102, the Near-RT RIC 3 returns an HTTP PUT response to the Non-RT RIC 1. If successful, "201 Created" is returned, and the message body carries an array of PolicyObjects. In the example of FIG. 11, the message body also carries an array of policy identifiers. The array of policy identifiers may be omitted. The location header of the HTTP PUT response may indicate the URI of the policy group.

[0089] Non-RT RIC 1 may instruct Near-RT RIC 3 whether feedback regarding the implementation status of multiple policies should be sent to Non-RT RIC 1 in a single feedback message or in multiple individual feedback messages. This instruction may be made in the policy creation request message of step 901, 1001, or 1101.

[0090] In one example, if Non-RT RIC 1 desires to receive a single feedback message, Non-RT RIC 1 may include only one callback URI or Notification Destination in the policy creation request message of steps 901, 1001, or 1101. Conversely, if multiple individual feedback messages are preferred, Non-RT RIC 1 may include multiple callback URIs or Notification Destinations corresponding to the multiple A1 policies to be created in the policy creation request message of steps 901, 1001, or 1101.

[0091] In another example, if Non-RT RIC 1 desires to receive a single feedback message, Non-RT RIC 1 may include a first indication to that effect in the policy creation request message of step 901, 1001, or 1101. On the other hand, if multiple individual feedback messages are preferred, Non-RT RIC 1 may omit the first indication from the policy creation request message of step 901, 1001, or 1101. Alternatively, Non-RT RIC 1 may include a second indication in the policy creation request message that expresses a desire for multiple individual feedback messages.

[0092] Next, some examples of operations for creating multiple A1 policies in multiple HTTP transactions will be described with reference to Figures 12 and 13. In the example of Figure 12, when the Non-RT RIC 1 sends a single policy creation request multiple times to create multiple A1 policies, it includes the same callback URI or Notification Destination for policy feedback in each of these multiple requests (1201). The Near-RT RIC 3 may recognize that it is permitted to send feedback on the implementation status of multiple A1 policies associated with the same callback URI or Notification Destination in a single message.

[0093] 13, Non-RT RIC 1 includes the same policy group identifier in each of the multiple requests when sending a single policy creation request multiple times to create multiple A1 policies (1301). Near-RT RIC 3 may recognize that it is permitted to send feedback on the implementation status of multiple A1 policies associated with the same policy group identifier in a single message.

[0094] According to the operation described in this embodiment, the Non-RT RIC 1 and the Near-RT RIC 3 can transfer policy feedback regarding changes in the implementation status of multiple A1 policies in a single message, which contributes to reducing the number of HTTP transactions required for feedback on the implementation status of multiple A1 policies.

[0095] Second Embodiment A configuration example of a system according to this embodiment may be similar to the example shown in Figures 1 and 2. This embodiment provides an improved operation for creating multiple A1 policies.

[0096] FIG. 14 shows an example of the operation of the Non-RT RIC 1 and the Near-RT RIC 3 according to this embodiment. The operation or procedure of FIG. 14 enables multiple A1 policies to be created in a single HTTP transaction. This operation or procedure may be referred to, for example, but not limited to, as a Create Multiple Polices operation, a Multiple Policies Create operation, or a Multiple Policies Creation operation. The operation or procedure shown in FIG. 14 may be partially or entirely identical to that described with reference to FIG. 9. In other words, the operation for creating multiple A1 policies described with reference to FIG. 9 does not necessarily need to be used in conjunction with the operation for feedback on the implementation status of multiple A1 policies described with reference to FIGS. 4 to 8. The operation for creating multiple A1 policies described with reference to FIG. 9 can be used independently of the operation for feedback on the implementation status of multiple A1 policies.

[0097] In step 1401, the Non-RT RIC 1 sends a request to create multiple policies in a single request message to the Near-RT RIC 3. The configuration of the request message and the operation of the Near-RT RIC 3 that receives it may be the same as those described with reference to Fig. 9. Duplicate description will be omitted here.

[0098] A more specific example of the Create multiple polices operation shown in Fig. 14 may be similar to those described with reference to Fig. 10 and Fig. 11. Here, a duplicated description will be omitted.

[0099] Non-RT RIC 1 may instruct Near-RT RIC 3 whether feedback regarding the implementation status of multiple policies should be sent to Non-RT RIC 1 in a single feedback message or in multiple individual feedback messages. This instruction may be made in the policy creation request message of step 1401 or 1501.

[0100] In one example, if Non-RT RIC 1 desires to receive a single feedback message, Non-RT RIC 1 may include only one callback URI or Notification Destination in the policy creation request message of step 1401 or 1501. Conversely, if multiple individual feedback messages are preferred, Non-RT RIC 1 may include multiple callback URIs or Notification Destinations corresponding to the multiple A1 policies to be created in the policy creation request message of step 1401 or 1501.

[0101] In another example, if Non-RT RIC 1 desires to receive a single feedback message, Non-RT RIC 1 may include a first indication to that effect in the policy creation request message of step 1401 or 1501. On the other hand, if multiple individual feedback messages are preferred, Non-RT RIC 1 may omit the first indication from the policy creation request message of step 1401 or 1501. Alternatively, Non-RT RIC 1 may include a second indication in the policy creation request message that expresses a desire for multiple individual feedback messages.

[0102] The multiple A1 policies that are the subject of policy creation using a single message can be determined by various methods or criteria. In a first example, the multiple A1 policies may be any multiple policies determined by the Non-RT RIC 1. In a second example, each of the multiple A1 policies may have the same scope identifier. In a third example, the scope identifiers of each of the multiple A1 policies may each include at least one common identifier (e.g., a UE identifier or a cell identifier). In a fourth example, each of the multiple A1 policies may include the same set of one or more policy statements. In a fifth example, the set of policy statements of each of the multiple A1 policies may each include at least one common policy statement.

[0103] According to the operation described in this embodiment, the Non-RT RIC 1 and the Near-RT RIC 3 can transfer requests for creating multiple A1 policies in a single message, which contributes to reducing the number of HTTP transactions required to create multiple A1 policies.

[0104] <Third Embodiment> A configuration example of a system according to this embodiment may be similar to the example shown in Figures 1 and 2. This embodiment relates to an improvement for providing more detailed information on non-enforcement of the A1 policy on the A1 interface.

[0105] FIG. 15 shows an example of the operation of the Non-RT RIC 1 and the Near-RT RIC 3 according to this embodiment. FIG. 15 shows an improvement or extension of an existing feedback policy. In step 1501, the Near-RT RIC 3 sends policy feedback regarding changes in the enforcement status of the A1 policy to the Non-RT RIC 1. The policy feedback may be an HTTP POST request. The policy feedback may include an enforceStatus attribute, as in the existing policy feedback, and may further include an enforceReason attribute when the enforceStatus attribute is NOT_ENFORCED.

[0106] Additionally, when the enforceStatus attribute is NOT_ENFORCED, the policy feedback further indicates details regarding the cause of non-enforcement of the A1 policy. The details regarding the cause of non-enforcement of the A1 policy indicate (a) the new value of at least one identifier included in the scope identifier associated with the A1 policy, or (b) the reason why one or more policy statements of the A1 policy are inapplicable, or a combination thereof. In other words, the details regarding the cause of non-enforcement of the A1 policy include information needed or used by the Non-RT RIC 1 to update the A1 policy. This information can be used by the Non-RT RIC 1 to determine the updated scope (scope identifier), one or more policy statements, or both, of the A1 policy.

[0107] The policy feedback may include one or more additional attributes, fields, or information elements to provide details about the cause of the non-enforcement of the A1 policy. Such an attribute, field, or attribute name may be, for example, but not limited to, the causeInfo attribute.

[0108] The policy feedback shown in FIG. 15 may be extended to show feedback regarding multiple A1 policies in the same manner as described in the first embodiment.

[0109] FIG. 16 shows an example of the extended policy feedback shown in step 1501 of FIG. 15. In step 1601, the Near-RT RIC 3 sends an HTTP POST request message to the Non-RT RIC 1. The message body of the HTTP POST request message includes a policy status object (PolicyStatusObject). In addition to the enforceStatus and enforceReason attributes, the policy status object includes a causeInfo attribute. The causeInfo attribute provides details about the cause of non-enforcement of the A1 policy. The policy status object (PolicyStatusObject) may further include a scope attribute indicating a scope identifier. In one example, if one policy feedback message indicates feedback on multiple A1 policies, the policy status object may include the scope attribute. In another example, the scope attribute in the policy status object may indicate one or more identifiers (e.g., UE identifier, cell identifier, slice identifier) ​​related to the details about the cause of non-enforcement indicated in the causeInfo attribute. In step 11602, the Non-RT RIC 1 returns an HTTP POST response with "204 No Content." The message body is empty.

[0110] FIG. 17 shows a specific example of the structure or format of a policy status object (PolicyStatusObject). The content of the causeInfo attribute (1701) may be in a format (1702) defined for each use case (e.g., policy type identifier). Additionally or alternatively, the content of the causeInfo attribute (1701) may specify a file path (1703) that stores detailed information about the cause of non-enforcement of the A1 policy. Additionally or alternatively, the content of the causeInfo attribute (1701) may include an embedded JSON file (1704).

[0111] In the example of FIG. 17 , the policy status object (PolicyStatusObject) includes a scope attribute (1720) indicating a scope identifier. In one example, when one policy feedback message indicates feedback regarding multiple A1 policies, the policy status object (PolicyStatusObject) may include the scope attribute (1720). In another example, the scope attribute (1720) may indicate one or more identifiers (e.g., UE identifier, cell identifier, slice identifier) ​​related to details regarding the cause of non-execution indicated in the causeInfo attribute (1701). Otherwise, the scope attribute (1720) may be omitted.

[0112] Figure 18 shows an example of a policy status object (PolicyStatusObject). The example in Figure 18 relates to a case where the UE identifier within the scope of the A1 policy has changed due to handover or other reasons, making the A1 policy unenforceable. In this case, the causeInfo attribute (1801) indicates the new value (1810) of the UE identifier included in the scope identifier.

[0113] In FIG. 18 , a new UE identifier (1810) is associated with the format (1802) of policy type identifier #1, but this is not limiting. The Non-RT RIC 1, which is an A1-P consumer, can use the Query policy type operation or procedure to learn the policy type identifiers of the policy types supported by the Near-RT RIC 3, which is an A1-P producer, and can receive the JSON schema for each policy type from the Near-RT RIC 3. The JSON schema for each policy type includes one JSON schema for PolicyObject and one JSON schema for PolicyStatusObject. The format for each policy type identifier in FIGS. 17 and 18 may follow the JSON schema for PolicyStatusObject provided by the Near-RT RIC 3.

[0114] In the example of FIG. 18 , the scope attribute (1820) indicates a UE identifier. This may indicate the value of the UE identifier before the change provided by the Non-RT RIC 1 in the A1 policy creation or update operation. Note that even without the scope attribute (1820), the Non-RT RIC 1 can know which A1 policy the PolicyStatusObject relates to from the URI (Notification Destinations) of the policy feedback that includes the PolicyStatusObject. Therefore, the scope attribute (1820) may be omitted. The scope attribute (1820) may be included only when one policy feedback message indicates feedback regarding multiple A1 policies.

[0115] Those skilled in the art will appreciate that similar extensions to the feedback policy operations described with reference to FIGS. 15-18 are possible for existing operations or procedures for querying the enforcement status of an A1 policy (i.e., the Query Policy Status procedure). Specifically, as already described, the operation for querying the enforcement status of a single A1 policy is based on HTTP GET. The Non-RT RIC 1 (A1-P consumer 11) sends an HTTP GET request to the Near-RT RIC 3 (A1-P producer 31). The A1 policy for which status is to be read is identified by a URI containing a policyId in the request line of the HTTP GET request. The HTTP GET response by the Near-RT RIC 3 (A1-P producer 31) includes a policy status object (PolicyStatusObject) in its message body. This policy status object (PolicyStatusObject) may provide details about the cause of the non-enforcement of the A1 policy, similar to those of the feedback policy operations described with reference to FIGS. 15-18.

[0116] Alternatively, the Non-RT RIC 1 may receive details about the cause of non-enforcement of the A1 policy from the Near-RT RIC 3 in one or more new A1 policy procedures that are different from the Feedback Policy procedure and the Query Policy Status procedure. The newly defined procedures may include a push-type procedure similar to the Feedback Policy procedure, as shown in FIG. 19. In the example of FIG. 19, in step 1901, the Near-RT RIC 3 sends a Push Detail Info message to the Non-RT RIC 1 indicating details about the cause of non-enforcement of the A1 policy. In other words, in the Push Detail Info operation or procedure, the Near-RT RIC 3 sends a message to the Non-RT RIC 1 indicating details about the cause of non-enforcement of the A1 policy. The message may be an HTTP POST request.

[0117] Additionally or alternatively, the newly defined procedure may include a pull-type procedure similar to the Query Policy Status procedure, as shown in Figure 20. In the example of Figure 20, in step 2001, Non-RT RIC 1 sends a Request Detail Info request message to Near-RT RIC 3. In step 2002, Near-RT RIC 3 sends a Request Detail Info response message to Non-RT RIC 1 indicating details regarding the cause of non-enforcement of the A1 policy. This operation or procedure may be based on HTTP GET.

[0118] In some cases, the Non-RT RIC 1 may be able to complete the A1 policy update without using O1 observables based on detailed information about the cause of the A1 policy non-enforcement received over the A1 interface from the Near-RT RIC 3. In this case, the time required for the Non-RT RIC 1 to update and (re)enforce the A1 policy after learning of the non-enforcement of the A1 policy can be reduced compared to when O1 observables are used. This can contribute to, for example, making it easier to dynamically update the A1 policy in response to sudden changes in the wireless environment.

[0119] However, in other cases, the Non-RT RIC 1 will need additional information received from the Near-RT RIC 3 or the E2 node 4 via the O1 interface to update the A1 policy. In this case, the Non-RT RIC 1 may collect information via the O1 interface in addition to the A1 policy management procedure described in this embodiment. The Non-RT RIC 1 may then update the A1 policy by further considering the information obtained from the Near-RT RIC 3 or the E2 node 4 via the O1 interface. As can be understood from the above, this embodiment does not force the Non-RT RIC 1 to update the A1 policy based solely on detailed information regarding the cause of non-implementation of the A1 policy on the A1 interface.

[0120] For example, only the detailed information on the cause of A1 policy non-implementation that is essential for policy update or highly urgent may be collected over the A1 interface. Optional or large pieces of detailed information on the cause of A1 policy non-implementation may be collected via the O1 interface. In this case, the time required to update and (re)implement the A1 policy may be shortened compared to when all detailed information on the cause of A1 policy non-implementation is collected via the O1 interface. This may contribute to, for example, making it easier to dynamically update the A1 policy in response to rapid changes in the wireless environment.

[0121] 21 shows an example in which information collection over the O1 interface is used in addition to information collection over the A1 interface. In step 2101, the Near-RT RIC 3 receives a RIC INDICATION message over the E2 interface from one or more E2 nodes 4. This RIC INDICATION message may be, for example, a RIC INDICATION message based on the E2 Service Model (E2SM) RAN Control (RC) REPORT Service Style 4: UE Information. This REPORT service style is initiated by E2SM-RC Event Trigger style 4: UE Information Change. This event trigger style is used to detect changes in UE context information.

[0122] The supported UE context information changes that trigger events are a Radio Resource Control (RRC) state change, a UE identifier change, or a change in a Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), or Medium Access Control (MAC) state variable. Event triggers related to a UE identifier change can be New UE Connected, UE Handed Over, UE ID Changed, or UE ID Removed. The New UE Connected event trigger is triggered when a new UE ID is assigned to a newly connected UE. The UE Handed Over event trigger is triggered when a new UE ID is assigned due to a handover from another node. The UE ID Changed event trigger is triggered when any content of an assigned UE ID changes. The UE ID Removed event trigger is triggered when a UE is released and its UE ID is removed. The RIC INDICATION message in step 2101 may be any of the UE context information changes described above. For example, the RIC INDICATION message in step 2101 may be triggered by a UE identifier change.

[0123] In step 2102, the Near-RT RIC 3 sends a Policy Feedback message to the Non-RT RIC 1 over the A1 interface. For example, the Near-RT RIC 3 may determine that the A1 policy is no longer enforceable based on the RIC INDICATION message of step 2101 and send the Policy Feedback message accordingly. The sending of the Policy Feedback message may be similar to that described with reference to FIG. 16 . The Policy Feedback message indicates details regarding the cause of the non-enforcement of the A1 policy. The Policy Feedback message may include only essential or urgent information required for the A1 policy update. The Policy Feedback message may indicate a new, changed value of the UE identifier included in the scope identifier associated with the A1 policy.

[0124] If necessary, in steps 2103 and 2104, the SMO framework 2 may collect RAN data or information via the O1 interface. Steps 2103 and 2104 may be performed alone or both. In other words, the SMO framework 2 may collect RAN data or information from the Near-RT RIC 3, from one or more E2 nodes 4, or from both. Specifically, the Non-RT RIC 1 may request or instruct the SMO framework 2 to perform additional RAN observations, and the SMO framework 2 may collect the additional RAN data or information over the O1 interface. In step 2105, the Non-RT RIC 1 receives the collected RAN data or information from the SMO framework 2. The RAN data or information may be optional or large information, such as detailed information regarding the cause of non-implementation of the A1 policy. The RAN data or information may also be additional information required or available for a policy update.

[0125] In step 2106, Non-RT RIC 1 requests an A1 policy update over the A1 interface from Near-RT RIC 3. To create the updated A1 policy, Non-RT RIC 1 uses the information received in step 2102 regarding details regarding the cause of the non-enforcement of the A1 policy. Optionally, Non-RT RIC 1 may use RAN data or information based on O1 observations received in step 2105 to create the updated A1 policy.

[0126] The Near-RT RIC 3 implements the updated A1 policy received from the Non-RT RIC 1. If necessary, in step 2107, the Near-RT RIC 3 sends a RIC CONTROL REQUEST message to one or more E2 nodes 4 over the E2 interface.

[0127] According to the operation described in this embodiment, the Non-RT RIC 1 can receive details regarding the cause of non-enforcement of the A1 policy from the Near-RT RIC 3 over the A1 interface. This allows the Non-RT RIC 1 to obtain information used for updating the A1 policy via the A1 interface. This can contribute, for example, to reducing the amount of information that the Non-RT RIC 1 must obtain via the O1 interface for updating the A1 policy. Also, in some cases, it can shorten the time required for the Non-RT RIC 1 to update and (re)enforce the A1 policy after learning that the A1 policy has not been enforced. This can contribute, for example, to making it easier to dynamically update the A1 policy in response to sudden changes in the wireless environment.

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

[0129] In the example of Figure 22, Non-RT RIC 1 is implemented as a computer system. The computer system includes one or more processors 2210, memory 2220, and mass storage 2230, which communicate with each other via a bus 2270. The one or more processors 2210 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 2240, one or more input devices 2250, and one or more peripherals 2260. The one or more peripherals 2260 may include a modem, a network adapter, or any combination thereof.

[0130] One or both of the memory 2220 and the mass storage 2230 may include a computer-readable medium having stored thereon one or more sets of instructions. These instructions may be located partially or completely in memory within one or more processors 2210. These instructions, when executed on one or more processors 2210, cause the one or more processors 2210 to provide the functionality of the Non-RT RIC 1 described in the above-described embodiments.

[0131] As described with reference to FIG. 22 , each of the processors included in the Non-RT RIC 1 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.

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

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

[0134] (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 receive feedback regarding the enforcement status of a plurality of policies, each including one or more policy statements, in a single message from a second RIC disposed between the first RIC and one or more RAN nodes. (Supplementary Note 2) The first RIC according to Supplementary Note 1, wherein the plurality of policies are any plurality of policies that the first RIC has requested the second RIC to create or set up. (Supplementary Note 3) The first RIC according to Supplementary Note 1, wherein each of the plurality of policies has the same scope identifier, and the scope identifier indicates a target to which one or more policy statements of the corresponding policy apply. (Supplementary Note 4) The first RIC of Supplementary Note 1, wherein a scope identifier of each of the plurality of policies includes at least one common identifier, and the scope identifier represents a target to which one or more policy statements of the corresponding policy apply. (Supplementary Note 5) The first RIC of Supplementary Note 1, wherein each of the plurality of policies includes the same set of one or more policy statements. (Supplementary Note 6) The first RIC of Supplementary Note 1, wherein each set of policy statements of the plurality of policies includes at least one common policy statement. (Supplementary Note 7) The first RIC of Supplementary Note 1, wherein the plurality of policies are a plurality of policies that the first RIC indicated at the time of policy creation that they are associated with each other. (Supplementary Note 8) The first RIC of any one of Supplements 1 to 7, wherein the at least one processor is configured to explicitly or implicitly indicate to the second RIC at the time of creation of the plurality of policies that the plurality of policies can be associated with each other for feedback.(Supplementary Note 9) The first RIC of Supplementary Note 8, wherein the at least one processor is configured to create or set up the plurality of policies in a single Hypertext Transfer Protocol (HTTP) transaction with the second RIC. (Supplementary Note 10) The first RIC of Supplementary Note 8, wherein the at least one processor is configured to indicate a same policy group identifier to the second RIC in multiple HTTP transactions for creating the plurality of policies. (Supplementary Note 11) The first RIC of Supplementary Note 8, wherein the at least one processor is configured to indicate a same callback Uniform Resource Identifier (URI) or Notification Destination to the second RIC in multiple HTTP transactions for creating the plurality of policies. (Supplementary Note 12) The first RIC of any one of Supplements 1 to 11, wherein the single message includes multiple scope identifiers each included in a respective one of the plurality of policies, and wherein the scope identifiers represent a target to which one or more policy statements of a corresponding policy apply. (Supplementary Note 13) The first RIC of any one of Supplements 1 to 11, wherein the single message includes a plurality of policy identifiers, each of which indicates a respective one of the plurality of policies. (Supplementary Note 14) The first RIC of any one of Supplements 1 to 11, wherein the single message includes a plurality of identifiers, each of which is associated with a respective one of the plurality of policies. (Supplementary Note 15) The first RIC of any one of Supplements 1 to 14, wherein the single message is configured to indicate details regarding a cause of non-enforcement of at least one policy among the plurality of policies, the details regarding the cause of non-enforcement of the at least one policy indicating (a) a changed new value of at least one identifier included in a scope identifier associated with the at least one policy, or (b) a reason why one or more policy statements of the at least one policy are inapplicable, or a combination thereof.(Supplementary Note 16) The first RIC of Supplementary Note 15, wherein the single message is a Hypertext Transfer Protocol (HTTP) POST request message, the HTTP POST request message including an enforceStatus attribute indicating NOT_ENFORCED and an enforceReason attribute indicating SCOPE_NOT_APPLICABLE, STATEMENT_NOT_APPLICABLE, or OTHER_REASON, and further including a new attribute indicating details regarding a cause of non-enforcement of the policy. (Supplementary Note 17) A method performed by a first Radio Access Network (RAN) Intelligent Controller (RIC), comprising receiving, in a single message, feedback regarding the enforcement status of a plurality of policies, each including one or more policy statements, from a second RIC located between the first RIC and one or more RAN nodes. (Supplementary Note 18) A program for causing a computer to perform a method for a first Radio Access Network (RAN) Intelligent Controller (RIC), the method comprising receiving, in a single message, feedback from a second RIC located between the first RIC and one or more RAN nodes, regarding the enforcement status of multiple policies, each of which includes one or more policy statements.(Supplementary Note 19) A second Radio Access Network (RAN) Intelligent Controller (RIC) disposed between a first RIC and one or more 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 send feedback regarding the enforcement status of a plurality of policies, each including one or more policy statements, to the first RIC in a single message. (Supplementary Note 20) The second RIC according to Supplementary Note 19, wherein the plurality of policies are any plurality of policies that the first RIC has requested the second RIC to create or set up. (Supplementary Note 21) The second RIC according to Supplementary Note 19, wherein each of the plurality of policies has the same scope identifier, and the scope identifier indicates a target to which one or more policy statements of the corresponding policy apply. (Supplementary Note 22) The second RIC of Supplementary Note 19, wherein a scope identifier of each of the plurality of policies includes at least one common identifier, and the scope identifier represents an object to which one or more policy statements of the corresponding policy apply. (Supplementary Note 23) The second RIC of Supplementary Note 19, wherein each of the plurality of policies includes the same set of one or more policy statements. (Supplementary Note 24) The second RIC of Supplementary Note 19, wherein each set of policy statements of the plurality of policies includes at least one common policy statement. (Supplementary Note 25) The second RIC of Supplementary Note 19, wherein the plurality of policies are a plurality of policies that the first RIC indicated at the time of policy creation that they are associated with each other. (Supplementary Note 26) The second RIC of any one of Supplements 19 to 25, wherein the at least one processor is configured to be explicitly or implicitly indicated by the first RIC at the time of creation of the plurality of policies that the plurality of policies can be associated with each other for feedback.(Supplementary Note 27) The second RIC of Supplementary Note 26, wherein the at least one processor is configured to receive a request to create or set up the plurality of policies in a single Hypertext Transfer Protocol (HTTP) transaction with the first RIC. (Supplementary Note 28) The second RIC of Supplementary Note 26, wherein the at least one processor is configured to receive the same policy group identifier from the first RIC in multiple HTTP transactions for creating the plurality of policies. (Supplementary Note 29) The second RIC of Supplementary Note 26, wherein the at least one processor is configured to receive the same callback Uniform Resource Identifier (URI) or Notification Destination from the first RIC in multiple HTTP transactions for creating the plurality of policies. (Supplementary Note 30) The second RIC of any one of Supplements 19 to 29, wherein the single message includes multiple scope identifiers each included in a respective one of the plurality of policies, and wherein the scope identifiers represent a target to which one or more policy statements of a corresponding policy apply. (Supplementary Note 31) The second RIC of any one of Supplements 19 to 29, wherein the single message includes a plurality of policy identifiers, each indicating a respective one of the plurality of policies. (Supplementary Note 32) The second RIC of any one of Supplements 19 to 29, wherein the single message includes a plurality of identifiers, each associated with a respective one of the plurality of policies. (Supplementary Note 33) The second RIC of any one of Supplements 19 to 32, wherein the single message is configured to indicate details regarding a cause of non-enforcement of at least one policy among the plurality of policies, the details regarding the cause of non-enforcement of the at least one policy indicating (a) a changed new value of at least one identifier included in a scope identifier associated with the at least one policy, or (b) a reason why one or more policy statements of the at least one policy are inapplicable, or a combination thereof.(Supplementary Note 34) The second RIC of Supplementary Note 33, wherein the single message is a Hypertext Transfer Protocol (HTTP) POST request message, the HTTP POST request message including an enforceStatus attribute indicating NOT_ENFORCED and an enforceReason attribute indicating SCOPE_NOT_APPLICABLE, STATEMENT_NOT_APPLICABLE, or OTHER_REASON, and further including a new attribute indicating details regarding the cause of non-enforcement of the policy. (Supplementary Note 35) 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 sending feedback regarding the enforcement status of a plurality of policies, each including one or more policy statements, to the first RIC in a single message. (Supplementary Note 36) 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 method comprising sending feedback regarding the enforcement status of a plurality of policies, each including one or more policy statements, to the first RIC in a single message. (Supplementary Note 37) 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, the at least one processor configured to send a request for creation of a plurality of policies, each including one or more policy statements, to a second RIC disposed between the first RIC and one or more RAN nodes in a single request message.(Supplementary Note 38) The first RIC of Supplementary Note 37, wherein the plurality of policies are any plurality of policies determined by the first RIC. (Supplementary Note 39) The first RIC of Supplementary Note 37, wherein each of the plurality of policies has the same scope identifier, and the scope identifier represents an object to which one or more policy statements of the corresponding policy apply. (Supplementary Note 40) The first RIC of Supplementary Note 37, wherein the scope identifier of each of the plurality of policies includes at least one common identifier, and the scope identifier represents an object to which one or more policy statements of the corresponding policy apply. (Supplementary Note 41) The first RIC of Supplementary Note 37, wherein the set of policy statements of each of the plurality of policies includes at least one common policy statement. (Supplementary Note 42) The first RIC of any one of Supplements 37 to 41, wherein the at least one processor is configured to include in the single request message a plurality of scope identifiers, each of which is included in a respective one of the plurality of policies, wherein the scope identifiers represent targets to which one or more policy statements of a corresponding policy apply. (Supplementary Note 43) The first RIC of any one of Supplements 37 to 41, wherein the at least one processor is configured to include in the single request message an array of a plurality of policy objects, each of which corresponds to a respective one of the plurality of policies, wherein each policy object includes a scope identifier and one or more policy statements, wherein the scope identifiers represent targets to which the one or more policy statements apply. (Supplementary Note 44) The first RIC of any one of Supplements 37 to 43, wherein the at least one processor is configured to include in the single request message a policy group identifier assigned to the plurality of policies.(Supplementary Note 45) The first RIC of Supplementary Note 44, wherein the single request message is a Hypertext Transfer Protocol (HTTP) PUT request message, and the at least one processor is configured to: set a Uniform Resource Identifier (URI) including the policy group identifier in a request line of the HTTP PUT request message, and include multiple policy identifiers, each indicating a respective one of the multiple policies, in a message body of the HTTP PUT request message. (Supplementary Note 46) The first RIC of any one of Supplements 37 to 45, wherein the single request message causes the second RIC to send feedback regarding the enforcement status of the multiple policies to the first RIC in a single feedback message. (Supplementary Note 47) The first RIC according to any one of Supplements 37 to 46, wherein the at least one processor is configured to instruct the second RIC in the single request message whether feedback regarding the enforcement status of the plurality of policies should be sent to the first RIC in a single feedback message or in multiple individual feedback messages. (Supplementary Note 48) A method performed by a first Radio Access Network (RAN) Intelligent Controller (RIC), comprising sending a request for creation of multiple policies, each including one or more policy statements, to a second RIC located between the first RIC and one or more RAN nodes in a single request message.(Supplementary Note 49) A program for causing a computer to perform a method for a first Radio Access Network (RAN) Intelligent Controller (RIC), the method comprising sending a request for creation of a plurality of policies, each including one or more policy statements, in a single request message to a second RIC located between the first RIC and one or more RAN nodes. (Supplementary Note 50) A second Radio Access Network (RAN) Intelligent Controller (RIC) located between a first RIC and one or more RAN nodes, the second RIC comprising: at least one memory; and at least one processor coupled to the at least one memory, the at least one processor configured to receive a request for creation of a plurality of policies, each including one or more policy statements, from the first RIC in a single request message. (Supplementary Note 51) The second RIC according to Supplementary Note 50, wherein the plurality of policies are any plurality of policies determined by the first RIC. (Supplementary Note 52) The second RIC of Supplementary Note 50, wherein each of the plurality of policies has the same scope identifier, and the scope identifier represents an object to which one or more policy statements of the corresponding policy apply. (Supplementary Note 53) The second RIC of Supplementary Note 50, wherein the scope identifier of each of the plurality of policies includes at least one common identifier, and the scope identifier represents an object to which one or more policy statements of the corresponding policy apply. (Supplementary Note 54) The second RIC of Supplementary Note 50, wherein the set of policy statements of each of the plurality of policies includes at least one common policy statement. (Supplementary Note 55) The second RIC of any one of Supplements 50 to 54, wherein the single request message includes multiple scope identifiers, each included in a respective one of the plurality of policies, and the scope identifier represents an object to which one or more policy statements of the corresponding policy apply.(Supplementary Note 56) The second RIC of any one of Supplements 50 to 54, wherein the single request message includes an array of multiple policy objects, each corresponding to a respective one of the multiple policies, each policy object including a scope identifier and one or more policy statements, the scope identifier indicating an object to which the one or more policy statements apply. (Supplementary Note 57) The second RIC of any one of Supplements 50 to 56, wherein the single request message includes a policy group identifier assigned to the multiple policies. (Supplementary Note 58) The second RIC of Supplementary Note 57, wherein the single request message is a Hypertext Transfer Protocol (HTTP) PUT request message, and the at least one processor is configured such that: a request line of the HTTP PUT request message indicates a Uniform Resource Identifier (URI) including the policy group identifier; and a message body of the HTTP PUT request message includes multiple policy identifiers, each indicating a respective one of the multiple policies. (Supplementary Note 59) The second RIC of any one of Supplements 50 to 58, wherein the at least one processor is configured to send feedback regarding the enforcement status of the plurality of policies to the first RIC in a single feedback message. (Supplementary Note 60) The second RIC of any one of Supplements 50 to 59, wherein the at least one processor is configured to determine whether feedback regarding the enforcement status of the plurality of policies should be sent to the first RIC in a single feedback message or in multiple individual feedback messages based on content of the single request message.(Supplementary Note 61) A method performed by a second Radio Access Network (RAN) Intelligent Controller (RIC) located between a first RIC and one or more RAN nodes, comprising receiving a request for creation of multiple policies, each including one or more policy statements, from the first RIC in a single request message. (Supplementary Note 62) A program for causing a computer to perform a method for a second Radio Access Network (RAN) Intelligent Controller (RIC) located between a first RIC and one or more RAN nodes, comprising receiving a request for creation of multiple policies, each including one or more policy statements, from the first RIC in a single request message. (Supplementary Note 63) 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 receive, over an A1 interface, from a second RIC disposed between the first RIC and one or more RAN nodes, details regarding a cause of non-enforcement of an A1 policy, the details regarding the cause of non-enforcement of the A1 policy indicating (a) a changed new value of at least one identifier included in a scope identifier associated with the A1 policy, or (b) a reason why one or more policy statements of the A1 policy are inapplicable, or a combination thereof. (Supplementary Note 64) The first RIC of Supplementary Note 63, wherein the at least one processor is configured to receive, from the second RIC, details regarding the cause of non-enforcement of the A1 policy in an extended feedback policy procedure.(Supplementary Note 65) The first RIC of Supplementary Note 64, wherein the at least one processor is configured to receive a Hypertext Transfer Protocol (HTTP) POST request message from the second RIC in the extended feedback policy procedure, the HTTP POST request message including an enforceStatus attribute indicating NOT_ENFORCED and an enforceReason attribute indicating SCOPE_NOT_APPLICABLE, STATEMENT_NOT_APPLICABLE, or OTHER_REASON, and further including a new attribute indicating details regarding a cause of non-enforcement of the A1 policy. (Supplementary Note 66) The first RIC of Supplementary Note 63, wherein the at least one processor is configured to receive details regarding a cause of non-enforcement of the A1 policy from the second RIC in an extended Query Policy Status procedure. (Supplementary Note 67) The first RIC of Supplementary Note 66, wherein the at least one processor is configured to receive a Hypertext Transfer Protocol (HTTP) GET response message from the second RIC in the extended Query Policy Status procedure, the HTTP GET response message including an enforceStatus attribute indicating NOT_ENFORCED and an enforceReason attribute indicating SCOPE_NOT_APPLICABLE, STATEMENT_NOT_APPLICABLE, or OTHER_REASON, and further including a new attribute indicating details regarding a cause of non-enforcement of the A1 policy. (Supplementary Note 68) The first RIC of Supplementary Note 63, wherein the at least one processor is configured to receive details regarding a cause of non-enforcement of the A1 policy from the second RIC in a new A1 policy procedure different from a Feedback Policy procedure and a Query Policy Status procedure.(Supplementary Note 69) The first RIC of Supplementary Note 68, wherein the new A1 policy procedure includes the first RIC receiving an HTTP POST request message from the second RIC, the HTTP POST request message indicating details regarding a cause for non-enforcement of the A1 policy. (Supplementary Note 70) The first RIC of Supplementary Note 68, wherein the new A1 policy procedure includes the first RIC receiving an HTTP GET response message from the second RIC, the HTTP GET response message indicating details regarding a cause for non-enforcement of the A1 policy. (Supplementary Note 71) The first RIC of any one of Supplements 63 to 70, 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 72) A method performed by a first Radio Access Network (RAN) Intelligent Controller (RIC), comprising receiving, over an A1 interface, from a second RIC located between the first RIC and one or more RAN nodes, details regarding a cause of non-enforcement of an A1 policy, wherein the details regarding the cause of non-enforcement of the A1 policy indicate (a) a changed new value of at least one identifier included in a scope identifier associated with the A1 policy, or (b) a reason why one or more policy statements of the A1 policy are inapplicable, or a combination thereof.(Supplementary Note 73) A program for causing a computer to perform a method for a first Radio Access Network (RAN) Intelligent Controller (RIC), the method comprising receiving, over an A1 interface, details regarding a cause of non-enforcement of an A1 policy from a second RIC located between the first RIC and one or more RAN nodes, the details regarding the cause of non-enforcement of the A1 policy indicating (a) a changed new value of at least one identifier included in a scope identifier associated with the A1 policy, or (b) a reason why one or more policy statements of the A1 policy are inapplicable, or a combination thereof. (Supplementary Note 74) A second Radio Access Network (RAN) Intelligent Controller (RIC) disposed between a first RIC and one or more 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 send details regarding a cause of non-enforcement of an A1 policy to the first RIC over an A1 interface, the details regarding the cause of non-enforcement of the A1 policy indicating (a) a changed new value of at least one identifier included in a scope identifier associated with the A1 policy, or (b) a reason why one or more policy statements of the A1 policy are inapplicable, or a combination thereof. (Supplementary Note 75) The second RIC according to Supplementary Note 74, wherein the at least one processor is configured to send details regarding the cause of non-enforcement of the A1 policy to the first RIC in an extended feedback policy procedure.(Supplementary Note 76) The second RIC of Supplementary Note 75, wherein the at least one processor is configured to send a Hypertext Transfer Protocol (HTTP) POST request message to the first RIC in the extended feedback policy procedure, the HTTP POST request message including an enforceStatus attribute indicating NOT_ENFORCED and an enforceReason attribute indicating SCOPE_NOT_APPLICABLE, STATEMENT_NOT_APPLICABLE, or OTHER_REASON, and further including a new attribute indicating details regarding a cause of non-enforcement of the A1 policy. (Supplementary Note 77) The second RIC of Supplementary Note 74, wherein the at least one processor is configured to send details regarding a cause of non-enforcement of the A1 policy to the first RIC in an extended Query Policy Status procedure. (Supplementary Note 78) The second RIC of Supplementary Note 77, wherein the at least one processor is configured to send a Hypertext Transfer Protocol (HTTP) GET response message to the first RIC in the extended Query Policy Status procedure, the HTTP GET response message including an enforceStatus attribute indicating NOT_ENFORCED and an enforceReason attribute indicating SCOPE_NOT_APPLICABLE, STATEMENT_NOT_APPLICABLE, or OTHER_REASON, and further including a new attribute indicating details regarding a cause of non-enforcement of the A1 policy. (Supplementary Note 79) The second RIC of Supplementary Note 74, wherein the at least one processor is configured to send details regarding a cause of non-enforcement of the A1 policy to the first RIC in a new A1 policy procedure different from the Feedback Policy procedure and the Query Policy Status procedure. (Supplementary Note 80) The second RIC described in Supplementary Note 79, wherein the new A1 policy procedure includes the second RIC sending an HTTP POST request message to the first RIC indicating details regarding the cause of the non-implementation of the A1 policy.(Supplementary Note 81) The second RIC of Supplementary Note 79, wherein the new A1 policy procedure includes the second RIC sending an HTTP GET response message to the first RIC indicating details regarding the cause of the non-enforcement of the A1 policy. (Supplementary Note 82) The second RIC of any one of Supplements 74 to 81, 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 83) A method performed by a second Radio Access Network (RAN) Intelligent Controller (RIC) located between a first RIC and one or more RAN nodes, comprising sending details regarding a cause of non-enforcement of an A1 policy to the first RIC over an A1 interface, wherein the details regarding the cause of non-enforcement of the A1 policy indicate (a) a changed new value of at least one identifier included in a scope identifier associated with the A1 policy, or (b) a reason why one or more policy statements of the A1 policy are inapplicable, or a combination thereof. (Supplementary Note 84) 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 method comprising sending details regarding a cause of non-enforcement of an A1 policy to the first RIC over an A1 interface, the details regarding the cause of non-enforcement of the A1 policy indicating (a) a changed new value of at least one identifier included in a scope identifier associated with the A1 policy, or (b) a reason why one or more policy statements of the A1 policy are inapplicable, or a combination thereof.

[0135] This application claims priority based on Japanese Patent Application No. 2022-128678, filed August 12, 2022, the disclosure of which is incorporated herein in its entirety.

[0136] 1 Non-RT RIC 2 SMO framework 3 Near-RT RIC 4 E2 node 2210 Processor 2220 Memory 2230 Mass storage

Claims

1. a first Radio Access Network (RAN) Intelligent Controller (RIC), means for receiving, in a single message, feedback from a second RIC disposed between the first RIC and one or more RAN nodes regarding an enforcement status of a plurality of policies, each of the policies including one or more policy statements; The first RIC.

2. 1. A method performed by a first Radio Access Network (RAN) Intelligent Controller (RIC), comprising: receiving feedback from a second RIC disposed between the first RIC and one or more RAN nodes in a single message regarding an enforcement status of a plurality of policies, each of the policies including one or more policy statements; method.

3. a second Radio Access Network (RAN) Intelligent Controller (RIC) disposed between the first RIC and one or more RAN nodes, means for sending feedback regarding the enforcement status of a plurality of policies, each of the policies including one or more policy statements, to the first RIC in a single message; Second RIC.

4. the plurality of policies being any plurality of policies that the first RIC has requested the second RIC to create or set up; A second RIC as claimed in claim 3.

5. each of the plurality of policies has the same scope identifier; The scope identifier indicates to what one or more policy statements of the corresponding policy apply. A second RIC as claimed in claim 3.

6. A method for receiving a request to create or set up the plurality of policies in a single Hypertext Transfer Protocol (HTTP) transaction with the first RIC. A second RIC according to any one of claims 3 to 5.

7. A method for creating a plurality of policies, comprising: receiving an identical policy group identifier from the first RIC in a plurality of HTTP transactions for creating the plurality of policies. A second RIC according to any one of claims 3 to 5.

8. the single message includes a plurality of scope identifiers, each of which is included in a respective one of the plurality of policies; The scope identifier indicates to what one or more policy statements of the corresponding policy apply. A second RIC according to any one of claims 3 to 5.

9. the single message is configured to provide details regarding a cause for non-enforcement of at least one policy in the plurality of policies; The details regarding the cause of non-enforcement of the at least one policy indicate (a) a new value of at least one identifier included in a scope identifier associated with the at least one policy, or (b) a reason why one or more policy statements of the at least one policy are inapplicable, or a combination thereof. A second RIC according to any one of claims 3 to 5.

10. 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: sending feedback regarding the enforcement status of a plurality of policies, each of the policies including one or more policy statements, to the first RIC in a single message. method.