FiWi增强型车载边缘计算网络

背景与动机

随着无线通信、感知、人工智能和云计算技术的迅速发展，智能网联汽车被广泛认为是传统车辆的未来发展趋势[1]。智能网联汽车配备了先进的车载传感器、控制器、执行器等设备，能够实现车辆与万物之间的智能信息共享，即车对外界通信（V2X），以及复杂环境感知、自动管理、智能导航、智能停车和自动驾驶[2]。为实现上述功能，智能网联车辆涉及多种应用技术，包括最短路径计算、虚拟现实、机器学习、自然语言处理（NLP）、交互式游戏等。其中大多数技术对计算资源和处理时延有较高要求。遗憾的是，现有的智能网联汽车计算能力有限且存储不足。资源受限的智能网联车辆与资源消耗型的智能网联汽车应用之间存在矛盾，这对智能网联汽车未来的发展提出了重大挑战[3]。

为了解决这一挑战，最常见的方法是将智能网联汽车（ICV）的计算密集型任务或其部分任务卸载到云中心，即云计算卸载（CCO）。然而，考虑到通过广域网进行长距离/超长距离传输所带来的长延迟和低可靠性问题，CCO无法满足大多数智能网联汽车应用的需求。近年来，移动边缘计算/多接入边缘计算（MEC）作为一种关键使能技术被提出，旨在5G网络中于无线接入网络侧为靠近移动用户的位置提供云计算能力和存储能力[4]。通过采用MEC技术，我们可以在路侧单元（RSU）部署大量轻量级边缘计算基础设施，并将智能网联汽车的部分计算任务卸载至邻近的边缘服务器。与远程云中心相比，尽管轻量级边缘服务器无法为智能网联汽车提供高计算能力和大容量存储资源，但它们能够显著降低完成智能网联汽车计算任务的往返延迟，并为其提供高可靠性、大规模连接服务。因此，MEC被视为解决智能网联车辆资源受限挑战的一项有前景的方案，即车载边缘计算网络。

在过去几年中，许多关于车载边缘计算网络的研究被提出。例如，Zhang等人[5]研究了车载边缘计算网络中的任务卸载问题，并提出了一种高效的预测式组合模式卸载方案，该方案将智能网联汽车的计算任务通过直接上传或预测性车对车中继传输自适应地卸载到边缘服务器。然而，与大多数MEC移动设备不同，智能网联车辆必须面对具有不同粒度和QoS需求的多样化计算任务，这些任务不仅包括计算量小且要求超低延迟的自然语言处理任务，还包括计算量大且要求低延迟的机器学习任务。在这种情况下，仅依赖部署在附近路侧单元的轻量级边缘服务器而忽略远程云中心的巨大计算资源显然是不够的。特别是随着无源光网络（PON）以及超低损耗和超低延迟光纤的广泛应用，长延迟和低可靠性问题已得到显著缓解[6]。因此，在利用远程云中心和部署在路侧单元的边缘服务器的计算资源之间实现平衡，并设计一种协同任务卸载方案，在车载边缘计算网络中变得必要且重要。

此外，当前车载网络中的通信主要包括车辆与其他车辆（V2V）、路侧基础设施（V2R）、驾驶员/乘客（V2P）、互联网（V2I）以及后端云服务器之间的信息共享。具体而言，常用的V2X通信技术包括：基于IEEE 802.11p的车载自组织网络用于V2V通信；基于4G/演进中的5G蜂窝网络用于V2V、V2R、V2P和V2I通信；Wi‐Fi和蓝牙用于V2P通信；以及光纤网络和数字用户线路（DSL）用于V2I通信。此外，作为迈向5G的另一项关键技术，设备到设备（D2D）通信也被认为是未来V2V直接通信的潜在技术[7],[8]。如表1所示，每种V2X通信技术都有其各自的优点与缺点。面对在高速移动的智能网联汽车中大规模、高频、低/超低延迟、高/极高可靠性数据传输的需求，通信技术的选择成为另一个挑战，因此无法依赖单一通信技术来满足车载边缘计算网络的要求。通过结合光纤网络在高容量、低延迟和高可靠性方面的优势，以及无线接入网络在高移动性、无处不在的连接和多种无线接入技术支持方面的优势，混合FiWi网络为5G时代提供了一种有前景的网络技术[9],[10]。特别是由于其集中控制机制，FiWi网络在许多高速移动场景中显得不可替代，例如中国高速铁路、新干线、快速移动车辆等，在这些场景中，当驾驶员/乘客从一个基站频繁切换到另一个基站时会遭受极其频繁的切换问题[11]。因此，FiWi网络被视为车载边缘计算网络中有前景的解决方案，从而催生了所谓的增强型光纤‐无线融合车载边缘计算网络。

为此，我们提出了一种基于FiWi的车载边缘计算网络架构，以充分利用远程云中心和边缘服务器的计算资源。研究了远程云中心、边缘服务器与智能网联汽车之间的协同任务卸载问题。作为解决方案，提出了两种协同任务卸载方案，即约束随机卸载方案（CROS）和集中式启发式贪婪卸载（CHGO）方案，在卸载决策过程中同时考虑了V2V和V2R通信。

FiWi增强型车载边缘计算网络

FiWi网络，也称为混合FiWi接入网络，将光纤网络和无线接入网络无缝集成。鉴于其在可扩展性和灵活性方面的优势，最近一些研究人员提出将FiWi网络与MEC相结合，并为MEC应用提出了一种灵活的基于FiWi的网络架构[12]。为了支持集中式云与MEC的共存，郭和刘[13]将FiWi融合引入MEC，并在此场景下提出了一种协同计算卸载方案，其中集中式云和边缘服务器的计算资源得到了高效利用。

图1展示了一个增强型FiWi车载边缘计算网络的通用架构。不失一般性，我们考虑一条单向无转向的道路，以及在该道路上以恒定速度行驶的若干智能网联车辆（ICV）。假设道路上ICV的分布服从泊松分布。沿道路部署有多个路侧单元（RSU），且任意两个相邻RSU之间的距离假设为固定值。RSU之间通过无线回传连接，并可为其覆盖范围内的ICV提供无线接入服务。具体而言，我们提出的网络架构可分为两部分：一部分是光骨干网络，用于将增强型FiWi车载网络连接至数千英里外的远程云中心；另一部分是增强型FiWi车载网络，用于为ICV提供移动边缘计算（MEC）和互联网接入服务。增强型FiWi车载网络又包含两个部分：一是光回传，用于连接RSU与光线路终端（OLT）；二是无线前端，用于为ICV提供无线接入服务。本文中，我们采用10G‐以太网无源光网络（10G‐EPON）作为光回传方案，因其具有广泛的应用和较高的成本效益。10G‐EPON采用树形分支拓扑结构，其中位于中心局的多个光线路终端（OLT）作为根节点，多个光网络单元作为末端节点（ONU）与RSU集成，即ONU‐RSU，构成网络的叶节点。ONU‐RSU通过1:N分光器（1:32或1:64）与OLTs相连。为了向智能网联汽车提供边缘计算服务，每个RSU都配备有一个或多个边缘服务器。智能网联车辆可以通过专用短程通信（DSRC）技术，如IEEE 802.11p、IEEE 1609协议族等[14],[15]，实现彼此之间的通信（即V2V）或与RSU的通信（即V2R）。

增强型FiWi车载网络中的移动边缘计算

在增强型光纤‐无线融合车载边缘计算网络中，智能网联汽车的计算任务可以在其自身的中央处理器上本地执行，也可以卸载到位于路侧单元的边缘服务器，或卸载到远程云中心。然而，在考虑所有智能网联车辆的任务时，必须考虑无线信道干扰。随着越来越多的计算任务被卸载到云中心和边缘服务器，上行链路数据速率将受到严重影响，从而导致任务的处理延迟增加。此外，智能网联汽车将其计算任务卸载到路侧单元的边缘服务器时通常有两种通信选择：通过V2R通信进行边缘计算，以及通过V2V通信进行边缘计算。具体而言，对于第一种方式，智能网联汽车可通过V2R通信将其计算任务卸载至当前所关联的路侧单元j连接的边缘服务器。任务完成后，该结果通过无线回传传输至智能网联汽车当时所关联的另一个路侧单元k。随后，路侧单元k通过V2R通信将输出结果返回给智能网联汽车。对于第二种方式，智能网联汽车可通过V2V通信直接将其计算任务发送至其行驶方向前方与路侧单元l相连的边缘服务器。

技术	V2X场景	Pros	Cons
光纤网络	v2i	高传输速率，高质量连接，高安全性，良好抗干扰性，高可扩展性	安装成本高，易受物理损坏
DSL	v2i	低成本，高带宽	强距离依赖性
DSRC	v2r/v2v/v2P	高移动性，分布式通信，自组织，低成本，自组织网络模式	频繁断连，短通信距离，频繁信道拥塞，高干扰（针对v2P通信）
蜂窝网络（3G/4G LTE）	v2v/v2r/v2p/v2i	高传输速率，大覆盖范围，集中式架构	高成本，有限带宽，高延迟用于安全服务
D2D	v2v	高频谱效率，低延迟	多通道干扰，不适用于高速移动场景
Wi‐Fi	v2P	高灵活性、低成本、成熟易于部署、广泛应用	能效低、安全性低、覆盖距离短
蓝牙	v2P	普及率高，免费稳定	覆盖范围短，传输速率低，效率低安全性低

这里，我们采用一种预测方法来获取路侧单元 l，智能网联汽车可在其任务刚好完成的时刻到达路侧单元 l 的覆盖范围。之后，输出结果通过V2R通信传回智能网联汽车。在下一节中，我们将详细介绍FiWi增强型车载边缘计算网络中的四种卸载策略。

本地计算

通常，任何智能网联汽车 i 的计算任务可以用四个项目来描述，包括任务的输入和输出数据大小、完成该任务所需的计算容量以及其最大允许处理时延。本文在不失一般性的前提下假设每辆智能网联汽车在同一时间仅有一个需要完成的计算任务。对于智能网联汽车 i，如果决定在其自身的车载CPU上本地执行其计算任务，则完成该任务的处理时间可简单地通过将其所需计算容量除以智能网联汽车 i 的计算能力来计算。

基于FiWi网络的云计算

对于处理延迟无严格限制的智能网联汽车计算任务，智能网联车辆可通过FiWi网络和光骨干网络，在增强型光纤‐无线融合车载边缘计算网络中将部分任务卸载至远程云中心。具体而言，当智能网联汽车 i 选择将其任务卸载至远程云中心时，该任务的处理时间可由以下三部分相加得到：通过FiWi网络和光骨干网络将输入数据上传至远程云中心的上传时间、任务在远程云中心的执行时间，以及通过光骨干网络和FiWi网络将输出结果从远程云中心下载回智能网联汽车的下载时间。为获得这些时间，上传时间进一步包括输入数据通过无线接入从智能网联汽车传输到路侧单元的时间，以及从路侧单元经FiWi网络的光回传链路和长距离光骨干网络传输至远程云中心的传输时间。任务的下载时间可类似地计算。这里，我们忽略任务在远程云中心的执行时间，因为远程云中心（如亚马逊云服务、微软Azure、阿里云等）通常具有充足的计算资源。

通过V2R通信实现边缘计算

如果智能网联汽车i选择通过V2R通信将计算任务卸载至部署在路侧单元的轻量级边缘服务器，则该任务的处理时间通常由以下四部分相加得到：智能网联汽车将输入数据传输到与其关联的路侧单元所连接的边缘服务器的传输时间、任务在边缘服务器上的执行时间、输出结果通过无线回传从先前关联的路侧单元传输到目标路侧单元k的传输时间，以及输出结果从路侧单元k下载到智能网联汽车的下载时间。其中，路侧单元k是计算任务完成时与智能网联汽车i相关联的路侧单元，且此时路侧单元k应刚好接收到该任务的输出结果。

通过V2V通信实现边缘计算

如前所述，我们也可以通过V2V通信将智能网联汽车i的计算任务卸载到边缘服务器。在这种情况下，我们首先通过V2V通信将该任务的输入数据发送到路侧单元l，其中路侧单元l是智能网联汽车在任务刚好完成时所到达的位置。然后，该任务在连接至路侧单元l的边缘服务器上执行。之后，输出结果通过V2R通信传回给智能网联汽车。具体而言，采用基于V2V通信的边缘计算处理智能网联汽车i的计算任务所需的时间可由以下四部分相加得到：输入数据通过V2V通信从智能网联汽车i传输到智能网联汽车m的传输时间、输入数据从智能网联汽车m上传至连接路侧单元l的边缘服务器的上传时间、该任务在边缘服务器上的执行时间，以及从边缘服务器通过V2R通信向智能网联汽车传输输出结果的下载时间。其中，智能网联汽车m是位于路侧单元l覆盖范围内的车辆。

增强型光纤‐无线融合车载边缘计算网络中的协同任务卸载

问题定义

根据我们之前的讨论，对于任何智能网联汽车的计算任务，最多有四种卸载策略可供选择。智能网联汽车可以选择其中一种策略来完成其计算任务，以获得最小的处理延迟。但是，如前所述，随着通过V2R通信或V2V通信卸载的计算任务增多，无线信道干扰不容忽视。在这种情况下，通过V2R通信的上行链路数据速率或传输数据速率V2V通信将大幅下降，导致智能网联汽车的任务处理时间增加。本文的目标是为所有智能网联车辆的计算任务找到一个最优卸载决策配置，以在满足其给定的处理延迟约束的前提下，最小化智能网联汽车任务的总体处理时延。具体而言，该约束优化问题可定义如下。

带处理时间约束的处理延迟最小化

给定智能网联汽车（ICVs）及其计算任务的初始信息，包括ICV的速度、完成任务所需的输入数据大小和所需计算能力，以及路侧单元（RSUs）上智能网联车辆和边缘服务器的全部计算能力，带处理时间约束的延迟最小化（DMTC）问题旨在为所有ICV的任务找到一个最优卸载决策配置，以在满足给定处理时延约束的前提下，实现最小的总体处理时延。

为了解决动态多任务协同问题（DMTC），一种穷举法是对智能网联车辆（ICVs）的计算任务的所有可能卸载决策组合进行枚举，并选择在满足其给定处理时间约束的前提下总体处理延迟最小的方案，即最优枚举卸载方案（OEOS）[13]。该方法简单直观，能够获得动态多任务协同问题（DMTC）的最优解。然而，最优枚举卸载方案（OEOS）并不实用，因其具有极高的计算复杂度，即$O(4^n)$，其中$n$是智能网联汽车计算任务的数量。

CROS

为了降低求解动态多任务协同问题（DMTC）的计算复杂度，我们进一步提出了一种约束随机化方法，即CROS。在CROS中，对于每辆智能网联汽车（ICV），我们首先分别采用前述四种卸载策略来计算其处理延迟，并在满足给定处理时延约束的前提下随机选择其中任意一种策略。CROS的详细内容如算法1所述。与OEOS相比，CROS具有更高的计算效率，即$O(n)$。然而，它无法为动态多任务协同问题（DMTC）提供最优解或近似最优解。

此外，为了解决DMTC并获得其近似最优解，可以采用另一种常用方法，即博弈论，该方法已在我们之前的工作[13]中提出。具体而言，我们可以将协同任务卸载问题建模为一个策略博弈，并设计一种基于博弈论的任务卸载方案（GTOS）。在GTOS中，智能网联汽车的集合可被建模为理性博弈参与者的集合，所有智能网联车辆的卸载策略构成了博弈参与者的策略集。关于成本函数，我们首先通过采用智能网联汽车i的潜在最优卸载决策（即在其他智能网联车辆的卸载决策给定的情况下，使其任务实现最小处理延迟的本地最优卸载决策），来引入该决策。随后，智能网联汽车i的潜在最优卸载决策可被建模为博弈参与者i需最小化的成本函数。更多细节请参见我们之前的工作[13]。

CHGO

如第[13]节所述，GTOS能够为我们的研究问题提供一个近似最优解。然而，其计算效率不如CROS，因为GTOS的运行时间在很大程度上依赖于所有博弈参与者（即ICV）达到纳什均衡所需的迭代次数。遗憾的是，根据我们之前的实验结果，该迭代次数通常比博弈参与者数量高出四到五倍，并且随着计算任务数量的增加，这一趋势还会持续上升。特别地，GTOS的计算复杂度可表示为$O(cn^2)$，其中$c$为常数。考虑到FiWi增强型车载边缘计算网络的集中式架构，并为进一步提高解决DMTC的计算效率，我们在CROS和GTOS的基础上提出了另一种CHGO。

在CROS的基础上，CHGO中的每辆智能网联汽车不会随机选择其任务卸载策略，而是选择能够实现最小处理延迟的策略。然后，智能网联汽车将其卸载决策报告给云中心，云中心通过V2R通信将所有当前连接广播给路侧单元（RSU），并通过V2V通信将这些连接广播给其余的智能网联车辆。之后，剩下的一个智能网联车辆做出其当前的最优卸载决策。该过程循环执行，直到所有智能网联车辆都完成卸载决策。CHGO的详细内容简要呈现在算法2中。

CHGO采用集中管理模式，更适合所提出的FiWi增强型车载边缘计算网络，而GTOS是一种分布式方法。与GTOS相比，CHGO不仅能够获得动态多任务协同问题（DMTC）的近似最优解，而且实现了更高的计算效率[即$O(n^2)$]，而非GTOS的更高复杂度。两者的详细比较将在后续评估部分中给出。

算法 1 CROS。
输入：智能网联车辆及其计算任务的信息、智能网联车辆和部署在远程站点的边缘服务器的全部计算能力，以及无线和光网络中的上行链路数据速率。
输出：所有智能网联车辆计算任务的最优卸载决策配置及相应的总体处理时延。
1：对于每辆智能网联车辆执行
2: 分别采用四种卸载策略计算其处理延迟
3: 在满足给定处理延迟约束的前提下，随机选择其中一种卸载策略
4: 计算当前车到路侧通信上行链路数据速率和车对车传输数据速率
5: 结束循环
6: 计算所有智能网联车辆任务的总体处理时延
7: 返回所有智能网联车辆任务的卸载决策配置及总体处理时延。

算法 2 CHGO。
输入：智能网联车辆及其计算任务的信息、智能网联车辆和部署在远程站点的边缘服务器的所有计算能力，以及无线和光网络中的上行链路数据速率。
输出：所有智能网联车辆计算任务的最优卸载决策配置文件及相应的总体处理时延。
1: 对于每个智能网联车辆执行
2: 分别采用四种卸载策略计算其处理延迟
3: 如果采用本地计算时其处理延迟无法满足给定的处理时延约束则
4: 选择在满足给定处理时延约束的前提下具有最小处理延迟的卸载策略作为其卸载决策
5: 更新所有与远程站点和智能网联车辆的连接
6: 结束如果
7: 结束循环
8: 对于剩余智能网联车辆中的任意智能网联车辆 i 执行
9: 分别采用四种可选卸载策略计算其处理延迟
10: 选择在满足给定处理时延约束的前提下具有最小处理延迟的卸载策略作为智能网联车辆 i 的卸载决策
11: 更新所有与远程站点和智能网联车辆的连接
12: 结束循环
13: 计算所有智能网联车辆任务的总体处理时延
14: 返回所有智能网联车辆任务的卸载决策配置文件及总体处理时延。

性能评估

在本节中，我们进行了对比实验，并展示了一系列数值结果，以验证所提出的协同任务卸载方案的性能。不失一般性，我们考虑一个FiWi增强的车载边缘计算网络场景，其中有五个RSU位于一条单向、不可转弯的道路沿线，云中心距离该道路1000公里。假设每个RSU拥有50个无线正交信道的频率资源，其信道带宽设置为40兆赫。光网络上的上行链路数据速率设置为4吉比特/秒。我们还假设道路上所有ICV以恒定速度行驶，且每辆ICV在同一时间仅有一个需要完成的计算任务。对于每个任务，假设其输入和输出数据大小在300至800千字节之间变化，所需计算能力（即中央处理器周期）设定在100至1000兆周期之间。此外，我们假设ICV任务的最大允许处理延迟在0.5至2秒之间。智能网联汽车和部署在路侧单元的边缘服务器的计算能力分别设置为1吉赫和4吉赫。

为了验证我们提出的在Fi‐Wi增强型车载边缘计算网络中的协同任务卸载方案的有效性和效率，我们比较了OEOS、CROS、GTOS和CHGO在不同ICV数量下的总体处理时延和运行时间，如图2所示。其中，能够为动态多任务协同问题（DMTC）提供最优解的OEOS作为我们的基准。从图2(a)可以看出，GTOS和CHGO均能为我们提出的协同任务卸载问题获得近似最优解，并且随着ICV数量的增加，这一趋势保持良好。图2(b)还表明，我们提出的所有方案（包括CROS、GTOS和CHGO）的计算效率均远高于OEOS（即基准）。此外，尽管CROS无法为我们的DMTC问题提供最优解，但它是最快速的方案，因此在需要快速响应的场景中，CROS提供了良好的解决方案。在大多数集中式车载边缘计算场景中，CHGO是最佳选择，因为它不仅能够为动态多任务协同问题（DMTC）获得近似最优解，而且其计算效率也高于GTOS。

为了进一步证明在FiWi增强型车载边缘计算网络中引入远程云中心并设计协同任务卸载方案的必要性，我们分别采用本地计算、无远程云中心的边缘计算以及CROS、GTOS和CHGO，对比了所获得的总体处理时延。如图3所示，我们提出的CHGO在五种方案中能够实现最低的总体处理时延。通过它们之间的比较，进一步验证了引入移动边缘计算（MEC）和远程云中心的必要性。

为了测试智能网联车辆的密度和速度对选择车到路侧和车到车通信的影响，我们还进行了两组实验。图4描绘了在固定智能网联车辆速度（即120公里/小时）下，智能网联车辆数量对选择车到路侧和车到车通信进行数据传输的影响的数值结果。x轴表示智能网联车辆总数，y轴表示选择车到路侧或车到车通信的智能网联车辆数量。可以明显观察到，随着智能网联车辆数量的增加，从而导致更高的智能网联车辆密度，越来越多的智能网联车辆选择采用V2V通信进行数据传输。图5展示了在固定的智能网联车辆数量（即120）下，智能网联车辆速度对选择车到路侧和车到车通信影响的数值结果。从中可以看出，随着智能网联车辆速度的增加，选择通过V2V通信进行数据传输的智能网联汽车比例略有下降，但基本保持不变。然而，选择通过V2R通信的智能网联汽车数量显著减少。根据这两组实验，我们可以得出结论：通过V2V通信的任务卸载主要与智能网联车辆密度相关，而与智能网联车辆速度关系较小；而通过无线回传的V2R通信任务卸载则受智能网联车辆速度影响较大，但对智能网联车辆数量不敏感。

结论

本文研究了车载边缘计算网络中的协同任务卸载问题，以充分利用远程云中心和轻量级边缘服务器的计算资源。首先，我们提出了一种FiWi增强型车载边缘计算网络架构，以支持远程云中心与连接至RSU的轻量级边缘服务器共存。接着，我们定义了在FiWi增强型车载边缘计算网络中的协同任务卸载问题，目标是最小化所有ICV任务的总体处理时延，同时考虑了V2R和V2V通信。随后，我们提出了两种逐步式任务卸载方案作为解决方案，大量数值结果验证了所提方案的有效性和高效性。