Systems and methods for RL based intelligent microservice-level power management

Abstract

Embodiments include a method for power management of a cloud native application comprising microservices deployed across worker nodes of a container orchestration cluster. A power management environment and actuator collects metrics including energy consumption, resource usage, and application performance, and constructs a state vector based on the collected metrics. The state vector is provided to a reinforcement learning power management engine, which determines a power management decision using a reinforcement learning agent. The power management decision is translated into power management actions that are enforced on the microservices in the worker nodes.

Description

SYSTEMS AND METHODS FOR RL BASED INTELLIGENT MICROSERVICE-LEVEL POWER MANAGEMENTCROSS REFERENCE TO RELATED INFORMATION

[0001] This application is a continuation-in-part, and claims the benefit, of Patent Cooperation Treaty priority application PCT / CN2025 / 083047 filed March 18, 2025, titled "Automated and dynamic microservice level power profile management for cloud native applications. "TECHNICAL FIELD

[0002] The present disclosure relates to systems and methods for reinforcement learning-based intelligent microservice-level power management of cloud native applications.BACKGROUND

[0003] The vendors of modern processors like Intel and AMD have provided so-called power management technologies to manage the power consumption and performance of the workload running on the computer systems. These technologies allow the deployments to be tuned for optimal performance and sustained loads, while providing power savings when the deployment is lightly loaded, hence the overall energy consumption can be reduced. For example, there is one power management method called Dynamic voltage frequency scaling (DVFS) , which can dynamically scale the voltage and frequency (v-f) settings of the CPU to provide "just-enough" speed to process the system workload. Scaling down voltage and frequency levels can result in a reduction in CPUs dynamic power consumption while scaling up can result in higher performance of the running application. There are some other methods available, for example, P-State, C-state, Speed Selection Technology (Intel) , etc. A Performance State (P-state) is an operating point where a CPU core is operating at a specific frequency and voltage while executing instructions. As the core moves to lower P-states, the frequency and associated voltage drops resulting in reduced power consumption and performance. C-states are power states that a CPU can use to reduce power consumption on a per-core level, or on a CPU package level, by powering down or enabling sleep some portions of the core, package, or both. Disabling portions of the core allows for large power savings but prevents the core from executing instructions. C-states can be used to move individual cores or the full CPU Package to an idle state, reducing the power consumption of the server. Many of the settings can be configured at individual CPU core level. Usually, the operating system can utilize these power management technologies via interfaces like ACPI (Advanced Configuration and Power Interface) , and the tools or libraries provided by the hardware vendors. However, for cloud platforms like Kubernetes, there is still no standard way to access and utilize these power management technologies. Kubernetes is purposefully built to operate as an abstraction layer between the workload and such hardware capabilities as a workload orchestrator. Therefore, applications running in Kubernetes with particular requirements on performance or power consumption reliant on hardware capabilities encounter a challenge as a consequence.

[0004] Some power management features give users more precise control over CPU performance and power use on a per-core basis. Kubernetes is purposefully built to operate as an abstraction layer between the workload and such hardware capabilities as a workload orchestrator. Therefore, workloads running in Kubernetes with particular requirements on performance or power consumption reliant on hardware capabilities encounter a challenge as a consequence. There are a few existing works that want to bridge the gap between the container orchestration layer and hardware features, and provide the power management for the deployed Pods, so that the performance and energy consumption could be tuned at container / Pod level.

[0005] The Kubernetes Power Manager is an open-sourced Kubernetes Operator that has been developed to provide a mechanism to request adjustment of worker node power management settings applied to cores allocated to the Pods when they are deployed. See, e.g., Kubernetes Power Manager, Intel, available at https:  / / github. com / intel / kubernetes-power-manager. The power management-related settings can be applied to individual cores or to groups of cores, and each may have different policies applied.

[0006] As shown in Figure 1, the Kubernetes Power Manager (KPM) has two main components, the overarching Power Operator in the master node and the Power Node Agent in each worker node of Kubernetes. The Power Operator is responsible for the configuration and deployment of the Power Node Agent, while the Power Node Agent is responsible for the tuning of the cores as requested by the user by communicating with the Intel Power Optimization Library. When deploying the pod, the user shall indicate a power profile in the pod’s description, for example, “balance-performance” , “balance-power” , “performance” , to indicate the pod’s preference on the tuning of the power management of the CPU core (s) to be assigned to the containers of the Pod. Based on the power profile, the Power Node Agent of KPM in each node will call the Intel Power Optimization library to tune the power management features (e.g., Core / Uncore frequency, P / C States ) accordingly for the CPU core (s) in which the pod is to run. It’s to be noted that the power profile is set before the pod is deployed and remains unchanged when the pod is running.

[0007] RedHatTM has also provided the pod-level power management feature in their OpenShiftTM system. See, e.g., “Save Power with per-pod power management for latency-sensitive workloads, ” RedHat, 2023, available at https:  / / www. redhat. com / architect / power-management-openshift-edge. As shown in Figure 2, in Pod’s description, additional annotations are used to set some pre-defined power management features, for example, to enable / disable C-States, set the governor to control the CPU frequency, etc. Like KPM, such annotations are set before the Pod being deployed and will remain unchanged during Pod running.

[0008] There are a few existing works that want to bridge the gap between the container orchestration layer and hardware features, and provide the power management for the deployed Pods, so that the performance and energy consumption could be tuned at container / Pod level. Kubernetes Power Manager is an open-sourced Kubernetes Operator that has been developed to provide a mechanism to request adjustment of worker node power management settings applied to cores allocated to the Pods when they are deployed. The power management-related settings can be applied to individual cores or to groups of cores, and each may have different policies applied. RedHat has also provided the pod-level power management feature in their OpenShift system. In Pod's description, additional annotations are used to set some pre-defined power management features, for example, to enable / disable C-States, set the governor to control the CPU frequency, etc. Like Kubernetes Power Manager, such annotations are set before the Pod being deployed and will remain unchanged during Pod running.

[0009] However, in both solutions the power profile associated with the Pod are assigned before the Pod is created and will remain the same during the life cycle of the Pod. It has some disadvantages: in general, the performance and power efficiency of a microservice is usually changed dynamically depending on multiple factors like the real-time load of the application and the cloud system, especially for those network functions which have quite dynamic and fluctuant load in both temporal and spatial aspect. When the workload is at its peak, the performance requirements of the network functions (NFs) should give higher priority to assure that the key performance indicators (KPIs) can be satisfied. While the workload is light, the power consumption of the NFs could be optimized by relaxing the performance of NFs but the KPIs can still be fulfilled. In such case, a dynamically managed power profile of each Pod can provide the best balance between performance and power consumption because it can be adapted to the real-time performance and power requirements. In both works, there is no mention how the power profile of each microservice (Pod) should be determined and left for the provider of the application to decide, most likely based on empirical and human experiences, which are not always the most suitable. US Patent Application Publication US20220113790A1 discloses intent driven power management. Patent application P112549WO01 describes automated and dynamic microservice level power profile management for cloud native applications.SUMMARY

[0010] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description.

[0011] In a first aspect, a computer-implemented method for power management of a cloud native application comprising a plurality of microservices deployed across one or more worker nodes of a container orchestration cluster is provided. The method comprises collecting, by a power management environment and actuator, metrics associated with the cloud native application, the metrics including at least one of energy consumption, resource usage, and application performance; constructing, by the power management environment and actuator, a state vector based on the collected metrics; providing the state vector to a reinforcement learning power management engine; determining, by the reinforcement learning power management engine, a power management decision based on the state vector using a reinforcement learning agent; translating, by the power management environment and actuator, the power management decision into one or more power management actions; and enforcing the one or more power management actions on the plurality of microservices in the one or more worker nodes.

[0012] In a second aspect, a system for power management of a cloud native application comprising a plurality of microservices deployed across one or more worker nodes of a container orchestration cluster is provided. The system comprises a power management environment and actuator configured to collect metrics associated with the cloud native application, the metrics including at least one of energy consumption, resource usage, and application performance, construct a state vector based on the collected metrics, and translate a power management decision into one or more power management actions; a reinforcement learning power management engine configured to determine the power management decision based on the state vector using a reinforcement learning agent; and a pool power management function in each of the one or more worker nodes, the pool power management function configured to enforce the one or more power management actions on the plurality of microservices.

[0013] In a third aspect, a computer program comprising instructions which, when executed by processing circuitry, cause the processing circuitry to perform the method of the first aspect is provided.

[0014] In a fourth aspect, a computer-implemented method performed by a reinforcement learning power management engine for power management of a cloud native application comprising a plurality of microservices deployed across one or more worker nodes of a container orchestration cluster is provided. The method comprises receiving a state vector from a power management environment and actuator, the state vector representing an operational context of the cloud native application based on collected metrics including at least one of energy consumption, resource usage, and application performance; determining, by a reinforcement learning agent, a power management decision based on the state vector, the power management decision comprising a power profile for each microservice of the plurality of microservices; and transmitting the power management decision to the power management environment and actuator for translation into one or more power management actions enforceable on the plurality of microservices.

[0015] In a fifth aspect, a computer-readable medium storing the computer program of the third aspect is provided. Providing the computer program on a computer-readable medium enables distribution and deployment of the power management functionality across different computing environments.

[0016] In a sixth aspect, a computer-implemented method performed by a power management environment and actuator for power management of a cloud native application comprising a plurality of microservices deployed across one or more worker nodes of a container orchestration cluster is provided. The method comprises collecting metrics associated with the cloud native application, the metrics including at least one of energy consumption, resource usage, and application performance; constructing a state vector based on the collected metrics, the state vector representing an operational context of the cloud native application; providing the state vector to a reinforcement learning power management engine; receiving a power management decision from the reinforcement learning power management engine, the power management decision comprising a power profile for each microservice of the plurality of microservices; translating the power management decision into one or more power management actions enforceable at a microservice level; and dispatching the one or more power management actions to a pool power management function in the one or more worker nodes.

[0017] In a seventh aspect, a computer-implemented method performed by a pool power management function in a worker node of a container orchestration cluster for power management of a cloud native application comprising a plurality of microservices is provided. The method comprises receiving one or more power management actions from a power management environment and actuator, the one or more power management actions corresponding to a power management decision for the plurality of microservices; assigning each microservice of the plurality of microservices to a power management pool based on the received power management actions, wherein each power management pool has associated CPU cores; and enforcing low-level power management actions on the CPU cores of each power management pool.

[0018] This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an indication of the scope of the claimed subject matter. BRIEF DESCRIPTION OF FIGURES

[0019] Embodiments of the invention will be described, by way of example, with reference to the following drawings, in which:

[0020] Figure 1 illustrates a block diagram of a Kubernetes Power Manager system architecture, according to aspects of the present disclosure.

[0021] Figure 2 illustrates a system architecture for per-pod power management in a cloud platform environment, according to an embodiment.

[0022] Figure 3 illustrates a flowchart for a method for managing a power profile for each microservice of a deployed application, according to aspects of the present disclosure.

[0023] Figure 4 illustrates a block diagram of a cloud platform for performing power management for cloud native applications, according to an embodiment.

[0024] Figure 5 illustrates an example of power profiles in JSON format, according to aspects of the present disclosure.

[0025] Figure 6 illustrates an example of mappings between defined power profiles and low-level power management configurations, according to an embodiment.

[0026] Figure 7 illustrates an example of a mapping between defined power profiles and low-level power management configurations based on CPU frequency ranges, according to aspects of the present disclosure.

[0027] Figure 8 illustrates a system for determining power profile assignments for microservices based on CPU utilization, according to an embodiment.

[0028] Figure 9 illustrates a sequence diagram for a method for managing power profiles of microservices in a cloud native application deployment, according to aspects of the present disclosure.

[0029] Figure 10 illustrates a bar graph showing total power consumption under different loads, according to an embodiment.

[0030] Figure 11 illustrates a line graph showing signaling round-trip time measurements over time, according to aspects of the present disclosure.

[0031] Figure 12 illustrates a flowchart for a method for performing power management for cloud native applications, according to an embodiment.

[0032] Figure 13 illustrates a flowchart for a method performed by a fine granular power controller for performing power management, according to aspects of the present disclosure.

[0033] Figure 14 illustrates a flowchart for a method performed by a PM Agent for performing power management, according to an embodiment.

[0034] Figure 15 illustrates a block diagram of a system for reinforcement learning based microservice-level power management, according to aspects of the present disclosure.

[0035] Figure 16 illustrates a flowchart for a method for reinforcement learning based power management of cloud native applications, according to an embodiment.

[0036] Figure 17 illustrates a bar chart comparing power improvement percentages across different methods at various load levels, according to aspects of the present disclosure.

[0037] Figure 18 illustrates a block diagram of a system for reinforcement learning based power management of cloud native applications, according to an embodiment.

[0038] Figure 19 illustrates a sequence diagram for continuous power management learning and optimization of a cloud native application, according to aspects of the present disclosure.

[0039] Figure 20 illustrates a flowchart for a method for power management of a cloud native application, according to an embodiment.

[0040] Figure 21 illustrates a flowchart for a method performed by a reinforcement learning power management engine, according to aspects of the present disclosure.

[0041] Figure 22 illustrates a flowchart for a method performed by a power management environment and actuator, according to an embodiment.

[0042] Figure 23 illustrates a flowchart for a method performed by a pool power management function in a worker node, according to aspects of the present disclosure.

[0043] Figure 24 illustrates a communication system in accordance with an embodiment.

[0044] Figure 25 illustrates a communication system with multiple access points and stations, according to aspects of the present disclosure.

[0045] Figure 26 illustrates a block diagram of a wireless device, according to an embodiment.

[0046] Figure 27 illustrates a block diagram of a network node, according to aspects of the present disclosure.

[0047] Figure 28 illustrates a block diagram of a virtualization environment, according to an embodiment.

[0048] Figure 29 illustrates a schematic block diagram of an example computer-implemented apparatus, according to an embodiment.

[0049] Common reference numerals are used throughout the figures to indicate similar features.DETAILED DESCRIPTION

[0050] Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and / or is implied from the context in which it is used. All references to a / an / the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and / or where it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments may apply to any other embodiments, and vice versa.

[0051] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Other embodiments, however, are contained within the scope of the subject matter disclosed herein, the disclosed subject matter should not be construed as limited to only the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

[0052] There currently exist certain challenges.

[0053] As mentioned above, the works from Intel and RedHat have provided the pod-level power management to enable fine granular control on the power efficiency and performance at pod-level in container-based cloud system. However, in both solutions the power profile associated with the Pod are assigned before the Pod is created and will remain the same during the life cycle of the Pod. This approach has some disadvantages: in general, the performance and power efficiency of a microservice is usually changed dynamically depending on multiple factors like the real-time load of the application and the cloud system, especially for those network functions which have quite dynamic and fluctuant load in both temporal and spatial aspect. When the workload is at its peak, the performance requirements of the network functions (NFs) should give higher priority to assure that the KPIs can be satisfied. While the workload is light, the power consumption of the NFs could be optimized by relaxing the performance of NFs but the KPIs can still be fulfilled. In such case, a dynamically managed power profile of each Pod can provide the best balance between the performance and power consumption because it can be adapted to the real-time performance and power requirements.

[0054] Also, in both works, there is no mention how the power profile of each microservice (Pod) should be determined and left for the provider of the application to decide, most likely based on empirical and human experiences, which are not always the most suitable.

[0055] In some prior art, an intent driven power management is proposed to manage the power management settings of a node. See, e.g., United State Patent Publication No. 2022 / 0113790A1. However, it’s not designed to manage the power profiles of microservices in the application

[0056] In certain embodiments, a system and mechanisms are provided to manage the power profile of the microservices in an automated way which can be adapted to the dynamicity of the running application and underlying cloud system. Embodiments can include a rule based power profile assignment of the microservices, which determines the power profile of each microservice by comparing its real-time CPU usage with pre-defined and static multi-levels threshold.

[0057] However, such rule and heuristic based management has some drawbacks: firstly, the power consumption and performance of the microservices'container is not only dependent on CPU usage, but also other factors like the network, disk usage. The underlying environment (e.g., network condition) could also contribute to the power consumption and performance of the container. Secondly, the rule is only based on the data metrics of individual microservice, in which the energy and performance impact on the whole application is not considered.

[0058] Therefore, there is a need for an intelligent system that can learn and adapt power management decisions over time, optimizing both performance and energy efficiency of applications in a dynamic cloud environment. Reinforcement Learning (RL) offers a promising path toward such adaptive control. Therefore, a more advanced system and method which uses Reinforcement Learning (RL) based is proposed to manage microservice level power management.

[0059] In addition, the present disclosure notes that to apply the low-level power management actions, CPU pinning technology could be used to pin microservice's container (s) to exclusively assigned CPU cores. Then the low-level actions cloud be applied to the CPU cores accordingly. But such mechanism has limited flexibility and prevents other microservices sharing the pinned CPU cores. In certain other embodiments, pool or balloon-based CPU management mechanisms (see, e.g., https:  / / containers. github. io / nri-plugins / stable / docs / resource-policy / policy / balloons. html) can be used to apply the RL-based microservice level power management.

[0060] Certain aspects of the disclosure and their embodiments may provide solutions to these or other challenges.

[0061] Certain embodiments under the present disclosure include systems and methods to manage the power profile of the microservices in an automated way which can be adapted to the dynamic nature of the running application and underlying cloud system. One objective can be to optimize the energy efficiency and fulfill the performance requirements of the application at the same time.

[0062] Figure 3 illustrates one embodiment of a high-level procedure flow for a method 400 for managing a power profile for each microservice of a deployed application in a cloud platform like Kubernetes. The power profile can be used to indicate how a microservice’s performance or power consumption is to be managed by underlying power management technologies commonly provided via the hardware. At 410, an application provides performance requirements and / or other related information. The system can analyze the initial information coming from the application, and at 420 assign / set an initial power profile to each microservice comprising the application from a set of pre-defined power profiles that are supported by the cloud platform. Then the microservices with the assigned power profiles will then be deployed, at 430, into the cloud platform (e.g., Kubernetes cluster) . At 440, after being deployed, the system will apply the power profile of each microservice in the node by translating the power profile to the detailed power management actions (for example, changing the P-state of the CPU that the microservice is running in) . At 450, the system monitors and collects related performance and power consumption metrics at the microservice levels and application level. From the collected metrics data, the two metrics collectors can also perform data aggregation and preprocessing for easy access from other components. At 460, the system’s hardware capabilities can be collected. At 470, the system can analyze the collected information including application requirements, power consumption, performance metrics, low level capabilities, and other information. The system can determine if a microservice’s power profile need to be changed to optimize the power consumption and still satisfy the performance requirements of the application. If needed, at 480, the system can calculate and assign a new profile to the microservice. The new profile can be enforced at step 440 for the affected microservice (s) . The system can continuously repeat the process to monitor the metrics and change the assigned power profiles of the microservices if necessary.

[0063] As described above and in further embodiments below, certain embodiments under the present disclosure include methods and systems to automate and dynamically manage power profiles of individual microservices of an application deployed in the cloud environment, so that power consumption can be reduced, and performance requirements from the deployed application can still be fulfilled.

[0064] Certain embodiments may provide one or more of the following technical advantages.

[0065] Certain proposed solutions can optimize the power consumption of an application while fulfilling various performance requirements. Such optimized setting of power profiles can be automated and can be adjusted according to dynamic system conditions in real-time.

[0066] Certain embodiments can include integrated Reinforcement Learning based intelligence with cloud native microservice level power management. Below are some advantages to compare with the previous RL-based (i.e., based on pre-defined threshold such as CPU utilization of microservices) power management. The proposed RL-based system could support more practical non-linear relationship between multiple metrics and power consumption, and more complete factors beyond only resource usage metrics, while rule-based always assumes a linear relationship between resource usages and performance / power consumption. RL can also learn those hidden patterns and find optimal power management decisions that hard-coded rule would miss. RL supports well the global optimization in which the energy consumption performance of the application can be considered as a whole, rather than only per-microservice optimization. One disadvantage of rule-based system is it is often based on static and pre-defined rules and thresholds which need to be manually refined or tuned into a new or changed environment. RL-based systems can usually adapt well in a dynamic environment to find dynamic optimal power-performance equilibrium.

[0067] Some embodiments may in some scenarios only manage the power profile (the high-level power consumption and performance balance) of the microservices, the mapping to low-level power management actions is static and pre-defined. But other embodiments, with hierarchical agent mode, the dynamic and optimal power management decisions can include the low-level power management actions.

[0068] Certain embodiments can also propose to use dynamic CPU pool to enforce the power manage actions for the microservice which provides more flexibility and better resource sharing when compared to previous CPU pinning based.

[0069] Figure 4 illustrates one possible system embodiment 600 under the present disclosure. System 600 can comprise a cloud platform, such as e.g., a cloud-based containerized system. Cloud platform 600 can in some embodiments be considered a cluster, or group of nodes 660, 680. Components can include: fine-granular power controller (FPC) 620, power metrics collector (PowerMC) 630, performance metrics collector (PerfMC) 640, power management (PM) agent (s) 662, 682. Control plane 650 can help control node (s) 660, 680. Each node (s) 660, 680 can comprise pod(s) 664, 684, PM agent (s) 662, 682, and hardware 668, 688. Control plane 650 can control a cloud platform e.g., a containerized cloud microservices solution (e.g., a Kubernetes cloud) and its comprising components.

[0070] Application 699 can be a cloud native application (s) to be deployed in the cloud platform 600. Application 699 can comprise multiple microservices, and each microservice can be deployed as one or more pods 664, 684. Cloud platform 600 (e.g., Kubernetes) can comprise one interface towards the application 699. Application 699 can e.g., provide application level performance metrics to PowerMC 630.

[0071] PowerMC 630 can be used to collect power consumptions of the application and cloud platform 600. PowerMC 630 can use multiple sources to collect power consumptions at different levels. For fine-grained power consumption of each microservice of the application 699, PowerMC 630 could use the open-source project KeplerTM. PowerMC 630 could also use external power meters to measure the power consumption of each node 660, 680 in cloud platform 600. These power consumptions at different level can be stored in a database like PrometheusTM so they can be accessed (e.g., in real time or later) by the FPC 620.

[0072] PerfMC 640 can collect various performance metrics and resource usages of application 699 in the cloud platform 600, for example, e.g., request processing throughput; processing latency at microservice level and application level; utilization usage of CPU and memory for each microservice; etc.

[0073] PM agent (s) 662, 682 can be deployed in each worker node 660, 680 whose system supports the power management features or capabilities, e.g., the CPU frequency tuning or P-state. According to the instruction from the FPC 620 , PM agent (s) 662, 682 can apply the power profile assigned to the microservices onto each node 660, 680 in the cloud platform 600 by using mechanisms for example, the tools provided by the operating system, the library provided by the vendor like Intel, or other similar means for adjusting power.

[0074] FPC 620 is responsible for managing the power profile of each microservice (s) of application 699. Certain functions include: creating the initial power profile for each microservice or pod 664, 684; analyzing the various metrics including power consumption, performance, resource usage of the microservice (s) belonging to application 699; determining the suitable power profile for each microservice; instructing the PM agent (s) 662, 682 to apply the power profile of the microservices.Power Profiles

[0075] The power profiles can be used for the system to indicate the balance of the power consumption and performance of the microservices. Each microservice can be associated with one power profile at a given time, and during the deployment, the power profile of the microservices can be changed dynamically.

[0076] The power profiles can indicate the general characteristics regarding the desired energy consumption or performance level for the microservices. The more profiles are defined, the finer-grained description of the power and performance requirements can be provided.

[0077] An example of power profiles 700 in JSON (JavaScript Object Notation) format is shown in Figure 5. In this example, four profiles are defined. Profile 1 is for those microservices that need least performance and most power saving, Profile 4 is for those that need best performance and care least power saving. Profile 2 and Profile 3 are for those that need more balanced performance and power consumption.

[0078] A profile (such as above) can indicate the desired power saving or performance preference for the microservices. To apply or enforce these power profiles on each node of the cloud system, mappings to low level power management configurations (for example, CPU frequency range, P-state, power governor, etc. ) can be used.

[0079] Figure 6 shows an example of mappings 800 between the defined power profiles and low level power management configurations at each node in the cluster or cloud platform. In this example, the enforcement of the power profile can be based on Intel Performance and Energy Bias Hint (EPB) and Energy Performance Preference (EPP) . The file comprises two parts, the first part specifies the default power management settings for the whole server, and the second part specifies the corresponding profile settings for each defined power profile. Such mappings could be the same on all nodes in the cluster, or could be different on the nodes. Figure 7 shows another example of mapping 900 which can be based on a specified CPU frequency range for each defined power profile.

[0080] The low-level power management features (e.g., CPU frequency, P-state) usually are applied either per CPU core or per CPU package. In order to enforce the power profile and the mappings on the microservice (pod or container) , the pods (or containers) of the microservices need exclusive use of CPU core (s) , which could be achieved by either CPU pining or CPU pooling. When the pods / containers are assigned the exclusive CPU (s) , the PM agent can enforce the power profiles on the CPU cores (s) according to the above defined mappings. For example, suppose microservice X has been assigned power profile ‘profile1’a nd the power profile mapping ‘epp-epb’ has been used, and CPU core ‘1, 3’ have been exclusively allocated to microservice ‘X’ , the PM Agent can set CPU core ‘1, 3’ Intel EPP / EPB to ‘power’ . If the power profile mapping ‘CPUfreq’ is used, the PM agent can set the frequency of CPU core ‘1, 3’ to 1000Mhz –1400Mhz on node1, and to 1000Mhz-1300Mhz on node2.Determining Power Profile of the Microservices

[0081] An FPC (e.g., FPC 620 of Figure 4) can be responsible for determining the power profile to be used by the microservices. The power profile could be determined by multiple techniques for example, AI / ML based, rule or policy based, etc.

[0082] Figure 8 illustrates one example algorithm 1000 to dynamically choose the power profile for the given microservices, but other approaches (e.g., AI / ML based) can be used as well. This algorithm can be, at least in part, based on CPU utilization of the microservices, but other metrics could be used as well, for example, the power consumption, the processing latency of the microservices, the overload related metrics (e.g., error rate) from the microservices, and / or other metrics.Mapping the Power Profiles to Low Level Power Management Features

[0083] The power profiles can indicate the general needs on power consumption or performance for the concerned microservices. As mentioned above, they can be mapped to the low level power management settings or configurations in each worker node (s) in the cloud platform or clusters.

[0084] The hardware may have provided various low level power management capabilities, for example, EPP / EPB based indication P-state management, the different P-state governors, the C-state settings, Uncore governors, Intel-SST technologies, etc. There may be no straightforward mapping from the power profiles to these low level settings. Such mapping could be performed together by the FPC and PM agent and based on the characteristics of the application.

[0085] The PM agents running in each worker node (s) can detect the low level power management capabilities by e.g., checking the hardware information (e.g., vendor, CPU parameters like core numbers, frequence ranges, kernel configurations like P / C-state driver, and any other related information) . The FPC can then, based on the characteristics or requirements of the application, determine which type (s) of the low level power management capabilities are to be used in the mappings. For example, for CPU intensive applications, the EPP / EPB based P-state management could be used. In another example, for those network intensive applications, the C-state based management could be used. Furthermore, based on the selected low level power management type and the capabilities of each worker nodes, the FPC can then determine the detail power management settings for each power profile in the worker nodes (as described above regarding example profile setting and mappings) . The more detailed procedures are described in the following section.Example Sequence Flow

[0086] Figure 9 illustrates one embodiment of a process flow for a method embodiment 1100 under the present disclosure. Method 1100 is carried out among components including: application 1101, cloud platform 1102 (e.g., Kubernetes) , FPC 1103, PM agent 1104, PowerMC 1105, PerfMC 1106, node 1107.

[0087] At 1110, FPC 1103 defines a list of power profiles (e.g., such as described herein with regard to various embodiments) . At 1120, FPC 1103 communicates with the PM agents 1104 running in each node of the cloud platform / cluster, to get the supported low level power management features to the nodes. At 1130, based on the information from the PM agent 1104, FPC 1103 defines the mapping of the power profiles to the low level power management settings or configurations in each node. At 1125, the orchestrators, application providers or operators deploy the application into cloud platform 1102. The performance requirements from the application can also be provided. At 1130, cloud platform 1102 schedules the microservices (Pods) of the application to various nodes 1107 in the cloud platform / cluster. At 1135, FPC 1103 gets notified of the deployment of the application, and also gets related application information and manifest from cloud platform 1102. At 1140, for each microservice (s) , the FPC 1103 shall set an initial power profile in the node (s) 1107 based on e.g., pre-configured setting (s) (for example, the ‘profile1’ in the example described above) . In the following steps, the system can continuously update the power profiles assigned to the microservices. At 1145, PowerMC 1105 can collect various power related metrics, e.g., the power consumption at the Pod level, node level, etc. This can be done e.g., continuously, in real time, at determined time intervals, on an irregular basis, or on other schedules.

[0088] Loop 1150 refers to the steps, which can be repeated, of dynamically modifying the power profile (s) . PerfMC 1106 continuously gets performance related metrics (e.g., processing latency) and resource usages (CPU, memory) of the microservices from the cloud platform 1102. The processing latency can in some embodiments can also be gotten from the dedicated distributed tracing technology like Open Telemetry. PerfMC 1106 continuously gets the application level performance metrics (e.g., end-to-end (e2e) latency) from the application.Evaluation Results

[0089] One possible embodiment under the present disclosure was implemented as a prototype and an evaluation was performed in a testbed in which 5G Core control plane Network Functions are installed. These experimental results serve to show the feasibility and benefits of embodiments described herein.

[0090] In the evaluation, one proposed system embodiment was compared with a baseline system in which there was no dynamic and fine-granular power management, i.e., all microservices of the deployed application and the nodes in the cluster have the same and static high performance-based power management settings.

[0091] In Figure 10, the power consumption for both the proposed system and the baseline system are illustrated, it can be seen that the proposed system has consumed significantly less energy, especially when the traffic load is low. If when the traffic load almost reaches the peak, the proposed system still consumes less energy when compared to the baseline.

[0092] In Figure 11, the average signalling RTT (Round-Trip Time) for both the proposed system and the baseline system are illustrated. It can be seen that the RTT of the proposed system is a bit higher than the baseline system which has used the high-performance settings, but the RTT can still fulfil the applications’ requirements, and the RTT remains stable when the traffic is increasing and reaching the peak. It has also been observed that there is an almost similar capability for the proposed system and baseline system in terms of the SAU (Simultaneously Attached Users) when the traffic load is increased.Additional Embodiments

[0093] Another possible method embodiment under the present disclosure is shown in Figure 12.Method 1800 comprises a computer-implemented method for performing power management for cloud native applications. Step 1810 is receiving an identification of an application and one or more performance requirements related to the application. Step 1820 is setting an initial power profile for each of the one or more microservices. Step 1830 is deploying the application among the one or more microservices. Step 1840 is applying the initial power profile to each of the one or more microservices. Step 1850 is measuring one or more performance metrics related to the deployed application and the one or more microservices. Step 1860 is detecting one or more capabilities of the one or more cloud-based hardware. Step 1870 is comparing the one or more performance metrics and the one or more capabilities. Step 1880 is calculating an updated power profile for each of the one or more microservices. Step 1885 is repeating steps 1840 to 1880 using the updated power profile. Method 1800 can comprise a variety of alternative, additional, and / or optional steps.

[0094] Another possible method embodiment under the present disclosure is shown in Figure 13.Method 2000 comprises a method performed by a fine granular power controller in a cloud environment, for performing power management for cloud native applications. Step 2010 is defining an initial power profile for each of one or more microservices, the one or more microservices configured to provide cloud-based performance of an application. Step 2020 is collecting, from each PM Agent, one or more capabilities of one or more nodes, the one or more nodes configured to provide the one or more microservices and each comprising a PM agent, the PM Agent configured to apply power profiles from the fine granular power controller at each of the one or more nodes, the one or more nodes each comprising one or more pods. Step 2030 is defining a hardware mapping for each of the initial power profiles based at least in part on the one or more capabilities, each hardware mapping defining which of the one or more nodes and one or more pods will comprise each of the one or more microservices. Step 2040 is receiving a notification that the application has been deployed in the cloud environment. Step 2050 is setting the initial power profile in the one or more pods and the one or more nodes. Step 2060 is querying, from a power metrics collector, one or more power metrics related to the deployed application and the one or more microservices, the power metrics collector configured to collect the one or more power metrics from the one or more nodes. Step 2070 is querying, from a performance metrics collector, one or more performance metrics related to the deployed application and the one or more microservices, the performance metrics collector configured to collect the one or more performance metrics from the one or more nodes. Step 2080 is calculating an updated power profile for each of the one or more microservices based at least in part on; the one or more capabilities, the one or more power metrics, and the one or more performance metrics. Step 2090 is instructing each PM Agent to implement each updated power profile. Method 2000 can comprise a variety of alternative, additional, and / or optional steps.

[0095] Another possible method embodiment under the present disclosure is shown in Figure 14. Method 2200 comprises a method performed by a PM Agent in a cloud environment for performing power management for cloud native applications. Step 2210 is providing, to a fine granular power controller, one or more capabilities of one or more nodes, wherein the cloud environment comprises the one or more nodes for providing one or more microservices, each of the one or more nodes comprising one or more pods and a PM Agent, each PM Agent configured to apply power profiles from the fine granular power controller at each of the one or more nodes. Step 2220 is receiving an instruction, from the fine granular power controller, to implement an updated power profile at its respective node of the one or more nodes, the updated power profile based at least in part on; the one or more capabilities, one or more power metrics, and one or more performance metrics; the one or more power metrics and the one or more performance metrics related to the deployed application and the one or more microservices. Step 2230 is applying the updated power profile at the respective node of the one or more nodes. Method 2200 can comprise a variety of alternative, additional, and / or optional steps.RL-Based Embodiments

[0096] Certain embodiments propose a system and method for RL-based microservice-level power management of cloud native applications. One system overview, seen in Figure 15, can include an RL Power Management Engine (RPME) 2440 that provides reinforcement learning-based dynamic and intelligent decisions of the power management for the application, for example, a high-level power profile to be assigned to each microservice of the deployed application to the Power Management Actuator. The power profile can be used to indicate the high-level balance of the energy consumption and performance required by each microservice. In each worker node of the cluster, the high-level power profiles are mapped to hardware-level power management actions towards the individual microservices. Such action mapping could be pre-defined and static, or the mapping could also be provided by the Power Management RL engine via reinforcement learning, e.g., hierarchical RL.

[0097] The Power Management Environment &Actuator (PMEA) 2420 provides the interface and interaction between the high-level intelligence e.g., RL Power Management Engine 2440 and the underlying cloud infrastructure (e.g., Kubernetes cluster 2460) and applications. On one hand, it gets the decisions from the RL Power Management Engine 2440 and applies the decisions (e.g., the power profile, and / or low-level power management actions mapping) onto the microservices in the cloud environment. On the other hand, it provides the information needed by RPME 2440 to perform the reinforcement learning, e.g., the information (like, the microservice lists of the application, the power management action lists) to construct the action and state space, the telemetry metrics (e.g., the resource usages, application performance, energy consumption) to construct the state space.

[0098] In the worker nodes 2470, pool or balloon-based CPU power management may be used to enforce the low-level actions to individual microservices / containers. So, in the system, there is a Pool Power Management 2480 component in each worker node which will manage the CPU pools (e.g., assigning / moving microservices to the pool) and trigger power management actions based on the instructions that communicated by the Power Management Environment &Actuator 2420.

[0099] In brief, the RL Power Management Engine 2440 learns power management decisions by interacting the cloud environment and application through the Power Management Environment and Actuator 2420, which enforces the decisions on the microservices belonging to the application in the worker nodes in the cluster. Unlike prior deterministic systems, the RL agent continuously updates its policy based on interaction with the Power Management Actuator and Metrics Collector, thereby adapting and improving decisions over time in a dynamic environment.

[0100] Figure 16 illustrates a high level flow-chart of one method embodiment 2600 under the present disclosure. Method 2600 begins with step 2605, where the system retrieves all related information of the application and running environment. The method 2600 then proceeds to step 2610, where the system sets up the power management environment / actuator and the RL engine. Following this setup, the method 2600 moves to step 2615, which serves as an entry point into a continuous loop for power management optimization. From step 2615, the method 2600 proceeds to step 2620, where the system monitors the related metrics including energy, performance, and resource usage metrics. The method 2600 then continues to step 2625, where the metrics are mapped to the state according to RL modeling. Next, the method 2600 moves to step 2630, where the RL engine updates the power management decisions for the application based on selected algorithm and strategy. The method 2600 then proceeds to step 2635, where the power management decisions are mapped to the enforceable actions. Finally, the method 2600 reaches step 2640, where the low-level actions are performed on the application in worker nodes. After step 2640, the method 2600 returns to step 2615, creating a continuous loop that enables the system to continuously learn and optimize power management decisions over time.

[0101] Certain embodiments include systems and methods in which the advanced reinforcement learning technology is integrated to automate and dynamically manage the power profiles of individual microservices of the application deployed in the cloud environment. The system can continuously learn and manage dynamic power management decisions to microservices of the application by considering multiple objectives including power consumption, performance requirements etc.

[0102] The system introduces the power management environment and actuator as a novel bridging component between the high-level intelligence and the underlying cloud infrastructure (e.g., Kubernetes) .

[0103] The system can enable a hierarchical approach to dynamically learn and optimize how high-level power management decisions are being translated into hardware actions.

[0104] To enforce these power management decisions at the hardware level, embodiments can implement a localized "Pool Power Management" component on individual worker nodes. This mechanism enforces the low-level hardware actions on specific microservices or containers by dynamically moving them between CPU pool or balloons techniques, and / or dynamically adjusting pool or balloons settings.

[0105] A prototype based on certain proposed embodiments has been evaluated in a lab environment which includes a Kubernetes based cloud environment and real 5G core network functions. Figure 17 shows under various traffic loads the power saving over the node-level performance baseline (i.e., all CPU cores of the server are set to performance oriented) of the RL-based system vs CPU utilization Rule-based. We can see that the RL-based system always achieves high power saving cross all traffic load, indicating it performed well and adapted well during the change of the environment compared to the rule-based system.

[0106] A detailed architecture of the system 3000 is illustrated in Figure 18. It includes the following components: RL Power Management Engine (RPME) 3040, Power Management Environment &Actuator (PMEA) 3020, Pool Power Management Function (PPMF) 3080, Kubernetes cluster (Kubernetes Control Plane 3070 and worker nodes 3075) . PMEA 3020 interfaces with the Kubernetes Control Plane 3070 and worker nodes 3075 containing Pool Power Management Function 3080 and CPU pools organized into Performance Pool 3082 and Powersave Pool 3084 configurations with associated CPUs 3086 and CPUs 3088. The RL Power Management Engine (RPME) 3040 is responsible for providing optimized decisions on the power management of the application 3010 in the cloud environment and aims to reduce the energy consumption of the application while maintaining the application's performance KPIs. Its main functions include RL Agents 3042, Optimization Algorithm &Strategy, and Action / State Space 3046. The RL Agents 3042 could support either single agent mode or Hierarchical Mode (Meta-Agent / Worker-Agent) . In single agent mode, a monolithic neural network (e.g., Actor-Critic) that processes all states data to output high-level power profiles for the microservices which are mapped to low level power management actions via pre-defined static rules. In hierarchical agent mode, there are two types of agents, Meta agent decides the high-level power profiles of the microservices, while Worker agent determines the low-level power management actions for the given the high-level power profiles. The Optimization Algorithm &Strategy defines and implements the RL algorithm and optimization strategy to be used, e.g., Proximal Policy Optimization (PPO) , and its exploration strategy. Action / State Space 3046 defines the action and state space based on the information received from the Power Management Environment &Actuator 3020. It also store and maintains the spaces based on the data received from the Power Management Environment &Actuator 3020. The Action / State Space 3046 is used by the RL Agents 3042 in the RL optimization process. In single agent mode, the action space is an array of all defined power profiles of the microservices. In hierarchical agent mode, the action space is split: the Meta-Agent's action is to select a power profile, while the Worker-Agent's action is determine the low level power management actions for the given power profiles.

[0107] The Power Management Environment &Actuator (PMEA) 3020 is the interface to interact with both the RL Power Management Engine 3040 and underlying cloud infrastructure (e.g., the Kubernetes cluster) . It includes the following main functions: the APP Information 3044 stores the retrieved information from the application 3010, for example, the performance KPIs, the microservice lists and graph, resource requests, etc. If needed, it can also get the topology of the microservices, i.e., the worker nodes 3075 that the microservices are deployed. The Metrics Collector 3022 monitors and collects real-time telemetry data such as energy consumption, resource usages, performance KPIs from multiple sources. The State Constructor 3028 transforms and aggregates these collected data into a format the RL Power Management Engine 3040 can understand. It can also scale the data (e.g., converting "CPU Nanocores" and "Milliseconds of Latency" into a normalized 0–1 range) data. The Action Dispatcher 3024 takes the high-level PM Decision 3025 from the RPME 3040 and converts it into power management actions or commands that can be enforced at the microservice level of the application 3010 in the cloud infrastructure. Such actions are then dispatched to the Pool Power Management Function 3080 and executed in each worker node in the worker nodes 3075.

[0108] The primary function of Pool Power Management Function (PPMF) 3080 is maintaining multiple dynamic Power Management Pools (PM Pools) in which the microservices with the same high-level power management actions are assigned in the same pool with shared CPU cores. For example, two Power Management Pools can be created: Performance Pool 3082 and Powersave Pool 3084. The Pool Power Management Function 3080 will enforce the mapped low-level power management actions (e.g., P-state, CPU frequency) to the microservices (i.e., CPUs 3086 and CPUs 3088) in each PM Pool. The actions are mapped from the high-level power profile of the pool, which could be pre-defined static mapping, or dynamically decided also by RPME 3040. The number of CPU cores assigned to a Pool can be dynamically changed based on the CPU resource requests of the microservices in the pool. The pool can be created and maintained through tools like Container Runtime Interface (CRI) Resource Manager and Node Resource Interface (NRI) plugins (e.g., balloon policy) for Kubernetes. Pool Power Management Function 3080 supports dynamic pool reassignment, i.e., when the RPME 3040 decides to change a microservice's high-level power profile, the microservice will be reassigned to the pool corresponding to the power profile.RL Based Problem Formulation and Optimization

[0109] Certain embodiments, such as system 2400 or system 3000, can be modeled as a Markov Decision Process (MDP) defined by the tuple (S, A, P, R, γ) , where the objective is to determine an optimal policy π* that maps application states to power management actions.

[0110] The state vector St∈S at time t represents the operational context of the cloud-native application. It is defined as the concatenation of multiple sub-vectors, for example: · Application Performance (Mt) : {Le2e, RPS, Errt} , where Le2e is the end-to-end latency, RPS is requests per second, and Err is the error rate. · Resource utilization (Rt) :  representing the CPU and Memory usage for each of the N microservices. · Energy consumption (Et) : representing total power consumption.

[0111] The action vector At∈A defines the power management decisions for each microservice i∈ {1, …, N}  · High-Level Decision: ai∈ {0, 1, 2} , representing discrete power profiles (e.g., 0: Power-Save, 1: Balanced, 2: Performance) . · Low-Level Mapping: in a hierarchical embodiment, ai includes a tuple (Profilei, Actioni) , where Actioni defines specific low-level power management enforcements such as CPU frequency associated with the high-level decision.

[0112] The Reward Function Rt is a critical element of the training process, guiding the RL agent to choose actions that meet the system's objectives: optimize power consumption while still fulfilling performance requirements. It can be formulated to incentivize energy efficiency while penalizing violations of the Performance KPI. For example, the reward can be calculated as: Where: · ∑P- (t) : The total instantaneous power consumption across all worker nodes K. · Cost (Le2e) : A penalty function can be defined for example: Cost (Le2e) =max (0, Le2e-Ltarget) k where k≥1 ensures an exponential penalty for significant service level agreement (SLA) breaches) . · α, β: weighting coefficients used to calibrate the trade-off between energy savings and performance reliability.

[0113] Transition Function (P) : the probability P (st+1|st, at) that the cloud environment moves to a new state after applying new power management decision. It represents how the cloud environment and application react to power changes.

[0114] Discount factor (γ) : This is a scalar value (typically between 0.9 and 0.99) that determines the agent's "horizon. " It weights the importance of future rewards compared to immediate rewards.Optimization with PPO (Proximal Policy Optimization)

[0115] One embodiment implementation of the optimization algorithm is to use PPO, which uses Actor-Critic architecture to prevent the agent from making radical changes that could disrupt the application.

[0116] In brief, the Actor network πθ (a|s) proposes power profile distributions for microservices, while the Critic Network estimates the value of the current state of the environment and application to reduce variance during training.

[0117] To ensure the application remains stable, PPO restricts the policy update using a clipping mechanism:

[0118] Other algorithms or equations can be used as a clipping mechanism. This prevents the engine from making "aggressive" power-reduction jumps that the environment or application cannot recover quickly. For example, if the agent discovers a decision to save massive power by a power management action, a standard RL agent might do it instantly. PPO's clipping function ensures the agent only moves toward that decision in small, measurable steps, allowing the system to signal a latency spike before the system becomes unstable.Handling Hierarchical Decisions

[0119] In the Hierarchical agent mode, the PPO can be applied at two levels: · Global PPO (Manager) : PPO optimizes the selection of power profiles based on application performance. · Local PPO (Worker) : Receives the profile and learns the best Action Mapping (e.g., choosing frequency scaling) to hit that profile's indication.

[0120] Figure 19 shows a detailed sequence flow diagram illustrating the continuous power management learning and optimization process or method 3300, depicting interactions between the Application 3310, Power Management Environment and Actuator 3315, RL Power Management Engine 3320, K8s Control Plane 3325, Pool Power Management 3330, and CPU Pools 3335 components within Worker Nodes 3340.

[0121] The method 3300 begins with a deploy application step 3351 where the application 3310 is deployed and instantiated across the Kubernetes worker nodes 3335 via the K8s Control Plane 3325. Following deployment, the Power Management Environment and Actuator 3315 performs a retrieve app requirements and information step 3352 to query the application 3310 for performance KPIs, microservice lists, and resource requests. The Power Management Environment and Actuator 3315 then executes a retrieve cluster and deployment information step 3353 to obtain cluster-level and node-level data from the K8s Control Plane 3325, including pod counts and worker node mappings.

[0122] Based on the retrieved information, the Power Management Environment and Actuator 3315 performs a setup environment and actuator step 3354 to initialize the RL environment, configure the state space and action space, and define the power management decision translation logic. An information for learning step 3355 transmits the defined state space, action space, and related information to the RL Power Management Engine 3320. The RL Power Management Engine 3320 then performs a setup RL engine step 3356 to self-configure its internal architecture, including selecting the optimization algorithm and architectural mode.

[0123] The method 3300 then enters a continuous loop for power management optimization. A collect metrics including power and resource usage step 3357 retrieves telemetry data from the K8s Control Plane 3325, while a collect app-level metrics step 3358 obtains application KPIs from the application 3310. An update and aggregate state metrics step 3359 normalizes and aggregates the collected metrics, and a provide updated state step 3360 transmits the synthesized state vector to the RL Power Management Engine 3320. A learning and update decision step 3361 calculates rewards and executes policy updates to determine optimal power management decisions. A send updated PM decision step 3362 transmits the decision to the Power Management Environment and Actuator 3315, which performs a translate PM decision step 3363 to convert the decision into enforceable actions. A dispatch PM actions step 3364 sends the actions to the Pool Power Management 3330 in the Worker Nodes 3335. An assign or migrate microservices to pool step 3365 dynamically assigns microservices to appropriate power management pools within the CPU Pools 3340, and an enforce PM actions step 3366 applies the low-level power management actions to the corresponding CPU cores.

[0124] Figure 20 illustrates one possible method embodiment under the present disclosure. Method 3400 comprises a computer-implemented method for power management of a cloud native application 3010 comprising a plurality of microservices deployed across one or more worker nodes 3075 of a container orchestration cluster 1060. At step 3410, a power management environment and actuator 3020 collects metrics associated with the cloud native application 3010, the metrics including at least one of energy consumption, resource usage, and application performance. At step 3420, the power management environment and actuator 3020 constructs a state vector based on the collected metrics. At step 3430, the state vector is provided to a reinforcement learning power management engine 3040. At step 3440, the reinforcement learning power management engine 3040 determines a power management decision based on the state vector using a reinforcement learning agent 3042. At step 3450, the power management environment and actuator 3020 translates the power management decision into one or more power management actions. At step 3460, the one or more power management actions are enforced on the plurality of microservices in the one or more worker nodes 3075.

[0125] In some embodiments, the power management decision comprises at least one of a high-level power profile for each microservice of the plurality of microservices indicating a balance between energy consumption and performance, or a low-level power management action for each microservice of the plurality of microservices. In certain embodiments, enforcing the one or more power management actions comprises assigning each microservice to a power management pool 3082, 3084 based on the power management decision, wherein microservices assigned to a same power management pool share CPU cores 3086, 3088. Enforcing the one or more power management actions may further comprise applying low-level power management actions to the CPU cores 3086, 3088 of each power management pool 3082, 3084, the low-level power management actions including at least one of a P-state setting and a CPU frequency setting. The method 3400 may further comprise dynamically migrating a microservice from a first power management pool to a second power management pool in response to a change in the power management decision for the microservice.

[0126] In some embodiments, the reinforcement learning agent 3042 operates in a hierarchical agent mode comprising a meta-agent configured to determine high-level power profiles for the plurality of microservices and a worker-agent configured to determine low-level power management actions for the high-level power profiles. Determining the power management decision may comprise calculating a reward based on a reward function that incentivizes energy efficiency while penalizing violations of a performance key performance indicator, wherein the reward function comprises a weighted sum of a total power consumption term and a latency penalty term. In certain embodiments, determining the power management decision comprises executing a policy update using Proximal Policy Optimization with a clipping mechanism to restrict policy updates.

[0127] Collecting the metrics may comprise at least one of retrieving power consumption and resource usage metrics from a control plane 3070 of the container orchestration cluster 1060, retrieving one or more power metrics from a power meter associated with one or more components not associated with the control plane, or retrieving application-level metrics from the cloud native application 3010. The state vector may comprise an application performance sub-vector including at least one of end-to-end latency, requests per second, and error rate, a resource utilization sub-vector including CPU usage and memory usage for each microservice, and an energy consumption value representing total power consumption. The method 3400 may be performed continuously in a loop to enable the reinforcement learning power management engine 3040 to learn and adapt power management decisions over time.

[0128] Figure 21 illustrates one possible method embodiment under the present disclosure. Method 3500 comprises a computer-implemented method performed by a reinforcement learning power management engine 3040 for power management of a cloud native application 3010 comprising a plurality of microservices deployed across one or more worker nodes 3075 of a container orchestration cluster 1060. At step 3510, the reinforcement learning power management engine 3040 receives a state vector from a power management environment and actuator 3020, the state vector representing an operational context of the cloud native application 3010 based on collected metrics including at least one of energy consumption, resource usage, and application performance. At step 3520, a reinforcement learning agent 3042 determines a power management decision based on the state vector, the power management decision comprising a power profile for each microservice of the plurality of microservices. At step 3530, the reinforcement learning power management engine 3040 transmits the power management decision to the power management environment and actuator 3020 for translation into one or more power management actions enforceable on the plurality of microservices.

[0129] In some embodiments, determining the power management decision comprises calculating a reward based on a reward function that comprises a weighted sum of a total power consumption term and a latency penalty term, and executing a policy update based on the calculated reward to select an optimal power management decision. In certain embodiments, the reinforcement learning agent 3042 operates in a hierarchical agent mode, wherein a meta-agent determines high-level power profiles for the plurality of microservices and a worker-agent determines low-level power management actions for the high-level power profiles.

[0130] The method 3500 may further comprise receiving information from the power management environment and actuator 3020, the information including a defined state space and action space 3046, and configuring an internal architecture of the reinforcement learning power management engine 3040 based on the received information, including selecting an optimization algorithm and an architectural mode.

[0131] Figure 22 illustrates one possible method embodiment under the present disclosure. Method 3700 comprises a computer-implemented method performed by a power management environment and actuator 3020 for power management of a cloud native application 3010 comprising a plurality of microservices deployed across one or more worker nodes 3075 of a container orchestration cluster 1060. At step 3710, the power management environment and actuator 3020 collects metrics associated with the cloud native application 3010, the metrics including at least one of energy consumption, resource usage, and application performance. At step 3720, the power management environment and actuator 3020 constructs a state vector based on the collected metrics, the state vector representing an operational context of the cloud native application 3010. At step 3730, the power management environment and actuator 3020 provides the state vector to a reinforcement learning power management engine 3040. At step 3740, the power management environment and actuator 3020 receives a power management decision from the reinforcement learning power management engine 3040, the power management decision comprising a power profile for each microservice of the plurality of microservices. At step 3750, the power management environment and actuator 3020 translates the power management decision into one or more power management actions enforceable at a microservice level. At step 3760, the power management environment and actuator 3020 dispatches the one or more power management actions to a pool power management function 3080 in the one or more worker nodes 3075.

[0132] In some embodiments, collecting the metrics comprises retrieving power consumption and resource usage metrics from a control plane 3070 of the container orchestration cluster 1060, and retrieving application-level metrics including performance key performance indicators from the cloud native application 3010. The method 3700 may further comprise retrieving application requirements and information from the cloud native application 3010, the application requirements including performance key performance indicators and a structural representation of the plurality of microservices, retrieving cluster-level and node-level deployment information from a control plane 3070 of the container orchestration cluster 1060, and configuring a state space and an action space 3046 based on the retrieved application requirements and deployment information. In certain embodiments, translating the power management decision comprises mapping a high-level power profile for each microservice to a corresponding power management pool 3082, 3084 in the one or more worker nodes 3075.

[0133] Figure 23 illustrates one possible method embodiment under the present disclosure. Method 3900 comprises a computer-implemented method performed by a pool power management function 3080 in a worker node 3075 of a container orchestration cluster 1060 for power management of a cloud native application 3010 comprising a plurality of microservices. At step 3910, the pool power management function 3080 receives one or more power management actions from a power management environment and actuator 3020, the one or more power management actions corresponding to a power management decision for the plurality of microservices. At step 3920, the pool power management function 3080 assigns each microservice of the plurality of microservices to a power management pool 3082, 3084 based on the received power management actions, wherein each power management pool has associated CPU cores 3086, 3088. At step 3930, the pool power management function 3080 enforces low-level power management actions on the CPU cores 3086, 3088 of each power management pool 3082, 3084.

[0134] In some embodiments, the power management pools 3082, 3084 comprise a performance pool 3082 and a powersave pool 3084, wherein microservices assigned to the performance pool 3082 are allocated to CPU cores 3086 configured with performance-oriented power settings and microservices assigned to the powersave pool 3084 are allocated to CPU cores 3088 configured with power-saving settings. Enforcing the low-level power management actions may comprise applying at least one of a P-state setting and a CPU frequency setting to the CPU cores 3086, 3088 of each power management pool 3082, 3084. The method 3900 may further comprise dynamically migrating a microservice from a first power management pool to a second power management pool in response to receiving an updated power management action for the microservice.

[0135] Figure 24 shows an example of a communication system 4100 in accordance with some embodiments. In the example, the communication system 4100 includes a telecommunications network 4102 that includes an access network 4104, such as a radio access network (RAN) , and a core network 4106, which includes one or more core network nodes 4108. The access network 4104 includes one or more access network nodes or base stations of various types, access network nodes 4110A and 4110B are depicted (which may be collectively referred to as network nodes 4110) , or any other similar 3rd Generation Partnership Project (3GPP) access nodes or non-3GPP access points (APs) . Some embodiments of the access network 4104 may include more than one access network technology. The network nodes 4110 of access network 4104 facilitate direct or indirect connection of wireless devices, also referred to as user equipments (UEs) , such as by connecting UEs 4112A, 4112B, 4112C, and 4112D (one or more of which may be generally referred to as UEs 4112) to the core network 4106 over one or more wireless connections.

[0136] Moreover, a network node is not necessarily limited to an implementation in which a radio portion and a baseband portion are supplied and integrated by a single vendor. Thus, it will be understood that network nodes include disaggregated implementations or portions thereof. For example, in some embodiments, the telecommunications network 4102 includes one or more Open-RAN (ORAN) network nodes. An ORAN network node is a network node in the telecommunications network 4102 that supports an ORAN specification (e.g., a specification published by the O-RAN Alliance, or any similar organization) and may operate alone or together with other network nodes to implement one or more functionalities of any network node in the telecommunications network 4102, including one or more access network nodes 4110 and / or core network nodes 4108.

[0137] Examples of an ORAN network node include an open radio unit (O-RU) , an open distributed unit (O-DU) , an open central unit (O-CU) , including an O-CU control plane (O-CU-CP) or an O-CU user plane (O-CU-UP) , a RAN intelligent controller (near-real time or non-real time) hosting software or software plug-ins, such as a near-real time control application (e.g., xApp) or a non-real time control application (e.g., rApp) , or any combination thereof (the adjective “open” designating support of an ORAN specification) . An ORAN network node may support a specification by, for example, supporting an interface defined by the ORAN specification, such as an A1, F1, W1, E1, E2, X2, Xn interface, an open fronthaul user plane interface, or an open fronthaul management plane interface. Moreover, an ORAN network node may be a logical node in a physical node. Furthermore, an ORAN network node may be implemented in a virtualization environment (described further below) in which one or more network functions are virtualized. For example, the virtualization environment may include an O-Cloud computing platform orchestrated by a Service Management and Orchestration Framework via an O-2 interface defined by the O-RAN Alliance or comparable technologies.

[0138] The network nodes 4110 facilitate direct or indirect connection of one or more UEs 4112 to the core network 4106 over one or more wireless connections. Example wireless communications over a wireless connection include transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Moreover, in different embodiments, the communication system 4100 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that may facilitate or participate in the communication of data and / or signals whether via wired or wireless connections. The communication system 4100 may include and / or interface with any type of communication, telecommunication, data, cellular, radio network, and / or other similar type of system.

[0139] The UEs 4112 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and / or operable to communicate wirelessly with the network nodes 4110 and other communication devices. Similarly, the network nodes 4108, 4110 are arranged, capable, configured, and / or operable to communicate directly or indirectly (e.g., via other devices of telecommunications network 4102) with the UEs 4112 and / or with other network nodes or equipment in the telecommunications network 4102 to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as administration in the telecommunications network 4102. More specifically, UEs 4112 may send messages, data, and / or other signals to network nodes 4108, 4110 or other elements of the telecommunications network 4102 by transmitting such signals to the relevant device directly without the signals passing through any intervening devices or by transmitting such signals to the relevant device indirectly through an intervening device (or multiple intervening devices) that then transmit the signal to the relevant device. Similarly, network nodes 4108, 4110 may send messages, data, and other signals to UEs 4112, other network nodes 4108, 4110, and other devices in telecommunications network 4102 directly or indirectly. As one specific example, a core network node 4108 may transmit a particular message to a UE 4112 by transmitting the message to an access network node 4110 that will then transmit the message to the intended UE 4112. Similarly, a core network node 4108 may receive a particular message from a UE 4112 by receiving the message from an access network node 4110 that itself received the message from the UE 4112.

[0140] In the depicted example, the core network 4106 connects elements of the access network 4104 (e.g., one or more of the network nodes 4110) to one or more host computing systems, such as host 4116. These connections may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directly coupled to hosts. The core network 4106 includes one or more core network nodes (e.g., core network node 4108) of various types, one or more of which may be generally referred to as network nodes 4108. Network nodes 4108 are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the UEs, access network nodes, and / or hosts, such that the descriptions thereof are generally applicable to the corresponding components of the core network node 4108. Example core network nodes provide functions of one or more of a Mobile Switching Center (MSC) , Mobility Management Entity (MME) , Home Subscriber Server (HSS) , Access and Mobility Management Function (AMF) , Session Management Function (SMF) , Authentication Server Function (AUSF) , Subscription Identifier De-concealing function (SIDF) , Unified Data Management (UDM) , Security Edge Protection Proxy (SEPP) , Network Exposure Function (NEF) , and / or a User Plane Function (UPF) .

[0141] The host 4116 may be under the ownership or control of a service provider other than an operator or provider of the access network 4104 and / or the telecommunications network 4102. The host 4116 may be operated by the service provider or on behalf of the service provider. The host 4116 may host a variety of applications to provide one or more service. Examples of such applications include live and pre-recorded audio / video content, data collection services such as retrieving and compiling data on various ambient conditions detected by a plurality of UEs, analytics functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server.

[0142] As a whole, the communication system 4100 of Figure 24 enables connectivity between the UEs, network nodes, and hosts. In that sense, the communication system 4100 may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are not limited to: Global System for Mobile Communications (GSM) ; Universal Mobile Telecommunications System (UMTS) ; Long Term Evolution (LTE) , and / or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g., 6G) ; wireless local area network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (Wi-Fi) ; and / or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (Wi-Max) , Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, Li-Fi, and / or any low-power wide-area network (LPWAN) standards such as LoRa and Sigfox. Moreover, the communication system 4100 may be configured to support multiple different standards, protocols, or other rule sets, with individual components supporting all of the relevant rule sets or with different components or sub-systems within the communication system 4100 supporting different standards, protocols, or rule sets.

[0143] As one example, in certain embodiments, access network 4104 may contain some access network nodes 4110 that support 3GPP radio access technologies (RAT) , such as LTE or NR, while other access network nodes 4110 support (or the same access network nodes 4110 additionally support) non-3GPP RATs, such as Wi-Fi or a proprietary RAT. As another example, telecommunications network 4102 may support multiple generations of related communication standards (e.g., 4G and 5G 3GPP communication standards) and, as a result, may include an access network 4104 and / or a core network 4106 that supports multiple different standard generations or may include multiple access networks 4104 and / or multiple core networks 4106 with individual networks 4104, 4106 supporting different standard generations.

[0144] Telecommunications network 4102 may support network slicing to provide different logical networks to different devices that are connected to the telecommunications network 4102. For example, the telecommunications network 4102 may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and / or Massive Machine Type Communication (mMTC)  / Massive IoT services to yet further UEs. In some examples, one or more of the UEs 4112 are configured to transmit and / or receive information without direct human interaction. For instance, a UE may be designed to transmit information to the access network 4104 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network 4104. Additionally, a UE may be configured for operating in single-or multi-RAT or multi-standard mode. For example, a UE may operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, i.e. being configured for multi-radio dual connectivity (MR-DC) , such as E-UTRAN (Evolved-UMTS Terrestrial Radio Access Network) New Radio –Dual Connectivity (EN-DC) .

[0145] In the example, the hub 4114 communicates with the access network 4104 to facilitate indirect communication between one or more UEs (e.g., UE 4112C and / or 4112D) and network nodes (e.g., network node 4110B) . In some examples, the hub 4114 may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, the hub 4114 may be a broadband router enabling access to the core network 4106 for the UEs. As another example, the hub 4114 may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be received from the UEs, network nodes 4110, or by executable code, script, process, or other instructions in the hub 4114.

[0146] As another example, the hub 4114 may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, the hub 4114 may be a content source. For example, for a UE that is a VR headset, display, loudspeaker or other media delivery device, the hub 4114 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub 4114 then provides to the UE either directly, after performing local processing, and / or after adding additional local content. In still another example, the hub 4114 acts as a proxy server or orchestrator for the UEs, in particular if one or more of the UEs are low energy IoT devices.

[0147] The hub 4114 may have a constant / persistent or intermittent connection to the network node 4110B. The hub 4114 may also allow for a different communication scheme and / or schedule between the hub 4114 and UEs (e.g., UE 4112C and / or 4112D) , and between the hub 4114 and the core network 4106. In other examples, the hub 4114 is connected to the core network 4106 and / or one or more UEs via a wired connection. Moreover, the hub 4114 may be configured to connect to an M2M service provider over the access network 4104 and / or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with the network nodes 4110 while still connected via the hub 4114 via a wired or wireless connection. In some embodiments, the hub 4114 may be a dedicated hub –that is, a hub whose primary function is to route communications to / from the UEs from / to the network node 4110B. In other embodiments, the hub 4114 may be a non-dedicated hub –that is, a device which is capable of operating to route communications between the UEs and network node 4110B, but which is additionally capable of operating as a communication start and / or end point for certain data channels.

[0148] Figure 25 is another example of a communication system 4200 according to some embodiments. As used herein, the communication system 4200 includes multiple access points (APs) 4210 (with four exemplary APs 4210A, 4210B, 4210C, and 4210D being depicted) and multiple wireless devices, referred to in the context of communication system 4200 as stations (STAs) 4212 (referred to individually as STA 4212A, STA 4212B, STA 4212C, STA 4212D, and STA 4212E) . STA 4212A is served by AP 4210A in a first basic service set (BSS) 4220A. STA 4210B and STA 4210C are served by AP 4210B in a second BSS, BSS 4220B. STA 4212D is served by AP 4210C in a third BSS, BSS 4220C. STA 4212E is served by AP 4210D in a fourth BSS, BSS 4220D. Stations 4212 may be non-AP STAs and correspond to various kinds of wireless devices, for example, user terminals, such as mobile or stationary computing devices like smartphones, laptop computers, desktop computers, tablet computers, gaming devices, head-mounted displays (HMDs) for Augmented Reality (AR) or Virtual Reality (VR) , or the like. Further, stations 4212 could, for example, correspond to other kinds of equipment like smart home devices, printers, multimedia devices, data storage devices, or the like.

[0149] Each of STAs 4212 may connect through a radio link to one of APs 4210. For example, depending on location or channel conditions experienced by a given STA 4212, the STA may select an appropriate AP and BSS for establishing the radio link. The radio link may be based on one or more orthogonal frequency-division multiplexing (OFDM) carriers from a frequency spectrum that is shared on the basis of a contention-based mechanism, e.g., an unlicensed or license exempt band like 2.4 GHz Industrial, Scientific, and Medical (ISM) band, the 5 GHz band, the 6 GHz band, or the 60 GHz band.

[0150] Each AP 4210 may provide data connectivity to STAs 4212 connected to a particular AP 4210. As illustrated, APs 4210 may be connected to a data network 4230. In this way, APs 4210 may also provide data connectivity between STAs 4212 and other entities, e.g., to one or more servers, service providers, data sources, data sinks, user terminals, or the like. Accordingly, the radio link established between a given STA 4212 and its serving AP 4210 may be used for providing various kinds of services to STA 4212, e.g., a voice service, a multimedia service, or other data service. Such services may be based on applications that are executed on STA 4212 and / or on a device linked to STA 4212. By way of example, Figure 25 illustrates an application service platform 4232 provided in data network 4230. The application (s) executed on STA 4212 and / or on one or more other devices linked to STA 4212 may use the radio link for data communication with one or more other STA 4212 and / or the application service platform 4232, thereby enabling utilization of the corresponding service (s) at STA 4212.

[0151] Figure 26 shows a wireless device 4300, which may be configured to operate in communication system 4100 of Figure 24 or in communication system 4200 of Figure 25. The wireless device 4300 may be alternatively referred to as a UE 4300, like a UE 4112 within the context of communication system 4100, or as a station (STA) 4300 or as a non-access-point station (non-AP STA) 4300, like a STA 4212 within the context of the communication system 4200, in accordance with respective embodiments. As used herein, a wireless device refers to a device capable, configured, arranged and / or operable to communicate wirelessly with network nodes and / or other wireless devices. Examples of a wireless device include, but are not limited to, a smart phone, mobile phone, cell phone, voice over IP (VoIP) phone, wireless local loop phone, desktop computer, personal digital assistant (PDA) , wireless cameras, gaming console or device, music storage device, playback appliance, wearable terminal device, wireless endpoint, mobile station, tablet, laptop, laptop-embedded equipment (LEE) , laptop-mounted equipment (LME) , smart device, wireless customer-premise equipment (CPE) , vehicle, vehicle-mounted or vehicle embedded / integrated wireless device, and wireless terminal. Other examples include any type of UE identified by the 3rd Generation Partnership Project (3GPP) , including a narrow band internet of things (NB-IoT) UE, a machine type communication (MTC) UE, and / or an enhanced MTC (eMTC) UE.

[0152] A wireless device 4300 may support device-to-device (D2D) communication, for example by implementing a 3GPP standard for sidelink communication, Dedicated Short-Range Communication (DSRC) , vehicle-to-vehicle (V2V) , vehicle-to-infrastructure (V2I) , or vehicle-to-everything (V2X) . In other examples, wireless device 4300 may not necessarily have a user in the sense of a human user who owns and / or operates the relevant device. Instead, wireless device 4300 may represent a device that is intended for sale to, or operation by, a human user but which may not, or which may not initially, be associated with a specific human user (e.g., a smart sprinkler controller) . Alternatively, wireless device 4300 may represent a device that is not intended for sale to, or operation by, an end user but which may be associated with or operated for the benefit of a user (e.g., a smart power meter) .

[0153] In particular embodiments, wireless device 4300 includes processing circuitry 4302 that is operatively coupled via a bus 4304 to an input / output interface 4306, a power source 4308, a memory 4310, a communication interface 4312, and / or any other component, or any combination thereof. Certain embodiments of wireless device 4300 may include all or a subset of the components shown in Figure 9. The level of integration between the components may vary from one embodiment of wireless device 4300 to another. In general, in a particular embodiment of wireless device 4300, processing circuitry 4302, input / output interface 4306, power source 4308, memory 4310, and communication interface 4312 may, in whole or in part, represent or include physical components common to or shared by one or more of the other elements of wireless device 4300. Further, certain embodiments of wireless devices 4300 may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0154] The processing circuitry 4302 is configured to process instructions and data and may be configured to implement any sequential state machine operative to execute instructions stored as machine-readable computer programs in the memory 4310. The processing circuitry 4302 may be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, field-programmable gate arrays (FPGAs) , application specific integrated circuits (ASICs) , etc. ) ; programmable logic together with appropriate firmware; one or more stored computer programs, general-purpose processors, such as a microprocessor or digital signal processor (DSP) , together with appropriate software; or any combination of the above. For example, the processing circuitry 4302 may include multiple central processing units (CPUs) .

[0155] In the example, the input / output interface 4306 may be configured to provide an interface or interfaces to an input device, output device, or one or more input and / or output devices. Examples of an output device include a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, an emitter, a smartcard, another output device, or any combination thereof. An input device may allow a user to capture information into wireless device 4300. Examples of an input device include a touch-sensitive or presence-sensitive display, a camera (e.g., a digital camera, a digital video camera, a web camera, etc. ) , a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, a smartcard, and the like. The presence-sensitive display may include a capacitive or resistive touch sensor to sense input from a user. A sensor may be, for instance, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, an optical sensor, a proximity sensor, a biometric sensor, etc., or any combination thereof. An output device may use the same type of interface port as an input device. For example, a Universal Serial Bus (USB) port may be used to provide an input device and an output device.

[0156] In some embodiments, the power source 4308 is structured as a battery or battery pack. Other types of power sources, such as an external power source (e.g., an electricity outlet) , photovoltaic device, or power cell, may be used to supply power to circuitry or to charge an associated battery. The power source 4308 may further include power circuitry for delivering power from the power source 4308 itself, and / or an external power source, to the various parts of wireless device 4300 via input circuitry or an interface such as an electrical power cable. Power source 4308 may perform any formatting, converting, or other modification to make accessible power suitable for the respective components of the wireless device 4300 to which power is supplied.

[0157] The memory 4310 may be or be configured to include memory such as random access memory (RAM) , read-only memory (ROM) , programmable read-only memory (PROM) , erasable programmable read-only memory (EPROM) , electrically erasable programmable read-only memory (EEPROM) , magnetic disks, optical disks, hard disks, removable cartridges, flash drives, and so forth. In one example, the memory 4310 includes one or more programs 4314, such as an operating system, web browser application, a widget, gadget engine, or other application, and corresponding data 4316. The memory 4310 may store, for use by wireless device 4300, any of a variety of various operating systems or combinations of operating systems.

[0158] The memory 4310 may be configured to include a number of physical drive units, such as redundant array of independent disks (RAID) , flash memory, USB flash drive, external hard disk drive, thumb drive, pen drive, key drive, high-density digital versatile disc (HD-DVD) optical disc drive, internal hard disk drive, Blu-Ray optical disc drive, holographic digital data storage (HDDS) optical disc drive, external mini-dual in-line memory module (DIMM) , synchronous dynamic random access memory (SDRAM) , external micro-DIMM SDRAM, smartcard memory such as tamper resistant module in the form of a universal integrated circuit card (UICC) including one or more subscriber identity modules (SIMs) , such as a USIM and / or ISIM, other memory, or any combination thereof. The UICC may for example be an embedded UICC (eUICC) , integrated UICC (iUICC) or a removable UICC commonly known as ‘SIM card. ’ The memory 4310 may allow wireless device 4300 to access instructions, programs and the like, stored on transitory or non-transitory memory media, to off-load data, or to upload data. An article of manufacture, such as one utilizing a communication system may be tangibly embodied as or in the memory 4310, which may be or comprise a device-readable storage medium.

[0159] The processing circuitry 4302 may be configured to communicate with an access network or other network via or using the communication interface 4312. The communication interface 4312 may comprise one or more communication subsystems and may include or be communicatively coupled to an antenna 4322. The communication interface 4312 may include one or more transceivers used to communicate, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another wireless device or a network node in an access network) . Each transceiver may include a transmitter 4318 and / or a receiver 4320 appropriate to provide network communications (e.g., optical, electrical, frequency allocations, and so forth) . Moreover, the transmitter 4318 and receiver 4320 may be coupled to one or more antennas (e.g., antenna 4322) and may share circuit components, software or firmware, or alternatively be implemented separately.

[0160] In the illustrated embodiment, communication functions of the communication interface 4312 may include cellular communication, Wi-Fi communication (e.g., according to an IEEE 802.11 family standard) , LPWAN communication, data communication, voice communication, multimedia communication, short-range communications such as Bluetooth, near-field communication, location-based communication such as the use of the global positioning system (GPS) to determine a location, another like communication function, or any combination thereof. Communications may be implemented according to one or more communication protocols and / or standards, such as IEEE 802.11, Code Division Multiplexing Access (CDMA) , Wideband Code Division Multiple Access (WCDMA) , GSM, LTE, New Radio (NR) , UMTS, WiMax, Ethernet, transmission control protocol / internet protocol (TCP / IP) , synchronous optical networking (SONET) , Asynchronous Transfer Mode (ATM) , QUIC, Hypertext Transfer Protocol (HTTP) , and so forth.

[0161] In particular embodiments, wireless device 4300 may provide an output of data captured via a sensor, through its communication interface 4312, via a wireless connection to a network node, and / or in any appropriate manner. Data captured by sensors of a wireless device 4300 can be communicated through a wireless connection to a network node via another wireless device 4300. In particular embodiments, such output may be periodic (e.g., once every 15 minutes if it reports the sensed temperature) , random (e.g., to even out the load from reporting from several sensors) , in response to a triggering event (e.g., when moisture is detected an alert is sent) , in response to a request (e.g., a user initiated request) , or a continuous stream (e.g., a live video feed of a patient) .

[0162] As another example, wireless device 4300 comprises an actuator, a motor, or a switch, related to a communication interface configured to receive wireless input from a network node via a wireless connection. In response to the received wireless input the states of the actuator, the motor, or the switch may change. For example, wireless device 4300 may comprise a motor that adjusts the control surfaces or rotors of a drone in flight according to the received input or to a robotic arm performing a medical procedure according to the received input.

[0163] Wireless device 4300, when in the form of an Internet of Things (IoT) device, may be a device for use in one or more application domains, these domains comprising, but not limited to, wearable technology, extended industrial application and healthcare. Non-limiting examples of such an IoT device are a device which is or which is embedded in: a connected refrigerator or freezer, a TV, a connected lighting device, an electricity meter, a robot vacuum cleaner, a voice controlled smart speaker, a home security camera, a motion detector, a thermostat, a smoke detector, a door / window sensor, a flood / moisture sensor, an electrical door lock, a connected doorbell, an air conditioning system like a heat pump, an autonomous vehicle, a surveillance system, a weather monitoring device, a vehicle parking monitoring device, an electric vehicle charging station, a smart watch, a fitness tracker, a wearable for tactile augmentation or sensory enhancement, a water sprinkler, an animal-or item-tracking device, a sensor for monitoring a plant or animal, an industrial robot, an Unmanned Aerial Vehicle (UAV) , and any kind of medical device, like a heart rate monitor or a remote controlled surgical robot. In particular embodiments, wireless device 4300 represents an IoT device that comprises circuitry and / or software in dependence of the intended application of the IoT device in addition to other components as described in relation to the example embodiment of wireless device 4300 shown in Figure 9.

[0164] As yet another specific example, in an IoT scenario, wireless device 4300 may represent a machine or other device that performs monitoring and / or measurements, and transmits the results of such monitoring and / or measurements to another wireless device and / or a network node. Wireless device 4300 may in this case be an M2M device, which may in a 3GPP context be referred to as an MTC device. As one particular example, wireless device 4300 may implement the 3GPP NB-IoT standard. In other scenarios, wireless device 4300 may represent a vehicle, such as a car, a bus, a truck, a ship and an airplane, or other equipment that is capable of monitoring and / or reporting on its operational status or other functions associated with its operation.

[0165] In practice, any number of wireless devices 4300 may be used together with respect to a single use case. For example, a first wireless device 4300 might be or be integrated in a drone and provide the drone’s speed information (obtained through a speed sensor) to a second wireless device 4300 that is a remote controller operating the drone. When a user makes changes from the remote controller, the first wireless device 4300 may adjust the throttle on the drone (e.g. by controlling an actuator) to increase or decrease the drone’s speed. The first and / or the second wireless device 4300 can also include more than one of the functionalities described above. For example, wireless device 4300 might comprise the sensor and the actuator, and handle communication of data for both the speed sensor and the actuators.

[0166] Figure 27 shows a network node 4400 in accordance with some embodiments. As used herein, network node refers to equipment capable, configured, arranged and / or operable to communicate directly or indirectly with a UE and / or with other network nodes or equipment, in a telecommunications network. In accordance with respective embodiments, network node 4400 may be configured to operate in communication system 4100 of Figure 24, like network nodes 4108 or 4110, or in communication system 4200 of Figure 25, like an AP 4210 or a station 4212. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points) , base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs) and NR NodeBs (gNBs) ) , O-RAN nodes or components of an O-RAN node (e.g., O-RU, O-DU, O-CU) .

[0167] Network nodes 4400 may be categorized based on the amount of coverage they provide (or, stated differently, their transmit power level) and so, depending on the provided amount of coverage, may be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. Network node 4400 may be a relay node or a relay donor node controlling a relay. Network nodes 4400 may also include one or more (or all) parts of a distributed radio base station such as centralized digital units, distributed units (e.g., in an O-RAN access node) and / or remote radio units (RRUs) , sometimes referred to as Remote Radio Heads (RRHs) . Such remote radio units may or may not be integrated with an antenna as an antenna integrated radio. Parts of a distributed radio base station may also be referred to as nodes in a distributed antenna system (DAS) .

[0168] Other examples of network nodes 4400 include multiple transmission point (multi-TRP) 5G access nodes, multi-standard radio (MSR) equipment such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs) , base transceiver stations (BTSs) , transmission points, transmission nodes, multi-cell / multicast coordination entities (MCEs) , Operation and Maintenance (O&M) nodes, Operations Support System (OSS) nodes, Self-Organizing Network (SON) nodes, positioning nodes (e.g., Evolved Serving Mobile Location Centers (E-SMLCs) ) , and / or Minimization of Drive Tests (MDTs) .

[0169] In particular embodiments, network node 4400 includes a processing circuitry 4402, a memory 4404, a communication interface 4406, and a power source 4408. In general, in a particular embodiment of network node 4400, processing circuitry 4402, memory 4404, communication interface 4406, and power source 4408 may, in whole or in part, represent or include physical components common to or shared by one or more of the other elements of network node 4400.

[0170] The network node 4400 may be composed of multiple distinct network entities (e.g., a NodeB entity and a RNC entity, or a BTS entity and a BSC entity, etc. ) , which may each have or utilize their own respective physical components. In certain scenarios in which the network node 4400 comprises multiple such entities (e.g., BTS and BSC) , one or more of the separate entities may be shared among several network nodes. For example, a single RNC may control multiple NodeBs. In such a scenario, each unique NodeB and RNC pair, may in some instances be considered a single separate network node. In some embodiments, the network node 4400 may be configured to support multiple radio access technologies (RATs) . In such embodiments, some components may be duplicated (e.g., separate memories 4404 or portions of memory 4404 for different RATs) and some components may be reused (e.g., a same antenna 4410 may be shared by different RATs) . The network node 4400 may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node 4400, for example GSM, WCDMA, LTE, NR, Wi-Fi (e.g., according to an IEEE 802.11 family standard) , Zigbee, Z-wave, LoRaWAN, Radio Frequency Identification (RFID) or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chip or set of chips and other components within network node 4400.

[0171] The processing circuitry 4402 may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and / or encoded logic operable to provide, either alone or in conjunction with other components, such as the memory 4404, to provide network node 4400 functionality.

[0172] In some embodiments, the processing circuitry 4402 includes a system on a chip (SOC) . In some embodiments, the processing circuitry 4402 includes one or more of radio frequency (RF) transceiver circuitry 4412 and baseband processing circuitry 4414. In some embodiments, the RF transceiver circuitry 4412 and the baseband processing circuitry 4414 may be on separate chips (or sets of chips) , boards, or units, such as radio units and digital units. In alternative embodiments, part or all of RF transceiver circuitry 4412 and baseband processing circuitry 4414 may be on the same chip or set of chips, boards, or units.

[0173] The memory 4404 may comprise any form of volatile or non-volatile computer-readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM) , read-only memory (ROM) , mass storage media (for example, a hard disk) , removable storage media (for example, a flash drive, a Compact Disk (CD) or a Digital Video Disk (DVD) ) , and / or any other volatile or non-volatile, non-transitory device-readable and / or computer-executable memory devices that store information, data, and / or instructions that may be used by the processing circuitry 4402. The memory 4404 may store any suitable instructions, data, or information, including a computer program, software, an application including one or more of logic, rules, code, tables, and / or other instructions capable of being executed by the processing circuitry 4402 and utilized by the network node 4400. The memory 4404 may be used to store any calculations made by the processing circuitry 4402 and / or any data received via the communication interface 4406. In some embodiments, the processing circuitry 4402 and memory 4404 is integrated.

[0174] The communication interface 4406 is used in wired or wireless communication of signaling and / or data with UEs, other network nodes, and / or any other network equipment. In the illustrated embodiment, communication interface 4406 comprises port (s)  / terminal (s) 4416 to send and receive data, for example to and from a network over a wired connection. In particular embodiments, network node 4300 may be capable of wireless communication and communication interface 4406 may also include radio front-end circuitry 4418 that may be coupled to, or in certain embodiments a part of, an antenna 4410. Particular embodiments of radio front-end circuitry 4418 include filter (s) 4420 and amplifier (s) 4422. The radio front-end circuitry 4418 may be connected to an antenna 4410 and processing circuitry 4402. The radio front-end circuitry may be configured to condition signals communicated between antenna 4410 and processing circuitry 4402. The radio front-end circuitry 4418 may receive digital data that is to be sent out to other network nodes or UEs via a wireless connection. The radio front-end circuitry 4418 may convert the digital data into a radio signal (s) having the appropriate channel and bandwidth parameters using a combination of filters 4420 and / or amplifiers 4422. The radio signal (s) may then be transmitted via the antenna 4410. Similarly, when receiving data, the antenna 4410 may collect radio signals which are then converted into digital data by the radio front-end circuitry 4418. The digital data may be passed to the processing circuitry 4402. In other embodiments, the communication interface may comprise different components and / or different combinations of components.

[0175] In certain alternative embodiments, network node 4400 may be capable of wireless communication but does not include separate radio front-end circuitry 4418, instead, the processing circuitry 4402 includes radio front-end circuitry and is connected to the antenna 4410. Similarly, in some embodiments, all or some of the RF transceiver circuitry 4412 is part of the communication interface 4406. In still other embodiments, the communication interface 4406 includes one or more ports or terminals 4416, the radio front-end circuitry 4418, and the RF transceiver circuitry 4412, as part of a radio unit (not shown) , and the communication interface 4406 communicates with the baseband processing circuitry 4414, which is part of a digital unit (not shown) .

[0176] The antenna 4410 may include one or more antennas, or antenna arrays, configured to send and / or receive wireless signals. The antenna 4410 may be coupled to the radio front-end circuitry 4418 and may be any type of antenna capable of transmitting and receiving data and / or signals wirelessly. In certain embodiments, the antenna 4410 is separate from the network node 4400 and connectable to the network node 4400 through one or more interfaces or ports.

[0177] The antenna 4410, communication interface 4406, and / or the processing circuitry 4402 may be configured to perform some or all of the receiving operations and / or obtaining operations described herein as being performed by the network node 4400. Any information, data and / or signals may be received from a UE, another network node and / or any other network equipment. Similarly, the antenna 4410, the communication interface 4406, and / or the processing circuitry 4402 may be configured to perform some or all of the transmitting or sending operations described herein as being performed by the network node 4400. Any information, data and / or signals may be transmitted to a UE, another network node and / or any other network equipment.

[0178] The power source 4408 provides power to the various components of network node 4400 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component) . The power source 4408 may further comprise, or be coupled to, power management circuitry to supply the components of the network node 4400 with power for performing the functionality described herein. For example, the network node 4400 may be connectable to an external power source (e.g., the power grid, an electricity outlet) via an input circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry of the power source 4408. As a further example, the power source 4408 may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry. The battery may provide backup power should the external power source fail.

[0179] Embodiments of the network node 4400 may include additional components beyond those shown in Figure 10 for providing certain aspects of the network node’s functionality, including any of the functionality described herein and / or any functionality necessary to support the subject matter described herein. For example, the network node 4400 may include user interface equipment to allow input of information into the network node 4400 and to allow output of information from the network node 4400. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for the network node 4400.

[0180] Figure 28 is a block diagram illustrating a virtualization environment 4500 in which functions implemented by some embodiments may be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any device described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 4500 hosted by one or more of hardware nodes, such as a hardware computing device that operates as an access network node, UE, core network node, or host. Further, in embodiments in which a virtual node does not require radio connectivity (e.g., a core network node or host) , then the node may be entirely virtualized. In some embodiments, the virtualization environment 4500 includes components defined by the O-RAN Alliance, such as an O-Cloud environment orchestrated by a Service Management and Orchestration Framework via an O-2 interface.

[0181] Applications 4502 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc. ) are run in the virtualization environment 4500 to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein. Hardware 4504 includes processing circuitry, memory that stores software and / or instructions executable by hardware processing circuitry, and / or other hardware devices as described herein, such as a network interface, input / output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers 4506 (also referred to as hypervisors or virtual machine monitors (VMMs) ) , provide VM 4508A and VM 4508B (which may be collectively referred to as VMs 4508) , and / or perform any of the functions, features and / or benefits described in relation with some embodiments described herein. The virtualization layer 4506 may present a virtual operating platform that appears like networking hardware to one or more of the VMs 4508.

[0182] The VMs 4508 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by virtualization layer 4506. Different embodiments of the instance of a virtual appliance 4502 may be implemented on one or more of VMs 4508, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV) . NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment. In the context of NFV, each of the VMs 4508 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each of the VMs 4508, and that part of hardware 4504 that executes that VM, be it hardware dedicated to that VM and / or hardware shared by that VM with others of the VMs, forms separate virtual network elements. Still in the context of NFV, a virtual network function is responsible for handling specific network functions that run in one or more of the VMs 4508 on top of the hardware 4504 and corresponds to an application 4502.

[0183] Hardware 4504 may be implemented in a standalone network node with generic or specific components. Hardware 4504 may implement some functions via virtualization. Alternatively, hardware 4504 may be part of a larger cluster of hardware (e.g. such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration 4510, which, among others, oversees lifecycle management of applications 4502. In some embodiments, hardware 4504 is coupled to one or more radio units that each include one or more transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In some embodiments, some signaling can be provided with the use of a control system 4512 which may alternatively be used for communication between hardware nodes and radio units.

[0184] Figure 29 is a schematic block diagram showing an example computer-implemented apparatus 4700, according to the embodiments herein. In an embodiment, the apparatus 4700 may be configured as the above mentioned network element (such as the wireless device 4300, the network node 4400, or components of the power management system including the power management environment and actuator 3020, the RL power management engine 3040, or the pool power management function 3080) , as shown in previous figures.

[0185] In an embodiment, the apparatus 4700 may include but not limited to at least one processor such as Central Processing Unit (CPU) 4701, a computer-readable medium 4702, and a memory 4703. The memory 4703 may comprise a volatile (e.g., Random Access Memory, RAM) and / or non-volatile memory (e.g., a hard disk or flash memory) . In an embodiment, the computer-readable medium 4702 may be configured to store a computer program and / or instructions, which, when executed by the processor 4701, causes the processor 4701 to carry out any of the above mentioned methods, e. g, 3400, 3500, 3700, 3900 and others.

[0186] In an embodiment, the computer-readable medium 4702 (such as tangible, non-transient computer readable medium) may be stored in the memory 4703. In another embodiment, the computer program may be stored in a remote location for example computer program product 4704 (also may be embodied as or include a tangible, non-transient computer-readable medium) , and accessible by the processor 4701 via for example carrier 4705.

[0187] The computer-readable medium 4702 and / or the computer program product 4704 may be distributed and / or stored on a removable computer-readable medium, e.g. diskette, CD (Compact Disk) , DVD (Digital Video Disk) , flash or similar removable memory media (e.g. compact flash, SD (secure digital) , memory stick, mini SD card, MMC multimedia card, smart media) , HD-DVD (High Definition DVD) , or Blu-ray DVD, USB (Universal Serial Bus) based removable memory media, magnetic tape media, optical storage media, magneto-optical media, bubble memory, or distributed as a propagated signal via a network (e.g. Ethernet, ATM, ISDN, PSTN, X. 25, Internet, Local Area Network (LAN) , or similar networks capable of transporting data packets to the infrastructure node) .

[0188] Although the computing devices described herein (e.g., UEs, network nodes, hosts) may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and / or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and / or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.

[0189] In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer-readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and / or by end users and a wireless network generally.

[0190] Features of any of the examples or embodiments outlined above may be combined to create additional examples or embodiments without losing the intended effect. It should be understood that the description of an embodiment or example provided above is by way of example only, and various modifications could be made by one skilled in the art. Furthermore, one skilled in the art will recognise that numerous further modifications and combinations of various aspects are possible. Accordingly, the described aspects are intended to encompass all such alterations, modifications, and variations that fall within the scope of the appended claims.Example Embodiments

[0191] Below are provided a variety of possible example embodiments under the present disclosure. These examples are provided solely to illustrate possible use cases or embodiments, and are not an exhaustive list of possible embodiments.

[0192] Embodiment 1: A computer-implemented method for performing power management for cloud native applications, the method comprising: (a) receiving an identification of an application and one or more performance requirements related to the application; (b) setting an initial power profile for each of the one or more microservices; (c) deploying the application among the one or more microservices; (d) applying the initial power profile to each of the one or more microservices; (e) measuring one or more performance metrics related to the deployed application and the one or more microservices; (f) detecting one or more capabilities of the one or more cloud-based hardware; (g) comparing the one or more performance metrics and the one or more capabilities; (h) calculating an updated power profile for each of the one or more microservices; and (i) repeating steps (d) to (h) using the updated power profile.

[0193] Embodiment 2: The method of embodiment 1, wherein the one or more cloud-based hardware comprise a Kubernetes system.

[0194] Embodiment 3: The method of embodiment 1 or 2, wherein the one or more performance metrics comprise one or more of: power consumption; power consumption per pod; power consumption per node; processing latency; one or more Central Processing Unit, CPU, data; one or more memory data; an end to end latency.

[0195] Embodiment 4: The method of any of embodiments 1 to 3, wherein the one or more microservices are deployed amongst one or more pods and / or one or more nodes, wherein the one or more cloud-based hardware comprise the one or more pods and / or one or more nodes.

[0196] Embodiment 5: The method of any of embodiments 1 to 4, wherein the initial power profile and / or updated power profile comprise at least one of: a Dynamic voltage frequency scaling, DVFS, power management method; a Performance State, P-State, power management method; a C-State power management method; a Speed Select Technology, SST, power management method.

[0197] Embodiment 6: A computer-implemented method for performing power management for cloud native applications, the method comprising: (a) defining, by a fine granular power controller, an initial power profile for each of one or more microservices, each of the one or more microservices operable to assist in performing an application, the one or more microservices configured to be deployed amongst one or more nodes, each of the one or more nodes comprising one or more pods and a Power Management, PM, Agent; (b) collecting, by the fine granular power controller from each of the PM Agents, one or more capabilities of the one or more nodes; (c) defining, by the fine granular power controller, a hardware mapping for each of the initial power profiles based at least in part on the one or more capabilities, each hardware mapping defining which of the one or more nodes and one or more pods will comprise each of the one or more microservices; (d) deploying, by a cloud platform comprising the fine granular power controller, the application among the one or more microservices; (e) scheduling, by the cloud platform, the one or more nodes and one or more pods as set forth in each hardware mapping; (f) notifying, by the cloud platform, the fine granular power controller of the deploying; (g) setting, by the fine granular power controller, the initial power profile in the one or more pods and the one or more nodes; (h) collecting, by a power metrics collector comprising the cloud platform, one or more power metrics from the one or more nodes, the one or more power metrics related to the deployed application and / or the one or more microservices; (i) querying, by the fine granular power controller from a power metrics collector, the one or more power metrics; (j) querying, by the fine granular power controller from a performance metrics collector, one or more performance metrics related to the deployed application and the one or more microservices, the performance metrics collector configured to collect the one or more performance metrics from the one or more nodes; (k) calculating, by the fine granular power controller, an updated power profile for each of the one or more microservices based at least in part on; the one or more capabilities, the one or more power metrics, and the one or more performance metrics; (l) querying, by the fine granular power controller from the cloud platform, one or more pod deployments; (m) instructing, by the fine granular power controller, each PM Agent to implement each updated power profile; and (n) applying, by each PM Agent, each updated power profile at each respective node of the one or more nodes.

[0198] Embodiment 7: The method of embodiment 6, further comprising repeating steps (j) to (n) on a periodic or non-periodic basis.

[0199] Embodiment 8: The method of embodiments 6 or 7, wherein the one or more cloud-based hardware comprise a Kubernetes system.

[0200] Embodiment 9: The method of any of embodiments 6 to 8, wherein the one or more performance metrics comprise one or more of: power consumption; power consumption per pod; power consumption per node; processing latency; one or more Central Processing Unit, CPU, data; one or more memory data; an end to end latency.

[0201] Embodiment 10: The method of any of embodiments 6 to 9, wherein the initial power profile and / or updated power profile comprise at least one of: a Dynamic voltage frequency scaling, DVFS, power management method; a Performance State, P-State, power management method; a C-State power management method; a Speed Select Technology, SST, power management method.

[0202] Embodiment 11: A method performed by a fine granular power controller in a cloud environment, for performing power management for cloud native applications, the method comprising: (a) defining an initial power profile for each of one or more microservices, the one or more microservices configured to provide cloud-based performance of an application; (b) collecting, from each Power Management, PM, Agent, one or more capabilities of one or more nodes, the one or more nodes configured to provide the one or more microservices and each comprising a PM agent, the PM Agent configured to apply power profiles of the one or more microservices from the fine granular power controller at each of the one or more nodes, the one or more nodes each comprising one or more pods; (c) defining a hardware mapping for each of the initial power profiles based at least in part on the one or more capabilities, each hardware mapping defining which of the one or more nodes and one or more pods will comprise each of the one or more microservices (d) receiving a notification that the application has been deployed in the cloud environment; (e) setting the initial power profile in the one or more pods and the one or more nodes; (f) querying, from a power metrics collector, one or more power metrics related to the deployed application and the one or more microservices, the power metrics collector configured to collect the one or more power metrics from the one or more nodes; (g) querying, from a performance metrics collector, one or more performance metrics related to the deployed application and the one or more microservices, the performance metrics collector configured to collect the one or more performance metrics from the one or more nodes; (h) calculating an updated power profile for each of the one or more microservices based at least in part on; the one or more capabilities, the one or more power metrics, and the one or more performance metrics; and (i) instructing each PM Agent to implement each updated power profile.

[0203] Embodiment 12: The method of embodiment 11, further comprising repeating steps (g) to (i) on a periodic or non-periodic basis.

[0204] Embodiment 13: The method of embodiment 11 or 12, wherein the cloud environment comprises a Kubernetes system.

[0205] Embodiment 14: The method of any of embodiments 11 to 13, wherein the one or more performance metrics comprise one or more of: power consumption; power consumption per pod; power consumption per node; processing latency; one or more Central Processing Unit, CPU, data; one or more memory data; an end to end latency.

[0206] Embodiment 15: The method of any of embodiments 11 to 14, wherein the initial power profile and / or updated power profile comprise at least one of: a Dynamic voltage frequency scaling, DVFS, power management method; a Performance State, P-State, power management method; a C-State power management method; a Speed Select Technology, SST, power management method.

[0207] Embodiment 16: A method performed by a Power Management, PM, Agent in a cloud environment for performing power management for cloud native applications, the method comprising: (a) providing, to a fine granular power controller, one or more capabilities of one or more nodes, wherein the cloud environment comprises the one or more nodes for providing one or more microservices, each of the one or more nodes comprising one or more pods and a PM Agent, each PM Agent configured to apply power profiles of the one or more microservices from the fine granular power controller at each of the one or more nodes; (b) receiving an instruction, from the fine granular power controller, to implement an updated power profile at its respective node one of the one or more nodes, the updated power profile based at least in part on; the one or more capabilities, one or more power metrics, and one or more performance metrics; the one or more power metrics and the one or more performance metrics related to the deployed application and the one or more microservices; and (c) applying the updated power profile at the respective node of the one or more nodes.

[0208] Embodiment 17: The method of embodiment 16, further comprising repeating steps (b) to (c) on a periodic or non-periodic basis.

[0209] Embodiment 18. The method of embodiments 16 or 17, wherein the one or more cloud-based hardware comprise a Kubernetes system.

[0210] Embodiment 19: The method of any of embodiments 16 to 18, wherein the one or more performance metrics comprise one or more of: power consumption; power consumption per pod; power consumption per node; processing latency; one or more Central Processing Unit, CPU, data; one or more memory data.

[0211] Embodiment 20: The method of any of embodiments 16 to 19, wherein the initial power profile and / or updated power profile comprise at least one of: a Dynamic voltage frequency scaling, DVFS, power management method; a Performance State, P-State, power management method; a C-State power management method; a Speed Select Technology, SST, power management method.

[0212] Embodiment 21: A cloud environment system for performing power management for cloud native applications, comprising: processing circuitry; and a memory, the memory containing instructions executable by the processing circuitry whereby the system is operative to perform the steps of: (a) receiving an identification of an application and one or more performance requirements related to the application; (b) setting an initial power profile for each of the one or more microservices; (c) deploying the application among the one or more microservices; (d) applying the initial power profile to each of the one or more microservices; (e) measuring one or more performance metrics related to the deployed application and the one or more microservices; (f) detecting one or more capabilities of the one or more cloud-based hardware; (g) comparing the one or more performance metrics and the one or more capabilities; (h) calculating an updated power profile for each of the one or more microservices; and (i) repeating steps (d) to (h) using the updated power profile.

[0213] Embodiment 22: The system of claim 21, wherein the system comprises a Kubernetes system.

[0214] Embodiment 23: A cloud environment system for performing power management for cloud native applications, comprising: one or more nodes configured to provide one or more microservices to assist a deployed application, each of the one or more nodes comprising one or more pods and Power Management, PM, Agent, the PM Agent configured to implement power profiles of the one or more microservices in the one or more nodes; a power metrics collector configured to collect, from the one or more nodes, one or more power metrics related to the deployed application and the one or more microservices; a performance metrics collector configured to collect, from the one or more nodes, one or more performance metrics related to the deployed application and the one or more microservices; a fine granular power controller configured to: define an initial power profile for each of the one or more microservices; collect, from each PM Agent, one or more capabilities of the one or more nodes; define a hardware mapping for each of the initial power profiles based at least in part on the one or more capabilities, each hardware mapping defining which of the one or more nodes and one or more pods will comprise each of the one or more microservices; set the initial power profile in the one or more pods and the one or more nodes; query, from the power metrics collector, the one or more power metrics; query, from the performance metrics collector, the one or more performance metrics; calculate an updated power profile for each of the one or more microservices based at least in part on; the one or more capabilities, the one or more power metrics, and the one or more performance metrics; and instruct each PM Agent to implement each updated power profile.

[0215] Embodiment 24: The system of claim 23, wherein the fine granular power controller is further configured to repeat steps (d) to (g) on a periodic or non-periodic basis.

Claims

1.A computer-implemented method (3400) for power management of a cloud native application (3010) comprising a plurality of microservices deployed across one or more worker nodes (3075) of a container orchestration cluster (1060) , the method comprising:collecting (3410) , by a power management environment and actuator (3020) , metrics associated with the cloud native application (3010) , the metrics including at least one of energy consumption, resource usage, and application performance;constructing (3420) , by the power management environment and actuator (3020) , a state vector based on the collected metrics;providing (3430) the state vector to a reinforcement learning power management engine (3040) ;determining (3440) , by the reinforcement learning power management engine (3040) , a power management decision based on the state vector using a reinforcement learning agent (3042) ;translating (3450) , by the power management environment and actuator (3020) , the power management decision into one or more power management actions; andenforcing (3460) the one or more power management actions on the plurality of microservices in the one or more worker nodes (3075) .2.The method of claim 1, wherein the power management decision comprises at least one of:a high-level power profile for each microservice of the plurality of microservices, the high-level power profile indicating a balance between energy consumption and performance; ora low-level power management action for each microservice of the plurality of microservices.3.The method of any of claims 1 or 2, wherein enforcing (3460) the one or more power management actions comprises assigning each microservice to a power management pool (3082, 3084) based on the power management decision, wherein microservices assigned to a same power management pool share CPU cores (3086, 3088) .4.The method of claim 3, wherein enforcing (3460) the one or more power management actions further comprises applying low-level power management actions to the CPU cores (3086, 3088) of each power management pool (3082, 3084) , the low-level power management actions including at least one of a P-state setting and a CPU frequency setting.5.The method of claim 3 or 4, further comprising dynamically migrating a microservice from a first power management pool to a second power management pool in response to a change in the power management decision for the microservice.6.The method of any of claims 1 to 5, wherein the reinforcement learning agent (3042) operates in a hierarchical agent mode comprising:a meta-agent configured to determine high-level power profiles for the plurality of microservices; anda worker-agent configured to determine low-level power management actions for the high-level power profiles.7.The method of any of claims 1 to 6, wherein determining (3440) the power management decision comprises calculating a reward based on a reward function that incentivizes energy efficiency while penalizing violations of a performance key performance indicator.8.The method of claim 7, wherein the reward function comprises a weighted sum of a total power consumption term and a latency penalty term.9.The method of any of claims 1 to 8, wherein determining (3440) the power management decision comprises executing a policy update using Proximal Policy Optimization with a clipping mechanism to restrict policy updates.10.The method of any of claims 1 to 9, wherein collecting (3410) the metrics comprises at least one of:retrieving power consumption and resource usage metrics from a control plane (3070) of the container orchestration cluster (1060) ;retrieving one or more power metrics from a power meter associated with one or more components not associated with the control plane; orretrieving application-level metrics from the cloud native application (3010) .11.The method of any of claims 1 to 10, wherein the state vector comprises:an application performance sub-vector including at least one of end-to-end latency, requests per second, and error rate;a resource utilization sub-vector including CPU usage and memory usage for each microservice; andan energy consumption value representing total power consumption.12.The method of any of claims 1 to 11, further comprising:retrieving application requirements and information from the cloud native application (3010) , the application requirements including performance key performance indicators and a list of microservices;retrieving cluster and deployment information from a control plane (3070) of the container orchestration cluster (1060) ; andconfiguring the power management environment and actuator (3020) and the reinforcement learning power management engine (3040) based on the retrieved information.13.The method of claim 12, wherein configuring comprises defining an action space (3046) and a state space (3046) based on the retrieved application requirements and cluster information.14.The method of any of claims 1 to 13, wherein the method (3400) is performed continuously in a loop to enable the reinforcement learning power management engine (3040) to learn and adapt power management decisions over time.15.A system (3000) for power management of a cloud native application (3010) comprising a plurality of microservices deployed across one or more worker nodes (3075) of a container orchestration cluster (1060) , the system (3000) comprising:a power management environment and actuator (3020) configured to:collect metrics associated with the cloud native application (3010) , the metrics including at least one of energy consumption, resource usage, and application performance;construct a state vector based on the collected metrics; andtranslate a power management decision into one or more power management actions;a reinforcement learning power management engine (3040) configured to determine the power management decision based on the state vector using a reinforcement learning agent (3042) ; anda pool power management function (3080) in each of the one or more worker nodes (3075) , the pool power management function (3080) configured to enforce the one or more power management actions on the plurality of microservices.16.The system (3000) of claim 15, wherein the power management environment and actuator (3020) comprises:a metrics collector (3022) configured to collect the metrics from the container orchestration cluster (1060) and the cloud native application (3010) ;a state constructor (3028) configured to transform and aggregate the collected metrics into the state vector; andan action dispatcher (3024) configured to translate the power management decision into the one or more power management actions and dispatch the actions to the pool power management function (3080) .17.The system (3000) of claim 15 or 16, wherein the reinforcement learning power management engine (3040) comprises:the reinforcement learning agent (3042) configured to operate in one of a single agent mode or a hierarchical agent mode; andan action / state space component (3046) configured to define and maintain an action space and a state space based on information received from the power management environment and actuator (3020) .18.The system (3000) of any of claims 15 to 17, wherein the pool power management function (3080) is configured to maintain a plurality of power management pools (3082, 3084) , each power management pool having associated CPU cores (3086, 3088) with respective low-level power management settings.19.The system (3000) of claim 18, wherein the pool power management function (3080) is further configured to dynamically assign or migrate microservices between the plurality of power management pools (3082, 3084) based on the power management decision.20.The system (3000) of any of claims 15 to 19, wherein the reinforcement learning agent (3042) is configured to use Proximal Policy Optimization with an Actor-Critic architecture.21.The system (3000) of any of claims 15 to 20, wherein the container orchestration cluster (1060) comprises a Kubernetes cluster.22.A computer-implemented method (3500) performed by a reinforcement learning power management engine (3040) for power management of a cloud native application (3010) comprising a plurality of microservices deployed across one or more worker nodes (3075) of a container orchestration cluster (1060) , the method (3500) comprising:receiving (3510) a state vector from a power management environment and actuator (3020) , the state vector representing an operational context of the cloud native application (3010) based on collected metrics including at least one of energy consumption, resource usage, and application performance;determining (3520) , by a reinforcement learning agent (3042) , a power management decision based on the state vector, the power management decision comprising a power profile for each microservice of the plurality of microservices; andtransmitting (3530) the power management decision to the power management environment and actuator (3020) for translation into one or more power management actions enforceable on the plurality of microservices.23.The method (3500) of claim 22, wherein determining (3520) the power management decision comprises:calculating a reward based on a reward function that comprises a weighted sum of a total power consumption term and a latency penalty term; andexecuting a policy update based on the calculated reward to select an optimal power management decision.24.The method (3500) of claim 22 or 23, wherein the reinforcement learning agent (3042) operates in a hierarchical agent mode, wherein a meta-agent determines high-level power profiles for the plurality of microservices and a worker-agent determines low-level power management actions for the high-level power profiles.25.The method (3500) of any of claims 22 to 24, further comprising:receiving information from the power management environment and actuator (3020) , the information including a defined state space and action space (3046) ; andconfiguring an internal architecture of the reinforcement learning power management engine (3040) based on the received information, including selecting an optimization algorithm and an architectural mode.26.A computer-implemented method (3700) performed by a power management environment and actuator (3020) for power management of a cloud native application (3010) comprising a plurality of microservices deployed across one or more worker nodes (3075) of a container orchestration cluster (1060) , the method (3700) comprising:collecting (3710) metrics associated with the cloud native application (3010) , the metrics including at least one of energy consumption, resource usage, and application performance;constructing (3720) a state vector based on the collected metrics, the state vector representing an operational context of the cloud native application (3010) ;providing (3730) the state vector to a reinforcement learning power management engine (3040) ;receiving (3740) a power management decision from the reinforcement learning power management engine (3040) , the power management decision comprising a power profile for each microservice of the plurality of microservices;translating (3750) the power management decision into one or more power management actions enforceable at a microservice level; anddispatching (3760) the one or more power management actions to a pool power management function (3080) in the one or more worker nodes (3075) .27.The method (3700) of claim 26, wherein collecting (3710) the metrics comprises:retrieving power consumption and resource usage metrics from a control plane (3070) of the container orchestration cluster (1060) ; andretrieving application-level metrics including performance key performance indicators from the cloud native application (3010) .28.The method (3700) of claim 26 or 27, further comprising:retrieving application requirements and information from the cloud native application (3010) , the application requirements including performance key performance indicators and a structural representation of the plurality of microservices;retrieving cluster-level and node-level deployment information from a control plane (3070) of the container orchestration cluster (1060) ; andconfiguring a state space and an action space (3046) based on the retrieved application requirements and deployment information.29.The method (3700) of any of claims 26 to 28, wherein translating (3750) the power management decision comprises mapping a high-level power profile for each microservice to a corresponding power management pool (3082, 3084) in the one or more worker nodes (3075) .30.A computer-implemented method (3900) performed by a pool power management function (3080) in a worker node (3075) of a container orchestration cluster (1060) for power management of a cloud native application (3010) comprising a plurality of microservices, the method (3900) comprising:receiving (3910) one or more power management actions from a power management environment and actuator (3020) , the one or more power management actions corresponding to a power management decision for the plurality of microservices;assigning (3920) each microservice of the plurality of microservices to a power management pool (3082, 3084) based on the received power management actions, wherein each power management pool has associated CPU cores (3086, 3088) ; andenforcing (3930) low-level power management actions on the CPU cores (3086, 3088) of each power management pool (3082, 3084) .31.The method (3900) of claim 30, wherein the power management pools (3082, 3084) comprise a performance pool (3082) and a powersave pool (3084) , wherein microservices assigned to the performance pool (3082) are allocated to CPU cores (3086) configured with performance-oriented power settings and microservices assigned to the powersave pool (3084) are allocated to CPU cores (3088) configured with power-saving settings.32.The method (3900) of claim 30 or 31, wherein enforcing (3930) the low-level power management actions comprises applying at least one of a P-state setting and a CPU frequency setting to the CPU cores (3086, 3088) of each power management pool (3082, 3084) .33.The method (3900) of any of claims 30 to 32, further comprising dynamically migrating a microservice from a first power management pool to a second power management pool in response to receiving an updated power management action for the microservice.34.A computer program (4704) comprising instructions which, when executed by processing circuitry (4701) , cause the processing circuitry to perform the method of any of claims 1 to 14, 22 to 25, 26 to 29, or 30 to 33.35.A computer-readable medium (4702) storing the computer program of claim 34.

Images