Service management orchestration and distributed unit direct control network energy saving using the O1 interface

Abstract

A method, apparatus, or system for service management and orchestration (SMO) and distributed unit direct control network energy saving (NES) using the O1 interface may be provided, which may include: transmitting network energy saving (NES) information comprising at least one of network traffic, load performance measurements, or key performance indicators (KPIs) to service management and orchestration (SMO) via an open radio access network (O-RAN) distributed unit (O-DU); the O-DU receiving a message indicating when a TRx control configuration should be applied to an O-RAN radio unit (O-RU); the O-DU configuring a transceiver (TRx) control configuration in the O-RU on a fronthaul (FH) interface for a management plane (M-Plane) or control plane (C-Plane) at least in part based on the received message; and the O-DU transmitting a notification to the SMO indicating that the activation of the TRx control configuration was successful.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to service management and orchestration (SMO) using the O1 interface and distributed unit direct control network energy saving (NES) implementation.

BACKGROUND ART

[0002] The information disclosed in this Background Art section is solely for the purpose of facilitating an understanding of the general background art of the present disclosure, and shall not be construed as an admission or any form of suggestion that this information constitutes prior art already known to those skilled in the art.

[0003] A radio access network (RAN) is a critical component in a communication system that 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. Conventionally, the hardware and / or software of a particular RAN was vendor-specific.

[0004] With the advent of Open RAN (O-RAN) technology, multiple vendors are enabled to provide hardware and / or software for communication systems. Since different vendors are involved, the types of hardware and / or software provided may also vary. That is, different types of NEs may be provided by different vendors, and depending on the specific service, the NEs may be virtualized in the form of software (e.g., virtual machine (VM) based) or take the form of physical hardware (e.g., non-VM based).

[0005] For this purpose, O-RAN decomposes RAN functions into aggregation units (CUs), distributed units (DUs), and radio units (RUs). A CU may be a logical node for hosting the RAN sublayers of Radio Resource Control (RRC), Service Data Adaptation Protocol (SDAP), and / or Packet Data Convergence Protocol (PDCP). A DU may be a logical node for hosting the RAN sublayers of Radio Link Control (RLC), Media Access Control (MAC), and Physical (PHY). A RU may be a physical node for converting radio signals from antennas into digital signals that can be transmitted to the DUs on the fronthaul. Because these entities have open protocols and interfaces between them, they can be developed by different vendors.

[0006] Figure 1 illustrates an O-RAN architecture in the relevant technology. The RAN functions in the O-RAN architecture may be controlled and optimized by a RAN Intelligent Controller (RIC). The RIC may also be a software-defined component that implements modular applications for achieving the multi-vendor operability required in the O-RAN system and for automating and optimizing RAN operations. As shown in Figure 1, the RIC may be divided into two types: a non-real-time RIC (non-RT RIC) 120 and a near-real-time RIC (near-RT RIC) 130.

[0007] The non-RT RIC 120 may be a control point of a non-real-time control loop and may operate on a timescale longer than one second within the Service Management and Orchestration (SMO) framework 110. Its functionality may be implemented through a modular application called rApp and may include providing policy-based guidance and enrichment across the A1 interface, which is an interface enabling communication between the non-RT RIC and the near-RT RIC, performing data analytics, artificial intelligence / machine learning (AI / ML) training and inference for RAN optimization, and / or recommending configuration management actions on the O1 interface, which may also be an interface connecting the SMO to RAN management elements (e.g., near-RT RIC 130, O-RAN aggregation units (O-CUs) 140, 150, O-RAN distributed units (O-DUs) 170, etc.).

[0008] The Near-Real-Time RIC130 may operate on timescales between 10 milliseconds and 1 second and may be coupled via the E2 interface to the O-DU170, O-CU (which is broken down into the O-CU Control Plane (O-CU-CP)140 and the O-CU User Plane (O-CU-UP)150), and the open evolved NodeB (O-eNB)160. The Near-Real-Time RIC130 may use the E2 interface to control the underlying RAN elements (E2 Node / Network Functions (NF)) on the Near-Real-Time control loop. The Near-Real-Time RIC130 may monitor, suspend / stop, override, and control the E2 nodes (O-CU140, 150, O-DU170, O-eNB160) via policies. For example, the Near-Real-Time RIC130 may set policy parameters on the functions of the E2 nodes to be activated. Furthermore, the nearby RT RIC130 may host xApps to implement functions such as quality of service (QoS) optimization, mobility optimization, slicing optimization, interference mitigation, load balancing, and security.

[0009] Here, O-CU-CP140 and O-CU-UP150 may be coupled to each other via the E1 interface, or they may be coupled to O-DU170 via the F1-c interface and F1-u interface, respectively. Furthermore, O-RU180 may be coupled to O-DU170 via the Open Fronthaul (OF) Control (C), User (U), Synchronization (S), Management (M) plane, or it may be coupled to SMO110 via the OF M-Plane.

[0010] To optimize O-RAN, two types of RICs collaborate. For example, a non-RT RIC120 may provide policies, data, and AI / ML models to be enforced and used by a near-RT RIC130 for RAN optimization, and the near-RT RIC130 may return policy feedback (i.e., how the policies set by the non-RT RIC120 performed).

[0011] As previously mentioned, the non-RT RIC120 may reside within an SMO framework 110 that manages and orchestrates the RAN elements. Specifically, the SMO110 may manage and orchestrate what is represented as an O-RAN cloud (O-Cloud) 190. The O-Cloud 190 may be a collection of RICs, O-CUs, O-DUs, supporting software components (e.g., operating systems and runtime environments), and physical RAN nodes hosting the SMO110 itself. In other words, the SMO110 may manage the O-Cloud 190 from within. The O2 interface may be an interface between the SMO110 and the O-Cloud 190 in which it resides. Through the O2 interface, the SMO110 may provide Infrastructure Management Services (IMS) and Deployment Management Services (DMS).

[0012] In related technologies, the O-eNB160 or a lower-level RAN element (NF) (which may be controlled together with the SMO110 on the O1 interface, as illustrated in Figure 1) may be placed in a network energy saving (NES) state to reduce operational costs and improve network efficiency. This may include, for example, shifting the network load to other candidate cells or draining traffic on existing cells before entering the energy saving state. [Overview of the project] [Problems that the invention aims to solve]

[0013] Conventional methods used in related technologies do not adequately consider how to efficiently analyze the needs for activating the NES state, trigger the appropriate elements, and communicate the necessary information for activating the NES to the constituent network elements. [Means for solving the problem]

[0014] According to embodiments, a method for service management and orchestration (SMO) and distributed unit direct control network energy saving (NES) using the O1 interface may be provided, which may include: an open radio access network (O-RAN) distributed unit (O-DU) transmitting network energy saving (NES) information comprising at least one of network traffic, load performance measurements, and key performance indicators (KPIs) to the service management and orchestration (SMO); the O-DU receiving a message indicating when a TRx control configuration should be applied to an O-RAN radio unit (O-RU); the O-DU configuring a transceiver (TRx) control configuration in the O-RU on a fronthaul (FH) interface for a management plane (M-Plane) or control plane (C-Plane) at least in part based on the received message; and the O-DU transmitting a notification to the SMO indicating whether the activation of the TRx control configuration was successful.

[0015] Based on the embodiments described above, an SMO-based NES approach using the O1 interface may enable more optimized network-wide energy consumption, improved automation, and more optimized resource allocation, as decision-making can be made using real-time data and / or predictive analytics to tune the power profile.

[0016] According to one embodiment, an Open Radio Access Network (O-RAN) Distributed Unit (O-DU) may be provided and configured to transmit network energy saving (NES) information, comprising at least one of network traffic, load performance measurements, and key performance indicators (KPIs), to Service Management and Orchestration (SMO); to receive a message indicating when a TRx control configuration should be applied to an O-RAN radio unit (O-RU); to configure a transceiver (TRx) control configuration in the O-RU on a fronthaul (FH) interface for either a management plane (M-Plane) or a control plane (C-Plane), at least in part, based on the received message; and to send a notification to the SMO indicating that the activation of the TRx control configuration was successful.

[0017] According to an embodiment, at least one non-temporary computer-readable recording medium may be provided that records instructions executable to implement a method including: an open radio access network (O-RAN) distributed unit (O-DU) transmitting network energy saving (NES) information comprising at least one of network traffic, load performance measurement results, and key performance indicators (KPIs) to service management and orchestration (SMO); the O-DU receiving a message indicating when a TRx control configuration should be applied to an O-RAN radio unit (O-RU); the O-DU configuring a transceiver (TRx) control configuration in the O-RU on a fronthaul (FH) interface for one of the management planes (M-Plane) or control planes (C-Plane) at least in part based on the received message; and the O-DU transmitting a notification to the SMO indicating whether the activation of the TRx control configuration was successful.

[0018] Additional aspects are presented in part in the following description, and will be in part apparent from the description, or may be realized by implementation of the presented embodiments of the present disclosure. [Brief Description of the Drawings]

[0019] Features, aspects, and advantages of certain exemplary embodiments of the disclosure are described below with reference to the accompanying drawings in which like reference numerals represent like elements.

[0020] Figure 1 illustrates an O-RAN architecture according to the related art. Figure 2 illustrates a system architecture diagram for O-RAN elements and interfaces according to an embodiment.

[0021] Figure 3 illustrates an overall call flow diagram for network energy saving according to an embodiment.

[0022] Figures 4A to 5C illustrate call flow diagrams for carrier and cell switch-off / on network energy saving according to an embodiment.

[0023] Figures 5A to 5C illustrate call flow diagrams for TRx network energy saving according to an embodiment.

[0024] Figures 6A to 6B illustrate call flow diagrams for policy-based SMO / O-DU direct control or O-DU driven TRx control implementation according to an embodiment.

[0025] Figures 7A to 7C illustrate call flow diagrams for advanced sleep mode network energy saving according to an embodiment.

[0026] FIG. 8 is a block diagram illustrating an example of a data structure for gNB-DU (O-DU) / gNB-CU (O-CU) IM / DM for supporting network energy saving according to an embodiment.

[0027] FIG. 9 is a block diagram illustrating an example of a data structure for O-DU network energy saving according to an embodiment.

[0028] FIG. 10 is a block diagram illustrating an example of a data structure for O-DU network energy saving using TRx control according to an embodiment.

[0029] FIG. 11 is a block diagram illustrating an example of a data structure for O-DU network energy saving using an advanced sleep mode according to an embodiment.

[0030] FIG. 12 is a block diagram illustrating an example of a data structure for O-CU network energy saving according to an embodiment.

[0031] FIG. 13 is a block diagram illustrating an example of a data structure for direct TRx control by an O-DU using M-Plane according to an embodiment.

[0032] FIG. 14 is a flowchart illustrating an example of a method for implementing Rx control by SMO / O-DU direct control according to an embodiment.

[0033] FIG. 15 is a diagram of an example environment in which the systems and / or methods described herein may be implemented.

[0034] FIG. 16 is a diagram of example components of a device according to an embodiment. [Description of Embodiments]

[0035] The following detailed descriptions of embodiments refer to the accompanying drawings. The prior disclosures provide examples and descriptions, but are not intended to be exhaustive or to limit implementations to the exact forms disclosed. Modifications and alterations are possible in light of the prior disclosures or may be obtained from the implementations. Furthermore, one or more features or components of one embodiment may be integrated with or combined with other embodiments (or one or more features of other embodiments). In addition, in the flowcharts and descriptions of operations provided below, one or more operations may be omitted, one or more operations may be added, one or more operations may be performed simultaneously (at least partially), and the order of one or more operations may be changed.

[0036] It will become clear that the systems and / or methods described herein may be implemented in different forms of hardware, firmware, or combinations of hardware and software. The specific control hardware or software code used to implement these systems and / or methods is not limiting to the implementation. For this reason, 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 descriptions herein.

[0037] Even if certain combinations of features are described in the claims and / or disclosed in the specification, these combinations are not intended to limit the disclosure of possible implementations. In fact, many of these features may be combined in ways different from those specifically described in the claims and / or disclosed in the specification. Each of the dependent claims listed below may depend directly on only one claim, but the disclosure of possible implementations includes each dependent claim in combination with all other claims in the group of claims.

[0038] None of the elements, actions, or commands used herein should be interpreted as important or essential unless explicitly stated otherwise. 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." When only one item is intended, the term "one" or similar is used. Also, as used herein, the terms "has," "have," "having," "include," "including," etc., are intended to be open-ended terms. Furthermore, the phrase "based on" means "at least partially based on" unless explicitly stated otherwise. Furthermore, expressions such as "at least one of A and B" or "at least one of A or B" are understood to include only A, only B, or both A and B.

[0039] According to embodiments, methods, apparatus, and systems for service management and orchestration (SMO) network energy saving (NES) using an O1 interface may be provided, which may include: an open radio access network (O-RAN) distributed unit (O-DU) transmitting network energy saving (NES) information to service management and orchestration (SMO) comprising at least one of network traffic, load performance measurements, and key performance indicators (KPIs); the O-DU receiving a message indicating when a TRx control configuration should be applied to an O-RAN radio unit (O-RU); the O-DU configuring a transceiver (TRx) control configuration in the O-RU on a fronthaul (FH) interface for a management plane (M-Plane) or control plane (C-Plane) at least in part based on the received message; and the O-DU transmitting a notification to the SMO indicating whether the activation of the TRx control configuration was successful. Based on the embodiments described above, an SMO-based NES approach using the O1 interface may enable more optimized network-wide energy consumption, improved automation, and more optimized resource allocation, as decision-making can be made using real-time data and / or predictive analytics to tune the power profile.

[0040] Figure 2 illustrates a system architecture diagram of O-RAN elements and interfaces according to one embodiment. In particular, Service Management and Orchestration (SMO) 200, O-CU 210, O-DU 220, and O-RU 230 may be provided.

[0041] Referring to Figure 2, the SMO200 may be configured to communicate with the O-CU210 and O-DU220 via the O1 interface, and vice versa. The O-CU210 and O-DU220 may also be able to communicate with each other via the F1 interface. The O-RU230 may also be able to communicate with the SMO200 and O-DU220 via the front haul (FH).

[0042] The SMO200 may be responsible for triggering an energy-saving use case to the O-DU220 via the O1 interface, and the O-DU220 may then implement the use case via the management plane (M-Plane) or control plane (C-Plane), depending on the specific implementation and use case.

[0043] According to one embodiment, the SMO200 can cooperate with the O-DU220 and O-CU210 to enable sleep mode / TRx controls that do not affect the F1 interface (e.g., sleep modes (SM)#0 and SM#1 with a write sleep of up to one frame (10ms)). According to another embodiment, the SMO200 may use the O1 interface to implement other sleep modes (e.g., SM#3 and SM#4 with deep and hibernate sleep (10ms to "x" seconds)).

[0044] Furthermore, the F1 interface may have limitations in providing policies to specifically instruct cells / RF channels to be deactivated / muted / sleep for energy-saving use cases, according to the specifications (e.g., those in the Third Generation Partnership Project (3GPP)). In this regard, the O-CU210 may be able to provide timers for when cells are activated or deactivated, but the F1 interface does not necessarily have to be able to distinguish between specific different use cases.

[0045] According to one embodiment, a hierarchical deployment may be provided. Here, the O-RU230 is configured to expose its energy-saving capability to the O-DU220 via a front haul management plane (FH M-Plane), which may transfer the capability to the SMO200 through an aggregation model or as a configuration file via the O1 interface.

[0046] According to one embodiment, a hybrid deployment may be provided. Here, SMO200 is a remote procedure call (RPC), for example, <rpc> <get-config>This allows you to understand / obtain capabilities directly from O-RU.

[0047] In some embodiments, the O-DU220 may be able to expose network energy saving (NES) related parameters to the SMO200. In particular, for example, in carrier and cell switch-off / on use cases, the O-DU220 may be able to expose energy saving support and related parameters (which should be investigated from the perspective of the O-DU).

[0048] According to other embodiments of RF channel reconfiguration using transceiver (TRx) control use cases, the O-DU220 may also be able to expose to the SMO200 a list of TRx control configurations (including antenna array configurations), a list of supported sleep modes (SM) (SM#0, SM#1, SM#2, SM#4), wake-up periods associated with sleep modes, TRx control antenna configuration transitions, and other relevant parameters (to be investigated from the perspective of the O-DU).

[0049] According to other embodiments of the Advanced Sleep Mode (ASM) use case, the O-DU220 may also be able to expose to the SMO200 the sleep modes (SM#0, SM#1, SM#2, SM#4), the wake-up period for each sleep mode, and other relevant parameters (to be investigated from the perspective of the O-DU).

[0050] According to one embodiment, the O-CU210 may also be able to expose NES-related parameters to the SMO200. These may include, but are not limited to, RRC configuration-related parameters, UE context-related parameters, neighbor cell-related parameters, and other parameters (which should be investigated from the perspective of the O-CU).

[0051] Transceiver (TRx) control implementation using the O1 interface

[0052] In one embodiment, the SMO200 may be responsible for providing a policy on when to activate a specific transceiver (TRx) control configuration by indicating the mask name. Subsequently, the O-DU220 can activate the same configuration in the O-RU230 by including each antenna mask in a section type 4 control plane (ST4 C-Plane) message.

[0053] In some embodiments, cell activation / deactivation features may be included. SMO200 may directly activate cells in O-DU220. SMO200 may configure cells in O-DU220, configure carriers in O-RU230, and then SMO200 activates the cells. In other embodiments, SMO200 may configure only the cells served by O-DU220 and their corresponding carriers on the O1 interface to O-DU220. O-DU220 may consequently configure (activate / deactivate) tx / rx array carriers on their FH interface. In other embodiments, it should also be understood that O-DU220 may activate or deactivate only the tx / rx array carriers belonging to the cells served by O-DU220 in O-RU230.

[0054] According to the embodiment, a notification framework may be provided. The SMO200 may subscribe to the O-CU210, O-DU220, and O-RU230 (only in the case of a hybrid deployment) via the notification framework. For example, the SMO200 can receive notifications from the O-DU220 about cell activation / deactivation and tr[x] array carrier status of the O-RU230.

[0055] According to the embodiment, an odu-id may be provided. This may facilitate carrier activation and deactivation, Trx control, and sleep mode implementation based on the odu-id and ru-instance-id. In the WG4 yang model, the odu-id may be defined within the [tr]x array carrier. According to the embodiment, the SMO200 can use the odu-id and ru-instance-id to implement carrier and cell switch-off / on use cases, TRx control use cases, and ASM use cases in a specific O-RU230 via the O-DU220, where the odu-id may be used as a common reference parameter. The SMO200 can use an aggregate model to sleep / deactivate a specific carrier / array, with the assistance of the corresponding carrier / array name in the O-RU yang model.

[0056] According to one embodiment, the O1 interface may allow a variety of parameters to be transmitted to the SMO200.

[0057] In particular, data / parameters that may be transmitted over O1 may include, but are not limited to, user throughput, power consumption, QoS, user issues, current O-RU configuration, cell configuration, UL / DL delay (minimum, maximum, average), transmit and receive windows, distributed delays including FH delay between O-DU220 and O-RU230, etc.

[0058] The O-DU220 capabilities that can be exposed on the O1 interface may further include the number of SSB beams supported per TRx control configuration, the number of data beams (e.g., PUSCH) per TRx control configuration, the beam sweep range as a function of the number of antenna array elements, or the number of beams per configuration as reported based on the O-RU capabilities.

[0059] The O-CU related parameters that may be transmitted may include TRx configuration changes to O-CU210 and O-DU220 by SMO200 so that O-CU210 can recognize the RRC configuration and gNB-DU configuration updates can coordinate with O-DU220. It may also include CSI-RS ports that should be updated according to the current TRx control configuration (see, for example, item 7.14 of 3GPP TS 38.802). It may also include SSB coverage area changes for each TRx control configuration (RRC configuration related changes (indicated to O-CU210 by near-RT RIC or non-RT RIC)). Other O-CU related parameters may include configuration update messages between O-CU and O-DU (gNB configuration updates and gNB-CU configuration updates), CSI measurement results, and reporting (periodic and irregular).

[0060] Notifications that may be sent over the O1 interface may include, but are not limited to, notifications to the O-CU210 via the O1 interface regarding RRC-related changes, that the SMO200 is subscribed to notifications, notifications of energy saving state (e.g., energy saving state) changes, notifications of [tx] array carrier state changes, and notifications of TRx control configuration changes.

[0061] Figures 3A-3C illustrate an overall call flow diagram for network energy saving (NES) according to one embodiment. In particular, SMO300, O-CU310, O-DU320, and O-RU330 may be provided, which may correspond to entities similar to those described in Figure 2 above.

[0062] Referring to Figure 3A, the capabilities of O-RU330 may be exposed first. The configuration step in the call flow is described as follows:

[0063] 1: SMO300 may request supported features of O-RU330 from O-DU320 using a "get rpc call" for oru features on the O1 interface.

[0064] 2: O-DU320 may request NES feature support (e.g., carrier / cell switch off / on, TRx control, advanced sleep mode) from O-RU330 using a "get rpc call" on the FH interface.

[0065] In a 3:2 configuration, the requested NES feature is exposed from O-RU330 to O-DU320.

[0066] 4: The NES capability parameter may be requested from the O-RU330 by the O-DU320 on the FH interface. Substeps for exposing the NES capability parameter may include (depending on the specific use case): 4.1: The carrier / cell switch on / off capability may be exposed to the O-DU320 by the O-RU330 via the M-Plane in the FH interface; 4.2: A list of supported TRx control antenna configurations may be exposed to the O-DU320 by the O-RU330 via the M-Plane in the FH interface; 4.3: A list of supported sleep modes may be exposed to the O-DU320 by the O-RU330 via the M-Plane in the FH; 4.4: Support for ST4 C-Plane messages and related parameters (e.g., TRx control and ASM use cases, command ranges, etc.) may be exposed to O-DU320 by O-RU330 via M-Plane in FH.

[0067] 5: The O-DU320 may transfer the NES features supported by the O-DU and the necessary configurations / parameters to the SMO300.

[0068] Following steps 1-5 illustrated in Figure 3A, the O-DU capability may be exposed as follows:

[0069] 6: Features supported by O-DU may be requested by SMO300 from O-DU320 via a "get rpc call" for odu features on the O1 interface.

[0070] 7: The O-DU320 may expose NES support features (for TRx and ASM use cases) on the O1 interface.

[0071] 8: The O-DU capability may be requested by SMO300 from O-DU320 via a "get rpc call" for the odu capability on the O1 interface.

[0072] 9: The NES capability parameters may be exposed to the SMO300 via the O-DU320 on the O1 interface.

[0073] Following steps 6-9 illustrated in Figure 3A, data collection and monitoring may also occur for the SMO300 (as illustrated in Figures 3A-3B).

[0074] 10.1: A request for the collection of network performance data regarding energy saving (performance and file management) may be made by the SMO300 from the O-CU310 on the O1 interface.

[0075] The measured network data requested in 10.2:10.1 may be shared with the SMO300 by the O-CU310 over the O1 interface.

[0076] 10.3: A request for the collection of network performance data regarding energy saving (performance and file management) may be made by the SMO300 from the O-DU320 on the O1 interface.

[0077] The measured network data requested in 10.4:10.3 may be shared with the SMO300 by the O-DU320 over the O1 interface.

[0078] In a hierarchical deployment, network data from O-RU regarding energy saving may be obtained as follows (as illustrated in Figure 3B):

[0079] 10.5: A request for the collection of network performance data regarding energy saving (performance and file management) may be made by the SMO300 from the O-DU320 on the O1 interface.

[0080] 10.6: A data collection request for energy saving is sent to O-RU330.

[0081] 10.7: Measured network data (O-RU data for network energy saving in 10.6) may be shared with SMO300 by O-DU320 over the O1 interface.

[0082] Alternatively, if the deployment is a hybrid deployment instead, the alternative call flow for steps 10.5-10.7 is as follows:

[0083] 10.8: Network performance data collection requests for energy saving (performance and file management) are sent directly from the SMO300 to the O-RU330 over the FH interface.

[0084] 10.9: O-RU330 shares the network energy saving data requested in step 10.8 with SMO300 on the FH interface.

[0085] The SMO300 may decide to trigger energy saving based on the network energy saving data collected in the above steps. Thus, in the first case, the SMO300 may communicate with the O-CU as follows to trigger the NES use case.

[0086] 11.1: The SMO300 triggers an NES use case / feature, recommends the appropriate sleep mode (ASM) and antenna mask (TRx control), and sends a trigger to the O-CU310 on the O1 interface.

[0087] 11.2: O-DU320 activates energy saving / O-CU310 requests O-RU330 to activate energy saving on the F1 interface.

[0088] 11.3.1: O-DU320 instructs O-RU330 on the FH interface to activate an energy saving feature (TRx control or ASM).

[0089] 11.3.2: The response to the energy saving activation request is sent by the O-DU320 to the O-CU310 over the F1 interface.

[0090] In the second case, the SMO300 may trigger the NES use case together with the O-DU320. The steps may be as follows:

[0091] 11.4: The SMO300 triggers an NES use case / feature and recommends the appropriate sleep mode (ASM) and antenna mask (TRx control) to the O-DU320 on the O1 interface.

[0092] 11.5: The energy saving feature (TRx control / ASM) is activated on the FH interface based on a request sent from O-DU320 to O-RU330.

[0093] 11.6: The response to the energy saving activation request is sent to the SMO300 via the O1 interface by the O-DU320.

[0094] Next, referring to Figure 3C, energy saving data collection may be performed by the SMO300 to monitor the status of energy saving from the NES use case implementation.

[0095] In step 11.7, the SMO300 requests energy saving data from the O-DU320 via the O1 interface.

[0096] In step 11.8, the response to the energy saving data request is sent to the SMO300 by the O-DU320 over the O1 interface.

[0097] SMO300 may determine that energy saving should be terminated based on the energy saving data received in step 11.8. In the first case, a request may be sent by SMO300 to O-CU310 in the following steps:

[0098] In step 11.9, a request for energy saving termination may be sent from SMO300 to O-CU310 on the O1 interface.

[0099] In step 11.10, the energy saving termination request is forwarded by the O-CU310 to the O-DU320 over the F1 interface.

[0100] In step 11.11, an energy-saving deactivation request is sent by O-DU320 to O-RU330 over the FH interface.

[0101] In step 11.12, the response to the energy saving termination request is sent from O-DU320 to O-CU310 over the F1 interface.

[0102] In step 11.13, the response to the energy saving termination request is received by the SMO300 from the O-CU310 on the O1 interface.

[0103] In the second case, the request for energy saving termination is sent directly from the SMO300 to the O-DU320 in the following steps:

[0104] In step 11.14, a request for energy saving termination is sent from SMO300 to O-DU320 on the O1 interface.

[0105] In step 11.15, a request to deactivate energy saving is sent by O-DU320 to O-RU330 over the FH interface.

[0106] In step 11.16, the response to the energy saving termination request is sent to the SMO300 by the O-DU320 over the O1 interface.

[0107] Figure 3 is a more generalized call flow diagram intended to cover multiple use cases, and it should be understood that more specific call flows for specific use cases are discussed below in Figures 4-7.

[0108] Figures 4A-4C illustrate a call flow diagram for carrier and cell switch-off / on network energy saving according to one embodiment. SMO400, O-CU410, O-DU420, and O-RU430 are provided and may be the same as their counterparts described above.

[0109] In step 1, the O-RU430 may expose energy-saving capabilities (e.g., NES-related information), including carrier and cell switch-off / on related capabilities, to the O-DU420 over the FH M-Plane interface.

[0110] In step 2, the O-DU420 may expose its energy saving capabilities to the SMO400 over the O1 interface through its O-RU capabilities and carrier and cell switch-off / on related capabilities.

[0111] In step 3, the O-CU410 may expose its energy saving capabilities to the SMO400 over the O1 interface through carrier and cell switch-off / on related capabilities.

[0112] In step 4, the SMO400 may collect traffic load performance and energy consumption measurement results from the O-CU410 on the O1 interface.

[0113] In step 5, the SMO400 may collect traffic load performance and energy consumption measurement results from the O-DU420 on the O1 interface.

[0114] Subsequently, the SMO400 may analyze traffic load performance measurement results, available cell list / coverage requirements / coverage holes / UE distribution to determine whether or not to activate the NES use case.

[0115] In step 6, the SMO400 may decide to trigger the activation of the NES on the O1 interface, via the O1 interface (based on traffic and load measurement results, key performance indicators (KPIs), etc.), using carrier and cell switch off / on. This may also be based on coverage and throughput requirements, and may be determined using, for example, artificial intelligence / machine learning (AI / ML).

[0116] Energy saving activation may be performed in O-RU430 as follows:

[0117] In step 7.1, the SMO400 may send a trigger to the O-CU410 on the O1 interface to activate the carrier and cell switch-off / on use cases. The O-CU410 may decide to initiate a handover action (for example, moving the UE to a neighboring cell in terms of switch-off).

[0118] In step 7.2, O-CU410 may forward a request to deactivate / shut down the cell and associated carrier by sending appropriate attributes / parameters / controls to O-DU420 over the F1 interface.

[0119] In step 7.3, the O-DU420 may prepare to process carrier and cell switch-off based on a request from the SMO400 via the O-CU410.

[0120] In step 7.4, O-DU420 may send an "edit-rpc call" to O-RU430 to initiate carrier and cell switch-off: for example, <edit-rpc><[tr]x-array-carrier:active -> INACTIVE>

[0121] Next, referring to Figure 4B, in step 7.5, O-RU430 may set "[tr]x-array-carrier:state -> DISABLED".

[0122] In step 7.6, the O-RU430 may be in an energy-saving state.

[0123] In step 7.7, the O-DU420 may send an update to the O-CU410 on the F1 interface to indicate that the cell / carrier is being switched off / the power is being turned off.

[0124] In step 7.8, the O-DU420 may notify the SMO400 via a notification on the O1 interface that the energy saving state has changed / energy saving has been activated (for example, the power of the carriers and cells to be switched has been turned off).

[0125] In step 8, the SMO400 may collect traffic load performance and energy consumption measurement results from the O-CU410 on the O1 interface.

[0126] In step 9, the SMO400 may collect traffic load performance and energy consumption measurement results from the O-DU420 on the O1 interface.

[0127] SMO400 may analyze the traffic load performance measurement results. In step 10, SMO may decide to deactivate carrier and cell switch off / on use cases based on coverage and throughput requirements (e.g., using AI / ML), such as poor KPIs, increased traffic, or required capacity. This may be done on the O1 interface.

[0128] In step 11.1, energy saving deactivation in the O-RU may be triggered by the SMO400 and may be transmitted to the O-CU410 on the O1 interface to deactivate carrier and cell switch-off / on use cases.

[0129] In step 11.2, a request is sent from O-CU410 to O-DU420 on the F1 interface to reactivate / switch on the cell and associated carrier by sending the appropriate attributes / parameters / controls.

[0130] In step 11.3, O-DU420 may prepare to process carrier and cell switch-on based on requests sent from SMO400 through O-CU410.

[0131] In step 11.4, O-DU420 sends an "edit rpc call" to O-RU430 on the FH M-Plane interface (i.e., <edit-rpc><[tr]x-array-carrier:active -> ACTIVE>), you may start switching on the carrier and cell.

[0132] In step 11.5, O-RU430 may send "[tr]x-array-carrier:state -> Ready".

[0133] In step 11.6, the O-RU430 may return to normal operation.

[0134] In step 11.7, the O-DU420 may send an update to the O-CU410 on the F1 interface indicating that the cell / carrier has been switched on / powered on. The O-CU410 may then begin accepting handover requests from UEs in neighboring cells.

[0135] In step 11.8, the O-DU420 may send a notification to the SMO400 on the O1 interface to indicate that the energy saving state has changed / energy saving has been deactivated (carrier and cell have been switched / powered on).

[0136] Figures 5A to 5C illustrate a call flow diagram for TRx network energy saving according to one embodiment.

[0137] SMO500, O-CU510, O-DU520, and O-RU530 are provided and may be similar to their counterparts mentioned above.

[0138] In step 1, the O-RU530 may expose energy-saving capabilities, including TRx control-related capabilities (e.g., NES-related information), to the O-DU520 via the FH M-Plane interface.

[0139] In step 2, the O-DU520 may expose its energy saving capabilities to the SMO500 over the O1 interface through its O-RU capabilities and TRx control-related capabilities.

[0140] In step 3, the O-CU510 may expose its energy saving capabilities to the SMO500 over the O1 interface through its TRx control-related capabilities.

[0141] In step 4, the SMO500 may collect traffic load performance and energy consumption measurement results from the O-CU510 on the O1 interface.

[0142] In step 5, the SMO500 may collect traffic load performance and energy consumption measurement results from the O-DU520 on the O1 interface.

[0143] Subsequently, the SMO500 may analyze traffic load performance measurement results, available cell list / coverage requirements / coverage holes / UE distribution to determine whether or not to activate the NES use case.

[0144] In step 6, the SMO500 may decide to trigger the activation of the NES on the O1 interface, via the O1 interface (based on traffic and load measurement results, key performance indicators (KPIs), etc.), using TRx control. This may also be based on coverage and throughput requirements, and may be determined using, for example, artificial intelligence / machine learning (AI / ML).

[0145] Energy saving activation may be performed in O-RU530 as follows:

[0146] In step 7.1, the SMO500 may provide a policy or send a trigger to the O-CU510 to activate the TRx control use case on the O1 interface.

[0147] In step 7.2, the O-DU520 may prepare to process the TRx control configuration (synchronous signal block / system information block) (SSB / SIB) and other related parameters based on a request from the SMO500.

[0148] In step 7.3, O-DU520 may send an update to the SSB configuration on the F1 interface to O-CU510 by sending the appropriate parameters / attributes / information elements (IE). O-CU510 may then initiate a handover action (e.g., moving the UE to a neighboring cell).

[0149] In step 7.4, O-DU520 may send an ST4 C-Plane message containing TRx control-related parameters to O-DU530 over the FH C-Plane interface.

[0150] In step 7.5, O-RU530 may send an ACK / NACK message to O-DU520 on the FH C-Plane interface using the "ackNackReqID" field in the ST4 C-Plane message.

[0151] Next, referring to Figure 5B, in step 7.6, the O-RU530 may process the ST4 C-Plane message and put each RF channel / antenna element to sleep / mute / off.

[0152] In step 7.7, the O-DU520 may notify the SMO500 via a notification on the O1 interface that the energy saving state has changed / energy saving has been activated (current TRx control / antenna array configuration).

[0153] In step 7.8, the O-RU530 may be in an energy-saving state.

[0154] In step 8, the SMO500 may collect traffic load performance and energy consumption measurement results from the O-CU510 on the O1 interface.

[0155] In step 9, the SMO500 may collect traffic load performance and energy consumption measurement results from the O-DU520 on the O1 interface.

[0156] The SMO500 may analyze the traffic load performance measurement results. In step 10, the SMO500 may decide to switch to a baseline antenna array configuration or activate another TRx control (antenna array) configuration based on coverage and throughput requirements (e.g., using AI / ML), such as poor KPIs, increased traffic, or required capacity. This may be done on the O1 interface.

[0157] In step 11.1, the SMO500 may provide a policy or send a trigger to the O-DU520 on the O1 interface to activate other TRx control configurations or to switch to a baseline antenna array configuration.

[0158] In step 11.2, the O-DU520 may prepare to process the TRx control configuration (SSB / SIB and other related parameters) based on the request from the SMO in step 11.1.

[0159] In step 11.3, O-DU520 may send an ST4 C-Plane message containing TRx control-related parameters to O-RU520 over the FH C-Plane interface.

[0160] In step 11.4, O-RU530 may send an ACK / NACK message using the "ackNackReqID" field in the ST4 C-Plane message.

[0161] Next, referring to Figure 5C, in step 11.5, O-RU530 may process the ST4 C-Plane message from 11.3, wake up O-RU530, or turn on / not sleep / not mute each RF channel / antenna element.

[0162] In step 11.6, if there is an unguaranteed wake-up period, an ST8 "ready" message may be sent from O-RU530 to O-DU520 on the FH C-Plane interface.

[0163] In step 11.7, if the CU plane processing unit is switched off as part of sleep, the O-DU520 may send an emergency wake-up message to the O-RU530 on the FH M-Plane interface to interrupt the sleep.

[0164] In step 11.8, O-RU530 may send a notification to O-DU520 on the FH M-Plane interface in the case of an emergency wake-up request.

[0165] In step 11.9, the O-RU530 may operate normally, or it may enter other TRx control configurations and / or sleep mode.

[0166] In step 11.10, the O-DU520 updates the SSB configuration on the O-CU510 by sending the appropriate attributes / parameters / IE over the F1 interface.

[0167] In step 11.11, the O-DU520 may notify the SMO500 via a notification on the O1 interface that the energy saving state has changed / energy saving has been activated (for example, the O-RU530 has occurred or is continuing the TRx control (antenna array) configuration).

[0168] Figures 6A-6B illustrate call flow diagrams for a policy-based SMO / O-DU direct control or O-DU-driven TRx control implementation according to one embodiment. SMO600, O-DU620, and O-RU630 are provided and may be similar to their counterparts described above.

[0169] Referring to Figure 6A, in step 1, the O-RU630 may advertise a valid / supported TRx control antenna mask / antenna array configuration to the O-DU620 on the FH M-Plane.

[0170] In step 2, the O-DU620 may expose its O-RU capabilities and its own capabilities to the SMO600 over the O1 interface.

[0171] The carrier and cell may be configured and activated. In step 3, the O-DU620 exposes traffic / load performance measurements and KPIs to the SMO600.

[0172] In the first subcase, an M-plane-based TRx control use case implementation may be applied.

[0173] In step 4.1, the O-DU620 may configure a specific TRx control configuration on the O-RU630 over the FH M-Plane interface.

[0174] In step 4.2, O-RU630 may send a notification with appropriate parameters to O-DU620.

[0175] In step 4.3, the O-DU620 may send a notification to the SMO600 on the O1 interface to indicate whether the activation / deactivation of a particular TRx control configuration was successful.

[0176] In the second subcase, a TRx control use case based on a C-plane may be applied. In step 5.1, the O-DU620 activates / deactivates a specific TRx control configuration.

[0177] In other alternative cases, the O-RU630 does not advertise a valid / supported TRx control antenna mask in step 6 (on the FH M-Plane interface).

[0178] Therefore, in step 7, O-DU620 and SMO600 may recognize that any antenna mask combination / configuration is supported by O-RU for a particular [tr]x array conforming to O-RAN-WG4-MP-V13.0.

[0179] Two further subcases may apply. First, the SMO600 may directly configure the TRx control configuration. In step 8.1, the u-plane configuration may be sent from the SMO600 to the O-DU620 on the O1 interface in order for the O-DU620 to request activation on the O-RU630.

[0180] In step 8.2, O-DU620 configures a specific TRx control configuration on O-RU630 on the FH M-Plane.

[0181] In step 8.3, O-RU630 sends a notification with the appropriate parameters to O-DU620 on the FH M-Plane interface.

[0182] In step 8.4, the O-DU620 sends a notification to the SMO600 indicating whether the activation / deactivation of a specific TRx control configuration was successful.

[0183] Next, referring to Figure 6B, in the second subcase, an O-DU driven TRx control use case implementation based on a policy using M-Plane may be applied. In step 9.1, a u-plane configuration with a specific TRx control configuration may be transmitted by SMO600 on the O1 interface and requested to O-DU620 to activate it in O-RU630.

[0184] In step 9.2, policy processing may be performed by O-DU620 (for example, provided that the policy parameters for a specific TRx control activation / deactivation are met).

[0185] In step 9.3, O-DU620 may transmit the U-plane configuration to O-RU630 over the FH M-Plane interface.

[0186] In step 9.4, O-RU630 may send a notification with appropriate parameters to O-DU620 on the FH M-Plane interface.

[0187] In step 9.5, the O-DU may send feedback to the SMO600 based on the received policy to indicate whether the policy activation / deactivation was successful. Figures 7A-7C illustrate a call flow diagram for Advanced Sleep Mode (ASM) network energy saving according to one embodiment. The SMO700, O-CU710, O-DU720, and O-RU730 are provided and may be similar to their counterparts described above.

[0188] In step 1, O-RU730 may expose energy saving to O-DU720 on the FH M-Plane interface using ASM-related capabilities.

[0189] In step 2, the O-DU720 may expose its energy saving capabilities to the SMO700 over the O1 interface through its O-RU and ASM capabilities.

[0190] In step 3, the O-CU710 may expose its energy saving capabilities to the SMO700 over the O1 interface through its ASM-related capabilities.

[0191] In step 4, the SMO700 may collect traffic load performance and energy consumption measurement results from the O-CU710 on the O1 interface.

[0192] In step 5, the SMO700 may collect traffic load performance and energy consumption measurement results from the O-DU720 on the O1 interface.

[0193] The SMO700 may analyze traffic load performance measurement results, available cell list / coverage requirements / coverage holes / UE distribution. In step 6, the SMO700 may decide to activate an ASM use case on the O1 interface (e.g., based on traffic and load measurement results, KPIs, etc.) based on coverage and throughput requirements (e.g., using AI / ML).

[0194] In step 7.1, the SMO700 may provide a policy or send a trigger to the O-DU720 to activate the ASM use case on the O1 interface.

[0195] In step 7.2, the O-DU720 may prepare to process the sleep mode (SSB / SIB and other related parameters) based on the request from the SMO700.

[0196] In step 7.3, O-DU720 may stop sending the SSB configuration in O-CU710 to O-CU710 on the F1 interface by sending the appropriate attributes / parameters / IE, or it may update it on the F1 interface. O-CU710 may initiate a handover action (for example, moving the UE to a neighboring cell (applicable only to sleep mode which puts the entire O-RU730 to sleep)).

[0197] In step 7.4, the O-DU720 may send an ST4 C-Plane message containing sleep mode-related parameters to the O-RU over the FH C-Plane interface.

[0198] In step 7.5, O-DU720 sends an ACK / NACK message to O-RU730 on the FH C-Plane interface, using the "ackNackReqID" field in the ST4 C-Plane message.

[0199] Next, referring to Figure 7B, in step 7.6, O-RU730 may process the ST4 C-Plane message from step 7.4, or it may put the entire O-RU or each of its components / elements to sleep / off.

[0200] In step 7.7, the O-DU720 may notify the SMO700 via the O1 interface that the energy saving state has changed / energy saving has been activated (sleep mode is ongoing).

[0201] In step 8, the SMO700 collects traffic load performance and energy consumption measurement results from the O-CU710 on the O1 interface.

[0202] In step 9, the SMO700 collects traffic load performance and energy consumption measurement results from the O-DU720 on the O1 interface.

[0203] The SMO700 may analyze the load performance measurement results received in steps 8 and 9 and decide in step 10 to terminate NES saving on the O1 interface. In particular, the SMO700 may decide to wake up the O-RU730, extend the ongoing sleep mode, or activate another sleep mode based on coverage and throughput requirements (e.g., using AI / ML), such as poor KPIs, increased traffic / required capacity.

[0204] In step 11.1, the SMO700 may initiate deactivating energy saving by providing a policy or sending a trigger to the O-DU720 on the O1 interface in order to wake up the O-RU730 or extend / activate another sleep mode.

[0205] In step 11.2, the O-DU720 may prepare to process the sleep mode (SSB / SIB and other related parameters) based on the request from the SMO700.

[0206] In step 11.3, O-DU720 sends an ST4 C-Plane message to O-RU730 on the FH C-Plane interface, containing sleep mode-related parameters (wake-up / extended sleep / other sleep modes).

[0207] In step 11.4, the O-RU730 sends an ACK / NACK message on the FH C-Plane interface using the "ackNackReqID" field in the ST4 C-Plane message.

[0208] Next, referring to Figure 7C, in step 11.5, O-RU730 may process the ST4 C-Plane message from step 11.3, wake up O-RU730, or put each component into an appropriate sleep mode.

[0209] In step 11.6, if there is an unguaranteed wake-up period, an ST8 "ready" message may be sent from O-RU730 to O-DU720 on the FH C-Plane interface.

[0210] In step 11.7, if the CU plane processing unit is switched off as part of sleep, O-DU720 may send an emergency wake-up message to O-RU730 on the FH M-Plane interface to interrupt sleep.

[0211] In step 11.8, O-RU730 may send a notification to O-DU720 on the FH M-Plane interface in the case of an emergency wake-up request.

[0212] In step 11.9, the O-RU730 may operate normally, or it may enter other TRx control configurations and / or sleep mode.

[0213] In step 11.10, O-DU720 may prepare, stop, or update the SSB configuration on O-CU710 by sending the appropriate attributes / parameters / IE over the F1 interface. O-CU710 may begin accepting handover requests from UEs in neighboring cells (applicable only to sleep mode which puts the entire O-RU to sleep).

[0214] In step 11.11, the O-DU720 may notify the SMO700 via a notification on the O1 interface that the energy saving state has changed (for example, the O-RU730 has woken up, the ongoing sleep mode has been extended, or it is in another sleep mode).

[0215] Figure 8 is a block diagram of an example of a data structure for gNB-DU(O-DU) / gNB-CU(O-CU)IM / DM to support network energy saving according to one embodiment. In some embodiments, gNB-DU(O-DU) / gNB-CU(O-CU)IM / DM may be configured to support network energy saving through NES management function and CES management function inheritance. Figure 8 illustrates various instances of network energy saving using NES management function containment.

[0216] Figure 9 is a block diagram of an example data structure for O-DU network energy saving according to one embodiment. According to the embodiment, network energy saving may be performed using carrier switch-off or on-use case objects. As illustrated in Figure 9, in the case of the CES management function defined in 3GPP, the CES management function may be reused to configure a cell using O-CU. In the O-RAN specific IOC "NESManagementFunction", the NES management function may be included in the 3GPP "NRSectorCarrier" to provide an SMO for enabling or disabling carriers in the O-RU. According to the embodiment, this enabling or disabling of carriers in the O-RU may be performed using the attribute "carrierActivationTime". However, in the case of the O-RU, the [tr]x array may be mapped with the [tr]x array carrier, and may be mapped with the 3GPP objects "NRSectorCarrier" and "NRCellDU". The "CarrierSwitchOffOn" use case object may be used in conjunction with the attributes "csSwitch", "csState", "csControl", and "csPolicy" included in the NES management function to enable or disable the [tr]x array carrier in O-RU.

[0217] Figure 10 is a block diagram of an example data structure for O-DU network energy saving using TRx control according to one embodiment. Referring to Figure 10, network energy saving may be performed using a TRx control use case object. In some instances, cells may be affected, in which case "NESManagementFunction" may be included under "NRCellDU". "NESManagementFunction" may include "RFChannelSwitchOffOn" with attributes "trxCtrlSwitch", "trxCtrlState", "trxCtrlPolicy", and "dataLayerControl". "RFChannelSwitchOffOn" may include a sub-use case object of TRx control with attributes such as (but not limited to) a list of supported TRx control configurations (antenna mask values) and associated sleep modes.

[0218] Figure 11 is a block diagram of an example of a data structure for O-DU network energy saving using advanced sleep mode according to one embodiment. Cells affecting "NESManagementFunction" may be included under "NRCellDU". In such instances, "NESManagementFunction" may include an "AdvancedSleepMode" use case object with attributes such as (but not limited to) "asmSwitch", "asmState", and "asmPolicy". "AdvancedSleepMode" may include a child object "ASMControl" which may include attributes for network energy saving such as a list of supported sleep modes, activation time, and data direction.

[0219] Figure 12 is a block diagram of an example data structure for O-CU network energy saving according to one embodiment. Figure 12 illustrates a high-level overview of network energy saving using gNB-CU(O-CU)IM / DM. In some embodiments, sub-use cases for handling each NES use case may be defined under "NESManagementFunction".

[0220] Figure 13 is a block diagram of an example of a data structure for direct TRx control by O-DU using M-Plane, according to one embodiment.

[0221] As shown in Figure 13, the O-RU may advertise supported TRx control masks using the "o-ran-uplane-conf.yang" module for exposure of O-RU capabilities in the fronthaul M-Plane. There may be a list of TRx control configurations supported by the O-RU, which may be reported along with the corresponding mask names and antenna masks. The absence of a list of "supported-trx-control-masks" may indicate that any combination of antenna masks may be supported by the O-RU for a particular [tr]x array. In some instances, if the O-DU does not find "supported-trx-control-masks", the O-DU may configure any mask, and the O-DU may deactivate or activate any particular TRx path / antenna array element by not configuring or removing "low-level-[tr]x-links / low-level-[tr]x-endpoint". As shown in Figure 13, the O-DU may or may not configure specific "low-level-[tr]x-links / low-level-[tr]x-endpoints" associated with "static-low-level-[tr]x-endpoints" (TRx paths / antenna arrays) to provision TRx control. "low-level-[tr]x-links" associated with [tr]x array carriers may also be mapped directly to "low-level-[tr]x-endpoints" for TRx control.

[0222] The data models described in Figures 8-13 are examples, and it should be understood that structural differences and name changes may be made by those skilled in the art depending on the specific implementation use case.

[0223] Figure 14 is a flowchart of an example of a method 1400 for implementing Rx control by direct SMO / O-DU control according to one embodiment.

[0224] In operation S1401, the O-DU may transmit NES information to the SMO. According to the embodiment, the network energy saving (NES) information may include at least one of network traffic, load performance measurement results, and key performance indicators (KPIs).

[0225] According to one embodiment, the O-DU may receive supported TRx control antenna masks and antenna array configurations from the O-RU. The NES information further comprises supported TRx control antenna masks and antenna array configurations. The O-DU and SMO are only permitted to configure the TRx control configuration to include supported TRx control antenna masks and antenna array configurations.

[0226] According to the embodiment, the NES information does not include an antenna mask or antenna array configuration, and the O-DU and SMO are permitted to configure the TRx control configuration to use any antenna mask and antenna array configuration.

[0227] In operation S1402, the O-DU may receive a message indicating when the TRx control configuration should be applied to the O-RU. According to one embodiment, the message comprises a U-plane configuration indicating a specific TRx control configuration. According to another embodiment, the message may be a policy indicating a specific TRx control configuration.

[0228] In operation S1403, the O-DU may configure the TRx configuration on the O-RU on the FH interface for the M-Plane or C-Plane based on the message received from operation S1402. According to one embodiment, if the message has a U-plane configuration, configuring the TRx control configuration involves the O-DU applying a specific TRx control configuration to the O-RU.

[0229] According to one embodiment, if a message includes a policy, configuring the TRx configuration involves processing the policy so that the O-DU obtains the parameters of the TRx control configuration, and then applying a specific TRx control configuration to the O-RU using the O-DU based on the obtained parameters.

[0230] In Operation S1404, the O-DU may send a notification indicating whether the TRx configuration activation was successful.

[0231] According to the embodiment, class definitions, class definition attributes, and class definition constraints may be provided. Various class definitions are described below.

[0232] CESManagementFunction < <ioc>>: This Information Object Class (IOC) may provide attributes that may be necessary to configure cells and cooperate with O-DUs to configure associated carriers to save energy using cell and carrier switch-off / on use cases. Attributes and attribute constraints are defined in accordance with 3GPP TS 28.541.

[0233] NESManagementFunction < <ioc>> is an O-RAN-specific class that may provide the attributes necessary to configure the O-DU to work with the O-RU for energy saving feature implementation. The attributes are given in Table 1A and may include attributes inherited from managed entities, as defined in 3GPP TS 28.622, item 4.3.20 and 3GPP TS 32.602, item 6.3.2. [Table 1A]

[0234] The attribute constraints for NES management functions are shown in Table 1B. [Table 1B]

[0235] CarrierSwitchOffOn <ioc>>: This IOC may provide attributes that may be necessary to configure the O-DU to work with the O-RU to enable or disable the "CarrierSwitchOffOn" use case object. The attributes may be inherited from the O-RAN specific "NESManagementFunction" IOC and may include the following attributes as shown in Tables 2A and 2B. [Table 2A] [Table 2B]

[0236] Attribute constraints may include the following, as shown in Tables 3A and 3B: [Table 3A] [Table 3B]

[0237] CSControl < <ioc>>: This IOC may provide attributes that may be necessary to configure the O-DU to work with the O-RU for carrier deactivation to achieve energy savings. The attributes may be inherited from the O-RAN-specific "CarrierSwitchOffOn" IOC and may include the following attributes as shown in Table 4. [Table 4]

[0238] RFChannelSwitchOffOn: This IOC may provide attributes that may be necessary to configure the O-DU to work with the O-RU to enable or disable the TRx control sub-use case for energy saving. The attributes may be inherited from the "NESManagementFunction" IOC and may include the following attributes as shown in Tables 5A and 5B. [Table 5A] [Table 5B]

[0239] The attribute constraints for "RFChannelSwitchOffOn" are shown in Tables 6A and 6B. [Table 6A] [Table 6B]

[0240] TRXControl: This IOC may provide attributes that may be necessary to configure the O-DU to work with the O-RU to activate or deactivate a specific TRX control configuration with relevant parameters for energy saving. In some embodiments, the TRX control configuration may be represented as the antenna array configuration. The attributes may be inherited from the "RFChannelSwitchOffOn" IOC and may include the following attributes as shown in Tables 7A and 7B. [Table 7A] [Table 7B]

[0241] The attribute constraints for "TRXControl" are shown in Tables 8A and 8B. [Table 8A] [Table 8B]

[0242] Advanced Sleep Modes < <ioc>>: This IOC may provide attributes that may be necessary to configure the O-DU to work with the O-RU to enable or disable advanced sleep mode use cases in order to achieve energy saving. The attributes may be inherited from the "NESManagementFunction" IOC and may include the following attributes as shown in Table 9. [Table 9]

[0243] AdvancedSleepMode < <ioc>The attribute constraints for ">" are shown in Table 10. [Table 10]

[0244] ASMControl < <ioc>>: This IOC may provide attributes that may be necessary to configure the O-DU to work with the O-RU to activate or deactivate specific sleep mode use cases in order to achieve energy saving. The attributes may be inherited from the "AdvancedSleepMode" IOC and may include the following attributes as shown in Table 11. [Table 11]

[0245] "ASMControl < <ioc>The attribute constraints for ">" are shown in Table 12. [Table 12]

[0246] According to the embodiment, an example of an O-DU data model is as follows: module: o-ran-o-du-nes.yang augment / me3gpp:ManagedElement / gnbdu3gpp:GNBDUFunction: NRCellDU or NRSectorCarrier: +--rw NESManagementFunction* enumeration +--rw id string +--rw attributes +--rw esNotAllowedTimePeriod? string +--rw trxCtrlSwitch* +--rw trxCtrlState* +--rw asmSwitch* +--rw asmState* +--rw CarrierSwitchOffOn* +--rw id string +--rw attributes +--rw csSwitch* string +--rw csState* string +--rw csPolicy* string +--rw CSControl* enumeration +--rw id string +--rw attributes +--rw carrierDeactivationTime? string +--rw RFChannelSwitchOffOn* enumeration +--rw id string +--rw attributes +--rw trxCtrlSwitch* string +--rw trxCtrlState* string +--rw trxCtrlPolicy* string +--rw TRXControl* enumeration +--rw id string +--rw attributes +--rw dataDir uint8 +--rw maskName ? string +--rw antennaMaskValues ? uint16 / string +--rw trxcMode0 ? string +--rw trxcMode1 ? string +--rw trxcMode2 ? string +--rw trxcMode3 ? string +--rw maskActivationTime ? string +--rw sleepModeActivationTime ? string +--rw dataLayerConfig string +--rw AdvancedSleepMode* enumeration +--rw id string +--rw attributes +--rw asmSwitch* string +--rw asmState* string +--rw asmPolicy* string +--rw ASMControl* enumeration +--rw id string +--rw attributes +--rw dataDir uint8 +--rw sleepMode0 ? string +--rw sleepMode1 ? string +--rw sleepMode2 ? string +--rw sleepMode3 ? string +--rw sleepModeActivationTime ? string

[0247] In some embodiments, some of the O-RAN WG4 defined YANG models may be optional to support optional capabilities. For example, if a device does not return a namespace associated with the optional O-RAN WG4 defined YANG model, the NETCONF client may infer that the device does not support the optional capabilities associated with the O-RAN WG4 defined YANG model. The optional O-RAN WG4 namespaces are shown in Table 13. [Table 13] JPEG2026534285000022.jpg179170

[0248] In some embodiments, some of the O-RAN WG5 defined YANG models may define optional feature support. The optional multi-vendor features defined in the O-RAN WG5 defined YANG model are shown in Table 14 below. [Table 14]

[0249] In some other embodiments, in addition to optional namespaces and optional features within the supported namespaces, a specific O-RAN WG5 defined YANG model may be defined, which is used to expose support for certain optional capabilities by O-DU. Optional capabilities in the O-RAN WG5 defined YANG model are shown in Table 15. [Table 15] JPEG2026534285000025.jpg78170

[0250] In some embodiments, various performance counters for O-CU are given below. In some embodiments, DLPDCP SDU data volume measurements per F1-U interface are shown in Table 16. This measurement may provide the downlink data volume (amount of PDCP SDU bits) delivered from GNB-CU-UP to GNB-DU (F1-U interface), external gNB-CU-UP (Xn-U interface), and external eNB (X2-U interface). This measurement may be calculated per QoS level (5QI or QCI mapped in NR option 3) and per S-NSSAI (Single-Network Slice Selection Assistance Information), per S-NSSAI and per PLMN ID (Public Land Mobile Network Identifier), and may be reported per interface (F1-U, Xn-U, X2-U). This measurement may include channel configuration (CC).

[0251] Furthermore, in some embodiments, this measurement may be obtained by counting the number of DL PDCP SDU bits sent to the GNB-DU (F1-U interface), sent to the external gNB-CU-UP (XnU interface), sent to the external eNB (X2-U interface). This measurement is performed in the GNB-CU-UP for each QoS level (5QI or QCI mapped in NR option 3) and each S-NSSAI, and each S-NSSAI and PLMN ID, and is reported for each interface (F1-U, Xn-U, X2-U).

[0252] Furthermore, in some embodiments, each measurement may be an integer value representing the number of bits measured in megabits, where 1 megabit = 1000 * 1000 bits. The number of measurements is equal to the sum of the number of QoS levels per interface, the number of S-NSSAIs per interface, and the number of PLMN IDs.

[0253] Furthermore, in some embodiments, the measurement name may be in the form of "DRB.F1uPdcpSduVolumnDL_Filter". The filter may be a combination of PLMN ID, QoS level, and S-NSSAI (i.e., FI-U interface measurement and Xn-U interface measurement). In some other embodiments, the filter may be a combination of PLMN ID and QoS level (i.e., X2-U interface measurement). PLMN-ID may represent a PLMN ID, QoS may represent a mapped SQI or QCI level, and SNSSAI may represent an S-NSSAI.

[0254] In some embodiments, EP_F1U (F1U interface), EP_XnU (Xn-U interface), and EP_X2U (X2-U interface) may be included.

[0255] In some embodiments, this measurement may also be valid for packet switching traffic. In some embodiments, it may also be applicable to 5GS.

[0256] In some embodiments, some uses may be aimed at ensuring performance in the integrity area (user plane connection quality) within the energy efficiency (EE) area. [Table 16] JPEG2026534285000027.jpg232170

[0257] Artificial intelligence / machine learning (AI / ML) models are shown in Table 17. [Table 17]

[0258] In some embodiments, the UL PDCP SDU data volume per F1-U interface is shown in Table 18. This measurement may provide the uplink data volume (amount of PDCP) delivered from the GNB-DU (F1-U interface), external gNB-CU-UP (Xn-U interface), and external eNB (X2-U interface) to the GNB-CU-UP. This measurement may be calculated per QoS level (5QI or QCI mapped in NR option 3) and per S-NSSAI, per S-NSSAI and per PLMN ID, and may be reported per interface (F1-U, Xn-U, X2-U). This measurement may include CC. In some embodiments, UL is abbreviated as uplink and DU as downlink.

[0259] Further, in some embodiments, this measurement may be obtained by counting the number of UL PDCP SDU bits entering the GNB-CU-UP from the GNB-DU (F1-U interface), the external gNB-CU-UP (XnU interface), and the external eNB (X2-U interface). This measurement is performed in the GNB-CU-UP for each QoS level (5QI or QCI mapped in NR Option 3), each S-NSSAI, and each PLMN ID, and reported for each of the interfaces (F1-U, Xn-U, X2-U).

[0260] Further, in some embodiments, each measurement may be an integer value representing the number of bits measured in megabits, where 1 megabit = 1000*1000 bits. The number of measurements is equal to the sum of the number of QoS levels per interface, the number of S-NSSAIs per interface, and the number of PLMN IDs.

[0261] Further, in some embodiments, the measurement name may be in the form of "DRB.F1uPdcpSduVolumnUL_Filter". The filter may be a combination of PLMN ID, QoS level, and S-NSSAI (i.e., F1-U interface measurement and Xn-U interface measurement). In some other embodiments, the filter may be a combination of PLMN ID and QoS level (i.e., X2-U interface measurement). PLMN-ID may represent the PLMN-ID, QoS may represent the mapped 5QI or QCI level, and SNSSAI may represent the S-NSSAI.

[0262] Some embodiments may include EP_F1U (F1U interface), EP_XnU (Xn-U interface), and EP_X2U (X2-U interface).

[0263] In some embodiments, this measurement may be valid for packet-switched traffic. In some embodiments, this may be applicable to 5GS.

[0264] In some embodiments, some uses may be aimed at ensuring performance in the integrity area (user plane connection quality) within the energy efficiency (EE) area. [Table 18] JPEG2026534285000030.jpg237170

[0265] The artificial intelligence / machine learning (AI / ML) models for UL PDCP SDU are shown in Table 19. [Table 19]

[0266] Various exemplary embodiments illustrating various performance counters for O-DU are given below. In some embodiments, reference signal reception quality (RSRQ) measurements are shown in Table 20. This measurement may provide a distribution of SS-RSRQ, which may be received by the gNB from the UE in the cell. Periodic UE measurements may be reported to all UEs, which may need to be triggered by the gNB in ​​the New Radio cell being measured (see also TS 28.331

[20] ). This measurement may include CC.

[0267] In some embodiments, when the RSRQ value is reported by the UE, and when RSRQ is used for the "MeasQuantityResults" IE in the "resultsSSB-Cell" IE within the "measResult" IE, as configured by a measurement report configuration as defined in TS 38.331

[20] , this measurement may be obtained by incrementing an appropriate measurement bin using the measured quantity value (see also Table 10.1.11.1-1 in TS 28.133

[35] , and item 5.1.3 SS reference signal reception quality (SS-RSRQ) in 38.215

[34] ).

[0268] In some embodiments, this measurement may be a set of integers. This measurement may include "MR.NRScSSRSRQ.BinX", where X may represent a range of measurement quality SS-RSRQ values ​​(-43 to 20 dB). In some cases, the number and range of bins may be left to the implementation. This measurement may include "NRCellCU". In some embodiments, this measurement may be valid for packet switch traffic. In some embodiments, this measurement may be applicable in 5GS. [Table 20] JPEG2026534285000033.jpg204170

[0269] The AI / ML models for RSRQ measurement are shown in Table 21. [Table 21]

[0270] In some embodiments, RSRP measurements are shown in Table 21. This measurement may provide a distribution of SS-RSRP per SSB, which may be received by the gNB from the UE in the cell when RSRP is used, for L1-RSRP configured by a reporting configuration as defined in TS 38.214

[33] , if the L1-RSRP reporting function is enabled (see TS 28.215

[34] ). This measurement may include CC.

[0271] In some embodiments, when the RSRP value is reported by the UE, and when SS-RSRP is used for an L1-RSRP configuration as defined in TS 38.214

[33] , this measurement may be obtained by incrementing the appropriate measuring bin using the measured quantity value (see also Table 10.1.6.1-1 in TS 38.133

[35] ).

[0272] In some embodiments, each subcounter of the RSRP measurement may be an integer. This measurement may include "L1M.SS-RSRP.Bin," where Bin may represent the range of the reported SS-RSRP value (0-127 dBm). In some cases, the number and range of bins may be left to the implementation. This measurement may include beams. In some embodiments, this measurement may be valid for packet switch traffic. In some embodiments, this measurement may be applicable in 5GS. In some embodiments, one use of this performance measurement is to support a Message Delivery Agent (MDA). [Table 22] JPEG2026534285000036.jpg188170

[0273] The AI / ML models for RSRQ measurement are shown in Table 23. [Table 23]

[0274] In some embodiments, the SS-RSRP distribution per SSB is shown in Table 24. This measurement may provide the distribution of SS-RSRP per SSB for neighboring New Radio (NR) cells received from the gNB from the UE when SS-RSRP is used, for L1-RSRP configured by a reporting configuration such as that defined in TS 38.214

[33] , if the L1-RSRP reporting function is enabled (see TS 38.215

[34] ). This measurement may include CC.

[0275] In some embodiments, this measurement may be obtained by incrementing the appropriate measurement bin using the measured quantity value (see also Table 10.1.6.1-1 in TS 38.133

[35] ). The RSRP value for the SSB beam of a nearby NR cell may be reported to the gNB by the UE via a Radio Resource Control (RRC) measurement report message (see TS 38.331

[20] ).

[0276] In some embodiments, each subcounter in this SS-RSRP distribution may be an integer. In some embodiments, this measurement may include "L1M.SS-RSRPNrNbr.SSBIndex.Bin", where SSBIndex identifies the SSB beam of a neighboring NR cell and Bin represents the range (0-127) of the reported SS-RSRP value. The number of bins and the range for each bin may be left to the implementation. In some embodiments, this measurement may include "NRCellRelation". In some embodiments, this measurement may be valid for packet switching traffic. In some embodiments, this may be applicable to 5GS. In some embodiments, one use of this performance measurement is to support MDA. [Table 24] JPEG2026534285000039.jpg186170

[0277] The AI / ML models for the SS-RSRP distribution are shown in Table 25. [Table 25]

[0278] In some embodiments, the RSRP distribution for each neighboring E-ULTRA cell is shown in Table 26. This measurement may provide an RSRP distribution of neighboring E-ULTRA cells that may be received by the gNB from the UE (see 38.331

[20] ). This measurement may include CC. This measurement may be obtained by incrementing the appropriate measurement bin using the measured quantity value (see also Table 10.1.6.1-1 in TS 28.133

[35] ) when the UE reports the RSRP value for neighboring E-ULTRA cells to the gNB via an RRC measurement report message (see TS 38.331

[20] ).

[0279] In some embodiments, each subcounter in the RSRP distribution may be an integer. In some embodiments, this measurement may include "L1M.RSRPEultraNbr.Bin," where Bin represents the range (-97) of the reported RSRP value. The number of bins and the range for each bin are left to the implementation. In some embodiments, this measurement may include "EUtranCellRelation." In some embodiments, this measurement may be valid for packet switching traffic. In some embodiments, it may be applicable to 5GS. In some embodiments, one use of this performance measurement is to support MDA. [Table 26] JPEG2026534285000042.jpg148170

[0280] The AI / ML models for the RSRP distribution are shown in Table 27. [Table 27]

[0281] In some embodiments, SNIR measurements are shown in Table 28. This measurement may provide a distribution of SS-SNIR that may be received by the gNB from the UE in the cell. Periodic UE measurements report to all UEs in the New Radio cell being measured (see also 38.331

[20] ), which may need to be triggered by the gNB. This measurement may include CC. When the SNIR value is reported by the UE, and when the SNIR is used for the "MeasQuantityResults" IE in the "resultsSSB-Cell" IE within the "measResult" IE, which is configured by a measurement report configuration as defined in TS 38.331

[20] , this measurement may be obtained by incrementing the appropriate measurement bin using the measured quantity value (see also Table 10.1.6.1-1 in TS 38.133

[35] ).

[0282] In some embodiments, each subcounter of the SINR measurement may be an integer. In some embodiments, this measurement may include "MR.NRScSSSINR.BinX", where X represents the range of the measured quantity SS-SNIR value (-23 to 40 dB). The number of bins and the range for each bin are left to the implementation. In some embodiments, this measurement may include "NRCellCU". In some embodiments, this measurement may be valid for packet switching traffic. In some embodiments, it may be applicable to 5GS. [Table 28] JPEG2026534285000045.jpg173170

[0283] The AI / ML models for SNIR measurements are shown in Table 29. [Table 29]

[0284] Based on the embodiments described above, an SMO-based NES approach using the O1 interface may enable more optimized network-wide energy consumption, improved automation, and more optimized resource allocation, as decision-making can be made using real-time data and / or predictive analytics to tune the power profile.

[0285] Figure 15 is a diagram of an example environment 1500 in which the system and / or method described herein may be implemented. As shown in Figure 15, the environment 1500 may include a user device 1510, a platform 1520, and a network 1530. The devices in environment 1500 may be interconnected via wired connections, wireless connections, or a combination of wired and wireless connections. In embodiments, any functions and operations described above with reference to Figures 2-14 may be performed by any combination of the elements illustrated in Figure 15.

[0286] User device 1510 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information related to platform 1520. For example, user device 1510 may include computing devices (e.g., desktop computers, laptop computers, tablet computers, handheld computers, smart speakers, servers, etc.), mobile phones (e.g., smartphones, wireless phones), wearable devices (e.g., smart glasses or smartwatches), or similar devices. In some implementations, user device 1510 may receive information from and / or transmit information to platform 1520.

[0287] Platform 1520 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information. In some implementations, Platform 1520 may include a cloud server or a group of cloud servers. In some implementations, Platform 1520 may be designed to be modular so that certain software components can be swapped (in or out) depending on specific needs. Thus, Platform 1520 may be easily and / or quickly reconfigured for different applications.

[0288] In some implementations, as shown, platform 1520 may be hosted in a cloud computing environment 1522. Although the implementations described herein describe platform 1520 as being hosted in a cloud computing environment 1522, in some implementations, platform 1520 may not be cloud-based (i.e., it may be implemented outside a cloud computing environment) or may be partially cloud-based.

[0289] The cloud computing environment 1522 includes an environment that hosts platform 1520. The cloud computing environment 1522 may provide services that do not require end-user (e.g., user device 1510) knowledge of the physical location and configuration of the systems and / or devices that host platform 1520, such as computation, software, data access, and storage. As shown, the cloud computing environment 1522 may also include a group of computing resources 1524 (collectively referred to as “computing resources 1524” and individually as “computing resources 1524”).

[0290] Computing resource 1524 includes one or more personal computers, a cluster of computing devices, a workstation computer, a server device, or other types of computation and / or communication devices. In some implementations, computing resource 1524 may host platform 1520. Cloud resources may include compute instances running in computing resource 1524, storage devices provided in computing resource 1524, data transfer devices provided by computing resource 1524, etc. In some implementations, computing resource 1524 may communicate with other computing resources 1524 via wired connections, wireless connections, or a combination of wired and wireless connections.

[0291] As further shown in Figure 15, the computing resource 1524 includes a group of cloud resources such as one or more applications ("APP") 1524-1, one or more virtual machines ("VM") 1524-2, virtualized storage ("VS") 1524-3, and one or more hypervisors ("HYP") 1524-4.

[0292] Application 1524-1 includes one or more software applications that may be provided to or accessed by the user device 1510. Application 1524-1 may eliminate the need to install and run software applications on the user device 1510. For example, Application 1524-1 may include any other software that can be provided via the platform 1520 and its associated software and / or the cloud computing environment 1522. In some implementations, one application 1524-1 may send and receive information to and from one or more other applications 1524-1 via a virtual machine 1524-2.

[0293] The virtual machine 1524-2 includes a software implementation of a device (e.g., a computer) that runs a program like a physical device. Depending on the degree to which the virtual machine 1524-2 is used and its correspondence to any real-world device, the virtual machine 1524-2 may be a system virtual machine or a process virtual machine. A system virtual machine may provide a complete system platform that supports the execution of a complete operating system ("OS"). A process virtual machine may run a single program or support a single process. In some implementations, the virtual machine 1524-2 may run on behalf of a user (e.g., a user device 1510) and manage the infrastructure of a cloud computing environment 1522, such as data management, synchronization, or long-duration data transfer.

[0294] Virtualized storage 1524-3 includes one or more storage systems and / or devices of one or more devices or computing resources 1524 that use virtualization technology within the storage systems. In some implementations, within the context of the storage system, the types of virtualization may include block virtualization and file virtualization. Block virtualization may represent an abstraction (or isolation) of logical storage from physical storage so that the storage system may be accessed without considering the physical storage or heterogeneous structure. Isolation can provide administrators of the storage system with flexibility in managing storage for end users. File virtualization may remove the dependency between data accessed at the file level and the location where the files are physically stored. This may enable optimized storage usage, server consolidation, and / or performance of non-destructive file migration.

[0295] The hypervisor 1524-4 may provide hardware virtualization technology that enables multiple operating systems (e.g., "guest operating systems") to run simultaneously on a host computer such as computing resource 1524. The hypervisor 1524-4 may present a virtual operating platform to the guest operating systems and may manage the execution of the guest operating systems. Multiple instances of various operating systems may share virtualized hardware resources.

[0296] Network 1530 includes one or more wired and / or wireless networks. For example, Network 1530 may include cellular networks (e.g., 5G networks, LTE (long-term evolution) networks, 3G networks, CDMA (code division multiple access) networks, etc.), PLMN (public land mobile network), local area networks (LANs), wide area networks (WANs), MAN (metropolitan area networks), telephone networks (e.g., PSTN (Public Switched Telephone Networks), private networks, ad hoc networks, intranets, the Internet, fiber optic networks, etc.), and / or combinations of these or other types of networks.

[0297] The number and arrangement of devices and networks shown in Figure 15 are provided as an example. In practice, there may be additional devices and / or networks, fewer devices and / or networks, different devices and / or networks, or devices and / or networks in different arrangements than those shown in Figure 15. Furthermore, two or more devices shown in Figure 15 may be implemented within a single device, and a single device shown in Figure 15 may be implemented as multiple distributed devices. In addition or alternatively, a set of devices in environment 1500 (e.g., one or more devices) may perform one or more functions described as being performed by other sets of devices in environment 1500.

[0298] Figure 16 illustrates one embodiment of device 1600. As shown in Figure 16, device 1600 may include a processor 1610, memory 1620, storage component 1630, input component 1640, output component 1650, communication interface 1660, and bus 1670.

[0299] The processor 1610 as used herein means any type of arithmetic circuit that may include hardware and software elements. The processor 1610 may be embodied as a multicore processor, a single-core processor, a combination of one or more multicore processors and / or one or more single-core processors, a distributed processing system, etc. The processor 1610 may also be a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), an ASIC (application-specific integrated circuit), or other types of processing components.

[0300] Memory 1620 includes a non-temporary computer-readable medium. Memory 1620 includes random access memory (RAM), read-only memory (ROM), and / or other types of dynamic or static storage devices (e.g., flash memory, magnetic memory, and / or optical memory) for storing information and / or instructions for use by processor 1610. Memory 1620 is provided with machine-readable instructions that can be executed by processor 1610. When these machine-readable instructions are executed by processor 1610, they cause processor 1610 to perform one or more method steps of the embodiment described above.

[0301] The storage component 1630 stores information and / or software related to the operation and use of device 1600. For example, the storage component 1630 may include, along with a corresponding drive, a hard disk (e.g., magnetic disk, optical disk, magneto-optical disk, and / or solid-state disk), a compact disk (CD), a digital multipurpose disk (DVD), a floppy disk, a cartridge, a magnetic tape, and / or other types of non-temporary computer-readable media.

[0302] The input component 1640 is configured to receive information such as user input. For example, the input component 1640 may include, but is not limited to, a touchscreen display, keyboard, keypad, mouse, buttons, switches, and / or a microphone. In addition or alternatively, the input component 1640 may include sensors for measuring information (e.g., a global positioning system (GPS), accelerometer, gyroscope, and / or actuator).

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

[0304] The communication interface 1660 is an interface that provides communication connections to other devices, such as external and internal devices. Connections via the communication interface 1660 may be wired, wireless, or a combination of both; they may be direct connections or indirect connections via a communication network existing between device 1600 and other devices. In other words, the specifications for the communication interface 1660 are not limited.

[0305] Bus 1670 functions as an interconnection between the processor 1610, memory 1620, storage component 1630, input component 1640, output component 1650, and communication interface 1660 of device 1600. Bus 1670 may include wired interconnections or wireless interconnections.

[0306] The number and arrangement of components shown in Figure 16 are provided as an example. In practice, device 1600 may include additional components, fewer components, different components, or components in different arrangements than those shown in Figure 16. In addition or alternatively, a set of components of device 1600 (e.g., one or more components) may perform one or more functions that are described as being performed by other sets of components of device 1600. Furthermore, one or more method steps described in any embodiment may be performed using multiple devices 1600 communicating with each other.

[0307] In the embodiments, any operation or process in Figures 2-14 may be implemented by or using any elements illustrated in Figures 15 and 16. Other embodiments are understood to be implemented in a variety of different architectures (e.g., bare metal architecture, any cloud-based architecture, or deployment architectures such as Kubernetes, Docker, or OpenStack).

[0308] The foregoing disclosures are illustrative and descriptive, but are not intended to be exhaustive or to limit implementations to the exact forms disclosed. Modifications and variations are possible in light of the foregoing disclosures or may be derived from the execution of implementations.

[0309] Some embodiments may also relate to systems, methods, and / or computer-readable media at a technical level of any possible integration. Furthermore, one or more of the above components may be implemented as instructions that are stored on a computer-readable medium and are executable by at least one processor (and / or may include at least one processor). The computer-readable medium may include a computer-readable non-temporary storage medium (or medium) that stores computer-readable program instructions for causing a processor to perform an operation.

[0310] A computer-readable storage medium may be a tangible device capable of holding and storing instructions for use by an instruction execution device. A computer-readable storage medium may, 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 thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes: portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital multipurpose disks (DVDs), memory sticks, floppy disks, mechanically encoded devices such as punch cards or grooves on which instructions are recorded, or any suitable combination thereof. The computer-readable storage medium used herein is not to be interpreted as a transient signal itself, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmitting media (e.g., light pulses passing through fiber optic cables), or electrical signals transmitted through wires.

[0311] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to each computing / processing device, or downloaded to an external computer or external storage device via a network such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and transfers them to storage in the computer-readable storage medium within each computing / processing device.

[0312] The computer-readable program code / instructions for performing the operation may be assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk and C++, procedural programming languages ​​such as the C programming language, or similar programming languages. The computer-readable program instructions may be executed as a standalone software package, either entirely on the user's computer, partially on the user's computer, partially on a remote computer, or entirely on a 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 wide area network (WAN), and the connection may be to an external computer (for example, via the Internet using an Internet Service Provider). In some embodiments, for example, an electronic circuit including a programmable logic circuit, an FPGA (field-programmable gate array), or a programmable logic array (PLA) may execute computer-readable program instructions by utilizing state information of computer-readable program instructions to personalize the electronic circuit in order to perform a side or operation.

[0313] These computer-readable program instructions may be provided to a general-purpose computer, a dedicated computer, or a processor of another programmable data processing device to generate a device such that instructions executed via the processor of a computer or other programmable data processing device generate means for implementing functions / actions described in flowcharts and / or block diagrams (one or more blocks). These computer-readable program instructions may be stored on a computer-readable storage medium on which the instructions are stored, which can be instructed to make a computer, a programmable data processing device, and / or other device function in a particular manner such that the storage medium containing the instructions has a creation containing instructions that implement aspects of functions / actions described in flowcharts and / or block diagrams (one or more blocks).

[0314] Computer-readable program instructions may be loaded onto a computer, another programmable device, or another device so that a series of operational steps are executed on the computer, another programmable device, or other device to generate a computer-implemented process in which instructions executed on the computer, another programmable device, or other device implement a function / action described in a flowchart and / or block diagram (one or more blocks).

[0315] The illustrated flowcharts and block diagrams illustrate the architecture, functions, and operations of possible implementations of systems, methods, and computer-readable media according to various embodiments. Here, each block in the flowchart or block diagram may represent a microservice, module, segment, or portion of instructions comprising one or more executable instructions to implement a particular logical function. The methods, computer systems, and computer-readable media may include additional blocks, fewer blocks, different blocks, or different arrangements of blocks than those shown in the diagrams. In some alternative implementations, the functions shown in the blocks may occur outside the order shown in the diagrams. For example, two blocks shown consecutively may actually be executed simultaneously or substantially simultaneously, depending on the functions involved, or the blocks may be executed in reverse order. Note that each block in the illustrated block diagrams and / or flowcharts, and combinations of blocks in the illustrated block diagrams and / or flowcharts, may be implemented by a system based on dedicated hardware that performs a particular function or action, or by executing a combination of dedicated hardware and computer instructions.

[0316] It is evident that the systems and / or methods described herein may be implemented in different forms of hardware, firmware, or combinations of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods is not limited to the implementation. 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 descriptions herein.

[0317] Various further aspects and features of the embodiments of this disclosure may be defined by the following items: Item 1: The Open Radio Access Network (O-RAN) Distributed Unit (O-DU) transmits network energy saving (NES) information, including network traffic, load performance measurement results, and at least one key performance indicator (KPI), to Service Management and Orchestration (SMO), The O-DU receives a message indicating when the TRx control configuration should be applied to the O-RAN radio unit (O-RU), The O-DU configures the transceiver (TRx) control configuration in the O-RU on the fronthaul (FH) interface for either the management plane (M-Plane) or the control plane (C-Plane), at least partially based on the received message. The O-DU sends a notification to the SMO indicating whether the activation of the TRx control configuration was successful. A method that includes this. Item 2: The O-DU further includes receiving the supported TRx control antenna mask and antenna array configuration from the O-RU, The NES information further includes the supported TRx control antenna mask and antenna array configuration. The O-DU and SMO are only permitted to configure the TRx control configuration, including the supported TRx control antenna mask and antenna array configuration. The method described in item 1. Item 3: The aforementioned NES information does not include the antenna mask or antenna array configuration. The O-DU and SMO can be configured to use any of the multiple antenna masks and antenna array configurations, with the TRx control configuration being configurable. The method described in item 1. Item 4: The aforementioned message is a method according to any of items 1 to 3, including a U-plane YANG (Yet Another Generation) configuration that indicates a specific TRx control configuration. Item 5: Setting the aforementioned TRx control configuration means The O-DU applies the specific TRx control configuration to the O-RU, The O-DU receives a notification from the O-RU with parameters based on the application of the specific TRx control configuration, The method described in item 4, which includes the method described in item 4. Item 6: The aforementioned message includes a policy indicating a specific TRx control configuration, as described in any of items 1 through 3. Item 7: Setting the aforementioned TRx control configuration means The O-DU processes the policy to obtain the parameters of the TRx control configuration, Based on the parameters obtained by the O-DU, the specific TRx control configuration is applied to the O-RU. The O-DU receives a notification from the O-RU with parameters based on the application of the specific TRx control configuration, The method described in item 6, which includes the method described in item 6. Item 8: An Open Radio Access Network (O-RAN) Distributed Unit (O-DU), To transmit network energy saving (NES) information, including network traffic, load performance measurement results, and at least one key performance indicator (KPI), to service management and orchestration (SMO), Receiving a message indicating when the TRx control configuration should be applied to the O-RAN radio unit (O-RU), Based at least in part on the received message, the transceiver (TRx) control configuration in the O-RU is set on the fronthaul (FH) interface for either the management plane (M-Plane) or the control plane (C-Plane), Send a notification to the SMO indicating whether the activation of the TRx control configuration was successful, O-DU configured to perform the following actions. Item 9: The supported TRx control antenna mask and antenna array configuration are further configured to be received from the O-RU. The NES information further includes the supported TRx control antenna mask and antenna array configuration. The O-DU and SMO are only permitted to configure the TRx control configuration, including the supported TRx control antenna mask and antenna array configuration. O-DU as described in item 8. Item 10: The aforementioned NES information does not include the antenna mask or antenna array configuration. The O-DU and SMO can be configured to use any of the multiple antenna masks and antenna array configurations, with the TRx control configuration being configurable. O-DU as described in item 8. Item 11: The aforementioned message includes an O-DU described in any of items 8 to 10, which includes a U-plane YANG (Yet Another Generation) configuration indicating a specific TRx control configuration. Item 12: The aforementioned O-DU is, Applying the specified TRx control configuration to the O-RU, The O-RU receives a notification with parameters based on the application of the specific TRx control configuration, The O-DU described in item 11 is configured to set the TRx control configuration accordingly. Item 13: The aforementioned message includes an O-DU as described in any of items 8 through 10, which includes a policy indicating a specific TRx control configuration. Item 14: The aforementioned O-DU is, Processing the policy to obtain the parameters of the TRx control configuration, Based on the acquired parameters, the specific TRx control configuration is applied to the O-RU, Receiving a notification from the O-RU with parameters based on the application of the aforementioned specific TRx control configuration, The O-DU described in item 13 is configured to set the TRx control configuration accordingly. Item 15: The Open Radio Access Network (O-RAN) Distributed Unit (O-DU) transmits network energy saving (NES) information, including network traffic, load performance measurement results, and at least one key performance indicator (KPI), to Service Management and Orchestration (SMO), The O-DU receives a message indicating when the TRx control configuration should be applied to the O-RAN radio unit (O-RU), The O-DU configures the transceiver (TRx) control configuration in the O-RU on the fronthaul (FH) interface for either the management plane (M-Plane) or the control plane (C-Plane), at least partially based on the received message. The O-DU sends a notification to the SMO indicating whether the activation of the TRx control configuration was successful. At least one non-temporary computer-readable recording medium that records executable instructions to implement a method including the following: Item 16: The method further includes receiving the supported TRx control antenna mask and antenna array configuration from the O-RU via the O-DU. The NES information further includes the supported TRx control antenna mask and antenna array configuration. The O-DU and SMO are only permitted to configure the TRx control configuration, including the supported TRx control antenna mask and antenna array configuration. At least one non-temporary computer-readable recording medium as described in item 15. Item 17: The aforementioned NES information does not include the antenna mask or antenna array configuration. The O-DU and SMO can be configured to use any of the multiple antenna masks and antenna array configurations, with the TRx control configuration being configurable. At least one non-temporary computer-readable recording medium as described in item 15. Item 18: The aforementioned message includes a U-plane YANG (Yet Another Generation) configuration that indicates a specific TRx control configuration. Setting the aforementioned TRx control configuration means The O-DU applies the specific TRx control configuration to the O-RU, The O-DU receives a notification from the O-RU with parameters based on the application of the specific TRx control configuration, At least one non-temporary computer-readable recording medium as described in any of items 15 to 17, including the above. Item 19: The message includes a policy indicating a specific TRx control configuration, and is contained in at least one non-temporary computer-readable recording medium as described in any of items 15 to 17. Item 20: Setting the aforementioned TRx control configuration means The O-DU processes the policy to obtain the parameters of the TRx control configuration, Based on the parameters obtained by the O-DU, the specific TRx control configuration is applied to the O-RU. The O-DU receives a notification from the O-RU with parameters based on the application of the specific TRx control configuration, At least one non-temporary computer-readable recording medium as described in item 19, including the one specified above.

[0318] In light of the above teachings, it can be understood that many modifications and variations of this disclosure are possible. It is clear that this disclosure may be implemented in a manner different from those specifically described herein, within the scope of the attached items.< / ioc> < / ioc> < / ioc> < / ioc> < / ioc> < / ioc> < / ioc> < / ioc> < / rpc>

Claims

1. The Open Radio Access Network (O-RAN) Distributed Unit (O-DU) transmits network energy saving (NES) information, including network traffic, load performance measurements, and at least one key performance indicator (KPI), to the Service Management and Orchestration (SMO), The O-DU receives a message indicating when the TRx control configuration should be applied to the O-RAN radio unit (O-RU), The O-DU configures the transceiver (TRx) control configuration in the O-RU on the fronthaul (FH) interface for either the management plane (M-Plane) or the control plane (C-Plane), at least in part, based on the received message. The O-DU sends a notification to the SMO indicating whether the activation of the TRx control configuration was successful. A method for providing this.

2. The O-DU further comprises receiving the supported TRx control antenna mask and antenna array configuration from the O-RU, The NES information further comprises the supported TRx control antenna mask and antenna array configuration. The O-DU and SMO are only permitted to configure the TRx control configuration, including the supported TRx control antenna mask and antenna array configuration. The method according to claim 1.

3. The aforementioned NES information does not include the antenna mask or antenna array configuration. The O-DU and SMO can be configured to use any of the multiple antenna masks and antenna array configurations, with the TRx control configuration being configurable. The method according to claim 1.

4. The method according to claim 1, wherein the message comprises a U-plane YANG (Yet Another Generation) configuration indicating a specific TRx control configuration.

5. Setting the aforementioned TRx control configuration means The O-DU applies the specific TRx control configuration to the O-RU, The O-DU receives a notification from the O-RU with parameters based on the application of the specific TRx control configuration, The method according to claim 4, comprising:

6. The method according to claim 1, wherein the message comprises a policy indicating a specific TRx control configuration.

7. Setting the aforementioned TRx control configuration means The O-DU processes the policy to obtain the parameters of the TRx control configuration, Based on the parameters obtained by the O-DU, the specific TRx control configuration is applied to the O-RU. The O-DU receives a notification from the O-RU with parameters based on the application of the specific TRx control configuration, The method according to claim 6, comprising:

8. An Open Radio Access Network (O-RAN) Distributed Unit (O-DU), To transmit network energy saving (NES) information, including network traffic, load performance measurement results, and at least one key performance indicator (KPI), to service management and orchestration (SMO), Receiving a message indicating when the TRx control configuration should be applied to the O-RAN radio unit (O-RU), Based at least in part on the received message, the transceiver (TRx) control configuration in the O-RU is set on the fronthaul (FH) interface for either the management plane (M-Plane) or the control plane (C-Plane), Send a notification to the SMO indicating whether the activation of the TRx control configuration was successful, O-DU configured to perform the following actions.

9. The supported TRx control antenna mask and antenna array configuration are further configured to be received from the O-RU. The NES information further comprises the supported TRx control antenna mask and antenna array configuration. The O-DU and SMO are only permitted to configure the TRx control configuration, including the supported TRx control antenna mask and antenna array configuration. The O-DU according to claim 8.

10. The aforementioned NES information does not include the antenna mask or antenna array configuration. The O-DU and SMO can be configured to use any of the multiple antenna masks and antenna array configurations, with the TRx control configuration being configurable. The O-DU according to claim 8.

11. The O-DU according to claim 8, wherein the message comprises a U-plane YANG (Yet Another Generation) configuration indicating a specific TRx control configuration.

12. The aforementioned O-DU is, Applying the specified TRx control configuration to the O-RU, The O-RU receives a notification with parameters based on the application of the specific TRx control configuration, The O-DU according to claim 11, configured to set the TRx control configuration by the above.

13. The O-DU according to claim 8, wherein the message comprises a policy indicating a specific TRx control configuration.

14. The aforementioned O-DU is, Processing the policy to obtain the parameters of the TRx control configuration, Based on the acquired parameters, the specific TRx control configuration is applied to the O-RU, Receiving a notification from the O-RU with parameters based on the application of the aforementioned specific TRx control configuration, The O-DU according to claim 13, configured to set the TRx control configuration by the above.

15. The Open Radio Access Network (O-RAN) Distributed Unit (O-DU) transmits network energy saving (NES) information, including network traffic, load performance measurements, and at least one key performance indicator (KPI), to the Service Management and Orchestration (SMO), The O-DU receives a message indicating when the TRx control configuration should be applied to the O-RAN radio unit (O-RU), The O-DU configures the transceiver (TRx) control configuration in the O-RU on the fronthaul (FH) interface for either the management plane (M-Plane) or the control plane (C-Plane), at least in part, based on the received message. The O-DU sends a notification to the SMO indicating whether the activation of the TRx control configuration was successful. At least one non-temporary computer-readable recording medium that stores instructions executable by at least one processor, to implement a method comprising the above.

16. The method further comprises receiving the supported TRx control antenna mask and antenna array configuration from the O-RU via the O-DU, The NES information further comprises the supported TRx control antenna mask and antenna array configuration. The O-DU and SMO are only permitted to configure the TRx control configuration, including the supported TRx control antenna mask and antenna array configuration. At least one non-temporary computer-readable recording medium according to claim 15.

17. The aforementioned NES information does not include the antenna mask or antenna array configuration. The O-DU and SMO can be configured to use any of the multiple antenna masks and antenna array configurations, with the TRx control configuration being configurable. At least one non-temporary computer-readable recording medium according to claim 15.

18. The aforementioned message includes a U-plane YANG (Yet Another Generation) configuration that indicates a specific TRx control configuration. Setting the aforementioned TRx control configuration means The O-DU applies the specific TRx control configuration to the O-RU, The O-DU receives a notification from the O-RU with parameters based on the application of the specific TRx control configuration, The at least one non-temporary computer-readable recording medium according to claim 15, comprising:

19. The message comprises a policy indicating a specific TRx control configuration, wherein the message is at least one non-temporary computer-readable recording medium according to claim 15.

20. Setting the aforementioned TRx control configuration means The O-DU processes the policy to obtain the parameters of the TRx control configuration, Based on the parameters obtained by the O-DU, the specific TRx control configuration is applied to the O-RU. The O-DU receives a notification from the O-RU with parameters based on the application of the specific TRx control configuration, The at least one non-temporary computer-readable recording medium according to claim 19, comprising:

Images