无人机辅助任务卸载

本文为两篇无人机辅助任务卸载论文的笔记，一篇为《UAV-Assisted Task Offloading in Vehicular Edge Computing Networks》（以下称paper1），一篇为《Delay-Aware Cooperative Task Offloading for Multi-UAV Enabled Edge-Cloud Computing》（以下称paper 2），两篇论文中无人机均承担了边缘服务器的职责，能够对来自其他设备的卸载任务进行计算，在能耗约束的前提下，最小化系统时延。

Background

paper1聚焦车载边缘计算（Vehicular edge computing, VEC)，对于交通流量繁忙的道路，车辆需要根据路况等信息随时做出反应，大量实时任务需要快速计算，而将这些任务全部上传到云中心，无疑会增加时延，那么将车辆任务卸载到车载边缘节点来计算成为一种有效解决途径。道路边侧单元（road side units，RSU）是车路协同路侧端的重要组成部分，其主要功能是采集当前的道路状况、交通状况等信息，通过通讯网络，与路侧感知设备、交通信号灯、电子标牌等终端通信，实现车路互联互通、交通信号实时交互等功能，其常常作为车载边缘节点，计算由车辆卸载的任务。而在城市繁忙的路段，许多计算负载重的实时任务如视频识别任务、在线路径规划等需要被快速计算响应，即使是RSU，也无法承接全部的卸载任务，容易出现过载，从而影响卸载性能。所以paper1提出采用无人机辅助卸载任务，过载的RSU可以将任务卸载到无人机上，由无人机完成任务计算。

paper2聚焦基础设施较弱的云边计算（edge-cloud computing）场景，在这样的场景中，由于缺乏边缘服务器这种基础设施，无人机就充当起边缘服务器的角色，处理来自外部设备（如用户或者其他无人机）的卸载任务，并且通过基站与云中心进行通信。所以paper2提出采用多个无人机作为边缘计算节点，无人机之间可以互相卸载任务，从而提升任务完成效率。

System Model

paper1的系统模型图如下：

系统分为三层：车辆层、RSU层以及无人机层。车辆 v生成计算密集型任务并通过vehicle-to-infrastructure(V2I)通信链路卸载任务至RSU m上。当卸载的任务超出RSU的计算能力时，RSU发生过载，显示在图中为红色。系统中使用一架部署有边缘服务器的无人机处理过载的RSU，该无人机在固定的高度H飞行。
系统有以下几点特性：

1. 系统处理时间敏感、计算密集的车辆任务。
2. 系统关注卸载效率，过载会导致响应变慢，影响QoS。
3. 系统中无人机相当于空中边缘服务器，与普通服务器不同的是，无人机可以随计算负载的改变而灵活移动。

paper2的系统模型图如下：

系统中包含U个旋翼无人机和一个连接着云中心的基站。在识别场景中，无人机收集大量的图像和视频数据用以分析，其既是任务的生成者，也是任务的执行者。无人机之间可以相互通信，卸载计算任务。

paper1

Vehicular Task Offloading Model

任务的到达符合泊松过程，使用$\lambda$_v^t即每个时隙到达的任务数来代表车辆v在t时刻的任务到达率。假定一个任务的期望计算负载为c (所需的CPU周期数），期望数据大小为d（任务的比特数），那么$\lambda$_v^tc 和$\lambda$_v^td就是时刻t车辆v的任务计算负载与数据大小。
当实现车辆任务卸载时，车辆和RSU之间的通信采用正交频分多址(orthogonal frequency division multiple access, OFDMA），每个RSU的带宽资源被分为多个正交子信道，分配给不同的车辆用户。忽略RSU m 的区域内干扰，只考虑区域间干扰，即其他RSU和其覆盖范围内车辆的通信干扰。通信干扰表示为

因此RSU m 与车辆 v 之间的数据传输率为

因此t时刻车辆到RSU m的传输时延为

UAV-Assisted Offloading Model

以下约束为计算负载约束，表示t时刻过载的RSU k 需要卸载到UAV上所需的CPU周期数以及数据大小不超过RSU k上到达任务所需CPU周期数以及数据总量。

接下来为RSU k 与UAV之间的传输通信。假设UAV与RSU之间的无线信道为概率LoS信道，以下式子为无线信道是LoS信道的概率

$\mu$₁和$\mu$₂是环境参数，$\beta$是UAV与RSU之间仰角，
则信道增益表示为

其中g0是参考距离的信道增益， ζ是NLoS信道的衰减因子。所以过载RSU k与UAV之间的传输数据率为

过载RSU k与UAV之间的传输时延表示为

同时，UAV将飞到RSU k的位置(xk, yk, H) 来提供卸载服务。f^u表示UAV的计算能力，那么我们可以获得UAV的计算时延为

相应地，UAV的计算能耗表示为

其中b是能耗系数，与UAV结构有关。
剩余没有被卸载到UAV上的任务，则由RSU进行计算，RSU m的计算时延为

其中i_k^m表示该RSU是否为过载的RSU，s_k^t表示该RSU是否选择卸载任务到UAV。

除此之外，需要考虑出现网络拥塞时队列的等待延迟，使用M/M/1队列理论建模

$\tau$为没有网络拥塞时车辆v 传输一个任务到过载RSU k 的期望时延，ξ为过载RSU k 上剩余的计算数据大小。
任务处理完毕后，UAV将结果返回给RSU，RSU将结果返回给对应的车辆，返回时延为

当UAV处理完一个过载的RSU时，需要飞到下一个过载的RSU附近，飞行速度为v，则飞行花费的能量为

UAV Energy Harvesting Model

UAV因为电池的寿命有限，所以经常使用能量收集(energy harvesting, EH)技术来提高工作时长。将能量收集过程建模为能量包到达的过程，用e^t表示t时刻到达的能量包

UAV u在开始时刻是充满电的，那么它每个时隙的energy budget为

UAV在时隙t的能量消耗为计算消耗+悬停消耗+飞行消耗：

长期能量约束表示为

paper2

UAV-to-UAV Transmission Model

假定无人机之间的无线通信链路是LoS的，网络拓扑结构为星状，即有一个hotpot能够传递信息给其他节点。现有工作经常将边缘节点之间的通信时延建模成线性模型，传输时延与卸载任务数成比例，如下式

其中$\beta$_i是UAV i 卸载到其他UAV上的任务数量（由于是部分卸载，所以该变量的值不为整数），s为一个任务的期望数据大小。
当多个UAV同时卸载数据到其他的UAV上时，在hotpot处由于带宽资源等的限制，必然会发生网络拥塞。M/M/1排队模型常常被用来建模网络拥塞的情形，现在大部分的RPC协议部署在分布式系统上，或在M2M场景中使用如MQTT等消息协议，这些都采用TCP协议，TCP协议有自己的拥塞控制和避免机制，因此排队延时的影响不完全等同于M/M/1模型。所以，重新建模传输时延模型，与线性模型相比，添加一个$\gamma$来反映模型的性能损失

但是$\gamma$不是一个常数，当网络流量增加，需要控制拥塞。$\gamma$是关于总流量$\beta$（所有UAV卸载的任务总数）的函数

因此，UAV i 在系统中的传输延时为

传输能量消耗为

UAV-to-Cloud Transmission Model

假设所有的UAV都停留在固定的高度H，无人机是静态的。无人机需要将任务卸载到云时，其需要与基站通信，再上传至云中心。而UAV与BS之间的环境是复杂的，需要同时考虑LoS和NLoS。
LoS channel
若无人机与基站之间比较开阔，那么信道为LoS。无人机与基站之间的信道增益为

g0是参考距离下的信道增益，那么LoS信道的可达数据率为

NLoS channel
若无人机与BS之间有许多高楼，距离也很远，那么需要考虑信号的衰落。那么NLoS信道的可达数据率为

使用LoS和NLoS来描述空地信道，那么无人机和基站之间的数据率表示为

Pr(LoS, $\theta$)为LoS信道的概率，该概率由以下式子计算

其中a, b为环境参数。
一个任务从UAV卸载到云的时延表示为

D_BS为基站和云的数据交换时延。 无人机i卸载任务到云的能耗为

Computation Model

云的计算时间可以忽略，因为云中心有足够的计算资源，其能量消耗也可以忽略，云不参与多无人机系统的能耗。因此，计算模型只考虑无人机的任务计算和能量消耗。每个UAV的边缘计算单元的计算频率为f_i，假定每个UAV都有多个核。
为了克服程序执行的不兼容性，这里假定无人机使用了虚拟化技术或容器化技术。比如，无人机i有多个虚拟机，其中一个虚拟器只用于计算UAV j的卸载任务，当UAV j 没有卸载人任务时保持空闲，那么对于无人机i来说，它可以同时执行来自不同无人机的卸载任务。如下图所示，UAV 1的一个任务被划分为四个子任务，这四个子任务分别卸载至UAV1, UAV2, UAV3和UAV4。

那么该任务的完成时间即为四个子任务的最晚完成时间，表示为

令$\mu$_i为其他无人机卸载到UAV i上的任务总数，那么UAV i的计算能耗表示为

Problem Formulation

paper1问题建模为


约束条件为



paper2问题建模为

其中C1为能耗约束，C2和C3为卸载约束，C4为无人机资源约束。

两篇文章中均采用Lyapunov optimization进行问题的求解，此处不进行详细介绍。

Evaluations

paper1采用真实世界的IoV数据集，根据真实的测量设定仿真参数，对比方法有三个：

• Delay consider first (DCF)：目标为最小化总的任务时延，不考虑能量消耗约束。
• Single slot constraint (SSC)：目标依然为最小化总的任务时延，依然遵守能量消耗约束，不过采取更加严格的约束，本文为长期能量约束，该算法则精确到每个时隙的卸载能量不得超过该时隙具有的能量。
• No UAV assistance (NUA)：不采用UAV进行卸载，即使RSU过载。

paper2使用真实的测量验证了系统模型的设定：
首先使用UAV-Enabled Edge Computing Platform，如下图所示

其中Pixhawk4为其飞行单元， Jetson Nano为搭载了GPU的计算单元，T208用于提供能量，MorningCore用于UAV之间的通信。作者使用两架无人机测量了空地信道，可达的数据率，验证了提出的UAV通信传输模型的合理性。而后进行仿真实验。

实验采用了两个真实世界的数据集，对比方法有四个：

• Non-cooperative Computing (NcC)：UAV全部各自执行自己的任务。
• Cloud offloading Computing (CoC)：UAV全部卸载到远程云中心。
• Random offloading Computing (RoC)：UAV随机卸载部分任务到随机的设备。
• Delay Lower Bound (DLB)：不考虑能量消耗约束时的最小系统卸载时延。

Comparisons

对比以上两篇文章，有以下异同：

1. 背景不同：一个是车载边缘计算，一个是云边计算
2. 系统模型不同：paper1采用单个无人机进行辅助，无人机能够移动到不同的过载RSU区域，而paper2采用多个无人机进行协同计算，无人机保持静止不能随意飞。
3. 信道建模方式相同：无人机和地面的通信同时考虑LoS channel和NLoS channel。
4. 卸载方式相同：均采用了部分卸载。
5. 仿真设置相同：均采用真实世界的数据集，环境参数设定均来源于真实的测量。

————————————————————————
参考文献：
【1】X. Dai, Z. Xiao, H. Jiang and J. C. S. Lui, “UAV-Assisted Task Offloading in Vehicular Edge Computing Networks,” in IEEE Transactions on Mobile Computing, vol. 23, no. 4, pp. 2520-2534, April 2024, doi: 10.1109/TMC.2023.3259394.
【2】Z. Bai, Y. Lin, Y. Cao and W. Wang, “Delay-Aware Cooperative Task Offloading for Multi-UAV Enabled Edge-Cloud Computing,” in IEEE Transactions on Mobile Computing, vol. 23, no. 2, pp. 1034-1049, Feb. 2024, doi: 10.1109/TMC.2022.3232375.