Deep hibernate mode in a radio access network architecture

Abstract

A method (700) is disclosed. The method includes receiving (702), by a Radio Unit (RU) a deep hibernate command to disable a plurality of functions associated with the RU from a RU-controller. The deep hibernate command comprises a predefined time duration for a deep hibernate timer. Further, the method includes disabling (704), by the RU, a Control Plane (C-Plane) function, a User Plane (U-Plane) function, and a Synchronization Plane (S-Plane) function associated with the RU and initiating the deep hibernate timer. Moreover, the method includes receiving (706), by the RU, a close-session command to suspend an established / active session between the RU and the RU controller, from the RU controller. Furthermore, in response to the received close-session command, the method includes disabling (708), by the RU, a Management Plane (M-Plane) associated with the RU and entering the deep hibernate mode.

Description

DEEP HIBERNATE MODE IN A RADIO ACCESS NETWORK ARCHITECTURECROSS-REFERENCE TO RELATED APPLICATION (S)This application claims priorities to IN provisional application 202411006862, filed onFebruary 01, 2024 and IN non-pro visional application 202411006862, filed on July 17, 2024; the entire contents of which are incorporated herein by reference.FIELD

[0001] The present disclosure relates to deep hibernate mode implementation in a Radio Access Network (RAN) architecture.BACKGROUND

[0002] The information disclosed in this background section is only for enhancement of understanding of the general background of the disclosure and should not be taken as an acknowledgement or any form of suggestion that this information forms the prior art already known to a person skilled in the art.

[0003] A Radio Access Network (RAN) is an important component in a telecommunication system and includes multiple network entities or network components that facilitate connections with end-user devices (user equipment). In recent years, Open RAN (O- RAN) architecture has been developed that disaggregates functions of the RAN through various logical nodes. Typically, an O-RAN architecture includes logical nodes such as an O- RAN Radio Unit (O-RU), a O-RAN Centralized Unit (O-CU), and a O-RAN Distributed Unit (O-DU). The O-CU may further be disaggregated into an O-CU control plane (O-CU-CP) andan O-CU user plane (O-CU-UP). One of the main challenges in the conventional O-RAN architecture is power consumption of these logical nodes, as this can affect operational cost, batery life, and environmental impact of the associated telecommunication system. Specifically, the power consumption by the O-RU is crucial due to limited power capabilities.

[0004] Therefore, there is a need to address the above-mentioned problem(s) of the RAN architecture.SUMMARY

[0005] This summary is provided to introduce a selection of concepts, in a simplified format, that are further described in the detailed description of the disclosure. This summary is neither intended to identify key or essential inventive concepts of the present disclosure nor is it intended to determine the scope of the disclosure.

[0006] Power consumption at logical nodes such as, a RU of an RAN affect operational cost, battery' life, and environmental impact of an associated communica tion system. Therefore, there is a need to optimize power consumption at the RU.

[0007] Disclosed herein are systems and methods for deep hibernate mode in an RAN architecture.

[0008] According to one embodiment of the present disclosure, a method is disclosed. The method includes receiving, by a Radio Unit (RU), a deep hibernate command to disable a plurality of functions associated with the RU from a RU-controller. The deep hibernate command comprises a predefined time duration for a deep hibernate timer. In response to the received deep hibernate command, the method includes disabling, by the RU, a Control Plane (C -Plane) function, a User Plane (U-Plane) function, and a Synchronization Plane (S-Plane) function associated with the RU. The method further includes initiating the deep hibernate timer. Thereafter, the method includes receiving, by the RU, a close-session command tosuspend an established / active session between the RU and the RU controller, from the RU controller. In response to the received close-session command, the method includes disabling, by the RU, a Management Plane (M-Plane) associated with the RU. Furthermore, the method includes entering the deep hibernate mode by the RU.

[0009] .According to another embodiment of the present disclosure, an apparatus associated with a Radio Unit (RU) is disclosed. The apparatus is configured to receive a deep hibernate command to disable a plurality of functions associated with the RU from a RU- controller. The deep hibernate command comprises a predefined time duration for a deep hibernate timer. In response to the received deep hibernate command, the apparatus is configured to disable a Control Plane (C -Plane) function, a User Plane (U-Plane) function, and a Synchronization Plane (S-Plane) function associated with the RU. The apparatus is also configured to initiate the deep hibernate timer. The apparatus is further configured to receive a close-session command to suspend an established / active session between the RU and the RU controller, from the RU controller. In response to the received close-session command, the apparatus is configured to disable a Management Plane (M-Plane) associated with the RU. The apparatus is also configured to enter the deep hibernate mode.

[0010] According to another embodiment of the present disclosure, a non-transitory computer-readable medium storing instructions is disclosed. The instructions include one or more instructions that are executed by a Radio Unit (RU) comprising one or more processors. The instructions cause the one or more processors to receive a deep hibernate command to disable a plurality of functions associated with the RU from a RU -controller. The deep hibernate command comprises a predefined time duration for a deep hibernate timer. The instructions cause the one or more processors to disable a Control Plane (C-Plane) function, a User Plane (U-Plane) function, and a Synchronization Plane (S-Plane) function associated withthe RU. The instructions cause the one or more processors to disable the C-Plane, the U-Plane, and the S-Plane functions in response to the received deep hibernate command. The instructions also cause the one or more processors to initiate the deep hibernate timer in response to the received deep hibernate command. The instructions cause the one or more processors to receive a close-session command to suspend 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 disable a Management Plane (M-Plane) associated with the RU. The M-Plane is disabled in response to the received closesession command. The instructions cause the one or more processors to enter the deep hibernate mode.

[0011] To further clarify the advantages and features of the present disclosure, a more particular description of the disclosure will be rendered by reference to specific embodiments thereof, which is illustrated in the appended drawing. It is appreciated that these drawings depict only typical embodiments of the disclosure and are therefore not to be considered limiting its scope. The disclosure will be described and explained with additional specificity and detail with the accompanying drawings.BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Features, aspects, and advantages of embodiments of the disclosure will be described below with reference to the accompanying drawings, in which like reference numerals denote like elements, and wherein:FIG. I illustrates a sequence of operations between an O-RU and an O-RU controller to enable a deep sleep mode, in accordance with one or more embodiments of the present disclosure;FIG. 2 illustrates a sequence of operations between the O-RU and the O-RU controller to disable the deep sleep mode, in accordance with one or more embodiments of the present disclosure;FIG. 3 illustrates a sequence of operations between the O-RU and the O-RU controller to activate deep sleep mode, in accordance with one or more embodiments of the present disclosure;FIG. 4 illustrates a deep- sleep- state transition diagram for the O-RU, in accordance with one or more embodiments of the present disclosure;FIG. 5 illustrates a sequence of operations between the O-RU and the O-RU controller to enable deep sleep mode, in accordance with one or more additional embodiments of the present disclosure;FIG. 6 illustrates a sequence of operations between the O-RU and the O-RU controller to activate a deep hibernate mode, in accordance with an embodiment of the present disclosure;FIG. 7 illustrates a flow chart of an example method, in accordance with an embodiment of the present disclosure; andFIG. 8 illustrates an embodiment of an example device, in accordance with an embodiment of the present disclosure.DETAILED DESCRIPTION

[0013] The following detailed description of example embodiments refers to the accompanying drawings. The present disclosure provides illustrations and descriptions, but is not intended to be exhaustive or to limit the implementations to the precise form disclosed. Modifications and variations are possible in light of the present disclosure or may be acquired from practice of the implementations. Further, one or more features or components of one embodiment may be incorporated into or combined with another embodiment (or one or morefeatures of another embodiment). Additionally, the flowchart and description of operations provided below relate to at least one of the embodiments in the present disclosure. It should be noted that it is possible to make other embodiments that do not exactly match the flowchart and its description. It is understood that in other embodiments 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).

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

[0015] Even though particular combinations of features are recited in the claims and / or disclosed in the specification, the particular combinations are not intended to limit the disclosure of implementations. In fact, many of these features may be combined in ways not specifically recited in the claims and / or disclosed in the specification. Even if a dependent claim directly depends on only one claim, the present disclosure may indicate that the dependent claim is dependent on other claims in the claim set.

[0016] No element, act, or instruction used herein should be construed as critical or essential unless explicitly described as such. .Also, as used herein, the articles “a” and “an” (in other words, nouns not mentioned in the plural) are intended to include one or more items, and may be used interchangeably with “one or more.” Also, as used herein, the terms “has,” “have,” “having,” “include,” “including,” or the like are intended to be open-ended terms. Further, thephrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise. Furthermore, expressions such as “at least one of [A] and [B],” “[A] and / or [B],” or“at least one of [A] or [B]” are to be understood as including only A, only B, or both A and B.

[0017] The present disclosure may be described with reference to a network management entity associated with a RAN. The network management entity may be configured to manage services in an O-RAN. In some embodiments, the network management entity may be implemented in the form of virtualized software units in hardware or cloud environments. In some embodiments, the network management entity may be implemented as dedicated hardware units. The network management entity may be associated with an O-RU, an O-CU, and an O-DU among other components of the O- RAN.

[0018] The terms “deep sleep”, “deep-hibemate sleep”, “deep-hibernate sleep mode”, “deep-hibernate mode”, “deep sleep mode”, or “deep hibernate” may be used interchangeably throughout the description.

[0019] In the present disclosure, an O-RU controller or a RU-controller may correspond to one of an O-DU or a Sendee Management and Orchestration (SMO) entity. Further, in case of the SMO, the SMO may coordinate with the O-DU to activate the deep-hibernate sleep, in accordance with the one or more embodiments of the present disclosure.

[0020] The present disclosure relates to a deep hibernate mode that is based on Management Plane (M-Plane) deactivation and / or disabling of a Control Plane (C -Plane), a User Plane (U-Plane), a Session Plane (S-Plane), and the M-Plane. The M-Plane is part of a network system configured for configuration, monitoring, management, and distribution of various services to all layers of a network stack and other parts of the network system. The deep hibernate mode enables maximum energy saving in a Radio Unit (RU). The deep hibernate mode includes applying deactivation to the whole RU not only to per[tr]x - arrays / [tr]x-array-carriers. In particular, the deep hibernate inode corresponds to all the carriers associated with the RU being put to sleep / turned off. Further, the deep hibernate mode includes clearing all carrier configurations associated with the RU. The carrier configuration may be deleted using any suitable reset procedure. The deep hibernate mode may be enabled with a predefined sleep duration, i.e., the RU may remain in the deep hibernate mode for a specific period of time with only a deep hibernate timer running in the RU.

[0021] FIG. 1 illustrates a sequence of operations between an 0-RU and an 0-RU controller (for example, 0-DU or the SMO) to enable deep sleep mode, in accordance with one or more embodiments of the present disclosure.

[0022] At step 101, the O-RU transmits a message to the O-RU controller advertising that the O-RU supports the deep sleep feature. At step 102, the O-RU controller receives either a trigger or a policy from a higher layer entity or a management / intelligent entity to start the deep sleep mode at the O-RU. Example of such management / intelligent entity includes a Radio Intelligent Controller (RIC), a Sendee Management and Orchestration (SMO) entity, north bound entity, an Element Management System (EMS), etc.

[0023]

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

[0025] At step 105, the O-RU responds with an RPC as follows: <rpc- reply ...><ok / >< / rpc-reply>. The transmitted RPC from the O-RU indicates that all the transmission [tr]x-array-carriers are disabled at the O-RU. Next, at step 106, the O-RU stops all Radio Frequency (RF) transmission.

[0026] The step 107 corresponds to clearing or deleting carrier configuration in the O- RU. Specifically, at step 107.1, the 0-RU controller transmits RPC to edit the configuration to the 0-RU which states as follows: <rpc><edit-config> <[tr]x-array-carriers’ parameters or block with operation ==delete> < / edit-config>< / rpc>. Next, at step 107.2, upon processing the RPC from the O-RU controller, the O-RU responds with a reply as <rpc-reply. . ,><ok / >< / rpc- reply>. Thereafter, at step 107.3, the O-RU may autonomously delete the carrier configuration block based on the deep sleep enable / start command.

[0027] Step 108 corresponds to the O-RU specific implementation of turning off O-RU modules. For instance, at step 108.1, the O-RU turns off both Control Plane and User Plane (CU-Plane) and a Synchronization-Plane (S-Plane) processing unit. Alternatively, at step 108.2, the O-RU turns off only the CU-Plane processing unit.

[0028] Post step 108, the O-RU may be in the deep sleep state / mode. Further, at step 109, the O-RU transmits a notification to the O-DU that indicates the completion of the deep sleep activation. In particular, the O-RU transmits the message as <notification><deep-sleep- activation-complete>< / notification>.

[0029] FIG. 2 illustrates a sequence of operations between the O-RU and the O-RU controller to disable the deep sleep mode, in accordance with one or more embodiments of the present disclosure. The sequence of operations illustrated in FIG. 2 is based on assumptions that the O-RU is in deep sleep state with all configurations as explained in reference to FIG. 1.

[0030] At step 201, the O-RU controller may receive either a trigger from a higher layer entity or based on a policy to stop the deep sleep mode. In response to the received trigger or policy, at step 202, the O-RU controller may transmit an RPC to stop deep sleep as <rpc><stopdeep-sleep>< / rpc>.

[0031] At step 203, the O-RU may enable all [tr]x-array-carriers and change the state to “READY”. Further, at step 204, the O-RU may transmit the reply as <rpc-reply. ..><ok / >< / rpc- reply> to the O-RU controller.

[0032] Step 205 corresponds to a reconfiguration of the carriers in the O-RU. In particular, at step 205.1, the O-RU controller may transmit the following RPC to edit the configuration to the O-RU: <rpc><edit-config><[tr]x-array-carriers parameters or block with operation =merge>< / edit-config>< / rpc>. Upon processing the RPC to edit the configuration, the O-RU transmits a reply to the O-DU as <rpc-reply. ..><ok / >< / rpc-reply>, at step 205.2. At step 205.3, the O-RU may autonomously populate or create the carrier configuration block based on the deep sleep disable / stop command.

[0033] Step 206 may correspond to specific implementations of the O-RU on restart of the O-RU modules that are in deep sleep state / mode. In particular, at step 206.1, the O-RU turns on both CU and S-Plane processing units. Alternatively, at step 206.2, the O-RU turns on the CU-Plane processing unit. After performing the step 206, the O-RU may now be in an operational state.

[0034] At step 207, the O-RU may send a notification indicating completion of the deep sleep mode to the O-RU controller as: <notification><deep-sleep-deactivation- complete>< / notification>. At step 208, the O-RU may start the RF transmissions.Moreover, during the carrier configuration procedure, the behavior of the O-RU may be as follows: o During deletion of the carrier configuration in the O-RU:Option 1 : The O-RU controller (O-DU or SMO) sends RPC «edit-config» with operation “delete” to the O-RU to delete the whole o-ran.uplane- config.yang file parameters. In response,Fault id (Alarm)#! 2 is raised, and the 0-R.U undergoes reset as recovery action as shown in below Table 1 :Option 2: The O-RU controller sends RPC «edit~config» with operation “delete” to the carrier configuration block or specific carrier-related parameters. « After deleting the carrier configurations, the CU-Plane processing unit can be turned off, thereby avoiding Alarm#28 as shown in below Table 1.Table 1During reconfiguration of the carrier in the O-RU:Option 1 : The O-RU controller sends RPC «edit-config» with operation “merge” to the O-RU to configure all applicable parameters of the o-ran.uplane-config.yang file.Option 2: The O-RU controller sends RPC «edit-config» with operation “merge” to the O- RU to configure applicable parameters in the carrier configuration block.

[0035] In one or more embodiments, the deep sleep procedure may operate in two modes i.e., mode 1 and mode 2. The mode 1 may be implemented with an M-Plane active state and the mode 2 may be implemented with an M-Plane turned off state. In the mode 1, for deep sleep activation, the O-RU controller sends an RPC <deep-sleep-model> to activate the deep sleep mode#l in the O-RU. Further, the deep sleep activation in the mode 1 includes: i) The O-RU controller deactivates all [tr]x-array-carriers. ii) The O-RU autonomously stopping C / U / S Plane processing units. iii) Carrier configurations deletion. iv) Deletion of other configurations and stopping of other hardware components by the O-RU. v) The O-RU sending a notification to indicate that the O-RU is in deep sleep.

[0036] Further, in mode 1 , for deep sleep deactivation, the O-RU controller sends an RPC <reset> to the O-RU to wake up as described in clause 9.5.3 of WG4-MP-V14. Specifically, the deep sleep deactivation in the mode 1 includes: i) The O-RU becomes operational, and all functional modules are active. ii) The carrier and other parameters configuration. iii) The O-RU becomes fully active. iv) The O-RU sending a notification to indicate that it has become operational.

[0037] In mode 2, for deep sleep activation, the O-RU controller sends an RPC <deep- sleep-mode2> to activate the deep sleep mode#2 in the O-RU. Further, in the deep sleep activation in mode 2: i) The O-RU controller sends the RPC<deep-sleep-mode2> to the O-RU, which then sets a supervision timer in the O-RU as required for the deep sleep mode. In one embodiment, a maximum time for the mode 2 may be 18 hours as supported by a current data type (uint!6). Alternatively, the maximum time for mode 2 may be configured by utilizing any suitable data type for defining date and / or time. However, the supervision timer may be extended as per the requirements. ii) The O-RU autonomously stops C / U / S Plane processing units. iii) The carrier configurations are deleted. iv) The O-RU may also delete other configurations and stop most of the HW components. v) The O-RU sends a notification to indicate that the O-RU is in the deep sleep.

[0038] In mode 2, for the deep sleep deactivation, once the timer ends, the O-RU autonomously proceeds with the next steps as per “Start-up” installation procedure described in Clause 6 of WG4-MP-V14. Specifically, in the deep sleep deactivation in mode 2: i) The O-RU may follow the start-up procedure and become operational with all functional modules being active. ii) The carrier and other required parameters configuration. iii) The O-RU becomes fully active. iv) The O-RU sends a notification to indicate that the O-RU has become operational.

[0039] In one or more embodiments, the deep sleep or deep dormancy procedure includes: i) Turn off the O-RU including M-Plane. ii) A timer for the O-RU wake-up is initiated. iii) The timer should consider the wake-up time of the O-RU, where it can advertise the min / max / average wake-up time. iv) Don’t have to manually turn on the O-RU, based on the timer, O-RU can come up. v) M-Plane shutdown timer - Power management function can shut off and turn on the M-Plane with NMS / NB / EMS / SMO / RIC entity. vi) If deep sleep is to be continued, M-Plane comes up after the timer ends, then O-DU can extend the timer to continue the deep sleep. For e.g., match cancellation, shopping mall maintenance, etc.

[0040] The potential use cases of the deep sleep mode may include: i) An operator may decide to shut off the cell and associated carriers when there are no users or fewer traffic requirements. For instance, in shopping malls, stadiums, convention centers, high-rise buildings, and offices (during weekends or holidays, etc.). ii) Capacity cell- during nighttime can be shut off.

[0041] Further, the deep sleep mode may have the following use case dependencies: i) The reduction in power usage does have a countereffect, which manifests as an activation delay when network requests are made. ii) This delay could potentially impact the quality of service (QoS ) that the User Equipment (UEs) experiences.

[0042] Some additional constraints to the deep sleep mode may include:i) The O-RU controller not only caters to user demands but also periodically awakens independently to broadcast control signals, thereby ensuring they remain detectable by user equipment (UEs). ii) While this can avoid potential degradation in service quality, it necessitates specific dedicated hardware capable of receiving wake-up signals from the O-DU.

[0043] In one or more embodiments, the present disclosure discloses deep dormancy / deep hibernate mode that includes turning off everything including the M-Plane, and also the O-RU needs to keep the timer running that indicates O-RU to wake up after some time.

[0044] Regarding a specific use case related to a mall with a pico-cell at night, when the mall closes down, and all the carriers may be shut down. However, this may be decided by the operator. Specifically, a timer-based deep-dormancy / deep-hibemate mode ensures turning off the O-RU in a shopping mall or a stadium so that the M-Plane can be turned off. Further, the deep dormancy / deep-hibemate mode may not require manually turning on the O-RU, instead, the O-RU may wake up based on a predefined timer. Further, if the deep sleep / deep hibernate is to be continued, the M-Plane may wake up after the timer ends, then the O-RU controller may extend the predefined timer to continue the deep sleep. In some embodiments, the O-RU may provide min / max time, i.e., the wake-up time to be considered for the predefined timer. In one embodiment, the Narrow Band-Internet of Things (NB-IoT) switch may control O-RU.

[0045] In an embodiment, the deep hibernate mode puts the O-RU to sleep and "forgets" all the carrier configuration, this allows a complete power-off of certain circuits (depending on the O-RU architecture) but requires carrier configuration as a part of the wake-up process.

[0046] However, the power reduction using the deep sleep mode may come with the trade-off of an a ctivation delay when the network requests arrive, which could potentially affect the Quality of Service (QoS) experience by the UEs.

[0047] In some embodiments, a Base Station (BS) may come into deeper sleep levels by successively deactivating components with longer activation delays. Consequently, lower overall power consumption is achieved while increasing the wake up latency. The BSs have the dual responsibility of catering to user demands while also independently waking up periodically to broadcast control signals to remain detectable to other UEs.

[0048] In some embodiments, the power management function can shut off the M-Plane and turn on the M-Plane through a Network Management System (NMS), if there is a match scheduled to happen or a shopping mall (e.g., at nighttime, there are no users).

[0049] Further, in one embodiment, a wake-up duration after deep dormancy is considered while setting the predefined timer. Specifically, to avoid potential sendee quality degradation certain dedicated hardware remained turned on to receive wake-up signals from the Baseband Unit (BBU).

[0050] FIG. 3 illustrates a sequence of operations between the O-RU and the O-RU controller to activate deep sleep mode, in accordance with one or more embodiments of the present disclosure. In particular, FIG. 3 corresponds to deep sleep in mode 2 as discussed above. Further, the O-RU controller may correspond to the O-DU. In one embodiment, the O-RU may correspond to a NETCONF server, and the O-RU controller may correspond to a NETCONF client.

[0051] The deep sleep state in accordance with mode 2 may include the following points: i) Depending on the traffic requirements, an operator may decide to turn off the O-RU including the CU-Plane, the S-Plane, and M-Plane processing units. ii) The O-RU controller may set a timer in O-RU via the M-Plane. iii) The timer may be specifically intended for activating the O-RU, in consideration of the O-RU's wake-up time.iv) The O-RU may advertise a corresponding minimum, maximum, and average wake-up times. v) No need for manual activation of the O-RU, as the O-RU may automatically power up based on a pre-set timer. vi) During wake-up, the O-RU may follow the start-up procedure defined in Figure6.1-1 of the WG4-MP-V14 spec.In an embodiment, a power management function associated with O-RU may have the ability to control the power state of the M-Plane processing unit, turning it off and on as required. vii) If deep sleep is to be extended, the M-Plane may be activated after the timer ends, and the O-RU controller may then extend the timer to prolong the deep sleep period. This may be applicable in situations like match cancellation, during maintenance at a shopping mall, etc.

[0052] The potential use cases of the deep sleep state in accordance with the mode 2 may include: i) An operator may decide to shut off the cell and associated carriers when there are no users or fewer traffic requirements. For instance, in shopping malls, stadiums, convention centers, high-rise buildings, and offices (during weekends or holidays, etc.). ii) In the case of capacity cells, these can be shut off during nighttime when demand is typically lower.

[0053] Further, the deep sleep mode state in accordance with the mode 2 may have the following use case dependencies: i) The decrease in power usage does have a countereffect, which manifests as an activation delay when network requests are made.ii) This delay could potentially impact the quality of service (QoS) that the UEs experiences.

[0054] Some additional constraints to the deep sleep mode state in accordance with the mode 2 may be as follows: i) The O-RU controllers not only cater to user demands but also periodically (for a relatively long time, e.g., every 1 hour) wake up the O-RU to broadcast control signals, thereby ensuring they remain detectable by a UE. ii) While this can avoid potential degradation in service quality, it necessitates the M-Plane to become active for the above-mentioned time for receiving wake-up signals from the O-RU controller.

[0055] In one or more embodiments, the present disclosure discloses a deep-hibernate sleep state. The deep sleep mode is used to achieve maximum energy saving by disabling all carriers and subsequently C / U / S / M Plane processing units and functions of the O-RU for a defined period of time. This implies that the O-RU is turned off with only the deep-sleep timer running.

[0056] In one embodiment, the pre-conditions for deep-hibemate sleep are as follows: i) If the M-Plane processing unit remains 'on', the user can use an existing powerstate or carrier deactivation procedure.

[0057] In an embodiment, the deep-hibernate sleep state via the M-Plane command is used to achieve maximum possible energy saving by disabling all carriers and C / U / S / M functions and corresponding processing units when compared to the power-state defined in clause 9.1.3 or advanced sleep mode defined in clause 20.4 from O-RAN-WG4-MP-V14 specification.

[0058] In one embodiment, the O-RU may expose the capability to support energy saving by disabling all carriers and C / U / S / M functions by including support of the feature DEEPSLEEP -MODE in its o-ran-wg4-features.yang YANG module.

[0059] For the implementation of the deep-hibernate sleep, the O-RU may need to advertise the “deep-sleep-mode” feature support.

[0060] Below Table 2 indicates optional O-RAN WG4 defined feature support:

[0061] The process includes the deep-sleep mode feature support to be advertised then the deep-sleep-state (also referred to as deep hibernate mode or deep hibernate sleep) should be mapped to the “DEEP-SLEEP-MODE” feature.

[0062] In particular, the process to implement deep-hibernate sleep includes: i) The O-RU controller sends the RPC <deep-sleep-mode2 or deep-sleep-mode> to the O-RU by indicating the duration in the leaf “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.

[0063] In one or more embodiments, the D.2.3 o-ran-hardware.yang module may 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 I ?+— ro availability-state? availability-type

[0064] The deep-sleep-state is a read-only state defined in o-ran-hardware.yang. This state is only exposed by the O-RUs supporting DEEP-SLEEP-MODE feature and is used by the O-RU to inform if a unit is in deep-sleep mode / state, not in the deep-sleep-state or transition between deep sleep state and non-deep sleep state. leaf deep-sleep-state { if-feature ''DEEP-SLEEP-MODE type boolean; config false; description"O-RU may use this leaf to indicate that it is in a deep-sleep state.

[0065] Further, when the O-RU controller sends deep-sleep-mode RPC to the O-RU, the O-RU controller may look for the re-call-home-no-ssh-timer value, since the O-RU controller may define the timer value in the RPC. This timer value indicates how much time the O-RU has to be in deep-sleep."; }.

[0066] If deep-sleep mode is not to be a separate feature, then the deep-sleep state could be defined in o-ran.hardware.yang model like power-state and mapped to ENERGY SAVING. The existing ENERGY SAVING feature could be reused for deep sleep.D.2.3 o-ran-hardware.yang module may correspond to: module: o-ran-hardware augment / hw : hard ware / h w : component : augment / hw:hardware / hw:component / hw:state:+— ro power-state? energysaving-state {ENERGYSAVING}?+— ro deep-sleep-state? energysaving-state {ENERGYSA VING} ?+— ro availability-state? availability-type

[0067] The deep-sleep-state may be a read-only state defined in o-ran- hard ware. yang. This state is only exposed by the O-RUs supporting ENERGYSAVING feature and is used by O-RU to inform if the unit is in energy saving state with deep-sleep mode activated, not in energy saving state or in transition between energy saving state and non-energy saving state. leaf deep-sleep-state { if-feature "ENERGYSA VING"; type energysaving-state; config false; description"O-RU may use this leaf to indicate that it is in deep-sleep-state.Note: When O-DU sends deep-sleep RPC to O-RU, it must look for the re-call-home- no-ssh-timer value, since O-DU in that RPC will define it. This timer value indicates that how much time O-RU has to be in deep-sleep.";FIG. 4 illustrates a deep- sleep- state transition diagram for the O-RU, in accordance with one or more embodiments of the present disclosure. These states may be controlled by the O-RU controller (for example, the O-DU) with RPC <deep-sleep-mode> along with editing of the parameter energy-saving-enabled. The different states illustrated in FIG. 4 may be explained as below: o AWAKE: This value of the deep-sleep-state node indicates that the O-RU is operating normally, i.e., not in energy-saving mode. AWAKE corresponds to an initial value of a power-state node after a reset of the O-RU. AWAKE is the deep sleep state of the O- RU in case energy-saving-enabled is FALSE or when at least one carrier is active. o DEEP-SLEEP / DEEP HIBERNATE SLEEP / DEEP HIBERANTE MODE: This value of deep-sleep-state node indicates that the O-RU is in energy saving mode. The O-RU may autonomously stop M-plane connection and functions and the other C / U / S functions if the O-RU receives the RPC <deep-sleep-mode> and there is a value ofenergy-saving-enabled is TRUE. This is to reduce energy consumption to the best extent possible, which depends on the O-RU design and deep-sleep-mode implementation. o UNKNOWN: This value of deep- sleep- state node can be exposed by the O-RU e.g., in case the O-RU does not know its deep-sleep-state value is .AWAKE or SLEEPING. This value of deep-sleep-state node is optional.In one embodiment, deep-sleep-state indicates the state of the O-RU.

[0068] Once the O-RU enters to the deep sleep or the deep hibernate mode, the O-RU may turn off the C / U / S P lane processing units and change the “deep-sleep-state”. Subsequently, the O-RU sends a notification to the O-RU controller indicating the corresponding deep-sleep state. This is followed by a termination of a Network Configuration Protocol (Netconf) session and the turning off ''deactivation of the M-Plane.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-hibemate-sleep / deep-sleep-mode {or-feat: DEEP-HIBERNATE- SLEEP / ENERGYSA VING} ?+ — 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-hibemate-sleep {or-feat:ENERGYSAVING or DEEP-HIBERNATE- SLEEP}?+— ro sro-id? -> / or-user:users / user / sro-id {or-feat:SHARED-ORU-MULTL OPERATOR}?Note: The above could be applicable to a shared O-RU case, if the notification needs to be sent with the sro-id to indicate which O-DU it notifies to. 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-MULT 1- OPERATOR}?+—n deep-sleep-mode {or-feat:ENERGYSA VING}?Note: In case a shared O-RU scenario is not considered, a notification could be specific to one O-DU.

[0069] In one embodiment, the O-RU may remain in deep-sleep mode for the duration defined in the leaf “re-call-home-no-ssh-timer” of the o-ran-operations.yang module or proprietary timer, after which the O-RU may initiate the 'Start-up' procedure outlined in Clause 6 of WG4-MP-vl4. The specific step from which this procedure should commence is determined by the vendor's implementation. When the O-RU receives the deep-sleep or deep- hibemate sleep RPC, the O-RU controller may look for time duration and either “re-call-home- no-ssh-timer ’ or some proprietary' timer assigned or mapped to count for the time duration for which the O-RU should be in deep-sleep mode. It is important to note that a buffer time or'wake-up' time must be considered when the O-RU wakes up from the deep-sleep mode. For instance, if the O-RU has a 30-minute 'wake-up' duration and deep-sleep is activated for 17 hours, the O-RU should start waking up from deep-sleep after 16.5 hours. This ensures that the O-RU, with its M-Plane activated and the Netconf session established, is fully operational by the end of the 17th hour. The 'wake-up' time for the O-RU is vendor-specific, and the buffer time must be factored into the O-RU's operational schedule. Therefore, this will not affect interoperability in a multi-vendor deployment scenario.

[0070] If deep-sleep is to be considered for shared O-RU, then the corresponding conditions need to be considered.

[0071] The disclosed process includes turning off M-PLANE, and then during wake-up the O-RU reset procedure (the same aspects related to MPLANE are also applicable here) may be followed. It could be with clean state or persistence for some critical configurations. Otherwise, this may be a vendor specific implementation. Since buffer time should account for the O-RU wake-up followed by the M-Plane configuration with or without the configuration being persistent.

[0072] In one embodiment, the O-DU (O-RU controller) may send the RPC command as «edit-config» to change the state of the deep-hibernate sleep to true in O-RAN hardware.yang or in operations. yang.

[0073] Moreover, the O-DU may identify the deep-hibernate sleep activation status by the following ways:* The O-DU may use an RPC command as «get-config» to retrieve the deep- hibernate sleep state of O-R U. In response, the O-DU may receive one of the following:1. TRUE (deep-sleep-enabled);2. FALSE (deep-sleep-disabled / awake): and3. Unknown (idle / busy / intermediate state).» In another embodiment, the O-RU utilizes a notification mechanism to transmit the deep-hibemate-sleep state change notification to O-DU.

[0074] The various approaches illustrated above may be similar to one or more existing mechanisms being used for synchronization state change. Such mechanisms may include, but are not limited to, RPC based enablement with notification and leaf-based enablement (e.g., O- RU sync lock - 1 . using leaf sync-state as locked (O-DU use get-config) and 2. using sync- state-change notification).

[0075] FIG. 5 illustrates a sequence of operations between the O-RU and the O-RU controller to enable deep sleep mode, in accordance with one or more additional embodiments of the present disclosure.

[0076] At step 501, the O-RU controller may transmit an RPC to the O-RU as <rpc><deep-sleep-mode-re-call-home-no-ssh-timer>< / rpc>. The RPC shall have deep- hibernate-sleep along with the time duration. The O-RU may identify the time duration whenever the O-RU receives the deep-hibemate-sleep RPC. The O-RU may then assign or map some timer depending on the design implementation of the O-RU. Once deep-hibernate sleep is activated, the timer starts running till the deep hibernate sleep ends.

[0077] At step 502, the O-RU sends a reply as <rpc-reply. ..><ok / >< / rpc-reply>.

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

[0079] At step 504, the O-RU may send a notification to the O-RU controller as <notification><O-RU in deep-sleep-mode or deep-sleep-mode activation success or activated>< / notification>.

[0080] At step 505, the O-RU controller closes and then terminates the Netconf session by sending RPC close command as (RPC <close-session> followed by or <kill-session> and <session-id> as <rpcxclose-session and / or kill-session>< / rpc>.

[0081] At step 506, the O-RU sends a reply as <rpc-reply. ..><ok / >< / rpc-reply>.

[0082] Thereafter, at step 507, the O-RU deactivates or turns off the M-Plane processing units and the function and leaves only the deep-sleep timer running. In response, the O-RU comes in deep sleep mode.

[0083] At step 508, the O-RU detects that the timer has ended and follows the start-up procedure starting from call home and so on (Refer to Clause 6 from O-RAN-WG4-MP-v14 spec).

[0084] Next, at step 509, the Netconf session starts followed by carriers and other configurations, and then O-RU becomes fully operational (Refer to Clause 6 from O-RAN- WG4-MP-vl4 spec). Further, at step 510, the O-RU may send an energy consumption report (energy / power consumed during deep sleep ) upon wake up of the O-RU, to the O-RU controller.

[0085] FIG. 6 illustrates a sequence of operations between an O-RU 610 (or a RU 610) and an O-RU controller 620 (or an RU controller 620) to activate a deep hibernate mode, in accordance with 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. Moreover, the O-RU controller 620 may also be referred to as the O-DU wi thout departing the scope of the present di sclosure.

[0086] .At step 601, the O-RU controller 620 may transmit an RPC to the O-RU 610 to activate the deep hibernate mode at the O-RU 610. The O-RLTcontroller 620 may transmit the RPC to activate the deep hibernate made and disable a plurality of functions associated with the O-RU 610. The O-RU controller 620 may also define a hibernate time in the transmittedRPC. The hibernate time may correspond to a duration for which the O-RU controller 620 wants the O-RU 610 to remain in deep hibernate mode. The transmitted RPC may be defined as:<rpc><deep-hibernate><hibemate-time> x minutes < / hibemate-time>< / deep-hibemate>< / rpc>

[0087] In one embodiment, prior to transmitting the RPC to activate the deep hibernate mode at the O-RU 610, the O-RU controller 620 may receive an indication from the O-RU 610. The indication may indicate that the O-RU 610 supports a deep hibernate feature associated with the deep hibernate mode and / or the deep hibernate state. In particular, the O-RU 610 may expose its ability to support deep hibernate functionality by including support of the feature DEEP-HIBERNATE in its o-ran-wg4-features.yang YANG module. The support of this feature means an O-RU shall advertise the data node max-hibernate -time-duration and optionally advertise data node min-hibemate-time-duration.

[0088] The O-RU 610 may advertise the indication upon establishing a successful connection with the O-RU controller 620. The O-RU 610 may also advertise and / or transmit a minimum and / or maximum time duration for which the O-RU 610 can activate the deep hibernate mode. The O-RU 610 may determine the minimum time duration based on an initialization and / or reset time of the O-RU 610. The O-RU 610 may determine the maximum time duration based on standby capabilities of the O-RU 610. The O-RU controller 620 may determine the hibemate-time based on the received minimum and / or maximum time durations from the O-RU 610. In one embodiment, the O-RU 610 may expose its ability to support thedeep hibernate functionality by including support of the feature DEEP- HIBERNATE in its o- ran-wg4-features.yang YANG module. The support of this feature means that the O-RU 610 may advertise each of the connected data node a max-hibernate-time-duration and optionally advertise the data nodes a min-hibernate-time-duration.

[0089] In one embodiment, before the O-RU controller 620 sends the RPC for the deep- hibernate mode, the O-RU controller 620 may ensure that all [tr]x-array-carrier(s) shall be deactivated as defined in Figure 15.3.2-0b. If the O-RU 610 receives the RPC for the deep- hibernate mode while one or more [tr]x-array-carriers are active, then the O-RU 610 may reject the RPC. In such a case, the O-RU 610 may also transmit an error-message to the O-RU controller 620, indicating a reason the deep-hibernation cannot be activated.

[0090] At step 602, the O-RU 610 transmits an RPC reply to the O-RU controller 620. The RPC reply may be defined as <rpc-reply ...><ok / >< / rpc-reply>. The RPC reply from the O-RU 610 may indicate that the O-RU 610 has successfully received and / or acknowledged the RPC for activation of the deep hibernate mode from the O-RU controller 620. The RPC reply may also indicate that the O-RU 610 is now ready to move to the deep-hibernate mode.

[0091] In one embodiment, when the O-RU 610 accepts the RPC for the deep-hibernate mode, the O-RU 610 may notify each of the subscribed O-RU controllers that the O-RU 610 has accepted the RPC for the deep-hibernate mode. This may prevent other O-RU controllers to transmit and / or wait for any communication to and from the O-RU 610. In some embodiments, the O-RU 610 may notify the hibernate-time to each of the subscribed O-RU controllers about the hibernate time in the notification transmitted to indicate the deep- hibemate mode at the O-RU 610.

[0092] At step 603, the O-RU 610 may stop C / U / S-Plane functions in response to the received RPC to activate the deep hibernate mode from the O-RU controller 620. In anembodiment, the O-RU 610 may stop the C / U / S-Plane functions after transmitting the RPC reply to the O-RU controller 620.

[0093] Next, at step 604, the O-RU 610 transmits a notification to the O-RU controller 620. The notification may indicate that the O-RU 610 has activated deep-hibernate mode. Alternatively, the notification may indicate that the C / U / S-Plane functions are stopped at the O-RU 610. The notification as transmitted by the O-RU 610 may as follow:<notification> deep-hibemate-activated.< / 'notification>

[0094] At step 605, the O-RU 610 initiates a deep-hibemate timer. In one embodiment, the O-RU 610 may initialize the deep-hibernate timer based on the hibernate-time as indicated in the RPC received from the O-RU controller 620 at step 601.

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

[0096] In one embodiment, the O-RU controller 620 may instruct the O-RU 610 to close all the active / established NETCONF session between the O-RU 610 and the O-RU controller 620 via the RPC command at step 606. The O-RU controller 620 may also instruct the O-RU 610 to disable the M-Plane processing unit and functions via the RPC command of step 606. In an embodiment, the O-RU 610 may disable / suspend all NECTONF call home operationsand / or Physical Network Function (PNF) registration operations after deep-hibernate mode is activated and / or upon receipt of the RPC command to close session.

[0097] At step 607, the O-RU 610 may disable the M-processing units and functions. Also, the O-RU 610 may disconnect and / or release all the NETCONF sessions between the O- RU 610 and the O-RU controller 620.

[0098] At step 608, the O-RU 610 may enter the deep hibernate mode. Therefore, upon disabling each of the C-Plane, the U-Plane, the S-Plane functions / processing units, and the M- Plane processing units and functions, the O-RU 610 may enter the deep-hibernate mode and achieve maximum energy saving.

[0099] At step 609, upon determining that the hibernate time has reached, or the deep- hibernate timer has expired, the O-RU 610 may re-start. In particular, after the expiry of the deep-hibernate timer, the O-RU 610 may re-initialize each of the ( / -Plane, the U-Plane, the S- Plane functions, and the M-Plane processing units and functions. The O-RU 610 may also initialize and / or re-establishes NETCONF sessions between the O-RU 610 and the O-RU controller 620.

[0100] In one embodiment, at an end of the hibernate-time, the O-RU 610 may perform a re-start and follow the procedures defined in Figure 6.1 -1. Upon restart, the O-RU 610 may set the restart-cause to DEEP-HIBERNATE-RESTzART using o-ran-operations.yang YANG module. In the case of autonomous restart of the O-RU 610 while in the deep-hibernate mode, e.g., because of some software failure, the O-RU 610 may not expect to continue the deep- hibernate mode.

[0101] Therefore, the deep-hibernate mode and / or the deep-hibernate state is an O-RU mode used to achieve relatively higher energy sa ving by disabling all carriers and stopping the C / U / S / M functions and corresponding processing units when compared to power-state definedin clause 9.1.3 or advanced sleep mode defined in clause 20.4 from O-RAN-WG4-MP-v14 spec.

[0102] In the case the O-RU 610 is operating as a shared O-RU as described in clause 19 from O-RAN-WG4-MP-V14 specification, an O-DU or the O-RU controller operating with "carrier" privileges as defined in Table 6.5-1 shall be prohibited from sending the RPC for the deep-hibemate mode.

[0103] FIG. 7 illustrates a flow chart of an example method 700, in accordance with another embodiment of the present disclosure. The method 700 may be performed by the a RU (for example, O-RU 610) which may also be referred to as the apparatus 610.

[0104] At step 702, the RU 610 may receive a deep hibernate command to disable a plurality of functions associated with the RU 610 from the RU controller 620.. The deep hibernate command comprises a predefined time duration for a deep hibernate timer. In one embodiment, the RU 610 may transmit a message indicating that the RU 610 supports a deep hibernate feature associated with the deep hibernate mode to the RU controller 620. The message may also indicate a deep-hibemate time duration as supported by the RU 610. The deep-hibernate time duration may indicate a minimum or a maximum time duration supported by the RU 610 for the deep-hibemate mode.

[0105] In one embodiment, for transmitting the deep-hibemate command, the RU controller 620 may receive the message indicating that the RU 610 supports the deep hibernate feature associated with the deep hibernate mode from the RU 610. The RU controller 620 may also monitor one or more parameters associated with the RU 610 over a period of time. The one or more parameters may include, but are not limited to, transmission and / or reception characteristics of the RU 610. Thereafter, the RU controller 620 mav determine to activate the deep hibernate mode at the RU 610 based on the one or more monitored parameters and thereceived message from the RU 610. For instance, upon determining that the RU 610 remains idle for a specific duration every day and the RU 610 supports the deep-hibemate mode, the RU controller 620 may decide to activate the deep-hibemate mode at the RU 610 for such a time duration. Therefore, upon determining to activate the deep hibernate mode at the RU 610, the RU controller 620 may transmit the deep hibernate command to the RU 610 to disable the C -Plane, the U-Plane, the S-Plane functions and / or the M-Plane associated with the RU 610 for the predefined time duration. In one embodiment, in response to the receiving deep hibernate command, the RU 610 may transmit a Remote Procedure Call (RPC) to the RU controller 620. The RPC may indicate acceptance of the deep-hibernate command by the RU 610.

[0106] Further, upon disabling the C-Plane, the U-Plane, and the S-Plane functions, the RU 610 may transmit a notification to the RU controller 620. The notification may indicate deep hibernate activation at the RU 610. Moreover, the RU 610 may initialize a deep hibernate timer based on the predefined time duration. In one embodiment, the notification may be transmitted via the M-Plane associated with the RU 610. The RU controller 620 may receive the notification and in response to said notification, the RU controller 620 may transmit a closesession command to the RU 610. The RU controller 620 may transmit the close-session command to suspend the established / active session (for example, NETCONF session) between the RU 610 and the RU controller 620. In one embodiment, the established / active session corresponds to a management session.

[0107] .At step 704, the RU 610 may disable the C-Plane, the U-Plane, and the S-Plane functions associated with the RU 610 and initiate the deep hibernate timer. The RU 610 may disable the C-Plane, the U-Plane, and the S-Plane functions in response to the received deep- hibernate command. In one embodiment, prior to disabling C-Plane, the U-Plane, and the S-Plane functions, the RU 610 may deactivate each of the plurality of carriers between the RU 610 and the RU-controller 620. Further, the method 700 may include determining by the RU controller 620 that each of the plurality of the carriers from the RU-controller 620 to RU 620 is deactivated. Moreover, upon determining that each of the plurality of the carriers from the RU-controller 620 to the RU 620 is deactivated, the RU-controller transmits the deep hibernate command.

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

[0109] At step 708, the RU 610 may disable the M-Plane associated with the RU 610 for the predefined time duration and enter the deep hibernate mode, in response to the received close-session command. Particularly, after the management session is closed, the RU 610 may disable the M-plane associated with the RU 610 for the predefined time duration and enter the deep hibernate mode.

[0110] The RU 610 may further determine whether the deep hibernate timer has lapsed or not. In one embodiment, upon determining that the deep hibernate timer has lapsed, the RU 610 may restart the C-Plane, the U-Plane, the S-Plane functions, and / or the M-Plane. Further, the RU 610 may re-initialize a session between the RU 610 and the RU controller 620.

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

[0112] Embodiments are exemplary7in nature and the sequence of the method 700 may vary with respect to omission or change in sequence of one or more steps.

[0113] FIG. 8 illustrates an embodiment of a device / apparatus 800. As shown in FIG. 8, the device 800 includes processor 810, a memory 820, a storage component 830, an inputcomponent 840, an output component 850, a communication interface 860, and a bus 870. The device 800 may be associated with the O-RU 610 or the O-RU controller 620.

[0114] The processor 810, as used herein, means any type of computational circuit that may comprise hardware elements and software elements. The 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 / or one or more single core processors, a distributed processing system, or the like. The 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.

[0115] The memory 820 includes a non-transitory computer readable medium. Memory 820 includes a random-access memory7(R.AM), a read only7memory (ROM), and / or another type of dynamic or static storage device (e.g., a flash memory7, a magnetic memory, and / or an optical memory) that stores information and / or instructions for use by processor 810. The memory7820 comprises machine-readable instructions which are executable by the processor 810. These machine-readable instructions when executed by the processor 810 cause the processor 810 to perform one or more method steps of an embodiment described above.

[0116] The storage component 830 stores information and / or software related to the operation and use of the device 800. For example, storage component 830 may7include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, and / or a solid-state disk), a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a cartridge, a magnetic tape, and / or another type of non-transitory7computer-readable medium, along with a corresponding drive.

[0117] The input component 840 is configured to receive information, such as user input. For example, the input component 840 may include, but not be limited to, a touch screendisplay, a keyboard, a keypad, a mouse, a button, a switch, and / or a microphone. .Additionally, or alternatively, the input component 840 may include a sensor for sensing information (e.g., a global positioning system (GPS), an accelerometer, a gyroscope, and / or an actuator).

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

[0119] The communication interface 860 is an interface that provides a communication connection to other devices, such as external devices and internal devices. The connection by the 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 that exists between the device 800 and other devices. In other words, the standard of the communication interface 860 is not limited.

[0120] The bus 870 acts as an interconnect between the processor 810, the memory 820, the storage component 830, the input component 840, the output component 850, and the communication interface 860 of the device 800. The bus 870 may include a wired interconnection or a wireless interconnection.

[0121] The number and arrangement of components shown in FIG. 8 are provided as an example. In practice, device 800 may include additional components, fewer components, different components, or differently arranged components than those shown in FIG. 8. Additionally, or alternatively, a set of components (e.g., one or more components) of the device 800 may perform one or more functions described as being performed by another set of components of the device 800. Further, one or more method steps described in any of theembodiments may be performed utilizing a plurality of devices 800 in communication with one another.

[0122] According to one aspect, a method is disclosed. The method includes receiving, by a Radio Unit (RU) a deep hibernate command to disable a plurality of functions associated with the RU from a RU -controller. The deep hibernate command comprises a predefined time duration for a deep hibernate timer. The method also includes disabling, by the RU, a Control Plane (C-Plane) function, a User Plane (U-Plane) function, and a Synchronization Plane (S- Plane) function associated with the RU in response to the received deep hibernate command. The method further includes initiating the deep hibernate timer in response to the received deep hibernate command. The method further includes receiving, by the RU, a close-session command to suspend an established / active session between the RU and the RU controller, from the RU controller. In response to the received close-session command, the method includes disabling, by the RU, a Management Plane (M-Plane) associated with the RU and entering the deep hibernate mode.

[0123] The method described in paragraph

[0122] , further includes transmitting, by the RU, a message indicating support of a deep hibernate feature with the deep hibernate mode by the RU, to the RU controller prior to receiving the deep hibernate command.

[0124] The method described in any one of paragraphs

[0122] -

[0123] , further includes disabling, by the RU, the established / active session between the RU and the RU controller based on the close-session command prior to disabling the M-Plane associated with the RU.

[0125] The method described in any one of paragraphs

[0122] -

[0124] , further includes deactivating, by the RU, each of the plurality of carriers between the RU and the RU-controller prior to disabling the C-Plane, the U-Plane, and the S-Plane functions.

[0126] The method described in any one of paragraphs

[0122] -

[0125] , further includes determining by the O-RU controller that each of the plurality of the carriers from the RU- controller to RU is deactivated. Moreover, upon determining that each of the plurality of the carriers from the RU-controller to RU is deactivated, the method includes transmitting, by the RU controller, the deep hibernate command.

[0127] The method described in any one of paragraphs

[0122] -

[0126] , further includes transmitting, by the RU, a Remote Procedure Call (RPC) message indicating an acceptance of the deep hibernate command, to the RU controller in in response to the received deep hibernate command. The RPC message may be transmitted prior to disabling the C-Plane, the U-Plane, and the S-Plane functions. Further, the method includes transmitting, by the RU, a notification indicating deep hibernate activation at the RU, to the RU controller upon disabling the C-Plane, the U-Plane, and the S-Plane functions.

[0128] The method described in any one of paragraphs

[0122] -

[0127] , further includes determining, by the RU, whether the deep hibernate timer has lapsed. The method also includes upon determining that the deep hibernate timer has lapsed, perform restarting, by the RU, at least one of the C-Plane, the U-Plane, the S-Plane functions, and the M-Plane. The method further includes re-initializing, by the RU, a session between the RU and the RU controller.

[0129] The method described in any one of paragraphs

[0122] -

[0128] , further includes receiving, by the RU controller, the message indicating that the RU supports the deep hibernate feature associated with the deep hibernate mode, from the RU. The method also includes monitoring, by the RU controller, one or more parameters associated with the RU, over a period of time. The method further includes determining, by the RU controller, to activate the deep hibernate mode at the RU based on the one or more monitored parameters and the received message from the RU. Moreover, upon determining to activate the deep hibernate mode at theRU, the method includes transmitting, by the RU controller, the deep hibernate command to the RU to disable the C-Plane, the U-Plane, and the S-Plane functions associated with the RU for the predefined time duration.

[0130] The method described in any one of paragraph s

[0122] -

[0129] , further comprises transmitting, by the RU, the notification via the M-Plane associated with the RU, to the RU controller.

[0131] The method described in any one of paragraphs

[0122] -

[0130] , further includes receiving, by the RU controller, the notification indicating the deep hibernate activation at the RU, from the RU. Further, in response to receiving the notification, the method includes transmitting, by the RU controller, the close-session command to suspend the established / active session between the RU and the RU controller, to the RU.

[0132] According to another aspect, an apparatus associated with a Radio Unit (RU) is disclosed. The apparatus is configured to receive a deep hibernate command to disable a plurality of functions associated with the RU from a RU-controller. The deep hibernate command comprises a predefined time duration for a deep hibernate timer. The apparatus is also configured to disable a Control Plane (C-Plane) function, a User Plane (U-Plane) function, and a Synchronization Plane (S-Plane) function associated with the RU and initiate the deep hibernate timer. The apparatus disables the C-Plane, the U-Plane, and the S-Plane functions in response to the received deep hibernate command. The apparatus is further configured to receive a close-session command to suspend 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 a 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 hibernate mode.

[0133] The apparatus as described in paragraph

[0132] , wherein prior to receiving the deep hibernate command, the apparatus is configured to transmit a message indicating support of a deep hibernate feature with the deep hibernate mode by the RU, to the RU controller.

[0134] The apparatus as described in any one of paragraphs

[0132] -

[0133] , wherein prior to disabling the M-Plane associated with the RU, the apparatus is configured to disable the established / active session between the RU and the RU controller based on the close-session command.

[0135] The apparatus as described in any one of paragraphs

[0132] -

[0134] , wherein prior to disabling the C-Plane, the U-Plane, and the S-Plane functions, the apparatus is configured to deactivate each of the plurality of carriers between the RU and the RU-controller.

[0136] The apparatus as described in any one of paragraphs

[0132] -

[0135] , is further configured to transmit a Remote Procedure Call (RPC) message indicating an acceptance of the deep hibernate command, to the RU controller in response to the received deep hibernate command. The RPC message is transmitted prior to disabling the C-Plane, the U-Plane, and the S-Plane functions. Further, the apparatus is configured to transmit a notification indicating deep hibernate activation at the RU, to the RU controller upon disabling the C-Plane, the U- Plane, and the S-Plane functions.

[0137] The apparatus as described in any one of paragraphs

[0132] -

[0135] , further configured to determine whether the deep hibernate timer has lapsed. Upon determining that the deep hibernate timer has lapsed, the apparatus is configured to perform at least one of restart at least one of the C-Plane, the U-Plane, the S-Plane functions, and the M-Plane, and reinitialize a session between the RU and the RU controller.

[0138] According to another aspect, a non-transitory computer-readable medium storing instructions is disclosed. The instructions include one or more instructions that are executed bya Radio Unit (O-R.U) comprising one or more processors. The instructions cause the one or more processors to receive a deep hibernate command to disable a plurality of functions associated with the RU from a RU-controller. The deep hibernate command comprises a predefined time duration for a deep hibernate timer. The instructions cause the one or more processors to disable a Control Plane (C-Plane) function, a User Plane (U-Plane) function, and a Synchronization Plane (S-Plane) function associated with the RU and initiate the deep hibernate timer. The instructions cause the one or more processors to disable the C-Plane, the U-Plane, and the S-Plane functions in response to the received deep hibernate command. The instructions cause the one or more processors to receive a close-session command to suspend 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 disable a Management Plane (M-Plane) associated with the RU. The M-Plane is disabled in response to the received close-session command. The instructions cause the one or more processors to enter the deep hibernate mode.

[0139] Therefore, the deep-hibernate corresponds to a RU (O-RU) mode that may be used to achieve relatively higher energy saving by disabling all carriers and stopping the C / U7S / M functions and corresponding processing units when compared to power-state defined in clause 9.1.3 or advanced sleep mode defined in clause 20.4 from O-RAN-WG4-MP-V14 specification.

Claims

WE CLAIM:

1. A method (700) comprising: receiving (702), by a Radio Unit (RU) a deep hibernate command to disable a plurality of functions associated with the RU from a RU -controller, wherein the deep hibernate command comprises a predefined time duration for a deep hibernate timer; in response to the received deep hibernate command, disabling (704), by the RU, a Control Plane (C-Plane) function, a User Plane (U-Plane) function, and a Synchronization Plane (S-Plane) function associated with the RU and initiating the deep hibernate timer; receiving (706), by the RU, a close-session command to suspend an established / active session between the RU and the RU controller, from the RU controller; and in response to the received close-session command, disabling (708), by the RU, a Management Plane (M-Plane) associated with the RU and entering the deep hibernate mode.

2. The method (700) as claimed in claim 1, wherein prior to receiving the deep hibernate command, the method comprises: transmitting, by the RU, a message indicating support of a deep hibernate feature with the deep hibernate mode by the RU, to the RU controller.

3. The method (700) as claimed in claim 1, wherein prior to disabling the M-Plane associated with the RU, the method comprises:disabling, by the RU, the established / active session between the RU and the RU controller based on the close-session command.

4. The method (700) as claimed in claim 1, wherein prior to disabling the C-Plane, the U- Plane, and the S-Plane functions, the method comprises: deactivating, by the RU, each of the plurality of carriers between the RU and the RU-controller.

5. The method (700) as claimed in claim 1, wherein receiving, by the RU a deep hibernate command to disable a plurality of functions associated with the RU, comprises: determining by the RU controller that each of the plurality of the carriers from the RU-controller to the RU is deactivated; upon determining that each of the plurality of the carriers from the RU- controller to RU is deactivated, transmitting, by the RU controller, the deep hibernate command.

6. The method (700) as claimed in claim 1, comprising: in response to the received deep hibernate command and prior to disabling the C-Plane, the U-Plane, and the S-Plane functions, transmiting, by the RU, a Remote Procedure Call (RPC) message indicating an acceptance of the deep hibernate command, to the RU controller; and upon disabling the C-Plane, the U-Plane, and the S-Plane functions, transmitting by the RU, a notification indicating deep hibernate activation at the RU, to the RU controller.

7. The method (700) as claimed in claim 1, comprising: determining, by the RU, whether the deep hibernate timer has lapsed; upon determining that the deep hibernate timer has lapsed, perform at least one of: restarting, by the RU, at least one of the C- Plane, the U-Plane, the S-Plane functions, and the M-Plane; and re-initializing, by the RU, a session between the RU and the RU controller.

8. The method (700) as claimed in claim 1, wherein receiving, from the RU controller, the deep hibernate command comprises: receiving, by the RU controller, the message indicating that the RU supports the deep hibernate feature associated with the deep hibernate mode, from the RU; monitoring, by the RU controller, one or more parameters associated with the RU, over a period of time; determining, by the RU controller, to activate the deep hibernate mode at the RU based on the one or more monitored parameters and the received message from the RU; and upon determining to activate the deep hibernate mode at the RU, transmitting, by the RU controller, the deep hibernate command to the RU to disable the C-Plane, the U-Plane, and the S-Plane functions associated with the RU for the predefined time duration.

9. The method (700) as claimed in claim 6, wherein transmiting, by the RU, the notification indicating the deep hibernate activation at the RU comprises: transmitting, by the RU, the notification via the M-Plane associated with the RU, to the RU controller.

10. The method (700) as claimed in claim 6, wherein receiving, from the RU controller, the close-session command comprises: receiving, by the RU controller, the notification indicating the deep hibernate activation at the RU, from the RU; and in response to receiving the notification, transmitting, by the RU controller, the closesession command to suspend the established / active session between the RU and the RU controller, to the RU.

11. An apparatus associated with a Radio Unit (RU) (610), configured to: receive a deep hibernate command to disable a plurality of functions associated with the RU (610) from a RU-controller (620), wherein the deep hibernate command comprises a predefined time duration for a deep hibernate timer; in response to the received deep hibernate command, disable a Control Plane (C-Plane) function, a User Plane (U-Plane) function, and a Synchronization Plane (S- Plane) function associated with the RU (610) and initiate the deep hibernate timer; receive a close-session command to suspend an established / active session between the RU (610) and the RU controller (620), from the RU controller (620); and in response to the received close-session command, disable a ManagementPlane (M -Plane) associated with the RU (610) and enter the deep hibernate mode.

12. The apparatus as claimed in claim 11, wherein prior to receiving the deep hibernate command, the apparatus is configured to: transmit a message indicating support of a deep hibernate feature with the deep hibernate mode by the RU (610), to the RU controller (620).

13. The apparatus as claimed in claim 11 , wherein prior to disabling the M-Plane associated with the RU, the apparatus is configured to: disable the established / active session between the RU (610) and the RU controller (620) based on the close-session command.

14. The apparatus as claimed in claim 11, wherein prior to disabling the C-Plane, the U- Plane, and the S-Plane functions, the apparatus is configured to: deactivate each of the plurality of carriers between the RU (610) and the RU- controller (620).

15. The apparatus as claimed in claim 11, further configured to: in response to the received deep hibernate command and prior to disabling the C-Plane, the U-Plane, and the S-Plane functions, transmit a Remote Procedure Call (RPC) message indicating an acceptance of the deep hibernate command, to the RU controller (620); and upon disabling the C-Plane, the U-Plane, and the S-Plane functions, transmit a notification indicating deep hibernate activation at the RU (610), to the RU controller(620).

16. The apparatus as claimed in claim 11 , further configured to: determine whether the deep hibernate timer has lapsed; upon determining that the deep hibernate timer has lapsed, perform at least one of: restart at least one of the C-Plane, the U-Plane, the S-Plane functions, and the M-Plane; and re-initialize a 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 that, when executed by a Radio Unit (O-RU) (610) comprising one or more processors, cause the one or more processors to: receive a deep hibernate command to disable a plurality of functions associated with the RU (610) from a RU -controller (620), wherein the deep hibernate command comprises a predefined time duration for a deep hibernate timer: in response to the received deep hibernate command, disable a Control Plane (C-Plane) function, a User Plane (U-Plane) function, and a Synchronization Plane (S- Plane) function associated with the RU (610) and initiate the deep hibernate timer; receive a close-session command to suspend an established / active session between the RU (610) and the RU controller (620), from the RU controller (620); and in response to the received close-session command, disable a Management Plane (M-Plane) associated with the RU (610) and enter the deep hibernate mode.

Images