RAN Intelligent Controller (RIC) and its method

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

[Technical Field]

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

[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 restructure radio access networks (RANs) to be 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 subscribing to event notifications related to A1 policies, including notification of changes in A1 policy enforcement status.

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

[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 contain one or more policy objective statements and / or one or more policy resource statements. The policy identifier (policyId) is assigned by the A1 Policy Management Service (A1-P) consumer, i.e., a Non-RT RIC, at the time of policy creation. Policy feedback for a 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). A scope identifier can be composed of a single or a combination of these data types, as further detailed in the policy type definitions in Non-Patent Document 5. Specifically, a scope identifier can be a UE identifier (Ueid), a UE group identifier (GroupId), a slice identifier (SliceId), a QoS identifier (QosId), or a cell identifier (CellId), or any combination thereof.

[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, a "201 Created" response 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 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.

[0019] The feedback policy operation requires the A1-P producer (i.e., the Near-RT RIC) to have a reduced-capability HTTP client for sending HTTP POST requests and receiving HTTP POST responses. Correspondingly, the A1-P consumer (i.e., the Non-RT RIC) is required to have a reduced-capability HTTP server for receiving HTTP POST requests and sending HTTP POST responses. The A1-P producer uses the feedback policy operation to notify the A1-P consumer of changes in the enforcement status of A1 policies. 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 enforcement status of a policy 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 when the policy cannot be enforced for reasons other than the scope or statement becoming inapplicable. [Prior art documents] [Non-patent literature]

[0021] [Non-Patent Document 1] 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 [Non-patent document 2] 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 [Non-patent document 3] O-RAN ALLIANCE Working Group 2, "O-RAN A1 interface: General Aspects and Principles 2.03", O-RAN.WG2.A1GAP-v02.03, October 2021 [Non-patent document 4] O-RAN ALLIANCE Working Group 2, "O-RAN A1 interface: Application Protocol 3.02", O-RAN.WG2.A1AP-v03.02, July 2022 [Non-Patent Document 5] O-RAN ALLIANCE Working Group 2, "O-RAN A1 interface: Type Definitions 3.0", O-RAN.WG2.A1TD-v03.00, July 2022 Summary of the Invention [Problem to be solved by the invention]

[0022] The inventors have examined the operations, procedures, and signaling on the A1 interface for A1 policy management and identified 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, the amount of policy feedback traffic may increase when multiple A1 policies are created and implemented for each UE. 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 each 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 concerns providing more detailed information about non-enforcement of A1 policy over 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, a long delay occurs 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. [Means for solving the problem]

[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 multiple 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 multiple policies, each policy 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 located 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 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 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.

[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. [Effects of the Invention]

[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. [Brief explanation of the drawings]

[0044] [Figure 1] FIG. 2 illustrates an architecture relating to the A1, O1, and E2 interfaces according to an embodiment. [Figure 2] FIG. 10 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. [Figure 3] FIG. 10 is a diagram illustrating an example of the structure of an A1 policy according to an embodiment. [Figure 4] FIG. 10 is a sequence diagram showing an example of the operation of a Non-RT RIC and a Near-RT RIC according to an embodiment. [Figure 5] FIG. 10 is a sequence diagram showing an example of the operation of a Non-RT RIC and a Near-RT RIC according to an embodiment. [Figure 6] FIG. 10 is a sequence diagram showing an example of the operation of a Non-RT RIC and a Near-RT RIC according to an embodiment. [Figure 7] FIG. 10 is a sequence diagram showing an example of the operation of a Non-RT RIC and a Near-RT RIC according to an embodiment. [Figure 8] FIG. 10 is a sequence diagram showing an example of the operation of a Non-RT RIC and a Near-RT RIC according to an embodiment. [Figure 9] FIG. 10 is a sequence diagram showing an example of the operation of a Non-RT RIC and a Near-RT RIC according to an embodiment. [Figure 10] FIG. 10 is a sequence diagram showing an example of the operation of a Non-RT RIC and a Near-RT RIC according to an embodiment. [Figure 11] FIG. 10 is a sequence diagram showing an example of the operation of a Non-RT RIC and a Near-RT RIC according to an embodiment. [Figure 12] FIG. 10 is a sequence diagram showing an example of the operation of a Non-RT RIC and a Near-RT RIC according to an embodiment. [Figure 13] FIG. 10 is a sequence diagram showing an example of the operation of a Non-RT RIC and a Near-RT RIC according to an embodiment. [Figure 14] FIG. 10 is a sequence diagram showing an example of the operation of a Non-RT RIC and a Near-RT RIC according to an embodiment. [Figure 15] FIG. 10 is a sequence diagram showing an example of the operation of a Non-RT RIC and a Near-RT RIC according to an embodiment. [Figure 16] FIG. 10 is a sequence diagram showing an example of the operation of a Non-RT RIC and a Near-RT RIC according to an embodiment. [Figure 17] FIG. 10 is a diagram illustrating an example of the format of a policy status object according to the embodiment. [Figure 18] FIG. 10 is a diagram illustrating an example of the format of a policy status object according to the embodiment. [Figure 19] FIG. 10 is a sequence diagram showing an example of the operation of a Non-RT RIC and a Near-RT RIC according to an embodiment. [Figure 20] FIG. 10 is a sequence diagram showing an example of the operation of a Non-RT RIC and a Near-RT RIC according to an embodiment. [Figure 21] FIG. 10 is a sequence diagram showing an example of the operation of the SMO framework, the Non-RT RIC, the Near-RT RIC, and the E2 node according to the embodiment. [Figure 22] FIG. 2 is a block diagram showing an example of the configuration of a Non-RT RIC and a Near-RT RIC according to an embodiment. DETAILED DESCRIPTION OF THE INVENTION

[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 construed to mean "when," "at or around the time," "after," "upon," "in response to determining," "in accordance with a determination," or "in response to detecting." These expressions may be construed to have the same meaning, depending on the context.

[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 subscribing to event notifications related to A1 policies, including notification of changes in A1 policy enforcement status.

[0052] O1-related services are provided by the SMO framework2 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 for 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 for 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 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 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] Non-RT RIC 1 manages A1 policies based on A1 policy feedback and network conditions provided via O1. Non-RT RIC 1 continuously evaluates the impact of A1 policies toward achieving RAN intent, for example, using O1 observables, and decides to issue or update goals expressed in A1 policies based on internal conditions. Near-RT RIC 3 acts based on its internal functions or applications, configuration received via O1, and temporary A1 policies 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). 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). A scope identifier can be composed of a single or a combination of these data types, as further detailed in the policy type definitions in Non-Patent Document 5. Specifically, a scope identifier can be a UE identifier (Ueid), a UE group identifier (GroupId), a slice identifier (SliceId), a QoS identifier (QosId), or a cell identifier (CellId), or any combination thereof.

[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., Non-RT RIC 1) generates a policyId and sends an HTTP PUT request to the A1-P producer 31 (i.e., Near-RT RIC 3). The target URI identifies the resource (policyId) under which to create the new policy. The message body carries the PolicyObject. The A1-P producer 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 an A1-P consumer 11 can request policy status updates for the created policy by including notificationDestination as a query parameter in a 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 brief 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 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 enforcement status of a policy 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 when 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 An example of the configuration of the system according to this embodiment may be similar to the example shown in Figures 1 and 2. This embodiment provides 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 each change 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 requests 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 respective scope identifiers 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 respective sets of policy statements 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 Non-RT RIC 1 indicated at the time of policy creation that they are associated with each other. In other words, Non-RT RIC 1 may explicitly or implicitly indicate to 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 Near-RT RIC 3 notifies 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 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 is described below.

[0077] Alternatively, to imply the association of such multiple A1 policies for 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 are also described below.

[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 included in a respective one of the multiple A1 policies. Additionally or alternatively, the single message may include multiple policy identifiers, each indicating a respective one of the multiple A1 policies. Additionally or alternatively, the single message may include multiple other identifiers, each associated with a respective one of the multiple A1 policies.

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

[0080] FIG. 6 shows another example in which a single message contains 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 contains an array of scope identifiers (scopes) 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, like the existing one, includes an enforceStatus attribute and, depending on the condition, may 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] Figure 7 shows an example in which a single message contains multiple policy identifiers for multiple A1 policies. In step 701, Near-RT RIC 3 sends an HTTP POST request message to Non-RT RIC 1. The message body of the HTTP POST request message in step 701 contains an array of policy status objects. In addition to the enforceStatus and enforceReason attributes, each policy status object additionally contains a policyId attribute indicating the policy identifier. This associates each policy status object with one corresponding A1 policy. In step 702, Non-RT RIC 1 returns an HTTP POST response with "204 No Content". The message body is empty.

[0082] FIG. 8 shows another example in which a single message contains multiple policy identifiers for multiple A1 policies. In step 801, Near-RT RIC 3 sends an HTTP POST request message to 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, like the existing one, includes an enforceStatus attribute and, depending on the condition, may include an enforceReason attribute. In step 802, Non-RT RIC 1 returns an HTTP POST response with "204 No Content." The message body is empty.

[0083] The following provides an improved operation for 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, as 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 for the creation of 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] Figure 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 an operation on multiple A1 policies within a single 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 in Figure 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 can 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 that indicates 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] FIG. 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. Similar to the example in 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 policy identifier array may be in one-to-one correspondence with the multiple policy objects in the policy object array 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 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 in the policy creation request message of steps 901, 1001, or 1101, corresponding to the multiple A1 policies being created.

[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. Conversely, 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, expressing 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 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). 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 it sends 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 transmit 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> An example of the configuration of the system according to this embodiment may be similar to the example shown in Figures 1 and 2. This embodiment provides an 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 of 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 of feedback on the implementation status of multiple A1 policies.

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

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

[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 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 being 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, expressing 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 respective scope identifiers 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 respective sets of policy statements 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> An example of the configuration of the system according to this embodiment may be similar to the example shown in Figures 1 and 2. This embodiment relates to an improvement to provide 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 Non-RT RIC 1 to update the A1 policy. This information can be used by 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 more 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, similar to that described in the first embodiment.

[0109] FIG. 16 illustrates 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 the non-enforcement of the A1 policy. The policy status object (PolicyStatusObject) may further include a scope attribute indicating a scope identifier. In one example, the policy status object may include the scope attribute if one policy feedback message indicates feedback on multiple A1 policies. 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 the 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, if 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 the non-execution indicated in the causeInfo attribute (1701). Otherwise, the scope attribute (1720) may be omitted.

[0112] Figure 18 shows a specific 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 a handover or other reason, 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 limited to this. 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 Figure 18, the scope attribute (1820) indicates the UE identifier. This may indicate the value of the UE identifier before the change provided by Non-RT RIC 1 in the A1 policy creation or update operation. Note that even without the scope attribute (1820), 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 for multiple A1 policies.

[0115] Those skilled in the art will appreciate that similar extensions to the feedback policy operations described with reference to Figures 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 Figures 15-18.

[0116] Alternatively, Non-RT RIC 1 may receive details about the cause of non-enforcement of the A1 policy from 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, Near-RT RIC 3 sends a Push Detail Info message to 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, Near-RT RIC 3 sends a message to 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, 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 A1 policy non-enforcement received from Near-RT RIC 3 over the A1 interface. In this case, the time required for 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 only 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 non-implementation of the A1 policy that is essential for policy update or highly urgent may be collected on the A1 interface. Optional or large-sized information on the detailed information on the cause of non-implementation of the A1 policy may be collected via the O1 interface. In this case, too, it may be possible to shorten the time required to update and (re)implement the A1 policy compared to when all detailed information on the cause of non-implementation of the A1 policy is collected via the O1 interface. Therefore, this can contribute to facilitating dynamic updating of the A1 policy in response to rapid changes in the wireless environment, for example.

[0121] FIG. 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 the 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 Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), or Medium Access Control (MAC) state variable change. 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 handover from another node. The UE ID Changed event trigger is triggered when any content of the 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 about 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 from Near-RT RIC 3 over the A1 interface. To create the updated A1 policy, Non-RT RIC 1 uses the information received in step 2102 regarding details about 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 about the cause of non-enforcement of the A1 policy from the Near-RT RIC 3 over the A1 interface. This enables 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 the 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 includes 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 on a non-transitory computer-readable medium or a tangible storage medium. By way of example and not limitation, computer-readable media or tangible storage media include random-access memory (RAM), read-only memory (ROM), flash memory, solid-state drive (SSD) or other memory technology, CD-ROM, digital versatile disk (DVD), Blu-ray (registered trademark) 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] (Appendix 1) a first Radio Access Network (RAN) Intelligent Controller (RIC), At least one memory; at least one processor coupled to the at least one memory; Equipped with The at least one processor is configured to receive, in a single message, feedback from a second RIC interposed between the first RIC and one or more RAN nodes regarding an enforcement status of a plurality of policies, each policy including one or more policy statements; 1st RIC. (Appendix 2) the plurality of policies are any plurality of policies that the first RIC requests the second RIC to create or set up; The first RIC described in Appendix 1. (Appendix 3) 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. The first RIC described in Appendix 1. (Appendix 4) the scope identifiers of each of the plurality of policies each include at least one common identifier; The scope identifier indicates to what one or more policy statements of the corresponding policy apply. The first RIC described in Appendix 1. (Appendix 5) each of the plurality of policies includes an identical set of one or more policy statements; The first RIC described in Appendix 1. (Appendix 6) the respective sets of policy statements of the plurality of policies each include at least one common policy statement; The first RIC described in Appendix 1. (Appendix 7) 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. The first RIC described in Appendix 1. (Appendix 8) the at least one processor is configured to explicitly or implicitly indicate to the second RIC upon creation of the plurality of policies that the plurality of policies can be associated with one another for feedback purposes; 10. The first RIC according to any one of appendices 1 to 7. (Appendix 9) 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. The first RIC as set forth in Appendix 8. (Appendix 10) the at least one processor is configured to indicate the same policy group identifier to the second RIC in multiple HTTP transactions for creating the multiple policies; The first RIC as set forth in Appendix 8. (Appendix 11) the at least one processor is configured to indicate the same callback Uniform Resource Identifier (URI) or Notification Destination to the second RIC in multiple HTTP transactions for creating the multiple policies; The first RIC as set forth in Appendix 8. (Appendix 12) 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. 12. The first RIC according to any one of appendices 1 to 11. (Appendix 13) the single message includes a plurality of policy identifiers, each of which indicates a respective one of the plurality of policies; 12. The first RIC according to any one of appendices 1 to 11. (Appendix 14) the single message includes a plurality of identifiers, each associated with a respective one of the plurality of policies; 12. The first RIC according to any one of appendices 1 to 11. (Appendix 15) the single message is configured to provide details regarding a cause for 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 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; 15. The first RIC according to any one of appendices 1 to 14. (Appendix 16) the single message is a Hypertext Transfer Protocol (HTTP) POST request message; the HTTP POST request message includes an enforceStatus attribute indicating NOT_ENFORCED and an enforceReason attribute indicating SCOPE_NOT_APPLICABLE, STATEMENT_NOT_APPLICABLE, or OTHER_REASON, and further includes a new attribute indicating details regarding the reason for non-enforcement of the policy; The first RIC described in Appendix 15. (Appendix 17) 1. A method performed by a first Radio Access Network (RAN) Intelligent Controller (RIC), comprising: receiving feedback from a second RIC interposed between the first RIC and one or more RAN nodes in a single message regarding the enforcement status of a plurality of policies, each policy including one or more policy statements; method. (Appendix 18) A program for causing a computer to perform a method for a first Radio Access Network (RAN) Intelligent Controller (RIC), comprising: The method includes receiving, in a single message, feedback from a second RIC interposed between the first RIC and one or more RAN nodes regarding an enforcement status of a plurality of policies, each policy including one or more policy statements. program. (Appendix 19) a second Radio Access Network (RAN) Intelligent Controller (RIC) disposed between the first RIC and one or more RAN nodes, At least one memory; at least one processor coupled to the at least one memory; Equipped with the at least one processor is configured to send feedback regarding the enforcement status of a plurality of policies, each of which includes one or more policy statements, to the first RIC in a single message; Second RIC. (Appendix 20) the plurality of policies are any plurality of policies that the first RIC requests the second RIC to create or set up; The second RIC as set forth in Appendix 19. (Appendix 21) 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. The second RIC as set forth in Appendix 19. (Appendix 22) the scope identifiers of each of the plurality of policies each include at least one common identifier; The scope identifier indicates to what one or more policy statements of the corresponding policy apply. The second RIC as set forth in Appendix 19. (Appendix 23) each of the plurality of policies includes an identical set of one or more policy statements; The second RIC as set forth in Appendix 19. (Appendix 24) the respective sets of policy statements of the plurality of policies each include at least one common policy statement; The second RIC as set forth in Appendix 19. (Appendix 25) 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. The second RIC as set forth in Appendix 19. (Appendix 26) the at least one processor is configured to receive an explicit or implicit indication from 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 purposes; 26. The second RIC according to any one of appendices 19 to 25. (Appendix 27) 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. The second RIC as set out in Appendix 26. (Appendix 28) 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 multiple policies. The second RIC as set out in Appendix 26. (Appendix 29) 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 multiple policies. The second RIC as set out in Appendix 26. (Appendix 30) 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. 30. The second RIC according to any one of appendices 19 to 29. (Appendix 31) the single message includes a plurality of policy identifiers, each of which indicates a respective one of the plurality of policies; 30. The second RIC according to any one of appendices 19 to 29. (Appendix 32) the single message includes a plurality of identifiers, each associated with a respective one of the plurality of policies; 30. The second RIC according to any one of appendices 19 to 29. (Appendix 33) the single message is configured to provide details regarding a cause for 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 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; 33. The second RIC according to any one of appendices 19 to 32. (Appendix 34) the single message is a Hypertext Transfer Protocol (HTTP) POST request message; the HTTP POST request message includes an enforceStatus attribute indicating NOT_ENFORCED and an enforceReason attribute indicating SCOPE_NOT_APPLICABLE, STATEMENT_NOT_APPLICABLE, or OTHER_REASON, and further includes a new attribute indicating details regarding the reason for non-enforcement of the policy; The second RIC as set out in Appendix 33. (Appendix 35) 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. (Appendix 36) 1. A program for causing a computer to perform a method for a second Radio Access Network (RAN) Intelligent Controller (RIC) disposed between a first RIC and one or more RAN nodes, the program comprising: The method includes 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. program. (Appendix 37) a first Radio Access Network (RAN) Intelligent Controller (RIC), At least one memory; at least one processor coupled to the at least one memory; Equipped with the at least one processor is configured to send a request for creation of multiple policies, each including one or more policy statements, in a single request message to a second RIC disposed between the first RIC and one or more RAN nodes; 1st RIC. (Appendix 38) The plurality of policies are any plurality of policies determined by the first RIC; The first RIC described in Appendix 37. (Appendix 39) 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. The first RIC described in Appendix 37. (Appendix 40) the scope identifiers of each of the plurality of policies each include at least one common identifier; The scope identifier indicates to what one or more policy statements of the corresponding policy apply. The first RIC described in Appendix 37. (Appendix 41) the respective sets of policy statements of the plurality of policies each include at least one common policy statement; The first RIC described in Appendix 37. (Appendix 42) the at least one processor is configured to include in the single request message a plurality of scope identifiers, each scope identifier being 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. 42. The first RIC according to any one of appendices 37 to 41. (Appendix 43) the at least one processor is configured to include in the single request message an array of multiple policy objects, each policy object corresponding to a respective one of the multiple policies; Each policy object contains a scope identifier and one or more policy statements. the scope identifier indicates to what the one or more policy statements apply; 42. The first RIC according to any one of appendices 37 to 41. (Appendix 44) the at least one processor is configured to include in the single request message a policy group identifier assigned to the plurality of policies. 44. The first RIC according to any one of appendices 37 to 43. (Appendix 45) the single request message is a Hypertext Transfer Protocol (HTTP) PUT request message; The at least one processor: placing a Uniform Resource Identifier (URI) containing the policy group identifier in a request line of the HTTP PUT request message; including in a message body of the HTTP PUT request message a plurality of policy identifiers, each of which indicates a respective one of the plurality of policies; It is configured as follows: The first RIC described in Appendix 44. (Appendix 46) the single request message causes the second RIC to send feedback regarding the enforcement status of the plurality of policies to the first RIC in a single feedback message; 46. ​​The first RIC according to any one of appendices 37 to 45. (Appendix 47) 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. 47. The first RIC according to any one of appendices 37 to 46. (Appendix 48) 1. 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, in a single request message to a second RIC interposed between the first RIC and one or more RAN nodes; method. (Appendix 49) A program for causing a computer to perform a method for a first Radio Access Network (RAN) Intelligent Controller (RIC), comprising: The method includes sending 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. program. (Appendix 50) a second Radio Access Network (RAN) Intelligent Controller (RIC) disposed between the first RIC and one or more RAN nodes, At least one memory; at least one processor coupled to the at least one memory; Equipped with the at least one processor is configured to receive a request for creation of a plurality of policies from the first RIC in a single request message, each policy including one or more policy statements. Second RIC. (Appendix 51) The plurality of policies are any plurality of policies determined by the first RIC; The second RIC described in Appendix 50. (Appendix 52) 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. The second RIC described in Appendix 50. (Appendix 53) the scope identifiers of each of the plurality of policies each include at least one common identifier; The scope identifier indicates to what one or more policy statements of the corresponding policy apply. The second RIC described in Appendix 50. (Appendix 54) the respective sets of policy statements of the plurality of policies each include at least one common policy statement; The second RIC described in Appendix 50. (Appendix 55) the single request 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. 55. The second RIC of any one of appendices 50 to 54. (Appendix 56) the single request message includes an array of policy objects, each corresponding to a respective one of the policies; Each policy object contains a scope identifier and one or more policy statements. the scope identifier indicates to what the one or more policy statements apply; 55. The second RIC of any one of appendices 50 to 54. (Appendix 57) the single request message includes a policy group identifier assigned to the plurality of policies; 57. The second RIC of any one of appendices 50 to 56. (Appendix 58) the single request message is a Hypertext Transfer Protocol (HTTP) PUT request message; The at least one processor: a request line of the HTTP PUT request message indicating a Uniform Resource Identifier (URI) that includes the policy group identifier; a message body of the HTTP PUT request message including a plurality of policy identifiers, each of which indicates a respective one of the plurality of policies; It is configured as follows: The second RIC described in Appendix 57. (Appendix 59) 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; 59. The second RIC of any one of appendices 50-58. (Appendix 60) 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. 59. The second RIC of any one of appendices 50 to 59. (Appendix 61) 1. A method performed by a second Radio Access Network (RAN) Intelligent Controller (RIC) disposed between a first RIC and one or more RAN nodes, comprising: receiving a request from the first RIC in a single request message to create a plurality of policies, each policy including one or more policy statements; method. (Appendix 62) 1. A program for causing a computer to perform a method for a second Radio Access Network (RAN) Intelligent Controller (RIC) disposed between a first RIC and one or more RAN nodes, the program comprising: The method comprises receiving a request for creation of a plurality of policies from the first RIC in a single request message, each policy including one or more policy statements. program. (Appendix 63) a first Radio Access Network (RAN) Intelligent Controller (RIC), At least one memory; at least one processor coupled to the at least one memory; Equipped with the at least one processor is configured to receive, over an A1 interface, details regarding a cause of non-enforcement of an A1 policy from a second RIC disposed between the first RIC and one or more RAN nodes; The details regarding the cause of non-enforcement of the A1 policy indicate (a) the new value of at least one identifier included in a 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; 1st RIC. (Appendix 64) 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; The first RIC described in Appendix 63. (Appendix 65) the at least one processor is configured to receive a Hypertext Transfer Protocol (HTTP) POST request message from the second RIC in the enhanced feedback policy procedure; the HTTP POST request message includes an enforceStatus attribute indicating NOT_ENFORCED and an enforceReason attribute indicating SCOPE_NOT_APPLICABLE, STATEMENT_NOT_APPLICABLE, or OTHER_REASON, and further includes a new attribute indicating details regarding the reason for non-enforcement of the A1 policy; The first RIC described in Appendix 64. (Appendix 66) the at least one processor is configured to receive details from the second RIC regarding the cause of non-enforcement of the A1 policy in an extended Query Policy Status procedure; The first RIC described in Appendix 63. (Appendix 67) 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 includes an enforceStatus attribute indicating NOT_ENFORCED and an enforceReason attribute indicating SCOPE_NOT_APPLICABLE, STATEMENT_NOT_APPLICABLE, or OTHER_REASON, and further includes a new attribute indicating details regarding the reason for non-enforcement of the A1 policy; The first RIC described in Appendix 66. (Appendix 68) the at least one processor is configured to receive from the second RIC, in a new A1 policy procedure different from the Feedback Policy procedure and the Query Policy Status procedure, details regarding a cause for non-enforcement of the A1 policy. The first RIC described in Appendix 63. (Appendix 69) the new A1 policy procedure includes receiving, by the first RIC, an HTTP POST request message from the second RIC indicating details regarding a cause for non-enforcement of the A1 policy; The first RIC described in Appendix 68. (Appendix 70) the new A1 policy procedure includes the first RIC receiving an HTTP GET response message from the second RIC indicating details regarding the cause of the non-enforcement of the A1 policy; The first RIC described in Appendix 68. (Appendix 71) the first RIC is an Open Radio Access Network (O-RAN) Non-Real-Time (Non-RT) RIC; The second RIC is an O-RAN Near-Real-Time (Near-RT) RIC. 71. The first RIC according to any one of appendices 63 to 70. (Appendix 72) 1. A method performed by a first Radio Access Network (RAN) Intelligent Controller (RIC), 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 indicate (a) the new value of at least one identifier included in a 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; method. (Appendix 73) A program for causing a computer to perform a method for a first Radio Access Network (RAN) Intelligent Controller (RIC), comprising: The method comprises 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 indicate (a) the new value of at least one identifier included in a 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; program. (Appendix 74) a second Radio Access Network (RAN) Intelligent Controller (RIC) disposed between the first RIC and one or more RAN nodes, At least one memory; at least one processor coupled to the at least one memory; Equipped with the at least one processor is configured to send details regarding the cause of non-enforcement of the A1 policy to the first RIC over an A1 interface; The details regarding the cause of non-enforcement of the A1 policy indicate (a) the new value of at least one identifier included in a 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; Second RIC. (Appendix 75) 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; The second RIC described in Appendix 74. (Appendix 76) the at least one processor is configured to send a Hypertext Transfer Protocol (HTTP) POST request message to the first RIC in the enhanced feedback policy procedure; the HTTP POST request message includes an enforceStatus attribute indicating NOT_ENFORCED and an enforceReason attribute indicating SCOPE_NOT_APPLICABLE, STATEMENT_NOT_APPLICABLE, or OTHER_REASON, and further includes a new attribute indicating details regarding the reason for non-enforcement of the A1 policy; The second RIC described in Appendix 75. (Appendix 77) 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 Query Policy Status procedure; The second RIC described in Appendix 74. (Appendix 78) 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 includes an enforceStatus attribute indicating NOT_ENFORCED and an enforceReason attribute indicating SCOPE_NOT_APPLICABLE, STATEMENT_NOT_APPLICABLE, or OTHER_REASON, and further includes a new attribute indicating details regarding the reason for non-enforcement of the A1 policy; The second RIC described in Appendix 77. (Appendix 79) 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 a new A1 policy procedure that is different from the Feedback Policy procedure and the Query Policy Status procedure; The second RIC described in Appendix 74. (Appendix 80) 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-enforcement of the A1 policy; The second RIC as set forth in Appendix 79. (Appendix 81) 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; The second RIC as set forth in Appendix 79. (Appendix 82) the first RIC is an Open Radio Access Network (O-RAN) Non-Real-Time (Non-RT) RIC; The second RIC is an O-RAN Near-Real-Time (Near-RT) RIC. 82. The second RIC of any one of appendices 74 to 81. (Appendix 83) 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 details regarding the cause of non-enforcement of the A1 policy to the first RIC over the A1 interface; The details regarding the cause of non-enforcement of the A1 policy indicate (a) the new value of at least one identifier included in a 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; method. (Appendix 84) 1. A program for causing a computer to perform a method for a second Radio Access Network (RAN) Intelligent Controller (RIC) disposed between a first RIC and one or more RAN nodes, the program comprising: the method 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 indicate (a) the new value of at least one identifier included in a 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; program.

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

[0136] 1 Non-RT RIC 2. SMO Framework 3 Near-RT RIC 4 E2 nodes 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 the enforcement status of a plurality of policies, each policy including one or more policy statements; First RIC.

2. 1. A method performed by a first Radio Access Network (RAN) Intelligent Controller (RIC), comprising: receiving, in a single message, feedback from a second RIC interposed between the first RIC and one or more RAN nodes regarding the enforcement status of a plurality of policies, each policy 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 are any plurality of policies that the first RIC requests the second RIC to create or set up; The second RIC of 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. The second RIC of claim 3.

6. comprising: means 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 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 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, the method 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.

Images