Deep sleep mode in radio access network architecture

Abstract

A method (700) is disclosed. The method includes receiving (702), by a radio unit (RU) from a RU controller, a deep sleep command to disable a plurality of functions associated with the RU. The deep sleep command includes a predefined duration for a deep sleep timer. Further, the method includes disabling (704), by the RU, control plane (C-plane) functions, user plane (U-plane) functions, and synchronization plane (S-plane) functions associated with the RU and starting the deep sleep timer. Further, the method includes receiving (706), by the RU from the RU controller, a close session command to suspend an established / active session between the RU and the RU controller. Further, in response to the received close session command, the method includes disabling (708), by the RU, management plane (M-plane) associated with the RU and entering a deep sleep mode.

Description

Cross-reference to related applications

[0001] This application claims priority to Indian Provisional Application 202411006862, filed on February 1, 2024, and Indian Non-Provisional Application 202411006862, filed on July 17, 2024, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This disclosure relates to the implementation of deep sleep mode in a radio access network (RAN) architecture. Background Technology

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

[0004] The Radio Access Network (RAN) is a crucial component of telecommunications systems and comprises multiple network entities or components that facilitate connectivity to end-user equipment (User Equipment). In recent years, the Open RAN (O-RAN) architecture has been developed, which decomposes RAN functionality through various logical nodes. Typically, an O-RAN architecture includes logical nodes such as the O-RAN Radio Unit (O-RU), the O-RAN Centralized Unit (O-CU), and the O-RAN Distributed Unit (O-DU). The O-CU can also be divided into the O-CU Control Plane (O-CU-CP) and the O-CU User Plane (O-CU-UP). One of the main challenges of traditional O-RAN architectures is the power consumption of these logical nodes, as this impacts the operating costs, battery life, and environmental impact of the associated telecommunications system. Specifically, the power consumption of the O-RU is critical due to its limited power capabilities.

[0005] Therefore, the aforementioned problems with the RAN architecture need to be addressed. Summary of the Invention

[0006] This summary is provided to introduce a series of concepts in a simplified form, which will be further described in the specific embodiments of this disclosure. This summary is not intended to identify key or fundamental inventive concepts of this disclosure, nor is it intended to define the scope of this disclosure.

[0007] The power consumption of logical nodes such as RUs in a RAN can affect the operating costs, battery life, and environmental impact of associated communication systems. Therefore, it is necessary to optimize power consumption at the RUs.

[0008] This paper discloses a system and method for deep sleep mode in RAN architecture.

[0009] According to one embodiment of this disclosure, a method is disclosed. The method includes receiving a deep sleep command from a radio unit (RU) controller for disabling multiple functions associated with the RU. The deep sleep command includes a predefined duration for a deep sleep timer. In response to the received deep sleep command, the method includes the RU disabling control plane (C-plane) functions, user plane (U-plane) functions, and synchronization plane (S-plane) functions associated with the RU. The method also includes starting a deep sleep timer. Subsequently, the method includes the RU receiving a session close command from the RU controller for suspending an established / active session between the RU and the RU controller. In response to the received session close command, the method includes the RU disabling the management plane (M-plane) associated with the RU. Furthermore, the method includes the RU entering a deep sleep mode.

[0010] According to another embodiment of this disclosure, an apparatus associated with a radio unit (RU) is disclosed. The apparatus is configured to receive a deep sleep command from an RU controller for disabling multiple functions associated with the RU. The deep sleep command includes a predefined duration for a deep sleep timer. In response to the received deep sleep command, the apparatus is configured to disable control plane (C-plane), user plane (U-plane), and synchronization plane (S-plane) functions associated with the RU. The apparatus is also configured to start a deep sleep timer. The apparatus is further configured to receive a session close command from the RU controller for suspending an established / active session between the RU and the RU controller. In response to the received session close command, the apparatus is configured to disable the management plane (M-plane) associated with the RU. The apparatus is also configured to enter a deep sleep mode.

[0011] According to another embodiment of this disclosure, a non-transitory computer-readable medium storing instructions is disclosed. The instructions include one or more instructions executed by a wireless unit (RU) including one or more processors. These instructions cause one or more processors to receive a deep sleep command from an RU controller for deactivating multiple functions associated with the RU. The deep sleep command includes a predefined duration for a deep sleep timer. These instructions cause one or more processors to deactivate control plane (C-plane) functions, user plane (U-plane) functions, and synchronization plane (S-plane) functions associated with the RU. These instructions cause one or more processors to deactivate the C-plane, U-plane, and S-plane functions in response to the received deep sleep command. These instructions also cause one or more processors to start a deep sleep timer in response to the received deep sleep command. These instructions cause one or more processors to receive a session shutdown command for pausing an established / active session between the RU and the RU controller. The session shutdown command is received from the RU controller. These instructions cause one or more processors to deactivate the management plane (M-plane) associated with the RU. In response to the received session shutdown command, the M-plane is deactivated. These instructions cause one or more processors to enter a deep sleep mode.

[0012] To further illustrate the advantages and features of this disclosure, a more specific description will be given with reference to the specific embodiments shown in the accompanying drawings. It should be understood that these drawings depict only typical embodiments of this disclosure and should not be considered as limiting its scope. This disclosure will be described and explained with additional specificity and detail in conjunction with the accompanying drawings. Attached Figure Description

[0013] The features, aspects, and advantages of embodiments of the present disclosure will now be described with reference to the accompanying drawings, wherein like reference numerals denote like elements, and in the drawings: Figure 1 The illustration shows an operational sequence between an O-RU and an O-RU controller for enabling a deep sleep mode according to one or more embodiments of the present disclosure; Figure 2 The illustration shows an operational sequence between an O-RU and an O-RU controller for disabling a deep sleep mode according to one or more embodiments of the present disclosure; Figure 3 The illustration shows an operational sequence between an O-RU and an O-RU controller for activating a deep sleep mode according to one or more embodiments of the present disclosure; Figure 4 The illustration shows a deep-sleep-state transition diagram of an O-RU according to one or more embodiments of the present disclosure; Figure 5The illustration shows an operational sequence between the O-RU and the O-RU controller for enabling a deep sleep mode according to one or more additional embodiments of the present disclosure; Figure 6 The illustration shows an operational sequence between the O-RU and the O-RU controller for activating a deep sleep mode according to an embodiment of the present disclosure; Figure 7 The illustration shows a flowchart of an example method according to an embodiment of the present disclosure; and Figure 8 An embodiment of an example device according to an embodiment of the present disclosure is illustrated. Detailed Implementation

[0014] The following detailed description of exemplary embodiments is provided with reference to the accompanying drawings. This disclosure provides illustrations and descriptions, but is not intended to be exhaustive or to limit implementation to the precise forms disclosed. Modifications and variations are possible according to this disclosure, or may be obtained from the practice of implementation. Furthermore, one or more features or components of one embodiment may be incorporated into or combined with another embodiment (or one or more features of another embodiment). Additionally, the flowcharts and descriptions of operation provided below relate to at least one embodiment of this disclosure. It should be noted that other embodiments may be made that do not perfectly match the flowcharts and their descriptions. It should be understood that in other embodiments, one or more operations may be omitted, one or more operations may be added, and one or more operations may be performed simultaneously (at least partially).

[0015] It is evident that the systems and / or methods described herein can be implemented in various forms of hardware, software, or combinations of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods should not limit their implementation. Therefore, since the operation and behavior of systems and / or methods are described herein without reference to specific software code, it should be understood that software and hardware can be designed to implement these systems and / or methods based on the descriptions herein.

[0016] Even if specific combinations of features are listed in the claims and / or disclosed in the specification, these specific combinations are not intended to limit the disclosure of implementation. In fact, many of these features can be combined in ways not specifically listed in the claims and / or not disclosed in the specification. Even if a dependent claim directly depends on only one claim, this disclosure may indicate that the dependent claim depends on other claims in the claim set.

[0017] Unless explicitly stated otherwise, no element, action, or instruction used herein should be construed as critical or necessary. Furthermore, as used herein, the terms “a” and “an” (in other words, nouns not mentioned in plural form) are intended to include one or more items and may be used interchangeably with “one or more”. Additionally, as used herein, the terms “has,” “have,” “having,” “include,” “including,” etc., are intended to be open-ended terms. Furthermore, unless explicitly stated otherwise, the word “based on” means “at least partially based on.” Moreover, 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.

[0018] This disclosure may be described with reference to a network management entity associated with the RAN. The network management entity can be configured to manage services in the O-RAN. In some embodiments, the network management entity may be implemented as a virtualized software unit in a hardware or cloud environment. In some embodiments, the network management entity may be implemented as a dedicated hardware unit. The network management entity may be associated with O-RUs, O-CUs, and O-DUs in other components of the O-RAN.

[0019] Throughout the instruction manual, the terms “deep sleep,” “deep hibernation sleep,” “deep hibernation sleep mode,” “deep hibernation mode,” “deep sleep mode,” or “deep hibernation” are used interchangeably.

[0020] In this disclosure, the O-RU controller or RU controller may correspond to either an O-DU or a Service Management and Orchestration (SMO) entity. Furthermore, according to one or more embodiments of this disclosure, in the case of an SMO, the SMO may coordinate with the O-DU to activate deep hibernation.

[0021] This disclosure relates to a deep sleep mode based on the deactivation and / or disable of the management plane (M plane), control plane (C plane), user plane (U plane), session plane (S plane), and M plane. The M plane is part of the network system and is configured to configure, monitor, manage, and distribute various services to all layers of the network stack and other parts of the network system. The deep sleep mode enables maximum power saving of the radio unit (RU). The deep sleep mode involves applying deactivation to the entire RU, not just to each [tr]x-array / [tr]x-array-carrier. Specifically, the deep sleep mode corresponds to all carriers associated with the RU that are placed in a sleep / off state. Furthermore, the deep sleep mode includes clearing all carrier configurations associated with the RU. The carrier configurations can be deleted using any suitable reset procedure. The deep sleep mode can be enabled by a predefined sleep duration, i.e., the RU can remain in deep sleep mode for a specific time period, where only a deep sleep timer runs in the RU.

[0022] Figure 1 The illustration shows an operational sequence between an O-RU and an O-RU controller (e.g., an O-DU or SMO) for enabling a deep sleep mode according to one or more embodiments of the present disclosure.

[0023] At step 101, the O-RU sends a message to the O-RU controller announcing that the O-RU supports the deep sleep feature. At step 102, the O-RU controller receives a trigger or policy from a higher-level entity or management / intelligent entity to initiate deep sleep mode at the O-RU. Examples of such management / intelligent entities include the Wireless Intelligent Controller (RIC), Service Management and Orchestration (SMO) entity, Northbound entity, Element Management System (EMS), etc.

[0025] At step 103, the O-RU controller sends a Remote Procedure Call (RPC) to the O-RU to initiate deep mode, as shown below: <rpc> <start-deep-sleep>< / start-deep-sleep> < / rpc> After receiving the RPC, at step 104, the O-RU disables all transport [tr]x-array-carriers.

[0026] At step 105, the O-RU responds using RPC, as shown below:<rpc-reply…> <ok / > The RPC sent from the O-RU instructs all transmissions [tr]x-array-carriers to be deenabled at the O-RU. Next, at step 106, the O-RU stops all radio frequency (RF) transmissions.

[0027] Step 107 corresponds to clearing or deleting the carrier configuration in the O-RU. Specifically, at step 107.1, the O-RU controller sends an RPC to the O-RU to edit the configuration, with the following status: <rpc> <edit-config><Parameter or block of x-array-carriers with operation = delete>< / edit-config> < / rpc> Next, at step 107.2, after processing the RPC from the O-RU controller, the O-RU...<rpc-reply…> <ok / > The response is made in response. Subsequently, at step 107.3, the O-RU can automatically delete the carrier configuration block based on the deep sleep enable / start command.

[0028] Step 108 corresponds to the O-RU-specific implementation when the O-RU module is shut down. For example, at step 108.1, the O-RU shuts down both the control plane and user plane (CU plane) processing units and the synchronization plane (S plane) processing units. Alternatively, at step 108.2, the O-RU shuts down only the CU plane processing unit.

[0029] After step 108, the O-RU can enter a deep sleep state / mode. Furthermore, at step 109, the O-RU sends a notification to the O-DU indicating that deep sleep activation is complete. Specifically, the O-RU sends a message such as... <notification> <deep-sleep-activation-complete>< / deep-sleep-activation-complete> < / notification> .

[0030] Figure 2 The illustration shows an operational sequence between an O-RU and an O-RU controller for disabling a deep sleep mode according to one or more embodiments of the present disclosure. Figure 2 The operation sequence shown is based on the assumption that the O-RU is in a deep sleep state, and all configurations are as per the reference. Figure 1 The explanation.

[0031] At step 201, the O-RU controller may receive a trigger from a higher-level entity or based on a policy for stopping the deep sleep mode. In response to the received trigger or policy, at step 202, the O-RU controller may send an RPC to stop the deep sleep, such as... <rpc> <stop-deep-sleep>< / stop-deep-sleep> < / rpc> .

[0032] At step 203, the O-RU can enable all [tr]x-array-carriers and change its state to "ready". Furthermore, at step 204, the O-RU can...<rpc-reply…> <ok / > It is sent as a reply to the O-RU controller.

[0033] Step 205 corresponds to the reconfiguration of the carrier in the O-RU. Specifically, at step 205.1, the O-RU controller may send the following RPC to the O-RU for editing the configuration: <rpc> <edit-config><Parameter or block of x-array-carriers with operation = merge>< / edit-config> < / rpc>After processing the RPC to edit the configuration, at step 205.2, the O-RU...<rpc-reply…> <ok / > As a reply, it is sent to the O-DU. At step 205.3, the O-RU can automatically populate or create a carrier configuration block based on the deep sleep enable / stop command.

[0034] Step 206 may correspond to a specific implementation of the O-RU during the restart of an O-RU module in a deep sleep state / mode. Specifically, at step 206.1, the O-RU enables both the CU plane and S plane processing units. Alternatively, at step 206.2, the O-RU enables the CU plane processing unit. After performing step 206, the O-RU can now be in an operational state.

[0035] At step 207, the O-RU can send a notification to the O-RU controller indicating that the deep sleep mode has been completed, such as: <notification> <deep-sleep-deactivation-complete>< / deep-sleep-deactivation-complete> < / notification> At step 208, the O-RU can begin RF transmission. Furthermore, during carrier configuration, the O-RU can behave as follows: ○ During the deletion of carrier configuration in O-RU: Option 1: The O-RU controller (O-DU or SMO) sends an RPC with the "delete" operation to the O-RU. <edit-config>>, to remove the parameters from the entire o-ran.uplane-config.yang file. In response, • Fault ID (alarm) #12 was triggered, and the O-RU was reset as a recovery action, as shown in Table 1 below: Option 2: The O-RU controller sends an RPC with the "delete" operation to the carrier configuration block or specific carrier-related parameters. <edit-config>> • After deleting the carrier configuration, the CU plane processing unit can be shut down, thereby avoiding alarm #28 as shown in Table 1 below. Table 1 During carrier reconfiguration in O-RU: Option 1: The O-RU controller sends an RPC with the "merge" operation to the O-RU. <edit-config>> to configure all applicable parameters in the o-ran.uplane-config.yang file. Option 2: The O-RU controller sends an RPC with the "merge" operation to the O-RU. <edit-config>> to configure the applicable parameters in the carrier configuration block.

[0036] In one or more embodiments, the deep sleep process can operate in two modes: Mode 1 and Mode 2. Mode 1 can be implemented using the M-plane active state, and Mode 2 can be implemented using the M-plane off state. In Mode 1, for deep sleep activation, the O-RU controller sends an RPC. <deep-sleep-mode1>To activate deep sleep mode #1 in the O-RU. Furthermore, deep sleep activation in mode 1 includes: i) The O-RU controller deactivates all [tr]x-array-carriers. ii) The O-RU automatically stops the C / U / S plane processing unit. iii) Carrier configuration deletion. iv) O-RU removes other configurations and stops other hardware components. v) The O-RU sends a notification indicating that the O-RU is in a deep sleep state.

[0037] Furthermore, in Mode 1, for deep sleep deactivation, the O-RU controller sends an RPC to the O-RU. <reset>Wake as described in section 9.5.3 of WG4-MP-v14. Specifically, deep sleep deactivation in Mode 1 includes: i) The O-RU becomes operational, and all functional modules are active. ii) Carrier and other parameter configuration. iii) O-RU becomes fully active. iv) The O-RU sends a notification indicating that it has become operational.

[0038] In mode 2, for deep sleep activation, the O-RU controller sends an RPC. <deep-sleep-mode2>To activate deep sleep mode #2 in O-RU. Furthermore, in mode 2, during deep sleep activation: i) The O-RU controller sends an RPC to the O-RU. <deep-sleep-mode2>Then, the O-RU sets a monitoring timer in the O-RU according to the requirements of the deep sleep mode. In one embodiment, the maximum time for mode 2 can be 18 hours, which is supported by the current data type (uint16). Alternatively, the maximum time for mode 2 can be configured by utilizing any suitable data type used to define the date and / or time. However, the monitoring timer can be extended as required. ii) The O-RU automatically stops the C / U / S plane processing unit. iii) The carrier configuration has been removed. iv) O-RU can also remove other configurations and stop most HW components. v) The O-RU sends a notification to indicate that the O-RU is in deep sleep.

[0039] In Mode 2, for deep sleep deactivation, after the timer expires, O-RU automatically proceeds to the next step according to the "Startup" installation process described in Clause 6 of WG4-MP-v14. Specifically, in Mode 2, during deep sleep deactivation: i) The O-RU can follow the startup process and become operational with all functional modules active. ii) Carrier and other required parameter configuration. iii) O-RU becomes fully active. iv) The O-RU sends a notification indicating that the O-RU has become operational.

[0040] In one or more embodiments, the deep sleep or deep dormancy process includes: i) Shut down the O-RU including the M plane. ii) The timer for O-RU wake-up is started. iii) The timer should take into account the wake-up time of the O-RU, where it can announce the minimum / maximum / average wake-up time. iv) O-RU can be started without manual activation, based on a timer. v) M-plane shutdown timer - power management function can use NMS / NB / EMS / SMO / RIC entities to turn the M-plane on and off. vi) If deep sleep is to continue, the M-plane starts after the timer expires, and then the O-DU can extend the timer to continue deep sleep. Examples include game cancellations and shopping mall maintenance.

[0041] Potential use cases for deep sleep mode may include: i) When there are no users or low business demand, operators may decide to shut down cells and related carriers. For example, in shopping malls, stadiums, conference centers, high-rise buildings, and offices (on weekends or holidays, etc.). ii) Capacity battery - can be turned off at night.

[0042] In addition, deep sleep mode can have the following use case relevance: i) The reduction in power consumption does have a counterproductive effect, which manifests as an activation delay when making network requests. ii) This delay can potentially affect the quality of service (QoS) experienced by the user equipment (UE).

[0043] Some additional constraints on deep sleep patterns may include: i) The O-RU controller not only meets user needs, but also periodically and independently wakes up to broadcast control signals, thereby ensuring that they remain detectable by the user equipment (UE). ii) While this avoids a potential degradation in service quality, it requires specific dedicated hardware capable of receiving wake-up signals from the O-DU.

[0044] In one or more embodiments, this disclosure discloses a deep rest / deep sleep mode, which includes shutting down all content, including the M-plane, and the O-RU needs to keep a timer running to instruct the O-RU to wake up after a certain period of time.

[0045] Regarding specific use cases related to shopping malls equipped with picocells at night, all carriers may be turned off when the mall closes. However, this can be determined by the operator. Specifically, a timer-based deep sleep / deep hibernation mode can ensure the shutdown of the O-RU in the shopping mall or stadium, thereby shutting down the M-plane. Furthermore, deep sleep / deep hibernation mode may not require manual activation of the O-RU; instead, the O-RU can be woken up according to a predefined timer. Additionally, if deep sleep / deep hibernation is to continue, the M-plane can be woken up after the timer expires, and the O-RU controller can then extend the predefined timer to continue deep sleep. In some embodiments, the O-RU can provide a minimum / maximum time, i.e., a wake-up time to be considered by the predefined timer. In one embodiment, a narrowband Internet of Things (NB-IoT) switch can control the O-RU.

[0046] In one embodiment, deep sleep mode puts the O-RU into sleep mode and "forgets" all carrier configurations, which allows certain circuits to be completely powered off (depending on the O-RU architecture), but requires carrier configurations as part of the wake-up process.

[0047] However, the reduced power of using deep sleep mode may come with a trade-off between activation latency when network requests arrive, which could impact the UE's Quality of Service (QoS) experience.

[0048] In some embodiments, the base station (BS) can enter a deeper sleep level by continuously deactivating components with longer activation delays. This achieves lower overall power consumption while increasing wake-up latency. The BS has a dual responsibility to meet user needs, while also independently and periodically waking up to broadcast control signals to maintain detectability to other UEs.

[0049] In some embodiments, if there is a game scheduled or shopping mall (e.g., at night, when there are no users), the power management function can shut down and turn on the M-plane via the Network Management System (NMS).

[0050] Furthermore, in one embodiment, the wake-up duration after a deep rest is considered when setting a predefined timer. Specifically, to avoid potential quality of service degradation, certain dedicated hardware remains on to receive wake-up signals from the baseband unit (BBU).

[0051] Figure 3 The illustration depicts an operational sequence between an O-RU and an O-RU controller for activating a deep sleep mode according to one or more embodiments of the present disclosure. Specifically, Figure 3 This corresponds to deep sleep in Mode 2 as described above. Furthermore, the O-RU controller can correspond to the O-DU. In one embodiment, the O-RU can correspond to the NETCONF server, and the O-RU controller can correspond to the NETCONF client.

[0052] The deep sleep state according to Mode 2 can include the following: i) Based on business requirements, operators may decide to shut down O-RUs, including CU plane, S plane and M plane processing units. ii) The O-RU controller can set timers in the O-RU via the M plane. iii) Considering the wake-up time of the O-RU, the timer can be used specifically to activate the O-RU. iv) The O-RU can announce the corresponding minimum, maximum, and average wake-up times. v) No manual activation of the O-RU is required, as the O-RU can be automatically powered on based on a preset timer. vi) During wake-up, the O-RU may conform to the WG4-MP-V14 specification. Figure 6 The startup process defined in .1-1. In one embodiment, the power management function associated with the O-RU may have the ability to control the power state of the M-plane processing unit to turn it off and on as needed. vii) If deep sleep needs to be extended, the M-plane can be activated after the timer expires, and the O-RU controller can then extend the timer to prolong the deep sleep period. This can be applied to situations such as match cancellations or maintenance at a shopping mall.

[0053] Potential use cases for the deep sleep state based on mode 2 may include: i) When there are no users or low business demand, operators may decide to shut down cells and related carriers. For example, in shopping malls, stadiums, conference centers, high-rise buildings, and offices (on weekends or holidays, etc.). ii) In the case of a capacity cell, it can be turned off at night when demand is typically low.

[0054] Furthermore, the deep sleep mode state based on mode 2 can have the following use case relevance: i) The reduction in power consumption does have a counterproductive effect, which manifests as an activation delay when making network requests. ii) This delay can potentially affect the quality of service (QoS) experienced by the UE.

[0055] Some additional constraints on the deep sleep state according to Mode 2 can be as follows: i) The O-RU controller not only meets user needs, but also periodically (over a relatively long period of time, such as every 1 hour) wakes up the O-RU to broadcast control signals, thereby ensuring that they remain detectable by the UE. ii) While this avoids a potential degradation in service quality, it requires the M plane to become active within the aforementioned time frame in order to receive a wake-up signal from the O-RU controller.

[0056] In one or more embodiments, this disclosure discloses a deep sleep state. The deep sleep mode is used to achieve maximum power saving by de-enabling all carriers for a defined time period and subsequently de-enabling the C / U / S / M plane processing units and functions of the O-RU. This means that the O-RU is turned off, and only the deep sleep timer is running.

[0057] In one embodiment, the prerequisites for deep sleep are as follows: i) If the M-plane processing unit remains 'on', the user can deactivate the process using the existing power state or carrier.

[0058] In one embodiment, compared to the power states defined in clause 9.1.3 of the O-RAN-WG4-MP-v14 specification or the advanced sleep mode defined in clause 20.4, the deep sleep sleep state via the M plane command is used to achieve the maximum possible energy savings by disabling all carriers and C / U / S / M functions and the corresponding processing units.

[0059] In one embodiment, by including support for the feature DEEP-SLEEP-MODE in its o-ran-wg4-features.yang YANG module to disable all carriers and C / U / S / M functions, the O-RU can demonstrate the ability to support energy savings.

[0060] To implement deep sleep, the O-RU may need to advertise support for the "deep-sleep-mode” feature.

[0061] Table 2 below indicates the optional O-RAN WG4 defined feature support: Table 2

[0062] The process includes the support for the deep sleep mode feature to be advertised, and then, the deep-sleep-state (also known as the deep sleep mode or deep sleep) should be mapped to the "DEEP-SLEEP-MODE” feature.

[0063] Specifically, the process for implementing deep sleep includes: i) The O-RU controller sends an RPC <deep-sleep-mode2 or deep-sleep-mode> to the O-RU by indicating the duration in the leaf node "re-call-home-no-ssh-timer” of the o-ran-operations.yang module. ii) The O-RU receives the above RPC, processes the RPC, and then sets the deep-sleep-state to "true”.

[0064] In one or more embodiments, the D.2.3 o-ran-hardware.yang module can be defined as: module: o-ran-hardware augment / hw:hardware / hw:component: augment / hw:hardware / hw:component / hw:state: +--ro power-state? energysaving-state {ENERGYSAVING}? +--ro deep-sleep-state? {DEEP-SLEEP-MODE / DEEP-HIBERNATE}? +--ro availability-state? availability-type

[0065] The deep-sleep-state is a read-only state defined in o-ran-hardware.yang. This state is only represented by O-RUs that support the DEEP-SLEEP-MODE feature, and is used by O-RUs to notify the unit whether it is in a deep sleep mode / state, rather than in a deep-sleep-state or a transition between deep sleep and non-deep sleep states. leaf deep-sleep-state { if-feature "DEEP-SLEEP-MODE"; type boolean; config false; description "The O-RU can use this leaf node to indicate that it is in the deep sleep state.

[0066] Furthermore, when the O-RU controller sends a deep-sleep-mode RPC to the O-RU, the O-RU controller can look up the re-call-home-no-ssh-timer value because the O-RU controller can define a timer value in the RPC. This timer value indicates the duration during which the O-RU must be in deep sleep.

[0067] If deep sleep patterns are not a separate feature, then deep sleep states can be defined in the o-ran.hardware.yang model, such as power states, and mapped to ENERGY SAVING. Existing ENERGY SAVING features can be reused for deep sleep. The D.2.3 o-ran-hardware.yang module can correspond to: module: o-ran-hardware augment / hw:hardware / hw:component: augment / hw:hardware / hw:component / hw:state: +--ro power-state? energysaving-state {ENERGYSAVING}? +--ro deep-sleep-state? energysaving-state {ENERGYSAVING}? +--ro availability-state? availability-type

[0068] The deep-sleep-state can be a read-only state defined in o-ran-hardware.yang. This state is only represented by the O-RU that supports the ENERGYSAVING feature, and is used by the O-RU to notify the unit whether it is in a power-saving state activated by deep sleep mode, whether it is not in a power-saving state, or a transition between power-saving and non-power-saving states. leaf deep-sleep-state { if-feature "ENERGYSAVING"; type energysaving-state; config false; description "The O-RU can use this leaf node to indicate that it is in the deep-sleep state. Note: When the O-DU sends a deep sleep RPC to the O-RU, it must look up the `re-call-home-no-ssh-timer` value, as the O-DU will define it in that RPC. This timer value indicates the duration the O-RU must be in a deep sleep state. Figure 4 The diagram illustrates a deep-sleep-state transition diagram of an O-RU according to one or more embodiments of the present disclosure. These states can be controlled by the O-RU controller (e.g., O-DU) via RPC. <deep-sleep-mode>It can be controlled by editing the parameter energy-saving-enabled. Figure 4 The different states shown can be explained as follows: ○ AWAKE: This value for the deep-sleep-state node indicates that the O-RU is operating normally, i.e., not in power-saving mode. AWAKE corresponds to the initial value of the power state node after the O-RU is reset. AWAKE is the deep sleep state of the O-RU when energy-saving-enabled is "false" or at least one carrier is active. ○ DEEP-SLEEP / DEEP HIBERNATE SLEEP / DEEP HIBERANTE MODE: This value for the deep-sleep-state node indicates that the O-RU is in power-saving mode. If the O-RU receives an RPC... <deep-sleep-mode>Furthermore, if the value of energy-saving-enabled is "true", the O-RU can automatically stop M-plane connections and functions, as well as other C / U / S functions. This is to minimize energy consumption, which depends on the O-RU design and the implementation of the deep sleep mode. ○ UNKNOWN: This value of the deep-sleep-state node can be revealed by the O-RU, for example, when the O-RU does not know whether its deep-sleep-state value is AWAKE or SLEEPING. This value of the deep-sleep-state node is optional. In one embodiment, deep-sleep-state indicates the state of the O-RU.

[0069] After the O-RU enters deep sleep or deep hibernation mode, the O-RU can shut down the C / U / S plane processing unit and change the "deep-sleep-state". Subsequently, the O-RU sends a notification to the O-RU controller indicating the corresponding deep sleep state. Following this, the Netconf session is terminated, and the M-plane is shut down / deactivated. The D.3.1 o-ran-operations.yang module may include: module: o-ran-operations rpcs: +---x reset +---x restart-call-home {or-feat:CALL-HOME-REACTIVATION-SUPPORTED}? +---x emergency-wake-up {or-feat:TRX-CONTROL or or-feat:ADVANCED-SLEEP-MODE}? +---w input | +---w sro-id -> / or-user:users / user / sro-id {or-feat:SHARED-ORU-MULTI-OPERATOR}? +--ro output +--ro operational-status [index] +--ro index uint8 +--ro sro-id? -> / or-user:users / user / sro-id {or-feat:SHARED-ORU-MULTI-OPERATOR}? +--ro status? enumeration +---x deep-hibernate-sleep / deep-sleep-mode {or-feat: DEEP-HIBERNATE- SLEEP / ENERGYSAVING}? +---w time-duration uint32 (time duration in seconds) ? notifications: +---n emergency-wake-up-complete {or-feat:TRX-CONTROL or or-feat:ADVANCED-SLEEP-MODE}? +--n deep-sleep-mode or deep-hibernate-sleep {or-feat:ENERGYSAVING orDEEP-HIBERNATE- SLEEP}? +--ro sro-id? -> / or-user:users / user / sro-id {or-feat:SHARED-ORU-MULTI-OPERATOR}? Note: If the notification needs to be sent along with the sro-id to indicate which O-DU it is notifying, the above may apply to shared O-RU scenarios. or +---n emergency-wake-up-complete {or-feat:TRX-CONTROL or or-feat:ADVANCED-SLEEP-MODE}? +--ro sro-id? -> / or-user:users / user / sro-id {or-feat:SHARED-ORU-MULTI-OPERATOR}? +--n deep-sleep-mode {or-feat:ENERGYSAVING}? Note: If a shared O-RU scenario is not considered, the notification can be specific to an O-DU.

[0070] In one embodiment, the O-RU can remain in deep sleep mode for the duration defined in the leaf node "re-call-home-no-ssh-timer" of the o-ran-operations.yang module or a proprietary timer, after which the O-RU can initiate the 'startup' procedure outlined in Clause 6 of WG4-MP-v14. The specific steps that should be taken to begin this procedure are determined by the vendor's implementation. When the O-RU receives a deep sleep or deep hibernation RPC, the O-RU controller can look up the duration, and "re-call-home-no-ssh-timer" or some proprietary timer is assigned or mapped to calculate the duration for which the O-RU should remain in deep sleep mode. It is important to note that when the O-RU wakes up from deep sleep mode, a buffer time or 'wake-up' time must be taken into account. For example, if the O-RU has a 30-minute 'wake-up' duration and deep sleep is activated for 17 hours, then the O-RU should begin waking up from deep sleep after 16.5 hours. This ensures that the O-RU is fully operational until the end of the 17th hour, provided the M-plane is activated and a Netconf session is established. The 'wake-up' time of the O-RU is vendor-specific, and the buffer time must be incorporated into the O-RU's operational schedule. Therefore, this does not affect interoperability in multi-vendor deployment scenarios.

[0071] If we want to consider deep sleep of shared O-RUs, then we need to consider the corresponding conditions.

[0072] The disclosed process involves shutting down the M-plane, and then, during the wake-up period, an O-RU reset process can be followed (the same aspects related to the M-plane also apply here). For certain critical configurations, this can be a clean state or persistent. Otherwise, this can be a vendor-specific implementation. The buffer time should account for O-RU wake-up, followed by M-plane configuration, regardless of whether the configuration is persistent.

[0073] In one embodiment, the O-DU (O-RU controller) can be configured to... <edit-config>>Sent as an RPC command to change the state of deep sleep to "true" in O-RAN hardware.yang or operations.yang.

[0074] In addition, O-DU can identify the deep sleep activation state in the following ways: O-DU can use RPC commands as < <get-config>To retrieve the deep sleep state of the O-RU. In response, the O-DU can receive one of the following: 1. "True" (deep-sleep-enabled); 2. "Fake" (deep-sleep-disabled / awake); and 3. Unknown (Idle / Busy / Intermediate status). • In another embodiment, the O-RU uses a notification mechanism to send a deep-hibernate-sleep change notification to the O-DU.

[0075] The methods described above can be similar to one or more existing mechanisms for synchronizing state changes. Such mechanisms may include, but are not limited to, RPC-based notification enabling and leaf node-based enabling (e.g., O-RU synchronization locks, 1: using leaf nodes to synchronize the state to lock (O-DU uses get-config), and 2: using sync-state-change notifications).

[0076] Figure 5 The illustration shows an operational sequence between the O-RU and the O-RU controller for enabling a deep sleep mode according to one or more additional embodiments of the present disclosure.

[0077] At step 501, the O-RU controller can send to the O-RU <rpc> <deep-sleep-mode-re-call-home-no-ssh-timer>< / deep-sleep-mode-re-call-home-no-ssh-timer> < / rpc> As an RPC, the RPC should have a deep-hibernate-sleep setting and a duration. Whenever the O-RU receives a deep-hibernate-sleep RPC, the O-RU can identify the duration. Then, the O-RU can allocate or map a timer, depending on its design implementation. After the deep hibernate-sleep is activated, the timer starts running until the deep hibernate-sleep ends.

[0078] At step 502, the O-RU sends...<rpc-reply…> <ok / > In response.

[0079] At step 503, the O-RU processes the RPC and deactivates all carriers and C / U / S plane functions / units.

[0080] At step 504, the O-RU can send to the O-RU controller. <notification><O-RU in deep sleep mode or deep sleep mode activation successful or activated>< / notification> As a notification.

[0081] At step 505, the O-RU controller shuts down, and then the Netconf session is terminated by sending an RPC shutdown command (RPC). <close-session>, followed by or <kill-session> ， <session-id>As <rpc><close-session and / or kill-session>< / rpc> .

[0082] At step 506, the O-RU sends...<rpc-reply…> <ok / > In response.

[0083] Subsequently, at step 507, the O-RU deactivates or disables the M-plane processing unit and functions, and only allows the deep sleep timer to run. In response, the O-RU enters deep sleep mode.

[0084] At step 508, the O-RU detects that the timer has ended and begins to follow the startup process from call home, etc. (see O-RAN-WG4-MP-v14 specification clause 6).

[0085] Next, at step 509, the Netconf session begins, followed by carrier and other configurations, and then the O-RU becomes fully operational (see O-RAN-WG4-MP-v14 specification clause 6). Additionally, at step 510, the O-RU can send an energy consumption report (energy / power consumed during deep sleep) to the O-RU controller after waking up.

[0086] Figure 6 The illustration shows an operational sequence for activating a deep sleep mode between an O-RU 610 (or RU 610) and an O-RU controller 620 (or RU controller 620) according to one or more embodiments of the present disclosure. In one embodiment, the O-RU 610 may correspond to a NETCONF server, and the O-RU controller 620 may correspond to a NETCONF client. Furthermore, without departing from the scope of the present disclosure, the O-RU controller 620 may also be referred to as an O-DU.

[0087] At step 601, the O-RU controller 620 may send an RPC to the O-RU 610 to activate a deep sleep mode at the O-RU 610. The O-RU controller 620 may send the RPC to activate deep sleep and de-enable multiple functions associated with the O-RU 610. The O-RU controller 620 may also define a sleep duration in the sent RPC. The sleep duration may correspond to the duration for which the O-RU controller 620 expects the O-RU 610 to remain in deep sleep mode. The sent RPC may be defined as follows: <rpc>< / rpc> <deep-hibernate>< / deep-hibernate> <hibernate-time>x minutes< / hibernate-time>

[0088] In one embodiment, before sending an RPC to activate the deep sleep mode at O-RU 610, O-RU controller 620 may receive an indication from O-RU 610. This indication may instruct O-RU 610 to support deep sleep features associated with deep sleep modes and / or deep sleep states. Specifically, O-RU 610 may demonstrate its ability to support deep sleep features by including support for the DEEP-HIBERNATE feature in its o-ran-wg4-features.yangYANG module. Support for this feature indicates that O-RU should advertise the maximum sleep duration to data nodes, and optionally, advertise the minimum sleep duration.

[0089] O-RU 610 may announce this indication after a successful connection is established with O-RU controller 620. O-RU 610 may also announce and / or send the minimum and / or maximum duration for which O-RU 610 can activate deep sleep mode. O-RU 610 may determine the minimum duration based on its initialization and / or reset time. O-RU 610 may determine the maximum duration based on its standby capability. O-RU controller 620 may determine the sleep time based on the minimum and / or maximum duration received from O-RU 610. In one embodiment, O-RU 610 may demonstrate its ability to support deep sleep functionality by including support for the DEEP-HIBERNATE feature in its o-ran-wg4-features.yang YANG module. Support for this feature indicates that O-RU 610 may announce the maximum sleep duration to each connected data node, and optionally announce the minimum sleep duration to the data nodes.

[0090] In one embodiment, as shown in Figure 15.3.2-0b, before the O-RU controller 620 sends the deep sleep mode RPC, the O-RU controller 620 can ensure that all (multiple) [tr]x-array-carriers should be deactivated. If the O-RU 610 receives the deep sleep mode RPC while one or more [tr]x-array-carriers are active, the O-RU 610 can reject the RPC. In this case, the O-RU 610 can also send an error message to the O-RU controller 620 indicating why deep sleep cannot be activated.

[0091] At step 602, the O-RU 610 sends an RPC response to the O-RU controller 620. The RPC response can be defined as...<rpc-reply…> <ok / > An RPC response from the O-RU 610 can indicate that the O-RU 610 has successfully received and / or acknowledged the RPC used to activate deep sleep mode from the O-RU controller 620. The RPC response can also indicate that the O-RU 610 is now ready to move to deep sleep mode.

[0092] In one embodiment, when O-RU 610 accepts an RPC in deep sleep mode, O-RU 610 can notify each subscribed O-RU controller that it has accepted the RPC in deep sleep mode. This prevents other O-RU controllers from sending and / or waiting for any communication from O-RU 610. In some embodiments, O-RU 610 can notify each subscribed O-RU controller of the sleep time in the sent notification to indicate the deep sleep mode at O-RU 610.

[0093] At step 603, O-RU 610 may stop C / U / S plane functionality in response to an RPC received from O-RU controller 620 for activating deep sleep mode. In one embodiment, O-RU 610 may stop C / U / S plane functionality after sending an RPC response to O-RU controller 620.

[0094] Next, at step 604, O-RU 610 sends a notification to O-RU controller 620. This notification may indicate that O-RU 610 has activated deep sleep mode. Alternatively, the notification may indicate that C / U / S plane functionality is stopped at O-RU 610. The notification sent by O-RU 610 may be as follows: <notification> deep-hibernate-activated. < / notification>

[0095] At step 605, the O-RU 610 starts a deep sleep timer. In one embodiment, the O-RU 610 may initialize the deep sleep timer based on the sleep duration indicated in the RPC received from the O-RU controller 620 at step 601.

[0096] At step 606, the O-RU controller 620 may send an RPC command to close the active and / or established session between the O-RU 610 and the O-RU controller 620. The RPC command used to close the session may be defined as follows: <rpc> <close-session> ….< / close-session> < / rpc>

[0097] In one embodiment, at step 606, the O-RU controller 620 may instruct the O-RU 610 via an RPC command to shut down all activity / establish NETCONF sessions between the O-RU 610 and the O-RU controller 620. The O-RU controller 620 may also instruct the O-RU 610 to de-enable M-plane processing units and functions via the RPC command in step 606. In one embodiment, after deep sleep mode is activated and / or after receiving an RPC command to close the session, the O-RU 610 may de-enable / suspend all NECTONF call home operations and / or Physical Network Function (PNF) registration operations.

[0098] At step 607, O-RU 610 may de-enable the M processing unit and functions. Furthermore, O-RU 610 may disconnect and / or release all NETCONF sessions between O-RU 610 and O-RU controller 620.

[0099] At step 608, the O-RU 610 can enter a deep sleep mode. Therefore, after de-enabling each of the C-plane function / processing unit, U-plane function / processing unit, S-plane function / processing unit, and M-plane processing unit and function, the O-RU 610 can enter a deep sleep mode and achieve maximum energy saving.

[0100] At step 609, after determining that the sleep time has been reached or the deep sleep timer has expired, the O-RU 610 can be restarted. Specifically, after the deep sleep timer expires, the O-RU 610 can reinitialize each of the C-plane, U-plane, S-plane, and M-plane processing units and functions. The O-RU 610 can also initialize and / or re-establish the NETCONF session between the O-RU 610 and the O-RU controller 620.

[0101] In one embodiment, at the end of the hibernation period, the O-RU 610 can perform a reboot and follow... Figure 6 The process is defined in .1-1. After rebooting, the O-RU 610 can use the o-ran-operations.yang YANG module to set the reboot reason to DEEP-HIBERNATE-RESTART. In cases where the O-RU 610 automatically reboots in deep hibernation mode, for example, due to a software failure, the O-RU 610 may not want to continue in deep hibernation mode.

[0102] Therefore, compared with the power states defined in Section 9.1.3 of the O-RAN-WG4-MP-v14 specification or the advanced sleep mode defined in Section 20.4, the deep sleep mode and / or deep sleep state is an O-RU mode that is used to achieve relatively high energy savings by de-enabling all carriers and stopping C / U / S / M functions and corresponding processing units.

[0103] When the O-RU 610 is operating as a shared O-RU as described in Clause 19 of the O-RAN-WG4-MP-v14 specification, the O-DU or O-RU controller operating with "carrier" privileges as defined in Table 6.5-1 should be prohibited from sending RPCs in deep sleep mode.

[0104] Figure 7 A flowchart of an example method 700 according to another embodiment of the present disclosure is illustrated. Method 700 may be performed by an RU (e.g., O-RU 610), which may also be referred to as device 610.

[0105] At step 702, RU 610 may receive a deep sleep command from RU controller 620 for enabling multiple functions associated with RU 610. The deep sleep command includes a predefined duration for the deep sleep timer. In one embodiment, RU 610 may send a message to RU controller 620 indicating that RU 610 supports deep sleep features associated with a deep sleep mode. This message may also indicate the deep sleep duration supported by RU 610. The deep sleep duration may indicate the minimum or maximum duration for which RU 610 supports the deep sleep mode.

[0106] In one embodiment, to send a deep sleep command, the RU controller 620 can receive from the RU 610 a message indicating that the RU 610 supports deep sleep features associated with a deep sleep mode. The RU controller 620 can also monitor one or more parameters associated with the RU 610 over a period of time. These parameters may include, but are not limited to, the transmission and / or reception characteristics of the RU 610. Thereafter, the RU controller 620 can determine whether to activate a deep sleep mode at the RU 610 based on the monitored parameters and the message received from the RU 610. For example, after determining that the RU 610 remains idle for a specific duration each day and that the RU 610 supports a deep sleep mode, the RU controller 620 can decide to activate a deep sleep mode at the RU 610 during such a duration. Therefore, after determining that a deep sleep mode is activated at the RU 610, the RU controller 620 can send a deep sleep command to the RU 610 to deactivate the C-plane, U-plane, S-plane, and / or M-plane functions associated with the RU 610 for a predefined duration. In one embodiment, in response to a received deep sleep command, RU610 may send a remote procedure call (RPC) to RU controller 620. The RPC may instruct RU 610 to accept the deep sleep command.

[0107] Furthermore, after disabling the C-plane, U-plane, and S-plane functions, RU 610 can send a notification to RU controller 620. This notification can instruct deep sleep activation at RU 610. Additionally, RU 610 can initialize a deep sleep timer based on a predefined duration. In one embodiment, this notification can be sent via the M-plane associated with RU 610. RU controller 620 can receive this notification, and in response, RU controller 620 can send a session shutdown command to RU 610. RU controller 620 can send the session shutdown command to suspend the established / active session (e.g., a NETCONF session) between RU 610 and RU controller 620. In one embodiment, the established / active session corresponds to a management session.

[0108] At step 704, RU 610 may deactivate the C-plane, U-plane, and S-plane functions associated with RU 610 and start a deep sleep timer. RU 610 may deactivate the C-plane, U-plane, and S-plane functions in response to a received deep sleep command. In one embodiment, before deactivating the C-plane, U-plane, and S-plane functions, RU 610 may deactivate each of a plurality of carriers between RU 610 and RU controller 620. Furthermore, method 700 may include RU controller 620 determining that each of the plurality of carriers from RU controller 620 to RU 620 is deactivated. Furthermore, after determining that each of the plurality of carriers from RU controller 620 to RU 620 is deactivated, the RU controller sends a deep sleep command.

[0109] At step 706, RU 610 may receive a close session command from RU controller 620 to suspend the established / active session between RU 610 and RU controller 620.

[0110] At step 708, in response to the received session shutdown command, RU 610 may de-enable the M-plane associated with RU 610 for a predefined duration and enter deep sleep mode. Specifically, after the management session is shut down, RU 610 may de-enable the M-plane associated with RU 610 for a predefined duration and enter deep sleep mode.

[0111] RU 610 can also determine whether a deep sleep timer has timed out. In one embodiment, after determining that the deep sleep timer has timed out, RU 610 can restart the C-plane function, U-plane function, S-plane function, and / or M-plane. Furthermore, RU 610 can reinitialize the session between RU 610 and RU controller 620.

[0112] In one embodiment, RU 610 may correspond to a NETCONF server, and RU controller 620 may correspond to a NETCONF client.

[0113] The embodiments are exemplary in nature, and the sequence of method 700 may vary depending on the omission or sequence change of one or more steps.

[0114] Figure 8 An embodiment of device / apparatus 800 is illustrated. (As shown) Figure 8 As shown, device 800 includes a processor 810, a memory 820, a storage component 830, an input component 840, an output component 850, a communication interface 860, and a bus 870. Device 800 can be associated with O-RU 610 or O-RU controller 620.

[0115] As used herein, processor 810 refers to any type of computing circuit that may include hardware and software elements. Processor 810 may be embodied as a multi-core processor, a single-core processor, or a combination of one or more multi-core processors and one or more single-core processors, a distributed processing system, etc. Processor 810 may be a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), an application-specific integrated circuit (ASIC), or another type of processing component.

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

[0117] Storage component 830 stores information and / or software related to the operation and use of device 800. For example, storage component 830 may include hard disk (e.g., magnetic disk, optical disk, magneto-optical disk and / or solid-state disk), optical disk (CD), digital versatile disk (DVD), floppy disk, cassette tape, magnetic tape, and / or another type of non-transitory computer-readable medium, and corresponding drives.

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

[0119] Output component 850 is configured to provide output information from device 800. For example, output component 850 may be, but is not limited to, a display, a speaker, a command device for an external device, and / or one or more light-emitting diodes (LEDs).

[0120] Communication interface 860 is an interface that provides communication connections to other devices, such as external and internal devices. The connection of communication interface 860 can be a wired connection, a wireless connection, or a combination of wired and wireless connections, and can be a direct connection or an indirect connection via a communication network existing between device 800 and other devices. In other words, the standard of communication interface 860 is unrestricted.

[0121] Bus 870 serves as an interconnect between the processor 810, memory 820, storage component 830, input component 840, output component 850, and communication interface 860 of device 800. Bus 870 may include wired or wireless interconnects.

[0122] Figure 8 The number and arrangement of components shown are provided as an example. In practice, with... Figure 8 Compared to the examples shown, device 800 may include more components, fewer components, different components, or components arranged differently. Additionally or alternatively, a set of components of device 800 (e.g., one or more components) may perform one or more functions described as being performed by another set of components of device 800. Furthermore, one or more method steps described in any embodiment may be performed using multiple devices 800 communicating with each other.

[0123] According to one aspect, a method is disclosed. The method includes receiving a deep sleep command from a radio unit (RU) controller for deactivating multiple functions associated with the RU. The deep sleep command includes a predefined duration for a deep sleep timer. The method further includes, in response to the received deep sleep command, deactivating control plane (C-plane) functions, user plane (U-plane) functions, and synchronization plane (S-plane) functions associated with the RU. The method further includes, in response to the received deep sleep command, starting the deep sleep timer. The method further includes receiving a close session command from the RU controller for suspending an established / active session between the RU and the RU controller. In response to the received close session command, the method includes, the RU, deactivating the management plane (M-plane) associated with the RU and entering a deep sleep mode.

[0124] According to the method described in paragraph

[0122] , it further includes: before receiving the deep sleep command, the RU sends a message to the RU controller indicating that the RU supports the deep sleep feature having the deep sleep mode.

[0125] The method according to any one of paragraphs

[0122] to

[0123] further includes: before de-enabling the M plane associated with the RU, the RU de-enabling the established / active session between the RU and the RU controller based on the closed session command.

[0126] The method according to any one of paragraphs

[0122] to

[0124] further includes: before deactivating the C-plane function, the U-plane function and the S-plane function, the RU deactivates each of the plurality of carriers between the RU and the RU controller.

[0127] The method according to any one of paragraphs

[0122] to

[0125] further includes the O-RU controller determining that each of the plurality of carriers from the RU controller to the RU is deactivated. Furthermore, after determining that each of the plurality of carriers from the RU controller to the RU is deactivated, the method includes the RU controller sending the deep sleep command.

[0128] The method according to any one of paragraphs

[0122] to

[0126] further includes: in response to a received deep sleep command, the RU sending a remote procedure call (RPC) message indicating acceptance of the deep sleep command to the RU controller. The RPC message may be sent before de-enabling the C-plane function, the U-plane function, and the S-plane function. Furthermore, the method includes: after de-enabling the C-plane function, the U-plane function, and the S-plane function, the RU sending a notification to the RU controller indicating deep sleep activation at the RU.

[0129] The method according to any one of paragraphs

[0122] to

[0127] further includes the RU determining whether the deep sleep timer has timed out. The method further includes, after determining that the deep sleep timer has timed out, the RU restarting at least one of the C-plane function, the U-plane function, the S-plane function, and the M-plane. The method further includes the RU re-initializing the session between the RU and the RU controller.

[0130] The method according to any one of paragraphs

[0122] to

[0128] further includes the RU controller receiving from the RU a message indicating that the RU supports the deep sleep feature associated with the deep sleep mode. The method further includes the RU controller monitoring one or more parameters associated with the RU over a time period. The method further includes the RU controller determining, based on the monitored one or more parameters and the message received from the RU, that the deep sleep mode is activated at the RU. Furthermore, after determining that the deep sleep mode is activated at the RU, the method includes the RU controller sending the deep sleep command to the RU to deactivate the C-plane function, the U-plane function, and the S-plane function associated with the RU for a predefined duration.

[0131] The method according to any one of paragraphs

[0122] to

[0129] further includes the RU sending the notification to the RU controller via the M plane associated with the RU.

[0132] The method according to any one of paragraphs

[0122] to

[0130] further includes receiving the notification from the RU by the RU controller, the notification indicating the activation of the deep sleep at the RU. Furthermore, in response to receiving the notification, the method includes sending the session shutdown command from the RU controller to the RU to suspend the established / active session between the RU and the RU controller.

[0133] According to another aspect, an apparatus associated with a radio unit (RU) is disclosed. The apparatus is configured to receive a deep sleep command from an RU controller for disabling multiple functions associated with the RU. The deep sleep command includes a predefined duration for a deep sleep timer. The apparatus is also configured to disable control plane (C-plane), user plane (U-plane), and synchronization plane (S-plane) functions associated with the RU, and to start the deep sleep timer. The apparatus disables the C-plane, U-plane, and S-plane functions in response to the received deep sleep command. The apparatus is further configured to receive a close session command for suspending an established / active session between the RU and the RU controller. The close session command is received from the RU controller. The apparatus is also configured to disable the management plane (M-plane) associated with the RU. The M-plane is disabled in response to the received close session command. The apparatus is also configured to enter the deep sleep mode.

[0134] According to the apparatus described in paragraph

[0132] , the apparatus is configured to send a message to the RU controller prior to receiving the deep sleep command, the message indicating that the RU supports the deep sleep feature having the deep sleep mode.

[0135] The apparatus according to any one of paragraphs

[0132] to

[0133] , wherein the apparatus is configured to disable the established / active session between the RU and the RU controller based on the session shutdown command before de-enabling the M plane associated with the RU.

[0136] The apparatus according to any one of paragraphs

[0132] to

[0134] , wherein the apparatus is configured to deactivate each of a plurality of carriers between the RU and the RU controller before deactivating the C-plane function, the U-plane function and the S-plane function.

[0137] The apparatus according to any one of paragraphs

[0132] to

[0135] is further configured to send a Remote Procedure Call (RPC) message indicating acceptance of the deep sleep command to the RU controller in response to the received deep sleep command. The RPC message is sent before de-enabling the C-plane function, the U-plane function, and the S-plane function. Furthermore, the apparatus is configured to send a notification indicating deep sleep activation at the RU to the RU controller after de-enabling the C-plane function, the U-plane function, and the S-plane function.

[0138] The apparatus according to any one of paragraphs

[0132] to

[0135] is further configured to determine whether the deep sleep timer has timed out. After determining that the deep sleep timer has timed out, the apparatus is configured to perform at least one of the following: restarting at least one of the C-plane function, the U-plane function, the S-plane function, and the M-plane; and reinitializing the session between the RU and the RU controller.

[0139] According to another aspect, a non-transitory computer-readable medium storing instructions is disclosed. The instructions include one or more instructions executed by a wireless unit (O-RU) comprising one or more processors. The instructions cause the one or more processors to receive from an RU controller a deep sleep command for deactivating multiple functions associated with the RU. The deep sleep command includes a predefined duration for a deep sleep timer. The instructions cause the one or more processors, in response to the received deep sleep command, to deactivate control plane (C-plane) functions, user plane (U-plane) functions, and synchronization plane (S-plane) functions associated with the RU, and to start the deep sleep timer. The instructions cause the one or more processors, in response to the received deep sleep command, to deactivate the C-plane functions, the U-plane functions, and the S-plane functions. The instructions cause the one or more processors to receive a close session command for suspending an established / active session between the RU and the RU controller. The close session command is received from the RU controller. The instructions cause the one or more processors to deactivate the management plane (M-plane) associated with the RU. The M-plane is deactivated in response to the received close session command. The instructions cause the one or more processors to enter a deep sleep mode.

[0140] Therefore, compared to the power states defined in Section 9.1.3 of the O-RAN-WG4-MP-v14 specification or the advanced sleep mode defined in Section 20.4, deep sleep corresponds to the RU (O-RU) mode, which can be used to achieve relatively higher energy savings by de-enabling all carriers and stopping C / U / S / M functions and corresponding processing units. < / kill-session> < / reset>

Claims

1. A method (700) comprising: The radio unit (RU) receives (702) a deep sleep command from the RU controller to de-enable multiple functions associated with the RU, wherein the deep sleep command includes a predefined duration for a deep sleep timer; In response to the received deep sleep command, the RU de-enables (704) the control plane (C plane) function, user plane (U plane) function and synchronization plane (S plane) function associated with the RU, and starts the deep sleep timer; The RU receives (706) a close session command from the RU controller to suspend the established / active session between the RU and the RU controller; as well as In response to the received session shutdown command, the RU de-enables (708) the management plane (M plane) associated with the RU and enters the deep sleep mode.

2. The method (700) according to claim 1, wherein before receiving the deep sleep command, the method comprises: The RU sends a message to the RU controller, the message indicating that the RU supports the deep sleep feature with the deep sleep mode.

3. The method (700) of claim 1, wherein before de-enabling the M plane associated with the RU, the method comprises: The RU enables the established / active session between the RU and the RU controller based on the closed session command.

4. The method (700) of claim 1, wherein before de-enabling the C-plane function, the U-plane function, and the S-plane function, the method comprises: The RU deactivates each of the multiple carriers between the RU and the RU controller.

5. The method (700) of claim 1, wherein receiving a deep sleep command by the RU for de-enabling a plurality of functions associated with the RU comprises: The RU controller determines that each of the plurality of carriers from the RU controller to the RU is deactivated; After determining that each of the plurality of carriers from the RU controller to the RU is deactivated, the deep sleep command is sent by the RU controller.

6. The method (700) according to claim 1, comprising: In response to the received deep sleep command, before de-enabling the C-plane function, the U-plane function and the S-plane function, the RU sends a remote procedure call (RPC) message to the RU controller indicating acceptance of the deep sleep command; as well as After de-enabling the C-plane function, the U-plane function, and the S-plane function, the RU sends a notification to the RU controller indicating that deep sleep activation is enabled at the RU.

7. The method (700) according to claim 1, comprising: The RU determines whether the deep sleep timer has timed out; After determining that the deep sleep timer has timed out, perform at least one of the following: The RU restarts at least one of the C-plane function, the U-plane function, the S-plane function, and the M-plane; and The session between the RU and the RU controller is reinitialized by the RU.

8. The method (700) of claim 1, wherein receiving the deep sleep command from the RU controller comprises: The RU controller receives the message from the RU, the message indicating that the RU supports the deep sleep feature associated with the deep sleep mode; The RU controller monitors one or more parameters associated with the RU within a time period; The RU controller determines whether to activate the deep sleep mode at the RU based on one or more monitored parameters and the messages received from the RU. as well as After determining that the deep sleep mode is activated at the RU, the RU controller sends the deep sleep command to the RU to deactivate the C-plane function, the U-plane function, and the S-plane function associated with the RU for the predefined duration.

9. The method (700) of claim 6, wherein sending the notification indicating deep sleep activation at the RU by the RU comprises: The notification is sent by the RU to the RU controller via the M plane associated with the RU.

10. The method (700) of claim 6, wherein receiving the session shutdown command from the RU controller comprises: The notification is received by the RU controller from the RU, the notification indicating that the deep sleep at the RU is activated; as well as In response to receiving the notification, the RU controller sends the close session command to the RU to suspend the established / active session between the RU and the RU controller.

11. An apparatus associated with a wireless unit (RU) (610), configured to: Receives a deep sleep command from the RU controller (620) for de-enabling a plurality of functions associated with the RU (610), wherein the deep sleep command includes a predefined duration for a deep sleep timer; In response to the received deep sleep command, the control plane (C plane) function, user plane (U plane) function and synchronization plane (S plane) function associated with the RU (610) are enabled, and the deep sleep timer is started; Receive a close session command from the RU controller (620) for suspending the established / active session between the RU (610) and the RU controller (620); and In response to the received session shutdown command, the management plane (M plane) associated with the RU (610) is enabled, and the deep sleep mode is entered.

12. The apparatus of claim 11, wherein before receiving the deep sleep command, the apparatus is configured to: A message is sent to the RU controller (620), the message indicating that the RU (610) supports the deep sleep feature with the deep sleep mode.

13. The apparatus of claim 11, wherein the apparatus is configured to: before de-enabling the M-plane associated with the RU. Based on the closed session command, the established / active session between the RU (610) and the RU controller (620) is deactivated.

14. The apparatus of claim 11, wherein before de-enabling the C-plane function, the U-plane function, and the S-plane function, the apparatus is configured to: Deactivate each of the plurality of carriers between the RU (610) and the RU controller (620).

15. The apparatus of claim 11, further configured to: In response to the received deep sleep command, before de-enabling the C-plane function, the U-plane function, and the S-plane function, a remote procedure call (RPC) message indicating acceptance of the deep sleep command is sent to the RU controller (620); and After de-enabling the C-plane function, the U-plane function and the S-plane function, a notification instructing the deep sleep activation at the RU (610) is sent to the RU controller (620).

16. The apparatus of claim 11, further configured to: Determine whether the deep sleep timer has timed out; After determining that the deep sleep timer has timed out, perform at least one of the following: Restart at least one of the C-plane function, the U-plane function, the S-plane function, and the M-plane function; and Reinitialize the session between the RU (610) and the RU controller (620).

17. A non-transitory computer-readable medium storing instructions, the instructions comprising one or more instructions, which, when executed by a wireless unit (O-RU) (610) including one or more processors, cause the one or more processors to: Receives a deep sleep command from the RU controller (620) for de-enabling a plurality of functions associated with the RU (610), wherein the deep sleep command includes a predefined duration for a deep sleep timer; In response to the received deep sleep command, the control plane (C plane) function, user plane (U plane) function and synchronization plane (S plane) function associated with the RU (610) are enabled, and the deep sleep timer is started; Receive a close session command from the RU controller (620) for suspending the established / active session between the RU (610) and the RU controller (620); and In response to the received session shutdown command, the management plane (M plane) associated with the RU (610) is enabled, and the deep sleep mode is entered.

Images