A Pre-Allocation Design for Cost Minimization and Delay Constraint in Vehicular Offloading System

Typically, a mobile edge computing system involves several vehicles and road side units. We denote $\mathcal{M}=\{1,2,...,M\}$ as the set of vehicles, where $M$ is the number of vehicles. These vehicle users are the producer of the whole system, which means they will stochastically generate certain amount of tasks at the beginning of each time slot. Here the stochasticity is two-fold, i.e., the occurrence of computation task and its numeric amount are both randomly distributed. In the light of the bursting nature of task arrival, vehicles either produce tasks, the quantity of which has a lower bound, or do not produce any new task at all. We thus use an i.i.d Bernoulli distribution across vehicles to model this burst arrival. We define $\rho$ as the parameter of the distribution, a.k.a the arrival rate. If $\xi_{i}^{t}$ is denoted to indicate the occurrence of a newly-arrived task on slot $t$ in vehicle $i$, then $p(\xi_{i}^{t}=1)=1-p(\xi_{i}^{t}=0)=\rho$. The numeric quantity of a computation task, denoted as $R_{task}$ is uniformly distributed on the closed interval $[R_{min},R_{max}]$. So in any time interval, the actual amount of newly generated tasks $R_{i}(t)$ can be defined as below,

Other than the quantity, a computation task is attributed by other factors. The most important one is the maximal tolerant delay. To guarantee the user Quality of Service (QoS), applications with high requirement in timeliness need a response within certain time after generation. We denote $\tau_{i}^{t}$ as the time limit of vehicle $i$’s task in slot $t$.

The execution of computation task is based on physical hardware (such as GPU, memory and HDD). In actual settings, different tasks also vary in the requirement of hardware. For instance, we call an application that has high requirement in GPU configuration as a GPU-intensive task. Vehicle-based virtual reality is one of the representative applications of this kind. So in the characterization of a computation task, we need to identify the request of resources respectively so that the edge servers can organize the VMs. Without loss of generality, we denote $k$ as the number of total types of resources, and then $\mathcal{r}=\{r_{1},r_{2},...,r_{k}\}$ is the set of configuration on hardware, where $r_{i},1\leq i\leq k$ is the configuration on type-$i$ resource. Thereafter, we use a tuple $A_{i}^{t}=(R_{i}(t),\tau_{i}^{t},\mathcal{r})$ to characterize a computation task based on the discussion above.

We assume that each computation task can be chopped into independent parts at any ratio, for local execution and offloading. This partition can be implemented by Spark [13]. We denote $\alpha_{i}^{t}\in[0,1]$ as the percentage of locally computed task, and $\beta_{i}^{t}\in[0,1]$ as the offloading percentage. For vehicle $i$, it will decide $\alpha_{i}^{t}$ and $\beta_{i}^{t}$ for each task considering delay cost and the accessibility to the server.

The delay cost is comprised of two components, the queueing delay and service time a.k.a the execution time. As discussed above, vehicles can either execute the task locally, or offload it to the remote server. For the local part, the frequency scheduled for the task $A_{i}^{t}$ is denoted as $f_{i,t}^{local}$, which can be implemented by adjusting the chip voltage with DVFS techniques[7]. The execution time can be expressed as

Compared with the server, vehicle users have limited local resources. So chances are that tasks are not instantly executed just on its arrival, but will have to be waiting in a backlog queue with FIFO discipline. This will generate the queueing delay. To quantify the queueing delay, we propose a novel delay time indicating method.

First, to facilitate the downstream method, we make a modification for the maximum tolerant delay $\tau_{i}^{t}$, which is a continuous variable. Here binning method is used to discretize $\tau_{i}^{t}$. $\mathbf{\Gamma}=\{\Gamma_{1},\Gamma_{2},...\Gamma_{s}\}$ is denoted as the set of typical delay constraints, where $\Gamma_{1}\leq\Gamma_{2}\leq...\leq\Gamma_{s}$ and $s$ is the number of delay constraints. As the task with lower delay requirement is more sensitive to the delay (e.g. the task with time limit of 10s is more sensitive to any 1s increase compared to that of time limit of 1 minute), typically we set the $\mathbf{\Gamma}$ to be a geometric sequence. We assign a delay index $h_{i}^{t}$ for each of the task according to its $\tau_{i}^{t}$ as below.

$h_{i}^{t}$ can also be deemed as the priority index of a task. The lower $h_{i}^{t}$ is, the quicker response for the result should be. After discretization of $\tau_{i}^{t}$ into $s$ delay constraints, we can formulate a delay time sequence denoted by $Q_{s,i}^{t}$ for each $\Gamma_{s}$, where its update equation is

where $\zeta$ is the time interval of each slot, $\mathbbm{1}_{\{h_{i}^{t}=s\}}$ is an indicator function that maps to 1 if $h_{i}^{t}=s$, and 0 otherwise. We also assume the CPU-cycle frequency is constrained by $f_{s}^{max}$.The queueing delay for tasks at time slot $t$ is the delay before it is generated, namely $Q_{s,i}^{t}$. Notice that the allocation and execution are separate in our settings. In other words, $\alpha_{i}^{t}$ and $f_{s}^{local}$ are designated to a task when it arrives, while the true execution may begin when the task is at the head of the queue. That’s why the framework is called pre-allocation here.

Another part of the task is offloaded to the MEC server. This process can be viewed as a renting behavior for the virtual machines from server. Typically, the server organizes and provides its service in the form of virtual machine, which contains quantified computation resources. These VMs work independently, and serve as a Plug and Play application. It means when the task is scheduled to the server with resources not exceeding its limit quantum, the task can be executed immediately without any queueing or waiting. Hence the delay of offloaded tasks can be expressed as

Therefore, the total delay $D_{i}^{t}$ can be expressed as

One of the advantages of using MEC server for offloading is that the delay can be reduced. We assume that the computation resource on server can easily satisfy the deadline requirement of any task, say, $\tau_{d}$, i.e.

Since $D_{i,t}^{server}<\frac{R_{i}^{t}}{f_{i,t}^{server}}$, we can also get $D_{i,t}^{server}<\tau_{d}$. According to Eq. 6, if we want to guarantee the total delay bound, the following inequality must be satisfied:

Apart from the delay, vehicles also pay attention to the energy cost for the task executed locally. The energy consumption model is describe below. For task $A_{i}^{t}$, $\alpha_{i}^{t}$ of the total amount is locally executed at CPU frequency $f_{i,t}^{local}$, so the energy cost throughout its execution can be expressed as

where $\kappa$ is the effective switched capacitance that depends on the chip architecture [1].

In this paper, the MEC server is equipped with a renewable energy generator, which consistently provides energy supply for the offloading system[12]. We denote the production rate as $U^{t}\in[0,U_{max}]$. The server benefits from the generation of renewable energy by reducing the amount of buying energy from the central electric grid. Compared to that from the latter one, the cost of renewable energy is negligent in this scenario, exempt from the investment of raw materials as well as the depravity of long-distance transmission. To make the best of the harvested energy, the server is also equipped with a battery as a buffer to store the energy. We denote the charging level of the battery in slot $t$ as $B^{t}$.

For the MEC server, it supplies energy for the tasks offloaded from vehicle users. For task $A_{i}^{t}$, we have a total amount of $(1-\alpha_{i}^{t})R_{i}^{t}$ with allocated CPU frequency $f_{i,t}^{server}$. So to empower the rent virtual machine, energy consumption for task $A_{i}^{t}$ can be expressed as

To avoid charging deficiency, the generated renewable energy is firstly supplied to execute the offloaded tasks. If there is redundant energy, then the surplus will be charged into the battery. Let $C^{t}$ be the current charging rate to the battery and thus $C^{t}\in[0,\min\{C^{max},(U^{t}-\sum_{i=1}^{M}N_{i}^{t})^{+}\}]$, where $(x)^{+}\triangleq\max\{0,x\}$. Otherwise, when the instant energy consumption exceeds the amount of renewable energy generation, the energy supply gap will be filled by either the battery or by the power grid. We denote the amount from latter resource as $G^{t}$. And so $(\sum_{i=1}^{M}N_{i}^{t}-U^{t})^{+}-G^{t}$ is the discharged amount of energy from battery under this condition.

With the notations stated above, we can derive the battery dynamics on the basis of charging and discharging strategy,

where $0<\eta^{+}\leq 1$ and $\eta^{-}\geq 1$ represent the charging and discharging efficiency respectively. And $\eta^{-}((\sum_{i=1}^{M}N_{i}^{t}-U^{t})^{+}-G^{t})$ denotes the amount of energy extracted from the battery, so it must satisfies:

which means the extracted energy must not exceed the current battery storage.

The backlog of tasks in vehicular users and the energy storage makes the offloading decisions for users and energy supply policy for servers to be more complicated, compared to the conventional mobile edge computing systems. These two kinds of backlog entail temporally correlated workload and energy level and makes the system decisions coupled in different time slots. In other words, the decisions are not myopic any more but to make a tradeoff between the long term and current profit.

The vehicular users are motivated to minimize the time-average expected cost for executing the tasks with guaranteed delay. This problem can be formulated as below,

where $\sum_{s=1}^{S}E_{i}^{t}$ denotes the overall energy consumption for local execution. And $\frac{\beta_{i}^{t}R_{i}^{t}}{f_{i,t}^{server}}g(f_{i,t}^{server})$ denotes the payment for VMs from MEC server. As a general business model, the service provided by server is charged by time. $g(f_{i,t}^{server})$ denotes the server’s unit price for providing CPU frequency $f_{i,t}^{server}$. The expectation above is with respect to the potential randomness of the control policy. $\Upsilon$ is the drop loss of a task. If the task is neither executed locally nor offloaded, it can be deemed as dropped (or deployed to cloud), the price of which is $\Upsilon$.

One challenge in solving $\mathbf{P1}$ is due to constraint $C1$, which brings time correlation to the problem. We leverage tools from Lyapunov optimization framework. First, we are going to modify $C1$, and transform the off-line problem $\mathbf{P1}$ to an online optimization problem. To guarantee the delay of task execution, we construct a virtual queue $W_{i}^{t}$, which can be expressed as follow:

We can define the Lyapunov function as $L_{i}(t)=\frac{1}{2}\sum_{i=1}^{S}(W_{s,i}^{t})^{2}$. Then, the conditional Lyapunov drift-plus-penalty for slot $t$ is given by:

where $V$ is a user-determined hyperparameter. While we assume that in any time slot, at most one task is newly generated, whose delay priority is denoted as $\hat{s}$. Then the drift-plus-penalty can be slacked with an upper bound,

where $B$ is a constant with regard to the function with variables $f_{s}^{local}$, $\alpha_{i}^{t}$ and $\beta_{i}^{t}$.

At every time slot, the vehicle will make decisions of the local allocated CPU frequency and the proportion to be offloaded for controlling the upper bound of cost. To this end, the Lyapunov framework minimizes the right hand side of the drift-plus-penalty expression. The optimization problem for vehicle $i$ can thus be formulated as

As for MEC server, it provides high-quality and ultra-low latency service for vehicles. Its objective is to make a profit for providing such service. However, it also pays close attention to the remnant in battery. For a sustainable business mode, the battery should be in a healthy and stable across time. The revenue maximization problem can be defined as below

where $\chi^{t}$ is the unit price of purchasing electricity from power grid. So $\chi^{t}G^{t}$ is the overall payment for extra power when the renewable energy supply is insufficient.

Nevertheless, due to the energy causality constraint (12), the decision making process of $G^{t}$ is coupled among different time slots. To facilitate further analysis, we first introduce an upper bound $E_{max}$ for the discharged energy, and the problem can be rewritten as the following

As will be elaborated later, the proposed solution to $\mathbf{P4}$ also satisfies constraint (12). Next we define the perturbation parameter $\theta$ and virtual energy queue $\widetilde{B}^{t}$ respectively,

where $H>0$ is a positive control parameter. With regard to the stability of battery queue, we adopt a similar Lyapunov framework on MEC server. The Lyapunov drift-plus-penalty is defined as

To minimize the RHS of the above inequality, the MEC server make decisions of $G^{t}$ and $f_{i,t}^{server}$. So the revenue maximization of MEC server can now be expressed as

Thus, in this vehicular edge computing scenario, we aim at devising a bidirectional pricing and energy management scheme for both vehicle users and MEC server. Meanwhile, we expect to guarantee the long term profit of all the agents in the system. To this end, a Stackelberg Game based algorithm is proposed for the agents’ own profit maximization respectively.