Field of the Invention

The present invention relates to an apparatus, a method and a computer program product for reducing energy consumption in cognitive autonomous networks.

Related background Art

The following meanings for the abbreviations used in this specification apply:

CAN Cognitive Autonomous Network

CCO Capacity and Coverage Optimization

CF Cognitive Function

CM Configuration Manager

CW Config (Configuration) Weight

DoD Degree of Dynamicity

DM DoD Manager

ESM Energy Saving Mode

ICIC Inter-Cell Interference Coordination

MAS Multi-Agent System

MLB Mobility Load Balancing

MNO Mobile Network Operator

NAF Network Automation Function

OCC Optimal Configuration Controller

OCRS Optimal config range set

QoS Quality of Service

RAT Radio Access Technology

SF SON Function

SON Self Organizing Network TXP Transmission Power

UE User equipment

UF Utility Function

Example embodiments, although not limited to this, relate to the operation of Network Automation Functions (NAF) in 5G (radio access) networks and other future generation of wireless/mobile networks. Self Organizing Network (SON) has been successful in introducing rule based network automation. SON deploys several rule-based NAFs, called SON Functions (SF) for automation purposes. However, the SFs are limited in two fundamental aspects - (i) they cannot adapt themselves in a rapidly changing environment because of their rule based behavior, and, (ii) existence of a large number of rules makes maintenance and upgrade of the system difficult.

Cognitive Autonomous Networks (CAN) are being promoted to replace SON by replacing the SFs with Cognitive Functions (CFs). These CFs are learning agents - they behave as they learn and do not follow any fixed set of rules. As a learning agent, a CF can determine the best network configuration for itself in a certain network state. Now, when a configuration is shared among multiple NAFs (e.g., TXP is shared among MLB, CCO, ICIC and others), each CF suggests a configuration value according to its own interest which gives rise to conflict among them. Thus, for the sake of stability of the system, no CF can directly make any changes to the network - only the "Configuration and Control" (as shown in Fig. 3) block can do it.

A previously proposed design of the Configuration and Control framework consists of a single Controller which communicates with the CFs through predefined interfaces. In case of a configuration sharing among multiple NAFs, each CF suggests a configuration value, suited to best of its interest, to the Controller and the Controller makes the final decision based on the information received from the CFs. According to earlier proposals, e.g. in "Game theoretic conflict resolution mechanism for cognitive autonomous networks" by Anubhab Banerjee, Stephen S. Mwanje and Georg Carle, the CAN is abstracted as a Multi-Agent System (MAS), where the CFs act as the agents of the system and a Controller is proposed which operates one layer above the CFs in the hierarchy. Agents in the MAS have the following properties:

PI. Each agent can learn and decide what is the best action for it by itself in a dynamic environment.

P2. No agent can communicate with each other and no one has a complete knowledge of the system.

P3. Some or all of these agents share the same resources and there exist conflicts of interests among them.

P4. Each agent tries to optimize its own target or goal simultaneously, and the concept of a common or team goal does not exist.

It would be advantageous to improve the present coordination and control mechanisms to support a more robust and energy efficient system design for CAN.

Summary of the Invention

Example embodiments address this situation aim to provide measures for supporting a more robust and energy efficient system design for CAN.

According to a first aspect, an apparatus is provided which comprises: at least one processor and at least one memory including computer program code, the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to perform: determining a request limitation value for restricting requests from network automation functions for configuring at least one network configuration value; when receiving a request from at least one of the network automation functions for configuring at least one network configuration value, deciding on whether to accept the request or not based on the request limitation value; and, when accepting the request, configuring the at least one network configuration value based on the accepted request.

According to a second aspect, a method, in a controller, is provided which comprises: determining a request limitation value for restricting requests from network automation functions for configuring at least one network configuration value, when receiving a request from at least one of the network automation functions for configuring at least one network configuration value, deciding on whether to accept the request or not based on the request limitation value, and, when accepting the request, configuring the at least one network configuration value based on the accepted request.

The first and second aspects may be modified as follows:

The request limitation value comprises a configuration value related threshold relating to a specific network configuration value to be re-configured, wherein the configuration value related threshold indicates a minimum number of network automation functions required to re-configure the specific network configuration value.

The request limitation value comprises a network automation function related threshold indicating a maximum number of requests allowed for a single network automation function to send within a certain time period.

The network automation function related threshold value may be sent to the at least one network automation function.

The request limitation value may be calculated based on at least one parameter configurable by a network operator. In configuring the at least one network configuration value based on the accepted request, the at least one network automation function may be requested to provide at least one candidate network configuration value, the at least one candidate network configuration value may be received from the at least one network automation function, and an optimal network configuration value may be determined based on the received at least one candidate network configuration value.

A configuration weight parameter for least one network configuration value for each network automation function may be calculated, and the configuration weight parameter may be applied for determining the optimal network configuration value.

The configuration weight parameter for least one network configuration value for each network automation function may be calculated based on variations in the output of the network automation function when the at least one candidate network configuration value varies.

A metric to measure an operational energy efficiency of the network may be calculated based on the following equation:

DoD = t*f*l/m, wherein DoD is the metric, t is a configuration value related threshold relating to a specific network configuration value to be re-configured, wherein the configuration value related threshold indicates a minimum number of network automation functions required to re-configure the specific network configuration value, m is a network automation function related threshold indicating a maximum number of requests allowed for a single network automation function to send within a certain time period, and f is a frequency of the time period. According to a third aspect, an apparatus, in a network automation function, is provided which comprises: at least one processor and at least one memory including computer program code, the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to perform: receiving, from a controller, a network automation function related threshold indicating a maximum number of requests allowed for a single network automation function to send within a certain time period to the controller, and restricting sending of a request for configuring at least one network configuration value to the controller based on the received network automation function related threshold.

According to a fourth aspect, a method, in a network automation function, is provided which comprises: receiving a network automation function related threshold indicating a maximum number of requests allowed for a single network automation function to send within a certain time period from a controller, and restricting sending of a request for configuring at least one network configuration value to the controller based on the received network automation function related threshold.

The third and fourth aspects may be modified as follows:

A request may be received from the controller, to provide at least one candidate network configuration value, and the at least one candidate network configuration value may be sent to the controller.

The at least one candidate network configuration value may be determined by learning such that it is optimal for achieving an objective of the network automation function for providing an optimal network configuration.

According to fifth aspect, a system is provided which comprises a controller including an apparatus according to the first aspect or its modifications, and at least one network automation function including an apparatus according to the third aspect or its modifications.

According to a sixth aspect, a system is provided which comprises a controller and at least one network automation function, wherein the controller is configured to determine a request limitation value for restricting requests from the at least one network automation function for configuring at least one network configuration value, to send the request limitation value to the at least one network automation function, to decide on whether to accept the request or not based on the request limitation value when receiving a request from the at least one network automation functions for configuring at least one network configuration value, and, to configure the at least one network configuration value, when accepting the request, based on the accepted request, and the at least one network automation function is configured to receive the request limitation value, and to restrict sending of a request for configuring at least one network configuration value to the controller based on the received request limitation value.

The request limitation value may comprise a network automation function related threshold indicating a maximum number of requests allowed for a single network automation function to send within a certain time period to the controller.

The fifth and sixths aspects may be modified in the same way as the first and third aspects.

According to a seventh aspect of the present invention a computer program product is provided which comprises code means for performing a method according to any one of the second and fourth aspects and/or their modifications when run on a processing means or module. The computer program product may be embodied on a computer-readable medium, and/or the computer program product may be directly loadable into the internal memory of the computer and/or transmittable via a network by means of at least one of upload, download and push procedures.

According to an eighth aspect, an apparatus is provided which comprises: means for determining a request limitation value for restricting requests from network automation functions for configuring at least one network configuration value, means for, when receiving a request from at least one of the network automation functions for configuring at least one network configuration value, deciding on whether to accept the request or not based on the request limitation value, and means for, when accepting the request, configuring the at least one network configuration value based on the accepted request.

According to a ninth aspect, an apparatus is provided which comprises: means for receiving a network automation function related threshold indicating a maximum number of requests allowed for a single network automation function to send within a certain time period from a controller, and means for restricting sending of a request for configuring at least one network configuration value to the controller based on the received network automation function related threshold.

Brief Description of the Drawings

These and other objects, features, details and advantages will become more fully apparent from the following detailed description of example embodiments, which is to be taken in conjunction with the appended drawings, in which: Fig. 1A shows a controller 1 according to an example embodiment,

Fig. IB shows a process carried out by the controller 1 according to the example embodiment,

Fig. 2A shows a CF (cognitive function) 2 according to an example embodiment,

Fig. 2B shows a process carried out by the CF 2 according to the example embodiment,

Fig. 3 shows a control and configuration management of access to and configuration of network resources,

Fig. 4 shows controller functionalities and interfaces according to an example embodiment,

Fig. 5 illustrates a sequential workflow of a DM shown in Fig. 4,

Fig. 6 shows an end-to-end workflow of the system according to an example embodiment,

Fig. 7 shows a flowchart of an optimal configuration calculation according to an example embodiment, and

Fig. 8 illustrates UFs of five CFs for a particular configuration c according to an example embodiment.

Detailed Description of example embodiments

In the following, description will be made to example embodiments. It is to be understood, however, that the description is given by way of example only, and that the described example embodiments are by no means to be understood as limiting the present invention thereto.

Before describing example embodiment, in the following problems to be solved are discussed in some more detail. Fig. 3 shows a control and configuration management of access to and configuration of network resources. In particular, the control and configuration management 32 configures access to an configuration of network resource, which are here illustrated as base stations 33, based on requests of network automations functions (NAF) 31.

In earlier proposals, it is discussed on how conflicts are resolved and optimal configurations are calculated dynamically in a CAN. In particular, each CF is a learning agent so it knows what configuration values are most beneficial for itself in a certain network state. This set of values is denoted by optimal- config-range set or OCRS. Based on its learning, each CF also generates a utility function (UF) which maps the relative goodness of a configuration in a fixed predefined scale (e.g., [0:10]). Based on these two information elements, the Controller calculates the optimal value for the combined interest of the CFs.

In reality, different configurations have different impacts on the objectives of different CFs. The impact of a configuration on the objective of a CF is quantified by Config-weight (CW) value. According to an earlier proposal, a CF can calculate the CW values for all its input configurations using Shapley Method.

Although this solution solves the existing problems of conflict resolutions and optimal value calculation, from the implementational perspective this approach has a few open challenges:

Some control parameters are shared among quite a number of CFs, like TXP which is shared among 4 CFs (CCO, MLB, Energy Savings, Coverage Hole Mgmt.). Now, in each consecutive cycle if one of the CFs sends a request for recalculation of TXP, the Controller has to recalculate the TXP in every cycle which consumes a lot of energy. On the other hand, in the earlier proposals, there were no lower bound on amount of change in optimal-config-range set needed to trigger the configuration recalculation process. So, even a slightest change in optimal-config-range set of one CF can trigger the whole configuration recalculation process which consumes a lot of energy whereas the newly calculated value is still very close to the previous one. For example, suppose current value of TXP is 46 dBm and optimal-config-range set of CCO is [40 dBm, 50 dBm]. Now, because of some small changes in the network, CCO finds that its new optimal-config-range set is [40.1 dBm, 50 dBm]. As this is not exactly same as the previous one ([40 dBm, 50 dBm]), CCO triggers the configuration recalculation process. This small change almost does not have any impact on the final TXP value, and the newly calculated value still came as 46 dBm. So, in effect, a lot of energy was spent although no gain was achieved.

Moreover, each CF can be produced by different vendors, so they cannot always be trustworthy. A CF has enough motivation to consecutively send requests to Controller in each cycle until the configuration value matches its expectations. So, from the perspective of the system, this is waste of a lot of energy and an unnecessary exchange of coordination control information.

Furthermore, in a real-life scenario, different CFs may be developed by different vendors and not all the CFs can be trusted regarding the config- weight values. A CF has enough leverage to lie about its config-weight value for a shared configuration to make the final configuration more inclined to its own favor which leads to a suboptimal value of that configuration for the whole system. To prevent this, at the Controller end there needs to be a mechanism for cross-verification of config-weight values supplied by a CF during an optimal configuration calculation. Example embodiments are directed to provide a new mechanism, which restricts the amount of requests sent by the CFs, ensures the system operates with energy efficiency and also ensures that inaccurate config-weight values do not lead to sub-optimal configurations of the system.

In the following, a general overview of some example embodiments is described by referring to Figs. 1A, IB, 2A and 2B.

Fig. 1A shows a controller 1 according to the present example embodiment. A procedure carried out by the controller 1 is illustrated in Fig. IB. Fig. 2A shows a CF 2 as an example for a network automation function according to the present example embodiment. Fig. 2B shows a procedure carried out by the CF 2.

The controller 1 shown in Fig. 1A comprises at least one processor 11 and at least one memory 12 including computer program code. The at least one processor 11, with the at least one memory 12 and the computer program code, is configured to cause the apparatus to perform: determining a request limitation value for restricting requests from network automation functions (e.g., the CF 2 shown in Fig. 2A) for configuring at least one network configuration value (Sll in Fig. IB), when receiving a request from at least one of the network automation functions for configuring at least one network configuration value, deciding on whether to accept the request or not based on the request limitation value (S12 in Fig. lb), and, when accepting the request, configuring the at least one network configuration value based on the accepted request (S13 in Fig. IB).

The CF 2 shown in Fig. 2B comprises at least one processor 21 and at least one memory 22 including computer program code. The at least one processor 21, with the at least one memory 22 and the computer program code, is configured to cause the apparatus to perform: receiving a network automation function related threshold indicating a maximum number of requests allowed for a single network automation function to send within a certain time period from a controller (S21 in Fig. 2B), and restricting sending of a request for configuring at least one network configuration value to the controller based on the received network automation function related threshold (S22 in Fig. 2B).

The controller 1 and the CF 2 described above may further comprise I/O units 13, 23, which are capable of transmitting to and receiving from other network elements.

Thus, according to some example embodiments as described above, request sent by network automation functions (such as CFs) to controllers are restricted, so that energy consumption can be reduced. Moreover, the configuration of the network configuration value is carried out by the controller, so that a more robust operation can be achieved.

The request limitation value described above may comprise a configuration value related threshold (such as a t-value described later) relating to a specific network configuration value (e.g. TXP) to be re-configured, wherein the configuration value related threshold indicates a minimum number of network automation functions required to re-configure the specific network configuration value. Alternatively or in addition, the request limitation value may comprise a network automation function related threshold (such as an m-value described later) indicating a maximum number of requests allowed for a single network automation function to send within a certain time period.

In the following, this is further described by referring to some further detailed embodiments.

As mentioned above, according to some example embodiments, a method to minimize unnecessary re-computations of the network control parameters (network configuration values) is provided. Within this method, the following is proposed: - A rule of minimum threshold (or, the t-value rule) that is applied by the controller to minimize the re-computations triggered when each CF request a recalculation of same control parameter in separate time slots. Using t-value rule, the Controller puts a lower bound on minimum number of requests necessary to trigger the recalculation of a configuration. For example, if 4 CFs share TXP and t-value for TXP is 0.5, then at least 4 * 0.5 = 2 CFs have to request simultaneously (in the same time slot) to trigger the recalculation of TXP. The t-value is an example for a configuration value related threshold.

- A rule of maximum request (or, the m-value rule) that limits the number of requests that a CF can make within a given time period. The controller should not be manipulated by frequency of requests and so each CF will only make those requests that are necessary. Using m-value rule, the Controller restricts the number of requests a CF can send in one time slot. For example, if m- value for CCO is 2, in one time slot the CCO can send maximum 2 requests for configuration recalculations. The m-value is an example for a network automation function related threshold.

- A new metric, called Degree of Dynamicity (DoD) to measure the operational energy efficiency of the CAN coordination mechanism. The concept of DoD helps CAN minimize unnecessary recalculations by combining the two rules above (the t-value and m-value rules). If f is the frequency of each time slot (also called "cycle"), then the Degree of Dynamicity (DoD) of the system is:

DoD = t * f * 1/m

- The lower the DoD value, the higher is the energy savings. So, by modifying the DoD value it is possible to control the energy consumption in a CAN.

- A functionality of a DoD Manager or DM which controls the Energy efficiency operation of the controller. The main duty of the block is to calculate the m- value and t-value of the system. When the system starts, the MNO decides in which energy savings mode (ESM) the MNO wants the system to operate (e.g., 25% ESM or 75% ESM). After this value is set, DM reads this value, calculates the corresponding m-value and t-value and communicate them to designated places. Every time the MNO changes the energy savings mode, DM recalculates the t-value and m-value and communicate them.

- A new functionality, called Config-weight Manager or CM, which is needed to avoid the risks of CFs manipulating the config-weight values (configuration weight values). In other words, instead of the CFs, the config-weight values are calculated by the CM which is not part of the individual CFs but may be an independent component of a part of the controller.

The previous functionality of the Controller, i.e. to compute the optimal configurations is undertaken by a functional block called the Optimal Configuration Calculator or OCC. So, in total, there may be three functionality blocks in a Controller: (i) DM, (ii) CM, and, (iii) Optimal Configuration Calculator or OCC, as shown in Fig. 4.

Fig. 4 shows Controller functionalities and interfaces. In particular, a controller 41 comprises an OCC 411, a DM 412 and a CM 413. The MNO 43 (i.e., some management entity of the MNO) may transmit ESM and/or f values to the DM 412. The DM 412 determines the above-mentioned t- and m-values based on the values received from the MNO 43. The m-value is transmitted to a CF 42 connected the controller 41, and the t-value is transmitted to the CM 413. The CM 413 receives a configuration recalculation request from the CF 42, and requests the CF for the latest OCRS, UF, based on which the CF 42 sends its latest OCRS and UF. The CM 413 sends the OCRS received from a plurality of CFs to the OCC 411, which determines the final optimal configuration.

Thus, the end-end flow of the coordination operation will as such be as follows: - After a CF detects a change in its OCRS of one or multiple configurations, it checks the current m-value and prioritizes its configurations and sends up to m requests to CM for configuration recalculation.

- After a CM receives a request from a CF, it checks if the t-value condition for that request has been satisfied. If not, it simply ignores the request. Otherwise, it sends requests to all CFs asking for their latest OCRSs and UFs.

- After the CM receives all the OCRSs and UFs, it calculates the corresponding CW values and sends them to OCC for final optimal configuration calculation.

- After the OCC receives this information, it calculates the optimal configuration following the method and makes necessary changes in the network.

At first, OCC combines all the OCRSs into a single configuration range set which covers all the OCRSs. Within this set, the OCC samples as many values as possible and calculates the product of the utilities raised to the power of CW values and selects that sample value as optimal for which this product is maximum.

For example, if OCC receives the following OCRSs: [ai, bi], [a2, b _å ] and [a3, b3], it creates the single configuration range set which is: [min(ai, a2, a3), max(bi, b2, b3)] and takes sample values within this range. If ui, U2, U3 are the respective UFs and wi, W2, W3 are the respective CW values, then for each sample value, the OCC calculates the product of: UI ^W1 U2 ^W2 U3 ^w3 and selects the one for which the product is maximum.

In case the OCC obtains the maximum product for multiple sample values, the OCC selects those which are close to one another. In other words, the OCC calculates the standard deviation of [ui ^wl ,U2 ^w2 , U3 ^w3 ] and selects the one for which the standard deviation value is the lowest. In the following, workflows in the different functionalities of the Controller described above (DM, CM, OCC) are described.

1. Workflow of DM

The DM is an intelligent functionality of the Controller. Based on its learning capability, it develops an algorithm using which it can directly calculate the DoD value corresponding to an ESM.

The workflow of DM consists of three sequential steps:

(i) Whenever the MNO sets a new ESM or f value, the DM gets the latest ESM value and calculates the corresponding DoD value from the ESM (S52 in Fig. 5).

(ii) After that, it gets the latest value of f from the system.

(iii) Then it calculates t and m using the following Eq.: t * 1/m < = DoD/f = const. such that both t and m are integers. That is, the value of the constant is DoD/f.

(iv) Finally, it sends the t-value to CM and sends the m-value to all the CFs in the system.

This sequential workflow is depicted in Fig. 5. That is, in S51, it is assumed that new [ESM, f] becomes available. Then, in S52, the DM gets both latest ESM and f value. In S53, the DM calculates the t-value and the m-value, as described above. In S54, the DM sends the t-value to the CM and the m-value to all CFs. In S55, the DM waits for a change in ESM or f.

2. Workflow of CM Main functionality of the CM is communicating with the CFs. Along with that, it also receives the t-value from DM whenever a change in ESM occurs. A CM can receive two types of information from a CF - (i) configuration recalculation request, or, (ii) its [OCRS, UF] value for a certain configuration. It sends only one type of message to the CFs - request for their latest [OCRS, UF] values and it sends sets of [OCRS, UF, CW] to the OCC for final optimal configuration calculation.

3. Workflow of OCC

Workflow of the OCC is the simplest among the three functionality blocks in the Controller. It has two tasks:

(i) whenever the CM sends a set of [OCRS, UF, CW] values, the OCC receives them and calculates the optimal value for that configuration as described above.

(ii) after it calculates a new configuration value, it makes necessary changes in the network.

4. End-to-end workflow of the system

In the following, the end-to-end workflow of the system is described, i.e., when and how a configuration is recalculated. In Fig. 6 shows the processes, which take place in a sequential manner. It is to be noted that the DM does not actively take part in configuration recalculation, so there will be no discussion about the workflow of DM in this section.

It is assumed that when the CFs become operational, from time to time they check for changes in the OCRS of all the used configurations. Whenever a CF detects a change in an optimal-config-range set of one input configuration, it triggers the entire process of optimal value calculation for that particular configuration which is shown in Fig. 6. This entire process consists of several sequential processes which are described below:

Process S61: After every certain time interval, for all input configurations, each CF compares its optimal-config-range set of current cycle with that of the previous cycle. If they are identical, the CF does nothing and continues learning until the next cycle. However, if the CF finds that its optimal-config- range set has changed, it proceeds to process S62.

Process S62: After a CF detects a change in its optimal-config-range set, it sends a request to the CM to recalculate that configuration. A CF which requests the CM for recalculation, is denoted as Requesting CF (as shown in Fig. 6). There can be one or multiple Requesting CFs.

Process S63: After the CM receives a request for configuration recalculation from a CF, the CM checks if the t-value criteria has been met for that configuration. If true, sends a message to all CFs in the system (including the Requesting CF), asking to send their (i) OCRS, and (ii) UF to the CM and goes to process S64. Else, it ignores the request and the whole process returns to process S61.

Process S64: After all the CFs (Requesting CF and rest of the CFs) receives the request from the CM, each CF sends the latest OCRS and UF to the CM.

Process S65: This step consists of two sub-steps. They are: Firstly, the CM receives (i) OCRS, and (ii) UF from each CF. Secondly, based on the received information, the CM calculates the config-weight value corresponding to each CF (as discussed in the following section 5).

Process S66: After the config-weight values are calculated, the CM send the OCRS, UF and CW values to the OCC for optimal configuration calculation. Process S67: The OCC calculates the optimal configuration based on the received information as described above and makes necessary adjustments in the network.

In Fig. 7, a flowchart for the whole operation is shown.

Hence, in S71, a CF is periodically checking for changes in OCRS. In S72, the CF determines whether there is any change in the OCRS. If no, the procedure returns to S71. If yes, i.e., when there is a change, the procedure proceeds to S73, in which the CF sends a request to CM for config recalculation. In S74, the CM checks for the t-value criteria. In S75, the CM determines whether the t-value criteria are satisfied or not. If no, the procedure returns to S71. If yes, the procedure continues to S76, in which the CM requests all CFs to send their OCRSs and UFs. In S77, the CM receives them and calculates CW values. In S78, the CM sends all three information (i.e., OCRS, UF and CW value for each CF) to the OCC. In S79, the OCC calculates the optimal configuration and makes corresponding changes.

6.5. Config-weight (CW) calculation

The config-weight describes the importance of a particular configuration on the output of a CF. In this section it is described how the CM can determine the config-weight values in a dynamic environment. In the following, a CAN with 5 CFs - FI, F2, F3, F4, F5 is considered, and it is assumed that there is a configuration c which is shared by all the CFs and its value has to be recalculated. Based on the received utility functions from the CFs (FI, F2, F3, F4 and F5 respectively), the CM plots their utility values vs c and gets a plot like shown in Fig 8.

In this plot it can be seen that output of FI varies most significantly and output of F2 varies least significantly with respect to c. The CM determines the impact of c on the output of each CF in the following way - within the given interval of the configuration, the CM measures the difference between consecutive local minimum and maximum and the more the difference is, the more is the config-weight value. For example, in this case c is varied between 1 and 100 for all CFs. Within this variation of c, output of Fi increases gradually from 0 to 1 and then gradually decreases from 1 to 0. So, the maximum variation of output of Fi is | (1 - 0) + (0 - 1) | = 2. For F2, the output gradually decreases from 0.3 to 0. So, the maximum variation of output of F2 is |0 - 0.3| = 0.3. For F3, the output gradually increases from 0 to 0.7. So, the maximum variation of output of F3 is |0.7 - 0| = 0.7. For F4, the output gradually decreases from 0.8 to 0.4. So, the maximum variation of output of F4 is |0.8 - 0.4| = 0.4. Output of Fs decreases gradually from 0.62 to 0 and then gradually increases from 0 to 0.7. So, the maximum variation of output of Fs is |(0 - 0.62) + (0.7 - 0)| = 1.32.

After the variations are calculated, the CM then normalizes them to get the final config-weight values. So, if the config-weight values of Fi, F2, F3, F4 and Fs for c are wi', W2', W3', W4' and ws' respectively, then 0.42

2 + 0.3 + 0.7 + 0.4 + 1.32

0.3

W2 = - = 0.06

2 + 0.3 + 0.7 + 0.4 + 1.32

0.7

W3 = - = 0.15

2 + 0.3 + 0.7 + 0.4 + 1.32

0.4

W4 = - = 0.08

2 + 0.3 + 0.7 + 0.4 + 1.32

1.32

Ws' = - = 0.29

2 + 0.3 + 0.7 + 0.4 + 1.32

From the config-weight (CW) values we see that Fi has the highest and F2 has the lowest value, which is in par with our earlier observation (output of FI varies most significantly and output of F2 varies least significantly w.r.t. c.). In this case, all the CW values are greater than zero, i.e., the CM sends OCRSs and UFs of all the CFs to the Controller for the calculation of c.

The embodiments described above offers several advantages as listed below:

1. According to some embodiments, the CW values are calculated by the Controller, unlike in the prior art, where the CW values are calculated by the CFs themselves. A CF has enough motivation to lie about the CW value which may lead to a sub-optimal configuration calculation. In the example embodiments described above, this problem is addressed, so that the system can work when different CFs are supplied by different vendors.

Some embodiments introduce a new functionality to restrict the number of requests a CF can send in one timeslot. This reduces the amount of information exchange in the system which in turn reduces overall energy consumption.

Some embodiments also introduce a new functionality to calculate optimal configuration only after a certain percentage of CFs request for recalculation of the same configuration. This feature saves unnecessary information exchange and optimal configuration calculation in the system and also saves energy.

The above-described example embodiments are only examples and may be modified.

For example, according to some embodiments described above, the DM calculates both a t-value and an m-value. However, this can be modified such that the DM only calculates one of the t-value and the m-value. In this way, the number of requests to be processed by the CM may still be limited, so that saving of energy can also be achieved when only one of the numbers of requests allowed for a CF within a given time period (time slot) is limited (m- value) or when only a certain percentage of CFs requests a recalculation of the same configuration (t-value).

Furthermore, according to some embodiments described above, the DM calculates the m-value and sends it to each CF, so that the CF has to limit the number of requests sent during a given time period. However, according to a modification, sending of the m-value to the CF may also be omitted. In this way, also CFs which do not support the procedure of the embodiments (namely to limit the number of requests within the given time period based on the m-value) could still be applied. This is in particular advantageous in case some CFs are from different vendors.

According to some embodiments described above, the m-value and the same t-value are provided for all CFs. However, alternatively, the m-value may be individually configured for each CF.

Names of network elements, protocols, and methods are based on current standards. In other versions or other technologies, the names of these network elements and/or protocols and/or methods may be different, as long as they provide a corresponding functionality.

In general, the example embodiments may be implemented by computer software stored in the memory (memory resources, memory circuitry) 12, 22 and executable by the processor (processing resources, processing circuitry) 11, 21 or by hardware, or by a combination of software and/or firmware and hardware.

As used in this application, the term "circuitry" refers to all of the following:

(a) hardware-only circuit implementations (such as implementations in only analog and/or digital circuitry) and

(b) to combinations of circuits and software (and/or firmware), such as (as applicable): (i) to a combination of processor(s) or (ii) to portions of processor(s)/software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions) and

(c) to circuits, such as a microprocessor(s) or a portion of a microprocessor(s), that require software or firmware for operation, even if the software or firmware is not physically present.

This definition of "circuitry" applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term "circuitry" would also cover an implementation of merely a processor (or multiple processors) or portion of a processor and its (or their) accompanying software and/or firmware. The term "circuitry" would also cover, for example and if applicable to the particular claim element, a baseband integrated circuit or applications processor integrated circuit for a mobile phone or a similar integrated circuit in server, a cellular network device, or other network device.

The terms "connected," "coupled," or any variant thereof, mean any connection or coupling, either direct or indirect, between two or more elements, and may encompass the presence of one or more intermediate elements between two elements that are "connected" or "coupled" together. The coupling or connection between the elements can be physical, logical, or a combination thereof. As employed herein two elements may be considered to be "connected" or "coupled" together by the use of one or more wires, cables and printed electrical connections, as well as by the use of electromagnetic energy, such as electromagnetic energy having wavelengths in the radio frequency region, the microwave region and the optical (both visible and invisible) region, as non-limiting examples.

The memory (memory resources, memory circuitry) 12, 22 may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory, and non- transitory computer-readable media. The processor (processing resources, processing circuitry) 11, 21 may be of any type suitable to the local technical environment, and may include one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on a multi core processor architecture, as non-limiting examples.

It is to be understood that the above description is illustrative of the invention and is not to be construed as limiting the invention. Various modifications and applications may occur to those skilled in the art without departing from the true spirit and scope of the invention as defined by the appended claims.