Optimizing antenna array model selection in telecommunications network

Abstract

A method for optimizing antenna array model selection in a telecommunications network, the method comprising: transmitting, by a radio unit (O-RU) via a management plane (M-plane) messaging, antenna configuration capability information comprising at least one antenna array model parameter to a distribution unit (O-DU); receiving, from the O-DU, an antenna array configuration comprising at least one antenna array model parameter supported by the O-RU via control plane (C-plane) messaging, or M-plane messaging, wherein the supported antenna array configuration is based on antenna configuration capability information comprising at least one antenna array model parameter of the O-RU, and a request from the higher layer network function to reconfigure the antenna array; and changing, by the O-RU, the antenna array model over the baseline antenna array configuration of the O-RU based on the antenna array configuration comprising at least one antenna array model parameter supported by the O-RU.

Description

[0001] Cross - Reference to Related Applications

[0002] This application is based on and 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 March 10, 2023, and Indian Provisional Patent Application No. 202341024486 filed on March 31, 2023, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This disclosure relates to optimizing the selection of antenna array models within an Open Radio Access Network (O-RAN) to save energy in a telecommunications network. Background Art

[0004] A Radio Access Network (RAN) is an important component in a telecommunications system as it connects end-user devices (or user equipment) to other parts of the network. The RAN consists of 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 are vendor-specific.

[0005] Open RAN (O-RAN) technology has emerged to enable multiple vendors to provide hardware and / or software to a telecommunications system. To this end, O-RAN decomposes RAN functions into a Centralized Unit (CU), a Distributed Unit (DU), and a Radio Unit (RU). The CU is a logical node for hosting the Radio Resource Control (RRC), Service Data Adaptation Protocol (SDAP), and / or Packet Data Convergence Protocol (PDCP) sub-layers of the RAN. The DU is a logical node for hosting the Radio Link Control (RLC), Medium Access Control (MAC), and Physical (PHY) sub-layers of the RAN. The RU is a physical node that converts radio signals from an antenna into digital signals that can be sent to the DU via fronthaul. Because there are open protocols and interfaces between these entities, they can be developed by different vendors.

[0006] Figure 1 Illustrates an existing O-RAN architecture. Refer to Figure 1, the RAN functions in the O-RAN architecture are controlled and optimized by the RIC. The RIC is a software-defined component that implements modular applications to facilitate multi-vendor operability required in the O-RAN system and automate and optimize RAN operations. The RIC is divided into two types: Non-Real-Time RIC (NRT-RIC) and Near-Real-Time RIC (nRT-RIC).

[0007] The NRT-RIC is the control point of the non-real-time control loop and operates on a time scale greater than 1 second within the Service Management Orchestration (SMO) framework. Its functions are implemented through modular applications called rApps (rApp 1, ……, rApp N) and include: providing policy-based guidance and enrichment across the A1 interface, which is the interface enabling communication between the NRT-RIC and the nRT-RIC; performing data analysis; artificial intelligence / machine learning (AI / ML) training and inference for RAN optimization; and / or recommending configuration management actions through the O1 interface, which is the interface connecting the SMO to RAN management elements (e.g., nRT-RIC, O-RAN Central Unit (O-CU), O-RAN Distributed Unit (O-DU), etc.).

[0008] The nRT-RIC operates on a time scale of 10 milliseconds to 1 second and is connected to the O-DU, O-CU (split into O-CU Control Plane (O-CU-CP) and O-CU User Plane (O-CUS-UP)), and Open eNodeB (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) via policies. For example, the nRT-RIC sets policy parameters for the activation function of the E2 nodes. In addition, the nRT-RIC hosts xApps to implement functions such as Quality of Service (QoS) optimization, mobility optimization, slice optimization, interference mitigation, load balancing, security, etc. These two types of RICs work together to optimize the O-RAN. For example, the NRT-RIC provides the policies, data, and artificial intelligence / machine learning AI / ML models implemented and used by the nRT-RIC for RAN optimization through the A1 interface, and the nRT-RIC returns policy feedback (i.e., how the policies set by the NRT-RIC work).

[0009] The SMO framework where the NRT-RIC is located manages and orchestrates RAN elements. Specifically, the SMO manages and orchestrates the so-called O-RAN Cloud (O-Cloud). The O-Cloud is a collection of physical RAN nodes that host the RIC, O-CU, and O-DU, support software components (e.g., operating systems and runtime environments), and the SMO itself.

[0010] In other words, the SMO manages the O-Cloud internally. The O2 interface is the interface between the SMO and the O-Cloud where it is located. Through the O2 interface, the SMO provides Infrastructure Management Service (IMS) and Deployment Management Service (DMS).

[0011] On the other hand, the O-Cloud is a cloud computing platform that includes a set of physical infrastructure nodes that meet O-RAN requirements to host relevant O-RAN functions (e.g., nRT-RIC, O-CU-CP, O-CU-UP, O-DU, etc.), support software components (such as operating systems, hypervisors, container runtimes, etc.), and appropriate management and orchestration functions.

[0012] The SMO framework where the NRT-RIC is located manages and orchestrates RAN elements. The SMO performs the management and orchestration of RAN elements through four key interfaces: the A1 interface between the NRT-RIC and the nRT-RIC in the SMO for RAN optimization; the O1 interface between the SMO and the O-RAN network functions for FCAPS support; in the case of a hybrid model, the open front-end M-plane interface between the SMO and the O-RU for FCAPS support; and the O2 interface between the SMO and the O-Cloud for platform resource and workload management.

[0013] In the O-RAN according to the prior art, massive multiple-input multiple-output (m-MIMO) antennas are used for beamforming techniques (i.e., beam weighting and / or antenna calibration datasets) to increase cell capacity and traffic throughput. To implement beamforming, the RU (i.e., O-RU) must concentrate power amplifiers at the antenna site by combining radiating elements such as a transceiver (TRx) (i.e., transmitter / receiver (Tx / Rx)) array (i.e., combining the radiating elements of the antenna array into an antenna array model).

[0014] In the prior art, the O-RU reports a standardized antenna array model based on a Cartesian coordinate system to the O-DU. The standardized antenna array model based on the Cartesian coordinate system is hard-coded as read-only by the O-RU vendor. In addition, the O-DU may not know the internal architecture of the O-RU, i.e., the connection of the physical antenna elements to the radio frequency (RF) transceiver ports.

[0015] Thus, in the prior art, it is not possible to mute (e.g., turn off) parts of the antenna elements and their corresponding RF transceiver chains. As described above, the drawback of the lack of communication between the O-DU and the O-RU according to the prior art is that, under certain O-RAN conditions predetermined by the operator (e.g., O-RAN load, when the expected traffic volume or the number of connected users is below the configured threshold), due to the vendor-centric proprietary settings of the TRx array, the high power consumption of the O-RU results in the inefficient operation of the energy of the RU within the O-RAN. SUMMARY OF THE INVENTION

[0016] According to an embodiment, the present disclosure provides an optimization of antenna array model selection in a telecommunication network. In particular, antenna configuration capability information including at least one antenna array model parameter is exchanged between an O-DU and an O-RU via management plane (M-plane) messaging (i.e., M-plane commands), and an antenna array configuration including at least one antenna array model parameter supported by the O-RU is exchanged between the O-DU and the O-RU via control plane (C-plane) messaging or M-plane messaging, wherein the supported antenna array configuration is based on the antenna configuration capability information including at least one antenna array model parameter of the O-RU, and a request for reconfiguring the antenna array from a higher-layer network function.

[0017] Thus, when the antenna array model changes above the baseline antenna array configuration of the O-RU based on the antenna array configuration including at least one antenna array model parameter supported by the O-RU, the O-DU knows the configuration capabilities of the O-RU. This has the advantage of defining the configuration capabilities of the O-RU.

[0018] According to an embodiment, a device includes an radio unit (O-RU) configured to send antenna configuration capability information including at least one antenna array model parameter to a distribution unit (O-DU) via management plane (M-plane) messaging. The O-RU receives an antenna array configuration including at least one antenna array model parameter supported by the O-RU from the O-DU via control plane (C-plane) messaging or M-plane messaging. The supported antenna array configuration is based on the antenna configuration capability information including at least one antenna array model parameter of the O-RU, and a request for reconfiguring the antenna array from a higher-layer network function. The O-RU changes the antenna array model above the baseline antenna array configuration of the O-RU based on the antenna array configuration including at least one antenna array model parameter supported by the O-RU.

[0019] According to an embodiment, a device includes a distribution unit (O-DU) configured to receive, via management plane (M-plane) messaging, antenna configuration capability information including at least one antenna array model parameter from a radio unit (O-RU). The O-DU receives a request for reconfiguring the antenna array from a higher layer network function. The O-DU determines an antenna array configuration including at least one antenna array model parameter supported by the O-RU based on the antenna configuration capability information including at least one antenna array model parameter from the O-RU and based on the request for reconfiguring the antenna array from the higher layer network function. The O-DU applies the supported antenna array configuration including at least one antenna array model parameter via C-plane messaging or M-plane messaging.

[0020] According to an embodiment, a method includes sending, by a radio unit (O-RU) via management plane (M-plane) messaging, antenna configuration capability information including at least one antenna array model parameter to a distribution unit (O-DU). The method further includes receiving, via control plane (C-plane) messaging or M-plane messaging, an antenna array configuration including at least one antenna array model parameter supported by the O-RU from the O-DU. The supported antenna array configuration is based on the antenna configuration capability information including at least one antenna array model parameter of the O-RU and a request for reconfiguring the antenna array from a higher layer network function. Additionally, the method includes changing, by the O-RU, an antenna array model on top of a baseline antenna array configuration of the O-RU based on the antenna array configuration including at least one antenna array model parameter supported by the O-RU.

[0021] According to an embodiment, a method includes receiving, by a distribution unit (O-DU) via management plane (M-plane) messaging, antenna configuration capability information including at least one antenna array model parameter from a radio unit (O-RU). Additionally, the method includes receiving a request for reconfiguring the antenna array from a higher layer network function. The antenna configuration capability information includes at least one antenna array model parameter from the O-RU and is based on the request for reconfiguring the antenna array from the higher layer network function. The method includes determining, by the O-DU, an antenna array configuration including at least one antenna array model parameter supported by the O-RU. Additionally, the method includes applying, by the O-DU, the supported antenna array configuration including at least one antenna array model parameter via C-plane messaging or M-plane messaging.

[0022] According to an embodiment, a non-transitory computer-readable recording medium has instructions recorded thereon that are executable by at least one processor, the at least one processor being configured to execute the instructions to implement a method. The method includes: sending, by a radio unit (O-RU) via management plane (M-plane) messaging, antenna configuration capability information including at least one antenna array model parameter to a distribution unit (O-DU). The method further includes: receiving, via control plane (C-plane) messaging or M-plane messaging, an antenna array configuration including at least one antenna array model parameter supported by the O-RU from the O-DU. The supported antenna array configuration is based on the antenna configuration capability information including at least one antenna array model parameter of the O-RU and a request for reconfiguring the antenna array from a higher layer network function. Further, the method includes: changing, by the O-RU, an antenna array model on top of a baseline antenna array configuration of the O-RU based on the antenna array configuration including at least one antenna array model parameter supported by the O-RU.

[0023] According to this embodiment, a non-transitory computer-readable recording medium has instructions recorded thereon that are executable by at least one processor, the at least one processor being configured to execute the instructions to implement a method. The method includes: receiving, by a distribution unit (O-DU) via management plane (M-plane) messaging, antenna configuration capability information including at least one antenna array model parameter from a radio unit (O-RU). Further, the method includes: receiving a request for reconfiguring the antenna array from a higher layer network function. The antenna configuration capability information includes: at least one antenna array model parameter from the O-RU and is based on the request for reconfiguring the antenna array from the higher layer network function. The method includes: determining, by the O-DU, an antenna array configuration including at least one antenna array model parameter supported by the O-RU. Further, the method includes: applying, by the O-DU via C-plane messaging or M-plane messaging, the supported antenna array configuration including at least one antenna array model parameter.

[0024] Additional aspects will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the presented embodiments of the disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Certain example embodiments of the present disclosure will now be described with reference to the drawings, in which like reference numerals represent like elements, and in which:

[0026] Figure 1 An O-RAN architecture in the prior art is illustrated;

[0027] Figure 2Illustrates a method for optimizing the selection of antenna array models in O-RAN from the perspective of an O-RU;

[0028] Figure 3 Illustrates a method for changing an antenna array model over a baseline antenna array according to an embodiment;

[0029] Figure 4 Illustrates a method for changing an antenna array model over a baseline antenna array according to another embodiment;

[0030] Figure 5 Illustrates a method for optimizing the selection of antenna array models in O-RAN from the perspective of an O-DU according to an embodiment;

[0031] Figure 6 Illustrates a method for selecting at least one antenna array model parameter operable by an O-RU according to an embodiment;

[0032] Figure 7 Illustrates an M-plane message passing method according to an embodiment, the method including: a Yang model for capability reporting of TRx control parameters and a Yang model for performance reporting of data layer control parameters;

[0033] Figure 8 Illustrates a flowchart of M-plane / C-plane message passing between an O-RU and an O-DU for a TRx control use case;

[0034] Figure 9 Illustrates an M-plane message passing method according to an embodiment, the method including: a Yang model for capability reporting of sleep mode and associated parameters;

[0035] Figure 10 Illustrates a flowchart of M-plane / C-plane message passing between an O-RU and an O-DU for a sleep mode use case;

[0036] Figure 11 Illustrates an embodiment of TRx control according to section type 4 TRx control;

[0037] Figure 12 Illustrates another embodiment of TRx control according to interval type 0 TRx control;

[0038] Figure 13 Illustrates an embodiment of TRx control and sleep mode according to section type 4 command type (ST4CmdType) TRx control;

[0039] Figure 14Illustrates another embodiment of the TRx control and sleep mode according to the section type 4 command type (ST4CmdType) TRx control / advanced sleep mode;

[0040] Figure 15 Illustrates the antenna array selection based on the antenna array model according to an embodiment;

[0041] Figure 16 Illustrates a method for masking an antenna array based on an antenna array model according to an embodiment;

[0042] Figure 17 Illustrates the antenna array selection based on the bit mask method according to an embodiment;

[0043] Figure 18 Illustrates the antenna array selection based on the bit mask method according to another embodiment;

[0044] Figure 19 Illustrates the 64T64R antenna array model to be selected by using the offset method according to an embodiment;

[0045] Figure 20 Illustrates the 32T32R antenna array model to be selected by using the offset method according to an embodiment;

[0046] Figure 21 Is a diagram of an example environment in which the systems and / or methods described herein can be implemented; and

[0047] Figure 22 Is a diagram of example components of a device according to an embodiment. Detailed Description

[0048] The following detailed description of example embodiments refers to the accompanying drawings. The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the implementation to the precise forms disclosed. Modifications and variations are possible in light of the foregoing disclosure, or may be acquired from practice of the implementation. Additionally, one or more features or components of one embodiment may be incorporated into (or combined with one or more features of) another embodiment. Further, in the flowcharts and operation 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 simultaneously (at least in part), and the order of one or more operations may be switched.

[0049] It is obvious that the device and / or method described herein can be implemented with different forms of hardware, firmware, or a combination of hardware and software. The actual dedicated control hardware or software code for implementing these systems and / or methods does not limit these implementations. Therefore, the operation and behavior of the system and / or method are described herein without reference to specific software codes. It should be understood that software and hardware can be designed to implement these systems and / or methods based on the description herein.

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

[0051] Unless explicitly stated, no element, act, or instruction used herein should be construed as critical or essential. In addition, as used herein, the terms "a" and "an" are intended to include one or more clauses and can be used interchangeably with "one or more". Figure One If the term "a" or "an" or similar language is used, the term "one" or "an" or similar language is used. In addition, as used herein, the terms "has," "have," "having," "include," "including," and the like are intended to be open-ended terms. In addition, unless otherwise expressly stated, the term "based on" means "based at least in part on." In addition, expressions such as "at least one of [A] and [B]" or "at least one of [A] or [B]" should be understood to include only A, only B, or both A and B.

[0052] Figure 2 The figure shows the method to optimize the antenna array model selection in O-RAN from the perspective of O-RU. Figure 2 The O-RU transmits (e.g., sent at initialization and / or during operation) configuration capability information required 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 and / or management plane (M-plane) messaging, and reconfigures the antenna array antenna model based on the supported antenna array configurations of the O-RU.

[0053] In step 201, the O-RU sends its antenna configuration capability information via management plane (M-plane) messaging (i.e., M-plane commands), which includes at least one antenna array model parameter. According to an example embodiment, in step 201, after power-on, the O-RU transfers (e.g., sends) to the O-DU via the M-plane the antenna configuration capability information required for it to perform antenna array reconfiguration, which includes at least one antenna array model parameter (i.e., the Yang model data parameters included in the Yang model). In an example embodiment, the O-RU exposes (reports) its capability data (including antenna configuration capability information) to the O-DU via the front-end (FH) interface during startup to support various ES methods (e.g., TRx control methods such as RF channel reconfiguration, antenna array selection, etc., and sleep modes such as early sleep mode, etc.). In another example embodiment, the O-RU transfers (e.g., sends) to the O-DU via the M-plane multiple supported antenna models (e.g., antenna models defined by antenna array model parameters) / configurations (i.e., antenna configuration capability information).

[0054] In another example embodiment, the O-RU transfers (e.g., sends) to the O-DU via the M-plane during operation the configuration capability information required for it to perform antenna array reconfiguration. For example, a high-layer network function may perform an ES method to roll back from an energy-saving network state to an original network state (e.g., it turns on the O-RU or a part of the O-RU). In another case, a high-layer network function may perform an ES method to roll back from an energy-saving network state or an original state to a high-performance network state (e.g., it turns on an idle O-RU or a part of the idle O-RU to obtain maximum performance).

[0055] According to an example embodiment, the antenna configuration capability information (O-RU antenna configuration capability information) may be hard-coded by the vendor during production together with at least one of the following parameters, unique name, index, reference, etc. to identify 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 configuration change, the value representing the energy savings achievable for each configuration, the associated beam weights (predefined beam weights), etc. In one example embodiment, when the O-RU is powered on (initialized), the O-RU starts using the M-plane yang models (e.g., urn:o-ran:module-cap:1.0 and an urn:o-ran:hardware:1.0) to report to the O-DU the supported energy-saving modes (i.e., antenna array configuration capability information), the hard-coded antenna array model, and other initialization parameters.

[0056] According to an embodiment, in accordance with the O-RAN open front-end M-plane specification that defines the management plane for the open front-end interface and the associated YANG model, the O-RU may indicate to lower-layer network functions and / or higher-layer network functions outside the O-RU (i.e., the O-RU controller, such as the O-DU and / or SMO, SMO framework, etc.) that the energy-saving features supported in the associated YANG model are YANG features (such as, for example, o-ran-wg4-features.yang).

[0057] To this end, the O-DU may use the YANG feature name label to identify the feature capabilities supported by the O-RU, such as, for example, TRX-CONTROL / TRX-ON-OFF, ADVANCED-SLEEP-MODE / SLEEP-MODE, LIGHT-HIBERNATE-SLEEP, DEEP-HIBERNATE-SLEEP / DEEP-SLEEP, etc.

[0058] The YANG feature name label TRX-CONTROL or TRX-ON-OFF may describe turning on / off the RF channel or Tx / Rx array elements (i.e., turning on or off the RF channel or Tx / Rx array elements), while the M-plane activation as an optional feature control may not be available.

[0059] The YANG feature name label ADVANCED-SLEEP-MODE or SLEEP-MODE may describe turning off the carrier and the associated O-RU circuit(s) and / or O-RU component(s) (i.e., muting and / or turning on / off the physical and functional components of the O-RU) based on the corresponding activated sleep mode, while the M-plane activation as an optional feature control may not be available.

[0060] The YANG feature name label HIBERNATE-SLEEP may describe achieving O-RU energy saving by turning off the carrier and the associated O-RU circuit / components for a longer duration, where the longer duration allows the optional feature control to be implemented as an M-plane-based sleep mode in a hardware / component / energy-saving enabled manner compared to other sleep modes.

[0061] The YANG feature name label LIGHT-HIBERNATE-SLEEP may describe achieving O-RU energy saving by turning off the carrier and the associated O-RU circuit / components for a longer duration without turning off the synchronization, where the longer duration allows the optional feature control to be implemented as an M-plane-based sleep mode in a hardware / component / energy-saving enabled manner compared to other sleep modes.

[0062] The YANG feature name label DEEP-HIBERNATE-SLEEP (i.e., deep sleep) can describe achieving O-RU energy saving by turning off the carrier and related O-RU circuits / components for a long duration by turning off synchronization, where the long duration allows an optional feature control to be implemented as an M-plane-based sleep mode in a hardware / component / energy-saving enabled manner compared to other sleep modes.

[0063] According to an example embodiment, referring to the YANG feature name labels ADVANCED-SLEEP-MODE or SLEEP-MODE, various short-duration (C-plane-based) sleep modes can be defined. For example, the advanced sleep mode can be used for short sleep durations such as milliseconds, seconds, or minutes, and is activated, for example, by ST4 C-plane messaging via control plane (C-plane) messaging.

[0064] According to an example embodiment, referring to the YANG feature name label HIBERNATE-SLEEP with a long duration, the hibernation sleep mode can be activated by adopting the M-plane. For example, by setting the parameter +--rw energy-saving-enabled? boolean{ENERGYSAVING}? in the corresponding o-ran-hardware.yang module to "true" or "yes".

[0065] According to an example embodiment, referring to the YANG feature name labels LIGHT-HIBERNATE-SLEEP and DEEP-HIBERNATE-SLEEP to distinguish long sleeps with and without turning off the synchronization plane circuit, a light hibernation sleep mode with synchronization and a deep hibernation sleep mode without synchronization can be implemented in the same way as the hibernation sleep by adopting the M-plane. For example, by setting the parameter +--rw energy-saving-enabled? boolean{ENERGYSAVING}? in the corresponding o-ran-hardware.yang module to "true" or "yes".

[0066] Refer to the O-RU reporting to the O-DU and / or SMO based on the yang module. For example, as described in o-ran module.cap.yang, the Advanced Sleep Mode (ASM) can support sleep modes with short-duration (C-plane-based) sleep modes (e.g., multiple sleep modes (SM), such as SM#0, SM#1, SM#2, SM#3, etc., where the duration SM#0 < SM#1 < SM#2 < SM#3), with different wake-up times, or if the wake-up time is too short, support for a defined entry sleep time (e.g., wake-up time duration / time). Additionally, the Advanced Sleep Mode (ASM) can support sleep modes with long-duration (M-plane-based) sleep modes (e.g., dormant sleep (i.e., deep sleep) without any synchronization or dormant sleep (i.e., deep sleep) with or without synchronization, while light dormant sleep (i.e., deep sleep) refers to an M-plane-based sleep mode with synchronization, and deep dormant sleep refers to an M-plane-based sleep mode without synchronization).

[0067] According to an embodiment, the Advanced Sleep Mode (ASM) has a (minimum or guaranteed) wake-up time per sleep mode. The shortest mode in the C-plane-based sleep mode (e.g., SM#0) may not be defined by the minimum or guaranteed wake-up time, but by the entry sleep time.

[0068] The O-RU reported to the O-DU and / or SMO based on the yang module (as described in o-ran module.cap.yang) can also support C-plane messages, such as section type 8 (ST8) "ready" messages and C-plane messages including command scape (e.g., CARRIER-COMMAND, ARRAY-COMMAND, O-RU-COMMAND) (such as section type 4 (ST4) messages).

[0069] The O-RU reported to the O-DU and / or SMO based on the yang module (e.g., the module specified in o-ran module.cap.yang) can also support sleep duration extension and emergency wake-up through M-plane and / or C-plane message passing.

[0070] Furthermore, the O-RU reported to the O-DU and / or SMO based on the yang module (e.g., as specified in o-ran module.cap.yang) can also provide information such as the achievable energy-saving percentage.

[0071] In addition, the O-RU reported to the O-DU and / or SMO based on the yang module (e.g., as described in o-ran module.cap.yang) can also support notification messages for the active or inactive state of the CU plane. For example, it supports the notifications required to ensure that the CU plane becomes active after the expiration of the sleep duration (i.e., in the case of defined, undefined, and / or long sleep durations, the CU plane circuitry can be turned off). To this end, the O-RU reported to the O-DU and / or SMO supports notifying the O-DU of the CU plane state from the O-RU in case it is turned off during any sleep mode activation.

[0072] To this end, in the O-RU, similar to the existing M-plane model (e.g., similar to the energy savings achieved by the transmission blanking parameters that the O-RU can send to the O-DU), a set of modified parameters can be defined to enable the O-RU to report energy-saving parameters, such as energy-saving-by-rf-channel-reconfiguration, energy-saving-by-advanced-sleep-modes, energy-saving-by-modify-number-of-spatial-streams, energy-saving-by-modifying-number-of-data-layers, etc., in order to report the supported energy-saving modes (i.e., antenna array configuration capability information), the hard-coded antenna array model, and other initialization parameters to the O-DU.

[0073] In addition, in one example embodiment, to ensure backward compatibility, the O-RU can mark the above energy-saving mode flags in the M-plane yang model (e.g., urn:o-ran:module-cap:1.0 and an urn:o-ran:hardware:1.0). If the O-RU does not support the custom configuration provided by the vendor for ES or the RF channel reconfiguration / antenna array selection method according to its hard-coded configuration, it returns false.

[0074] According to an example embodiment, a TRx control method for reconfiguring an antenna array may include: a TRx management configuration identified by a corresponding unique configuration identifier or name. The antenna array model of the TRx control configuration includes at least one antenna mask (antMask), where the antenna mask bit combination may be limited to supported TRx control configurations, where the antenna mask bits identify '0' for the antenna elements to be turned off and '1' for the active elements of the antenna array. In addition, in addition to the mask bits for at least one antenna mask (antMask), the TRx control configuration further includes antenna layer mask bits for creating at least one antenna layer mask (antLayerMask).

[0075] According to an example embodiment, supported TRx control configurations may include a transition time (i.e., a wake-up time different from that of ASM), which defines the minimum or guaranteed time required to switch from a baseline configuration to a specific configuration (i.e., switching a baseline 64TRx antenna array to another antenna mask configuration, such as a 32TRx_antenna array model). The transition time associated with each configuration change of the supported TRx control configuration and as a function of the subcarrier spacing, for example, for 15KHz, one time slot is 1 millisecond, for 30KHz, one time slot is 0.5 millisecond or 500 microseconds, and so on.

[0076] The term transition time and the term wake-up time may be interchangeable and define the duration of the transition from one antenna array configuration to another antenna array configuration, and vice versa. According to an example embodiment, the transition time / wake-up time may refer to the duration of the transition from one antenna array model to another antenna array model, and vice versa.

[0077] According to an example embodiment, the TRx control method may include controlling to turn on / off the entire RF transceiver chain and / or the radio frequency front end (RFFE) of the radio frequency (RF) processing unit related to some RF channels / antenna elements.

[0078] In addition, according to another example embodiment, the TRx control method may include controlling to turn on / off components, circuits, IPs, cores, computing engines (i.e., physical components of the O-RU) of the digital baseband and the O-RAN front-end processing unit.

[0079] According to embodiments of the advanced sleep mode (ASM) with a short-duration (C-plane-based) sleep mode and the sleep mode with a long-duration (M-plane-based) sleep mode, the wake-up delay (i.e., the wake-up time or the sleep entry time) of the ASM and the wake-up delay of the TRx control method may be different and do not interfere with each other (e.g., hinder).

[0080] In step 202, the O-RU receives an antenna array configuration including at least one antenna array model parameter supported by the O-RU via control plane (C-plane) messaging or management plane (M-plane) messaging. The supported antenna array configuration including at least one antenna array model parameter is based on configuration capability information including at least one antenna array model parameter of the O-RU and a request for reconfiguring the antenna array from a higher layer network function.

[0081] To this end, in step 202, the received antenna array configuration including at least one antenna array model parameter supported by the O-RU refers to an antenna array configuration including at least one antenna array model parameter applied by the O-DU via control plane (C-plane) messaging or management plane (M-plane) messaging (i.e., C-plane messaging or M-plane messaging for activating (i.e., applying) a change in the antenna array model on top of the baseline antenna array configuration of the O-RU).

[0082] According to the exemplary embodiment set forth in step 202, the sleep mode can be compatible with the control plane (C-plane) and / or the management plane (M-plane), depending on the sleep duration.

[0083] According to the exemplary embodiments of the advanced sleep mode (ASM) with a short-duration (C-plane-based) sleep mode and the sleep mode with a long-duration (M-plane-based) sleep mode, the wake-up delay of the ASM (i.e., the wake-up time or the time to enter the sleep state) and the wake-up delay of the TRx control method (e.g., during the transition from one antenna array model to another considering the transition time (i.e., the wake-up delay for the antenna configuration change)) can be different and do not interfere with each other (e.g., hinder).

[0084] The term transition time is interchangeable with the term wake-up time and defines the duration of the transition from one antenna array configuration to another, and vice versa. According to the exemplary embodiment, the transition time / wake-up time can refer to the duration of the transition from one antenna array model to another, and vice versa.

[0085] According to an embodiment of the TRx control method (e.g., changing the antenna array model on top of the baseline antenna array configuration of the O-RU based on an antenna array configuration including at least one antenna array model parameter supported by the O-RU), the antenna array configuration can be activated via control plane (C-plane) messaging and / or via management plane (M-plane) messaging (i.e., M-plane command).

[0086] In step 203, the O-RU changes (i.e., reconfigures) the antenna array model on top of the baseline antenna array configuration of the O-RU (i.e., based on the received antenna array configuration, including at least one antenna array model parameter supported by the O-RU, the O-RU changes (i.e., reconfigures) the antenna array model on top of the baseline antenna array configuration).

[0087] Alternatively, in another step, according to an example embodiment, the O-RU sends a response to the antenna array configuration change (i.e., antenna array model change) to the supported antenna array model to the O-DU via C-plane messaging or M-plane messaging.

[0088] In an example embodiment, the C-plane messaging may be an acknowledgement message for the antenna array configuration change (i.e., antenna array model change) to the supported antenna array configuration. In another example embodiment, the M-plane messaging may be a notification of the antenna array configuration change to the supported antenna array configuration.

[0089] For example, considering the transition time (i.e., wake-up time), the O-RU may notify the configuration change (i.e., antenna array model change) during the transition from one antenna array configuration (e.g., the first antenna array configuration) to another antenna array configuration. This notification may be sent to the O-DU via the hierarchical architecture of O-RAN or to a higher-layer network function (e.g., SMO, RIC, etc.) via the hybrid architecture of O-RAN.

[0090] According to an example embodiment, considering the transition time (i.e., wake-up time), the O-RU may notify the antenna array configuration change (e.g., the return configuration to the baseline antenna array configuration) during the transition from the second antenna array configuration to the first antenna array configuration. For example, considering the transition time (i.e., wake-up time), the O-RU notifies the rollback configuration change during the transition from the energy-saving mode (i.e., the second antenna array configuration) to the baseline configuration (i.e., the first antenna array configuration).

[0091] Figure 3 Illustrated is a method for changing the antenna array model on top of the baseline antenna array. Referring Figure 3 , in step 301, the O-RU configures at least one beam weight and / or at least one array calibration data set based on at least one antenna model parameter received from the O-DU (i.e., the O-RU configures at least one beam weight and / or at least one antenna calibration data set predefined or generated by the O-DU for the corresponding antenna model to be activated and applied to the O-RU by the O-DU. The predefined or generated beam weights applied by the O-DU to the O-RU are either based on the antenna configuration capability information including at least one antenna array model parameter or based on the antenna array configuration including at least one antenna array model parameter supported by the O-RU).

[0092] In step 302, considering the transition time of the antenna configuration change, the O-RU responds to the antenna configuration change during the transition from one antenna array model to another antenna array model. Not limited to the method in step 301, step 302 can start independently of step 301. For example, considering the transition time of the antenna configuration change for at least one network energy saving (NES) method (such as the TRx control process, sleep mode, etc.), the O-RU responds to the antenna configuration change during the transition from one antenna array model to another antenna array model.

[0093] According to Figure 3 , in particular, the advantage of step 302 is that by considering the transition time of the antenna configuration change (i.e., wake-up time, going to sleep, wake-up delay, etc.), NES embodiments, such as the advanced sleep mode (ASM) with a short duration (C-plane based) sleep mode, the sleep mode with a long duration (M-plane based) sleep mode, the wake-up delay of the ASM (i.e., wake-up or sleep time), and the wake-up delay of the TRx control process (i.e., method) do not interfere with each other (e.g., hinder).

[0094] The term transition time is interchangeable with the term wake-up time and defines the duration of the transition from one antenna array configuration to another antenna array configuration, and vice versa. According to an example embodiment, the transition time / wake-up time can refer to the duration of the transition from one antenna array model to another antenna array model, and vice versa.

[0095] Figure 4 Illustrated is a method for changing the antenna array model over a baseline antenna array. Referring to Figure 4 , the antenna configuration capability information includes at least one antenna array model parameter for defining at least one predefined antenna array model among a plurality of predefined antenna array models that the O-RU can activate. In step 401, the O-RU receives bits from the O-DU to activate a mask for at least one antenna array model. In step 402, the O-RU activates at least one antenna array model over the baseline antenna array configuration of the O-RU based on the bit mask received from the O-DU.

[0096] According to Figure 4 , this method allows for dynamic change of the antenna array configuration, such as switching between one antenna array model and another antenna array model (i.e., muting (e.g., turning off) parts of the antenna array (i.e., antenna elements) and their corresponding RF transceiver chains). The advantage of this is that due to the exchange of knowledge of the proprietary internal architecture (e.g., O-RU read-only (proprietary) parameters) with the O-DU, the ES (i.e., NES) method can be implemented with the highest efficiency.

[0097] According toFigures 2 to 4 The method can be implemented in at least one device, which includes a memory for storing instructions and at least one processor configured to execute the instructions to implement Figures 2 to 4 the method.

[0098] Referring to the method and device according to Figures 2 to 4 The dynamic antenna array reconfiguration (e.g., dynamic change of the antenna array configuration, such as switching from one antenna array model to another (i.e., muting (e.g., turning off) parts of the antenna array (i.e., antenna elements) and their corresponding RF transceiver chains)) has the advantage that, due to the exchange of knowledge of the proprietary internal architecture (e.g., O-RU read-only (proprietary) parameters), the ES method can be implemented with maximum efficiency.

[0099] Figure 5 illustrates a method for optimizing the antenna array model selection in O-RAN from the perspective of the O-DU. Referring to Figure 5 , in step 501, the O-DU receives antenna configuration capability information including at least one antenna array model parameter from the radio unit (O-RU) via management plane (M-plane) messaging (i.e., M-plane commands). For example, the O-RU reports the configuration capability information, such as the supported network energy saving (i.e., ES or NES) mode, through O-RU-urn:o-ran:module-cap:1.0.

[0100] For example, the antenna configuration capability information can be hard-coded during production by the vendor together with at least one of the following parameters, unique name, index, reference, etc., to identify the antenna array configuration capability (e.g., the technical specification 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 configuration change, the value referring to the energy saving achievable for each configuration, the associated beam weights (predefined beam weights), etc. In one exemplary embodiment, when the O-RU is powered on (initialized), the O-RU starts reporting the supported energy saving mode (i.e., antenna configuration capability information), the hard-coded antenna array model, and other initialization parameters to the O-DU using the M-plane yang models (e.g., urn:o-ran:module-cap:1.0 and an urn:o-ran:hardware:1.0).

[0101] In an example embodiment, the energy-saving-by-transmission-blanks parameter can be used to send configuration capabilities information from the O-RU to the O-DU. This allows the use of the existing M-plane model to provide (i.e., define) new parameters to enable the O-RU to report 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.).

[0102] For the existing M-plane yang model, to ensure backward compatibility, if the O-RU does not support the custom configuration of ES or the RF channel reconfiguration / antenna array selection method, the O-RU can mark the above energy-saving modes as "false".

[0103] In another example embodiment, the O-RU configuration capabilities information can include supported features, such as the energy-saving features supported in o-ran-wg4-features.yang. The O-RU can indicate to the O-RU controller the energy-saving features supported in o-ran-wg4-features.yang (i.e., the O-DU or a higher-layer network function (e.g., SMO)).

[0104] According to an embodiment, in accordance with the O-RAN open front-end M-plane specification that defines the management plane of the open front-end interface and the associated YANG model, the O-RU can indicate to the O-RU controller (such as the O-DU and / or a higher-order network function (i.e., SMO, etc.)) the energy-saving features supported in the associated YANG model, such as o-ran-wg4-features.yang.

[0105] To this end, the O-RU configuration capabilities information can include 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., DEEPSLEEP), etc.

[0106] The YANG feature name tags TRX-CONTROL or TRX-ON-OFF can describe turning on / off the RF channel or Tx / Rx array elements (i.e., the opening or closing of the RF channel or Tx / Rx array elements), while the M-plane activation as an optional feature control may not be available.

[0107] The YANG feature name tags ADVANCED - SLEEP - MODE or SLEEP - MODE can describe turning off the carrier and associated (multiple) O - RU circuits and / or (multiple) O - RU components (i.e., muting and / or turning on / off the physical and functional components of the O - RU) based on the corresponding activated sleep mode, while the M - plane activation as an optional feature control may not be available.

[0108] The YANG feature name tag HIBERNATE - SLEEP can describe achieving O - RU energy savings by turning off the carrier and associated O - RU circuits / components over a longer duration, where the longer duration allows the optional feature control to be implemented in a hardware / component / energy - saving - enabled manner as an M - plane - based sleep mode compared to other sleep modes.

[0109] The YANG feature name tag LIGHT - HIBERNATE - SLEEP can describe achieving O - RU energy savings by turning off the carrier and associated O - RU circuits / components over a longer duration without turning off synchronization, where the longer duration allows the optional feature control to be implemented in a hardware / component / energy - saving - enabled manner as an M - plane - based sleep mode compared to other sleep modes.

[0110] The YANG feature name tag DEEP - HIBERNATE - SLEEP (i.e., deep sleep) can describe achieving O - RU energy savings by turning off the carrier and associated O - RU circuits / components over a longer duration by turning off synchronization, where the longer duration allows the optional feature control to be implemented in a hardware / component / energy - saving - enabled manner as an M - plane - based sleep mode compared to other sleep modes.

[0111] According to an example embodiment, various short - duration (C - plane - based) sleep modes can be defined with reference to the YANG feature name tags ADVANCED - SLEEP - MODE or SLEEP - MODE. For example, the advanced sleep mode can be used for shorter sleep durations such as milliseconds, seconds, or minutes, and is activated, for example, by ST4 C - plane messages through control plane (C - plane) messaging.

[0112] According to an example embodiment, with reference to the YANG feature name tag HIBERNATE - SLEEP of a longer duration, the hibernate sleep mode can be activated by adopting the M - plane. For example, by setting the parameter +--rw energy - saving - enabled? boolean {ENERGYSAVING}? in the corresponding o - ran - hardware.yang module to "true" or "yes".

[0113] According to an example embodiment, with reference to the YANG feature name tags LIGHT-HIBERNATE-SLEEP and DEEP-HIBERNATE-SLEEP to distinguish longer sleep with and without turning off the synchronization plane circuit, a light hibernation sleep mode with synchronization and a deep hibernation sleep mode without synchronization can be implemented in the same way as the hibernation sleep by adopting the M-plane. For example, by setting the parameter +--rw energy-saving-enabled? boolean{ENERGYSAVING}? in the corresponding o-ran-hardware.yang module to "true" or "yes".

[0114] Referring to the O-RU reporting to the O-DU based on the yang module (i.e., the O-DU receives the O-RU configuration capability information), for example, as described in o-ran module.cap.yang, the Advanced Sleep Mode (ASM) can support a sleep mode (SM) with a short-duration (C-plane-based) sleep mode (e.g., multiple sleep modes such as SM#0, SM#1, SM#2, SM#3, etc., where the duration SM#0 < SM#1 < SM#2 < SM#3), with different wake-up times, or if the wake-up time is too short, support a defined entry sleep time. In addition, the Advanced Sleep Mode (ASM) can support a sleep mode with a long-duration (M-plane-based) sleep mode (e.g., a hibernation sleep without any synchronization (i.e., deep sleep) or a hibernation hibernation (i.e., deep sleep) mode with or without synchronization, while a light hibernation sleep refers to an M-plane-based sleep mode with synchronization, and a deep hibernation sleep refers to an M-plane-based sleep mode without synchronization.

[0115] According to an embodiment, the Advanced Sleep Mode (ASM) has a wake-up time (minimum or guaranteed) per sleep mode. The shortest mode in the C-plane-based sleep mode (e.g., SM#0) may not be defined by the minimum or guaranteed wake-up time, but by the entry sleep time.

[0116] The O-RU reported to the O-DU and / or SMO based on the yang module (as described in o-ran module.cap.yang) can also support C-plane messages such as the section type 8 (ST8) "ready" message and C-plane messages including commands scape (e.g., CARRIER-COMMAND, ARRAY-COMMAND, O-RU-COMMAND) (such as the section type 4 (ST4) message).

[0117] According to an example embodiment, a TRx control method for reconfiguring an antenna array may include: a TRx management configuration identified by a corresponding unique configuration identifier or name. The antenna array model of the TRx control configuration includes at least one antenna mask (antMask), where the antenna mask bit combination may be limited to supported TRx control configurations, where the antenna mask bits identify '0' for the antenna elements to be turned off and '1' for the active elements of the antenna array. In addition, in addition to the mask bits for at least one antenna mask (antMask), the TRx control configuration further includes antenna layer mask bits for creating at least one antenna layer mask (antLayerMask).

[0118] 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 parameters.

[0119] +--rw module-capability

[0120] +--ro ru-capabilities

[0121] / / TRx control - Capability report

[0122] |+--ro trx-control-capability{or-feat:TRX-CONTROL}?

[0123] ||+--ro number-of-supported-trx-control-configuration?Uint8 / / The number of supported TRx control configurations.

[0124] ||+--ro supported-trx-control-configuration*[name]

[0125] |||+--ro configuration-name

[0126] string / / The unique name of each TRx control configuration

[0127] |||+--ro antenna-mask?

[0128] binary or bits / / List of antMasks - All antenna masks for each TRx control configuration

[0129] |||+--ro antenna-layer-mask?

[0130] binary or bits / / List of antLayerMask - antenna layer masks for each TRx control configuration

[0131] |||+--ro transition-time or wake-up-time uint32

[0132] / / Transition time (list) associated with each configuration change of the supported TRx control configuration and as a function of the subcarrier spacing. Since for 15KHz, 1 time slot is 1 millisecond, and for 30KHz, 1 time slot is 0.5 millisecond or 500 microseconds

[0133] |||+--ro energy-saving-ratio

[0134] uint8 / / Percentage of energy saving for each TRx control configuration

[0135] / / Data layer / space stream control - capability report

[0136] |+--ro data-layer-control-supported? boolean{or-feat:TRX-CONTROL}? / / Does the O-RU support data layer control / limit the number of space streams?

[0137] According to an example embodiment, the supported TRx control configuration may include a transition time (i.e., a wake-up time different from ASM), which defines the minimum or guaranteed time required to switch from a baseline configuration to a specific configuration (i.e., switching the baseline 64TRx antenna array to another antenna mask configuration, such as a 32TRx_antenna array model or a 64TRx_antenna array model). The transition time (i.e., wake-up time) associated with each configuration change of the supported TRx control configuration and as a function of the subcarrier spacing, e.g., for 15KHz, one time slot is 1 millisecond, for 30KHz, one time slot is 0.5 millisecond or 500 microseconds, etc.

[0138] According to an example embodiment, the O-Ru may report data layer control capabilities or the ability to limit the number of space streams for at least one supported (i.e., given) antenna configuration as described above in the Yang model o-ran-module-cap.yang.

[0139] In an example embodiment, the TRx of an antenna array (e.g., 64T64R antenna array) can remain active, while the gain (i.e., energy-saving gain) can be achieved by turning off the O-RU processing device by changing the number of data layers / spatial streams. According to an example embodiment, the TRx control method may include controlling to turn on / off the entire RF transceiver chain and / or the radio frequency front end (RFFE) of the radio frequency (RF) processing unit related to some RF channels / antenna elements.

[0140] In addition, according to another example embodiment, the TRx control method may include controlling to turn on / off components, circuits, IPs, cores, computing engines (i.e., physical components of the O-RU) of the digital baseband and the O-RAN front-end processing unit.

[0141] According to embodiments of the advanced sleep mode (ASM) with a short-duration (C-plane-based) sleep mode and the sleep mode with a long-duration (M-plane-based) sleep mode, the wake-up delay of the ASM (i.e., wake-up time or sleep entry time) and the wake-up delay of the TRx control may be different and do not interfere with each other (e.g., hinder).

[0142] The O-RU reported to the O-DU and / or SMO based on the yang module (e.g., the module specified in o-ran module.cap.yang) can also support sleep duration extension and emergency wake-up through M-plane and / or C-plane messaging.

[0143] In addition, the O-RU reported to the O-DU and / or SMO based on the yang module (e.g., as specified in o-ran module.cap.yang) can also provide information such as the achievable energy-saving percentage.

[0144] In addition, the O-RU reported to the O-DU and / or SMO based on the yang module (e.g., as described in o-ran module.cap.yang) can also support notification messages of the active or inactive state of the CU plane. For example, it supports the notification required to ensure that the CU plane becomes active after the sleep duration expires (i.e., in the case of defined, undefined, and / or long sleep durations, the CU plane circuit can be turned off). To this end, the O-RU reported to the O-DU and / or SMO supports notifying the CU plane state from the O-RU to the O-DU in case it is turned off during any sleep mode activation.

[0145] Generally, o-ran-module-cap.yang relates to common O-RU capabilities (i.e., O-RU configuration capability information of sleep modes such as the advanced sleep mode, CU-plane state reporting for implementing sleep modes (e.g., advanced sleep mode, etc.), and TRx control methods).

[0146] To this end, o-ran-module-cap.yang and other YANG models may include all the information required to implement the antenna array configuration support of the O-RU (i.e., based on the O-RU configuration capability information).

[0147] According to an example embodiment, o-ran-module-cap.yang and other YANG models for the TRx control method for reconfiguring the antenna array may include a TRx control configuration identified by a corresponding unique configuration identifier or name. The antenna array model of the TRx control configuration includes at least one antenna mask (antMask), where the antenna mask bit combination may be limited to the supported TRx control configuration, where the antenna mask bits identify '0' for the antenna elements to be turned off and '1' for the active elements of the antenna array. In addition, in addition to the mask bits for at least one antenna mask (antMask), the TRx control configuration further includes antenna layer mask bits for creating at least one antenna layer mask (antLayerMask).

[0148] The YANG model o-ran-module-cap.yang may include the following parameters.

[0149] o-ran-module-cap.yang - Advanced Sleep Mode

[0150] +--rw module-capability

[0151] +--ro ru-capabilities

[0152] |+--ro max-num-component-carriers? uint8

[0153] |x--ro max-num-bands? uint16

[0154] / / Advanced Sleep Mode - Capability Report

[0155] |+--ro advanced-sleep-mode-capability? enumeration{or-feat:ADVANCED-SLEEP-MODE}?

[0156] ||+--ro supported-sleep-modes*[name] / / List of supported sleep modes, such as Sleep Mode 0, 1, 2, and 3 (SM#0 - 3)

[0157] |||+--ro sleep-mode-name

[0158] string / / sleepMode0(SM#1), sleepMode1(SM#2), sleepMode2(SM#2), and sleepMode3(SM#3)

[0159] |||+--ro wake-up-time

[0160] uint32 / / List of wake-up times (minimum or guaranteed) in number of time slots associated with each sleep mode and as a function of subcarrier spacing. For example, SM#1 - L time slots, SM#2 - M time slots, and SM#3 - N time slots. The O-RU lists the wake-up times in number of time slots for all supported subcarrier spacings. Since for 15KHz, 1 time slot is 1 millisecond, and for 30KHz, one time slot is 0.5 millisecond or 500 microseconds.

[0161] |||+--ro energy-saving-ratio

[0162] uint8 / / Percentage of energy savings for each sleep mode

[0163] |+--ro hibernate-sleep-capability{or-feat:HIBERNATE-SLEEP}? / / Option 1: Longer sleep duration

[0164] ||+--ro hibernate-wake-up-time or wake-up-time-hibernate uint32 / / Wake-up time for hibernate sleep (in milliseconds)

[0165] |+--ro light-hibernate-sleep-capability{or-feat:LIGHT-HIBERNATE-SLEEP}? / / Option #2a: Longer sleep duration with synchronization

[0166] ||+--ro lh-wake-up-time or wake-up-time-lh uint32

[0167] / / Wake-up time for light hibernate sleep (in milliseconds)

[0168] |+--ro deep-hibernate-sleep-capability{or-feat:DEEP-HIBERNATE-SLEEP}? / / Option #2b: Longer sleep duration without synchronization

[0169] ||+--ro dh-wake-up-time or wake-up-time-dh uint32

[0170] / / Wake-up time for deep hibernate sleep (in milliseconds)

[0171] ||+--ro supported-command-scape*enumeration / / Supported ST4 command interfaces to be reported by the O-RU, such as "CARRIER-command, ARRAY-command, O-RU-command". For example, one or two or all three

[0172] ||+--ro st8-ready-msg-supported? boolean / / The O-RU has reported support for section type (ST) 8 messages in the supported-section-type, so from the NES perspective, the O-RU will report support for the "ready" command in ST8 messages as a capability

[0173] ||+--ro sleep-duration-extension-supported? boolean / / During a defined sleep, if the O-DU wants to extend the ongoing sleep, it can issue a sleep extension C-plane command (short sleep duration) and an M-plane command (longer sleep duration). The O-RU can advertise support for this as an optional option.

[0174] ||+--ro emergency-wake-up-by-cplane-command-supported? boolean / / (During a defined (not guaranteed) or undefined sleep duration, the O-DU can interrupt the sleep at any time by issuing an emergency wake-up C-plane command, provided that the CU plane remains active or the CU plane circuitry is on. The O-RU can advertise this support as an optional option.

[0175] ||+--Is emergency wake-up by M-plane command supported? boolean / / (During a defined (not guaranteed) or undefined sleep duration, when the CU plane is off, the O-DU can interrupt sleep at any time by sending an emergency wake-up command via the M-plane. The O-RU can advertise this support as an optional option.)

[0176] Referring to the above summary, the general O-RU capabilities can apply to both TRx control and the advanced sleep mode.

[0177] According to an example embodiment, the supported TRx control configuration can include a transition time (i.e., a wake-up time different from that of ASM), which defines the minimum or guaranteed time required to switch from a baseline configuration to a specific configuration (i.e., switching the baseline 64TRx antenna array to another antenna mask configuration, such as the 32TRx_antenna array model). The transition time (i.e., wake-up time), which is associated with each configuration change of the supported TRx control configuration and is a function of the subcarrier spacing, for example, for 15KHz, one time slot is 1 millisecond, for 30KHz, one time slot is 0.5 millisecond or 500 microseconds, and so on.

[0178] The term transition time and the term wake-up time are interchangeable and define the duration of the transition from one antenna array configuration to another antenna array configuration, and vice versa. According to an example embodiment, the transition time / wake-up time can refer to the duration of the transition from one antenna array model to another antenna array model, and vice versa.

[0179] According to an example embodiment, the TRx control method can include controlling to turn on / off the entire RF transceiver chain related to some RF channels / antenna elements and / or the radio frequency front end (RFFE) of the radio frequency (RF) processing unit.

[0180] In addition, according to another example embodiment, the TRx control method can include controlling to turn on / off components, circuits, IPs, cores, computing engines (i.e., physical components of the O-RU) of the digital baseband and the O-RAN front-end processing unit.

[0181] According to embodiments of the advanced sleep mode (ASM) with a short-duration (C-plane-based) sleep mode and the sleep mode with a long-duration (M-plane-based) sleep mode, the wake-up delay (i.e., wake-up time or sleep entry time) of the ASM and the wake-up delay of the TRx control method can be different and do not interfere with each other (e.g., hinder).

[0182] In addition, the common capability parameters of both the TRx control method and the sleep mode (e.g., advanced sleep mode) for which the O-RU configuration capability information is to be reported to the O-DU via the M-plane can include the C-plane ST8 "ready" message and sleep duration extension (e.g., in the case of defined sleep, if the O-DU needs to extend the sleep mode, it sends a sleep extension command before the wake-up time starts). If the CU-plane remains active, the extension command can be based on the C-plane for a shorter sleep duration. If the CU-plane is closed, the extension command can be based on the M-plane for a longer sleep duration.

[0183] In addition, the common capability parameters of both the TRx control method and the sleep mode (e.g., advanced sleep mode) for which the O-RU configuration capability information is to be reported to the O-DU via the M-plane can include the emergency wake-up of the O-RU from sleep. This capability can 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 the sleep mode, it sends a sleep mode interruption command. If the CU-plane remains active, the emergency wake-up command can be based on the C-plane for a shorter sleep duration (defined or undefined). If the CU-plane is closed, the emergency wake-up command can be based on the M-plane for a longer sleep duration (defined or undefined).

[0184] According to an example embodiment, o-ran-module-cap.yang and other YANG models for CU-plane status reporting (e.g., for implementing the O-RU capabilities of defined and undefined sleep modes). o-ran-module-cap.yang includes information for enabling the CU-plane circuit to be turned off to achieve additional energy savings. This information can include: the name identifier and status identifier of Rx-array-carriers, as well as the name identifier, action identifier, and status of the CU-plane to report user plane configuration. Based on the above information, the O-DU can turn on or wake up the CU-plane circuit via the M-plane. According to an example embodiment, a notification is required to indicate whether the CU-plane becomes active (wakes up from sleep), which can be defined in o-ran-uplane.yang respectively.

[0185] The YANG model o-ran-uplane.yang can include the following parameters.

[0186] +--ro rx-array-carriers*[name]

[0187] +--ro name-> / user-plane-configuration / rx-array-carriers / name

[0188] +--ro state? -> / user-plane-configuration / rx-array-carriers / state

[0189] +---n CU-plane-state-change

[0190] |+--ro CU-plane[name]

[0191] |+--ro active? -> / user-plane-configuration / CU-plane / active; Active / Inactive

[0192] |+--ro state? -> / user-plane-configuration / CU-plane / state:Enabled / Disabled

[0193] According to an example embodiment of the use case of RF channel reconfiguration (i.e., RF channel off / on), the sub-use case can be defined as TRx control (i.e., Tx array control and Rx array control can be declared separately because the antenna mask can be defined at the array level. For this sub-use case, the O-RU can include at least one of the following capability reports (i.e., configuration capability information). The configuration capability information can include: at least reporting other capabilities that support the activation / deactivation of TRx control based on the C-plane and M-plane, reporting the list of supported antenna array configurations / TRx control configurations (e.g., valid antenna mask values (each antenna array configuration value) and unique names), reporting the wake-up time / duration as a function of the SCS (sub-carrier spacing) (i.e., this wake-up can be different from the wake-up time / duration reported for the advanced sleep mode), reporting the support for the TRx control sleep mode, reporting the energy saving / power saving / energy saving ratio achievable for each antenna array configuration (Tx array and / or Rx array) or TRx control (Tx control and / or Rx control), reporting the support for defined and undefined duration sleep, ST8 ready message, sleep duration extension, and using valid yang data model parameters to perform emergency wake-up and reporting on the O-RU internal architecture (functional blocks) to achieve maximum energy saving (i.e., exposing the O-RU internal architecture).

[0194] According to another example embodiment of the use case of RF channel reconfiguration (i.e., RF channel off / on), the sub-use case can be defined as data layer control. For this sub-use case, the capability report (i.e., configuration capability information) can include: the list of the maximum spatial streams / data layers supported for each antenna array (TRx control) configuration.

[0195] According to another example embodiment, a use case can be defined as an advanced sleep mode. For this sub-use case, the O-RU can include at least one of the following capability reports (i.e., configuration capability information). In addition to other capability reports, the configuration capability information can at least further include: a report of the wake-up duration associated with each sleep mode as a function of the SCS, a report of the energy savings achievable per sleep mode type, a report of the support for defined and undefined duration sleep, an ST8 ready message, sleep duration extension, and emergency wake-up.

[0196] According to another example embodiment of the use case RF channel reconfiguration (i.e., RF channel close / open), the sub-use case can be defined as dormant sleep. For this sub-use case, the O-RU can include at least one of the following capability reports (i.e., configuration capability information). In addition to other capability reports, the configuration capability information can at least further include a report of the support for dormant sleep (i.e., deep sleep) (such as long sleep (light / deep sleep)), a report of the support for the O-RU to remove / deprovision carriers during long sleep, a report of the support for shutting down the C-plane, U-plane, S-plane, and M-plane processing units (i.e., support for an O-DU request (e.g., by sending (one or more) appropriate RPCs) or the internal logic of the O-RU).

[0197] In step 502, the O-DU receives a request for reconfiguring the antenna array from a high-layer network function. The request for reconfiguring the antenna array is based on the monitored network parameters meeting a predetermined condition. In an example embodiment, the high-layer network function can determine whether the current network parameters (e.g., the current network parameters reflected by O1-related KPIs, such as throughput, the number of users in the cell, user statistics, etc.) meet a predetermined condition (i.e., a predetermined threshold related to O-RAN network conditions). The predetermined network parameters can be based on the rank indicator (RI) value shared by the UE, the traffic scenario, etc., which can be derived from the O1 interface-related KPIs, such as throughput, the number of users in the cell, user statistics, etc.).

[0198] In step 503, the O-DU determines an antenna array configuration including at least one antenna array model parameter supported by the O-RU. The determined antenna array configuration is based on the antenna configuration capability information including at least one antenna array model parameter from the O-RU and based on the request for reconfiguring the antenna array from the high-layer network function as described above.

[0199] In Figure 2 and Figure 5Among them, the antenna configuration capability information including at least one antenna array model parameter from the O-RU and the information based on the request for reconfiguring the antenna array from the higher-layer network function can be similar and interchangeable.

[0200] In step 504, the O-DU applies the supported antenna array configuration including at least one antenna array model parameter via C-plane messaging or M-plane messaging (i.e., via C-plane messaging or M-plane messaging for activating (i.e., applying) an antenna array model change on top of the baseline antenna array configuration of the O-RU based on the supported antenna array configuration).

[0201] According to the example embodiment set forth in step 501, the sleep mode can be compatible with the control plane (C-plane) or the management plane (M-plane), depending on the sleep duration.

[0202] According to the example embodiments of the advanced sleep mode (ASM) with a short-duration (C-plane-based) sleep mode and the sleep mode with a long-duration (M-plane-based) sleep mode, the wake-up delay (i.e., wake-up time or time to enter the sleep state) of the ASM and the wake-up delay of the TRx control method can be different and do not interfere with each other (e.g., hinder).

[0203] Alternatively, in another step (i.e., as Figure 3 shown), the O-DU receives from the O-RU via response C-plane messaging or response M-plane messaging (i.e., via C-plane messaging or M-plane messaging different from the C-plane messaging or M-plane messaging for activating (i.e., applying) an antenna array model change based on the supported antenna array configuration including at least one antenna array model parameter).

[0204] C-plane messaging or M-plane messaging is in response to an antenna array configuration change to the supported antenna array configuration. In an example embodiment, the C-plane messaging can be an acknowledgment message for an antenna array configuration change to the supported antenna array configuration. In another example embodiment, the M-plane messaging can be a notification of an antenna array configuration change to the supported antenna array configuration.

[0205] Figure 6 Illustrates a method for selecting at least one antenna array model parameter operable by the O-RU. Refer to Figure 6, in step 601, the O-DU selects (e.g., generates, determines, etc.) at least one antenna array model parameter operable by the O-RU on top of the baseline antenna array configuration of the O-RU. According to an embodiment, the O-DU determines at least one antenna array model parameter supported by the O-RU based on antenna configuration capability information including at least one antenna array model parameter from the O-RU and based on a request for reconfiguring the antenna array from a higher-layer network function. According to an example embodiment, the at least one antenna array model parameter allows, for example, bitmasking (e.g., generating, selecting, determining, etc.) at least one antenna array model operable by the O-DU on top of the baseline antenna array configuration of the O-DU.

[0206] In step 602, based on the selected at least one antenna array model parameter, on top of the baseline antenna array configuration of the O-RU, the O-DU bitmasks at least one antenna array model operable by the O-RU. In step 603, the O-DU sends the bitmask to activate at least one antenna array model at the O-RU. In one example embodiment, the bitmask in step 602 may refer to indexing the antenna array model, and the bitmask in step 603 refers to sending at least one index of the antenna array model as at least one antenna array model parameter (e.g., at least one offset parameter).

[0207] According to Figure 6 , the method allows for dynamic change of the antenna array configuration, such as switching between one antenna array model and another (i.e., muting (e.g., turning off) parts of the antenna array (i.e., antenna elements) and their corresponding RF transceiver chains). This has the advantage that, due to the exchange of knowledge of the proprietary internal architecture (e.g., O-RU read-only (proprietary) parameters) with the O-DU, the ES (i.e., NES) method can be implemented with maximum efficiency.

[0208] According to Figure 5 and Figure 6 's method can be implemented in at least one device that includes a memory for storing instructions and at least one processor configured to execute the instructions to implement Figure 5 and Figure 6 's method.

[0209] Referring to the method and device according to Figure 5 and Figure 6 , the advantages of dynamic antenna array reconfiguration (e.g., dynamic change of the antenna array configuration, such as switching from one antenna array model to another (i.e., muting (e.g., turning off) parts of the antenna array (i.e., antenna elements) and their corresponding RF transceiver chains)) are that, due to the exchange of knowledge of the proprietary internal architecture (e.g., O-RU read-only (proprietary) parameters), the ES method can be implemented with maximum efficiency.

[0210] Figure 7 Illustrated is a method of M-plane message passing, which includes a Yang model for the capability report of TRx control parameters and a YANG model for the capability report of data layer control parameters.

[0211] Reference Figure 7 , based on the Yang model of the capability report for the TRx control method, the O-RU reports its capability information for implementing TRx control to the O-DU. Based on the TRx control, the parameters and requirements for the O-RU are different. The O-DU uses the capability information to apply the supported antenna array configuration (i.e., apply the supported antenna array configuration for the corresponding TRx control method (i.e., the TRx control process)).

[0212] In an example embodiment, according to the specific antenna array configuration of the O-RU (i.e., the O-RU internal architecture), the antenna configuration capability information of the O-RU may include at least one antenna array model parameter (i.e., data defining at least one antenna array model), where when applying the TRx control process to reconfigure the antenna array, the O-DU may select (e.g., determine or generate) at least one antenna array model operable by the O-RU above the baseline antenna array configuration. For example, the O-DU may perform a bitmask on at least one (selected) antenna array model based on the antenna configuration capability information of the O-RU (i.e., based on the antenna array models operable by the O-RU above the baseline antenna array configuration of the O-RU). In this case, the O-DU may send a bitmask of at least one antenna array model to be activated to the O-RU.

[0213] In another example embodiment, the antenna configuration capability information of the O-RU may include at least one antenna array model parameter (i.e., data defining at least one antenna array model) according to the specific antenna array configuration of the O-RU (i.e., the O-RU internal architecture), where when applying the TRx control process to reconfigure the antenna array, the O-DU may select (i.e., determine, generate, etc.) at least one antenna array model operable by the O-RU above the baseline antenna array configuration, where the (selected) antenna array model is defined by an offset parameter, which may be reported by the O-RU to the O-DU, for example (i.e., the antenna array model is operable by the O-RU above the baseline antenna array configuration of the O-RU). In this case, the O-DU may send an offset parameter referring to the (selected) antenna array model to be activated to the O-RU.

[0214] The offset parameters include a first offset value in the horizontal direction (x-direction) of the antenna array and a second offset value in the vertical direction (y-direction), where the first offset value represents the element-to-element spacing (dx) from the lower left side to the lower right side of the antenna array, which defines at least one column of antenna elements to be muted in the x-direction of the antenna array, and where the second offset value represents the element-to-element spacing (dy) from the lower left side to the upper left side of the antenna array, which defines at least one row of antenna elements to be muted in the y-direction of the antenna array.

[0215] Generally, o-ran-module-cap.yang involves common O-RU capabilities (i.e., O-RU configuration capability information for sleep modes (such as advanced sleep mode), CU-plane status reporting for implementing sleep modes (e.g., advanced sleep mode, etc.), and TRx control methods.

[0216] To this end, o-ran-module-cap.yang and other YANG models can include all the information required to implement antenna array configuration support for the O-RU (i.e., based on the O-RU configuration capability information).

[0217] According to an example embodiment, o-ran-module-cap.yang and other YANG models for the TRx control method for reconfiguring the antenna array can include a TRx control configuration identified by a corresponding unique configuration identifier or name. The antenna array model of the TRx control configuration includes at least one antenna mask (antMask), where the antenna mask bit combination can be limited to the supported TRx control configurations, where the antenna mask bits identify '0' for the antenna elements to be turned off and '1' for the active elements of the antenna array. In addition, in addition to the mask bits for at least one antenna mask (antMask), the TRx control configuration also includes antenna layer mask bits for creating at least one antenna layer mask (antLayerMask).

[0218] According to an example embodiment, the TRx control method can include controlling to turn on / off the entire RF transceiver chain and / or the radio frequency front end (RFFE) of the radio frequency (RF) processing unit related to some RF channels / antenna elements.

[0219] In addition, according to another example embodiment, the TRx control method can include controlling to turn on / off components, circuits, IPs, cores, computing engines (i.e., physical components of the O-RU) of the digital baseband and the O-RAN front-end processing unit.

[0220] According to an example embodiment of RF channel reconfiguration according to a use case (i.e., RF channel close / open), sub-use cases can be defined as TRx control (i.e., Tx array control and Rx array control can be declared separately because the antenna mask can be defined at the array level. For this sub-use case, the O-RU can include at least one of the following capability reports (i.e., configuration capability information). The configuration capability information can include: at least reporting other capabilities that support activation / deactivation of TRx control based on the C-plane and M-plane, reporting the list of supported antenna array configurations / TRx control configurations (e.g., valid antenna mask values (for each antenna array configuration value) and indices and / or unique names, reporting the wake-up time / duration as a function of the SCS (subcarrier spacing) (i.e., this wake-up can be different from the wake-up time / duration reported for the advanced sleep mode), reporting support for the TRx control sleep mode, reporting the energy saving / power saving / energy saving ratio achievable for each antenna array configuration (Tx array and / or Rx array) or TRx control (Tx control and / or Rx control), reporting support for defined and undefined duration sleep, ST8 ready message, sleep duration extension, and reporting emergency wake-up and reporting of the O-RU internal architecture (functional blocks) using valid yang data model parameters to achieve maximum energy saving (i.e., exposing the O-RU internal architecture).

[0221] The energy saving report through TRx control can be reported through the parameters of the YANG model o-ran-module-cap.yang, summarized as follows:

[0222] The format of the module capabilities module is as follows:

[0223] |+--ro energy-saving-by-transmission-blanks boolean

[0224] |+--ro energy-saving-by-trx-control boolean / / TRx control - multiple antenna configurations for energy saving

[0225] |+--ro energy-saving-by-advanced-sleep-modes boolean

[0226] ||+--ro advanced-sleep-modes enum

[0227] ||+--ro micro-sleep-mode-supported?Boolean / / The O-DU reads this response ("yes" or "no") and knows whether the O-RU supports micro-sleep - option #1

[0228] ||+---n micro-sleep-mode-supported / / Notification to indicate whether micro-sleep mode is supported - Option #2

[0229] |+--ro CU plane - active-state enum / / This indicates the ability of the CU plane circuitry to be awake and active to receive messages from the O-DU. For example, during the sleep mode, the CU plane circuitry sometimes shuts down and wakes up. According to the current notification framework, the O-RU only reports the operator active state to the O-DU. It is necessary to notify the O-DU in advance that the CU plane has woken up from sleep and is in the active state so that the O-DU can start scheduling CU plane packets. |+--ro eaxcid-grouping-capabilities

[0230] {o-ran-module-cap:EAXC-ID-GROUP-SUPPORTED}?

[0231] According to another exemplary embodiment for the use case of RF channel reconfiguration (i.e., RF channel off / on), the sub-use case may include: the O-RU's ability report (i.e., configuration ability information) of the maximum supported spatial stream / data layer list for each antenna array (TRx control) configuration. For example, this sub-use case can be defined as data layer control.

[0232] According to another exemplary embodiment for the advanced sleep mode use case, the O-RU may include at least one of the following ability reports (i.e., configuration ability information). In addition to other ability reports, the configuration ability information may at least further include: a report of the wake-up duration associated with each sleep mode as a function of the SCS, a report of the energy savings achievable for each sleep mode type, a report of the support for defined and undefined duration sleep, ST8 ready message, sleep duration extension, and emergency wake-up.

[0233] According to an exemplary embodiment, the supported TRx control configuration may include a transition time (i.e., different from the wake-up time of ASM), which defines the minimum or guaranteed time required to switch from the baseline configuration to a specific configuration (i.e., switch the baseline 64TRx antenna array to another antenna mask configuration, such as the 32TRx_antenna array model). The transition time (i.e., wake-up time) associated with each configuration change of the supported TRx control configuration and as a function of the subcarrier spacing. For example, for 15KHz, one time slot is 1 millisecond, for 30KHz, one time slot is 0.5 millisecond or 500 microseconds, and so on.

[0234] The YANG model o-ran-module-cap.yang can include the following parameters.

[0235] TRx Control Configuration and Associated Parameter Reporting — o-ran-uplane-conf.yang

[0236] |+--rw name string

[0237] |+--rw sro-id? -> / or-user:users / user / sro-id{feat:SHARED-ORU-MULTI-OPERATOR}? |+--rw processing-element -> / o-ran-pe:processing-elements / ru-elements / name

[0238] |+--rw transport-session-type? enumeration

[0239] {feat:MULTIPLE-TRANSPORT-SESSION-TYPE}?

[0240] |+--rw transport-qualified-processing-element? ->

[0241] / o-ran-pe:processing-elements / additional-transport-session-type-elements[o-ran-pe:transport-session-type = current() / .. / transport-session-type] / ru-elements / name

[0242] {feat:MULTIPLE-TRANSPORT-SESSION-TYPE}?

[0243] |+--rw tx-array-carrier -> / user-plane-configuration / tx-array-carriers / name

[0244] / / trx control

[0245] |+--ro trx-control-configurations

[0246] / / Antenna Masking and Antenna Layer Report

[0247] ||+--ro antLayerMask unint16 / / Antenna layer number to be reported by O-RU

[0248] ||+--ro antMask unint32 / / List of antenna masks for all supported configurations, consisting of a matrix of [0, 1, …… x] -> this will map to 1s (for antenna elements to be turned off) and 0s (for active antenna elements); if antMask bits exceed the total number of antenna elements, the remaining bits are set to zero so that the O-DU ignores these additional bits |||+--rox decimal64 / / Number of TRx

[0249] / / Report on the energy savings achievable for each TRx control antenna configuration

[0250] / / Option #1

[0251] ||+--ro achievable-energy-saving-range decimal64 / / List containing the energy savings values calculated for all TRx control configurations under different environmental conditions (based on the power consumption for each configuration); this information will be shared by the O-RU vendor as they are design specific / / Option #2

[0252] ||+--ro achievable-energy-saving-trx-control decimal64 / / List containing the best possible energy savings achievable for all supported configurations

[0253] / / Report on the transition time for each TRx control antenna configuration

[0254] ||+--ro transition-time decimal64 / / List containing the transition times achievable for all supported configurations according to environmental conditions and based on the number of TRx channel on / off; in symbols, time slots, milliseconds, seconds, minutes, hours / / Notification to ensure a transition from one TRx control antenna configuration to another

[0255] ||+---n trx-control-configuration-state-change / / Notification to confirm a successful transition from one configuration to another or to the baseline (change in the active state of the O-RU) so that the O-DU can schedule data according to the current configuration.

[0256] / / Data Layer / Spatial Stream Control

[0257] |+--ro max-no-of-spatial-streams-per-trx-control-configuration unint32 / / Limits the number of spatial streams / data layers per TRx control configuration

[0258] ||+--ro achievable-energy-saving-spatial-streams-control decimal64 / / Energy savings achieved through data layer / spatial stream control over the TRx control configuration

[0259] Figure 8 The flowchart of M-plane / C-plane message passing between the O-RU and the O-DU in the use case of TRx control is illustrated. Refer to Figure 8 , in operation 1, the O-RU provides the M-plane message passing parameters (i.e., Yang model parameters) "antMask" and "antLayerMask" to the O-DU based on the TRx control configuration supported by the O-RU and / or the antenna model (i.e., the configuration ability information can include the TRx control configuration and / or the array model).

[0260] In operation 2, the O-RU provides the energy savings achievable for each configuration (i.e., array configuration, such as TRx control configuration, antenna model, etc.) to the O-DU.

[0261] In operation 3, the O-RU provides the transition time for switching from one configuration (i.e., array configuration, such as TRx control configuration, antenna model, etc.) to another configuration or rolling back to the baseline configuration to the O-DU.

[0262] Generally, the above operations 1 to 3 are the O-RU capability reports to the O-DU (i.e., the O-DU receives the configuration ability information of the O-RU).

[0263] In operation 4, the O-DU updates the number of bits (x) to represent the parameter "antMask" (e.g., if the O-RU reports 64TRx (baseline configuration), the value of the parameter antMask is [5:0]. In addition, the O-DU stores the number of TRx configurations supported by the O-RU, its transition time, and the approximate energy savings for each configuration reported by the O-Ru in operations 1 to 3. In an example embodiment, referring to the bit mask of the antenna array, the total number of TRx (antennas) can refer to the parameter with values [0,1,2,3,4,5,6,7,……x]. The parameter referring to the baseline antenna configuration can have the value [0,0,0,0,0,……x], where the '0' value represents an active element and the '1' value represents a deactivated element (i.e., an element to be turned off). In addition, the parameter related to the TRx control configuration can have the value [1,1,1,1,1,0,0,0,0,0,……x], where the '0' value represents an active element and the '1' value represents a deactivated element (i.e., an element to be turned off).

[0264] In operation 5, based on a high-layer network function request, the O-DU activates a specific antenna configuration for a determined or undefined duration.

[0265] In operation 6, the O-RU configures the TRx corresponding to the antMask bits. For this, the TRx elements are assigned '0' to turn off / remain inactive / enter the sleep state and '1' to turn on / remain active with the associated circuits or components (e.g., RF components such as RF transceivers and RF channels (PA / LNA, etc.), digital components, baseband components, etc.). In addition, according to an example embodiment, the O-RU can wait for messages and / or commands via the C-plane or M-plane to take further actions.

[0266] In operation 7, the O-RU provides an O-RU transmission notification to the O-DU to confirm the success / failure of transitioning from one TRx control configuration to another or rolling back to the baseline configuration (i.e., reporting that the array configuration has changed from a first array configuration to a second array configuration and vice versa).

[0267] In operation 8, if a failure occurs during the configuration change, the O-DU retries or rolls back to the working configuration (i.e., the current configuration) or takes appropriate actions (e.g., reporting to the high-layer network function and / or initiating a fail-safe process).

[0268] In operation 9, the O-RU reports the power consumption using the performance counter "epe-stats".

[0269] In operation 10, the O-DU monitors the power consumption of both the baseline configuration and the TRx control antenna configuration. In addition, the O-DU forwards the power consumption data to the high-layer network function or calculates the energy savings for each configuration for future reference.

[0270] In operation 11, after the network usage becomes normal, the O-DU sends an ST4 message with all-zero antMask to bring back the baseline antenna configuration.

[0271] In operation 12, the O-RU sends a notification to confirm the successful transition to the baseline antenna configuration.

[0272] As Figure 7 and Figure 8 shown. The dynamic antenna array reconfiguration (e.g., dynamic changes in the antenna array configuration, such as switching from one antenna array model to another (i.e., muting (e.g., turning off) parts of the antenna array (i.e., antenna elements) and their corresponding RF transceiver chains)) has the advantage that the ES method can be implemented with maximum efficiency due to the exchange of knowledge of the proprietary internal architecture (e.g., O-RU read-only (proprietary) parameters based on the above antenna array capability information).

[0273] Figure 9 Illustrated is an M-plane messaging method according to an embodiment, which includes at least one Yang model for the reporting of capabilities for the sleep mode (e.g., advanced sleep mode) and associated parameters. Referring Figure 9 to, the O-RU reports its ability information for implementing the sleep mode to the O-DU based on the Yang model for the reporting of capabilities for the sleep mode. Based on the sleep mode, the parameters and requirements of the O-RU are different. The O-DU uses the ability information to apply the supported antenna array configuration (i.e., apply the supported antenna array configuration for the corresponding sleep mode).

[0274] The sleep mode can be defined as shown in the following table.

[0275]

[0276]

[0277] Referring to the above table, the slot number calculation takes into account 15KHz SCS.

[0278] Regarding the sleep mode (e.g., advanced sleep mode), the advanced sleep mode with a minimum sleep duration can be activated and deactivated, and the minimum duration for each sleep mode can be exchanged between the O-RU and the O-DU.

[0279] Regarding the sleep mode, the energy savings achieved can be reported by the O-RU or monitored by the O-DU.

[0280] In addition, for the sleep mode with undefined sleep (SM4), the wake-up time is provided by the O-RU. Sleep mode #4 (SM4, undefined time) is achieved by setting "numSlots" and "sleepDepth" to zero, and the O-DU defines the sleep duration.

[0281] In addition, for the sleep mode with undefined sleep (SM4), a notification for wake-up confirmation can be sent by the O-RU.

[0282] Based on the wake-up time notified and / or confirmed by the O-RU, the O-DU defines the wake-up time of the sleep mode with undefined sleep (SM4).

[0283] In addition, for the sleep mode with undefined sleep (SM4), the O-DU can provide a notification of the CU plane active or inactive state to ensure that the CU plane is active after the sleep duration expires.

[0284] According to another exemplary embodiment of the use case RF channel reconfiguration (i.e., RF channel off / on), the sub-use case can be defined as dormant sleep. For this sub-use case, the O-RU receives, via management plane (M-plane) messaging, the antenna array configuration supported by the O-RU from the O-Du, where in addition to other commands for activating and deactivating the O-RU, the supported antenna array configuration can include at least one of the following items: a command for the O-DU to set the energy saving enable to "true" using the "o-ran.hardware.yang" module, a value of "sleep" or "inactive" sent by the O-Du to the O-RU to put the carrier into sleep or deactivate <rpc> <edit-config>The command of <[tr]x-array-carrier::ACTIVE>. Then, the O-RU changes [tr]x-array-carrier::STATE to DISABLED via BUSY. One command is that the O-DU uses the appropriate RPC (i.e., <edit-config>And <delete-config>To deconfigure or delete the (multiple) carriers in the O-RU, or the O-RU can perform this operation by its internal logic during a long sleep (e.g., this command can provide more energy savings as the relevant circuits can be turned off). One command is that if all carriers are deleted / deconfigured during a dormant (long / deep) sleep, the C-plane, U-plane, S-plane, and M-plane circuits are turned off. One command is that the O-DU can turn off the C-plane, U-plane, S-plane, and M-plane circuits by sending an appropriate command / rpc. One command is that the O-RU itself and its internal logic can turn off the C-plane, U-plane, S-plane, and M-plane circuits. One command is to turn off the M-plane (Netconf supervision and monitoring) and the CU-plane monitoring circuit (e.g., in the case of long-term energy savings, the shutdown command for the monitoring circuit can be applied on top of the energy-saving use cases based on TRx control and advanced sleep modes). One command is that the O-RU sends an RPC reply to the O-DU to indicate the correct reception of the above RPC by sending "ok".

[0285] In an example embodiment, the Yang model for the capability report of the CU plane circuit active state (waking up from sleep) can have an o-ran-module-cap.yang structure that includes the following parameters.

[0286] |+--ro energy-saving-by-transmission-blanks boolean

[0287] |+--ro energy-saving-by-trx-control boolean / / TRx control - various antenna configurations for energy savings

[0288] |+--ro energy-saving-by-advanced-sleep-modes boolean

[0289] ||+--ro advanced-sleep-modes enum

[0290] ||+--ro micro-sleep-mode-supported?Boolean / / The O-DU reads this response ("yes" or "no") and knows whether the O-RU supports micro-sleep - Option #1

[0291] ||+---n micro-sleep-mode-supported / / Notification to indicate whether the micro-sleep mode is supported - Option #2

[0292] |+--ro CU plane - active - state enum / / This ability to indicate that the CU plane circuit is in a wake - up and active state to receive messages from the O - DU. For example, during the sleep mode, the CU plane circuit sometimes shuts down and wakes up. According to the current notification framework, the O - RU only reports the operator activity state to the O - DU. It is necessary to notify the O - DU in advance that the CU plane has woken up from sleep and is in an active state so that the O - DU can start scheduling CU plane packets.

[0293] |+--ro eaxcid - grouping - capabilities

[0294] {o - ran - module - cap:EAXC - ID - GROUP - SUPPORTED}?

[0295] In an example embodiment, the Yang model for the capabilities report for the supported advanced sleep mode and associated parameters (e.g., the advanced sleep mode) may have an o - ran - uplane - conf.yang structure that includes the following parameters.

[0296] o - ran - uplane - conf.yang module

[0297] The format of the user plane configuration module is as follows

[0298] |+--rw tx - array - carrier -> / user - plane - configuration / tx - array - carriers / name

[0299] / / Advanced sleep mode

[0300] +--ro advanced - sleep - modes - types

[0301] |+--rosleep - mode#0:SM0string

[0302] ||+--ro sleep - duration:tsleep decimal64 / uint16 / / Sleep duration range (Tsleep)=sign to Tslot, where Tslot is the time slot time in microseconds

[0303] |||+--ro minimum - sleep - duration decimal / uint16 / / Symbol time

[0304] ||+--ro achievable-energy-saving decimal64 / / Energy saving achievable based on O-RU design, sleep mode, and environmental conditions

[0305] |+--ro sleep-mode#1:SM1 string

[0306] ||+--ro sleep-duration:tsleep decimal / uint16 / / Sleep duration range (Tsleep) = Tslot to 10 ms

[0307] |||+--ro minimum-sleep-duration decimal / uint16 / / Tslot – time slot time (microseconds)

[0308] ||+--ro achievable-energy-saving decimal64 / / Energy saving achievable based on O-RU design, sleep mode, and environmental conditions

[0309] |+--ro sleep-mode#2:SM2 string

[0310] ||+--ro sleep-duration:tsleep decimal / uint16 / / Sleep duration range (Tsleep) = 10 ms to 100 ms

[0311] |||+--ro minimum-sleep-duration decimal / uint16 / / 1 radio frame (10 ms)

[0312] ||+--ro achievable-energy-saving decimal64 / / Energy saving achievable based on O-RU design, sleep mode, and environmental conditions

[0313] |+--ro sleep-mode#3:SM3 string

[0314] ||+--ro sleep-duration:tsleep decimal / uint16 / / Sleep duration range (Tsleep) = 100 ms to 1 minute

[0315] |||+--ro minimum-sleep-duration decimal / uint16 / / 100 ms

[0316] ||+--ro achievable-energy-saving decimal64 / / Energy saving achievable based on O-RU design, sleep mode, and environmental conditions

[0317] |+--ro sleep-mode#4:SM4 string

[0318] ||+--ro sleep-duration:tsleep decimal / uint16 / / Sleep duration range (Tsleep) = undefined time (to be defined by O-DU)

[0319] |||+--ro minimum-sleep-duration decimal / uint16 / / 1 minute

[0320] ||+--ro wake-up-time decimal64 / / Wake-up time range based on O-RU design, sleep mode duration, and environmental conditions

[0321] ||+--ro achievable-energy-saving decimal64 / / Energy saving achievable based on O-RU design, sleep mode, and environmental conditions

[0322] |+--rw low-level-tx-endpoint-> / user-plane-configuration / low-level-tx-endpoints / name

[0323] According to embodiments of the advanced sleep mode (ASM) with a short-duration (C-plane-based) sleep mode and the sleep mode with a long-duration (M-plane-based) sleep mode, the wake-up delay (i.e., wake-up time or time to enter the sleep state) of the ASM and the wake-up delay of the TRx control method can be different and do not interfere with each other (e.g., hinder).

[0324] In addition, the common capability parameters of both the TRx control method and the sleep mode (e.g., advanced sleep mode) for which the O-RU configuration capability information is to be reported to the O-DU via the M-plane can include the C-plane ST8 "ready" message and sleep duration extension (e.g., in the case of defined sleep, if the O-DU needs to extend the sleep mode, it sends a sleep extension command before the start of the wake-up time). If the CU-plane remains active, the extension command can be based on the C-plane for a shorter sleep duration. If the CU-plane is closed, the extension command can be based on the M-plane for a longer sleep duration.

[0325] In addition, the common capability parameters for both the TRx control method and the sleep mode (e.g., advanced sleep mode) in which the O-RU configuration capability information is to be reported to the O-DU via the M-plane can include the emergency wake-up of the O-RU from sleep. This capability can 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 the sleep mode, it sends a sleep mode interruption command. If the CU-plane remains active, the emergency wake-up command can be based on the C-plane for a shorter sleep duration (defined or undefined). If the CU-plane is closed, the emergency wake-up command can be based on the M-plane for a longer sleep duration (defined or undefined).

[0326] According to an example embodiment, o-ran-module-cap.yang and other yang models for CU-plane status reporting (e.g., for the O-RU capabilities to implement defined and undefined sleep modes). o-ran-module-cap.yang includes information for enabling the CU plane circuitry to be turned off to achieve additional energy savings. This information can include the name identifier and status identifier of the rx-array-carrier, as well as the name identifier, action identifier, and status of the CU-plane to report the user plane configuration. Based on the above information, the O-DU can turn on or wake up the CU-plane circuitry via the M-plane. According to an example embodiment, a notification is required to indicate whether the CU-plane becomes active (wakes up from sleep), which can be defined in o-ran-uplane.yang respectively.

[0327] In one example embodiment, the Yang model for the capability report for the notification to indicate that the CU plane is active from sleep can have an o-ran-uplane-conf.yang structure, which includes the following parameters.

[0328] The format of the user plane configuration module is as follows

[0329] +---n rx-array-carriers-state-change

[0330] +--ro rx-array-carriers*[name]

[0331] +--ro name-> / user-plane-configuration / rx-array-carriers / name

[0332] +--ro state? -> / user-plane-configuration / rx-array-carriers / state

[0333] +---n cu-plane-state-change

[0334] |+--ro cu-plane[name]

[0335] |+--ro state? -> / user-plane-configuration / CU-plane / state; The available states are active, sleep, and inactive / disabled

[0336] Figure 10 The flowchart of M-plane / C-plane message passing between the O-RU and the O-DU for the use case of the sleep mode is illustrated. Refer to Figure 10 , in operation 1, the O-RU provides the O-DU with a list of supported sleep modes (e.g., advanced sleep mode) and their minimum sleep durations (i.e., the configuration capability information reported by the O-RU to the O-RU via M-plane message passing can include a list of supported sleep modes (e.g., advanced sleep mode) and their minimum sleep durations.

[0337] In operation 2, the O-RU provides the O-DU with the energy savings achievable for each sleep mode (e.g., each sleep mode provided in operation 1 can refer to an array configuration).

[0338] In operation 3, for the case of a sleep mode with undefined sleep (i.e., for SM4), the O-RU provides the O-DU with the wake-up time from the sleep state to the active state of undefined sleep (i.e., for sleep mode SM4).

[0339] Generally, the above operations 1 to 3 refer to the O-RU capability report to the O-DU (i.e., the O-DU receives the configuration capability information of the O-RU).

[0340] In operation 4, the O-DU maps the reported sleep mode to the C-plane parameter "sleepMode". In addition, the O-DU maps the reported sleep duration and sleep mode (i.e., except for the indeterminate / undefined sleep mode) to the C-plane parameters "sleepDur" and "Mul" respectively. The parameter "Mul" is used to flexibly adjust the sleep duration within the range of specific sleep modes supported by the O-RU. The C-plane parameters "sleepMode", "sleepDur", and "Mul" can be defined in the fields related to the advanced sleep mode in the ST4 CMD TYPE message.

[0341] In operation 5, the O-DU sends an ST4 message ("sleepMode" and "Tsleep") to the O-RU and activates sleep for a specific duration (based on the adopted sleep mode). The scheduling of the ST4 message ("sleepMode" and "Tsleep") is based on a high-layer network function request, or the O-DU itself decides to activate the sleep mode.

[0342] In operation 6, the O-RU receives and processes the sleep command via an ST4 message with a determined duration. In one exemplary embodiment, for a sleep mode with an indefinite sleep, the O-DU may send a sleep mode activation request to the O-RU via an ST4 (C-plane) message or via M-plane message passing (i.e., carrier deactivation).

[0343] In operation 7, the O-RU provides a notification to the O-DU to confirm the success / failure of the sleep mode activation.

[0344] In operation 8, if a failure occurs during the sleep mode activation, the O-DU retries the sleep mode activation or takes appropriate actions (e.g., reporting to a high-layer network function, initiating a fail-safe process, etc.). In an exemplary embodiment, depending on the actions of the O-DU in case of a failure, the O-RU may respond in operation 8 to the actions requested by the O-DU.

[0345] In operation 9, based on the O-DU subscribing to the "epe-stats" counter of the O-RU, the O-RU provides an O-RU report of power consumption to the O-DU via the M-plane using the performance counter "epe-stats".

[0346] In operation 10, the O-DU monitors the power consumption during each sleep mode / sleep duration. In addition, the O-DU forwards the power consumption data to a high layer, or calculates the energy savings for each sleep mode for future reference.

[0347] In operation 11, the O-DU sends a wake-up command to the O-RU to deactivate the sleep mode.

[0348] In operation 12, the O-RU sends a notification to confirm the successful deactivation of the sleep mode and becomes active. Generally, this notification refers to a notification for reporting a change in array configuration from a first array configuration to a second array configuration and vice versa.

[0349] Figure 11 The figure illustrates a method for implementing a TRx control process via at least one section type 4 message in the C-plane according to an embodiment.

[0350] Reference Figure 11 , in step 1101, the O-DU determines the antenna array configuration supported by the O-RU based on the configuration capability information from the O-RU and the request for reconfiguring the antenna array from the higher-layer network function.

[0351] In step 1102, the O-DU applies the supported antenna array configuration via C-plane message passing including section type 4 messages.

[0352] For example, the O-DU instructs the O-RU not to use certain resource blocks or symbols in the C-plane section type message (e.g., ST 0 or ST 4 message) (e.g., the O-DU can create idle periods, guard periods, etc.). In addition, the O-DU can utilize non-associated (i.e., reserved or not yet defined) U-plane messages (i.e., at least one of C-plane section type 0 or section type 4 and at least one of section extension 10, 11, 16, 19, etc. messages) containing IQ samples (data) of the section types (ST 0, ST 4) as described above.

[0353] In any case, the purpose of using the resource blocks or symbols of the existing but unused C-plane section type messages is to notify (apply to) the O-RU by the O-DU that the RF signal transmission (e.g., radiation of the RF signal) can be stopped within the specified idle interval (e.g., power can be saved due to stopping transmission within the specified idle interval, or the idle interval can be provided for calibration).

[0354] For this purpose, the O-DU sends at least one message via the C-plane, which includes at least one section type 0 message and at least one of section extension (SE) 7 message and / or section type (ST) 4 message and SE 10, 11, 16, 19, etc. messages.

[0355] In an example embodiment, according to the C-plane message passing between the O-DU and the O-RU, although the O-RU can report the supported antenna array model to the O-DU via the M-plane as shown in step 402 of Figure 4 , the O-DU applies the (new) antenna array model implemented by the O-RU. For this purpose, the O-DU uses as shown in Figure 4 Existing specification (message passing protocol) of the CUS plane shown in step 405. In this case, the O-DU can apply the (new) antenna array model to be implemented by the O-RU for deactivating (e.g., masking, blanking, muting, etc.) antenna elements (e.g., the O-DU can use the SE 7 message to mask the extended antenna carrier (eAxC), where the mask can be part of the eAxC identifier (ID) specified by the ST 0 message) according to the existing specification (message passing protocol) of CUS plane message passing. For example, the eAxC can include data of a single antenna (or spatial stream) of a single carrier in a single sector.

[0356] In another exemplary embodiment, the O-DU can use the C-plane ST 4 message and at least one of the SE 10, 11, 16, and 19 messages anywhere as needed (e.g., during run time) to apply the (new) antenna array model to the O-RU. In particular, the O-DU can use the ST 4 command type (ST4CmdType) to apply a configuration set (i.e., a specific antenna model / configuration).

[0357] In one exemplary embodiment, according to the C-plane ST 4 message, the O-DU applies single / multiple endpoints by adopting a common section type 4 header followed by single / multiple section type 4 commands (e.g., ST4CmdType), where each section type 4 command is used to specify a configuration command applied to a specific time slot, using the specified time slot-level configuration.

[0358] In another exemplary embodiment, according to the C-plane ST 4 message and section extension (SE) 10, the O-DU uses the section extension 10 to apply section types 1, 3, and 5. To this end, the O-DU utilizes the C-plane partial information of multiple ports (i.e., layers or Tx / Rx paths), which can be similar except for the beam identifier (ID) or user entity (UE) ID. As a result, when multiple ports share common partial information within the O-RU, the O-DU sends the C-plane partial via the corresponding ports (RU_ports), and these ports are merged into one C-plane partial via the representative port using the section extension 10. On the side (O-RU path), the M-plane pre-configures the representative port by grouping the ports to be merged to represent the ports. For example, in the case of C-plane message passing using the section extension (SE) 10 of ST4, when sending C-plane and U-plane messages to the O-RU, the O-DU can use a unique eAxC_ID to address each layer or spatial stream. In addition, SE 10 can be used together with the "representative eAxC_ID" (configured via the M-plane) to reduce the C-plane overhead of sending multiple messages by sending a single C-plane message.

[0359] In another exemplary embodiment, based on the C-plane ST 4 message and the segmentation extension (SE) 11, the O-DU applies flexible beamforming weights to the O-RU using the segmentation extension (PE) 11. The SE 11 enables the O-DU to provide different beamforming weights for different physical resource blocks (PRBs) within a segment to facilitate (e.g., zero-forcing precoding). To this end, the O-DU provides the number of bundled PRBs (numBundPrb) parameter for each beamforming weight, which notifies the O-RU of how many PRBs are bundled together and share the corresponding beamforming weight.

[0360] For example, to enable the O-DU to use the SE 11 as described above, an optional "little endian byte order" can be applied to the beamforming.weight.in-phase.value / beamforming.weight.q-phase.value (bfwI / bfwQ) fields (i.e., the I / Q beamforming weight fields). In this case, the C-plane ST 4 message and the section extension 11 are applied only to C-plane section types 1 and 3, respectively.

[0361] In another exemplary embodiment, based on the C-plane ST 4 message and the segmentation extension (SE) 16, the O-DU applies the antenna mapping in UL beamforming based on UE channel information to the O-RU. The segmentation extension (PE) 16 can also be applied to the C-plane ST5 message. The section extension (SE) 16 includes a bit mask for each RX endpoint to indicate the antennas to be pre-combined into the RX endpoint (i.e., eAxC_ID). According to this exemplary embodiment, the O-DU can use the section extension (SE) 16 together 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.

[0362] In another exemplary embodiment, based on the C-plane ST 4 message and the section extension (SE) 19, the O-DU applies compact beamforming information for multiple antenna ports (i.e., in the context of this section extension 19, 'port' refers to a logical antenna port) to control the TRx. The section extension 19 can also be applied to the C-plane section types (ST) 1 and 3. According to this exemplary embodiment, the O-DU uses the SE 19 to send compact beamforming information for multiple antenna ports. For example, "little endian byteorder" can be applied to the bfwI / bfwQ fields in the SE 19. Therefore, considering a large number of channel state information reference signal (CSI-RS) ports and multiple channel state information (CSI) resource sets, the use of the SE 19 is beneficial for channel state information reference signal (CSI-RS) channel messaging.

[0363] In addition, in an alternative exemplary embodiment, based on the C-plane ST 4 message, the O-DU can implement an application for maintaining the antenna array configuration, which can be achieved through the numslots command to achieve long-term energy saving. According to this embodiment, the O-DU, using the C-plane ST 4 message, applies the command to multiple endpoints / eAXC IDs (i.e., the array for TD beamforming). For this purpose, the numslots command is used in the C-plane ST4 message to specify the number of time slots for which the operation (i.e., power saving mode) is to be performed.

[0364] Figure 12 Illustrated is a method for implementing a TRx control process through a section type 0 message in the C-plane according to an embodiment.

[0365] Refer to Figure 12 , in step 1201, the O-DU determines the antenna array configuration supported by the O-RU based on the configuration capability information from the O-RU and the request for reconfiguring the antenna array from a higher-layer network function.

[0366] In step 1202, the O-DU applies the supported antenna array configuration via C-plane messaging, which includes at least one of the section type (ST) 0 message and the section extension (SE) 7 message (e.g., the command field in the SE 10 and the ST 0 message, where the ST 0 message specifies the transceiver (TRx) control parameters for reconfiguring the antenna array and the energy saving duration to be applied to the O-RU via the C-plane).

[0367] According to an example embodiment, the O-DU can use a C-plane ST 0 message to specify a set of antenna elements to be muted (i.e., apply a (new) antenna array model to be implemented by the O-RU). To this end, the O-DU can use blocks or symbols not used in existing uplink (UL) and downlink (DL) C-plane ST 0 messages to transmit (apply) the (new) antenna array model(s) to be implemented by the O-RU (e.g., specify a set of antenna elements to be muted). The advantage of using a C-plane ST 0 message is that, compared with other C-plane messages (e.g., at least one of ST 4 and SE 10, 11, 16, and 19 messages), the antenna elements of the antenna array can be muted for a longer duration because the C-plane ST0 message can be used to dynamically update the antenna array configuration (i.e., dynamically update / generate at least one antenna model, including (multiple) beam weights and / or a necessary antenna calibration data set for at least one of the antenna models).

[0368] Therefore, by adopting a C-plane ST 0 message, the specified set of antenna elements can be muted for a longer time to achieve maximum energy saving.

[0369] In an example embodiment, the O-DU can indicate to the O-RU that certain resource blocks or symbols will not be used in the C-plane section type message (e.g., ST 0 or ST 4 message) (e.g., the O-DU can create an idle period, a guard period, etc.). In addition, the O-DU can utilize a non-associated (i.e., reserved or not yet defined) U-plane message containing IQ samples (data) of the section type (ST 0, ST 4) as described above (i.e., at least one of C-plane section type 0 or section type 4 and at least one of section extensions 10, 11, 16, 19, etc. messages).

[0370] In any case, the purpose of using the resource blocks or symbols of the existing but unused C-plane section type message is to notify (apply to) the O-RU that RF signal transmission (e.g., RF signal radiation of certain antenna elements in the antenna array) can be stopped during the specified idle interval (e.g., to save power or provide a calibration interval).

[0371] To this end, according to an example embodiment, the O-DU can send at least one message via the C-plane, the message including at least one section type 0 message and section extensions (SE) 7, 10, 11, 16, 19, etc. messages.

[0372] In an example embodiment, the O-DU can apply a new (selected, generated, etc.) antenna array model by using section extension (SE) 7 messages and section type 0 messages, where it is used to mask / blank / mute the antenna elements with existing specifications in the existing specification (e.g., SE7, mask the eAXCID part specified by the ST 0 message).

[0373] In addition, in another exemplary embodiment, to mute the antenna elements for a longer duration, a C-plane section type 0 message can be used to specify a longer duration of set element mute. The section type 0 message is used to specify blocks or symbols not used in the UL and DL.

[0374] The O-DU can indicate to the O-RU that certain resource blocks or symbols will not be used (idle periods, guard periods). Similarly, there is no associated U-plane message containing IQ data of this section type. The purpose is to inform the O-RU that the transmission can stop within the specified idle interval (e.g., for energy saving or providing a calibration interval). For this, C-plane messaging can specify that the antenna elements are muted for a longer time to save energy by adopting the section type 0 message.

[0375] According to an exemplary embodiment, an antenna element can be masked or muted by not allocating a beam weight or beam '0' to the corresponding antenna element via the corresponding C-plane message. This C-plane messaging can be implemented symbol-by-symbol or time-slot-by-time-slot or PRB-by-PRB (i.e., for a shorter-duration energy saving mode such as the TDD mode, where the Tx chain is turned off during the UL).

[0376] In addition, by sharing the duration with C-plane messaging, the masking or muting of C-plane messaging can also be extended to a longer-duration energy saving mode.

[0377] In an exemplary embodiment, the O-DU can apply an antenna array configuration, such as for a TRx control method or a sleep mode, by using the existing specifications (messaging protocol) of the CU S-plane.

[0378] In addition, the O-DU can use the C-plane ST 0 message and SE 7 to modify (apply) the number of spatial streams while activating the corresponding antenna model / TRx configuration using the eAXC (identification) ID mask. For this, the eAxC_ID subfield includes an eAxC identifier (eAxC_ID), which includes a band and sector identifier (BandSector_ID), a component carrier identifier (CC_ID), a spatial stream identifier (RU_Port_ID), and a distributed unit identifier (DU_Port_ID), where the RU_Port_ID specifies logical streams such as data layers or spatial streams, and logical streams such as individual digital techniques (such as PRACH) or signaling channels that require special antenna allocation, such as sounding reference signals (SRS).

[0379] Figure 13 An embodiment of a sleep mode of TRX CONTROL according to a section type 4 command type (ST4CmdType) is illustrated. Refer to Figure 13 , the sleep mode has different sleep depths.

[0380] Reference Figure 13 , the TRX CONTROL command type is consistent with the section type 4 command type (ST4CmdType), where the command common header format includes an 8-bit field (i.e., an octet field). The command common header format includes various headers, and each header includes one or more header fields (i.e., header octets).

[0381] According to the TRX CONTROL command type configuration, the first header field is occupied by the transmission header. The transmission header refers to an 8-byte sequence of the first octet (i.e., the number of bytes from octet 1 to octet 8 is 8).

[0382] The second header field is occupied by the common section type 4 header. The common section type 4 header refers to an 8-byte sequence of the 9th octet (i.e., the number of bytes from octet 9 to octet 16 is 8).

[0383] The third header field is occupied by the section type 4 common part of the command header. The section type 4 common part of the command header refers to an 8-byte sequence of the 17th octet (i.e., the number of bytes from octet 17 to octet 24 is 8).

[0384] The fourth header field is occupied by the multi-command section type 4 header, which refers to a 1-byte sequence of the 25th octet (i.e., the number of bytes of octet 25 is 1).

[0385] The multi-command section type 4 header includes a direction identifier bothDir at the 0th bit position of the most significant msb and a close field at the 1st bit position. In addition, the 2nd to 5th bit positions of the multi-command section type 4 header refer to the identifier of the sleep mode type sleepDurIndex field (i.e., [sleepDurIndex3:0]). The 6th bit position and the least significant bit (i.e., the 7th bit position) refer to the sleep depth of the advanced sleep mode of the 25th octet (i.e., sleepDepth[1:0]) (i.e., the number of bytes of octet 25 is 1).

[0386] The fifth header field may include a reserved field and a 1-byte sequence of the 26th octet (i.e., the number of bytes of octet 26 is 1).

[0387] The 1-byte sequence of the 26th octet in the fifth header field may be occupied by the log2maskbits header (i.e., log2maskbit[3:0]). The log2maskbits header command header refers to a 1-byte sequence of the 26th octet (i.e., the number of bytes of octet 26 is 1).

[0388] The sixth header field is occupied by the antLayerMask command header of the antenna layer mask (i.e., antLayerMask[15:0]* - reserved when cmdScape ≠ ARRAY-COMMAND). The antLayerMask header refers to a 2-byte (16-bit) sequence in the 27th octet (i.e., the number of bytes in octet 27 is 1).

[0389] The seventh header field is occupied by the Antenna Mask antMask command header (i.e., antMask[x:0] - present only when cmdScape = ARRAY-command). The antMask header refers to an 8-byte (64-bit) sequence in the 29th octet (i.e., the number of bytes is variable (e.g., a 2-byte field from octet 28 to octet 29)).

[0390] According to an example embodiment, the TRx control process for reconfiguring an antenna array may include a TRx management configuration identified by a corresponding unique configuration identifier or name. The antenna array model of the TRx control configuration includes at least one antenna mask (antMask), where the antenna mask bit combination may be limited to the supported TRx control configurations, where the antenna mask bits identify '0' for the antenna elements to be turned off and '1' for the active elements of the antenna array. In addition, in addition to the mask bits for at least one antenna mask (antMask), the TRx control configuration also includes antenna layer mask bits for creating at least one antenna layer mask (antLayerMask).

[0391] According to an example embodiment, the supported TRx control configurations may include a transition time (i.e., a wake-up time different from ASM), which defines the minimum or guaranteed time required to switch from a baseline configuration to a specific configuration (i.e., switching a baseline 64TRx antenna array to another antenna mask configuration, such as a 32TRx_antenna array model). The transition time associated with each configuration change of the supported TRx control configuration and as a function of the subcarrier spacing, for example, for 15KHz, one time slot is 1 millisecond, for 30KHz, one time slot is 0.5 millisecond or 500 microseconds, and so on.

[0392] According to an example embodiment, the TRx control process may include controlling to turn on / off the entire RF transceiver chain and / or the radio frequency front end (RFFE) of the radio frequency (RF) processing unit related to some RF channels / antenna elements.

[0393] In addition, according to another example embodiment, the TRx control process may include controlling to turn on / off components, circuits, IPs, cores, computing engines, and the O-RAN front-end processing unit (i.e., the physical components of the O-RU) of the digital baseband.

[0394] According to embodiments of an advanced sleep mode (ASM) having a short-duration (C-plane-based) sleep mode and a sleep mode having a long-duration (M-plane-based) sleep mode, the wake-up latency (i.e., wake-up time or sleep entry time) of the ASM and the wake-up latency of TRx control can be different and do not interfere with each other (e.g., hinder).

[0395] Figure 14 Illustrated are embodiments of a sleep mode according to a section type 4 command type (ST4CmdType) st4CmdType 'TRX-CONTROL / ADVANCED-SLEEP-MODE'.

[0396] Reference Figure 14 , according to ST4CmdType 'TRX-CONTROL / ADVANCED-SLEEP-MODE' configured according to the TRX CONTROL command type, the first header field is occupied by a transport header. The transport header refers to an 8-byte sequence of the first octet (i.e., 8 bytes from octet 1 to octet 8).

[0397] The second header field is occupied by a common section type 4 header. The common section type 4 header refers to an 8-byte sequence of the 9th octet (i.e., 8 bytes from octet 9 to octet 16).

[0398] The third header field is occupied by the section type 4 common part of the command header. The section type 4 common part of the command header refers to an 8-byte sequence of the 17th octet (i.e., 8 bytes from octet 17 to octet 25).

[0399] The fourth header field is occupied by a multi-command section type 4 header that refers to a 3-byte sequence of the 25th octet (i.e., 3 bytes from octet 25 to octet 27).

[0400] The multi-command section type 4 header includes a direction identifier bothDir at the highest significant msb 0 bit position, followed by an OnOff field, a 1-bit symbolMask[0:1] field, a 1-bit advanced sleep mode flag asmflag[0:1], a 16-bit eAxCmask[0:15] field, and a 1-byte sleepDepth[1:0] of the 25th octet (i.e., 3 bytes from octet 25 to octet 27).

[0401] The fifth header field is occupied by a multi-command section type 4 header that refers to a 4-byte sequence of the 28th octet (i.e., 4 bytes from octet 28 to octet 31).

[0402] The multi-command section type 4 header includes the extnumslots[0:15] field, the symbolMask[0:11] field, and the log2maskbits[3:0] field of the 28th octet (i.e., the number of bytes from octet 28 to octet 31 is 3).

[0403] The sixth header field is occupied by the antenna layer mask antLayerMask command header (i.e., antLayerMask[15:0]* — reserved when cmdScape ≠ ARRAY-command). The antLayerMask header refers to a 2-byte (16-bit) sequence of the 27th octet (i.e., the number of bytes from octet 32 to octet 34 is 2).

[0404] The seventh header field is occupied by the Antenna Mask antMask command header (i.e., antMask[x:0] — only present when cmdScape = ARRAY-command). The antMask header refers to an 8-byte (64-bit) sequence of the 29th octet (i.e., starting from octet 32, the number of bytes is variable).

[0405] According to Figure 14 the st4CmdType ‘TRX-CONTROL / ADVANCED-SLEEP-MODE’ in , the use of the TRX-CONTROL command (undefined sleep duration) may include an operation where the O-DU reads the O-RU sleep capabilities, including the L, M, and N values of the supported sleep levels. For this purpose, when the O-DU decides to deactivate the antenna elements / layers, the O-DU may issue a TRX-CONTROL command. The first TRX-CONTROL command includes the field values numSlots = 0, sleepDurIndex = 0xF, sleepDepth = 0. Although there is no guaranteed sleep duration, the antenna elements can be activated in any future time slot without a minimum sleep duration. The second TRX-CONTROL command includes the field values numslots = 0, sleepDurIndex = 0xF, sleepDepth ≠ 0. In this case, the O-RU may enter the command sleep mode and the O-DU will not activate the antenna elements / layers after L, M, or N time slots (as specified by the new mask). For this purpose, when the O-RU receives a new (i.e., changed) TRX-CONTROL command, it may activate the new mask for exactly L, M, or N time slots after receiving the command. This rule applies even if the new mask uses fewer antenna elements than the previous mask. Refer to Figure 3 , this rule enables the response to antenna configuration changes during the transition from one antenna array model to another to take into account the transition time of the antenna configuration change.

[0406] To this end, L, M, and N time slots are respectively defined as the wake-up delays (i.e., transition times) only for sleep modes 1, 2, and 3. However, for undefined sleep, it may not be possible to define the wake-up delay.

[0407] Reference Figure 14 , if TRx control and the advanced sleep mode are executed simultaneously, it is necessary to consider the transition delay wake-up delay (i.e., transition time) that occurs when changing from one TRx control configuration to another (i.e., the antenna configuration change during the transition from one antenna array model to another).

[0408] The definition of the wake-up delay (i.e., transition time) can be used to apply the sleep mode on top of the TRx control. Otherwise, L, M, and N need to be explicitly defined with two values corresponding to the TRx control and the sleep mode.

[0409] In addition, the sleep mode definition can be used to execute the TRx control within defined and undefined durations.

[0410] In addition, in the advanced sleep mode, some components in the component are turned off according to the sleep duration, but in the TRx control, the entire baseband and RF processing chain related to certain antenna elements are turned off. Therefore, the wake-up delay (ASM) and the transition time (TRx control) can be different.

[0411] Figure 15 Illustrates the antenna array selection based on the standard antenna array model according to an embodiment. Reference Figure 15 , the baseline 32T32R standard antenna array includes 8 rows and 12 columns of antenna elements in 8 RF transceivers (RF TRx) of 32T32R. Each of the 8 TRx (i.e., 8 RF TRx) includes (maps) the antenna elements to sub-arrays.

[0412] To this end, each RF transceiver (TRx 1 to TRx 8) in the RF transceiver can be activated or deactivated (i.e., turned off, muted, deactivated, masked, etc.). For example, reference Figure 15 , the O-DU applies the antenna array model parameters according to the first (standard) mode within the 32T32R antenna array (i.e., implements RF channel reconfiguration / antenna array selection).

[0413] In Figure 15 , four patterns are shown in a continuous manner, where the first pattern and the second pattern refer to continuing A1, and the third pattern and the fourth pattern refer to continuing A2.

[0414] The first mode (i.e., the first standard mode) includes 8 TRx, which vertically divide the 32T32R antenna array into 4 active TRx and 4 inactive TRx in a so-called semi-right active configuration.

[0415] The second mode (i.e., the second standard mode) includes 8 TRx configured in a vertical half-loaded configuration, where in a so-called left column active configuration, the 8 TRx form a vertical stripe pattern of active and inactive antenna elements within the 32T32R antenna array.

[0416] The third pattern (i.e., the third standard pattern) can be similar to the first pattern, having 4 active TRx. The 4 active TRx vertically divide the 32T32R antenna array, and in a so-called left semi-active configuration, there is an opposite order division of 4 active and 4 inactive TRx. Thus, the sequence of active and inactive TRx can be reversed.

[0417] The fourth mode (i.e., the fourth standard mode) with 4 active TRx horizontally divides the 32T32R antenna array into 4 active TRx and 4 inactive TRx in a so-called upper half-active configuration. The active-inactive TRx sequence can be reversed to a so-called lower half-active configuration.

[0418] Among multiple predefined antenna array models, the first to fourth standard modes refer to the antenna array models that the O-RU can activate. The first to fourth standard modes can be reported after initializing the O-RU (i.e., antenna configuration capability information including antenna array model parameters)

[0419] Figure 16 Illustrates a method for masking an antenna array based on an antenna array model according to an embodiment. Refer to Figure 16 , when the O-RU is powered on (initialized), the O-RU starts reporting the supported energy-saving modes and hard-coded antenna array models (e.g., multiple predefined antenna array models, antenna array configuration capability information, which can include Figure 9 the standard modes) and other initialization parameters to the O-DU using the M-plane yang model (e.g., urn:o-ran:module-cap:1.0 and an urn:o-ran:hardware:1.0).

[0420] For example, the standard antenna array configuration (i.e., as Figure 16 The antenna pattern shown can be identified by the total number of antenna elements according to the corresponding antenna array configuration (i.e., the antenna array model), the number of elements in the rows and columns of the corresponding antenna array, and the possible energy savings of the corresponding energy savings reported to the O-DU via an M-plane message in a predefined / supported antenna array configuration using the M-plane yang model (e.g., urn:o-ran:module-cap:1.0 and an urn:o-ran:hardware:1.0).

[0421] According to Figure 16 the example embodiment in, for example, according to the antenna array configuration shown on the right, in the first row, 1 to 8 elements are masked (muted). In this case, the number of active elements is 48 dual-polarized elements, and there are 4 TRx out of a total of 96 elements in the right half-active configuration (i.e., the first standard pattern).

[0422] For this purpose, according to the 16T16R array, the elements connected to transceivers TRx 3, 4, 7, and 8 are active (i.e., TRx chains / RF channels 9 to 16 and 25 to 32 are active), and the elements connected to receivers TRx 1, 2, 5, and 6 are muted / inactive (i.e., TRx chains / RF channels 1 to 8 and 17 to 24 are off).

[0423] Figure 17 Illustrated is antenna array selection based on a bitmask method according to another embodiment. Refer to Figure 17 and use at least one bitmask parameter to supplement the configuration and rollback configuration of the antenna array according to the total number of antenna elements according to the corresponding antenna array configuration and the number of elements in the rows and columns of the corresponding antenna array according to Figure 16 .

[0424] In Figure 17 , two patterns are shown in a continuous manner, where the first pattern refers to continuation B1 and the second pattern refers to continuation B2.

[0425] Figure 18 Illustrated is antenna array selection based on a bitmask method according to another embodiment.

[0426] In Figure 18 , two patterns are shown in a continuous manner, where the first pattern refers to continuation C and the second pattern refers to continuation C.

[0427] Refer to Figure 18 and the first pattern with 4 active TRx horizontally divides the 32T32R antenna array into 4 active TRx and 4 inactive TRx in the so-called lower half-active configuration.

[0428] In addition, the second pattern includes 8TRx configured in a vertical half-loading configuration, where in the so-called bottom row active configuration, the 8TRx forms a horizontal stripe pattern of active and inactive antenna elements within a 32T32R antenna array.

[0429] Figure 19 Illustrated is a 64T64R antenna array model selected by using an offset method according to yet another embodiment. Refer to Figure 19 , the antenna configuration ability information of the O-RU includes an antenna array baseline model, which includes 192 antenna elements (i.e., X2W baseline configuration, 12 antenna elements in a row, 8 antenna elements in a column, the element spacing in a row is dx, and the element spacing in a column is dy), where a first offset value and a second offset value (horizontal offset value offset-x and vertical offset value offset-y) are predefined to define multiple antenna array models, which enable the O-RU to activate at least one antenna array model above the baseline antenna array configuration, and the baseline antenna array configuration includes at least one of the 64T64R model (64 transmitter chains; 64 receiver chains), and this model has 192 elements, including 96 dual-polarized elements.

[0430] For example, 96 dual-polarized elements can be arranged in an X2 / 2W configuration into a first 32T32R antenna model (#1) (32 transmitter chains; 32 receiver chains), where there are 12 antenna elements in a row, 4 antenna elements in a column, the element spacing in a row is dx, and the element spacing in a column is dy. The first 32T32R antenna model (#1) in the X2 / 2W configuration includes 48 dual-polarized elements.

[0431] In another example, 96 dual-polarized elements can be arranged in an X2 / 2W configuration into a second 32T32R antenna model (32 transmitter chains; 32 receiver chains) (#2), with 6 elements in a row and 4 elements in a column, the element spacing in a row is 2*dx, and the element spacing in a column is dy (1*dy). The second 32T32R antenna model (#2) in the X2 / 2W configuration includes 48 dual-polarized elements.

[0432] In another example, 96 dual-polarized elements can be arranged in an X2 / 2W configuration into a third 32T32R antenna model (32 transmitter chains; 32 receiver chains) (#3), with 6 elements in a row and 4 elements in a column, the element spacing in a row is 2*dx, and the element spacing in a column is dy (1*dy). The third 32T32R antenna model (#3) in the X2 / 2W configuration includes 48 dual-polarized elements, where the third antenna model (#3) can include 12 elements in a row being single-polarized and 8 elements in a column being single-polarized.

[0433] In another example, the antenna array model over the baseline antenna array configuration may include 72 elements (48 transmitter chains; 48 receiver chains) in a 48T48R antenna model in a 3X2 / 4W configuration. The fourth antenna model includes 144 dual-polarized elements.

[0434] In another example, 96 dual-polarized elements may be arranged in a fifth 32T32R antenna model (32 transmitter chains; 32 receiver chains) in X2 / 2W (#5), with an element spacing of dx between elements in a row and an element spacing of dy between elements in a column. The fifth 32T32R antenna model (#5) in the X2 / 2W configuration includes 48 dual-polarized elements.

[0435] Figure 20 Illustrated is a 32T32R antenna array model to be selected by using an offset method according to yet another embodiment. Refer to Figure 20 , the antenna configuration capability information of the O-RU includes an antenna array baseline model, which includes a 32T32R (32 transmitter chains; 32 receiver chains) baseline configuration with 192 antenna elements, where a first offset value offset-x and a second offset value offset-y are predefined to define a plurality of antenna array models, which enable the O-RU to activate at least one antenna array model over the baseline antenna array configuration.

[0436] For example, based on the 32T32R baseline configuration, the antenna model may include at least one of the following: a 16T16R antenna array baseline model with 96 dual-antenna elements, a 16T16R antenna array baseline model with 96 single-antenna elements, and an 8T8R antenna array baseline model with 48 dual-antenna elements.

[0437] In an example embodiment, 192 elements may be arranged in a first 32T32R antenna model (32 transmitter chains; 32 receiver chains) in an X1 / W configuration, where there are 12 elements in a row and 8 elements in a column, with an element spacing of dx (1*dx) between elements in a row and an element spacing of dy (1*dy) between elements in a column. The second 32T32R antenna model in the X1 / W configuration includes 96 dual-polarized elements.

[0438] In an example embodiment, 96 dual-polarized elements may be arranged in a first 32T32R antenna model (32 transmitter chains; 32 receiver chains) in an X1 / 2W configuration (#1), where there are 12 elements in a row and 8 elements in a column, with an element spacing of 2*dx between elements in a row and an element spacing of dy (1*dy) between elements in a column. The first 32T32R antenna model (#1) in the X1 / 2W configuration includes 48 dual-polarized elements.

[0439] In one example embodiment, 48 dual-polarized elements may be arranged in an X2 / 4W configuration into a second 8T8R antenna model (8 transmitter chains; 8 receiver chains) (#2), with 6 elements in a row and 4 elements in a column, the spacing between elements in a row being dx (1*dx) and the spacing between elements in a column being dy (1*dy). The second 8T8R antenna model (#2) in the X2 / 4W configuration includes 24 dual-polarized elements.

[0440] In an example embodiment, 96 elements may be arranged in an X1 / 2W configuration into a third 16T16R antenna model (16 transmitter chains; 16 receiver chains) (#3), with 12 single elements in a row and 8 single elements in a column, the spacing between elements in a row being 2*dx and the spacing between elements in a column being dy (1*dy). The second 16T16R antenna model (#3) in the X1 / 2W configuration includes 96 single-polarized elements.

[0441] Figure 21 is a diagram of an example environment 2100 in which the systems and / or methods described herein may be implemented. As Figure 21 shown, the environment 2100 may include a user device 2210, a platform 2220, and a network 2130. The devices of the environment 2100 may be interconnected via a wired connection, a wireless connection, or a combination of wired and wireless connections. In an embodiment, any of the functions and operations described above with reference to Figure 1 may be performed by any combination of the elements Figure 21 shown.

[0442] The user device 2210 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information associated with the platform 2220. For example, the user device 2210 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, etc.), a wearable device (e.g., smart glasses or a smart watch), or a similar device. In some implementations, the user device 2210 may receive information from and / or send information to the platform 2220.

[0443] The platform 2220 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information. In some implementations, the platform 2220 may include a cloud server or a group of cloud servers. In some implementations, the platform 2220 may be designed to be modular such that certain software components may be swapped in or out according to specific needs. Thus, the platform 2220 may be easily and / or quickly reconfigured for different uses.

[0444] In some implementations, as shown, platform 2220 may be hosted in a cloud computing environment 2222. It should be noted that although the implementations described herein describe platform 2220 as being hosted in cloud computing environment 2222, in some implementations, platform 2220 may not be cloud-based (i.e., may be implemented outside of a cloud computing environment), or may be partially cloud-based.

[0445] Cloud computing environment 2122 includes the environment that hosts platform 2220. Cloud computing environment 2122 may provide services such as computing, software, data access, storage, etc., which do not require an end user (e.g., user device 2210) to know the physical location and configuration of the (multiple) systems and / or (multiple) devices of platform 2220. As shown, cloud computing environment 2122 may include a set of computing resources 2124 (collectively referred to as computing resources 2124 and individually referred to as computing resource 2124).

[0446] Computing resources 2124 include one or more personal computers, clusters of computing devices, workstation computers, server devices, or other types of computing and / or communication devices. In some implementations, computing resources 2124 may host platform 2220. Cloud resources may include computing instances executed in computing resources 2124, storage devices provided in computing resources 2124, data transmission devices provided by computing resources 2124, etc. In some implementations, computing resources 2124 may communicate with other computing resources 2124 via a wired connection, a wireless connection, or a combination of wired and wireless connections.

[0447] As Figure 21 further shown, computing resources 2124 include a set of cloud resources, such as one or more applications ("APP") 2124-1, one or more virtual machines ("VM") 2124-2, virtualized storage ("VS") 2124-3, one or more hypervisors ("HYP") 2124-4, etc. It should be understood that one or more example embodiments are not limited to a particular type of cloud computing environment and may be implemented on one or more servers in the form of virtualized network functions (VNFs), containerization, and / or cloud native functions (CNFs), etc.

[0448] Application 2124-1 includes one or more software applications that can be provided to or accessed by user device 2210. Application 2124-1 can eliminate the need to install and execute software applications on user device 2210. For example, Application 2124-1 can include software associated with platform 2220 and / or any other software that can be provided via cloud computing environment 2122. In some implementations, one Application 2124-1 can send information to / receive information from one or more other Applications 2124-1 via virtual machine 2124-2.

[0449] Virtual machine 2124-2 includes a software implementation of a machine (e.g., a computer), such as a physical machine, that executes programs. Virtual machine 2124-2 can be a system virtual machine or a process virtual machine, depending on the degree of use and correspondence of virtual machine 2124-2 with any real machine. A system virtual machine can provide a complete system platform that supports the execution of a complete operating system (OS). A process virtual machine can execute a single program and can support a single process. In some implementations, virtual machine 2124-2 can execute on behalf of a user (e.g., user device 2210) and can manage the infrastructure of cloud computing environment 2122, such as data management, synchronization, or long-duration data transfer.

[0450] Virtualized storage 2124-3 includes one or more storage systems and / or one or more devices that use virtualization technology within a storage system or device of computing resources 2124. In some implementations, in the context of a storage system, the types of virtualization can include block virtualization and file virtualization. Block virtualization can refer to the abstraction (or separation) of logical storage from physical storage such that the storage system can be accessed without regard to the physical storage or heterogeneous structure. This separation can allow the administrator of the storage system to have flexibility in how the administrator manages storage for end users. File virtualization can eliminate the dependence between the data accessed at the file level and the location where the file is physically stored. This can enable performance for optimizing storage use, server consolidation, and / or non-disruptive file migration.

[0451] Hypervisor 2124-4 can provide hardware virtualization technology that allows multiple operating systems (e.g., "guest operating systems") to execute simultaneously on a host, such as computing resources 2124. Hypervisor 2124-4 can present a virtual operating platform to the guest operating systems and can manage the execution of the guest operating systems. Multiple instances of various operating systems can share virtualized hardware resources.

[0452] The network 2130 includes one or more wired and / or wireless networks. For example, the network 2130 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, a fiber-based network, etc., and / or a combination of these or other types of networks.

[0453] Figure 21 The number and arrangement of devices and networks shown are provided as examples. In practice, there may be Figure 21 More devices and / or networks, fewer devices and / or networks, different devices and / or networks, or differently arranged devices and / or networks than shown. Figure 21 Two or more of the devices shown may be implemented in a single device, or Figure 21 The single device shown may be implemented as multiple distributed devices. Additionally or alternatively, one or more devices of the environment 2100 may perform one or more functions described as being performed by another set of devices of the environment 2100.

[0454] According to an embodiment, [X] described herein (or one or more operations associated therewith) may be implemented or deployed in the above-mentioned server platform in the form of a virtualized network function (VNF). In this regard, it is contemplated that the terms "virtual", "virtualization", etc. described above are intended only to specify that the nature of the machine (and elements and resources associated therewith) is provided in a virtual or software form. In this regard. The "virtual machine", "virtualized storage", etc. described above should not be limited to any specific type of virtual machine or virtual element. Therefore, it is understood that these (or operations associated therewith) may be defined or presented in the form of containerized network functions, where these functions may be provided in a container form.

[0455] Figure 22 2200 is a diagram of example components of a device 2200. The device 2200 may correspond to a user device 2210 and / or a platform 2220. Figure 22 As shown, the device 2200 may include a bus 2110 , a processor 2120 , a memory 2230 , a storage component 2240 , an input component 2250 , an output component 2260 , and a communication interface 2270 .

[0456] The bus 2110 includes components that permit communication among the components of the device 2200. The processor 2120 may be implemented in hardware, firmware, or a combination of hardware and software. The processor 2120 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 another type of processing component. In some implementations, the processor 2120 includes one or more processors that can be programmed to perform functions. The memory 2230 includes random access memory (RAM), read only memory (ROM), and / or another type of dynamic or static storage device that stores information and / or instructions for use by the processor 2120 (e.g., flash memory, magnetic memory, and / or optical memory).

[0457] The storage component 2240 stores information and / or software related to the operation and use of the device 2200. For example, the storage component 2240 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optical disk, and / or a solid state disk), a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a cassette tape, a magnetic tape, and / or another type of non-transitory computer-readable medium, as well as corresponding drives. The input component 2250 includes components that permit the device 2200 to receive information, such as via a user input (e.g., a touch screen display, a keyboard, a keypad, a mouse, a button, a switch, and / or a microphone). Additionally or alternatively, the input component 2250 may include sensors for sensing information (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, and / or an actuator). The output component 2260 includes components that provide output information from the device 2200 (e.g., a display, a speaker, and / or one or more light emitting diodes (LEDs)).

[0458] The communication interface 2270 includes transceiver-like components (e.g., a transceiver and / or separate receiver and transmitter) that enable the device 2200 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 2270 may permit the device 2200 to receive information from and / or provide information to another device. For example, the communication interface 2270 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.

[0459] Device 2200 may perform one or more of the processes described herein. Device 2200 may perform these processes in response to a processor 2120 executing software instructions stored by a non-transitory computer-readable medium such as a memory 2230 and / or a storage component 2240. A computer-readable medium is defined herein as a non-transitory memory device. A memory device includes a memory space within a single physical storage device or a memory space distributed across multiple physical storage devices.

[0460] Software instructions may be read into the memory 2230 and / or the storage component 2240 from another computer-readable medium or from another device via a communication interface 2270. When executed, the software instructions stored in the memory 2230 and / or the storage component 2240 may cause the processor 2120 to perform one or more of the processes described herein.

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

[0462] Figure 22 The number and arrangement of the components shown are provided as an example. In practice, Device 2200 may include more components, fewer components, different components, or components arranged differently than shown. Additionally or alternatively, a set of components (e.g., one or more components) of Device 2200 may perform one or more functions described as being performed by another set of components of Device 2200. Figure 22 Compared to what is shown, Device 2200 may include more components, fewer components, different components, or components arranged differently. Additionally or alternatively, a set of components (e.g., one or more components) of Device 2200 may perform one or more functions described as being performed by another set of components of Device 2200.

[0463] In an embodiment, Figures 2 to 10 any one of the operations or processes of Figure 21 and Figure 22 shown may be implemented by or using any one of the elements shown. It should be understood that other embodiments are not limited to this and may be implemented in various different architectures (e.g., a bare-metal architecture, any cloud-based architecture, or deployment architectures such as Kubernetes, Docker, OpenStack, etc.).

[0464] According to one or more embodiments, an O-RU, an O-DU, etc. (or one or more operations associated therewith) may be implemented in the form of a containerized network function. An example configuration for implementing containerized functions is provided below.

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

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

[0467] A computer-readable storage medium may be a tangible device that can retain and store instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes: a portable computer floppy disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disc (DVD), a memory stick, a floppy disk, a mechanically encoded device on which instructions are recorded (such as a punched card or raised structures in a groove), and any suitable combination of the foregoing. As used herein, a computer-readable storage medium should not itself be construed as a transitory signal, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., an optical pulse through an optical fiber cable), or an electrical signal transmitted through a wire.

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

[0469] The computer-readable program code / instructions for performing the operations can be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, firmware instructions, state-setting data, configuration data for an integrated circuit system, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages (such as Smalltalk, C++, etc.) and procedural programming languages (such as the "C" programming language or similar programming languages). The computer-readable program instructions can be executed entirely on the user's computer, partially on the user's computer, executed as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer can be connected to the user's computer through any type of network connection, including a local area network (LAN) or a wide area network (WAN), or a connection to an external computer (e.g., using an Internet service provider via the Internet) can be made. In some embodiments, an electronic circuit system (including, for example, a programmable logic circuit system, a field-programmable gate array (FPGA), or a programmable logic array (PLA)) can execute the computer-readable program instructions by utilizing the state information of the computer-readable program instructions to personalize the electronic circuit system, thereby performing various aspects or operations.

[0470] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce a machine, such that the instructions executed via the processor of the computer or other programmable data processing device create a means for implementing the functions / actions specified in the flowchart and / or block diagram blocks. These computer-readable program instructions can also be stored in a computer-readable storage medium, which can direct a computer, a programmable data processing device, and / or other devices to work in a particular manner, such that the computer-readable storage medium in which the instructions are stored includes an article of manufacture that includes instructions for implementing various aspects of the functions / actions specified in the flowchart and / or block diagram blocks.

[0471] The computer-readable program instructions can also be loaded onto a computer, other programmable data processing device, or other device, so that a series of operation steps are executed on the computer, other programmable device, or other device, thereby producing a computer-implemented process, such that the instructions executed on the computer, other programmable device, or other device implement the functions / actions specified in the flowchart and / or block diagram blocks.

[0472] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer-readable media according to various embodiments. In this regard, each block in the flowchart or block diagram may represent a micro service, instruction module, segment, or portion that includes one or more executable instructions for implementing the specified logical function(s). Compared to what is shown in the figures, the method, computer system, and computer-readable media may include more blocks, fewer blocks, different blocks, or blocks arranged differently. In some alternative implementations, the functions described in the blocks may not occur in the order shown in the figures. For example, in fact, two consecutive blocks shown may be executed simultaneously or substantially simultaneously, or these blocks may sometimes be executed in the reverse order, depending on the functions involved. It will also be noted that each block of the block diagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, can be implemented by a system based on dedicated hardware that performs the specified functions or actions or by a combination of dedicated hardware and computer instructions.

[0473] It is obvious that the devices and / or methods described herein can be implemented in different forms of hardware, firmware, or a combination of hardware and software. The actual specific control hardware or software code for implementing these systems and / or methods does not limit these implementations. Thus, the operation and behavior of these systems and / or methods are described herein without reference to specific software code. It should be understood that software and hardware can be designed to implement these systems and / or methods based on the description herein.

[0474] Various additional corresponding aspects and features of embodiments of the present disclosure may be defined by the following clauses:

[0475] Clause [1] A device includes: an Open Radio Unit (O-RU) configured to: send antenna configuration capability information including at least one antenna array model parameter to a Distribution Unit (O-DU) via management plane (M-plane) messaging; receive an antenna array configuration including at least one antenna array model parameter supported by the O-RU from the O-DU via control plane (C-plane) messaging or M-plane messaging, wherein the supported antenna array configuration is based on the antenna configuration capability information including at least one antenna array model parameter of the O-RU and a request for reconfiguring the antenna array from a higher layer network function; and change an antenna array model on top of a baseline antenna array configuration of the O-RU based on the antenna array configuration including at least one antenna array model parameter supported by the O-RU.

[0476] Clause [2] The apparatus according to clause [1], wherein the apparatus configured to change the antenna array model over the baseline antenna array configuration may further be configured to: configure at least one beam weight and / or at least one antenna calibration data based on at least one antenna model parameter received from the O-DU; and respond to the antenna configuration change during the transition from one antenna array model to another antenna array model, taking into account the transition time of the antenna configuration change.

[0477] Clause [3] The apparatus according to clause [1 or 2], wherein the antenna configuration capability information may include: at least one antenna array model parameter for defining at least one antenna array model among a plurality of predefined antenna array models that the O-RU is capable of activating, and wherein the apparatus may further be configured to: receive a bit mask from the O-DU for activating at least one antenna array model based on the selected at least one antenna array model parameter; and activate at least one antenna array model over the baseline antenna array configuration of the O-RU based on the bit mask.

[0478] Clause [4] An apparatus includes: a distribution unit (O-DU) configured to: receive, via management plane (M-plane) messaging, antenna configuration capability information including at least one antenna array model parameter from a radio unit (O-RU); receive a request for reconfiguring the antenna array from a higher layer network function; determine an antenna array configuration including at least one antenna array model parameter supported by the O-RU based on the antenna configuration capability information including at least one antenna array model parameter from the O-RU and based on the request for reconfiguring the antenna array from the higher layer network function; and apply the supported antenna array configuration including at least one antenna array model parameter via C-plane messaging or M-plane messaging.

[0479] Clause [5] The apparatus according to clause [4], wherein the apparatus configured to determine an antenna array configuration including at least one antenna array model parameter supported by the O-RU may further be configured to: select at least one antenna array model parameter operable by the O-RU over the baseline antenna array configuration of the O-RU; bit mask at least one antenna array model operable by the O-RU over the baseline antenna array configuration of the O-RU based on the selected at least one antenna array model parameter; and send the bit mask to activate at least one antenna array model at the O-RU.

[0480] Clause [6] The apparatus according to any one of clauses [1 to 5], wherein the antenna configuration capability information may include an antenna array baseline model configuration, wherein a bitmask defines a plurality of antenna array models, the plurality of antenna array models enabling the O-RU to activate at least one antenna array model on top of the baseline antenna array configuration, wherein at least one antenna array model includes at least one of the following items: 64T64R model, having 192 elements, including 96 dual-polarized elements; 48T48R model, having 72 elements, including 144 dual-polarized elements; 32T32R, including 96 elements, including 48 dual-polarized elements, with 12 dual-polarized elements in a row and 4 dual-polarized elements in a column; 32T32R, including 96 elements, including 48 dual-polarized elements, with 12 dual-polarized elements in a row and 4 dual-polarized elements in a column; 32T32R, including 96 elements, with 12 single-polarized elements in a row and 8 single-polarized elements in a column; and 32T32R, including 96 elements, including 48 dual-polarized elements within two sub-matrices of 24 dual-polarized elements symmetric to each other.

[0481] Clause [7] The apparatus according to any one of clauses [1 to 5], wherein the antenna configuration capability information may include an antenna array baseline model configuration, wherein a bitmask defines a plurality of antenna array models, the plurality of antenna array models enabling the O-RU to activate at least one antenna array model parameter on top of the baseline antenna array configuration, wherein at least one antenna array model includes at least one of the following items: 16T16R antenna array baseline model, having 96 dual-polarized elements; 16T16R antenna array baseline model, having 96 single-polarized elements; and 8T8R antenna array baseline model, having 48 dual-polarized elements.

[0482] Clause [8] A method includes: sending, by a radio unit (O-RU) via management plane (M-plane) messaging, antenna configuration capability information including at least one antenna array model parameter to a distribution unit (O-DU); receiving, via control plane (C-plane) messaging, or M-plane messaging, from the O-DU an antenna array configuration including at least one antenna array model parameter supported by the O-RU, wherein the supported antenna array configuration is based on the antenna configuration capability information including at least one antenna array model parameter of the O-RU and a request from a higher-layer network function for reconfiguring the antenna array; and changing, by the O-RU, an antenna array model on top of the baseline antenna array configuration of the O-RU based on the antenna array configuration including at least one antenna array model parameter supported by the O-RU.

[0483] Clause [9] The method according to clause [8], wherein the method may further include: configuring, by the O-RU, at least one beam weight and / or at least one antenna calibration data based on at least one antenna model parameter received from the O-DU; and responding, by the O-RU, to an antenna configuration change during a transition from one antenna array model to another antenna array model, taking into account the transition time of the antenna configuration change.

[0484] Clause

[10] The method according to clause [9], wherein the method may further include: receiving, from the O-DU, a bit mask for activating at least one antenna array model based on at least one selected antenna array model parameter; and activating, by the O-RU, at least one antenna array model on top of the baseline antenna array configuration of the O-RU based on the bit mask.

[0485] Clause

[11] A method includes: receiving, by a distribution unit (O-DU) via management plane (M-plane) messaging, antenna configuration capability information including at least one antenna array model parameter from a radio unit (O-RU); receiving a request for reconfiguring an antenna array from a higher layer network function; determining, by the O-DU, an antenna array configuration including at least one antenna array model parameter supported by the O-RU based on the antenna configuration capability information including at least one antenna array model parameter from the O-RU and based on the request for reconfiguring the antenna array from the higher layer network function; and applying, by the O-DU via C-plane messaging or M-plane messaging, the supported antenna array configuration including at least one antenna array model parameter.

[0486] Clause

[12] The method according to clause

[11] , wherein the method may further include: selecting, by the O-DU, at least one antenna array model parameter operable by the O-RU on top of the baseline antenna array configuration of the O-RU; masking, by the O-DU, at least one antenna array model operable by the O-RU on top of the baseline antenna array configuration of the O-RU based on the selection; and sending, by the O-DU, the bit mask to activate at least one antenna array model at the O-RU.

[0487] Clause

[13] The method according to any one of Clauses [8 to 12], wherein the antenna configuration capability information may include an antenna array baseline model configuration, wherein a bitmask defines a plurality of antenna array models, and the plurality of antenna array models enable the O-RU to activate at least one antenna array model on top of the baseline antenna array configuration, and wherein the at least one antenna array model includes at least one of the following: a 64T64R model having 192 elements including 96 dual-polarized elements; a 48T48R model having 72 elements including 144 dual-polarized elements; a 32T32R including 96 elements including 48 dual-polarized elements, wherein there are 12 dual-polarized elements in a row and 4 dual-polarized elements in a column; a 32T32R including 96 elements including 48 dual-polarized elements, wherein there are 12 dual-polarized elements in a row and 4 dual-polarized elements in a column; a 32T32R including 96 elements, wherein there are 12 single-polarized elements in a row and 8 single-polarized elements in a column; and a 32T32R including 96 elements including 48 dual-polarized elements within two sub-matrices of 24 dual-polarized elements symmetric to each other.

[0488] Clause

[14] The method according to any one of Clauses [8 to 12], wherein the antenna configuration capability information may include an antenna array baseline model configuration, wherein a bitmask defines a plurality of antenna array models, and the plurality of antenna array models enable the O-RU to activate at least one antenna array model parameter on top of the baseline antenna array configuration, and wherein the at least one antenna array model includes at least one of the following: a 16T16R antenna array baseline model having 96 dual-polarized elements; a 16T16R antenna array baseline model including 96 single-polarized elements; and an 8T8R antenna array baseline model including 48 dual-polarized elements. < / rpc>

Claims

1. An apparatus, comprising: A radio unit (O-RU), wherein the O-RU is configured to: Send antenna configuration capability information including at least one antenna array model parameter to a distribution unit (O-DU) via management plane (M-plane) messaging; Receive an antenna array configuration including at least one antenna array model parameter supported by the O-RU from the O-DU via control plane (C-plane) messaging or M-plane messaging, wherein the supported antenna array configuration is based on the antenna configuration capability information including at least one antenna array model parameter of the O-RU and a request from a higher layer network function to reconfigure the antenna array; And Change an antenna array model on top of a baseline antenna array configuration of the O-RU based on the antenna array configuration including at least one antenna array model parameter supported by the O-RU.

2. The apparatus according to claim 1, wherein the apparatus configured to change the antenna array model on top of the baseline antenna array configuration is further configured to: Configure at least one beam weight and / or at least one antenna calibration data based on the at least one antenna model parameter received from the O-DU; and Respond to an antenna configuration change during a transition from one antenna array model to another, taking into account a transition time of the antenna configuration change.

3. The apparatus according to claim 1, wherein the antenna configuration capability information includes: At least one antenna array model parameter for defining at least one antenna array model among a plurality of predefined antenna array models that the O-RU is capable of activating, and wherein the apparatus is further configured to: Receive a bit mask from the O-DU for activating the at least one antenna array model based on the selected at least one antenna array model parameter; And Activate at least one antenna array model on top of a baseline antenna array configuration of the O-RU based on the bit mask.

4. An apparatus, comprising: A distribution unit (O-DU), configured to: Receive antenna configuration capability information including at least one antenna array model parameter from a radio unit (O-RU) via management plane (M-plane) messaging; Receive a request to reconfigure an antenna array from a higher layer network function; Determine an antenna array configuration including at least one antenna array model parameter supported by the O-RU based on the antenna configuration capability information including at least one antenna array model parameter from the O-RU and the request from the higher layer network function to reconfigure the antenna array; And Apply the supported antenna array configuration including at least one antenna array model parameter via C-plane messaging or M-plane messaging.

5. The apparatus according to claim 4, wherein the apparatus configured to determine an antenna array configuration including at least one antenna array model parameter supported by the O-RU is further configured to: Select at least one antenna array model parameter operable by the O-RU on top of a baseline antenna array configuration of the O-RU; Based on the selected at least one antenna array model parameter, perform a bitmask on at least one antenna array model operable by the O-RU on top of the baseline antenna array configuration of the O-RU; and transmit the bitmask to activate the at least one antenna array model at the O-RU.

6. The apparatus according to claim 4, wherein the antenna configuration capability information includes an antenna array baseline model configuration, wherein the bitmask defines a plurality of antenna array models, the plurality of antenna array models enabling the O-RU to activate the at least one antenna array model on top of the baseline antenna array configuration, wherein the at least one antenna array model includes at least one of the following: 64T64R model, having 192 elements, including 96 dual-polarized elements, 48T48R model, having 72 elements, including 144 dual-polarized elements, 32T32R, including 96 elements, including 48 dual-polarized elements, 32T32R, including 96 elements, including 48 dual-polarized elements, where there are 12 dual-polarized elements in a row and 4 dual-polarized elements in a column, 32T32R, including 96 elements, where there are 12 single-polarized elements in a row and 8 single-polarized elements in a column, and 32T32R, including 96 elements, including 48 dual-polarized elements within two sub-matrices of 24 dual-polarized elements symmetric to each other.

7. The apparatus according to claim 4, wherein the antenna configuration capability information includes an antenna array baseline model configuration, wherein the bitmask defines a plurality of antenna array models, the plurality of antenna array models enabling the O-RU to activate the at least one antenna array model parameter on top of the baseline antenna array configuration, wherein the at least one antenna array model includes at least one of the following: 16T16R, including 48 dual-polarized elements, 16T16R, including 96 single-polarized elements, and 8T8R, including 24 dual-polarized elements.

8. A method, comprising: sending, by a radio unit (O-RU) via management plane (M-plane) messaging, antenna configuration capability information including at least one antenna array model parameter to a distribution unit (O-DU); receiving, via control plane (C-plane) messaging or M-plane messaging, an antenna array configuration including at least one antenna array model parameter supported by the O-RU from the O-DU, wherein the supported antenna array configuration is based on the antenna configuration capability information including at least one antenna array model parameter of the O-RU and a request from a higher layer network function for reconfiguring the antenna array; and changing, by the O-RU, an antenna array model on top of the baseline antenna array configuration of the O-RU based on the antenna array configuration including at least one antenna array model parameter supported by the O-RU.

9. The method according to claim 8, wherein the method further comprises: The O-RU configures at least one beam weight and / or at least one antenna calibration data based on the at least one antenna model parameter received from the O-DU; and in view of the transition time of the antenna configuration change, the O-RU responds to the antenna configuration change during the transition from one antenna array model to another antenna array model.

10. The method according to claim 8, wherein the method further comprises: receiving, from the O-DU, a bit mask for activating the at least one antenna array model based on the at least one selected antenna array model parameter; and based on the bit mask, the O-RU activates at least one antenna array model parameter on top of the baseline antenna array configuration of the O-RU.

11. A method comprising: receiving, by a distribution unit (O-DU) via management plane (M-plane) messaging, antenna configuration capability information including at least one antenna array model parameter from a radio unit (O-RU); receiving a request for reconfiguring the antenna array from a higher layer network function; determining, by the O-DU, an antenna array configuration including at least one antenna array model parameter supported by the O-RU based on the antenna configuration capability information including at least one antenna array model parameter from the O-RU and based on the request for reconfiguring the antenna array from the higher layer network function; and applying, by the O-DU via C-plane messaging or M-plane messaging, the supported antenna array configuration including at least one antenna array model parameter.

12. The method according to claim 11, wherein the method further comprises: selecting, by the O-DU, at least one antenna array model parameter operable by the O-RU on top of the baseline antenna array configuration of the O-RU; masking, by the O-DU, at least one antenna array model operable by the O-RU on top of the baseline antenna array configuration of the O-RU based on the selection; and sending, by the O-DU, the bit mask to activate the at least one antenna array model at the O-RU.

13. The method according to claim 11, wherein the antenna configuration capability information includes an antenna array baseline model configuration, wherein the bit mask defines a plurality of antenna array models, the plurality of antenna array models enabling the O-RU to activate the at least one antenna array model on top of the baseline antenna array configuration, wherein the at least one antenna array model includes at least one of the following: 64T64R model, having 192 elements, including 96 dual-polarized elements, 48T48R model, having 72 elements, including 144 dual-polarized elements, 32T32R, including 96 elements, including 48 dual-polarized elements, 32T32R, including 96 elements, including 48 dual-polarized elements, wherein there are 12 dual-polarized elements in one row and 4 dual-polarized elements in one column, 32T32R, including 96 elements, with 12 single-polarization elements in one row and 8 single-polarization elements in one column, and 32T32R, including 96 elements, including 48 dual-polarization elements within two sub-matrices of 24 dual-polarization elements symmetric to each other.

14. The method according to claim 11, wherein the antenna configuration capability information includes an antenna array baseline model configuration, wherein the bit mask defines a plurality of antenna array models, the plurality of antenna array models enabling the O-RU to activate the at least one antenna array model parameter on top of the baseline antenna array configuration, wherein the at least one antenna array model includes at least one of the following items: 16T16R, including 48 dual-polarization elements, 16T16R, including 96 single-polarization elements, and 8T8R, including 24 dual-polarization elements.

Images