英语原文共 9 页
面向车联网的移动边缘计算
卸载框架和任务调度
作为车辆互联网（IoV）的支持技术，除了其他可访问资源之外，移动边缘计算（MEC）还提供了用于在车辆之间共享计算能力的潜在解决方案。本文首先介绍了一种分布式车辆边缘计算方案——自动车辆边缘（AVE），它使得通过车对车（V2V）通信共享相邻车辆可用资源成为可能。然后我们将这个概念扩展到一个更通用的在线解决方案，称为混合车辆边缘（HVC），它能够通过使用多址网络有效共享所有可访问的计算资源，包括路边单元（RSU）和云。我们还演示了这两个分散边缘计算解决方案对任务执行性能的影响。最后，我们讨论了几个悬而未决的问题和未来的研究方向。
随着无线通信技术的发展，车辆可以通过V2V通信直接相互连接，也可以通过车辆到基础设施（V2I）通信与RSU之类的基础设施相连。V2V和V2I，即车辆对一切（V2X）通信可以通过使用IEEE 802.11p、毫米波（mm波），或者甚至可以将具有上限干扰的蜂窝频率重用到主要蜂窝用户来实现。V2X通信是在自动驾驶中使用的基本技术，可以帮助显著增强道路上的安全性，更好地安排交通以减少汽油消耗和二氧化碳排放，实现众多应用（例如，视频观看[3]）等等。
为了使未来的汽车生活更加便捷，高效和安全，将会有越来越多的车载应用，例如基于机器学习的智能语音/图像识别和处理，增强现实支持的游戏等。每个车辆可以有许多应用程序运行在它上面，与相应的后端和管理器模块，以帮助实现这些应用程序。这给车辆满足这些日益增加的计算能力提出了新的挑战。更新硬件是最简单的方法，但它带来了高额的货币成本。访问远程云是另一种选择，但它受到车辆环境中长延迟和不稳定连接的困扰。
MEC，也称为雾计算[4]-[6]，在网络边缘提供信息服务环境和云计算能力，即，车辆环境中的RSU或相邻车辆可以是满足吞吐量和延迟性能要求的更合适的解决方案。[7]和[8]中的相关研究表明在车辆环境中具有良好的性能，然而，这些方案具有各种限制，例如仅可用于静态场景，专用于特定应用或需要基于基础设施的集中控制。如何为各种应用提供通用框架并在高度动态的车载环境中有效地执行边缘计算仍然是开放的研究问题。固有的主要研究问题是如何发现可用资源以及如何使用多路访问网络支持来调度任务卸载以最大化已定义的性能目标。
本文解决了这些研究问题，并展示了如何通过多址网络利用相邻车辆、RSU和云中的可用资源来获得对新兴车载应用程序的日益增加的计算能力。在农村和城市中，车辆行驶的环境是非常不同的，因此，我们设计了两种新颖的解决方案：分布式车辆边缘计算和在线车辆边缘计算，有效地利用了相邻车辆的闲置资源和可用的通信技术。
第一个解决方案[9]，我们称之为AVE框架，通过利用相邻车辆的可用资源和通过IEEE 802.11p进行V2V通信的专用短程通信（DSRC）来提高计算能力。该框架使用工作流来支持在网络和任务处理需求约束下的自主车辆云的分散组织。未使用诸如基站和RSU等基础设施。工作流由任务缓存（用于分布式批处理调度）、相邻车辆发现、任务调度（即，应在何时和何处处理每个任务）、数据传输（即，如果任务被分配到另一个节点）、任务执行和结果数据传输组成。在邻近的车辆发现和作业调度期间考虑邻近车辆的数据，包括GPS信息。在[10]中，基于蚁群优化（ACO）的调度方案呈现出近乎最优的性能，并且计算复杂度低得多。在线解决方案是HVC，在[11]中部分介绍。该解决方案将AVE扩展为涉及RSU和远程云服务器（通过蜂窝网络），其具有比相邻车辆更强大的计算能力。除了IEEE 802.11p之外，包括LTE和毫米波通信的多路访问技术[12]用于V2X通信。我们研究如何有效地利用多路访问网络资源，并设计一个在线调度算法进行工作卸载。通过模拟说明了多路访问网络对混合车辆边缘云框架性能的影响。通过引入额外的通信和计算资源，我们表明可以实现更高的计算能力。
车载边缘计算框架
本节介绍两种车辆边缘计算框架及其用于高效卸载的任务调度算法。
系统总览
要进行车辆边缘计算，必须发现相邻车辆（以及RSU和远程云服务器）的可用性，将任务安排到可用车辆，RSU或云，并指定卸载和下载传输方法。为了更好地制定一个必要的任务要求，在一般框架中，本文假设任务是使用以下特征的流程的通用实体：
1)效用：完成工作对用户体验的影响。
2)指定的主机：处理器必须满足处理作业所需的主机要求（即相关语言和软件）。
3)上下文无关：一个作业可以在满足主机要求的另一个节点上执行，其中包含所有数据。
4)简介：是关于任务的信息，例如工作负载。
与其他客户端 - 服务器体系结构一样，此框架中的软件包括客户端应用程序和相应的服务器端应用程序，称为应用程序模块和后端模块，如图1所示。应用程序在本机操作系统上运行， 管理他们的优先事项和可用资源; 后端在虚拟机中运行，该虚拟机由框架管理。 管理器模块被实现为中间件，以收集关于来自其他两个模块的作业和结果的信息，并进行卸载和作业分配决策。
为了解释车辆边缘计算的工作原理，生成任务的节点名为请求程序，帮助处理任务的节点称为处理器。如果计划在生成任务的节点处处理任务，则表示该任务在本地处理。当请求者生成超出其自身计算能力的更多任务时，请求者需要搜索潜在的处理器并将任务卸载到选定的处理器以使其处理。两个主要的固有技术挑战是请求程序如何在有或没有中间节点帮助的情况下找到处理器，并且在获得处理器知识之后，请求程序应如何将其任务分配给这些可用处理器以最大化所定义的目标 功能。 在为每个任务决定处理器之后，相应的数据将被发送到指定的处理器，并且在任务处理完成之后将返回结果。在本文中，这些过程称为工作流。 车辆边缘计算研究如何设计工作流程以及如何安排任务。
AVE的框架
AVE的工作流程
AVE是我们提出的用于车辆边缘计算的分布式解决方案，并且可以在动态车辆环境中提供任务卸载服务，而不需要部署特定的基础设施，例如无线蜂窝网络，RSU和云服务器。通过借用相邻车辆的计算能力来完成卸载，其中基于IEEE 802.11p的网络用于V2V通信。图2（a）显示了AVE中的工作流程。要为每个节点中的卸载和调度做出分布式决策，需要遵循一些关键步骤。
1）用信标估计邻近的资源：信标消息用于获取有关附近可用资源的信息。一个信标消息是相对简单的，只提供基本信息给邻近的车辆决定是进入处理器发现和卸载阶段还是本地处理作业。车辆以微小的速度差异发送信标信息，被认为是潜在的处理器。
2）任务缓存：不是在任务到达时立即调度和上传，而是首先缓存生成的任务，以寻求更好的任务分配，并避免多个同时发现过程和数据传输。当缓存的任务足够多或等待时间足够长时，任务缓存结束。
3）处理器发现：如果在引导阶段发现了潜在的处理器，则请求程序在任务缓存后进入处理器发现阶段，并广播请求消息以发现缓存任务的处理器。任务信息（例如任务需求和请求程序的速度）也包含在消息中，可用且可行的处理器将投标返回给请求程序。在这个步骤中，投标是一个完成工作所需的时间的估计。
4）任务调度：待调度的有限集任务，发现后获得可以帮助处理任务的有限集节点。考虑到 AVE 中有限的 DSRC 信道容量，传输时间至关重要，只有在传输完成后才能开始处理。如果有多个任务，将逐一处理，并且是在先到先服务的基础上。调度机制确定要传输的任务的顺序和每个任务的处理器，以便最大化所定义的目标函数。 在完成调度之后，将向分配的节点通知调度结果。
5）任务卸载：确定将任务卸载到指定处理器的持续时间，并将结果从处理器下载到请求者。发现和数据传输之间的时间长度通常很短，我们可以假设网络结构不会发生太大变化。然后，可以沿着在发现阶段期间使用的相同路径转发处理任务过程所需的相应数据。为了将结果返回给请求者，在我们的实施中使用了一种称为无线自组网按需平面距离矢量路由协议的传统路由协议，其他路由方案也适用。
基于ACO的调度
作为工作流程的一部分，AVE中的调度问题确定要传输的任务的顺序（在所提出的解决方案中不假设并行传输）和每个任务的处理器，以便最大化所定义的目标函数。这是一个两阶段的混合流水线问题，并且是NP难的。AVE框架的非基础结构性质仅使用相邻车辆的有限通信资源和计算能力，这需要有效的调度算法来组织任务以获得更好的整体性能。
所提出的解决方案采用基于ACO的调度算法，其导致近乎最优的性能和低计算复杂度。 与粒子群优化和随机扩散搜索类似，ACO使用群体智能。ACO是一种概率方法论，其灵感来自寻找食物之路的蚂蚁的行为。食物的良好（例如，较短）路径吸引蚂蚁跟随，并且正反馈最终导致所有蚂蚁遵循这条良好的路径。该策略产生的技术问题是如何将AVE调度问题制定为基于ACO的调度问题，其答案在[9]中进行了解释。基本上，我们遵循ACO的一般步骤。我们首先通过仔细选择所涉及的参数然后更新它们，将可行的作业调度解决方案映射到ACO中的路径。最后，该算法将会使任务调度达到一个最好的性能。
HVC框架
HVC是车辆边缘计算的在线版本，它使用多路访问网络，以分散的方式包含RSU的计算资源和邻车旁的远程云。我们假设V2V通信及车辆与RSU之间的通信均可通过使用 IEEE 802.11p 或毫米波。图1显示了具有边缘，云和多路访问网络的车辆MEC系统。可以在请求者和处理器之间直接建立毫米波通信，或者使用毫米波继电器（在我们的HVC中最多两跳）。由于毫米波的方向性和易于阻挡的性质，故障概率被添加到毫米波通道。 如果计划在远程云中处理作业，则请求者通过蜂窝网络与远程云通信（具有相应的蜂窝电荷费用）。如何组织这些计算和通信资源是固有的技术挑战。由于具有更丰富的通信和计算资源，所提出的HVC旨在进一步提高作业的完成率，同时降低蜂窝使用费用。
HVC的工作流程
由于上述原因，HVC的工作流程对AVE的工作流程进行了必要的变更，如图2 (b)所示。这两个工作流程之间存在明显的差异和动机。
1）信标和处理器发现：减少等待处理的任务时间，此处的信标消息携带更多信息，以便可以进行调度无需再次寻找处理器。当一辆车在接收来自RSU或相邻车辆的信标消息时，它计算相应节点的可用时间，其估计发送方停留在其通信范围内的预期时间段。可用时间用于任务调度。 除了远程云，每个请求程序还可以从信标阶段获取潜在处理器列表。
2）任务调度：调度程序立即运行调度过程以选择处理器，寻求缩短任务的完成时间。如果传输通道或本地资源当前正忙，任务将添加到相应的队列中，并且调度程序将决定任务在队列中的位置。HVC中的这种调度类似于具有不同目标函数和额外约束的两阶段混合流水线问题。在“用于HVC的在线算法”部分中引入了在线算法来解决该调度问题; 它还调整要传输和卸载的任务的时间，以提高调度性能。
3）任务卸载：HVC旨在进一步缩短响应时间，同时保持卸载的可靠性。为此，当将任务卸载到RSU或附近的车辆时，使用交换关于预定开始时间的可行性的信息的握手。如果处理器变得不可行，则将重新安排相应的任务。
HVC的在线算法
要在 HVC 中进行调度，必须在每个任务到达时选择处理器，并且必须根据是否有其他等待处理的任务来决定排队位置。在HVC中，任务是在没有缓存的情况下立即被调度的，因此与AVE中的任务相比，每次被调度的任务数量要小得多。因此，我们应用具有线性复杂度的在线算法来在HVC中执行关于任务数量times;节点数量的调度对于要调度的每个任务，我们知道一组RSU和满足任务和截止时间要求的车辆节点。每个节点当前队列的处理率和完成时间也是已知的。可以估计使用基于IEEE 802.11p的DSRC向每个附近节点的卸载时间和此任务的处理时间。图3显示了使用该算法的示例。
我们将效用函数定义为成本感知作业执行增益，效用值表示为完成的工作数减去加权的蜂窝成本。与使用RSU或相邻车辆相比，通过蜂窝网络访问远程云会导致额外的蜂窝使用费用，因此，远程云被用作次要选项。我们首先假设工作将使用毫米波传输，传输时间可以忽略不计，然后贪婪地搜索空闲时隙以在到达时处理即将到来的工作。如果队列中有多个这样的插槽，则选择具有满足截止日期的最新开始时间的插槽，以便将来的作业可以更容易地找到合适的插槽。如果没有用于传输和处理的空闲时隙，则使用蜂窝网络在远程云处理该作业，这会导致额外的手机使用费用。由于毫米波传输是定向的并且易于阻挡，我们为基于毫米波的通信添加了失败概率。 如果通信失败，则调度算法检查基于IEEE 802.11p的DSRC或毫米波是否可以传输数据。如果DSRC无法容纳数据传输，请求程序在找到另一个可行的调度结果之前重新安排当前任务。
性能分析
我们现在展示了车辆边缘计算系统带来的计算能力改善，以及框架中的每个组件如何影响整体性能。
仿真设置
我们使用Omnet和Veins来模拟基于IEEE802.11p的DSRC。车辆的传输功率设定为100mW。毫米波通道的传输速率为4Gb / s，出错率为10％。假设用户可以以32Mb / s的总带宽共享蜂窝网络。
城市交通仿真（SUMO）用于模拟车辆交通，卢森堡SUMO交通情景[14]用于生成地图和车辆交通。使用了面积为800mx600m的城市场景和两个RSU。为了更好地评估车辆数量对性能的影响，选择了四个时间段，即400,600,700和8:30，每个时间段持续15分钟。车辆密度较小的是凌晨4点，即平均每平方公里1.23。6点，7点和8点30分的车辆密度比分别分别为凌晨4点的24.4,71.5和78.5倍。在所有设置中，渗透率，也称为部署比率，即该框架中涉及的车辆的百分比，为20％。详细设置和其他模拟参数在[9]和[11]中介绍。
AVE的性能
图4显示了通过比较AVE与本地处理基线的相对效
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
