TECHNICAL FIELD

The solution presented herein generally relates to the configuration of radio equipment, and more particularly to dynamically adapting the configuration of individual radio equipment.

BACKGROUND

Wireless networks may incorporate multiple Remote Radio Heads (RRHs) at a single network access site to accurately convey wireless signals. Figure 1 shows one exemplary wireless network comprising multiple transmission/reception points, also referred to herein as network access points, each comprising multiple RRHs. One or more baseband controllers, located remotely from or at a network access point, control the operation of each RRH.

Typically, databases stored at each RRH define the operational limits of the RRH hardware and determine control behavior. Thus, by controlling the parameters in these databases, the baseband controller is able to control the configuration of the RRHs.

The parameters in these databases typically apply to an entire group of RRHs. As such, while the databases configure the RRH hardware to meet collective performance goals, these databases do not account for the individual performance of a particular RRH within a given environment, and do not account for hardware component degradation within individual RRHs due to aging, environment, etc. Further, these databases do not support the ability for a network operator to customize radio performance based on local network operational needs. As a result, each RRH does not operate at optimal capability or account for hardware degradation. Thus, there remains a need for RRH configuration solutions that improve performance ability of the RRHs, and particularly of individual RRHs.

SUMMARY

The solution presented herein enables the individual and dynamic configuration of each Remote Radio Head (RRH). Broadly speaking, each RRH comprises at least one hardware component, which comprises one or more performance sensors. Each RRH adapts the configuration of its hardware component responsive to one or more performance metrics retrieved from that hardware component's performance sensor(s). In so doing, the RRH accounts for its hardware component's particular performance characteristics, including accounting for tolerance differences that occur at manufacturing and different performance degradations due to different environments. As such, the solution presented herein may help each RRH achieve optimum performance.

One exemplary embodiment comprises a method, implemented by an RRH, of dynamically controlling a performance of the RRH. The RRH operatively connects to one or more baseband controllers. The method comprises retrieving one or more performance metrics from a hardware component in the RRH, where the hardware component is configured to control at least one of a transmission performance and a reception performance of the RRH. The method further comprises adapting a configuration of the hardware component responsive to the one or more performance metrics, and configuring the hardware component according to the adapted configuration to control the performance of the RRH.

One exemplary embodiment comprises an RRH operatively connected to one or more baseband controllers. The RRH comprises a hardware component and an adaptation circuit. The hardware component, which is configured to control at least one of a transmission performance and a reception performance of the RRH, comprises one or more performance sensors. The adaptation circuit operatively connects to the hardware component and is configured to retrieve one or more performance metrics from the one or more performance sensors, adapt a configuration of the hardware component responsive to the one or more performance metrics, and configure the hardware component using the adapted configuration to control a performance of the RRH. It will be appreciated that in some embodiments, the adaptation circuit may comprise an adaptation module or unit.

One exemplary embodiment comprises an RRH operatively connected to one or more baseband controllers. The RRH comprises a hardware component, a memory, and one or more processing circuits. The hardware component, which is configured to control at least one of a transmission performance and a reception performance of the RRH, comprises one or more performance sensors. The memory contains instructions executable by the one or more processing circuits such that the RRH is configured to retrieve one or more performance metrics from the one or more performance sensors, adapt a configuration of the hardware component responsive to the one or more performance metrics, and configure the hardware component using the adapted configuration to control a performance of the RRH.

One exemplary embodiment comprises a computer program product for controlling an

RRH. The RRH operatively connects to one or more baseband controllers, and comprises a hardware component comprising one or more performance sensors, where the hardware component is configured to control at least one of a transmission performance and a reception performance of the RRH. The computer program product comprising software instructions which, when run on at least one processing circuit in the RRH, causes the RRH to retrieve one or more performance metrics from the one or more performance sensors, adapt a configuration of the hardware component responsive to the one or more performance metrics, and configure the hardware component using the adapted configuration to control a performance of the RRH.

In solving the problems of existing systems, the solution presented herein may enable more efficient utilization of radio resources, improved quality of service metrics, increased radio sector cell size, dynamic adaptation of RF carrier power to current operating conditions, adaptive learning of optimal hardware parameter configuration, and/or power savings due to the more efficient use of radio resources. BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 shows an exemplary wireless network.

Figure 2 shows a method chart for configuring hardware component(s) of a remote radio head according to one exemplary embodiment.

Figure 3 shows a block diagram for a remote radio head according to one exemplary embodiment.

Figure 4 shows an exemplary decision tree learner process.

Figure 5 shows a system-level sequence diagram for implementing the solution presented herein according to one exemplary embodiment.

Figure 6 shows an overall algorithm for implementing the solution presented herein according to one exemplary embodiment.

Figure 7 shows an exemplary decision tree learner for a power amplifier according to one exemplary embodiment.

Figure 8 shows a system-level network diagram according to one exemplary

embodiment.

Figure 9 shows a block diagram for a remote radio head according to another exemplary embodiment.

DETAILED DESCRIPTION

Figure 1 shows an exemplary wireless network 10 comprising a plurality of wireless access points 12. Each access point 12 includes a plurality of Remote Radio Heads (RRHs) 100, where each RRH 100 operatively connects to at least one baseband controller (BBC) 200. Each RRH 100, which also may be referred to as a Remote Radio Unit (RRU) or Radio

Equipment (RE), comprises the access point's Radio Frequency (RF) circuitry (e.g., amplifiers, filters, etc.), as well as any associated analog-to-digital/digital-to-analog converters, frequency up/down converters, etc. For some wireless system technologies, e.g., GSM, CDMA, UMTS, or LTE, RRH 100 may be remote from any Base Transceiver Station (BTS)/NodeB/eNodeB. RRHs 100 may be used to extend the coverage of a BTS/NodeB/eNodeB in challenging environments, e.g., rural areas or tunnels, and are generally connected to the BTS/NodeB/eNodeB via a fiber optic cable using Common Public Radio Interface protocols. In addition, RRHs 100 make Multiple Input Multiple Output (MIMO) operation easier, and they increase a base station's efficiency and facilitate easier physical location for gap coverage problems. While Figure 1 shows three RRHs 100 per network access point 12, it will be appreciated that each network access point 12 may include any number of RRHs 100. Further, while Figure 1 shows two baseband controllers 200, it will be appreciated that network 10 may include any number of baseband controllers 200, that each RRH 100 may operatively connect to one or more baseband controllers 200, and that each baseband controller 200, which also may be referred to as an RE Controller (REC), may be located at an access point 12 or remotely from an access point 12.

As used herein, an access point refers to a network node comprising equipment capable, configured, arranged and/or operable to communicate directly or indirectly with a wireless device and/or with other network nodes or equipment in the wireless network to enable and/or provide wireless access to the wireless device and/or to perform other functions (e.g., administration) in the wireless network. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs) and NR NodeBs (gNBs)). Base stations may be categorized based on the amount of coverage they provide (or, stated differently, their transmit power level) and may then also be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. A base station may be a relay node or a relay donor node controlling a relay. A network node may also include one or more (or all) parts of a distributed radio base station such as centralized digital units and/or remote radio units (RRUs), sometimes referred to as Remote Radio Heads (RRHs). Such remote radio units may or may not be integrated with an antenna as an antenna integrated radio. Parts of a distributed radio base station may also be referred to as nodes in a distributed antenna system (DAS). Yet further examples of network nodes include multi-standard radio (MSR) equipment such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base transceiver stations (BTSs), transmission points, transmission nodes, and/or multi-cell/multicast coordination entities (MCEs). As another example, a network node may be a virtual network node. More generally, however, network nodes may represent any suitable device (or group of devices) capable, configured, arranged, and/or operable to enable and/or provide a wireless device with access to the wireless network or to provide some service to a wireless device that has accessed the wireless network.

As noted above, current RRH configuration solutions rely on configuration databases that are set up at manufacturing. Such databases universally apply to multiple RRHs 100, and cannot be modified without software updates. The solution presented herein provides a configuration solution that enables the individual configuration of an RRH 100 and allows the RRH configuration to be modified without software updates.

Figure 2 shows one exemplary method 300 for dynamically configuring the parameters of an RRH 100 to control, and thus to improve, the performance of the RRH 100. As shown in Figure 3, an RRH 100 comprises at least one hardware component 1 10, where the hardware component 1 10 comprises one or more performance sensors 1 12. Method 300 comprises retrieving one or more performance metrics from the hardware component 1 10, e.g., from one or more of the performance sensors 1 12 (block 310). The RRH 100 adapts a configuration of the hardware component 1 10 responsive to the performance metric(s) retrieved for that hardware component 1 10 (block 320). For example, according to one exemplary embodiment, the RRH 100 may utilize a statistically based machine learning algorithm to adapt the hardware component configuration. The RRH 100 then configures the hardware component 1 10 according to the adapted configuration to control the performance of the RRH 100 (block 330). While method 300 of Figure 2 discusses the configuration of one hardware component 1 10, it will be appreciated that this same method 300 may be used to configure any number of hardware components in the RRH 100.

Figure 3 shows a block diagram of one exemplary RRH 100, which comprises one or more hardware components 1 10 (each comprising one or more performance sensors 1 12), an adaptation circuit 120, an optional detection circuit 130, a memory 140, and an input/output circuit 150. It will be appreciated that each hardware component 1 10 may have a different number of performance sensors, e.g., 1 12-1 ...1 12-N or 1 12-1 ...1 12-M. Exemplary hardware components 1 10 include, but are not limited to, transmitter hardware component(s) 1 10 (e.g., a transmitter amplifier, e.g., a power amplifier, a transmitter filter, one or more oscillators, etc.) and receiver hardware component(s) 1 10 (e.g., a receiver amplifier, a receiver filter, one or more oscillators, etc.). Adaptation circuit 120 retrieves one or more performance metrics from at least one of the hardware components 1 10, e.g., by retrieving data from the performance sensor(s) 1 12 from the transmitter hardware component(s) 1 10 and/or the receiver hardware component(s) 1 10 to retrieve one or more transmitter performance metrics and/or one or more receiver performance metrics. Exemplary performance metrics include, but are not limited to, amplifier output level, oscillator frequency, filter cutoff point(s), or any other metric representing the performance of the particular hardware component 1 10 in question. For example, when the hardware component 1 10 in question comprises a transmitter hardware component, exemplary transmitter performance metrics include, but are not limited to, a transmitter output power metric, a transmitter output accuracy metric, a transmitter dynamic range metric, a transmitter intermodulation metric, a transmitter spurious emissions metric, a transmitter phase error metric, a transmitter time delay metric, and/or a transmitter isolation metric. When the hardware component 1 10 in question comprises a receiver hardware component, exemplary receiver performance metrics include, but are not limited to, a receiver noise figure metric, a receiver intermodulation metric, a receiver gain metric, and/or a receiver crosstalk metric. Responsive to the retrieved performance metric(s), adaptation circuit 120 adapts a configuration of the corresponding hardware component 1 10, e.g., adapts one or more databases defining the configuration of the hardware component 1 10, and configures the hardware component 1 10 using the adapted configuration. For example, the adaptation circuit 120 may adapt the configuration of a transmitter hardware component 1 10 by configuring, according to the adapted configuration, a transmitter power amplifier output, a transmitter filter equalization, a transmitter delay compensation, a transmitter mean power limiting, a transmitter mean power clipping, a transmitter temperature supervision, one or more settings for a transmitter local oscillator, a transmitter local oscillator supervision, and/or a transmitter feedback control loop, Alternatively or additionally, the adaptation circuit 120 may adapt the configuration of a receiver hardware component 1 10 by configuring, according to the adapted configuration, a receiver automatic gain control setting, one or more receiver local oscillator settings, a receiver local oscillator supervision, a receiver gain compensation setting, a receiver gain compensation supervision, one or more receiver diagnostic settings, a receiver diagnostic supervision, a receiver delay compensation, a receiver phase compensation, a receiver noise figure measurement setting, a receiver voltage standing wave ratio configuration, and/or a receiver voltage standing wave ratio supervision. Memory circuit 140 stores various information and instructions necessary to implement the solution presented herein, including but not limited to, decision trees and a decision tree learner (discussed below), configuration databases, etc.

In some embodiments, the adaptation may optionally occur responsive to an adaptation trigger (Figure 2, block 340). Exemplary adaptation triggers may result from, but are not limited to, the initiation of a decision tree set, the activation of a transmission/reception carrier, the release of a transmission/reception carrier, the expiration of a periodic interval, etc. For example, RRH 100 may optionally include a detection circuit 130 configured to detect the adaptation trigger, where the adaptation circuit 120 implements blocks 310-330 of Figure 2 responsive to the adaptation trigger.

Input/output circuit 150 transmits any signals provided by the hardware components 1 10, e.g., the transmission hardware components 1 10, and/or provides any received signals to the hardware components 1 10, e.g., the reception hardware components 1 10. In addition, the input/output circuit 150 may send information regarding the adapted configuration to the network operator, may provide received configuration information from the network operator to the adaptation circuit 120, may send/receive configuration-type information to/from the baseband controller 200, and/or may provide a received adaptation trigger to the detection circuit 130. In one exemplary embodiment, the input/output circuit 150 comprises one or more antennas. It will be appreciated, however, that input/output circuit 150 may alternatively or additionally comprise a wired or fiber connection.

The following provides more details regarding exemplary implementations of the solution presented herein. It will be appreciated that these details are for illustration purposes and are not limiting to the broad solution presented herein.

As noted above, the solution presented herein makes automated management of radio hardware configuration parameters possible, e.g., by configuring at least one hardware component 1 10 in the RRH 100 responsive to performance metrics 1 12 retrieved from the performance sensors 1 12 of each hardware component 1 10. In one exemplary embodiment, the adaptation circuit 120 may do so by applying statistically-based machine learning to a decision tree learner responsive to the retrieved performance metric(s). For example, upon startup, an RRH 100 provides the baseband controller(s) 200 with its radio performance capabilities and radio operational statistics. The baseband controller(s) 200 then provide the RRH 100 with an initial list of decision tree rule sets, which are based on operator supplied rules, radio status and heuristics, and the initial radio configuration. As part of carrier setup and activation, the adaptation circuit 120 may use a decision tree learner and an initial database for each configurable parameter to setup the initial configuration for the hardware component(s) 1 10. Periodically the decision tree learner implemented by the adaptation circuit 120 may updates the decision trees responsive to retrieved performance metrics, as discussed herein, where this update may also consider operator requirements and operational performance. These modified decision trees are used to adapt the configuration of one or more of the hardware components.

As understood by those skilled in the art, a decision tree learner is an adaptive decision tree which uses a statistically-based machine learning algorithm to provide predictive target values, e.g., that predict a current performance. With respect to the solution presented herein, a decision tree learner permits the RRH 100 to adapt parameters in the RRH's internal databases, which allows the RRH 100 to maximize operational performance parameters according to rules decided upon by the network operator, operational deployment, and performance metrics. In particular, the decision tree learner uses inputs from the performance sensors 1 12 to produce statistics on the performance of key parameter attributes associated with the corresponding hardware component 1 10, e.g., to predict the current performance of the hardware component. A statistically-based machine learning algorithm, e.g., implemented by the adaptation circuit 120, uses the produced statistics to provide optimal changes to the hardware parameters.

Figure 4 shows one exemplary decision tree learning process, where each circle represents one "leaf," and where there is one rule for each leaf. Such use of the decision tree learner may enable more efficient utilization of radio resources, improved quality of service metrics, increased radio sector size, dynamic adaptation of RF carrier power to current operating conditions, adaptive learning of optimal hardware parameter configuration, and power savings due to the more efficient use of radio resources. In particular, Figure 4 illustrates the adaptation of at least one rule set in the decision learning tree by determining a trend associated with the performance of the RRH, e.g., determining a trend of an error rate of the RRH, and adapting the rule sets responsive to that trend, e.g., pruning at least one of the rule sets when the error rate is decreasing, and adding one or more rules to at least one of the rule sets when the error rate is increasing.

Figure 5 shows one example of a decision tree process implemented, e.g., by the adaptation circuit 120. As shown in Figure 5, the baseband controller 200 sends an operational rule set to the RRH 100 over network management communication channels (1). When an RRH 100 restarts, the baseband controller 200 sends a get capabilities request message to the RRH 100 (2). Responsive to the get capabilities request message, the RRH 100 responds with RF performance capabilities and self-diagnostic statistics (3). Based on this information from the RRH 100 and the operator rule set, the baseband controller 200 sends initial decision trees to be used by the adaptation circuit 120 to optimize hardware configuration (4). The baseband controller 200 sends the carrier setup and configuration requests (5). The RRH 100 computes the optimal decision trees for hardware configuration using the decision tree learner, and then uses this optimized tree and the internal databases to configure the hardware parameters.

Periodically, the decision tree learner implemented by adaptation circuit 120 uses self- diagnostics and hardware supervision data (e.g., performance metrics from performance sensor(s) 1 12) to compute optimal hardware component configuration parameters (6). The adaptation circuit 120 adapts the configuration of one or more hardware components 1 10 using the rule set from the decision tree learner (7). The input/output circuit 150 may forward the optimized rule set from the adaptation circuit 120 back to the baseband controller 200. For example, the input/output circuit 150 may forward the adapted rule set to the baseband controller 200 periodically or responsive to a request received from the baseband controller 200.

Figure 6 shows one example of the dynamic configuration of the hardware component(s) 1 12 in an RRH 100 according to the solution presented herein. The configuration of the hardware component(s) 1 12 is driven by the internal databases (e.g., stored in memory circuit 140) and the rule sets developed by the decision tree learner (e.g., in adaptation circuit 120). The adaptation circuit 120 evolves the hardware configuration decision trees by adding tests that maximize a rule's accuracy responsive to the performance metrics. Further, adaptation circuit 120 deals with diagnostic and measured data, e.g., as provided by performance sensors 1 12, missing values, noisy data, and the rule set provided by the baseband controller 200. As a result, the adaptation circuit 120 adapts the hardware configuration parameters, which evolve to minimize errors.

To assess the performance of the adaptation solution presented herein, adaptation circuit 120 may assess configuration errors associated with one or more hardware components 1 10. The adaptation circuit 120 may compute configuration errors by comparing performance metrics obtained by one or more of the performance sensors 1 12 before and after the configuration adaptation occurs. If adaptation circuit 120 determines the adaptation reduced the errors, then the adaptation circuit 120 checks the decision tree to determine if it can be pruned. If adaptation circuit 120 determines the adaptation increased the errors, then the adaptation circuit 120 checks the decision tree learner for rule set modification so as to reduce the errors.

It will be appreciated that adaptation circuit 120 may use a decision tree for each hardware parameter affected by radio component age, temperature, and/or radio deployment scenario. The adaptation circuit 120 uses training data to provide these decision trees with confidence intervals, heuristic limits, and statistical assumptions. Using the decision tree learner, adaptation circuit 120 may aggressively prune the decision tree to provide minimal error with optimized performance. Over time, the adaptation circuit 120 adapts these decision trees to the operator's network requirements for the RRH 100 while simultaneously considering the individual performance of the hardware components of a particular RRH 100 (via the performance metrics obtained from the performance sensors 1 12).

As shown in Figure 6, there are multiple different scenarios which may initiate the adaptation of the hardware configuration by the adaptation circuit 120. It will be appreciated that the adaptation initiated for one circumstance does not preclude the initiation of the adaptation for other circumstance(s).

In a first example, adaptation circuit 120 initiates the hardware configuration adaptation responsive to the initiation of the decision tree rule sets. In this exemplary embodiment, for each decision tree, the adaptation circuit 120:

· reads the trained rule sets from the database;

• classifies the performance metrics provided by performance sensor(s) 1 12 using the trained rule set;

• checks which rules are affected by network operator preferences; and

• weight adjusts decision rules to optimize decision trees for customer preferences and according to the classified performance metrics.

In another example, adaptation circuit 120 initiates the adaptation responsive to the activation of a carrier. In this exemplary embodiment, for each decision tree affected by the carrier activation, the adaptation circuit 120:

• checks performance metrics provided by performance sensor(s) 1 12; · reads configuration and rule sets from the database;

• tests performance to determine if error rate is increasing or decreasing;

• if the error rate is increasing, modifies configuration change rule set;

• if the error rate is decreasing, prunes rule set;

• uses the revised rule set to adapt configuration of hardware parameter(s); and · configures hardware according to adapted configuration and stores new configuration and rule set in database (e.g., in memory circuit 140). In another example, adaptation circuit 120 initiates the adaptation according to a periodic interval. In this exemplary embodiment, for each decision tree used by the current hardware configuration, the adaptation circuit 120:

· checks performance metrics provided by the performance sensor(s) 1 12;

• reads configuration and rule set from the database;

• tests performance to determine if the error rate is increasing or decreasing;

• if the error rate is increasing, modifies configuration change rule set;

• if the error rate is decreasing, prunes rule set;

· uses revised rule set to adapt configuration of hardware parameter(s); and

• configures hardware according to adapted configuration and stores new configuration and rule set in database (e.g., in memory circuit 140). In another example, adaptation circuit 120 initiates the adaptation responsive to the release of a carrier. In this exemplary embodiment, for each decision tree affected by the carrier release, the adaptation circuit 120:

• checks performance statistics provided by the performance sensor(s) 1 12; · reads configuration and rule set from database;

• tests performance to determine if error rate is increasing or decreasing;

• if the error rate is increasing, modifies configuration change rule set;

• if the error rate is decreasing, prunes rule set;

• uses revised rule set to adapt configuration of hardware parameter(s); and · configures hardware according to adapted configuration and stores new configuration and rule set in database (e.g., in memory circuit 140). Figure 7 shows an example of the solution presented herein as applied to the gate bias of a power amplifier. For power amplifiers, it is desirable to ensure low distortion of the analog signals. As such, the gates of transistors in the power amplifier are biased in order to prevent the power amplifier from being driven into a nonlinear region of operation. Such gate bias adjustment is achieved by the generation of a bias voltage (from a digital-to-analog converter (DAC)). Initially, the digital word input to the DAC to generate the gate bias voltage is initially pre-calibrated by the factory and stored in memory 140, along with the dependent temperature. For each supported power class of the RRH's power amplifier, a corresponding set of data for each transistor in the power amplifier is stored in the database for the power amplifier (which is stored in memory 140) during production. The RRH 100 may interpolate the DAC word value for power levels between power classes. Figure 7 shows how the decision tree learner executed by the adaptation circuit 120 uses the performance metrics retrieved from the performance sensors 1 12 of the power amplifier to determine how to adjust the gate bias for the power amplifier. In particular, for the embodiment of Figure 7, the adaptation circuit 120 retrieves the current operating temperature, the current spectral emission, the current power output, and the current power savings estimate from the corresponding performance sensors of the power amplifier. The adaptation circuit 120 applies these performance metrics, as well as the current database, a current power amplifier gate bias (e.g., retrieved from the database), information regarding the service time since the factory assembly (e.g., age of the power amplifier), local operational requirements, and power amplifier operating limits to the decision tree learner (or other statistically-based machine learning algorithm). The decision tree learner uses the provided information to provide optimal changes to the power amplifier parameters, e.g., the gate bias, and updates the rules for that RRH 100 accordingly.

Figure 8 shows an example of the deployment of RRHs 100 with a server-based Radio

Base Station (RBS). The solution presented herein permits the RRH 100 to be controlled remotely using a server-based RBS. Using rules-based hardware configuration of radios, the remote RRHs 100 are operated according to local operating conditions and individual radio performance statistics, which makes it possible for the same server-based RBS to control RRHs 100 for different radio operators.

The solution presented herein enables the cellular network operator to better utilize radio network resources by enabling the RRH 100 to automatically adapt to customer needs and the radio performance metrics (provided by the performance sensors 1 12). The operator can do this without exposing hardware in each RRH 100 to damage. For example, by including damage protection thresholds as part of the rule sets when setting the configuration change(s), the hardware component cannot be configured outside of safe operating limits. Further, the degree of radio hardware configuration adaption is adjustable to suit network operating conditions. The rules controlling the hardware configuration are based on performance metrics from the performance sensor(s) 1 12, along with factory trained data and/or customer preferences.

The solution presented herein enables the automated management of an individual RRH's configuration parameters. When an RRH 100 starts-up, the RRH 100 provides the baseband controller 200 with its capability rating, and the baseband controller 200 provides an initial rule set based on customer preferences and expected radio deployment. The RRH 100 can adapt the rule sets used to configure the radio parameters, e.g., using a decision tree learner, to optimize performance. With time, the RRH 100 develops configuration rule sets which account for current operating mode, initial component performance within the tolerances, component age, and environmental conditions.

Figure 9 shows an RRH 100 in accordance with one or more embodiments. As shown, RRH 100 includes a processor circuit 160 and an input/output circuit 150. The input/output circuit 150 is configured to transmit and/or receive information to and/or from one or more other nodes, the baseband controller, etc., e.g., via any communication technology. Such communication may occur via one or more antennas that are either internal or external to the RRH 100 and/or via one or more wired lines (copper, fiber, etc.). The processor circuit 160 is configured to perform processing described above, e.g., in Figure 2, such as by executing instructions stored in memory 140. The processor circuit 160 in this regard may implement certain functional means, units, or modules.

The embodiments of Figures 3 and 9 include multiple circuits/modules/units for performing the steps of the corresponding method, e.g., adaptation circuit/unit/module 120, memory circuit/unit/module 140, input/output circuit/unit/module 150, optional detection circuit/unit/module 130, and processor circuit/unit/module 160. The circuits or circuitry in this regard may comprise circuits dedicated to performing certain functional processing and/or one or more microprocessors in conjunction with memory 140. In embodiments that employ memory 140, which may comprise one or several types of memory such as read-only memory (ROM), random-access memory, cache memory, flash memory devices, optical storage devices, etc., the memory 140 may store program code that, when executed by the one or more processors 160, carries out the techniques described herein.

Those skilled in the art will also appreciate that embodiments herein further include corresponding computer programs. A computer program comprises instructions which, when executed on at least one processing circuit 160 of an RRH 100, cause the RRH 100 to carry out any of the respective processing described above, e.g., the process 300 of Figure 2. A computer program in this regard may comprise one or more code modules corresponding to the means or units described above. To that end, memory 140 stores the code to be executed by the processing circuitry 160 and/or adaptation circuit 120 according, e.g., to the method 300 of Figure 2.

The present invention may, of course, be carried out in other ways than those specifically set forth herein without departing from essential characteristics of the invention. The present embodiments are to be considered in all respects as illustrative and not restrictive, and all changes coming within the meaning and equivalency range of the appended claims are intended to be embraced therein.