Network energy saving enhancement

Abstract

Example embodiments of the present disclosure relate to the network energy-saving enhancement. According to example embodiments, a system may include a non-real-time (Non-RT) radio access network intelligent controller (RIC). The Non-RT RIC may be configured to generate an energy-saving policy and provide the energy-saving policy to a near-real-time (Near-RT) RIC. The energy-saving policy is executable by the Near-RT RIC to perform an energy-saving operation, including at least one of: synchronization signal block (SSB) management, system information block 1 (SIB1) management, wake-up signal management, and physical random access channel (PRACH) management. The energy-saving policy may include a parameter associated with an activation criteria, a parameter associated with a user equipment (UE) capability requirement, and a parameter associated with a policy decision.

Description

NETWORK ENERGY SAVING ENHANCEMENTCROSS REFERENCE TO RELATED APPLICATION

[0001] This application claims priority to U.S. Provisional Patent Application No. 63 / 665,314 filed with the U.S. Patent and Trademark Office on June 28, 2024, the entire contents of which are incorporated herein by reference.TECHNICAL FIELD

[0002] The present disclosure relates to the enhancement of energy saving in a telecommunications network.BACKGROUND

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

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

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

[0006] Example embodiments of the present disclosure provide systems, apparatuses, methods, and the like that effectively and efficiently provision network energy-saving enhancements.

[0007] According to example embodiments, a system may include a non-real-time (Non- RT) RAN intelligent controller (RIC) that may be configured to generate an energy-saving policy and provide the energy-saving policy to a near-real-time (Near-RT RIC). The energy-saving policy is executable by the Near-RT RIC to perform an energy-saving operation, including at least one of: synchronization signal block (SSB) management, system information block 1 (SIB1) management, wake-up signal management, and physical random access channel (PRACH) management. The energy-saving policy may include a parameter associated with an activation criteria, a parameter associated with a user equipment (UE) capability requirement, and a parameter associated with a policy decision.

[0008] According to example embodiments, a method may include: generating, by a Non- RT RIC, an energy-saving policy, and providing, by the Non-RT RIC, the energy-saving policy to a Near-RT RIC. The energy-saving policy is executable by the Near-RT RIC to perform an energysaving operation, including at least one of: SSB management, SIB1 management, wake-up signal management, and PRACH management. The energy-saving policy may include a parameter associated with an activation criteria, a parameter associated with a UE capability requirement, and a parameter associated with a policy decision.

[0009] According to example embodiments, a non-transitory computer-readable recording medium having recorded thereon instructions executable by a system that includes a Non-RT RIC to cause the Non-RT RIC to perform a method. The method may include: generating an energysaving policy, and providing the energy-saving policy to a Near-RT RIC. The energy-saving policy is executable by the Near-RT RIC to perform an energy-saving operation, including at least one of: SSB management, SIB1 management, wake-up signal management, and PRACH management. The energy-saving policy may include a parameter associated with an activation criteria, a parameter associated with a UE capability requirement, and a parameter associated with a policy decision.

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

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

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

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

[0014] FIG. 3 illustrates a block diagram of an example method for implementing an energy-saving policy, according to one or more example embodiments;

[0015] FIG. 4 illustrates a block diagram of an example device for implementing one or more example embodiments; and

[0016] FIG. 5 illustrates a block diagram of an example environment for implementing one or more example embodiments.DETAILED DESCRIPTION

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

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

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

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

[0021] Further, although example embodiments of the present disclosure are described herein as being mainly implemented by one or more specific 0-RAN components (e.g., Non-RT RIC, etc.), it is contemplated that the example embodiments of the present disclosure may also be implemented by any suitable modules or entities in the O-RAN, without departing from the scope of the present disclosure. For instance, although it is described herein that the Non-RT RIC may be configured to generate and provide an energy-saving policy to the Near-RT RIC, it can be understood that any other suitable modules or entities in any suitable systems (e.g., O-RAN systems, 3 GPP systems, 5G systems, 6G systems, etc.) may be configured to generate or provide the policy to the Near-RT RIC, any other suitable modules or entities in any suitable systems maybe configured to receive the policy for utilization, and the like, without departing from the scope of the present disclosure.

[0022] It shall be noted that, descriptions of example embodiments of the present disclosure may include terms and names defined in one or more standard organizations, such as the 3rd Generation Partnership Project (3GPP) standard organization, the European Telecommunications Standards Institute (ETSI) standard organization, the Open Radio Access Network (O-RAN) Alliance standard organization, and the like. For instance, the terms “SMO”, “Non-RT RIC”, “Near-RT RIC”, “rApp”, “xApp”, “Fl interface”, “Al policy”, “E2SM”, “E2 interface”, “01 interface”, “02 interface”, “E2 node”, “SSB”, “SIBl”, “wake-up signal”, “PRACH”, and the like, as well as the associated features and operations, are to be interpreted as consistent with those specified in one or more technical specifications, unless being described otherwise.

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

[0024] On the other hand, network energy saving is an important aspect of 0-RAN in order to optimize energy efficiency, reduce operating costs, and minimize carbon footprint, while maintaining high network performance and ensuring high quality of service (QoS). In the related art, the concept of a policy-based carrier and cell switch off / on for energy saving has been introduced. Nevertheless, there is a growing need to further enhance energy-saving capabilities and opportunities by optimizing other network operations, particularly, network operations that periodically broadcast signals and / or communicate with the user equipment (UEs), such as the transmissions of synchronization signal blocks (SSBs), system information block 1 (SIB1), physical random access channel (PRACH), and wake-up signals. These network operations contribute significantly to network energy consumption, since these network operations typically involve signals broadcasting to multiple UEs or signals transmission in a way that allows multiple UEs to access the associated information or resources. For instance, SSB and SIB1 are typically broadcast periodically at fixed intervals, regardless of network conditions or energy-saving requirements, to provide synchronization and system information to the UEs. PRACH and wakeup signals may also be utilized or transmitted at fixed periodic transmissions regardless of network conditions or energy-saving requirements, to maintain readiness for user access and connectivity requirements. While these network operations are essential for ensuring seamless network functionality and user connectivity, their periodic nature can result in significant energy consumption, particularly during periods of low user activity or low network load conditions. Thus, there is a need to optimize the energy-saving capabilities and opportunities in these network operations.

[0025] In this regard, although the concept of policy-based energy saving has been introduced in the related art, the specific contents or parameters of the policies involved, and the specific mechanisms for provisioning and implementing such policies, are not specified or defined in the related art. In this regard, since entities from different vendors may be involved in the O- RAN architecture, it is crucial to define and specify the policies for energy saving, particularly policies associated with the management of SSB, SIB1, PRACH, and wake-up signals for energy saving, such that entities from different vendors can understand the policies and implement the policies accordingly for energy-saving purposes.

[0026] Example embodiments of the present disclosure provide a system, a method, a device, and the like that facilitate provisioning of network energy-saving enhancements. Specifically, example embodiments implement a Non-RT RIC to generate an energy-saving policy that contains new attributes and parameters, which supplement those specified for the policies in the current version of technical specifications provided by standard organizations like the 3 GPP and the 0-RAN Alliance. Further, example embodiments also introduce mechanisms to generate, transmit, manage, and utilize the energy-saving policy for implementing one or more energysaving operations, as well as to dynamically adjust or update the energy-saving policy based on real-time or near-real-time data (e.g., network performance, energy consumption status, etc.). Ultimately, example embodiments of the present disclosure may ensure that the energy-saving operations can be dynamically and adaptively configured, thereby enhancing and optimizing the energy-saving opportunities while maintaining the network performance.

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

[0028] FIG. 1 illustrates an O-RAN architecture 100 in which one or more example embodiments may be applied. As shown in FIG. 1, the system architecture 100 may include at least one Service Management and Orchestration (SMO) framework 110 that includes at least one non-real-time RAN Intelligent Controller (Non-RT RIC) 120, at least one near-real-time RIC (Near-RT RIC) 130, at least one O-RAN Central Unit (O-CU) 140, at least open evolved NodeB (O-eNB) 150, at least one O-RAN Distributed Unit (O-DU) 160, a plurality of O-RAN Radio Units (O-RUs) 170, and at least one O-RAN Cloud (O-Cloud) 180. It is contemplated that the system may include more / fewer components than illustrated, and / or may be configured in a different manner, without departing from the scope of the present disclosure. For instance, in some example implementations, the system architecture 100 may include a plurality of O-DUs 160 each of which may be communicatively coupled to the O-CU 140, and the like.

[0029] Generally, the O-RAN components (e.g., O-CU 140, O-DU 160, etc.) may be controlled or optimized by the Non-RT RIC 120 and the Near-RT RIC 130. In this regard, the Non-RT RIC 120 and the Near-RT RIC 130 may each be a software-defined component that implements one or more modular applications to facilitate multivendor operability, as well as to automate and optimize RAN operations. In the following, descriptions of the Non-RT RIC 120 are provided, followed by the descriptions of the Near-RT RIC 130.

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

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

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

[0033] According to example embodiments, the Non-RT RIC 120 (or the rApp 121 associated therewith) may be configured to generate and provide one or more policies to the Near- RT RIC 130 via the Al interface, and may be configured to manage one or more policies that are provided to the Near-RT RIC 130 over the Al interface. Thus, a policy that is provided by the Non-RT RIC 120 via the Al interface may also be referred to as an “Al policy” herein. Similarly, a policy that is associated with an energy-saving operation may be referred to as an “energy-saving policy”. Furthermore, since the policy may be implemented via the E2 interface of the O-RAN E2 Service Model (E2SM), said policy may also be referred to as an “E2SM policy”. Namely, an Al policy may include an energy-saving policy that may be implemented via the E2 interface, and thus the terms “policy”, “Al policy”, “energy-saving policy”, and “E2SM policy” may be used interchangeably herein.

[0034] The Non-RT RIC 120 (or the rApp 121 associated therewith) may create and provide the policies to the Near-RT RIC 130 for execution by the Near-RT RIC 130, thereby providing guidance to the Near-RT RIC 130 towards one or more objectives or goals defined in the RAN intent. The RAN intent may refer to the high-level operational or business goal(s) to be achieved by the RAN, which may be defined by one or more desired service level agreements (SLAs) that the RAN is to fulfill for all users or for a subset of users in a given area over at least a predefined period of time.

[0035] According to example embodiments, the policies may be declarative policies and / or imperative policies that contain information applicable to one or more network nodes (e.g., one or more UEs, one or more network cells, etc.). For instance, the policies may include declarative information focusing on providing guidance on the objective to be achieved by the policies, and / or declarative information defining the operations and conditions for triggering the operations toachieve the objective. Further descriptions associated with the example contents and parameters of an energy-saving policy are provided below with reference to Tables 1-9.

[0036] According to example embodiments, the Non-RT RIC 120 (or the rApp 121 associated therewith) may be configured to perform one or more policy management operations to provide and manage one or more policies. Specifically, the Non-RT RIC 120 (or the rApp 121 associated therewith) may be configured to generate, update, and delete one or more energy-saving policies. According to example embodiments, the Non-RT RIC 120 (or the rApp 121) may be configured to manage (e.g., generate, update, etc.) an energy-saving policy based on an associated policy schema. The policy schema may be defined by a user (e.g., a network operator) to define the structure, configuration, and content of the associated policy(s), and may be obtained by the Non-RT RIC 120 (or the rApp 121) from any suitable storage medium that stores the policy schema, when required.

[0037] According to example embodiments, the Non-RT RIC 120 (or the rApp 121 associated therewith) may be configured to receive, from the Near-RT RIC 130 viathe Al interface, one or more feedbacks associated with one or more policies (“Al policy feedback” herein). Similarly, the Non-RT RIC 120 (or the rApp 121 associated therewith) may be configured to receive one or more observables (e.g., events, counters, etc.) provided by the O-CU 140, the O- eNB 150, the 0-DU 160, and / or one or more of the O-RUs 170 over the 01 interface. Accordingly, the Non-RT RIC 120 (or the rApp 121 associated therewith) may be configured to continuously (or periodically) manage the one or more policies based on the Al policy feedback(s) and / or the observables provided over the 01 interface. For instance, the Non-RT RIC 120 (or the rApp 121 associated therewith) may continuously (or periodically) evaluate the impact or effectiveness of the one or more policies towards the fulfillment of the RAN intent and then configure or updatethe one or more policies accordingly. As further described below, the Non-RT RIC 120 and the Near-RT RIC 130 may interoperate to monitor the network conditions and / or performances after implementing one or more energy-saving operations (based on one or more energy-saving policies), and then dynamically adjust or configure the one or more energy-saving policies based on the real-time (or near-real-time) network conditions and / or performances. In this regard, it is contemplated that the Non-RT RIC 120 may obtain the information associated with the network conditions and / or performances in the form of Al policy feedback, observables provided over the 01 interface, and / or any other suitable monitoring mechanisms.

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

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

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

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

[0042] According to example embodiments, the Near-RT RIC 130 may be configured to execute one or more policies provided by the Non-RT RIC 120 and then perform one or more operations based thereon. Further, the Near-RT RIC 130 may monitor, suspend / stop, override, and control the E2 nodes via utilizing one or more policies. For example, the Near-RT RIC 130 may receive the one or more policies from the Non-RT RIC 120 (or the rApp 121 associated therewith), and then interpret the received policy(s) to determine one or more control operations and perform the control operation(s) thereafter. In this regard, upon receiving the policy(s), the Near-RT RIC 130 may collect one or more measurement data from one or more E2 nodes via the E2 interface, and then determine (e.g., by performing AI / ML inference based on the received policy(s) and the collected measurement data, etc.) the one or more control operations thereafter. According to example embodiments where the received policy(s) includes the imperative information, the Near- RT RIC 130 may simply follow the control operations defined or specified by the imperative information. Subsequently, the Near-RT RIC 130 may generate and send one or more control messages to one or more E2 nodes and / or one or more of the O-RUs 170 to thereby implementing the associated control operation(s). Accordingly, the E2 node(s) and / or the O-RU(s) may be configured to update their associated configurations to execute one or more operations according to the control messages provided by the Near-RIC 130. According to example embodiments where the policy(s) provided by the Non-RT RIC 120 includes an energy-saving policy(s), the Near-RT RIC 130 may perform or impalement energy-saving related operations based on the energy-saving policies, in a similar manner.

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

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

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

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

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

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

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

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

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

[0052] According to example embodiments, the components in the O-RAN architecture 100 (e.g., Non-RT RIC 120, Near-RT RIC 130, O-CU 140, O-DU 160, etc.) may interoperate with each other to provide network energy-saving enhancement. Specifically, the Non-RT RIC 120 (or the associated rApp 121) may manage long-term policies and strategies for energy savings, analyze historical data, optimize policy parameters (or decide to optimize the policy parameters), provide guidance / instructions to the Near-RT RIC 130 (or the associated xApp 131), provide instructions to the O-CU 140 and / or the O-DU 160, and the like. The Near-RT RIC 130 (or the associated xApp 131) may execute or implement one or more energy-saving operations based on real-time (or near-real-time) data and predefined / provided policies (e.g., instruct the O-CU 140 and / or the O-DU 160 to perform one or more energy-saving operations, etc.), monitor network conditions, execute control commands, adjust policy parameters according to the guidance / instructions of the Non-RT RIC 120 (or the associated rApp 121), and the like. The O-CU 140 may manage overall network control and coordination, receive instructions (e.g., policy instructions) from the Non-RT RIC 120 (or the associated rApp 121) and / or the Near-RT RIC 130 (or the associated xApp 131) and then coordinate with the O-DU 160 to implement one or more energy-saving operations, and the like. The O-DU 160 may execute low-level energy-saving operations as instructed by the Non-RT RIC 120 (or the associated rApp 121), the Near-RT RIC 130 (or the associated xApp 131), and / or the O-CU 140, implement adjustments to one or more energy-saving operations, and the like. The Fl interface may facilitate communication between the O-CU 140 and the O-DU 160, and may be utilized to transport control and configuration messages associated with one or more energy-saving operations. The E2 interface may facilitate communication between the Near-RT RIC 130 (or the associated xApp 131), the O-CU 140, and the O-DU 160 for real-time control and management, and may be utilized to transport control messages from the Near-RT RIC 130 (or the associated xApp 131) to the O-CU 140 and / or the O-DU 160 thereby enabling dynamic implementation and adjustment of energy-saving operations in near-real-time.

[0053] In view of the above, example embodiments of the present disclosure introduce a system for facilitating or provisioning network energy-saving enhancement in the 0-RAN. Specifically, the Non-RT RIC 120 may be utilized to generate an energy-saving policy that includes parameters or contents for dynamically implementing one or more energy-saving operations, and then provide the energy-saving policy to the Near-RT RIC 130 for execution. The Non-RT RIC 120 and the Near-RT RIC 130 may interoperate to dynamically and adaptive adjust the energy-saving policy, thereby enhancing the energy-saving opportunities while maintaining the network performance. Further details of the example energy-saving operations, as well as the associated energy-saving policy, are provided below.Example Network Operation Managements and Associated Policy

[0054] As described above with reference to FIG. 1, one or more energy saving-operations may be implemented based on one or more energy-saving policies to thereby enhancing network energy savings in a telecommunications network. In this regard, the energy-saving policy described herein may include information or parameters that outline methods and operations foroptimizing network energy consumption while maintaining / improving network performance. Further, the energy-saving policy may align with 3 GPP Rel-19 agreements for network energy savings and may integrate with the O-RAN E2 architecture.

[0055] According to example embodiments, the energy-saving policy may include an activation criteria, a user equipment (UE) capability requirement, a parameter associated with a policy decision, and a parameter defining an energy-saving operation. Further, the energy-saving operations may include at least one of: synchronization signal block (SSB) management, system information block 1 (SIB1) management, wake-up signal management, physical random access channel (PRACH) management, and a combination thereof. In the following, descriptions of several examples of energy-saving operations, the contents / parameters of the associated energysaving policy, and example use cases, are provided.Synchronization Signal Block (SSB) Management

[0056] SSB is a signal transmitted by the network (e.g., the base station) to provide synchronization and initial access information to the UEs. In the related art, the SSB is broadcast periodically across predefined beams within a synchronization raster, and the periodicity of SSB transmission is generally fixed regardless of network conditions and energy-saving requirements.

[0057] Example embodiments of the present disclosure enable the adjustment of the transmission intervals of the SSB, thereby achieving significant energy savings. Specifically, example embodiments provide an energy-saving policy for implementing compact SSB settings and dynamically adjusting the SSB configuration based on real-time (or near-real-time) data, such as network conditions, energy-saving requirements, and / or the like. The operation(s) associated with SSB configuration management / adjustment may be referred to herein as “compact SSB configuration”, “dynamic SSB adaptation”, “SSB management”, and any other suitableterminologies. An example energy-saving policy associated therewith is provided in the following Table 1.Table 1: Example Policy for Compact SSB Configuration

[0058] The policy name and policy description are presented in Table 1 for descriptive purposes and may be optional to (or may be excluded from) the energy-saving policy. Further, the presented policy ID is merely an example and may include any other suitable ID / terminologies.

[0059] As presented in Table 1, the parameter associated with the activation criteria may include: a parameter defining a time of a day (e.g., “off-peak”, etc.) at which the energy-savingoperation (i.e., compact SSB configuration) may be performed (labeled as “timeOfDay” in Table 1), a parameter (e.g., percentage, etc.) defining a network load of the current network or cell (labeled as “networkLoad” in Table 1), and a parameter (e.g., percentage, etc.) defining a minimum percentage of UEs in a cell that supports the energy-saving operation (labeled as “minUESupportPercentage” in Table 1). The activation criteria may define the condition(s) for activating the energy-saving policy and implementing the energy-saving operation (i.e., compact SSB configuration). For instance, one of, multiple of, or all of said parameters are required to be satisfied in order to activate the energy-saving policy.

[0060] The parameter associated with the UE capability requirement may include a parameter defining whether the UEs support the compact SSB configuration / dynamic SSB adaptation (labeled as “ueS SB AdaptationSupport” in Table 1), and a parameter defining the minimum percentage of the UEs in the cell that support the necessary features for the policy to activate (labeled as “minUESupportPercentage” in Table 1). The UE capability requirement may be utilized by the network to determine which UE(s) in the network / cell support the energy-saving operation (e.g., compact SSB configuration). In some example implementations, one or more parameters of the UE capability requirement may be similar to one or more parameters of the activation criteria.

[0061] The parameter associated with the policy decision may include one or more key performance indicators (KPIs) and / or one or more counters. For instance, in the example of Table 1, this parameter includes a parameter (e.g., percentage, etc.) defining a current network load (labeled as “networkLoad” in Table 1), a parameter (e.g., watts, etc.) defining an energy consumption of one or more network elements (labeled as “energyConsumption” in Table 1), a parameter (e.g., an integer, etc.) defining a number of UEs supporting the energy-saving operation(labeled as “ueSupportCount” in Table 1), a parameter (e.g., Mbps, etc.) defining an average throughput per UE (labeled as “averageThroughput” in Table 1), a parameter (e.g., milliseconds, etc.) defining an average latency in the network (labeled as “averageLatency” in Table 1), and a parameter (e g., percentage, etc.) defining a packet error rate (labeled as “packetErrorRate” in Table 1). At least a portion of said parameters may be monitored before, during, and / or after the implementation of the energy-saving operation. In some example implementations, one or more parameters associated with the policy decision may be similar to one or more parameters of the activation criteria.

[0062] In the example of Table 1, the parameter defining the energy-saving operation (labeled as “Compact SSB Configuration Parameters” in Table 1) may include a parameter (e.g., milliseconds, etc.) associated with the periodicity of SSB bursts or SSB transmission (labeled as “ssbPeriodicity” in Table 1), a parameter (e.g., an integer, etc.) associated with the power offset for SSB transmission (labeled as “ssbPowerControlOffset” in Table 1), a parameter (e.g., milliseconds, etc.) associated with a duration for updating an SSB configuration (labeled as “ssbConfigUpdatePeriod” in Table 1), and a parameter (e.g., Boolean, etc.) associated with a state (e.g., enabled state, disabled state, etc.) of dynamic SSB configuration (labeled as “dynamics SBConfigEnabled” in Table 1). These parameters may also be referred to herein as “SSB settings”, “SSB configurations”, and the like. Further, these parameters may be initially defined by the network operator and dynamically updated (by the Non-RT RIC, the Near-RT RIC, etc.) based on real-time or near-real-time network conditions and requirements.

[0063] According to example embodiments, the procedure or operation of the compactSSB configuration may include: (1) implementing the compact SSB configuration during a specified low-traffic period, (2) monitoring network performance after implementing the compactSSB configuration, and (3) adjusting the compact SSB configuration based on the monitored network performance.

[0064] Step (1) may include one or more operations where the Non-RT RIC 120 (or the associated rApp 121) and / or the Near-RT RIC 130 (or the associated xApp 131) may create, integrate, and / or apply configuration profiles that define the compact SSB settings (e.g., the SSB transmission periodicity, power offset for SSB transmission, etc.) and apply the compact SSB settings based on the configuration profiles. Further, step (1) may also include one or more operations where the compact SSB settings are scheduled and implemented during specific network conditions. For instance, one or more E2 nodes may be set (via the E2 interface by the Near-RT RIC 130 or the associated xApp 131) to implement or use the compact SSB settings during specific low-traffic periods.

[0065] Step (2) may include one or more operations where the Non-RT RIC 120 (or the associated rApp 121) and / or the Near-RT RIC 130 (orthe associated xApp 131) may continuously monitor or track network performance. For instance, the Non-RT RIC 120 (or the associated rApp 121) and / or the Near-RT RIC 130 (or the associated xApp 131) may gather, from the E2 nodes, network performance / condition data (such as those defined in the KPIs of the energy-saving policy). In some example embodiments, the Near-RT RIC 130 (or the associated xApp 131) may gather, from the E2 nodes via the E2 interface, the network data and then provide the same to the Non-RT RIC 120 (or the associated rApp 121) via the Al interface. Additionally or alternatively, Non-RT RIC 120 (or the associated rApp 121) may gather the network data from the E2 nodes via the 01 interface. These network data may define the effectiveness of the energy-saving operations and the associated impact on the network performance (if any).

[0066] Step (3) may include one or more operations where the Non-RT RIC 120 (or the associated rApp 121) and / or the Near-RT RIC 130 (or the associated xApp 131) may make necessary adjustments on the energy-saving polices to maintain or optimize network performance / quality and / or energy-saving effectiveness. For instance, the Non-RT RIC 120 (or the associated rApp 121) may determine, based on the network data, that the compact SSB configurations can be (or should be) adjusted to achieve an energy-saving target while maintaining the network performance. Accordingly, the Non-RT RIC 120 (or the associated rApp 121) may provide (via the Al interface) a guidance / instruction to the Near-RT RIC 130 (or the associated xApp 131) thereby guiding / instructing the Near-RT RIC 130 (or the associated xApp 131) to perform real-time (or near-real-time) adjustments on the energy-saving policy. Subsequently, the Near-RT RIC 130 (or the associated xApp 131) may determine, based on real-time network data, one or more parameters (e.g., SSB transmission periodicity, SSB transmission power offset, etc.) to be adjusted, and then instruct (via the E2 interface) the O-CU 140 and / or the O-DU 160 to implement the adjustments on the one or more determined parameters. In some additional or alternative implementations, the Non-RT RIC 120 (or the associated rApp 121) may determine one or more parameters to be adjusted and directly provide (via the 01 interface) a guidance / instruction to the O-CU 140 and / or the O-DU 160 to implement the adjustments on the one or more determined parameters.

[0067] In view of the above, example embodiments may integrate the settings and parameters for dynamic and compact SSB configuration / adjustment in an energy-saving policy for granular and efficient energy savings. Further, example embodiments may implement the dynamic and compact SSB configuration / adjustment based on real-time or near-real-time data (e.g., network conditions, energy-saving requirements, etc ), thereby ensuring optimal networkperformance and energy-savings. Furthermore, example embodiments may leverage capabilities and functionalities of the O-RAN components (e.g., Non-RT RIC, Near-RT RIC, etc.) to seamlessly integrate the dynamic / compact SSB configuration / adjustment within any telecommunications network based on the O-RAN architecture. In addition, example embodiments may leverage the advanced UE capabilities for implementing the dynamic / compact SSB configuration / adjustment, thereby ensuring broader applicability and higher efficiency.System Information Block 1 (SIB 1 ) Management

[0068] SIB1 is a message / signal that contains essential system information required by UEs for network access and connectivity. Specifically, after the initial synchronization of UE with the network, the UE may start listening to SIB 1 which carries cell access-related information. SIB 1 may be broadcasted periodically via the physical downlink shared channel (PDSCH). In the related art, the SIB1 transmission is performed periodically according to predefined intervals (e.g., every 80ms, etc.) regardless of the network conditions and energy-saving requirements.

[0069] Example embodiments of the present disclosure dynamically transmit or request the SIB1 transmissions based on real-time or near-real-time network conditions or requirements, thereby avoiding continuous SIB1 broadcasting and reducing energy consumption. Specifically, example embodiments provide an energy-saving policy for transmitting SIB1 based on real-time (or near-real-time) requirements and dynamically adjusting the SIB1 transmission based on realtime (or near-real-time) data, such as network conditions / performances, energy-saving requirements, and / or the like. The SIB1 transmission, according to one or more example embodiments, may be referred to herein as “on-demand SIB1 transmission”, “dynamic SIB1 transmission”, and any other suitable terminologies. An example energy-saving policy associated therewith is provided in the following Table 2.Table 2: Example Policy for On-Demand SB1 Transmission

[0070] One or more parameters in Table 2 may be similar to those presented in Table 1. Namely, the energy-saving policy associated with S1B1 management (e.g., on-demand SIB I transmission) may include one or more parameters similar to the energy-saving policy associated with SSB management (e.g., compact SSB configuration). Thus, redundant descriptions associated therewith may be omitted below for conciseness.

[0071] The policy name and policy description are presented in Table 2 for descriptive purposes and may be optional to (or may be excluded from) the energy-saving policy. Further, the presented policy ID is merely an example and may include any other suitable ID / terminologies.

[0072] Similar to the energy-saving policy in Table 1, the parameter associated with the activation criteria of the energy-saving policy in Table 2 may include a parameter defining a time of a day (e.g., “off-peak”, etc.) at which the energy-saving operation (i.e., compact SSB configuration) may be performed (labeled as “timeOfDay” in Table 2), a parameter (e.g., percentage, etc.) defining a network load of the current network or cell (labeled as “networkLoad” in Table 2), and a parameter (e.g., percentage, etc.) defining a minimum percentage of UEs in a cell that supports the energy-saving operation (labeled as “minUESupportPercentage” in Table 2). The activation criteria may define the condition(s) for activating the energy-saving policy and implementing the energy-saving operation (i.e., on-demand SIB1 transmission). For instance, one of, multiple of, or all of said parameters are required to be satisfied in order to activate the energysaving policy.

[0073] In addition, similar to the energy-saving policy in Table 1, the parameter associated with the UE capability requirement of the energy-saving policy in Table 2 may include a parameter defining the minimum percentage of the UEs in the cell that support the necessary features for the policy to activate (labeled as “minUESupportPercentage” in Table 2). Further, the UE capability requirement in Table 2 may also include a parameter defining whether the UEs support on-demand SIB1 transmissions (labeled as “ueSIBlOnDemandSupport” in Table 2). The UE capability requirement may be utilized by the network to determine which UE(s) in the network / cell support the energy-saving operation (e.g., on-demand SIB1 transmission). In some exampleimplementations, one or more parameters of the UE capability requirement may be similar to one or more parameters of the activation criteria.

[0074] The parameter associated with the policy decision in Table 2 may include one or more KPIs and / or one or more counters similar to those described in Table 1. For instance, in the example of Table 2, this parameter includes a parameter (e.g., percentage, etc.) defining a current network load (labeled as “networkLoad” in Table 2), a parameter (e.g., watts, etc.) defining an energy consumption of one or more network elements (labeled as “energyConsumption” in Table 2), a parameter (e.g., an integer, etc.) defining a number of UEs supporting the energy-saving operation (labeled as “ueSupportCount” in Table 2), a parameter (e.g., Mbps, etc.) defining an average throughput per UE (labeled as “averageThroughput” in Table 2), a parameter (e.g., milliseconds, etc.) defining an average latency in the network (labeled as “averageLatency” in Table 2), and a parameter (e.g., percentage, etc.) defining a packet error rate (labeled as “packetErrorRate” in Table 2). At least a portion of said parameters may be monitored before, during, and / or after the implementation of the energy-saving operation. In some example implementations, one or more parameters associated with the policy decision may be similar to one or more parameters of the activation criteria.

[0075] In the example of Table 2, the parameter defining the energy-saving operation (labeled as “On-Demand SIB1 Transmission Parameters” in Table 2) may include a parameter (e.g., milliseconds, etc.) associated with the interval for SIB1 transmission (labeled as “sib 1 Transmissioninterval” in Table 2), a parameter (e.g., an integer, etc.) associated with the power offset for SIB1 transmission (labeled as “siblPowerControlOffset” in Table 2), and a parameter (e.g., Boolean, etc.) associated with a state (e.g., enabled state, disabled state, etc.) of dynamic SIB1 transmission (labeled as “dynamicSIBITransmissionEnabled” in Table 2). Theseparameters may also be referred to herein as “SIB1 settings”, “SIB1 configurations”, and the like. Further, these parameters may be initially defined by the network operator and dynamically updated (by the Non-RT RIC, the Near-RT RIC, etc.) based on real-time or near-real-time network conditions and requirements.

[0076] According to example embodiments, the procedure or operation of the on-demand SIB1 transmission may include: (1) determining the need for SIB1 broadcasting, (2) triggering SIB1 transmission based on the result of the determining, (3) monitoring network performance after the triggering, and (4) adjusting the SIB1 transmission based on the monitored network performance.

[0077] Step (1) may include one or more operations where the Non-RT RIC 120 (or the associated rApp 121) and / or the Near-RT RIC 130 (or the associated xApp 131) may obtain network and / or UE data, such as network events, UE state information, and the like, to determine the need for S1B1 broadcasting or identify when the UE(s) need the SIB1 information.

[0078] Step (2) may include one or more operations where the Non-RT RIC 120 (or the associated rApp 121) and / or the Near-RT RIC 130 (or the associated xApp 131) may implement the on-demand SIB1 transmission based on determining that there is a need for SIB1 broadcasting / transmission. For instance, the Near-RT RIC 130 (or the associated xApp 131) may dynamically trigger the SIB 1 transmission based on the need identified or determined in real-time (or near-real-time), and instruct / request one or more E2 nodes (via the E2 interface) to broadcast / transmit the SIB 1.

[0079] Step (3) may include one or more operations where the Non-RT RIC 120 (or the associated rApp 121) and / or the Near-RT RIC 130 (or the associated xApp 131) may continuously monitor or track network performance after triggering the on-demand SIB1 transmission. Forinstance, the Non-RT RIC 120 (or the associated rApp 121) and / or the Near-RT RIC 130 (or the associated xApp 131) may gather, from the E2 nodes, network performance / condition data (such as those defined in the KPIs of the energy-saving policy). The Near-RT RIC 130 (or the associated xApp 131) may gather, from the E2 nodes via the E2 interface, the network data and then provide the same to the Non-RT RIC 120 (or the associated rApp 121) via the Al interface. Additionally or alternatively, the Non-RT RIC 120 (or the associated rApp 121) may gather the network data from the E2 nodes via the 01 interface. These network data may define the effectiveness of the energy-saving operations and the associated impact on the network performance (if any).

[0080] Step (4) may include one or more operations where the Non-RT RIC 120 (or the associated rApp 121) and / or the Near-RT RIC 130 (or the associated xApp 131) may make necessary adjustments on the energy-saving policy to maintain or optimize the network performance / quality and / or energy-saving effectiveness. For instance, the Non-RT RIC 120 (or the associated rApp 121) may determine, based on the network data, that the S1B1 configurations can be (or should be) adjusted to achieve an energy-saving target while maintaining the network performance. Accordingly, the Non-RT RIC 120 (or the associated rApp 121) may provide (via the Al interface) guidance / instruction to the Near-RT RIC 130 (or the associated xApp 131) thereby guiding / instructing the Near-RT RIC 130 (or the associated xApp 131) to perform realtime (or near-real-time) adjustments on the energy-saving policy. Subsequently, the Near-RT RIC 130 (or the associated xApp 131) may determine, based on real-time network data, one or more parameters (e.g., SIB1 transmission interval, SIB1 transmission power offset, etc.) to be adjusted, and then instruct (via the E2 interface) the O-CU 140 and / or the 0-DU 160 to implement the adjustments on the one or more determined parameters. In some additional or alternative implementations, the Non-RT RIC 120 (or the associated rApp 121) may determine one or moreparameters to be adjusted and directly provide (via the 01 interface) guidance / instruction to the 0-CU 140 and / or the 0-DU 160 to implement the adjustments on the one or more determined parameters.

[0081] In view of the above, example embodiments may integrate the settings and parameters for dynamic / on-demand SIB1 transmission / adjustment in an energy-saving policy for granular and efficient energy savings. Further, example embodiments may implement the dynamic / on-demand SIB 1 transmission / adjustment based on real-time or near-real-time data (e.g., network conditions, energy-saving requirements, etc.), thereby ensuring optimal network performance and energy-savings. Furthermore, example embodiments may leverage capabilities and functionalities of the 0-RAN components (e g., Non-RT RIC, Near-RT RIC, etc.) to seamlessly integrate the dynamic / on-demand SIB1 transmission / adjustment within any telecommunications network based on the 0-RAN architecture. In addition, example embodiments may leverage the advanced UE capabilities for implementing the dynamic / on-demand S1B1 transmission / adjustment, thereby ensuring broader applicability and higher efficiency.Wake-Up Signal Management

[0082] Wake-up signals may refer to the signals transmitted on a periodic basis to notify UEs in idle or low-power states to wake up for potential communication activities. In the related art, the wake-up signals are transmitted on predefined intervals or events (e.g., during the off- duration of a discontinuous reception (DRX) cycle where the UE(s) is in the low-power state, etc.), regardless of the network conditions and energy-saving requirements.

[0083] Example embodiments of the present disclosure enable the adjustment of the transmission of the wake-up signals. Specifically, example embodiments provide an energy-saving policy for transmitting the wake-up signals and dynamically adjusting the wake-up signalconfiguration based on real-time or near-real-time data, such as network conditions / performances, energy-saving requirements, and the like. The operation(s) associated with wake-up signal configuration management / adjustment may be referred to herein as “wake-up signal configuration”, “dynamic wake-up signal adaptation”, “wake-up signal management”, and any other suitable terminologies. An example energy-saving policy associated therewith is provided in the following Table 3.Table 3: Example Policy for Wake-Up Signal Configuration

[0084] One or more parameters in Table 3 may be similar to those presented in Table 1 and Table 2. Namely, the energy-saving policy associated with wake-up signal management (e.g., on-wake-up signal configuration) may include one or more parameters similar to the energy-saving policy associated with SSB management (e.g., compact SSB configuration) and the energy-saving policy associated with SIB1 management (e.g., on-demand SIB1 transmission). Thus, redundant descriptions associated therewith may be omitted below for conciseness.

[0085] The policy name and policy description are presented in Table 3 for descriptive purposes and may be optional to (or may be excluded from) the energy-saving policy. Further, the presented policy ID is merely an example and may include any other suitable ID / terminologies.

[0086] Similar to the energy-saving policies in Table 1 and Table 2, the parameter associated with the activation criteria of the energy-saving policy in Table 3 may include a parameter defining a time of a day (e.g., “off-peak”, etc.) at which the energy-saving operation (i.e., wake-up signal configuration) may be performed (labeled as “timeOfDay” in Table 3), a parameter (e.g., percentage, etc.) defining a network load of the current network or cell (labeled as “networkLoad” in Table 3), and a parameter (e.g., percentage, etc.) defining a minimum percentage of UEs in a cell that supports the energy-saving operation (labeled as “minUESupportPercentage” in Table 3). The activation criteria may define the condition(s) for activating the energy-saving policy and implementing the energy-saving operation (i.e., wake-up signal configuration). For instance, one of, multiple of, or all of said parameters are required to be satisfied in order to activate the energy-saving policy.

[0087] In addition, similar to the energy-saving policies in Table 1 and Table 2, the parameter associated with the UE capability requirement of the energy-saving policy in Table 3 may include a parameter defining the minimum percentage of the UEs in the cell that support thenecessary features for the policy to activate (labeled as “minUESupportPercentage” in Table 3). Further, the UE capability requirement in Table 3 may also include a parameter defining whether the UEs support wake-up signal configuration (labeled as “ueWakeUpSignalSupport” in Table 3). The UE capability requirement may be utilized by the network to determine which UE(s) in the network / cell support the energy-saving operation (e.g., wake-up signal configuration). In some example implementations, one or more parameters of the UE capability requirement may be similar to one or more parameters of the activation criteria.

[0088] Further, the parameter associated with the policy decision in Table 3 may include one or more KPIs and / or one or more counters similar to those described in Table 1 and Table 2. For instance, in the example of Table 3, this parameter includes a parameter (e.g., percentage, etc.) defining a current network load (labeled as “networkLoad” in Table 3), a parameter (e g., watts, etc.) defining an energy consumption of one or more network elements (labeled as “energyConsumption” in Table 3), a parameter (e.g., an integer, etc.) defining a number of UEs supporting the energy-saving operation (labeled as “ueSupportCount” in Table 3), a parameter (e.g., Mbps, etc.) defining an average throughput per UE (labeled as “averageThroughput” in Table 3), a parameter (e.g., milliseconds, etc.) defining an average latency in the network (labeled as “averageLatency” in Table 3), and a parameter (e.g., percentage, etc.) defining a packet error rate (labeled as “packetErrorRate” in Table 3). At least a portion of said parameters may be monitored before, during, and / or after the implementation of the energy-saving operation. In some example implementations, one or more parameters associated with the policy decision may be similar to one or more parameters of the activation criteria.

[0089] In the example of Table 3, the parameter defining the energy-saving operation(labeled as “Wake-up Signal Configuration Parameters” in Table 3) may include a parameter (e.g.,milliseconds, etc.) associated with the periodicity of wake-up signal transmission (labeled as “wakeUpSignalPeriodicity” in Table 3), a parameter (e.g., an integer, etc.) associated with the power offset for wake-up signal transmission (labeled as “wakeUpSignalPowerControlOffsef ’ in Table 3), and a parameter (e.g., Boolean, etc.) associated with a state (e g., enabled state, disabled state, etc.) of dynamic wake-up signal configuration (labeled as “dynamicWakeUpSignalEnabled” in Table 3). These parameters may also be referred to herein as “wake-up signal settings”, “wakeup signal configurations”, and the like. Further, these parameters may be initially defined by the network operator and dynamically updated (by the Non-RT RIC, the Near-RT RIC, etc.) based on real-time network conditions and requirements.

[0090] According to example embodiments, the procedure or operation of the wake-up signal configuration may include: (1) determining a current network load, (2) implementing a predefined wake-up signal configuration based on the current network load (the predefined wakeup signal configuration may be provided by the network operator, may be determined by the Non- RT RIC 120 (or the associated rApp 121), may be defined by a current version of energy-saving policy, and the like), (3) monitoring network performance after the implementing, and (4) adjusting the predefined wake-up signal configuration based on the monitored network performance.

[0091] In view of the above, example embodiments may integrate the settings and parameters for dynamic wake-up signal configuration / adjustment in an energy-saving policy for granular and efficient energy savings. Further, example embodiments may implement the dynamic wake-up signal configuration / adjustment based on real-time or near-real-time data (e.g., network conditions, energy-saving requirements, etc.), thereby ensuring optimal network performance and energy-savings. Furthermore, example embodiments may leverage capabilities and functionalitiesof the O-RAN components (e.g., Non-RT RIC, Near-RT RIC, etc.) to seamlessly integrate the dynamic wake-up signal configuration / adjustment within any telecommunications network based on the O-RAN architecture. In addition, example embodiments may leverage the advanced UE capabilities for implementing the dynamic wake-up signal configuration / adjustment, thereby ensuring broader applicability and higher efficiency.Physical Random Access Channel (PRACH) Management

[0092] PRACH transmissions typically occur when UEs perform the random access procedure, such as during initial access, handover, or re-establishing a connection. In the related art, PRACH configurations, including the preamble format, time / frequency resources, and periodicity, are predefined and broadcast regardless of the network conditions and energy-saving requirements.

[0093] Example embodiments of the present disclosure enable the adjustment of the PRACH configurations. Specifically, example embodiments provide an energy-saving policy for dynamically configuring one or more PRACH configurations in the time domain and / or spatial domain, based on real-time or near-real-time data, such as network conditions / performance, energy-saving requirements, and the like. The operation(s) associated with PRACH configurations managem ent / adjustment may be referred to herein as “PRACH configuration”, “dynamic PRACH configuration”, “adaptive PRACH configuration”, “PRACH management”, and any other suitable terminologies. An example energy-saving policy associated therewith is provided in the following Table 4.Table 4: Example Policy for Dynamic PRACH Configuration

[0094] One or more parameters in Table 4 may be similar to those presented in Tables 1- 3. Namely, the energy-saving policy associated with PRACH management (e.g., dynamic PRACH configuration) may include one or more parameters similar to the energy-saving policy associated with SSB management (e.g., compact SSB configuration), the energy-saving policy associated with SIB1 management (e.g., on-demand SIB1 transmission), and the energy-saving policy associated with wake-up signal management (e.g., wake-up signal configuration). Thus, redundant descriptions associated therewith may be omitted below for conciseness.

[0095] The policy name and policy description are presented in Table 4 for descriptive purposes and may be optional to (or may be excluded from) the energy-saving policy. Further, the presented policy ID is merely an example and may include any other suitable ID / terminologies.

[0096] Similar to the energy-saving policies in Tables 1-3, the parameter associated with the activation criteria of the energy policy in Table 4 may include a parameter defining a time of a day (e.g., “off-peak”, etc.) at which the energy-saving operation (i.e., dynamic PRACH configuration) may be performed (labeled as “timeOfDay” in Table 4), a parameter (e.g., percentage, etc.) defining a network load of the current network or cell (labeled as “networkLoad” in Table 4), and a parameter (e.g., percentage, etc.) defining a minimum percentage of UEs in a cell that supports the energy-saving operation (labeled as “minUESupportPercentage” in Table 4). The activation criteria may define the condition(s) for activating the energy-saving policy and implementing the energy-saving operation (i.e., dynamic PRACH configuration). For instance, one of, multiple of, or all of said parameters are required to be satisfied in order to activate the energy-saving policy.

[0097] In addition, similar to the energy-saving policies in Tables 1-3, the parameter associated with the UE capability requirement of the energy policy in Table 4 may include a parameter defining the minimum percentage of the UEs in the cell that support the necessary features for the policy to activate (labeled as “minUESupportPercentage” in Table 4). Further, the UE capability requirement in Table 4 may also include a parameter defining whether the UEs support dynamic PRACH configuration (labeled as “uePRACHAdaptationSupport” in Table 4). The UE capability requirement may be utilized by the network to determine which UE(s) in the network / cell support the energy-saving operation (e.g., dynamic PRACH configuration). In someexample implementations, one or more parameters of the UE capability requirement may be similar to one or more parameters of the activation criteria.

[0098] Further, the parameter associated with the policy decision in Table 3 may include one or more KPIs and / or one or more counters similar to those described in Tables 1-3. For instance, in the example of Table 4, this parameter includes a parameter (e.g., percentage, etc.) defining a current network load (labeled as “networkLoad” in Table 4), a parameter (e.g., watts, etc.) defining an energy consumption of one or more network elements (labeled as “energyConsumption” in Table 4), a parameter (e.g., an integer, etc.) defining a number of UEs supporting the energy-saving operation (labeled as “ueSupportCount” in Table 4), a parameter (e.g., Mbps, etc.) defining an average throughput per UE (labeled as “averageThroughput” in Table 4), a parameter (e.g., milliseconds, etc.) defining an average latency in the network (labeled as “averageLatency” in Table 4), and a parameter (e.g., percentage, etc.) defining a packet error rate (labeled as “packetErrorRate” in Table 4). At least a portion of said parameters may be monitored before, during, and / or after the implementation of the energy-saving operation. In some example implementations, one or more parameters associated with the policy decision may be similar to one or more parameters of the activation criteria.

[0099] In the example of Table 4, the parameter defining the energy-saving operation (labeled as “PRACH Configuration Parameters” in Table 4) may include a parameter (e.g., milliseconds, etc.) associated with the periodicity of PRACH transmission (labeled as “prachPeriodicity” in Table 4), a parameter (e.g., an integer, etc.) associated with the power offset for PRACH transmission (labeled as “prachPowerControlOffset” in Table 4), a parameter (e.g., Boolean, etc.) associated with a state (e.g., enabled state, disabled state, etc.) of dynamic PRACH configuration (labeled as “dynamicPRACHConfigEnabled” in Table 4), and a parameter (e.g.,Boolean, etc.) associated with a state (e.g., enabled state, disabled state, etc.) of non-uniform PRACH resource allocation per SSB (labeled as “nonUniformPRACHResources” in Table 4). These parameters may also be referred to herein as “PRACH settings”, “PRACH configurations”, and the like. Further, these parameters may be initially defined by the network operator and dynamically updated (by the Non-RT RIC, the Near-RT RIC, etc.) based on real-time network conditions and requirements.

[0100] According to example embodiments, the procedure or operation of the wake-up signal configuration may include: (1) determining a current network load, (2) implementing a predefined PRACH configuration based on the current network load (the predefined PRACH configuration may be provided by the network operator, may be determined by the Non-RT RIC 120 (or the associated rApp 121), may be defined by a current version of energy-saving policy, and the like), (3) monitoring network performance after the implementing, and (4) adjusting the predefined PRACH configuration based on the monitored network performance.

[0101] In view of the above, example embodiments may integrate the settings and parameters for dynamic PRACH configuration / adjustment / adaptation in an energy-saving policy for granular and efficient energy savings. Further, example embodiments may implement the dynamic PRACH configuration / adjustment / adaptation based on real-time or near-real-time data (e g., network conditions, energy-saving requirements, etc.), thereby ensuring optimal network performance and energy-savings. Furthermore, example embodiments may leverage capabilities and functionalities of the O-RAN components (e g., Non-RT RIC, Near-RT RIC, etc.) to seamlessly integrate the dynamic PRACH configuration / adjustment / adaptation within any telecommunications network based on the O-RAN architecture. In addition, example embodimentsmay leverage the advanced UE capabilities for implementing the dynamic PRACH configured on / adjustm ent / adaptation, thereby ensuring broader applicability and higher efficiency. Example Combinations

[0102] According to example embodiments, the parameters associated with multiple energy-saving operations may be included in a single energy-saving policy. In the following, several example policies (that include parameters of multiple energy-saving operations) are described.

[0103] According to example embodiments, the parameters associated with dynamic SSB and SIB1 adjustments may be included in a single policy. An example policy is presented in the following Table 5.Table 5: Example Policy for Compact SSB Configuration and On-Demand SIB1 Transmission

[0104] The parameters of the policy in Table 5 may be similar to those in Tables 1-2. Thus, redundant descriptions associated therewith may be omitted below for conciseness.

[0105] According to example embodiments, the parameters associated with the common si nal / channel (e.g., SSB and PRACH) may be included in a single policy. An example policy is presented in the following Table 6.Table 6: Example Policy for Common Signal / Channel Adaptations

[0106] The parameters of the policy in Table 6 may be similar to those in Tables 3-4. Thus, redundant descriptions associated therewith may be omitted below for conciseness.

[0107] According to example embodiments, the parameters associated with wake-up signal configuration and the common signal / channel (e.g., SSB and PRACH) may be included in a single policy. An example policy is presented in the following Table 7.Table 7: Example Policy for Wake-Up Signal Configuration & Common Signal / Channel Adaptation

[0108] The parameters of the policy in Table 7 may be similar to those in Tables 3 and 6.Thus, redundant descriptions associated therewith may be omitted below for conciseness.

[0109] In view of the above, example embodiments may integrate the settings and parameters of multiple energy-saving operations in a single energy-saving policy for granular andefficient energy savings. Further, example embodiments may implement multiple energy-saving operations based on real-time or near-real-time data (e.g., network conditions, energy-saving requirements, etc.), thereby ensuring optimal network performance and energy-savings. Furthermore, example embodiments may leverage capabilities and functionalities of the O-RAN components (e.g., Non-RT RIC, Near-RT RIC, etc.) to seamlessly integrate multiple energy-saving operations within any telecommunications network based on the O-RAN architecture. In addition, example embodiments may leverage the advanced UE capabilities for implementing multiple energy-saving operations, thereby ensuring broader applicability and higher efficiency.Example Use Cases

[0110] It is contemplated that the contents and parameters in the above-mentioned Tables 1-7 are merely examples and the energy-saving policy may include more / less contents or parameters, the parameters may include other suitable terminologies, and the like, without departing from the scope of the present disclosure. For instance, in some example implementations, the policy may include additional contents or parameters, such as a target network condition, an energy-saving requirement / target, information of associated policy, different KPIs to monitor and / or make a policy decision, and the like. On the other hand, in some example implementations, the policy may include less content, e g., less KPIs to monitor may be included, the UE requirement may be excluded, and the like. Descriptions of example policies associated with several example use cases, according to one or more example embodiments, are provided in the following.

[0111] Below Table 8 presents an example policy associated with a first example use case, which demonstrates dynamic adjustments in SSB configurations and on-demand SIBl transmissions to achieve energy savings during periods of low network load. This first use caseshowcases the integration of control mechanisms and dynamic adjustments within the O-RAN framework, according to one or more example embodiments.Table 8: Example Policy of First Use Case

[0112] The policy in Table 8 includes one or more param eters / contents similar to those in Table 5. The policy in Table 8 is different from the policy in Table 5 in that, Table 8 includes an additional parameter associated with a target network condition and excludes some parameters of Table 5 (e.g., excluding the UE capabilities requirements, etc.).

[0113] In the first example use case, the policy is implemented to enhance energy-saving opportunities when there is low user activity during off-peak hours. In this regard, the policy may be activated during off-peak hours of the day, when the network load is equal to or lower than 20%, and at least 80% of UEs in the network cell support both the compact SSB configuration and on-demand SIB1 transmission.

[0114] When the policy is activated, the Non-RT RIC 120 (or the associated rApp 121) and the Near-RT RIC 130 (or the associated xApp 131) may be configured to interoperate witheach other to implement the energy-saving operations defined in the policy. For instance, the Non- RT RIC 120 (or the associated rApp 121) may deploy the policy to enable dynamic SSB and SIB1 adjustment, and communicate (or instruct the Near-RT RIC 130 / xApp 131 to communicate) with the associated network elements (e.g., control elements, E2 nodes, etc.) to set up the necessary parameters for SSB and SIB1 adjustments.

[0115] In this example use case, the features of dynamic SSB configuration are enabled to configure / adjust the periodicity of the SSB transmission to 40ms and configure / adjust the power offset for SSB transmission to -5dB (i.e., reducing the SSB transmission power by 5dB relative to a reference power level), thereby reducing the power consumption and optimizing the energysavings opportunities. In addition, the features of dynamic SIB1 transmission are enabled to configure / adjust the interval for SIB1 transmission to 500ms and configure / adjust the power offset for SIB1 transmission to -5dB (i.e., reducing the SIB1 transmission power by 5dB relative to a reference power level), thereby further reducing the power consumption and further optimizing the energy-savings opportunities.

[0116] Upon implementing the energy-saving operations and configuring the SSB and SIB1 according to the policy, the Non-RT RIC 120 (or the associated rApp 121) and / or the Near- RT RIC 130 (or the associated xApp 131) may be configured to continuously (or periodically) monitor the network conditions to determine whether the implementation of the energy-saving operations maintain / degrade the network performances, satisfy / below the energy-saving target, and the like. For instance, in this example use case, the Non-RT RIC 120 (or the associated rApp 121) and / or the Near-RT RIC 130 (or the associated xApp 131) may be configured to collect data associated with energy consumption of the network / cell (or network elements associated therewith) and analyze the data to determine the network energy status based thereon. In addition, the Non-RT RIC 120 (or the associated rApp 121) and / or the Near-RT RIC 130 (or the associated xApp 131) may be configured to collect data associated with the average throughput, average latency, and packet error rate, and then analyze the data to determine the network performance based thereon.

[0117] Upon determining that there is a need to adjust the energy-saving operation(s), e.g., the network energy does not satisfy the energy-saving target and / or the network performance is degraded or below a predefined threshold, the Non-RT RIC 120 (or the associated rApp 121) and / or the Near-RT RIC 130 (or the associated xApp 131) may interoperate to adjust the energysaving operation(s). For instance, the Non-RT RIC 120 (or the associated rApp 121) may determine which policy (or which parameter(s) associated therewith) may be adjusted to satisfy the intended energy-saving target and / or network performance, and then instruct / provide guidance to the Near-RT RIC 130 (or the associated xApp 131) and / or the associated network elements (e.g.,E2 nodes). Accordingly, the Near-RT RIC 130 (or the associated xApp 131) and / or the associated network elements may adjust the policy / associated parameters (e g., SSB configuration parameters,SIB1 configuration parameters, etc.) based on the instruct! on / guidance provided by the Non-RTRIC 120 (or the associated rApp 121).

[0118] Table 9 in the following presents an example policy associated with a second example use case, which demonstrates dynamic adjustments in wake-up signal configurations and common signal / channel transmissions (SSB and PRACH) to achieve significant energy savings during periods of low network load. This second example use case illustrates the integration of control mechanisms and dynamic adjustments within the 0-RAN framework, according to one or more example embodiments.Table 9: Example Policy of Second Use CaseNetwork Condition: Low user activity during off-peak hours

[0119] The policy in Table 9 includes one or more parameters / contents similar to those presented in Table 7. The policy in Table 9 is different from the policy in Table 7 in that, Table 9 includes an additional parameter associated with a target network condition and excludes some parameters of Table 7 (e.g., excluding the UE capabilities requirements, etc.).

[0120] Similar to the first example use case in Table 8, the policy in the second example use case in Table 9 is implemented to enhance energy-saving opportunities when there is low user activity during off-peak hours. Similarly, the policy may be activated during off-peak hours of the day, when the network load is equal to or lower than 20%, and at least 80% of UEs in the network cell support both the wake-up signal configuration and common signal / channel adaptation.

[0121] When the policy is activated, the Non-RT RIC 120 (or the associated rApp 121) and the Near-RT RIC 130 (or the associated xApp 131) may be configured to interoperate witheach other to implement the energy-saving operations defined in the policy. For instance, the Non- RT RIC 120 (or the associated rApp 121) may deploy the policy to enable dynamic wake-up signal, SSB, and PRACH adjustments, and communicate (or instruct the Near-RT RIC 130 / xApp 131 to communicate) with the associated network elements (e g., control elements, E2 nodes, etc.) to set up the necessary parameters for wake-up signal, SSB, and PRACH adjustments.

[0122] In this example use case, the feature of dynamic wake-up signal configuration enabled to configure / adjust the periodicity of the wake-up signal transmission to 40ms and configure / adjust the configure / adjust the power offset for the wake-up signal transmission to -5dB (i.e., reducing the wake-up signal transmission power by 5dB relative to a reference power level), thereby reducing the power consumption and optimizing the energy-savings opportunities.

[0123] Further, the features of dynamic SSB configuration, dynamic PRACH configuration, and non-uniform PRACH resource allocation are enabled to further reduce the power consumption and further optimize the energy- savings opportunities. Specifically, the periodicity of the SSB transmission may be configured / adjusted to 40ms and the periodicity of the PRACH transmission may be configured / adjusted to 20ms, while the power offsets for SSB transmission and PRACH transmission may be configured / adjusted to -5dB (i.e., reducing each of the SSB and PRACH transmission powers by 5dB relative to a respective reference power level).

[0124] Upon implementing the energy-saving operations and configuring the wake-up signal, SSB, and PRACH according to the policy, the Non-RT RIC 120 (or the associated rApp 121) and / or the Near-RT RIC 130 (or the associated xApp 131) may be configured to continuously (or periodically) monitor the network conditions to determine whether the implementation of the energy-saving operations maintain / degrade the network performances, satisfy / below the energysaving target, and the like. For instance, in this example use case, the Non-RT RIC 120 (or theassociated rApp 121) and / or the Near-RT RIC 130 (or the associated xApp 131) may be configured to collect data associated with energy consumption of the network / cell (or network elements associated therewith) and analyze the data to determine the network energy status based thereon. In addition, the Non-RT RIC 120 (or the associated rApp 121) and / or the Near-RT RIC 130 (or the associated xApp 131) may be configured to collect data associated with the average throughput, average latency, and packet error rate, and then analyze the data to determine the network performance based thereon.

[0125] Upon determining that there is a need to adjust the energy-saving operation(s), e.g., the network energy does not satisfy the energy-saving target and / or the network performance is degraded or below a predefined threshold, the Non-RT RIC 120 (or the associated rApp 121) and / or the Near-RT RIC 130 (or the associated xApp 131) may interoperate to adjust the energysaving operation(s). For instance, the Non-RT RIC 120 (or the associated rApp 121) may determine which policy (or which parameter(s) associated therewith) may be adjusted to satisfy the intended energy-saving target and / or network performance, and then instruct / provide guidance to the Near-RT RIC 130 (or the associated xApp 131) and / or the associated network elements (e.g., E2 nodes). Accordingly, the Near-RT RIC 130 (or the associated xApp 131) and / or the associated network elements may adjust the policy / associated parameters (e.g., wake-up signal configuration parameters, common signal / channel adaptation parameters, etc.) based on the instruction / guidance provided by the Non-RT RIC 120 (or the associated rApp 121).Example Methods and Operations

[0126] As described above, the network elements (e.g., Non-RT RIC 120, Near-RT RIC121, O-CU 140, O-DU 160, etc.) may be configured to interoperate with each other and performone or more methods / operations to enhance energy-savings opportunities in the network. In the following, descriptions of several example methods and the associated operations are provided.

[0127] One or more operations (or the data involved therein) may be similar to those described above with reference to FIG. 1 and Tables 1-9, thus it may be understood that the described operation(s) / data may be similarly applied to the operations described herein (unless described otherwise) and redundant descriptions associated therewith may be omitted for conciseness.

[0128] For descriptive purposes, the operations are mainly described as being performed by the Non-RT RIC, although it can be understood that, in actual implementations, the Near-RT RIC may perform similar / related operations from the opposite side, without departing from the scope of the present disclosure. For instance, an operation of the Non-RT RIC sending an energysaving policy to the Near-RT RIC may indicate or suggest an operation of the Near-RT RIC receiving the energy-saving policy from the Non-RT RIC, a description of the energy-saving policy being executable by the Near-RT RIC to perform one or more operations may indicate or suggest that the Near-RT RIC executes the energy-saving policy to perform the one or more operations, and the like.

[0129] According to example embodiments, the Non-RT RIC may be implemented in one or more hardware components, and one or more operations described hereinbelow may be performed by the one or more hardware components. For instance, the Non-RT RIC may be implemented in a server that includes a processor and a memory storage (or any other suitable storage mediums), wherein the memory storage may include computer-executable instructions which, when being executed by the processor, cause the processor to perform one or more operations described herein. Further, it is contemplated that one or more operations associated withthe Non-RT RIC may be implemented by one or more rApps associated with the Non-RT RIC. For instance, the Non-RT RIC may be configured to implement one or more rApps to perform one or more operations described herein.

[0130] FIG. 2 illustrates a block diagram of an example method 200 for facilitating the network energy-saving enhancement, according to one or more example embodiments.

[0131] As illustrated in FIG. 2, at operation S201, the Non-RT RIC may be configured to generate an energy-saving policy. In this regard, the operations of generating the energy-saving policy may include modifying / updating an existing energy-saving policy to thereby obtain a modified / updated energy-saving policy, generating a new energy-saving policy, or a combination thereof.

[0132] In some example embodiments, the Non-RT RIC may be configured to generate the energy policy based on a policy guideline, a policy schema, or any other suitable data / algorithm, thereby ensuring that the energy-saving policy is standardized and enforceable across different Near-RT RICs (or different xApps). In this case, at operation S201, the Non-RT RIC may be configured to obtain, from a storage medium (e.g., a memory storage of a server that implements the Non-RT RIC, a server dedicated to storing the policy schema, a memory storage of another server that implements another Non-RT RIC, etc.) the policy guideline / schema associated with the to be generated energy-saving policy, and then generate the energy-saving policy based thereon.

[0133] According to example embodiments, the energy-saving policy is executable or enforceable by a Near-RT RIC (or an xApp associated therewith) to perform at least one energysaving operation. The energy-saving operation comprises at least one of SSB management, SIB1 management, wake-up signal management, and PRACH management. Further, the energy-savingpolicy may include a parameter associated with an activation criteria, a parameter associated with a UE capability requirement, and a parameter associated with a policy decision.

[0134] According to example embodiments, the parameter associated with the activation criteria may include at least one of: a parameter defining a time of a day, a parameter defining a network load, and a parameter defining a minimum percentage of UEs in a cell that supports the energy-saving operation. Additionally or alternatively, the parameter associated with the UE capability requirement may include at least one of: a parameter defining whether the UEs support the energy-saving operation, and the parameter defining the minimum percentage of the UEs in the cell that supports the energy-saving operation. Additionally or alternatively, the parameter associated with the policy decision may include at least one KPI, wherein the KPI may include at least one of: a parameter associated with the network load, a parameter defining an energy consumption of a network element, a parameter defining a number of UEs supporting the energysaving operation, a parameter defining an average throughput per UE, a parameter defining an average latency in the network, and a parameter defining a packet error rate.

[0135] According to example embodiments where the energy-saving operation includes the SSB management, the SSB management may include an operation of compact SSB configuration (or dynamic SSB configuration / adjustment). In this regard, the energy-saving policy may further include at least one of: a parameter associated with a periodicity of SSB transmission, a parameter associated with a power offset for SSB transmission, a parameter associated with a duration for updating an SSB configuration, and a parameter associated with a state of dynamic SSB configuration.

[0136] According to example embodiments where the energy-saving operation includes the SIB1 management, the SIB1 management may include an operation of on-demand SIB1transmission (or dynamic SIB1 configuration / adjustment). In this regard, the energy-saving policy may further include at least one of: a parameter associated with an interval for SIB1 transmission, a parameter associated with a power offset for SIB1 transmission, and a parameter associated with a state of dynamic SIB1 transmission.

[0137] According to example embodiments where the energy-saving operation includes the wake-up signal management, the wake-up signal management may include an operation of wake-up signal configuration (or dynamic wake-up signal configuration / adjustment). In this regard, the energy-saving policy may further include at least one of: a parameter associated with a periodicity of wake-up signal transmission, a parameter associated with a power offset for wakeup signal transmission, and a parameter associated with a state of dynamic wake-up signal configuration.

[0138] According to example embodiments where the energy-saving operation includes the PRACH management, the PRACH management may include an operation of PRACH configuration (or dynamic PRACH configuration / adjustment / adaptation). In this regard, the energy-saving policy may further include at least one of: a parameter associated with a periodicity of PRACH transmission, a parameter associated with a power offset for PRACH transmission, a parameter associated with a state of dynamic PRACH configuration, and a parameter associated with a state of non-uniform PRACH resource allocation per SSB.

[0139] According to example embodiments where the energy-saving operation includes both the SSB management and SIB1 management, the SSB management may include an operation of compact SSB configuration (or dynamic SSB configuration / adjustment) while the SIBl management may include an operation of on-demand SIBl transmission (or dynamic SIBl transmission / configuration / adjustment). In this regard, the energy-saving policy may furtherinclude both of the parameters associated with the SSB management (e.g., a parameter associated with a periodicity of SSB transmission, a parameter associated with a power offset for SSB transmission, a parameter associated with a duration for updating an SSB configuration, and / or a parameter associated with a state of dynamic SSB configuration) and the parameters associated with the SIB1 management (e.g., a parameter associated with an interval for SIB1 transmission, a parameter associated with a power offset for SIB1 transmission, and / or a parameter associated with a state of dynamic SIB1 transmission).

[0140] According to example embodiments, the energy-saving operation may include a common signal / channel management, which may include the SSB management and the PRACH management. In this regard, the SSB management may include an operation of compact SSB configuration (or dynamic SSB configuration / adjustment) while the PRACH management may include an operation of PRACH configuration (or dynamic PRACH configuration / adjustment / adaptation). In this regard, the energy-saving policy may further include both of the parameters associated with the SSB management (e.g., a parameter associated with a periodicity of SSB transmission, a parameter associated with a power offset for SSB transmission, a parameter associated with a duration for updating an SSB configuration, and / or a parameter associated with a state of dynamic SSB configuration) and the parameters associated with the PRACH management (e.g., a parameter associated with a periodicity of PRACH transmission, a parameter associated with a power offset for PRACH transmission, a parameter associated with a state of dynamic PRACH configuration, and / or a parameter associated with a state of non-uniform PRACH resource allocation per SSB).

[0141] According to example embodiments, the energy-saving operation may include both the wake-up signal management and the common signal / channel management. In this regard, thewake-up signal management may include an operation of wake-up signal configuration (or dynamic wake-up signal configuration / adjustment), while the common signal / channel management may include the SSB management (which may include an operation of compact SSB configuration or dynamic SSB configuration / adjustment) and the PRACH management (which may include an operation of PRACH configuration (or dynamic PRACH configuration / adjustment / adaptation). Accordingly, the energy-saving policy may further include the parameters associated with the wake-up signal management (e.g., a parameter associated with a periodicity of wake-up signal transmission, a parameter associated with a power offset for wakeup signal transmission, and a parameter associated with a state of dynamic wake-up signal configuration), the parameters associated with the SSB management (e.g., a parameter associated with a periodicity of SSB transmission, a parameter associated with a power offset for SSB transmission, a parameter associated with a duration for updating an SSB configuration, and / or a parameter associated with a state of dynamic SSB configuration), and the parameters associated with the PRACH management (e.g., a parameter associated with a periodicity of PRACH transmission, a parameter associated with a power offset for PRACH transmission, a parameter associated with a state of dynamic PRACH configuration, and / or a parameter associated with a state of non-uniform PRACH resource allocation per SSB).

[0142] Further descriptions of the generation of the energy-saving policy, as well as the structure, contents, and configurations of the energy-saving policy, have been provided above with reference to FIG. 1 and Tables 1-9. Thus, redundant descriptions associated therewith may be omitted below for conciseness.

[0143] Referring still to FIG. 2, at operation S202, the Non-RT RIC may be configured to provide the energy-saving policy to the Near-RT RIC. For instance, the Non-RT RIC may provide the energy-saving policy to the Near-RT RIC via the Al interface.

[0144] According to example embodiments, upon sending the energy-saving policy to the Near-RT RIC, the Non-RT RIC may be configured to receive one or more feedback from the Near- RT RIC upon execution of the policy. Subsequently, the Non-RT RIC may be configured to generate, based on the feedback(s), another energy-saving policy (e.g., an updated / fine-tuned energy-saving policy, a new energy-saving policy, etc.), and then provide said another energysaving policy to the Near-RT RIC for further operations.

[0145] FIG. 3 illustrates a block diagram of an example method 300 for implementing an energy-saving policy, according to one or more example embodiments. Method 300 may include one or more operations performed or implemented by the Non-RT RIC (or the associated rApp) and the Near-RT RIC (or the associated xApp). Further, method 300 may include one or more operations in method 200 (in FIG. 2), and may involve an operation, data, information, and the like, described above with reference to FIG. 1 and Tables 1-9.

[0146] Referring to FIG. 3, at operation S301, a parameter or a setting associated with an energy-saving operation may be configured. For instance, the Non-RT RIC (or the associated rApp) and / or the Near-RT RIC (or the associated xApp) may create, integrate, and / or apply one or more configuration profiles that define the param eter / setting of the energy-saving operation and apply the parameter / setting within the configuration module of the Non-RT RIC (or the associated rApp) and / or the Near-RT RIC (or the associated xApp).

[0147] At operation S302, an associated energy-saving policy may be deployed. For instance, the Non-RT RIC (or the associated rApp) and / or the Near RT RIC (or the associatedxApp) may schedule the implementation of the energy-saving policy based on the activation criteria defined in the energy-saving policy. For instance, one or more E2 nodes may be set (via the E2 interface by the Near-RT RIC 130 or the associated xApp 131) to implement or use the param eter / setting of the energy-saving operation during a specific low-traffic period.

[0148] At operation S303, the network conditions may be continuously (or periodically) monitored. For instance, the Non-RT RIC (or the associated rApp) and / or the Near-RT RIC (or the associated xApp) may gather, from the E2 nodes, network performance / condition data (such as those defined in the KPIs of the energy-saving policy). The Near-RT RIC (or the associated xApp) may gather, from the E2 nodes via the E2 interface, the network data and then provide the same to the Non-RT RIC (or the associated rApp) via the Al interface. Additionally or alternatively, the Non-RT RIC 120 (or the associated rApp 121) may gather the network data from the E2 nodes via the 01 interface. These network data may define the effectiveness of the energysaving operations and the associated impact on the network performance (if any).

[0149] At operation S304, the energy-saving policy (or a parameter associated therewith) may be adjusted. Specifically, Non-RT RIC (or the associated rApp 121) and / or the Near-RT RIC 130 (or the associated xApp 131) may make necessary adjustments to the energy-saving policy to maintain or optimize network performance / quality and / or energy-saving effectiveness. For instance, the Non-RT RIC (or the associated rApp) may determine, based on the monitored network data, which of the parameter(s) in the energy-saving policy can be (or should be) adjusted to achieve an energy-saving target while maintaining the network performance. Accordingly, the Non-RT RIC (or the associated rApp) may provide (via the Al interface) a guidance / instruction to the Near-RT RIC (or the associated xApp) thereby guiding / instructing the Near-RT RIC (or the associated xApp) to perform real-time (or near-real-time) adjustments on the energy-saving policy.

[0150] One or more example energy-saving operations described herein may include or may be implemented via one or more operations of method 300. For instance, the operation of compact SSB configuration may include: implementing the compact SSB configuration during a specified low-traffic period (which may involve operations S301 and S302); monitoring network performance after implementing the compact SSB configuration (which may involve operation S3O3); and adjusting the compact SSB configuration based on the monitored network performance (which may involve operation S304).

[0151] As another example, the operation of on-demand SIB1 transmission may include: determining the need for SIB1 broadcasting and triggering SIB1 transmission based on the result of the determining (which may involve operations S301 and S302); monitoring network performance after the triggering (which may involve operation S303); and adjusting the SIB1 transmission based on the monitored network performance (which may involve operation S304).

[0152] As yet another example, the operation of wake-up signal configuration may include: determining a current network load and implementing a predefined wake-up signal configuration based on the current network load (which may involve operations S301 and S302); monitoring network performance after the implementing (which may involve operation S3O3); and adjusting the predefined wake-up signal configuration based on the monitored network performance (which may involve operation S304).

[0153] As yet another example, the operation of PRACH configuration may include: determining a current network load and implementing a predefined PRACH configuration based on the current network load (which may involve operations S301 and S302); monitoring network performance after the implementing (which may involve operation S303); and adjusting thepredefined PRACH configuration based on the monitored network performance (which may involve operation S304).

[0154] In view of the above, example embodiments of the present disclosure provide methods and operations for provisioning energy-saving enhancement in a telecommunications network. Specifically, the methods and operations may be implemented by one or more 0-RAN components (e.g., Non-RT RIC, etc.) to generate, transmit, manage, and utilize one or more energy-saving policies that include parameters and contents for implementing one or more energysaving operations, as well as to dynamically update the energy-saving policies based on real-time data (e.g., network performance, energy consumption status, etc.), thereby ensuring that the energy-saving operations may be dynamically and adaptively configured to enhance or optimize the energy-saving opportunities while maintaining the network performance.Example Device

[0155] One or more components of the example embodiments (e.g., Non-RT RIC, Near- RT RIC, etc ), as well as the operations associated therewith, may be implemented in one or more devices or hardware components. For instance, one or more components / operations of the Non- RT RIC may be implemented in one or more devices like a server(s), a network device(s), and the like.

[0156] In the following, descriptions of a device in which the example embodiments may be implemented are provided. It is contemplated that one or more features, operations, and methods described above may be performed by the device. For instance, the one or more operations or methods may be performed by at least one processor of the device upon executing machine- readable instructions or computer-readable instructions stored in a memory or a storage component of the device.

[0157] FIG. 4 illustrates a block diagram of an example device 400 for implementing one or more example embodiments. As shown in FIG. 4, the device 400 includes processor 410, a memory 420, a storage component 430, an input component 440, an output component 450, a communication interface 460, and a bus 470.

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

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

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

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

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

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

[0164] The bus 470 acts as an interconnect between the processor 410, the memory 420, the storage component 430, the input component 440, the output component 450, and the communication interface 460 of the device 400. The bus 470 may include a wired interconnection or a wireless interconnection.

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

[0166] Example embodiments of the present disclosure may be implemented in any suitable type of environment. In the following, an example environment (in which the example embodiments may be implemented) is described.

[0167] FIG. 5 illustrates a block diagram of an example environment 500 for implementing in which systems and / or method, described herein, may be implemented. The implementation environment 500 includes a UE (User equipment) 510, a service environment 520, and a network 530. The service environment 520 include one or more sub-environments 521. To illustrate this, FIG. 5 shows, for convenience, examples of a 1st sub-environment 521-1, a 2nd sub-environment 521-2, and an N-th sub-environment 521-N (where N is any natural number).

[0168] The UE 510 is connected to the network 530, and the network 530 is connected to the service environment 520. The connections may be wired, wireless, or a combination of both wired and wireless. The UE 510 and the service environment 520 are connected via the network 530.

[0169] The UE 510 is a device that communicates with the service environment 520. The UE 510 receives information from the service environment 520 and / or sends information to the service environment 520. Also, the UE 510 may generate and / or store information to be transmitted, as necessary. Also, the UE 510 may store and / or process information that is received, as necessary.

[0170] The example figure 5 refers to the “UE”. However, it should be understood by those skilled in the art that general terms such as “user device,” “terminal,” “terminal device,”“communication device,” and “communication terminal” can be used interchangeably with the term “UE.”

[0171] For example, the UE 510 may include a computing device (e.g., a desktop computer, a laptop computer, a tablet computer, a handheld computer, a smart speaker, a server, etc.), a mobile phone (e.g., a smart phone, a radiotelephone, etc.), a wearable device (e.g., a pair of smart glasses or a smart watch), or a similar device.

[0172] The service environment 520 is an environment that communicates with the UE 510 to provide one or more services. The service environment 520 receives information from the UE 510 and / or sends information to the UE 510. Also, the service environment 520 may generate and / or store information to be transmitted, as necessary. Also, the service environment 520 may store and / or process information that is received, as necessary. For example, the service environment 520 may provide computing resources as one of the services. It should be noted that the service is not limited to being provided to the UE; it may also be provided to devices other than the UE. For example, based on communication from the UE, the service may perform processes such as anomaly detection or traffic analysis and notify the results to a predetermined destination.

[0173] The example figure 5 refers to the “service environment”. The term "service environment" is used to refer to the broader context within which services operate. For example, cloud environments, platforms, computing systems, network systems, and cloud systems generally represent the environments in which services are conducted, and these are included within the "service environment." However, the "service environment" is not limited to these examples. Additionally, the specific types of environments within the "service environment" are not restricted.For instance, cloud environments and cloud systems can be categorized as private cloud, public cloud, hybrid cloud, or multi-cloud, all of which are included within the "service environment."

[0174] The one or more services provided by the service environment 520 is not specifically limited and can be adjusted according to the embodiments. For example, the services may include a service that provides information to the UE 510, a service that stores information from the UE 510, or a service that performs processing based on information from the UE 510 and returns the results of the processing.

[0175] In an embodiment, the Service Environments 520 may also provide computing resources as the service. The computing resources can be hardware resources and / or software resources. For example, applications, processors, memory, and storage can be included in the provided computing resources. Each computing resource can communicate with other computing resources via wired connections, wireless connections, or a combination of wired and wireless connections.

[0176] The provided computing resources can be actual resources (also referred to as physical resources) and / or virtual resources. Furthermore, means of virtualization for virtual resources can be selected as appropriate. That is, in this disclosure, the use of adjectives such as "Virtual" or "Virtualized" to describe names does not imply that they are virtualized by a specific means of virtualization. For example, “virtual machine” refers to software that operates like an actual computer, realized through means of virtualization, and it is not intended to exclude those realized by specific means of virtualization such as Hypervisors or Containers. Conversely, when means of virtualization such as Hypervisors or containers are mentioned in this disclosure, it is merely cited as a general method of implementation. It should also be interpreted that embodimentsimplemented with other virtualization means are also disclosed. Also, the services may also be provided using resources virtualized by different means.

[0177] The service environment 520 includes one or more devices, such as servers and network devices, which provide services or perform processes. The placement of these devices within the service environment 520 can be determined as appropriate. Additionally, if the service environment 520 includes one or more sub-environments 521, the placement of devices can be determined based on predetermined policies for each sub-environment 521 . For example, devices related to the first service may be placed in the 1st sub-environment 521-1, and devices related to the second service may be placed in the 2nd sub -environment 521-2. In another example, devices expected to have a higher load than a predetermined threshold may be placed in the 1st subenvironment 521-1, while devices expected to have a lower load than the predetermined threshold may be placed in the 2nd sub-environment 521-2. In this way, specific devices can be placed in specific sub-environments 521. Conversely, each sub-environment 521 can be specialized for a particular purpose.

[0178] In an embodiment, all processes executed in a single service may run within a single service environment, or in multiple service environments. Multiple processes executed in a single service could be provided by different service environments.

[0179] The network 530 is a network that exchanges information between the UE 510 and the service environment 520. The network 530 includes one or more wired and / or wireless networks.

[0180] For example, the network 530 may include a cellular network (e.g., a fifth generation (5G) network, a long-term evolution (LTE) network, a third generation (3G) network, a code division multiple access (CDMA) network, etc.), a public land mobile network (PLMN), alocal area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., the Public Switched Telephone Network (PSTN)), a private network, an ad hoc network, an intranet, the Internet, a fiber optic-based network, or the like, a non-terrestrial network (NTN), and / or a combination of these or other types of networks.

[0181] The network 530 can be a part of a network. For example, in a 5G network that includes a RAN, a transport network, and a core network, the network 530 can be at least one of the RAN, the transport network, or the core network. For example, the service environment 520 could be in the core network, in which case the network 530 could correspond to a network that is a combination of a RAN and a transport network and is part of the 5G network.

[0182] The number and arrangement of devices and networks shown in FIG. 5 are provided as an example. It should be understood that any changes that may be implemented by those skilled in the art, such as the addition or rearrangement of well-known devices or networks at the time of implementation, are included in this disclosure.Various Aspects of Embodiments

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

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

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

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

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

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

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

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

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

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

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

[0194] In view of the above, various further respective aspects and features of embodiments of the present disclosure may be defined by the following items:Item [1]: A system including a Non-RT RIC that may be configured to generate an energy-saving policy and provide the energy-saving policy to a Near- RT RIC. The energy-saving policy may be executable by the Near-RT RIC toperform an energy-saving operation, including at least one of SSB management, SIB1 management, wake-up signal management, and PRACH management. The energy-saving policy may include a parameter associated with an activation criteria, a parameter associated with a user equipment (UE) capability requirement, and a parameter associated with a policy decision.Item [2]: The system according to item [1], wherein the SSB management may include an operation of compact SSB configuration. Further, the energy-saving policy may further include at least one of: a parameter associated with a periodicity of SSB transmission, a parameter associated with a power offset for SSB transmission, a parameter associated with a duration for updating an SSB configuration, and a parameter associated with a state of dynamic SSB configuration.Item [3]: The system according to one or more of items

[0001] -[2], wherein theSIB1 management may include an operation of on-demand SIB1 transmission. Further, the energy-saving policy may further include at least one of a parameter associated with an interval for SIB1 transmission, a parameter associated with a power offset for SIB1 transmission, and a parameter associated with a state of dynamic SIB1 transmission.Item [4]: The system according to one or more of items

[0001] -[3], wherein the wake-up signal management may include an operation of wake-up signal configuration. Further, the energy-saving policy may further include at least one of: a parameter associated with a periodicity of wake-up signal transmission, aparameter associated with a power offset for wake-up signal transmission, and a parameter associated with a state of dynamic wake-up signal configuration.Item [5]: The system according to one or more of items

[0001] -[4], wherein thePRACH management may include an operation of PRACH configuration. Further, the energy-saving policy may further include at least one of: a parameter associated with a periodicity of PRACH transmission, a parameter associated with a power offset for PRACH transmission, a parameter associated with a state of dynamic PRACH configuration, and a parameter associated with a state of non-uniform PRACH resource allocation per SSB.Item [6]: The system according to one or more of items

[0001] -[5], wherein the energy-saving operation may include the SSB management and the SIB1 management, the SSB management may include an operation of compact SSB configuration, and the S1B1 management may include an operation of on-demand SIB1 transmission. Further, the energy-saving policy may further include (a) at least one of: a parameter associated with a periodicity of SSB transmission, a parameter associated with a power offset for SSB transmission, a parameter associated with a duration for updating an SSB configuration, and a parameter associated with a state of dynamic SSB configuration, and (b) at least one of: a parameter associated with an interval for SIB1 transmission, a parameter associated with a power offset for SIB1 transmission, and a parameter associated with a state of dynamic SIB1 transmission.Item [7]: The system according to one or more of items

[0001] -[6], wherein the energy-saving operation may include a common signal / channel management, andthe common signal / channel transmission management may include the SSB management and the PRACH management. Further, the SSB management may include an operation of compact SSB configuration, and the PRACH management may include an operation of PRACH configuration. Furthermore, the energysaving policy may further include (a) at least one of a parameter associated with a periodicity of SSB transmission, a parameter associated with a power offset for SSB transmission, and a parameter associated with a state of dynamic SSB configuration, and (b) at least one of: a parameter associated with a periodicity of PRACH transmission, a parameter associated with a power offset for PRACH transmission, a parameter associated with a state of dynamic PRACH configuration, and a parameter associated with non-uniform PRACH resource allocation per SSB. Item [8]: The system according to item [7], wherein the energy-saving operation may include the wake-up signal management and the common signal / channel management, and the wake-up signal management comprises an operation of wake-up signal configuration. Further, the energy-saving policy may further include at least one of: a parameter associated with a periodicity of the wakeup signal, a parameter associated with power offset for wake-up signal transmission, and a parameter associated with a state of dynamic wake-up signal configuration. Item [9]: The system according to one or more of items [2], [6], [7], and [8], wherein the operation of compact SSB configuration may include: implementing the compact SSB configuration during a specified low traffic period; monitoring network performance after implementing the compact SSB configuration; andadjusting the compact SSB configuration based on the monitored network performance.Item

[0010] : The system according to one or more of items [3], [6], and [9], wherein the operation of on-demand SIB1 transmission may include: determining the need for SIB1 broadcasting; triggering SIB1 transmission based on the result of the determining; monitoring network performance after the triggering; and adjusting the SIB1 transmission based on the monitored network performance.Item

[0011] : The system according to one or more of items [4], [8], [9], and

[0010] , wherein the operation of wake-up signal configuration may include: determining a current network load; implementing a predefined wake-up signal configuration based on the current network load; monitoring network performance after the implementing; and adjusting the predefined wake-up signal configuration based on the monitored network performance.Item

[0012] : The system according to one or more of items [5], [7], [8], [9],

[0010] , and

[0011] , wherein the operation of PRACH configuration may include: determining a current network load; implementing a predefined PRACH configuration based on the current network load; monitoring network performance after the implementing; and adjusting the predefined PRACH configuration based on the monitored network performance. c The system according to one or more of items [1]-

[0012] , wherein the parameter associated with the activation criteria may include at least one of: a parameter defining a time of a day, a parameter defining a network load, and a parameter defining a minimum percentage of UEs in a cell that supports the energy-saving operation. Further, the parameter associated with the UE capability requirement may include at least one of: a parameter defining whether the UEs support the energy-saving operation, and the parameter defining the minimum percentage of the UEs in the cell that supports the energy-saving operation. Furthermore, the parameter associated with the policy decision may include at least one key performance indicator (KPI), wherein the KPI may include at least one of: a parameter associated with the network load, a parameter defining an energy consumption of a network element, a parameter defining a number of UEs supporting the energy-saving operation, a parameter defining an average throughput per UE, a parameter defining an average latency in the network, and a parameter defining a packet error rate.Item

[0014] : A method may including: generating, by a Non-RT RIC, an energysaving policy, and providing, by the Non-RT RIC, the energy-saving policy to a Near-RT RIC. The energy-saving policy may be executable by the Near-RT RIC to perform an energy-saving operation, including at least one of: SSB management, SIB1 management, wake-up signal management, and PRACH management. The energy-saving policy may include a parameter associated with an activation criteria, a parameter associated with a user equipment (UE) capability requirement, and a parameter associated with a policy decision.Item

[0015] : The method according to item

[0014] , wherein the SSB management may include an operation of compact SSB configuration. Further, the energy-saving policy may further include at least one of: a parameter associated with a periodicity of SSB transmission, a parameter associated with a power offset for SSBtransmission, a parameter associated with a duration for updating an SSB configuration, and a parameter associated with a state of dynamic SSB configuration.Item

[0016] : The method according to one or more of items

[0014] -

[0015] , wherein the SIB1 management may include an operation of on-demand SIB1 transmission. Further, the energy-saving policy may further include at least one of: a parameter associated with an interval for SIB1 transmission, a parameter associated with a power offset for SIB1 transmission, and a parameter associated with a state of dynamic SIB1 transmission.Item

[0017] : The method according to one or more of items

[0014] -

[0016] , wherein the wake-up signal management may include an operation of wake-up signal configuration. Further, the energy-saving policy may further include at least one of: a parameter associated with a periodicity of wake-up signal transmission, a parameter associated with a power offset for wake-up signal transmission, and a parameter associated with a state of dynamic wake-up signal configuration.Item

[0018] : The method according to one or more of items

[0014] -

[0017] , wherein the PRACH management may include an operation of PRACH configuration. Further, the energy-saving policy may further include at least one of: a parameter associated with a periodicity of PRACH transmission, a parameter associated with a power offset for PRACH transmission, a parameter associated with a state of dynamic PRACH configuration, and a parameter associated with a state of non- uniform PRACH resource allocation per SSB.Item

[0019] : The method according to one or more of items

[0014] -

[0018] , wherein the energy-saving operation may include the SSB management and the SIB1 management, the SSB management may include an operation of compact SSB configuration, and the SIB1 management may include an operation of on-demand SIB1 transmission. Further, the energy-saving policy may further include (a) at least one of: a parameter associated with a periodicity of SSB transmission, a parameter associated with a power offset for SSB transmission, a parameter associated with a duration for updating an SSB configuration, and a parameter associated with a state of dynamic SSB configuration, and (b) at least one of: a parameter associated with an interval for SIB1 transmission, a parameter associated with a power offset for SIB1 transmission, and a parameter associated with a state of dynamic SIB1 transmission.Item

[0020] : A non-transitory computer-readable recording medium having recorded thereon instructions executable by a system that includes a Non-RT RIC to cause the Non-RT RIC to perform a method. The method may include: generating an energy-saving policy, and providing the energy-saving policy to a Near-RT RIC. The energy-saving policy is executable by the Near-RT RIC to perform an energy-saving operation, including at least one of: SSB management, SIB1 management, wake-up signal management, and PRACH management. The energy-saving policy may include a parameter associated with an activation criteria, a parameter associated with a user equipment (UE) capability requirement, and a parameter associated with a policy decision.

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

Claims

What is claimed is:

1. A system comprising: a non-real-time (Non-RT) radio access network intelligent controller (RIC) configured to: generate an energy-saving policy executable by a near-real-time (Near-RT) RIC to cause the Near-RT RIC to perform an energy-saving operation, wherein the energy-saving operation comprises at least one of: synchronization signal block (SSB) management, system information block 1 (SIB1) management, wake-up signal management, and physical random access channel (PRACH) management, wherein the energy-saving policy comprises a parameter associated with an activation criteria, a parameter associated with a user equipment (UE) capability requirement, and a parameter associated with a policy decision; and provide the policy to the Near-RT RIC.

2. The system according to claim 1, wherein the SSB management comprises an operation of compact SSB configuration, and wherein the energy-saving policy further comprises at least one of: a parameter associated with a periodicity of SSB transmission, a parameter associated with a power offset for SSB transmission, a parameter associated with a duration for updating an SSB configuration, and a parameter associated with a state of dynamic SSB configuration.

3. The system according to claim 1 , wherein the SIB1 management comprises an operation of on-demand SIBl transmission, andwherein the energy-saving policy further comprises at least one of: a parameter associated with an interval for SIB1 transmission, a parameter associated with a power offset for SIB1 transmission, and a parameter associated with a state of dynamic SIB1 transmission.

4. The system according to claim 1, wherein the wake-up signal management comprises an operation of wake-up signal configuration, and wherein the energy-saving policy further comprises at least one of: a parameter associated with a periodicity of wake-up signal transmission, a parameter associated with a power offset for wake-up signal transmission, and a parameter associated with a state of dynamic wake-up signal configuration.

5. The system according to claim 1, wherein the PRACH management comprises an operation of PRACH configuration, and wherein the energy-saving policy further comprises at least one of: a parameter associated with a periodicity of PRACH transmission, a parameter associated with a power offset for PRACH transmission, a parameter associated with a state of dynamic PRACH configuration, and a parameter associated with a state of non-uniform PRACH resource allocation per SSB.

6. The system according to claim 1, wherein the energy-saving operation comprises the SSB management and the SIB1 management,wherein the SSB management comprises an operation of compact SSB configuration, wherein the SIB1 management comprises an operation of on-demand SIB1 transmission, and wherein the energy-saving policy further comprises (a) at least one of: a parameter associated with a periodicity of SSB transmission, a parameter associated with a power offset for SSB transmission, a parameter associated with a duration for updating an SSB configuration, and a parameter associated with a state of dynamic SSB configuration, and (b) at least one of: a parameter associated with an interval for SIB1 transmission, a parameter associated with a power offset for SIB 1 transmission, and a parameter associated with a state of dynamic SIB1 transmission.

7. The system according to claim 1, wherein the energy-saving operation comprises a common signal / channel management, wherein the common signal / channel transmission management comprises the SSB management and the PRACH management, wherein the SSB management comprises an operation of compact SSB configuration, wherein the PRACH management comprises an operation of PRACH configuration, and wherein the energy-saving policy further comprises (a) at least one of: a parameter associated with a periodicity of SSB transmission, a parameter associated with a power offset for SSB transmission, and a parameter associated with a state of dynamic SSBconfiguration, and (b) at least one of: a parameter associated with a periodicity of PRACH transmission, a parameter associated with a power offset for PRACH transmission, a parameter associated with a state of dynamic PRACH configuration, and a parameter associated with non-uniform PRACH resource allocation per SSB.

8. The system according to claim 7, wherein the energy-saving operation comprises the wake-up signal management and the common signal / channel management, wherein the wake-up signal management comprises an operation of wake-up signal configuration, and wherein the energy-saving policy further comprises at least one of: a parameter associated with a periodicity of the wake-up signal, a parameter associated with power offset for wake-up signal transmission, and a parameter associated with a state of dynamic wake-up signal configuration.

9. The system according to claim 2, wherein the operation of compact SSB configuration comprises: implementing the compact SSB configuration during a specified low-traffic period; monitoring network performance after implementing the compact SSB configuration; and adjusting the compact SSB configuration based on the monitored network performance.

10. The system according to claim 3, wherein the operation of on-demand SIB1 transmission comprises:determining the need for SIB1 broadcasting; triggering SIB1 transmission based on the result of the determining; monitoring network performance after the triggering; and adjusting the SIB1 transmission based on the monitored network performance.

11. The system according to claim 4, wherein the operation of wake-up signal configuration comprises: determining a current network load; implementing a predefined wake-up signal configuration based on the current network load; monitoring network performance after the implementing; and adjusting the predefined wake-up signal configuration based on the monitored network performance.

12. The system according to claim 5, wherein the operation of PRACH configuration comprises: determining a current network load; implementing a predefined PRACH configuration based on the current network load; monitoring network performance after the implementing; and adjusting the predefined PRACH configuration based on the monitored network performance.

13. The system according to claim 1,wherein the parameter associated with the activation criteria comprises at least one of: a parameter defining a time of a day, a parameter defining a network load, and a parameter defining a minimum percentage of UEs in a cell that supports the energy-saving operation, wherein the parameter associated with the UE capability requirement comprises at least one of: a parameter defining whether the UEs support the energy-saving operation, and the parameter defining the minimum percentage of the UEs in the cell that supports the energy-saving operation, and wherein the parameter associated with the policy decision comprises at least one key performance indicator (KPI), wherein the KPI comprises at least one of: a parameter associated with the network load, a parameter defining an energy consumption of a network element, a parameter defining a number of UEs supporting the energy-saving operation, a parameter defining an average throughput per UE, a parameter defining an average latency in the network, and a parameter defining a packet error rate.

14. A method comprising: generating, by a non-real-time (Non-RT) radio access network intelligent controller (RIC), an energy-saving policy executable by a near-real-time (Near-RT) RIC to perform an energy-saving operation, wherein the energy-saving operation comprises at least one of: synchronization signal block (SSB) management, system information block 1 (SIB1) management, wake-up signal management, and physical random access channel (PRACH) management, wherein the energy-saving policy comprises a parameter associated with an activation criteria, a parameter associated with a user equipment (UE) capability requirement, and a parameter associated with a policy decision; andproviding, by the Non-RT RIC and to the Near-RT RIC, the energy-saving policy.

15. The method according to claim 14, wherein the SSB management comprises an operation of compact SSB configuration, and wherein the energy-saving policy further comprises at least one of: a parameter associated with a periodicity of SSB transmission, a parameter associated with a power offset for SSB transmission, a parameter associated with a duration for updating an SSB configuration, and a parameter associated with a state of dynamic SSB configuration.

16. The method according to claim 14, wherein the STB1 management comprises an operation of on-demand SIB1 transmission, and wherein the energy-saving policy further comprises at least one of: a parameter associated with an interval for SIB1 transmission, a parameter associated with a power offset for SIB1 transmission, and a parameter associated with a state of dynamic SIB1 transmission.

17. The method according to claim 14, wherein the wake-up signal management comprises an operation of wake-up signal configuration, and wherein the energy-saving policy further comprises at least one of: a parameter associated with a periodicity of wake-up signal transmission, a parameter associated with a power offset for wake-up signal transmission, and a parameter associated with a state of dynamic wake-up signal configuration.

18. The method according to claim 14, wherein the PRACH management comprises an operation of PRACH configuration, and wherein the energy-saving policy further comprises at least one of: a parameter associated with a periodicity of PRACH transmission, a parameter associated with a power offset for PRACH transmission, a parameter associated with a state of dynamic PRACH configuration, and a parameter associated with a state of non-uniform PRACH resource allocation per SSB19. The method according to claim 14, wherein the energy-saving operation comprises the SSB management and the SIB1 management, wherein the SSB management comprises an operation of compact SSB configuration, wherein the SIB1 management comprises an operation of on-demand SIB1 transmission, and wherein the energy-saving policy further comprises (a) at least one of: a parameter associated with a periodicity of SSB transmission, a parameter associated with a power offset for SSB transmission, a parameter associated with a duration for updating an SSB configuration, and a parameter associated with a state of dynamic SSB configuration, and (b) at least one of: a parameter associated with an interval for SIBl transmission, a parameter associated with a power offset for SIB 1 transmission, and a parameter associated with a state of dynamic SIBl transmission.

0. A non-transitory computer-readable recording medium having recorded thereon instructions executable by a system that includes a non-real-time (Non-RT) radio access network intelligent controller (RIC) to cause the Non-RT RIC to perform a method comprising: generating an energy-saving policy executable by a near-real-time (Near-RT) RIC to perform an energy-saving operation, wherein the energy-saving operation comprises at least one of: synchronization signal block (SSB) management, system information block 1 (SIB1) management, wake-up signal management, and physical random access channel (PRACH) management, wherein the energy-saving policy comprises a parameter associated with an activation criteria, a parameter associated with a user equipment (UE) capability requirement, and a parameter associated with a policy decision; and providing the energy-saving policy to the Near-RT RIC.

Images