Adaptive Resource Management for a Virtualized Computing Platform within Edge Computing

TL;DR

This paper introduces ARCES, an online resource management algorithm for edge computing that minimizes energy consumption by jointly optimizing computing and communication resources under QoS constraints.

Contribution

It proposes a novel energy-aware server management algorithm that considers both computing and communication energy, integrating traffic forecasting, workload allocation, and energy harvesting in edge environments.

Findings

ARCES achieves up to 69% energy savings.

Energy consumption reduced to 31%-45% of baseline.

Effective under various reconfiguration costs.

Abstract

In virtualized computing platforms, energy consumption is related to the computing-plus-communication processes. However, most of the proposed energy consumption models and energy saving solutions found in literature consider only the active Virtual Machines (VMs), thus the overall operational energy expenditure is usually related to solely the computation process. To address this shortcoming, in this paper we consider a computing-plus-communication energy model, within the Multi-access Edge Computing (MEC) paradigm, and then put forward a combination of a traffic engineering- and MEC Location Service-based online server management algorithm with Energy Harvesting (EH) capabilities, called Automated Resource Controller for Energy-aware Server (ARCES), for autoscaling and reconfiguring the computing-plus-communication resources. The main goal is to minimize the overall energy consumption, under hard per-task delay constraints (i.e., Quality of Service (QoS)). ARCES jointly performs (i) a short-term server demand and harvested solar energy forecasting, (ii) VM soft-scaling, workload and processing rate allocation and lastly, (iii) switching on/off of transmission drivers (i.e., fast tunable lasers) coupled with the location-aware traffic scheduling. Our numerical results reveal that ARCES achieves on average energy savings of 69%, and an energy consumption ranging from 31%-45%and from 21%-25% at different values of per-VM reconfiguration cost, with respect to the case where no energy management is applied.

Tables

Table 1. TABLE I : System Parameters.

Parameter	Value
Max. number of VMs, $M$	$10$
Min. number of VMs, $d$	$1$
Time slot duration, $\tau$	$1\min$
Idle state energy for VM $m$, ${\theta }_{\mathrm{idle},m}\left(t\right)$	$10J$
Max. energy for VM $m$, ${\theta }_{\max ,m}\left(t\right)$	$60J$
per-VM reconfiguration cost, ${\kappa }_e$	$0.005J/{\left(\mathrm{MHz}\right)}^2$
TOE in idle state, ${\theta }_{\mathrm{idle}}^{\mathrm{TOE}}\left(t\right)$	$13.1J$
Max. allowed processing time, $\Delta$	$0.8s$
Processing rate set, $\left\{f_m\left(t\right)\right\}$	$\{0,50,70,90,105\}$
Bandwidth, $W_m$	$1\mathrm{MHz}$
Max. number of drivers, $Y$	$6$
Max. tolerable delay, ${\tau }_{\max }$	$2s$
Noise spectral density, $N_0^{\left(m\right)}$	-$174$ dBm/$\mathrm{Hz}$
Max. VM $m$ load, ${\gamma }^{\max }$	$5$ Mbit
Driver energy, $O_{\mathrm{opt},y}\left(t\right)$	$1J/s$
Target transmission rate, $r_0$	$1$ Mbps
Controllable factor of delay, $\alpha$	$0.96$
Reconfiguration overhead, $\sigma$	$20\mathrm{ms}$
Energy storage capacity, ${\beta }_{\max }$	$490\mathrm{kJ}$
Lower energy threshold, ${\beta }_{\mathrm{low}}$	$30$% of ${\beta }_{\max }$
Upper energy threshold, ${\beta }_{\mathrm{up}}$	$70$% of ${\beta }_{\max }$

Equations

$$\mbox{$\theta_{\rm MEC}(t)=\theta_{\rm COMP}(t)+\theta_{\rm COMM}(t)$}\,,$$

$$\mbox{$\theta_{\rm CPU}(t)=\sum_{m=1}^{M(t)}\theta_{{\rm idle},m}(t)+\theta_{{\rm dyn},m}(t)$},$$

$$\mbox{$\theta_{\rm SC}(t)=\sum_{m=1}^{M(t)}\kappa_{e}(f_{2}(t)-f_{1}(t))^{2}$},$$

$$\mbox{$\theta_{\rm TOE}(t)=\zeta(t)\,\theta_{\rm idle}^{\rm TOE}(t)\,+\theta_{\rm max}^{\rm TOE}(t)$},$$

$$\mbox{$\theta_{\rm VLAN}(t)=2\,\sum_{m=1}^{M(t)}P_{m}(r_{m}(t))(\lambda_{m}(t)/r_{m}(t))$},$$

$$\mbox{$\theta_{\rm WCOM}(t)=\sum_{y=1}^{Y(t)}\frac{O_{{\rm opt},y}(t)\,l_{y}(t)}{r_{0}}$},$$

$$B(t+1)=B(t)+H(t)-{\theta }_{\mathrm{MEC}}(t)+E(t),$$

$$:$$

$$C1$$

$$C2$$

$$C3$$

$$C4$$

$$C5$$

$$C6$$

$$C7$$

$$\text{textupsilon}(t+1)=\varphi (\text{textupsilon}(t),\psi (t)),$$

$$\widehat{\text{textupsilon}}(t+1)=\varphi (\text{textupsilon}(t),\psi (t)).$$

Full text

††publicationid: pubid: 978-1-7281-2294-6/19/$31.00 ©2019 IEEE

I Introduction

The data growth generated by pervasive mobile devices and the Internet of Things, couple with the demand for ultra-low latency, requires high computation resources which are not available at the end-user device. Undoubtedly, offloading to a powerful computational resource-enriched server located closer to mobile users is an ideal solution. Thus, Multi-access Edge Computing (MEC [1]) has recently emerged to enable low-latency and location-aware data processing at the network edge, i.e., in close proximity to mobile devices, sensors, actuators and connected things. Despite the potential presented by MEC, the computing resources (i.e., VMs) plus communication within the MEC server (node) raises concerns related to energy consumption, in the effort to build greener networks and reduce carbon emissions into the atmosphere. Nonetheless, with the integration of EH into the edge (or computing) system [2], resulting into an EH-powered MEC (EH-MEC) system, the carbon footprint and the dependence on the power grid can be minimized.

The energy drained in the computing platform due to the computing-plus-communication processes is associated with (i) the running VMs [3][4] and (ii) the communication within the server’s virtual network [5] (see Fig. 3.5 in this reference). It is observed in the literature that most of the existing Energy Saving (ES) studies have involved autoscaling [6][7][8][9][10] (scaling up/down the number of computing nodes/servers or VMs), VM migration [11] (movement of a VM from one host to another) and soft resource scaling [12] (shortening the access time to physical resources), all hereby referred to as VM soft-scaling, i.e., the reduction of computing resources per time instance. Hence, the proposed energy models (see [13] for a summary of the proposed models) and the overall operational expenditure of the computing node is usually related to the computation process (i.e., the running VMs), overlooking the communication processes within the server.

Regarding energy consumption related to communication within a computing node, it is shown in [14][15] that having the least number of data transmission drivers (fast tunable lasers) can yield significant amount of ESs. It is worth observing that both works, [14][15], are not along the direction of MEC, but they propose the tuning of the transmission drivers as one of the ES strategies within the Mobile Network (MN) infrastructure. Thus, ESs within the MEC server can be jointly achieved by launching an optimal number of VMs for computing, and transmission drivers coupled with the location-aware traffic routing for real-time data transfer.

I-A Motivation

The virtualized MEC node is equipped with higher computational and storage resources compared to the end-users devices, in order to handle the computation workload being generated at the network edge. However, while MEC tries to meet the computational demand and the guarantee of low-latency, the issue of energy consumption is still a challenge within the virtualized computing node [3][4]. To address this challenge: (i) it is expected that the Network Function Virtualization (NFV) framework can exploit the benefits of virtualization technologies to significantly reduce the energy consumption in MN infrastructure; (ii) the current trends in battery and solar module costs show an expected reduction. This two points motivate the integration of MEC and EH systems towards green computing [2][16].

I-B Related work

For several years, great effort has been devoted to study energy savings in computing environments with the aim of minimizing the energy consumption. Procedures for the dynamic on/off switching of servers have been proposed as a way of minimizing energy consumption in computing platforms. In [6], computing resources are provisioned depending on the expected server workloads via a reinforcement learning-based resource management algorithm, which learns the optimal policy for dynamic workload offloading and servers autoscaling. Our previous works in [7] and [17], focus on the provision of computing resources (VMs) based on a Limited Lookahead Control (LLC) policy and the network impact (the use of traffic load as a performance metric [18]), after forecasting the future workloads and harvested energy. A single Base Station (BS) optimization case is considered for an off-grid site in [7], and a multiple BS optimization case, each BS site powered by hybrid energy sources, is studied in [17] where the edge management procedures are enabled by an edge controller. This work differs from our previous works as the MEC server is placed in proximity to a BS cluster, and not one co-located for each BS. Moreover, here we focus on the integration of communication-related energy consumption by considering the tuning of the transmission drivers, which is a novel concept within the MEC paradigm. In [11], Central Processing Unit (CPU) utilization thresholds are used to identify over-utilized servers. VMs are migrated to servers that will accept them without incurring in high energy costs. Subsequently, the idle servers are turned-off.

Energy management is also of interest in data centers using virtualization technologies. Along the same lines of VM soft-scaling, in [8] a traffic engineering-based adaptive approach is presented with the aim of minimizing energy consumption induced by computing, communication and reconfiguration costs of virtualized clouds. An iterative method is used to obtain ESs within a server that transmits wirelessly to clients. Then, in [9] the computing-plus-communication is also considered towards a goal of saving energy through an adaptive transmission rate for a Fog node. An automated server provisioning algorithm that aims to meet workload demand while minimizing energy consumption in data centers is presented in [10]. Here, energy-aware server provisioning is performed by taking into account trade-offs between cost, performance, and reliability. Lastly, a soft resource scaling mechanism is proposed in [12] where the scheduler shortens the maximum resource usage time for each VM, i.e., the time slice allocated for using the underlying physical resources, in order to compensate for the low energy savings achieved with Dynamic Voltage and Frequency Scaling (DVFS).

I-C Objective and Contributions

The main contributions of this work are as follows:

• •

we consider the aforementioned scenario, where MEC and EH are combined into a single system located close to a BS cluster, towards energy self-sustainability in MNs. The EH-MEC system is equipped with solar panels for EH and an Energy Buffer (EB) for energy storage.

• •

We consider a computing-plus-communication energy model within the MEC paradigm, formulating a constrained optimization problem. Due to the non-linear behavior of the rate-vs-power relationship, the optimization problem is non-convex. To solve it, we convexify the function by using Geometric Programming (GP [19]) and then employing the CVXOPT toolbox111M. Andersen and J. Dahl. CVXOPT: Python Software for Convex Programming, 2019. [Online]. Available: https://cvxopt.org/ and approximations.

• •

We forecast the short-term future server workload and harvested energy, by using a Long Short-Term Memory (LSTM) neural network [20], to enable foresighted optimization.

• •

Lastly, we develop an online controller-based algorithm called Automated Resource Controller for Energy-aware Server (ARCES) for the MEC server management based on LLC theory [21] and energy management procedures. The main goal is to minimize the overall energy consumption, under hard per-task delay constraints (i.e., QoS), through the joint consideration of VM soft-scaling and the tuning of transmission drivers coupled with the location-aware traffic routing. To the best of our knowledge, this is a novel concept within the MEC paradigm. ARCES considers future server workloads, onsite green stored energy, and target BS (based on the Location Service (LS) [22]), and then enable ES procedures.

The proposed optimization strategy is able to reduce the energy consumption under the guidance of the online resource controller and the energy management procedures.

The rest of the paper is organized as follows. The system model is presented in Section II. In Section III, we detail the optimization problem and the proposed LLC-based online algorithm. Simulation results are discussed in Section IV. Lastly, we conclude our work in Section V.

II System Model

As a major deployment of MEC [1], the considered network scenario is illustrated in Fig. 1. It consists of a cache-enabled, TCP/IP offload-enabled (partial computation at the network adapter), virtualized MEC server hosting $M$ VMs and it is assumed to be deployed at an aggregation point [1][2], i.e., a point in proximity to a group of BSs interconnected to the MEC server for computation offloading. The MEC node is assumed to be equipped with higher computational and storage resources compared to the end-user device. The server clients are assumed to be mobile users moving in groups and they are represented by the Reference Point Group Mobility Model (RPGM [23]). Their current locations are known through the LS Application Programmable Interface (API) [22], in the MEC platform, which is a service that supports UE’s location retrieval mechanism, and then passing the information to the authorized applications within the server. The computing site is empowered with EH capabilities through a solar panel and an EB that enables energy storage. Energy supply from the power grid is also available for backup. The Energy Manager (EM) is an entity responsible for selecting the appropriate energy source and for monitoring the energy level of the EB. The virtualized Access Control Router (ACR) of Fig. 1 acts as an access gateway, responsible for routing, and it is locally hosted as an application. Moreover, we consider a discrete-time model, whereby time is discretized as $t=1,2,\dots$, and each time slot $t$ has a fixed duration $\tau$.

II-A Server Workload and Energy Consumption

For many MN services, the workload demand exhibits a diurnal behavior, thus it suffices to forecast the short-term server workload (using historical datasets [2][10]) and then enable dynamic resource management within the server. In this work, anonymized real server workload traces obtained from [24] are used to emulate server workloads due to the difficulties in obtaining relevant open source datasets containing computing requests. A trace file consist of the file size, session duration, total number of packets and average transmission rate, over one day. In our numerical results, we use the total number of packets, denoted by $L_{\rm in}(t)$ ([bits]), to represent the buffered (or admitted) computation workload at the input buffer at time slot $t$ (see red curve in Fig. 2). In addition, we assume that the upper-bounded input/output (I/O) queue’s of Fig. 1 are loss-free and they implement the First-In First-Out (FIFO) service discipline, thus $L_{\rm in}(t)=L_{\rm out}(t)$, where $L_{\rm out}(t)$ is the amount of the aggregate computation result stored at the output buffer.

The total energy consumption ([$\text{\,}\mathrm{J}$]) for the virtualized computing platform is formulated as follows, inspired by [7][8] and the virtualization knowledge from [5]:

[TABLE]

where $\theta_{\rm COMP}(t)$ is the energy drained due to computation and $\theta_{\rm COMM}(t)$ due to intra-communications processes in the MEC server at time slot $t$.

Computing energy

$\theta_{\rm COMP}(t)=\theta_{\rm CPU}(t)+\theta_{\rm SC}(t)+\theta_{\rm TOE}(t)$, where $\theta_{\rm CPU}(t)$ is the energy drained due to the running VMs, w.r.t CPU utilization, and $\theta_{\rm SC}(t)$ is the energy drained due to VM switching the processing rates $f_{m}(t)\in[0,f_{\rm max}]$. $f_{\rm max}$ [(bit/s)] is the maximum processing rate for VM $m$. $\theta_{\rm TOE}(t)$ is the energy induced by the TCP/IP offload on the network interface card (NIC, e.g., TCP/IP checksum offload). In practice, the VMs are instantiated on top of the CPU cores and each VM processes the currently allotted task by managing its own local virtualized computing resources, thus we model the processing rates to be between $f_{0}=0$ (represents zero speed of the VM, e.g., deep sleep or shutdown) and $f_{\rm max}$. Here, we assume that real-time processing of computation workloads is performed in parallel over the VMs interconnected by a power-limited and rate-adaptive switched Virtual Local Area Network (VLAN).

Considering that $\theta_{\rm CPU}(t)$ is related to the number of VMs running in time slot $t$, named $M(t)\leq M$, and on the CPU frequency that is allotted to each VM, $\theta_{\rm CPU}(t)$ is obtained using the linear relationship between the CPU utilization contributed by VM $m$, and the energy drained is, inspired by [7]:

[TABLE]

where $\theta_{{\rm idle},m}(t)$ represents the static energy drained by VM $m$ in the idle state, and the quantity $\theta_{{\rm dyn},m}(t)=\alpha_{m}(t)(\theta_{{\max},m}(t)-\theta_{{\rm idle},m}(t))$ represents the dynamic energy component of VM $m$, where $\alpha_{m}(t)=(f_{m}(t)/f_{\max})^{2}$ [21] is a load dependent factor and $\theta_{{\max},m}(t)$ is the maximum energy that VM $m$ can drain.

Next, we remark that the VM switching cost $\theta_{\rm SC}(t)$ depends on the frequency reconfiguration, i.e., the transition from $f_{1}(t)$ (current processing rate for VM $m$) to $f_{2}(t)$ (the next processing rate), as an example. In short, the energy cost depends on the absolute processing rate gap, $|f_{2}(t)-f_{1}(t)|$. Thus, $\theta_{\rm SC}(t)$ is defined as [8]:

[TABLE]

where $\kappa_{e}$ is the the per-VM reconfiguration cost caused by a unit-size frequency switching. Typically, $\kappa_{e}$ is limited to a few hundreds of $\text{\,}\mathrm{mJ}$ per $($\text{,}\mathrm{MHz}$)^{2}$.

At this regard, we put forward the following: at the beginning of time slot $t$, the online resource controller adaptively allocates the available virtual resources and thus determines the VMs demanded, $M(t)$, the workload allotted to VM $m$, denoted by $\lambda_{m}(t)$, and $f_{m}(t)$ for VM $m$ that will yield the desired or expected processing time, $\chi_{m}(t)=\lambda_{m}(t)/f_{m}(t)$. Note that $L_{\rm in}(t)=\sum_{m=1}^{M(t)}\lambda_{m}(t)$. Moreover, in practical application scenarios, the maximum per-VM computation load to be computed is generally limited up to an assigned value, named $\lambda_{\rm max}$. Lastly, the VM provisioning and workload allocation is discussed in Section III-B2, and $f_{m}(t)\stackrel{{\scriptstyle\Delta}}{{=}}\lambda_{m}(t)/\Delta$.

Along the same lines of computation, advancement in TCP/IP Offload Engine (TOE) technology enables partial computation in the server’s NIC [26], i.e., some TCP/IP processing (e.g., checksum computation) is offloaded to a specialized hardware on the network adapter, relieving the host CPU from the overhead of processing TCP/IP. Thus, $\theta_{\rm TOE}(t)$ is obtained by using the fact that it is data volume dependent and then determined using the workload volume received. Due to the lack of an existing TOE energy model, we rely on the performance measure for the Broadcom (Fibre) $10$ Gbps NIC [26], which is considered here as an example of a TCP/IP offload-capable device. Then, $\theta_{\rm TOE}(t)$ is obtained as:

[TABLE]

where $\theta_{\rm idle}^{\rm TOE}(t)>0$ is the energy drained by the TOE when powered, with all links connected without any data transfer. This motivates the idea of tuning even the NIC so that the energy drained is always zero when there is no data transfer. For this, we have $\zeta(t)=(0,1)$ as the NIC switching status indicator ($1$ for active state and [math] for idle state). $\theta_{\rm max}^{\rm TOE}(t)=\frac{L_{\rm in}(t)}{\eta}$ is the maximum energy drained by the TOE. $\eta$ is a fixed value measured in [Gbit/$\text{\,}\mathrm{J}$].

Communication energy

$\theta_{\rm COMM}(t)=\theta_{\rm VLAN}(t)+\theta_{\rm WCOM}(t)$, where $\theta_{\rm VLAN}(t)$ is the energy drained due to the communication links (to-and-from each VM), and $\theta_{\rm WCOM}(t)$ is the energy drained due to the number of transmission (optical) drivers used for the data transfer to target BS(s).

The communication energy within the VLAN is obtained by using the Shannon-Hartley exponential analysis. Here, we assume that each VM $m$ communicates with the resource controller through a dedicated reliable link, that operates at the transmission rate of $r_{m}(t)$ [(bit/s)]. Thus, the energy needed for sustaining the two-way $m^{\rm th}$ link is defined as, inspired by [16]:

[TABLE]

where $P_{m}(r_{m}(t))=\Gamma_{m}(2^{r_{m}(t)/W_{m}}-1)$ is the power drained by the $m^{\rm th}$ communication link and $\Gamma_{m}=\frac{W_{m}\times N_{0}^{(m)}}{g_{m}}$. $N_{0}^{(m)}($\text{,}\mathrm{W}\mathrm{/}\mathrm{Hz}$)$ is the noise spectral power density, $W_{m}$ is the bandwidth, and $g_{m}$ is the (non-negative) gain of the $m^{\rm th}$ link. In practical application scenarios, the maximum per-slot communication rate within the intra-VLAN is generally limited up to an assigned value $r_{\rm max}$. Thus, the following hard constraint must hold: $\sum_{m=1}^{M(t)}r_{m}(t)\leq r_{\rm max}$.

Before proceeding, we consider the two-way per-task execution delay ([s]). We have the $m=\{1,\dots,M(t)\}$ link connection delays, each denoted by $\Omega_{m}(t)=\lambda_{m}(t)/r_{m}(t)$, and $\chi_{m}(t)\leq\Delta$, where $\Delta$ is the maximum per-slot and per-VM processing time ([s]). At this regard, we note that $\Delta$ is also the server’s response time, i.e., the maximum time allowed for processing the total computation load and it is fixed in advance regardless of the task size allocated to VM $m$. Since parallel real-time processing is assumed in this work, the overall communication equates to $2\,\Omega_{m}(t)+\Delta$. Therefore, the hard per-task delay constraint on the computation time is: $\max\{2\,\Omega_{m}(t)\}+\Delta\leq\tau_{\rm max}$, where $\tau_{\rm max}$ is the maximum tolerable delay, which is fixed in advance.

Finally, $\theta_{\rm WCOM}(t)$ depends on the number of laser (optical) drivers, named $Y(t)\leq Y$ ($Y$ is the total number of them), that are required for transferring $\ell_{y}(t)\in L_{\rm out}(t)$ in time slot $t$ ($\ell_{y}(t)$ is the downlink traffic volume ([bits] of the driver at slot $t$). $L_{\rm out}(t)$ is accumulated over a fixed period of time to form a batch at the output buffer. At this regard, we note that a large number of drivers yield large transmission speed while at the same time resulting into high energy consumption [15]. Therefore, the energy consumption can be minimized by launching an optimal number of drivers for the data transfer. Moreover, for every mobile client who offloaded their task into the MEC server associated with the radio nodes, i.e. BSs, its location and the computation result is known through the UE subscription procedure (i.e., through the LS), thus enabling the location-aware traffic routing and obtaining $Y(t)$.

The energy drained during the data transmission process consists of the following: a constant energy for utilizing each fast tunable driver denoted by $O_{{\rm opt},y}(t)$ ([$\text{\,}\mathrm{J}$/s]), the target transmission rate $r_{0}$ [bits/s] and $L_{\rm out}(t)$. Thus, the energy is, inspired by [14][27]:

[TABLE]

where the parameter $Y(t)$ is obtained using the total number of target BSs as Y(t)=\big{\lceil}\frac{1}{\alpha}\cdot(\frac{\omega(t)+1}{\omega(t)})^{2}\big{\rceil} (see [14]), where $\omega(t)=\sqrt{\frac{\Upsilon}{\sigma N_{\rm BS}(t)}}$. $\alpha\in(0,1]$ is a controllable factor that determines the delay constraint of optical networks, $\sigma$ ([$\text{\,}\mathrm{ms}$]) is the reconfiguration cost for tuning the transceivers, $N_{\rm BS}(t)$ is an integer value representing the total number of target BSs at time slot $t$, and $\Upsilon$ is the number of time slots at which the computed workload is accumulated at the output buffer. $\alpha,\sigma,$ and $\Upsilon$ are fixed values. $L_{\rm out}(t)$ is equally distributed over the $Y(t)$ drivers.

II-B Energy Patterns and Storage

The energy buffer of Fig. 1 is characterized by its maximum energy storage capacity $B_{\rm max}$, and power charging/discharging and leaking losses are not assumed. At each time slot $t$, the EM provides the energy level report to the MEC server, through the pull mode procedure (e.g., File Transfer Protocol [28]), thus the EB level $B(t)$ is known, enabling the provision of the required computation and communication resources, i.e., the VMs and laser drivers.

In this work, the amount of harvested energy $H(t)$ in time slot $t$ is obtained from open-source solar traces within a solar panel farm located in Armenia [25] (see green curve in Fig. 2), where the dataset time scale matches our time slot duration ($1\text{\,}\mathrm{min}$). The dataset is the result of daily environmental records for a place assumed to be free from surrounding obstructions (e.g., buildings, shades). In our numerical results, $H(t)$ is obtained by picking one day data from the dataset and then scaling the solar energy to fit the EB capacity $B_{\rm max}$ of $490\text{\,}\mathrm{kJ}$. Thus, the available EB level $B(t+1)$ at the beginning of time slot $t+1$ is calculated as follows:

[TABLE]

where $B(t)$ is the energy level in the battery at the beginning of time slot $t$, $\theta_{\rm MEC}(t)$ is the energy consumption of the computing platform over time slot $t$, see Eq. (1), and $E(t)\geq 0$ is the amount of energy purchased from the power grid. We remark that $B(t)$ is updated at the beginning of time slot $t$ whereas $H(t)$ and $\theta_{\rm MEC}(t)$ are only known at the end of it.

For decision making by the resource controller, the received EB level reports are compared with the following thresholds: $B_{\rm low}$ and $B_{\rm up}$, respectively termed the lower and the upper energy threshold with $0<B_{\rm low}<B_{\rm up}<B_{\rm max}$. $B_{\rm up}$ corresponds to the desired energy buffer level and $B_{\rm low}$ is the lowest EB level that the MEC server should ever reach. The suitable energy source at each time slot $t$ is selected based on the forecast expectations, i.e., the expected harvested energy $\hat{H}(t)$. If $\hat{H}(t)$ is enough to reach $B_{\rm up}$, no energy purchase is needed. Otherwise, the remaining amount up to $B_{\rm up}$, i.e., $E(t)=B_{\rm up}-B(t)$ is bought from the electrical grid. Our optimization framework in Section III-A makes sure that $B(t)$ never falls below $B_{\rm low}$ and guarantees that $B_{\rm up}$ is reached at every time slot.

III Problem Formulation

In this section, we formulate an optimization problem to obtain reduced energy consumption through short-term server workload and harvested solar energy forecasting along with server management procedures. The optimization problem is defined in Section III-A, and the online server management procedures are presented in Section III-B.

III-A Optimization Problem

On per time slot basis, the online controller adaptively schedules the communication and computing resources, at the same time receiving the energy level report from the EM. The goal is to minimize the overall resulting communication-plus-computing energy, i.e., the energy consumption related to the MEC server’s VMs and transmission drivers. To achieve this, for $t=1,\dots,T$, where $T$ is the optimization horizon, we define the optimization problem as:

[TABLE]

where $\mathcal{E}\stackrel{{\scriptstyle\Delta}}{{=}}\{M(t),\{\alpha_{m}(t)\},\{P_{m}(t)\},\{\lambda_{m}(t)\},\zeta(t),Y(t)\}$ is the set of objective variables to be configured at slot $t$ in the MEC server, for the computing-plus-communication processes. Regarding the constraints, C1 forces the required number of VMs, $M(t)$, to be always greater than or equal to a minimum number $d\geq 1$: the target of this is to be always able to handle mission critical communications. C2 makes sure that the EB level is always above or equal to a preset threshold $B_{\rm low}$, to guarantee energy self-sustainability over time. C3 and C4, bound the maximum processing rate and workloads of each running VM $m$. Constraint C5 represents a hard-limit on the corresponding per-slot and per-VM processing time. Furthermore, C6 bounds the aggregate communication rate sustainable by the VLAN to $r_{\rm max}$ and C7 forces the server to process the offloaded tasks within the set value $\tau_{\rm max}$.

From P1, we note that $\theta_{\rm MEC}(t)$ consists of a non-convex component, i.e., Eq. (5), while the others are convex and non-decreasing. Then, Eq. (5) can be convexified into a convex function using GP theory [19], by introducing alternative variables and approximations. In this, we introduce fixed parameters (i.e., $\mu_{m},\nu_{m}$) and approximations. Dropping the index $t$ for convenience, we let $r_{m}=2\,\lambda_{m}/(\tau_{\rm max}-\Delta)$. We obtain $P_{m}(r_{m})$ in terms of $\lambda_{m}$, by rearranging the Shannon-Hartley expression and substituting the value of $r_{m}$, as: $\hat{P}_{m}(r_{m})=\frac{((2\,\lambda_{m}/(\tau_{\rm max}-\Delta))-\nu_{m}\,W_{m})\ln 2}{\mu_{m}W_{m}}+\ln(N_{0}^{(m)})-\ln g_{m}$. From the Shannon-Hartley expression, we simply observed the presence of the log-sum-exp function as it has been proven to be convex in [29] and recall that $P_{m}(r_{m})=\exp(\hat{P}_{m}(r_{m}))$.

To solve P1, we leverage the use of LLC [21], GP [19], and heuristics, obtaining the feasible system control inputs $\psi(t)=(M(t),\{\alpha_{m}(t)\},\{P_{m}(t)\},\{\lambda_{m}(t)\},\zeta(t),Y(t))$, that yield the best system behavior within $T$.

III-B Resource Controller Design and Server Management

In this subsection, a server workload and energy harvesting forecasting method, and an online resource management algorithm are proposed to solve the previously stated problem P1. In subsection III-B1, we discuss the LSTM neural network used to predict the short-term future server workloads and harvested energy, then in subsection III-B2, we solve P1 by using LLC principles, GP theory, and heuristics, and lastly, in subsection III-B3 we put forward the ARCES algorithm.

III-B1 Server workload and energy prediction

in order to estimate the system workload over the prediction horizon $T$, we perform time series prediction, i.e., we obtain $T=3$ estimates of $\hat{\rm L}(t+1)$ and $\hat{H}(t+1)$, by using an LSTM network developed in Python using TensorFlow deep learning libraries (Keras, Sequential, Dense, LSTM), with a hidden layer of $4$ LSTM neurons, and an output layer that makes a single value prediction. The dataset is split as $67\%$ for training and $33\%$ for testing. As for the performance measure of the model, we use the Root Mean Square Error (RMSE). In this work, prediction steps similar to [7] are adopted (see Table I in this reference), and Fig. 3 shows the prediction results that will be discussed in Section IV-B.

III-B2 Edge system dynamics

we denote the system state vector at time $t$ by $\textupsilon(t)=(M(t),Y(t),B(t))$, which contains the number of active VMs, $M(t)$, transmission drivers, $Y(t)$, and the EB level, $B(t)$. The input vector $\psi(t)=(M(t),\{\alpha_{m}(t)\},\{P_{m}(t)\},\{\lambda_{m}(t)\},\zeta(t),Y(t))$ drives the MEC server behavior (handles the joint VM soft-scaling and the tuning of transmission drivers) at time $t$. Note that $\{P_{m}^{*}(t)\}$ is obtained with CVXOPT, and $\{\lambda_{m}^{*}(t)\}$ is obtained by following remark $1$.

The system behavior is described by the discrete-time state-space equation, adopting the LLC principles [21][30]:

[TABLE]

where $\phi(\cdot)$ is a behavioral model that captures the relationship between $(\textupsilon(t),\psi(t))$, and the next state $\textupsilon(t+1)$. Note that this relationship accounts for the amount of energy drained $\theta_{\rm MEC}(t)$, that harvested $H(t)$ and that purchased from the electrical grid $E(t)$, which together lead to the next buffer level $B(t+1)$ through Eq. (7). The online resource management algorithm, ARCES, finds the best control action vector that yields the desired energy savings within the computing environment. Specifically, for each time slot $t$, problem (III-A) is solved, obtaining control actions for the prediction horizon $T$. The control action that is applied at time $t$ is $\psi^{*}(t)$, which is the first one in the retrieved control sequence. This control amounts to setting the number of instantiated VMs, $M^{*}(t)$ (along with their obtained $\{\alpha_{m}^{*}(t)\}$, $\{P_{m}^{*}(t)\}$, $\{\lambda_{m}^{*}(t)\}$ values), NIC status to either active or not, $\zeta^{*}(t)\in(0,1)$, and the optimal transmission drivers, $Y^{*}(t)$. The entire process is repeated every time slot $t$ when the controller can adjust the behavior given the new state information.

Since the actual values for the system input cannot be measured until the next time instant when the controller adjusts the system behavior, the corresponding system state for $t+1$ can only be estimated as:

[TABLE]

For these estimations we use the forecast values of load $\hat{L}_{\rm in}(t)$ and harvested energy $\hat{H}(t)$, from the LSTM forecasting module.

Remark 1 (VM provisioning and load distribution)

a remark on the provisioned VMs at slot $t$, $M(t)$, is in order. The number of active VMs depends on the forecasted server workload, $\hat{L}_{\rm in}(t+1)$, and each VM can compute an amount of up to $\lambda_{\max}$ (considering that virtualization technologies specify the minimum and maximum amount of resources that can be allocated per VM [31]). Then, the projected number of VMs that shall be active in slot $t$ to serve the forecasted server workloads is hereby obtained as: M(t)=\big{\lceil}(\hat{L}_{\rm in}(t+1)/\lambda_{\max})\big{\rceil}, where \big{\lceil}\cdot\big{\rceil} returns the nearest upper integer. We heuristically split the workload among VMs by allocating a workload $\lambda_{m}(t)=\lambda_{\max}$ to the first $M(t)-1$ VMs, $m=1,\dots,M(t)-1$, and the remaining workload $\lambda_{m}(t)=\hat{L}_{\rm in}(t+1)-(M(t)-1)\lambda_{\max}$ to the last one. This load distribution is motivated by the shares feature [31] that is inherent in virtualization technologies. This enables the resource scheduler to efficiently distribute resources amongst contending VMs, thus guaranteeing the completion of the computation process within the expected time.

III-B3 The ARCES algorithm

in order to obtain the best control action that will adjust the computing system behavior at time $t$, with negligible computational overhead, the controller explores the prediction horizon of comprising discrete states and comes up with the feasibility action set that yields the minimum energy cost, i.e., $\psi(t)=(M(t),\{\alpha_{m}(t)\},\{P_{m}(t)\},\{\lambda_{m}(t)\},\zeta(t),Y(t))$.

The algorithm pseudocode is outlined in Algorithm 1 and it follows the technique from [21]. Starting from the initial state, the controller constructs, in a breadth-first fashion, a tree comprising all possible future states up to the prediction depth $T$. The algorithm proceeds as follows: A search set $\mathcal{S}$ consisting of the current system state is initialized (line 01), and it is accumulated as the algorithm traverse through the tree (line 03), accounting for predictions, accumulated workloads at the output buffer, past outputs and controls. The set of states reached at every prediction depth $t+n$ is referred to as $\mathcal{S}(t+n)$ (line 02). Given $\textupsilon(t)$, we first estimate the workload $\hat{L}_{\rm in}(t+n)$ and harvested energy $\hat{H}(t+n)$ (line 02), and generate the next set of reachable control actions by applying the input workload and energy harvested (line 03). The energy cost function corresponding to each generated state $\hat{\textupsilon}(t+n)$ is then computed (line 04). Once the prediction horizon is explored, a sequence of reachable states yielding minimum energy consumption is obtained (line 05). The control action $\psi^{*}(t)$ corresponding to $\hat{\textupsilon}(t+n)$ (the first state in this sequence) is provided as input to the system while the rest are discarded (line 06). The process is repeated at the beginning of each time slot $t$.

IV Performance Evaluation

This section present some selected numerical results of the ARCES algorithm for real server workloads. The parameters that were used for the simulations are listed in Table I.

IV-A Simulation Setup

As one of the MEC deployment scenarios, we assume that the MEC server is placed at an aggregation point where BSs in proximity can offload their computation workload following the random real-valued arrival process. Our time slot duration $\tau$ is set to $1\text{\,}\mathrm{min}$ and the time horizon is set to $T=3$ time slots. The simulations are carried out by exploiting the Python programming language.

IV-B Numerical Results

In Fig. 3, we show real and predicted values for the server workloads (Server) and harvested energy (Solar) over time. We track the one-step predictive mean value at each step of the online forecasting routine. The obtained average prediction error (RMSE) for the server workloads and harvested energy processes, both normalized in [0,1] for $T\in\{1,2,3\}$, are $L_{\rm in}(t)=\{0.017,0.019,0.021\}$ and $H(t)=\{0.038,0.039,0.039\}$. Note that the predictions for $L_{\rm in}(t)$ are more accurate than those of $H(t)$ (confirmed by comparing the average RMSE), due to differences in the used dataset granularity. However, the measured accuracy is deemed good enough for the proposed optimization.

Our online server management algorithm (ARCES) is benchmarked with another one, named Iterative-based Resource Scheduler (IRS), which is inspired by the iterative approach from [8]. In IRS, the optimum computing-plus-communication parameters are obtained in an iterative manner: at the end of each cycle, convergence conditions are used to determine if the found solution is acceptable or the optimization process should continue. The observed conditions are as follows: (i) to ensure that the total load $L_{\rm in}(t)$ has been fully allocated with accuracy $\frac{\sum_{m=1}^{M(t)}\lambda_{m}(t)-L_{\rm in}(t)}{L_{\rm in}(t)}\leq\epsilon$, with $\epsilon=0.01$; (ii) to verify if the selected working frequency $f_{m}(t)$ is able to cope with the input load $L_{\rm in}(t)$, guaranteeing that the computation processing time is within the server’s response time limit $\Delta$, i.e., $L_{\rm in}(t)\leq f_{m}(t)\Delta$ . The average energy savings obtained by ARCES are shown in Fig. 4. The average results for ARCES ($\kappa_{e}=0.005,\Gamma_{m}=$0.5\text{,}\mathrm{mW}$,\eta=1.4$ Gbit/$\text{\,}\mathrm{J}$) show energy savings of $69$%, while IRS achieves $56$% on average, in both cases with respect to the case where no energy management procedures are applied; i.e., the MEC server provisions the computing resources for maximum expected computation workload (maximum value of $\theta_{\rm MEC}(t)$, with $M=10$, $\forall t$). As expected, the highest energy savings peak is observed at $9\text{\,}\mathrm{h}$ as the aggregate computation requests/workload was at its lowest with an expected increase in the computation workload and harvested solar energy in the near future. The effectiveness of the joint VM soft-scaling and tuning of transmission drivers, coupled with foresighted optimization is observed in the obtained numerical results.

In Fig. 5, we show the effects of the per-VM reconfiguration cost on $\theta_{\rm MEC}(t)$ at $\kappa_{e}=\{0.001,0.005\}$ ($\Gamma_{m}=$0.5\text{,}\mathrm{mW}$,\eta=1.4$ Gbit/$\text{\,}\mathrm{J}$), taking into account the performance of ARCES when compared with IRS for $M(t)=1,\dots,M$. It can be observed that $\theta_{\rm MEC}(t)$ increases with large $\kappa_{e}$ only for small values of $M(t)$, and as $M(t)$ increases the energy consumption decreases for large $\kappa_{e}$. Moreover, ARCES leads to an energy consumption reduction with respect IRS from $25$% to $7$% (case of $\kappa_{e}=0.005$) and from $7$% to $5$% (case of $\kappa_{e}=0.001$). When ARCES is compared with the case where no energy management is applied (maximum value of $\theta_{\rm MEC}(t)$, with $M=10$, $\forall t$), the obtained energy reduction ranges from $45$% to $31$% (case of $\kappa_{e}=0.005$) and from $25$% to $21$% (case of $\kappa_{e}=0.001$). These numerical results confirm that jointly autoscaling the available computing-plus-communication resources within the computing platform provides remarkable energy savings. These results conforms to our expectations from [16].

V Conclusions

In this paper, we have envisioned a hybrid-powered MEC server placed in proximity to a BS cluster for handling the offloaded computation workload. Moreover, the use of green energy promotes energy self-sustainability within the network. We have considered a computing-plus-communication energy model, within the MEC paradigm, and then have put forward a combination of a traffic engineering- and MEC Location Service-based online server management algorithm with EH capabilities, called Automated Resource Controller for Energy-aware Server (ARCES), for autoscaling and reconfiguring the computing-plus-communication resources. The main goal is to minimize the overall energy consumption, under hard per-task delay constraints (i.e., QoS). ARCES jointly performs (i) a short-term server demand and harvested solar energy forecasting, (ii) VM soft-scaling, workload and processing rate allocation and lastly, (iii) switching on/off of transmission drivers (i.e., fast tunable lasers) coupled with the location-aware traffic scheduling. Numerical results, obtained with real-world energy and server workload traces, demonstrate that the proposed algorithm (ARCES) achieves energy savings of $69$%, on average, with an energy consumption ranging from $31$%-$45$% at high per-VM reconfiguration cost and from $21$%-$25$% at low per-VM reconfiguration cost, with respect to the case where no energy management techniques are applied.

Acknowledgements

This work has received funding from the European Union’s Horizon 2020 research and innovation programme under the Marie Sklodowska-Curie grant agreement No. 675891 (SCAVENGE).