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

Abstract

A method, apparatus, and system for directly controlling network energy savings (NES) using service management and orchestration (SMO) and distributed units of an O1 interface may be provided, and may include transmitting, by an open radio access network (O-RAN) distributed unit (O-DU), network energy savings (NES) information to the service management and orchestration (SMO), the network energy saving information comprises at least one of network traffic, load performance measurement, and key performance indicator (KPI); receiving, by the O-DU, a message indicating when to apply the TRx control configuration to an O-RAN radio unit (O-RU); setting, by the O-DU, a transceiver (TRx) control configuration at the O-RU over a forward pass (FH) interface on a management plane (M-plane) or a control plane (C-plane) based at least in part on the received message; and transmitting, by the O-DU to the SMO, a notification indicating whether the activation of the TRx control configuration is successful.

Description

Technical Field

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

[0002] The information disclosed in this Background section is intended only to enhance the understanding of the general background of this disclosure and should not be construed as an admission or in any way implying that the information constitutes prior art known to those skilled in the art.

[0003] Radio access networks (RANs) are critical components of telecommunications systems because they connect end-user equipment (or user gear) to other parts of the network. RANs comprise a combination of various network elements (NEs) that connect end-users to the core network. Traditionally, the hardware and / or software of a particular RAN are vendor-specific.

[0004] Open RAN (O-RAN) technology has emerged, enabling multiple vendors to provide hardware and / or software for telecommunications systems. Due to the involvement of different vendors, the types of hardware and / or software provided may also differ. That is, different types of NEs can be provided by different vendors, and depending on the specific service, NEs can be virtualized in software (e.g., based on virtual machines (VMs)) or can be physical hardware (e.g., based on non-VMs).

[0005] To this end, O-RAN decomposes RAN functions into Central Units (CUs), Distributed Units (DUs), and Radio Units (RUs). A CU can be a logical node that carries the RAN's Radio Resource Control (RRC), Service Data Adaptation Protocol (SDAP), and / or Packet Data Convergence Protocol (PDCP) sublayers. A DU can be a logical node that carries the RAN's Radio Link Control (RLC), Medium Access Control (MAC), and Physical (PHY) sublayers. An RU can be a physical node that converts radio signals from antennas into digital signals, which can then be transmitted to the DU via fronthaul. Because these entities have open protocols and interfaces, they can be developed by different vendors.

[0006] Figure 1 The O-RAN architecture in the relevant technology is illustrated. RAN functions within the O-RAN architecture can be controlled and optimized by a RAN Intelligent Controller (RIC). The RIC can be a software-defined component that implements modular applications to facilitate multi-vendor interoperability required in O-RAN systems and to automate and optimize RAN operations. Figure 1As shown, RICs can be divided into two types: Non-RT RICs 120 and Near-RT RICs 130.

[0007] The Non-RT RIC 120 can be a control point in a non-real-time control loop and can operate within the Service Management and Orchestration (SMO) framework 110 on a timescale greater than 1 second. Its functionality can be implemented through a modular application called rApp, and may include: providing policy-based guidance and enhancements across an A1 interface, which is the interface enabling communication between the Non-RT RIC and the Near-RT RIC; performing data analysis; artificial intelligence / machine learning (AI / ML) training and inference for RAN optimization; and / or recommending configuration management actions via an O1 interface, which can be an interface connecting the SMO to RAN management elements (e.g., Near-RT RIC 130, O-RAN Centralized Units (O-CUs) 140, 150, O-RAN Distributed Units (O-DUs) 170, etc.).

[0008] The Near-RT RIC 130 operates on timescales between 10 milliseconds and 1 second and can be coupled to the O-DU 170, O-CU (decomposed into the O-CU control plane (O-CU-CP) 140 and the O-CU user plane (O-CU-UP) 150), and Open Evolution NodeB (O-eNB) 160 via the E2 interface. The Near-RT RIC 130 can control underlying RAN elements (E2 node / network function (NF)) through a near real-time control loop using the E2 interface. The Near-RT RIC 130 can monitor, pause / stop, override, and control E2 nodes (O-CU 140, O-CU 150, O-DU 170, and O-eNB 160) through policies. For example, the Near-RT RIC 130 can set policy parameters for the activated functions of E2 nodes. In addition, the Near-RT RIC 130 can support xApp to enable functions such as Quality of Service (QoS) optimization, mobility optimization, slicing optimization, interference mitigation, load balancing, and security.

[0009] Here, O-CU-CP 140 and O-CU-UP 150 can be coupled to each other via the E1 interface, and can be coupled to O-DU 170 via the F1-c interface and F1-u interface, respectively. In addition, O-RU 180 can be coupled to O-DU 170 via the Open Fronthaul (OF) Control (C), User (U), Synchronization (S) plane and Open Fronthaul (OF) Management (M) plane, and can be coupled to SMO 110 via the OF M plane.

[0010] These two types of RICs work together to optimize O-RAN. For example, the Non-RT RIC 120 can provide policies, data, and AI / ML models for RAN optimization that are enforced and used by the Near-RT RIC 130, and the Near-RT RIC 130 can return policy feedback (i.e., how the policies set by the Non-RT RIC 120 work).

[0011] As described above, the Non-RT RIC 120 can reside within the SMO framework 110, which manages and orchestrates RAN elements. Specifically, the SMO 110 can manage and orchestrate a so-called O-RAN cloud (O-Cloud) 190. The O-Cloud 190 can be a collection of physical RAN nodes that host the RIC, O-CU, and O-DU, supporting software components (e.g., operating system and runtime environment), and the SMO 110 itself. In other words, the SMO 110 can manage the O-Cloud 190 internally. The O2 interface can be the interface between the SMO 110 and its host O-Cloud 190. Through the O2 interface, the SMO 110 can provide Infrastructure Management Services (IMS) and Deployment Management Services (DMS).

[0012] In related technologies, to reduce operating costs and improve network efficiency, O-eNB 160 or underlying RAN elements (NF) (such as...) Figure 1 As shown, it can enter Network Energy Saving (NES) state via the O1 interface (which can be controlled by the SMO 110). For example, this may include: shifting network load to other candidate cells, or draining traffic from existing cells before moving to energy saving state. Summary of the Invention

[0013] Conventional methods used in related technologies may not adequately consider how to efficiently analyze the need to activate the NES state, how to trigger the appropriate components, and how to transmit the correct information required to activate the NES to the constituent network components.

[0014] According to an embodiment, a method for Service Management and Orchestration (SMO) and Distributed Unit Direct Control of Network Energy Saving (NES) using an O1 interface can be provided, and the method may include: sending network energy saving (NES) information from an Open Radio Access Network (O-RAN) Distributed Unit (O-DU) to the Service Management and Orchestration (SMO), the network energy saving information including at least one of network traffic, load performance measurement, and key performance indicators (KPIs); receiving a message from the O-DU indicating when to apply TRx control configuration to an O-RAN Radio Unit (O-RU); setting up transceiver (TRx) control configuration at the O-RU via a fronthaul (FH) interface on the management plane (M plane) or control plane (C plane) based at least in part on the received message; and sending a notification from the O-DU to the SMO indicating whether the activation of the TRx control configuration was successful.

[0015] Based on the above embodiments, the SMO-based NES method using the O1 interface can allow for more optimized energy consumption across the network because decisions can be made using real-time data and / or predictive analytics to adjust power profiles, enabling improved automation and more optimized resource allocation.

[0016] According to an embodiment, an Open Radio Access Network (O-RAN) Distributed Unit (O-DU) can be provided, and it is configured to: send Network Energy Saving (NES) information to Service Management and Orchestration (SMO), the network energy saving information including at least one of network traffic, load performance measurement, and key performance indicators (KPIs); receive a message indicating when to apply TRx control configuration to an O-RAN Radio Unit (O-RU); set up transceiver (TRx) control configuration at the O-RU via a fronthaul (FH) interface on either the management plane (M plane) or the control plane (C plane), at least in part based on the received message; and send a notification to the SMO indicating whether the activation of the TRx control configuration was successful.

[0017] According to an embodiment, at least one non-transitory computer-readable recording medium may be provided having instructions executed to implement a method comprising: sending network power saving (NES) information from an Open Radio Access Network (O-RAN) Distributed Unit (O-DU) to Service Management and Orchestration (SMO), the network power saving information including at least one of network traffic, load performance measurement, and key performance indicators (KPIs); receiving a message from the O-DU indicating when to apply TRx control configuration to an O-RAN Radio Unit (O-RU); setting up a transceiver (TRx) control configuration at the O-RU via a fronthaul (FH) interface on either the management plane (M plane) or the control plane (C plane) based at least in part on the received message; and sending a notification from the O-DU to the SMO indicating whether the activation of the TRx control configuration was successful.

[0018] Additional aspects will be set forth in part in the description which follows, and will be apparent in part from the description, or may be implemented by means of the embodiments presented in this disclosure. Attached Figure Description

[0019] The features, aspects, and advantages of certain exemplary embodiments of this disclosure will now be described with reference to the accompanying drawings, in which similar reference numerals denote similar elements, and wherein: Figure 1 The O-RAN architecture based on related technologies is shown;

[0020] Figure 2 A system architecture diagram of O-RAN elements and interfaces according to one embodiment is shown;

[0021] Figure 3 shows a general call flow diagram for network energy saving according to one embodiment;

[0022] Figures 4A to 5C illustrate call flowcharts for carrier and cell shutdown / enable network power saving according to one embodiment;

[0023] Figures 5A to 5C illustrate call flow diagrams for power saving in TRx networks according to one embodiment;

[0024] Figures 6A and 6B show call flow diagrams for a TRx control implementation method that is directly controlled by an SMO / O-DU or driven by a policy-based O-DU, according to one embodiment.

[0025] Figures 7A to 7C show call flow diagrams for network power saving in advanced sleep mode according to one embodiment;

[0026] Figure 8This is a block diagram of an example data structure for gNB-DU (O-DU) / gNB-CU (O-CU) IM / DM to support network power saving, according to one embodiment;

[0027] Figure 9 This is a block diagram of an example data structure for energy saving in an O-DU network according to one embodiment;

[0028] Figure 10 This is a block diagram of an example data structure for energy saving in an O-DU network using TRx control, according to one embodiment;

[0029] Figure 11 This is a block diagram of an example data structure for power saving in an O-DU network using an advanced sleep mode, according to one embodiment.

[0030] Figure 12 This is a block diagram of an example data structure for energy saving in an O-DU network according to one embodiment;

[0031] Figure 13 This is a block diagram of an example data structure for direct TRx control of the M plane via O-DU, according to one embodiment;

[0032] Figure 14 This is a flowchart of an example method for implementing Rx control directly via SMO / O-DU, according to one embodiment;

[0033] Figure 15 This is a diagram of an example environment that can implement the systems and / or methods described in this paper; and

[0034] Figure 16 This is a diagram of example components of a device according to one embodiment. Detailed Implementation

[0035] The following detailed description of exemplary embodiments is with reference to the accompanying drawings. While the foregoing disclosure provides illustrations and descriptions, it is not intended to be exhaustive or to limit implementations to the precise forms disclosed. Modifications and variations can be made based on the foregoing disclosure, or can be obtained from practice of the implementations. Furthermore, one or more features or components of one embodiment may be combined or integrated into another embodiment (or one or more features of another embodiment). Additionally, in the flowcharts and operational descriptions provided below, it should be understood that 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 switched.

[0036] It is evident that the systems and / or methods described herein can be implemented using various 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 does not limit these implementations. Therefore, this document describes the operation and behavior of the systems and / or methods without reference to any specific software code. It should be understood that software and hardware can be designed to implement the system and / or method based on the description herein.

[0037] Although specific combinations of features are listed 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 can be combined in ways not specifically stated in the claims and / or not disclosed in the specification. While each dependent claim listed below may depend directly on only one claim, the disclosure of possible implementations includes each dependent claim combined with each other claim in the claim set.

[0038] No element, action, or instruction used herein should be construed as essential or necessary unless explicitly stated otherwise. Furthermore, as used herein, the articles “a” and “one” are intended to include one or more items and may be used interchangeably with “one or more.” The term “one” or similar language is used if referring to only one item. Moreover, as used herein, the terms “having,” “with,” “comprising,” “including,” “containing,” etc., are open-ended terms. Additionally, unless explicitly stated otherwise, the word “based on” means “at least partially based on.” Furthermore, expressions such as “at least one of [A] and [B]” or “at least one of [A] or [B]” should be understood to include only A, only B, or both A and B.

[0039] According to embodiments, a method, apparatus, and system for Service Management and Orchestration (SMO) Network Energy Saving (NES) using an O1 interface may be provided, and may include: sending network energy saving (NES) information from an Open Radio Access Network (O-RAN) Distributed Unit (O-DU) to the Service Management and Orchestration (SMO), the network energy saving information including at least one of network traffic, load performance measurement, and key performance indicators (KPIs); receiving a message from the O-DU indicating when to apply TRx control configuration to an O-RAN Radio Unit (O-RU); setting up transceiver (TRx) control configuration at the O-RU via a fronthaul (FH) interface on the management plane (M plane) or control plane (C plane) based at least in part on the received message; and sending a notification from the O-DU to the SMO indicating whether the activation of the TRx control configuration was successful. Based on the above embodiments, the SMO-based NES method using the O1 interface can allow for more optimized energy consumption across the network because decisions can be made using real-time data and / or predictive analytics to adjust power profiles, enabling improved automation and more optimized resource allocation.

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

[0041] Reference Figure 2 The SMO 200 can be configured to communicate with the O-CU 210 and O-DU 220 via the O1 interface, and vice versa. The O-CU 210 and O-DU 220 can communicate with each other via the F1 interface. The O-RU 230 can communicate with the SMO 200 and O-DU 220 via the fronthaul (FH).

[0042] SMO 200 can trigger energy-saving use cases for O-DU 220 via the O1 interface, and O-DU 220 can implement the use case via the management plane (M-plane) or the control plane (C-plane), depending on the specific implementation and use case.

[0043] According to an embodiment, SMO 200 can coordinate with O-DU 220 and O-CU 210 to enable sleep mode / TRx control that does not affect the F1 interface (e.g., sleep modes (SM) #0 and SM#1 with light sleep of up to 1 frame (10 ms)). According to an embodiment, SMO 200 can use the O1 interface to implement other sleep modes (e.g., SM#3 and SM#4 with deep sleep and hibernation sleep (10 ms to "x" seconds).

[0044] It should be noted that, according to specifications (such as those in the 3rd Generation Partnership Project (3GPP), the F1 interface may have limitations in providing strategies for specifically instructing cells / RF channels to be disabled / silent / enter sleep for power-saving use cases. In this respect, the O-CU 210 may be able to provide timers for cells to be activated or disabled, but the F1 interface itself may not be able to distinguish between specific use cases.

[0045] According to one embodiment, a tiered deployment can be provided, wherein the O-RU 230 is configured to expose its energy-saving capabilities to the O-DU 220 via a fronthaul management plane (FH M-plane), which can forward the capabilities to the SMO 200 via an aggregation model or as a configuration file through the O1 interface.

[0046] According to one embodiment, a hybrid deployment can be provided, wherein the SMO 200 is capable of using Remote Procedure Call (RPC) (e.g., <rpc> <get-config>This allows you to directly understand / retrieve the capability from the O-RU.

[0047] According to one embodiment, the O-DU 220 may be able to expose network power saving (NES) related parameters to the SMO 200. In particular, for example, for carrier and cell shutdown / on use cases, the O-DU 220 may be able to expose power saving support and associated parameters (to be examined from the O-DU perspective).

[0048] According to another embodiment of RF channel reconfiguration for use cases using transceiver (TRx) control, the O-DU 220 may be able to expose a list of TRx control configurations (including antenna array configurations), a list of supported sleep modes (SMs) (SM#0, SM#1, SM#2, and SM#4), wake-up durations associated with sleep modes, TRx control antenna configuration transitions, and other associated parameters to the SMO 200 (to be examined from the O-DU perspective).

[0049] According to another embodiment for the Advanced Sleep Mode (ASM) use case, the O-DU 220 may be able to expose the sleep modes (SM#0, SM#1, SM#2 and SM#4), the wake-up duration of each sleep mode, and other associated parameters to the SMO 200 (to be studied from the perspective of the O-DU).

[0050] According to the embodiment, the O-CU 210 may be able to expose NES-related parameters to the SMO 200. This may include, but is not limited to, RRC configuration-related parameters, UE context-related parameters, neighboring cell-related parameters, and other parameters (which will be examined from the perspective of the O-CU).

[0051] Implementation using transceiver (TRx) with O1 interface

[0052] According to an embodiment, SMO 200 can be responsible for providing a strategy related to the activation time of a specific transceiver (TRx) control configuration by indicating the mask name. Subsequently, O-DU 220 can activate the same configuration in O-RU 230 by including the corresponding antenna mask in the Section Type 4 control plane (ST4 C plane) message.

[0053] According to an embodiment, cell activation / deactivation functionality may be included. SMO 200 can directly activate cells in O-DU 220. SMO 200 can configure cells in O-DU 220, O-DU 220 then configures carriers in O-RU 230, and subsequently, SMO 200 activates the cells. According to another embodiment, SMO 200 can configure only the cells served by O-DU 220 and their corresponding carriers directed towards O-DU 220 via the O1 interface. O-DU 220 can then thus configure (activate / deactivate) the tx / rx-array-carrier via its FH interface. It should also be understood that, according to another embodiment, O-DU 220 can activate or deactivate only the tx / rx array carriers in O-RU 230, which belong to the cells served by O-DU 220.

[0054] According to the embodiment, a notification framework may be provided. The SMO 200 can subscribe to O-CU 210, O-DU 220, and O-RU 230 (only in hybrid deployments) via this notification framework. For example, the SMO 200 can receive notifications from O-DU 220 related to cell activation / deactivation and tr[x]-array carrier status of O-RU 230.

[0055] According to embodiments, an odu-id can be provided. This can correspondingly facilitate carrier activation and deactivation, TRx control, and sleep mode implementations based on odu-id and ru-instance-id. In the WG4 yang model, the odu-id can be defined within the [tr]x array carrier. According to embodiments, the SMO 200 can use odu-id and ru-instance-id to implement carrier and cell shutdown / activation use cases, TRx control use cases, and ASM use cases in a specific O-RU 230 via the O-DU 220, where the odu-id can be used as a common reference parameter. The SMO 200 can use an aggregation model to put a specific carrier / array into sleep / deactivation with the assistance of the corresponding carrier / array name in the O-RU yang model.

[0056] According to an embodiment, the O1 interface can allow various parameters to be sent to the SMO 200.

[0057] Specifically, the data / parameters that can be sent via O1 may include, but are not limited to: user throughput, power consumption, QoS, user pebeam, current O-RU configuration, cell configuration, UL / DL delay (minimum, maximum, and average), transmit and receive windows, distributed delay including FH delay between O-DU 220 and O-RU 230, etc.

[0058] The O-DU 220 capabilities that can be exposed via the O1 interface may also include the number of SSB beams supported by each TRx control configuration, the number of data beams (e.g., PUSCH) for each TRx control configuration, the beam scan range that varies with the number of antenna array elements, or the number of beams per configuration reported based on the O-RU capabilities.

[0059] The O-CU-related parameters that can be sent may include TRx configuration changes sent from SMO 200 to O-CU 210 and O-DU 220, enabling O-CU 210 to be aware of the RRC configuration and coordinating gNB-DU configuration updates with O-DU 220. It may also include CSI-RS ports to be updated based on the current TRx control configuration (see, for example, 3GPP TS 38.802 - Clause 7.14). It may also include SSB coverage area changes-RRC configuration-related changes for each TRx control configuration (indicated to O-CU 210 by either 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), and CSI measurements and reports (both periodic and non-periodic).

[0060] Notifications that can be sent via the O1 interface may include, but are not limited to: SMO 200 subscription notifications, energy-saving state (e.g., energySavingState) change notifications, [tx]-array carrier state change notifications, and TRx control configuration change notifications sent to the O-CU 210 via the O1 interface for RRC-related changes.

[0061] Figures 3A to 3C illustrate a general call flow diagram for Network Energy Saving (NES) according to one embodiment. Specifically, SMO 300, O-CU 310, O-DU 320, and O-RU 330 may be provided, which can correspond to the above-described... Figure 2 Similar entities described in [the text].

[0062] Referring to Figure 3A, the capabilities of the O-RU 330 can be exposed first. The constituent steps in the call flow are described below.

[0063] 1 - SMO 300 can request features supported by O-RU 330 from O-DU320 via the O1 interface using get rpc calls for oru-feature.

[0064] 2 - The O-DU 320 can request NES function support (such as carrier / cell off / on, TRx control, and advanced sleep mode) from the O-RU 330 via the FH interface using the get rpc call.

[0065] 3 - The NES functionality requested in 2 is exposed from O-RU 330 to O-DU 320 in the response.

[0066] 4 - NES capability parameters can be requested from the O-DU 320 to the O-RU 330 via the FH interface. Sub-steps for exposing NES capability parameters may include (depending on the specific use case): 4.1 - Carrier / cell enable / disable capability can be exposed from O-RU 330 to O-DU 320 via the M plane in the FH interface; 4.2 - A list of supported TRx control antenna configurations can be exposed from the O-RU 330 to the O-DU 320 via the M-plane in the FH interface; 4.3 - A list of supported sleep modes can be exposed from the O-RU 330 to the O-DU320 via the M-plane in the FH; and 4.4 - Support for ST4 C-plane messages and associated parameters (e.g., for TRx control and ASM use cases, command scope, etc.) can be exposed to O-DU 320 by O-RU 330 via the M-plane in FH.

[0067] 5 - O-DU 320 can send back the NES functions supported by O-DU and the required configuration / parameters to SMO300.

[0068] After steps 1-5 as shown in Figure 3A, the O-DU capability can be exposed as follows.

[0069] 6 - The functions supported by O-DU can be requested by SMO 300 through the O1 interface via getrpc call for odu-feature to O-DU 320.

[0070] 7 - O-DU 320 can expose the NES-supported functions (for TRx and ASM use cases) through the O1 interface.

[0071] 8 - O-DU capability can be requested from SMO 300 to O-DU 320 via the O1 interface through a get rpc call for odu-capability.

[0072] 9 - NES capability parameters can be exposed to SMO 300 by O-DU 320 through the O1 interface.

[0073] After steps 6-9 shown in Figure 3A, data can be collected and monitored for the SMO 300 (as shown in Figures 3A-3b).

[0074] 10.1 - Requests for collecting network performance data for energy saving (performance and file management) can be made by the SMO300 to the O-CU 310 via the O1 interface.

[0075] 10.2 - The measurement network data requested in 10.1 can be shared by the O-CU 310 to the SMO300 via the O1 interface.

[0076] 10.3 - Requests for collecting network performance data for energy saving (performance and file management) can be made by the SMO300 to the O-DU 320 via the O1 interface.

[0077] 10.4 - The measurement network data requested in 10.3 can be shared by the O-DU 320 to the SMO300 via the O1 interface.

[0078] In a layered deployment scenario, network data from the O-RU for energy saving can be obtained as follows (e.g.) Figure 3b (As shown).

[0079] 10.5 - Requests for collecting network performance data for energy saving (performance and file management) can be made by the SMO300 to the O-DU 320 via the O1 interface.

[0080] 10.6 - Data collection requests for energy saving are sent to O-RU 330.

[0081] 10.7 – Measurement network data (which is the O-RU data used for network power saving in 10.6) can be shared by the O-DU 320 to the SMO 300 via the O1 interface.

[0082] Alternatively, if the deployment is a hybrid deployment, the alternative call flow for steps 10.5 to 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 SMO 300 to the O-RU 330 via the FH interface.

[0084] 10.9 - The O-RU 330 shares the data requested in step 10.8 for network energy saving with the SMO 300 via the FH interface.

[0085] The SMO 300 can determine whether to trigger power saving based on the network power saving data collected in the above steps. Therefore, in the first case, the SMO 300 can communicate with the O-CU as follows to trigger the NES use case:

[0086] 11.1 - The SMO 300 triggers the NES use case / function, recommends the appropriate sleep mode (ASM) and antenna mask (TRx control), and sends the trigger to the O-CU 310 via the O1 interface.

[0087] 11.2 - O-CU 310 requests O-DU 320 to activate power saving / activate power saving in O-RU 330 via F1 interface.

[0088] 11.3.1 - The O-DU 320 commands the O-RU 330 to activate the energy-saving function (TRx control or ASM) via the FH interface.

[0089] 11.3.2 - The response to the power-saving activation request is sent from O-DU 320 to O-CU 310 via the F1 interface.

[0090] In the second scenario, the SMO 300 can trigger an NES use case with the O-DU 320. The steps can be as follows:

[0091] 11.4 - The SMO 300 triggers NES use cases / functions and recommends appropriate sleep modes (ASM) and antenna masks (TRx control) for the O-DU 320 via the O1 interface.

[0092] 11.5 - The energy-saving function is activated via the FH interface (TRx control / ASM) based on a request sent from the O-DU 320 to the O-RU 330.

[0093] 11.6 - The response to the energy-saving activation request is sent from the O-DU 320 to the SMO 300 via the O1 interface.

[0094] Referring now to Figure 3C, energy-saving data collection can be performed by the SMO 300 to monitor the energy-saving status from NES use case implementations.

[0095] In step 11.7, the SMO 300 requests energy-saving data from the O-DU 320 via the O1 interface.

[0096] In step 11.8, the response to the energy-saving data request is sent from O-DU 320 to SMO 300 via the O1 interface.

[0097] SMO 300 can determine that the energy saving should be terminated based on the energy saving data received in step 11.8. In the first case, the request can be sent by SMO 300 to O-CU 310, as follows:

[0098] At step 11.9, the request to terminate energy saving can be sent from SMO 300 to O-CU310 via the O1 interface.

[0099] At step 11.10, the power-saving termination request is forwarded by O-CU 310 to O-DU 320 via the F1 interface.

[0100] At step 11.11, the power-saving shutdown request is sent from O-DU 320 to O-RU 330 via the FH interface.

[0101] At step 11.12, the response to the power saving termination request is sent from O-DU 320 to O-CU310 via the F1 interface.

[0102] At step 11.13, the response to the power saving termination request is received by the SMO 300 from the O-CU 310 via the O1 interface.

[0103] In the second scenario, the request to terminate energy saving is sent directly from the SMO 300 to the O-DU 320. The steps are as follows:

[0104] At step 11.14, the request for power saving termination is sent from SMO 300 to O-DU320 via the O1 interface.

[0105] At step 11.15, the request to disable energy saving is sent by O-DU 320 to O-RU 330 via the FH interface.

[0106] At step 11.16, the response to the energy-saving termination request is sent from O-DU 320 to SMO300 via the O1 interface.

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

[0108] Figures 4A-4C illustrate call flow diagrams for network power saving according to embodiments of carrier and cell switchoff / on. SMO 400, O-CU 410, O-DU 420, and O-RU 430 are provided, and they may be similar to their counterparts described above.

[0109] At step 1, the O-RU 430 can expose power-saving capabilities (e.g., NES-related information) including carrier and cell shutdown / on capabilities to the O-DU 420 via the FH M-plane interface.

[0110] In step 2, the O-DU 420 can expose its power-saving capabilities related to carrier and cell shutdown / on, along with its O-RU capabilities, to the SMO 400 via the O1 interface.

[0111] At step 3, the O-CU 410 can expose its energy-saving capabilities related to carrier and cell shutdown / on to the SMO 400 via the O1 interface.

[0112] At step 4, the SMO 400 can collect flow load performance and energy consumption measurements from the O-CU 410 via the O1 interface.

[0113] At step 5, the SMO 400 can collect flow load performance and energy consumption measurements from the O-DU 420 via the O1 interface.

[0114] Afterwards, the SMO 400 can analyze traffic load performance measurements, available cell list / coverage requirements / coverage holes / UE distribution to determine whether to activate NES use cases.

[0115] At step 6, the SMO 400 can determine, via the O1 interface (based on traffic and load measurements, key performance indicators (KPIs), to trigger the activation of NES using carrier and cell shutdown / opening. This can also be based on coverage and throughput requirements, and can be determined, for example, using artificial intelligence / machine learning (AI / ML).

[0116] Energy-saving activation in the O-RU 430 can be performed as follows.

[0117] At step 7.1, the SMO 400 can send a trigger to the O-CU 410 to activate carrier and cell shutdown / enable use cases via the O1 interface. The O-CU 410 can then decide to initiate a handover action (e.g., moving the UE to a neighboring cell due to cell shutdown).

[0118] At step 7.2, O-CU 410 can forward requests to disable / shut down (multiple) cells and associated (multiple) carriers by sending appropriate attributes / parameters / controls to O-DU 420 via the F1 interface.

[0119] At step 7.3, the O-DU 420 can prepare to process carrier and cell shutdown based on a request from the SMO 400 and via the O-CU 410.

[0120] At step 7.4, the O-DU 420 can send an edit-rpc call to the O-RU 430 to initiate carrier and cell shutdown: for example, <edit-rpc><[tr]x-array-carrier:active->INACTIVE>.

[0121] Referring now to Figure 4B, at step 7.5, O-RU 430 can set [tr]x-array-carrier: state->DISABLED.

[0122] At step 7.6, the O-RU 430 can be in an energy-saving state.

[0123] At step 7.7, the O-DU 420 can send an update to the O-CU 410 via the F1 interface to indicate that (multiple) cells / (multiple) carriers are turned off / powered down.

[0124] At step 7.8, the O-DU 420 can notify the SMO 400 via the O1 interface that the power saving status has changed / power saving has been activated (e.g., the carrier and cell have been turned off / powered down).

[0125] At step 8, the SMO 400 can collect flow load performance and energy consumption measurements from the O-CU 410 via the O1 interface.

[0126] At step 9, the SMO 400 can collect flow load performance and energy consumption measurements from the O-DU 420 via the O1 interface.

[0127] The SMO 400 can analyze traffic load performance measurements. In step 10, the SMO can determine carrier deactivation and cell shutdown / activation use cases based on coverage and throughput requirements (e.g., using AI / ML), such as poor KPIs, increased traffic, required capacity, etc. This can be performed via the O1 interface.

[0128] At step 11.1, the power-saving deactivation in the O-RU can be triggered by the SMO 400 and sent to the O-CU 410 via the O1 interface to deactivate carrier and cell shutdown / open use cases.

[0129] At step 11.2, the request to reactivate / reconnect the cell and associated carrier is sent from O-CU 410 to O-DU 420 via the F1 interface by sending appropriate attributes / parameters / controls.

[0130] At step 11.3, O-DU 420 can prepare to process carrier and cell activation based on the request sent from SMO 400 via O-CU 410.

[0131] In step 11.4, the O-DU 420 can initiate carrier and cell activation by sending an edit RPC call to the O-RU 430 via the FH M-plane interface. <edit-rpc><[tr]x-array-carrier:active ->ACTIVE>

[0132] At step 11.5, the O-RU 430 can send [tr]x-array-carrier: state->Ready.

[0133] At step 11.6, the O-RU 430 can return to normal operation.

[0134] At step 11.7, the O-DU 420 can send an update to the O-CU 410 via the F1 interface to indicate that (multiple) cells / (multiple) carriers are enabled / powered on. Afterwards, the O-CU 410 can begin accepting handover requests from (multiple) UEs in neighboring cells.

[0135] At step 11.8, the O-DU 420 can send a notification to the SMO 400 via the O1 interface to inform that the power saving status has changed / power saving has been disabled (carrier and cell enabled / powered on).

[0136] Figures 5A-5C show call flow diagrams for TRx network power saving according to one embodiment.

[0137] SMO 500, O-CU 510, O-DU 520 and O-RU 530 are available, and they can be similar to their counterparts above.

[0138] At step 1, the O-RU 530 can expose energy-saving capabilities, including TRx control-related capabilities (e.g., NES-related information), to the O-DU 520 via the FH M-plane interface.

[0139] In step 2, the O-DU 520 can expose its energy-saving capabilities controlled by TRx, along with its O-RU capabilities, to the SMO 500 via the O1 interface.

[0140] At step 3, the O-CU 510 can expose its energy-saving capabilities controlled by TRx to the SMO 500 via the O1 interface.

[0141] At step 4, the SMO 500 can collect flow load performance and energy consumption measurements from the O-CU 510 via the O1 interface.

[0142] At step 5, the SMO 500 can collect flow load performance and energy consumption measurements from the O-DU 520 via the O1 interface.

[0143] Afterwards, the SMO 500 can analyze traffic load performance measurements, available cell list / coverage requirements / coverage holes / UE distribution to determine whether to activate NES use cases.

[0144] At step 6, the SMO 500 can determine, via the O1 interface, to trigger the activation of the NES controlled by TRx (based on traffic and load measurements, key performance indicators (KPIs), etc.). This can also be based on coverage and throughput requirements, and determined, for example, using artificial intelligence / machine learning (AI / ML).

[0145] Energy-saving activation can be performed in the O-RU 530 as follows.

[0146] At step 7.1, the SMO 500 can provide policies or send triggers to the O-CU 510 via the O1 interface to activate TRx control use cases.

[0147] At step 7.2, the O-DU 520 can prepare to process the TRx control configuration (Synchronization Signal Block / System Information Block) (SSB / SIB) and other associated parameters based on a request from the SMO 500.

[0148] At step 7.3, the O-DU 520 can send an update to the SSB configuration to the O-CU 510 via the F1 interface by sending appropriate parameter / attribute / information element (IE). The O-CU 510 can then initiate a handover action (e.g., moving the UE to a neighboring cell).

[0149] At step 7.4, O-DU 520 can send ST4 C-plane messages with TRx control-related parameters to O-DU 530 via the FH C-plane interface.

[0150] At step 7.5, the O-RU 530 can send an ACK / NACK message to the O-DU 520 via the FH C-plane interface using the "ackNackReqID" field in the ST4 C-plane message.

[0151] Referring now to Figure 5B, at step 7.6, the O-RU 530 can process the ST4 C-plane message and put the corresponding RF channel / antenna element into sleep / silence / shutdown.

[0152] At step 7.7, the O-DU 520 can notify the SMO 500 via the O1 interface that the power saving status has changed / power saving has been activated (current TRx control / antenna array configuration).

[0153] At step 7.8, the O-RU 530 can be in an energy-saving state.

[0154] At step 8, the SMO 500 can collect flow load performance and energy consumption measurements from the O-CU 510 via the O1 interface.

[0155] At step 9, the SMO 500 can collect flow load performance and energy consumption measurements from the O-DU 520 via the O1 interface.

[0156] The SMO 500 can analyze traffic load performance measurements. At step 10, the SMO 500 can determine whether to move 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 KPI performance, increased traffic, required capacity, etc. This can be performed via the O1 interface.

[0157] At step 11.1, the SMO 500 can provide a policy or transmit a trigger to the O-DU 520 via the O1 interface to activate another TRx control configuration or move to a reference antenna array configuration.

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

[0159] At step 11.3, the O-DU 520 can send an ST4 C-plane message with TRx control-related parameters to the O-RU 520 via the FH C-plane interface.

[0160] At step 11.4, the O-RU 530 can use the "ackNackReqID" field in the ST4 C-plane message to send an ACK / NACK message.

[0161] Referring now to Figure 5C, in step 11.5, the O-RU 530 can process the ST4 C-plane message from 11.3 and wake up the O-RU 530 or enable / unsleep / unmute the corresponding RF channel / antenna element.

[0162] At step 11.6, the ST8 "ready" message can be sent from O-RU 530 to O-DU 520 via the FH C-plane interface without guaranteeing the wake-up duration.

[0163] At step 11.7, when the CU plane processing unit is turned off as part of sleep, the O-DU 520 can send an emergency wake-up to the O-RU 530 via the FH M plane interface to interrupt sleep.

[0164] In step 11.8, in response to an emergency wake-up request, the O-RU 530 can send a notification to the O-DU520 via the FH M-plane interface.

[0165] At step 11.9, the O-RU 530 can operate normally or enter another TRx control configuration and / or sleep mode.

[0166] At step 11.10, O-DU 520 updates the SSB configuration at O-CU510 via the F1 interface by sending the appropriate attributes / parameters / IE.

[0167] At step 11.11, the O-DU 520 can notify the SMO 500 via the O1 interface that the power-saving state has changed (e.g., the O-RU 530 has been woken up, or an ongoing TRx control (antenna array) configuration is in progress).

[0168] Figures 6A-6B illustrate call flow diagrams of TRx control implementations according to one embodiment, using direct control by an SMO / O-DU or policy-based O-DU driving. An SMO 600, O-DU 620, and O-RU 630 are provided, and they may be similar to their counterparts described above.

[0169] Referring to Figure 6A, at step 1, the O-RU 630 can announce the valid / supported TRx control antenna mask / antenna array configuration to the O-DU 620 via the FH M-plane.

[0170] In step 2, the O-DU 620 can expose its capabilities, along with the O-RU capabilities, to the SMO600 via the O1 interface.

[0171] Carriers and cells can be configured and activated. In step 3, the O-DU 620 exposes traffic / load performance measurements and KPIs to the SMO 600.

[0172] In the first sub-case, the TRx control use case implementation based on the M-plane can be applied.

[0173] At step 4.1, the O-DU 620 can configure a specific TRx control configuration at the O-RU 630 via the FH M-plane interface.

[0174] At step 4.2, the O-RU 630 may send a notification with appropriate parameters to the O-DU 620.

[0175] In step 4.3, the O-DU 620 can send a notification to the SMO 600 via the O1 interface to indicate whether the activation / deactivation of a specific TRx control configuration was successful.

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

[0177] In another alternative scenario, at step 6, the O-RU 630 (via the FH M-plane interface) does not advertise the valid / supported TRx control antenna mask.

[0178] Therefore, at step 7, O-DU 620 and SMO 600 can recognize that any antenna mask combination / configuration is supported by O-RU for a specific [tr]x-array according to O-RAN-WG4-MP-V13.0.

[0179] Two other sub-cases can be applied. First, the SMO 600 can directly configure the TRx control configuration. In step 8.1, the U-plane configuration can be sent from the SMO 600 to the O-DU 620 via the O1 interface to request the O-DU 620 to activate the configuration in the O-RU 630.

[0180] At step 8.2, the O-DU 620 configures a specific TRx control configuration in the O-RU 630 via the FH M plane.

[0181] At step 8.3, the O-RU 630 sends a notification with appropriate parameters to the O-DU 620 via the FH M plane interface.

[0182] At step 8.4, the O-DU 620 sends a notification to the SMO 600 to indicate whether the activation / deactivation of a specific TRx control configuration was successful.

[0183] Referring now to Figure 6B, in the second sub-case, a policy-based O-DU-driven TRx control use case implementation using the M-plane can be applied. At step 9.1, the U-plane configuration with the specific TRx control configuration can be sent from the SMO 600 to the O-DU 620 via the O1 interface, requesting activation of the configuration in the O-RU 630.

[0184] At step 9.2, policy processing can be performed by the O-DU 620 (e.g., satisfying the conditions and parameters of the policy for a specific TRx control activation / deactivation).

[0185] At step 9.3, the O-DU 620 can send U-plane configuration to the O-RU 630 via the FH M-plane interface.

[0186] At step 9.4, the O-RU 630 can send a notification with appropriate parameters to the O-DU 620 via the FH M-plane interface.

[0187] At step 9.5, the O-DU may send feedback to the SMO 600 based on the received policy to indicate whether the activation / deactivation of the policy was successful. Figures 7A-7C illustrate call flow diagrams for Advanced Sleep Mode (ASM) network power saving according to an embodiment. The SMO 700, O-CU 710, O-DU 720, and O-RU 730 are provided, and they may be similar to their counterparts described above.

[0188] At step 1, the O-RU 730 can expose energy-saving capabilities via ASM to the O-DU 720 through the FH M-plane interface.

[0189] In step 2, the O-DU 720 can expose its ASM power-saving capabilities along with its O-RU capabilities to the SMO 700 via the O1 interface.

[0190] In step 3, the O-CU 710 can expose its energy-saving capabilities via ASM to the SMO700 through the O1 interface.

[0191] At step 4, the SMO 700 can collect flow load performance and energy consumption measurements from the O-CU 710 via the O1 interface.

[0192] At step 5, the SMO 700 can collect flow load performance and energy consumption measurements from the O-DU 720 via the O1 interface.

[0193] The SMO 700 can analyze traffic load performance measurements, available cell lists / coverage requirements / coverage holes / UE distribution. At step 6, the SMO 700 can activate ASM use cases based on the following decisions: coverage and throughput requirements (e.g., using AI / ML) via the O1 interface (e.g., based on traffic and load measurements, KPIs, etc.).

[0194] At step 7.1, the SMO 700 can provide policies or send triggers to the O-DU 720 through the O1 interface to activate the ASM use case.

[0195] At step 7.2, the O-DU 720 can prepare to process the sleep mode (SSB / SIB) and other associated parameters(s) based on a request from the SMO 700.

[0196] At step 7.3, the O-DU 720 may stop transmitting to the O-CU 710 via the F1 interface, or update the SSB configuration at the O-CU 710 by sending the appropriate attributes / parameters / IE. The O-CU 710 may initiate a handover action (e.g., moving the UE to a neighboring cell, only applicable to putting the entire O-RU 730 into sleep mode).

[0197] At step 7.4, the O-DU 720 can send an ST4 C-plane message with sleep mode-related parameters to the O-RU via the FH C-plane interface.

[0198] In step 7.5, the O-DU 720 sends an ACK / NACK message to the O-RU 730 via the FH C-plane interface using the "ackNackReqID" field in the ST4 C-plane message.

[0199] Referring now to Figure 7B, at step 7.6, the O-RU 730 can process the ST4 C-plane message from step 7.4 and put the entire O-RU or its corresponding components / elements to sleep / shutdown.

[0200] At step 7.7, the O-DU 720 can notify the SMO 700 via the O1 interface that the power saving status has changed / power saving has been activated (in the current sleep mode).

[0201] At step 8, the SMO 700 collects flow load performance and energy consumption measurements from the O-CU 710 via the O1 interface.

[0202] At step 9, the SMO 700 collects flow load performance and energy consumption measurements from the O-DU 720 via the O1 interface.

[0203] The SMO 700 can analyze the load performance measurements received in steps 8 and 9, and in step 10, determine to terminate NES power saving via the O1 interface. Specifically, the SMO 700 can determine to wake up the O-RU 730 or extend the ongoing sleep mode, or activate another sleep mode, based on coverage and throughput requirements (e.g., using AI / ML), such as based on KPI deterioration, increased traffic / required capacity.

[0204] At step 11.1, a policy can be provided to the O-DU 720 via the O1 interface to initiate a power-saving shutdown, wake up the O-RU 730, or extend / activate another sleep mode.

[0205] At step 11.2, the O-DU 720 may prepare to process the sleep mode (SSB / SIB) and other associated parameters(s) based on a request from the SMO 700.

[0206] At step 11.3, the O-DU 720 sends an ST4 C-plane message containing sleep mode-related parameters (wake-up / extended sleep / another sleep mode) to the O-RU 730 via the FH C-plane interface.

[0207] At step 11.4, the O-RU 730 sends an ACK / NACK message via the FH C-plane interface using the "ackNackReqID" field in the ST4 C-plane message.

[0208] Referring now to Figure 7C, at step 11.5, the O-RU 730 can process the ST4 C-plane message from step 11.3 and wake up the O-RU 730 or put the corresponding component into an appropriate sleep mode.

[0209] At step 11.6, the ST8 "ready" message can be sent from O-RU 730 to O-DU 720 via the FH C-plane interface without guaranteeing the wake-up duration.

[0210] At step 11.7, when the CU plane processing unit is shut down as part of sleep, the O-DU 720 can send an emergency wake-up to the O-RU 730 via the FH M plane interface to interrupt sleep.

[0211] In step 11.8, in response to an emergency wake-up request, the O-RU 730 can send a notification to the O-DU720 via the FH M-plane interface.

[0212] At step 11.9, the O-RU 730 can operate normally or enter another TRx control configuration and / or sleep mode.

[0213] At step 11.10, the O-DU 720 can prepare, stop, or update the SSB configuration at the O-CU 710 via the F1 interface by sending the appropriate attributes / parameters / IE. The O-CU 710 can then begin accepting handover requests from UEs in neighboring cells (only applicable to sleep mode that puts the entire O-RU to sleep).

[0214] At step 11.11, the O-DU 720 can notify the SMO 700 via the O1 interface that the power-saving state has changed (e.g., the O-RU 730 has been woken up, or the ongoing sleep mode has been extended or it has entered another sleep mode).

[0215] Figure 8 This is a block diagram of an example data structure for gNB-DU (O-DU) / gNB-CU (O-CU)IM / DM to support network power saving, according to one embodiment. In some embodiments, gNB-DU (O-DU) / gNB-CU (O-CU)IM / DM can be configured to support network power saving through inheritance of NESManagementFunction and CESManagementFunction. Figure 8 Examples of various instances of network energy saving included using NES management functions are shown.

[0216] Figure 9 This is a block diagram of an example data structure for O-DU network power saving according to an embodiment. According to the embodiment, network power saving can be accomplished using carrier shutdown or startup use case objects. Figure 9 As shown, in the case of the CESManagementFunction defined in 3GPP, the CESManagementFunction can be reused to configure the cell using the O-CU. In the O-RAN-specific IOC "NESManagementFunction", the NESManagementFunction can be included in the 3GPP "NRSectorCarrier" to enable or disable the carrier in the O-RU for SMO purposes. According to an embodiment, enabling or disabling the carrier in the O-RU can be accomplished using the attribute "carrierActivationTime". However, for the O-RU, [tr]x-array can be mapped to [tr]x-array-carrier, and then to the 3GPP objects NRSectorCarrier and NRCellDU. To enable or disable the [tr]x-array-carrier in the O-RU, the "CarrierSwitchOffOn" use case object can be utilized along with the attributes "csSwitch", "csState", "csControl", and "csPolicy" included in the NESManagementFunction.

[0217] Figure 10 This is a block diagram of an example data structure for energy saving in an O-DU network using TRx control, according to an embodiment. (Refer to...) Figure 10 Network energy saving can be accomplished using TRx control use case objects. In some cases, the cell can be affected, and in such cases, "NESManagementFunction" can be included under "NRCellDU". "NESManagementFunction" can include "RFChannelSwitchOffOn" with attributes "trxCtrlSwitch", "trxCtrlState", "trxCtrlPolicy", and "dataLayerControl". "RFChannelSwitchOffOn" can include a sub-use case object for 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 This is a block diagram of an example data structure for O-DU network power saving using an advanced sleep mode, according to one embodiment. Cells affected by the "NESManagementFunction" can be included under "NRCellDU". In this case, the "NESManagementFunction" can include an "AdvancedSleepMode" use case object with attributes such as, but not limited to, "asmSwitch", "asmState", and "asmPolicy". The "AdvancedSleepMode" can include a sub-object "ASMControl", which can include attributes such as a list of supported sleep modes, activation time, and data direction for network power saving.

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

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

[0221] according to Figure 13 The O-RU can advertise supported TRx control masks in the fronthaul M-plane using the o-ran-uplane-conf.yang module for O-RU exposure capabilities. A list of TRx control configurations supported by the O-RU can exist, which can be reported along with their corresponding mask-name and antenna-mask. The absence of a supported-trx-control-mask in the list can indicate that any combination of antenna masks can be supported by the O-RU for a specific [tr]x-array. In some cases, if the O-DU does not detect a supported-trx-control-mask, the O-DU can configure any mask, or the O-DU can disable or activate any specific TRx path / antenna array element by not configuring or removing low-level [tr]x-links / low-level [tr]x-endpoints. Figure 13 As shown, the O-DU can be configured or not configured with a specific low-level-[tr]x-link / low-level-[tr]x-endpoint associated with the static-low-level-[tr]x-endpoint (TRx path / antenna array) to provide TRx control. The low-level-[tr]x-link associated with the [tr]x-array-carrier can be mapped to the low-level-[tr]x-endpoint for direct TRx control.

[0222] It should be understood that, Figures 8 to 13 The data model described above is an example, and those skilled in the art may make differences in structure and variable names depending on the specific implementation use case.

[0223] Figure 14 This is a flowchart of an example method 1400 for an Rx control implementation directly controlled by an SMO / O-DU, according to one embodiment.

[0224] At operation S1401, the O-DU can send NES information to the SMO. According to an embodiment, the Network Energy Saving (NES) information may include at least one of network traffic, load performance measurement, and key performance indicators (KPIs).

[0225] According to an embodiment, the O-DU can receive the supported TRx control antenna mask and antenna array configuration from the O-RU, wherein the NES information also includes the supported TRx control antenna mask and antenna array configuration, and wherein the O-DU and SMO are only allowed to set the TRx control configuration to include the supported TRx control antenna mask and antenna array configuration.

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

[0227] At operation S1402, the O-DU may receive a message indicating when a TRx control configuration is applied to the O-RU. According to one embodiment, this message includes a U-plane configuration indicating a specific TRx control configuration. According to other embodiments, this message may be a policy indicating a specific TRx control configuration.

[0228] At operation S1403, the O-DU can, based on a message received from operation S1402, set the TRx configuration at the O-RU via the FH interface on the M-plane or C-plane. According to an embodiment, if the message includes a U-plane configuration, setting the TRx control configuration includes applying a specific TRx control configuration to the O-RU by the O-DU.

[0229] According to an embodiment, if the message includes a policy, setting the TRx configuration includes: the O-DU processing the policy to obtain parameters for the TRx control configuration, and the O-DU applying a specific TRx control configuration to the O-RU based on the obtained parameters.

[0230] At operation S1404, the O-DU can send a notification indicating whether the activation of the TRx configuration was successful.

[0231] According to an embodiment, class definitions, attributes of class(s), and constraints of class(s) can be provided. The various class definitions are described as follows:

[0232] CESManagementFunction< <ioc>>- An Information Object Class (IOC) can provide the following attributes, which may be required for configuring (multiple) cells and cooperating with the O-DU to configure associated carriers for energy saving using cell and carrier shutdown / 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 and can provide (multiple) attributes required to configure the O-DU to cooperate with the O-RU for energy-saving functions. These (multiple) attributes may include those inherited from ManagedEntity as defined in Clause 4.3.20 of 3GPP TS 28.622 and Clause 6.3.2 of 3GPP TS 32.602, as given in Table 1A. Table 1A

[0234] The attribute constraints for NESManagementFunction are shown in Table-1B. Table-1B

[0235] CarrierSwitchOffOn< <ioc>This IOC can provide the following attributes, which can be required for configuring the O-DU to cooperate with the O-RU to enable or disable the CarrierSwitchOffOn use case object. These attributes can be inherited from the O-RAN-specific NESManagementFunction IOC and can 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 can provide the attributes required to configure the O-DU to cooperate with the O-RU for carrier deactivation, thereby achieving energy savings. These attributes can be inherited from the O-RAN-specific CarrierSwitchOffOn IOC and can include the following attributes as shown in Table 4. Table 4

[0238] RFChannelSwitchOffOn - This IOC can provide the following(s) properties, which can be those required to configure the O-DU to cooperate with the O-RU to enable or disable the TRx control sub-use case for energy saving. These properties can be inherited from the NESManagementFunction IOC and can include the following properties 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 can provide the following attributes, which can be specific TRXControl configurations required for configuring the O-DU to cooperate with the O-RU to activate or deactivate associated parameters for energy saving. In some embodiments, the TRXControl configuration may also be referred to as the antenna array configuration. This attribute can 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 property constraints for TRXControl are shown in Tables-8A and-8B. Table 8A Table-8B

[0242] AdvancedSleepMode< <ioc>This IOC can provide the following properties, which can be those required for configuring the O-DU to cooperate with the O-RU to enable or disable advanced sleep mode use cases for energy saving. These properties can be inherited from the NESManagementFunction IOC and can include the following properties as shown in Table-9. Table 9

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

[0244] ASMControl< <ioc>This IOC can provide the following properties, which can be those required for configuring the O-DU to cooperate with the O-RU to activate or deactivate specific sleep mode use cases for energy saving. These properties can be inherited from the AdvancedSleepMode IOC and can include the following properties as shown in Table 11. Table 11

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

[0246] According to an embodiment, an example of the O-DU data model is as follows: Module: o-ran-o-du-nes.yang

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

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

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

[0250] In some embodiments, various performance counters for the O-CU are given below. In some embodiments, the DLPDCP SDU data volume measurement for each F1-U interface is shown in Table 16. This measurement can provide the amount of data (number of PDCP SDU bits) transmitted in the downlink from GNB-CU-UP to GNB-DU (F1-U interface), to external gNB-CU-UP (Xn-U interface), and to external eNB (X2-U interface). This measurement can be calculated according to QoS level (5QI or QCI mapped in NR Option 3), according to single network slice selection assistance information (S-NSSAI), according to S-NSSAI, and according to Public Land Mobile Network Identifier (PLMN ID), and reported by interface (F1-U, Xn-U, X2-U). This measurement may include channel configuration (CC).

[0251] Furthermore, in some embodiments, this measurement can be obtained by counting the number of DL PDCP SDU bits sent to the GNB-DU (F1-U interface), to the external gNB-CU-UP (XnU interface), and to the external eNB (X2-U interface). This measurement is performed in the GNB-CU-UP according to the QoS level (5QI or QCI mapped in NR Option 3), according to S-NSSAI, according to S-NSSAI, and according to the PLMN ID, and reported according to the 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 Mbit, where (1 Mbit = 1000) (1000 bits). The number of measurements equals the number of QoS levels per interface plus the number of S-NSSAIs per interface plus the number of PLMN IDs.

[0253] Furthermore, in some embodiments, the measurement name may be in the form of DRB.F 1UPDCPSDUVolumnDL_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, it may include EP_F1U (F1U interface), EP_XnU (Xn-U interface) and EP_X2U (X2-U interface).

[0255] In some embodiments, this measurement can be valid for packet-switched traffic. In some embodiments, this can be applied to 5GS.

[0256] In some embodiments, certain uses may be for performance guarantees in the energy efficiency (EE) region for the integrity region (user plane connection quality). Table 16

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

[0258] In some embodiments, the amount of UL PDCP SDU data per F1-U interface is shown in Table-18. This measurement can provide the amount of data (number of PDCPs) transmitted in the uplink from GNB-DU (F1-U interface), from external gNB-CU-UP (Xn-U interface), and from external eNB (X2-U interface) to gNB-CU-UP. This measurement can be performed according to QoS level (5QI or QCI mapped in NR Option 3), according to S-NSSAI, according to S-NSSAI, and according to PLMN ID, and reported by interface (F1-U, Xn-U, X2-U). This measurement may include CC. In some embodiments, UL is an abbreviation for uplink, and DL is an abbreviation for downlink.

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

[0260] Furthermore, in some embodiments, each measurement may be an integer value representing the number of bits measured in Mbit, where (1 Mbit = 1000) (1000 bits). The number of measurements equals the number of QoS levels per interface plus the number of S-NSSAIs per interface plus the number of PLMN IDs.

[0261] Furthermore, in some embodiments, the measurement name may be in the form DRB.F1uPdcpSduVolumnUL_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.

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

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

[0264] In some embodiments, certain uses may be for performance guarantees in the energy efficiency (EE) region for the integrity region (user plane connection quality). Table 18

[0265] The artificial intelligence / machine learning (AI / ML) model used for the UL PDCP SDU is shown in Table-19. Table 19

[0266] The following are various exemplary embodiments illustrating various performance counters for O-DU. In some embodiments, a reference signal reception quality (RSRQ) measurement is shown in Table-20. This measurement can provide the distribution of SS-RSRQ that can be received by the gNB from the UE in the cell. Periodic UE measurements can be reported for all UEs that may be requested 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 the RSRQ is used in the MeasQuantityResults IE within the resultsSSB-Cell IE of the measResult IE configured as defined in TS 38.331

[20] , the measurement can be obtained by adding an appropriate measurement interval using the measurement value (also refer to Table 10.1.11.1-1 in TS 28.133

[35] and Clause 5.1.3 SS Reference Signal Received Quality (SS-RSRQ) in TS 38.215

[34] .

[0268] In some embodiments, the measurement can be a set of integers. The measurement may include MR.NRScSSRSRQ.BinX, where X can represent a range of SS-RSRQ values ​​(-43 to 20 dB). In some cases, multiple intervals and ranges may be left to be implemented. The measurement may include NRCellCU. In some embodiments, the measurement may be valid for packet-switched traffic. In some embodiments, the measurement may be applicable to 5GS. Table 20

[0269] The AI / ML model used for RSRQ measurement is shown in Table 21. Table 21

[0270] In some embodiments, RSRP measurements are shown in Table 21. When the L1-RSRP reporting function can be enabled, and RSRP is used for L1-RSRP as configured by the reporting configuration defined in TS 38.214

[33] , this measurement can provide the SS-RSRP distribution for each SSB that can be received by the gNB from the UE in the cell (see TS 28.215

[34] ). This measurement may include CC.

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

[33] , the measurement can be obtained by using the measurement value to increase the appropriate measurement range (see also Table 10.1.6.1.1-1 in TS 38.133

[35] ).

[0272] In some embodiments, the sub-counters of the RSRP measurement can be integers. The measurement may include L1M.SS-RSRP.Bin, where Bin may represent the range (0-127 dBm) of the reported SS-RSRP value. In some cases, multiple intervals and ranges may be left to be implemented. The measurement may include Beam. In some embodiments, the measurement may be valid for packet-switched traffic. In some embodiments, the measurement may be applicable to 5GS. In some embodiments, one use of this performance measurement is to support Message Delivery Agent (MDA). Table 22

[0273] The AI / ML model used for RSRQ measurement is shown in Table 23. Table 23

[0274] In some embodiments, the SS-RSRP distribution for each SSB is shown in Table 24. When the L1-RSRP reporting function is enabled, and SS-RSRP is used for L1-RSRP as configured by the reporting configuration defined in TS 38.214

[33] , the measurement can provide the SS-RSRP distribution based on the SSBs of neighboring new radio (NR) cells received by the gNB from the UE (see TS 38.215

[34] ). This measurement may include CC.

[0275] In some embodiments, the measurement can be obtained by using the measured value to increase the appropriate interval (see Table 10.1.6.1-1 in TS 38.133

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

[20] ).

[0276] In some embodiments, the sub-counters of the SS-RSRP distribution can be integers. In some embodiments, the measurement can include L1M.SS-RSRPNrNbr.SSBIndex.Bin, where SSBIndex identifies the SSB beams of neighboring NR cells, and Bin represents the range (0-127) of the reported SS-RSRP values. The number of intervals and the range of each interval are left to be implemented. In some embodiments, the measurement can include NRCellRelation. In some embodiments, the measurement can be valid for packet-switched traffic. In some embodiments, this can be applied to 5GS. In some embodiments, one use of this performance measurement is to support MDA. Table 24

[0277] The AI / ML model used for the SS-RSRP distribution is shown in Table 25. Table 25

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

[20] ). The measurement may include CC. When the RSRP value for a neighboring E-ULTRA cell is reported by the UE to the gNB via an RRC Measurement Report message (see TS 38.331

[20] ), the measurement can be obtained by using the measurement value to increase the appropriate measurement interval (see Table 10.1.6.1-1 in TS 28.133

[35] ).

[0279] In some embodiments, the sub-counters of the RSRP distribution can be integers. In some embodiments, the measurement can include L1M.RSRPEultraNbr.Bin, where Bin represents the range of the reported RSRP value up to 97. The number of intervals and the range of each interval are left to be implemented. In some embodiments, the measurement can include EUtranCellRelation. In some embodiments, the measurement can be valid for packet-switched traffic. In some embodiments, this can be applied to 5GS. In some embodiments, one use of this performance measurement is to support MDA. Table 26

[0280] The AI / ML model used for RSRP distribution is shown in Table 27. Table 27

[0281] In some implementations, the SNIR measurement is shown in Table 28. This measurement can provide the SS-SNIR distribution that can be received by the gNB from the UE in the cell. Periodic UE measurements are reported for all UEs that may be triggered by the gNB in ​​the new radio cell being measured (see 38.331

[20] ). This measurement may include CC. When the SNIR value is reported by the UE, and when the SNIR is used in the MeasQuantityResults IE in the resultsSSB-Cell IE within the resultsResults IE as configured by the MeasurementReport configuration defined in TS 38.331

[20] , the measurement can be obtained by using the measured value to increase the appropriate measurement interval (see Table 10.1.6.1-1 in TS 38.133

[35] ).

[0282] In some embodiments, the sub-counters for the SINR measurement can be integers. In some embodiments, the measurement may include MR.NRScSSSINR.BinX, where X represents the range of the measured SS-SNIR value (-23 to 40 dB). The number of intervals and the range of each interval are left to be implemented. In some embodiments, the measurement may include NRCellCU. In some embodiments, the measurement may be valid for packet-switched traffic. In some embodiments, this may be applicable to 5GS. Table 28

[0283] The AI / ML model used for SNIR measurements is shown in Table 29. Table 29

[0284] Based on the above embodiments, the SMO-based NES method using the O1 interface can allow for more optimized energy consumption across the network because decisions can be made using real-time data and / or predictive analytics to adjust power profiles, enabling improved automation and more optimized resource allocation.

[0285] Figure 15 This is a diagram of an example environment 1500 that can implement the systems and / or methods described in this paper. (See diagram 1500.) Figure 15 As shown, environment 1500 may include user equipment 1510, platform 1520, and network 1530. Devices in environment 1500 may be interconnected via wired connections, wireless connections, or a combination of wired and wireless connections. In an embodiment, reference is made above... Figures 2 to 14 Any functions and operations described can be accessed through Figure 15 Any combination of the elements shown can be used to perform this action.

[0286] User equipment 1510 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information associated with platform 1520. For example, user equipment 1510 may include computing devices (e.g., desktop computers, laptop computers, tablet computers, handheld computers, smart speakers, servers, etc.), mobile phones (e.g., smartphones, cordless phones, etc.), wearable devices (e.g., a pair of smart glasses or a smartwatch), or similar devices. In some implementations, user equipment 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, allowing certain software components to be swapped in or out as needed. Thus, platform 1520 can be easily and / or quickly reconfigured for different uses.

[0288] In some implementations, as shown in the figure, platform 1520 can be hosted in a cloud computing environment 1522. It is worth noting that although the implementations described herein depict 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 of a cloud computing environment) or may be partially cloud-based.

[0289] The cloud computing environment 1522 includes the environment that hosts the platform 1520. The cloud computing environment 1522 can provide services such as computing, software, data access, and storage, without requiring end users (e.g., user equipment 1510) to know the physical location and configuration of the systems and / or devices hosting the platform 1520. As shown in the figure, the cloud computing environment 1522 may include a set of computing resources 1524 (collectively referred to as "computing resources 1524" and individually referred to as "computing resources 1524").

[0290] Computing resource 1524 includes one or more personal computers, clusters of computing devices, workstations, server devices, or other types of computing and / or communication devices. In some implementations, computing resource 1524 may host platform 1520. Cloud resources may include computing instances executing 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] like Figure 15 As further shown, computing resources 1524 include cloud resource groups, such as one or more applications ("APPs") 1524-1, one or more virtual machines ("VMs") 1524-2, virtualized storage ("VSs") 1524-3, one or more hypervisors ("HYPs") 1524-4, etc.

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

[0293] Virtual machine 1524-2 includes a software implementation of a machine (e.g., a computer) that executes programs similarly to a physical machine. Depending on the use of virtual machine 1524-2 and its correspondence to any real machine, virtual machine 1524-2 can be a system virtual machine or a process virtual machine. A system virtual machine can be a complete system platform that supports the execution of a complete operating system ("OS"). A process virtual machine can execute a single program and can support a single process. In some implementations, virtual machine 1524-2 can execute on behalf of a user (e.g., user device 1510) and can manage the infrastructure of 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 one or more devices that utilize virtualization technology within the storage system or device of computing resource 1524. In some implementations, the type of virtualization, within the context of the storage system, may include block virtualization and file virtualization. Block virtualization may refer to the abstraction (or separation) of logical storage from physical storage, enabling access to the storage system regardless of the physical storage or heterogeneous architecture. This separation allows storage system administrators flexibility in how they manage storage for end users. File virtualization eliminates the dependency between data accessed at the file level and the location of the physical storage file. This enables optimization of storage usage, server consolidation, and / or non-destructive file migration performance.

[0295] Hypervisor 1524-4 provides hardware virtualization technology that allows multiple operating systems (e.g., "guest operating systems") to execute concurrently on a host computer such as computing resource 1524. Hypervisor 1524-4 can present a virtual operating platform to the guest operating systems and manage their execution. Multiple instances of various operating systems can 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., fifth-generation (5G) networks, long-term evolution (LTE) networks, third-generation (3G) networks, code division multiple access (CDMA) networks, etc.), public land mobile networks (PLMN), local area networks (LAN), wide area networks (WAN), metropolitan area networks (MAN), telephone networks (e.g., public switched telephone network (PSTN)), private networks, self-organizing networks, intranets, the Internet, fiber-optic networks, etc., and / or combinations of these or other types of networks.

[0297] Figure 15 The number and arrangement of devices and networks shown are provided as examples. In reality, additional devices and / or networks, fewer devices and / or networks, different devices and / or networks, or networks may exist. Figure 15 The devices and / or networks shown are arranged differently. Furthermore, Figure 15 The two or more devices shown can be implemented within a single device, or Figure 15 The single device shown can be implemented as multiple distributed devices. Additionally, or alternatively, a group of devices in environment 1500 (e.g., one or more devices) can perform one or more functions described as being performed by another group of devices in environment 1500.

[0298] Figure 16 An embodiment of device 1600 is shown. For example... Figure 16 As shown, device 1600 includes processor 1610, memory 1620, storage component 1630, input component 1640, output component 1650, communication interface 1660, and bus 1670.

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

[0300] Memory 1620 includes non-transitory computer-readable media. Memory 1620 includes random access memory (RAM), read-only memory (ROM), and / or another type of dynamic or static storage device (e.g., flash memory, magnetic storage, and / or optical storage) that stores information and / or instructions for use by processor 1610. Memory 1620 includes machine-readable instructions executable by processor 1610. When executed by processor 1610, these machine-readable instructions cause processor 1610 to perform one or more method steps of the embodiments described above.

[0301] Storage component 1630 stores information and / or software related to the operation and use of device 1600. For example, storage component 1630 may include hard disks (e.g., magnetic disks, optical disks and / or magneto-optical disks, and / or solid-state drives), compact discs (CDs), digital universal discs (DVDs), floppy disks, cassette tapes, magnetic tapes, and / or other types of non-transitory machine-readable media and corresponding drives.

[0302] Input component 1640 is configured to receive information, such as user input. For example, input component 1640 may include, but is not limited to, a touchscreen display, keyboard, keypad, mouse, button, switch, and / or microphone. Additionally, or alternatively, input component 1640 may include sensors for sensing information (e.g., Global Positioning System (GPS), accelerometer, gyroscope, and / or actuator).

[0303] Output component 1650 is configured to provide output information from device 1600. For example, 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] Communication interface 1660 is an interface that provides communication connectivity to other devices, such as external and internal devices. The connection via communication interface 1660 can be a wired connection, a wireless connection, or a combination of wired and wireless connections, and can be a direct or indirect connection via a communication network existing between device 1600 and other devices. In other words, the standard of communication interface 1660 is not limited.

[0305] Bus 1670 serves as an interconnect between processor 1610, memory 1620, storage component 1630, input component 1640, output component 1650, and communication interface 1660 in device 1600. Bus 1670 may include wired or wireless interconnects.

[0306] Figure 16 The number and arrangement of components shown are provided as an example. In practice, device 1600 may include additional components, fewer components, different components, or components with... Figure 16 The components shown are arranged differently. Additionally, or alternatively, a group of components of device 1600 (e.g., one or more components) may perform one or more functions described as being performed by another group 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 an embodiment, Figures 2 to 14 Any of the operations or processes can be performed or used Figure 15 and Figure 16 This can be implemented using any of the components shown. It should be understood that other embodiments are not limited thereto and can be implemented in a variety of different architectures, such as bare metal architecture, any cloud-based architecture, or deployment architecture such as Kubernetes, Docker, OpenStack, etc.

[0308] While the foregoing disclosure provides examples and descriptions, it is not intended to be exhaustive or to limit the implementation to the precise form disclosed. Modifications and variations can be made based on the foregoing disclosure, or derived from the practice of the implementation.

[0309] Some embodiments may relate to systems, methods, and / or computer-readable media at any possible level of technical detail integration. Furthermore, one or more of the foregoing components may be implemented as instructions stored on a computer-readable medium and executable by at least one processor (and / or may include at least one processor). The computer-readable medium may include one or more computer-readable non-transitory storage media having computer-readable program instructions on it for causing a processor to perform operations.

[0310] Computer-readable storage media can be tangible devices capable of retaining and storing instructions for use by an instruction execution device. Computer-readable storage media can be, for example, but not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer floppy disks, 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 disc read-only memory (CD-ROM), digital universal disc (DVD), memory sticks, floppy disks, mechanical encoding devices such as punch cards or raised structures in recesses on which instructions are recorded, and any suitable combination of the foregoing. As used herein, computer-readable storage media should not be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses passing through fiber optic cables), or electrical signals transmitted through lines.

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

[0312] The computer-readable program code / instructions used to perform operations can be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, integrated circuit configuration data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and procedural programming languages ​​such as the "C" programming language or similar programming languages. The computer-readable program instructions can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer via any type of network, including a local area network (LAN) or wide area network (WAN), or can be connected to an external computer (e.g., via the Internet provided by an Internet service provider). In some embodiments, electronic circuits, such as those including programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), can execute computer-readable program instructions to personalize the electronic circuits for performing aspects or operations by utilizing the status information of the computer-readable program instructions.

[0313] These computer-readable program instructions may be provided to the processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, form means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions may also be stored in a computer-readable storage medium capable of directing a computer, programmable data processing apparatus, and / or other device to function in a particular manner, such that the computer-readable storage medium in which the instructions are stored includes an article of manufacture comprising the instructions that implement aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0314] Computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other equipment to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other equipment, thereby producing a computer-implemented process, such that the instructions executed on the computer, other programmable apparatus, or other equipment perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0315] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer-readable media according to various embodiments. In this regard, the blocks in the flowcharts or block diagrams may represent portions of microservices, modules, segments, or instructions, including one or more executable instructions for implementing the specified logical function. Methods, computer systems, and computer-readable media may include additional blocks, fewer blocks, different blocks, or blocks arranged differently from those depicted in the figures. In some alternative implementations, the functions indicated in the blocks may occur in a different order than indicated in the figures. For example, depending on the functions involved, two blocks shown consecutively may actually be executed simultaneously or substantially simultaneously, or these blocks may sometimes be executed in reverse order. It should also be noted that the blocks in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented by a dedicated hardware-based system that performs the specified function or action, or a combination of dedicated hardware and computer instructions.

[0316] It is evident that the systems and / or methods described herein can be implemented using various 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 does not limit these implementations. Therefore, since 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 can be designed to implement the systems and / or methods based on the descriptions herein.

[0317] Various other corresponding aspects and features of embodiments of this disclosure can be defined by the following items: Project [1]: A method comprising: sending network power saving (NES) information from an Open Radio Access Network (O-RAN) Distributed Unit (O-DU) to a Service Management and Orchestration (SMO), the network power saving information including at least one of network traffic, load performance measurement, and key performance indicators (KPIs); receiving a message from the O-DU indicating when to apply TRx control configuration to an O-RAN Radio Unit (O-RU); setting a transceiver (TRx) control configuration at the O-RU via a fronthaul (FH) interface on either the management plane (M plane) or the control plane (C plane) based at least in part on the received message; and sending a notification from the O-DU to the SMO indicating whether the activation of the TRx control configuration was successful. Project [2]: The method according to Project [1] further includes: receiving a supported TRx control antenna mask and antenna array configuration from the O-RU by the O-DU, wherein the NES information further includes the supported TRx control antenna mask and antenna array configuration, and wherein the O-DU and SMO are only allowed to set the TRx control configuration to include the supported TRx control antenna mask and antenna array configuration. Project [3]: According to the method described in Project [1], wherein the NES information does not include an antenna mask or antenna array configuration, and the O-DU and SMO are enabled to set the TRx control configuration to use any of the multiple antenna masks and antenna array configurations. Item [4]: ​​The method according to any one of Items [1]-[3], wherein the message includes a U-plane next-generation (YANG) configuration indicating a particular TRx control configuration. Project [5]: According to the method described in Project [4], setting the TRx control configuration includes: applying the specific TRx control configuration to the O-RU by the O-DU; and receiving a notification from the O-RU by the O-DU having parameters based on the application of the specific TRx control configuration. Item [6]: The method according to any one of Items [1]-[3], wherein the message includes a policy indicating a specific TRx control configuration. Project [7]: According to the method described in Project [6], setting the TRx control configuration includes: the O-DU processing the policy to obtain parameters of the TRx control configuration; the O-DU applying the specific TRx control configuration to the O-RU based on the obtained parameters; and the O-DU receiving a notification from the O-RU having parameters based on the application of the specific TRx control configuration. Project [8]: An Open Radio Access Network (O-RAN) Distributed Unit (O-DU) configured to: send Network Energy Saving (NES) information to Service Management and Orchestration (SMO), the Network Energy Saving information including at least one of network traffic, load performance measurement, and Key Performance Indicators (KPIs); receive a message indicating when to apply TRx control configuration to an O-RAN Radio Unit (O-RU); set up a transceiver (TRx) control configuration at the O-RU via a fronthaul (FH) interface on either the management plane (M plane) or the control plane (C plane) based at least in part on the received message; and send a notification to the SMO indicating whether the activation of the TRx control configuration was successful. Project [9]: The O-DU according to Project [8] is also configured to: receive a supported TRx control antenna mask and antenna array configuration from the O-RU, wherein the NES information further includes the supported TRx control antenna mask and antenna array configuration, and wherein the O-DU and SMO are only allowed to set the TRx control configuration to include the supported TRx control antenna mask and antenna array configuration. Item

[10] : According to the O-DU of Item [8], wherein the NES information does not include an antenna mask or antenna array configuration, and the O-DU and SMO are enabled to set the TRx control configuration to use any of the multiple antenna masks and antenna array configurations. Item

[11] : O-DU according to any of Items [8]-

[10] , wherein the message includes a U-plane next-generation (YANG) configuration indicating a particular TRx control configuration. Item

[12] : According to the O-DU described in Item

[11] , wherein the O-DU is configured to set the TRx control configuration by: applying the specific TRx control configuration to the O-RU; and receiving from the O-RU a notification having parameters based on the application of the specific TRx control configuration. Item

[13] : O-DU according to any of Items [8]-

[10] , wherein the message includes a policy indicating a particular TRx control configuration. Project

[14] : According to the O-DU of Project

[13] , wherein the O-DU is configured to set the TRx control configuration by: processing the policy to obtain parameters of the TRx control configuration; applying the specific TRx control configuration to the O-RU based on the obtained parameters; and receiving from the O-RU a notification having parameters based on the application of the specific TRx control configuration.

[15] : At least one non-transitory computer-readable recording medium having instructions executed to implement a method comprising: sending network power saving (NES) information from an Open Radio Access Network (O-RAN) Distributed Unit (O-DU) to Service Management and Orchestration (SMO), the network power saving information including at least one of network traffic, load performance measurement, and key performance indicators (KPIs); receiving a message from the O-DU indicating when to apply TRx control configuration to an O-RAN Radio Unit (O-RU); setting a transceiver (TRx) control configuration at the O-RU via a fronthaul (FH) interface on one of the management plane (M plane) or control plane (C plane) based at least in part on the received message; and sending a notification from the O-DU to the SMO indicating whether the activation of the TRx control configuration was successful. Item

[16] : According to at least one non-transitory computer-readable recording medium of Item

[15] , the method further includes: receiving, by the O-DU, a supported TRx control antenna mask and antenna array configuration from the O-RU, wherein the NES information further includes the supported TRx control antenna mask and antenna array configuration, and wherein the O-DU and SMO are only permitted to set the TRx control configuration to include the supported TRx control antenna mask and antenna array configuration. Item

[17] : At least one non-transitory computer-readable recording medium according to Item

[15] , wherein the NES information does not include an antenna mask or antenna array configuration, and the O-DU and SMO are enabled to set the TRx control configuration to use any of the multiple antenna masks and antenna array configurations. Item

[18] : At least one non-transitory computer-readable recording medium according to Items

[15] -

[17] , wherein the message includes a U-plane next-generation (YANG) configuration indicating a specific TRx control configuration, wherein setting the TRx control configuration includes: applying the specific TRx control configuration to the O-RU by the O-DU; and receiving a notification from the O-RU by the O-DU having parameters based on the application of the specific TRx control configuration. Item

[19] : At least one non-transitory computer-readable recording medium according to Items

[15] -

[17] , wherein the messages include a policy indicating a particular TRx control configuration. Item

[20] : At least one non-transitory computer-readable recording medium according to Item

[19] , wherein setting the TRx control configuration includes: the O-DU processing the policy to obtain parameters of the TRx control configuration; the O-DU applying the specific TRx control configuration to the O-RU based on the obtained parameters; and the O-DU receiving from the O-RU a notification having parameters based on the application of the specific TRx control configuration.

[0318] It should be understood that many modifications and variations of this disclosure can be made based on the teachings above. It is evident that, to the extent of the appended terms, this disclosure can be practiced in ways other than those specifically described herein.< / ioc> < / ioc> < / ioc> < / ioc> < / ioc> < / ioc> < / ioc> < / ioc> < / rpc>

Claims

1. A method comprising: Network power saving (NES) information is sent from the Open Radio Access Network (O-RAN) Distributed Unit (O-DU) to Service Management and Orchestration (SMO), and the network power saving information includes at least one of network traffic, load performance measurement, and key performance indicators (KPIs); The O-DU receives a message indicating when to apply TRx control configuration to the O-RAN radio unit (O-RU); and The O-DU, based at least in part on the received messages, sets up a transceiver (TRx) control configuration at the O-RU via a fronthaul (FH) interface on either the management plane (M plane) or the control plane (C plane); and The O-DU sends a notification to the SMO indicating whether the activation of the TRx control configuration was successful.

2. The method according to claim 1, further comprising: The O-DU receives the supported TRx control antenna mask and antenna array configuration from the O-RU, wherein the NES information further includes the supported TRx control antenna mask and antenna array configuration, and wherein the O-DU and SMO are only allowed to set the TRx control configuration to include the supported TRx control antenna mask and antenna array configuration.

3. The method of claim 1, wherein the NES information does not include an antenna mask or antenna array configuration, and the O-DU and SMO are enabled to set the TRx control configuration to use any of the multiple antenna masks and antenna array configurations.

4. The method of claim 1, wherein the message includes a U-plane next-generation (YANG) configuration indicating a specific TRx control configuration.

5. The method according to claim 4, wherein setting the TRx control configuration includes: The specific TRx control configuration is applied from the O-DU to the O-RU; The O-DU receives a notification from the O-RU containing parameters based on the application of the specific TRx control configuration.

6. The method of claim 1, wherein the message includes a policy indicating a specific TRx control configuration.

7. The method of claim 6, wherein setting the TRx control configuration includes: The strategy is processed by the O-DU to obtain the parameters of the TRx control configuration; The O-DU applies the specific TRx control configuration to the O-RU based on the obtained parameters; and The O-DU receives a notification from the O-RU containing parameters based on the application of the specific TRx control configuration.

8. An Open Radio Access Network (O-RAN) Distributed Unit (O-DU) configured as follows: Send Network Energy Saving (NES) information to Service Management and Orchestration (SMO), the network energy saving information including at least one of network traffic, load performance measurement and key performance indicators (KPI); Receive a message indicating when to apply TRx control configuration to the O-RAN radio unit (O-RU); and Based at least in part on the received messages, a transceiver (TRx) control configuration is set at the O-RU via a fronthaul (FH) interface on either the management plane (M plane) or the control plane (C plane); and Send a notification to the SMO indicating whether the activation of the TRx control configuration was successful.

9. The O-DU according to claim 8, further configured as follows: The O-RU receives the supported TRx control antenna mask and antenna array configuration, wherein the NES information further includes the supported TRx control antenna mask and antenna array configuration, and wherein the O-DU and SMO are only allowed to set the TRx control configuration to include the supported TRx control antenna mask and antenna array configuration.

10. The O-DU of claim 8, wherein the NES information does not include an antenna mask or antenna array configuration, and the O-DU and SMO are enabled to set the TRx control configuration to use any of the multiple antenna masks and antenna array configurations.

11. The O-DU of claim 8, wherein the message includes a U-plane next-generation (YANG) configuration indicating a specific TRx control configuration.

12. The O-DU of claim 11, wherein the O-DU is configured to set the TRx control configuration as follows: Apply the specific TRx control configuration to the O-RU; and Receive a notification from the O-RU containing parameters based on the application of the specific TRx control configuration.

13. The O-DU of claim 8, wherein the message includes a policy indicating a specific TRx control configuration.

14. The O-DU of claim 13, wherein the O-DU is configured to set the TRx control configuration as follows: The strategy is processed to obtain the parameters of the TRx control configuration; The specific TRx control configuration is applied to the O-RU based on the obtained parameters; and Receive a notification from the O-RU containing parameters based on the application of the specific TRx control configuration.

15. At least one non-transitory computer-readable recording medium having instructions recorded thereon that can be executed by at least one processor to implement a method, said method comprising: Network power saving (NES) information is sent from the Open Radio Access Network (O-RAN) Distributed Unit (O-DU) to Service Management and Orchestration (SMO), and the network power saving information includes at least one of network traffic, load performance measurement, and key performance indicators (KPIs); The O-DU receives a message indicating when to apply TRx control configuration to the O-RAN radio unit (O-RU); and The O-DU, based at least in part on the received messages, sets up a transceiver (TRx) control configuration at the O-RU via a fronthaul (FH) interface on either the management plane (M plane) or the control plane (C plane); and The O-DU sends a notification to the SMO indicating whether the activation of the TRx control configuration was successful.

16. The method further comprises: at least one non-transitory computer-readable recording medium according to claim 15. The O-DU receives the supported TRx control antenna mask and antenna array configuration from the O-RU, wherein the NES information further includes the supported TRx control antenna mask and antenna array configuration, and wherein the O-DU and SMO are only allowed to set the TRx control configuration to include the supported TRx control antenna mask and antenna array configuration.

17. The at least one non-transitory computer-readable recording medium of claim 15, wherein the NES information does not include an antenna mask or antenna array configuration, and the O-DU and SMO are enabled to set the TRx control configuration to use any of the plurality of antenna masks and antenna array configurations.

18. The at least one non-transitory computer-readable recording medium of claim 15, wherein the message includes a U-plane next-generation (YANG) configuration indicating a specific TRx control configuration, wherein setting the TRx control configuration includes: The specific TRx control configuration is applied from the O-DU to the O-RU; The O-DU receives a notification from the O-RU containing parameters based on the application of the specific TRx control configuration.

19. The at least one non-transitory computer-readable recording medium of claim 15, wherein the message includes a policy indicating a specific TRx control configuration.

20. The at least one non-transitory computer-readable recording medium of claim 19, wherein setting the TRx control configuration includes: The strategy is processed by the O-DU to obtain the parameters of the TRx control configuration; The O-DU applies the specific TRx control configuration to the O-RU based on the obtained parameters; and The O-DU receives a notification from the O-RU containing parameters based on the application of the specific TRx control configuration.

Images