Sleep mode implementation through control plane segment type 4 messaging in telecommunication network

Abstract

An apparatus includes an O-DU configured to receive configuration capability information from a radio unit (O-RU) via a management plane (M plane) command from the O-RU. The O-DU receives a request to reconfigure the antenna array from a higher layer network function. The O-DU determines a sleep mode type supported by the O-RU based on configuration capability information from the O-RU. The O-DU applies the supported sleep mode type to the O-RU via a C-plane segment type 4 message or an M-plane command based on a request from a higher layer network function to reconfigure the antenna array, and based on the supported sleep mode type.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application is based on and claims priority from 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 disclosures of which are incorporated herein by reference in their entirety. Technical Field

[0003] Apparatus and methods consistent with example embodiments of the present disclosure relate to sleep mode implementation via control plane (C-plane) segment type (ST) 4 messaging in a telecommunications network. Background Art

[0004] The Radio Access Network (RAN) is a crucial component in telecommunications systems because it connects end-user devices (or user equipment) to the rest of the network. The RAN comprises a combination of various network elements (NEs) that connect end users to the core network. Traditionally, the hardware and / or software of a particular RAN is vendor-specific.

[0005] Open RAN (O-RAN) technology has emerged to enable multiple suppliers to provide hardware and / or software to telecommunications systems. Because different suppliers are involved, the types of hardware and / or software provided may also vary. That is, different types of NEs can be provided by different suppliers, and depending on the specific service, the NEs can be virtualized in software form (e.g., based on virtual machines (VMs)) or in physical hardware form (e.g., non-VM-based).

[0006] To this end, O-RAN decomposes RAN functionality into a centralized unit (CU), a distributed unit (DU), and a radio unit (RU). The CU can be a logical node for hosting the radio resource control (RRC), service data adaptation protocol (SDAP), and / or packet data convergence protocol (PDCP) sublayers of the RAN. The DU can be a logical node for hosting the radio link control (RLC), medium access control (MAC), and physical (PHY) sublayers of the RAN. The RU can be a physical node that converts radio signals from the antenna into digital signals, which can be transmitted to the DU via a frontend. Because there are open protocols and interfaces between these entities, they can be developed by different suppliers.

[0007] Figure 1 The O-RAN architecture in the related art is shown. The RAN functions in the O-RAN architecture can be controlled and optimized by the RAN Intelligent Controller (RIC). The RIC can be a software-defined component that implements modular applications to facilitate the multi-supplier operability required in the O-RAN system, as well as to automate and optimize RAN operations. Figure 1 As shown, RIC can be divided into two types: non-real-time RIC (non-RT RIC) 120 and near-real-time RIC (near-RT RIC) 130 .

[0008] The non-RT RIC 120 can be the control point of a non-real-time control loop and can operate at a timescale greater than 1 second within the service management and orchestration (SMO) framework 110. Its functions can be implemented through modular applications called rApps and can include: providing policy-based guidance and enrichment over the A1 interface, which is the interface that enables communication between the non-RT-RIC and the near-RT-RIC; performing data analysis; artificial intelligence / machine learning (AI / ML) training and inference for RAN optimization; and / or recommending configuration management actions over the O1 interface, which can be the interface that connects the SMO to RAN management elements (e.g., near-RT RIC 130, O-RAN centralized units (O-CU) 140, 150, O-RAN distributed units (O-DU) 170, etc.).

[0009] The near-RT RIC 130 can operate on a timescale between 10 milliseconds and 1 second and can be coupled to the O-DU 170, the O-CU (decomposed into the O-CU control plane (O-CU-CP) 140 and the O-CU user plane (O-CU-UP) 150), and the open evolved Node B (O-eNB) 160 via the E2 interface. The near-RT RIC 130 can control the underlying RAN elements (E2 nodes / network functions (NFs)) through a near real-time control loop using the E2 interface. The near-RT RIC 130 can monitor, pause / stop, override, and control the E2 nodes (O-CUs 140, 150, O-DU 170, and O-eNB 160) via policy. For example, the near-RT RIC 130 can set policy parameters for the active functions of the E2 nodes. In addition, the near-RT RIC 130 can host xApps to implement functions such as quality of service (QoS) optimization, mobility optimization, slice optimization, interference mitigation, load balancing, security, and more.

[0010] Here, the O-CU-CP 140 and the O-CU-UP 150 may be coupled to each other via an E1 interface and may be coupled to the O-DU 170 via an F1-c interface and an F1-u interface, respectively. In addition, the O-RU 180 may be coupled to the O-DU 170 via the open front end (OF) control (C), user (U), synchronization (S), and management (M) planes, and may be coupled to the SMO 110 via the OF M plane.

[0011] These two types of RICs work together to optimize O-RAN. For example, the non-RT RIC 120 can provide policies, data, and AI / ML models that the near-RT RIC 130 implements and uses for RAN optimization, and the near-RT RIC 130 can provide policy feedback (i.e., how the policies set by the non-RT RIC 120 are working).

[0012] As described above, the non-RT RIC 120 can be located within the SMO framework 110 that manages and orchestrates RAN elements. Specifically, the SMO 110 can manage and orchestrate the so-called O-Ran Cloud (O-Cloud) 190. The O-Cloud 190 can be a collection of physical RAN nodes that host RICs, O-CUs, and O-DUs, supporting software components (such as operating systems and runtime environments), and the SMO 110 itself. In other words, the SMO 110 can manage the O-Cloud 190 from within. The O2 interface can be the interface between the SMO 110 and the O-Cloud 190 in which it is located. Through the O2 interface, the SMO 110 can provide infrastructure management services (IMS) and deployment management services (DMS).

[0013] In the related art, due to the lack of communication between the O-DU and the O-RU, the network energy saving method cannot be dynamically implemented.

[0014] Furthermore, in a related aspect, since the O-DU is unaware of the proprietary settings of the provider-centric TRx array (ie, antenna array), it is not possible to effectively control the power consumption of the O-RU.

[0015] For example, it may not be possible to shield (eg, turn off) some of the antenna elements in an antenna array and their corresponding RF transceiver chains. Summary of the Invention

[0016] According to an embodiment, the present disclosure provides a sleep mode implementation through control plane (C-plane) segment type (ST) 4 messaging in a telecommunications network. Configuration capability information is received by a distributed unit (O-DU) from a radio unit (O-RU) (i.e., sent by the O-RU to the O-DU via management plane (M-plane) messaging, the management plane messaging enabling the O-DU to determine the sleep mode types supported by the O-RU, wherein the supported sleep mode types are based on the configuration capability information from the O-RU and based on a request to reconfigure an antenna array from a higher layer network function. The informed determination enables the O-DU to apply the supported sleep mode types to the O-RU via a C-plane segment type 4 message or an M-plane command, and enables the O-RU to activate the sleep mode types to a portion of the O-RU based on the supported sleep mode types from the O-DU.

[0017] The detailed application and activation of sleep mode types as described above has the advantage of achieving maximum power savings by partially powering down the O-RU based on the supported sleep mode implementations provided by the O-DU.

[0018] An apparatus includes a distributed unit (O-DU) configured to receive configuration capability information from a radio unit (O-RU) via management plane (M-plane) messaging from the O-RU. The O-DU receives a request to reconfigure an antenna array from a higher-layer network function. The O-DU determines a sleep mode type supported by the O-RU based on the configuration capability information from the O-RU and based on the request to reconfigure the antenna array from the higher-layer network function. The O-DU applies the supported sleep mode type to the O-RU via a C-plane segment type 4 message or an M-plane command based on the supported sleep mode type.

[0019] An apparatus includes a radio unit (O-RU) configured to: send configuration capability information to an open distributed unit (O-DU) via a management plane (M-plane) command; the O-RU receiving, from the O-DU via a C-plane segment type 4 message or an M-plane command, sleep mode types supported by the O-RU, wherein the supported sleep mode types are based on the configuration capability information of the O-RU and a request to reconfigure an antenna array from a higher layer network function; and the O-RU activating the sleep mode types to a portion of the O-RU based on the sleep mode types supported by the O-RU.

[0020] A method comprising receiving, by a distributed unit (O-DU), configuration capability information from a radio unit (O-RU) via management plane (M-plane) messaging from the O-RU. The method comprises receiving, by the O-DU, a request to reconfigure an antenna array from a higher layer network function. The method comprises determining, by the O-DU, a sleep mode type supported by the O-RU. The O-RU supports the supported sleep mode type based on the configuration capability information from the O-RU and based on the request to reconfigure the antenna array from the higher layer network function. The method comprises applying, by the O-DU, to the O-RU, via a C-plane segment type 4 message or an M-plane command, the supported sleep mode type based on the supported sleep mode type.

[0021] A method, the method comprising sending, by a radio unit (O-RU), configuration capability information to an open distributed unit (O-DU) via a management plane (M-plane) command. The method comprises receiving, by the O-RU, from the O-DU via a C-plane segment type 4 message or an M-plane command, sleep mode types supported by the O-RU, wherein the supported sleep mode types are based on the configuration capability information of the O-RU and a request from a higher layer network function to reconfigure an antenna array. The method comprises activating, by the O-RU, a sleep mode type for a portion of the O-RU based on the sleep mode types supported by the O-RU.

[0022] A non-transitory computer-readable recording medium having recorded thereon instructions executable by at least one processor, the processor being configured to execute the instructions to implement a method, the method comprising receiving, by a distributed unit (O-DU), configuration capability information from a radio unit (O-RU) via management plane (M-plane) messaging from the O-RU. The method comprises receiving, by the O-DU, a request to reconfigure an antenna array from a higher-layer network function; based on the configuration capability information from the O-RU. The method comprises determining, by the O-DU, a sleep mode type supported by the O-RU based on the request to reconfigure the antenna array from the higher-layer network function. The method comprises applying, by the O-DU, the supported sleep mode type to the O-RU via a C-plane segment type 4 message or an M-plane command based on the supported sleep mode type.

[0023] A non-transitory computer-readable recording medium having recorded thereon instructions executable by at least one processor, the processor being configured to execute the instructions to implement a method, the method comprising: sending, by a radio unit (O-RU), configuration capability information to an open distributed unit (O-DU) via a management plane (M-plane) command. The method comprises receiving, by the O-RU, from the O-DU via a C-plane segment type 4 message or an M-plane command, sleep mode types supported by the O-RU, wherein the supported sleep mode types are based on the configuration capability information of the O-RU and a request from a higher-layer network function to reconfigure an antenna array. The method comprises activating, by the O-RU, a sleep mode type of a portion of the O-RU based on the sleep mode types supported by the O-RU.

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

[0025] Features, aspects, and advantages of certain exemplary embodiments of the present disclosure will be described below with reference to the accompanying drawings, in which like reference numerals represent like elements, and in which:

[0026] Figure 1 The O-RAN architecture in the related art is shown;

[0027] Figure 2 A method for implementing sleep mode implementation through control plane segment type 4 messaging from an O-DU perspective according to an embodiment is shown;

[0028] Figure 3 shows a method of using wakeup delay information for sleep mode implementation via a C-plane segment type 4 message through the parameter asmflag according to an embodiment;

[0029] Figure 4 A method for sending an interrupt via C-plane segment type 4 messaging to wake up the O-RU from a first sleep mode type SM1 and activate the CU-plane processing unit after at least one of L time slots of SM1, M time slots of SM2, and N time slots of SM3 according to an embodiment is shown;

[0030] Figure 5 A method for implementing sleep mode implementation through control plane section type 4 messaging from an O-RU perspective according to an embodiment is shown;

[0031] Figure 6 shows a method for using wakeup delay information for sleep mode implementation via C-plane segment type 4 message through parameter asmflag according to an embodiment;

[0032] Figure 7 A method for deactivating logic radio frequency components (FPGA, RFIC) and RF front-end module (RFFE) components based on wake-up delay information according to an embodiment is shown;

[0033] Figure 8 A method of M-plane messaging according to an embodiment is shown, the method including a Yang model for capability reporting of sleep modes and associated parameters;

[0034] Figure 9 shows a flow chart of M-Plane / C-Plane messaging between an O-RU and an O-DU for a sleep mode use case according to an embodiment;

[0035] Figure 10 shows a flowchart of a sleep mode implementation of sleep mode type SM1 according to an example embodiment;

[0036] Figure 11 shows a flowchart of a sleep mode implementation of sleep mode type SM3 according to an example embodiment;

[0037] Figure 12 The sleep mode implementation according to the Segment Type 4 Command Type (ST4CmdType) TRX CONTROL is shown. Figure 13 ,According to an example embodiment, the sleep modes have different sleep depths;

[0038] Figure 13 shows a sleep mode implementation according to a segment type 4 command type (ST4CmdType) ST4CmdType 'TRX-CONTROL / ADVANCED-SLEEP-MODE' according to an example embodiment;

[0039] Figure 14 shows a sleep mode implementation according to a segment type 4 command type (ST4CmdType) ST4CmdType 'TRX-CONTROL / ADVANCED SLEEP-MODE', the command type including a parameter symbolMask for implementing a symbol-level sleep duration to support sleep mode type 0 (SM0) according to an example embodiment;

[0040] Figure 15 shows a flow chart of a startup and wakeup procedure between an O-DU and an O-RU for sleep mode implementation through control plane segment type 4 messaging according to an example embodiment;

[0041] Figure 16shows a flow chart of a startup and wakeup procedure between an O-DU and an O-RU for sleep mode implementation through control plane segment type 4 messaging according to an example embodiment;

[0042] Figure 17 illustrates deactivating O-RU components by activating a sleep mode type in the O-RU through control plane segment type 4 messaging according to an example embodiment;

[0043] Figure 18 An embodiment of TRx control and sleep mode according to a Segment Type 4 Command Type (ST4CmdType) TRX-CONTROL and a Segment Type 4 Command Common Header format according to another example embodiment is shown.

[0044] Figure 19 is an illustration of an example environment in which the systems and / or methods described herein may be implemented; and

[0045] Figure 20 is an illustration of example components of a device according to an embodiment. DETAILED DESCRIPTION

[0046] The following detailed description of example embodiments refers to the accompanying drawings. The above disclosure provides illustrations and descriptions, but is not intended to be exhaustive or to limit implementation to the precise form disclosed. In view of the above disclosure, modifications and variations are possible, or can be obtained from the practice of implementation. In addition, one or more features or components of an embodiment may be incorporated into or combined with another embodiment (or one or more features of another embodiment). In addition, in the flowcharts and descriptions of the operations provided below, it should be understood that one or more operations may be omitted, one or more operations may be added, one or more operations may be performed simultaneously (at least in part), and the order of one or more operations may be switched.

[0047] It will be apparent that the systems and / or methods described herein can be implemented in various forms of hardware, firmware, or a combination of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods does not limit the implementation. Therefore, the operation and behavior of the 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 the systems and / or methods described herein.

[0048] 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 can be combined in ways not specifically recited in the claims and / or disclosed in the specification. Although each dependent claim listed below may only be directly dependent on one claim, the disclosure of possible implementations includes each dependent claim in combination with every other claim in the claim set.

[0049] Unless explicitly described, any element, action or instruction used in this article should not be interpreted as critical or essential. In addition, as used herein, the articles "a" and "a piece" are intended to include one or more items and can be used interchangeably with "one or more". If only one item is intended to be used, the term "a" or similar language is used. In addition, as used herein, the terms "having", "having", "containing", "including", "comprising" and the like are intended to be open terms. In addition, unless otherwise explicitly stated, the phrase "based on" is intended to mean "based at least in part on". In addition, expressions such as "at least one of [A] and [B]", "[A] and / or [B]" or "at least one of [A] or [B]" should be understood to include only A, only B or both A and B.

[0050] It should be noted that the description of the exemplary embodiments of the present disclosure may include terms and names defined in one or more standard organizations, such as the 3rd Generation Partnership Project (3GPP) standards organization, the European Telecommunications Standards Institute (ETSI) standards organization, the Open RAN (O-RAN Alliance), etc. For example, technical or functional terms describing the exemplary embodiments, etc., and associated features and operations are to be interpreted as being consistent with those specified in one or more telecommunication standard specifications (e.g., 3GPP, ETSI, O-RAN Alliance, etc.), unless otherwise described.

[0051] An exemplary embodiment of the present disclosure provides an O-DU that applies a supported sleep mode type to an O-RU via a C-plane segment type 4 message or an M-plane command, and an O-RU that activates a sleep mode type to a portion of the O-RU based on the supported sleep mode type from the O-DU. Thus, the O-DU and the O-RU enable maximum power savings by shutting down a portion of the O-RU based on the supported sleep mode type provided by the O-DU, wherein the O-DU is aware of the O-RU configuration capability information.

[0052] Figure 2 A method for optimizing antenna array model selection in O-RAN from the perspective of O-DU is shown. Figure 2In step 201, the O-DU receives capability information from the radio unit (O-RU) via management plane (M-plane) messaging. For example, the O-RU reports configuration capability information such as supported network energy saving (i.e., ES or NES) modes according to O-RU–urn:o-ran:module-cap:1.0.

[0053] For example, the vendor may hard-code the antenna configuration capability information and at least one of the following parameters during production: a unique name, an index, a 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 by each configuration of the antenna array, antenna calibration data applied by the O-RU during configuration changes, energy savings achievable with reference to each configuration, associated beam weights (predefined beam weights), etc. In an example embodiment, when the O-RU is powered on (initialized), the O-RU begins reporting supported energy saving modes (i.e., antenna array configuration capability information) and the hard-coded antenna array model and other initialization parameters to the O-DU using an M-plane YANG model (e.g., urn:o-ran:module-cap:1.0 and an urn:o-ran:hardware:1.0).

[0054] In an example embodiment, the energy saving by transmission blanking parameter can be used to send configuration capability information from the O-RU to the O-DU. This allows the existing M-plane model to be used 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 mode, energy saving by not modifying spatial streams, etc.).

[0055] An example of energy-saving parameters by transmission blanks in the M-plane model can be as follows: leaf energy-saving-by-transmission-blanks{

[0056] type boolean;

[0057] mandatory true;

[0058] description

[0059] "Parameter informs if unit supports energy-saving by transmission blanking";

[0060] }

[0061] grouping Energy-saving-method{

[0062] status active;

[0063] description

[0064] "Grouping for energy-saving method.

[0065] Note:This grouping is meant for energy-saving methods.";

[0066] leaf energy-saving-method{

[0067] type enumeration{

[0068] enum RF CHANNEL RECONFIGURATION{

[0069] description

[0070] "RF Channel Reconfiguration will be used”;

[0071] }

[0072] enum ADVANCED SLEEP MODE{

[0073] description

[0074] "Advanced Sleep Mode will be used";

[0075] }

[0076] enum MODIFY NO OF SPATIAL STREAMS{

[0077] description

[0078] "No of Spatial Streams will be modified";

[0079] }

[0080] }

[0081] description

[0082] "Energy-saving method which can be supported by the O-RU.

[0083] An O-RU may further refine the applicability of energy-saving

[0084] methods per endpoint using o-ran-uplane-conf.yang model";

[0085] }

[0086] }

[0087] leaf energy-saving-by-RF-channel-reconfiguration{

[0088] type boolean;

[0089] mandatory true;

[0090] description

[0091] "Parameter informs if unit supports energy-saving by RFchannelreconfiguration";

[0092] }

[0093] leaf energy-saving-by-Advanced-Sleep-Mode{

[0094] type boolean;

[0095] mandatory true;

[0096] description

[0097] "Parameter informs if unit supports energy-saving by Advanced sleepmode";

[0098] }

[0099] leaf energy-saving-by-modify-no-of-spatial-streams{

[0100] type boolean;

[0101] mandatory true;

[0102] description

[0103] "Parameter informs if unit supports energy-saving by Modifying no ofspatial streams / layers";

[0104] }

[0105] container eaxcid-grouping-capabilities{

[0106] if-feature o-ran-module-cap:EAXC-ID-GROUP-SUPPORTED;

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

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

[0109] According to an embodiment, in accordance with the O-RAN Open Front-end M-Plane specification, which defines the management plane of the open front-end interface and the associated YANG model, the O-RU may indicate to the O-RU controller (such as the O-DU and / or higher-order network functions (i.e., SMO, etc.)) the energy-saving features supported in the associated YANG model, e.g., O-RAN-wg4-features.yang.

[0110] To this end, the O-RU configuration capability information may include 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.

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

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

[0113] The YANG feature name tag HIBERNATE-SLEEP may describe O-RU power saving achieved by shutting down the carrier and associated O-RU circuits / components for a longer duration, where the longer duration allows for implementing optional feature control as an M-plane based sleep mode to achieve hardware / component / power saving compared to other sleep modes.

[0114] The YANG feature name tag LIGHT-HIBERNATE-SLEEP may describe O-RU power saving by shutting down the carrier and associated O-RU circuits / components for longer durations without shutting down synchronization, where the longer duration allows for implementing optional feature control as an M-plane based sleep mode to achieve hardware / component / power saving compared to other sleep modes.

[0115] The YANG feature name tag DEEP-HIBERNATE-SLEEP (i.e., DEEPSLEEP) may describe O-RU power saving achieved by shutting down the carrier and associated O-RU circuits / components for a longer duration by shutting down synchronization, where the longer duration allows for the implementation of optional feature control as an M-plane based sleep mode to achieve hardware / component / power saving compared to other sleep modes.

[0116] According to example embodiments, various short-duration (C-plane based) sleep modes may be defined with reference to the YANG feature name tag ADVANCED-SLEEP-MODE or SLEEP-MODE. For example, the advanced sleep mode may be used for shorter sleep durations, such as milliseconds, seconds, or minutes, and may be activated, for example, using an ST4 C-plane message via control plane (C-plane) messaging.

[0117] According to an example embodiment, referring to the YANG feature name tag HIBERNATE-SLEEP for longer durations, the hibernation sleep mode may be activated by employing the M-plane, for example, by setting the parameter +--rw energy-saving-enabled? boolean{ENERGYSAVING}? to "true" or "yes" in the corresponding o-ran-hardware.yang module.

[0118] According to an example embodiment, referring to the YANG feature name tags LIGHT-HIBERNATE-SLEEP and DEEP-HIBERNATE-SLEEP, in order to distinguish between longer sleep times with and without shutting down the sync plane circuit, the light hibernate sleep mode with synchronization and the deep hibernate sleep mode without synchronization may be implemented in the same manner as hibernate sleep by employing the M-plane, for example, by setting the parameter +--rwenergy-saving-enabled?boolean{ENERGYSAVING}? to "true" or "yes" in the corresponding o-ran-hardware.yang module.

[0119] 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 specified in the O-ran module.cap.yang, the advanced sleep mode (ASM) can support a sleep mode (SM) with a short duration (based on the C-plane) sleep mode (e.g., multiple sleep modes, such as SM#0, SM#1, SM#2, SM#3, etc., where the duration of SM#0<SM#1<SM#2<SM#3) has different wake-up times, or if the wake-up time is too short, a defined sleep entry time. In addition, the advanced sleep mode (ASM) can support a sleep mode with a long duration (based on the M-plane) sleep mode (e.g., a sleep mode that does not involve any synchronization or a sleep mode with or without synchronization, while light sleep refers to an M-plane-based sleep mode with synchronization, and deep sleep refers to an M-plane-based sleep mode without synchronization).

[0120] According to an embodiment, the advanced sleep modes (ASM) have a wake-up time (minimum or guaranteed) for each sleep mode. The shortest mode (e.g., SM#0) among the C-plane-based sleep modes may not be defined by a minimum or guaranteed wake-up time, but by the sleep entry time.

[0121] The O-RU reporting to the O-DU and / or SMO based on the yang module (e.g., as specified in O-ran module.cap.yang) may also support C-plane messages, such as segment type 8 (ST8) "Ready" messages and C-plane messages including a range of commands (e.g., CARRIER-COMMAND, ARRAY-COMMAND, O-RU-COMMAND), such as segment type 4 (ST4) messages).

[0122] According to an example embodiment, a TRx control method for reconfiguring an 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), wherein the antenna mask bit combinations may be limited to supported TRx configurations, wherein the antenna mask bits identify antenna elements to be turned off as "0" and identify active elements of the antenna array as "1." In addition, in addition to the mask bits for the at least one antenna mask (antMask), the TRx control configuration also includes array layer mask bits for creating at least one array layer mask (antLayerMask).

[0123] To this end, the O-RU may report its capabilities for TRx control and data layer control via the Yang model o-ran-module-cap.yang. The Yang model o-ran-module-cap.yang may include the summarized parameters.

[0124] o-ran-module-cap.yang – TRx control and data plane control

[0125] Module: o-ran-module-cap

[0126] +--rw module-capability

[0127] +--ro ru-capabilities

[0128] / / TRx control–Capability reporting

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

[0130] ||+--ro number-of-supported-trx-control-configuration?Uint8 / / numberof supported TRx control configuration.

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

[0132] |||+--ro configuration-name string / / unique name of each TRx controlconfiguration

[0133] |||+--ro antenna-mask?binary or bits / / antMask list–antenna mask perTRx control config for all

[0134] |||+--ro antenna-layer-mask?binary or bits / / antLayerMask list–antennalayer mask per TRx control config for all

[0135] |||+--ro transition-time or wake-up-time uint32 / / transition time(list)associated with each configuration change for the supported TRx controlconfigurations and as a function of sub carrier spacing.Since for 15KHz,1slotis 1milli second,and for 30KHz,1slot is 0.5milli second or 500micro-seconds

[0136] |||+--ro energy-saving-ratio uint8 / / percentage of energy-saving perTRx control configuration / / data-layer / spatial streams control–Capabilityreporting

[0137] |+--ro data-layer-control-supported? boolean{or-feat:TRX-CONTROL}? / / Data layer control / limiting no of spatial streams supported by O-RU or not?

[0138] According to an example embodiment, the supported TRx control configurations may include a transition time (i.e., a wake-up time different from the ASM) that 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 may be, for example, 1 millisecond for a 15KHz slot, 0.5 milliseconds or 500 microseconds for a 30KHz slot, and so on.

[0139] According to an example embodiment, O-Ru may report the data layer control capability or the Yang model O-ran-module-cap.yang as described above, which limits the number of spatial streams for at least one supported (ie, given) antenna configuration.

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

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

[0142] According to an embodiment of an advanced sleep mode (ASM) having a short duration (C-plane based) sleep mode and 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 TRx control may be different and do not interfere with (e.g., hinder) each other.

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

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

[0145] In addition, the O-RU reporting to the O-DU and / or SMO based on the YANG module (e.g., as specified in O-ran module.cap.yang) may also support notification messaging of the CU plane active or inactive state, such as to support notifications that may be required to ensure that the CU plane becomes active after the sleep duration expires (i.e., the CU plane circuitry may be shut down in the case of a defined, undefined, and / or longer sleep duration). To this end, the O-RU reporting to the O-DU and / or SMO supports notification of the CU plane state from the O-RU to the O-DU in the event that the CU plane is shut down during any sleep mode activation.

[0146] Generally speaking, o-ran-module-cap.yang involves common O-RU capabilities, namely, O-RU configuration capability information of sleep modes (such as advanced sleep mode), CU plane status report for implementing sleep modes (such as advanced sleep mode), and TRx control methods.

[0147] To this end, o-ran-module-cap.yang may include, in addition to other YANG models, all required information to implement antenna array configurations supported by the O-RU (i.e., based on the O-RU configuration capability information).

[0148] According to an example embodiment, o-ran-module-cap.yang for a TRx control method for reconfiguring an antenna array may include, in addition to other YANG models, 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), wherein the antenna mask bit combination may be limited to the supported TRx control structure, wherein the antenna mask bit identifies the antenna element to be turned off as "0" and identifies the active element of the antenna array as "1". 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).

[0149] The YANG model o-ran-module-cap.yang may include parameters as summarized below. o-ran-module-cap.yang – Advanced Sleep Model

[0150] Module: o-ran-module-cap

[0151] +--rw module-capability

[0152] +--ro ru-capabilities

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

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

[0155] / / Advanced sleep mode–Capability reporting

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

[0157] ||+--ro supported-sleep-modes*[name] / / list of supported sleep modeslike sleep mode 0,1,2,and 3(SM#0-3)

[0158] |||+--ro sleep-mode-name string

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

[0160] |||+--ro wake-up-time uint32

[0161] / / wake-up time list(minimum or guaranteed)associated witheach sleepmode and represented in slots as a function of Sub carrierspacing.For e.g.,SM#1–L slots,SM#2–M slots,and SM#3–N slots.The wake-up time in slots islisted for all supported sub-carrier spacingby O-RU.Since for 15 KHz,1 slotis 1 milli second,and for 30 KHz,1slot is 0.5 milli second or 500microseconds.

[0162] |||+--ro energy-saving-ratio uint8

[0163] / / percentage of energy-saving per sleep mode

[0164] |+--ro hibernate-sleep-capability{or-feat:HIBERNATE-SLEEP}?

[0165] / / option#1:longer sleep duration

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

[0167] / / wake-up time in milli seconds for hibernate sleep

[0168] |+--ro light-hibernate-sleep-capability{or-feat:LIGHT-HIBERNATE-SLEEP}? / / option#2a:longer sleepduration with synchronization

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

[0170] / / wake-up time in milli seconds for light hibernate sleep

[0171] |+--ro deep-hibernate-sleep-capability{or-feat:DEEP-HIBERNATE-SLEEP}? / / option#2b:longer sleepduration without synchronization

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

[0173] / / wake-up time in milli seconds for deep hibernate sleep

[0174] ||+--ro supported-command-scope*enumeration / / supported ST4commandscope such as“CARRIER-COMMAND,ARRAY-COMMAND,O-RU-COMMAND”to be reported by O-RU.For e.g.,one or two or all three

[0175] ||+--ro st8-ready-msg-supported?boolean / / O-RU already reports thesupport of Section Type(ST)8message in supported-section-types,hence in NESperspective support of“ready”command in ST8 message to reported by O-RU as acapability

[0176] ||+--ro sleep-duration-extension-supported?boolean / / in defined sleep,if O-DU wants to extend the ongoing sleep it can issue sleep extension CPlane command(short sleep duration)and M Plane command(long sleep duration).The supported of this could be advertised by O-RU as an optional.

[0177] ||+--ro emergency-wake-up-by-cplane-command-supported?boolean / / (indefined(not guaranteed)or undefined sleep duration,O-DU could any timeinterrupt the sleep by issuing emergency wake-up C Plane command,provided CU-Plane remain active or CU-Plane circuitON.This support could be advertised byO-RU as an optional.

[0178] ||+--ro emergency-wake-up-by-mplane-command-supported? boolean / / (indefined(not guaranteed)or undefined sleep duration,O-DU could any timeinterrupt the sleep by issuing emergency wake-up command via M Plane as CU-Plane is turned off. This support could be advertised by O-RU as optional.

[0179] Referring to the above summary, the generic O-RU capability can be used for both TRx control and advanced sleep mode.

[0180] According to an example embodiment, the supported TRx control configurations may include a transition time (i.e., a wake-up time different from the ASM) that 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 (i.e., wake-up time) associated with each configuration change of the supported TRx control configuration and as a function of the subcarrier spacing may be, for example, 1 millisecond for a 15KHz slot, 0.5 milliseconds or 500 microseconds for a 30KHz slot, and so on.

[0181] According to example embodiments, the TRx control method may include control of turning on / off an entire RF transceiver chain and / or a radio frequency (RF) front end (RFFE) of a radio frequency (RF) processing unit associated with some of the RF channels / antenna elements.

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

[0183] According to an embodiment of an advanced sleep mode (ASM) having a short duration (C-plane based) sleep mode and 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 (e.g., hinder) each other.

[0184] In addition, the common capability parameters for both TRx control methods and sleep modes (e.g., advanced sleep modes) reported to the O-DU via the M-plane regarding the O-RU configuration capability information may include a C-plane ST8 "ready" message and sleep duration extension (e.g., in a defined sleep situation, 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, for short sleep times, the extension command can be based on the C-plane. If the CU plane is turned off, for long sleep times, the extension command can be based on the M-plane.

[0185] In addition, the common capability parameters of both the TRx control method and the sleep mode (e.g., advanced sleep mode) reported to the O-DU via the M-plane regarding the O-RU configuration capability information may include emergency wakeup of the O-RU from sleep. The O-RU may report this capability 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. While the CU plane remains active, for short sleep times, the emergency wakeup command may be based on the C-plane (defined or undefined). While the CU plane is turned off, for long sleep times, the emergency wakeup command may be based on the M-plane (defined or undefined).

[0186] According to an example embodiment, when the sleep mode is activated for a predefined duration, the CU plane processing unit may be shut down, and then the CU plane processing unit wakes up after the sleep time ends.

[0187] If the sleep duration is significantly longer than the wakeup duration of the CU plane processing unit, the CU plane processing unit may be shut down.

[0188] In addition, when the O-RU is in sleep mode for a predefined duration, the CU plane processing unit is turned off, and if the O-DU needs to interrupt the sleep, it can send an M-plane wake-up command (i.e., an emergency wake-up command) to the O-RU to wake up the CU plane processing unit.

[0189] In response to the above wake-up command, the O-RU may send a notification to the O-DU to indicate that the CU plane processing unit wake-up is complete.

[0190] According to an example embodiment, o-ran-module-cap.yang is used for CU plane status reporting in addition to other YANG models (for example, for implementing O-RU functionality for defined and undefined sleep modes). o-ran-module-cap.yang includes information that enables the CU plane circuit to be shut down for additional energy saving. The information may include the name identifier and status identifier of the rx array carrier, and 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 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 may be defined in o-ran-uplane.yang respectively.

[0191] The Yang model o-ran-uplane.yang can include parameters as summarized below. o-ran-uplane-conf.yang

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

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

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

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

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

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

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

[0199] According to an example embodiment of the use case RF channel reconfiguration (i.e., RF channel closing / opening), a sub-use case may be defined as TRx control (i.e., Tx array control and Rx array control may be declared separately, since antenna masks may be defined at the array level). For this sub-use case, the O-RU may include at least one of the following capability reports (i.e., configuration capability information). The configuration capability information may include, among other capability reports, at least: reporting support for activation / deactivation of TRx control based on the C-plane and M-plane, reporting a list of supported antenna array configurations / TRx control configurations (e.g., valid antenna mask values (per antenna array configuration value) and a unique name), reporting Wake-up time / duration as a function of SCS (subcarrier spacing) (i.e., this wake-up can be different from the wake-up time or duration reported for advanced sleep modes), reporting support for TRx control sleep modes, reporting the amount of energy saving / power saving / energy saving ratio achievable per 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 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).

[0200] According to another example embodiment of the use case RF channel reconfiguration (i.e., RF channel closing / opening), a 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 a list of the maximum supported spatial streams / data layers per antenna array (TRx control) configuration.

[0201] According to another example embodiment, the use case may be defined as an advanced sleep mode. For this sub-use case, the O-RU may include at least one of the following capability reports (i.e., configuration capability information). The configuration capability information may include, among other functional reports, at least reporting the wakeup duration associated with each sleep mode as a function of the SCS, reporting the energy savings achievable for each sleep mode type, reporting support for defined and undefined duration sleep, ST8 ready messages, sleep duration extension, and emergency wakeup.

[0202] According to another example embodiment of this use case, the RF channel reconfiguration (i.e., RF channel off / on) sub-use case may be defined as hibernation sleep. For this sub-use case, the O-RU may include at least one of the following capability reports (i.e., configuration capability information). The configuration capability information may also include, in addition to other functional reports: at least reporting support for hibernation sleep, such as long duration sleep (shallow / deep sleep), reporting support for O-RU to remove / cancel configuration carriers during long sleep, reporting support for shutting down C-plane, U-plane, S-plane, and M-plane processing units (i.e., supporting O-DU requests (e.g., by sending appropriate (multiple) RPCs) or through the internal logic of the O-RU).

[0203] In step 202, the O-DU receives a request from a higher-layer network function to reconfigure the antenna array. The request to reconfigure the antenna array is based on monitored network parameters that meet predetermined conditions. In an example embodiment, the higher-layer network function may determine whether current network parameters (e.g., current network parameters reflected by O1-related KPIs, such as throughput, number of users in the cell, user statistics, etc.) meet predetermined conditions (i.e., predetermined thresholds related to O-RAN network conditions). The predetermined network parameters may be based on UE-shared rank indicator (RI) values, traffic scenarios, etc., which may be derived from the O1 interface-related KPIs (i.e., throughput, number of users in the cell, user statistics, etc.).

[0204] In step 203, the O-DU determines the type of sleep mode supported by the O-RU. The determined sleep mode is based on the configuration capability information from the O-RU and based on the request to reconfigure the antenna array from the higher layer network function as described above.

[0205] exist Figure 2 In the embodiment, the configuration capability information may also include wake-up delay information for the sleep mode type, wherein the wake-up delay information is transmitted via M-plane messaging to announce L time slots for the first sleep mode type SM1, M time slots for the second sleep mode type SM-2, and N time slots for the third sleep mode type SM3.

[0206] In step 204, the O-DU applies the supported sleep mode type to the O-RU via a C-plane segment type 4 message or an M-plane command (i.e., via a C-plane segment type 4 message or an M-plane command for activating (i.e., applying) the supported sleep mode type).

[0207] According to the example embodiment set forth in step 201 above, the sleep mode may be a compatible control plane (C-plane) or management plane (M-plane) depending on the sleep duration.

[0208] According to an example embodiment of an advanced sleep mode (ASM) having a short duration (C-plane based) sleep mode and 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 (e.g., hinder) each other.

[0209] Alternatively, in a further step, the O-DU is received from the O-RU via a response C-plane messaging or a response M-plane messaging (i.e., via a C-plane message or an M-plane message, different from the C-plane messaging or the M-plane messaging for activating (i.e., applying) an antenna array model change based on a supported antenna array configuration including at least one antenna array model parameter).

[0210] C-Plane messaging or M-Plane messaging is a response to a change in antenna array configuration to a supported antenna array configuration. In an example embodiment, C-Plane messaging may be a confirmation message that the antenna array configuration has changed to a supported antenna array configuration. In another example embodiment, M-Plane messaging may be a notification that the antenna array configuration has changed to a supported antenna array configuration.

[0211] Figure 3 A method for using wakeup delay information for sleep mode implementation via C-plane segment type 4 message through parameter asmflag is shown. Figure 3 In step 301, the O-DU receives configuration capability information from the O-DU through an M-plane message, where the configuration capability information includes wakeup delay information of the sleep mode type, where the wakeup delay information announces L time slots for the first sleep mode type SM1, M time slots for the second sleep mode type SM2, and N time slots for the third sleep mode type SM-3.

[0212] Example embodiment of O-RU configuration capability information, including wake-up delay information announcement time slot:

[0213]

[0214] Another example embodiment of O-RU configuration capability information includes a wake-up delay information announcement time slot:

[0215]

[0216]

[0217]

[0218] refer to Figure 3The method of using the wake-up delay information for sleep mode implementation via the C-plane segment type 4 message through the parameter asmflag may further include the O-DU applying the supported sleep mode type to a fixed number of time slots defined by at least one of the parameters extnumSlots and numSlots of the C-plane segment type 4 message based on the supported sleep mode type (i.e., applying the C-plane segment model 4 message (st4CmdType) 'TRX-CONTROL / ADVANCED-SLEEP-MODE' including at least one of the parameters extnumSlots and numSlots).

[0219] According to an example embodiment, the total sleep duration in a time slot is the time slot defined by the parameters extnumSlots and numSlots as described above, and the sum of the wake-up delay information for each sleep mode type, which is received by the O-DU from the O-RU via M-plane messaging (i.e., configuration capability information).

[0220] According to another example embodiment, the method of using wake-up delay information for sleep mode implementation via a C-plane section type 4 message through parameter asmflag may further include: the O-DU sending a C-plane section type 4 message to wake up the O-RU from, for example, a first sleep mode type SM1 based on the application of the parameter asmfrag via the C-plane section type 4 message.

[0221] Still refer to Figure 3 , in step 302, the O-DU receives a request to reconfigure the antenna array (eg, a network energy saving request) from a higher layer network function.

[0222] In step 303, the O-DU applies the supported sleep mode type to a fixed number of slots defined by at least one of the parameters extnumSlots and numSlots of the C-Plane Segment Type 4 message (ST4CmdType), wherein the supported sleep mode type is similar to Figure 2 The sleep mode determined in step 203.

[0223] Figure 3 The method of using the wakeup delay information for sleep mode implementation via the parameter asmflag via the C-plane segment type 4 message has the advantage that for sleep modes with undefined sleep duration, there is no need to send the sleep mode command multiple times to update the sleep duration, which saves FH bandwidth. In addition, using the wakeup delay information for sleep mode implementation via the parameter asmflag via the C-plane segment type 4 message provides full flexibility for sleep mode enable / disable and simple implementation within standard messaging with low complexity.

[0224] Furthermore, according to an alternative example embodiment, in step 304, the O-DU applies a parameter asmflag to the O-RU via a C-plane segment type 4 message, wherein the parameter asmflag defines that at least one of SM1, SM2, and SM3 is active for an undefined sleep duration or is active for a defined sleep period.

[0225] Figure 4 A method is shown for sending an interrupt via a C-plane segment type 4 message to wake up the O-RU from a first sleep mode type SM1 and activate the CU plane processing unit after at least one of L time slots of SM1, M time slots of SM2, and N time slots of SM3.

[0226] refer to Figure 4 , in step 401 , the O-DU applies a parameter asmflag to the O-RU via a C-plane segment type 4 message, wherein the parameter asmflag defines that at least one of SM1 , SM2 , and SM3 is active for an undefined sleep duration.

[0227] In step 402, based on the undefined sleep duration, the O-DU sends an interrupt via a C-plane segment type 4 message to wake up the O-RU from at least one of SM1, SM2, and SM3, and activate the CU-plane processing unit after at least one of L time slots of SM1, M time slots of SM2, and N time slots of SM3.

[0228] As a result, according to an example embodiment, the O-DU interrupts the sleep by transmitting at least one of SM1, SM2, and SM3, so that the CU plane processing unit of the O-RU becomes active after at least one of L time slots of SM1, M time slots of SM2, and N time slots of SM3, and thus the O-DU can schedule data accordingly.

[0229] Alternatively, in step 402, according to another embodiment, based on a defined sleep duration, the O-DU applies a CU-plane wake-up command via M-plane messaging within a predetermined sleep duration. For example, the predefined sleep duration for SM1 may be up to 640 time slots. Furthermore, the predefined sleep duration may be based on the sleep mode type and subcarrier spacing as described above (e.g., 11 to 640 time slots for a 960 kHz subcarrier spacing for SM1).

[0230] According to an example embodiment, when the sleep mode is activated for a predefined duration, the CU plane processing unit may be shut down, and then the CU plane processing unit wakes up after the sleep time ends.

[0231] If the sleep duration is significantly longer than the wakeup duration of the CU plane processing unit, the CU plane processing module may be shut down.

[0232] In addition, when the O-RU is in sleep mode for a predefined duration, the CU plane processing unit is turned off, and if the O-DU needs to interrupt the sleep, it can send an M-plane wake-up command (i.e., an emergency wake-up command) to the O-RU to wake up the CU plane processing unit.

[0233] In response to the above wake-up command, the O-RU may send a notification to the O-DU to indicate that the CU plane processing unit wake-up is complete.

[0234] Figure 5 A method for implementing sleep mode implementation from the O-RU perspective through control plane section type 4 messaging is shown. Figure 5 The O-RU transmits (e.g., 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 or management plane (M-plane) messaging, and reconfigures the antenna array antenna model based on the antenna array configurations supported by the O-RU.

[0235] In step 501, the O-RU sends configuration capability information via a management plane (M-plane) command. According to an example embodiment, in step 201, upon power-up, the O-RU transmits (e.g., sends) its configuration capability information to the O-DU via the M-plane, the configuration capability information including wake-up delay information (i.e., Yang model data parameters included by the Yang model) for a sleep mode type required to perform antenna array reconfiguration, wherein the wake-up delay information is communicated via M-plane messaging to announce L time slots for a first sleep mode type SM1, M time slots for a second sleep mode type SM2, and N time slots for a third sleep mode type SM3.

[0236] In another example embodiment, the O-RU exposes (reports) its capability data (including antenna configuration capability information) to the O-DU via a 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 advanced sleep mode, etc.). In another example embodiment, the O-RU communicates (e.g., sends) a plurality of supported antenna models (e.g., antenna models defined by antenna array model parameters) / configurations (i.e., antenna configuration capability information) to the O-DU through the M-plane.

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

[0238] According to an example embodiment, antenna configuration capability information (O-RU antenna configuration capability information) may be hard-coded by the supplier during the production process along with at least one of the following parameters: a unique name, an index, a reference, etc., to identify the antenna array configuration capability (e.g., technical specifications of the antenna array), the number of spatial streams / layers supported by each configuration of the antenna array, antenna calibration data applied by the O-RU during configuration changes, energy savings achievable with reference to each configuration, associated beam weights (predefined beam weights), etc. In an example embodiment, when the O-RU is powered on (initialized), the O-RU begins reporting supported energy saving modes (i.e., antenna array configuration capability information) and the hard-coded antenna array model and other initialization parameters to the O-DU using an M-plane YANG model (e.g., urn:o-ran:module-cap:1.0 and an urn:o-ran:hardware:1.0).

[0239] According to an embodiment, according to 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 the energy-saving features supported in the associated YANG model as Yang features, such as O-RAN-wg4-features.yang is indicated as low-order network functions and / or high-order network functions other than the O-RU (i.e., O-RU controller, such as O-DU and / or SMO, SMO framework, etc.).

[0240] To this end, the O-DU may use YANG feature name tags to identify the functions 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, etc.

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

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

[0243] The YANG feature name tag HIBERNATE-SLEEP may describe O-RU power saving achieved by shutting down the carrier and associated O-RU circuits / components for a longer duration, where the longer duration allows for implementing optional feature control as an M-plane based sleep mode to achieve hardware / component / power saving compared to other sleep modes.

[0244] The YANG feature name tag LIGHT-HIBERNATE-SLEEP may describe enabling O-RU power savings by shutting down the carrier and associated O-RU circuitry / components for longer durations without shutting down synchronization, where the longer duration allows for implementing optional feature control as an M-plane based sleep mode to achieve hardware / component / power savings compared to other sleep modes.

[0245] The YANG feature name tag DEEP-HIBERNATE-SLEEP may describe O-RU power saving achieved by shutting down the carrier and associated O-RU circuits / components for longer durations of time compared to other sleep modes, where the longer duration allows for optional feature control to be implemented as an M-plane based sleep mode to achieve hardware / component / power savings.

[0246] According to example embodiments, various short-duration (C-plane based) sleep modes may be defined with reference to the YANG feature name tag ADVANCED-SLEEP-MODE or SLEEP-MODE. For example, the advanced sleep mode may be used for shorter sleep durations, such as milliseconds, seconds, or minutes, and may be activated, for example, using an ST4 C-plane message via control plane (C-plane) messaging.

[0247] According to an example embodiment, referring to the YANG feature name tag HIBERNATE-SLEEP for longer durations, the hibernation sleep mode may be activated by employing the M-plane, for example, by setting the parameter +--rw energy-saving-enabled? boolean{ENERGYSAVING}? to "true" or "yes" in the corresponding o-ran-hardware.yang module.

[0248] According to an example embodiment, referring to the YANG feature name tags LIGHT-HIBERNATE-SLEEP and DEEP-HIBERNATE-SLEEP, in order to distinguish between longer sleep with and without shutting down the sync plane circuit, the light hibernate sleep mode with synchronization and the deep hibernate sleep mode without synchronization may be implemented in the same manner as hibernate sleep by employing the M-plane, for example, by setting the parameter +--rw energy-saving-enabled? boolean{ENERGYSAVING}? to "true" or "yes" in the corresponding o-ran-hardware.yang module.

[0249] With reference to the O-RU reporting to the O-DU and / or SMO based on the yang module, for example, as specified in the 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 of SM#0<SM#1<SM#2<SM#3) has different wake-up times, or if the wake-up time is too short, has a defined sleep entry 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 mode that does not involve any synchronization or a hibernation sleep mode with or without synchronization, while light hibernation sleep refers to an M-plane based sleep mode with synchronization, and deep hibernation sleep refers to an M-plane based sleep mode without synchronization).

[0250] According to an embodiment, the advanced sleep modes (ASM) have a wake-up time (minimum or guaranteed) for each sleep mode. The shortest mode (e.g., SM#0) among the C-plane-based sleep modes may not be defined by a minimum or guaranteed wake-up time, but by the sleep entry time.

[0251] The O-RU reporting to the O-DU and / or SMO based on the YANG module (e.g., as specified in o-ran-module.cap.yang) may also support C-plane messages, such as Segment Type 8 (ST8) "Ready" messages and C-plane messages including a range of commands (e.g., CARRIER-COMMAND, ARRAY-COMMAND, O-RU-COMMAND), such as Segment Type 4 (ST4) messages).

[0252] The O-RU reporting to the O-DU and / or SMO based on the YANG module (e.g., as specified in o-ran-module.cap.yang) may also support sleep duration extension and emergency wakeup through M-plane and / or C-plane messaging.

[0253] Additionally, the O-RU reporting to the O-DU and / or SMO based on the YANG module (e.g., as specified in o-ran module.cap.yang) may also provide information such as the percentage of energy savings that can be achieved.

[0254] In addition, the O-RU reporting to the O-DU and / or SMO YANG module (e.g., as specified in o-ran module.cap.yang) may also support notification messaging of the CU plane active or inactive state, for example, to support notification that may be required to ensure that the CU plane becomes active after the sleep duration expires (i.e., the CU plane circuitry may be shut down in the case of defined, undefined, and / or longer sleep durations). To this end, the O-RU reporting to the O-DU and / or SMO supports notification of the CU plane state from the O-RU to the O-DU in the event that the CU plane is shut down during any sleep mode activation period.

[0255] To this end, in the O-RU, similar to the existing M-plane model (for example, similar to the energy saving of the transmission blanking parameter that the O-RU can send to the O-DU), a modified parameter set can be defined to enable the O-RU to report energy saving parameters, such as energy saving through RF channel reconfiguration, energy saving through advanced sleep mode, energy saving without modifying spatial streams, etc., so as to report the supported energy saving modes (i.e., antenna array configuration capability information) and hard-coded antenna array models and other initialization parameters to the O-DU.

[0256] Furthermore, in an example embodiment, to ensure backward compatibility, if the O-RU does not support the custom configuration or RF channel reconfiguration / antenna array selection method of the ES according to its hard-coded configuration provider as described above, the O-RU may mark the aforementioned energy saving mode flag (e.g., urn:o-ran:module-cap:1.0 and an urn:o-ran:hardware:1.0) as false in the M-plane YANG model.

[0257] According to an example embodiment, a TRx control method for reconfiguring an 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), wherein antenna mask bit combinations may be limited to supported TRx configurations, wherein the antenna mask bits identify antenna elements to be turned off as "0" and identify active elements of the antenna array as "1". In addition, in addition to the mask bits for the at least one antenna mask (antMask), the TRx control configuration also includes array layer mask bits for creating at least one array layer mask (antLayerMask).

[0258] According to an example embodiment, the supported TRx control configurations may include a transition time (i.e., different from the wake-up time of the ASM) that 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). The transition time associated with each configuration change of the supported TRx control configuration and as a function of the subcarrier spacing may be, for example, 1 millisecond for a 15KHz slot, 0.5 milliseconds or 500 microseconds for a 30KHz slot, and so on.

[0259] According to example embodiments, the TRx control method may include control of turning on / off an entire RF transceiver chain and / or a radio frequency (RF) front end (RFFE) of a radio frequency (RF) processing unit associated with some of the RF channels / antenna elements.

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

[0261] According to an embodiment of an advanced sleep mode (ASM) having a short duration (C-plane based) sleep mode and 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 (e.g., hinder) each other.

[0262] In step 502, the O-RU receives the sleep mode types supported by the O-RU via a C-plane segment type 4 message or an M-plane command. The supported sleep mode types are based on the O-RU's configuration capability information and a request to reconfigure the antenna array from a higher-layer network function.

[0263] According to the example embodiment set forth in step 502, the sleep mode may be control plane (C-plane) and / or management plane (M-plane) compatible depending on the sleep duration.

[0264] According to an embodiment 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), 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 method (e.g., during transition from one antenna array model to another antenna array model considering the transition time (i.e., wake-up delay for antenna configuration change)) may be different and do not interfere with (e.g., hinder) each other.

[0265] According to an embodiment of the TRx control method (e.g., changing the antenna array model over 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 antenna array configuration can be activated via control plane (C-plane) messaging and / or via management plane (M-plane) messaging.

[0266] In step 503, the O-RU activates the sleep mode type to the O-RU's part based on the supported sleep mode type determined by the O-DU.

[0267] Alternatively, in a further 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 a supported antenna array model to the O-DU via C-plane messaging or M-plane messaging.

[0268] In an example embodiment, C-plane messaging may be a confirmation message that the antenna array configuration has changed (i.e., the antenna array model has changed) to a supported antenna array configuration. In another example embodiment, M-plane messaging may be a notification that the antenna array configuration has changed to a supported antenna array configuration.

[0269] 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 (e.g., the second antenna array configuration). The notification may be sent to the O-DU via the layered architecture of the O-RAN, or may be sent to a higher-layer network function (e.g., SMO, RIC, etc.) via the hybrid architecture of the O-RAN.

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

[0271] Figure 6 A method for using wakeup delay information for sleep mode implementation via the parameter asmflag via a C-plane segment type 4 message is shown. Figure 6 In step 601, the O-RU sends configuration capability information, which also includes wake-up delay information for sleep mode types, where the wake-up delay information is passed via M-plane messaging to announce L time slots for the first sleep mode type SM1, M time slots for the second sleep mode type SM2, and N time slots for the third sleep mode type SM3.

[0272] In step 602 , the O-RU receives a parameter asmflag to the O-RU via a C-Plane Segment Type 4 message, wherein the parameter asmflag defines that at least one of SM1 , SM2 , and SM3 is active for a defined sleep duration.

[0273] In step 603 , the O-RU deactivates the CU plane (ie, deactivates the CU plane processing unit of the O-RU) based on the defined sleep duration.

[0274] To this end, in case the O-DU applies (ie commits to) a defined sleep duration, the O-RU may shut down the CU plane to achieve additional energy savings.

[0275] Alternatively, in step 603, the O-RU sends an ACK / NACK message via C-plane segment Type 8 messaging, where the ACK message signals the O-DU to start scheduling CU-plane data. The O-RU sends the ACK / NACK message via C-plane segment Type 8 messaging based on the defined sleep duration and the predetermined sleep duration.

[0276] For example, the predefined sleep duration for SM1 may have a limit of up to 640 time slots. Furthermore, the predefined sleep duration may be based on the sleep mode type and subcarrier spacing as described above (e.g., 11 to 640 time slots for a subcarrier spacing of 960 kHz for SM1).

[0277] According to an example embodiment, for long sleep durations, as an optional capability, CU-plane wakeup based on the M-plane can be employed, and C-plane messaging can include ACK / NACK messages (segment type 8). C-plane ST 8 messaging can be used to ensure O-RU availability, as wakeup latency can vary depending on environmental conditions and O-RU design. Based on the received ACK message, the O-DU can start scheduling CU-plane data.

[0278] Therefore, the ACK / NACK of the segment type 8 message can be used to indicate whether the CU plane is active.

[0279] Figure 7 A method for disabling logical radio frequency components (FPGA, RFIC) and RF front end module (RFFE) components depending on wake-up delay information is shown.

[0280] refer to Figure 7 , in step 701 , the O-RU receives a parameter asmflag to the O-RU via a C-plane segment type 4 message, wherein the parameter asmflag defines that at least one of SM1 , SM2 , and SM3 is active for an undefined sleep duration.

[0281] In step 702, the O-RU deactivates the logical radio frequency components (FPGA, RFIC) and the RF front-end module (RFFE) based on the wake-up delay information. The O-RU's partial deactivation is based on an undefined sleep duration. If the sleep duration is undefined, the O-RU can either keep the CU plane active or shut it down. If the CU plane is shut down, an M-plane-based wake-up is used.

[0282] To this end, if the O-DU does not promise a sleep duration (i.e., the O-DU does provide a supported sleep mode type with a defined sleep duration), the O-RU can keep the C-plane processing unit active, for example, the C-plane processing unit remains "on" during sleep to ensure the KPI. However, depending on the wake-up latency, the O-RU can shut down all major power-consuming devices, such as FPGA, RFIC, RFFE components, etc.

[0283] Figure 8An M-Plane messaging method according to an embodiment is shown, which includes at least one Yang model for capability reporting of sleep modes (eg, advanced sleep modes) and associated parameters. Figure 8 The O-RU reports its ability to implement sleep mode based on the Yang model, which is used to report the sleep mode capabilities to the O-DU. Based on the sleep mode, the parameters and requirements of the O-RU may be 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 sleep mode).

[0284] The definition of Sleep Mode (SM) is shown in the following table.

[0285]

[0286] Referring to the table above, the number of time slots is calculated taking into account 15KHz SCS.

[0287] Regarding sleep modes (eg, advanced sleep modes), advanced sleep modes having minimum sleep durations may be activated and deactivated, and the minimum duration for each sleep mode may be exchanged between the O-RU and the O-DU.

[0288] Regarding sleep mode, the achievable energy savings are either reported by the O-RU or monitored by the O-DU.

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

[0290] In addition, regarding the sleep mode (SM4) with undefined sleep, the O-RU can send a notification for confirming wakeup.

[0291] The O-DU defines the wake-up time for the sleep mode (SM4) with undefined sleep based on the wake-up time notified and / or confirmed by the O-RU.

[0292] In addition, for sleep mode with undefined sleep (SM4), the O-DU can provide notification of the CU plane active or inactive status to ensure that the CU plane is active after the sleep procedure time ends.

[0293] According to another example embodiment of the use case RF channel reconfiguration (i.e., RF channel closing / opening), a sub-use case may be defined as sleep. For this sub-use case, the O-RU receives antenna array configurations supported by the O-RU from the O-Du via management plane (M-plane) messaging, wherein the supported antenna array configurations include at least one command in which the O-DU sets power saving enable to "true" using the "O-run.htmel.yang" module in addition to other commands for activating and deactivating the O-RU, and the O-DU sends a value of "SLEEP" or "INACTIVE" to the O-RU. <rpc> <edit-config>The O-RU then changes the [tr]x-array-carrier::ACTIVE> command to put the carrier into sleep or deactivate. The O-RU then changes the [tr]x-array-carrier::STATE to DISABLED via BUSY. This command instructs the O-DU to use appropriate RPCs (i.e., <edit-config> and <delete-config>) to deconfigure or remove the carrier(s) in the O-RU, or instructs the O-RU to perform this operation itself during long sleep through its internal logic (for example, this command can provide more energy savings because the associated circuits can be turned off). If all carriers are removed / deconfigured during sleep (long / deep) sleep, the C-plane, U-plane, and S-plane are turned off. The O-RU itself and its internal logic can shut down the C-plane, U-plane, S-plane and M-plane circuits by sending appropriate commands / RPCs, and the O-DU can shut down the C-plane, U-plane, S-plane and M-plane circuits, the command to shut down the M-plane (Netconf supervision monitoring) and the command to shut down the CU-plane monitoring circuit (for example, in the case of long-duration energy saving, the shutdown command of the monitoring circuit can be applied to energy saving use cases based on both TRx control and advanced sleep mode). The O-RU sends an RPC reply to the O-DU to indicate the correct reception of the above RPC commands by sending "ok".

[0294] In an example embodiment, the Yang model for reporting the capability of CU plane circuit activity status (wake up from sleep) may have an o-ran-module-cap.Yang structure including parameters as summarized below.

[0295] The format of the module function module is as follows

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

[0297] |+--ro energy-saving-by-trx-control boolean / / TRx control–variousantenna configuration for energy savings

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

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

[0300] ||+--ro micro-sleep-mode-supported?Boolean / / O-DU read this response(either‘Yes’or‘No’)and get to know whether O-RU supports micro sleep or not–Option#1

[0301] ||+---n micro-sleep-mode-supported / / Notification to indicate whethermicro-sleep mode supported or not–Option#2

[0302] |+--ro CU-plane-active-state enum / / this capability to indicate CU-Plane circuit is awake and active to receive messages from O-DU.For example,during sleep mode,CU-Plane circuit turned off sometime and wake-up.With thecurrent notification framework,only carrier active state is being reported byO-RU to O-DU.It is required to notify O-DU that CU-Plane is waked up fromsleep and active before hand,so that O-DU can start scheduling CU-Planepackets.

[0303] |+--ro eaxcid-grouping-capabilities{o-ran-module-cap:EAXC-ID-GROUP-SUPPORTED}?

[0304] In an example embodiment, a Yang model for reporting the capabilities of supported advanced sleep modes and associated parameters (e.g., advanced sleep modes) may have an o-ran-module-cap.Yang structure that includes parameters summarized as follows: o-ran-uplan-conf.yang module

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

[0306] |+--rw tx-array-carrier-> / user-plane-configuration / tx-array-carriers / name / / advanced sleep modes

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

[0308] |+--ro sleep-mode#0:SM0 string

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

[0310] |||+--ro minimum-sleep-duration decimal / uint16 / / symbol time

[0311] ||+--ro achievable-energy-saving decimal64 / / achievable energy savingsbased on O-RU design, sleep mode, and environmental condition

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

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

[0314] |||+--ro minimum-sleep-duration decimal / uint16 / / Tslot–slot time inmicroseconds

[0315] ||+--ro achievable-energy-saving decimal64 / / achievable energysavingsbased on O-RU design,sleep mode,and environmental condition

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

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

[0318] |||+--ro minimum-sleep-duration decimal / uint16 / / 1 Radio frame(10ms)||+--ro achievable-energy-saving decimal64 / / achievable energy savingsbased onO-RU design,sleep mode,and environmental condition

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

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

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

[0322] ||+--ro achievable-energy-saving decimal64 / / achievable energysavingsbased on O-RU design, sleep mode, and environmental condition

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

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

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

[0326] ||+--ro wake-up-time decimal64 / / wakeup time range based on O-RUdesign, sleep mode duration, and environmental condition

[0327] ||+--ro achievable-energy-saving decimal64 / / achievable energy savingsbased on O-RU design, sleep mode, and environmental condition

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

[0329] According to an embodiment of an advanced sleep mode (ASM) having a short duration (C-plane based) sleep mode and 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 (e.g., hinder) each other.

[0330] In addition, common capability parameters for both TRx control methods and sleep modes (e.g., advanced sleep mode) reported to the O-DU via the M-plane regarding the O-RU configuration capability information may include a C-plane ST8 "ready" message and sleep duration extension (e.g., in a defined sleep scenario, if the O-DU needs to extend the sleep mode, it sends a sleep extension command before the wake-up time begins). If the CU plane remains active, for short sleep times, the extension command can be based on the C-plane. If the CU plane is turned off, for long sleep times, the extension command can be based on the M-plane.

[0331] In addition, the public capability parameters of the TRx control method and sleep mode (e.g., advanced sleep mode) reported to the O-DU via the M-plane regarding the O-RU configuration capability information may include emergency wakeup of the O-RU from sleep. The O-RU may report this capability 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. While the CU plane remains active, for short sleep times, the emergency wakeup command may be based on the C-plane (defined or undefined). While the CU plane is turned off, for long sleep times, the emergency wakeup command may be based on the M-plane (defined or undefined).

[0332] According to an example embodiment, when the sleep mode is activated for a predefined duration, the CU plane processing unit may be shut down, and then the CU plane processing unit wakes up after the sleep time ends.

[0333] If the sleep duration is significantly longer than the wakeup duration of the CU plane processing unit, the CU plane processing unit may be shut down.

[0334] In addition, when the O-RU is in sleep mode for a predefined duration, the CU plane processing unit is turned off, and if the O-DU needs to interrupt the sleep, it can send an M-plane wake-up command (i.e., an emergency wake-up command) to the O-RU to wake up the CU plane processing unit.

[0335] In response to the above wake-up command, the O-RU may send a notification to the O-DU to indicate that the CU plane processing unit wake-up is complete.

[0336] According to an example embodiment, o-ran-module-cap.yang is used for CU plane status reporting in addition to other YANG models (for example, for implementing O-RU functionality for defined and undefined sleep modes). o-ran-module-cap.yang includes information that enables the CU plane circuitry to be shut down for additional energy saving. The information may include the name identifier and status identifier of the rx array carrier, and 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, 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.

[0337] In an example embodiment, a Yang model indicating that a CU plane becomes active from a sleep state may have an o-ran-uplan-conf.yangs structure including parameters as summarized below.

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

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

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

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

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

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

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

[0345] |+--ro state? -> / user-plane-configuration / cu-plane / state; The state can be active, sleep, and inactive / disabled

[0346] Figure 9 A flowchart showing the M-Plane / C-Plane messaging between the O-RU and O-DU for the sleep mode use case is shown. Figure 9 In operation 1, the O-RU provides the O-DU with a list of supported sleep modes (e.g., advanced sleep modes) and their minimum sleep durations (i.e., the configuration capability information reported by the O-RU to the O-RU via M-plane messaging may include a list of supported sleep modes (e.g., advanced sleep modes) and their minimum sleep durations).

[0347] In operation 2, the O-RU provides the O-DU with energy savings achievable by each sleep mode (eg, each sleep mode provided in operation 1 may refer to an array configuration).

[0348] In operation 3, for the case of a sleep mode with undefined sleep (ie, for SM4), the O-RU provides the O-DU with a wakeup time from the sleep state to the active state for the undefined sleep (ie, for the sleep mode SM4).

[0349] Generally speaking, the above operations 1 to 3 refer to reporting the O-RU capabilities to the O-DU (ie, the O-DU receives the configuration capability information of the O-RU).

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

[0351] 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 sleep mode used). The dispatch of the ST4 message ("sleepMode" and "Tsleep") is based on a higher-layer network function request or the O-DU itself decides to activate sleep mode.

[0352] In operation 6, the O-RU receives the sleep command via an ST4 message with an explicit duration and processes it. In an example embodiment, for a sleep mode with indeterminate 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 messaging (i.e., carrier deactivation).

[0353] In operation 7, the O-RU provides the O-DU with an O-RU send notification to confirm the success / failure of the sleep mode activation to the O-DU.

[0354] In operation 8, in the event of a failure during sleep mode activation, the O-DU may either retry sleep mode activation or take appropriate action (e.g., reporting to a higher layer network function, initiating a failsafe procedure, etc.). In an example embodiment, the O-RU may respond to the action requested by the O-DU in operation 8, depending on the action of the O-DU in the event of the failure.

[0355] In operation 9, the O-RU uses the performance counter "epe stats" via the M-plane to provide the O-RU with power consumption reports based on the O-DU's subscription of the "epe stats" counter to the O-RU.

[0356] The O-DU monitors the power consumption during each sleep mode / sleep duration in operation 10. In addition, the O-DU either forwards the power consumption data to higher layers or calculates the energy saving of each sleep mode for future reference.

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

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

[0359] Figure 10 FIG2 shows a flowchart of a sleep mode implementation for sleep mode type SM1. Figure 10 In operation 1, the O-RU sends wake-up delay information to the O-DU as part of the configured capability information. For example, the O-RU capabilities reported to the O-DU via the M-plane include L time slots for a first sleep mode type SM1, M time slots for a second sleep mode type SM2, and N time slots for a third sleep mode type SM3, advertising a minimum sleep duration / wake-up delay. Alternatively, the configured capability information includes U time slots of undefined sleep duration for an undefined sleep mode type.

[0360] According to an embodiment, the configuration capability information may include 14 different sleep duration values that the M-plane configures for sleep over 255 time slots.

[0361] In operation 2A, according to example embodiment case #1a, the O-DU sends a first sleep mode type (SM1) activation request to the O-RU via a C-plane segment type 4 message. According to an embodiment, a radio frame is 15 kHz and is approximately 10 slots long. In this case, the O-RU sleeps for 30 slots (10 slots (sleep duration) + 20 slots (wake-up delay)). In operation 3A, the O-RU wakes up after the defined sleep duration of 30 slots.

[0362] In operation 2B, according to example embodiment case #1b, the O-DU sends a first sleep mode type (SM1) activation request to the O-RU via a C-plane segment type 4 message (ST4 msg). According to an embodiment, a radio frame is a 120 kHz radio frame with a length of approximately 80 slots. In this case, the O-RU sleeps for 100 slots (80 slots (sleep duration) + 20 slots (wake-up delay)). In operation 3B, the O-RU wakes up after the defined sleep duration of 100 slots.

[0363] According to example embodiments, Case #1a and Case #1b, the O-DU schedules a sleep duration of up to 255 slots (SM1 > L slots). According to example Case #1a and Case #1b, L is equal to 20 slots (i.e., the minimum sleep duration for SM1), where the subcarrier spacing (SCS) is defined as 15 kHz and 120 kHz. Therefore, the sleep duration of the radio frame in Case #1a is 10 slots for a 15 kHz SCS, and the sleep duration of the radio frame in Case #1a is 80 slots for a 120 kHz SCS.

[0364] In operation 4, according to example embodiment case #2, the O-DU may send a sleep mode (SM1) activation request via a C-plane ST4 msg. According to an embodiment, the sleep duration may refer to four radio frames, where one radio frame refers to 120 kHz and is approximately 320 slots long. However, in this case, the O-RU sleeps for 340 slots (320 slots (sleep duration) + 20 slots (wake-up delay)). Therefore, for the above settings, the O-RU will wake up very late because L = 20 slots (the minimum sleep duration for SM1) must be considered.

[0365] To this end, in operation 5, as an alternative to case #2 of the example embodiment, for example, the O-DU checks 14 sleep values and may not find an exact sleep duration that matches the above example (i.e., 4 radio frames @ 120KHz SCS, 320 time slots), so the O-DU determines the closest sleep duration value supported by the O-RU, such as 430 time slots.

[0366] As a result, in operation 5, the O-DU sends a sleep mode (SM1) activation request of 430 time slots via a C-plane ST4 message, where the 430 time slots are part of the M-plane configuration sleep value sent together with the configuration capability information, such as in operation 1.

[0367] In operation 6, in order to match the 340 time slots (320 time slots (sleep duration) + 20 time slots (wake-up delay)) of the example embodiment case #2 described above, the O-DU sends an interrupt via a C-plane segment type 4 message to wake up the O-RU from the first sleep mode type SM1 after 320 time slots (sleep duration). For example, the O-RU starts to activate after 320 time slots (sleep duration), and the CU plane is in the active state after L time slots (i.e., 20 time slots (wake-up delay)).

[0368] Therefore, in operation 7, the O-RU wakes up after a sleep duration of 340 time slots (ie, 320 time slots (sleep duration) + 20 time slots (wake-up delay)) and is in an active state.

[0369] According to operations 5 and 6, the O-DU schedules sleep for any of 14 different sleep duration values advertised by the O-RU via the M-plane, where the O-RU can keep the CU plane (i.e., C-plane) active or shut it down.

[0370] Figure 11 FIG2 shows a flowchart of a sleep mode implementation for sleep mode type SM3. Figure 11 In operation 1, the O-RU sends wake-up delay information to the O-DU as part of the configured capability information. For example, the O-RU capabilities reported to the O-DU via the M-plane include L time slots for a first sleep mode type SM1, M time slots for a second sleep mode type SM2, and N time slots for a third sleep mode type SM3, advertising a minimum sleep duration / wake-up delay. Alternatively, the configured capability information includes U time slots of undefined sleep duration for an undefined sleep mode type.

[0371] According to an embodiment, the configuration capability information may include 14 different sleep duration values that the M-plane configures for sleep over 255 time slots.

[0372] In operation 2A, according to example embodiment case #1a, the O-DU sends a third sleep mode type (SM3) activation request to the O-RU via a C-Plane Segment Type 4 message. According to an embodiment, a radio frame is 15 kHz and is approximately 10 slots long. In this case, the O-RU sleeps for 110 slots (10 slots (sleep duration) + 100 slots (wake-up delay)). In operation 3A, the O-RU wakes up after the defined sleep duration of 110 slots.

[0373] In operation 2B, according to example embodiment case #1b, the O-DU sends a third sleep mode type (SM3) activation request to the O-RU via a C-plane segment type 4 message (ST4 msg). According to an embodiment, a radio frame is a 120 kHz radio frame with a length of approximately 80 slots. In this case, the O-RU sleeps for 180 slots (80 slots (sleep duration) + 110 slots (wake-up delay)). In operation 3B, the O-RU wakes up after the defined sleep duration of 180 slots.

[0374] According to example embodiments, Case #1a and Case #1b, the O-DU schedules a sleep duration of up to 255 slots (SM3 > N slots). According to example Case #1a and Case #1b, N is equal to 100 slots (i.e., the minimum sleep duration for SM3), where the subcarrier spacing (SCS) is defined as 15 kHz and 120 kHz. Therefore, the sleep duration of the radio frame in Case #1a is 10 slots for a 15 kHz SCS, and the sleep duration of the radio frame in Case #1a is 80 slots for a 120 kHz SCS.

[0375] In operation 4, according to example embodiment case #2, the O-DU may send a sleep mode (SM1) activation request via a C-plane ST4 msg. According to an embodiment, the sleep duration may refer to four radio frames, where one radio frame refers to 120 kHz and is approximately 320 slots long. However, in this case, the O-RU sleeps for 420 slots (320 slots (sleep duration) + 100 slots (wake-up delay)). Therefore, for the above setting, the O-RU will wake up very late because N = 100 slots (the minimum sleep duration for SM3) must be considered.

[0376] To this end, in operation 5, as an alternative to case #2 of the example embodiment, for example, the O-DU checks 14 sleep values and may not find an exact sleep duration that matches the above example (i.e., 4 radio frames @ 120KHz SCS, 320 time slots), so the O-DU determines the closest sleep duration value supported by the O-RU, such as 430 time slots.

[0377] As a result, in operation 5, the O-DU sends a sleep mode (SM1) activation request of 430 time slots via a C-plane ST4 message, where the 430 time slots are part of the M-plane configuration sleep value sent together with the configuration capability information, such as in operation 1.

[0378] In operation 6, the O-DU sends an interrupt via a C-plane segment type 4 message to wake up the O-RU from the first sleep mode type SM1 after 320 time slots (sleep duration) to match the 420 time slots (320 time slots (sleep duration) + 100 time slots (wake-up delay)) of the example embodiment case #2 described above. For example, the O-RU starts to activate after 320 time slots (sleep duration), and the CU plane is in the active state after N time slots (i.e., 100 time slots (wake-up delay)).

[0379] Therefore, in operation 7, the O-RU wakes up after the sleep duration of 420 time slots (ie, 320 time slots (sleep duration) + 100 time slots (wake-up delay)) and is in the active state.

[0380] According to operations 5 and 6, the O-DU schedules sleep for any of 14 different sleep duration values advertised by the O-RU via the M-plane, where the O-RU can keep the CU plane (i.e., C-plane) active or shut it down.

[0381] Figure 12 The sleep mode implementation according to the Segment Type 4 Command Type (ST4CmdType) TRX CONTROL is shown. Figure 12 , sleep modes have different sleep depths.

[0382] refer to Figure 12 The TRX CONTROL command type is consistent with the segment type 4 command type (ST4CmdType), wherein the command common header format includes 8-bit fields (ie, octet fields). The command common header format includes various headers, each header including one or more header fields (ie, header octets).

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

[0384] 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 (ie, the number of bytes from octet 9 to octet 16 is 8).

[0385] 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 the 8-byte sequence of the 17th octet (ie, the number of bytes from octet 17 to octet 24 is 8).

[0386] The fourth header field is occupied by the Multiple Command Segment Type 4 header, which is a one-byte sequence referring to the 25th octet (ie, the byte number of octet 25 is 1).

[0387] The Multiple Command Segment Type 4 header includes the direction identifier bothDir at the most significant bit position 0 and the shutdown field at bit position 1. Furthermore, bit positions 2 to 5 of the Multiple Command Segment Type 4 header refer to the sleep mode type sleepDurIndex field identifier (i.e., [sleepDurIndex3:0]). Bit positions 6 and the least significant bit, i.e., bit position 7, refer to the sleep depth of the advanced sleep mode (i.e., sleepDepth[1:0]) in the 25th octet (i.e., the byte number of octet 25 is 1).

[0388] The fifth header field may consist of a one-byte sequence of a reserved field and the 26th octet (ie, the byte number of octet 26 is 1).

[0389] The one-byte sequence of the 26th octet in the fifth header field may be occupied by the log2maskbits header (ie, log2maskbits[3:0]). The log2maskbits header command header refers to the one-byte sequence of the 26th octet (ie, the byte number of octet 26 is 1).

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

[0391] The seventh header field is occupied by the antenna mask antMask command header (i.e., antMask[x:0] - only present when cmdScope=ARRAY-COMMAND). The antMask header refers to the 8-byte (64-bit) sequence starting with the 29th octet (i.e., the number of bytes is variable (e.g., a 2-byte field from octet 28 to octet 29)).

[0392] According to an example embodiment, a TRx control process for reconfiguring an 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), wherein antenna mask bit combinations may be limited to supported TRx configurations, wherein the antenna mask bits identify antenna elements to be turned off as "0" and identify active elements of the antenna array as "1." In addition, in addition to the mask bits for the 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).

[0393] According to an example embodiment, the supported TRx control configurations may include a transition time (i.e., a wake-up time different from the ASM) that 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 (i.e., wake-up time) associated with each configuration change of the supported TRx control configuration and as a function of the subcarrier spacing may be, for example, 1 millisecond for a 15KHz slot, 0.5 milliseconds or 500 microseconds for a 30KHz slot, and so on.

[0394] According to example embodiments, the TRx control process may include control of turning on / off an entire RF transceiver chain and / or a radio frequency front end (RFFE) of a radio frequency (RF) processing unit associated with some of the RF channels / antenna elements.

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

[0396] According to an embodiment of an advanced sleep mode (ASM) having a short duration (C-plane based) sleep mode and 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 TRx control can be different and do not interfere with (e.g., hinder) each other.

[0397] Figure 13 The sleep mode implementation according to the section type 4 command type (ST4CmdType) st4CmdType'TRX-CONTROL / ADVANCED-SLEEP-MODE' is shown.

[0398] refer to Figure 13 According to the st4CmdType 'TRX-CONTROL / ADVANCED-SLEEP-MODE' configured for the TRX CONTROL command type, the first header field is occupied by the transport header. The transport header refers to the 8-byte sequence of the first octet (i.e., the number of bytes from octet 1 to octet 8 is 8).

[0399] 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 (ie, the number of bytes from octet 9 to octet 16 is 8).

[0400] 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 the 8-byte sequence of the 17th octet (ie, the number of bytes from octet 17 to octet 24 is 8).

[0401] The fourth header field is occupied by a multiple command section type 4 header, which refers to a 3-byte sequence of the 25th octet (ie, the number of bytes from octet 25 to octet 27 is 3).

[0402] The multiple command segment type 4 header includes the direction identifier bothDir in the most significant MSB 0-bit position of the 25th octet, followed by the OnOff field, the 1-bit symbolMask[0:1] field, the 1-bit advanced sleep mode flag asmflag[0:1], the 16-bit eAxCmask[0:15] field, and the 1-byte sleepDepth[1:0] (i.e., the number of bytes from octet 25 to octet 27 is 3).

[0403] The fifth header field is occupied by a multiple command segment type 4 header, which refers to a 4-byte sequence of the 28th octet (ie, the number of bytes from octet 28 to octet 31 is 4).

[0404] The multi-command section type 4 header includes an extnumSlots[0:15] field, a symbolMask[0:11] field, and a log2maskbits[3:0] field of the 28th octet (ie, the number of bytes from octet 28 to octet 31 is 3).

[0405] The parameter "extnumSlots" can be used to select any defined sleep duration, as well as the "numSlots" in the public header, which provides full flexibility and thus may not be needed Figure 12 In the C plane, the "sleepDurIndex" of st4CmdType'TRX-CONTROL' is used.

[0406] According to an example embodiment, the total sleep duration in a time slot may be the sum of the values of the parameters extnumSlots, numSlots, and the wakeup delay (number of time slots), where the latter is reported for each sleep mode via M-plane messaging (i.e., provided via the configuration capability information of the M-plane messaging). In addition, for the defined sleep duration, the CU plane may be shut down to save additional energy.

[0407] According to an example embodiment of the sleep mode SM1, in the case where the sleep duration is 4 radio frames (i.e., 40 ms), the wake-up delay of SM1 refers to L, which is equal to 20 slots. Therefore, for a subcarrier spacing (SCS) equal to 15 kHz, the total sleep duration is equal to 60 slots (40 slots + 20 slots (wake-up delay)). Therefore, for a sleep duration in slots equal to 60 slots (@15 kHz SCS), the total sleep duration in slots is calculated as follows: extnumSlots(0)+numSlots(40)+L(20 slots).

[0408] According to another example embodiment of the sleep mode SM1, for an SCS equal to 120 kHz, the total sleep duration is 340 slots (320 slots + 20 slots (wake-up delay)). Therefore, for a sleep duration in slots equal to 340 slots (@ 120 kHz SCS), the total sleep duration in slots is calculated as follows: extnumSlots(65)+numSlots(255)+L(20 slots).

[0409] According to an example embodiment of the sleep mode SM3, in the case where the sleep duration is 4 radio frames (i.e., 40 ms), the wake-up delay of SM 3 refers to N equal to 100 slots. Therefore, for a subcarrier spacing (SCS) equal to 15 kHz, the total sleep duration is equal to 140 slots (40 slots + 100 slots (wake-up delay)). Therefore, for a sleep duration in slots equal to 140 slots (@ 15 kHz SCS), the total sleep duration in slots is calculated as follows: extnumSlots(0)+numSlots(40)+L(100 slots).

[0410] According to another example embodiment of the sleep mode SM3, for an SCS equal to 120 kHz, the total sleep duration is 420 slots (320 slots + 100 slots (wake-up delay)). Therefore, for a sleep duration in slots equal to 420 slots (@ 120 kHz SCS), the total sleep duration in slots is calculated as follows: extnumSlots(65)+numSlots(255)+L(100 slots).

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

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

[0413] according to Figure 13 In st4CmdType'TRX-CONTROL / ADVANCED-SLEEP-MODE', the use of the TRX-CONTROL command (undefined sleep duration) may include an operation in which the O-DU reads the O-RU sleep capabilities, including the L, M, and N values of the supported sleep levels. To this end, the O-DU may issue a TRX-CONTROL command when the O-DU determines to deactivate an antenna element / layer. The first TRX-CONTROL command includes field values numSlots=0, sleepDurIndex=0xF, sleepDepth=0. Although there is no guaranteed sleep duration, the antenna element may be activated in any future timeslot without a minimum sleep duration. The second TRX-CONTROL command includes field values numSlots=0, sleepDurIndex=0xF, sleepDepth≠0. In this case, the O-RU may enter command sleep mode, and the O-DU may not activate the antenna element / layer after L, M, or N timeslots (as specified by the new mask). To this end, when the O-RU receives a new TRX-CONTROL command (i.e., a change to this command), it can activate the new mask 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.

[0414] For this purpose, L, M, and N time slots are respectively defined as wake-up delays (i.e., transition times) only for sleep modes 1, 2, and 3. However, for undefined sleep, the wake-up delay may not be defined.

[0415] refer to Figure 13 , if TRx control and advanced sleep mode are executed simultaneously, the transition delay wake-up delay (i.e., transition time) that occurs when changing from one TRx control configuration to another TRx control configuration needs to be considered (i.e., antenna configuration change during transition from one antenna array model to another antenna array model).

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

[0417] Furthermore, the sleep mode definition can be used to perform TRx control for both defined and undefined durations.

[0418] Furthermore, in Advanced Sleep Mode, some components are turned off depending on the sleep duration, but in TRx Control, the entire baseband and RF processing chain associated with some antenna elements is turned off. Therefore, the wake-up delay (ASM) and transition time (TRx Control) may differ.

[0419] Figure 14 The sleep mode implementation according to the section type 4 command type (ST4CmdType) st4CmdType'TRX-CONTROL / ADVANCED-SLEEP-MODE' is shown, which includes the parameter symbolMask for implementing symbol-level sleep duration to support sleep mode type 0 (SM0).

[0420] refer to Figure 14 , st4CmdType'TRX-CONTROL / ADVANCED-SLEEP-MODE' is similar to Figure 13 The fifth header field is occupied by the Multiple Command Segment Type 4 header, which refers to the 4-byte sequence of the 28th octet (i.e., the number of bytes from octet 28 to octet 31 is 4). The Multiple Command Segment 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).

[0421] In case of sleep mode type 0 (SM0), the parameter "symbolMask" can be used to define the sleep duration from a number of symbols to one or a number of time slots. Figure 14 As shown, bit "1" corresponds to a symbol that needs to be activated for SM0, and bit "0" corresponds to a symbol that is not used for SM0.

[0422] If the value of the parameter symbolMask indicates an allocation that exceeds the slot boundaries, such allocation may be ignored (eg, when there are fewer than 14 symbols in the slot).

[0423] Figure 15 A flowchart of the startup and wakeup process between the O-DU and O-RU for sleep mode implementation via control plane segment type 4 messaging is shown. Figure 15 , applications such as Figure 13 and Figure 14 The parameters shown are used to implement sleep mode. Figure 15 The implementation of the second sleep mode type SM2 (i.e., advanced sleep mode) through the ST4 message is shown. According to the example embodiment, the SCS of SM2 is 15KHz. The O-RU notifies the O-DU of the minimum sleep duration / wake-up delay (i.e., SM2-M time slots) via M-plane messaging of the configuration capability information (wake-up delay information). Figure 15 In the sleep mode implementation, SM2 refers to a defined sleep mode, i.e., the O-RU schedules sleep for any number of time slots (SM2 > M time slots), where the C-plane remains active (i.e., the O-RU maintains C-plane activity). The sleep duration is set to 4 radio frames (40ms), where the wake-up delay is M, which is equal to 60 time slots. Therefore, for a 15kHz SCS, the total sleep duration is equal to 100 time slots (40 time slots + 60 time slots (wake-up delay)).

[0424] In operation 1, the O-DU sends a sleep mode (SM#2) activation request to the O-RU using an ST4 message (ie, a C-plane message).

[0425] In operation 2, the O-DU sends "asmflag" to indicate that SM2 remains active until the O-RU receives another SM2 wake-up command from the O-DU. After sending "asmflag", sleep mode begins. The "asmflag" bit map is as follows:

[0426]

[0427]

[0428] In operation 3, the O-DU sends a wake-up command (SM1).

[0429] In operation 4, the O-RU wakes up and sends a carrier active message to the O-DU. The O-RU wake-up delay between operations 3 and 4 is M, which is equal to 60 time slots. With operation 4, the sleep mode ends.

[0430] Figure 16 A flowchart of the startup and wakeup process between the O-DU and the O-RU for sleep mode implementation via control plane segment type 4 messaging is shown. Figure 16 ,application Figure 13 and Figure 14 The parameters shown are used to implement sleep mode. Figure 16 The implementation of the second sleep mode type SM2 (i.e., advanced sleep mode) through the ST4 message is shown. According to the example embodiment, the SCS of SM2 is 120KHz. The O-RU notifies the O-DU of the minimum sleep duration / wake-up delay (i.e., SM2-M time slots) via M-plane messaging of the configuration capability information (wake-up delay information). Figure 15 In the sleep mode implementation, SM2 refers to a defined sleep mode, i.e., the O-RU schedules sleep for any number of time slots (SM2 > M time slots), where the C-plane remains active (i.e., the O-RU maintains C-plane activity). The sleep duration is set to 4 radio frames (40ms), where the wake-up delay is M, which is equal to 60 time slots. Therefore, for a 120kHz SCS, the total sleep duration is equal to 380 time slots (320 time slots + 60 time slots (wake-up delay)).

[0431] In operation 1, the O-DU sends a sleep mode (SM#2) activation request to the O-RU using an ST4 message (ie, a C-plane message).

[0432] In operation 2, the O-DU sends "asmflag" to indicate that SM2 remains active until the O-RU receives another SM2 wake-up command from the O-DU. After sending "asmflag", sleep mode begins. The "asmflag" bit map is as follows:

[0433]

[0434]

[0435] In operation 3, the O-DU sends a wake-up command (SM1).

[0436] In operation 4, the O-RU wakes up and sends a carrier active message to the O-DU. The O-RU wake-up delay between operations 3 and 4 is M, which is equal to 60 time slots. With operation 4, the sleep mode ends.

[0437] Figure 17 Deactivation of the O-RU portion by activating a sleep mode type control plane segment type 4 messaging in the O-RU is shown. Figure 17 , the deactivation of the O-RU part through control plane segment type 4 messaging takes into account the wake-up delay of the O-RU components, and one or more O-RU parts are shut down for each sleep mode.

[0438] refer to Figure 17 The O-Du connects to the O-RU via the O-RAN FH interface. The O-RU consists of an O-RAN front-end processing unit that hosts the evolved common public radio interface (eCPRI), as well as processing resources for C-plane, S-plane, and M-plane processing. Additionally, the O-RAN front-end processing unit hosts low-physical (PHY) processing and antenna calibration processing. The O-RAN front-end processing unit connects to the digital processing unit via a packet interface. The digital processing unit hosts component carrier digital pre-distortion (DPD), crest factor reduction (CFR), digital up-conversion (DUC), and digital down-conversion (DDC). The digital processing unit connects to the radio front-end (RF) processing unit via a digital interface. The RF processing unit hosts the transceiver (TRx) as well as the analog-to-digital converter (ADC) and digital-to-analog converter (DAC), calibration CAL switch, time division duplexing (TDD) front-end with low-noise amplifier (LNA) and power amplifier (PA), and cavity filter. The O-RAN front-end processing unit, digital processing unit, and RF processing unit are synchronized by the timing / synchronization unit and powered by the O-RU's power unit.

[0439] During sleep mode 1, SM1 enables the O-RU to turn off the PA / LNA when the wake-up delay or minimum sleep duration matches that defined for SM1, eg, L time slots.

[0440] During Sleep Mode 2, SM2 enables the O-RU to shut down the PA / LNA. Additionally, the O-RU can shut down the RF and digital processing units when the wakeup delay or minimum sleep duration matches that defined for SM2, e.g., M time slots.

[0441] During Sleep Mode 3, SM3 enables the O-RU to shut down the PA / LNA. Furthermore, the O-RU may shut down at least one of the RF processing unit, the digital processing unit, and the low physical processing unit. Furthermore, for example, when the wakeup delay or minimum sleep duration matches the wakeup delay or minimum sleep duration defined for SM3, such as N time slots, at least one of the eCPRI, C-Plane, U-Plane, S-Plane, and M-Plane processing units may be shut down.

[0442] Figure 18 An embodiment of TRx control and sleep mode according to the Segment Type 4 Command Type (ST4CmdType) TRX-CONTROL and Segment Type 4 Instruction Common Header Format is shown. Figure 18 , the (ST4CmdType)TRx control is similar to Figure 12 this control in. The use of the TRX-CONTROL command (defining the sleep duration) involves the O-DU reading the O-RU sleep capabilities, which includes the L, M, and N values of the supported sleep levels provided from the M-plane message passing of the configuration capabilities information. In the case where the O-DU determines to deactivate some antenna elements / layers, it issues the TRX-CONTROL command. This determination can be based on the configuration capabilities information from the O-RU and on the request to reconfigure the antenna array from a higher-layer network function. According to an example embodiment, the parameter numSlots can be set to a value not equal to NULL(0). In this case, the sleep duration is referred to as the specified number of time slots, and sleepDepth can be set to the maximum possible value such that numSlots ≥ L or M or N. Additionally, if numSlots < L, sleepDeep can be set to 0. In this case, the SleepDurIndex is ignored.

[0443] According to an example embodiment, the parameter numSlots can be set to a value equal to NULL(0), and the parameter sleepDurIndex can be set to a value not equal to 0xF. In this case, the sleep duration is known via the M-plane (up to 14 possible values). Additionally, in this case, the C-plane processing can be turned off for the specified duration. In this case, the parameter sleepDepth is ignored because the sleep depth can be inferred from the sleepDurIndex value.

[0444] Refer to Figure 18 , the section type 4 command common header format includes the parameter "numSlots", which is an eight-octet sequence according to the 20th Octetin in the common header. The sleep modes SM1, SM2, and SM3 can be configured with up to 255 time slots at most. For other sleep durations, the O-DU can know 14 possible values via the M-plane. However, in an example embodiment, the sleep mode of each O-RU can be 17, which results in an extended sleep mode and additional utilization of the sleep mode model above SM1, SM2, and SM3.

[0445] Figure 19 is an illustration of an example environment 1900 in which the systems and / or methods described herein can be implemented. As Figure 19 shown, the environment 1900 can include a user device 1910, a platform 1920, and a network 1930. The devices of the environment 1900 can 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 can be performed by Figure 19 Any combination of the elements shown may be performed.

[0446] User device 1910 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information associated with platform 1920. For example, user device 1910 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., a pair of smart glasses or a smart watch), or the like. In some implementations, user device 1910 can receive information from platform 1920 and / or transmit information to platform 1920.

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

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

[0449] Cloud computing environment 1922 includes an environment hosting platform 1920. Cloud computing environment 922 can provide computing, software, data access, storage, and other services without requiring end users (e.g., user devices 1910) to be aware of the physical location and configuration of the system(s) and / or device(s) hosting platform 1920. As shown, cloud computing environment 1923 can include a group of computing resources 1924 (collectively, "computing resources 1924" and individually, "computing resource 1924").

[0450] Computing resources 1924 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 1924 can host platform 1920. Cloud resources can include computing instances executed in computing resources 1924, storage devices provided in computing resources 1924, data transfer devices provided by computing resources 1924, etc. In some implementations, computing resources 1924 can communicate with other computing resources 1924 via wired connections, wireless connections, or a combination of wired and wireless connections.

[0451] like Figure 19 As further shown, computing resources 1924 include cloud resource groups, such as one or more applications ("APP") 1924-1, one or more virtual machines ("VM") 1924-2, virtualized storage ("VS") 1924-3, one or more hypervisors ("HYP") 1924-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), containerized and / or cloud native functions (CNFs), etc.

[0452] Applications 1924-1 include one or more software applications that can be provided to or accessed by user device 1910. Applications 1924-1 can eliminate the need to install and execute software applications on user device 1910. For example, applications 1924-1 can include software associated with platform 1920 and / or any other software provided via cloud computing environment 1922. In some implementations, one application 1924-1 sends information to / receives information from one or more other applications 1924-1 via virtual machine 1924-2.

[0453] Virtual machine 1924-2 comprises a software implementation of a machine (e.g., a computer) that executes programs similar to a physical machine. Virtual machine 1924-2 can be a system virtual machine or a process virtual machine, depending on the use of virtual machine 1924-1 and the degree of correspondence 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 1924-2 can execute on behalf of a user (e.g., user device 1910) and can manage the infrastructure of cloud computing environment 1922, such as data management, synchronization, or long-term data transfer.

[0454] Virtualized storage 1924-3 includes one or more storage systems and / or one or more devices that use virtualization technology within the storage system or device of computing resource 1924. In some implementations, within the context of a storage system, the types of virtualization may include block virtualization and file virtualization. Block virtualization may refer to the abstraction (or separation) of logical storage from physical storage, making it possible to access the storage system without regard to physical storage or heterogeneous structures. This separation may allow administrators of the storage system to have flexibility in how to manage storage for end users. File virtualization may eliminate the dependency between data accessed at the file level and the physical storage location of the file. This may optimize the performance of storage usage, server consolidation, and / or non-disruptive file migration.

[0455] Hypervisor 1924-4 can provide hardware virtualization technology that allows multiple operating systems (e.g., "guest operating systems") to execute simultaneously on a host computer, such as computing resources 1924. Hypervisor 1924-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.

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

[0457] Figure 19 The number and arrangement of devices and networks shown are provided as examples. Figure 19 There may be additional devices and / or networks, fewer devices and / or networks, different devices and / or networks, or differently arranged devices and / or networks than those shown. Figure 19 Two or more of the devices shown may be implemented in a single device, or Figure 19 The single device shown may be implemented as multiple distributed devices. Additionally or alternatively, a set of devices (eg, one or more devices) of environment 1900 may perform one or more functions described as being performed by another set of devices of environment 2000.

[0458] According to an embodiment, the O-RU and O-DU described herein (or one or more operations associated therewith) can be implemented or deployed in the above-mentioned server platform in the form of a virtualized network function (VNF). In this regard, it is envisioned that the terms "virtual" and "virtualization" described above are intended only to specify the nature of a machine (and its associated elements and resources) provided in a virtual or software form. In this regard, the "virtual machine" and "virtualized storage" 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) can be defined or presented in the form of containerized network functions, where these functions can be provided in the form of containers.

[0459] Figure 20 2000. The device 2000 may correspond to the user device 2010 and / or the platform 1920. Figure 20 As shown, device 2000 may include a bus 2010 , a processor 2020 , a memory 2030 , a storage component 2040 , an input component 2050 , an output component 2060 , and a communication interface 2070 .

[0460] The bus 2010 includes components that allow communication between components of the device 2000. The processor 2020 can be implemented in hardware, firmware, or a combination of hardware and software. The processor 2020 can 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 2020 includes one or more processors that can be programmed to perform functions. The memory 2030 includes random access memory (RAM), read-only memory (ROM), and / or another type of dynamic or static storage device (e.g., flash memory, magnetic memory, and / or optical memory) that stores information and / or instructions for use by the processor 2020.

[0461] The storage component 2040 stores information and / or software related to the operation and use of the device 2000. For example, the storage component 2040 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 disk (DVD), a floppy disk, a cassette tape, a magnetic tape, and / or another type of non-transitory computer-readable medium and a corresponding drive. The input component 2050 includes components that allow the device 2000 to receive information, such as via user input (e.g., a touch screen display, a keyboard, a keypad, a mouse, buttons, switches, and / or a microphone). Additionally or alternatively, the input component 2050 may include a sensor for sensing information (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, and / or an actuator). The output component 2060 includes components that provide output information from the device 2000 (e.g., a display, a speaker, and / or one or more light-emitting diodes (LEDs)).

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

[0463] Device 2000 can perform one or more processes described herein. Device 2000 can perform these processes in response to processor 2020 executing software instructions stored by non-transitory computer-readable media (such as memory 2030 and / or storage component 2040). Computer-readable media is defined herein as non-transitory memory devices. Memory devices include memory space within a single physical storage device or memory space distributed across multiple physical storage devices.

[0464] The software instructions may be read into memory 2030 and / or storage component 2040 from another computer-readable medium or from another device via communication interface 2070. When executed, the software instructions stored in memory 2030 and / or storage component 2040 may cause processor 2020 to perform one or more processes described herein.

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

[0466] Figure 20 The number and arrangement of components shown are provided as examples. In practice, the device 2000 may include Figure 20 The components shown may include additional components, fewer components, different components, or differently arranged components. Additionally or alternatively, one set of components (e.g., one or more components) of device 2000 may perform one or more functions described as being performed by another set of components of device 2000.

[0467] In an embodiment, Figures 2 to 11 Any of the operations or processes can be performed by Figure 19 and Figure 20 It should be understood that other embodiments are not limited thereto and can be implemented in a variety of different architectures (e.g., bare metal architecture, any cloud-based architecture or deployment architecture, such as Kubernetes, Docker, OpenStack, etc.).

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

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

[0470] Some embodiments may relate to systems, methods, and / or computer-readable media at any possible level of integrated technical detail. In addition, 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). The computer-readable medium may include a computer-readable non-transitory storage medium (or multiple media) having computer-readable program instructions thereon for causing a processor to perform operations.

[0471] A computer-readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. A computer-readable storage medium can 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 thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: a portable computer 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 disk (DVD), a memory stick, a floppy disk, a mechanical encoding device, such as a punched card or a raised structure in a groove, on which instructions are recorded, and any suitable combination thereof. As used herein, a computer-readable storage medium itself should not be interpreted as a transient signal, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagated through a waveguide or other transmission medium (e.g., a light pulse passing through an optical cable), or an electrical signal transmitted by a wire.

[0472] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a corresponding computing / processing device via a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network), or downloaded to an external computer or external storage device. The network can include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. The 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.

[0473] The computer readable program code / instruction for performing an operation can be an assembly instruction, an instruction set architecture (ISA) instruction, a machine instruction, a machine-related instruction, a microcode, a firmware instruction, a state setting data, the configuration data of an integrated circuit device, or a source code or an 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 "C" programming language or similar programming languages. The computer readable program code / instruction can be performed completely on the user's computer, partly on the user's computer, performed as an independent software package, partly on the user's computer and partly on a remote computer, or completely 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, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (for example, using an internet service provider through the internet). In certain embodiments, the electronic circuit device comprising for example a programmable logic circuit device, a field programmable gate array (FPGA) or a programmable logic array (PLA) can be performed by utilizing the state information of the computer readable program instruction to personalize the electronic circuit device, so as to perform various aspects or operation.

[0474] 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 apparatus to produce a machine, such that the instructions executed by the processor of the computer or other programmable data processing apparatus create means for implementing the functions / actions specified in one or more flowcharts and / or block diagram blocks. These computer-readable program instructions can also be stored in a computer-readable storage medium that can direct the computer, programmable data processing apparatus, and / or other device to operate in a specific manner, such that the computer-readable storage medium having the instructions stored therein comprises an article of manufacture that includes instructions for implementing various aspects of the functions / actions specified in one or more flowcharts and / or block diagram blocks.

[0475] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other device to produce a computer-implemented process, such that the instructions executed on the computer, other programmable apparatus, or other device implement the functions / actions specified in one or more flowcharts and / or block diagram blocks.

[0476] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments. In this regard, each block in the flowchart or block diagram may represent a microservice, module, segment, or portion of instructions, which includes one or more executable instructions for implementing the specified logical function. The method, computer system, and computer-readable medium may include additional blocks, fewer blocks, different blocks, or blocks arranged differently than those depicted in the figures. In some alternative implementations, the functions mentioned in the blocks may not appear in the order mentioned in the figures. For example, depending on the functions involved, two blocks shown in succession may actually be executed simultaneously or substantially simultaneously, or the blocks may sometimes be executed in the opposite order. It will also be noted that each block in the block diagram and / or flowchart illustration, as well as combinations of blocks in the block diagram and / or flowchart illustration, can be implemented by a dedicated hardware-based system that performs the specified functions or actions or executes a combination of dedicated hardware and computer instructions.

[0477] It is clear that the apparatus and / or methods described herein can be implemented in various forms of hardware, firmware, or a combination of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods does not limit these implementations. Therefore, the operation and behavior of the systems and / or methods are described herein without reference to specific software code, and it should be understood that software and hardware can be designed based on the description herein to implement the systems and / or methods.

[0478] In view of the foregoing, various further corresponding aspects and features of embodiments of the present disclosure may be defined by the following clauses:

[0479] Clause [1] An apparatus comprising: a distributed unit (O-DU), the O-DU configured to: receive configuration capability information from a radio unit (O-RU) via management plane (M-plane) messaging from the O-RU; receive a request to reconfigure an antenna array from a higher layer network function; determine a sleep mode type supported by the O-RU based on the configuration capability information from the O-RU and based on the request to reconfigure the antenna array from the higher layer network function; and based on the supported sleep mode type, apply the supported sleep mode type to the O-RU via a C-plane segment type 4 message or an M-plane command.

[0480] Clause [2] An apparatus according to clause [1], wherein the configuration capability information may further include wake-up delay information for the sleep mode type, and wherein the O-DU may further be configured to: receive the wake-up delay information from the O-DU via M-plane messaging, the wake-up delay information announcing L time slots for the first sleep mode type SM1, M time slots for the second sleep mode type SM2, and N time slots for the third sleep mode type SM3.

[0481] Clause [3] The apparatus of clause [2], wherein the O-DU may be further configured to: based on the supported sleep mode type, apply the supported sleep mode type to a fixed number of time slots defined by at least one of parameters extnumSlots and numSlots of the C-Plane Segment Type 4 message.

[0482] Clause [4] An apparatus according to clause [3], wherein the total sleep duration in the time slot is the time slot defined by parameters extnumSlots and numSlots, and the sum of wake-up delay information for each sleep mode type, wherein the parameters extnumSlots and numSlots are applied by the O-DU to the O-RU via a C-plane segment type 4 message, and the sum of wake-up delay information for each sleep mode type is received by the O-DU from the O-RU via an M-plane message.

[0483] Clause [5] An apparatus according to clause [2], wherein the O-DU may be further configured to: apply a parameter asmflag to the O-RU via a C-Plane Segment Type 4 message, wherein the parameter asmflag defines that at least one of SM1, SM2, and SM3 is active for an undefined sleep duration or is active for a defined sleep duration.

[0484] Clause [6] An apparatus according to clause [5], wherein the O-DU may be further configured to: send a C-plane segment type 4 message to wake up the O-RU from at least one of SM1, SM2, and SM3 based on applying parameter asmflag via the C-plane segment type 4 message.

[0485] Clause [7] An apparatus according to clause [6], wherein the O-DU may be further configured to: apply a parameter asmflag to the O-RU via a C-plane segment type 4 message, wherein the parameter asmflag defines that at least one of SM1, SM2, and SM3 is active for an undefined sleep duration; and send an interrupt via a C-plane segment type 4 message based on the undefined sleep duration to wake up the O-RU from at least one of SM1, SM2, and SM3.

[0486] Clause [8] An apparatus according to any of clauses [5 to 8], wherein the apparatus may further comprise: applying a CU-plane wake-up command via M-plane messaging within a predefined sleep duration based on a defined sleep duration.

[0487] Clause [9] An apparatus comprising: a radio unit (O-RU) configured to: send configuration capability information to an open distributed unit (O-DU) via a management plane (M-plane) command; receive sleep mode types supported by the O-RU from the O-DU via a C-plane segment type 4 message or an M-plane command, wherein the supported sleep mode types are based on the configuration capability information of the O-RU and a request to reconfigure an antenna array from a higher layer network function; and activate a sleep mode type of a portion of the O-RU based on the supported sleep mode types of the O-RU.

[0488] Clause

[10] An apparatus according to clause [9], wherein the configuration capability information may also include wake-up delay information for the sleep mode types, and wherein the O-RU may be further configured to: send the wake-up delay information via M-plane messaging, the wake-up delay information announcing L time slots for the first sleep mode type SM1, M time slots for the second sleep mode type SM2, and N time slots for the third sleep mode type SM3.

[0489] Clause

[11] An apparatus according to clause [9], wherein the O-RU may be further configured to: receive a parameter asmflag to the O-RU via a C-plane segment type 4 message, wherein the parameter asmflag defines that at least one of SM1, SM2, and SM3 is active for a defined sleep duration; and deactivate the CU plane processing unit of the O-RU based on the defined sleep duration.

[0490] Clause

[12] An apparatus according to any of clauses [9 to 11], wherein the O-RU may be further configured to: send an ACK / NACK message via C-plane segment type 8 messaging within a predetermined sleep duration based on a defined sleep duration, wherein the ACK message signals the O-DU to start scheduling CU-plane data.

[0491] Clause

[13] An apparatus according to any of clauses [9 to 12], wherein the O-RU may be further configured to: receive a parameter asmflag to the O-RU via a C-plane segment type 4 message, wherein the parameter asmflag defines that at least one of SM1, SM2, and SM3 is active during the sleep duration, and based on the undefined sleep duration, deactivate the logical radio frequency components (FPGA, RFIC) and the RF front-end module (RFFE) components depending on the wake-up delay information.

[0492] Clause

[14] A method comprising: receiving, by a distributed unit (O-DU), configuration capability information from a radio unit (O-RU) via management plane (M-plane) messaging from the O-RU; receiving, by the O-DU, a request to reconfigure an antenna array from a higher layer network function; determining, by the O-DU, sleep mode types supported by the O-RU based on the configuration capability information from the O-RU and based on the request to reconfigure the antenna array from the higher layer network function; and applying, by the O-DU, the supported sleep mode types to the O-RU via a C-plane segment type 4 message or an M-plane command based on the supported sleep mode types.

[0493] Clause

[15] A method according to clause

[14] , wherein the configuration capability information may further include wake-up delay information for the sleep mode types, and wherein the method may further include: receiving, by the O-DU, the wake-up delay information from the O-DU via M-plane messaging, which announces L time slots for the first sleep mode type SM1, M time slots for the second sleep mode type SM2, and N time slots for the third sleep mode type SM3.

[0494] Clause

[16] A method according to clause

[14] , wherein the method may further comprise: applying, by the O-DU based on the supported sleep mode type, the supported sleep mode type to a fixed number of time slots defined by at least one of parameters extnumSlots and numSlots of the C-Plane Segment Type 4 message.

[0495] Clause

[17] The method according to clause

[15] , wherein the total sleep duration in the time slot is the sum of the time slots defined by parameters extnumSlots and numSlots, and wake-up delay information for each sleep mode type, wherein parameters extnumSlots and numSlots are applied by the O-DU to the O-RU via C-plane segment type 4 messaging, and wake-up delay information for each sleep mode type is received by the O-DU from the O-RU via M-plane messaging.

[0496] Clause

[18] A method according to clause

[15] , wherein the method may further comprise: applying, by the O-DU, a parameter asmflag to the O-RU via a C-Plane Segment Type 4 message, wherein the parameter asmflag defines that at least one of SM1, SM2, and SM3 is active for an undefined sleep duration or is active for a defined sleep duration.

[0497] Clause

[19] A method according to clause

[18] , wherein the method may further include: sending, by the O-DU, a C-plane segment type 4 message to wake up the O-RU from at least one of SM1, SM2, and SM3 based on applying parameter asmflag via the C-plane segment type 4 message.

[0498] Clause

[20] A method according to clause

[18] , wherein the method may further include: applying, by the O-DU, a parameter asmflag to the O-RU via a C-plane segment type 4 message, wherein the parameter asmflag defines that at least one of SM1, SM2, and SM3 is active for an undefined sleep duration; and sending, by the O-DU, an interrupt via a C-plane segment type 4 message based on the undefined sleep duration, to wake up the O-RU from at least one of SM1, SM2, and SM3.

[0499] Clause

[21] A method according to any of clauses [14 to 20], wherein the method may further comprise: applying, by the O-DU, a CU-plane wake-up command via M-plane messaging within a predefined sleep duration based on the defined sleep duration.

[0500] Clause

[22] A method comprising: sending, by a radio unit (O-RU) via a management plane (M-plane) command, configuration capability information to an open distributed unit (O-DU); receiving, by the O-RU, from the O-DU via a C-plane segment type 4 message or an M-plane command, sleep mode types supported by the O-RU, wherein the supported sleep mode types are based on the configuration capability information of the O-RU and a request to reconfigure an antenna array from a higher layer network function; and activating, by the O-RU, a sleep mode type of a portion of the O-RU based on the supported sleep mode types of the O-RU.

[0501] Clause

[23] A method according to clause

[22] , wherein the configuration capability information may also include wake-up delay information for the sleep mode types, and wherein the method may further include: the wake-up delay information is sent by the O-RU via M-plane messaging, which announces L time slots for the first sleep mode type SM1, M time slots for the second sleep mode type SM2, and N time slots for the third sleep mode type SM3.

[0502] Clause

[24] A method according to clause

[22] , wherein the method may further include: receiving, by the O-RU, a parameter asmflag to the O-RU via a C-Plane Segment Type 4 message, wherein the parameter asmflag defines that at least one of SM1, SM2, and SM3 is active for a defined sleep duration; and deactivating, by the O-RU, the CU plane processing unit based on the defined sleep duration.

[0503] Clause

[25] A method according to any of clauses [22 to 24], wherein the method may further comprise: sending, by the O-RU, an ACK / NACK message via C-plane segment type 8 messaging within a predetermined sleep duration based on a defined sleep duration, wherein the ACK message signals the O-DU to start scheduling CU-plane data.

[0504] Clause

[26] A method according to any of clauses [22 to 24], wherein the method may further include: receiving, by the O-RU, a parameter asmflag to the O-RU via a C-Plane Segment Type 4 message, wherein the parameter asmflag defines that at least one of SM1, SM2, and SM3 is active for an undefined sleep duration, and deactivating, by the O-RU, the logical radio frequency components (FPGA, RFIC) and the RF front-end module (RFFE) components based on the undefined sleep duration and depending on the wake-up delay information.

[0505] It will be appreciated that numerous modifications and variations of the present disclosure are possible in light of the above teachings.It will be apparent that within the scope of the appended claims, the present disclosure may be practiced otherwise than as specifically described herein. < / rpc>

Claims

1. A device comprising: Distributed Unit (O-DU), the O-DU being configured to: receiving configuration capability information from a radio unit (O-RU) via management plane (M-plane) messaging from the O-RU; receiving a request from a higher layer network function to reconfigure the antenna array; determining a sleep mode type supported by the O-RU based on the configuration capability information from the O-RU and based on the request from the higher layer network function to reconfigure the antenna array; as well as Based on the supported sleep mode type, the supported sleep mode type is applied to the O-RU via a C-plane segment type 4 message or an M-plane command.

2. The apparatus of claim 1 , wherein the configuration capability information further includes wakeup delay information for a sleep mode type, and wherein the O-DU is further configured to: The wake-up delay information is received from the O-DU via M-plane messaging, the wake-up delay information advertising L time slots for a first sleep mode type SM1, M time slots for a second sleep mode type SM2, and N time slots for a third sleep mode type SM3.

3. The apparatus according to claim 2, wherein the O-DU is further configured to: Based on the supported sleep mode type, the supported sleep mode type is applied to a fixed number of time slots defined by at least one of parameters extnumSlots and numSlots of the C-Plane Segment Type 4 message.

4. The apparatus of claim 3 , wherein a total sleep duration in a time slot is a time slot defined by the parameters extnumSlots and numSlots, and a sum of the wake-up delay information for each sleep mode type, the parameters extnumSlots and numSlots being applied to the O-RU by the O-DU via the C-plane segment type 4 message, and the sum of the wake-up delay information for each sleep mode type being received from the O-RU by the O-DU via M-plane messaging.

5. The apparatus of claim 2, wherein the O-DU is further configured to: A parameter asmflag is applied to the O-RU via the C-plane segment type 4 message, wherein the parameter asmflag defines that at least one of SM1, SM2, and SM3 is active for an undefined sleep duration or is active for a defined sleep duration.

6. The apparatus according to claim 5, wherein the O-DU is further configured to: Based on applying the parameter asmflag via the C-plane segment type 4 message, a C-plane segment type 4 message is sent to wake up the O-RU from at least one of the SM1, SM2, and SM3.

7. The apparatus of claim 5, wherein the O-DU is further configured to: applying a parameter asmflag to the O-RU via the C-Plane Segment Type 4 message, wherein the parameter asmflag defines that at least one of SM1, SM2, and SM3 is active for an undefined sleep duration; and Based on the undefined sleep duration, an interrupt is sent via a C-plane segment type 4 message to wake up the O-RU from at least one of the SM1, SM2, and SM3.

8. A method comprising: receiving, by a distributed unit (O-DU), configuration capability information from a radio unit (O-RU) via management plane (M-plane) messaging from the O-RU; receiving, by the O-DU from a higher layer network function, a request to reconfigure the antenna array; determining, by the O-DU, a sleep mode type supported by the O-RU based on the configuration capability information from the O-RU and based on the request from the higher layer network function to reconfigure the antenna array; as well as The O-DU applies the supported sleep mode type to the O-RU via a C-plane segment type 4 message or an M-plane command based on the supported sleep mode type.

9. The method of claim 8, wherein the configuration capability information further includes wakeup delay information for a sleep mode type, and wherein the method further comprises: The wake-up delay information is received by the O-DU from the O-DU via M-plane messaging, the wake-up delay information announcing L time slots for a first sleep mode type SM1, M time slots for a second sleep mode type SM2, and N time slots for a third sleep mode type SM3.

10. The method according to claim 8, wherein the method further comprises: The O-DU applies the supported sleep mode type to a fixed number of time slots defined by at least one of parameters extnumSlots and numSlots of the C-plane segment type 4 message based on the supported sleep mode type.

11. The method of claim 10 , wherein the total sleep duration in a time slot is the sum of the time slot defined by the parameters extnumSlots and numSlots, applied by the O-DU to the O-RU via the C-plane segment type 4 message, and the wake-up delay information for each sleep mode type received by the O-DU from the O-RU via M-plane messaging.

12. The method according to claim 9, further comprising: The O-DU applies a parameter asmflag to the O-RU via the C-plane segment type 4 message, wherein the parameter asmflag defines whether at least one of SM1, SM2, and SM3 is active for an undefined sleep duration or is active for a defined sleep duration.

13. The method according to claim 12, wherein the method further comprises: The O-DU sends a C-plane segment type 4 message to wake up the O-RU from at least one of the SM1, SM2, and SM3 based on applying the parameter asmflag via the C-plane segment type 4 message.

14. The method according to claim 12, further comprising: applying, by the O-DU via the C-Plane Segment Type 4 message, a parameter asmflag to the O-RU, wherein the parameter asmflag defines that at least one of SM1, SM2, and SM3 is active for an undefined sleep duration; as well as An interrupt is sent by the O-DU via a C-plane segment type 4 message based on the undefined sleep duration to wake up the O-RU from at least one of the SM1, SM2, and SM3.

15. The method according to claim 12, further comprising: The CU-plane wake-up command is applied by the O-DU via M-plane messaging within a predefined sleep duration based on the defined sleep duration.

16. A method comprising: The radio unit (O-RU) sends configuration capability information to the open distributed unit (O-DU) via a management plane (M-plane) command; receiving, by the O-RU from the O-DU via a C-plane segment type 4 message or an M-plane command, sleep mode types supported by the O-RU, wherein the supported sleep mode types are based on the configuration capability information of the O-RU and a request from a higher layer network function to reconfigure an antenna array; as well as The sleep mode type of a portion of the O-RU is activated by the O-RU based on the supported sleep mode types of the O-RU.

17. The method of claim 16, wherein the configuration capability information further includes wakeup delay information for a sleep mode type, and wherein the method further comprises: The wake-up delay information is sent by the O-RU via M-plane messaging, and the wake-up delay information announces L time slots for the first sleep mode type SM1, M time slots for the second sleep mode type SM2, and N time slots for the third sleep mode type SM3.

18. The method according to claim 16, wherein the method further comprises: receiving, by the O-RU via the C-Plane Segment Type 4 message, a parameter asmflag to the O-RU, wherein the parameter asmflag defines that at least one of SM1, SM2, and SM3 is active for a defined sleep duration; as well as The CU plane processing unit is deactivated by the O-RU based on a defined sleep duration.

19. The method according to claim 16, wherein the method further comprises: An ACK / NACK message is sent by the O-RU via C-plane segment type 8 messaging within a predetermined sleep duration based on a defined sleep duration, wherein the ACK message signals the O-DU to start scheduling CU-plane data.

20. The method of claim 16, further comprising: receiving, by the O-RU via the C-Plane Segment Type 4 message, a parameter asmflag to the O-RU, wherein the parameter asmflag defines that at least one of SM1, SM2, and SM3 is active for an undefined sleep duration; as well as The O-RU deactivates logic radio frequency components (FPGA, RFIC) and RF front-end module (RFFE) components based on the undefined sleep duration and depending on the wake-up delay information.

Images