Pre-configuration of O-RAN energy saving policies

Abstract

Example embodiments of the present disclosure relate to pre-configuration of one or more O-RAN energy saving policies. According to an example embodiment, a system may include a non-real-time (non-RT) radio access network intelligent controller (RIC). The non-RT RIC may be configured to acquire a policy pattern, and then generate, based on the policy pattern, at least one energy saving policy for execution by a near real-time (near RT) RIC. The at least one energy saving policy may include a policy range identifier to specify a network node to which the energy saving policy is applied; the strategy target is used for specifying an energy-saving target; and a policy resource for specifying a resource usage condition of the energy saving policy. Thus, the non-RT RIC may be configured to provide the at least one power saving policy to the near RT RIC via the A1 interface.

Description

Cross Reference to Related Applications

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

[0002] The present disclosure relates to pre-configuration of one or more energy saving strategies for Open Radio Access Network (O-RAN). BACKGROUND

[0003] The information disclosed in this Background section is for the purpose of enhancing the understanding of the general context of the present disclosure and it may not be taken as an acknowledgement or any form of suggestion that this information forms prior art of this disclosure or any form of admission.

[0004] A Radio Access Network (RAN) is an important component of a telecommunication system as it connects end user devices (or user equipment) to other parts of the network. A RAN includes a combination of various network elements (NEs) that connect end users to a core network. Traditionally, the hardware and / or software of a particular RAN is provider specific.

[0005] The advent of Open Radio Access Network (O-RAN) technology has enabled multiple providers to provide hardware and / or software to a telecommunication system. Due to the involvement of different providers, the type of hardware and / or software provided can also vary. That is, different types of NEs can be provided by different providers and depending on the specific service, the NEs can be virtualized in software form (e.g., based on virtual machines (VMs) or the like) or can exist in physical hardware form (e.g., based on non-VMs or the like). Thus, O-RAN breaks down RAN functionality into different entities such as Central Unit (CU), Distributed Unit (DU), and Radio Unit (RU). Since these entities have open protocols and interfaces between them, they can be developed by different providers. SUMMARY

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

[0007] According to an example embodiment, a system can include a non-real-time (non-RT) radio access network intelligent controller (RIC). The non-RT RIC can be configured to obtain a policy pattern, and then generate, based on the policy pattern, at least one energy saving policy to be executed by a near-real-time (near-RT) RIC. The at least one energy saving policy can include at least one policy scope identifier to specify at least one node to which the energy saving policy is applied, at least one policy target to specify an energy saving target, and at least one policy resource to specify a condition for resource usage of the energy saving policy. Accordingly, the non-RT RIC can be configured to provide the at least one energy saving policy to the near-RT RIC via an A1 interface.

[0008] According to an example embodiment, a method can include obtaining a policy pattern, generating, based on the policy pattern, at least one energy saving policy to be executed 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 A1 interface. The at least one energy saving policy can include at least one policy scope identifier to specify at least one node to which the energy saving policy is applied, at least one policy target to specify an energy saving target, and at least one policy resource to specify a condition for resource usage of the energy saving policy.

[0009] According to an example embodiment, a non-transitory computer-readable recording medium can record thereon instructions executable by a system including a non-real-time (non-RT) radio access network intelligent controller (RIC) to cause the non-RT RIC to perform a method. The method can include obtaining a policy pattern, generating, based on the policy pattern, at least one energy saving policy to be executed by a near-real-time (near-RT) RIC, and providing the at least one energy saving policy to the near-RT RIC via an A1 interface. The at least one energy saving policy can include at least one policy scope identifier to specify at least one node to which the energy saving policy is applied, at least one policy target to specify an energy saving target, and at least one policy resource to specify a condition for resource usage of the energy saving policy.

[0010] Other aspects will be apparent on review of the following description. BRIEF DESCRIPTION OF DRAWINGS

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

[0012] Figure 1 illustrates an O-RAN architecture in which one or more example embodiments can be applied;

[0013] Figure 2a block diagram illustrating example energy saving policies in accordance with one or more example embodiments;

[0014] Figure 3 a block diagram illustrating various types of energy saving policies in accordance with one or more example embodiments;

[0015] Figure 4 a flow diagram illustrating an example method for preconfiguring one or more energy saving policies in accordance with one or more example embodiments; and

[0016] Figure 5 an example component diagram 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 above disclosure provides an illustration and description of, 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 by practicing the implementations. Additionally, one or more features or components from an embodiment can be incorporated into or combined with another embodiment (or one or more features of another embodiment). Further, the flow diagrams and descriptions of operations provided below relate to one of the various embodiments. It is noted that other embodiments can be made that do not match the flow diagrams exactly. It will be appreciated that in other embodiments, one or more of the operations can be omitted, one or more additional operations can be added, or one or more operations can be performed simultaneously (at least in part).

[0018] It will be obvious, that the systems and / or methods described herein can be implemented in different hardware, firmware, or software combinations. The actual specialized control hardware or software code used to implement these systems and / or methods is not limiting of the implementations. Thus, the operation and behavior of the systems and / or methods were described herein without reference to specific software code — it being understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.

[0019] While certain combinations of features are disclosed in the claims and / or specification, other combinations of the features are also possible. Dependent claims refer to those dependencies that are technically possible but not necessarily implied by the specification. Although each dependent claim may only directly depend from one claim, the disclosure of the implementations includes each dependent claim in combination with all other claims in the 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, “a” and “one” are intended to include one or more items, and can be used interchangeably with “one or more.” Furthermore, as used herein, the terms “has,” “have,” “including,” “contains,” “containing,” 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. Also, as used herein, expressions such as “at least one of A and B” or “at least one of A or B” or “at least one of A and / or B” are to be understood as including only A, only B, or both A and B.

[0021] It should be noted that the description of example embodiments of the present disclosure can include terminology and names defined in one or more standard organizations, such as the Third Generation Partnership Project (3GPP) standard organization, the European Telecommunications Standards Institute (ETSI) standard organization, the Open Radio Access Network (O-RAN) Alliance standard organization, and the like. For example, the terms “rApp,” “xApp,” “A1 interface,” “A1 policy,” “E2 interface,” “01 interface,” “02 interface,” and the like, and their associated features and operations, should be interpreted to be consistent with what is specified in one or more technical specifications, unless otherwise stated.

[0022] As the telecommunication network technology evolves, the RAN can be decomposed into multiple nodes or entities. Specifically, in the O-RAN architecture, the RAN functions can be decomposed into multiple logical nodes or entities, such as a Central Unit (CU), a Distributed Unit (DU), and a Radio Unit (RU). The CU can be a logical node for hosting the Radio Resource Control (RRC), the Service Data Adaptation Protocol (SDAP), and / or the Packet Data Convergence Protocol (PDCP) sub-layers of the RAN. The DU can be a logical node for hosting the Radio Link Control (RLC), the Medium Access Control (MAC), and the Physical (PHY) sub-layers of the RAN. A single DU can host or serve multiple network cells formed by multiple RUs. The RU can be a physical node that converts the radio signals from the antennas into digital signals that can be transmitted to the DU over a fronthaul link. In this regard, a network cell can correspond to one or more radio units that are responsible for providing wireless coverage and signal transmission within the network cell. To this end, since these decomposed entities have open protocols and interfaces among them, they can be developed by different providers.

[0023] On the other hand, network energy saving is an important aspect of O-RAN, aiming to optimize energy efficiency, reduce operational 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 on / off energy saving has been introduced. However, the specific content of the involved policies and the specific mechanism for preconfiguring such policies are not specified or defined in the prior art. In this regard, since entities from different providers can be involved in the O-RAN architecture, it is crucial to define and specify energy saving policies in a standardized manner so that entities from different providers can understand these policies and perform energy saving operations accordingly.

[0024] Example embodiments of the present disclosure provide a system, method, device, and the like that facilitate preconfiguration of one or more energy saving policies in a standardized manner. Specifically, example embodiments of the present disclosure introduce an energy saving policy pattern and utilize a non-real-time (non-RT) Radio Access Network Intelligent Controller (RIC) to generate various types of energy saving policies based on the energy saving policy pattern. Each type 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 can be anticipated that example embodiments of the present disclosure can also be implemented by any suitable module or entity without departing from the scope of the present disclosure. For example, although it is described herein that a non-RT RIC can utilize a policy pattern to generate one or more energy saving policies and provide the same to a near-RT RIC, it can be appreciated that any other suitable module or entity in any suitable system (e.g., an O-RAN system, a 3GPP system, a 5G system, a 6G system, and the like) can utilize the policy pattern to generate or create one or more energy saving policies, which can be provided to or transmitted to other suitable modules or entities in any suitable system for utilization, and the like.

[0026] Furthermore, it can be anticipated that the features, advantages, and significance of the above-described example embodiments are only a part of the present disclosure, and are not intended to exhaust or limit the scope of the present disclosure. Further descriptions of the features, components, configurations, operations, and implementations of example embodiments of the present disclosure will be provided below. Example System Architecture

[0027] Figure 1 FIG. 1 illustrates an O-RAN architecture in which one or more example embodiments can be applied. As shown in FIG. 1, the O-RAN architecture includes a near-RT RIC 102, a non-RT RIC 104, a base station 106, and a user equipment (UE) 108. The near-RT RIC 102 can be configured to perform near-RT operations, such as radio resource management (RRM), radio access network (RAN) optimization, and the like. The non-RT RIC 104 can be configured to perform non-RT operations, such as network energy saving, network slicing, and the like. The base station 106 can be configured to perform operations related to the near-RT RIC 102 and the non-RT RIC 104, such as radio resource management (RRM), radio access network (RAN) optimization, network energy saving, network slicing, and the like. The UE 108 can be configured to perform operations related to the near-RT RIC 102 and the non-RT RIC 104, such as radio resource management (RRM), radio access network (RAN) optimization, network energy saving, network slicing, and the like. Figure 1As shown in FIG. 1, the system architecture can 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-RT RIC (near-RT RIC) 130, at least one O-RAN central unit (O-CU) 140, at least one 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 can be communicatively coupled with other components via respective interface(s) for communication.

[0028] It is contemplated that the system can include more / less components than shown in the figure, and / or can be configured in different ways, without departing from the scope of the present disclosure. For example, in some example implementations, the system architecture can include a plurality of O-DUs 160, each of which is communicatively coupled with the O-CU 140, and so on.

[0029] Generally, the RIC can be a software-defined component that implements modular applications to facilitate multi-vendor operations, as well as automating and optimizing RAN operations. As Figure 1 As shown in FIG. 1, the RIC can be divided into two types, namely, the non-RT RIC 120 and the near-RT RIC 130. The following provides a description of the non-RT RIC 120 first, followed by a description of the near-RT RIC 130.

[0030] The non-RT RIC 120 can refer to a logical function within the SMO framework 110 that drives the content carried over the Al interface, thereby enabling non-real-time control and optimization of RAN elements and resources. The Al interface can refer to a logical interface between the non-RT RIC 120 and the near-RT RIC 130 that 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 feedbacks 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 can operate at a time scale greater than 1 second as a control point for a non-real-time control loop and within the SMO framework 110. Generally, the functionality of the non-RT RIC 120 can include, for example, providing policy-based guidance and enhancements over the Al interface, performing data analytics, artificial intelligence / machine learning (AI / ML) model training and inference for RAN optimization, and / or recommending configuration management actions. In addition, as further described below, the non-RT RIC 120 can also be configured to generate one or more energy saving policies and provide to the near-RT RIC 130. Further, the non-RT RIC 120 can access or communicate with other SMO framework functionalities or components via the Al interface, the Ol interface, the 02 interface, and one or more interfaces associated with one or more open front-haul planes.

[0032] According to example embodiments, the functionality of the non-RT RIC 120 can be implemented by at least one modular non-RT RIC application, such as a rApp 121. The rApp 121 can leverage the functionality 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 enhanced information. In some example implementations, the non-RT RIC 120 can implement multiple rApps 121.

[0033] According to example embodiments, the non-RT RIC 120 (or the rApp 121 associated therewith) can be configured to generate one or more policies via the Al interface and provide them to the near-RT RIC 130, and can be configured to manage the one or more policies provided to the near-RT RIC 130 via the Al interface. The policies can be referred to herein as “Al policies,” 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 described further below, the one or more Al policies can consist of a scope identifier and one or more policy statements. The scope identifier can specify or define the node(s) or entity(ies) (e.g., cell, UE, DU, etc.) to which the policy is applied. The policy statement(s) can define the subject, purpose, or goal of the policy, and can include information associated with one or more policy goals and one or more policy resources. According to example embodiments, at least a portion of the Al policies are associated with energy saving operations (the policies can be referred to herein as “energy saving policies”). The non-RT RIC 120 (or the rApp 121 associated therewith) can create and provide 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 to achieve one or more goals or purposes defined in a RAN intent. The RAN intent can refer to high-level operational or business purpose(s) that the RAN is to achieve, which can be defined by one or more desired service level agreements (SLAs) that the RAN needs to satisfy for all users or a subset of users in a given area for at least a pre-defined period of time.

[0034] According to example embodiments, the non-RT RIC 120 (or the rApp 121 associated therewith) can 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.). In particular, the non-RT RIC 120 (or the rApp 121 associated therewith) can 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) can manage one or more Al policies to include information associated with energy saving (examples of the information are described further 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) can be configured to receive, from the near-RT RIC 130 via the Al interface, one or more feedbacks associated with one or more Al policies (herein “Al policy feedbacks”). Similarly, the non-RT RIC 120 (or the rApp 121 associated therewith) can be configured to receive, over the Ol interface, 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 the one or more O-RUs 170. Accordingly, the non-RT RIC 120 (or the rApp 121 associated therewith) can be configured to continuously (or periodically) manage the one or more Al policies based on the Al policy feedbacks and / or the observables provided over the Ol interface. For example, the non-RT RIC 120 (or the rApp 121 associated therewith) can continuously (or periodically) evaluate the impact or effectiveness of the one or more Al policies on achieving the RAN intent, and then configure or update the one or more Al policies accordingly.

[0036] In addition to communicating with the near-RT RIC 130 via the Al interface, the SMO framework 110 (and the non-RT RIC 120 and / or the rApp 121 implemented therein) can also 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 Ol interface. In this regard, the Ol interface can 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 that enables the SMO framework 110 (and 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 so forth, to the near-RT RIC 130, the O-CU 140, the O-eNB 150, the O-DU 160, and the O-RU(s) 170. Moreover, the Ol interface also 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 can be leveraged by the non-RT RIC 120 (or the rApp 121 associated therewith) for managing the one or more Al policies, training the one or more AI / ML models, and so forth.

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

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

[0039] Next, a description of the near-RT RIC 130 will be provided. The near-RT RIC 130 can refer to a logical function that implements near-real-time control and optimization of RAN elements and resources. For example, the near-RT RIC 130 can provide near-real-time control and optimization via fine-grained (e.g., UE-based, cell-based, etc.) data collection and actions based on an E2 interface. In some example implementations, the near-RT RIC 130 can operate on a time scale of 10 milliseconds to 1 second, and can be coupled with the O-CU 140, O-eNB 150, and O-DU 160 via an E2 interface. The near-RT RIC 130 can use the E2 interface to control underlying RAN elements (E2 nodes / network functions (NFs)) through a near-real-time control loop.

[0040] According to example embodiments, the near-RT RIC 130 can be configured to execute one or more Al policies provided by the non-RT RIC 120, and then (based on the one or more Al policies) perform one or more energy saving operations, such as switching on / off a cell / carrier, switching a user from one cell to another, and so on. Further, the near-RT RIC 130 can monitor, suspend / stop, override, and control E2 nodes (e.g., O-CU 140, O-DU 160, and so on) via utilization of the one or more Al policies. For example, the near-RT RIC 130 can receive one or more Al policies (e.g., energy saving policy(s), and so on) 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), and so on) or one or more policy commands. In some example implementations, upon receiving the Al policy(s), the near-RT RIC 130 can collect one or more measurement data from one or more E2 nodes (e.g., O-CU 140, O-eNB 150, O-DU 160, and so on) via an E2 interface, and then determine the one or more control operations thereafter (e.g., by performing AI / ML inference based on the received Al policy(s) and the collected measurement data, and so on). Subsequently, the near-RT RIC 130 can generate one or more control messages (e.g., cell / carrier on / off message, and so on) and send to one or more of the E2 nodes and / or O-RU 170. Accordingly, the E2 node(s) and / or O-RU(s) can be configured to update their associated configurations, and thereby perform one or more operations to turn on / off a cell or a carrier.

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

[0042] Next, a description of the O-CU 140, O-eNB 150, O-DU 160, and O-RU 170 will be provided. Generally, the O-CU 140, O-DU 160, and O-RU 170 can constitute a base station, such as a gNodeB (gNB) of 5G NR or a node in a next generation radio access network (NG-RAN), a base station of a 6G network, and so forth. On the other hand, the O-eNB 150 can refer to an O-RAN compliant node of a 4G LTE version (e.g., an eNB following the O-RAN architecture).

[0043] Communication between the O-CU 140 and the O-DU 160 can be performed via the F1 interface, while communication between the O-DU 160 and the O-RU 170 can 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 can be merged and collectively referred to as the “CUS plane.” According to example embodiments, the system can include a plurality of O-DUs 160, and the O-CU 140 can be communicatively coupled with the plurality of O-DUs via the F1 interface. Similarly, the system can include a plurality of O-RUs 170, and the O-DU(s) 160 can be communicatively coupled with the plurality of O-RUs via one or more O-FHC / U / S / M plane interfaces.

[0044] According to example embodiments, the O-CU 140 and the O-DU 160 can be defined in software and can be deployed in one or more network nodes. For example, the O-CU 140 and the O-DU 160 can be deployed in the form of virtualized network functions (VNFs), containerized and / or cloud-native functions (CNFs), and the like on one or more servers. According to example embodiments, the O-CU 140 and the O-DU 160 can be deployed in the same node (e.g., the same server) and / or can be located in similar geographical locations (e.g., deployed on different servers of the same data center). According to embodiments, the O-CU 140 and the O-DU 160 can be deployed in different nodes and / or can be located in different geographical locations. For example, the O-CU 140 can be deployed in one or more central servers (i.e., servers in one or more central data centers), while the O-DU 160 can be deployed in one or more edge servers (i.e., servers in one or more edge data centers).

[0045] The O-DU 160 can receive radio signals from end users (via one or more UEs and one or more cells) and can accordingly provide operations or support for lower layers of the protocol stack (e.g., RLC layer, MAC layer, physical layer, etc.). For example, the O-DU 160 can perform one or more scheduling operations. The O-CU 140 can communicatively couple the O-DU 160 to a core network (e.g., a 4G evolved packet core (EPC), a 5G core network, etc.) and can receive radio signals from the O-DU 160, accordingly providing operations or support for higher layers of the protocol stack (e.g., PDCP layer, RRC layer, etc.).

[0046] According to example embodiments, the O-CU 140 can 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 can refer to a logical node that hosts or implements the control plane portion of the RRC and PDCP protocols and can be responsible for managing 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 can refer to a logical node that hosts or implements the user plane portion of the PDCP protocol and the SDAP protocol and can be responsible for managing the transmission of data traffic and user data packets. The O-CU-CP 141 and the O-CU-UP 142 can be coupled to each other via an El interface.

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

[0048] The O-RU(s) 170 can be physical nodes that convert radio signals from antennas into digital signals that can be transmitted over a fronthaul link to the O-DU 160. In this regard, the network cell(s) described herein can correspond to one or more radio units that are responsible for providing wireless coverage and signal transmission within the network cell. The network cell can include a macro cell, a micro cell, a pico cell, a femto cell, and / or any other suitable type of network cell. Each cell can have an associated coverage area within which at least one O-RU 170, at least one antenna system, and any other suitable type of transport network element (TNE) can be deployed.

[0049] According to example embodiments, the O-DU 160 can be configured to control or instruct the associated O-RU(s) via one or more O-FHC / U / S / M plane interfaces. For example, the O-DU 160 can instruct the O-RU(s) 170 to shut down or enter a sleep mode via the O-FH C / U / S plane interfaces. On the other hand, the exchange of capabilities between the SMO 110 and the O-RU(s) 170 can be performed via the O-FH M plane interface. For example, the O-RU(s) 170 can inform the SMO 110 of how long it needs to remain in a sleep mode (or a shutdown mode) to save a certain amount of energy, and so forth.

[0050] In view of the above, example embodiments of the present disclosure introduce a mechanism to pre-configure one or more energy saving policies in an O-RAN architecture. Specifically, the non-RT RIC 120 can be leveraged to generate various types of energy saving policies and provide them to the near-RT RIC 130, which can leverage the energy saving policies provided by the non-RT RIC 120 to perform suitable energy saving operation(s). Further details of the energy saving policies will be provided below. Energy saving policies

[0051] As noted above, example embodiments of the present disclosure facilitate pre-configuration of one or more energy saving policies. In particular, example embodiments provide a system that includes a non-RT RIC (or an apparatus / device implementing the non-RT RIC) configured to generate at least one energy saving policy to be executed by a near-RT RIC, and then provide the at least one energy saving policy to the near-RT RIC. In this regard, example embodiments introduce new attributes and parameters for defining and specifying various types of energy saving policies. These new attributes and parameters are in addition to the attributes and parameters specified for A1 policies in current version technical specifications (e.g., O-RAN.WG2.A1TD) provided by standard organizations such as the O-RAN Alliance. Further, as further described below, in some example embodiments, the non-RT RIC can 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 includes new attributes and parameters associated with energy saving. In the following, descriptions of example energy saving policies and example policy schemas are provided in accordance with one or more example embodiments.

[0052] Figure 2 A block diagram illustrating an example energy saving policy in accordance with one or more example embodiments is shown. As shown in Figure 2 The energy saving policy includes information associated with at least one policy scope identifier, at least one policy target, and at least one policy resource. In some example implementations, the policy target and the policy resource can form a policy statement.

[0053] The information of the energy saving policy can be represented in simple data types and structured data types. Simple data types can refer to basic data types representing a single parameter, such as integer, float value, character, and the like. On the other hand, structured data types can refer to a collection of data items organized in a structured manner.

[0054] Examples of simple data types for scopes and statements associated with energy saving policies can be defined in Table 1 below. Table 1: Definition of simple data types for scopes and statements

[0055] Further, an enumeration OperatorType (which represents a preference for a particular comparison operator) associated with energy saving policies can be defined in Table 2 below. Table 2: Definition of OperatorType

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

[0057] According to example embodiments, the policy scope identifier can be defined in the form of a structured data type, and can be referred to as “ScopeIdentifier”. It is contemplated that the policy scope identifier described herein can also be referred to or defined by any other suitable term without departing from the scope of the present disclosure. In this regard, the policy scope identifier can include one or more information or attributes, as defined in Table 3 below. Table 3: ScopeIdentifier data type definition

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

[0059] On the other hand, the policy objective and the policy resource can form one or more statements defining the subject, purpose, or target of the power saving policy. The definition of the structured data type or attributes that can be used in the statement for the policy objective and / or the statement for the policy resource can be defined in Table 4 below. Table 4: Data type definition related to policy objective / resource

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

[0061] According to example embodiments, a policy objective can specify energy saving objectives. For example, information associated with a policy objective can include one or more of the following: an energy saving objective (which can be referred to herein as “ES” or “EsObjectives,” and which can be calculated based on the formula ES = ΔEC%, where “EC” refers to a specific energy consumption), an energy efficiency objective (which can be referred to herein as “EE”), a RAN energy consumption objective (which can be referred to herein as “EC NG-RAN ”), a gNB energy consumption objective (which can be referred to herein as “EC gNB ”), a network service energy consumption objective (which can be referred to herein as “EC ns ”), a network function energy consumption objective (which can be referred to herein as “EC NF ”), and a quality of service (QoS) objective. According to example embodiments, an EE objective can include one or more EE objectives associated with various network levels or tiers, such as a PLMN level EE objective (which can be referred to herein as “EE MN, DV bits / J ”), a slice level EE objective, a node level EE objective, and the like.

[0062] According to example embodiments, structured data types and attributes that can be used to define a policy objective can be defined in Table 5 below. Table 5: Statements for policy objectives

[0063] According to example embodiments, a policy resource can specify conditions for resource usage of an energy saving policy. For example, information associated with a policy resource can include one or more of the following: a list of conditions, a list of inclusions, and a list of exclusions. In this regard, the list of conditions can include one or more of the following: network conditions and timing conditions. The list of inclusions can include information of one or more nodes that can apply one or more energy saving operations. The list of exclusions can include information of one or more nodes that should be excluded from one or more energy saving operations.

[0064] According to example embodiments, structured data types and attributes that can be used to define a policy resource can be defined in Table 6 below. Table 6: Statements for policy resources

[0065] The types, content or attributes of energy saving resources (referred to herein as "EsResources") can be further defined in Table 7 below. Table 7: Definition of type EsResource

[0066] The esResources statement can be defined in Table 8 below as an array of the EsResource types defined in 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 ordered in descending order of importance as to how the cells should be preferred or avoided, e.g. the first entry is the most preferred or most to be avoided. When the value of the preference is set to "SHALL" or "FORBID", the cellldList contains cells of equal importance.

[0068] According to example embodiments, when the value of the primary attribute (i.e. the attribute of the primary cell) is set to "true" and / or the value of the preference attribute is set to "SHALL", then only the cells in the cellldList can be used as primary cells. When the value of the primary attribute is set to "true" and / or the value of the preference attribute (i.e. the attribute of the preferred cell) is set to "PREFER", then the cells in the cellldList can be used as primary cells. When the value of the primary attribute is set to "true" and the value of the preference is set to "AVOID" or "FORBID", then none of the cells in the cellldList can be used as primary cells.

[0069] Further, the EsObjective statement can contain the attributes defined in Table 9 below: Table 9: Definition of statement type EsObjectives

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

[0071] According to non-limiting use cases, a traffic steering policy (TSP) statement can be combined with one or more information or content of an energy saving policy. For example, a TSP statement can be applied with a ScopeIdentifier that contains different combinations of identifiers. Example combinations of TSP statements with ScopeIdentifiers are presented in Table 10 below. Table 10: Example combinations of tspResources statements with ScopeIdentifiers

[0072] In Table 10 above, each row lists the allowed combinations of identifiers for the specified statement. In this regard, the notation is the same as the cardinality: “0” means that the identifier must not appear, “0..1” means that the identifier can appear, and “1” means that the identifier must appear.

[0073] According to example embodiments, parameters and characteristics of an energy saving policy can be defined by a policy schema. In this regard, a policy schema can define or specify a structured format that outlines the attributes and content of an energy saving policy. For example, a policy schema can specify the name, description, statements, and data structures of an energy saving policy, which can include parameter types, associated values, and settings, among others. According to example embodiments, an energy saving policy can be defined in the format of JavaScript Object Notation (JSON). In this case, an energy saving policy can be generated or defined by a non-RT RIC based on an associated JSON-based policy schema. Specifically, a JSON policy schema outlines the attributes or fields required to define an energy saving policy, the associated data types, and any other policy requirements, and the non-RT RIC can obtain and utilize the policy schema to define, generate, and configure an energy saving policy.

[0074] According to one or more example embodiments, an example of a JSON schema associated with an energy saving policy is presented in Table 11 below. For ease of description only, portions associated with energy saving configuration (e.g., scope identifier, policy objectives, resources, etc.) are shown in bold. Table 11: Example of a JSON-based policy schema

[0075] According to example embodiments, the non-RT RIC can obtain a policy pattern, and then based on the policy pattern, generate various types of energy saving policies to be executed by near-RT RICs. For example, Figure 3 FIGURE 1 illustrates a block diagram of various types of energy saving policies, according to one or more example embodiments. As shown in FIGURE 1, the energy saving policies can be classified into at least one of the following: 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 can be generated and provided by the non-RT RIC, and can be executed by near-RT RICs to perform one or more energy saving operations. Examples of each type of the above-mentioned energy saving policies will be described hereinafter. Figure 3 Energy saving policies based on energy thresholds

[0076] This type of energy saving policy establishes a specific threshold(s) or limit(s) defined by an energy related criterion or parameter (e.g., energy consumption target, energy efficiency target, energy saving target, etc.) for triggering or initiating the execution of one or more energy saving operations. For example, when the energy related criterion (e.g., energy usage) exceeds or falls below the threshold, the energy saving policy can trigger one or more operations to optimize energy saving.

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

[0078] ​Further, the policy target of the energy threshold-based policy can specify one or more energy saving targets. In this regard, the policy target can include an energy parameter associated with an energy saving target and defining a threshold for initiating execution of one or more energy saving operations. For example, the policy target of the policy can include one or more of the following: an energy saving target (ES), an energy efficiency target (e.g., an energy efficiency target (EE MN, DV bits / J ) of a PLMN, etc.), a RAN energy consumption target (EC NG-RAN ), a gNB energy consumption target (EC gNB ), a network service energy consumption target (EC ns ), and a network function energy consumption target (EC NF ).

[0079] Further, the policy resource of the energy threshold-based policy can specify a condition for resource usage of the energy threshold-based policy. For example, the policy resource can include one or more of the following: an inclusion list, an exclusion list, and a resource or preference based on a range identifier(s). In this regard, the inclusion list can include information of one or more nodes (e.g., cell ID, network ID, O-RU ID, etc.) that can apply the energy saving operation(s); while the exclusion list can 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 can be applicable to different network levels or tiers. For example, the energy threshold-based policy can be used to optimize slice level energy efficiency, optimize node level (e.g., gNB / O-CU / O-DU / O-RU level) energy efficiency, optimize cell level energy efficiency, optimize PLMN level energy efficiency, and so on.

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

[0082] In the example of Table 12, the range identifier of the energy policy includes a slice ID, which defines the specific network slice(s) for which the energy saving policy is applicable; and a PLMN ID, which defines the PLMN associated with the target network slice. Further, the policy objective of the energy policy includes an energy efficiency target, which defines the threshold for initiating the energy saving operation(s). Further, the policy resource can include an exclusion list, which specifies the cells that can be excluded from the energy saving operation(s). These cells can refer to the cells in a specific area, such as a high capacity area, a hospital, and the like. In this case, once the energy efficiency of the specified network slice is below the threshold defined by the energy efficiency target, the near-RT RIC can perform or trigger at least one energy saving operation on the associated cell(s), such as turning off one or more cells in the network slice (except those specified in the exclusion list) to reach or maintain the energy efficiency target.

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

[0084] In the example above, the energy saving policy has the same policy resource as the energy saving policy defined in Table 12 above. This energy saving policy in Table 13 is different from the energy saving policy in Table 12 in that its associated range identifier contains the ID of the specific node (e.g., gNB-DU ID of a DU) for which the energy saving operation is applicable, instead of the slice ID and the PLMN ID. Further, the associated policy objective contains an energy consumption target (instead of the energy efficiency target in Table 12), which defines the threshold for initiating the energy saving operation(s). In this case, once the energy consumption of the associated DU(s) exceeds / is below the threshold defined by the energy consumption target, the near-RT RIC can perform or implement the energy saving operation(s) to maintain the energy consumption of the associated node to satisfy the energy consumption target.

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

[0086] In the example of Table 14, the range identifier of the energy saving policy includes a PLMN ID, which defines the specific PLMN for which the energy saving policy is applicable. Further, the policy objective of the energy policy includes an energy efficiency target (EE MN, DV), which defines a threshold for initiating the energy saving operation(s). In addition, the policy resource includes an include list, which specifies the O-RUs for which the energy saving operation is applicable, and an exclude list, which specifies the O-RUs that can be excluded from the energy saving operation(s). In this case, the near-RT RIC can perform the energy saving operation(s) to maintain the energy efficiency of the associated PLMN to meet the energy efficiency target once the energy efficiency of the associated PLMN exceeds / is below the threshold defined by the energy efficiency target.

[0087] In view of the above, the pre-configuration of the energy threshold-based energy saving policy enables the establishment of one or more energy saving targets in the form of measurable thresholds, covering factors such as energy efficiency and energy consumption. These energy saving targets can be implemented with or without the allocation of policy resources, allowing the creation of an include list or an exclude list. Energy saving policies based on service assurance thresholds

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

[0089] According to example embodiments, the policy target of the service assurance threshold-based energy saving policy can include both QoS target(s) and energy-related target(s) (e.g., energy efficiency target, energy consumption target, energy saving target, etc.), thereby enhancing energy efficiency while maintaining a certain QoS level. Specifically, one or more QoS targets and one or more energy-related targets can be set to achieve a certain level of service assurance. By integrating these two types of targets, energy consumption can be optimized without affecting the desired QoS.

[0090] It can be contemplated that the service assurance threshold-based energy saving policy can include one or more policy scope identifiers and one or more policy resources, 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] In addition, similar to the energy threshold-based energy saving policy, the service assurance threshold-based energy saving policy can be applicable to different network levels or tiers. For example, the service assurance threshold-based energy saving policy can be used to optimize slice-level energy efficiency, optimize node-level (e.g., gNB / O-CU / O-DU / O-RU level) energy efficiency, optimize cell-level energy efficiency, optimize PLMN-level energy efficiency, and so on.

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

[0093] In the example of Table 15, the range identifier of the energy saving policy includes a PLMN ID and a QoS ID, the PLMN ID defines a specific PLMN to which the energy saving policy is applicable, and the QoS ID defines a QoS to which the energy saving policy is applicable. Further, the policy target of the energy policy includes an energy saving target and a plurality of QoS targets, which define one or more thresholds for initiating the energy saving operation(s). Further, the policy resource includes a cell level inclusion list, which specifies the cells to which the energy saving operation(s) are applicable, and a cell level exclusion list, which specifies the cells that can be excluded from the energy saving operation(s). In this case, the near RT RIC can trigger or execute the energy saving operation(s) on the cells defined in the inclusion list and avoid executing the energy saving operation(s) on the cells defined in the exclusion list once the energy efficiency of the associated PLMN exceeds / is below the threshold defined by the energy efficiency target and / or once the QoS exceeds / is below the threshold(s) defined by the QoS target(s), thereby achieving the energy efficiency target while ensuring the QoS target for the specific QoS.

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

[0095] In the example of Table 16, the energy saving policy has a similar policy range identifier and policy target as the energy saving policy in Table 15. The energy saving policy in Table 16 differs from the energy saving policy in Table 15 in that the associated policy resource includes a node level inclusion list, which specifies the O-DUs to which the energy saving operation(s) are applicable. In this case, the near RT RIC can trigger or execute the energy saving operation(s) on the O-DUs defined in the inclusion list and avoid triggering or executing the energy saving operation(s) on the cells defined in the exclusion list once the energy efficiency of the associated PLMN exceeds / is below the threshold defined by the energy efficiency target and / or once the QoS exceeds / is below the threshold(s) defined by the QoS target(s), thereby achieving the energy efficiency target while ensuring the QoS target for the specific QoS.

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

[0097] In the example of Table 17, the range identifier of the power saving policy can include a slice ID and a cell ID, the slice ID defining the network slice to which the power saving policy is applicable, and the cell ID defining the network cell to which the power saving policy is applicable. Moreover, the policy objective of the power saving policy includes a power saving target and a plurality of QoS targets, which define one or more thresholds for initiating the power saving operation(s). Furthermore, the policy resource includes an include list, which specifies the cells to which the power saving operation(s) are applicable, and an exclude list, which specifies the cells that can be excluded from the power saving operation(s). In this case, the near-RT RIC can trigger or execute the power saving operation(s) on the cells defined in the include list, while refraining from triggering or executing the power saving operation(s) on the cells defined in the exclude list, once the energy efficiency of the associated slice and / or cell exceeds / falls below the threshold defined by the energy efficiency target, and / or once the specific QoS exceeds / falls below the threshold(s) defined by the QoS target(s), thereby achieving the energy efficiency target while ensuring the QoS targets for the specific QoS.

[0098] In addition to cell / carrier shutdown, the near-RT RIC can also trigger handover of low priority users from the target cell to a neighboring cell. In this case, the near-RT RIC is responsible for maintaining the specific QoS of those users within the defined range identifier. This ensures seamless transfer of users while optimizing energy consumption.

[0099] In view of the above, by preconfiguring power saving policies based on service assurance thresholds, it is possible to optimize energy efficiency while maintaining a certain level of QoS, thereby achieving a certain level of service assurance. By integrating the energy-related target(s) and the QoS target(s), it is possible to optimize energy consumption without affecting the desired QoS. Energy saving policies based on network conditions

[0100] This type of power saving policy includes or prioritizes network criteria or parameters for initiating the execution of one or more power saving operations. According to example embodiments, network condition based power saving policies involve activating the policy objective(s) upon meeting specific network condition(s) (determined by the near-RT RIC). This approach allows for the implementation of power saving measures when pre-defined network conditions are met, thereby optimizing overall energy efficiency.

[0101] According to example embodiments, the policy resource of the network condition based energy saving policy can include at least one network condition for triggering or initiating execution of one or more energy saving operations. The network condition can include one or more of the following: 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, without departing from the scope of the present disclosure, the network condition based energy saving policy can include one or more policy scope identifiers and one or more policy targets, which 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.

[0103] Further, the network condition based energy saving policy can be applicable to different network levels or tiers. For example, the network condition based energy saving policy can be used to optimize slice level energy efficiency, optimize node level (e.g., gNB / O-CU / O-DU / O-RU level) energy efficiency, optimize cell level energy efficiency, optimize PLMN level energy efficiency, etc.

[0104] Examples of the network condition based policy for optimizing network level energy saving are defined in Table 18 below. Table 18: Example network level network condition based policy

[0105] In the example of Table 18, the scope identifier of the energy saving policy can include a PLMN ID, which defines the PLMN to which the applicable energy saving policy is applied. Further, the policy target of the energy policy includes an energy efficiency target. Also, the policy resource includes a condition list, which includes a plurality of network conditions; an inclusion list, which specifies cells for which the energy saving operation(s) are applicable when one or more network conditions in the condition list are satisfied; and an exclusion list, which specifies cells that can be excluded from the energy saving operation(s). In this case, once the energy efficiency of the associated PLMN exceeds / is below the threshold defined by the energy efficiency target, the near RT RIC can determine whether the one or more network conditions are satisfied. Accordingly, based on the determination that the one or more network conditions are satisfied, the near RT RIC can trigger or execute the energy saving operation(s) for the cells defined in the inclusion list, while refraining from triggering or executing the energy saving operation(s) for the cells defined in the exclusion list, thereby achieving the energy efficiency target.

[0106] In view of the above, the network condition(s) are incorporated into the energy saving policy, allowing the near-RT RIC to initiate or perform the energy saving operation(s) (e.g., cell / carrier shutdown, user handover, etc.) when the specified network condition(s) are met. As the measurements are performed with lower latency, the near-RT RIC is able to utilize a more efficient control loop, thus quickly implementing and recovering the appropriate operation(s). Moreover, the configuration or selection of the network conditions in the energy saving policy can be decided based on specific preferences or priorities. Furthermore, the specified network conditions provide the network operator the ability to trigger the energy saving operation(s) when the complexity of the xApp exceeds expectations or when the rApp specifies the terms, especially when xApps from different providers are used. Energy saving policies based on timing conditions

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

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

[0109] It is contemplated that, without departing from the scope of the present disclosure, the network condition-based energy saving policy can include one or more policy scope identifiers and one or more policy targets, 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 energy saving policy.

[0110] Moreover, the timing condition-based energy saving policy can be applicable to different network levels or tiers. For example, the timing condition-based energy saving policy can be used to optimize slice-level energy efficiency, optimize node-level (e.g., gNB / O-CU / O-DU / O-RU level) energy efficiency, optimize cell-level energy efficiency, optimize PLMN-level energy efficiency, and the like.

[0111] An example of a timing condition-based policy for optimizing network-level energy saving is defined in Table 19 below. Table 19: Example network-level network condition-based policy

[0112] In the example of Table 19, the range identifier of the energy saving policy can include a PLMN ID, which defines the PLMN for which the energy saving policy is applicable. Further, the policy objective of the energy saving policy includes an energy efficiency target. Moreover, the policy resource includes a condition list, which includes multiple timing conditions (e.g., esNotAllowedTimePeriod, esAllowedTimePeriod, etc.), and a containment list, which specifies the cell(s) for which the energy saving operation(s) are applicable when one or more of the timing conditions in the condition list are satisfied. In this case, during the esAllowedTimePeriod (e.g., night time from Monday to Friday), the near-RT RIC can trigger or execute the energy saving operation(s) on the cells defined in the containment list when the energy efficiency of the associated PLMN exceeds / is below the threshold value defined by the energy efficiency target, thereby achieving the energy efficiency target. On the other hand, during the esNotAllowedTimePeriod (e.g., day time from Monday to Friday), the near-RT RIC will not initiate or execute the energy saving operation(s) with the specific energy saving policy.

[0113] In view of the above, the energy saving policy based on timing condition refers to activating the energy saving policy within a specified time period, while excluding the energy saving policy during the specific time period. This approach enables adjusting energy consumption, especially during off-peak hours or network activity lulls. By implementing the energy saving policy based on timing condition, the network operator can optimize energy usage based on fluctuations in network demand, thereby facilitating efficient resource utilization. Multiple types of energy saving policies

[0114] In addition to the four types of energy saving policies mentioned above (i.e., energy saving policy based on energy threshold, energy saving policy based on service assurance threshold, energy saving policy based on network condition, and energy saving policy based on timing condition), the non-RT RIC can also be configured to generate and provide one or more energy saving policies including multiple types of the above-mentioned energy saving policies.

[0115] Examples of multi-type energy saving policies for optimizing slice-level and cell-level energy saving are defined in Table 20 below. Table 20: Example combinations of policy based on network condition and policy based on timing condition

[0116] In the example of Table 20, the scope identifier of the energy saving policy can include a slice ID and a cell ID, the slice ID defining a network slice to which the energy saving policy is applicable, and the cell ID defining a 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 can be an action-oriented objective, which can be enforced or initiated by the near-RT RIC according to the conditions defined in the energy saving policy (e.g., shutting down a particular cell when a particular timing condition is met, etc.). Further, the policy resource includes a condition list, which includes a timing condition (e.g., esNotAllowedTimePeriod) and a plurality of network conditions (e.g., prbUsage, rrcUsers, etc.); an inclusion list, which specifies the cells to which the energy saving operation(s) are applicable when one or more conditions in the condition list are met; and an exclusion list, which specifies the cells that can be excluded from the energy saving operation(s). In this case, the near-RT RIC will only enforce the energy saving policy when the timing condition is met (i.e., outside the time period defined by esNotAllowedTimePeriod). Upon determining that the timing condition is met, the near-RT RIC can further determine whether the network condition(s) are met. Accordingly, the near-RT RIC can shut down (or trigger operations to shut down) the cells defined in the inclusion list while refraining from 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 of the different types of energy saving policies can be applicable to pre-configure the multi-type energy saving policy, such as a combination of three types or all types of energy saving policies, without departing from the present disclosure.

[0118] To this end, by utilizing different types of energy saving policies and different combinations of different types of energy saving policies, the example embodiments of the present disclosure efficiently and effectively facilitate the pre-configuration of energy policies that are compliant with the dynamicity and complexity of the policy requirements in O-RAN.

[0119] It is to be understood that the above-described energy policies (in Tables 12-20) are merely examples of possible configurations, the content of which is simplified for ease of description. In actual implementations, the energy policies can include more or less information, and / or the content therein can be arranged in different manners, without departing from the scope of the present disclosure. Example operations for preconfiguring energy saving policies

[0120] As described above, the example embodiments of the present disclosure facilitate the pre-configuration of one or more energy saving policies. The example operations associated therewith are described below.

[0121] Figure 4A flowchart illustrating an example method 400 for preconfiguring one or more energy saving policies, in accordance with one or more example embodiments, is shown. One or more operations of the method 400 can be performed by a non-RT RIC included in a system (e.g., see Figure 1 The non-RT RIC 120, etc., in the O-RAN system as described above). In some example implementations in which the non-RT RIC 120 is implemented in an apparatus or hardware (e.g., a server), one or more operations of the method 400 can be performed by a hardware component (e.g., a processor of the server) when executing computer-readable instructions (stored in a memory of the server, etc.).

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

[0123] After obtaining the policy schema, the method 400 can continue to operation S420, at which the non-RT RIC can be configured to generate, based on the policy schema, at least one energy saving policy to be executed by a near-RT RIC. According to an example embodiment, the at least one energy saving policy can 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.

[0124] As described above, in general, an energy saving policy can include information associated with: at least one policy scope identifier to specify at least one node to which the energy saving policy is applied; at least one policy target to specify an energy saving target; and at least one policy resource to specify a condition of resource usage for the energy saving policy. In this regard, the at least one policy target of an energy threshold based energy saving policy can include an energy parameter defining a threshold for initiating execution of one or more energy saving operations; the at least one policy target of a service assurance threshold based energy saving policy can include a QoS target defining a threshold for initiating execution of one or more energy saving operations; the at least one policy resource of a network condition based energy saving policy can include a network condition for initiating execution of one or more energy saving operations; and the at least one policy resource of a timing condition based energy saving policy can include a timing for initiating execution of one or more energy saving operations.

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

[0126] Further, the at least one policy objective can include one or more of: a power 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] Further, the at least one policy resource can include one or more of: a condition list, an include list, and an exclude list. The condition list can include one or more of: a network condition and a timing condition. The include list can include information of one or more nodes that are capable of applying one or more power saving operations. The exclude list can include information of one or more nodes that should be excluded from one or more power saving operations.

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

[0129] After generating the at least one power saving policy, the method 400 can proceed to operation S430, at which the non-RT RIC can be configured to provide the at least one power saving policy to the near-RT RIC via the Al interface. Thus, the near-RT RIC can be configured to execute the at least one power saving policy to perform one or more power saving operations (e.g., cell on / off, user handover to another cell, etc.).

[0130] In view of the above, example embodiments of the present disclosure effectively and efficiently facilitate pre-configuration of one or more power saving policies by the non-RT RIC, thereby optimizing energy efficiency and power saving opportunities in an O-RAN system. Example of system hardware components

[0131] One or more components in a system of example embodiments (e.g., the non-RT RIC, the near-RT RIC, etc.) and operations associated therewith (e.g., Figure 4One or more of the operations, one or more energy saving operations, etc., described in the above can be implemented in one or more systems, devices, or hardware components, such as one or more servers, etc. In the following, a description of a device of a system or component in which example embodiments can be implemented will be provided. It is contemplated that the above description with reference to Figures 1-4 The one or more operations or methods described can be performed by the device. For example, the one or more operations or methods can be performed by at least one processor of the device when executing machine-readable instructions or computer-readable instructions (e.g., instructions for implementing a non-RT RIC, etc.) stored in a memory or storage component of the device.

[0132] Figure 5 An embodiment of a device 500 is illustrated. As shown in Figure 5 As shown in the above, the device 500 can 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] As used herein, the processor 510 means any type of computational circuitry, which can include hardware elements and software elements. The processor 510 can 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, etc. The processor 510 can be a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), an application-specific integrated circuit (ASIC), or other types of processing components.

[0134] The memory 520 includes a non-transitory computer-readable medium. The memory 520 includes a random access memory (RAM), a read-only memory (ROM), and / or other types of dynamic or static storage devices (e.g., a flash memory, a magnetic storage device, and / or an optical storage device) to store information and / or instructions for use by the processor 510. The memory 520 includes machine-readable instructions executable by the processor 510. The machine-readable instructions, when executed by the processor 510, cause the processor 510 to perform one or more method steps of the above-described embodiments.

[0135] The storage component 530 stores information and / or software associated with the operation and use of the device 500. For example, the storage component 530 can include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, and / or a solid state disk), a compact disk (CD), a digital versatile disk (DVD), a flash drive, a memory stick, a magnetic cassette, a magnetic tape, and / or other types of non-transitory computer- readable media, and corresponding drives.

[0136] The input component 540 is configured to receive information, such as user input. For example, the input component 540 can include, but is not 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 can include a sensor for sensing information (e.g., a global positioning system (GPS), an accelerometer, a gyroscope, and / or an actuator).

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

[0138] The communication interface 560 is an interface for providing a communication connection to other devices, such as external devices and internal devices. The connection of 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 present between the device 500 and other devices. In other words, the standard of the communication interface 560 is not limited.

[0139] The bus 570 serves as an interconnection 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 can include a wired interconnection or a wireless interconnection.

[0140] Figure 5 The number and arrangement of components shown in FIG. 5 are provided as an example. In practice, a device 500 can 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 the device 500 can perform one or more functions described as being performed by another set of components of the device 500. Figure 5 Various aspects of embodiments It is contemplated that the embodiments described above with reference to FIGS. 1-5 are merely examples of possible implementations of the present disclosure, and are not intended to limit or restrict the scope or nature of the present disclosure.

[0141] Figures 1-5 In particular, the aforementioned disclosure provides illustration and description, but is not intended to be exhaustive or to be limited to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or can be acquired from practice of the implementations. The present disclosure is well adapted to carry out the objects and attain the ends and advantages mentioned above as well as those that are inherent therein.

[0142] In particular, the aforementioned disclosure provides illustration and description, but is not intended to be exhaustive or to be limited to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or can be acquired from practice of the implementations. The present disclosure is well adapted to carry out the objects and attain the ends and advantages mentioned above as well as those that are inherent therein.

[0143] ​Some embodiments may relate to devices (e.g., nodes, etc.), systems, methods, and / or computer-readable media, and the degree of integration of their technical details is not limited. Furthermore, one or more of the aforementioned components 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 computer-readable non-transitory storage media (or multiple media) storing computer-readable program instructions thereon for causing the processor to perform operations.

[0144] A computer-readable storage medium can be a tangible device capable of retaining and storing instructions for use by an instruction execution device. A computer-readable storage medium can be, for example, but not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes: portable computer floppy disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), electrically erasable programmable read-only memory (EEPROM), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital multifunction disc (DVD), memory sticks, floppy disks, mechanical encoding devices (such as punched cards or raised structures with instructions engraved in grooves), and any suitable combination of the foregoing. As used herein, a computer-readable storage medium should not be construed as a transient signal itself, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses through fiber optic cables), or electrical signals transmitted through wires.

[0145] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a corresponding computing / processing device, or can be downloaded via a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network) to an external computer or external storage device. This network may include copper transmission cables, optical transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to a computer-readable storage medium within the corresponding computing / processing device for storage.

[0146] Computer readable program code / instructions for carrying out operations can be assembly instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuitry, or 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 a procedural programming language such as the "C" programming language or similar programming languages.

[0147] The computer readable program instructions can 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 can 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 connection can be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry (for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA)) can be used in place of or in combination with a computer readable program instruction to implement aspects or operations.

[0148] These computer readable program instructions can 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 can 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

[0149] The computer readable program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device 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 diagrams in the figures illustrate the architecture, functionality, and operations 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 can represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical functions ("instructions"). The methods, computer systems, and computer-readable media can include more, fewer, or different blocks than those shown in the figures. In some alternative implementations, the functions noted in the blocks can occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently or in the reverse order, depending on the functionality involved. Also, a block represented as a single block in the figures can be implemented in multiple blocks depending on the logic involved. Further, it should be noted that any of the blocks in the block diagrams and / or flowchart illustrations, and combinations thereof, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

[0151] It will be apparent that systems and / or methods, described herein, can 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 limiting of the implementations. Thus, the operation and behavior of the systems and / or methods were described herein without reference to specific software code — it being understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.

[0152] In light of the above, various other corresponding aspects and features of embodiments of the present disclosure can be defined by the following items:

[0153] Item [1]: A system comprising: a non-real-time (non-RT) radio access network intelligent controller (RIC) configured to: obtain a policy pattern; generate, based on the policy pattern, at least one energy saving policy to be executed by a near-RT RIC, wherein the at least one energy saving policy can comprise: at least one policy scope identifier to specify at least one node to which the energy saving policy is applied; at least one policy target to specify an energy saving target; and at least one policy resource to specify a condition of resource usage for the energy saving policy; and provide the at least one energy saving policy to the near-RT RIC via an Al interface.

[0154] Item [2]: The system of item [1], wherein the at least one energy saving policy can comprise 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.

[0155] Item [3]: The system of item [2], wherein the at least one policy objective of the energy threshold-based energy saving policy can comprise an energy parameter defining a threshold for initiating execution of one or more energy saving operations; wherein the at least one policy objective of the service assurance threshold-based energy saving policy can comprise a quality of service (QoS) objective defining a threshold for initiating execution of one or more energy saving operations; wherein the at least one policy resource of the network condition-based energy saving policy can comprise a network condition for initiating execution of one or more energy saving operations; and wherein the at least one policy resource of the timing condition-based energy saving policy can comprise a timing for initiating execution of one or more energy saving operations.

[0156] Item [4]: The system of any of items [1]-[3], wherein the at least one policy scope identifier can comprise 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 list of cell IDs that can comprise a plurality of cell IDs, a list of gNB IDs that can comprise a plurality of gNB IDs, a list of O-RU IDs that can comprise a plurality of O-RU IDs, a list of O-DU IDs that can comprise a plurality of O-DU IDs, a list of O-CU IDs that can comprise a plurality of O-CU IDs, a list of slice IDs that can comprise a plurality of slice IDs, and a list of network IDs that can comprise a plurality of network IDs.

[0157] Item [5]: The system of any of items [1]-[4], wherein the at least one policy objective can comprise 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.

[0158] Item [6]: The system of any of items [1]-[5], wherein the at least one policy resource can comprise one or more of: a condition list, an inclusion list, and an exclusion list, wherein the condition list can comprise one or more of: a network condition and a timing condition, wherein the inclusion list can comprise information of one or more nodes that can apply one or more energy saving operations, and wherein the exclusion list can comprise information of one or more nodes that should be excluded from one or more energy saving operations.

[0159] Item [7]: The system of any of items [1]-[6], wherein the policy schema can comprise a JavaScript Object Notation (JSON) schema.

[0160] Item [8]: A method comprising: obtaining a policy pattern; generating, based on the policy pattern, 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 can comprise: at least one policy scope identifier to specify at least one node to which the energy saving policy is applied; at least one policy objective to specify an energy saving objective; and at least one policy resource to specify a condition of resource usage for the energy saving policy; and providing the at least one energy saving policy to the near-RT RIC via an Al interface.

[0161] Item [9]: The method of item [8], wherein the at least one energy saving policy can comprise 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.

[0162] Item

[10] : The method of item [9], wherein the at least one policy objective of the energy threshold based energy saving policy can comprise an energy parameter defining a threshold for initiating execution of one or more energy saving operations; wherein the at least one policy objective of the service assurance threshold based energy saving policy can comprise a quality of service (QoS) objective defining a threshold for initiating execution of one or more energy saving operations; wherein the at least one policy resource of the network condition based energy saving policy can comprise a network condition for initiating execution of one or more energy saving operations; and wherein the at least one policy resource of the timing condition based energy saving policy can comprise a timing for initiating execution of one or more energy saving operations.

[0163] Item

[11] : The method of any of items [8]-

[10] , wherein the at least one policy scope identifier can comprise 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 list of cell IDs that can comprise a plurality of cell IDs, a list of gNB IDs that can comprise a plurality of gNB IDs, a list of O-RU IDs that can comprise a plurality of O-RU IDs, a list of O-DU IDs that can comprise a plurality of O-DU IDs, a list of O-CU IDs that can comprise a plurality of O-CU IDs, a list of slice IDs that can comprise a plurality of slice IDs, and a list of network IDs that can comprise a plurality of network IDs.

[0164] Item

[12] : The method of any of items [8]-

[11] , wherein the at least one policy objective can comprise 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.

[0165] Item

[13] : The method of any of items [8]-

[12] , wherein the at least one policy resource can comprise one or more of: a condition list, an include list, and an exclude list, wherein the condition list can comprise one or more of: a network condition and a timing condition, wherein the include list can comprise information of one or more nodes that can apply one or more energy saving operations, and wherein the exclude list can comprise information of one or more nodes that should be excluded from one or more energy saving operations.

[0166] Item

[14] : The method of any of items [8]-

[13] , wherein the policy schema can comprise a JavaScript Object Notation (JSON) schema.

[0167] Item

[15] : A non-transitory computer-readable recording medium having recorded thereon instructions executable by a system comprising 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 executed by a near-RT RIC, wherein the at least one energy saving policy can comprise: at least one policy scope identifier to specify at least one node to which an energy saving policy is applied; at least one policy objective to specify an energy saving objective; and at least one policy resource to specify a condition of resource usage of the energy saving policy; and providing the at least one energy saving policy to the near-RT RIC via an Al interface.

[0168] Item

[16] : The non-transitory computer-readable recording medium of item

[15] , wherein 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.

[0169] Item

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

[16] , wherein the at least one policy objective of the energy threshold-based power saving policy can include an energy parameter defining a threshold for initiating execution of one or more power saving operations; wherein the at least one policy objective of the service assurance threshold-based power saving policy can include a quality of service (QoS) objective defining a threshold for initiating execution of one or more power saving operations; wherein the at least one policy resource of the network condition-based power saving policy can include a network condition for initiating execution of one or more power saving operations; and wherein the at least one policy resource of the timing condition-based power saving policy can include a timing for initiating execution of one or more power saving operations.

[0170] Item

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

[15] -

[17] , wherein the at least one policy scope identifier can 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 list of cell IDs that can include a plurality of cell IDs, a list of gNB IDs that can include a plurality of gNB IDs, a list of O-RU IDs that can include a plurality of O-RU IDs, a list of O-DU IDs that can include a plurality of O-DU IDs, a list of O-CU IDs that can include a plurality of O-CU IDs, a list of slice IDs that can include a plurality of slice IDs, and a list of network IDs that can include a plurality of network IDs.

[0171] Item

[19] : The non-transitory computer-readable recording medium according to items

[15] -

[18] , wherein the at least one policy objective can include one or more of: a power 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.

[0172] Item

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

[15] -

[19] , wherein the at least one policy resource can include one or more of: a condition list, an inclusion list, and an exclusion list, wherein the condition list can include one or more of: a network condition and a timing condition, wherein the inclusion list can include information of one or more nodes to which one or more power saving operations can be applied, and wherein the exclusion list can include information of one or more nodes from which one or more power saving operations should be excluded.

[0173] It is understood that the present disclosure can be carried out in various modifications and variations of the foregoing teachings and within the scope of the appended claims. It is further understood that the aspects of the present disclosure can be carried out in different embodiments and of the application and that only certain aspects of the application can be altered - others remain the same. Therefore, discrete embodiments are contemplated. In addition, where necessary, the components of the application have been partitioned into units conveniently to aid in

Claims

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

2. The system of 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 of claim 2, wherein the at least one policy objective of the energy threshold based energy saving policy comprises an energy parameter defining a threshold for initiating 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 defining a threshold for initiating execution of the one or more energy saving operations, wherein the at least one policy resource of the network condition based energy saving policy comprises a network condition for initiating 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 comprises a timing for initiating execution of the one or more energy saving operations.

4. The system of 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 list of cell IDs comprising a plurality of cell IDs, a list of gNB IDs comprising a plurality of gNB IDs, a list of O-RU IDs comprising a plurality of O-RU IDs, a list of O-DU IDs comprising a plurality of O-DU IDs, a list of O-CU IDs comprising a plurality of O-CU IDs, a list of slice IDs comprising a plurality of slice IDs, and a list of network IDs comprising a plurality of network IDs.

5. The system of 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 energy consumption objective, a network function energy consumption objective, and a QoS objective.

6. The system of claim 1, wherein the at least one policy resource comprises one or more of: a list of conditions, a list of inclusions, and a list of exclusions, wherein the list of conditions comprises one or more of: network conditions and timing conditions, wherein the list of inclusions comprises information of one or more nodes that are able to apply one or more energy saving operations, and wherein the list of exclusions comprises information of one or more nodes that should be excluded from the one or more energy saving operations.

7. The system of 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 to specify at least one node for which the energy saving policy is applied; at least one policy objective to specify an energy saving objective; and at least one policy resource to specify a condition of resource usage for the energy saving policy; and providing, via an Al interface, the at least one energy saving policy to the near-RT RIC.

9. The method of 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 of claim 9, wherein the at least one policy objective of the energy threshold based energy saving policy comprises an energy parameter defining a threshold for initiating 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 defining a threshold for initiating execution of the one or more energy saving operations, wherein the at least one policy resource of the network condition based energy saving policy comprises a network condition for initiating 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 comprises a timing for initiating execution of the one or more energy saving operations.

11. The method of 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 list of cell IDs comprising a plurality of cell IDs, a list of gNB IDs comprising a plurality of gNB IDs, a list of O-RU IDs comprising a plurality of O-RU IDs, a list of O-DU IDs comprising a plurality of O-DU IDs, a list of O-CU IDs comprising a plurality of O-CU IDs, a list of slice IDs comprising a plurality of slice IDs, and a list of network IDs comprising a plurality of network IDs. 12.The method of claim 8, wherein the at least one policy objective comprises one or more of: a power 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 of 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 capable of applying one or more power saving operations, and wherein the exclusion list comprises information of one or more nodes that should be excluded from the one or more power saving operations. 14.The method of 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 comprising a non-real-time (non-RT) Radio Access Network Intelligent Controller (RIC) to cause the non-RT RIC to perform a method, the method comprising: obtaining a policy schema; generating, based on the policy schema, at least one power saving policy executed by a near-RT RIC, wherein the at least one power saving policy comprises: at least one policy scope identifier for specifying at least one node to which the power saving policy is applied; at least one policy objective for specifying a power saving objective; and at least one policy resource for specifying a condition of resource usage of the power saving policy; and providing the at least one power saving policy to the near-RT RIC via an A1 interface. 16.The non-transitory computer-readable recording medium of claim 15, wherein the at least one power saving policy comprises at least one of: an energy threshold based power saving policy, a service assurance threshold based power saving policy, a network condition based power saving policy, and a timing condition based power saving policy. 17.The non-transitory computer-readable recording medium of claim 16, wherein the at least one policy objective of the energy threshold based power saving policy comprises an energy parameter defining a threshold for initiating execution of one or more power saving operations, wherein the at least one policy objective of the service assurance threshold based power saving policy comprises a Quality of Service (QoS) objective defining a threshold for initiating execution of the one or more power saving operations, wherein the at least one policy resource of the network condition based power saving policy comprises a network condition for initiating execution of the one or more power saving operations, and wherein the at least one policy resource of the timing condition based power saving policy comprises a timing for initiating execution of the one or more power saving operations.

18. The intransitive computer-readable recording medium of 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 including a plurality of cell IDs, a gNB ID list including a plurality of gNB IDs, an O-RU ID list including a plurality of O-RU IDs, an O-DU ID list including a plurality of O-DU IDs, an O-CU ID list including a plurality of O-CU IDs, a slice ID list including a plurality of slice IDs, and a network ID list including a plurality of network IDs.

19. The intransitive computer-readable recording medium of claim 15, wherein the at least one policy objective comprises one or more of: a power 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 intransitive computer-readable recording medium of 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 capable of applying one or more power saving operations, and wherein the exclusion list comprises information of one or more nodes that should be excluded from the one or more power saving operations.

Images