DYNAMICALLY TRANSFERRING CELL TRAFFIC TO REDUCE POWER CONSUMPTION

Abstract

Techniques for dynamically transferring cell traffic to reduce power consumption are disclosed. A method for dynamically transferring cell traffic to reduce power consumption begins by determining a load on radio units that service a geographic area. A determination is made that the load on a first radio unit fails to satisfy a reduce power threshold. A determination is made that the load on the first radio unit satisfies a transfer threshold. The load on the first radio unit is transferred to at least a second radio unit such that the first radio unit satisfies the reduce power threshold. Then, a component associated with the first radio unit to turn off is selected. The component is turned off, causing the first radio unit to enter a reduced-power state.

Description

BACKGROUND

Demand for mobile bandwidth continues to grow as customers access new services and applications. To remain competitive, telecommunications companies are cost-effectively expanding their networks while also improving user experience.

In some implementations of cellular networks, for example 5G cellular networks, the entirety of an antenna's structure (e.g., all network ports), along with certain reference signals and other components within resource blocks are used at all times to enhance transmission and reception capabilities.

BRIEF SUMMARY

In many cases, a particular geographic area will include overlapping coverage areas of multiple cells. Cells with overlapping coverage areas are commonly installed such that user devices in the geographic area may connect to one of several cells, increasing network availability. It is common practice to maintain each cell at full capacity, regardless of current utilization of the cells or bandwidth demand of connected user devices. For example, several cells having overlapping coverage areas in a geographic area may be maintained at full capacity despite having few or no connected user devices. Because cells may consume significant amounts of power even in no-load or low-load conditions, maintaining cells at full capacity regardless of cell traffic in the geographic area wastes substantial power. Furthermore, cells with overlapping coverage areas may be arbitrarily made available to service user device, such that several cells each service a small number of user devices. Thus, in some examples, none of the several cells may be turned off without degrading service to user devices, despite each cell having low utilization.

Embodiments are directed to dynamically transferring cell traffic to reduce power consumption. A load on radio units of cells that service a geographic area are determined. A determination is made that the load on a first radio unit fails to satisfy a reduce power threshold and satisfies a transfer threshold. For example, the first radio unit may be servicing too many user devices to enter a reduced-power mode without affecting service, but it may not be servicing enough user devices to represent an efficient use of power. The load is transferred to at least a second radio unit that services the geographic area such that the first radio unit satisfies the reduce power threshold. Then, a component associated with the first radio unit to turn off is selected and turned off, causing the first radio unit to enter the reduced-power mode.

In some embodiments, the second radio unit is selected based on the second radio unit satisfying a threshold to increase power. In some embodiments, the first radio unit and the second radio unit are at a same cell site. In some embodiments, the reduce power threshold is the radio unit having one connected user device. In some embodiments, a first portion of the load is transferred to the second radio unit, and a second portion of the load is transferred to another radio unit. Embodiments described herein dynamically transfer cell traffic away from relatively low utilization cells or cell components, and turn off, put into sleep mode, etc., those cells or components.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a high-level block diagram showing a 5G cellular network using vDUs and a vCU.

FIG. 2 is a diagram of radio frames within a cell according to some embodiments.

FIG. 3 is a diagram of several types of antennas within a cellular network according to some embodiments.

FIG. 4A is a diagram of an arrangement of several types of antennas within a cellular network connected to processing hardware according to some embodiments.

FIG. 4B illustrates a logical flow diagram showing one embodiment of a process for dynamically transferring traffic from a radio unit to enter a reduced-power state.

FIG. 4C illustrates a logical flow diagram showing one embodiment of a process for dynamically transferring cell traffic to a cell to enter an increased-power state.

FIG. 5 illustrates a high-level block diagram showing 5G cellular network with clusters.

FIG. 6 illustrates a block diagram of the system of FIG. 2 but further illustrating details of cluster configuration software, according to various embodiments.

FIG. 7 illustrates a method of establishing cellular communications using clusters.

FIG. 8 illustrates a block diagram of stretching the clusters from a public network to a private network, according to various embodiments.

FIG. 9 illustrates a method of establishing cellular communications using clusters stretched from a public network to a private network.

FIG. 10 illustrates a system with a centralized observability framework, according to various embodiments.

FIGS. 11 and 12 illustrate an overall architecture of an observability framework, according to various embodiments.

DETAILED DESCRIPTION

As shown in FIG. 1, a radio access network (RAN) includes a tower 101, radio unit (RU) (or remote radio unit (RRU)) 102, distributed unit (DU) (or virtualized distributed unit vDU, as shown) 103, central unit (CU) (or virtualized central unit vCU, as shown) 104, and an element management system (EMS) (not shown). FIG. 6 illustrates a system that delivers full RAN functionality using network functions virtualization (NFV) infrastructure. This approach decouples baseband functions from the underlying hardware and creates a software fabric. Within the solution architecture, virtualized baseband units (vBBU) process and dynamically allocate resources to remote radio units (RRUs) based on the current network needs. Baseband functions are split between central units (CUs) and distributed units (DUs) that can be deployed in aggregation centers or in central offices using a distributed architecture, such as using containerized applications (for example Kubernetes clusters) as discussed herein.

A cellular network often includes cell sites. A typical cell site includes a distributed unit (DU), a cell site router (CSR), one or more radio units (RUs), and one or more directional antennas having sectors that correspond to geographic coverage areas. One or more of these components may be implemented using containerized applications as described herein. The distributed unit is in communication with the cell site router, and the cell site router in turn communicates with one or more radio units. The one or more radio units communicate with one or more directional antennas. A user device may communicate with the cellular network via the one or more directional antennas.

A cell site comprises one or more cells. A cell is equipment used to service a geographic area, i.e. a sector. A cell may include equipment specific to the cell, such as an antenna, as well as equipment shared by one or more other cells, such as a cell site router, a distributed unit, or a radio unit. For example, a cell site having three antennas may include three cells despite having only one distributed unit and one cell site router.

FIG. 2 shows an exemplary system for transfer of data packets within an infrastructure for a carrier, such as a wireless communication carrier. In the leftmost column, a list of subcarrier numbers (e.g., 624 to 553, inclusive) for a 10 MHz system are provided. The numbers are not so limited, and may exist from, for example, 624 to 1, as up to 624 subcarriers with, for example, 15 kHz spacing, may occur in a 10 MHz system.

Along the top row is a list of integer symbols. As a nonlimiting example, each subframe may have fourteen symbols (numbered 0-13, inclusive) which will amount to a normal cycle. The frame may be, for example, a 1 millisecond frame, though again is not so limited.

When data is sent from one location to another, there is a granular level at which the data is sent. One is the time domain (the horizontal axis within each subframe, 0-13 inclusive), which repeats. This repeats for each subframe and 10 repetitions (e.g., 10 subframes) may, for example, be considered one radio frame. The radio frames, as a whole, are continuously transmitted by the radio unit (RU), described in more detail later.

At the intersections of respective symbols and subcarriers within a particular subframe is a resource element. For example, in FIG. 2, at subframe 1, the intersection of symbol 0 and subcarrier 624 is a physical downlink control channel, or PDCCH, resource element. Thus, in each subframe, there exist 14 resource elements in the time domain (horizontally) and 12 resource elements for each physical resource block (PRB) in the frequency domain. Again, this is not so limited, as other numbers of resource elements within the time and frequency domain may be possible.

When data is to be sent, it may be sent across one symbol versus 12 subcarriers, which will provide a minimum granularity. The data may be sent to a user, such as a user of user device, via broadcast (e.g., unicast or multicast).

The signal through the PDCCH is a physical downlink control channel. As shown in FIG. 2, the highlighted portions of columns 0 and 1 from subchannels 612-601 amount to physical downlink allocations within a certain resource block, described in more detail later. Though not shown, there could be a similar allocation for an uplink allocation in the same frame.

The PDCCH will carry the downlink control information which will tell what resources exist in the downlink for a particular user or users, so the user(s) (via his/her user device) can identify that the data packet belongs to the appropriate user.

Embedded within the resource elements, for example the downlink control information but also in any other resource element, may exist particular access information to ensure that the user's user device is able to access the data for a particular time period, and under certain authentication conditions. For example, the system may allow for an automated check as to the authentication characteristics of the user, whether the user has accessed the data at the accessible time, and so on. Such a configuration may be controlled using cloud control, such as using a distributed unit (DU) and/or central unit (CU) distributed within a cloud network. The RUs may transmit the resource elements, which can then be broadcast periodically, e.g., for a predetermined time, and/or may repeat every period.

As shown in FIGS. 3 and 4A, there are multiple radio units (RUs), or physical hardware on a tower, that connects to multiple antennas to transmit the data. The RUs each have multiple antenna ports. As in FIG. 4A, the RUs may be connected to a control and status register (CSR), which is connected to a DU.

Each RU in some embodiments has multiple antenna ports, for example, 4 antenna ports. These ports may provide information to the user device with respect to access to the data within the resource elements. Each antenna port is connected to its own amplifier to provide power to the antenna port. In some embodiments, the RUs described herein may be able to transmit and/or receive data at multiple frequencies.

In some embodiments, a configuration to reduce the number of antenna ports to turn on, thereby reducing power, may be achieved. Such a configuration may still allow access to the data for the user device, but the number of antenna ports on at a particular time may be dynamically adjusted to reduce power consumption, taking into consideration current or expected load conditions.

As an example, in a 4T4R (4 transmit 4 receive) antenna system, which is a default in a 5G wireless configuration, the power requirements are rather high. By having the system, for example a cloud-based system, periodically and/or continuously check load by observing usage of the network, it can be determined whether the system, and particularly even the RU and/or antenna within the system, is generally in a no load or a low load condition. The low load condition may be defined as a load below a predetermined amount, such as when only a small number of users are using a particular part of the network or when only a minimal amount of data is being transferred at the particular part of the network. Nevertheless, a low-load condition is a condition where a number of users, or an amount of data expected to be transmitted and/or received, is below a predetermined threshold. Similarly, a no-load condition is when there are no users or no data being transferred at a particular time, in a particular location within the wireless communications network.

In some embodiments, the number of antenna ports within the 4T4R antenna system can be dynamically changed based upon the load condition. For example, the 4T4R antenna system can be changed to a 2T2R (2 transmit 2 receive) antenna system, with two transmitting and two receiving antenna ports turned off, when the system determines that it, or a particular part of the system (e.g., a part of the system using the subject antenna system), has a lower load condition or a no load condition, or when the system determines, based upon historical data, that a low load or no load condition is expected to shortly occur and/or is occurring. Alternatively, the system may instruct to turn off only two transmitting antenna ports, resulting in a 2T4R antenna system, for example in a case where maximum data receiving capability is needed, for example at a time where it is expected that the antenna will need to receive significant amounts of data, such as during maintenance or at a time of expected high receiving volume.

The instruction to reduce the number of antenna ports may come from within the RU or a locally hosted processor such as the CSR of FIG. 4A, or from a cloud-hosted processor (e.g., within the DU or CU) that is connected (via the internet, fiber optical connection or otherwise) to the hardware of the antennas, RU and/or CSR. In any case, any processor of the RU, DU and CU may be utilized to observe, predict or otherwise assess current load and/or expected load or another predetermined variable, and, given the cooperation and communication between such processors, any one of such processors can instruct the antenna to turn off the required number of transmitting and/or receiving antenna ports in response to the load and/or predetermined variable being at a threshold amount. The predetermined variables may be, for example, number of users, resource block utilization, and others. This can be a dynamic action taking into consideration variables observed, predicted or otherwise assessed using any kind of logic, machine learning, or preprogrammed algorithms, and may be performed in real time or near real time. The processors may be locally hosted and connected only to specific aspects of the network, for example directly to antennas and/or RUs connected thereto, or may be part of a 5G cloud-based infrastructure, for example tied into the observability framework described later.

While the above describes reducing a number of antenna ports from a 4T4R antenna system to a 2T4R or 2T2R antenna system, in some cases, the reduction may be to a 3T3R, or 3T4R, or 4T3R system as well, though the number of ports will ideally be optimized to allow for transmission diversity and to allow for maximum transmission of data. In some embodiments, the reconfiguration can occur to an appropriate configuration taking into consideration MIMO (multiple input multiple output) and SISO (single input single output) requirements, as well as transfer diversity configuration based upon the set, recognized, or otherwise required load condition and thresholds.

FIG. 4A shows an example of a particular sector of the network (sector α) in a reduced-power state, having the reduced antenna ports, such as a 2T2R antenna port, 2T4R antenna port, or, in a bi-sector antenna with sector β turned off, a 2T2R bi-sector antenna.

By reducing the transmission and reception configuration of antenna ports dynamically based upon the assessment of a no or low load condition, there can be an advantageous significant power reduction given that two power amplifiers (at least) would be turned off while still providing a sufficient amount of data transmit/reception ability to current or potential users. That is, in some embodiments, the amount of antenna port reduction that occurs to preserve power is balanced by the need for a satisfactory user experience, where, for example, a certain number of users may desire parallel transmission of data (via multiple transmitting antenna ports) in order to reduce latency, improve speed, and the like. Nevertheless, when below a predetermined number of users exists at a particular time, or is expected at a particular time, a number of antenna ports can be deactivated to save power while minimizing the decrease in user experience, either because there are very users are using the antenna at particular time, or because the users that are using the antennas do not require the use of a 4T4R antenna system for the amount of data that needs to be transmitted or received.

Similar to how a reduced-power state may be entered, an increased-power state may be entered (e.g., turn deactivated ports back on) or otherwise take an action to improve data transmission/reception capability. This, again, may be a dynamic action taking into consideration variables observed, predicted and otherwise assessed using any of logic, machine learning, or preprogrammed algorithms, and can happen in real time or near real time.

In some embodiments, other variables may be considered such as variables relating to a number of RRC (radio resource control) connected user devices at a given time, or that may be expected at a given time based upon historical data. In such embodiments, the system may determine whether or not to turn off, or at least limit, supplemental downlink (SDL) ability. SDL is a configuration in which a frequency band is used for downlink-only traffic to support a conventional band running both uplink and downlink.

Such conventional bands with downlink and uplink may be, for example, FDD (frequency division duplexing) or TDD (time division duplexing), where a user may access, ask questions (provide data inputs) and receive a response (data output). These are mandatory channels, so as to allow communication happening from both the user side and the radio side.

An RRC connected user (connected user) is a user that uses (via a user device) radio resource control connection. That is, once a user sees the cell, it is identified, and an action can be taken that requires additional data. The RRC is a control mechanism that can allow for data exchange can occur via dynamic configuration changes in order to allow for optional configuration at the time of communication.

When an SDL configuration is used, faster downloads may be achieved and a relatively larger number of users with mobile devices may be supported. This may be in a situation where, for example, additional downlink data is needed to be sent from the RU to the user (via the user device), and the SDL channels can thus be used by transmitting through the radio unit.

In some examples, if there are no users detected in the subject location, for example, a primary cell, the SDL will be requiring power given that its providing antenna ports are active and powered by their respective amplifiers, even though the SDL is not necessary, or is providing limited utility. That is, when there are no RRC users in the primary cell, the system may instruct, using the processors described herein, the antennas controlling the SDL to turn off all four of the antenna ports in the SDL, or at least some of the antenna ports in the SDL. Similarly, once an RRC connected user device has arrived in the primary cell, the system, via the processors, can turn on some, or all, of the antenna ports powering the SDL. For example, based upon data requirements from the requests of the RRC connected user device, the system may choose to increase from 0 to 2 ports, or 2 to 4 ports, saving power as much as possible while still allowing the RRC connected user device to transmit and/or receive data.

In some embodiments, the system, via the processors described heretofore, can allow for transmission periodicity increases of SSB (Synchronization Signal Block) transmission in response to certain variables. Referring back to FIG. 2, signals are transmitted in the downlink across radio frames 200 (e.g., moving horizontally from one radio frame 200 to another, not shown). The radio frames include multiple subframes 200a, each separated by some time, for example 1 ms, with, for example, 10 subframes 200a (10 ms separation) for each radio frame 200. However, the number of subframes and time spacing between each subframe described above is only exemplary and is not so limited.

Along the left column are physical resource blocks 220 identifying subcarriers. These resource blocks are allocated to a user based upon usage requirements (e.g., data demand). For example, one user may require only 10 Kbps and be allocated only some resource blocks as shown in FIG. 2, while others may require 20 Kbps and may require more resource blocks. Shaded along the left are physical downlink control channels (PDCCH) 201. These PDCCHs 201 are where control information is available, for example information about which radio frame the user needs to read and in which resource block to read.

A static allocation of these PDCCHs and generally of control resources may occur. For example, when more users are present, they can be allocated to a particular subframe. For example, the resources may be allocated where they serve two users, or perhaps even 4, or 6, or 10 or more, every subframe, based upon available bandwidth. The PDCCHs may be provided with two symbols 201a, 201b as shown in FIG. 2.

Since it is a static allocation, the PDCCH may be initially set to have two symbols. In some embodiments, the number of symbols is dynamically changed based upon need, thereby allowing for power reduction. This may again utilize the processors described above. For example, power may be saved on uplink because the user will not need to read all the symbols when they are broadcast. The user thus only needs to read one symbol. Once the symbol is fully utilized, the system, via the processors, may dynamically change to turn back on the second symbol. This can also save power even in the RU because transmission in two symbols is not required, as it can be transferred in only one symbol until that symbol is fully utilized.

Further, the PDCCHs can be transmitted in all four antenna ports (e.g., 4T), or even in 2 antenna ports (2T), or even with just one transmitting antenna port (1T). Transmitting in 1T may further save power during download.

While PDCCH signals are described above, other signals can similarly be transmitted through 2T or 1T when requirements are below a particular threshold.

Referring again to FIG. 2, numbers 8, 9, 10 and 11 of subframe 2 are grouped as unit 230. Moving vertically down the resource blocks 220, eventually additional signals, particularly synchronization signal blocks (SSB) 235, are provided. These SSB 235 are the first signal that the user (via user device) will read from the base station, and may be comprised of a primary synchronization signal 235a and a secondary synchronization signal 235b. The user (via the user device) will look for these signals and determine whether the blocks are accessible. In some situations, the SSB may not be accessible directly, but by a roaming partner or the like.

The SSB 235 may indicate broadcast information to that the next adjacent blocks 236, which may be system information blocks (SIB), and ultimately to a master information block (MIB) 237. In some embodiments, this data is transmitted through just one antenna port even when there are two antenna ports active. Accordingly, the processors can dynamically change a number of ports for PDCCH, SSB, and SIB broadcast based upon efficient power utilization, given that the user device can efficiently determine which ports to search. This can again be particularly useful in a low load situation where coverage does not need to be enhanced. Further, interference can be reduced by having less antenna ports open during this data transmission, thus allowing for an additional advantage. Transmitting PDCCH and SSB and SIB information on relatively fewer antenna ports will improve power saving and avoid interference.

Additionally, the SDL cell, which may be a coverage cell provided by the antenna connected to an RU, may not necessarily need SIB transmission. Thus, there can be dynamical turning off of SIB information in the supplemental downlink, to avoid having to transmit SIB1 to SDL cells when it would otherwise be of no use.

Additionally or alternatively, transmission of the SSB 235 may be transmitted with a particular periodicity, such as 5 ms, 10 ms, up to 160 ms. In the primary cell, there may be a periodicity of 20 ms which may be required in a regular primary cell. That is, every 20 ms there is a transmission. But under certain situations, such as no load or low load conditions and/or a lack of RDC connected user devices or the like, the periodicity of the SSB transmission for the SDL cell may be reduced (e.g., from 20 ms to 40 ms, or to even 80 ms or 160 ms or the like), which may provide yet another avenue for power saving.

In some examples, in a no user condition, the SDL may be turned off entirely, while in a low user condition, the SDL may be turned on, with an increased periodicity. Further, even when the periodicity is increased, certain symbols may still be available for data transmission, which can allow for increased capacity while still lowering power requirements.

In some embodiments, either in addition to or instead of changing characteristics of the SDL, the primary cell bandwidth can also be changed dynamically, by the same processor discussed above, in response to no or low load conditions. Referring back to FIG. 2, there may exist hundreds or even thousands of subcarriers. By dynamically changing bandwidth, for example, from 15 MHz to 5 Mhz, power saving may occur without negatively affecting usage.

In some embodiments, when a cell does not have an RRC connected user device, further actions can be taken to minimize power output. For example, three exists a channel state information reference signal (CSIRS) transmission that is typically turned on based on the static CSI Measurement set up configuration in all physical resource blocks across an entire channel bandwidth (e.g., 5 MHz, 10 MHz, 15 MHz, and so on up to 100 MHz in a first frequency). However, this may not be necessary in order to still achieve acceptable functionality. A CSIRS may be particularly useful to report channel quality information in uplink, which is particularly desirable when an RRC connected user device is present, in order for the base station (e.g., gnodeB) to allocate resource blocks to appropriate users.

Referring again to FIG. 2, a determination of where signals are located can be made by finding tracking reference signals (TRS) 240. A TRS may be desirable to aid in tracking when a connected (RRC connected) user is having difficulty taking an action such as transmitting or receiving data. The channel state information reference signals (CSIRS) 241, with the TRS and CSIRS available across various reference blocks. However, in a state where there are no, or limited (e.g., below a predetermined threshold) RRC connected user devices within a specific point in the system, such as within a primary cell or within a frame or within some other cell or portion of the cellular network, one or both of the TRS 240 and CSIRS 241 can be turned off. This may be executed by the processors described above.

This may achieve further power saving while still having an optimized network where when RRC connected user devices join the requisite cells or other predetermined locations, the TRS and/or CSIRS can be dynamically turned on in order to allow for the appropriate measuring and/or tracking afforded by such reference signals.

Additionally or alternatively, in a state where there are no, or limited (e.g., below a predetermined threshold) RRC connected user devices within a specific point in the system, such as within a primary cell or within a frame or within some other cell or portion of the cellular network, the CSIRS and/or TRS configuration can be scaled down by increasing the periodicity thereof. It can also be scaled up when a predetermined number of RRC connected user devices enter the point.

Further, a number of resource blocks can be dynamically changed in response to a number of RRC connected user devices, which can affect a bandwidth change for the CSIRS. Similarly, this can occur to affect a bandwidth change for the TRS.

While embodiments discussed above describe various techniques for reducing power consumption in response to detecting a no-load or low-load state, the disclosure is not so limited. FIGS. 4B and 4C illustrate processes 400b and 400c, respectively, which are used to transfer cell traffic away from low-utilization cells or components thereof, so the cell components may be entered into a reduced-power state to reduce power consumption. Generally, the term “low-utilization” refers to utilization such as 1%, 5%, 10%, etc., or a number of serviced user devices such as 1, 5, 10, etc., such that a low-utilization cell or component thereof may not be turned off without degrading service to connected user devices. In other words, a low utilization cell or component thereof that does not satisfy a first threshold to enter a reduced-power state may nonetheless satisfy a transfer threshold for traffic to be transferred away from it, thereby placing it into a no-load or low-load state where power may be reduced.

Generally, the terms “no-load” or “low-load” indicate that a cell or component thereof satisfies a reduce-power threshold, meaning it may be entered into a reduced-power state without degrading service to connected user devices, or degrading the service less than a configurable service degradation threshold such as dropping 1, 5, 10, etc. connected user devices, or reducing bandwidth available to the connected user devices by less than 20%, 50%, etc.

As discussed herein, various components of a cell may be entered into reduced-power states in low-load or no-load scenarios. The processes 400b and 400c are generally directed to consolidating traffic away from low-utilization cell components to high-utilization cell components, and turning off components of the cells from which traffic is transferred away to reduce power consumption.

FIG. 4B illustrates a logical flow diagram showing one embodiment of a process 400b for dynamically handing off connected user devices to reduce power consumption.

Process 400b begins, after a start block, at block 402, where a load on each radio unit that services a geographic area is determined. In some embodiments, the geographic area is selected based on a count of radio units capable of servicing the geographic area. For example, the geographic area may be selected such that at least 2, 5, 10, etc., radio units service the geographic area. This may indicate that there is a possibility of reducing power consumption by migrating user device connections away from a first radio unit to a second radio unit such that components of the first radio unit may be turned off. In contrast, there may be less or no possibility of migrating user device connections and turning off radio unit components in a geographic area served by only one radio unit.

In some embodiments, determining the load on each radio unit includes obtaining a number of user devices serviced by the radio unit, a utilization of the radio unit, various information relating to the radio unit, etc. After block 402, process 400b continues to block 404.

At block 404, it is determined that the load on a first radio unit of the plurality of radio units fails to satisfy a first threshold to enter a reduced-power state (the “reduce power threshold”). In other words, the first radio unit is not in a low-load or no-load state, and reducing power to one of its components would impact service to connected user devices.

The reduce power threshold in various embodiments indicates that a component of the first radio unit may enter a reduced-power state without impacting service of a connected user device. For example, the first threshold may be that no user devices are being serviced by the first radio unit. Accordingly, the first radio unit may be entered into a reduced-power state without degrading service to a connected user device. In some embodiments, the reduce power threshold may be configured to allow some degradation of service to connected user devices. For example, the reduce power threshold may be 1%, 5%, or 10% utilization of the first radio unit, such that the radio unit may enter a reduced-power state despite interrupting service to a relatively small amount of traffic.

In some embodiments, the reduce power threshold is based on a count of connected user devices of the radio unit such as 0, 1, 10, etc. In some such embodiments, the reduce power threshold is satisfied when a number of connected user devices is below the selected count of connected user devices. For example, the reduce power threshold may be configured to trigger a reduced-power state when the radio unit is only servicing a few connected user devices. In some embodiments, the reduce power threshold is a percentage of the average load on the component over a period of time such as a day, week, month, etc. The reduce power threshold may be based on a number of other radio units that service at least a portion of the geographic area serviced by the radio unit. For example, the reduce power threshold may be higher when there are more radio units available to service connected user devices, and lower when there are fewer radio units available to service connected user devices. In some embodiments, the reduce power threshold is set by an administrator.

At block 406, a determination is made that the load of the first radio unit satisfies a second threshold to transfer load (the “transfer threshold”). In general, the transfer threshold is used to identify radio units that are too loaded to be put into a reduced-power state, but are not being efficiently utilized. The transfer threshold may be satisfied, for example, by a radio unit consuming thousands of kilowatts of electricity to service a small number of connected user devices, or by a radio unit servicing a geographic area that is serviced by other radio units having low utilization. Accordingly, the transfer threshold may be based on various metrics. Note that a radio unit may fail to satisfy the reduce power threshold but satisfy the transfer threshold, such as when the radio unit is servicing a small number of connected user devices.

Often, a user device is in a geographic area that is serviced by multiple radio units. Thus, any one of the multiple radio units may be capable of servicing the user device. In some embodiments, the transfer threshold is based on a utilization of one or more radio units capable of servicing a connected user device of the first radio unit. The transfer threshold is dynamic and may change over time in response to various conditions. For example, when an average utilization of radio units capable of servicing the connected user device is 75%, the transfer threshold may be 75% or a fraction thereof, indicating that the first radio unit is relatively underutilized compared to other radio units capable of servicing the connected user device. Thus, satisfaction of the transfer threshold does not necessarily indicate that the first radio unit has low utilization in absolute terms. The transfer threshold may be 5%, 10%, or 50% utilization, for example, such that the transfer threshold is satisfied if the utilization of the first radio unit is below the specified utilization.

In some embodiments, the transfer threshold is based on the number of radio units capable of servicing user devices of the first radio unit. If only one radio unit may service the user devices, the transfer threshold may be configured to allow the radio unit to have low utilization, such as 1%, 5% or 10% utilization because the first radio unit cannot transfer the user device connection to another radio unit. But if many radio units may service the user device, the transfer threshold may disallow even moderate utilization such as 25%, 50% or 60%, because the first radio unit may transfer the user device connection to the other radio units and shut down one or more of its components.

In some embodiments, the transfer threshold is based on a capacity of a radio unit. For example, a low-capacity radio unit servicing ten connected user devices may be fully utilized, while a high-capacity radio unit servicing one hundred connected user devices may be underutilized.

In some embodiments, the transfer threshold is based on a time of day, week, month, year, or another time. For example, the first radio unit may experience low utilization at a particular time such as at night. Accordingly, the transfer threshold may based on a time of day. In various embodiments, any previous data regarding the first radio unit may be used to anticipate periods of low utilization and set the transfer threshold such that the first radio unit satisfies the transfer threshold in response to the anticipated periods of low utilization.

In various embodiments, the transfer threshold is an expense of servicing a connected user device by the first radio unit. For example, the transfer threshold may be a power cost currently expended per connected user device, such as 10 watts per connection, 100 watts per connection, 1000 watts per connection, etc. In an example, the first radio unit may currently be consuming 5,000 watts of electricity and be servicing two connected user devices. Thus, the first radio unit is consuming 2,500 watts of electricity per connected user device. This metric is then compared to the reduce power threshold to determine if the first radio unit is to be entered into a reduced-power state. In some embodiments, the transfer threshold is satisfied if the power expended per user device is above the specified power consumption.

In some embodiments, the transfer threshold is a monetary cost of electricity expended per connected user device, such as greater than $0.20 per hour. For example, if a cost of delivering electricity to the first radio unit is $0.15 per kilowatt-hour, the first radio unit consuming 2.5 kilowatts of electricity per connected user device consumes $0.38 of electricity per connected user device per hour. Thus, the first radio unit satisfies the transfer threshold of $0.20 per hour. In various embodiments, other fixed expenses, operating expenses, or a combination thereof may be considered in calculating the expense of servicing a connected user device.

In various embodiments, the expense of servicing the connected user device by the first radio unit may be determined over any suitable time period. For example, a cost per second, minute, day, week, etc., may be used. The expense may also be an averaged of expense over the time period, a maximum expense over the time period, etc.

In some embodiments, an expense of servicing a first connection with a user device may be different than an expense of servicing a second connection. For example, a first connection may consume 1,000 watts while a second connection consumes 10 watts. Therefore, the expense per connection may represent a mean, median, mode, percentile value, standard deviation, etc., of an expense of servicing each connection that is serviced by the first radio unit. In general, the expense of servicing the connection may be based on any statistical measure of one or more expenses associated with the first radio unit. After block 406, process 400b continues to block 408.

At block 408, the load of the first radio unit is transferred from the first radio unit to at least a second radio unit so that the first radio unit satisfies the reduce power threshold. In some embodiments, the second radio unit to which to transfer the load is selected based on utilization information for the radio units that service the geographic area. The second radio unit may be selected to have a highest utilization among the radio units that service the geographic area that is also capable of receiving all or a configurable portion of the first radio unit's load. For example, if the first radio unit has 15% utilization and the other radio units servicing the geographic have utilizations of 20%, 50%, and 90%, the radio unit having 50% utilization may be selected. Thus, the overall load of radio units servicing the geographic area is consolidated to a small number of highly-utilized radio units so that power to other radio units or components thereof may be reduced.

In various embodiments, the utilization information includes a measure of bandwidth, processing capability, a number of connected user devices currently serviced, or other characteristic of the radio unit. As described herein, consolidation of connected user devices from low-utilization radio units to high-utilization radio units is often desirable. In some embodiments, connected user devices are to be handed off to radio units having relatively high utilization. Accordingly, the second radio unit may be selected to satisfy a handoff threshold such as the increase power threshold discussed with respect to FIG. 4C.

The radio unit selected as the second radio unit typically has sufficient bandwidth capable of servicing the load to be transferred to it. For example, a radio unit having 100% utilization is incapable of servicing additional load and is in some embodiments not selected as the second radio unit. In various embodiments, the second radio unit is selected from the radio units that service the geographic area having utilization between a lower utilization threshold such as 50% and an upper utilization threshold such as 90%. In some embodiments, the lower handoff threshold, the upper handoff threshold, or both, are dynamically determined based on the radio unit utilization, the load to be transferred, or a combination thereof.

The utilization information of the second radio unit may include a median, mean, mode, or other metric of the utilization. Furthermore, the utilization information may be weighted based on how quickly the utilization changes. For example, if the utilization changes quickly, unpredictably, a large amount, or a combination thereof, the utilization information may reflect such characteristics. This may prevent the transfer of load from the first radio unit to a second radio unit that may be subject to large changes in utilization that may render it overutilized.

In some embodiments, the load of the first radio unit is transferred entirely to the second radio unit. For example, assuming that the first radio unit and the second radio unit have a same capacity, if the load of the first radio unit incurs a utilization of 5% and the second radio unit has a utilization of 10%, the entire load of the first radio unit may be transferred to the second radio unit. In some embodiments, a portion of the load of the first radio unit is transferred to one or more radio units besides the second radio unit.

The load of the first radio unit to transfer to the second radio unit is typically determined based on a sector overlap between the first radio unit and the second radio unit. For example, the second radio unit cannot service user devices that are outside of its sectors and such user device connections are typically not transferred to the second radio unit.

In some embodiments, the first radio unit and the second radio unit are different radio units but located at the same cell site. In some embodiments, the first radio unit and the second radio unit are different radio units located at separate and distinct cell sites. After block 408, process 400b continues to block 410.

At block 410, in response to the first radio unit satisfying the first or reduce power threshold, a component associated with the first radio unit is selected to enter into a reduced-power state. In some embodiments, the selected component is the first radio unit. In some such embodiments, one or more ports, processors, power supplies, etc. of the first radio unit may be the selected component. In some embodiments, the selected components is an antenna power amplifier associated with the first radio unit. After block 410, process 400b continues to block 412.

At block 412, the selected component is turned off, causing the first radio unit to enter the reduced-power state. In some embodiments, the reduced-power state includes an antenna power amplifier associated with the first radio unit being turned off. In some embodiments, the reduced-power state includes turning the first radio unit off, putting the first radio unit into standby mode, putting the first radio unit into sleep mode, etc. In some embodiments, the reduced-power state includes reducing a clock rate or power limit of a processor or other component associated with the first radio unit. In some embodiments, the reduced-power state includes changing a power state of a component associated with the first radio unit. In various embodiments, the first radio unit may be entered into any reduced-power state as discussed herein. After block 412, process 400b ends at an end block.

While process 400b is discussed in terms of radio units, the disclosure is not so limited. In various embodiments, process 400b may be applied to cells, such that loads are transferred between cells so cells or components thereof may be entered into reduced-power states.

FIG. 4C illustrates a logical flow diagram showing one embodiment of process 400c for dynamically transferring connected user devices between radio units to cause a radio unit to enter an increased-power state. As discussed herein, consolidation of connected users into a relatively small number of highly utilized cells allows for other cells to enter reduced-power states, saving power. While such consolidation of connected user devices may be achieved by identifying a cell to enter a reduced-power state as discussed with respect to FIG. 4B, it may also be achieved by identifying a cell to enter an increased-power state as described herein. Additionally, embodiments of process 400c may be utilized to enter a cell previously entered into a reduced-power state into an increased-power state. For example, embodiments of process 400c may be used to reestablish a cell in a reduced-power state that is not currently operating at full capacity.

Process 400c begins, after a start block, at block 422, where a determination is made that a first radio satisfies a transfer threshold. The transfer threshold may be as described with respect to FIG. 4B. For example, satisfaction of the transfer threshold may indicate that traffic is to be transferred away from the first radio unit such that the first radio unit enters a low-load or no-load state and power to the first radio unit may be reduced. In some embodiments, the transfer threshold indicates the radio unit is experiencing excess load. The transfer threshold may include a maximum utilization for the first radio unit such as 90%, 95%, or 100%. Thus, satisfaction of the transfer threshold may indicate that the first radio unit is experiencing excess load that is to be transferred away from the first radio unit. The transfer threshold is typically configured such that the first radio unit may transfer load to other radio units without significant degradation of service to connected user devices.

In some embodiments, the transfer threshold is based on a number of requests from user devices to connect to the first radio unit in a specified period of time. For example, if the first radio unit detects that 1, 5, 10, etc. user devices attempt to connect to it but are rejected due to insufficient capacity, the first radio unit may be determined to satisfy the transfer threshold.

At block 424, candidate radio units capable of receiving a connected user device from the first radio unit are identified. In various embodiments, each of the candidate radio units and the first radio unit service overlapping geographic areas. In some embodiments, a sector of each of the identified candidate radio units overlaps with a sector of the first radio unit. The identified candidate radio units may be in reduced-power states, in full power states, or a combination thereof. After block 424, process 400c continues to block 426.

At block 426, utilization information is obtained for the candidate radio units not in a reduced-power state. In some embodiments, the utilization information is a throughput of the radio unit. For example, the utilization information may include a throughput of the radio unit, a throughput of an antenna port of the radio unit, etc. In some embodiments, the utilization information is based on a transmit radio unit load, a receive radio unit load, or a combination thereof.

In various embodiments, the utilization information includes a variability of utilization of the radio unit over a select time period. For example, if in the last second, minute, hour, day, etc., the utilization varies between 0 gigabits per second and 10 gigabits per second, the utilization may be determined to have high utilization variability. After block 426, process 400c continues to block 428.

At block 428, if utilization of all candidate radio units not in a reduced-power state are above an upper utilization threshold, the second radio unit is selected from candidate radio units in a reduced-power state. Satisfying the upper utilization threshold generally indicates that a candidate radio unit is unavailable to receive traffic from the first radio unit. In some embodiments, if all available candidate radio units that are not in reduced-power states satisfy the upper utilization threshold, capacity of the network is increased by removing a second radio unit in the candidate radio units from a reduced-power state.

The upper utilization threshold may be based on a utilization of a radio unit such as 80%, 90%, or 100%, a number of faults or errors produced by the radio unit in a selected time period, an average latency of communications from the radio unit, etc. As described herein, consolidation of connected user devices from low-utilization radio units to high-utilization radio units is often desirable. In some embodiments, the second radio unit is selected to have relatively high utilization such as 50% utilization. In some embodiments, the second radio unit is selected such that all connected user devices of the first radio unit may be transferred to the second radio unit. For example, the second radio unit may be selected such that each user device connected to the first radio unit is also in a sector associated of the second radio unit. In various embodiments, the second radio unit may be selected based on any aspect of utilization information described herein.

At block 430, the second radio unit is caused to enter an increased-power state. In some embodiments, the increased-power state includes turning the radio unit on, taking the radio unit or components thereof out of standby mode, etc. In some embodiments, the increased-power state includes increasing a clock rate or power limit of a processor or other component associated with the second radio unit. In various embodiments, entering the second radio unit into the increased-power state includes turning on or increasing power to a component associated with the second radio unit such as a radio unit antenna port, an antenna power amplifier, etc. After block 430, process 400c continues to block 432.

At block 432, the connected user device is handed off from the first radio unit to the second radio unit. In some embodiments where the first radio unit satisfies a threshold to reduce power, the second radio unit is entered into a reduced-power state. In various embodiments, entering the first radio unit into the reduced-power state includes turning off or reducing power to a component associated with the first radio unit such as a radio unit antenna port, an antenna power amplifier, etc. In various embodiments, block 432 employs embodiments of block 412 of FIG. 4B to enter the second radio unit into the reduced-power state. In various embodiments, the reduced-power state is any reduced-power state described herein. After block 432, process 400c ends at an end block.

While the discussion above describes process 400c with respect to radio units, in various embodiments process 400c is performed with respect to cells or other cell components. By handing off traffic between cells, increased power saving may be achieved because entire cells may be turned off. For example, if a first cell is determined to satisfy the transfer threshold, connected user devices of the first cell are handed off to the second cell. In response to the handoff, the first cell may enter a reduced-power state. Thus, load may be consolidated between cells. This may be used to improve overall power efficiency of the network and allows cells in reduced-power states to be reactivated when the network experiences increased traffic.

As discussed herein, various components of a cell such as the central unit or the distributed unit may be implemented using containerized applications. This may provide benefits such as autoscaling, reducing hardware components that are located at a cell site, and improving serviceability and resiliency of the cell. Implementing components of the cell using containerized applications provides further flexibility for reducing power consumption of the cell, as containerized application capacity may be easily reduced in low-load or no-load scenarios.

The containerized application can be any containerized application but is described herein as Kubernetes clusters for ease of illustration, but it should be understood that the present invention should not be limited to Kubernetes clusters and any containerized applications could instead be employed. In other words, the below description uses Kubernetes clusters and exemplary embodiments but the present invention should not be limited to Kubernetes clusters.

The dynamic determinations described above can occur within a cellular network using Kubernetes clusters. As such, various embodiments provide running Kubernetes clusters along with a radio access network (“RAN”) to coordinate workloads in the cellular network, such as a 5G cellular network. Broadly speaking, embodiments of the present invention provide methods, apparatuses and computer implemented systems for providing data for observability on a 5G cellular network using servers at cell sites, cell towers and Kubernetes clusters that stretch from a public network to a private network.

A Kubernetes cluster may be part of a set of nodes that run containerized applications. Containerizing applications is an operating system-level virtualization method used to deploy and run distributed applications without launching an entire virtual machine (VM) for each application.

Cluster configuration software is available at a cluster configuration server. This guides a user, such as a system administrator, through a series of software modules for configuring hosts of a cluster by defining features and matching hosts with requirements of features so as to enable usage of the features in the cluster. The software automatically mines available hosts, matches host with features requirements, and selects the hosts based on host-feature compatibility. The selected hosts are configured with appropriate cluster settings defined in a configuration template to be part of the cluster. The resulting cluster configuration provides an optimal cluster of hosts that are all compatible with one another and allows usage of various features. Additional benefits can be realized based on the following detailed description.

The present application uses such containerized applications (e.g., Kubernetes clusters) to deploy a RAN so that the vDU of the RAN is located at one Kubernetes cluster and the vCU is located at a remote location from the vDU. This configuration allows for a more stable and flexible configuration for the RAN.

Virtualized CUs and DUs (vCUs and vDUs) run as virtual network functions (VNFs) within the NFV infrastructure. The entire software stack that is needed is provided for NFV, including open-source software. This software stack and distributed architecture increases interoperability, reliability, performance, manageability, and security across the NFV environment.

RAN standards require deterministic, low-latency, and low-jitter signal processing. These may be achieved using containerized applications (e.g., Kubernetes clusters) to control each RAN. Moreover, the RAN may support different network topologies, allowing the system to choose the location and connectivity of all network components. Thus, the system allowing various DUs on containerized applications (e.g. Kubernetes clusters) allows the network to pool resources across multiple cell sites, scale capacity based on conditions, and ease support and maintenance requirements.

FIG. 5 illustrates an exemplary system used in constructing clusters that allows a network to control cell sites, in one embodiment of the invention. The system includes a cluster configuration server that can be used by a cell site to provide various containers for processing of various functions. Each of the cell sites are accessed via at least one cellular tower (and RRU) by the client devices, which may be any computing device which has cellular capabilities, such as a mobile phone, computer or other computing device.

As shown, the system includes an automation platform (AP) module 501, a remote data center (RDC) 502, one or more local data centers (LDC) 504, and one or more cell sites 506.

The cell sites provide cellular service to the client devices through the use of a vDU 509, server 508, and a cell tower 101. The server 508 at a cell site 506 controls the vDU 509 located at the cell site 506, which in turn controls communications from the cell tower 101. Each vDU 509 is software to control the communications with the cell towers 507, RRUs, and CU so that communications from client devices can communicate from one cell tower 507 through the clusters (e.g. Kubernetes clusters) to another cell tower 707. In other words, the voice and data from a cellular mobile client device connects to the towers and then goes through the vDU to transmit such voice and data to another vDU to output such voice and data to another tower 507.

The server(s) on each individual cell site 506 or LDC 504 may not have enough computing power to run a control plane that supports the functions in the mobile telecommunications system to establish and maintain the user plane. As such, the control plane is then run in a location that is remote from the cell sites 506, such as the RDC.

The RDC 502 is the management cluster which manages the LDC 504 and a plurality of cell sites 506. As mentioned above, the control plane may be deployed in the RDC 502. The control plane maintains the logic and workloads in the cell sites from the RDC 502 while each of the containerized applications (e.g., Kubernetes containers) is deployed at the cell sites 506. The control plane also monitors the workloads to ensure they are running properly and efficiently in the cell sites 506 and fixes any workload failures. If the control plane determines that a workload fails at the cell site 506, for example, the control plane redeploys the workload on the cell site 506.

The RDC 502 may include a master 512 (e.g., a Kubernetes master or Kubernetes master module), a management module 514 and a virtual (or virtualization) module 516. The master module 512 monitors and controls the workers 510 (also referred to herein as Kubernetes workers, though workers of any containerized applications are within the scope of this feature) and the applications running thereon, such as the vDUs 509. If a vDU 509 fails, the master module 512 recognizes this, and will redeploy the vDU 509 automatically. In this regard, the Kubernetes clusters system has intelligence to maintain the configuration, architecture and stability of the applications running. As such, the Kubernetes clusters system may be considered to be “self-healing”.

The management module 514 along with the Automation Platform 501 creates the Kubernetes clusters in the LDCs 504 and cell sites 506.

For each of the servers 508 in the LDC 504 and the cell sites 506, an operating system is loaded in order to run the workers 510. For example, such software could be ESKi and Photon OS. The vDUs are also software, as mentioned above, that runs on the workers 510. In this regard, the software layers are the operating system, and then the workers 510, and then the vDUs 509.

The automation platform module 501 includes a graphical user interface (GUI) that allows a user to initiate clusters. The automation platform module 501 communicates with the management module 514 so that the management module 514 creates the clusters and a master module 512 for each cluster.

Prior to creating each of the clusters, the virtualization module 516 creates a virtual machine (VM) so that the clusters can be created. VMs and containers are integral parts of the containerized applications (e.g., Kubernetes clusters) infrastructure of data centers and cell sites. VMs are emulations of particular computer systems that operate based on the functions and computer architecture of real or hypothetical computers. A VM is equipped with a full server hardware stack that has been virtualized. Thus, a VM includes virtualized network adapters, virtualized storage, a virtualized central processing unit (CPU), and a virtualized BIOS. Since VMs include a full hardware stack, each VM requires a complete operating system (OS) to function, and VM instantiation thus requires booting a full OS.

In addition to VMs, which provide abstraction at the physical hardware level (e.g., by virtualizing the entire server hardware stack), containers are created on top of the VMs. Containers Application presentation systems create a segmented user space for each instance of an application. Applications may be used, for example, to deploy an office suite to dozens or thousands of remote workers. In doing so, these applications create sandboxed user spaces on a server for each connected user device. While each user shares the same operating system instance including kernel, network connection, and base file system, each instance of the office suite has a separate user space.

In any event, once the VMs and containers are created, the master modules 512 then create a vDU 509 for each VM.

The LDC 504 is a data center that can support multiple servers and multiple towers for cellular communications. The LDC 504 is similar to the cell sites 506 except that each LDC has multiple servers 508 and multiple towers 101. Each server in the LDC 504 (as compared with the server in each cell site 506) may support multiple towers. The server 508 in the LDC may be different from the server 508 in the cell site 506 because the servers 508 in the LDC are larger in memory and processing power (number of cores, etc.) relative to the servers in the individual cell sites 506. In this regard, each server 508 in the LDC may run multiple vDUs (e.g., 2), where each of these vDUs independently operates a cell tower 707. Thus, multiple towers 101 can be operated through the LDCs 504 using multiple vDUs using the clusters. The LDCs 504 may be placed in bigger metropolitan areas whereas individual cell sites 506 may be placed at smaller population areas.

FIG. 6 illustrates a block diagram of the system of FIG. 5, while further illustrating details of cluster configuration software, according to various embodiments.

As illustrated, a cluster management server 600 is configured to run the cluster configuration software 610. The cluster configuration software 610 runs using computing resources of the cluster management server 600. The cluster management server 600 is configured to access a cluster configuration database 620. In one embodiment, the cluster configuration database 620 includes a host list with data related to a plurality of hosts 630 including information associated with hosts, such as host capabilities. For instance, the host data may include list of hosts 630 accessed and managed by the cluster management server 600, and for each host 630, a list of resources defining the respective host's capabilities. Alternately, the host data may include a list of every host in the entire virtual environment and the corresponding resources or may include only the hosts that are currently part of an existing cluster and the corresponding resources. In an alternate embodiment, the host list is maintained on a server that manages the entire virtual environment and is made available to the cluster management server 600.

In addition to the data related to hosts 630, the cluster configuration database 620 includes features list with data related to one or more features including a list of features and information associated with each of the features. The information related to the features include license information corresponding to each feature for which rights have been obtained for the hosts, and a list of requirements associated with each feature. The list of features may include, for example and without limitations, live migration, high availability, fault tolerance, distributed resource scheduling, etc. The list of requirements associated with each feature may include, for example, host name, networking and storage requirements. Information associated with features and hosts are obtained during installation procedure of respective components prior to receiving a request for forming a cluster.

Each host is associated with a local storage and is configured to support the corresponding containers running on the host. Thus, the host data may also include details of containers that are configured to be accessed and managed by each of the hosts 830. The cluster management server 800 is also configured to access one or more shared storage and one or more shared network.

The cluster configuration software 610 includes one or more modules to identify hosts and features and manage host-feature compatibility during cluster configuration. The configuration software 610 includes a compatibility module 612 that retrieves a host list and a features list from the configuration database 620 when a request for cluster construction is received from the client. The compatibility module 612 checks for host-feature compatibility by executing a compatibility analysis which matches the feature requirements in the features list with the hosts capabilities from the host list and determines if sufficient compatibility exists for the hosts in the host list with the advanced features in the features list to enable a cluster to be configured that can utilize the advanced features. Some of the compatibilities that may be matched include hardware, software and licenses.

It should be noted that the aforementioned list of compatibilities are exemplary and should not be construed to be limiting. For instance, for a particular advanced feature, such as fault tolerance, the compatibility module checks whether the hosts provide a compatible processor family, host operating system, Hardware Virtualization enabled in the BIOS, and so forth, and whether appropriate licenses have been obtained for operation of the same. Additionally, the compatibility module 612 checks to determine if networking and storage requirements for each host in the cluster configuration database 620 are compatible for the selected features or whether the networking and storage requirements may be configured to make them compatible for the selected features. In one embodiment, the compatibility module checks for basic network requirements. This might entail verifying each host's connection speed and the subnet to determine if each of the hosts has the required speed connection and access to the right subnet to take advantage of the selected features. The networking and storage requirements are captured in the configuration database 820 during installation of networking and storage devices and are used for checking compatibility.

The compatibility module 612 identifies a set of hosts accessible to the cluster management server 600 that either matches the requirements of the features or provides the best match and constructs a configuration template that defines the cluster configuration settings or profile that each host needs to conform in the configuration database 620. The configuration analysis provides a ranking for each of the identified hosts for the cluster. The analysis also presents a plurality of suggested adjustments to particular hosts so as to make the particular hosts more compatible with the requirements. The compatibility module 612 selects hosts that best match the features for the cluster. The cluster management server 600 uses the configuration settings in the configuration template to configure each of the hosts for the cluster. The configured cluster allows usage of the advanced features during operation and includes hosts that are most compatible with each other and with the selected advanced features.

In addition to the compatibility module 612, the configuration software 610 may include additional modules to aid in the management of the cluster including managing configuration settings within the configuration template, addition/deletion/customization of hosts and to fine-tune an already configured host so as to allow additional advanced features to be used in the cluster. Each of the modules is configured to interact with each other to exchange information during cluster construction. For instance, a template configuration module 614 may be used to construct a configuration template to which each host in a cluster must conform based on specific feature requirements for forming the cluster. The configuration template is forwarded to the compatibility module which uses the template during configuration of the hosts for the cluster. The host configuration template defines cluster settings and includes information related to network settings, storage settings and hardware configuration profile, such as processor type, number of network interface cards (NICs), etc. The cluster settings are determined by the feature requirements and are obtained from the Features list within the configuration database 620.

A configuration display module may be used to return information associated with the cluster configuration to the client for rendering and to provide options for a user to confirm, change or customize any of the presented cluster configuration information. In one embodiment, the cluster configuration information within the configuration template may be grouped in sections. Each section can be accessed to obtain further information regarding cluster configuration contained therein.

A features module 617 may be used for mining features for cluster construction. The features module 617 is configured to provide an interface to enable addition, deletion, and/or customization of one or more features for the cluster. The changes to the features are updated to the features list in the configuration database 620. A host-selection module 618 may be used for mining hosts for cluster configuration. The host-selection module 618 is configured to provide an interface to enable addition, deletion, and/or customization of one or more hosts. The host-selection module 618 is further configured to compare all the available hosts against the feature requirements, rank the hosts based on the level of matching and return the ranked list along with suggested adjustments to a cluster review module 619 for onward transmission to the client for rendering.

The cluster review module 619 may be used to present the user with a proposed configuration returned by the host-selection module 618 for approval or modification. The configuration can be fine-tuned through modifications in appropriate modules during guided configuration set-up which are captured and updated to the host list in either the configuration database 620 or the server. The suggested adjustments may include guided tutorial for particular hosts or particular features. In one embodiment, the ranked list is used in the selection of the most suitable hosts for cluster configuration. For instance, highly ranked hosts or hosts with specific features or hosts that can support specific applications may be selected for cluster configuration. In other embodiments, the hosts are chosen without any consideration for their respective ranks. Hosts can be added or deleted from the current cluster. In one embodiment, after addition or deletion, the hosts are dynamically re-ranked to obtain a new ranked list. The cluster review module 612 provides a tool to analyze various combinations of hosts before selecting the best hosts for the cluster.

A storage module 611 enables selection of storage requirements for the cluster based on the host connectivity and provides an interface for setting up the storage requirements. Shared storage is required in order to take advantage of the advanced features. As a result, one should determine what storage is shared by all hosts in the cluster and use only those storages in the cluster in order to take advantage of the advanced features. The selection options for storage include all the shared storage available to every host in the cluster. The storage interface provides default storage settings based on the host configuration template stored in the configuration database 620 which is, in turn, based on compatibility with prior settings of hosts, networks and advanced features and enables editing of a portion of the default storage settings to take advantage of the advanced features. In one embodiment, if a required storage is available to only a selected number of hosts in the cluster, the storage module will provide necessary user alerts in a user interface with required tutorials on how to go about fixing the storage requirement for the configuration in order to take advantage of the advanced features. The storage module performs edits to the default storage settings based on suggested adjustments. Any updates to the storage settings including a list of selected storage devices available to all hosts of the cluster are stored in the configuration database 620 as primary storage for the cluster during cluster configuration.

A networking module 613 enables selection of network settings that is best suited for the features and provides an interface for setting up the network settings for the cluster. The networking module provides default network settings, including preconfigured virtual switches encompassing several networks, based on the host configuration template stored in the cluster configuration database, enables selecting/editing the default network settings to enter specific network settings that can be applied/transmitted to all hosts, and provides suggested adjustments with guided tutorials for each network options so a user can make informed decisions on the optimal network settings for the cluster to enable usage of the advanced features. The various features and options matching the cluster configuration requirements or selected during network setting configuration are stored in the configuration database and applied to the hosts so that the respective advanced features can be used in the cluster.

FIG. 6 also illustrates cell sites 506 that are configured to be clients of each cluster. Each cell site 506 includes a cell tower 101 and a connection to each distributed unit (DU), similar to FIG. 5. Each DU is labeled as a virtualized distributed unit (vDU) 509, similar to FIG. 5, and each vDU runs as virtual network functions (VNFs) within an open source network functions virtualization (NFV) infrastructure.

With the above overview of the various components of a system used in the cluster configuration, specific details of how each component is used in establishing and communicating through a cellular network using containerized applications such as Kubernetes clusters, as shown in FIG. 7.

First, all of the hardware required for establishing a cellular network (e.g., a RAN, which includes towers, RRUs, DUs, CU, etc.) and a cluster (e.g., servers, workers, racks, etc.) are provided, as described in block 702. The LDC 504, RDC 502, and cell sites 506 are created and networked together via a network.

In blocks 702-714, the process of constructing a cluster using a plurality of hosts will now be described.

The process begins at block 704 with a request for constructing a cluster from a plurality of hosts which support one or more containers. The request is received at the automation platform module 501 from a client. The process of receiving a request for configuring a cluster then triggers initiating the clusters at the RDC 502 using the automation platform module 501, as illustrated in block 706.

In block 708, the clusters are configured and this process will not be described.

The automation platform module 501 is started by a system administrator or by any other user interested in setting up a cluster. The automation platform module 501 then invokes the cluster configuration software on the server, such as a virtual module server, running cluster configuration software.

In some embodiments, containerized applications (e.g., Kubernetes clusters) are used in 5G to stretch a private cloud network to/from a public cloud network. Each of the workload clusters in a private network is controlled by master nodes and support functions (e.g. MTCIL) that are run in the public cloud network.

Also, a virtualization platform runs the core and software across multiple geographic availability zones. A data center within the public network 8002/cloud stretches across multiple availability zones (“AZs”) in a public network to host: (1) stack management and automation solutions (e.g. the automation platform module, the virtual module, etc.) and (2) cluster management module and the control plane for the RAN clusters. If one of the availability zones fails, another of the availability zones takes over, thereby reducing outages. More details are presented below of this concept.

A private network (sometimes referred to as a data center) resides on a company's own infrastructure, and is typically firewall protected and physically secured. An organization may create a private network by creating an on-premises infrastructure, which can include servers, towers, RRUs, and various software, such as DUs. Private networks are supported, managed, and eventually upgraded or replaced by the organization. Since private clouds are typically owned by the organization, there is no sharing of infrastructure, no multi-tenancy issues, and zero latency for local applications and users. To connect to the private network, a user's device must be authenticated, such as by using a pre-authentication key, authentication software, authentication handshaking, and the like.

Public networks alleviate the responsibility for management of the infrastructure since they are by definition hosted by a public network provider such as AWS, Azure, or Google Cloud. In and infrastructure-as-a-service (IaaS) public network deployment, enterprise data and application code reside on the public network provider servers. Although the physical security of hyperscale public network providers such as AWS is unmatched, there is a shared responsibility model that requires organizations that subscribe to those public network services to ensure their applications and network are secure, for example by monitoring packets for malware or providing encryption of data at rest and in motion.

Public networks are shared, on-demand infrastructure and resources delivered by a third-party provider. In a public network deployment the organization utilizes one or more types of cloud services such as software-as-a-service (SaaS), platform-as-a-service (PaaS) or IaaS from public providers such as AWS or Azure, without relying to any degree on private cloud (on-premises) infrastructure.

A private network is a dedicated, on-demand infrastructure and resources that are owned by the user organization. Users may access private network resources over a private network or VPN; external users may access the organization's IT resources via a web interface over the public network. Operating a large datacenter as a private network can deliver many benefits of a public network, especially for large organizations.

In its simplest form, a private network is a service that is completely controlled by a single organization and not shared with other organizations, while a public network is a subscription service that is also offered to any and all customers who want similar services.

Regardless, because cellular networks are private networks run by a cellular provider, and the control of the containerized applications (e.g., Kubernetes clusters) and the control plane needs to be on a public network which has more processing power and space, the containerized applications (e.g., Kubernetes clusters) need to originate on the public network and extend or “stretch” to the private network.

FIG. 10 illustrates a block diagram of stretching the containerized applications (e.g., Kubernetes clusters) from a public network to a private network and across the availability zones, according to various embodiments.

This is done by the automation platform module 501 creating master modules 512 in the control plane 800 located within the public network 802. The containerized applications (e.g., Kubernetes clusters) are then created as explained above but are created in both private networks 804 and public networks 802.

The public network 802 shown in FIG. 10 shows that there are three availability zones AZ1, AZ2 and AZ3. These three availability zones AZ1, AZ2 and AZ3 are in three different geographical areas. For example, AZ1 may be in the western area of the US, AZ2 may be in the Midwestern area of the US, and AZ3 may be in the east coast area of the US.

A national data center (NDC) 806 is shown as deployed over all three availability zones AZ1, AZ2 and AZ3 and the workloads will be distributed over these three availability zones AZ1, AZ2 and AZ3. It is noted that the NDC 806 is a logical creation of the data center instead of a physical creation over these zones. The NDC 806 is similar to the RDC 502 but instead of being regional, it is stretched nationally across all availability zones.

It is noted that the control plane 800 stretches across availability zones AZ1 and AZ2 but could be stretched over all three availability zones AZ1, AZ2 and AZ3. If one of the zones fails, the control plane 800 would automatically be deployed on the other zone. For example, if zone AZ1 fails, the control plane 800 would automatically be deployed on AZ2. This is because each of the software programs which are deployed on one zone are also deployed in the other zone and are synced together so that when one zone fails, the duplicate started software automatically takes over. This creates significant stability.

Moreover, because the communication is to and from a private network, the communications between the public and private networks may be performed by pre-authorizing the modules on the public network to communicate with the private network.

The private network 804 includes the LDC 504 and cell sites 506 as well as an extended data center (EDC) 580. The LDC 504 and cell sites 506 interact with the EDC 580 as the EDC 580 acts a router for the private network 804. The EDC 580 is configured to have a concentration point where the private network 804 will extend from. All of the LDCs 504 and cell sites 506 connect to only the EDC 580 so that all of the communications to the private network 804 can be funneled through one point.

The master modules 512 control the DUs so that the clusters are properly allowing communications between the private network 804 and the public network 802. There are multiple master modules 512 so that if one master module fails, one of the other master modules takes over. For example, as shown in FIG. 8, there are three master modules 512 and all three are synced together so that if one fails, the other two are already synced together to automatically become the controlling master.

Each of the master modules 512 performs the functions of discussed above, including creating and managing the DUs 509. This control is shown over path B which extends from a master module 512 to each of the DUs 509. In this regard, the control and observability of the DUs 509 occurs only in the public network 802 and the DUs and the clusters are in a private network 804.

There is also a module for supporting functions and PaaS (the support module 814). There are some supporting functions that are required for observability and this support module 814 will provide such functions. The support module 814 manages all of the DUs from an observability standpoint to ensure it is running properly and if there are any issues with the DUs, notifications will be provided. The support module 814 is provided on the public network 802 to monitor any of the DUs 509 across any of the availability zones.

The master modules 512 thus create and manage the Kubernetes clusters and create the DUs 509 and the support module 814, and the support module 814 then supports the DUs 509. Once the DUs 509 are created, they run independently, but if a DU fails (as identified by the support module8) then the master module 512 can restart the DU 509.

Once the software (e.g., clusters, DUs 509, support module 814, master module 512, etc.) is set up and running, the user voice and data communications received at the towers 101 and is sent over the path of communication A so that the voice and data communications is transmitted from tower 101, to a DU 509, and then to the CU 812 in a EKS cluster 811. This path of communication A is separate from the path of communication B for management of the DUs for creation and stability purposes.

FIG. 9 illustrates a method of establishing cellular communications using containerized applications (e.g., Kubernetes clusters) stretched from a public network to a private network. Blocks 902, 903 and 904 of FIG. 9 are similar to Blocks 702, 704 and 706 of FIG. 7.

Block 906 of FIG. 9 is also similar to 708 of FIG. 7 except that the containerized applications (e.g., Kubernetes clusters) will be established on the private network from the public network. The containerized applications (e.g., Kubernetes clusters) can also be established on the public network as well. To establish the containerized applications on the private network, the private network allows a configuration module on the public network to access the private network servers and to install the workers on the operating systems of the servers.

In block 908, master modules are created on the public network as explained above. One of the master modules controls the workers on the private network. As discussed above, the master modules are all synced together.

In block 910, the DUs are created for each of the containerized applications (e.g., Kubernetes clusters) on the private network. This is accomplished by the active master module installing the DUs from the public network. The private network allows the active master module access to the private network for this purpose. Once the DUs are installed and configured to the RRUs and the corresponding towers, the DUs then can relay communications between the towers and the CU located on the public network.

Also in block 910, the support module is created on the public network and is created by the active master module. This support module provides the functions as established above and the private network allows access thereto for such support module to monitors each of the DUs on the private network.

Last, block 912 of FIG. 9 is similar to block 714 of FIG. 7. However, the communications proceed along path A in FIG. 8 as explained above and the management and monitoring of the DUs is performed along the Kubernetes clusters along path B.

Observability

While the network is running, the support module will collect various data to ensure the network is running properly and efficiently. This observability framework (“OBF”) collects telemetry data from all network functions that will enable the use of artificial intelligence and machine learning to operate and optimize the cellular network. The observability framework described herein may also be configured to monitor the no load and low load characteristics in order to allow for the power-saving characteristics and other features described earlier to occur. That is, the system 1000 described herein may include the processors configured assessing a characteristic of at least a portion of the cellular network described earlier, and also to reducing power to at least one part of the antenna or otherwise adjust some aspect of the cellular network.

This adds to the telecom infrastructure vendors that support the RAN and cloud-native technologies as a provider of Operational Support Systems (“OSS”) services. Together, these OSS vendors will aggregate service assurance, monitoring, customer experience and automation through a singular platform on the network.

The OBF brings visibility into the performance and operations of the network's cloud-native functions (“CNFs”) with near real-time results. This collected data will be used to optimize networks through its Closed Loop Automation module, which executes procedures to provide automatic scaling and healing while minimizing manual work and reducing errors.

This is shown in FIG. 10, which is described below.

FIG. 10 illustrates the network described above but also explains how data is collected according to various embodiments. The system 1000 includes the networked components 1002-1006 as well as the observability layers 1010-1014.

First, a network functions virtualization infrastructure (“NFVI”) 1002 encompasses all of the networking hardware and software needed to support and connect virtual network functions in carrier networks. This includes the cluster creation as discussed herein.

On top of the NFVI, there are various domains, including the Radio (or RAN) and Core CNFs 1004, clusters (e.g., Kubernetes clusters) and pods (or containers) 1006 and physical network functions (“PNFs”) 1008, such as the RU, routers, switches and other hardware components of the cellular network. These domains are not exhaustive and there may be other domains that could be included as well.

The domains transmit their data using probes/traces 1014 to a common source, namely a Platform as a Server (“PaaS”) OBF layer 1012. The PaaS OBF layer 1012 may be located within the support module on the public network so that it is connected to all of the DUs and CU to pull all of the data from the RANs and Core CNFs 1004. As such all of the data relating to the RANs and Core CNFs 1004 are retrieved by the same entity deploying and operating the each of the DUs of the RANs as well as the operator of the Core CNFs. In other words, the data and observability of these functions do not need to be requested from vendors of these items and instead are transmitted to the same source which is running these functions, such as the administrator of the cellular network.

The data retrieved are key performance indicators (“KPI”) and alarms/faults. KPI are the critical indicators of progress toward performing cellular communications and operations of the cellular network. KPIs provides a focus for strategic and operational improvement, create an analytical basis for decision making and help focus attention on what matters most. Performing observability with the use of KPIs includes setting targets (the desired level of performance) and tracking progress against that target.

The PaaS OBF and data bus (e.g., Kafka bus) retrieves the distributed data collection system so that such data can be monitored. This system uses the containerized application (e.g., Kubernetes cluster) structure, uses a data bus such as Kafka as an intermediate node of data convergence, and finally uses data storage for storing the collected and analyzed data.

In this system, the actual data collection tasks may be divided into two different functions. First the PaaS OBF is responsible for collecting data from each data domain and transmitting it to data bus and then, the data bus is responsible for persistent storage of data collected from data consumption after aggregation. The master is responsible for maintaining the deployment of the PaaS OBF and data bus and monitoring the execution of these collection tasks.

It should be noted that a data bus may be any data bus but in some embodiments, the data bus is a Kafka bus but the present invention should not be so limited. Kafka may be used herein simply as illustrative examples. Kafka is currently an open source streaming platform that allows one to build a scalable, distributed infrastructure that integrates legacy and modern applications in a flexible, decoupled way.

The PaaS OBF performs the actual collection task after registering with the master module. Among the tasks, the PaaS OBF aggregates the collected data into the Kafka bus according to the configuration information of the task, and stores the data in specified areas of the Kafka bus according to the configuration information of the task and the type of data being collected.

Specifically, when PaaS OBF collects data, it needs to segment data by time (e.g., data is segmented in hours), and the time segment information where data is located is written as well as the collected data entity in the data bus. In addition, because the collected data is stored in the data bus in the original format, other processing systems can transparently consume the data in the data bus without making any changes.

In the process of executing the actual collection task, the PaaS OBF also needs to maintain the execution of the collection task, and regularly reports it to the specific data bus, waiting for the master to pull and cancel the consumption. By consuming the heartbeat data reported by the slave in Kafka (for example), the master can monitor the execution of the collection task of the PaaS OBF and the data bus.

As can be seen, all of the domains are centralized in a single layer PaaS OBF 1212. If some of the domains are provided by some vendors and other by other vendors and these vendors would typically collect data at their networks, the PaaS OBF collects all of the data over all vendors and all domains in a single layer PaaS OBF 1012 and stores the data in a centralized long term storage using the data bus. This data is all accessible to the system at a centralized database or centralized network, such as public network 802 discussed above with regard to FIG. 8. Because all of the data is stored in one common area from various different domains and even from products managed by different vendors, the data can then be utilized in a much more efficient and effective manner.

After the data is collected across multiple domains, the data bus (e.g., Kafka) is used to make the data available for all domains. Any user or application can receive data to the data bus to retrieve data relevant to thereto. For example, a policy engine from a containerized application such as a Kubernetes cluster may not be getting data from the Kafka bus, but through some other processing, it indicates that may need to receive data from the Radio and Core CNF domain so it can start pulling data from the Kafka bus or data lake on its own.

It should be known that any streaming platform bus may be used and the Kafka bus is used for ease of illustration of the invention and the present invention should not be limited to such a Kafka bus.

Kafka is unique because it combines messaging, storage and processing of events all in one platform. It does this in a distributed architecture using a distributed commit log and topics divided into multiple partitions.

With this distributed architecture, the above-described data bus is different from existing integration and messaging solutions. Not only is it scalable and built for high throughput but different consumers can also read data independently of each other and in different speeds. Applications publish data as a stream of events while other applications pick up that stream and consume it when they want. Because all events are stored, applications can hook into this stream and consume as required—in batch, real time or near-real-time. This means that one can truly decouple systems and enable proper agile development. Furthermore, a new system can subscribe to the stream and catch up with historic data up until the present before existing systems are properly decommissioned. The uniqueness of having messaging, storage and processing in one distributed, scalable, fault-tolerant, high-volume, technology-independent streaming platform provides an advantage over not using the above-described data bus extending over all layers.

There are two types of storage areas shown in FIG. 10 for collection of the data. The PaaS OBF is the first data storage 1016. In this regard, the collection of data is short term storage by collecting data on a real time basis on the same cloud network where the core of the RAN is running and where the master modules are running (as opposed to collecting the data individually at the vendor sites). Here, the data is centralized for short term storage, as described above.

Then, the second data storage is shown as box 1018, which is longer term storage on the same cloud network as the first data storage 1016 and the core of the RAN. This second data storage allows data that can be used by any applications without having to request the data on a database or network in a cloud separate from the core and master modules.

There are other storage types as well such as a data lake 1020 which provides more of a permanent storage for data history purposes.

It should be noted that the data collected for all storage types are centralized to be stored on the public network, such as the public network 802 discussed above with regard to FIG. 8.

FIGS. 11 and 12 show an overall architecture of the OBF as well as the layers involved. First, in FIG. 11, there are three layers shown: the PaaS OBF layer 1012, the data bus layer 1010 and the storage layer 1104. There are time sensitive use applications 1102 which use the data directly from the data bus for various monitoring and other applications which need data on a more real-time basis, such as MEC, security, orchestration, etc. Various applications may pull data from the PaaS OBF layer since this is a real-time data gathering.

There are other use cases 1106 that can obtain data either from the PaaS OBF layer 1012, the data bus layer 1010 and the storage layer 1104, depending on the applications. Some applications may be NOC, service reassurance, AIML, enterprises, emerging use, etc.

As shown in FIG. 11, there are more details on various domains 1100, such as cell sites (vDU, vRAN, etc.), running on the NFVI 1002 layer. Also, as shown, the NFVI receives data from various hardware devices/sites, such as from cell sites, user devices, RDC, etc.

In FIG. 12, the network domains and potential customers/users are shown on the left with core and IMS, transport, RAN, NFC/Kubernetes (K8S), PNF, enterprises, applications, services, location, and devices. All of these domains are collected in one centralized location using various OBF collection means. For example, data from the core and IMS, RAN, and NFC/Kubernetes domains are collected using the RAN/Core OBF platform of the PaaS layer 1012. Also, data from the RAN and PNF domains are collected on the transport OBF layer. In any event, all of the data from the various domains and systems, whether or not there are multiple entities/vendors managing the domains, are collected at a single point or single database and on a common network/server location. This allows the applications (called “business domains” in the right hand side of FIG. 14) to have a single point of contact to retrieve whatever data is needed for those applications, such as security, automation, analytics, assurance, etc.

Although specific embodiments were described herein, the scope of the invention is not limited to those specific embodiments. The scope of the invention is defined by the following claims and any equivalents therein.

As will be appreciated by one skilled in the art, aspects of the present disclosure may be embodied as a system, a method or a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.

Any combination of one or more computer readable medium(s) may be utilized. The computer readable medium may be a computer readable signal medium or a non-transitory computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the non-transitory computer readable storage medium would include the following: a portable computer diskette, a hard disk, a radio access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a non-transitory computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

Aspects of the present disclosure are described above with reference to flowchart illustrations and block diagrams of methods, apparatuses (systems) and computer program products according to embodiments of the disclosure. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

The flowcharts and block diagrams in the Figs. illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The following is a summary of the claims as originally filed.

A method for dynamically transferring radio unit load to reduce power consumption may be summarized as including: determining a load on each radio unit of a plurality of radio units that service a geographical area; determining that the load on a first radio unit of the plurality of radio units fails to satisfy a first threshold to trigger a reduced-power state; in response to determining that the load on the first radio unit satisfies a second threshold to transfer the load: transferring the load from the first radio unit to at least a second radio unit of the plurality of radio units such that the load on the first radio unit after the transfer satisfies the first threshold; and in response to the load on the first radio unit after the transfer satisfying the first threshold: selecting a component associated with the first radio unit for which to reduce power; and reducing power to the component associated with the first radio unit, causing the first radio unit to enter the reduced-power state.

Transferring the load from the first radio unit to at least a second radio unit may include: selecting the second radio unit based on the second radio unit satisfying a third threshold to increase power; and transferring the load to the second radio unit.

The first radio unit and the second radio unit may be at a same cell site.

Determining that the load on the first radio unit fails to satisfy a first threshold to trigger a reduced-power state may include: determining that the first radio unit has at least one connected user device.

Determining that the load on the first radio unit fails to satisfy a first threshold to trigger the reduced-power state may include: obtaining utilization information for one or more components of the first radio unit; and determining, based on the utilization information, that the first radio unit fails to satisfy the first threshold.

Determining that the load on the first radio unit satisfies the second threshold to transfer the load may include: determining that the load on the first radio unit is below a load threshold.

Transferring the load from the first radio unit to at least the second radio unit may include: obtaining utilization information for the second radio unit; determining, based on the utilization information, that the second radio unit satisfies a threshold to increase power; calculating, based on the utilization information, a portion of the load to transfer to the second radio unit; and transferring the portion of the load to the second radio unit.

Selecting the component associated with the first radio unit for which to reduce power may include: selecting an antenna power amplifier associated with the radio unit.

Determining the load on each radio unit of the plurality of radio units that service the geographic area may include: selecting the geographic area based on a count of radio units that service the geographic area.

A system may be summarized as including: one or more memories configured to collectively store instructions; and one or more processors configured to collectively execute the stored instructions to: determine a first cell to enter a reduced-power state; identify a connected user device of the first cell; determine a component of the first cell to turn off; identify a second cell to which to transfer the connected user device; transfer the connected user device from the first cell to the second cell; and in response to transferring the connected user device, turn off the component of the first cell, causing the first cell to enter the reduced-power state.

The one or more processors may determine the first cell to enter the reduced-power state by being further configured to: determine, for each corresponding cell of a plurality of cells, an expense of servicing a correspondingly connected user device by the corresponding cell; and select the first cell from the plurality of cells based on the determined expenses of servicing the correspondingly connected user device of the plurality of cells.

The one or more processors may determine the first cell to enter the reduced-power state by being further configured to: determine a power consumption per connected user device of each of a plurality of cells; select the first cell from the plurality of cells based on the power consumptions.

The one or more processors may determine the first cell to enter the reduced-power state by being further configured to: identify a target geographic area; identify a plurality of cells that service the target geographic area; select the first cell from the plurality of cells, wherein each of one or more connected user devices of the first cell may be handed off to one or more target cells in the plurality of cells.

The one or more processors may determine the first cell to enter the reduced-power state by being further configured to: select the first cell from a plurality of cells based on a utilization of the first cell being below a utilization threshold.

The one or more processors may determine the first cell to enter a reduced-power state by being further configured to: select the first cell from a plurality of cells, wherein the first cell has a number of connected user devices that is below a connected device threshold.

The one or more processors may determine the first cell to enter a reduced-power state by being further configured to: select the first cell from a plurality of cells, wherein the first cell is expected to fall below a utilization threshold based on past utilization data for the first cell.

The one or more processors may determine the component of the first cell to turn off by being further configured to: identify a component that is servicing the connected user device; and designate the component that is servicing the connection as the component of the first cell to turn off.

The first cell and the second cell may be at different cell sites.

The first cell and the second cell may be separate cells at a same cell site.

One or more non-transitory computer-readable media that collectively store instructions that, when executed by a processor in a computing system, cause the processor to perform actions, the actions may be summarized as including: determining a first cell that satisfies a threshold to increase power; identifying one or more candidate cells capable of handing off a connected user device to the first cell; selecting a second cell in the one or more candidate cells; causing the first cell to enter an increased-power state; handing off the connected user device of the second cell to the first cell; and causing the second cell to enter a reduced-power state.

The various embodiments described above can be combined to provide further embodiments. All of the U.S. patents, U.S. patent application publications, U.S. patent applications, foreign patents, foreign patent applications and non-patent publications referred to in this specification and/or listed in the Application Data Sheet are incorporated herein by reference, in their entirety. Aspects of the embodiments can be modified, if necessary to employ concepts of the various patents, applications and publications to provide yet further embodiments.

These and other changes can be made to the embodiments in light of the above-detailed description. In general, in the following claims, the terms used should not be construed to limit the claims to the specific embodiments disclosed in the specification and the claims, but should be construed to include all possible embodiments along with the full scope of equivalents to which such claims are entitled. Accordingly, the claims are not limited by the disclosure.

Claims

1. A method for dynamically transferring radio unit load to reduce power consumption, the method comprising: determining a load on each radio unit of a plurality of radio units that service a geographical area;determining that the load on a first radio unit of the plurality of radio units fails to satisfy a first threshold to trigger a reduced-power state;in response to determining that the load on the first radio unit satisfies a second threshold to transfer the load: transferring the load from the first radio unit to at least a second radio unit of the plurality of radio units such that the load on the first radio unit after the transfer satisfies the first threshold; andin response to the load on the first radio unit after the transfer satisfying the first threshold: selecting a component associated with the first radio unit for which to reduce power; andreducing power to the component associated with the first radio unit, causing the first radio unit to enter the reduced-power state.

2. The method of claim 1, wherein transferring the load from the first radio unit to at least the second radio unit comprises: selecting the second radio unit based on the second radio unit satisfying a third threshold to increase power; andtransferring the load to the second radio unit.

3. The method of claim 1, wherein the first radio unit and the second radio unit are at a same cell site.

4. The method of claim 1, wherein determining that the load on the first radio unit fails to satisfy the first threshold to trigger the reduced-power state further comprises: determining that the first radio unit has at least one connected user device.

5. The method of claim 1, wherein determining that the load on the first radio unit fails to satisfy the first threshold to trigger the reduced-power state comprises: obtaining utilization information for one or more components of the first radio unit; anddetermining, based on the utilization information, that the first radio unit fails to satisfy the first threshold.

6. The method of claim 1, wherein determining that the load on the first radio unit satisfies the second threshold to transfer the load comprises: determining that the load on the first radio unit is below a load threshold.

7. The method of claim 1, wherein transferring the load from the first radio unit to at least the second radio unit comprises: obtaining utilization information for the second radio unit;determining, based on the utilization information, that the second radio unit satisfies a threshold to increase power;calculating, based on the utilization information, a portion of the load to transfer to the second radio unit; andtransferring the portion of the load to the second radio unit.

8. The method of claim 1, wherein selecting the component associated with the first radio unit for which to reduce power comprises: selecting an antenna power amplifier associated with the radio unit.

9. The method of claim 1, wherein determining the load on each radio unit of the plurality of radio units that service the geographic area comprises: selecting the geographic area based on a count of radio units that service the geographic area.

10. A system comprising: one or more memories configured to collectively store instructions; andone or more processors configured to collectively execute the stored instructions to: determine a first cell to enter a reduced-power state;identify a connected user device of the first cell;determine a component of the first cell to turn off;identify a second cell to which to transfer the connected user device;transfer the connected user device from the first cell to the second cell; andin response to transferring the connected user device, turn off the component of the first cell, causing the first cell to enter the reduced-power state.

11. The system of claim 10, wherein the one or more processors determine the first cell to enter the reduced-power state by being further configured to: determine, for each corresponding cell of a plurality of cells, an expense of servicing a correspondingly connected user device by the corresponding cell; andselect the first cell from the plurality of cells based on the determined expenses of servicing the correspondingly connected user device of the plurality of cells.

12. The system of claim 10, wherein the one or more processors determine the first cell to enter the reduced-power state by being further configured to: determine a power consumption per connected user device of each of a plurality of cells;select the first cell from the plurality of cells based on the power consumptions.

13. The system of claim 10, wherein the one or more processors determine the first cell to enter the reduced-power state by being further configured to: identify a target geographic area;identify a plurality of cells that service the target geographic area;select the first cell from the plurality of cells, wherein each of one or more connected user devices of the first cell may be handed off to one or more target cells in the plurality of cells.

14. The system of claim 10, wherein the one or more processors determine the first cell to enter the reduced-power state by being further configured to: select the first cell from a plurality of cells based on a utilization of the first cell being below a utilization threshold.

15. The system of claim 10, wherein the one or more processors determine the first cell to enter the reduced-power state by being further configured to: select the first cell from a plurality of cells, wherein the first cell has a number of connected user devices that is below a connected device threshold.

16. The system of claim 10, wherein the one or more processors determine the first cell to enter the reduced-power state by being further configured to: select the first cell from a plurality of cells, wherein the first cell is expected to fall below a utilization threshold based on past utilization data for the first cell.

17. The system of claim 10, wherein the one or more processors determine the component of the first cell to turn off by being further configured to: identify a component that is servicing the connected user device; anddesignate the component that is servicing the connection as the component of the first cell to turn off.

18. The system of claim 10, wherein the first cell and the second cell are at different cell sites.

19. The system of claim 10, wherein the first cell and the second cell are separate cells at a same cell site.

20. One or more non-transitory computer-readable media that collectively store instructions that, when executed by a processor in a computing system, cause the processor to perform actions, the actions comprising: determining that a utilization of a first cell satisfies a transfer threshold;identifying one or more candidate cells capable of receiving a connected user device from the first cell;selecting a second cell in the one or more candidate cells;causing the second cell to enter an increased-power state;handing off the connected user device of the first cell to the second cell; andcausing the first cell to enter a reduced-power state.