SYSTEM POWER MANAGEMENT AND OPTIMIZATION IN TELECOMMUNICATION SYSTEMS

Abstract

It is described a method (700) for reducing power consumption in a telecommunication system, the method (700) comprising: collecting (704) system data from at least a part of a plurality of subsystems (518) of the telecommunication system; determining a set of system constraints corresponding to the collected system data for at least the part of the plurality of subsystems (518); determining a configuration for at least the part of the plurality of sub-systems (518) based on the collected system data so that a total power consumption for at least the part of the plurality of subsystems (518) is reduced and the determined set of system constraints is met; and applying (712) the determined configuration to at least the part of the plurality of subsystems to enforce the determined configuration.

Claims

1. A method for reducing power consumption in a telecommunication system, the method comprising: collecting system data from at least a part of a plurality of subsystems of the telecommunication system; determining a set of system constraints corresponding to the collected system data for at least the part of the plurality of subsystems; determining a configuration for at least the part of the plurality of subsystems based on the collected system data so that a total power consumption for at least the part of the plurality of subsystems is reduced and the determined set of system constraints is met; and applying the determined configuration to at least the part of the plurality of subsystems to enforce the determined configuration.

2. Method as set forth in claim 1, the method further comprising: evaluating whether the determined configuration meets a predefined stability criterion, wherein the determined configuration is only applied if the determined configuration meets a predefined stability criterion.

3. Method as set forth in claim 1, the method further comprising: receiving a trigger signal to start collecting system data, wherein the trigger signal is received periodically or based on an event.

4. Method as set forth in claim 1, wherein the system data comprises a central processing unit load, wherein the system data comprises a network traffic load including a signaling traffic load and a user data traffic load, wherein the system data comprises a power consumption in an idle state and a power consumption corresponding to the central processing unit load the traffic load, wherein the set of system constraints comprises one or more overload thresholds such as a maximum processing load, a maximum network traffic load, system limitations regarding the total power consumption.

5. Method as set forth in claim 1, wherein determining the set of constraints comprises formulating an optimization problem.

6. Method as set forth in claim 5, wherein the determining the configuration for at least the part of the plurality of subsystems comprises directly solving the optimization problem using an exhaustive search.

7. Method as set forth in claim 5, wherein formulating the optimization problem comprises: defining the set of system constraints; and formulating an objective function of the optimization problem, wherein the objective function minimizes the total power consumption.

8. Method as set forth in claim 7, wherein the objective function is based on the power consumption in an idle state of at least the part of the plurality of subsystems and the power consumption corresponding to the central processing unit load the traffic load of at least the part of the plurality of subsystems.

9. Method as set forth in claim 7, wherein determining a configuration for each of the plurality of subsystems comprises solving the optimization problem by minimizing the objective function of the optimization problem with respect to the determined set of system constraints.

10. Method as set forth in claim 1, wherein evaluating whether the determined system configuration meets the predefined stability criterion comprises determining whether a time trend of the collected system data indicates an increase or a decrease of the collected system data without fluctuation.

11. Method as set forth in claim 1, wherein applying the determined configuration comprises: translating the determined configuration into one or more system commands for at least the part of the plurality of subsystems, sending the one or more system commands to at least the part of the plurality of subsystems so that at least the part of the plurality of subsystems remains operational when applying the determined configuration, configuring one or more cooling systems of at least the part of the plurality of subsystems based on the determined configuration.

12. Method as set forth in claim 11, wherein the system commands comprise at least one of the following system commands: switching on a subsystem, switching off a subsystem, suspending a subsystem in a standby mode, resuming a subsystem from a standby mode, changing a distribution of processing load, and changing a routing of traffic so that a network traffic load is distributed differently.

13. Method as set forth in claim 1, the method further comprising: if the determined configuration does not meet the predefined stability criterion, discarding the determined configuration, and waiting for the next trigger signal to start collecting the system data.

14. Method as set forth in claim 1, wherein the configuration is determined so that the total power consumption for at least the part of the plurality of subsystems is reduced to a minimum total power consumption.

15. Method as set forth in claim 1, wherein at least the part of the plurality of subsystems is fully operational during determining the configuration.

16. Method as set forth in claim 1, the method further comprising: predicting future parameters of the system data based on historical data in a predefined time interval.

17. Method as set forth in claim 16, the method further comprising: evaluating whether the telecommunication system is in a stable state previous to determining the configuration, wherein evaluating comprises determining whether a continuous change is predicted in the future parameters of the system data.

18. Method as set forth in claim 17, wherein determining the configuration for at least the part of the plurality of subsystems is only initiated if the telecommunication system has been evaluated to be in the stable state, and/or the method further comprising: if the telecommunication system is evaluated not to be in the stable state, terminating the method, and waiting to receive the next trigger signal.

19. Telecommunication apparatus, the telecommunication apparatus comprising: a plurality of subsystems, a power reduction module configured to reduce power consumption of a plurality of subsystems, the power reduction module comprising: a system data collector configured to collect system data from at least a part of the plurality of subsystems; a constraint determining unit configured to determine a set of system constraints corresponding to the collected system data for at least the part of the plurality of subsystems; a configuration determining unit configured to determine a configuration for at least the part of the plurality of subsystems based on the collected system data so that a total power consumption for at least the part of the plurality of subsystems is reduced and the determined set of system constraints is met; and a system configuration enforcer configured to apply the determined configuration to at least the part of the plurality of subsystems to enforce the determined configuration.

20. Telecommunication system as set forth in claim 19, wherein the telecommunication system is an advanced telecommunications computing architecture system, and wherein the plurality of subsystems comprises a plurality of advanced telecommunications computing architecture subsystems.

21. Telecommunication system as set forth in claim 19, wherein the power reduction module is configured to reduce power by: collecting system data from at least a part of a plurality of subsystems of the telecommunication system; determining a set of system constraints corresponding to the collected system data for at least the part of the plurality of subsystems; determining a configuration for at least the part of the plurality of subsystems based on the collected system data so that a total power consumption for at least the part of the plurality of subsystems is reduced and the determined set of system constraints is met; and applying the determined configuration to at least the part of the plurality of subsystems to enforce the determined configuration, and, evaluating whether the determined configuration meets a predefined stability criterion, wherein the determined configuration is only applied if the determined configuration meets a predefined stability criterion.

22. Computer program embodied on a non-transitory computer readable medium, the computer program, when executed by a data processor, controlling for carrying out the method as specified in claim 1.

Description

BRIEF DESCRIPTION OF THE DRAWING

[0035] FIG. 1 shows a simplified system overview comprising an Advanced Telecommunications Computing Architecture (ATCA) system.

[0036] FIG. 2 shows an exemplary ATCA system including a power optimization module within shelf managers

[0037] FIG. 3 shows an exemplary ATCA system including a power optimization module as an internal module of the ATCA system

[0038] FIG. 4 shows an exemplary ATCA system and a power optimization module as an external module of the ATCA system

[0039] FIG. 5 shows an exemplary block diagram of a power optimization module

[0040] FIG. 6 shows an exemplary block diagram of an extended power optimization module

[0041] FIG. 7 shows an exemplary flow chart of a power optimization module

[0042] FIG. 8 shows an exemplary flow chart of an optimization problem formulator module

[0043] FIG. 9 shows an exemplary flow chart of an extended power optimization module

[0044] FIG. 10 shows an exemplary time line of power optimization processes of an ATCA system

DETAILED DESCRIPTION

[0045] The illustration in the drawing is schematically. It is noted that in different figures, similar or identical elements are provided with the same reference signs or with reference signs, which are different from the corresponding reference signs only within the first digit.

[0046] In the following, an Advanced Telecommunications Computing Architecture (ATCA) system is used to explain the examples of embodiment. However, other systems such as Self-Organizing Networks (SONs) may be used to implement aspects of the present invention. For example, the present invention may also be implemented in a manager module of a self-organizing network.

[0047] FIG. 1 shows a simplified system overview of a telecommunication system 100 comprising an Advanced Telecommunications Computing Architecture (ATCA) system 102, monitored and managed by a “System Manager” system 104. The ATCA is a set of industry standard specifications, produced by the PCI Industrial Computers Manufacturers Group (PICMG). The ATCA specification specifies the next generations of carrier grade communications, military and aerospace equipment. ATCA specifications, e.g. PICMG 3.0 Advanced Telecommunications Computing Architecture Base Specification, R3.0, may provide the description of mechanical and electrical design of ATCA systems 102 as well as the basic embedded software and hardware building blocks and their interconnections, designed to achieve sufficient reliability, availability and serviceability depending on the application.

[0048] Examples of common wireless network elements running on the ATCA platform or the ATCA system 102 may include Radio Network Controllers (RNC), Base Station Controllers (BSC), Mobile Station Controllers (MSC), Tunneling Termination Gateways (TTG), Serving GPRS support nodes (SGSN), Gateway GPRS support nodes (GGSN), Gateway Mobile Switching Centers (GMSC) and System Architecture Evolution (SAE) or Long-Term Evolution (LTE) components such as Serving Gateways (SGW), Packet Data Network Gateways (PGW), Mobility Management Entities (MME), Evolved Packet Data Gateways (ePDG) etc. The invention may also apply to any other rack/shelf-based computing systems consisting of blades inserted in slots of the shelf/rack.

[0049] As exemplary depicted in FIG. 1, ATCA systems 102 may comprise interconnected blades 106, the ATCA subsystems, which may act as processing units and/or networking switches. ATCA systems may also include other subsystems such as power supplies and/or shelf managers 108. The shelf managers 108 may monitor the health of other boards using Intelligent Platform Management Interface (IPMI) protocols, may manage system fans and/or may set a power state of any blade (on/off/standby etc.). The interconnection between shelf managers and the other boards in an ATCA system may be based on multiple Intelligent Platform Management Buses (IPMBs) 110. Shelf managers 108 may also communicate with other external systems, e.g. a system manager 104, via a plurality of networking interfaces using e.g. Intelligent Platform Management Interface (IPMI) 112 specifications or Internet Engineering Task Force (IETF) specifications and corresponding protocols, e.g. Remote Management Control Protocol (RMCP), Simple Network Management Protocol (SNMP) and/or various other protocols.

[0050] As can be seen in the example of FIG. 1, there may be various types of ATCA subsystems. For example, ATCA blades 106 may include Advanced Mezzanine Card (AMC) modules which may implement expansion functionality and may be plugged into the system as Rear Transition Modules (RTMs).

[0051] Furthermore, at least one or each ATCA subsystem may further include an Intelligent Platform Management Controller (IPMC) and Modular Management Controller (MMC) modules that may be used for signaling, configuration and monitoring purposes.

[0052] Similarly, shelf managers 108 may include a shelf management controller (ShMC).

[0053] The concept of the system manager may encompass both, automated software systems and human operators. The system manager may be used to remotely monitor and control ATCA systems. In addition, the use of the system manager might not be constrained to a single ATCA system. Several ATCA systems might also be interconnected, wherein the system manager may be able to connect to all of the shelf managers of the one or more ATCA systems.

[0054] System availability may be important in ATCA systems. Redundancy principles may be utilized in order to minimize system outages, e.g. application faults and/or network outages, and to achieve predefined customer Service Level Agreements (SLAs). In addition, in order to achieve high degrees of flexibility and serviceability, ATCA subsystems may be field as Field Replaceable Units (FRUs).

[0055] ATCA systems may comprise a chassis with free slots for blades that operate with a various number of multicore Central Processing Units (CPUs). Each CPU may be considered as an independent network node. However, common deployments may let behave the whole system as a single network node employing load balancing algorithms for scheduling traffic within the system. In ATCA systems, two major modes of deployment are preferably used. First, a so-called deployment mode N+, where some or all blades, i.e. subsystems, installed on the chassis may act as traffic processing systems. Second, a so-called deployment mode 2N, where blades may be grouped as a pair of active and backup subsystems for preserving zero-outage with a high probability.

[0056] In order to achieve predefined levels of operational performance, ATCA subsystems may be grouped in groups of two and more subsystems to implement redundancy principles of the deployment modes as described previously. In particular, the 2N redundancy principle may comprise N active ATCA subsystems which may serve computational load, e.g. networking traffic, and a second set of N ATCA subsystems which may be inactive. In some implementations, each active subsystem may be paired with one inactive or backup subsystem. If one or more active subsystems fail, then the corresponding paired subsystem may take over and may continue to serve computational load, e.g. networking traffic, with zero operational downtime or outage.

[0057] The N+M redundancy principle may consist of N active ATCA subsystems and M inactive subsystems. If one or more active subsystems fail, then one inactive subsystem may be activated and may take over the serving of computational load, e.g. networking traffic, from the faulty subsystem.

[0058] Moreover, ATCA subsystems may be grouped in load balancing configurations where a plurality of subsystems may share the computational load, e.g. serve equal amounts of networking traffic. Load balancing configurations may be useful in telecommunication systems since load balancing configurations may split the network traffic load among multiple systems, thus maintaining uniformly distributed capacity requirements for the network links and/or avoiding potential network congestions. In addition, load balancing configurations may assure that a single point of failure would not affect a large amount of traffic volume.

[0059] The principles as described above with respect to ATCA systems may be applied as well as to any other rack/shelf-based computing systems including blades inserted in slots of the shelf/rack.

[0060] A common ATCA system may be configured in e.g. 2N and N+ ATCA deployments to handle the packet core traffic of an operator. Further, such common ATCA system may be configured in a 2N deployment to have all of its subsystems active 24hours/7days/365days in order to satisfy a target availability, e.g. 99.9999% uptime, according to the operator's requirements. ATCA based systems and subsystems use state-of-the-art computing hardware and perform intensive computations for e.g. traffic analysis, routing functions, traffic monitoring & interception. Therefore, conventional ATCA based systems and subsystems may consume high amounts of power. Additionally, ATCA systems may also require high amounts of cooling power according to air conditioning requirements which is needed to keep the system temperature within specifications.

[0061] Thus, by having all ATCA subsystems active even in times when they do not handle any load, the system may be rendered highly non-optimal in its usage of energy resources. Further, energy may wasted by not taking into account that the power consumption of ATCA subsystems is a function of load (e.g. traffic). Thus, common ATCA systems might not distribute the load in the optimal way across subsystems.

[0062] In particular, the processing load handled by the ATCA system may be a function of a plurality of parameters such as the mobile user behavior (session creation, network traffic generation, idle states and session deletion events and statistics depending on the time of the day and the day of the year), the network state and parameters (e.g. routing policies, potential downtime of related systems) and operator configuration (whether e.g. deep packet inspection, content caching, video optimization is configured).

[0063] Depending on the ATCA deployment mode (such as 2N or N+ described above), the ATCA system may schedule the workload among the active ATCA subsystems. For example, when N+ deployment is used, traffic may be distributed among and handled by all the active subsystems, thus achieving a specific level of performance and power consumption.

[0064] This invention may provide a power optimization module for ATCA systems. The power optimization module may solve an optimization problem using a suitable technique or algorithm such as exhaustive search or an interior point method. The choice of technique or algorithm may be flexibly chosen by the implementation and depends on e.g. the ATCA system dimension. For modern ATCA systems that comprise a small number of ATCA subsystems, an exhaustive search might not require considerable computational complexity—and may provide the optimal (or sub-optimal in favor of complexity) solution to the allocation of resources among the ATCA subsystems.

[0065] As shown in FIGS. 2 to 4, one or more power optimization modules may be included in one or more ATCA system in order to perform power optimization of the one or more ATCA systems. A power optimization module may measure a system state regarding load and power consumption, may take into account future estimates and predefined profiles for system states, may formulate the optimization problem of minimizing total ATCA power consumption, may solve the optimization problem and may allocate available resources optimally among the ATCA subsystems.

[0066] FIG. 2 shows an exemplary ATCA system 200 including a power optimization module 202 within one or more ATCA shelf managers 208. The power optimization module may be a software component included with the one or more ATCA self managers 208. The power optimization module 202 may also be included as a software component in any other ATCA subsystem.

[0067] FIG. 3 shows an exemplary ATCA system 300 including a power optimization module 302 as an internal module of the ATCA system 300. The power optimization module 302 may be implemented as a hardware module, e.g. an ATCA subsystem, within the ATCA system 300.

[0068] FIG. 4 shows an exemplary ATCA system 400 and a power optimization module 402 as an external module of the ATCA system 400. The power optimization module 402 may be implemented as a software module, a hardware module, or a combination of both, software and hardware modules, which may be located outside of the ATCA system 400. Preferably, the power optimization module is integrated within a System Manager entity 404.

[0069] It should be noted that in the above figures the types of interfaces, blade types and component architecture are merely examples rather than limitations and that the power optimization module may be integrated in any ATCA or similar system.

[0070] FIG. 5 shows an exemplary block diagram 500 comprising a power optimization module 502. The power optimization module 502 may be triggered by any other module or scheduler, e.g. a power optimization module scheduler 504. For example, the power optimization module scheduler 504 may periodically trigger, e.g. one or two times per minute, the power optimization module 502 by providing a trigger signal 506 to the power optimization module 504. Additionally or alternatively, the power optimization module scheduler 504 may trigger the power optimization module 502 based on events, e.g. traffic bursts, failure of subsystems, etc.

[0071] Further, the power optimization module 502 may comprise one or more of the following submodules: [0072] A system data collector 508 which may collect all available information on the system, i.e. the ATCA system, such as power and processing load measurements, historical data, statistics and power/traffic/load profiles, operator policies etc. from any entity, e.g. internal or external systems/subsystems and databases 509. [0073] A total system power optimization problem formulator 510, e.g. a constraint determining unit, which may formulate the optimization problem of minimizing total system power consumption. The total system power optimization problem formulator 510 may take as an input all collected measurements and may formulate the problem variables, the objective function and the constraints of the optimization problem. [0074] A total system power optimization problem solver 512, e.g. a configuration determining unit, which solves, using any suitable algorithm or procedure, the optimization problem formulated by the total system power optimization problem formulator 510. [0075] A solution evaluation module 514, e.g. a stability evaluation unit, which may evaluate the suitability of the solution produced by the optimization problem solver 512, taking into account all the information gathered by the system data collector 508. The solution evaluation module may decide whether the solution of the optimization problem solver 512 may be suitable for application to the system with respect to network stability. The solution evaluation module 514 may have the advantage that unstable extreme situations of continuously enabling/disabling subsystems 518 may be avoided. [0076] A system configuration enforcer 516 may apply the selected solution (if any) from the solution evaluation module 514 to all subsystems 518. The system configuration enforcer 516 may send disable commands to the subsystems 518.

[0077] Furthermore, the power optimization module 502 may use the following parameter for reducing, e.g. optimizing, the power consumption of the subsystems: [0078] measured network traffic load from each ATCA subsystem 518, including signaling and user data traffic loads, [0079] estimations and projections of network traffic load based on profiles of mobile user behavior and knowledge of the network states: For example, the estimations may comprise that the traffic load is decreasing during night. The estimations and projections of network traffic load may be used to evaluate whether a determined solution or configuration of the total system power optimization problem solver 512 may affect network stability. [0080] measured processor load of pat least a part or all of the processing units in each ATCA subsystem, [0081] processing load-power consumption characteristics for at least one or each subsystem in the ATCA system: The characteristics may be actual measurements or projected profiles, e.g. estimations; [0082] an ATCA system configuration including specific deployment types and/or modes of operations of at least one or each ATCA subsystem, [0083] specific performance targets such as desired availability, target quality of service per traffic profile, system capacity and/or network throughput etc. [0084] any constraints such as limitations on the total power consumption and/or limitations on the maximum allowed processing load per ATCA subsystem [0085] any operational and/or technical specification differences between the various ATCA subsystems [0086] any technical constraints regarding the type of network traffic, e.g. signaling or data and application type such as traffic analysis, specific routing functionality, traffic monitoring, content caching etc., and how such traffic may be handled and transferred from one ATCA subsystem to another, e.g. limitations and/or delays etc., in case of e.g. switchovers. This parameter may help to program actions for preserving system stability and may minimize any user-experience outage.

[0087] FIG. 6 shows an exemplary block diagram 600 comprising an extended power optimization module 602. The extended power optimization module 602 may include one or more submodules or units which may operate in a sequential or in a parallel order: [0088] A subsystem load and subsystem power consumption collector submodule 620 which may collect measurements of load, e.g. traffic load, signaling load, and/or CPU load, and/or power consumption from at least a part or all of the subsystems. [0089] A subsystem profile collector submodule 622 which may collect profiles for at least a part or all of the subsystems, such as load/power profiles in e.g. look-up table, curve or other form, from internal or external databases 609. The profiles may be pre-defined according to a specification of a subsystem. [0090] A network traffic profile and operator policy collector submodule 624 which may collect traffic profiles, e.g. statistics for each time of the year, and/or operator policies, including functionality, configuration changes and/or traffic shaping, which might affect the load and power consumption of the system and subsystems, from internal and/or external databases 609. Network traffic profiles and/or operator policies may be defined and provided by an operator of the ATCA system. [0091] A predictor submodule 626 which may predict or estimate a future load for each subsystem in any detail required by the following modules. [0092] A system hysteresis/delay and system stability evaluator submodule 628 which may evaluate the current and future stability of the system in terms of overload conditions, e.g. overload thresholds. The system hysteresis/delay and system stability evaluator submodule 628 may use historical data and/or observation data taken from any internal and/or external database 609 and may also update this database if needed. [0093] A total system power optimization problem formulator submodule 610 which may formulate the optimization problem of minimizing total system power consumption. [0094] A total system power optimization problem solver submodule 612, which may solve, using any suitable algorithm or procedure, the optimization problem formulated by the total system power optimization problem formulator submodule 610. [0095] A solution evaluation module 614 which may evaluate the suitability of the solution produced by the optimization problem solver 612, taking into account at least some or all the information gathered by the system data collector 620 and may decide whether this solution may suitable for application to the system with respect to e.g. network stability. By evaluation the solution according to e.g. network stability, unstable extreme situation of enabling/disabling subsystems continuously may be avoided. [0096] A system configuration enforcer 616 which may apply the selected solution (if any) from the previous module to at least a part or all of the subsystems. For example, the system configuration enforcer 616 may send system commands, e.g. a command for disabling a subsystem to a particular subsystem.

[0097] FIG. 7 shows an exemplary flow chart 700 of the power optimization module 502. Once the power optimization module 502 is started, e.g. triggered 702, by any other entity or component, the power optimization module may start collecting system data (step 704). In the following steps, the optimization problem may be formulated 706 and solved 708.

[0098] The solution may then be evaluated 710 for its stability and feasibility. If the solution might not be deemed as suitable or stable, the whole process/method may conclude 714 without applying the solution since the solution might affect system stability and/or network stability. Otherwise, if the solution may be deemed suitable, the solution may be enforced/applied 712 to the system and at least a part or all of its subsystems and a transition phase for the system state begins during which the system may remain fully operational. After enforcing the solution, the method may terminate/end 714.

[0099] FIG. 8 shows an exemplary flow chart 800 of an optimization problem formulator module 510. After starting 802 the optimization problem formulator module 510, at least some or all available data may be collected 804. Upon collecting 804 some or all available data, the optimization problem constraints may be defined 806 and evaluated. In addition, the objective function of the optimization problem may be formulated 808. Thus, all the pre-processing steps necessary as input to the optimization problem solver 512 may be completed so that the method of the optimization problem formulator module 510 may terminate/end in step 810.

[0100] FIG. 9 shows an exemplary flow chart 900 of an extended power optimization module. Once the power optimization module is started, e.g. triggered 902 by any other entity and/or component, the power optimization module may start collecting 904 system data. In addition, other parameters and/or data, e.g. external parameters, may be gathered/collected 916 such as operator policies, traffic profiles, etc. In the next step, a future state of the system and a future value of system parameters may be predicted 914. Then, the procedure may ascertain 920 that the system is currently stable. The term “stable” may be specified as meeting a predefined stability criterion. For example, the predefined stability criterion may refer to a time interval in which a particular value of a time trend may show a steady state. If the system is predicted to be not stable, the procedure may be terminated. If the system is stable, the optimization problem may be formulated 906 and then solved 908. The solution may then be evaluated 910 for its stability and feasibility. If the solution is not deemed as suitable/stable, the whole process concludes 914 without applying the solution since the solution may affect system stability. Otherwise, if the solution is deemed suitable, the solution may be enforced/applied 912 to the system. For example, ATCA subsystems may be signaled by the shelf manager to go into a standby state or wake up from a standby state. Further, at least a part or all of the subsystems may be in a transition phase when a change of the system state begins during which the system may remain fully operational.

Optimization Problem Formulation

[0101] In the following, an exemplary formulation of an optimization problem is described which may consider some or all of the following parameters:

[0102] The measured network traffic load from at least one or each ATCA subsystem (including signaling and user data traffic loads).

[0103] Estimations and/or projections of network traffic load based on profiles of mobile user behavior and knowledge of the network states.

[0104] The measured processor load of at least one or all of the processing units in at least one or each ATCA subsystem.

[0105] The processing load-power consumption characteristics for each subsystem in the ATCA system. The characteristics may be actual measurements and/or projected/estimated profiles.

[0106] The ATCA system configuration including specific deployment types and/or modes of operations of at least one or each ATCA subsystem.

[0107] Specific performance targets such as desired availability, target quality of service (QoS) per traffic profile, system capacity and/or network throughput.

[0108] Any constraints such as limitations on the total power consumption and/or limitations on the maximum allowed processing load per ATCA subsystem.

[0109] Any operational and/or technical specification differences between the various ATCA subsystems.

[0110] Any technical constraints regarding the type of network traffic, e.g. signaling or data and application type such as traffic analysis, specific routing functionality, traffic monitoring, content caching etc., and how such traffic can be handled and transferred from one ATCA subsystem to another, limitations, delays etc., in case of e.g. switchovers.

[0111] For formulating the optimization problem, it is assumed that the system, in particular the telecommunication system, may comprise N subsystems. The power optimization module may aim to minimize the total system power consumption by formulating an objective function under specific constraints. The objective function as defined below may represent an exemplary objective function out of a plurality of objective functions comprising variables regarding power, load, and/or scheduling constraints. The variables of the objective function may be adapted to specific system constraints, e.g. available and/or measured system constraints of at least a part of the N subsystems.

[0112] The objective function may be formulated as follows:

[00001]$\underset{\underset{\_}{c},\underset{\_}{x}}{\min }.Math..Math.P_{\mathrm{tot}}\left(\underset{\_}{x}\right)=\mathrm{.Math.}.Math.\underset{i=1}{\overset{N}{.Math.}}.Math..Math.P_{\mathrm{st}}^{\left(i\right)}.Math.c_i+\left(1-\mathrm{.Math.}\right).Math.\underset{i=1}{\overset{N}{.Math.}}.Math..Math.P_{\mathrm{xs}}^{\left(i\right)}\left(x_i\right)$

[0113] subject to the following constraints:

[00002]$i\in \left\{1,\mathrm{.Math.},N\right\}$$x_i\in \left[0,100\right].Math.\text{:}.Math.\%.Math..Math.\mathrm{CPU}.Math..Math.\mathrm{load}.Math..Math.\mathrm{of}.Math..Math.\mathrm{subsystem}.Math..Math.i$$\underset{\_}{x}={\left[x_i.Math.\mathrm{.Math.}.Math..Math.x_N\right]}^T$$c_i\in \left\{0,1\right\}$$\underset{i=1}{\overset{N}{.Math.}}.Math..Math.c_i\ge 1$$\underset{\_}{c}={\left[c_1.Math.\mathrm{.Math.}.Math..Math.c_N\right]}^T$

[0114] ε∈ (0,1): is used to prioritize the first term over the other and vice versa

P.sub.xs.sup.(i)∈[0, P.sub.max.sup.(i)−P.sub.st.sup.(i)], ∀i ∈ {1, . . . N}

x.sub.i≦τ.sub.i, τ.sub.i∈(0,1], ∀i

τ.sub.i:overload threshold.

[0115] According to the above formulation, the total system power may be defined as a weighted sum of two semi-independent terms. This first term may be the constant P.sub.st.sup.(i), which may represent the standard power consumption of subsystem i when it may be active but might not process any traffic load (idle state). The second term, P.sub.xs.sup.(i) (x.sub.i), may be the excess power that subsystem i may consume when it processes traffic load. The second term may be a function of load, e.g. a function of CPU load x.sub.i, and/or a function of traffic load.

[0116] Variable c.sub.i may be a scheduling variable for at least one or each subsystem i. The variable c.sub.i may take binary values, i.e. zero or one, for disabling or enabling a subsystem respectively. When the variable c.sub.i is equal to zero, the variable c.sub.i may eliminate the first term. When a subsystem is chosen to be deactivated, the excess power term, i.e. the second term, may also be eliminated since its' CPU load will be zero. The sum

[00003]$\underset{i=1}{\overset{N}{.Math.}}.Math..Math.c_i\ge 1$

may indicate that at least one subsystem should be active in order to avoid the extreme case of powering off all subsystems of the system.

[0117] Furthermore, P.sub.xs.sup.(i) (x.sub.i) cannot be greater than P.sub.max.sup.(i)−P.sub.st.sup.(i), where P.sub.max.sup.(i) may be the maximum power consumption of a subsystem at full load, e.g. full CPU and/or full traffic load. The maximum power consumption may be provided by the subsystem manufacturer.

[0118] The constraint x.sub.i≦τ.sub.i, τ.sub.i∈ (0,1], ∀i may indicate that the allocated load, e.g. the allocated CPU load, to any subsystem i should not exceed a predefined or configurable overload threshold τ.sub.i. The overload threshold may provide the advantage that a subsystem below the overload threshold may be defined as a stable subsystem.

[0119] In the optimization problem as described above, the optimization variables, i.e. the variables that may be found to contribute to the optimal solution by solving the optimization problem, may be x=[x.sub.i. . . x.sub.N].sup.T and c=[c.sub.1 . . . c.sub.N].sup.T. More specifically, the solution may choose to enable or disable each subsystem and may distribute the traffic load accordingly. In this respect, it is noted that x=[x.sub.i . . . x.sub.N].sup.T, i.e. the CPU load, may be exemplary defined as a result of traffic load processing. The second variable, i.e. c=[c.sub.1 . . . c.sub.N].sup.T, may be considered as auto-adjustive. When the ATCA system operates in a load balancing mode, the traffic load may be distributed among at least a part or all of the active subsystems equally by the network. An equally distributed traffic load may also result in an equally distributed CPU load among at least a part or all of the subsystems. In other words, the optimization problem may provide a solution regarding how to distribute the load.

[0120] The above optimization problem may be a combinatorial optimization problem and may be solved using any available algorithm/solver. Examples of such algorithms may be simplex and interior point algorithms. When at least a part or all of the subsystems are identical, the above optimization problem may be solved with significantly less complexity, i.e. may be solved in polynomial time.

[0121] In small scale systems, in particular ATCA systems, which may include less than 50 subsystems, the optimization problem may be solved via enumeration. The power optimization module may solve the optimization problem and may compute the objective function for all of the possible subsystem combinations by tweaking or toggling the respective binary optimization variables c=[c.sub.1 . . . c.sub.N].sup.T. The complexity may grow exponentially with the number of subsystems, but the complexity might not significantly influence the computational time required for solving the objective function in dimensions less than 50 subsystems. Moreover, optimization module might not be triggered very frequently, since the network may need several minutes to come to a steady or stable state. For example, the optimization module may be triggered once or twice a minute or every 1, 2, 3 . . . 10 minutes.

Examples of Formulating and Solving the ATCA Total Power Optimization Problem According to the Power Optimization Module

[0122] The following examples show how the power optimization module may be applied to telecommunication systems and, in particular, to ATCA systems.

[0123] In a first example, an ATCA system may comprise a small number of subsystems where only the ON/Standby state of each ATCA subsystem may be managed. This system may have the lowest complexity in terms of power/load/traffic management.

[0124] The first example may consider an ATCA system operating in a mobile data network during low data traffic hours, e.g. at night. The specific network setup, in particular the ATCA configuration, may employ 4 subsystems, e.g. 2 active/serving subsystems and another 2 subsystems in standby mode, accommodating high availability services. Each subsystem may process traffic load up to 10 Gbps, which results in 20 Gbps total system capacity. At a specific time, the measured traffic that is processed in the ATCA system is 3 Gbps. Thus, 15% of total system capacity may be used and the rest of the computing power may be spent unreasonably. The power optimization module may deactivate 1 subsystem of the 2 active subsystems since the capacity of one subsystem may be enough to handle current traffic conditions. The power optimization may perform the following process as depicted in FIG. 5: [0125] 1. The system data collector 508 may gather/collect traffic and CPU load from all subsystems, e.g. subsystem 1 processes 1,2 Gbps traffic and its' CPU is 35% loaded etc. [0126] 2. The optimization problem formulator module 510 may map the collected measurements to the respective problem variables. [0127] 3. The problem solver 512 may solve the optimization problem. The algorithm which may used to solve the optimization problem may be subject to the system specifications of the subsystems of the one or more ATCA systems. For small dimension ATCA systems (up to 50 subsystems), exhaustive search may be used that may always yield the optimal solution in terms of maximum throughput and power consumption minimization. For systems comprising more subsystems, low-complexity algorithms may be used in order to ensure real-time solver response. A branch and bound method may be the best choice, since the branch and bound method may always yield the optimal solution of the system setup, e.g. ON/STANDBY subsystems and/or traffic load distribution among them. The branch and bound method may have reduced computational complexity as compared to an exhaustive search.

[0128] In the first example using 4 subsystems, the exhaustive search may be used. The optimization problem solver may examine all possible subsystem combinations to find the best subset in terms of total power consumption minimization. As specified by the optimization problem formulation, a weighted sum of constant standby power consumption along with the consumed processing power as a function of CPU load may be calculated for each possible subsystems subset. The subsystems subset with the smallest calculated value may be selected as the optimal solution and may be enforced via configuration commands to the ATCA system. For example, the solver 512 may select a pair of subsystems in the first example, e.g. 1 active subsystem and 1 subsystem in standby mode, since a single active subsystem may be able to handle the current traffic load and the power consumption or power cost of two active subsystems with low CPU load may be larger as compared to the power consumption or power cost of one active subsystem having increased CPU load. [0129] 4. The solution evaluation module 514 may act as a guardian/stabilization step that may prevent the systems to perform sequential configuration changes in traffic conditions of strong traffic load fluctuations without any stable evolution profile. The solution evaluation module may be implemented as a learning filter that may know whether the current network traffic conditions may be unstable in terms of load and may discard the optimization problem solution to prevent the power optimization module from changing system configuration, e.g. to switch ON and/or OFF subsystems. [0130] 5. As a last step, the solution enforcer, e.g. the system configuration enforcer 516, may map or transform the optimization problem solution to system configuration commands. For example, the system configuration commands may switch off subsystems which might not be required to handle traffic load. The solution enforcer module may operate as part of the shelf manager that may be located internally or externally of the one or more ATCA systems.

[0131] In a second example, the total power consumption of the ATCA system may be minimized by optimally balancing the CPU load and/or traffic load for each one of the ATCA subsystems in real-time as a final product of the solution of the optimization problem described previously. In other words, the optimization algorithm may choose how much traffic to allocate to each ATCA subsystem so that the sum of the power consumed by all subsystems may be reduced to a minimum.

[0132] The second example may consider an ATCA system configured with e.g. N=12 subsystems. One half of the subsystems may be configured to process and analyze mobile traffic and the other half of the subsystems may accommodate high availability services. During the day, network traffic load may vary, reaching high values during rush hours stressing the system to its limits, and dropping down to a low load level during e.g. night hours.

[0133] FIG. 10 shows an exemplary time line 1000 of power optimization processes of an ATCA system of the second example. In particular, the timeline shows a transition time interval where mobile users may start to log off the network at time t0 1002 and where a traffic load trend may be decreasing. At time t1 1004, a traffic burst may arrive and the ATCA system may operate for a while near its limits until mobile users may start gradually to decrease at time t2 1006 and only a few mobile users may be left online.

[0134] The method for reducing power consumption implemented in the power optimization module may perform the exemplary power optimization processes at times t0 to t2 as described below.

[0135] Mobile users may begin to log off the network at time t0. At time t0+t, where t may have an arbitrary value in the interval t0<t<t1, a particular amount of users may have already logged off the network. The power optimization module may be triggered and may perform the following process: [0136] 1. The system data collector 508 may collect measurements of traffic and/or CPU load from at least a part or all of the subsystems. [0137] 2. The optimization problem formulator module 510 may map the collected measurements to the respective problem variables. [0138] 3. The problem solver 512 may solve the optimization problem. At time t0, where some or all subsystems may be active but the traffic load may have decreased, the problem solver 512 may examine all possible subsystem combinations and may calculate the power consumption or the power cost subject to the objective function of the optimization problem. The algorithm may provide a solution for which only a subset of all subsystems may be required to handle the current network traffic load. The solution of the problem solver 512 may deactivate some subsystems and their standby pairs. Thus, the remaining active subsystems may operate with increased CPU and/or traffic load which may result in less total power consumption since the power cost of a fully loaded subsystem might not differ significantly from the power cost an idle subsystem. If the subsystems may comprise subsystems of an identical type, i.e. the hardware and/or the software configuration of the subsystems may be identical or almost identical, the traffic may be uniformly distributed among the subsystems of identical type. If the subsystems may comprise subsystem of different types, i.e. the hardware and/or the software configuration of the subsystems differ significantly, the problem solver 512 may provide a solution which may result in equal power consumption for each subsystem. The information regarding the hardware and/or the software configuration of the subsystems may be provided by the subsystem profile collector module 622 to the problem solver 612. For example, if the subsystem hardware is different for at least a part or all of the subsystems, the CPU load of each of the subsystems may vary and the traffic may be distributed to the different subsystems so that the CPU load of at least the part or all of the subsystems may be identical. [0139] 4. The solution evaluation module 514 may act as a guardian/stabilization step that may prevent the one or more systems, in particular the one or more ATCA systems, to perform sequential configuration changes in traffic conditions of strong traffic load fluctuations without any stable evolution profile. The solution evaluation module 514 may be implemented as a learning filter that may know whether the current network traffic conditions may be unstable in terms of load, e.g. network and/or traffic load, and may discard the optimization problem solution to prevent the power optimization module from changing the system configuration. When the traffic load trend is decreasing, the solution evaluation module 514 may allow the solution to be enforced in the ATCA system. [0140] 5. As a last step, the solution enforcer 516 may map or transform the optimization problem solution to system configuration commands. The system configuration commands may turn off subsystems that are chosen not to handle any traffic. The solution enforcer module 516 may operate at the shelf manager which may be located internally or externally of the one or more ATCA systems.

[0141] At time t1, the system, in particular the ATCA system, may operate with a number of subsystems turned off and the remaining subsystems may process the network traffic. If a traffic burst arrives and at least a part of the active subsystems may arrive at an overload state, the power optimization module 502 may be triggered. The power optimization module may perform the following process: [0142] 1. The system data collector 508 may gather/collect the traffic and/or CPU load from at least a part or all of the active subsystems. [0143] 2. The optimization problem formulator module 510 may map the collected measurements to the respective problem variables of the optimization problem. In this respect, it is noted that the deactivated subsystems may also be taken into account in the objective function calculation. In order to compute the optimal solution, the optimization problem may have to know all parameters of the optimization problem which may include also the parameters of the deactivated subsystems. [0144] 3. The problem solver 512 may solve the optimization problem. If the gathered/collected subsystem parameters may violate the optimization problem constraints, e.g. the constraint CPU load<100%, more subsystems may have to be activated in order to process current traffic needs. Again, the deployed algorithm may yield a solution that may specify the exact number of active subsystems and their standby pairs that may be needed to process network traffic without violating optimization problem constraints, e.g. system constraints such as CPU load<100% and P<Pmax per subsystem. The algorithm may examine at least a part or all of possible subsystem combinations and may find the combination that may result to the smallest objective function value, i.e. the result which may use the minimum number of active subsystems and which may choose those subsystems that may consume the lowest power consumption for processing current traffic demands. [0145] 4. The solution evaluation module 514 may recognize the increasing trend of network traffic and may allow the solution yielded by the solver to be enforced to the ATCA system in order to accommodate mobile users' needs. [0146] 5. The solution enforcer, e.g. the system configuration enforcer 516, may map the yielded solution to system configuration commands. For example, the system configuration commands, when executed, may switch on the excess subsystems needed for handling the current traffic needs.

[0147] After the burst of traffic and the system adaptation to network needs at time t1, mobile users may start to log off the network massively at time t2. The CPU load of the operational subsystems may start to drop down again. At time t2+t, where t is the time when the power optimization module 502 is triggered, the power optimization module 502 may perform the following process: [0148] 1. The system data collector 508 may gather/collect the traffic and/or CPU load from at least a part or all of the active subsystems. [0149] 2. The optimization problem formulator module 510 may map the collected measurements to the respective problem variables. [0150] 3. The problem solver 512 may solve the optimization problem. This situation may be identical with the situation at time to. In particular, more subsystems than needed may be active and may operate at very low CPU load. Current network needs might be handled by less active subsystems that may operate at higher CPU load. As described earlier, subsystems operating at full load may consume only slightly more power than subsystems which are active and idle. The algorithm may examine all possible subsystem combinations and may select the subsystem combination which results in the smallest objective function value, i.e. the smallest total power consumption. [0151] 4. The solution evaluation module 514 may recognize the decreasing trend of network traffic and may allow the solution yielded by the solver to be enforced to the ATCA system in order to optimize hardware resources usage. [0152] 5. The solution enforcer, e.g. the system configuration enforcer 516, may map the yielded solution to system configuration commands. For example, the system configuration commands may deactivate subsystems which the optimization problem solver 512 has selected as not needed for handling current network traffic demands.

[0153] In any one of the above cases, the power management module, e.g. the power reduction module or the power optimization module 502, may incorporate information on cooling systems (air conditioning, ventilation etc.) and may also decide and enforce suitable configurations on such cooling systems. Further, user sessions, e.g. control plane signaling, may be transferred from one subsystem which may be disabled to another subsystem which may remain active. The user session may be transferred from one subsystem which may be disabled to another system which may remain active without a connection loss or a system outage observable to a user.

[0154] It should be noted that the term “comprising” does not exclude other elements or steps and the use of articles “a” or “an” does not exclude a plurality. Also elements described in association with different embodiments may be combined. It should also be noted that reference signs in the claims should not be construed as limiting the scope of the claims.

[0155] In order to recapitulate the above described embodiments of the present invention one can state:

[0156] The embodiments of the present invention may provide decision elements to decide how to allocate traffic handling among ATCA subsystems and their processing units in an ATCA telecommunication system while minimizing the total power consumption of the ATCA system. This may be performed by enabling/disabling ATCA subsystems that might not be needed for processing the current traffic amount served by the ATCA system.

[0157] Further, the embedment of the present invention may address the problem of inefficient power utilization in modern ATCA systems. By formulating the ATCA total system consumption as an optimization problem, a method which may be provided which may consider the system load, the current system state (e.g. traffic, number of network connections etc.), the relation between various system states regarding total power consumption and future predictions of resource requirements. In particular, the method may re-configure resource allocation (power, traffic scheduling etc.) among the ATCA subsystems thereby achieving minimum power consumption.

LIST OF REFERENCE SIGNS

[0158] 100 telecommunication system [0159] 102 ATCA system [0160] 104 system manager [0161] 106 interconnected blades [0162] 108 shelf manager [0163] 110 intelligent platform management bus [0164] 112 intelligent platform management interface [0165] 200 ATCA system [0166] 202 power optimization module [0167] 208 shelf manager [0168] 300 ATCA system [0169] 302 power optimization module [0170] 400 ATCA system [0171] 402 power optimization module [0172] 404 system manager entity [0173] 500 block diagram [0174] 502 power optimization module [0175] 504 power optimization module scheduler [0176] 506 trigger signal [0177] 508 system data collector [0178] 509 internal or external databases [0179] 510 total system power optimization problem formulator [0180] 512 total system power optimization problem solver [0181] 514 solution evaluation module [0182] 516 system configuration enforcer [0183] 518 subsystem [0184] 600 block diagram [0185] 602 power optimization module [0186] 604 power optimization module scheduler [0187] 609 internal or external database [0188] 610 total system power optimization problem formulator [0189] 612 total system power optimization problem solver [0190] 614 solution evaluation module [0191] 616 system configuration enforcer [0192] 618 subsystem [0193] 620 subsystem load and subsystem power consumption collector module [0194] 622 subsystem profile collector submodule [0195] 624 network traffic profile and operator policy collector submodule [0196] 626 predictor submodule [0197] 628 system hysteresis and system stability evaluator module [0198] 700 flow chart [0199] 702 receive trigger signal [0200] 704 collect system data [0201] 706 formulate optimization problem [0202] 708 solve optimization problem [0203] 710 evaluate stability of a solution [0204] 712 enforce system configuration [0205] 714 terminate process [0206] 800 flow chart [0207] 802 start optimization problem formulator module [0208] 804 collect available data [0209] 806 formulate constraints [0210] 808 formulate objective function [0211] 810 terminate optimization problem formulator module [0212] 900 flow chart [0213] 902 receive trigger signal [0214] 904 collect system data [0215] 906 formulate optimization problem [0216] 908 solve optimization problem [0217] 910 evaluate stability of a solution [0218] 912 enforce system configuration [0219] 914 terminate process [0220] 916 collect external parameter data [0221] 918 predict future parameters [0222] 920 evaluate system stability [0223] 1000 time line [0224] 1002 time t0 [0225] 1004 time t1 [0226] 1006 time t2

LIST OF ABBREVIATIONS

[0227] AMC : Advanced Mezzanine Card [0228] ATCA : Advanced Telecommunications Computing Architecture [0229] BSC : Base Station Controller [0230] CAPEX : Capital Expenses [0231] CO2 : Carbon Dioxide [0232] CPU : Central Processing Unit [0233] ePDG : Evolved Packet Data Gateway [0234] FRU : Field Replaceable Unit [0235] GGSN : Gateway GPRS support node [0236] GMSC : Gateway Mobile Switching Center [0237] IETF : Internet Engineering Task Force [0238] IPMB : Intelligent Platform Management Buses [0239] IPMI : Intelligent Platform Management Interface [0240] ISO : International Organization for Standardization [0241] LTE : Long-Term Evolution [0242] MME : Mobility Management Entity [0243] MSC : Mobile Station Controller [0244] OPEX : Operating Expenses [0245] PGW : Packet Data Network Gateway [0246] PICMG : PCI Industrial Computers Manufacturers Group [0247] RMCP : Remote Management Control Protocol [0248] RNC : Radio Network Controller [0249] RTM : Rear Transition Module [0250] SAE : System Architecture Evolution [0251] SGSN : Serving GPRS support node [0252] SGW : Serving Gateway [0253] ShMC : Shelf management Controller [0254] SLA : Service Level Agreement [0255] SNMP : Simple Network Management Protocol [0256] TTG : Tunneling Termination Gateway