Energy savings through flexible Cubanetis pod capacity selection during horizontal pod auto-scaling (HPA).

Abstract

Methods, apparatus, and non-temporary computer-readable media are described. An artificial intelligence / machine learning (AI / ML) based horizontal pod automatic scaler (HPA) is implemented. Performance metrics regarding pod resource allocation and capacity are received by the HPA. Current traffic demand is measured, and future traffic demand is predicted relative to the current system capacity. Pod capacity and scaling are selected based on the measured current traffic demand and the predicted future traffic demand relative to the current system capacity, in order to provide optimal performance for current and future traffic demand according to the pod capacity category. Scaling commands are generated for the selected pod capacity and selected scaling to provide fine-grained scaling to optimize energy consumption according to the pod capacity category. Scaling commands are sent to the Cubanetis API to scale the pods to meet current and future traffic demand according to the pod capacity category.

Claims

1. A method for reducing energy consumption by flexible Cubanetis pod capacity selection during horizontal pod auto-scaling (HPA), To implement an artificial intelligence / machine learning (AI / ML) based horizontal pod automatic scaler (HPA), The HPA receives performance metrics regarding pod resource allocation and capacity, This involves measuring current traffic demand and predicting future traffic demand relative to current system capacity, In order to provide optimal performance for the current and future traffic demands according to the pod capacity category, select and scale pod capacity in terms of the number of pods and pod capacity version based on the measured current traffic demand and the predicted future traffic demand relative to the current system capacity. To provide fine-grained scaling to optimize energy consumption according to pod capacity categories, the system generates scaling commands for the selected pod capacity and the selected scaling, A method comprising scaling a pod to meet the current and future traffic demands according to a pod capacity category based on the scaling command.

2. Implementing the aforementioned AI / ML-based HPA includes implementing a non-real-time radio access network intelligent controller (non-RT RIC), The non-RT RIC uses rApp to apply the scaling command to pods deployed in the open cloud (O-cloud) system. Receiving the performance metrics includes obtaining performance metrics by the non-RT RIC by collecting O Cloud Failure, Configuration, Accounting, Performance, and Security (FCAPS) data via the O2 interface and collecting E2 node data via the O1 interface. The method according to claim 1, wherein the non-RT RIC trains and deploys an AI / ML model to generate scaling guidance for the O-cloud or the E2 node based on priority, load and energy consumption, and quality of service specifications.

3. The method according to claim 2, wherein training and deploying the AI / ML model with the non-RT RIC includes training and deploying at least one of a linear regression model, a feedforward neural network (FNN), a convolutional neural network (CNN) model, or a long-short-term memory model.

4. The method according to claim 1, wherein the scaling command is generated by a scaling determination unit based on data, the data being received from an application type and quality-of-experience (QoE) application specification, a quality-of-service (QoS) related configuration and specification, a scaling policy for improving performance, increasing energy savings, minimizing hardware resource utilization, maximizing throughput, minimizing latency, and meeting a latency budget, and a hardware configuration.

5. The method according to claim 1, wherein the HPA receiving performance metrics relating to pod resource allocation and capacity includes receiving one or more of the following: the number of radio resource control (RRC) connections, the number of active / inactive user devices (UEs), the number of data radio bearers (DRBs), or average throughput.

6. The method according to claim 1, wherein sending the scaling command to the container manager includes sending the scaling command to the container manager to instruct a deployment / replication controller (RC) to scale the pods according to the pod capacity category.

7. The method according to claim 1, wherein selecting the pod capacity with respect to the number of pods and pod capacity version selection based on the measured current traffic demand and the predicted future traffic demand, and selecting the scaling, includes tracking traffic demand using fine granularity to match the current system capacity with actual traffic demand and to match resource utilization with resource demand.

8. It is a device, A KPI predictor configured to receive performance metrics regarding pod resource allocation and capacity, measure current traffic demand, and forecast future traffic demand relative to current system capacity, A scaling determination unit configured to select pod capacity and scaling in terms of the number of pods and pod capacity version based on the measured current traffic demand and the predicted future traffic demand relative to the current system capacity, in order to provide optimal performance for the current and future traffic demand according to the pod capacity category, wherein the scaling determination unit generates scaling commands for the selected pod capacity and the selected scaling in order to provide fine-grained scaling to optimize energy consumption according to the pod capacity category. A device comprising a container manager configured to receive scaling commands to scale pods to meet the current and future traffic demands according to pod capacity categories.

9. The system further includes a non-real-time radio access network intelligent controller (non-RT RIC) configured to collect O-cloud fault, configuration, accounting, performance, and security (FCAPS) data via the O2 interface and E2 node data via the O1 interface. The non-RT RIC uses rApp to apply the scaling command received from the scaling determination unit to the pods deployed in the open cloud (O-cloud) system. The performance metrics include performance metrics for the non-RT RIC based on the collection of O-Cloud failure, configuration, accounting, performance, and security (FCAPS) data via the O2 interface and the collection of E2 node data via the O1 interface. The device according to claim 8, wherein the non-RT RIC trains and deploys an AI / ML model to generate scaling guidance for the O-cloud or the E2 node based on priority, load and energy consumption, and quality of service specifications.

10. The device according to claim 9, wherein the non-RT RIC is configured to train and deploy the AI / ML model by training and deploying at least one of the following: a linear regression model, a feedforward neural network (FNN), a convolutional neural network (CNN) model, or a long-short-term memory model.

11. The device according to claim 8, wherein the scaling determination unit is configured to generate the scaling command based on data, the data being received from the application type and quality-of-experience (QoE) application specifications, quality-of-service (QoS) related configurations and specifications, a scaling policy for improving performance, increasing energy savings, minimizing hardware resource utilization, maximizing throughput, minimizing latency, meeting a latency budget, and hardware configuration.

12. The device according to claim 8, wherein the KPI predictor is configured to receive performance metrics relating to the resource allocation and capacity of a pod by receiving one or more of the following: the number of radio resource control (RRC) connections, the number of active / inactive user devices (UEs), the number of data radio bearers (DRBs), or average throughput.

13. The device according to claim 8, wherein the scaling determination unit is configured to send the scaling command to the container manager instructing the deployment / replication controller (RC) to scale the pods according to the pod capacity category.

14. The device according to claim 8, wherein the scaling determination unit is configured to select the scaling with respect to the number of pods and pod capacity version selection based on the measured current traffic demand and the predicted future traffic demand, by tracking traffic demand using fine granularity in order to match the current system capacity with actual traffic demand and to match resource utilization with resource demand.

15. A non-temporary computer-readable medium storing computer-readable instructions for performing an operation, wherein the operation is: To implement an artificial intelligence / machine learning (AI / ML) based horizontal pod automatic scaler (HPA), The HPA receives performance metrics regarding pod resource allocation and capacity, This involves measuring current traffic demand and predicting future traffic demand relative to current system capacity, In order to provide optimal performance for the current and future traffic demands according to the pod capacity category, select and scale pod capacity in terms of the number of pods and pod capacity version based on the measured current traffic demand and the predicted future traffic demand relative to the current system capacity. To provide fine-grained scaling to optimize energy consumption according to pod capacity categories, the system generates scaling commands for the selected pod capacity and the selected scaling, A non-transient computer-readable medium, which includes scaling a pod to meet the current and future traffic demands according to a pod capacity category based on the scaling command.

16. Implementing the AI / ML-based HPA includes implementing a non-real-time radio access network intelligent controller (non-RT RIC), the non-RT RIC using rApp to apply the scaling commands to pods deployed in an open cloud (O-cloud) system and to receive the performance metrics, the non-RT RIC obtaining performance metrics by collecting O-cloud fault, configuration, accounting, performance, and security (FCAPS) data via the O2 interface and E2 node data via the O1 interface, the non-RT RIC training and deploying an AI / ML model to generate scaling guidance for the O-cloud or the E2 nodes based on priority, load and energy consumption, and quality of service specifications. The non-temporal computer-readable medium according to claim 15, wherein training and deploying the AI / ML model by the non-RT RIC includes training and deploying at least one of a linear regression model, a feedforward neural network (FNN), a convolutional neural network (CNN) model, or a long-short-term memory model.

17. The non-transient computer-readable medium according to claim 16, wherein the scaling command is generated by a scaling determination unit based on data, the data being received from an application type and quality-of-experience (QoE) application specification, a quality-of-service (QoS) related configuration and specification, a scaling policy for improving performance, increasing energy savings, minimizing hardware resource utilization, maximizing throughput, minimizing latency, meeting a latency budget, and a hardware configuration.

18. The non-transient computer-readable medium according to claim 15, wherein the HPA receiving performance metrics relating to pod resource allocation and capacity includes receiving one or more of the following: the number of radio resource control (RRC) connections, the number of active / inactive user devices (UEs), the number of data radio bearers (DRBs), or average throughput.

19. The non-temporary computer-readable medium according to claim 15, wherein sending the scaling command to the Cubanetis API includes sending the scaling command to the Cubanetis API to instruct a deployment / replication controller (RC) to scale the pods according to a pod capacity category.

20. The non-temporary computer-readable medium according to claim 15, wherein selecting the pod capacity with respect to the number of pods and pod capacity version selection based on the measured current traffic demand and the predicted future traffic demand, and selecting the scaling, includes tracking traffic demand using fine granularity to match the current system capacity with actual traffic demand and to match resource utilization with resource demand.

Images