Systems and methods for managing remote radio unit power sources

Abstract

Presented are systems and methods for managing power sources for radio unit (s). A power source controller can monitor a plurality of power sources configured to provide power to a radio unit of a wireless communication node. The power source controller can send information based on the monitoring to a remote radio unit controller. The remote radio unit controller can receive information based on the monitoring from the power source controller.

Description

SYSTEMS AND METHODS FOR MANAGING REMOTE RADIO UNIT POWER SOURCESTECHNICAL FIELD

[0001] The disclosure relates generally to wireless communications, including but not limited to systems and methods for managing remote radio unit power sources.BACKGROUND

[0002] Coverage is a key consideration in cellular network deployments. With the rise of interconnected devices, there is a growing focus on effective device communication. The current 3GPP standards, spanning from 3G to 5G and beyond, focus on the importance of seamless communication among various devices, from smart home devices to wearable devices. In industrial settings, the complexity of tasks often requires collaboration. This calls for several cooperative operational management systems, with the aim of creating workgroups and managing different types of devices to complete the required tasks.SUMMARY

[0003] The example embodiments disclosed herein are directed to solving the issues relating to one or multiple of the problems presented in the prior art, as well as providing additional features that will become readily apparent by reference to the following detailed description when taken in conjunction with the accompany drawings. In accordance with various embodiments, example systems, methods, devices and computer program products are disclosed herein. It is understood, however, that these embodiments are presented by way of example and are not limiting, and it will be apparent to those of ordinary skill in the art who read the present disclosure that various modifications to the disclosed embodiments can be made while remaining within the scope of this disclosure.

[0004] At least one aspect is directed to a system, method, apparatus, or computer-readable medium. A power source controller (e.g., RRU power source controller) can monitor a plurality of power sources configured to provide power to a radio unit (e.g., remote radio unit) of a wireless communication node. The power source controller can send / transmit / provide  information that is based on the monitoring to a remote radio unit (RRU) controller. In certain implementations, the power source controller can monitor at least one of the following information of the plurality of power sources: real-time status, real-time condition, or power usage. In certain implementations, the power source controller can identify the plurality of power sources. In certain implementations, the power source controller can determine, according to the information, to use or switch to one or more of the plurality of power sources to supply power to the wireless communication node.

[0005] In certain implementations, the power source controller can receive / obtain / acquire, according to a message from a remote radio unit (RRU) controller or the wireless communication node, an indication to at least one of: activate or deactivate usage of one of the plurality of power sources, or switch to a different subset of the plurality of power sources. In certain implementations, the power source controller can determine a power-related status of at least one of:the radio unit (e.g., RRU) or the RRU controller. In certain implementations, the power source controller can identify an association between the performance of a first task and the power-related status. In certain implementations, the power source controller can determine, according to the association or the power-related status, whether the radio unit or the RRU controller (e.g., BBU) or both are to perform the task.

[0006] In certain implementations, the power source controller can send / transmit / provide a trigger to the radio unit (e.g., RRU) to perform at least one of: self-calibration or monitoring of transmit power. In certain implementations, the power source controller can receive / obtain / acquire a status of one of the plurality of power sources. In certain implementations, the power source controller can send a report, according to (e.g., based on or comprising) the status, to the RRU controller. In certain implementations, the power source controller can initiate authentication of a power source when the power source becomes available to provide power to the radio unit. In certain implementations, the power source controller can assign an internet protocol (IP) address to the power source to support one or more communication or reporting functions. In certain implementations, the power source controller can enable / allow discovery by the power source. In certain implementations, the power source controller can discover the power source. In certain implementations, the RRU controller can  determine an energy indicator according to the information and can send / transmit / provide a report, according to the energy indicator, to a function of a core network (e.g., AMF / OAM) .

[0007] In certain implementations, the power source controller can send / transmit / provide an indication of a capability of the power source controller to at least one of: the radio unit or the RRU controller. The capability may include at least one of the following: monitoring one or more of the power sources, switching to one or more of the power sources, a maximum operating power, a maximum transmit power, calculating or determining the power source controller’s power consumption, calculating or determining the power source controller’s carbon footprint, support for mixed power input from multiple power sources, ability to store energy, minimum power to maintain operation, ability to compensate for unstable power sources, or ability to stabilize for power shortage. In certain implementations, the power source controller can send / transmit / provide an indication of a change in power usage to the radio unit. The radio unit can send a report, according to the indication, to the RRU controller. In certain implementations, the RRU controller can send a request to the radio unit to provide a report or update of the radio unit’s capabilities.

[0008] In certain implementations, the power source controller can combine power provided by at least two of the power sources into a combined power output. In certain implementations, the power source controller can combine the power provided by at least two of the power sources according to at least one of: a communication from the RRC controller or a power demand of the radio unit. In certain implementations, the power source controller can provide the combined power output to the radio unit. In certain implementations, each of the power sources can be associated with at least one tag or indication of at least one of the following: a sustainability level or carbon footprint, reliability, failure probability, recovery time from failure, stability of output voltage, stability of electric current, whether power storage is supported, capacity of the power storage, a maximum output power, or a maximum electric current. In certain implementations, the power source controller can maintain or request a state of a first power source of the plurality of power sources. In certain implementations, the state may include at least one of the following: active, ready, trusted, untrusted, unknown, partly active, or partly ready.

[0009] In certain implementations, a remote radio unit (RRU) controller can receive / obtain / acquire information from a power source controller. The information can be based on monitoring a plurality of power sources configured to provide power to a radio unit (e.g., RRU) of a wireless communication node.

[0010] The system of the technical solutions disclosed herein can address the demand for energy efficiency among network operators and / or the desire to configure the network to consume power from sustainable sources. The system of the technical solutions can support the identification and / or reporting of each network component’s current power source. The system of the technical solutions can achieve this through at least one of the following example configurations (e.g., features or solutions) :

[0011] ● Example configuration 1: Configuring a remote radio unit to be able to identify and / or report its own power status.

[0012] ● Example configuration 2: Providing intelligent control and scheduling of data communication and other services.BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Various example embodiments of the present solution are described in detail below with reference to the following figures or drawings. The drawings are provided for purposes of illustration only and merely depict example embodiments of the present solution to facilitate the reader’s understanding of the present solution. Therefore, the drawings should not be considered limiting of the breadth, scope, or applicability of the present solution. It should be noted that for clarity and ease of illustration, these drawings are not necessarily drawn to scale.

[0014] FIG. 1 illustrates an example cellular communication network in which techniques disclosed herein may be implemented, in accordance with an embodiment of the present disclosure;

[0015] FIG. 2 illustrates a block diagram of an example base station and a user equipment device, in accordance with some embodiments of the present disclosure;

[0016] FIG. 3 illustrates an example system configuration with a remote radio unit power source controller, in accordance with some embodiments of the present disclosure;

[0017] FIG. 4 illustrates another example system configuration with a remote radio unit power source controller, in accordance with some embodiments of the present disclosure;

[0018] FIG. 5 illustrates another example system configuration with a remote radio unit power source controller, in accordance with some embodiments of the present disclosure;

[0019] FIG. 6 illustrates an example configuration / arrangement of signaling exchange, in accordance with some embodiments of the present disclosure;

[0020] FIG. 7 illustrates another example configuration / arrangement of signaling exchange, in accordance with some embodiments of the present disclosure; and

[0021] FIG. 8 illustrates a flow diagram of an example method for managing power sources of remote radio unit (s) , in accordance with an embodiment of the present disclosure.DETAILED DESCRIPTION

[0022] 1. Mobile Communication Technology and Environment

[0023] FIG. 1 illustrates an example wireless communication network, and / or system, 100 in which techniques disclosed herein may be implemented, in accordance with an embodiment of the present disclosure. In the following discussion, the wireless communication network 100 may be any wireless network, such as a cellular network or a narrowband Internet of things (NB-IoT) network, and is herein referred to as “network 100. ” Such an example network 100 includes a base station 102 (hereinafter “BS 102” ; also referred to as wireless communication node) and a user equipment device 104 (hereinafter “UE 104” ; also referred to as wireless communication device) that can communicate with each other via a communication link 110 (e.g., a wireless communication channel) , and a cluster of cells 126, 130, 132, 134, 136, 138 and 140 overlaying a geographical area 101. In Figure 1, the BS 102 and UE 104 are contained within a respective geographic boundary of cell 126. Each of the other cells 130, 132, 134, 136, 138 and 140 may include at least one base station operating at its allocated bandwidth to provide adequate radio coverage to its intended users.

[0024] For example, the BS 102 may operate at an allocated channel transmission bandwidth to provide adequate coverage to the UE 104. The BS 102 and the UE 104 may communicate via a downlink radio frame 118, and an uplink radio frame 124 respectively. Each radio frame 118 / 124 may be further divided into sub-frames 120 / 127 which may include data symbols 122 / 128. In the present disclosure, the BS 102 and UE 104 are described herein as non-limiting examples of “communication nodes, ” generally, which can practice the methods disclosed herein. Such communication nodes may be capable of wireless and / or wired communications, in accordance with various embodiments of the present solution.

[0025] FIG. 2 illustrates a block diagram of an example wireless communication system 200 for transmitting and receiving wireless communication signals (e.g., OFDM / OFDMA signals) in accordance with some embodiments of the present solution. The system 200 may include components and elements configured to support known or conventional operating features that need not be described in detail herein. In one illustrative embodiment, system 200 can be used to communicate (e.g., transmit and receive) data symbols in a wireless communication environment such as the wireless communication environment 100 of Figure 1, as described above.

[0026] System 200 generally includes a base station 202 (hereinafter “BS 202” ) and a user equipment device 204 (hereinafter “UE 204” ) . The BS 202 includes a BS (base station) transceiver module 210, a BS antenna 212, a BS processor module 214, a BS memory module 216, and a network communication module 218, each module being coupled and interconnected with one another as necessary via a data communication bus 220. The UE 204 includes a UE (user equipment) transceiver module 230, a UE antenna 232, a UE memory module 234, and a UE processor module 236, each module being coupled and interconnected with one another as necessary via a data communication bus 240. The BS 202 communicates with the UE 204 via a communication channel 250, which can be any wireless channel or other medium suitable for transmission of data as described herein.

[0027] As would be understood by persons of ordinary skill in the art, system 200 may further include any number of modules other than the modules shown in Figure 2. Those skilled in the art will understand that the various illustrative blocks, modules, circuits, and processing logic described in connection with the embodiments disclosed herein may be implemented in  hardware, computer-readable software, firmware, or any practical combination thereof. To clearly illustrate this interchangeability and compatibility of hardware, firmware, and software, various illustrative components, blocks, modules, circuits, and steps are described generally in terms of their functionality. Whether such functionality is implemented as hardware, firmware, or software can depend upon the particular application and design constraints imposed on the overall system. Those familiar with the concepts described herein may implement such functionality in a suitable manner for each particular application, but such implementation decisions should not be interpreted as limiting the scope of the present disclosure.

[0028] In accordance with some embodiments, the UE transceiver 230 may be referred to herein as an “uplink” transceiver 230 that includes a radio frequency (RF) transmitter and a RF receiver each comprising circuitry that is coupled to the antenna 232. A duplex switch (not shown) may alternatively couple the uplink transmitter or receiver to the uplink antenna in time duplex fashion. Similarly, in accordance with some embodiments, the BS transceiver 210 may be referred to herein as a “downlink” transceiver 210 that includes a RF transmitter and a RF receiver each comprising circuity that is coupled to the antenna 212. A downlink duplex switch may alternatively couple the downlink transmitter or receiver to the downlink antenna 212 in time duplex fashion. The operations of the two transceiver modules 210 and 230 may be coordinated in time such that the uplink receiver circuitry is coupled to the uplink antenna 232 for reception of transmissions over the wireless transmission link 250 at the same time that the downlink transmitter is coupled to the downlink antenna 212. Conversely, the operations of the two transceivers 210 and 230 may be coordinated in time such that the downlink receiver is coupled to the downlink antenna 212 for reception of transmissions over the wireless transmission link 250 at the same time that the uplink transmitter is coupled to the uplink antenna 232. In some embodiments, there is close time synchronization with a minimal guard time between changes in duplex direction.

[0029] The UE transceiver 230 and the base station transceiver 210 are configured to communicate via the wireless data communication link 250, and cooperate with a suitably configured RF antenna arrangement 212 / 232 that can support a particular wireless communication protocol and modulation scheme. In some illustrative embodiments, the UE transceiver 210 and the base station transceiver 210 are configured to support industry standards  such as the Long Term Evolution (LTE) and emerging 5G standards, and the like. It is understood, however, that the present disclosure is not necessarily limited in application to a particular standard and associated protocols. Rather, the UE transceiver 230 and the base station transceiver 210 may be configured to support alternate, or additional, wireless data communication protocols, including future standards or variations thereof.

[0030] In accordance with various embodiments, the BS 202 may be an evolved node B (eNB) , a serving eNB, a target eNB, a femto station, or a pico station, for example. In some embodiments, the UE 204 may be embodied in various types of user devices such as a mobile phone, a smart phone, a personal digital assistant (PDA) , tablet, laptop computer, wearable computing device, etc. The processor modules 214 and 236 may be implemented, or realized, with a general purpose processor, a content addressable memory, a digital signal processor, an application specific integrated circuit, a field programmable gate array, any suitable programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof, designed to perform the functions described herein. In this manner, a processor may be realized as a microprocessor, a controller, a microcontroller, a state machine, or the like. A processor may also be implemented as a combination of computing devices, e.g., a combination of a digital signal processor and a microprocessor, a plurality of microprocessors, one or multiple microprocessors in conjunction with a digital signal processor core, or any other such configuration.

[0031] Furthermore, the steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied directly in hardware, in firmware, in a software module executed by processor modules 214 and 236, respectively, or in any practical combination thereof. The memory modules 216 and 234 may be realized as RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. In this regard, memory modules 216 and 234 may be coupled to the processor modules 210 and 230, respectively, such that the processors modules 210 and 230 can read information from, and write information to, memory modules 216 and 234, respectively. The memory modules 216 and 234 may also be integrated into their respective processor modules 210 and 230. In some embodiments, the memory modules 216 and 234 may each include a cache memory for storing  temporary variables or other intermediate information during execution of instructions to be executed by processor modules 210 and 230, respectively. Memory modules 216 and 234 may also each include non-volatile memory for storing instructions to be executed by the processor modules 210 and 230, respectively.

[0032] The network communication module 218 generally represents the hardware, software, firmware, processing logic, and / or other components of the base station 202 that enable bi-directional communication between base station transceiver 210 and other network components and communication nodes configured to communicate with the base station 202. For example, network communication module 218 may be configured to support internet or WiMAX traffic. In a typical deployment, without limitation, network communication module 218 provides an 802.3 Ethernet interface such that base station transceiver 210 can communicate with a conventional Ethernet based computer network. In this manner, the network communication module 218 may include a physical interface for connection to the computer network (e.g., Mobile Switching Center (MSC) ) . The terms “configured for, ” “configured to” and conjugations thereof, as used herein with respect to a specified operation or function, refer to a device, component, circuit, structure, machine, signal, etc., that is physically constructed, programmed, formatted and / or arranged to perform the specified operation or function.

[0033] The Open Systems Interconnection (OSI) Model (referred to herein as, “open system interconnection model” ) is a conceptual and logical layout that defines network communication used by systems (e.g., wireless communication device, wireless communication node) open to interconnection and communication with other systems. The model is broken into seven subcomponents, or layers, each of which represents a conceptual collection of services provided to the layers above and below it. The OSI Model also defines a logical network and effectively describes computer packet transfer by using different layer protocols. The OSI Model may also be referred to as the seven-layer OSI Model or the seven-layer model. In some embodiments, a first layer may be a physical layer. In some embodiments, a second layer may be a Medium Access Control (MAC) layer. In some embodiments, a third layer may be a Radio Link Control (RLC) layer. In some embodiments, a fourth layer may be a Packet Data Convergence Protocol (PDCP) layer. In some embodiments, a fifth layer may be a Radio Resource Control (RRC) layer.  In some embodiments, a sixth layer may be a Non-Access Stratum (NAS) layer or an Internet Protocol (IP) layer, and the seventh layer being the other layer.

[0034] Various example embodiments of the present solution are described below with reference to the accompanying figures to enable a person of ordinary skill in the art to make and use the present solution. As would be apparent to those of ordinary skill in the art, after reading the present disclosure, various changes or modifications to the examples described herein can be made without departing from the scope of the present solution. Thus, the present solution is not limited to the example embodiments and applications described and illustrated herein. Additionally, the specific order or hierarchy of steps in the methods disclosed herein are merely example approaches. Based upon design preferences, the specific order or hierarchy of steps of the disclosed methods or processes can be re-arranged while remaining within the scope of the present solution. Thus, those of ordinary skill in the art will understand that the methods and techniques disclosed herein present various steps or acts in a sample order, and the present solution is not limited to the specific order or hierarchy presented unless expressly stated otherwise.

[0035] 2. Systems and Methods for Managing Power Sources for Remote Radio Unit (s)

[0036] Energy efficiency has become important for network operators, and it may be desirable to configure the network to consume more power from sustainable sources, such as solar power or wind. In this regard, each component of the network is to be able to identify and report its own current power source. A power source controller can collect the reported information and make optimized configurations to achieve a satisfactory balance between network performance and the associated energy consumption from different power sources. In certain implementations, a remote radio unit (RRU) (or a radio unit) can consume a large portion of a base station’s power consumption. As a result, it is desirable for an RRU (or a radio unit) to be able to identify and report its power status and to facilitate smart controlling and / or scheduling of data and other services accordingly. In certain implementations, the power source controller can be configured to manage multiple power sources of different types and possibly from different vendors / providers.

[0037] In certain implementations, the RRUs can be powered up by greener sources instead of being plugged into the power grid. In certain implementations, the RRUs can be powered by solar panels, wind turbines, and the like. The signaling between the baseband unit (BBU) and RRU can be subject to the implementation choices of vendors. In certain implementations, to facilitate interoperability between BBU and RRU from different vendors, the signaling exchange and related procedures relevant to RRU power state and power sources can be defined. In certain implementations, the open radio access network (O-RAN) Alliance can define the interface and signaling procedures between BBU and RRU. In some implementations, the O-RAN design can be used as a reference.

[0038] In certain implementations, the RRU controller, the O-RU controller, the NETCONF client, the O-DU, or the BBU can be used interchangeably. In certain implementations, the RRU controller can be (more generically or generally) referred to herein to include a BBU, O-RU controller, NETCONF client, or O-DU. In certain implementations, the DU can be integrated within the BBU, which can be directly connected to the RRU, such that the RRU can be controlled by the DU. In certain implementations, the O-RU can be defined by the O-RAN specifications. In some implementations, the O-RU can be referred to herein as an RRU. In certain implementations, the O-RU controller can be the NETCONF client according to the O-RAN specifications. In some implementations, according to the O-RAN specifications, the NETCONF client can be referred to herein as the O-DU. In certain implementations, the O-DU can send an indication to the O-RU power source controller through management plane (M-plane) or control plane (C-plane) . In certain implementations, the C-plane can deliver indications in near real-time.

[0039] In certain implementations, a new / specific module in the RRU can identify and / or switch between power sources to supply to the RRU. This new / specific module in the RRU can monitor the real-time status and / or conditions of different power sources (e.g., solar, wind, power grid, etc. ) . In certain implementations, the new / specific module in the RRU can determine and / or identify which power source (s) to use. In certain implementations, the new module in the RRU can change the power source according to configurations or commands from the RRU controller or externally. Upon request, the new module in the RRU can report detailed power usage and status, including the average power, peak power, power source, and consumption of  different components (different components may use different power sources) , etc., to the RRU controller (e.g., BBU) . This new module in the RRU can be referred to herein as a RRU power source controller. In certain implementations, the RRU power source controller can collect the status of one or more power sources and report to the other nodes if one of the power sources becomes unavailable or needs maintenance. The reported information can be used by, or eventually forwarded to, a network management function. After receiving the information, the network management function can make decisions accordingly or trigger a warning message to maintenance engineers. In certain implementations, the RRU power source controller can manage power sources for multiple RRUs, as shown in FIG. 4. In certain implementations, the RRU power controller can be integrated within the RRU (such as software running on the RRU’s processors) , as shown in FIG. 5. In certain implementations, the RRU power source controller can be an external module but maintain a one-to-one link with the RRU, as shown in FIG. 5.

[0040] In certain implementations, there can be different ways for the BBU to send / transmit / provide indications to the RRU power source controller. Depending on the implementation, the BBU can send / transmit indications to the RRU power source controller directly or indirectly through the RRU. For example, when the RRU controller (e.g., BBU) transmits an indication to the RRU power source controller, the indication can be transmitted directly from the BBU to the RRU power source controller or from the BBU to the RRU, which then forwards the indication to the RRU power source controller. As shown in FIGS. 3 and 5, the dashed line associating / connecting / linking the BBU with the RRU power source controller can indicate a direct link between the BBU and the RRU power source controller. In certain implementations, if the direct link does not exist, the RRU can operate as an intermediary to forward the messages. In certain implementations, when the RRU power source controller is integrated within the RRU, a direct link may not be desired, as the fronthaul interface connects the BBU and RRU.

[0041] In certain implementations, upon receiving a command from the network management function, the BS / BBU (or RRU controller) can indicate to the RRU power source controller to switch to a different power source, power ON and OFF a particular power source, and / or activate additional power sources. This can occur for various reasons, such as to  support / enable higher reliability, to use / access a more reliable power source, to access additional power sources due to insufficient current power, or to reduce carbon footprint by using sustainable power sources, even if they may be unstable. The command / indication to implement these changes can result in success or failure, and further adjustments / actions can be initiated in response to the success or failure. In certain implementations, some tasks can be performed jointly by the baseband unit (BBU) and RRU, or some tasks can be performed in BBU or RRU. Depending on the real-time power status of RRU, some task offloading can be achieved between the two nodes. This configuration may include associating / correlating the performance of certain tasks with the power status of the RRU. In certain implementations, the transmission power of the RRU can vary due to the instability of some power sources with respect to the output voltage. In some implementations, the transmission power of the RRU can vary because the RRU may switch from one power source to another. This configuration may include periodic self-calibration and monitoring of its associated Tx power by the RRU, triggered by updates from the RRU power source controller. In certain implementations, the transmission timing can vary, impacting the timing control of the RRU and antennas. This configuration may also desire calibration. In certain implementations, the RRU working status can vary.

[0042] In certain implementations, for maintenance and troubleshooting purposes, a power source can report its associated (e.g., operational) status, including breakdown, power OFF, and requirement for repair, to the RRU power source controller. The RRU power source controller can report to the RRU controller (which can be the BS or BBU) and then report to the management function. In certain implementations, a power source, at least when first connected / plugged into the RRU (or when the RRU is first turned on) , is to be discovered and / or undergo an authentication process. This ensures that the power source can be trusted, and that the information reported by the power source (e.g., power status, type, carbon footprint, etc. ) can be trusted. In certain implementations, the RRU power source controller or the power source itself can re-initiate the authentication process if a power source fails authentication. In certain implementations, the RRU power source controller and / or RRU power sources can be each assigned an IP address (e.g., by the RRU power source controller) after their first-time turn-on / activation. Some implementations may include intelligent power sources with basic communication functions that for instance allow them to be assigned an IP address and / or report their working parameters (e.g., to the RRU power source controller) . In certain implementations,  the RRU power source controller can be discovered by the RRU. In certain implementations, the RRU power sources can be discovered by the RRU power source controller.

[0043] In certain implementations, the RRU power source controller can maintain a list of trusted or candidate power sources and can keep record / track of their status and type. The RRU power source controller can update the list by triggering / transmitting / sending a request to one or more connected power sources to provide updates on their status and / or type (e.g., state) of power source. In some implementations, the RRU power source controller can manage and / or maintain several states for the power source, such as one or a combination of: active, ready, trusted, untrusted, unknown, partly active, and partly ready, among others. In some implementations, a state change can be triggered by the expiration of a timer, feedback received by the RRU power source controller from a particular power source, or direct monitoring of the power source by the RRU power source controller. In some implementations, the “active” state can indicate that this power source is being used by the RRU. In some implementations, the “ready” state can indicate that this power source is not used by the RRU, but the RRU can switch to it. In some implementations, the “unknown” state can indicate that the RRU power source controller may not know the up-to-date state of a power source. In some implementations, the “untrusted” state can indicate that the power source failed the authentication process. In some implementations, the “trusted” state can indicate that the power source passed the authentication process. In some implementations, the “partly active” state can indicate that RRU is using this power source, and the output voltage or output power is X%of the full power. In some implementations, the “partly ready” state can indicate that the power source can be switched to, but the output voltage or power can be X%of the full power. In some implementations, each power source can have a priority indicator that indicates its priority to be selected as an active power source or primary power source.

[0044] In certain implementations, the BBU can calculate and / or report an energy indicator based on itself (e.g., its own status, conditions, configuration, operation / mode) and the reported energy source information of one or more connected RRU power source controllers. The BS can calculate an overall energy indicator to provide to the AMF / OAM for use in mobility management (e.g., handover between base stations or cells) and other network functions (e.g., sensing) . In certain implementations, the BBU can calculate and / or report an energy indicator  based on itself and the reported energy source of one or more connected RRUs. The management function in a BS can calculate an overall energy indicator to provide for external functions used for carbon trade or carbon footprint tracking. In some implementations, when reporting carbon footprint or energy consumption, the RRU or BBU can send / transmit the information to a trusted third party for verification, may send it to a block chain, or may send this information to a network management function.

[0045] In certain implementations, the RRU power source controller can indicate to the RRU and / or the RRU controller (or BBU) its capabilities, including whether it supports monitoring power sources, whether it can switch power sources, maximum operation power, maximum transmit power, ability to calculate its power consumption, ability to calculate its carbon footprint, ability to support mixed power input from multiple sources, ability to store energy, and minimum power to maintain operation. In certain implementations, the RRU controller can send / transmit a message to the RRU to request the RRU’s capabilities, including maximum transmit power. In some implementations, because the RRU may switch between different power sources, this capability may change / vary accordingly. The RRU power source controller can report to the RRU on a change in power usage, and the RRU can report to the RRU controller (e.g., event triggered or periodic report) . In certain implementations, the RRU controller (or BBU) can send / transmit a request for RRU to update on its supported capabilities. In some implementations, the RRU power source controller can function as a mixer, for example, to mix / combine input power from multiple power sources and can output the combined power to the RRU. The RRU power source controller can mix different power sources and can provide output to the RRU, based on a command or recommendation from the RRU controller, and / or based on the power demand of the RRU.

[0046] In certain implementations, the power source can be associated with various tags (e.g., classifications, categories or labels) , including tags for or corresponding to: sustainability level or carbon footprint level (e.g., indicating how green the power is) , reliability, failure probability, recovery time (e.g., indicating the time desired to recover from a failure) , stability of the associated output voltage or electric current, presence and capacity of power storage, maximum output power or electric current, among others. This information can be assumed to be quasi-static. In some implementations, the dynamic status parameters may include current voltage,  electric current, remaining power storage, and / or temperature of the battery (e.g., if there is one present / available, for example, serving as storage) , among others. In some implementations, the RRU power source controller can monitor and / or request this information, and can report it to other network nodes. In some implementations, when describing / discussing “information exchange” or “signaling exchange” between power sources and RRU power source controllers, not all types of information / signaling listed / contemplated here will be explicitly mentioned for the sake of brevity.

[0047] In certain implementations, the RRU power source controller can monitor all power sources for a specific RRU. The RRU power source controller can be configured to report the types of power sources and their status periodically or upon request. In certain implementations, the RRU power source controller can monitor the status of power sources, for example, by sending / transmitting a message to the power source to request an update / report on its current status, including for instance the voltage, remaining power storage, temperature of the battery (if there is one present, e.g., serving as storage) , and / or other maintenance parameters. This configuration may implement / provide / include a standard interface between the power sources and the RRU power source controller. In some implementations, as shown in FIG. 5 or 6, multiple power sources can exchange information with the RRU power source controller. In certain implementations, the RRU power source controller can independently monitor the status of the power sources, for example, by connecting directly to the power source to measure its voltage. This configuration can be implemented when the power source is designed jointly / compatibly with the RRU power source controller to allow such measurement.

[0048] In certain implementations, where the RRU controller is an O-RU controller and the RRU (e.g., radio unit) is an O-RU, the RRU power source controller can be integrated within an O-RU. In certain implementations, when the RRU controller, the O-RU controller, the NETCONF client, or the O-DU receives the update from a RRU power source controller (e.g., forwarded by the RRU) , it may start / initiate a calibration operation. This is because a change in the power status can result in a change in the transmit power of the RRU, along with other potential changes in parameters. The RRU controller (e.g., the NETCONF client) can start a calibration procedure by retrieving resource requirements for antenna calibration operation, e.g., timing and / or number of iterations / steps, from O-RU by getting the antenna-calibration- capabilities container defined in the o-ran-antenna-calibration YANG model. In certain implementations, the RRU can determine whether to perform antenna calibration after receiving updates from the RRU power source controller. The RRU can make this determination on its own. In this example, the O-DU can subscribe to antenna-calibration-required notifications to receive indications from the O-RU that calibration is required. In certain implementations, when the O-RU indicates antenna calibration is desired / requested or when the NETCONF Client determines to calibrate the O-RU, the NETCONF Client can allocate time resources for antenna calibration and can configure these in the O-RU using the start-antenna-calibration RPC request. The NETCONF client can allocate time resources for the calibration operation, ensuring they satisfy the minimum time duration desired as reported by the O-RU using the antenna-calibration-capabilities.

[0049] In certain implementations, the RRU controller (e.g., the BBU) , the O-RU controller, or the NETCONF Client can put / set the tx-array-carrier or rx-array-carrier to sleep (e.g., sleep mode) by setting the value of the parameter “active” in the corresponding tx-array-carrier element or rx-array-carrier element to “SLEEP” after receiving a message indicating the latest status of RRU power sources and / or RRU power usage. In some implementations, if a tx-array-carrier  / rx-array-carrier is assigned to a tx-array or rx-array, all of whose elements are at that time disabled due to sleep mode, the O-RU can allow all those elements of the tx-array  / rx-array to allow carrier activation after receiving a message to update the RRU power sources and / or RRU power usage.

[0050] In certain implementations, the O-RU power source controller and / or O-RU power sources that have obtained / received / acquired their IPv6 addresses by stateless address auto-configuration can use stateless DHCPv6 to obtain management plane configuration information. In some implementations, the O-RU power source controller and / or O-RU power sources operating using stateful IPv4 or IPv6 address allocations can obtain / receive / acquire management plane configuration information during IP address allocation. In some implementations, the O-RU power source controller and / or O-RU power sources that have had their IP address (es) manually configured can also be manually configured and can be discovered by their controllers or controlling nodes. In some implementations, to be discovered and identified, the O-RU power  source controller and / or O-RU power sources may have a pre-defined sequence indicating at least their vendor, type, and status, among others.

[0051] In certain implementations, the O-RU can send / transmit its NETCONF capabilities in the NETCONF Hello message. The NETCONF capabilities can be exchanged between the O-RU and the NETCONF client (s) . In some implementations, the NETCONF capabilities may include, but are not limited to, the ability to switch power sources, the ability to monitor power sources, maximum operation power, maximum transmit power, the ability to calculate its own power consumption, the ability to calculate its own carbon footprint, the ability to support mixed power input from multiple sources, the ability to store energy, and / or the minimum power to maintain operation, among other items.

[0052] In certain implementations, once receiving an update in power usage (e.g., event triggered) , the O-RU can report to the O-DU through the M-plane or C-plane according to its current supported capabilities. In some implementations, the report can be sent / transmitted through a NETCONF session. In certain implementations, the O-RU can report to the O-DU through the M-plane or C-plane on its current supported capabilities periodically. In some implementations, the report can be sent / transmitted through a NETCONF session. In certain implementations, the O-DU can request the O-RU to send its current supported capabilities, or to request an update / report on supported capabilities. In some implementations, an update on O-RU supported capabilities may include capability items different from the last report. In some implementations, the request and / or report can be sent / transmitted through a NETCONF session. In some implementations, the request and / or report can be sent / transmitted through the M-plane or C-plane.

[0053] In certain implementations, when the BBU sends / transmits a data stream to the RRU (e.g., radio unit) , the BBU can increase the transmission power to increase the SNR and can make it easier for the RRU to decode the data without needing / desiring / using complicated algorithms. This is a non-limiting example of how the RRU can offload certain tasks to the BBU to save power when using a specific power source that may not support high output power, or to save power when using a less environment-friendly power source.

[0054] In certain implementations, some tasks / functions related to communications or sensing can be jointly performed by the O-RU and O-DU, such as beamforming, uplink data processing, and angle of arrival estimation. There can be several ways of functionally splitting between O-DU and O-RU, for example, determined by O-RU using a particular power source. In some implementations, the O-DU, after receiving the power status and usage information from the O-RU, can notify the O-RU when performing certain tasks on the O-RU or O-DU.

[0055] In certain implementations, when a power source encounters an operational error, the power source can send / transmit a message to the O-RU power controller. In some implementations, the O-RU power controller can determine that an error has occurred, for example, by directly monitoring the working status of the power source. In some implementations, the O-RU power controller can inform the O-RU. In some implementations, the O-RU can send / transmit the <alarm-notif> indication / signaling to a subscriber when the NETCONF Client establishes a subscription to alarm notifications, and a new alarm is added to the active-alarm-list. In certain implementations, when the O-RU power controller encounters an error, the O-RU power controller can inform O-RU. The O-RU can send / transmit the <alarm-notif> indication / signaling to a subscriber when the NETCONF Client establishes a subscription to alarm notification and a new alarm is added to the active-alarm-list.

[0056] In certain implementations, the new alarm may include / specify / indicate a fault-ID, a fault source (e.g., a particular power or the O-RU power controller itself) , a fault severity (which can be a value to indicate how bad the error is) , or a description of encountered problems if the O-RU power controller can collect such information from power sources, for example, including probable causes and specific problems. In some implementations, the new alarm may include a description of suggested repair / remediation actions in the information element proposed-repair-actions, including for instance replacing a battery or replacing a solar panel.

[0057] In certain implementations, when an error in a power source is fixed, the power source can send the message to the O-RU power controller. In certain implementations, the O-RU power controller can determine that the error is fixed, for example, by directly monitoring the working status of the power source. In some implementations, the O-RU power controller can inform the O-RU. In some implementations, the O-RU can send the <alarm-notif> to a  subscriber when the NETCONF Client establishes a subscription to alarm notification (s) and an alarm is removed from the list.

[0058] In certain implementations, as shown in FIG. 7, the configuration can be implemented when an RRU is first plugged into a power source or when authentication expires. The configuration  / implementation ensures that the power source can be trusted. As shown in FIG. 7, the power source can send / transmit an access request to the RRU power source controller. The power source ID, power status, type, and / or credentials may be included in the message. In some implementations, the credentials may include the power source ID, a timestamp, an expiration time, and / or the type of power source (e.g., wind, solar, etc. ) , among others.

[0059] In certain implementations, upon receiving the access request, the RRU power source controller can forward the power source ID and / or credentials to the RRU. The RRU can further forward the power source ID and / or credentials to the RRU controller (or BBU) and / or then to a management function via the RRU controller or BBU, for example, for authentication. The RRU can send / transmit the above information to the RRU controller or BBU through the management plane (e.g., M-plane) . The RRU controller or BBU can send / transmit the information to the management function through the O1 interface.

[0060] In certain implementations, the management function can verify / validate the receiving credentials, for example, by validating the timestamp and the expiration time or by checking that the power source ID in the credentials matches the power source ID in the message. The verification can be done in the management function if there is a local database in it storing the relevant rules. In certain implementations, the management function can connect to an online database to check if the provided ID, credentials, and / or other information match.

[0061] In certain implementations, the management function can send / transmit the power source authentication response to the RRU controller, which can transmit it to the RRU, and can subsequently send it back to the RRU power source controller via the RRU. In some implementations, if the verification is successful, the RRU can consider / determine authorizing the access of the power source based on the power status it provided and can add it to a list of candidate power sources (e.g., by adding it to the trusted power source list) . In some implementations, if the verification fails, the RRU can refuse / reject the access request.

[0062] In certain implementations, the O-RU controller (e.g., the O-DU) can collect information on the working / operational status of power sources. In some implementations, the O-DU can forward this information to the service management and orchestration (SMO) , and / or near-real-time ran intelligent controller (near-RT RIC) . The SMO, near-RT RIC, and / or non-RT RIC can receive / obtain / acquire information and make decisions.

[0063] In certain implementations, and as an example, the RRU can use power source A, which has an output power of 100 W. In some implementations, when the RRU desires additional power to support its real-time data traffic, the RRU power source controller can activate two power sources, such as one power source with 100 W output power and another power source with 50 W output power. In this manner, the RRU power source controller can function as a mixer and / or activate two power sources directly connected to the RRU.

[0064] In certain implementations, the O-DU can indicate to the RRU power source controller whether a certain power source is to be turned ON or OFF, and / or indicate how much power, voltage, and / or electric current is to be used from a certain power source. This indication can be sent to the RRU power source controller regarding multiple power sources, such as turning ON power source A, turning ON power source B, and turning OFF power source C. In some implementations, the indication may include a timer to indicate the timing of this action, or it can function without a timer. In certain implementations, to indicate / specify the timing for performing actions, the indication can be associated with a time indication / reference, such as “to turn on a power source at 9: 00 am” . In some implementations, the action can be carried out immediately when the indication comes (e.g., is received by the RRU power source controller) without a timer or time indication. This indication can be sent / transmitted to the RRU power source controller on the M plane.

[0065] In certain implementations, the O-DU can indicate to the RRU power source controller whether a certain power source is to be turned ON or OFF, and / or how much power, voltage, or electric current is to be used from a certain power source. In some implementations, the indication can be carried out or communicated on the C plane, which is much faster than M plane configurations. In some implementations, the O-DU can associate the power source indication with the data stream being transmitted on the U-plane to achieve precise control of the  transmit power of different symbols, slots, or frames. For instance, the O-DU can send / transmit a slot to the O-RU, where there are 14 symbols in one slot. The transmit power for the 14 symbols can be different, and the O-DU can indicate to the O-RU and / or the RRU power source controller how much power to transmit a particular symbol. Upon or responsive to receiving the indication, the RRU power source controller can schedule among all available power sources and make sure that the power demand can be satisfied for every symbol. In some implementations, the RRU power source controller can provide feedback to O-DU (e.g., directly or through O-RU) that the power demand on a certain symbol may not be satisfied or indicate how much is the gap / deficiency in power.

[0066] In certain implementations, where the BS is to carry out or perform sensing tasks, the BS may desire a larger transmit power than communications tasks. In this case, the O-DU can indicate to the O-RU power source controller that, for a certain task, a new or additional power source is to be desired. This indication can be sent via M-plane or C-plane. In some implementations, for transmitting reference signals related to communications and sensing, different transmit powers may be desired. In this case, the O-DU can indicate to the O-RU power source controller the need / demand for the new or additional power source (s) .

[0067] In certain implementations, for different use cases, the wireless sensing tasks may desire / demand different transmit powers. For instance, in a use case such as monitoring vehicles, a smaller transmit power may suffice due to the large radar cross section (RCS) of vehicles. In some implementations, if the sensing task is to sense human motions, it may be desirable for the transmit power to be larger. In this case, the sensing function (SF) or a management function in the core network or O-cloud can send / transmit an indication or recommendation of the transmit power to the O-DU. The O-DU can indicate to the O-RU power source controller on the demand in transmit power. The O-RU power source controller can then switch to and / or activate additional or new power sources to meet the demand / need.

[0068] Referring now to FIG. 8, which illustrates a flow diagram of a method 1300 for managing power sources for radio unit (s) . The method 800 may be implemented using any of the components and devices detailed herein in connection with FIGS. 1–7. In an overview, the method 800 may include a power source controller monitoring a plurality of power sources  configured to provide power to a radio unit of a wireless communication node (802) . The method 800 may include the power source controller sending information based on the monitoring to a remote radio unit controller (804) . The method 800 may include the remote radio unit controller receiving information based on the monitoring from the power source controller (806) .

[0069] In certain configurations, a power source controller (e.g., RRU power source controller) can monitor a plurality of power sources configured to provide power to a radio unit (e.g., remote radio unit) of a wireless communication node (802) . The power source controller can send / transmit / provide information that is based on the monitoring to a remote radio unit (RRU) controller (804) . In certain configurations, the power source controller can monitor at least one of the following information of the plurality of power sources: real-time status, real-time condition, or power usage. In certain configurations, the power source controller can identify the plurality of power sources. In certain configurations, the power source controller can determine, according to the information, to use and / or switch to one or more of the plurality of power sources to supply power to the wireless communication node.

[0070] In certain configurations, the power source controller can receive / obtain / acquire, according to a message from a remote radio unit (RRU) controller or the wireless communication node, an indication to at least one of: activate or deactivate usage of one of the plurality of power sources, or switch to a different subset of the plurality of power sources. In certain configurations, the power source controller can determine a power-related status of at least one of:the radio unit (e.g., RRU) or the RRU controller (e.g., the BBU) . In certain configurations, the power source controller can identify an association between the performance of a first task and the power-related status. In certain configurations, the power source controller can determine, according to the association or the power-related status, whether the radio unit or the RRU controller (e.g., BBU) or both are to perform the task.

[0071] In certain configurations, the power source controller can send / transmit / provide a trigger / indication to the radio unit (e.g., RRU) to perform at least one of: self-calibration or monitoring of transmit power. In certain configurations, the power source controller can receive / obtain / acquire a status of one of the plurality of power sources. In certain configurations,  the power source controller can send a report, according to (e.g., based on or comprising) the status, to the RRU controller. In certain configurations, the power source controller can initiate / perform authentication of a power source when the power source becomes available to provide power to the radio unit. In certain configurations, the power source controller can assign an internet protocol (IP) address to the power source to support one or more communication or reporting functions (e.g., to enable the authentication) . In certain configurations, the power source controller can enable / allow discovery by the power source. In certain configurations, the power source controller can discover the power source. In certain configurations, the RRU controller can determine / calculate an energy indicator according to the information and can send / transmit / provide a report, according / corresponding to the energy indicator, to a function of a core network (e.g., AMF / OAM) .

[0072] In certain configurations, the power source controller can send / transmit / provide an indication of a capability of the power source controller to at least one of: the radio unit or the RRU controller. The capability may include at least one of the following capabilities: monitoring one or more of the power sources, switching to one or more of the power sources, support for a maximum operating power, support for a maximum transmit power, calculating or determining the power source controller’s power consumption, calculating or determining the power source controller’s carbon footprint, support for mixed power input from multiple power sources, ability to store energy, support for a minimum power to maintain operation, ability to compensate for unstable power sources, or ability to stabilize for power shortage. In certain configurations, the power source controller can send / transmit / provide an indication of a change in power usage to the radio unit. The radio unit can send a report, according to the indication, to the RRU controller. In certain configurations, the RRU controller can send a request to the radio unit to provide a report or update of the radio unit’s capabilities.

[0073] In certain configurations, the power source controller can combine / merge power provided by at least two of the power sources into a combined power output. In certain configurations, the power source controller can combine the power provided by at least two of the power sources according to at least one of: a communication / instruction / trigger from the RRC controller or a power demand of the radio unit. In certain configurations, the power source controller can provide the combined power output to the radio unit. In certain configurations,  each of the power sources can be associated with at least one tag or indication of at least one of the following: a sustainability level or carbon footprint, reliability, failure probability, recovery time from failure, stability of output voltage, stability of electric current, whether power storage is supported, capacity of the power storage, a maximum output power, or a maximum electric current. In certain configurations, the power source controller can maintain or request a state of a first power source of the plurality of power sources. In certain configurations, the state may include at least one of the following: active, ready, trusted, untrusted, unknown, partly active, or partly ready. A power source can have / achieve or be assigned two or more non-conflicting states (e.g., at any time instance) , such as “trusted” and “ready” .

[0074] In certain configurations, a remote radio unit (RRU) controller can receive / obtain / acquire information from a power source controller (806) . The information can be based on monitoring a plurality of power sources configured to provide power to a radio unit (e.g., RRU) of a wireless communication node.

[0075] While various embodiments / implementations of the present solution have been described above, it should be understood that they have been presented by way of example only, and not by way of limitation. Likewise, the various diagrams may depict an example architecture or configuration, which are provided to enable persons of ordinary skill in the art to understand example features and functions of the present solution. Such persons would understand, however, that the solution is not restricted to the illustrated example architectures or configurations but can be implemented using a variety of alternative architectures and configurations. Additionally, as would be understood by persons of ordinary skill in the art, one or multiple features of one embodiment / implementation can be combined with one or multiple features of another embodiment / implementation described herein. Thus, the breadth and scope of the present disclosure should not be limited by any of the above-described illustrative embodiments.

[0076] It is also understood that any reference to an element herein using a designation such as “first, ” “second, ” and so forth does not generally limit the quantity or order of those elements. Rather, these designations can be used herein as a convenient means of distinguishing between two or more elements or instances of an element. Thus, a reference to first and second elements  does not mean that only two elements can be employed, or that the first element must precede the second element in some manner.

[0077] Additionally, a person having ordinary skill in the art would understand that information and signals can be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, and symbols, which may be referenced in the above description, can be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

[0078] A person of ordinary skill in the art would further appreciate that any of the various illustrative logical blocks, modules, processors, means, circuits, methods and functions described in connection with the aspects disclosed herein can be implemented by electronic hardware (e.g., a digital implementation, an analog implementation, or a combination of the two) , firmware, various forms of program or design code incorporating instructions (which can be referred to herein, for convenience, as “software” or a “software module) , or any combination of these techniques. To clearly illustrate this interchangeability of hardware, firmware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware, firmware or software, or a combination of these techniques, depends upon the particular application and design constraints imposed on the overall system. Skilled artisans can implement the described functionality in various ways for each particular application, but such implementation decisions do not cause a departure from the scope of the present disclosure.

[0079] Furthermore, a person of ordinary skill in the art would understand that various illustrative logical blocks, modules, devices, components, and circuits described herein can be implemented within or performed by an integrated circuit (IC) that can include a general purpose processor, a digital signal processor (DSP) , an application specific integrated circuit (ASIC) , a field programmable gate array (FPGA) or other programmable logic device, or any combination thereof. The logical blocks, modules, and circuits can further include antennas and / or transceivers to communicate with various components within the network or within the device. A general purpose processor can be a microprocessor, but in the alternative, the processor can be  any conventional processor, controller, or state machine. A processor can also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or multiple microprocessors in conjunction with a DSP core, or any other suitable configuration to perform the functions described herein.

[0080] If implemented in software, the functions can be stored as one or multiple instructions or code on a computer-readable medium. Thus, the steps of a method or algorithm disclosed herein can be implemented as software stored on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that can be enabled to transfer a computer program or code from one place to another. A storage media can be any available media that can be accessed by a computer. By way of example, and not limitation, such computer-readable media can include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer.

[0081] In this document, the term “module” as used herein, refers to software, firmware, hardware, and any combination of these elements for performing the associated functions described herein. Additionally, for purpose of discussion, the various modules are described as discrete modules; however, as would be apparent to one of ordinary skill in the art, two or more modules may be combined to form a single module that performs the associated functions according to embodiments of the present solution.

[0082] Additionally, memory or other storage, as well as communication components, may be employed in embodiments of the present solution. It will be appreciated that, for clarity purposes, the above description has described embodiments of the present solution with reference to different functional units and processors. However, it will be apparent that any suitable distribution of functionality between different functional units, processing logic elements or domains may be used without detracting from the present solution. For example, functionality illustrated to be performed by separate processing logic elements, or controllers, may be performed by the same processing logic element, or controller. Hence, references to  specific functional units are only references to a suitable means for providing the described functionality, rather than indicative of a strict logical or physical structure or organization.

[0083] Various modifications to the embodiments described in this disclosure will be readily apparent to those skilled in the art, and the general principles defined herein can be applied to other embodiments without departing from the scope of this disclosure. Thus, the disclosure is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the novel features and principles disclosed herein, as recited in the claims below.

Claims

1.A method, comprising:monitoring, by a power source controller, a plurality of power sources configured to provide power to a radio unit of a wireless communication node; andsending, by the power source controller to a remote radio unit (RRU) controller, information that is based on the monitoring.2.The method of claim 1, comprising monitoring, by the power source controller, at least one of following information of the plurality of power sources: real-time status, real-time condition, or power usage.3.The method of claim 1, comprising identifying, by the power source controller, the plurality of power sources.4.The method of claim 1, comprising determining, by the power source controller according to the information, to use or switch to one or more of the plurality of power sources to supply power to the wireless communication node.5.The method of claim 1, comprising receiving, by the power source controller according to a message from a remote radio unit (RRU) controller or the wireless communication node, an indication to at least one of: activate or deactivate usage of one of the plurality of power sources, or switch to a different subset of the plurality of power sources.6.The method of claim 1, comprising at least one of:determining, by the power source controller, a power-related status of at least one of: the radio unit or the RRU controller;identifying, by the power source controller, an association between the performance of a first task, and the power-related status; ordetermining, by the power source controller according to the association or the power-related status, whether the radio unit or the RRU controller or both are to perform the task.7.The method of claim 1, comprising:sending, by the power source controller, a trigger to the radio unit to perform at least one of: self-calibration or monitoring of transmit power.8.The method of claim 1, comprising at least one of:receiving, by the power source controller, a status of one of the plurality of power sources; orsending, by the power source controller to the RRU controller, a report according to the status.9.The method of claim 1, comprising at least one of:initiating, by the power source controller, authentication of a power source when the power source becomes available to provide power to the radio unit;assigning, by the power source controller, an internet protocol (IP) address to the power source to support one or more communication or reporting functions;enabling the power source controller to be discovered by the power source; ordiscovering, by the power source controller, the power source.10.The method of claim 1, wherein the RRU controller determines an energy indicator according to the information, and sends a report according to the energy indicator to a function of a core network.11.The method of claim 1, comprising sending, by the power source controller to at least one of:the radio unit or the RRU controller, an indication of a capability of the power source controller,wherein the capability comprises at least one of: monitoring one or more of the power sources, switching to one or more of the power sources, a maximum operating power, a maximum transmit power, calculating or determining the power source controller’s power consumption, calculating or determining the power source controller’s carbon footprint, support for mixed power input from multiple power sources, ability to store energy, minimum power to maintain operation, ability to compensate for unstable power sources, or ability to stabilize for power shortage.12.The method of claim 1, comprising:sending, by the power source controller to the radio unit, an indication of a change in power usage, wherein the radio unit sends to the RRU controller a report according to the indication.13.The method of claim 1, wherein the RRU controller sends a request to the radio unit to provide a report or update of the radio unit’s capabilities.14.The method of claim 1, comprising at least one of:combining, by the power source controller, power provided by at least two of the power sources, into a combined power output;combining, by the power source controller, the power provided by at least two of the power sources, according to at least one of: a communication from the RRC controller, or a power demand of the radio unit; orproviding, by the power source controller, the combined power output to the radio unit.15.The method of claim 1, wherein each of the power sources is associated with at least one tag or indication of at least one of: a sustainability level or carbon footprint, reliability, failure probability, recovery time from failure, stability of output voltage, stability of electric current, whether power storage is supported, capacity of the power storage, a maximum output power, or a maximum electric current.16.The method of claim 1, comprising maintaining or requesting, by the power source controller, a state of a first power source of the plurality of power sources, wherein the state comprises at least one of: active, ready, trusted, untrusted, unknown, partly active, or partly ready.17.A method, comprising:receiving, by a remote radio unit (RRU) controller from a power source controller, information,wherein the information is based on monitoring a plurality of power sources configured to provide power to a radio unit of a wireless communication node.18.A non-transitory computer readable storage medium storing instructions, which when executed by one or more processors can cause the one or more processors to perform the method of any one of claims 1-17.19.A device comprising at least one processor configured to implement the method of any one of claims 1-17.

Images