WO2011107163A1

WO2011107163A1 - A processing system with processing load control

Info

Publication number: WO2011107163A1
Application number: PCT/EP2010/052859
Authority: WO
Inventors: Andras Vajda; Kari-Pekka Perttula; Tuomas Erke; Dietmar Fiedler; Tohmas Vennberg
Original assignee: Telefonaktiebolaget L M Ericsson (Publ)
Priority date: 2010-03-05
Filing date: 2010-03-05
Publication date: 2011-09-09

Abstract

The invention relates to a processing system, comprising a set (101) of active processing entities (103) for task processing, a set (105) of standby processing entities (107), a processor (109) being configured to determine a cumulated processing load associated with the task processing by the set of the active processing entities, and to deactivate at least one active processing entity (103) of the set (101) of active processing entities if the cumulated processing load is smaller than or equal to a deactivation threshold, or to activate at least one standby processing entity (107) of the set (105) of standby processing entities if the cumulated processing load is equal to or greater than an activation threshold.

Description

TITLE

A processing system with processing load control TECHNICAL FIELD

The present invention pertains to controlling the processing load in processing systems, in particular in hierarchically organized processing systems. BACKGROUND

Energy consumption is one of the key factors impacting the operational expenses (OPEX) related to data centers, computing clusters and telecommunication infrastructure. At global scale, ICT is already responsible for 2% of the world's energy consumption, of which 0.6% is generated by telecommunications. Power efficiency in clusters and data centers is therefore one of the key research topics with immediate impact for the cost structure of data center or telecommunications providers deploying telecommunication infrastructure nodes for providing telecommunication services.

Telecommunication infrastructure nodes in general have a multi-rack, multi-blade architecture, with usually specialized blades, tailored for various functions such as digital signal processing, packet handling, control software etc. Large

telecommunication nodes usually contain processor systems with tens to hundreds of processors of various types, with thousands of processor cores, interconnected using multiple networks with various topologies. In fact, a telecommunication node is a computing cluster custom built to fulfill a specialized role. From software architecture perspective, telecommunication infrastructure nodes are often built as hierarchical processor systems, where higher level software components, which are executed on one set of processors, control and manage lower level components, which are usually executed on another set of processors. Lower level components are usually handled in pools of resources and used by higher level components to fulfill certain tasks. In such systems, a setup of a user session, for example, is gradually divided into smaller and smaller tasks which are handled by lower level software and hardware components. The hierarchical software architecture of the system also supports the non-uniform nature of the interconnect network between the cluster nodes, where e.g. a bandwidth between two blades located in the same rack may be higher than a bandwidth between two blades located in different racks.

The performance of a telecommunication node is usually expressed in terms of maximum simultaneous user sessions, e.g. voice calls or data connections, maximum bandwidth which may e.g. be defined in a total or maximum per user connections, and maximum session setup/tear-down rate. Based on these characteristics, the networks are usually dimensioned for a typical worst case scenario in order to ensure processing the typical maximum load which may be estimated by the network operator in terms of e.g. simultaneous user sessions, bandwidth or session setup/tear-down rate. If the actual load is above these levels, overload protection mechanisms are usually deployed in order to gracefully discard traffic that cannot be handled reliably, while maintaining the quality of service of sessions that do get processed.

In practice, however, the load in a telecommunication network varies over time. By way of example, the business district of a large city may be considered: the load is likely to be highest during office hours, e.g. peaking at near 100% of maximum capacity, while during the night and weekends the load will probably be low, e.g. below 10% of maximum capacity. However, a reduction of the maximum

engineered capacity is not always possible as it may result in a capacity which is below the maximum load in the network and, consequently, in a possibility of rejecting user sessions. Accordingly, there is a need to power-efficiently operate a processor system.

SUMMARY

The invention is based on the finding that a processor system with a plurality of processors may efficiently be operated when processors of the system are activated or deactivated such that a cumulated processing load which is associated with performing one or more processing tasks by the processor system is within a predetermined processing load range.

The predetermined processing load range may e.g. be defined by an activation threshold, at which at least one processor is to be activated to reduce the average load per active processor, and by a deactivation threshold at which one or more processors are to be deactivated in order to e.g. increase the average load per active processor. Thus, a power consumption of a computing cluster may automatically be adjusted in dependency on the actual computational load while guaranteeing that the required in-service performance indicators are met. According to an aspect, the invention relates to a processing system comprising a set of active processing entities for task processing, a set of standby processing entities, and a processor being configured to determine a cumulated processing load associated with the task processing by the set of the active processing entities. The processor is further configured to deactivate at least one active processing entity of the set of active processing entities if the cumulated processing load is smaller than or equal to a deactivation threshold, and/or to activate at least one standby processing entity of the set of standby processing entities if the cumulated processing load is equal to or greater than an activation threshold. The cumulated processing load may be defined by a sum of processing loads per active processor. By way of example, the cumulated processing load may be related to a ratio between the total processing load summed over the processing loads of all active processors and the number of active processors. However, also other cumulated load measures may be deployed.

According to an embodiment, the processor may be configured to deactivate a first predetermined number of active processing entities if the cumulated processing load is smaller than or equal to the deactivation threshold, the first predetermined number being chosen such that the resulting cumulated processing load upon deactivating the first predetermined number of active processing entities is smaller than or equal to the activation threshold, or to activate a predetermined number of standby processing entities if the cumulated processing load is equal to or greater than the activation threshold, the second predetermined number being chosen such that the resulting cumulated processing load upon activating the second predetermined number of standby processing entities is equal to or greater than the deactivation threshold. In order to choose or to determine the predetermined number, the processor may emulate behaviour of the processing system by e.g. iteratively calculating a resulting cumulated load when activating or deactivating processing entities.

According to an embodiment, the processor may be configured to estimate an expected cumulated processing load as the cumulated processing load upon the basis of a task request, the task request requesting to process a further task. The task request may e.g. originate from e.g. a higher processing level in particular in a hierarchical processing scenario. Generally, the task request may be received by the processor from another processing entity which requests the active processing entity to process the further task.

According to an embodiment, the active processing entities may respectively be configured to indicate a processing load associated with processing a task by a respective active processing entity to the processor, and wherein the processor is configured to determine the cumulated processing load upon the basis of the indicated processing loads. In order to indicate the respective processing load, the active processing entities may, respectively, transmit an information signal towards the processor.

According to an embodiment, the processor may be configured not to activate any further processing entity if the set of standby processing entities is empty and if the cumulated processing load is equal to or greater than an activation threshold. The further processing entity may be e.g. a processing entity associated with another processing level e.g. in a hierarchical processing scenario. Thus, the processor may only activate or deactivate as many processing entities as comprised in the respective set of processing entities.

According to an embodiment, the processor may be configured to switch a standby processing entity into an active mode in order to activate the standby processing entity for task processing, and to assign the activated processing entity to the set of active processing entities.

According to an embodiment, the processor may be configured to switch an active processing entity into a standby mode in order to deactivate the active processing entity, and to assign the deactivated processing entity to the set of standby processing entities.

According to an embodiment, the processor may be configured to determine which standby processing entity is to be activated, and which task is to be processed by the standby processing entity which is to be activated. In order to determine which standby processing entity is to be activated, the processor may determine which standby entity may process the requested task with a minimum load. In other words, the processor may determine which standby entity may more efficiently process the requested task than another standby entity in the set of standby entities. According to an embodiment, the processor may be configured to determine a certain active processing entity which is processing a task at a processing load which is lower that a processing load of another active processing entity in the set of active processing entities, and to deactivate the certain active processing entity if the cumulated processing load is smaller than or equal to the deactivation threshold. The deactivation may take effect only after all tasks performed by the selected processing entity are finished or moved to other processing entities.

According to an embodiment, the processor may be configured to deactivate an active processing entity based on at least one of the following policies: immediate forceful termination of all tasks, upon expiration of a grace period being

determined by a timer, followed by forceful termination of remaining tasks, or upon normal termination of all processing tasks. According to an embodiment, the processor may be configured to deactivate the set of active processing entities upon receiving a request signal requesting a deactivation of the set of active processing entities. Thus, the processor may completely deactivate or active processing entities upon request. According to an embodiment, the set of active processing entities and the set of standby processing entities may be arranged to form a first processing entity group being associated with a first processing level of a hierarchical processing arrangement, wherein the processing system comprises a further set of active processing entities for further task processing and a further set of standby processing entities which are arranged to form a second processing level of the hierarchical processing arrangement. The processing system may further comprise a further processor for determining a further cumulated processing load associated with the further task processing by the set of the active processing entities, wherein the further processor may be configured to deactivate at least one active processing entity of the further set of active processing entities if a further cumulated processing load is smaller than or equal to a further deactivation threshold, and/or to activate at least one standby processing entity of the further set of standby processing entities if the cumulated processing load is equal to or greater than an activation threshold. Thus, the processing system may comprise several processing levels of the hierarchical processing arrangement, wherein each processing level may comprise active processing entities, standby

processing entities and a processor associated therewith. Correspondingly, the tasks to be processed by a processing level may be provided for processing by a higher processing level of the hierarchical processing arrangement. According to an aspect, the invention relates to a telecommunication network node comprising the processing system for processing communication tasks.

According to an aspect, the invention relates to a method for controlling a processing load of a processing system, the processing system comprising a set of active processing entities for task processing, and a set of standby processing entities. The method comprises determining a cumulated processing load associated with the task processing by the set of the active processing entities, deactivating at least one active processing entity of the set of active processing entities if a cumulated processing load is smaller than or equal to a deactivation threshold, or activating at least one standby processing entity of the set of standby processing entities if the cumulated processing load is equal to or greater than an activation threshold. Further method steps are directly derivable from the functionality of the processing system or of any entity described in connection therewith.

According to an aspect, the invention relates to a computer program for performing the method for controlling a processing load of a processing system.

BRIEF DESCRIPTION OF THE DRAWINGS Further embodiments will be described with reference to the following figures, in which:

Fig. 1 shows a processing system according to an embodiment;

Figs. 2a - 2c show a hierarchical processing system according to an embodiment;

Fig. 3 shows a telecommunication network node according to an embodiment; Fig. 4 shows a communication network node according to an embodiment; and

Fig. 5 shows a flow diagram of a method for controlling a processing load according to an embodiment. DETAILED DESCRIPTION

Fig. 1 shows a processing system comprising a set 101 of active processing entities 103. Furthermore, the processing system comprises a set 105 of standby processing entities 107. A processor 109 is provided in order to determine a cumulative processing load associated with task processing by the set 101 of active processing entities 103. In particular, the processor 109 is configured to deactivate at least one active processing entity 103 of the set 101 of active processing entities if the cumulated processing load is smaller than or equal to a deactivation threshold. Correspondingly, the processor 109 may activate at least one standby processing entity 107 of the set 105 of standby processing entities 107 if the cumulated processing load is equal to or greater than an activation threshold. The processing system of Fig. 1 may be configured for hierarchically processing tasks. Thus, the processing system may comprise a further set 1 1 1 of active processing entities 1 13 for further task processing and a further set 1 15 of standby processing entities 1 17. Furthermore, a further processor 1 19 is provided for determining a further cumulated processing load associated with the further task processing by the further set 1 1 1 of the active processing entities 1 13. In particular, the processor is configured to deactivate at least one active processing entity 1 13 of the further set 1 1 1 of active processing entities if a further cumulated processing load is smaller than or equal to a further deactivation threshold.

Correspondingly, the further processor 1 19 may be configured to activate at least one standby processing entity 1 17 of the further set 1 15 of standby processing entities if the cumulated processing load is equal to or greater than an activation threshold. By way of example, the set 101 of active processing entities 103 and the set 105 of the standby processing entities 107 are arranged to form a first processing entity group being associated with a first processing level of the hierarchical processing arrangement. Correspondingly, the further set 1 1 1 of active processing entities and the further set 1 15 of standby processing entities may form a second processing level of the hierarchical processing arrangement. Thus, the processor 109 and 1 19 may communicate with each other so that e.g. the processor 109 may request the processor 1 19 to perform a certain processing task by the entities associated therewith, or vice versa. Figs. 2A - 2C show an embodiment of a distributed, hierarchical processing, i.e. computing system, where higher level components control or use services from lower level components.

The processing system comprises, by way of example, three processing levels with level 0 resources 201 comprising components 201 a to 201 f, which are controlled by a set of level 1 components 203 comprising components 203a to 203c. The level 1 components 203a to 203c may be owners of the level 0 components 201 a to 201 f belonging to a set 203 of level 0 components and provide surfaces to other levels of which level 2 components 205a to 205b may be the users of the services provided by level 1 components 203a to 203c. The level 2 components may belong to a set 205 of level 2 components. These components may use all or some of the components at level 1 . Correspondingly, level 3 components 207 are provided which may be the users of level 2 components 205a to 201 b. As shown in Fig. 2a, each component of a certain level communicates with each component of the level above and below the certain levels. The level components may be, by way of example, processing entities such as processors of processing boards.

Fig. 2B shows, by way of example, the processing system of Fig. 2A at the usage level of 20% with three levels of resources. Dashed nodes are in active mode. As depicted in Fig. 2B, by way of example, the level 0 components 201 may comprise active processing entities 209a, 209b, and inactive processing entities 21 1 a to 21 1 d which are e.g. in a power-save mode. Correspondingly, the level 1 components 203 may comprise an active processing entity 213 and inactive, i.e. standby, processing entities 215a and 215b. Correspondingly, the level 2 components 205 may comprise an active processing entity 217 and an inactive processing entity 219. The level 3 component 207 may be, by way of example, in its active state.

Fig. 2C shows a mode of the processing system of Fig. 2A at 60% usage level.

Fig. 3 shows a front view 301 and a rear view 303 of a telecommunication network node for e.g. a telecom switch with a plurality of modules 305 - 315.

Fig. 4 shows an example of a module with a plurality of switch boards 401 a to 401 c, IF boards 403a to 403c, device boards 405a to 405I or control processor boards 407a and 407b.

With reference to Figs. 3 and 4, the power save algorithm according to some could be applied in a telecom switch. Telecoms switches are normally delivered in cabinets with front and rear view. These cabinets host several hardware modules with different purpose as demonstrated in Fig. 3, wherein each module suits its own purpose.

In this regard, device boards are boards for executing the actual user data processing, such as speech processing. Those are the boards where the user data is transported and manipulated. Those boards are normally equipped with specialized hardware e.g. DSP, ASICS, FPGA or other specialized processors. Interface boards are boards for terminating a certain external interface towards the Telecom equipment. Those can e.g. be for ATM IP or TDM transport. Control processor boards are boards which are normally equipped with a more powerful processor for general purpose execution. Those processors could be Power PCs or X.86 based processors. Those processors are normally used for call setup and release procedures, resource handling, possible control protocol encoding and decoding and many other tasks. Switch boards are boards which interconnect the different modules together.

In such systems, a hierarchical structure of processors is provided where some processors use other processor to distribute tasks, in case of telecom equipment phone calls.

The Level 0 processors would be the processors on device boards and the If boards. Each phone call needs at least an incoming and an outgoing interface. For those purpose a processor/device on the interface boards must be allocated.

Furthermore each phone call may need some speech processing/manipulation which are executed on a device board. Therefore a device board may be necessary. The control processors boards contain the possible level 1 , 2 and 3 processes.

In Fig. 4, for e.g. Level 0 and 1 , the left Ctrl board would control the 7 Device boards and 2 interface boards and the right control board would control 7 device boards and 3 interface boards. During full traffic capacity all device boards and interface boards are fully utilized. But if the traffic goes under the defined threshold some of the interface boards and device boards would be put out of service. When the boards are out of service they consume less power.

Module 2, 4, 5 and 6 in Fig. 4, e.g. for Level 2, are modules which may be called device modules. Whereas module 3 would be configured with several control boards lets call them control module. The control module in module 3 would distribute the phone calls to one of the device modules via the control board in the device module.

If the control module notices that we have so little traffic in the system that a whole branch could be shut down it will do so. Therefore module 3 might shut down whole branches of processors, e.g. modules 2, 4 and 5.

A telecom system may consist of several cabinets, wherein, Level 3 may be considered by way of example. Therefore the module 1 could be a control module for all cabinets in the system. Thus, module 1 could shutdown a whole cabinet by not routing any new traffic to control module 3. Than, the modules 3, 2, 4, 5 and 6 would be out of traffic and another cabinet would handle the remaining traffic.

With reference to Figs. 1 to 4, a gap between engineered and real world usage while keeping the in-service performance characteristics of the system at the same level may be exploited. This can be achieved according to some embodiments through a dynamic, load-based scheduling method that can switch on and off processors in such a way that it can cater for fluctuations in load, while keeping the power usage at the lowest possible level.

With reference to Figs. 2a to 2c, a hierarchical, power-aware and load based scheduling may be performed. In this regard, resource management in telecommunication infrastructure nodes relies on policies that aim for distributing the load as evenly as possible across available resources, in order to minimize the impact of HW or SW failures (the less calls a certain HW or SW component handles, the lower the impact in case of failure). While this approach minimizes the impact in case of HW/SW failures, it also warrants that practically all components will be active all the time, reducing power efficiency and making power savings almost impossible, even at very low load levels.

Therefore, in order to be able to switch off parts of the system, the load needs to be concentrated to as few components as possible. Obviously, there has to be a trade-off between securing in-service performance and power saving. This trade off may be achieved according to the principles described herein.

According to some embodiments, the processing system may be described by a resource model, wherein an abstract resource model of the system on which we will apply our power-aware load-based scheduling method may be defined. In this context, the computational cluster may be structured into a tree with the following properties of processing entities, i.e. resources:

A terminal node is a resource that does not own any other resources; it is typically a processor or processor core that supports power saving modes of operation. A non-terminal node is a resource that itself owns and controls other resources, modeled as its sub-trees; a non-terminal node is typically a software component that may execute alone on a given processor or may be co-located with other software components. From resource management point of view, the best approach is either isolated execution or co-location with its sub-trees, typically on the same blade. These nodes may be called resource owners, while the resources controlled by these nodes form the resource pool of the node. Each resource may be active (powered on) or inactive (in power save mode). Fig. 5 shows, by way of example, a flow diagram of a method for controlling a processing load according to an embodiment. The method comprises determining 101 a cumulated processing load associated with the task processing by the set of the active processing entities, deactivating 103 at least one active processing entity of the set of active processing entities if a cumulated processing load is smaller than or equal to a deactivation threshold, and/or activating 105 at least one standby processing entity of the set of standby processing entities if the cumulated processing load is equal to or greater than an activation threshold.

In order to determine whether the cumulated processing load is smaller than or equal to a deactivation threshold, the method may comprise comparing 107 the cumulated processing load with the deactivation threshold. Furthermore, the method may comprise comparing 109 the cumulated processing load with the activation threshold 109 in order to determine whether the cumulated processing load is greater than or equal to the cumulated processing load. According to some embodiments, the step of comparing 107 the cumulated processing load with the deactivation threshold may be executed before or after the step of comparing 109 the cumulated processing load with the activation threshold. However, the steps 107 and 109 may simultaneously be executed. According to some embodiments, if a result of the comparison in step 107 indicates that the cumulated processing load is greater than the deactivation threshold, then the method may proceed with step 109. Correspondingly, if a result of the comparison in step 109 indicates that the cumulated processing load is smaller than the activation threshold, then the method may proceed with step 107.

According to some embodiments, certain rules related to active and inactive states. By way of example, at any given time, only powered on, i.e. active, resources may be used for processing. If a non-terminal node is inactive, all the nodes in its sub-trees may be inactive, i.e. in a standby mode. If a non-terminal node is active, it has at least one child node that is active. The different resource pools may have different restrictions. For example, for efficiency reasons, it may be advisable to have pools active in each rack in order to minimize inter-rack communication. These restrictions may be provided as attributes associated with non-terminal nodes of the resource model of the system and may be followed by the resource owners.

Further, a resource usage model may be provided which defines the model for using resources, which may be different from the resource control model. By way of example, the resource usage model may be defined as follows:

- Terminal resources may only be used by their respective resource owner; this guarantees single point of access to low level resources, and

- Non-terminal resources on level n (which own a pool) may be used by any other non-terminal resources from level n+1 ; this requirement guarantees that specialized pools (e.g. pools of resources in a rack) can be accessed whenever needed from anywhere else in the system. Obviously, only active resources may be used. According to some embodiments, a scheduling algorithm configuration may be employed. In this regard, the amount of active resources may dynamically be adjusted depending on the load in the system. When load increases, the amount of active resources may increase; when the load decreases, the amount of active resources may decrease.

By way of example, several parameters may be introduced that may drive the behavior of the system:

A load level may define an activation threshold at which more resources may be activated (highLoad). This parameter controls when resources may be activated in advance in order to cater for observed increasing load in the system. For example, let's assume that this parameter is set to 80%, there are 10 equal resources, i.e. processors forming processing entities, in the system and three out of these are active at a given time. When the aggregated load on those three active resources is at the 80% level, the resource management software, e.g. run on a processor, may activate one or several additional resources and make those available for processing tasks; in our case, if one resource is activated, the overall aggregated load would decrease to 60% and the newly activated resource will also be used for new tasks. A load level may define a deactivation threshold at which some active resources may be inactivated (lowLoad). This parameter controls when some of the active resources may be put into inactive state, as the load on the system does not justify so many active resources. For example, under the same assumptions as for the highLoad example, if this parameter is set to 40% and the number of active resources in three out of ten, inactivating one resource will result in an aggregated load of 60%, over two remaining active resources.

Furthermore, the amount of resources with which to increase / decrease the pool of active resources may be determined by the parameter "activeStep" forming an embodiment of the predetermined number. It may be given as absolute value or as percentage of e.g. a total capacity.

In order to avoid bouncing between low load and high load states, there may be some difference between lowLoad and highLoad and activeStep may be set so that it will not switch the system between low load and high load states for any set of active resources.

As to the scheduling algorithm, at every level of the resource management tree, the resource owner may have its pool partitioned into two sets: a set of active resources and a set of inactive resources. The set of active resources may e.g. be actively used for traffic. The set of inactive resources may form the set of standby processing entities in a powered down mode. Initially, for active pools, an activeStep amount of resources may be in active mode, while all other resources will be inactive. This is required in order to guarantee that new tasks can be served immediately. Each resource owner may be responsible for managing the resources in the resource pool it controls. There are three main cases that the resource owner may handle, detailed in the sections below. In a normal operating mode where aggregated load is between the deactivation and the activation threshold, each active resource, terminal or non-terminal, may be responsible for reporting its load status, e.g. usage percentage, to its resource owner whenever this changes as well as the percentage of the resources it controls that are in the active pool. The reason for change depends on the nature of the resource:

For terminal resources, the change is usually due to new tasks, finished tasks or changing computational requirement of active tasks. Terminal resources may always report 100% as the percentage of resources it controls that are in the active pool.

For non-terminal resources, the change is due to lower level resources in its active pool reporting changed load levels. Based on the reported load level, the nonterminal resource owner may re-calculate the aggregate load within the active pool it controls. This can be calculated as the arithmetical average of the load reported by the resources in its active pool:

Aggregated load = SUM(Resource Load) / N where N is the number of resources in the active pool. The load balancing policy within the active pool, under normal operation, may follow the rule of equal distribution, hence making sure that the available load is as equally shared as possible among active resources. When the aggregated load is over highLoad, i.e. deactivation threshold, e.g.

means when the load within an active resource pool exceeds the highLoad threshold, the resource owner for the pool may activate additional resources, according to the activeStep parameter's value. In case the pool controlled by the resource owner is completely in use, i.e. when e.g. all resources are active, crossing over the highLoad threshold will not trigger any additional action.

The activation of new resources may be performed in three steps:

The resource owner may select the inactive resources that may become active and will initiate the activation of these (switching from power save mode to active mode); how the switch on will happen is dependent on the actual HW system, OS support etc. Each activated resource may restore its operational state to a fully functioning one; as this may take some time, the resource may inform the resource owner as soon as it's ready to be used. Activated resources that are ready to be used are added to the active pool and will start receiving tasks, according to the load balancing policy

When the aggregated load is under lowLoad, i.e. the activation threshold, e.g. when the load within an active resource pool drops under the level set by the lowLoad parameter, the resource owner may de-activate some active resources. There are two issues that may be addressed in this regard:

- Which resources to de-activate, and

- How to handle the tasks executing on the selected resources. There are several strategies that may be used for selecting the active resources that may be inactivated: it may target the resources with the lowest load; it may also target resources which are likely to conclude their tasks fastest. In either case, de-activation may happen in a graceful manner, so that ongoing tasks can be concluded normally. The way this is done depends on the nature of the tasks and the actual cluster: tasks may be migrated or the system may wait until these tasks terminate.

In case task migration is possible, tasks executing on the resources that may be deactivated will be migrated to other resources within the active pool. In case this is not possible, the system may wait until the tasks terminate, e.g. the call is terminated; in order to make the method deterministic, a time limit may be set after which still ongoing tasks will be forcefully terminated. A pre-requisite for freeing up selected active resources is that no new tasks are allocated to these - so, essentially, for new tasks, these resources are already considered inactive. According to some embodiments, also the complete pool, i.e. set of active processing entities, may be deactivated. If a resource owner decides to deactivate a resource that itself is a resource owner, the request may be propagated down the resource management tree. When it gets the request to de-active itself, a resource owner may order all its resources that are also resource owners to deactivate themselves; this de-activation may be done within a certain time limit, after which a forceful de-activation may happen. Further, users that it will not be available for new traffic may be informed.

According to some embodiments, a hierarchical, resource usage based monitoring and resource allocation framework may be performed that enables the cluster to autonomously switch on and off computing elements, depending on the actual computational load experienced by the system. This approach may be used for the telecommunication infrastructure nodes, but can easily be used for any cluster computing environment executing multiple tasks. According to some embodiments, the approaches described herein may be based on the assumption that a user of the system may configures basic parameters such as Power save mode on/off, the level of load defining the activation threshold where the amount of active components shall be increased, e.g. 90% over already active components), and the level of load where the amount of active components shall be decreased, e.g. 60% over already active components) - deactivation threshold.

As to the processing entity usage policy, it may be defined that certain types of components or components located at certain locations shall always be active. On each level in the hierarchical system, the components may operate on the following principle:

Lower level resources may be grouped in two categories: pool of active and pool of sleep mode components, power off or low power mode, forming the standby processing entities. Initially, when there are no computations to be performed, all components may in the pool of sleep mode components. Based on computational load and predefined component usage policy, some of the components in the pool of sleep mode components are moved to the pool of active components, i.e. the set of active entities, so as to satisfy the usage policy and guarantee a load beneath the deactivation threshold. The activation of components - transition from power save mode to operational mode - may happen automatically when the component receives the first task to be performed or may be triggered explicitly by higher level components through other means such as HW actions.

The usage (load) on active processing entities may be monitored; components in the active pool may be used in such manner as to maximize the load on few components while leaving other components less loaded - this may allow lower, processor level power management; different policies may be deployed, such as to minimize the overall power consumption, e.g. loading 2 components up to 45% may yield lower power consumption that loading 1 component to 90%. If the load increases over the activation threshold, a new component or

components are moved to the active pool from the pool of sleep mode

components.

A policy for selecting which component to move to the pool of active components may be based on the pattern of computation that will be performed so as to maximize some specific system characteristics. By way of example, if the load drops below the activation threshold, then some of the components from the active pool are moved back to the sleep mode pool; no new computation is allocated to these, thus after these complete their ongoing computation, will be put to power save mode.

A policy for selecting which component to move to the pool of sleep mode components may be to select the components with the least computation load or any other policy improving some relevant system characteristics.

By way of example, the approaches described herein may be applied to a media gateway for mobile networks, e.g. a mobile media gateway, to a multi-processor cluster part of the 3rd generation (3G) mobile network infrastructure with the following parameters, by way of example:

Four levels in the resource control model, with the following setup: one resource at level three controlling three resources at level two; each of the three resource owners at level two control three resources at level one (giving a total of nine resources at level 1 ); each of the nine resource owner at level one control 50 resources at level zero, which are in fact processors performing the execution of tasks

For the power model, an approximation where resources at levels 1 , 2,3 consume 10x more power than resources at level zero may be employed which is corresponds to a systems behavior where as resources at level zero are usually DSPs, while resources at higher levels are general purpose, control processors.

There are two parameters that may influence the results of the evaluation: the load profile (what is the load level at different moments in time and how does it evolve) and the settings for the three parameters, lowLoad, highLoad and activeStep. By way of example, the load may be defined by a sinusoidal distribution which is typical for telecommunication networks. According to some embodiments, when load is decreasing, the power

consumption may decrease much slower; this is primarily due to the way already allocated tasks are managed: the resource management system may wait for these tasks to finish before de-activating resources.

Claims

CLAIMS:

1 . A processing system, comprising: a set (101 ) of active processing entities (103) for task processing; a set (105) of standby processing entities (107); a processor (109) being configured to determine a cumulated processing load associated with the task processing by the set of the active processing entities, and to deactivate at least one active processing entity (103) of the set (101 ) of active processing entities if the cumulated processing load is smaller than or equal to a deactivation threshold, or activate at least one standby processing entity (107) of the set (105) of standby processing entities if the cumulated processing load is equal to or greater than an activation threshold.

2. The processing system of claim 1 , wherein the processor (109) is configured to deactivate a first predetermined number of active processing entities (103) if the cumulated processing load is smaller than or equal to the deactivation threshold, the first predetermined number being chosen such that the resulting cumulated processing load upon deactivating the first predetermined number of active processing entities is smaller than or equal to the activation threshold, or activate a predetermined number of standby processing entities (107) if the cumulated processing load is equal to or greater than the activation threshold, the second predetermined number being chosen such that the resulting cumulated processing load upon activating the second predetermined number of standby processing entities (107) is equal to or greater than the deactivation threshold.

3. The processing system of claim 1 or 2, wherein the processor (109) is configured to estimate an expected cumulated processing load as the cumulated processing load upon the basis of a task request, the task request requesting to process a further task.

4. The processing system of any of the claims 1 to 3, wherein the active processing entities (103) are respectively configured to indicate a processing load associated with processing a task by a respective active processing entity (103) to the processor (109), and wherein the processor (109) is configured to determine the cumulated processing load upon the basis of the indicated processing loads.

5. The processing system of any of the claims 1 to 4, wherein the processor (109) is configured not to activate any further processing entity (103) if the set (105) of standby processing entities (107) is empty and if the cumulated

processing load is equal to or greater than an activation threshold.

6. The processing system of any of the claims 1 to 5, wherein the processor (109) is configured to switch a standby processing entity (107) into an active mode in order to activate the standby processing entity (103) for task processing, and to assign the activated processing entity to the set (101 ) of active processing entities (103)).

7. The processing system of any of the claims 1 to 6, wherein the processor (109) is configured to switch an active processing entity (103) into a standby mode in order to deactivate the active processing entity (103), and to assign the deactivated processing entity to the set (105) of standby processing entities (107).

8. The processing system of any of the claims 1 to 7, wherein the processor (109) is configured to determine which standby processing entity (107) is to be activated, and which task is to be processed by the standby processing entity (107) which is to be activated.

9. The processing system of any of the claims 1 to 8, wherein the processor (109) is configured to determine a certain active processing entity (103) which is processing a task at a processing load which is lower that a processing load of another active processing entity (103) in the set (101 ) of active processing entities (103), and to deactivate the certain active processing entity (103) if the cumulated processing load is smaller than or equal to the deactivation threshold.

10. The processing system of any of the claims 1 to 9, wherein the processor (109) is configured to deactivate an active processing entity (103) based on at least one of the following policies: immediate forceful termination of all tasks, upon expiration of a grace period being determined by a timer, followed by forceful termination of remaining tasks, or upon normal termination of all processing tasks.

1 1 . The processing system of any of the claims 1 to 9, wherein the processor (109) is configured to deactivate the set (101 ) of active processing entities (103) upon receiving a request signal requesting a deactivation of the set of active processing entities.

12. The processing system of any of the claims 1 to 1 1 , wherein the set (101 ) of active processing entities (103) and the set (105) of standby processing entities

(107) are arranged to form a first processing entity group being associated with a first processing level of a hierarchical processing arrangement, wherein the processing system comprises a further set (1 1 1 ) of active processing entities (1 13) for further task processing and a further set (1 15) of standby processing entities (1 17) which are arranged to form a second processing level of the hierarchical processing arrangement, and wherein processing system further comprises a further processor (1 19) for determining a further cumulated processing load associated with the further task processing by the further set (1 1 1 ) of the active processing entities (1 13), the further processor (1 19) being configured to deactivate at least one active processing entity (1 13) of the further set (1 1 1 ) of active processing entities (1 13) if a further cumulated processing load is smaller than or equal to a further deactivation threshold, or activate at least one standby processing entity (1 17) of the further set (1 15) of standby processing entities (1 17) if the cumulated processing load is equal to or greater than an activation threshold.

13. A telecommunication network node comprising the processing system of any of the claims 1 to 12 for processing communication tasks.

14. A method for controlling a processing load of a processing system, the processing system comprising a set of active processing entities for task processing, and a set of standby processing entities, the method comprising: determining (101 ) a cumulated processing load associated with the task processing by the set of the active processing entities; deactivating (103) at least one active processing entity of the set of active processing entities if a cumulated processing load is smaller than or equal to a deactivation threshold; or activating (105) at least one standby processing entity of the set of standby processing entities if the cumulated processing load is equal to or greater than an activation threshold.

15. A computer program for performing the method of claim 14 when run on a computer.