Provisioning of o-ran energy-saving policies

Abstract

Example embodiments of the present disclosure relate to the provisioning of one or more O-RAN energy-saving policies. According to example embodiments, a system may include a non-real-time (Non-RT) radio access network intelligent controller (RIC). The Non-RT RIC may be configured to obtain a policy schema and then generate at least one energy-saving policy based on the policy schema for execution by a near-real-time (Near-RT) RIC. The at least one energy-saving policy may include a policy scope identifier specifying a network node to which the energy-saving policy is applied, a policy objective specifying an energy-saving target, and a policy resource specifying a condition for resource usage for the energy-saving policy. Accordingly, the Non-RT RIC may be configured to provide, to the Near-RT RIC via an A1 interface, the at least one energy-saving policy.

Description

PROVISIONING OF O-RAN ENERGY-SAVING POLICIESCROSS REFERENCE TO RELATED APPLICATION

[0001] This application claims priority to U.S. Provisional Patent Application No. 63 / 472,096 filed with the U.S. Patent and Trademark Office on June 9, 2023, and U.S. Provisional Patent Application No. 63 / 471,053 filed with the U.S. Patent and Trademark Office on June 5, 2023, the entire contents of which are incorporated herein by reference.TECHNICAL FIELD

[0002] The present disclosure relates to the provisioning of one or more energy-saving policies of the open radio access network (0-RAN).BACKGROUND

[0003] The information disclosed in this background section is only for the enhancement of understanding of the general background of the disclosure and should not be taken as an acknowledgement or any form of suggestion that this information forms the prior art already known to a person skilled in the art.

[0004] A radio access network (RAN) is an important component in a telecommunications system, as it connects end-user devices (or user equipment) to other parts of the network. The RAN includes a combination of various network elements (NEs) that connect end-users to a core network. Traditionally, hardware and / or software of a particular RAN is vendor specific.

[0005] Open RAN (O-RAN) technology has emerged to enable multiple vendors to provide hardware and / or software to a telecommunications system. Since different vendors are involved, the type of hardware and / or software provided may also be different. That is, differenttypes of NEs may be provided by different vendors, and depending on the specific service, the NE could be virtualized in software form (e.g., virtual machine (VM)-based, etc.), or could be in physical hardware form (e.g., non-VM based, etc.) Accordingly, O-RAN disaggregates the RAN functions into different entities, such as a central unit (CU), a distributed unit (DU), and a radio unit (RU). Since these entities have open protocols and interfaces between them, they can be developed by different vendors.SUMMARY

[0006] Example embodiments of the present disclosure provide systems, apparatuses, methods, and the like, that facilitate the provisioning of one or more energy-saving policies of the O-RAN

[0007] According to example embodiments, a system may include a non-real-time (Non- RT) radio access network intelligent controller (RIC). The Non-RT RIC may be configured to obtain a policy schema and then generate at least one energy-saving policy based on the policy schema for execution by a near-real-time (Near-RT) RIC. The at least one energy-saving policy may include at least one policy scope identifier specifying at least one node to which the energysaving policy is applied, at least one policy objective specifying an energy-saving target, and at least one policy resource specifying a condition for resource usage for the energy-saving policy. Accordingly, the Non-RT RIC may be configured to provide, to the Near-RT RIC via an Al interface, the at least one energy-saving policy.

[0008] According to example embodiments, a method may include: obtaining a policy schema, generating at least one energy-saving policy based on the policy schema for execution by a near-real-time (Near-RT) radio access network intelligent controller (RIC), and providing the at least one energy-saving policy to the Near-RT RIC via an Al interface. The at least one energy-saving policy may include at least one policy scope identifier specifying at least one node to which the energy-saving policy is applied, at least one policy objective specifying an energy-saving target, and at least one policy resource specifying a condition for resource usage for the energy-saving policy.

[0009] According to example embodiments, a non-transitory computer-readable recording medium may have recorded thereon instructions executable by a system that comprises a non-real- time (Non-RT) radio access network intelligent controller (RIC) to cause the Non-RT RIC to perform a method. The method may include: obtaining a policy schema, generating at least one energy-saving policy based on the policy schema for execution by a near-real-time (Near-RT) RIC, and providing the at least one energy-saving policy to the Near-RT RIC via an Al interface. The at least one energy-saving policy may include at least one policy scope identifier specifying at least one node to which the energy-saving policy is applied, at least one policy objective specifying an energy-saving target, and at least one policy resource specifying a condition for resource usage for the energy-saving policy.

[0010] Additional aspects will be set forth in part in the description that follows and, in part, will be apparent from the description, or may be realized by practice of the presented embodiments of the disclosure.BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Features, aspects, and advantages of embodiments of the disclosure will be described below with reference to the accompanying drawings, in which like reference numerals denote like elements, and wherein:

[0012] FIG. 1 illustrates an 0-RAN architecture in which one or more example embodiments may be applied;

[0013] FIG. 2 illustrates a block diagram of an example energy-saving policy, according to one or more example embodiments;

[0014] FIG. 3 illustrates a block diagram of various types of energy-saving policies, according to one or more example embodiments;

[0015] FIG. 4 illustrates a flow diagram of an example method for provisioning one or more energy-saving policies, according to one or more example embodiments; and

[0016] FIG. 5 illustrates a diagram of example components of a device for implementing one or more example embodiments.DETAILED DESCRIPTION

[0017] The following detailed description of example embodiments refers to the accompanying drawings. The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the implementations to the precise forms disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the implementations. Further, one or more features or components of one embodiment may be incorporated into or combined with another embodiment (or one or more features of another embodiment). Additionally, the flowchart and description of operations provided below relate to one of the various embodiments. It should be noted that it is possible to make other embodiments that do not exactly match the flowchart and its description. It is understood that in other embodiments one or more operations may be omitted, one or more operations may be added, one or more operations may be performed simultaneously (at least in part).

[0018] It will be apparent that systems and / or methods, described herein, may be implemented in different forms of hardware, firmware, or a combination of hardware and software. The actual specialized control hardware or software code used to implement these systems and / ormethods is not limited to the described implementations. Thus, the operation and behavior of the systems and / or methods are described herein without reference to specific software code. It is understood that software and hardware may be designed to implement the systems and / or methods based on the description herein.

[0019] Even though particular combinations of features are disclosed in the claims and / or in the specification, these combinations are not intended to limit the disclosure of implementations. In fact, many of these features may be combined in ways not specifically recited in the claims and / or disclosed in the specification. Although each dependent claim listed below may directly depend on only one claim, the disclosure of implementations includes each dependent claim in combination with every other claim in the claim set.

[0020] No element, act, or instruction used herein should be construed as critical or essential unless explicitly described as such. Also, as used herein, the articles “a” and “an” are intended to include one or more items, and may be used interchangeably with “one or more.” Also, as used herein, the terms “has,” “have,” “having,” “include,” “including,” or the like are intended to be open-ended terms. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise. Furthermore, expressions such as “at least one of [A] and [B]”, “[A] and / or [B]”, or “at least one of [A] or [B]”, are to be understood as including only A, only B, or both A and B.

[0021] It shall be noted that, descriptions of example embodiments of the present disclosure may include terms and names defined in one or more standard organizations, such as the 3rd Generation Partnership Project (3GPP) standard organization, the EuropeanTelecommunications Standards Institute (ETSI) standard organization, the Open Radio AccessNetwork (O-RAN) Alliance standard organization, and the like. For instance, the terms “rApp”,“xApp”, “Al interface”, “Al policy”, “E2 interface”, “01 interface”, “02 interface”, and the like, as well as the associated features and operations, are to be interpreted as consistent with those specified in one or more technical specifications, unless being described otherwise.

[0022] With the evolvement in telecommunication network technologies, the RAN may be disaggregated into multiple nodes or entities. Specifically, in the 0-RAN architecture, the RAN functions may be disaggregated into multiple logical nodes or entities, such as a central unit (CU), a distributed unit (DU), and a radio unit (RU). The CU may be a logical node for hosting Radio Resource Control (RRC), Service Data Adaptation Protocol (SDAP), and / or Packet Data Convergence Protocol (PDCP) sublayers of the RAN. The DU may be a logical node hosting Radio Link Control (RLC), Media Access Control (MAC), and Physical (PHY) sublayers of the RAN. A single DU may host or serve multiple network cells formed by multiple RUs. The RU may be a physical node that converts radio signals from antennas to digital signals that can be transmitted over the Front Haul to a DU. In this regard, a network cell may correspond to one or more radio units responsible for providing wireless coverage and signal transmission within the network cell. To this end, since the disaggregated entities have open protocols and interfaces between them, they can be developed by different vendors.

[0023] On the other hand, network energy-saving is an important aspect of 0-RAN in order to optimize energy efficiency, reduce operating costs, and minimize carbon footprint, while maintaining high network performance and ensuring high quality of service (QoS). In the related art, the concept of policy-based carrier and cell switch off / on for energy-saving has been introduced. Nevertheless, the specific contents of the policies involved, and the specific mechanisms for provisioning such policies, are not specified or defined in the related art. In this regard, since entities from different vendors may be involved in the 0-RAN architecture, it iscrucial to define and specify the policies for energy-saving in a standardized manner, such that entities from different vendors can understand the policies and operate accordingly for energysaving.

[0024] Example embodiments of the present disclosure provide a system, a method, a device, and the like, that facilitate the provisioning of one or more energy-saving policies, in a standardized manner. Specifically, example embodiments of the present disclosure introduce an energy-saving policy schema and leverage the non-real-time (Non-RT) radio access network intelligent controller (RIC) to generate various types of energy-saving policy based on the energysaving policy schema. Each of the types of energy-saving policy contains novel attributes or parameters that satisfy different network requirements, scenarios and use cases in O-RAN.

[0025] In this regard, it is contemplated that the example embodiments of the present disclosure may also be implemented by any suitable modules or entities in the O-RAN, without departing from the scope of the present disclosure. For instance, although it is described herein that the Non-RT RIC may utilize the policy schema to generate and provide one or more energysaving policies to the near-real-time (Near-RT) RIC, it can be understood that any other suitable modules or entities in any suitable systems (e.g., O-RAN systems, 3GPP systems, 5G systems, 6G systems, etc.) may utilize the policy schema to generate or create the one or more energy-saving policies, said one or more energy-saving policies may be provided or transferred to other suitable modules or entities in any suitable systems for utilization, and the like.

[0026] Further, it is contemplated that features, advantages, and significances of example embodiments described hereinabove are merely a portion of the present disclosure, and are not intended to be exhaustive or to limit the scope of the present disclosure. Further descriptions ofthe features, components, configuration, operations, and implementations of the example embodiments of the present disclosure are provided in the following.Example System Architecture

[0027] FIG. 1 illustrates an O-RAN architecture in which one or more example embodiments may be applied. As shown in FIG. 1, the system architecture may include at least one Service Management and Orchestration (SMO) framework 110 that includes at least one non- real-time RAN Intelligent Controller (Non-RT RIC) 120, at least one near-real-time RIC (Near- RT RIC) 130, at least one O-RAN Central Unit (O-CU) 140, at least open evolved NodeB (O-eNB) 150, at least one O-RAN Distributed Unit (O-DU) 160, a plurality of O-RAN Radio Units (O-RUs) 170, and at least one O-RAN Cloud (O-Cloud) 180. As further described below, the components may be communicatively coupled to another component(s) via a respective interface(s).

[0028] It is contemplated that the system may include more / fewer components than illustrated, and / or may be configured in a different manner, without departing from the scope of the present disclosure. For instance, in some example implementations, the system architecture may include a plurality of O-DUs 160 each of which is communicatively coupled to the O-CU 140, and the like.

[0029] Generally, the RIC may be a software-defined component that implements modular applications to facilitate multivendor operability, as well as to automate and optimize RAN operations. As shown in FIG. 1, the RIC may be divided into two types, i.e., the Non-RT RIC 120 and the Near-RT RIC 130. In the following, descriptions of the Non-RT RIC 120 are provided, followed by the descriptions of the Near-RT RIC 130.

[0030] The Non-RT RIC 120 may refer to a logical function within the SMO framework110 that drives the content carried across the Al interface to enable non-real-time control andoptimization of RAN elements and resources. The Al interface may refer to a logical interface between the Non-RT RIC 120 and the Near-RT RIC 130, which enables the Non-RT RIC 120 to provide policy-based guidance to the Near-RT RIC 130 and enables the Near-RT RIC 130 to provide one or more feedback to the Non-RT RIC 120 thereby enabling the Non-RT RIC 120 to monitor the status or implementation of one or more policies.

[0031] In some example implementations, the Non-RT RIC 120 may be the control point of a non-real-time control loop and may operate on a timescale greater than 1 second within the SMO framework 110. Generally, the functionalities of the Non-RT RIC 120 may include, for example, providing policy-based guidance and enrichment across the Al interface, performing data analytics, Artificial Intelligence / Machine Learning (AI / ML) models training and inference for RAN optimization, and / or recommending configuration management actions. In addition, as further described below, the Non-RT RIC 120 may also be configured to generate and provide one or more energy-saving policies to the Near-RT RIC 130. Further, the Non-RT RIC 120 may access or communicate with other SMO framework functionalities or components via Al interface, 01 interface, 02 interface, and one or more interfaces associated with one or more open fronthaul planes.

[0032] According to example embodiments, the functionalities of the Non-RT RIC 120 may be implemented through at least one modular, Non-RT RIC application, such as the rApp 121. The rApp 121 may leverage the functionalities available in the SMO framework 110 and / or the Non-RT RIC 120 to provide value-added services related to RAN operation and optimization, such as policy management, radio resource management, data analytics, and providing enrichment information. In some example implementations, the Non-RT RIC 120 may implement a plurality of rApps 121 .

[0033] According to example embodiments, the Non-RT RIC 120 (or the rApp 121 associated therewith) may be configured to generate and provide one or more policies to the Near- RT RIC 130 via the Al interface, and may be configured to manage one or more policies that are provided to the Near-RT RIC 130 over the Al interface. Said policies may be referred to as “Al policies” herein, and are declarative policies that contain information applicable to one or more network nodes (e.g., one or more UEs, one or more network cells, etc.) As further described below, the one or more Al policies may consist of a scope identifier and one or more policy statements. The scope identifier may specify or define the node(s) or entity(s) to which the policy is applied (e.g., cells, UEs, DUs, etc.) The policy statements may define the targets, goals or objectives of the policy and may include information associated with one or more policy objectives and one or more policy resources. According to example embodiments, at least a portion of the Al policies are associated with energy-saving operations (said policies may be referred to as “energy-saving policy” herein). The Non-RT RIC 120 (or the rApp 121 associated therewith) may create and provide the one or more Al policies to the Near-RT RIC 130 for execution by the Near-RT RIC 130, thereby providing guidance to the Near-RT RIC 130 towards one or more objectives or goals defined in the RAN intent. The RAN intent may refer to the high-level operational or business goal(s) to be achieved by the RAN, which may be defined by one or more desired service level agreements (SLAs) that the RAN is to fulfill for all users or for a subset of users in a given area over at least a predefined period of time.

[0034] According to example embodiments, the Non-RT RIC 120 (or the rApp 121 associated therewith) may be configured to perform one or more policy management operations to provide and manage one or more Al policies (e.g., energy-saving policy(s), etc.) Specifically, theNon-RT RIC 120 (or the rApp 121 associated therewith) may be configured to generate, update,and delete one or more Al policies. According to example embodiments, the Non-RT RIC 120 (or the rApp 121 associated therewith) may manage the one or more Al policies to include information associated with energy-saving (examples of the information are further described below), and then provide the one or more Al policies to the Near-RT RIC 130 via the Al interface.

[0035] According to example embodiments, the Non-RT RIC 120 (or the rApp 121 associated therewith) may be configured to receive, from the Near-RT RIC 130 viathe Al interface, one or more feedbacks associated with one or more Al policies (“Al policy feedback” herein). Similarly, the Non-RT RIC 120 (or the rApp 121 associated therewith) may be configured to receive one or more observables (e.g., events, counters, etc.) provided by the O-CU 140, the O- eNB 150, the O-DU 160, and / or one or more of the O-RUs 170 over the 01 interface. Accordingly, the Non-RT RIC 120 (or the rApp 121 associated therewith) may be configured to continuously (or periodically) manage the one or more Al policies based on the Al policy feedback(s) and / or the observables provided over the 01 interface. For instance, the Non-RT RIC 120 (or the rApp 121 associated therewith) may continuously (or periodically) evaluate the impact or effectiveness of the one or more Al policies towards the fulfillment of the RAN intent and then configure or update the one or more Al policies accordingly.

[0036] In addition to the communication with the Near-RT-RIC 130 via the Al interface, the SMO framework 110 (as well as the Non-RT RIC 120 and / or the rApp 121 implemented therein) may communicate with the Near-RT RIC 130, the O-CU 140, the O-eNB 150, the O-DU 160, and the O-RU(s) 170 via the 01 interface. In this regard, the 01 interface may refer to a logical interface between the SMO framework 110, the Near-RT RIC 130, the O-CU 140, the O- eNB 150, the O-DU 160, and the O-RU(s) 170, which enables the SMO framework 110 (as well as the Non-RT RIC 120 and the rApp 121 implemented therein) to provide Fault, Configuration,Accounting, Performance, and Security (FCAPS) and other management operations, such as network monitoring, network discovery, and the like, to the Near-RT RIC 130, the O-CU 140, the O-eNB 150, the O-DU 160, and the O-RU(s) 170. Additionally, the 01 interface enables the Near- RT RIC 130, the O-CU 140, the O-eNB 150, the O-DU 160, and the O-RU(s) 170 to provide information or observable(s) that may be utilized by the Non-RT RIC 120 (or the rApp 121 associated therewith) to manage one or more Al policies, to train one or more AI / ML models, and the like.

[0037] Further, the SMO framework 110 (as well as the Non-RT RIC 120 and / or the rApp 121 implemented therein) may communicate with the O-Cloud 180 via the 02 interface. In this regard, the 02 interface may refer to a logical interface between the SMO framework 110 and the O-Cloud 180, which may be a collection of physical RAN nodes that host the Non-RT RIC 120, the Near-RT RIC 130, the O-CU 140, and the O-DU 160, the supporting software components (e g., the operating systems and runtime environments), and the SMO framework 110 itself. In other words, the SMO framework 110 may manage the O-Cloud 180 from within, and the 02 interface may be the interface between the SMO framework 110 and the O-Cloud 180 it resides in. Through the 02 interface, the SMO framework 110 (as well as the Non-RT RIC 120 and / or the rApp 121 implemented therein) may provide infrastructure management services (IMS) and deployment management services (DMS) for the O-Cloud 180.

[0038] Furthermore, the SMO framework 110 (as well as the Non-RT RIC 120 and / or the rApp 121 implemented therein) may also communicate with the O-RU(s) 170 via an open fronthaul (O-FH) management plane (M-Plane) interface. In this regard, the O-FH M-Plane may enable the SMO framework 110 (aswell as the Non-RT RIC 120 and / or the rApp 121 implemented therein) to perform one or more FCAPS operations on the O-RU(s) 170.

[0039] Next, the descriptions of the Near-RT RIC 130 are provided. The Near-RT RIC 130 may refer to a logical function that enables near-real-time control and optimization of RAN elements and resources. For instance, the Near-RT RIC 130 may provide near-real-time control and optimization via fine-grained (e.g., UE basis, Cell basis, etc.) data collection and actions over the E2 interface. In some example implementations, the Near-RT RIC 130 may operate on a timescale between 10 milliseconds and 1 second and may be coupled with the O-CU 140, the O- eNB 150, and the 0-DU 160 via the E2 interface. The Near-RT RIC 130 may use the E2 interface to control the underlying RAN elements (E2 nodes / network functions (NFs)) over a near-real-time control loop.

[0040] According to example embodiments, the Near-RT RIC 130 may be configured to execute one or more Al policies provided by the Non-RT RIC 120 and then perform (based on the one or more Al policies) one or more energy-saving operations, such as switching a cell / carrier On / Off, handover a user from a cell to another cell, and the like. Further, the Near-RT RIC 130 may monitor, suspend / stop, override, and control the E2 nodes (e.g., O-CU 140, O-DU 160, etc.) via utilizing one or more Al policies. For example, the Near-RT RIC 130 may receive the one or more Al policies (e.g., energy-saving policy(s), etc.) from the Non-RT RIC 120 (or the rApp 121 associated therewith), and then interpret the received Al policy(s) to determine one or more control operations (e.g., energy-saving operation(s), etc.) or one or more policy commands. In some example implementation, upon receiving the Al policy(s), the Near-RT RIC 130 may collect one or more measurement data from one or more E2 nodes (e.g., O-CU 140, O-eNB 150, O-DU 160, etc.) via the E2 interface, and then determine (e.g., by performing AI / ML inference based on the received Al policy(s) and the collected measurement data, etc.) the one or more control operations thereafter. Subsequently, the Near-RT RIC 130 may generate and send one or more controlmessages (e.g., Cell / Carrier Switch On / Off message, etc.) to one or more E2 nodes and / or one or more of the O-RUs 170. Accordingly, the E2 node(s) and / or the O-RU(s) may be configured to update their associated configurations to execute one or more operations to switch on / off the cell or carrier.

[0041] According to example embodiments, the Near-RT RIC 130 may host or implement one or more applications, such as the xApp 131, to implement the associated functions or operations described herein. In this regard, the xApp 131 may consist of one or more microservices, which may be independent of the Near-RT RIC 130 and may be provided by any third party. The E2 interface may enable a direct association between the xApp 131 and other RAN functionalities (e g., O-CU 140, O-eNB 150, O-DU 160, etc.), thereby enabling the xApp 131 to provide information or data to the RAN functionalities for further utilization. According to example embodiments, the Near-RT RIC 130 may consist of multiple xApps 131 and a set of platform functions that are commonly used to support the specific functions hosted by the multiple xApps 131. In this regard, the Near-RT RIC platform may communicate with the xApp(s) 131 via one or more application programming interfaces (APIs). Further, the Near-RT RIC platform may be configured to route Al policy management messages to the registered xApps based on Al policy type and operator policies.

[0042] Next, the descriptions of the O-CU 140, the O-eNB 150, the O-DU 160, and the O- RU 170 are provided. Generally, the O-CU 140, the O-DU 160, and the 0-RU 170 may constitute a base station, such as a gNodeB (gNB) of 5G NR or a node in Next Generation Radio Access Network (NG-RAN), a base station of a 6G network, and the like. On the other hand, the O-eNB150 may refer to a 4G LTE version of the O-RAN-compliant node (e.g., an eNB that adheres to the O-RAN architecture).

[0043] The communication between the O-CU 140 and the O-DU 160 may be performed via an Fl interface, while the communication between the O-DU 160 and the O-RU 170 may be performed via one or more O-FH Control (C), User (U), Synchronization (S), and Management (M) plane interfaces. In some example implementations, the C, U, and S planes may be consolidated and referred to as the “CUS-plane”. According to example embodiments, the system may include a plurality of O-DUs 160, and the O-CU 140 may be communicatively coupled to the plurality of O-DUs via the Fl interface. Similarly, the system may include a plurality of O-RUs 170, and the O-DU(s) 160 may be communicatively coupled to the plurality of O-RUs via one or more of the O-FH C / U / S / M plane interfaces.

[0044] According to example embodiments, the O-CU 140 and the O-DU 160 may be defined in software form and may be deployed in one or more network nodes. For instance, the O- CU 140 and the O-DU 160 may be deployed in one or more servers in the form of virtualized network function (VNF), containerized and / or cloud-native function (CNF), and the like. According to example embodiments, the O-CU 140 and the O-DU 160 may be deployed in the same node (e.g., same server) and / or may be located at a similar geographical location (e.g., be deployed in different servers in the same data center). According to embodiments, the O-CU 140 and the O-DU 160 may be deployed in different nodes and / or may be located at different geographical locations. For instance, the O-CU 140 may be deployed in one or more central servers (i.e., servers in one or more central data centers), and the O-DU 160 may be deployed in one or more edge servers (i.e., servers in one or more edge data centers).

[0045] The O-DU 160 may receive radio signals from an end user (via one or more UEs and one or more cells) and may provide operation or support for lower layers of protocol stacks(e.g., RLC layer, MAC layer, Physical Layer, etc.) accordingly. As an example, the O-DU 160may perform one or more scheduling operations. The O-CU 140 may communicatively couple the O-DU 160 to a core network (e.g., 4G Evolved Packet Core (EPC) network, 5G Core network, etc.) and may receive the radio signals from the O-DU 160, thereby providing operation or support for higher layers of protocol stacks (e g., PDCP layer, RRC layer, etc.) accordingly.

[0046] According to example embodiments, the O-CU 140 may include an O-CU control plane (O-CU-CP) 141 and an O-CU user plane (O-CU-UP) 142. The O-CU-CP 141 may refer to the logical node that hosts or implements the RRC and the control plane part of the PDCP protocol, and may be responsible for managing the signaling between the core network and the radio network, handling tasks such as session management, radio bearer control, and mobility management. On the other hand, the O-CU-UP 142 may refer to the logical node that hosts or implements the user plane part of the PDCP protocol and the SDAP protocol, and may be responsible for managing the data traffic and the transmission of user data packets. The O-CU-CP 141 and the O-CU-UP 142 may be coupled to each other via the El interface.

[0047] Further, a single O-DU 160 may host or serve multiple network cells formed by multiple O-RUs 170. According to example embodiments, the O-DU 160 may implement various radio technologies, such as massive multiple-input multiple-output (MIMO), beamforming, and the like, to optimize radio communication among the multiple cells and the O-CU 140. In some example implementations, the O-DU 160 may concurrently host or serve hundreds (e.g., 512, etc.) of cells at a time.

[0048] The O-RU(s) 170 may be a physical node that converts radio signals from antennas to digital signals that can be transmitted over the Front Haul to the O-DU 160. In this regard, a network cell described herein may correspond to one or more radio units responsible for providing wireless coverage and signal transmission within the network cell. The network cell may includea macro cell, a micro cell, a pi co cell, a femto cell, and / or any other suitable type of network cell. Each of the cells may have an associated coverage area, in which at least one O-RU 170, at least one antenna system, and any other suitable type of transport network element (TNE), may be deployed therein.

[0049] According to example embodiments, the 0-DU 160 may be configured to control or instruct the associated O-RU(s) via one or more of the O-FH C / U / S / M plane interfaces. For instance, the O-DU 160 may instruct the O-RU(s) 170 to shut down or enter sleep mode via the O-FH C / U / S plane interfaces. On the other hand, the capability exchange between the SMO 110 and the O-RU(s) 170 may be performed via the O-FH M-plane interface. As an example, the O- RU(s) 170 may inform the SMO 110 of the amount of time it requires to maintain in sleep mode (or off mode) in order to save an amount of energy, and the like.

[0050] In view of the above, example embodiments of the present disclosure introduce a mechanism for provisioning one or more energy-saving policies in the O-RAN architecture. Specifically, the Non-RT RIC 120 may be utilized to generate and provide various types of energysaving policies to the Near-RT RIC 130, and the Near-RT RIC 130 may utilize the energy-saving policies provided by the Non-RT RIC 120 to perform appropriate energy-saving operation(s). Further details of the energy-saving policies are provided in the following.Energy-saving Policies

[0051] As described above, example embodiments of the present disclosure facilitate the provisioning of one or more energy-saving policies. Specifically, example embodiments provide a system that includes a Non-RT RIC (or an apparatus / device that implements the Non-RT RIC) configured to generate at least one energy-saving policy for execution by a Near-RT RIC and then provide the at least one energy-saving policy to the Near-RT RIC. In this regard, exampleembodiments introduce new attributes and parameters for defining and specifying various types of energy-saving policies. These new attributes and parameters supplement those specified for the Al policies in the current version of technical specifications provided by the standard organizations like the O-RAN Alliance (e g., 0-RAN.WG2.A1TD). Further, as further described below, in some example embodiments, the Non-RT RIC may be configured to obtain a policy schema and then generate the at least one energy-saving policy based on the policy schema. In this regard, example embodiments introduce a new policy schema that include new attributes and parameters associated with energy-saving. In the following, descriptions of the example energysaving policies and example policy schema, according to one or more example embodiments, are provided.

[0052] FIG. 2 illustrates a block diagram of an example energy-saving policy, according to one or more example embodiments. As illustrated in FIG. 2, the energy-saving policy includes information associated with at least one policy scope identifier, at least one policy objective, and at least one policy resource. In some example implementations, the policy objective and the policy resource may form a policy statement.

[0053] The information of the energy-saving policy may be represented in simple data types and structured data types. The simple data types may refer to the basic data types that represent single parameters, such as integers, floating-point values, characters, and the like. On the other hand, the structured data types may refer to a collection of data items that is organized in a structured manner.

[0054] Examples of simple data types for scope and statements associated with the energysaving policy may be defined in Table 1 below.Table 1: Definition of simple data types for scope and statements

[0055] Further, the enumeration OperatorType (that represents the preference of a specific comparison operator) associated with the energy-saving policy may be defined in the following Table 2.Table 2: Definition of OperatorType

[0056] According to example embodiments, the scope identifier of the energy-saving policy may specify at least one node to which the energy-saving policy is applied or applicable. Specifically, the scope identifier may include information defining the target network entity or node such as one or more of a user equipment (UE) identifier (ID), a group ID associated with multiple UEs, a cell ID, a slice ID associated with a network slice, a network ID (e.g., public land mobile network (PLMN) ID, etc ), a gNodeB (gNB) ID, an O-RU ID, an O-DU ID, O-CU ID, a cell ID list comprises a plurality of cell IDs, a gNB ID list comprises a plurality of gNB IDs, anO-RU ID list comprises a plurality of O-RU IDs, an O-DU ID list comprises a plurality of O-DU IDs, an O-CU ID list comprises a plurality of O-CU IDs, a slice ID list comprises a plurality of slice IDs, and a network ID list comprises a plurality of network IDs. As further described below, by specifying the scope identifier based on the network levels or layers (e g., network level, slice level, node level, etc.), the energy-saving policy may be specified and defined for optimizing energy efficiency in various network levels or layers (e.g., cell level, slice level, node level, network level, etc.)

[0057] According to example embodiments, the policy scope identifier may be defined in the form of structured data type and may be referred to as “Scopeidentifier”. It is contemplated that the policy scope identifier described herein may also be referred to or be defined in any other suitable terms, without departing from the scope of the present disclosure. In this regard, the policy scope identifier may contain one or more information or attributes as defined in the following Table 3.Table 3: Definition of data type Scopeidentifier

[0058] The presence of condition “C” in Table 3 means that at least one attribute shall be included when the scope of the policy is defined. The allowable combinations of attributes may depend on the policy statement (i.e., the policy objective and policy resource, etc.) that is combined with the scope identifier and may be policy type specific.

[0059] On the other hand, the policy objectives and policy resources may form one or more statements that define the targets, goals, or objectives of the energy-saving policy. The definitions of structured data types or attributes that may be used in statements for policy objectives and / or statements for policy resources may be defined in the following Table 4.Table 4: Definition of data types associated with policy objectives / resources

[0060] The presence of condition “C” in Table 4 means that at least one attribute shall be included when the scope of the policy is defined. The presence of condition “O” in Table 4 means that data type can be optionally included.

[0061] According to example embodiments, the policy objective may specify an energysaving target. For instance, the information associated with the policy objective may include one or more of: an energy-saving objective (may be referred to as “ES” or “EsObj ectives” herein and may be computed based on a formula of ES =Delta EC %, wherein “EC” refers to a specific energy consumption), an energy efficiency objective (may be referred to as “EE” herein), a RAN energy consumption objective (may be referred to as “ECNG-RAN” herein), a gNB energy consumption objective (may be referred to as “ECgNB” herein), a network service energy consumption objective (may be referred to as “ECns” herein), a network function energy consumption objective (may bereferred to as “ECNF” herein), and a quality of service (QoS) objective. According to example embodiments, the EE objective may include one or more EE objectives associated with various network levels or layers, such as a PLMN level EE objective (may be referred to as “EEMN, Dvbits / j” herein), a slice level EE objective, a node level EE objective, and the like.

[0062] According to example embodiments, the structured data types and attributes that may be used for defining the policy objectives may be defined in the following Table 5.Table 5: Statements for policy objectives

[0063] According to example embodiments, the policy resource may specify a condition for resource usage for the energy-saving policy. For instance, the information associated with the policy resource may include one or more of: a condition list, an inclusion list, and an exclusion list. In this regard, the condition list may include one or more of: a network condition and a timing condition. The inclusion list may include information of one or more nodes to which one or more energy-saving operations can be applicable. The exclusion list may include information of one or more nodes that should be excluded from the one or more energy-saving operations.

[0064] According to example embodiments, the structured data types and attributes that may be used for defining the policy resources may be defined in the following Table 6.Table 6: Statements for policy resources

[0065] The types, contents or attributes of the energy-saving resources (referred to as “EsResources” herein) may be further defined in the following Table 7.Table 7: Definition of type EsResource

[0066] An esResources statement may be defined in the following Table 8 as an array of the type EsResource defined in the above Table 7.Table 8: Definition of statement type EsResources

[0067] According to example embodiments, when the value of the preference attribute is set to “PREFER” or “AVOID”, the cellldList contains cells in descending order of importance for how they should be preferred or avoided, e.g., the first entry is the most preferred or most avoided. When the preference value is set to “SHALL” or “FORBID”, the cellldList contains cells that are of equal importance.

[0068] According to example embodiments, when the value of the primary attribute (i.e., attribute of a primary cell) is set to “true”, and / or the value of the preference attribute is set to “SHALL”, then only a cell in the cellldList is to be used as the primary cell. When the value of the primary attribute is set to “true”, and / or the value of the preference attribute (i.e., attribute of a preference cell) is set to “PREFER”, then a cell in the cellldList may be used as the primary cell.When the value of the primary attribute is set to “true”, and the preference value is set to “AVOID” or “FORBID”, then no cell in the cellldList is to be used as the primary cell.

[0069] Further, an EsObjective statement may contain the attribute defined in the following Table 9:Table 9: Definition of statement type EsObjectives

[0070] In the example of above Table 9, the EsObjectives refer to a policy objective that includes attributes associated with the maximum number of user equipment (UE). This policy objective may help in triggering energy-saving operation(s) based on the number of UE (e.g., when UEs<2). According to example embodiments, the energy-saving policy may have a dedicated identifier. For example, the identifier may be referred to as “ORAN_EnergySavings_2.0.0”.

[0071] According to a non-limiting use case, a traffic steering policy (TSP) statement may be combined with one or more information or contents of the energy-saving policy. For instance, the TSP statement may be applied together with Scopeidentifier containing different combinations of identifiers. Example combinations of TSP statement with Scopeidentifier are presented in the following Table 10.Table 10: Example combinations of tspResources statement with Scopeidentifier

[0072] In above Table 10, each row is listed with a combination of identifiers that is allowed for the indicated statement. In this regard, the notation is the same as for cardinality: "0" means the identifier shall not occur, "0..1" means the identifier may occur, and "1" means the identifier shall occur.

[0073] According to example embodiments, the parameters and characteristics of an energy-saving policy may be defined by a policy schema. In this regard, a policy schema may define or specify a structured format that outlies the attributes and contents of the energy-saving policy. For instance, the policy schema may specifies the name, descriptions, statements, and data structure of the energy-saving policy, which may include the types of parameters, the associated values and settings, and the like. According to example embodiments, the energy-saving policy may be defined in the format of JavaScript Object Notation (JSON). In that case, the energy-saving policy may be generated or defined by the Non-RT RIC based on an associated JSON-based policy schema. Specifically, the JSON policy schema outlines the attributes or fields, the associated data types, and any other policy requirements that are required for defining an energy-saving policy, and may be obtained and utilized by the Non-RT RIC to define, generate, and configure the energysaving policy.

[0074] An example of the JSON schema associated with the energy-saving policy, according to one or more example embodiments, is presented in the following Table 11. Merelyfor descriptive purposes, the portions that are associated with the energy-saving configurations (e.g., scope identifier, policy objective, resources, etc.) are reflected in bold.Table 11: Example JSON based policy schema

[0075] According to example embodiments, the Non-RT RIC may obtain the policy schema and then generate, based on the policy schema, various types of energy-saving policies for execution by the Near-RT RIC. For instance, FIG. 3 illustrates a block diagram of various types of energy-saving policies, according to one or more example embodiments. As illustrated in FIG. 3, the energy-saving policy may be categorized into at least one of: an energy threshold-based energy-saving policy, a service assurance threshold-based energy-saving policy, a network condition-based energy-saving policy, a timing condition-based energy-saving policy, and a combination thereof. These energy-saving policies may be generated and provided by the Non-RTRIC, and may be executed by the Near-RT RIC to perform one or more energy-saving operations. In the following, examples of each of the aforesaid types of energy-saving policy are described.Energy Threshold-based Energy-Savins Policy

[0076] This type of energy-saving policy establishes specific threshold(s) or limit(s) defined by energy-related criteria or parameters (e.g., energy consumption objective, energy efficiency objective, energy-saving objective, etc.) for triggering or initiating the execution of one or more energy-saving operations. For instance, when the energy-related criteria (e.g., energy usage) exceeds or falls below this threshold(s), the energy-saving policy may trigger one or more operations to optimize energy savings.

[0077] According to example embodiments, the policy scope identifier of the energy threshold-based policy may specify one or more nodes to which the energy threshold-based policy should be applied. In this regard, the policy scope identifier may include one or more of: a cell ID, a slice ID, a network ID, a gNB ID, an 0-RU ID, an 0-DU ID, an O-CU ID, a cell ID list that includes a plurality of cell IDs, a gNB ID list that includes a plurality of gNB IDs, an 0-RU ID list that includes a plurality of O-RU IDs, an 0-DU ID list that includes a plurality of 0-DU IDs, an O-CU ID list that includes a plurality of O-CU IDs, a slice ID list that includes a plurality of slice IDs, and a network ID list that includes a plurality of network IDs.

[0078] Further, the policy objective of the energy threshold-based policy may specify one or more energy-saving targets. In this regard, the policy objective may include an energy parameter that associates with the energy-saving target and defines a threshold for initiating the execution of one or more energy-saving operations. For instance, the policy objective of said policy may include one or more of: an energy-saving objective (ES), an energy efficiency objective (e.g., energy efficiency objective of a PLMN (EEMN,DVbits / j), etc ), a RAN energy consumption objective (ECNG-RAN), a gNB energy consumption objective (EC§NB), a network service energy consumption objective (ECns), and a network function energy consumption objective (ECNF).

[0079] Furthermore, the policy resource of the energy threshold-based policy may specific a condition for resource usage for the energy threshold-based policy. For instance, the policy resource may include one or more of: an inclusion list, an exclusion list, and resources or preferences based on the scope identifier(s). In this regard, the inclusion list may include information of one or more nodes (e.g., cell ID, network ID, O-RU ID, etc.) to which the energysaving operation(s) can be applicable, while the exclusion list may include information of one or more nodes that should be excluded from the energy-saving operation(s).

[0080] According to example embodiments, the energy threshold-based policy may be applicable to different network levels or layers. For instance, the energy threshold-based policy may be utilized for optimizing slice level energy efficiency, for optimizing node level (e.g., gNB / O-CU / O-DU / O-RU level) energy efficiency, for optimizing cell level energy efficiency, for optimizing PLMN level energy efficiency, and the like.

[0081] An example of an energy threshold-based policy for optimizing slice level energysaving is defined in the following Table 12.Table 12: Example slice level energy threshold-based policy

[0082] In the example of Table 12, the scope identifier of the energy policy includes a slice ID that defines the specific network slice(s) to which the energy-saving policy is applicable and a PLMN ID that defines the PLMN associated with the target network slice. Further, the policy objective of the energy policy includes an energy efficiency objective defining a threshold for initiating the energy-saving operation(s). Furthermore, the policy resources may include an exclusion list that specifies the cells that may be excluded from the energy-saving operation(s). Such cells may refer to cells of specific areas, such as a high-capacity zone, a hospital, and the like. In this case, once the energy efficiency of the specified network slice is lower than the threshold defined by the energy efficiency objective, the Near-RT RIC can execute or trigger at least one energy-saving operation(s) on the associated cell(s), such as shutting down one or morecells among the network slice (cells other than those specified in the exclusion list), to achieve or maintain the energy efficiency objective.

[0083] Further, an example of an energy threshold-based policy for optimizing node level energy-saving is defined in the following Table 13.Table 13: Example node level energy threshold-based policy

[0084] In the above example, the energy-saving policy has the same policy resources as the energy-saving policy defined in above Table 12. This energy-saving policy in Table 13 isdifferent from the one in Table 12 in that, instead of a slice ID and PLMN ID, the associated scope identifier contains an ID of a specific node (e.g., gNB-DU ID of a DU) to which the energy-saving operations are applicable. Further, the associated policy objective contains an energy consumption objective (instead of an energy efficiency objective as in Table 12) defining a threshold for initiating the energy-saving operation(s). In this case, once the energy consumption of the associated DU(s) exceeds / is lower than the threshold defined by the energy consumption obj ective, the Near-RT RIC can perform or execute the energy-saving operation(s) to maintain the energy consumption of the associated node to satisfy the energy consumption objective.

[0085] Next, an example threshold-based energy-saving policy for optimizing network level energy-saving is defined in the following Table 14.Table 14: Example network level energy threshold-based policy

[0086] In the example of Table 14, the scope identifier of the energy-saving policy includes a PLMN ID that defines the specific PLMN to which the energy-saving policy is applicable. Further, the policy objective of the energy policy includes an energy efficiency objective (EEMN.DV) that defines a threshold for initiating the energy-saving operation(s). Furthermore, the policy resources include an inclusion list that specifies the O-RUs to which the energy-saving operation(s) is applicable and an exclusion list that specifies the O-RUs that may be excluded from the energysaving operation(s). In this case, once the energy efficiency of the associated PLMN exceeds / is lower than the threshold defined by the energy efficiency objective, the Near-RT RIC can perform or execute the energy-saving operation(s) to maintain the energy efficiency of the associated PLMN to satisfy the energy efficiency objective.

[0087] In view of the above, the provisioning of an energy threshold-based energy-saving policy enables the establishment of one or more energy-saving objectives in the form of measurable thresholds, encompassing factors like energy efficiency and energy consumption. These energy-saving objectives can be implemented with or without the allocation of policy resources, allowing for the creation of inclusion or exclusion listsService Assurance Threshold-based Energy-Saving Policy

[0088] This type of energy-saving policy includes or prioritizes service assurance criteria or parameters that define the threshold for initiating or triggering the execution of one or more energy-saving operations. Specifically, the policy objective of the service assurance thresholdbased energy-saving policy may include at least one QoS objective that defines a threshold for initiating the execution of the one or more energy-saving operations.

[0089] According to example embodiments, the policy objective of the service assurance threshold-based energy-saving policy may include both QoS objective(s) and energy-related objective(s) (e.g., energy efficiency objective, energy consumption objective, energy-saving objective, etc.), thereby facilitating energy efficiency while maintaining a specified level of QoS. Namely, one or more QoS Objectives can be set along with one or more energy-related objectives to achieve a certain level of service assurance. By integrating both types of objectives, energy consumption may be optimized without compromising on the desired QoS.

[0090] It is contemplated that the service assurance threshold-based energy-saving policy may include one or more policy scope identifiers and one or more policy resources that are similar to those described above with reference to the energy threshold-based energy-saving policy, without departing from the scope of the present disclosure.

[0091] Further, similar to the energy threshold-based energy-saving policy, the service assurance threshold-based energy-saving policy may be applicable to different network levels or layers. For instance, the service assurance threshold-based energy-saving policy may be utilized for optimizing slice level energy efficiency, for optimizing node level (e.g., gNB / O-CU / O-DU / O- RU level) energy efficiency, for optimizing cell level energy efficiency, for optimizing PLMN level energy efficiency, and the like.

[0092] An example of a service assurance threshold-based policy for optimizing network level energy-saving is defined in the following Table 15.Table 15: Example network level service assurance threshold-based policy

[0093] In the example of Table 15, the scope identifier of the energy-saving policy includes a PLMN ID that defines the specific PLMN to which the energy-saving policy is applicable, and a QoS ID that defines the QoS to which the energy-saving policy is applicable. Further, the policy objective of the energy policy includes an energy-saving objective and a plurality of QoS objectives that define one or more thresholds for initiating the energy-saving operation(s). Furthermore, the policy resources include a cell-wise inclusion list that specifies the cells to which the energy-saving operation(s) is applicable and a cell-wise exclusion list that specifies the cells that may be excluded from the energy-saving operation(s). In this case, once the energy efficiency of the associated PLMN exceeds / is lower than the threshold defined by the energy efficiency objective and / or once the QoS exceeds / is lower than the threshold(s) defined by the QoS objectives, the Near-RT RIC can trigger or perform the energy-saving operation(s) to the cells defined in the inclusion list while avoiding performing the energy-saving operation(s) to the cells defined in the exclusion list, thereby achieving the energy efficiency objective while ensuring the QoS objectives for the specific QoS.

[0094] Another example of a service assurance threshold-based policy for optimizing network level energy-saving is defined in the following Table 16.Table 16: Example network level service assurance threshold-based policy

[0095] In the example of Table 16, the energy-saving policy has the policy scope identifiers and policy objectives similar to the energy-saving policy in Table 15. The energy-saving policy in Table 16 is different from the one in Table 15 in that, the associated policy resources include a node level inclusion list that specifies the O-DUs to which the energy-saving operation(s) is applicable. In this case, once the energy efficiency of the associated PLMN exceeds / is lowerthan the threshold defined by the energy efficiency objective and / or once the QoS exceeds / is lower than the threshold(s) defined by the QoS objectives, the Near-RT RIC can trigger or perform the energy-saving operation(s) to the O-DUs defined in the inclusion list while avoiding triggering or performing the energy-saving operation(s) to the cells defined in the exclusion list, thereby achieving the energy efficiency objective while ensuring the QoS objectives for the specific QoS.

[0096] Next, an example of a service assurance threshold-based policy for optimizing slice level and cell level energy-saving is defined in the following Table 17.Table 17: Example network level and cell level service assurance threshold-based policy

[0097] In the example of Table 17, the scope identifier of the energy-saving policy may include a slice ID that defines the network slice to which the energy-saving policy is applicable and a cell ID that defines the network cell to which the energy-saving policy is applicable. Further, the policy objective of the energy policy includes an energy-saving objective and a plurality of QoS objectives that define one or more thresholds for initiating the energy-saving operation(s). Furthermore, the policy resources include an inclusion list that specifies the cells to which the energy-saving operation(s) is applicable and an exclusion list that specifies the cells that may be excluded from the energy-saving operation(s). In this case, once the energy efficiency of the associated slice and / or cell exceeds / is lower than the threshold defined by the energy efficiency objective and / or once a specific QoS exceeds / is lower than the threshold(s) defined by the QoS objectives, the Near-RT RIC can trigger or perform the energy-saving operation(s) to the cells defined in the inclusion list while avoiding triggering or performing the energy-saving operation(s) to the cells defined in the exclusion list, thereby achieving the energy efficiency objective while ensuring the QoS objectives for the specific QoS.

[0098] In addition to cell / carrier shutdown, the Near-RT RIC can also trigger handovers of low-priority users from target cells to neighboring cells. In such scenarios, the Near-RT RIC is responsible for maintaining the specified QoS for those users within the defined scope identifiers. This ensures a seamless transition for users while optimizing energy consumption.

[0099] In view of the above, by provisioning the service assurance threshold-based energysaving policy, energy efficiency can be optimized while maintaining a specified level of QoS, thereby achieving a certain level of service assurance. By integrating both energy-related objective(s) and QoS objective(s), energy consumption can be optimized without compromising on desired QoS.Network Condition-based Energy-Savins Policy

[0100] This type of energy-saving policy includes or prioritizes network criteria or parameters for initiating the execution of one or more energy-saving operations. According to example embodiments, the network condition-based energy-saving policy involves the activation of policy objective(s) after a specific network condition(s) is met, as determined by the Near-RT RIC. This approach allows the implementation of energy-saving measures when the predefined network conditions are satisfied, optimizing overall energy efficiency.

[0101] According to example embodiments, the policy resource of the network conditionbased energy-saving policy may include at least one network condition for triggering or initiating the execution of the one or more energy-saving operations. The network condition may include one or more of network traffic, number of users in RRC state, number of active users, physical resource block (PRB) usage, and energy-related criteria (e.g., energy efficiency, energy consumption, etc.)

[0102] It is contemplated that the network condition-based energy-saving policy may include one or more policy scope identifiers and one or more policy objectives that are similar to those described above with reference to the energy threshold-based energy-saving policy and the service assurance threshold-based energy-saving policy, without departing from the scope of the present disclosure.

[0103] Further, the network condition-based energy-saving policy may be applicable to different network levels or layers. For instance, the network condition-based energy-saving policy may be utilized for optimizing slice level energy efficiency, optimizing node level (e.g., gNB / O- CU / O-DU / O-RU level) energy efficiency, optimizing cell level energy efficiency, optimizing PLMN level energy efficiency, and the like.

[0104] An example of a network condition-based policy for optimizing network level energy-saving is defined in the following Table 18.Table 18: Example network level network condition-based policy

[0105] In the example of Table 18, the scope identifier of the energy-saving policy may include a PLMN ID that defines the PLMN to which the energy-saving policy is applicable. Further, the policy objective of the energy policy includes an energy efficiency objective. Furthermore, the policy resources includes a condition list that includes a plurality of network conditions, an inclusion list that specifies the cells to which the energy-saving operation(s) is applicable when one or more of the network conditions in the condition list is satisfied, and an exclusion list that specifies the cells that may be excluded from the energy-saving operation(s). In this case, once the energy efficiency of the associated PLMN exceeds / is lower than the thresholddefined by the energy efficiency objective, the Near-RT RIC may determine whether or not the one or more network conditions are satisfied. Accordingly, based on determining that the one or more network conditions are satisfied, the Near-RT RIC can trigger or perform the energy-saving operation(s) to the cells defined in the inclusion list while avoiding triggering or performing the energy-saving operation(s) to the cells defined in the exclusion list, thereby achieving the energy efficiency objective.

[0106] In view of the above, the inclusion of the network condition(s) in the energy-saving policy allows Near-RT RIC to initiate or execute energy-saving operation(s) (e.g., cell / carrier shutdown, users handover, etc.) when the specified network condition(s) is satisfied. With measurements conducted at lower latency, the Near-RT RIC can swiftly implement and recover appropriate operation(s), leveraging a more efficient control loop. Further, the configuration or selection of the network conditions of the energy-saving policy can be decided based on a specific preference or priority. Furthermore, specifying the network conditions provides the network operator with the ability to trigger the energy-saving operation(s) when complexities in xApp are unexpected or when rApp dictates terms, especially when using xApps from different providers. Timins Condition-based Energy-Savins Policy

[0107] This type of energy-saving policy includes or prioritizes timing criteria or parameters for initiating the execution of one or more energy-saving operations. Specifically, the energy-saving operation(s) may be initiated based on specific time intervals or schedules (e.g., off- peak hours or periods of low network activity, etc.) defined in the policy.

[0108] According to example embodiments, the policy resource of the timing conditionbased energy-saving policy may include at least one timing condition for initiating the execution of the one or more energy-saving operations. The timing condition may include one or more of:an energy-saving allowed time period (esAllowedTimePeriod) and an energy-saving not allowed time period (esNotAllowedTimePeriod). These time periods may include timing information such as period of day, days of week, and the like.

[0109] It is contemplated that the network condition-based energy-saving policy may include one or more policy scope identifiers and one or more policy objectives that are similar to those described above with reference to the energy threshold-based energy-saving policy, the service assurance threshold-based energy-saving policy, and the network condition-based energysaving policy, without departing from the scope of the present disclosure.

[0110] Further, the timing condition-based energy-saving policy may be applicable to different network levels or layers. For instance, the timing condition-based energy-saving policy may be utilized for optimizing slice level energy efficiency, for optimizing node level (e.g., gNB / O-CU / O-DU / O-RU level) energy efficiency, for optimizing cell level energy efficiency, for optimizing PLMN level energy efficiency, and the like.[0U1] An example of a timing condition-based policy for optimizing network level energy-saving is defined in the following Table 19.Table 19: Example network level network condition-based policy

[0112] In the example of Table 19, the scope identifier of the energy-saving policy may include a PLMN ID that defines the PLMN to which the energy-saving policy is applicable. Further, the policy objective of the energy policy includes an energy efficiency objective. Furthermore, the policy resources include a condition list that includes a plurality of timing conditions (e.g., esNotAllowedTimePeriod, esAllowedTimePeriod, etc.) and an inclusion list that specifies the cells to which the energy-saving operation(s) is applicable when one or more of the timing conditions in the condition list is satisfied. In this case, during the esAllowedTimePeriod (e g., nighttime from Monday to Friday), when the Near-RT RIC determines that the energy efficiency of the associated PLMN exceeds / is lower than the threshold defined by the energyefficiency objective, the Near-RT RIC may trigger or perform the energy-saving operation(s) to the cells defined in the inclusion list, thereby achieving the energy efficiency objective. On the other hand, during the esNotAllowedTimePeriod (e.g., daytime from Monday to Friday)), the Near-RT RIC will not utilize the specific energy-saving policy to initiate or perform the energysaving operation(s).

[0113] In view of the above, the timing condition-based energy-saving policy entails the activation of an energy-saving policy for designated time periods while excluding the same during specified times. This approach enables adjustment of energy consumption, particularly during off- peak hours or periods of low network activity. By implementing the timing condition-based energy-saving policy, the network operator can optimize energy usage based on the fluctuating demands of the network, promoting efficient resource utilization.Multi-Types Energy-Saving Policy

[0114] In addition to the above mentioned four types of energy-saving policies (i.e., energy threshold-based energy-saving policy, service assurance threshold-based energy-saving policy, network condition-based energy-saving policy, and timing condition-based energy-saving policy), the Non-RT RIC may also be configured to generate and provide one or more energy-saving policies that include multi-types of the aforementioned energy-saving policies.

[0115] An example of a multi-type energy-saving policy for optimizing slice level and cell level energy-saving is defined in the following Table 20.Table 20: Example combination of netw ork condition-based policy and timing condition-based policy

[0116] In the example of Table 20, the scope identifier of the energy-saving policy may include a slice ID that defines the network slice to which the energy-saving policy is applicableand a cell ID that defines the network cell to which the energy-saving policy is applicable. Further, the policy objective of the energy policy includes an energy-saving cell shutdown objective. In this regard, the cell shutdown objective may be an action oriented objective that may be enforced or initiated by the Near-RT RIC according to the conditions defined in the energy-saving policy (e.g., shutdown a specific cell when a specific timing condition is satisfied, etc.) Furthermore, the policy resources includes a condition list that includes a timing condition (e.g., esNotAllowedTimePeriod) and a plurality of network conditions (e.g., prbusage, rrcusers, etc.), an inclusion list that specifies the cells to which the energy-saving operation(s) is applicable when one or more conditions in the condition list are satisfied, and an exclusion list that specifies the cells that may be excluded from the energy-saving operation(s). In this case, the Near-RT RIC will only implement the energy-saving policy when the timing condition is satisfied (i.e., outside of the time period defined by the esNotAllowedTimePeriod). Upon determining that the timing condition is satisfied, the Near-RT RIC may further determine whether or not the network condition(s) is satisfied. Accordingly, the Near-RC RIC may shut down the cells defined in the inclusion list (or trigger an operation to shutdown said cells) while avoiding shutting down the cells defined in the exclusion list, thereby achieving the energy-saving cell shutdown objective.

[0117] It is contemplated that any other suitable combination is applicable for provisioning the multi-type energy-saving policy, such as the combination of three types or all types of energysaving policies, without departing from the disclosure of the present disclosure.

[0118] To this end, by leveraging different types of energy-saving policy and different combinations of the different types of energy-saving policy, example embodiments of the present disclosure efficiently and effectively facilitate the provisioning of energy policies that comply with the dynamic and complex nature of policy requirements in O-RAN.

[0119] It can be understood that the above-described energy policies (in Tables 12-20) are merely examples of possible configurations and the contents thereof are simplified for descriptive purposes. In the actual implementations, said energy policies may include more or less information and / or the contents therein may be arranged in a different manner, without departing from the scope of the present disclosure.Example Operations for Provisioning Energy-Saving Policy

[0120] As described above, example embodiments of the present disclosure facilitate the provisioning of one or more energy-saving policies. Example operations associated therewith are described in the following.

[0121] FIG. 4 illustrates a flow diagram of an example method 400 for provisioning one or more energy-saving policies, according to one or more example embodiments. One or more operations of the method 400 may be performed by a Non-RT RIC included in a system (e.g., the Non-RT RIC 120 in an O-RAN system as described above with reference to FIG. 1, etc.) In some example implementations in which the Non-RT RIC 120 is implemented in an apparatus or a hardware (e.g., a server), one or more operations of the method 400 may be performed by a component of the hardware (e.g., a processor of the server) upon executing computer-readable instruction (stored in a memory of the server, etc.)

[0122] Referring to FIG. 4, at operation S410, the Non-RT RIC may be configured to obtain a policy schema. The policy schema may be obtained from a memory or a storage component of the hardware (e.g., server) in which the Non-RT RIC is implemented, or may be obtained from a different storage medium (e.g., another server, etc.) Further, the policy schema may be obtained from any suitable components or entities in the O-RAN system. According toexample embodiments, the policy schema may include a JSON schema (an example associated therewith has been described above with reference to Table 11).

[0123] Upon obtaining the policy schema, the method 400 may proceed to operation S420, at which the Non-RT RIC may be configured to generate, based on the policy schema, at least one energy-saving policy for execution by a Near-RT RIC. According to example embodiments, the at least one energy-saving policy may include at least one of: an energy threshold-based energysaving policy, a service assurance threshold-based energy-saving policy, a network conditionbased energy-saving policy, and a timing condition-based energy-saving policy.

[0124] As described above, in general, an energy-saving policy may include information associated with at least one policy scope identifier specifying at least one node to which the energysaving policy is applied, at least one policy objective specifying an energy-saving target, and at least one policy resource specifying a condition for resource usage for the energy-saving policy. In this regard, the at least one policy objective of the energy threshold-based energy-saving policy may include an energy parameter that defines a threshold for initiating the execution of one or more energy-saving operations, the at least one policy objective of the service assurance thresholdbased energy-saving policy may include a QoS objective that defined a threshold for initiating the execution of the one or more energy-saving operations, the at least one policy resource of the network condition-based energy-saving policy may include a network condition for initiating the execution of the one or more energy-saving operations, and the at least one policy resource of the timing condition-based energy-saving policy may include a timing for initiating the execution of the one or more energy-saving operation.

[0125] Further, in some example embodiments, the at least one policy scope identifier may include one or more of: a cell ID, a slice ID, a network ID, a gNB ID, an 0-RU ID, an 0-DU ID,an O-CU ID, a cell ID list that includes a plurality of cell IDs, a gNB ID list that includes a plurality of gNB IDs, an 0-RU ID list that includes a plurality of 0-RU IDs, an 0-DU ID list that includes a plurality of 0-DU IDs, an O-CU ID list comprises a plurality of O-CU IDs, a slice ID list that includes a plurality of slice IDs, and a network ID list that includes a plurality of network IDs.

[0126] Furthermore, the at least one policy objective may include one or more of: an energy-saving objective, an energy efficiency objective, a RAN energy consumption objective, a gNB energy consumption objective, a network service energy consumption objective, a network function energy consumption objective, and a QoS objective.

[0127] Additionally, the at least one policy resource may include one or more of: a condition list, an inclusion list and an exclusion list. The condition list may include one or more of: a network condition and a timing condition. The inclusion list may include information of one or more nodes to which one or more energy-saving operations can be applicable. The exclusion list may include information of one or more nodes that should be excluded from the one or more energy-saving operations

[0128] Further details and example contents of the energy-saving policy(s) have been described above with reference to Tables 12-20. Thus, redundant descriptions associated therewith may be omitted below for conciseness.

[0129] Upon generating the at least one energy-saving policy, the method 400 may proceed to operation S430, at which the Non-RT RIC may be configured to provide the at least one energysaving policy to the Near-RT RIC via the Al interface. Accordingly, the Near-RT RIC may be configured to execute the at least one energy-saving policy to perform one or more energy-saving operations (e.g., cell switch On / Off, handover of users to another cell, etc.)

[0130] In view of the above, example embodiments of the present disclosure effectively and efficiently facilitate the provisioning of one or more energy-saving policies with the Non-RT RIC, thereby optimizing the energy efficiency and energy-saving opportunities in the 0-RAN system.Examples of System Hardware Components

[0131] One or more components of the system of the example embodiments (e.g., Non-RT RIC, Near-RT RIC, etc.), as well as the operations associated therewith (e.g., one or more operations in FIG. 4, one or more energy-saving operations, etc.), may be implemented in one or more systems, devices, or hardware components, such as one or more servers, and the like. In the following, descriptions of a device in which the systems or components of the example embodiments may be implemented are provided. It is contemplated that one or more operations or methods described above with reference to FIG. 1 to FIG. 4 may be performed by the device. For instance, the one or more operations or methods may be performed by at least one processor of the device upon executing machine-readable instructions or computer-readable instructions (e.g., instructions for implementing the Non-RT RIC, etc.) stored in a memory or a storage component of the device.

[0132] FIG. 5 illustrates an embodiment of a device 500. As shown in FIG. 5, the device 500 may include a processor 510, a memory 520, a storage component 530, an input component 540, an output component 550, a communication interface 560, and a bus 570.

[0133] The processor 510, as used herein, means any type of computational circuit that may comprise hardware elements and software elements. The processor 510 may be embodied as a multi-core processor, a single core processor, or a combination of one or more multi-core processors and / or one or more single core processors, a distributed processing system, or the like.The processor 510 may be a Central Processing Unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), an application-specific integrated circuit (ASIC), or another type of processing component.

[0134] Memory 520 includes a non-transitory computer readable medium. Memory 520 includes a random-access memory (RAM), a read only memory (ROM), and / or another type of dynamic or static storage device (e.g., a flash memory, a magnetic memory, and / or an optical memory) that stores information and / or instructions for use by processor 510. The memory 520 comprises machine-readable instructions which are executable by the processor 510. These machine-readable instructions when executed by the processor 510 cause the processor 510 to perform one or more method steps of an embodiment described above.

[0135] Storage component 530 stores information and / or software related to the operation and use of the device 500. For example, storage component 530 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, and / or a solid-state disk), a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a cartridge, a magnetic tape, and / or another type of non-transitory computer-readable medium, along with a corresponding drive.

[0136] Input component 540 is configured to receive information, such as user input. For example, the input component 540 may include, but not be limited to, a touch screen display, a keyboard, a keypad, a mouse, a button, a switch, and / or a microphone. Additionally, or alternatively, the input component 540 may include a sensor for sensing information (e.g., a global positioning system (GPS), an accelerometer, a gyroscope, and / or an actuator).

[0137] Output component 550 is configured to provide output information from the device500. For example, the output component 550 may be, but not limited to, a display, a speaker, instructions to an external device, and / or one or more light-emitting diodes (LEDs).

[0138] Communication interface 560 is an interface that provides a communication connection to other devices, such as external devices and internal devices. The connection by the communication interface 560 can be a wired connection, a wireless connection, or a combination of wired and wireless connections, and can be a direct connection or an indirect connection via a communication network that exists between the device 500 and other devices. In other words, the standard of the communication interface 560 is not limited.

[0139] The bus 570 acts as an interconnect between the processor 510, the memory 520, the storage component 530, the input component 540, the output component 550, and the communication interface 560 of the device 500. The bus 570 may include a wired interconnection or a wireless interconnection.

[0140] The number and arrangement of components shown in FIG. 5 are provided as an example. In practice, device 500 may include additional components, fewer components, different components, or differently arranged components than those shown in FIG. 5. Additionally, or alternatively, a set of components (e.g., one or more components) of device 500 may perform one or more functions described as being performed by another set of components of device 500. Further, one or more method steps described in any of the embodiments may be performed utilizing a plurality of devices 500 in communication with one another.Various Aspects of Embodiments

[0141] It is contemplated that the example embodiments described hereinabove with reference to FIG. 1 to FIG. 5 are merely examples of possible embodiments of the present disclosure, and are not intended to limit or restrict the scope of the present disclosure.

[0142] Specifically, the foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the implementations to the precise form disclosed.Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the implementations.

[0143] Some embodiments may relate to a device (e.g., node, etc.), a system, a method, and / or a computer-readable medium at any possible technical detail level of integration. Further, one or more of the above components described above may be implemented as instructions stored on a computer-readable medium and executable by at least one processor (and / or may include at least one processor). The computer-readable medium may include a computer-readable non- transitory storage medium (or media) having computer-readable program instructions thereon for causing a processor to carry out operations.

[0144] The computer-readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer-readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer-readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), electrically erasable programmable read-only memory (EEPROM), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer-readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic wavespropagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

[0145] Computer-readable program instructions described herein can be downloaded to respective computing / processing devices from a computer-readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and / or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium within the respective computing / processing device.

[0146] Computer-readable program code / instructions for carrying out operations may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuitry, or either source code or object code written in any combination of one or more programming languages, including an object-oriented programming language such as Smalltalk, C++, or the like, and procedural programming languages, such as the "C" programming language or similar programming languages.

[0147] The computer-readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connectionmay be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer-readable program instructions by utilizing state information of the computer- readable program instructions to personalize the electronic circuitry, in order to perform aspects or operations.

[0148] These computer-readable program instructions may be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks. These computer- readable program instructions may also be stored in a computer-readable storage medium that can direct a computer, a programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer-readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function / act specified in the flowchart and / or block diagram block or blocks.

[0149] The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer-implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0150] The flowchart and block diagrams in the Figures illustrate the architecture,functionality, and operation of possible implementations of systems, methods, and computer- readable media according to various embodiments. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). The method, computer system, and computer-readable medium may include additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted in the Figures. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed concurrently or substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and / or flowchart illustration, and combinations of blocks in the block diagrams and / or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.

[0151] It will be apparent that systems and / or methods, described herein, may be implemented in different forms of hardware, firmware, or a combination of hardware and software. The actual specialized control hardware or software code used to implement these systems and / or methods is not limited to the implementations. Thus, the operation and behavior of the systems and / or methods were described herein without reference to specific software code — it is understood that software and hardware may be designed to implement the systems and / or methods based on the description herein.

[0152] In view of the above, various further respective aspects and features of embodiments of the present disclosure may be defined by the following items:Item [1]: A system including: a non-real-time (Non-RT) radio access network intelligent controller (RIC) configured to: obtain a policy schema; generate, based on the policy schema, at least one energy-saving policy for execution by a near-real-time (Near- RT) RIC, wherein the at least one energy-saving policy may include at least one policy scope identifier specifying at least one node to which the energy-saving policy is applied, at least one policy objective specifying an energy-saving target, and at least one policy resource specifying a condition for resource usage for the energy-saving policy; and provide, to the Near-RT RIC via an Al interface, the at least one energy-saving policy.Item [2]: The system according to item [1], wherein the at least one energy-saving policy may include at least one of: an energy threshold-based energy-saving policy, a service assurance threshold-based energy-saving policy, a network condition-based energy-saving policy, and a timing condition-based energy-saving policy.Item [3]: The system according to item [2], wherein the at least one policy objective of the energy threshold-based energy-saving policy may include an energy parameter that defines a threshold for initiating the execution of one or more energy-saving operations, wherein the at least one policy objective of the service assurance threshold-based energysaving policy may include a quality of service (QoS) objective that defined a threshold for initiating the execution of the one or more energy-saving operations, wherein the at least one policy resource of the network condition-based energy-saving policy may include a network condition for initiating the execution of the one or more energy-saving operations, and wherein the at least one policy resource of the timing condition-based energy-saving policy may include a timing for initiating the execution of the one or more energy-saving operation.Item [4]: The system according to any one of items [l]-[3], wherein the at least one policy scope identifier may include one or more of: a cell identifier (ID), a slice ID, a network ID, a gNodeB (gNB) ID, an open radio access network (O-RAN) radio unit ORU) ID, an O-RAN distributed unit (O-DU) ID, an O-RAN central unit (O-CU) ID, a cell ID list that may include a plurality of cell IDs, a gNB ID list that may include a plurality of gNB IDs, an O-RU ID list that may include a plurality of O-RU IDs, an O-DU ID list that may include a plurality of O-DU IDs, an O-CU ID list that may include a plurality of O-CU IDs, a slice ID list that may include a plurality of slice IDs, and a network ID list that may include a plurality of network IDs.Item [5]: The system according to any one of items [l]-[4], wherein the at least one policy objective may include one or more of: an energy-saving objective, an energy efficiency objective, a RAN energy consumption objective, a gNB energy consumption objective, a network service energy consumption objective, a network function energy consumption objective, and a QoS objective.Item [6]: The system according to any one of items [l]-[5], wherein the at least one policy resource may include one or more of: a condition list, an inclusion list and an exclusion list, wherein the condition list may include one or more of: a network condition and a timing condition, wherein the inclusion list may include information of one or more nodes to which one or more energy-saving operations can be applicable, and wherein the exclusion list may include information of one or more nodes that should be excluded from the one or more energy-saving operations.Item [7]: The system according to any one of items [l]-[6], wherein the policy schema may include a JavaScript Object Notation (JSON) schema.Item [8]: A method comprising: obtaining a policy schema; generating, based on the policy schema, at least one energy-saving policy for execution by a near-real-time (Near-RT) radio access network intelligent controller (RIC), wherein the at least one energy-saving policy may include at least one policy scope identifier specifying at least one node to which the energy-saving policy is applied, at least one policy objective specifying an energy-saving target, and at least one policy resource specifying a condition for resource usage for the energy-saving policy; and providing, to the Near-RT RIC via an Al interface, the at least one energy-saving policy.Item [9]: The method according to item [8], wherein the at least one energy-saving policy may include at least one of: an energy threshold-based energy-saving policy, a service assurance threshold-based energy-saving policy, a network condition-based energy-saving policy, and a timing condition-based energy-saving policy.Item

[0010] : The method according to item [9], wherein the at least one policy objective of the energy threshold-based energy-saving policy may include an energy parameter that defines a threshold for initiating the execution of one or more energy-saving operations, wherein the at least one policy objective of the service assurance thresholdbased energy-saving policy may include a quality of service (QoS) objective that defined a threshold for initiating the execution of the one or more energy-saving operations, wherein the at least one policy resource of the network condition-based energy-saving policy may include a network condition for initiating the execution of the one or more energy-saving operations, and wherein the at least one policy resource of the timing condition-based energy-saving policy may include a timing for initiating the execution of the one or more energy-saving operation.Item

[0011] : The method according to any one of items [8]-[l 0], wherein the at least one policy scope identifier may include one or more of a cell identifier (ID), a slice ID, a network ID, a gNodeB (gNB) ID, an open radio access network (O-RAN) radio unit ORU) ID, an O-RAN distributed unit (O-DU) ID, an O-RAN central unit (O-CU) ID, a cell ID list that may include a plurality of cell IDs, a gNB ID list that may include a plurality of gNB IDs, an O-RU ID list that may include a plurality of O-RU IDs, an O-DU ID list that may include a plurality of O-DU IDs, an O-CU ID list that may include a plurality of O-CU IDs, a slice ID list that may include a plurality of slice IDs, and a network ID list that may include a plurality of network IDs.Item

[0012] : The method according to any one of items [8]-[l 1], wherein the at least one policy objective may include one or more of: an energy-saving objective, an energy efficiency objective, a RAN energy consumption objective, a gNB energy consumption objective, a network service energy consumption objective, a network function energy consumption objective, and a QoS objective.Item

[0013] : The method according to any one of items [8]-

[0012] , wherein the at least one policy resource may include one or more of: a condition list, an inclusion list and an exclusion list, wherein the condition list may include one or more of: a network condition and a timing condition, wherein the inclusion list may include information of one or more nodes to which one or more energy-saving operations can be applicable, and wherein the exclusion list may include information of one or more nodes that should be excluded from the one or more energy-saving operations.Item

[0014] : The method according to any one of items [8]-

[0013] , wherein the policy schema may include a JavaScript Object Notation (JSON) schema.Item

[0015] : A non-transitory computer-readable recording medium having recorded thereon instructions executable by a system that includes a non-real-time (Non-RT) radio access network intelligent controller (RIC) to cause the Non-RT RIC to perform a method comprising: obtaining a policy schema; generating, based on the policy schema, at least one energy-saving policy for execution by a near-real-time (Near-RT) RIC, wherein the at least one energy-saving policy may include at least one policy scope identifier specifying at least one node to which the energy-saving policy is applied, at least one policy objective specifying an energy-saving target, and at least one policy resource specifying a condition for resource usage for the energy-saving policy; and providing, to the Near-RT RIC via an Al interface, the at least one energy-saving policyItem

[0016] : The non-transitory computer-readable recording medium according to item

[0015] , wherein the at least one of: an energy threshold-based energy-saving policy, a service assurance threshold-based energy-saving policy, a network condition-based energy-saving policy, and a timing condition-based energy-saving policy.Item

[0017] : The non-transitory computer-readable recording medium according to item

[0016] , wherein the at least one policy objective of the energy threshold-based energysaving policy may include an energy parameter that defines a threshold for initiating the execution of one or more energy-saving operations, wherein the at least one policy objective of the service assurance threshold-based energy-saving policy may include a quality of service (QoS) objective that defined a threshold for initiating the execution of the one or more energy-saving operations, wherein the at least one policy resource of the network condition-based energy-saving policy may include a network condition for initiating the execution of the one or more energy-saving operations, and wherein the atleast one policy resource of the timing condition-based energy-saving policy may include a timing for initiating the execution of the one or more energy-saving operation.Item

[0018] : The non-transitory computer-readable recording medium according to any one of items

[0015] -

[0017] , wherein the at least one policy scope identifier may include one or more of: a cell identifier (ID), a slice ID, a network ID, a gNodeB (gNB) ID, an open radio access network (O-RAN) radio unit (O-RU) ID, an O-RAN distributed unit (O-DU) ID, an O-RAN central unit (O-CU) ID, a cell ID list that may include a plurality of cell IDs, a gNB ID list that may include a plurality of gNB IDs, an O-RU ID list that may include a plurality of O-RU IDs, an O-DU ID list that may include a plurality of O-DU IDs, an O- CU ID list that may include a plurality of O-CU IDs, a slice ID list that may include a plurality of slice IDs, and a network ID list that may include a plurality of network IDs.Item

[0019] : The non-transitory computer-readable recording medium according to any one of items

[0015] -

[0018] , wherein the at least one policy objective may include one or more of: an energy-saving objective, an energy efficiency objective, a RAN energy consumption objective, a gNB energy consumption objective, a network service energy consumption objective, a network function energy consumption objective, and a QoS objective.Item

[0020] : The non-transitory computer-readable recording medium according to any one of items

[0015] -

[0019] , wherein the at least one policy resource may include one or more of: a condition list, an inclusion list and an exclusion list, wherein the condition list may include one or more of: a network condition and a timing condition, wherein the inclusion list may include information of one or more nodes to which one or more energysaving operations can be applicable, and wherein the exclusion list may includeinformation of one or more nodes that should be excluded from the one or more energysaving operations.

[0153] It can be understood that numerous modifications and variations of the present disclosure are possible in light of the above teachings. It will be apparent that within the scope of the appended clauses, the present disclosures may be practiced otherwise than as specifically described herein.

Claims

What is claimed is:

1. A system comprising: a non-real-time (Non-RT) radio access network intelligent controller (RIC) configured to: obtain a policy schema; generate, based on the policy schema, at least one energy-saving policy for execution by a near-real-time (Near-RT) RIC, wherein the at least one energysaving policy comprises at least one policy scope identifier specifying at least one node to which the energy-saving policy is applied, at least one policy objective specifying an energy-saving target, and at least one policy resource specifying a condition for resource usage for the energy-saving policy; and provide, to the Near-RT RIC via an Al interface, the at least one energysaving policy.

2. The system according to claim 1, wherein the at least one energy-saving policy comprises at least one of: an energy threshold-based energy-saving policy, a service assurance threshold-based energy-saving policy, a network condition-based energy-saving policy, and a timing condition-based energy-saving policy.

3. The system according to claim 2, wherein the at least one policy objective of the energy threshold-based energysaving policy comprises an energy parameter that defines a threshold for initiating the execution of one or more energy-saving operations,wherein the at least one policy objective of the service assurance threshold-based energy-saving policy comprises a quality of service (QoS) objective that defined a threshold for initiating the execution of the one or more energy-saving operations, wherein the at least one policy resource of the network condition-based energysaving policy comprises a network condition for initiating the execution of the one or more energy-saving operations, and wherein the at least one policy resource of the timing condition-based energysaving policy comprises a timing for initiating the execution of the one or more energysaving operation.

4. The system according to claim 1, wherein the at least one policy scope identifier comprises one or more of: a cell identifier (ID), a slice ID, a network ID, a gNodeB (gNB) ID, an open radio access network (O-RAN) radio unit (O-RU) ID, an O-RAN distributed unit (O- DU) ID, an O-RAN central unit (O-CU) ID, a cell ID list comprises a plurality of cell IDs, a gNB ID list comprises a plurality of gNB IDs, an O-RU ID list comprises a plurality of O-RU IDs, an O-DU ID list comprises a plurality of O-DU IDs, an O-CU ID list comprises a plurality of O-CU IDs, a slice ID list comprises a plurality of slice IDs, and a network ID list comprises a plurality of network IDs.

5. The system according to claim 1, wherein the at least one policy objective comprises one or more of an energy-saving objective, an energy efficiency objective, a RAN energy consumption objective, a gNB energy consumption objective, a network service energyconsumption objective, a network function energy consumption objective, and a QoS objective.

6. The system according to claim 1, wherein the at least one policy resource comprises one or more of: a condition list, an inclusion list and an exclusion list, wherein the condition list comprises one or more of: a network condition and a timing condition, wherein the inclusion list comprises information of one or more nodes to which one or more energy-saving operations can be applicable, and wherein the exclusion list comprises information of one or more nodes that should be excluded from the one or more energy-saving operations.

7. The system according to claim 1, wherein the policy schema comprises a JavaScript Object Notation (JSON) schema.

8. A method comprising: obtaining a policy schema; generating, based on the policy schema, at least one energy-saving policy for execution by a near-real-time (Near-RT) radio access network intelligent controller (RIC), wherein the at least one energy-saving policy comprises at least one policy scope identifier specifying at least one node to which the energy-saving policy is applied, at least one policyobjective specifying an energy-saving target, and at least one policy resource specifying a condition for resource usage for the energy-saving policy; and providing, to the Near-RT RIC via an Al interface, the at least one energy-saving policy.

9. The method according to claim 8, wherein the at least one energy-saving policy comprises at least one of: an energy threshold-based energy-saving policy, a service assurance threshold-based energy-saving policy, a network condition-based energy-saving policy, and a timing condition-based energy-saving policy.

10. The method according to claim 9, wherein the at least one policy objective of the energy threshold-based energysaving policy comprises an energy parameter that defines a threshold for initiating the execution of one or more energy-saving operations, wherein the at least one policy objective of the service assurance threshold-based energy-saving policy comprises a quality of service (QoS) objective that defined a threshold for initiating the execution of the one or more energy-saving operations, wherein the at least one policy resource of the network condition-based energysaving policy comprises a network condition for initiating the execution of the one or more energy-saving operations, and wherein the at least one policy resource of the timing condition-based energysaving policy comprises a timing for initiating the execution of the one or more energysaving operation.

11. The method according to claim 8, wherein the at least one policy scope identifier comprises one or more of: a cell identifier (ID), a slice ID, a network ID, a gNodeB (gNB) ID, an open radio access network (O-RAN) radio unit (O-RU) ID, an O-RAN distributed unit (O- DU) ID, an O-RAN central unit (O-CU) ID, a cell ID list comprises a plurality of cell IDs, a gNB ID list comprises a plurality of gNB IDs, an O-RU ID list comprises a plurality of O-RU IDs, an O-DU ID list comprises a plurality of O-DU IDs, an O-CU ID list comprises a plurality of O-CU IDs, a slice ID list comprises a plurality of slice IDs, and a network ID list comprises a plurality of network IDs.

12. The method according to claim 8, wherein the at least one policy objective comprises one or more of: an energy-saving objective, an energy efficiency objective, a RAN energy consumption objective, a gNB energy consumption objective, a network service energy consumption objective, a network function energy consumption objective, and a QoS objective.

13. The method according to claim 8, wherein the at least one policy resource comprises one or more of: a condition list, an inclusion list and an exclusion list, wherein the condition list comprises one or more of: a network condition and a timing condition, wherein the inclusion list comprises information of one or more nodes to which one or more energy-saving operations can be applicable, andwherein the exclusion list comprises information of one or more nodes that should be excluded from the one or more energy-saving operations.

14. The method according to claim 8, wherein the policy schema comprises a JavaScript Object Notation (JSON) schema.

15. A non-transitory computer-readable recording medium having recorded thereon instructions executable by a system that comprises a non-real-time (Non-RT) radio access network intelligent controller (RIC) to cause the Non-RT RIC to perform a method comprising: obtaining a policy schema; generating, based on the policy schema, at least one energy-saving policy for execution by a near-real-time (Near-RT) RIC, wherein the at least one energy-saving policy comprises at least one policy scope identifier specifying at least one node to which the energy-saving policy is applied, at least one policy objective specifying an energy-saving target, and at least one policy resource specifying a condition for resource usage for the energy-saving policy; and providing, to the Near-RT RIC via an Al interface, the at least one energy-saving policy.

16. The non-transitory computer-readable recording medium according to claim 15, wherein the at least one energy-saving policy comprises at least one of: an energy threshold-basedenergy-saving policy, a service assurance threshold-based energy-saving policy, a network condition-based energy-saving policy, and a timing condition-based energy-saving policy.

17. The non-transitory computer-readable recording medium according to claim 16, wherein the at least one policy objective of the energy threshold-based energysaving policy comprises an energy parameter that defines a threshold for initiating the execution of one or more energy-saving operations, wherein the at least one policy objective of the service assurance threshold-based energy-saving policy comprises a quality of service (QoS) objective that defined a threshold for initiating the execution of the one or more energy-saving operations, wherein the at least one policy resource of the network condition-based energysaving policy comprises a network condition for initiating the execution of the one or more energy-saving operations, and wherein the at least one policy resource of the timing condition-based energysaving policy comprises a timing for initiating the execution of the one or more energysaving operation.

18. The non-transitory computer-readable recording medium according to claim 15, wherein the at least one policy scope identifier comprises one or more of: a cell identifier (ID), a slice ID, a network ID, a gNodeB (gNB) ID, an open radio access network (O-RAN) radio unit (O-RU) ID, an O-RAN distributed unit (O-DU) ID, an O-RAN central unit (O-CU) ID, a cell ID list comprises a plurality of cell IDs, a gNB ID list comprises a plurality of gNB IDs, an O-RU ID list comprises a plurality of O-RU IDs, an O-DU ID list comprisesa plurality of O-DU IDs, an O-CU ID list comprises a plurality of O-CU IDs, a slice ID list comprises a plurality of slice IDs, and a network ID list comprises a plurality of network IDs.

19. The non-transitory computer-readable recording medium according to claim 15, wherein the at least one policy objective comprises one or more of: an energy-saving objective, an energy efficiency objective, a RAN energy consumption objective, a gNB energy consumption objective, a network service energy consumption objective, a network function energy consumption objective, and a QoS objective.

20. The non-transitory computer-readable recording medium according to claim 15, wherein the at least one policy resource comprises one or more of: a condition list, an inclusion list and an exclusion list, wherein the condition list comprises one or more of: a network condition and a timing condition, wherein the inclusion list comprises information of one or more nodes to which one or more energy-saving operations can be applicable, and wherein the exclusion list comprises information of one or more nodes that should be excluded from the one or more energy-saving operations.

Images