Implementation of dynamic antenna array reconfiguration in communication networks

Abstract

The present disclosure relates to implementing dynamic antenna array reconfiguration in an O-RAN, wherein a radio unit (O-RU) is configured to: send configuration capability information to a distributed unit (O-DU) via management plane (M-Plane) messaging; receive antenna array configurations supported by the O-RU from the O-DU via control plane (C-Plane) messaging based on the O-RU's configuration capability information and a request to reconfigure the antenna array from a higher layer network function; and reconfigure the antenna array configuration of the O-RU based on the antenna array configuration supported for the O-RU.

Description

[Technical Field]

[0001] [CROSS REFERENCE TO RELATED APPLICATIONS] This application claims priority to Indian Provisional Patent Application No. 202221076397 filed on December 28, 2022, Indian Provisional Patent Application No. 202341031813 filed on May 4, 2023, Indian Provisional Patent Application No. 202321007046 filed on February 3, 2023, Indian Provisional Patent Application No. 202321016149 filed on April 10, 2023, and Indian Provisional Patent Application No. 202341024486 filed on April 31, 2023, the disclosures of all of which are incorporated herein by reference in their entireties.

[0002] [Technical field] The present disclosure relates to implementing dynamic antenna array reconfiguration in an Open Radio Access Network (O-RAN) to conserve energy in communication networks. [Background technology]

[0003] The Radio Access Network (RAN) is a critical component in a communication system that connects end-user devices (or user equipment) to the rest of the network. The RAN includes a combination of various network elements (NEs) that connect end-user devices to the core network. Traditionally, the hardware and / or software of a particular RAN has been vendor-specific.

[0004] The emergence of Open RAN (O-RAN) technology allows multiple vendors to provide hardware and / or software for communication systems. To this end, O-RAN decomposes RAN functions into a centralized unit (CU), distributed units (DUs), and radio units (RUs). The CU is a logical node for hosting the RAN sublayers of Radio Resource Control (RRC), Service Data Adaptation Protocol (SDAP), and / or Packet Data Convergence Protocol (PDCP). The DU is a logical node for hosting the RAN sublayers of Radio Link Control (RLC), Medium Access Control (MAC), and Physical (PHY). The O-RU (i.e., O-RAN RU) is a physical node that converts radio signals from the antenna into digital signals that can be transmitted over the fronthaul to the O-DU (O-RAN DU). These entities can be developed by different vendors because of the open protocols and interfaces between them.

[0005] Figure 1 illustrates an O-RAN architecture in the related art. Referring to Figure 1, RAN functions in the O-RAN architecture are controlled and optimized by a Radio Access Network Intelligent Controller (RIC). The RIC is a software-defined component that implements modular applications to realize the multi-vendor operability required in the O-RAN system and automate and optimize RAN operations. RICs are divided into two types: non-real-time RIC (NRT-RIC) and near-real-time RIC (nRT-RIC).

[0006] The NRT-RIC is the control point for non-real-time control loops and operates within a Service Management and Orchestration (SMO) framework on timescales longer than one second. Its functions are implemented through modular applications called rApps (rApp 1, ..., rApp N) and include providing policy-based guidance and enrichment over the A1 interface, which is the interface enabling communication between the NRT-RIC and nRT-RIC; performing data analytics; artificial intelligence / machine learning (AI / ML) training and inference for RAN optimization; and / or recommending configuration management actions over the O1 interface, which is the interface connecting the SMO to RAN management elements (e.g., nRT-RIC, O-RAN aggregation unit (O-CU), O-RAN distributed unit (O-DU), etc.).

[0007] The nRT-RIC operates on a time scale between 10 milliseconds and 1 second and connects to the O-DU, O-CU (decomposed into the O-CU control plane (O-CU-CP) and the O-CU user plane (O-CU-UP)), and open evolved NodeB (O-eNB) via the E2 interface. The nRT-RIC uses the E2 interface to control the underlying RAN elements (E2 nodes / network functions (NFs)) in a near-real-time control loop. The nRT-RIC monitors, suspends / stops, overrides, and controls the E2 nodes (O-CU, O-DU, and O-eNB) through policies. For example, the nRT-RIC sets policy parameters on the activated functions of the E2 nodes. Furthermore, the nRT-RIC hosts xApps for implementing functions such as quality of service (QoS), mobility optimization, slicing optimization, interference mitigation, load balancing, and security. The two types of RICs work together to optimize the O-RAN. For example, the NRT-RIC provides policies, data, and artificial intelligence / machine learning (AI / ML) models over the A1 interface that are enabled and used by the nRT-RIC for RAN optimization, and the nRT-RIC returns policy feedback (i.e., how the policies set by the NRT-RIC are working).

[0008] The SMO framework in which the NRT-RIC resides manages and coordinates RAN elements. Specifically, the SMO manages and coordinates what is referred to as the O-RAN Cloud (O-Cloud). The O-Cloud is a collection of physical RAN nodes that host the RIC, O-CU, O-DU, supporting software components (e.g., operating systems and runtime environments), and the SMO itself. Summary of the Invention [Problem to be solved by the invention]

[0009] In related technology, the O-RU reports a standardized antenna array model and / or antenna mask based on a Cartesian coordinate system to the O-DU. The standardized antenna array model and / or antenna mask based on a Cartesian coordinate system is hard-coded as read-only by the O-RU vendor. Furthermore, the O-DU may not be aware of the internal architecture of the O-RU, i.e., the physical antenna element connections with the radio frequency (RF) transceiver ports.

[0010] As a result, related art techniques do not allow for muting (eg, switching off) portions of the antenna elements along their respective RF transceiver chains. [Means for solving the problem]

[0011] Embodiments of the present disclosure relate to the implementation of dynamic antenna array reconfiguration in an open radio access network (O-RAN) to save energy in a communication network. Furthermore, embodiments provide a notification mechanism between an O-RU and an O-DU to perform and suggest a transition from one antenna array configuration to another, without significant changes to existing O-RAN management plane (M-Plane) and control user synchronization plane (CUS-Plane) specifications, while allowing the O-RU to report its configuration capability information (e.g., O-RU internal architecture) to the O-DU and the O-DU to apply an antenna array configuration (e.g., beam weights for a generated or predetermined antenna model) in a manner supported by the O-RU's configuration capability information. As a result, antenna calibration requirements for each antenna array configuration can be met and maximum energy savings can be achieved by muting the physical and functional components of the O-RU according to the O-RU's configuration capability information (e.g., O-RU internal architecture).

[0012] According to one embodiment, an apparatus includes an open radio access network (O-RAN) higher layer network function configured to monitor at least one network parameter via an O1 interface to implement dynamic antenna array reconfiguration, and further configured to request a distributed unit (O-DU) to reconfigure the antenna array based on the at least one monitored network parameter satisfying a predetermined condition.

[0013] According to one embodiment, an apparatus includes an O-DU (Distribution Unit). The O-DU is configured to receive configuration capability information from an O-RU (Radio Unit) via management plane (M-Plane) messaging. The O-DU is further configured to receive a request to reconfigure an antenna array from a higher layer network function, and to determine an antenna array configuration supported by the O-RU based on the configuration capability information from the O-RU and based on the request to reconfigure the antenna array from the higher layer network function. Based on the determination, the O-DU applies the supported antenna array configuration via control plane (C-Plane) messaging.

[0014] According to one embodiment, an apparatus includes an O-RU configured to send configuration capability information to an O-DU via management plane (M-Plane) messaging. The O-RU further receives, from the O-DU via control plane (C-Plane) messaging, antenna array configurations supported by the O-RU based on the O-RU's configuration capability information and a request from a higher layer network function to reconfigure the antenna array, and reconfigures an antenna array model based on the antenna array configurations supported for the O-RU.

[0015] According to one embodiment, a method includes, by a higher layer network function of an open radio access network (O-RAN), monitoring at least one network parameter via an O1 interface to implement dynamic antenna array reconfiguration, and further including, by the higher layer network function, requesting a distributed unit (O-DU) to reconfigure the antenna array based on the at least one monitored network parameter satisfying a predetermined condition.

[0016] According to one embodiment, a method includes receiving, by a distributed unit (O-DU), configuration capability information from a radio unit (O-RU) via management plane (M-Plane) messaging. The method further includes receiving, by the O-DU, a request to reconfigure the antenna array from a higher layer network function. The method further includes determining, by the O-DU, antenna array configurations supported by the O-RU based on the configuration capability information from the O-RU and based on the request to reconfigure the antenna array from the higher layer network function. Additionally, the method includes activating, by the O-DU, the supported antenna array configurations via control plane (C-Plane) messaging.

[0017] According to one embodiment, a method includes transmitting, by a radio unit (O-RU), configuration capability information to a distributed unit (O-DU) via management plane (M-Plane) messaging. The method further includes receiving, by the O-RU, antenna array configurations supported by the O-RU from the O-DU via control plane (C-Plane) messaging. The supported antenna array configurations are based on the O-RU's configuration capability information and a request to reconfigure the antenna array from a higher layer network function. The method further includes reconfiguring, by the O-RU, the antenna array configuration of the O-RU based on the antenna array configuration supported for the O-RU.

[0018] According to one embodiment, a non-transitory computer-readable storage medium has stored thereon instructions executable by at least one processor to perform a method, the method including monitoring, by a higher layer network function of an open radio access network (O-RAN), at least one network parameter via an O1 interface to implement dynamic antenna array reconfiguration, and further including, by the higher layer network function, requesting a distributed unit (O-DU) to reconfigure the antenna array based on the at least one monitored network parameter satisfying a predetermined condition.

[0019] According to one embodiment, a non-transitory computer-readable storage medium has stored thereon instructions executable by at least one processor to perform a method. The method includes transmitting, by an O-RU, configuration capability information to a distributed unit (O-DU) via management plane (M-Plane) messaging. The method further includes receiving, by the O-RU, antenna array configurations supported by the O-RU from the O-DU via control plane (C-Plane) messaging. The supported antenna array configurations are based on the O-RU's configuration capability information and a request to reconfigure the antenna array from a higher layer network function. The method further includes reconfiguring, by the O-RU, the antenna array configuration of the O-RU based on the antenna array configuration supported for the O-RU.

[0020] Additional aspects will be set forth in part in the description that follows, and in part will be obvious from the description, or may be realized by practice of the presented embodiments of the present disclosure. [Brief explanation of the drawings]

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

[0022] FIG. 1 illustrates an O-RAN architecture in the related art.

[0023] FIG. 2A illustrates a method for implementing dynamic antenna array reconfiguration from the perspective of a higher layer function within O-RAN, according to one embodiment.

[0024] FIG. 2B illustrates a method for implementing dynamic antenna array reconfiguration from the perspective of higher layer functionality within O-RAN, according to another embodiment.

[0025] FIG. 3 illustrates a method for implementing dynamic antenna array reconfiguration from the perspective of an O-DU, according to one embodiment.

[0026] FIG. 4A illustrates a method for implementing dynamic antenna array reconfiguration in a hierarchical deployment from the perspective of an O-RU, according to one embodiment.

[0027] FIG. 4B illustrates a method for implementing dynamic antenna array reconfiguration in a hybrid deployment from the perspective of an O-RU, according to another embodiment.

[0028] FIG. 5 illustrates an operational flow for dynamic antenna array configuration, according to one embodiment.

[0029] FIG. 6A illustrates a method for dynamic antenna array configuration via C-Plane messaging according to one embodiment.

[0030] FIG. 6B illustrates a method for dynamic antenna array configuration via M-Plane messaging according to one embodiment.

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

[0032] FIG. 8 is a diagram of example components of a device according to one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0033] The following detailed description of exemplary embodiments refers to the accompanying drawings. The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit implementations to the precise form disclosed. Modifications and variations are possible in light of the foregoing disclosure or may be acquired from practice of implementations. Furthermore, one or more features or components of one embodiment may be combined or integrated with other embodiments (or one or more features of other embodiments). Additionally, in the flowcharts and operational descriptions provided below, it is understood that one or more operations may be omitted, one or more operations may be added, one or more operations may be performed concurrently (at least in part), or the order of one or more operations may be rearranged.

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

[0035] Although particular feature combinations are recited in the claims and / or disclosed in the specification, these combinations are not intended to limit the disclosure of possible implementations. Indeed, many of these features may be combined in ways other than those specifically recited in the claims and / or specifically disclosed in the specification. Although each dependent claim listed below may depend directly on only one claim, the disclosure of possible implementations includes each dependent claim in combination with all other claims in the claim group.

[0036] No element, act, or instruction used herein should be construed as critical or required unless explicitly stated otherwise. Also, as used herein, the articles "a" and "an" are intended to include one or more items and may be used interchangeably with "one or more." Where only one item is intended, the term "one" or similar words are used. Also, as used herein, the terms "has," "have," "having," "include," "including," etc. are intended to be open-ended terms. Furthermore, the phrase "based on" is intended to mean "based, at least in part, on," unless expressly stated otherwise. Furthermore, phrases such as "at least one of A and B" or "at least one of A or B" are understood to include A only, B only, or both A and B.

[0037] In O-RAN, key performance indicators (KPIs) may relate to network traffic capacity and are monitored by the RIC (i.e., NRT-RIC and / or nRT-RIC) and / or the Cognitive Self-Organizing Network (CSON) in coordination with the O-CU, O-DU, and O-Cloud according to Figure 1.

[0038] For example, the key performance indicators (KPIs) may represent data to be scheduled, number of users in a cell, network traffic scenario over time, user throughput, etc. The key performance indicators (KPIs) allow higher layer network functions (i.e., SMO, RiC, etc.) of O-RAN to determine network parameters.

[0039] Based on the network parameters, a higher network layer network function may trigger a request to implement energy saving (ES) methods in the O-RAN. ES methods may include antenna array configuration. Typically, antenna array configuration includes transceiver TRx control methods and radio frequency (RF) channel reconfiguration methods, such as changing the number of SSB beams or O-RU antenna transmit power to achieve energy savings, O-RU TRx control / antenna array selection, data layer control / number of spatial streams change, etc. Related art does not implement dynamic antenna array reconfiguration, e.g., dynamically changing the antenna array configuration, such as switching from one antenna array model to another (i.e., muting (e.g., switching off) portions of the antenna array (i.e., antenna elements) along their respective RF transceiver chains).

[0040] As a result, due to the unique internal architecture of the O-RU (i.e., read-only (unique) parameters), the absence of a dynamic antenna array reconfiguration ES method is inefficient.

[0041] Furthermore, the related art ES method cannot dynamically coordinate the ES mode based on monitored network traffic capacity KPIs (i.e., based on network parameters), for example, by the O-DU L2 scheduler (i.e., indirectly coordinate the ES means by the nRT-RIC via the E2 interface and / or by the nRT-RIC via the O1 interface).

[0042] Thus, due to the above drawbacks of the related art, maximum energy savings cannot be achieved by implementing dynamic antenna array reconfiguration in O-RAN.

[0043] 2A illustrates a method for implementing dynamic antenna array reconfiguration from the perspective of a higher layer function in an O-RAN, according to one embodiment. Referring to FIG. 2A, in step 201A, a higher layer network function (e.g., an O-RAN function such as an SMO, an NRT-RIC, or an nRT-RIC) monitors at least one network parameter via the O1 interface to implement dynamic antenna array reconfiguration. For example, the higher layer network function monitors at least one of O-RU PBR (Priority Based Routing) / packet scheduling data via the O1 interface, O-DU packet scheduling data via the O1 interface, and O-CU packet scheduling data via the O1 interface.

[0044] In step 202A, the higher layer network function requests the distributed unit (O-DU) to reconfigure the antenna array function based on at least one monitored network parameter satisfying a predetermined condition. For example, the higher layer network function may determine to request the antenna array reconfiguration from the lower layer network function (e.g., O-DU) via the O1 interface based on at least one predetermined first network parameter.

[0045] For example, a higher layer network function (e.g., an O-RAN function such as SMO, NRT-RIC, nRT-RIC, etc.) triggers an energy saving (ES) mode (i.e., a request for antenna array reconfiguration) via the O1 interface based on at least one predetermined first network parameter.

[0046] In one embodiment, triggering the energy saving (ES) mode (i.e., requesting antenna array reconfiguration) is based on a comparison of at least one predetermined first network parameter and a current network parameter obtained from the monitoring step 201A via the O1 interface.

[0047] The comparison may be an evaluation of O1-related key performance indicators (KPIs) of the O-RAN obtained from monitoring O1 packet scheduling data as described above.

[0048] The higher layer network function may determine whether a current network parameter (e.g., a current network parameter reflected by an O1-related KPI, such as throughput, number of users in a cell, user statistics, etc.) is a predetermined first network parameter (e.g., first, second). The predetermined network parameter may be based on a rank indicator (RI) value shared by the UE, a traffic scenario that may be obtained by the O1 interface-related KPI, such as throughput, number of users in a cell, user statistics, etc.

[0049] 2B illustrates a method for implementing dynamic antenna array reconfiguration from the perspective of a higher layer function in an O-RAN according to another embodiment. Referring to FIG. 2B, in step 201B, a higher layer network function (e.g., an O-RAN function such as an SMO, an NRT-RIC, or an nRT-RIC) monitors at least one network parameter via the O1 interface to implement dynamic antenna array reconfiguration. For example, the higher layer network function monitors at least one of O-RU PBR (Priority Based Routing) / packet scheduling data via the O1 interface, O-DU packet scheduling data via the O1 interface, and O-CU packet scheduling data via the O1 interface.

[0050] In step 202B, the higher layer network function requests the radio unit (O-RU) to reconfigure its antenna array functionality based on at least one monitored network parameter satisfying a predetermined condition. For example, the higher layer network function may determine to request the radio function O-RU to reconfigure its antenna array via the O1 interface (e.g., via the management plane fronthaul (FH M-Plane)) based on at least one predetermined first network parameter.

[0051] In one embodiment, a higher layer network function (e.g., an O-RAN function such as SMO, NRT-RIC, nRT-RIC, etc.) triggers an energy saving (ES) mode (i.e., a request for antenna array reconfiguration) over the O1 interface based on at least one predetermined first network parameter.

[0052] 2B, a higher layer network function (e.g., SMO, RIC) may request RF channel reconfiguration / antenna array selection (NES) directly (without messaging via the O-DU) to the O-RU via the O1 interface (e.g., via the FH M-Plane) according to the O-RAN hybrid architecture as shown in FIG. 1. In this case, the O-RU may inform the O-DU about the changed configuration (i.e., the O-RU may directly apply the antenna array reconfiguration request from the higher layer network function (e.g., RIC)) so that the O-DU can schedule data accordingly.

[0053] In an embodiment, the O-RU may reconfigure the array configuration based on a request from a higher network layer to reconfigure the antenna array, the request being based on at least one monitored network parameter satisfying a predetermined condition.

[0054] To this end, in one embodiment, the O-RU may send a message to the TRx antenna array (TRx array) for reconfiguration and may notify the O-DU of the reconfiguration after implementing the changes. In one embodiment, the O-RU may acknowledge the antenna array reconfiguration request (i.e., triggering ES mode when the O-RAN is underutilized) to the O-DU.

[0055] FIG. 3 illustrates a method for implementing dynamic antenna array reconfiguration from the perspective of an O-DU, according to one embodiment.

[0056] 3, in step 301, the O-DU receives configuration capability information from an O-RAN radio unit (O-RU) via management plane (M-Plane) messaging. For example, the O-RU reports configuration capability information such as the energy saving mode "urn:o-ran:module-cap:1.0" supported by the O-RU.

[0057] For example, the antenna configuration capability information may be hard-coded by the vendor during manufacturing, along with at least one of a unique name, index, and reference for identifying the antenna array configuration capability (e.g., the technical specifications of the antenna array), the number of spatial streams / layers supported for each configuration of the antenna array, the antenna calibration data to be applied by the O-RU during a configuration change, a value referring to the achievable energy saving for each configuration, the associated beam weights (predetermined beam weights), etc. In one embodiment, when the O-RU is powered on (initialized), the O-RU begins reporting the supported energy saving modes (i.e., the antenna array configuration capability information) and the hard-coded antenna array model, along with other initialization parameters, to the O-DU using the M-Plane yang model (e.g., "urn:o-ran:module-cap:1.0" and "urn:o-ran:hardware:1.0").

[0058] In one embodiment, an "energy-saving-by-transmission-blanks" parameter may be used to transmit configuration capability information from the O-RU to the O-DU. This uses the existing M-Plane model and allows the O-RU to provide (i.e., define) new parameters to enable reporting new energy-saving parameters (e.g., "energy-saving-by-rf-channel-reconfiguration," "energy-saving-by-advanced-sleep-modes," "energy-saving-by-modify-no-of-spatial-streams," etc.).

[0059] An example for the "energy-saving-by-transmission-blanks" parameter in the M-Plane model could be: grouping energy-saving-method { status active; description "Grouping for energy saving method. Note: This grouping is meant for energy saving methods."; leaf energy-saving-method { type enumeration { enum RF-CHANNEL-RECONFIGURATION { description "RF Channel Reconfiguration will be used"; } enum ADVANCED-SLEEP-MODE { description "Advanced Sleep Mode will be used"; } enum MODIFY NO OF SPATIAL STREAMS { description "No of Spatial Streams will be modified"; } } description "Energy saving method which can be supported by the O-RU. An O-RU may further refine the applicability of energy saving methods per endpoint using o-ran-uplane-conf.yang model"; } } leaf energy-saving-by-RF-channel-reconfiguration { type boolean; mandatory true; description "Parameter informs if unit supports energy saving by RF channel reconfiguration"; } leaf energy-saving-by-Advanced-Sleep-Mode { type boolean; mandatory true; description "Parameter informs if unit supports energy saving by Advanced sleep mode"; } leaf energy-saving-by-modify-no-of-spatial-streams { type boolean; mandatory true; description "Parameter informs if unit supports energy saving by Modifying no of spatial streams / layers"; }

[0060] For the existing M-Plane yang model, to ensure backward compatibility, if the O-RU does not support custom configuration or RF channel reconfiguration / antenna array selection approaches for the ES, the O-RU may flag the aforementioned energy saving mode as "false".

[0061] In other embodiments, the O-RU configuration capability information may comprise supported features, such as energy saving features supported in "o-ran-wg4-features.yang". The O-RU may indicate the energy saving features supported in "o-ran-wg4-features.yang" to the O-RU controller (i.e., the O-DU or a higher layer network function (e.g., SMO)).

[0062] According to one embodiment, in line with the O-RAN Open Fronthaul M-Plane specification, which defines the management plane of the open fronthaul interface and the associated YANG model, the O-RU may indicate the energy saving features (e.g., Yang features such as "o-ran-wg4-features.yang") supported in the associated YANG model to an O-RU controller, such as the O-DU and / or higher-order network function (i.e., SMO, etc.).

[0063] To this end, the O-RU configuration capability information may comprise feature capabilities supported by the O-RU using YANG feature name tags such as "TRX-CONTROL", "TRX-ON-OFF", "ADVANCED-SLEEP-MODE", "SLEEP-MODE", "LIGHT-HIBERNATE-SLEEP", "DEEP-HIBERNATE-SLEEP" (i.e., deep sleep), etc.

[0064] The YANG feature name tag "TRX-CONTROL" or "TRX-ON-OFF" may describe on / off switching of an RF channel or Tx / Rx array element (i.e., switching an RF channel or Tx / Rx array element on or off), while M-Plane activation as an optional feature control may not be available.

[0065] The YANG feature name tag "ADVANCED-SLEEP-MODE" or "SLEEP-MODE" may describe switching off (i.e., switching to sleep) the carrier and associated O-RU circuitry and / or O-RU components based on the respective activated sleep mode (i.e., muting and / or switching on / off physical and functional components of the O-RU), while M-Plane activation as an optional feature control may not be available.

[0066] The YANG feature name tag "HIBERNATE-SLEEP" may describe O-RU energy saving by switching on / off all [tr]x-carriers and associated O-RU circuitry / components for a longer period of time. The longer period compared to other sleep modes allows for an optional feature control to be implemented as an M-Plane-based sleep mode "hardware / component / energy-saving-enabled".

[0067] The YANG feature name tag "LIGHT-HIBERNATE-SLEEP" may describe O-RU energy saving by switching on / off carriers and associated O-RU circuitry / components for longer periods without switching synchronization off. The longer periods compared to other sleep modes allow for optional feature control to be implemented as an M-Plane-based sleep mode "hardware / component / energy-saving-enabled".

[0068] The YANG feature name tag "DEEP-HIBERNATE-SLEEP" (i.e., deep sleep) may describe O-RU energy saving by switching off synchronization and switching on / off carriers and associated O-RU circuitry / components for longer periods. The longer periods compared to other sleep modes allow for optional feature control to be implemented as an M-Plane-based sleep mode "hardware / component / energy-saving-enabled".

[0069] According to one embodiment, the YANG feature name tag "ADVANCED-SLEEP-MODE" or "SLEEP-MODE" may define various short-term (C-Plane based) sleep modes. For example, advanced sleep modes may be shorter sleep periods such as milliseconds, seconds, or minutes, and may be activated by, for example, an ST4 C-Plane message via control plane (C-Plane) messaging.

[0070] According to one embodiment, the "HIBERNATE-SLEEP" mode may be activated by utilizing M-Plane (e.g., by setting the parameter "+--rw energy-saving-enabled? boolean {ENERGYSAVING}?" in the respective "o-ran-hardware.yang" module to "True" or "Yes") with reference to the YANG feature name tag "HIBERNATE-SLEEP" for a longer period of time.

[0071] According to one embodiment, with reference to the YANG feature name tags "LIGHT-HIBERNATE-SLEEP" and "DEEP-HIBERNATE-SLEEP" for differentiating longer sleep depending on whether the synchronization plane circuitry is switched off, the "LIGHT-HIBERNATE-SLEEP" mode with synchronization and the "DEEP-HIBERNATE-SLEEP" mode without synchronization may be implemented in the same way as "HIBERNATE-SLEEP" by utilizing M-Plane (e.g., by setting the parameter "+--rw energy-saving-enabled? boolean {ENERGYSAVING}?" in the respective "o-ran-hardware.yang" module to "True" or "Yes").

[0072] Based on the yang module as defined in 「o-ran module.cap.yang」, referring to the O-RU that reports to the O-DU (i.e., the O-RU receives the O-RU configuration capability information from the O-DU), or when the wake-up time is too short for the defined sleep transition time, the advanced sleep mode (ASM) may support a sleep mode (SM) with short-term (C-Plane based) sleep modes having different wake-up times (e.g., multiple sleep modes such as SM#0, SM#1, SM#2, SM#3, etc., where for the period, SM#0 < SM#1 < SM#2 < SM#3). Further, the advanced sleep mode (ASM) may support a sleep mode with a long-term (M-Plane based) sleep mode (e.g., hibernation sleep without synchronization (i.e., the S-Plane is switched off), or hibernation sleep mode regardless of the presence or absence of synchronization (i.e., the S-Plane is switched on / off or switched to sleep)). On the other hand, light hibernation sleep represents an M-Plane based sleep mode with synchronization (i.e., the S-Plane remains in an active state), and deep hibernation sleep represents an M-Plane based sleep mode without synchronization (i.e., the S-Plane is switched off).

[0073] According to one embodiment, the advanced sleep mode (ASM) has a wake-up time (minimum or guaranteed) for each sleep mode. The shortest sleep mode based on the C-Plane (e.g., SM#0) may not be defined by the minimum or guaranteed wake-up time, and may be defined by the sleep transition time.

[0074] Based on the yang module as defined in "o-ran module.capc.yang", an O-RU reporting to an O-DU and / or SMO may support C-Plane messages such as Section Type 8 (ST8) "ready" messages and C-Plane messages containing command scopes (e.g., "CARRIER-COMMAND", "ARRAY-COMMAND", "O-RU-COMMAND") such as Section Type 4 (ST4) messages.

[0075] According to one embodiment, a TRx control method for reconfiguring an antenna array may include TRx control configurations identified by their unique configuration identities or names. The antenna array model of the TRx control configuration includes at least one antenna mask (antMask). Antenna mask bit combinations may be limited to supported TRx control configurations. The antenna mask bits may be "0" to identify antenna elements to be switched off and "1" to identify active elements of the antenna array. Furthermore, the TRx control configuration may include, in addition to the mask bits for the at least one antenna mask (antMask), at least one antenna layer mask bit for generating an antenna layer mask (antLayerMask).

[0076] To this end, the O-RU may report its capabilities via the Yang model "o-ran-module-cap.yang" for TRx control and data layer control. The Yang model "o-ran-module-cap.yang" may include the following summary parameters: o-ran-module-cap.yang - TRx control and data layer control module: o-ran-module-cap +--rw module-capability +--ro ru-capabilities / / TRx control - Capability reporting | +--ro trx-control-capability {or-feat:TRX-CONTROL}? | | +--ro number-of-supported-trx-control-configuration? Uint8 / / number of supported TRx control configuration. | | +--ro supported-trx-control-configuration* [name] | | | +--ro configuration-name string / / unique name of each TRx control configuration | | | +--ro antenna-mask? binary or bits / / antMask list - antenna mask per TRx control config for all | | | +--ro antenna-layer-mask? binary or bits / / antLayerMask list - antenna layer mask per TRx control config for all | | | +--ro transition-time or wake-up-time uint32 / / transition time (list) associated with each configuration change for the supported TRx control configurations and as a function of sub carrier spacing. Since for 15 KHz, 1 slot is 1 milli second, and for 30 KHz, 1 slot is 0.5 milli second or 500 micro-seconds | | | +--ro energy-saving-ratio uint8 / / percentage of energy saving per TRx control configuration / / data-layer / spatial streams control - Capability reporting | +--ro data-layer-control-supported? boolean {or-feat:TRX-CONTROL}? / / Data layer control / limiting no of spatial streams supported by O-RU or not?

[0077] According to one embodiment, the supported TRx control configurations may have transition times (i.e., different from the ASM wake-up time) that define the minimum or guaranteed time required to switch from a baseline configuration to a particular configuration (i.e., switching from a baseline 64TRx antenna array to another antenna mask configuration, such as a 32TRx antenna array model). The transition time (i.e., wake-up time) as a function of subcarrier spacing associated with each configuration change for the supported TRx control configurations may be, for example, 1 millisecond per slot for 15 KHz, 0.5 milliseconds or 500 microseconds per slot for 30 KHz, etc.

[0078] According to one embodiment, the O-RU may report data layer control capabilities or capabilities to limit the number of spatial streams according to the Yang model "o-ran-module-cap.yang" as described above for at least one supported (i.e., given) antenna configuration.

[0079] In one embodiment, the TRx of an antenna array (e.g., a 64T64R antenna array) may be kept active while gain (i.e., energy saving gain) may be realized from switching off the O-RU processing equipment by changing the number of data layers / spatial streams. According to one embodiment, a TRx control method may include control for switching on / off the radio frequency front end (RFFE) of the radio frequency (RF) processing unit for the entire RF transceiver chain and / or some of the RF channels / antenna elements.

[0080] Furthermore, according to another embodiment, the TRx control method may include control for switching on / off components, circuits, and computing engines of the digital baseband and O-RAN fronthaul processing units (i.e., physical components of the O-RU).

[0081] According to an embodiment of a sleep mode having an advanced sleep mode (ASM) with a short-term (C-Plane based) sleep mode and a long-term (M-Plane based) sleep mode, the wake-up latency (i.e., wake-up time or sleep transition time) for the ASM and the wake-up latency of the TRx control may be different and may not interfere (e.g., disrupt) with each other.

[0082] Based on the yang module as defined in "o-ran module.cap.yang", an O-RU reporting to an O-DU and / or SMO may support sleep period extension and emergency wake-up via M-Plane or C-Plane messaging for normal (i.e., scheduled or pre-defined) wake-up.

[0083] Additionally, based on the yang module as defined in "o-ran module.cap.yang", the O-RU reporting to the O-DU and / or SMO may provide information such as the percentage of achievable energy savings.

[0084] Furthermore, based on the yang module as defined in "o-ran module.cap.yang", an O-RU reporting to the O-DU and / or SMO may support notification messaging about the CU-Plane active or inactive state (e.g., notification that may be needed to ensure that the CU-Plane becomes active after a sleep period has passed (i.e., the CU-Plane circuitry may be switched off for defined, undefined, and / or longer sleep periods). To this end, an O-RU reporting to the O-DU and / or SMO supports notification from the O-RU to the O-DU regarding the CU-Plane status if it is switched off during any of the sleep mode activations.

[0085] Generally, "o-ran-module-cap.yang" relates to common O-RU capabilities (i.e., O-RU configuration capability information for sleep modes (e.g., advanced sleep mode)) and CU-Plane status reporting for implementing sleep modes (e.g., advanced sleep mode) and TRx control methods.

[0086] To this end, "o-ran-module-cap.yang", in addition to other YANG models, may comprise all the information necessary to implement antenna array configuration support by the O-RU (i.e., based on the O-RU configuration capability information).

[0087] According to one embodiment, in addition to other YANG models, "o-ran-module-cap.yang" for the TRx control method to reconfigure the antenna array may include TRx control configurations identified by their unique configuration identities or names. The antenna array model of the TRx control configuration includes at least one antenna mask (antMask). Antenna mask bit combinations may be limited to supported TRx control configurations. The antenna mask bits may be "0" to identify antenna elements to be switched off and "1" to identify active elements of the antenna array. Furthermore, the TRx control configuration may include, in addition to the mask bits for the at least one antenna mask (antMask), at least one antenna layer mask bit for generating an antenna layer mask (antLayerMask).

[0088] The Yang model "o-ran-module-cap.yang" may include parameters according to the following summary: o-ran-module-cap.yang - Advanced sleep mode module: o-ran-module-cap +--rw module-capability +--ro ru-capabilities | +--ro max-num-component-carriers? uint8 | x--ro max-num-bands? uint16 / / Advanced sleep mode - Capability reporting | +--ro advanced-sleep-mode-capability? enumeration {or-feat:ADVANCED-SLEEP-MODE}? | | +--ro supported-sleep-modes* [name] / / list of supported sleep modes like sleep mode 0, 1, 2, and 3 (SM#0-3) | | | +--ro sleep-mode-name string / / sleepMode0 (SM#1), sleepMode1 (SM#2), sleepMode2 (SM#2), and sleepMode3 (SM#3) | | | +--ro wake-up-time uint32 / / wake-up time list (minimum or guaranteed) associated with each sleep mode and represented in slots as a function of Sub carrier spacing. For e.g., SM#1 - L slots, SM#2 - M slots, and SM#3 - N slots. The wake-up time in slots are listed for all supported sub carrier spacing by O-RU. Since for 15 KHz, 1 slot is 1 milli second, and for 30 KHz, 1 slot is 0.5 milli second or 500 micro-seconds. | | | +--ro energy-saving-ratio uint8 / / percentage of energy saving per sleep mode | +--ro hibernate-sleep-capability {or-feat:HIBERNATE-SLEEP}? / / option#1: longer sleep duration | | +--ro hibernate-wake-up-time or wake-up-time-hibernate uint32 / / wake-up time in milli seconds for hibernate sleep | +--ro light-hibernate-sleep-capability {or-feat:LIGHT-HIBERNATE-SLEEP}? / / option#2a: longer sleep duration with synchronization | | +--ro lh-wake-up-time or wake-up-time-lh uint32 / / wake-up time in milli seconds for light hibernate sleep | +--ro deep-hibernate-sleep-capability {or-feat:DEEP-HIBERNATE-SLEEP}? / / option#2b: longer sleep duration without synchronization | | +--ro dh-wake-up-time or wake-up-time-dh uint32 / / wake-up time in milli seconds for deep hibernate sleep | | +--ro supported-command-scope* enumeration / / supported ST4 command scope such as “CARRIER-COMMAND, ARRAY-COMMAND, O-RU-COMMAND” to be reported by O-RU. For e.g., one or two or all three | | +--ro st8-ready-msg-supported? boolean / / O-RU already reports the support of Section Type (ST) 8 message in supported-section-types, hence in NES perspective support of “ready” command in ST8 message to reported by O-RU as a capability | | +--ro sleep-duration-extension-supported? boolean / / in defined sleep, if O-DU wants to extend the ongoing sleep it can issue sleep extension C Plane command (short sleep duration) and M Plane command (long sleep duration). The supported of this could be advertised by O-RU as an optional. | | +--ro emergency-wake-up-by-cplane-command-supported? boolean / / (in defined (not guaranteed) or undefined sleep duration, O-DU could any time interrupt the sleep by issuing emergency wake-up C Plane command, provided CU plane remain active or CU plane circuit ON. This support could be advertised by O-RU as an optional. | | +--ro emergency-wake-up-by-mplane-command-supported? boolean / / (in defined (not guaranteed) or undefined sleep duration, O-DU could any time interrupt the sleep by issuing emergency wake-up command via M Plane as CU plane is turned off. This support could be advertised by O-RU as an optional.

[0089] The above summary of the Yang model "o-ran-module-cap.yang" references common O-RU capabilities for both TRx control and advanced sleep modes.

[0090] According to one embodiment, the supported TRx control configurations may have transition times (i.e., different from the ASM wake-up time) that define the minimum or guaranteed time required to switch from a baseline configuration to a particular configuration (i.e., switching from a baseline 64TRx antenna array to another antenna mask configuration, such as a 32TRx antenna array model). The transition time (i.e., wake-up time) as a function of subcarrier spacing associated with each configuration change for the supported TRx control configurations may be, for example, 1 millisecond per slot for 15 KHz, 0.5 milliseconds or 500 microseconds per slot for 30 KHz, etc.

[0091] According to one embodiment, the TRx control method may include control to switch on / off the radio frequency front end (RFFE) of the radio frequency (RF) processing unit for the entire RF transceiver chain and / or some of the RF channels / antenna elements.

[0092] Furthermore, according to another embodiment, the TRx control method may include control for switching on / off components, circuits, IP, computing engines of the digital baseband and O-RAN fronthaul processing units (i.e., physical components of the O-RU).

[0093] According to an embodiment of a sleep mode having an advanced sleep mode (ASM) with a short-term (C-Plane based) sleep mode and a long-term (M-Plane based) sleep mode, the wake-up latency (i.e., wake-up time or sleep transition time) for the ASM and the wake-up latency of the TRx control method may be different and may not interfere (e.g., disrupt) with each other.

[0094] Furthermore, for both the TRx control method and sleep mode (e.g., advanced sleep mode), common capability parameters to be reported to the O-DU via the M-Plane by the O-RU configuration capability information may include the C-Plane ST8 "ready" message and sleep period extension (e.g., for a defined sleep, if the O-DU needs to extend the sleep mode, it sends a sleep extension command just before the start of the wake-up time). If the CU-Plane remains active, the extension command may be based on the C-Plane for a short sleep period. If the CU-Plane is switched off, the extension command may be based on the M-Plane for a long sleep period.

[0095] Furthermore, for both the TRx control method and sleep mode (e.g., advanced sleep mode), a common capability parameter to be reported to the O-DU via the M-Plane by the O-RU configuration capability information may include emergency wake-up from sleep of the O-RU. This capability may be reported by the O-RU via the M-Plane. For example, in the case of a sleep mode interruption, if the O-DU needs to interrupt sleep mode, it sends a sleep mode interrupt command (i.e., a C-Plane command). If the CU-Plane remains active, the emergency wake-up command may be based on the C-Plane for a short sleep period (defined or undefined). If the CU-Plane is switched off, the emergency wake-up command may be based on the M-Plane for a long sleep period (defined or undefined).

[0096] According to one embodiment, "o-ran-module-cap.yang" in addition to other YANG models is for CU-Plane status reporting (e.g., for implementing O-RU capabilities for defined and undefined sleep modes). "o-ran-module-cap.yang" comprises information for enabling CU-Plane circuits to be switched off to achieve additional energy savings. The information may include name and status identifiers of "rx-array-carriers" for reporting user plane configuration, and name, action, and state for the cu-plane. Based on the above information, the O-DU may switch on or wake up the CU-Plane circuit through the M-Plane. According to one embodiment, a notification is required to indicate whether the CU-Plane becomes active (wakes up from sleep), and the same may be defined in "o-ran-uplane.yang", respectively.

[0097] The Yang model "o-ran-uplane.yang" may include parameters according to the following summary: o-ran-uplane-conf.yang +--ro rx-array-carriers* [name] +--ro name -> / user-plane-configuration / rx-array-carriers / name +--ro state? -> / user-plane-configuration / rx-array-carriers / state +---n cu-plane-state-change | +--ro cu-plane [name] | +--ro active? -> / user-plane-configuration / cu-plane / active; Active / Inactive | +--ro state? -> / user-plane-configuration / cu-plane / state: Enabled / Disabled

[0098] According to one embodiment for the use case RF channel reconfiguration (i.e., RF channel switch off / on), a sub-use case may be defined as TRx control (i.e., antenna masks may be defined per array level, so Tx array control and Rx array control may be required separately). For this sub-use case, the O-RU may include at least one of the following capability reporting (i.e., configuration capability information): reporting support for TRx control activation / deactivation based on the C-Plane and M-Plane; reporting a list of supported antenna array configurations / TRx control configurations (e.g., valid antenna mask values ​​(per antenna array configuration value)) with unique names; reporting wake-up time / duration as a function of SCS (subcarrier spacing) (i.e., this wake-up may be different from the wake-up time / duration reported for advanced sleep mode); reporting support for TRx control sleep mode, in addition to other capability reporting. This may include reporting the amount of achievable energy saving / power saving / energy saving ratio per antenna array configuration (Tx array and / or Rx array) or TRx control (Tx control and / or Rx control), reporting support for sleep for defined and undefined periods, ST8 "ready" messages, sleep period extension, and emergency wake-up, and reporting the O-RU internal architecture (function blocks) using valid YANG data model parameters to achieve maximum energy saving (i.e., disclosing the O-RU internal architecture).

[0099] According to another embodiment, a sub-use case for the use case RF channel reconfiguration (i.e., RF channel switch off / on) may be included in the O-RU's capability reporting (i.e., configuration capability information) that supports a list of maximum supported spatial streams / data layers per antenna array (TRx control) configuration. For example, this sub-use case may be defined as data layer control.

[0100] According to another embodiment, for example, a sub-use case may be defined as an advanced sleep mode. This sub-use case may be included in the capability reporting (i.e., configuration capability information) of an O-RU that supports at least one of the following capability reporting (i.e., configuration capability information): The configuration capability information may include, among other capability reporting, at least reporting of wake-up periods associated with each sleep mode as a function of SCS, reporting of the amount of energy savings achievable per sleep mode type, reporting of support for defined and undefined duration sleep, ST8 "ready" messages, sleep period extensions, and emergency wake-up.

[0101] According to another embodiment, a sub-use case for the use case RF channel reconfiguration (i.e., RF channel switch off / on) may be defined as hibernate sleep. For this sub-use case, the O-RU may include at least one of the following capability reporting (i.e., configuration capability information): reporting of support for hibernate sleep (i.e., "Deep-Sleep"), such as long-term sleep (light / deep sleep), reporting of support for carrier removal / deconfiguration by the O-RU during long sleep, and reporting of support for switching off the C-Plane, U-Plane, and S-Plane while keeping the M-Plane processing unit active (i.e., support for O-DU request (e.g., by sending an appropriate RPC or by the O-RU's internal logic)), in addition to other capability reporting.

[0102] In step 302, the O-DU receives a request to reconfigure the antenna array from a higher layer network function. As described in step 202A of FIG. 2A, the request to reconfigure the antenna array is based on at least one monitored network parameter satisfying a predetermined condition.

[0103] In step 303, the O-DU determines the antenna array configuration supported by the O-RU. The determined antenna array configuration is based on configuration capability information from the O-RU, as described in step 203, and a request to reconfigure the antenna array from a higher layer network function, as described in step 202.

[0104] In step 304, the O-DU applies the supported antenna array configuration via control plane (C-Plane) messaging or via management plane (M-Plane) messaging.

[0105] According to an embodiment, as described in step 301, the sleep mode may be control plane (C-Plane) or management plane (M-Plane) compatible depending on the sleep duration.

[0106] According to an embodiment of a sleep mode having an advanced sleep mode (ASM) with a short-term (C-Plane based) sleep mode and a long-term (M-Plane based) sleep mode, the wake-up latency (i.e., wake-up time or sleep transition time) for the ASM and the wake-up latency of the TRx control may be different and may not interfere (e.g., disrupt) with each other.

[0107] 2A, 2B, and 3, the method for implementing dynamic antenna array reconfiguration in an open radio access network (O-RAN) according to steps 201-205 provides a notification mechanism between the O-RU and the O-DU to perform and suggest transitions from one antenna array configuration to another antenna array configuration without significant modifications to existing O-RAN CUS-Plane and M-Plane specifications, while allowing the O-RU to report its configuration capability information (e.g., O-RU internal architecture) to the O-DU.

[0108] This has the advantage that the O-DU can apply beam weights for a generated or predetermined antenna model in a manner supported by the O-RU's configuration capability information (e.g., the O-RU's internal architecture) so that the antenna calibration requirements for each antenna array configuration are met and maximum energy savings can be achieved by muting the O-RU's physical and functional components in accordance with the O-RU's configuration capability information.

[0109] The method for implementing dynamic antenna array reconfiguration in an Open Radio Access Network (O-RAN) according to FIGS. 2A, 2B, and 3 may be implemented in at least one device comprising a memory for storing instructions and a processor configured to execute the instructions.

[0110] According to one embodiment, an apparatus includes an open radio access network (O-RAN) higher layer network function configured to monitor at least one network parameter via an O1 interface to implement dynamic antenna array reconfiguration, and further configured to request a distributed unit (O-DU) to reconfigure the antenna array based on the at least one monitored network parameter satisfying a predetermined condition.

[0111] According to one embodiment, an apparatus includes an O-DU (Distribution Unit). The O-DU is configured to receive configuration capability information from an O-RU (Radio Unit) via management plane (M-Plane) messaging. The O-DU is further configured to receive a request to reconfigure an antenna array from a higher layer network function, and to determine an antenna array configuration supported by the O-RU based on the configuration capability information from the O-RU and based on the request to reconfigure the antenna array from the higher layer network function. Based on the determination, the O-DU applies the supported antenna array configuration via control plane (C-Plane) messaging.

[0112] 4A illustrates a method for implementing dynamic antenna array reconfiguration in a hierarchical deployment from the perspective of an O-RU. Referring to FIG. 4A, the O-RU communicates (e.g., sends at initialization and / or during operation) its configuration capability information necessary to perform antenna array reconfiguration to the O-DU via the M-Plane, receives (from the O-DU) antenna array configurations supported by the O-RU via control plane (C-Plane) messaging or management plane (M-Plane) messaging, and reconfigures the antenna array antenna model based on the antenna array configurations supported for the O-RU.

[0113] In step 401A-Alt, the O-RU powers up and initializes the O-RU functions after installation, maintenance, updates, etc. to the O-RAN inventory.

[0114] In step 401A, the O-RU sends its configuration capability information via management plane (M-Plane) messaging. The O-RU configuration capability information described in step 203 of FIG. 2 represents step 301 in FIG. 3, respectively.

[0115] According to an embodiment, in step 401A, upon power-up, the O-RU communicates (e.g., transmits) its configuration capability information necessary to perform antenna array reconfiguration to the O-DU via the M-Plane. In one embodiment, the O-RU exposes (reports) its capability data (including antenna configuration capability information) to the O-DU during startup via a fronthaul (FH) interface to support various ES methods (e.g., RF channel reconfiguration, TRx control methods such as antenna array selection, and sleep modes such as advanced sleep mode). In another embodiment, the O-RU communicates (e.g., transmits) multiple supported antenna models / configurations (i.e., antenna configuration capability information) to the O-DU via the M-Plane.

[0116] In another embodiment, the O-RU communicates (e.g., transmits) its configuration capability information necessary to perform antenna array reconfiguration to the O-DU via the M-Plane during operation. For example, a higher layer network function may perform a rollback of the ES method from an energy-saving network state to the original network state (e.g., switching on the O-RU or a portion of the O-RU). In another case, a higher layer network function may perform a rollback of the ES method from an energy-saving network state or an original state to a high-performance network state (e.g., switching an idle O-RU or a portion of the idle O-RU to maximum performance).

[0117] According to one embodiment, the antenna configuration capability information (O-RU antenna configuration capability information) may be hard-coded by the vendor during manufacturing, along with at least one of the following parameters, a unique name, an index, a reference, etc., for identifying the antenna array configuration capability (e.g., the technical specifications of the antenna array), the number of spatial streams / layers supported for each configuration of the antenna array, the antenna calibration data to be applied by the O-RU during a configuration change, a value referring to the energy saving achievable for each configuration, the associated beam weights (predetermined beam weights), etc. In one embodiment, when the O-RU is powered on (initialized), the O-RU begins reporting the supported energy saving modes (i.e., the antenna array configuration capability information) and the hard-coded antenna array model, along with other initialization parameters, to the O-DU using the M-Plane yang model (e.g., "urn:o-ran:module-cap:1.0" and "urn:o-ran:hardware:1.0").

[0118] According to one embodiment, in line with the O-RAN Open Fronthaul M-Plane specification, which defines the management plane of the open fronthaul interface and the associated YANG model, the O-RU may indicate the energy saving features supported in the associated YANG model (e.g., Yang features such as "o-ran-wg4-features.yang") to a lower-level network function different from the O-RU and / or to a higher-level network function (i.e., an O-RU controller such as an O-DU, SMO, SMO framework, etc.).

[0119] To this end, the O-DU may identify the feature capabilities supported by the O-RU using YANG feature name tags such as "TRX-CONTROL", "TRX-ON-OFF", "ADVANCED-SLEEP-MODE", "SLEEP-MODE", "LIGHT-HIBERNATE-SLEEP", "DEEP-HIBERNATE-SLEEP" (i.e., "DEEP-SLEEP"), etc.

[0120] The YANG feature name tag "TRX-CONTROL" or "TRX-ON-OFF" may describe on / off switching of an RF channel or Tx / Rx array element (i.e., switching an RF channel or Tx / Rx array element on or off), while M-Plane activation as an optional feature control may not be available.

[0121] While the YANG feature name tag "ADVANCED-SLEEP-MODE" or "SLEEP-MODE" may describe switching on / off carrier and associated O-RU circuitry and / or O-RU components based on the respective activated sleep mode (i.e., muting and / or switching on / off physical and functional components of the O-RU), M-Plane activation as an optional feature control may not be available.

[0122] The YANG feature name tag "HIBERNATE-SLEEP" may describe O-RU energy saving by switching on / off carriers and associated O-RU circuitry / components for longer periods of time. The longer periods compared to other sleep modes allow for optional feature control to be implemented as an M-Plane-based sleep mode "hardware / component / energy-saving-enabled".

[0123] The YANG feature name tag "LIGHT-HIBERNATE-SLEEP" may describe O-RU energy saving by switching on / off carriers and associated O-RU circuitry / components for longer periods without switching synchronization off. The longer periods compared to other sleep modes allow for optional feature control to be implemented as an M-Plane-based sleep mode "hardware / component / energy-saving-enabled".

[0124] The YANG feature name tag "DEEP-HIBERNATE-SLEEP" may describe O-RU energy saving by switching off synchronization and switching on / off carriers and associated O-RU circuitry / components for longer periods. The longer periods compared to other sleep modes allow for optional feature control to be implemented as an M-Plane-based sleep mode "hardware / component / energy-saving-enabled".

[0125] According to one embodiment, the YANG feature name tag "ADVANCED-SLEEP-MODE" or "SLEEP-MODE" may define various short-term (C-Plane based) sleep modes. For example, advanced sleep modes may be shorter sleep periods such as milliseconds, seconds, or minutes, and may be activated by control plane (C-Plane) messaging, e.g., by an ST4 C-Plane message.

[0126] According to one embodiment, the "HIBERNATE-SLEEP" mode may be activated by utilizing M-Plane (e.g., by setting the parameter "+--rw energy-saving-enabled? boolean {ENERGYSAVING}?" in the respective "o-ran-hardware.yang" module to "True" or "Yes") with reference to the YANG feature name tag "HIBERNATE-SLEEP" for a longer period of time.

[0127] According to one embodiment, with reference to the YANG feature name tags "LIGHT-HIBERNATE-SLEEP" and "DEEP-HIBERNATE-SLEEP" for differentiating longer sleep depending on whether the synchronization plane circuitry is switched off, the "LIGHT-HIBERNATE-SLEEP" mode with synchronization and the "DEEP-HIBERNATE-SLEEP" mode without synchronization may be implemented in the same way as "HIBERNATE-SLEEP" by utilizing M-Plane (e.g., by setting the parameter "+--rw energy-saving-enabled? boolean {ENERGYSAVING}?" in the respective "o-ran-hardware.yang" module to "True" or "Yes").

[0128] Based on the yang module as defined in "o-ran module.cap.yang", referring to the O-RU that reports to the O-DU and / or SMO, or when the wake-up time is too short for the defined sleep transition time, the Advanced Sleep Mode (ASM) may support a sleep mode with short-term (C-Plane based) sleep modes having different wake-up times (e.g., multiple sleep modes (SM) such as SM#0, SM#1, SM#2, SM#3, etc., where for the periods, SM#0 < SM#1 < SM#2 < SM#3). Further, the Advanced Sleep Mode (ASM) may support a sleep mode with a long-term (M-Plane based) sleep mode (e.g., hibernate sleep without synchronization, or hibernate sleep mode regardless of synchronization), while the light hibernate sleep represents a sleep mode based on the M-Plane with synchronization, and the deep hibernate sleep represents a sleep mode based on the M-Plane without synchronization.

[0129] According to one embodiment, the Advanced Sleep Mode (ASM) has a wake-up time (minimum or guaranteed) for each sleep mode. The shortest sleep mode based on the C-Plane (e.g., SM#0) may not be defined by the minimum or guaranteed wake-up time and may be defined by the sleep transition time.

[0130] Based on the yang module as defined in "o-ran module.capc.yang", the O-RU that reports to the O-DU and / or SMO may support C-Plane messages including section type 8 (ST8) "ready" messages and command scopes such as section type 4 (ST4) messages (e.g., "CARRIER-COMMAND", "ARRAY-COMMAND", "O-RU-COMMAND").

[0131] Based on the yang module as defined in "o-ran module.cap.yang", an O-RU reporting to an O-DU and / or SMO may support sleep period extension and emergency wake-up via M-Plane and / or C-Plane messaging.

[0132] Additionally, based on the yang module as defined in "o-ran module.cap.yang", the O-RU reporting to the O-DU and / or SMO may provide information such as the percentage of achievable energy savings.

[0133] Furthermore, based on the yang module as defined in "o-ran module.cap.yang", an O-RU reporting to the O-DU and / or SMO may support notification messaging about the CU-Plane active or inactive state (e.g., notification that may be needed to ensure that the CU-Plane becomes active after a sleep period has passed (i.e., the CU-Plane circuitry may be switched off for defined, undefined, and / or longer sleep periods). To this end, an O-RU reporting to the O-DU and / or SMO supports notification from the O-RU to the O-DU regarding the CU-Plane status if it is switched off during any of the sleep mode activations.

[0134] For this purpose, a modified set of parameters may be defined in the O-RU to enable the O-RU to report energy saving parameters (e.g., "energy-saving-by-rf-channel-reconfiguration", "energy-saving-by-advanced-sleep-modes", "energy-saving-by-modify-no-of-spatial-streams") to report the supported energy saving modes (i.e., antenna array configuration capability information) and hard-coded antenna array model to the O-DU, along with other initialization parameters, similar to the existing M-Plane model (e.g., similar to the energy saving by transmit blank parameters that the O-RU may transmit to the O-DU).

[0135] Furthermore, in one embodiment, to ensure backward compatibility, if the O-RU does not support custom configuration or RF channel reconfiguration / antenna array selection approaches for the ES, the O-RU may mark the aforementioned energy saving mode flag in the M-Plane yang model (e.g., "urn:o-ran:module-cap:1.0" and "urn:o-ran:hardware:1.0") as "false" according to its hard-coded configuration vendor as described above.

[0136] According to one embodiment, a TRx control method for reconfiguring an antenna array may include TRx control configurations identified by their unique configuration identities or names. The antenna array model of the TRx control configuration includes at least one antenna mask (antMask). Antenna mask bit combinations may be limited to supported TRx control configurations. The antenna mask bits may be "0" to identify antenna elements to be switched off and "1" to identify active elements of the antenna array. Furthermore, the TRx control configuration may include, in addition to the mask bits for the at least one antenna mask (antMask), at least one antenna layer mask bit for generating an antenna layer mask (antLayerMask).

[0137] According to one embodiment, the supported TRx control configurations may have transition times (i.e., different from the ASM wake-up time) that define the minimum or guaranteed time required to switch from a baseline configuration to a particular configuration (i.e., switching from a baseline 64TRx antenna array to another antenna mask configuration, such as a 32TRx antenna array model). The transition time (i.e., wake-up time) as a function of subcarrier spacing associated with each configuration change for the supported TRx control configurations may be, for example, 1 millisecond per slot for 15 KHz, 0.5 milliseconds or 500 microseconds per slot for 30 KHz, etc.

[0138] According to one embodiment, the TRx control method may include control to switch on / off the radio frequency front end (RFFE) of the radio frequency (RF) processing unit for the entire RF transceiver chain and / or some of the RF channels / antenna elements.

[0139] Furthermore, according to another embodiment, the TRx control method may include control for switching on / off components, circuits, IPs, cores, computing engines of the digital baseband and O-RAN fronthaul processing units (i.e., physical components of the O-RU).

[0140] According to an embodiment of a sleep mode having an advanced sleep mode (ASM) with a short-term (C-Plane based) sleep mode and a long-term (M-Plane based) sleep mode, the wake-up latency (i.e., wake-up time or sleep transition time) for the ASM and the wake-up latency of the TRx control method may be different and may not interfere (e.g., disrupt) with each other.

[0141] In step 402A, the O-RU receives antenna array configurations supported by the O-RU via control plane (C-Plane) messaging or management plane (M-Plane) messaging, where the supported antenna array configurations are based on the O-RU's configuration capability information and a request to reconfigure the antenna array from a higher layer network function. To this end, step 402A may represent step 304 in FIG. 3. That is, the O-DU applies the supported antenna array configurations via control plane (C-Plane) messaging or management plane (M-Plane) messaging.

[0142] According to an embodiment, as described in step 401A (i.e., step 301 in FIG. 3), the sleep mode may be control plane (C-Plane) or management plane (M-Plane) compatible depending on the sleep duration.

[0143] According to an embodiment of a sleep mode having an advanced sleep mode (ASM) with a short-term (C-Plane based) sleep mode and a long-term (M-Plane based) sleep mode, the wake-up latency (i.e., wake-up time or sleep transition time) for the ASM and the wake-up latency of the TRx control may be different and may not interfere (e.g., disrupt) with each other.

[0144] According to an embodiment of the TRx control method, antenna array configuration is via control plane (C-Plane) messaging or management plane (M-Plane) messaging.

[0145] In step 403A, the O-RU reconfigures the antenna array configuration of the O-RU based on the antenna array configuration supported for the O-RU (i.e., provided, for example, from the O-DU).

[0146] In step 404A, according to one embodiment, the O-RU may signal a change in antenna array configuration from one antenna array configuration to another via management plane (M-Plane) messaging or control plane (C-Plane) messaging.

[0147] For example, the O-RU may notify the O-DU of a configuration change during a transition from one antenna array configuration to another, taking into account the transition time (i.e., wake-up time). The notification may be made to the O-DU via the O-RAN hierarchical architecture or a higher layer network function (e.g., SMO, RIC, etc.).

[0148] According to one embodiment, the O-RU may signal an antenna array configuration change (e.g., back configuration) during a transition from the second antenna array configuration to the first antenna array configuration, taking into account the transition time (i.e., wake-up time). For example, the O-RU signals a rollback configuration change during a transition from an energy saving mode (i.e., second antenna array configuration) to a baseline configuration (i.e., first antenna array configuration), taking into account the transition time.

[0149] The method for implementing dynamic antenna array reconfiguration from the perspective of an O-RU, according to steps 401A-404A, may be implemented in at least one device comprising a memory for storing instructions and a processor configured to execute the instructions.

[0150] According to one embodiment, an apparatus includes an O-RU configured to send configuration capability information to an O-DU via management plane (M-Plane) messaging. The O-RU further receives, from the O-DU via control plane (C-Plane) messaging, antenna array configurations supported by the O-RU based on the O-RU's configuration capability information and a request from a higher layer network function to reconfigure the antenna array, and reconfigures an antenna array model based on the antenna array configurations supported for the O-RU.

[0151] With reference to the method and apparatus according to FIG. 4 , dynamic antenna array reconfiguration, e.g., dynamically changing the antenna array configuration such as switching from one antenna array model to another (i.e., muting (e.g., switching off) portions of the antenna array (i.e., antenna elements) along their respective RF transceiver chains), has the advantage that the ES method can be implemented with maximum efficiency due to the exchange of proprietary internal architecture knowledge (e.g., O-RU read-only (proprietary) parameters).

[0152] 4B illustrates a method for implementing dynamic antenna array reconfiguration in a hybrid deployment from the perspective of an O-RU. Referring to FIG. 4B, in step 401B-Alt, after installation, maintenance, updates, etc. to the O-RAN inventory, the O-RU powers up and initializes O-RU functions.

[0153] In step 401B, the O-RU sends its configuration capability information via management plane (M-Plane) messaging. Step 301 may represent step 203. The O-RU configuration capability information described in step 401B represents step 301 in FIG. 3 and step 401A in FIG. 4A, respectively.

[0154] According to an embodiment, in step 401B, upon power-up, the O-RU communicates (e.g., transmits) its configuration capability information necessary to perform antenna array reconfiguration to the O-DU via the M-Plane. In one embodiment, the O-RU exposes (reports) its capability data (including antenna configuration capability information) to the O-DU and / or higher layer network functions during startup via a fronthaul (FH) interface to support various ES methods (e.g., RF channel reconfiguration, TRx control methods such as antenna array selection, and sleep modes such as advanced sleep mode). In another embodiment, the O-RU communicates (e.g., transmits) multiple supported antenna models / configurations (i.e., antenna configuration capability information) over the M-Plane and / or FH M-Plane.

[0155] In step 402B, the O-RU receives a request to reconfigure an antenna array configuration from a higher layer network function in a hybrid deployment via fronthaul management plane (FH M-Plane) messaging. In one embodiment, the request to reconfigure the antenna array configuration may represent an antenna array configuration that is an antenna array configuration supported by the O-RU. The supported antenna array configuration may be based on the O-RU's configuration capability information and the request to reconfigure the antenna array from the higher layer network function.

[0156] According to an embodiment, the sleep mode may be management plane (M-Plane) compatible depending on the sleep duration, as described in step 402A (ie, step 301 in FIG. 3).

[0157] According to an embodiment of an Advanced Sleep Mode (ASM) having a long-term (M-Plane based) sleep mode, the wake-up latency (i.e., wake-up time or sleep transition time) for the ASM and the wake-up latency of the TRx control may be different and may not interfere (e.g., disrupt) with each other.

[0158] In step 403B, the O-RU reconfigures the antenna array configuration of the O-RU based on a request to reconfigure the antenna array from a higher layer network function (e.g., SMO, RIC, etc.) (e.g., based on the antenna array configuration supported for the O-RU (i.e., provided, for example, by the O-DU to the SMO)). The antenna array configuration may be a baseline configuration or a hard-coded, vendor-centric configuration known to the higher layer network function (e.g., SMO, RIC, etc.).

[0159] In step 404B, according to one embodiment, the O-RU may signal a change in antenna array configuration from one antenna array configuration to another antenna array configuration via the management plane (M-Plane).

[0160] For example, the O-RU may notify the O-DU of a configuration change during a transition from one antenna array configuration to another, taking into account the transition time (i.e., wake-up time). The notification may be made to the O-DU via the O-RAN hierarchical architecture or a higher layer network function (e.g., SMO, RIC, etc.).

[0161] According to one embodiment, the O-RU may signal an antenna array configuration change (e.g., back configuration) during a transition from the second antenna array configuration to the first antenna array configuration, taking into account the transition time (i.e., wake-up time). For example, the O-RU signals a rollback configuration change during a transition from the energy saving mode (i.e., second antenna array configuration) to the baseline configuration (i.e., first antenna array configuration), taking into account the transition time (i.e., wake-up time).

[0162] The method for implementing dynamic antenna array reconfiguration from the perspective of an O-RU, according to steps 401B-404B, may be implemented in at least one device comprising a memory for storing instructions and a processor configured to execute the instructions.

[0163] According to one embodiment, an apparatus includes an O-RU. The O-RU is configured to send configuration capability information to an O-DU via management plane (M-Plane) messaging. The O-RU is further configured to receive a request to reconfigure an antenna array from a higher layer network function via an O1 interface. Based on the request to reconfigure the antenna array from the higher layer network function, the O-RU is further configured to reconfigure the antenna array configuration of the O-RU. The O-RU may be further configured to notify a change in antenna array configuration from one antenna array configuration to another antenna array configuration via management plane (M-Plane) messaging.

[0164] With reference to the method and apparatus according to Figures 4A and 4B, dynamic antenna array reconfiguration, e.g., dynamically changing the antenna array configuration such as switching from one antenna array model to another (i.e., muting (e.g., switching off) portions of the antenna array (i.e., antenna elements) along their respective RF transceiver chains), has the advantage that the ES method can be implemented with maximum efficiency due to the exchange of proprietary internal architecture knowledge (e.g., O-RU read-only (proprietary) parameters).

[0165] 5 illustrates an operational flow for dynamic antenna array configuration, according to one embodiment. Referring to FIG. 5, in operation 1, the O-RU sends configuration capability information to the distributed unit (O-DU) via management plane (M-Plane) messaging, for example, upon initialization.

[0166] In operation 2, a higher-layer network function monitors at least one network parameter via the O1 interface to implement dynamic antenna array reconfiguration. For example, the SMO, RIC, etc. monitors O-CU packet scheduling, O-DU packet scheduling, and / or O-RU policy-based routing (PBR) / packet scheduling via the O-RAN O1 interface. According to the hierarchical architecture, there is an associated delay when determining RF channel reconfiguration based on network capacity utilization. For example, an O-DU may coordinate packet / PRB scheduling with multiple O-RUs, and an O-CU may need to coordinate with multiple O-DUs and thus a large number of O-RUs for the network.

[0167] In operation 3, based on a predetermined network parameter (i.e., based on at least one monitored network parameter satisfying a predetermined condition), a higher layer network function (e.g., SMO, RIC, etc.) decides to request antenna array reconfiguration from the O-DU via the O1 interface.

[0168] In one embodiment, according to a hierarchical architecture, the RIC / CSON, in coordination with the O-DU, requests that the O-RU enter energy saving mode. In one embodiment, the scope of the request may represent RF channel reconfiguration (TRx control and data layer control / number of spatial streams).

[0169] In other embodiments, based on network usage (i.e., number of active users), at least one of the following approaches (i.e., request from higher layer network functions) may be utilized: O-RU TRx control / antenna array selection, changing the number of MIMO spatial streams or data layers for single-user SU / multiple-user MU, changing the number of synchronization signal block SSB beams, changing the O-RU antenna transmit power, etc.

[0170] In operation 4, the O-DU determines the antenna array configuration supported by the O-RU based on the configuration capability information from the O-RU and a request to reconfigure the antenna array from the higher layer network function.

[0171] In operation 5, in accordance with the hierarchical architecture of the O-RAN, the O-DU applies the supported antenna array configuration via control plane (C-Plane) messaging or management plane (M-Plane) messaging (i.e., the O-RU may receive the supported antenna array configuration via C-Plane messaging or M-Plane messaging).

[0172] In one embodiment, the O-DU may apply the TRx control method to the O-RU via control plane (C-Plane) messaging to reconfigure the antenna array with at least one antenna model. For example, the O-DU may send messages via the C-Plane comprising at least one Section Type 0 message with a Section Extension (SE) 7 message, and a Section Type 4 message with at least one of SE 10, 11, 16, and 19 messages.

[0173] In other embodiments, the O-DU applies appropriate beam weights and / or antenna calibration via the C-Plane. For example, the O-DU transmits beam weight and / or antenna calibration configurations based on the activated antenna model implemented by the O-RU (i.e., the O-DU provides the O-RU with predetermined beam weights for each configuration or dynamically generated beam weights to satisfy the O-RU's antenna configuration capability information).

[0174] In another embodiment, the O-DU may schedule fronthaul and M-Plane messages to activate the supported antenna array configurations of the O-RU.

[0175] Alternatively, according to the O-RAN hybrid architecture, in operation 5.1, a higher layer network function (i.e., SMO, RIC, etc.) requests that a radio unit (O-RU) reconfigure its antenna array based on network capacity, traffic scenario, etc. The request may be based on at least one monitored network parameter satisfying a predetermined condition. For example, the RIC requests RF channel reconfiguration, antenna selection (NES), etc. from the O-RU through the O1 interface in the hybrid architecture.

[0176] With reference to the alternative in operation 5.1, the O-RU reconfigures the antenna array configuration of the O-RU based on a request to reconfigure the antenna array from the higher layer network function, as described below in accordance with operation 6.

[0177] Based on the network parameters satisfying the network conditions, the RIC may determine the number of layers / spatial streams after RF channel reconfiguration and / or antenna array selection is determined based on a rank indicator (RI) value shared by the UE. Furthermore, in other embodiments, the RIC may determine the number of layers / spatial streams based on a traffic scenario.

[0178] In operation 6, the O-RU reconfigures the antenna array configuration of the O-RU based on the antenna array configuration supported for the O-RU.

[0179] In other embodiments, the O-RU may implement beam weights and / or antenna calibration by shutting down the appropriate RF chains through the RF interface and processing IQ samples provided by the O-DU to change the antenna array configuration based on the antenna model applied by the O-DU. To this end, the O-RU may configure beam weights and / or antenna calibration by activating a 32T32R antenna array pattern in a 64T64R configuration of the TRx array, and then request that the O-DU apply the correct beam weights for the new configuration.

[0180] Additionally, in one embodiment, the O-RU may perform antenna calibration when implementing the beam weights, and to do so, the O-RU may switch off the RF transceivers associated with the muted antenna elements to achieve maximum power savings.

[0181] After the reconfiguration according to operation 6, in alternative operation 5.2., the O-RU notifies the O-DU of a change in the antenna array configuration. To this end, the O-RU notifies the O-DU of a change in the antenna array configuration at the O-RU in response to a higher network layer request in alternative operation 5.1. For example, the O-RU reports a change from the first antenna array configuration to the second antenna array configuration to the O-DU via management plane (M-Plane) messaging.

[0182] According to an embodiment, the O-RU may configure beam weights and / or perform antenna calibration based on at least one antenna model applied by the O-DU.

[0183] According to another embodiment, the OR-RU may process the IQ samples obtained from the O-DU to change the antenna array configuration by deactivating (e.g., muting or switching off) the appropriate RF chains through an RF interface in the TRx array.

[0184] According to another embodiment, the OR-RU may process the IQ samples to activate a 32T32R configuration within the 64T64R antenna array configuration. In one embodiment, after activation of a 32T32R configuration within the 64T64R antenna array configuration, the O-RU may request that the O-DU apply appropriate beam weights to the (newly) activated 32T32R configuration. To this end, the O-RU may perform antenna calibration based on the (newly) activated 32T32R configuration and may switch off TRxs associated with antenna elements muted according to the (newly) activated 32T32R configuration for maximum energy savings.

[0185] In operation 7, the O-RU signals a configuration change during a transition from one antenna array configuration to another antenna array configuration, taking into account the transition time. For example, the O-RU signals a configuration change during a transition from the baseline configuration (i.e., the first antenna array configuration) to the energy saving mode (i.e., the second antenna array configuration), taking into account the transition time (i.e., the wake-up time).

[0186] In alternative operation 7.1, the O-RU notifies the higher layer network function of a configuration change, for example, from one antenna array configuration to another, via the O1 interface. The notification may take into account the transition time (i.e., wake-up time).

[0187] For example, the O-RU notifies the configuration change during the transition from the baseline configuration (i.e., the first antenna array configuration) to the energy saving mode (i.e., the second antenna array configuration), taking into account the transition time (i.e., the wake-up time).

[0188] 6A illustrates a method for dynamic antenna array configuration via C-Plane messaging, according to one embodiment. Referring to FIG. 5, in step 601A, the O-DU applies the antenna array configuration via control plane (C-Plane) messaging.

[0189] In one embodiment, the O-DU may indicate to the O-RU that a particular resource block or symbol is not used in the C-Plane section type message (e.g., ST0 or ST4 message) (e.g., the O-DU may generate idle periods, guard periods, etc.). Additionally, the O-DU may utilize unrelated (i.e., reserved or not yet defined) U-Plane messages that contain IQ samples (data) for section types (ST0, ST4) as described above (i.e., at least one of C-Plane section type 0 or section type 4 with at least one of section extensions 10, 11, 16, 19, etc.).

[0190] In either case, the purpose of using existing unused resource blocks or symbols in a C-Plane Section type message is to inform (apply to) the O-RU that RF signal transmission (e.g., emission of RF signals by a particular antenna element in an antenna array) may be stopped during a defined idle interval (e.g., to conserve power or to provide an interval for calibration).

[0191] To this end, according to an embodiment, the O-DU may transmit at least one message via the C-Plane, including at least one Section Type 0 message accompanied by a Section Extension (SE) 7 message, and / or a Section Type (ST) 4 message accompanied by at least one of SE10, 11, 16, 19, etc. messages.

[0192] In one example, the O-DU may apply the new antenna array model by using a Section Extension (SE) 7 message along with a Section Type 0 message used in the existing specification for masking / blanking / muting antenna elements with the existing specification (e.g., for SE7, masking the portion of the eAXC ID specified by the ST0 message). In addition to the example, Section Type 4, Section Extension 10, 11, 16, 19 messages may be used during runtime.

[0193] Additionally, in other embodiments, to mute antenna elements for longer periods of time, a C-Plane Section Type 0 message can be used to specify the set of elements to be muted for longer periods of time. The Section Type 0 message is used to specify unused blocks or symbols in the UL and DL.

[0194] The O-DU may indicate to the O-RU that certain resource blocks or symbols are not used (idle periods, guard periods). Similarly, there are no associated U-Plane messages containing IQ data for this section type.

[0195] The purpose is to inform the O-RU that transmission may be suspended during a defined idle interval (e.g., to provide an interval for power saving or calibration). To this end, C-Plane messaging may specify antenna elements that should be muted for a longer period of time to save energy by utilizing Section Type 0 messages.

[0196] Section Type 0 messages may be defined as described in the summary below. [Table 1]

[0197] According to one embodiment, each C-Plane message may mask or mute an antenna element by not assigning a beam weight to it or by assigning beam "0". Such C-Plane messaging can be by symbol, symbol or slot, slot or PRB, PRB (i.e., for shorter duration energy saving mode, as in TDD mode where the Tx chain is switched off during the UL).

[0198] Additionally, by sharing the period with C-Plane messaging, masking or muting by C-Plane messaging may be extended into an energy saving mode for a longer period.

[0199] In one embodiment, the O-DU may apply the antenna array configuration by using the existing specifications (messaging protocols) of the CUS-Plane, for example, for the TRx control method or sleep mode.

[0200] In other embodiments, the O-DU may use a C-Plane ST4 message accompanied by at least one of SE10, 11, 16, and 19 messages when necessary (e.g., during runtime) to apply a (new) antenna array model to the O-RU. In particular, the O-DU may use an ST4 command type (ST4CmdType) to apply a configuration set (i.e., a specific antenna model / configuration).

[0201] In one embodiment, according to the C-Plane ST4 message, the O-DU uses the slot level configuration defined to apply to single / multiple endpoints by utilizing a common Section Type 4 header followed by single / multiple Section Type 4 commands (e.g., ST4CmdType), while each Section Type 4 command is used to specify the configuration command to apply to a specific slot.

[0202] In another embodiment, the O-DU uses the section extension (SE) 10 to apply section types 1, 3, and 5 according to a C-Plane ST4 message with the section extension (SE) 10. For this purpose, the O-DU utilizes C-Plane section information for multiple ports (i.e., layers or Tx / Rx paths) that may be similar except for the beam identifier (ID) or user entity (UE) ID. As a result, when multiple ports share common section information within an O-RU, the O-DU transmits the C-Plane sections via corresponding ports (RU_ports) that are merged into one C-Plane section via a representative port that uses the section extension 10. On the O-DU side, the O-DU pre-configures the representative port via the M-Plane by grouping the ports to be merged to represent the port (in the O-RU). For example, in the case of C-Plane messaging using ST4, Section Extension (SE) 10, the O-DU may use a unique eAxC_ID to address each layer or spatial stream when sending C-Plane and U-Plane messages to the O-RU. Additionally, the SE 10 may be used with a "representative eAxC_ID" (configured via the M-Plane) to reduce the C-Plane overhead when sending multiple messages by sending a single C-Plane message.

[0203] In yet another embodiment, the O-DU uses the section extension (SE) 11 to apply flexible beamforming weights to the O-RU according to a C-Plane ST4 message with the section extension (SE) 11. The SE 11 allows the O-DU to provide different beamforming weights for different physical resource blocks (PRBs) within a section for facilitating (e.g., zero-forcing precoding). For this purpose, the O-DU provides a number of PRBs bundled per beamforming weight (numBundPrb) parameter to inform the O-RU of the number of PRBs to be bundled together and share the beamforming weight accordingly.

[0204] In another embodiment, the option "little endian byte order" may be applied to the "beamforming. weight. in-phase. value / beamforming. weight. q-phase. value" (bfwI / bfwQ) fields (i.e., I / Q beamforming weight fields) if selected via M-Plane so that the O-DU can utilize SE11 as described above. In this case, the C-Plane ST4 message with only section extension 11 applies to C-Plane section types 1 and 3, respectively.

[0205] In yet another embodiment, the O-DU applies antenna mapping in UL beamforming based on UE channel information to the O-RU according to a C-Plane ST4 message with a section extension (SE) 16. The section extension (SE) 16 may also be applied to a C-Plane ST5 message. The section extension (SE) 16 includes a bit mask for each RX endpoint to indicate the antennas to be pre-paired to the RX endpoint (i.e., eAxC_ID). According to this embodiment, the O-DU may use the section extension (SE) 16 with the section extension 10. In this case, the section extension (SE) 16 includes a list of bit masks to indicate the number of RX endpoints used in the section extension 10.

[0206] In yet another embodiment, the O-DU applies compact beamforming information for multiple antenna ports (i.e., "port" in the context of this section extension 19 represents a logical antenna port) to control the TRx according to a C-Plane ST4 message with section extension (SE) 19. Section extension 19 may be applied to C-Plane section types (ST) 1 and 3. According to this embodiment, the O-DU uses section extension 19 to transmit compact beamforming information for multiple antenna ports. For example, "little endian byte order" may be applied to the "bfwI / bfwQ" fields in SE 19. As a result, considering a large number of channel state information reference signal (CSI-RS) ports and multiple channel state information (CSI) resource sets, the use of SE 19 has benefits for channel state information reference signal (CSI-RS) channel messaging.

[0207] In yet another embodiment, the O-DU may use a C-Plane ST0 message to specify a set of antenna elements to be muted (i.e., to apply a (new) antenna array model to be implemented by the O-RU). For this purpose, unused blocks or symbols of existing uplink (UL) and downlink (DL) C-Plane ST0 messages may be used by the O-DU to communicate (apply) a (new) antenna array model to be implemented by the O-RU (e.g., to specify a set of antenna elements to be muted). The use of a C-Plane ST0 message has the advantage that antenna elements of an antenna array may be muted for a longer period of time compared to other C-Plane messages, such as ST4, that accompany at least one of SE10, 11, 16, and 19 messages, because the C-Plane ST0 message may be used to dynamically update the antenna array configuration (i.e., dynamically update / generate at least one antenna model with beam weights and / or required antenna calibrations for the at least one antenna model).

[0208] As a result, by utilizing C-Plane ST0 messages, a given set of antenna elements can be muted for a longer period of time to achieve maximum energy savings.

[0209] Furthermore, in an alternative embodiment, the O-DU may, in accordance with the C-Plane ST4 message, achieve sustainable antenna array configuration application, which may be implemented by the "numslots" command for long-term energy saving. According to this embodiment, the O-DU, the C-Plane ST4 message applies the command to multiple endpoints / eAXC IDs (i.e., arrays for TD beamforming). For this purpose, the "numslots" command is used in the C-Plane ST4 message to specify the number of slots in which the operation (i.e., power save mode) should be performed.

[0210] In step 602A, the O-RU receives antenna array configurations supported by the O-RU from the O-DU via control plane (C-Plane) messaging, where the supported antenna array configurations are based on the O-RU's configuration capability information and a request to reconfigure the antenna array from a higher layer network function.

[0211] According to one embodiment for the use case RF channel reconfiguration (i.e., RF channel switch off / on), a sub-use case may be defined as TRx control (i.e., antenna masks may be defined per array level, so Tx array control and Rx array control may be required separately). For this sub-user case, the O-RU shall provide ST4 C-Plane messaging, including C-Plane messaging supporting the appropriate antenna mask value and sleep mode type, the "numSlots" and "numSlotsExt" fields in the ST4 C-Plane message to indicate the duration for which the antenna array configuration (antenna mask) is active in each sleep mode, C-Plane messaging supporting "numSlots" and "numSlotsExt" to both provision short and long sleep, C-Plane messaging supporting symbol masks representing ST8-based confirmations to indicate correct reception of ST4 C-Plane messages for specific RF channel switch on / off (TRx control and / or data layer control) and / or activation of advanced sleep modes, and C-Plane messaging supporting the ST8 "READY" message to indicate that the O-RU has become active after waking up from an unspecified sleep period. It may include C-Plane messaging for activation of Tx control and Rx control via C-Plane messages, and may include at least one of the following activation / deactivation capabilities:

[0212] According to another embodiment, a sub-use case for the use case RF channel reconfiguration (i.e., RF channel switch off / on) may be defined as data layer control. For this sub-use case, the O-RU may include at least one of the following activation / deactivation capabilities, which may include C-Plane messaging for activation of data layer control using ST4 C-Plane messages: Here, the ST4 message field has mask bits to activate / change the number of data layers / spatial streams for a given antenna array configuration to save additional energy, C-Plane messaging for use cases to reduce the number of spatial streams / data layers for a given antenna array configuration (e.g., 64T64R can support 16 spatial streams, but traffic / throughput / KPI requirements may limit the number of spatial streams to 8 / 4 / 2, etc.), and C-Plane messaging for use cases to change / activate the number of spatial streams per TRx control configuration (e.g., antenna array) based on capabilities reported via M-Plane (e.g., a 64T64R antenna array may support 16 spatial streams when switched to a 32T32R antenna array supporting 8 spatial streams (this number of spatial streams may be a reference for the O-DU to activate only 8 spatial streams when switching from 64T64R to 32T32R)).

[0213] According to another embodiment, a sub-use case for the use case RF channel reconfiguration (i.e., RF channel switch off / on) may be defined as an advanced sleep mode. For this sub-use case, the O-RU may include at least one of the following activation / deactivation capabilities, which may include C-Plane messaging for the sleep mode to be activated by an ST4 C-Plane message: Here, the ST4 C-Plane message may include fields such as "sleepMode" to indicate a specific sleep mode, and "numSlots" and "numSlotsExt" to indicate a time period for which the specific sleep mode should be activated.

[0214] In step 603A, the O-RU reconfigures the antenna array antenna model based on control plane (C-Plane) messaging from the O-DU based on the antenna array configuration supported for the O-RU.

[0215] Alternatively, in one embodiment, the O-RU signals the configuration change during the transition from one antenna array configuration to another, taking into account the transition time.

[0216] With reference to FIG. 6A , the present disclosure provides a notification mechanism between the O-RU and the O-DU to perform and suggest a transition from one antenna array configuration to another antenna array configuration without significant modifications to the existing O-RAN management plane (M-Plane) and control-user synchronization plane (CUS-Plane) specifications, while allowing the O-RU to report its configuration capability information (e.g., O-RU internal architecture) to the O-DU and the O-DU to apply the antenna array configuration (e.g., beam weights for a generated or predetermined antenna model) in a manner supported by the O-RU's configuration capability information.

[0217] As a result, by muting the physical and functional components of the O-RU according to the configuration capability information of the O-RU (e.g., the internal architecture of the O-RU), the antenna calibration requirements for each antenna array configuration can be met and maximum energy savings can be achieved.

[0218] 6B illustrates a method for dynamic antenna array configuration via M-Plane messaging, according to one embodiment. Referring to FIG. 6B, in step 601B, the O-DU applies the antenna array configuration via management plane (M-Plane) messaging.

[0219] For this purpose, M-Plane messaging between the O-DU and O-RU includes at least one Yang module "o-ran:uplane-conf:1.0 yang module" that includes at least one antenna model to be applied to the O-RU for each antenna array configuration. Here, for each of at least one user, a U-Plane configuration message may include at least one antenna array configuration information such as an antenna model. Here, a transport-based endpoint identifier maps user U-Plane configuration messages to the associated O-RU.

[0220] In one embodiment, the O-RU controller (e.g., O-DU or SMO) and the O-RU operation and maintenance (OAM) may exchange their state via M-Plane (e.g., via the "o-ran:uplane-conf:1.0 yang module").

[0221] In other embodiments, a configuration change may be requested by an O-RU controller (e.g., an O-DU or SMO), where the O-RU may decode the M-Plane message and perform the following steps: a shutdown step (e.g., switching off carrier, digital front-end, and TRx functional blocks (i.e., muting the requested TRx (i.e., a specific set of antenna elements) and the respective radio frequency front-end (RFFE) module (i.e., the respective RF chain) according to the requirements (i.e., antenna array reconfiguration requested from a higher layer network function and according to the antenna array model supported by the TRx array according to the antenna configuration capability information reported by the O-RU at initialization)); an activation step (e.g., in case of a rollback configuration to the baseline configuration, switching on the required functional blocks and TRx ports, switching to another more appropriate energy saving mode, etc.). The activation step may be realized by mapping between "low-level-t[r]x-link", "static-low-level-t[r]x-endpoint", and "low-level-t[r]x-endpoint" during implementation of reconfiguration based on the TRx control method for reconfiguring the antenna array.

[0222] According to one embodiment, the antenna array model to be activated is selected from the predetermined models reported by the O-RU as its capabilities (i.e., based on configuration capability information from the O-RU and a request to reconfigure the antenna array from a higher layer network function, the O-DU determines the antenna array configurations (e.g., antenna array models) supported by the O-RU).

[0223] Activation of a particular antenna array configuration may be performed by bit-masking the baseline antenna array (i.e., bit-masking method). According to the bit-masking method, the O-DU on the baseline antenna array configuration (e.g., full antenna array model) performs bit-masking using the following Yang model, which may be sent to the O-RU: description "Y dimension of position of leftmost, bottom array element"; } leaf z { type decimal64 { fraction-digits 4; } units Meter; description "Z dimension of position of leftmost, bottom array element"; } } / / From the above commands, O-DU able to read baseline antenna array model. On top of this, bit masking can be applied according to the expected configuration. / / Beam weights after enabling energy savings mode; How O-DU will generate the beam weights for the new antenna array configuration that has less no of elements than the baseline configuration. grouping endpoint-beam-capacity { leaf max-beams-per-symbol { type uint16 { range "min .. 32767"; } description "Max number of beams within one symbol that can be processed by endpoint or processed collectively by group of endpoints sharing capacity If the parameter is absent or if value 0 is reported for the parameter, then the endpoint does not support beamforming operation."; } / / Gain correction required after reconfiguration to be considered. Since change in RF Channel configuration, no of beams, no of spatial streams etc… will definitely cause the change in gain values. leaf gain-correction { type decimal64 { fraction-digits 4; }

[0224] According to one embodiment, the O-RU OAM may indicate its operational status to the O-RU controller while transmitting, and the O-DU status changes accordingly. As a result, when a higher layer network function (SMO, RIC, etc.) requests the O-DU, the O-DU may start scheduling antenna array model data according to the new configuration.

[0225] According to one embodiment, the supported antenna array configurations may be communicated in an "o-ran:uplane-conf:1.0" Yang model structure. Antenna array configuration parameters, such as a name, index, or reference to identify the antenna array configuration (e.g., configuration set number), the number of antenna elements in a particular configuration set, the array model to be applied (or offset values ​​defining the start and end antenna elements to be activated or muted in a TRx array), and the number of spatial streams supported for each antenna model, are entered into the "o-ran:uplane-conf:1.0" Yang model structure. Here, each configuration applied by the O-DU during ES mode is copied into the U-Plane Configuration message.

[0226] In one embodiment, the number of antenna elements in the new antenna array along with their parameters and associated endpoint mappings (i.e., Tx / Rx array carriers and Tx / Rx links) are configured using M-Plane messaging (e.g., using YANG models such as "o-ran:uplane-conf:1.0", "urn:o-ran:beamforming:1.0", etc.).

[0227] To this end, according to the M-Plane messaging approach, the O-DU communicates the number of elements (i.e., antenna elements) of the (new) antenna array configuration to be implemented by the O-RU, along with the antenna array model parameters and associated endpoint mappings (i.e., the Tx / Rx array carriers and Tx / Rx links are configured using the M-Plane yang model (e.g., "o-ran:uplane-conf:1.0" and "urn:o-ran:beamforming:1.0")).

[0228] For this purpose, the parameters of the respective M-Plane yang models (e.g., "o-ran:uplane-conf:1.0" and "urn:o-ran:beamforming:1.0") are updated to apply the (new) antenna array model / configuration to be implemented by the O-RU.

[0229] For example, in each M-Plane yang model (e.g., "o-ran:uplane-conf:1.0" and "urn:o-ran:beamforming:1.0"), the parameters may include at least one of the total number of elements (antenna elements), the number of elements (in rows and columns) of the antenna array, the offset antenna array model size and / or a bitmask value defining a predetermined antenna array pattern, etc., and are dynamically updated to generate a (new) antenna array model / configuration to be implemented by the O-RU.

[0230] Each M-Plane yang model (e.g., "o-ran:uplane-conf:1.0" and "urn:o-ran:beamforming:1.0") may have the following parameters: | +--rw transport-qualified-processing-element? -> / o-ran-pe:processing-elements / additional-transport-session-type-elements[o-ran-pe:transport-session-type = current() / .. / transport-session-type] / ru-elements / name {feat:MULTIPLE-TRANSPORT-SESSION-TYPE}? | +--rw tx-array-carrier -> / user-plane-configuration / tx-array-carriers / name | +--rw low-level-tx-endpoint -> / user-plane-configuration / low-level-tx-endpoints / name +--rw antenna-array-configuration* [id] {feat:ANTENNA-ARRAY-CONFIGURATION}? | +--rw configuration set id uint16 | +--rw total no of elements uint16 | +--rw no of elements in row uint16 | +--rw no of elements in column uint16 | +--rw offset decimal 64 / / Offset value to define new configurations | +--rw no of spatial streams supported | +--rw amount of energy saving unit16 +--ro rx-arrays* [name] | +--ro name string | +--ro configuration set id uint16 | +--ro total no of elements uint16 | +--ro number-of-rows uint16 | +--ro number-of-columns uint16 | +--ro number-of-array-layers uint8 | +--ro horizontal-spacing? decimal64 | +--ro vertical-spacing? decimal64 | +--ro offset decimal64 / / Offset value of antenna array model | +--ro amount of energy saving unit16 | +--ro no of spatial streams supported unint16 | +--ro normal-vector-direction | | +--ro azimuth-angle? decimal64 | | +--ro zenith-angle? decimal64 | +--ro leftmost-bottom-array-element-position | | +--ro x? decimal64 | | +--ro y? decimal64 | | +--ro z? decimal64

[0231] These parameters as above may be updated to accommodate new antenna array models / configurations.

[0232] In other embodiments, a higher layer network function (SMO, NRT-RIC, nRT-RIC) may control the number of layers / spatial streams. In this case, for example, the higher layer network function may request the O-RU via the M-Plane that the O-DU apply the number of spatial streams to be supported for each TRx / antenna model. For this purpose, the M-Plane uses the "o-ran:uplane-conf:1.0.yang" module and defines the supported spatial streams for each antenna model accordingly.

[0233] In step 602B, the O-RU receives antenna array configurations supported by the O-RU from the O-DU via management plane (M-Plane) messaging, where the supported antenna array configurations are based on the O-RU's configuration capability information and a request to reconfigure the antenna array from a higher layer network function.

[0234] According to one embodiment for the use case RF channel reconfiguration (i.e., RF channel switch off / on), a sub-use case may be defined as TRx control (i.e., Tx array control and Rx array control may be required separately, since antenna masks may be defined per array level). For this sub-use case, the O-RU receives the antenna array configurations supported by the O-RU from the O-DU via management plane (M-Plane) messaging. Here, the supported antenna array configurations include a command for the O-DU to set "trx-control-based-energy-saving enabled" to "true" (where "1" means sleep and "0" means awake / active) using the "o-ran.hardware.yang" module, in addition to other commands to activate and deactivate the O-RU, a command for the O-DU to activate a specific TRx control (at the Tx and / or Rx antenna array) configuration, or to revert to the baseline antenna array (antenna masks are all "0" / "1", based on the implementation) using the "o-ran.hardware.yang" module. <rpc> <edit-config> <antenna-mask>", a command to change beam weights and antenna calibration during TRx control activation, and a command for the O-RU to send an RPC reply to the O-DU to indicate correct reception of the above RPC by sending "ok". Furthermore, in another embodiment of this sub-user case, the SMO may subscribe to notifications to the O-DU and / or O-RU to indicate TRx control activation / deactivation state changes with appropriate parameters.

[0235] According to another embodiment, a sub-use case for the use case RF channel reconfiguration (i.e., RF channel switch off / on) may be defined as TRx control. For this sub-use case, the supported antenna array configurations include commands for the O-DU to set "trx-control-based-energy-saving enabled" to "true" (where "1" means sleep and "0" means awake / active) using the "o-ran.hardware.yang" module, for the O-DU to activate a specific TRx control (in the Tx and / or Rx antenna array) configuration, or to revert to the baseline antenna array (antenna mask is all "0" / "1" based on the implementation), in addition to other commands for activating and deactivating the O-RU. <rpc> <edit-config> <antenna-mask>The sub-user case may include at least one of a command to send an RPC reply to the O-DU to indicate correct reception of the above RPC by sending "ok", a command to change the beam weights and antenna calibration during TRx control activation, and a command for the O-RU to send an RPC reply to the O-DU to indicate correct reception of the above RPC by sending "ok". Furthermore, in another embodiment for this sub-user case, the SMO may subscribe to notifications from the O-DU and / or O-RU to indicate TRx control activation / deactivation state changes with appropriate parameters. According to another embodiment, a sub-use case for the use case RF channel reconfiguration (i.e., RF channel switch off / on) may be defined as hibernate sleep. For this sub-user case, the O-RU receives the antenna array configurations supported by the O-RU from the O-DU via management plane (M-Plane) messaging. Here, the supported antenna array configurations are the commands that the O-DU uses to set "energy-saving enabled" to "true" using the "o-ran.hardware.yang" module, in addition to other commands to activate and deactivate the O-RU, and the commands that the O-DU uses to put the carrier to sleep or deactivate the carrier. <rpc> <edit-config><[tr]x-array-carrier:: ACTIVE>" with the value "SLEEP" or "INACTIVE" is sent to the O-RU, and the O-RU changes "[tr]x-array-carrier:: STATE" from "BUSY" to "DISABLED". Command, the O-DU issues an appropriate RPC (i.e., <edit-config>" and " <delete-config>"), or the O-RU may perform this operation in its own internal logic during long sleep (for example, this command may provision more energy saving since the related circuits may be switched off). A command to switch off the C-Plane, U-Plane, S-Plane, and M-Plane circuits if all carriers are removed / deconfigured during hibernate (long / deep) sleep. The O-DU may switch off the C-Plane, U-Plane, S-Plane, and M-Plane circuits by sending appropriate commands / rpcs. The O-RU itself may switch off the C-Plane, U-Plane, S-Plane, and M-Plane circuits in its internal logic. The RPC may include at least one of a command to switch off the CU-Plane monitoring circuit (e.g., for long-term energy saving, switch off the command for monitoring circuit, which may be applied on both the energy saving use cases based on TRx control and advanced sleep mode), and a command for the O-RU to send an RPC reply to the O-DU to indicate correct receipt of the above RPC by sending "ok". Furthermore, in another embodiment of this sub-user case, the SMO may subscribe to notifications to the O-DU and / or O-RU to indicate carrier state changes and activation / deactivation state changes with appropriate parameters for TRx control and advanced sleep mode.

[0236] In step 603B, the O-RU reconfigures the antenna array antenna model via / based on management plane (M-Plane) messaging from the O-DU based on the antenna array configuration supported for the O-RU. Alternatively, in one embodiment, the O-RU notifies the configuration change during the transition from one antenna array configuration to another, taking into account the transition time (i.e., wake-up time).

[0237] 6B , to perform and suggest a transition from one antenna array configuration to another, a notification mechanism between the O-RU and the O-DU without significant changes to the existing O-RAN M-Plane specifications allows the O-RU to report its configuration capability information (e.g., the O-RU internal architecture) to the O-DU. As a result, by muting the physical and functional components of the O-RU according to the O-RU's configuration capability information (e.g., the O-RU's internal architecture), the antenna calibration requirements for each antenna array configuration can be met and maximum energy savings can be achieved.

[0238] 7 is a diagram of an example environment 700 in which the systems and / or methods described herein may be implemented. As shown in FIG. 7, environment 700 may include a user device 710, a platform 720, and a network 730. The devices of environment 700 may be interconnected via wired connections, wireless connections, or a combination of wired and wireless connections. In an embodiment, any of the functions and operations described below with reference to FIG. 1 above may be performed by any combination of elements illustrated in FIG. 8.

[0239] User device 710 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information related to platform 720. For example, user device 710 may include a computing device (e.g., a desktop computer, a laptop computer, a tablet computer, a handheld computer, a smart speaker, a server, etc.), a mobile phone (e.g., a smartphone, a wireless phone), a wearable device (e.g., smart glasses or a smart watch), or a similar device. In some implementations, user device 710 may receive information from platform 720 and / or send information to platform 720.

[0240] Platform 720 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information. In some implementations, platform 720 may include a cloud server or a group of cloud servers. In some implementations, platform 720 may be designed to be modular, such that particular software components may be swapped in or out depending on particular needs. In this manner, platform 720 may be easily and / or quickly reconfigured for different uses.

[0241] In some implementations, as shown, platform 720 may be hosted in a cloud computing environment 722. Note that although the implementations described herein describe platform 720 as being hosted in a cloud computing environment 722, in some implementations platform 720 may not be cloud-based (i.e., may be implemented outside of a cloud computing environment) or may be partially cloud-based.

[0242] Cloud computing environment 722 includes an environment that hosts platform 720. Cloud computing environment 722 may provide services such as computation, software, data access, storage, etc., without requiring end-user (e.g., user device 710) knowledge of the physical location and configuration of the systems and / or devices that host platform 720. As shown, cloud computing environment 722 may include a group of computing resources 724 (collectively referred to as “computing resources 724” and individually referred to as “computing resource 724”).

[0243] Computing resources 724 include one or more personal computers, clusters of computing devices, workstation computers, server devices, or other types of computation and / or communication devices. In some implementations, computing resources 724 may host platform 720. Cloud resources may include compute instances executing on computing resources 724, storage devices provided on computing resources 724, data transfer devices provided by computing resources 724, etc. In some implementations, computing resources 724 may communicate with other computing resources 724 via wired connections, wireless connections, or a combination of wired and wireless connections.

[0244] As further shown in FIG. 8, computing resources 724 include a group of cloud resources such as one or more applications (“APP”) 724-1, one or more virtual machines (“VM”) 724-2, virtualized storage (“VS”) 724-3, and one or more hypervisors (“HYP”) 724-4.

[0245] Applications 724-1 include one or more software applications that may be provided to or accessed by user device 710. Applications 724-1 may obviate the need to install and run software applications on user device 710. For example, applications 724-1 may include software associated with platform 720 and / or any other software that may be provided via cloud computing environment 722. In some implementations, one application 724-1 may send and receive information to one or more other applications 724-1 via virtual machine 724-2.

[0246] Virtual machine 724-2 includes a software implementation of a device (e.g., a computer) that executes programs like a physical device. Virtual machine 724-2 may be a system virtual machine or a process virtual machine, depending on the use by virtual machine 724-2 and the degree of correspondence with any real-world device. A system virtual machine may provide a complete system platform that supports the execution of a complete operating system (“OS”). A process virtual machine may execute a single program or support a single process. In some implementations, virtual machine 724-2 may execute on behalf of a user (e.g., user device 710) and manage the infrastructure of cloud computing environment 722, such as data management, synchronization, or long-term data transfer.

[0247] Virtualized storage 724-3 includes one or more storage systems and / or one or more devices or computing resources 724 that use virtualization technology within a storage system. In some implementations, within the context of a storage system, types of virtualization may include block virtualization and file virtualization. Block virtualization may represent the abstraction (or separation) of logical storage from physical storage so that the storage system may be accessed without consideration of the physical storage or heterogeneous structure. The separation may provide storage system administrators with flexibility in managing storage for end users. File virtualization may remove the dependency between data accessed at the file level and where the file is physically stored. This may enable storage usage optimization, server consolidation, and / or non-disruptive file migration performance.

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

[0249] Network 730 may include one or more wired and / or wireless networks. For example, network 730 may include a cellular network (e.g., a fifth-generation (5G) network, a long-term evolution (LTE) network, a third-generation (3G) network, a code division multiple access (CDMA) network, etc.), a public land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., a public switched telephone network (PSTN), a private network, an ad hoc network, an intranet, the Internet, an optical fiber-based network, etc.), and / or a combination of these or other types of networks.

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

[0251] 8 is a diagram of example components of a device 800. The device 800 may correspond to a user device 710 and / or a platform 720. As shown in FIG. 8, the device 800 may include a bus 810, a processor 820, a memory 830, a storage component 840, an input component 850, an output component 860, and a communication interface 870.

[0252] The bus 810 includes components that enable communication between the components of the device 800. The processor 820 may be implemented in hardware, firmware, or a combination of hardware and software. The processor 820 may be a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), a microprocessor, a microcontroller, a digital signal processor (DSP), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), or other type of processing component. In some implementations, the processor 820 includes one or more processors that are programmable to perform functions. The memory 830 includes random access memory (RAM), read-only memory (ROM), and / or other types of dynamic or static storage devices (e.g., flash memory, magnetic memory, and / or optical memory) that store information and / or instructions for use by the processor 820.

[0253] The storage component 840 stores information and / or software related to the operation and use of the device 800. For example, the storage component 840 may include a hard disk (e.g., a magnetic disk, optical disk, magneto-optical disk, and / or solid-state disk), a compact disk (CD), a digital versatile disk (DVD), a floppy disk, a cartridge, a magnetic tape, and / or other type of non-transitory computer-readable medium, along with a corresponding drive. The input component 850 includes components that enable the device 800 to receive information, such as via user input (e.g., a touchscreen display, a keyboard, a keypad, a mouse, buttons, switches, and / or a microphone). Additionally or alternatively, the input component 850 may include sensors for measuring information (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, and / or an actuator). The output component 860 includes components that provide output information from the device 800 (e.g., a display, a speaker, and / or one or more light-emitting diodes (LEDs)).

[0254] The communication interface 870 includes transceiver-like components (e.g., a transceiver and / or a separate receiver and transmitter) that allow the device 800 to communicate with other devices, such as via a wired connection, a wireless connection, or a combination of wired and wireless connections. The communication interface 870 allows the device 800 to receive information from and / or provide information to other devices. For example, the communication interface 870 may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, a Wi-Fi interface, a cellular network interface, etc.

[0255] Device 800 may perform one or more processes described herein. Device 800 may perform these processes in response to processor 820 executing software instructions stored by a non-transitory computer-readable medium, such as memory 830 and / or storage component 840. A computer-readable medium is defined herein as a non-transitory memory device. A memory device includes memory space within a single physical storage device or memory space distributed across multiple physical storage devices.

[0256] The software instructions may be loaded into memory 830 and / or storage component 840 from other computer-readable media or other devices via communication interface 870. When executed, the software instructions stored in memory 830 and / or storage component 840 may cause processor 820 to perform one or more of the processes described herein.

[0257] Additionally or alternatively, hardwired circuitry may be used in place of, or in combination with, software instructions to implement one or more processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.

[0258] The number and arrangement of components shown in Figure 8 are provided as an example. In practice, device 800 may include additional, fewer, different, or differently arranged components than those shown in Figure 8. Additionally or alternatively, a set of components (e.g., one or more components) of device 800 may perform one or more functions that are described as being performed by other sets of components of device 800.

[0259] In embodiments, any operation or process of Figures 2-6 may be implemented by or using any of the elements illustrated in Figures 1, 7, and 8. It is understood that other embodiments are not so limited and may be implemented in a variety of different architectures (e.g., bare metal architectures, any cloud-based architectures, or deployment architectures such as Kubernetes, Docker, OpenStack, etc.).

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

[0261] Some embodiments may relate to systems, methods, and / or computer-readable media at any possible level of technical detail of integration. Furthermore, one or more of the above-described 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 a computer-readable non-transitory storage medium (or medium) having computer-readable program instructions stored thereon for causing a processor to perform operations.

[0262] A computer-readable storage medium may be a tangible device that can hold and store instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory sticks, floppy disks, punch cards, or mechanically encoded devices such as raised structures in grooves in which instructions are recorded, or any suitable combination thereof. As used herein, computer-readable storage medium is not to be understood as a transitory signal per se, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., a light pulse passing through a fiber optic cable), or an electrical signal transmitted over a wire.

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

[0264] The computer-readable program code / instructions for carrying out operations may be assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for an integrated circuit, or source or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk or C++, procedural programming languages ​​such as the "C" programming language, or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, partially on the user's computer, partially on a remote computer, or entirely on a remote computer or server, as a standalone software package. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be to an external computer (e.g., through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), may execute computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the electronic circuitry to perform a certain aspect or operation.

[0265] These computer-readable program instructions may be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to produce an apparatus, such that the instructions, when executed by the processor of the computer or other programmable data processing apparatus, produce means for implementing the functions / acts set forth in the flowcharts and / or block diagrams (one or more blocks). These computer-readable program instructions may be stored on a computer-readable storage medium that can direct a computer, programmable data processing apparatus, and / or other device to function in a particular manner, such that the computer-readable storage medium on which the instructions are stored comprises an article including instructions that implement aspects of the functions / acts set forth in the flowcharts and / or block diagrams (one or more blocks).

[0266] The computer-readable program instructions may be loaded onto a computer, other programmable data processing apparatus, or other device such that a series of operational steps are performed on the computer, other programmable apparatus, or other device to generate a computer-implemented process such that the instructions, executed on the computer, other programmable apparatus, or other device, implement the functions / acts described in the flowcharts and / or block diagrams (one or more blocks).

[0267] The illustrated flowcharts and block diagrams illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer-readable media according to various embodiments. Each block in a flowchart or block diagram may represent a microservice, module, segment, or portion of instructions, comprising one or more executable instructions for implementing specific logical functions. The method, computer system, or computer-readable medium may include additional, fewer, different, or differently arranged blocks than those shown in the figures. In some alternative implementations, the functions shown in the blocks may occur out of the order shown in the figures. For example, two blocks shown in succession may actually be executed concurrently or substantially concurrently, depending on the functionality involved, or the blocks may be executed in the reverse order. Note that each block of the block diagram and / or flowchart illustrations, or combinations of blocks in the block diagram and / or flowchart illustrations, may be implemented by a dedicated hardware-based system performing specific functions or acts, or by executing a combination of dedicated hardware and computer instructions.

[0268] It will be apparent that the devices and / or methods described herein may be implemented in different forms, such as hardware, firmware, or a combination of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods does not limit the implementation. As such, the operation and behavior of the systems and / or methods are described herein without reference to specific software code. It will be understood that software and hardware may be designed to implement the devices and / or methods based on the descriptions herein.

[0269] Various further respective aspects and features of embodiments of the present disclosure may be defined by the following items. Item 1: A higher layer network function of an Open Radio Access Network (O-RAN), comprising: monitoring at least one network parameter via an O1 interface to implement dynamic antenna array reconfiguration; requesting a distributed unit (O-DU) to reconfigure an antenna array based on the at least one monitored network parameter satisfying a predetermined condition; 1. An apparatus including a higher layer network function configured to perform: Item 2: Item 10. The apparatus of item 1, wherein the radio unit (O-RU) requests, via a management plane fronthaul (FH M-Plane), to reconfigure the antenna array based on the at least one monitored network parameter satisfying a predetermined condition. Item 3: An optical distribution unit (O-DU), receiving configuration capability information from a radio unit (O-RU) via management plane (M-Plane) messaging; receiving a request from a higher layer network function to reconfigure the antenna array; determining an antenna array configuration supported by the O-RU based on the configuration capability information from the O-RU and based on the request to reconfigure the antenna array from the higher layer network function; activating the supported antenna array configurations via control plane (C-Plane) messaging; 1. An apparatus including an O-DU configured to perform the steps of: Item 4: 4. The apparatus of claim 3, wherein the O-DU is configured to activate the supported antenna array configurations via the management plane (M-Plane) messaging. Item 5: 5. The apparatus of claim 3 or 4, wherein the supported antenna array configurations are at least one of: a configuration for implementing TRx control; and a configuration for implementing at least one sleep mode, including a configuration for implementing at least one of an advanced sleep mode and a deep sleep mode. Item 6: 1. A radio unit (O-RU), comprising: Sending configuration capability information to a distributed unit (O-DU) via management plane (M-Plane) messaging; receiving, via control plane (C-Plane) messaging, from the O-DU, an antenna array configuration supported by the O-RU based on the configuration capability information of the O-RU and a request to reconfigure an antenna array from a higher layer network function; reconfiguring the antenna array configuration of the O-RU based on the antenna array configuration supported for the O-RU; 12. An apparatus including an O-RU configured to perform the steps of: Item 7: The O-RU is receiving the request to reconfigure the antenna array from the higher layer network function via a management plane fronthaul (FH M-Plane) interface; reconfiguring the antenna array configuration of the O-RU based on the request to reconfigure the antenna array from the higher layer network function; may be further configured to perform Item 6. The device according to item 6. Item 8: 8. The apparatus of claim 7, wherein the O-RU may be further configured to receive from the O-DU via management plane (M-Plane) messaging an antenna array configuration supported by the O-RU based on the configuration capability information of the O-RU and a request to reconfigure an antenna array from a higher layer network function. Item 9: 9. The device of any of items 6 to 8, wherein the supported antenna array configurations are at least one of configurations for implementing TRx control, advanced sleep mode, and deep sleep. Item 10: 10. The apparatus of any of items 6 to 9, wherein the O-RU may be further configured to notify a configuration change from one antenna array configuration to another antenna array configuration via management plane (M-Plane) messaging. Item 11: 11. The apparatus of any of items 6 to 10, wherein the O-RU may be further configured to send configuration capability information via management plane (M-Plane) messaging upon initialization. Item 12: monitoring at least one network parameter via an O1 interface to implement dynamic antenna array reconfiguration by a higher layer network function of an open radio access network (O-RAN); requesting, by the higher layer network function, that a distributed unit (O-DU) reconfigure an antenna array based on the at least one network parameter monitored satisfying a predetermined condition; A method comprising: Item 13: Item 13. The method of item 12, wherein the higher layer network function requests the radio unit (O-RU) to reconfigure the antenna array via a management plane fronthaul (FH M-Plane) based on the at least one network parameter monitored satisfying a predetermined condition. Item 14: receiving, by a distributed unit (O-DU), configuration capability information from a radio unit (O-RU) via management plane (M-Plane) messaging; receiving, by the O-DU, a request from a higher layer network function to reconfigure an antenna array; determining, by the O-DU, an antenna array configuration supported by the O-RU based on the configuration capability information from the O-RU and based on the request to reconfigure the antenna array from the higher layer network function; activating, by the O-DU, the supported antenna array configurations via control plane (C-Plane) messaging; A method comprising: Item 15: Item 15. The method of item 14, further comprising activating, by the O-DU, the supported antenna array configurations via the management plane (M-Plane) messaging. Item 16: Item 16. The method of item 14 or 15, wherein the supported antenna array configurations are at least one of a configuration for implementing TRx control and a configuration for implementing at least one sleep mode, including a configuration for implementing at least one of an advanced sleep mode and a deep sleep mode. Item 17: sending, by the radio unit (O-RU), configuration capability information to the distributed unit (O-DU) via management plane (M-Plane) messaging; receiving, by the O-RU, from the O-DU via control plane (C-Plane) messaging, an antenna array configuration supported by the O-RU based on the configuration capability information of the O-RU and a request to reconfigure an antenna array from a higher layer network function; reconfiguring, by the O-RU, the antenna array configuration of the O-RU based on the antenna array configuration supported for the O-RU; A method comprising: Item 18: receiving, by the O-RU, the request to reconfigure the antenna array from the higher layer network function via a management plane fronthaul (FH M-Plane) interface; reconfiguring, by the O-RU, the antenna array configuration of the O-RU based on the request to reconfigure the antenna array from the higher layer network function; Item 18. The method according to item 17, which may further comprise: Item 19: 19. The method of claim 17 or 18, further comprising receiving, by the O-RU, from the O-DU via management plane (M-Plane) messaging, an antenna array configuration supported by the O-RU that is based on the configuration capability information of the O-RU and a request to reconfigure an antenna array from a higher layer network function. Item 20: 20. The method of any of items 17 to 19, wherein the supported antenna array configurations are at least one of a configuration for implementing TRx control and a configuration for implementing at least one sleep mode, including a configuration for implementing at least one of an advanced sleep mode and a deep sleep mode. Item 21: 21. The method of any of items 17 to 20, further comprising: notifying, by the O-RU, via management plane (M-Plane) messaging, of a configuration change from one antenna array configuration to another antenna array configuration. Item 22: 22. The method of any of items 17 to 21, further comprising, upon initialization, sending configuration capability information by the O-RU via management plane (M-Plane) messaging. < / rpc> < / edit-config> < / rpc> < / edit-config> < / rpc>

Claims

1. A higher layer network function of an Open Radio Access Network (O-RAN), comprising: monitoring at least one network parameter via an O1 interface to implement dynamic antenna array reconfiguration; requesting a distributed unit (O-DU) to reconfigure an antenna array based on the at least one monitored network parameter satisfying a predetermined condition; 1. An apparatus comprising a higher layer network function configured to perform:

2. 2. The apparatus of claim 1, wherein the radio unit (O-RU) requests, via a management plane fronthaul (FH M-Plane), to reconfigure the antenna array based on the at least one monitored network parameter satisfying a predetermined condition.

3. An optical distribution unit (O-DU), comprising: receiving configuration capability information from a radio unit (O-RU) via management plane (M-Plane) messaging; receiving a request from a higher layer network function to reconfigure the antenna array; determining an antenna array configuration supported by the O-RU based on the configuration capability information from the O-RU and based on the request to reconfigure the antenna array from the higher layer network function; activating the supported antenna array configurations via control plane (C-Plane) messaging; An apparatus comprising an O-DU configured to perform the steps of:

4. 4. The apparatus of claim 3, wherein the O-DU is configured to activate the supported antenna array configurations via the management plane (M-Plane) messaging.

5. 4. The apparatus of claim 3, wherein the supported antenna array configurations are at least one of: a configuration for implementing TRx control; and a configuration for implementing at least one sleep mode, including a configuration for implementing at least one of an advanced sleep mode and a deep sleep mode.

6. 1. A radio unit (O-RU), comprising: Sending configuration capability information to a distributed unit (O-DU) via management plane (M-Plane) messaging; receiving, via control plane (C-Plane) messaging, from the O-DU, an antenna array configuration supported by the O-RU based on the configuration capability information of the O-RU and a request to reconfigure an antenna array from a higher layer network function; reconfiguring the antenna array configuration of the O-RU based on the antenna array configuration supported for the O-RU; 12. An apparatus comprising: an O-RU configured to perform the steps of:

7. The O-RU is receiving the request to reconfigure the antenna array from the higher layer network function via a management plane fronthaul (FH M-Plane) interface; reconfiguring the antenna array configuration of the O-RU based on the request to reconfigure the antenna array from the higher layer network function; and further configured to perform 7. The apparatus of claim 6.

8. 8. The apparatus of claim 7, wherein the O-RU is further configured to receive from the O-DU via management plane (M-Plane) messaging an antenna array configuration supported by the O-RU based on the configuration capability information of the O-RU and a request to reconfigure an antenna array from a higher layer network function.

9. 7. The apparatus of claim 6, wherein the O-RU is further configured to signal a configuration change from one antenna array configuration to another antenna array configuration via management plane (M-Plane) messaging.

10. monitoring at least one network parameter via an O1 interface to implement dynamic antenna array reconfiguration by an Open Radio Access Network (O-RAN) higher layer network function; requesting, by the higher layer network function, that a distributed unit (O-DU) reconfigure an antenna array based on the at least one network parameter monitored satisfying a predetermined condition; A method for providing the above.

11. 11. The method of claim 10, wherein the higher layer network function requests, via a management plane fronthaul (FH M-Plane), that the radio unit (O-RU) reconfigure its antenna array based on the at least one network parameter monitored satisfying a predetermined condition.

12. receiving, by a distributed unit (O-DU), configuration capability information from a radio unit (O-RU) via management plane (M-Plane) messaging; receiving, by the O-DU, a request from a higher layer network function to reconfigure an antenna array; determining, by the O-DU, an antenna array configuration supported by the O-RU based on the configuration capability information from the O-RU and based on the request to reconfigure the antenna array from the higher layer network function; activating, by the O-DU, the supported antenna array configurations via control plane (C-Plane) messaging; A method for providing the above.

13. 13. The method of claim 12, further comprising activating, by the O-DU, the supported antenna array configurations via the management plane (M-Plane) messaging.

14. 13. The method of claim 12, wherein the supported antenna array configurations are at least one of: a configuration for implementing TRx control; and a configuration for implementing at least one sleep mode, including a configuration for implementing at least one of an advanced sleep mode and a deep sleep mode.

15. transmitting, by the radio unit (O-RU), configuration capability information to the distributed unit (O-DU) via management plane (M-Plane) messaging; receiving, by the O-RU, from the O-DU via control plane (C-Plane) messaging, an antenna array configuration supported by the O-RU based on the configuration capability information of the O-RU and a request to reconfigure an antenna array from a higher layer network function; reconfiguring, by the O-RU, the antenna array configuration of the O-RU based on the antenna array configuration supported for the O-RU; A method for providing the above.

16. receiving, by the O-RU, the request to reconfigure the antenna array from the higher layer network function via a management plane fronthaul (FH M-Plane) interface; reconfiguring, by the O-RU, the antenna array configuration of the O-RU based on the request to reconfigure the antenna array from the higher layer network function; The method of claim 15 further comprising:

17. 16. The method of claim 15, further comprising receiving, by the O-RU, from the O-DU via management plane (M-Plane) messaging, an antenna array configuration supported by the O-RU that is based on the configuration capability information of the O-RU and a request to reconfigure an antenna array from a higher layer network function.

18. 16. The method of claim 15, wherein the supported antenna array configurations are at least one of: a configuration for implementing TRx control; and a configuration for implementing at least one sleep mode, including a configuration for implementing at least one of an advanced sleep mode and a deep sleep mode.

19. 16. The method of claim 15, further comprising: signaling, by the O-RU, a configuration change from one antenna array configuration to another antenna array configuration via management plane (M-Plane) messaging.

20. 16. The method of claim 15, further comprising sending, by the O-RU upon initialization, configuration capability information via management plane (M-Plane) messaging.

Images