I Introduction
Vehicles are becoming connected and intelligent. The development of communications protocols such as IEEE 802.11p and LTEV enable vehicletoeverything (V2X) communications [80211p, 3gpp36300, tdlte]. To realize autonomous driving and various onboard infotainment applications, vehicles will be equipped with powerful computation resources, e.g., to handle dhrystone million instructions per second [intel], as well as a variety of sensors such as cameras and radars. These moving communication, computation and sensing resources can be further exploited to enhance conventional multiaccess edge computing (MEC) systems [mao2017mobile, mach2017mobile, yu2018survey], where computation and storage resources are deployed in static infrastructures such as base stations (BSs) at the edge of wireless networks.
Consequently, the concept of vehicular edge computing (VEC) (also known as vehicular fog or cloud computing) has been proposed [abdel2015vehicle, bitam2015vanet, hou2016vfc, choo2017sdvc, qian2018collaborative, Sun2019CMag, Abdreev2019dense, cheng20175G], where road side units (RSUs) and vehicles with surplus computation resources are employed as computing nodes just like the role of edge servers in the MEC system. The computation resources are abstracted via network function virtualization and software defined networking techniques to support various applications. Task requesters, including onboard driving systems and mobile devices of passengers and pedestrians, can get computing services from service providers, including vehicles and RSUs, by means of task offloading. In this context, vehicles acting as service providers are called service vehicles (SeVs), while vehicles whose driving systems or passengers requesting computation task offloading are called task vehicles (TaVs). Typical use cases in the VEC system include autonomous driving applications such as collective environment perception and cooperative collision avoidance [5gv2x], and vehicular crowdsensing for road monitoring and parking navigation [vehcrowd]. Applications in conventional MEC systems are also supported by the VEC system for passengers and pedestrians, including augmented reality, cloud gaming, and etc.
In the VEC system, the offloading delay, including data transmission and computation, is the key performance metric, and it is vital to schedule tasks and allocate computation resources for realtime computing services. Tasks can be offloaded from TaVs to SeVs directly in a distributed manner, or collected by the RSUs and then assigned to the SeVs in a centralized manner [Sun2019CMag]. In the literature, centralized resource allocation schemes are proposed in [choo2017sdvc, zheng2015smdp, Jiang2017IoT]
, wherein the communication and computation resources are optimized globally based on Markov decision process (MDP) with the coordination of RSUs. However, the complexity is usually very high due to a large state space involving many vehicles and tasks. The global states, including locations, velocities, moving directions of vehicles, wireless channel states and available computation resources, should also be collected by RSUs frequently, leading to high signaling overhead. An alternative way is to make offloading decisions in a distributed manner by task requesters
[fengave, zhou2019reliable, Sun2018ICC, Sun2019TVT]. In this context, it is still difficult for the TaV to acquire the global state information of SeVs and the offloading behaviors of other TaVs in the neighborhood. Contract theory is adopted in [zhou2019reliable], while online learning algorithm based on multiarmed bandit (MAB) theory is proposed in [Sun2018ICC, Sun2019TVT], to overcome the challenges.In fact, challenges and opportunities coexist in the VEC system. On the one hand, task offloading in the VEC system faces a more volatile environment, where the network topology and wireless channels vary rapidly due to vehicle movements. On the other hand, moving vehicles acting as VEC servers can provide more computation offloading opportunities, while at the same time relieving the impact from the voltile environment.
To further exploit the computation resources in the VEC system, we introduce task replication. Specifically, each task is replicated to multiple candidate SeVs at the same time and executed by them independently. Upon the first result transmitted back from one of the selected SeVs, the task is completed. Task replication technique is adopted in largescale cloud computing servers to reduce delay and mitigate the straggler effect, and the impact of redundancy level (i.e., the number of task replicas) on the delay performance is analyzed based on queueing theory [gardner2015reducing, gardner2017redundancy, joshi2017efficient]. However, the transmission delay and the dynamic network topology are not considered in these works. Introducing task replication to the VEC system, a centralized algorithm that maximizes the task completion ratio is proposed in [Jiang2017IoT] based on MDP, while a contextual MAB based learning algorithm is proposed in [chen2019task], enabling the RSU to treat the service delay as a grey box. However, no theoretical results have been revealed on how to select the number of task replicas under different network conditions, including density of vehicles, task arrival rates and service capabilities, to optimize the quality of service such as delay and reliability. Moreover, these algorithms require the RSUs to collect and assign tasks in a centralized manner.
In this paper, we study the task replication problem in the VEC system, with the objective of delay minimization. The optimal number of task replicas is derived, and a distributed learningbased task replication algorithm is proposed. The main contributions are summarized as follows:

We propose a distributed task replication framework, which enables any TaV to offload task replicas to multiple candidate SeVs in a distributed manner, so as to minimize the average offloading delay under the task failure constraint.

Performance analysis is carried out to characterize how the number of task replicas affects the offloading delay, given the network conditions such as density of vehicles, average task arrival rate and computing power. The optimal number of task replicas is approximated in closedform, and is validated through simulations.

Exploiting combinatorial MAB (CMAB) theory, an online learningbased task replication algorithm (LTRA) is proposed, which can adapt to the dynamics of the VEC system, with provable bounded learning regret.

A realistic traffic scenario is generated via traffic simulator Simulation for Urban MObility (SUMO) to evaluate the proposed task replication algorithm. Results show the delay reduction brought by the joint effort of task replication and online learning. Specifically, under our settings, using LTRA with the optimal number of task replicas can reduce the average offloading delay by over , compared to the benchmark without task replication. Meanwhile, the task completion ratio can be improved from to over .
The rest of this paper is organized as follows. In Section II
, we introduce the system model and problem formulation. The impacts of the number of task replicas on the delay performance and task failure probability are analyzed in Section
LABEL:sys_ana, and the task replication algorithm is then proposed in Section LABEL:algo. Numerical and simulation results are shown in Section LABEL:sim, and the paper is finally concluded in Section LABEL:con.Throughout the paper, we use to represent the expectation operation, and to represent the probability of an event. Define as an indicator function, where if condition is true, and otherwise. The cardinality of a set is denoted by . Let denote the number of combinations of choosing items out of at a time. maps the least integer equal to or greater than , and maps to its nearest integer.
Ii System Model and Problem Formulation
Iia System Overview
As shown in Fig. 1, we consider computation task offloading among moving vehicles in a VEC system. TaVs generate computation tasks and offload them to the neighboring SeVs, with surplus computation resources, for remote execution. Note that the role of each vehicle, i.e., being either a TaV or an SeV, can change across time, which mainly depends on whether it has free computation resources to share.
For each TaV, the SeVs moving in the same direction within its singlehop communication range are considered as candidates. Multiple candidate SeVs may be able to process each task, and we introduce task replication technique to counter the dynamics in the vehicular networks. In particular, each task is replicated and offloaded to multiple candidate SeVs and processed by them independently. Once the first response is received from one of the selected SeVs, the task is completed. However, we assume that other slower SeVs do not cancel the replicas of this task upon its completion, due to two main reasons. On the one hand, cancellations require TaVs to exchange additional information with SeVs, and cancelling tasks at SeVs introduces additional delay [gardner2017better]
, which further complicate the task replication problem. On the other hand, the proposed reinforcement learning algorithm needs to observe the delay performance of all the selected SeVs, which will be introduced in Section
LABEL:algo.Distributed task offloading is considered in this work. That is, each TaV selects a subset of candidate SeVs to serve each task on its own, without any coordinations with other vehicles. Without loss of generality, we will focus on a typical TaV and design the task replication algorithm in the following.
IiB SeV Candidates and Task Arrival
In the considered time period, the TaV has a total number of tasks to be offloaded. For the th task, the candidate SeV set is denoted by , which may vary across time due to vehicle movements. These candidate SeVs may also serve the tasks from other TaVs simultaneously. We assume that the TaV can always associate to at least one SeV during the considered period, i.e., for . Otherwise, the TaV may offload tasks to RSUs, which is beyond the scope of this paper. A subset of SeVs, denoted by , are selected to process the replicas of the th task. We assume that the number of task replicas is fixed as , where should be carefully designed based on the network conditions, such as the densities of TaVs and SeVs, task arrival rates at TaVs, service capabilities of SeVs, etc. If , we have and . If , let .
The arrival of tasks at the TaV is modeled by a Poisson process with rate (in tasks per second). The input data size to be uploaded from TaV to SeV, and the output data size transmitted back from SeV to TaV, are assumed to be identical across time, and denoted by and (in bits) respectively. This is a reasonable assumption since tasks generated from the same kind of applications have similar input and output data size. Moreover, tasks with different input data volumes can be further partitioned into subtasks and offloaded sequentially. For example, video segmentation technique can be adopted to partition long video frames into short video clips for classification or detection purposes [cvpr2010].
IiC Task Replication Procedure
In the VEC system, there are three procedures for task replication, i.e., task upload, task execution and result feedback. Details of the three procedures and the corresponding delay models are described in the following.
IiC1 Task Upload
We consider that the replicas of each task are multicast to all the selected SeVs without retransmission using IEEE 802.11p protocol [80211p], so that replication does not bring additional communication burdens to the VEC system. For the th task, the uplink wireless channel state between the TaV and SeV is denoted by , and the interference power is denoted by . Given the uplink channel bandwidth , transmission power and noise power , the achievable uplink transmission rate between TaV and SeV , denoted by , is given by
(1) 
We assume that the transmission link between TaV and SeV is a packet erasure channel with erasure probability . That is, the input data of the th task is either successfully received by SeV with probability , or failed with probability , due to the randomness of channels such as blockage or deep fast fading. We also assume that the erasure behavior of each SeV is independent from other SeVs.
Note that all the selected SeVs should be able to receive the task via multicast. Therefore, given the selected SeV set , the achievable uplink transmission rate is given by
(2) 
Then the uploading delay, denoted by , can be written as
(3) 
IiC2 Task Execution
For the th task, the SeVs that can successfully receive its input data is denoted by , with . A task failure occurs when all the selected SeVs fail to receive the input data packets, with probability
(4) 
Each candidate SeV can serve multiple TaVs within its service range , the the offloading behavior of these TaVs are independent from others. Based on the fact that the superposition of independent arrivals resembles a Poisson process [Sriram1983characterizing, Ko2018wireless], the task arrival at each candidate SeV is approximated by a Poisson process with rate (in tasks per second). Parameter reflects the workload of each SeV , which is related to the number of TaVs within its communication range, as well as the task arrival rate and the number of replicas of each TaV.
Task execution at each SeV is modeled by an M/M/1 queueing system according to the firstcome firstserved discipline, where the service rate of SeV is denoted by
(in tasks per second), and the task processing delay (service time) follows exponential distribution with mean
. Define the total task execution delay (sojourn time) of the th task as , which includes queueing delay and processing delay. According to queueing theory [queueing_theo], task execution delay follows exponential distribution with mean .IiC3 Result Feedback
Upon completion, each selected SeV unicasts the computation results back to the TaV using a spectrum orthogonal to that for task uploading. We assume that the results can always be delivered back to the TaV successfully, with retransmissions if necessary. Define the result feedback delay as , including queueing delay and transmission delay, which may be affected by many factors such as downlink channel state, interference power, link reliability and retransmission times. The expression of is not specified in our work, since the proposed task replication algorithm in Section LABEL:algo can learn it.
Comments
There are no comments yet.