车载云资源管理与发现

第6章 车联云

6.1 简介

在过去几十年中，车载云（VCs）不仅受到服务和汽车行业的广泛关注，也引起了科学界的高度重视。人们对这种云的关注源于其能够提供的各种机会、服务和应用程序。车载云提供动态资源分配、可靠服务和保证交付。车辆可以通过所提供的资源来利用云服务；因此，车载云必须考虑资源管理，以便实现资源的共享。合理的管理使得车辆能够请求车载云中的可用空闲资源以获得授权访问。

以云的形式随意协作并共享资源的过境车辆构成了车载云 [25]。这些资源的集合形成了一个服务池，可供用户和其他车辆使用。因此，这些云需要提供动态的资源分配、资源发现以及可靠的服务交付。为实现这一目标，车载云可以通过路侧单元（RSUs）、蜂窝网络或任何其他外部支持接入有线基础设施。此外，这些云还可以通过车辆之间的通信，借助车辆间的协作与协作而获益 [14]。

然而，由于车载网络具有高车辆移动性和拓扑结构持续变化等特点，资源管理与发现变得极具挑战性。当车载云缺乏中心控制来处理检测和管理时，这些问题在这些方面更加严重，因为车辆需要创建基础设施来管理云的资源和请求。此外，车辆云之间的协作对于满足服务需求同时不违反其服务质量（QoS）要求至关重要。

在本章节中，我们讨论车载云的概念以及资源管理和发现的问题，同时考虑车辆云的两种主要架构类型。由于这两个要素是创建和维护此类云的关键部分，本章将现有研究分为这两类。

本章节的其余部分组织如下。第6.2节描述了车载云的概念。第6.3节介绍了针对车辆云资源管理的基本方法，并讨论了未来研究中的主要挑战和问题。第6.4节介绍了针对车辆云资源发现的主要方法，并讨论了未来研究中的主要挑战和问题。最后，第6.5节对本章节进行了简要总结。

6.2 车载云概念

车载云在资源发现与供给方面引入了一种新颖的范式。该领域的创新性激发了多项开创性工作，以及对该特定云及其特性的界定。[29]中描述的研究最初将车载云定义为一个车辆组，这些车辆自主地、协作地协调对资源的授权访问。因此，它们的协同计算、通信、感知和物理资源支持动态分配。

同样，我们在本章节中将车载云定义为具有嵌入式资源（如存储、计算和物理资源）的车辆组。这些车辆通过彼此之间以及与外部基础设施的通信，共享并动态调度其资源。此类云可根据资源可用性和应用程序对服务质量的需求动态调整 [39]。

分析最重要的先前研究[1, 7, 39],，我们观察到这些研究通常提出架构以创建和管理车辆云。这些研究中的大多数将架构结构划分为三个主要层次：车载、通信和云。图6.1展示了一个通用车联网云架构的抽象，该抽象基于这些先前的研究对主要部分进行了概括。

第一层——车载层——负责抽象化车辆所包含的嵌入式传感器、全球定位系统、摄像头、雷达及其他设备的信息。收集的信息可以被发送到云中进行存储，或作为应用层中多种服务的输入。因此，该层不仅能够促进对环境的感知，还能促进对车辆内乘客和驾驶员行为的感知。

第二层——通信层——确保了位于其下方的车载层与位于其上方的云层之间的连接。为实现这一点，车辆配备了使用无线通信协议（如802.11p、3G和4G）的设备。这些设备使得该层可分为两部分：车辆与车辆之间的通信，即车对车（V2V）通信，以及车辆与外部基础设施之间的通信，即车对基础设施（V2I）通信。V2V通信涉及处于相同通信范围内的车辆，因此信息可以通过车辆逐级传播，直至到达云层（如果存在）

车辆感知到道路上的显著事件。车到基础设施通信包括车辆、基础设施和云之间的信息交换。外部基础设施可以是路侧单元、蜂窝天线或道路旁任何能够实现与云通信连接的结构。

第三层——云层——负责资源的聚合，并向用户以及其他应用程序、服务和系统提供应用程序和服务。该层分为三个子层：实时应用程序、主要服务和基础设施。应用程序子层能够提供满足实时约束的服务和应用程序，并支持诸如信息即服务（IaaS）、协作即服务（CaaS）以及娱乐即服务（EaaS）等核心云服务。而云平台和云基础设施则作为传统移动云计算系统的基础。云基础设施包含存储组件和计算组件。存储组件与应用程序协同工作，根据应用需求存储从车辆收集的数据。计算组件负责托管和处理指定的计算任务。

一些作者，例如[4, 17, 24],，提出了基于底层网络元素的车载云架构。一个通用的车载云可以由数据中心（中心云）、云微粒和底层车载网络组成。图6.2展示了车载云的通用元素。

在此架构中，数据中心提供由传统云（如Microsoft Azure和 Amazon EC2）提供的多种服务。这些数据中心依赖于传统有线网络进行互联，并向用户（车辆）提供服务和资源。在这种情况下，车辆通过路侧单元或任何其他外部基础设施连接到数据中心。这些路侧单元可以具备计算功能，以协助数据中心进行资源的管理和发现。因此，路侧单元作为车载云之间的代理，用于在不同云之间共享和管理资源与服务[1]。路侧单元中的这些计算资源组被称为云微粒，其由一组配备可用资源的车辆组成，这些车辆可通过混合通信方式相互共享资源[17]。

车载云对应于该架构的另一端，通过车辆之间的通信协作与协调而形成。因此，车载云创建了一种基础设施，可向数据中心、云微粒及其他车辆提供资源。因此，如果有路侧单元或任何其他外部连接可用，车载云自身必须能够实现资源的发现与管理，像数据中心一样提供资源。否则，车辆将构建一种基础设施，以满足车载环境中用户对资源发现与管理的需求。

6.2.1 云形成和服务

车载云可以通过地理上共址的停放在停放位置的一组车辆的计算资源整合而成[30]。因此，将停放在商场、机场或私人停车场的车辆进行分组，可通过聚合其资源形成一个云。这种云的形成方式类似于传统云，后者由位于数据中心内地理上共址的物理主机中的虚拟化资源构成[32]。车载云也可以是绑定到岸基基础设施的传统云，该基础设施提供对互联网的访问，从而实现对车载网络的服务接入及相关信息的抽象。然而，纯车载云是通过车辆之间的相互通信建立的。此类云不仅需要应对车载网络的独特特性，还需应对移动云在训练和资源管理方面的限制，例如主机之间的资源迁移。

与传统云类似，车辆云（VCs）也提供传统云通常提供的服务，例如通过聚合嵌入车辆的设备并利用常规云来增强其计算能力，从而提供计算服务。网络作为一种服务，使车辆云能够向用户提供网络资源，如带宽和互联网接入。存储即服务则提供信息存储机制。然而，在涉及存储时，必须考虑哪些车辆的信息将被存储，例如某车辆在停车场停留了多长时间。为了克服这些限制，使用P2P应用程序可以实现相同数据的多个副本存储

许多汽车上的文件块。此外，由于车辆之间的传输时间较短，这些区块的大小可以很小，便于共享。

除了传统服务外，还开发了新的云服务，例如感知即服务（SenaaS），该服务将其组件（包括车载传感器和设备）用于车辆监控应用，如称为传感器云服务的云计算能力。Zingirian和Valenti [46]提出了这项服务，它利用车辆中嵌入的传感器以及车辆间的通信来感知城市道路。

SenaaS可用于协助智慧城市进行道路感知和监控。除了此项服务外，智慧城市还可以利用其他服务，通过传播交通状况信息或城市及街道上可能发生的事等信息，来协助城市交通管理。该帮助台对应于：

协作即服务（CaaS） ：车载网络提供多种新服务，如驾驶安全、交通信息、交通拥堵和交通警报、天气或交通状况、停车位可用性以及广告。为了传播此类信息，需要通过数据分发机制收集数据以供这些服务使用。为此，不仅需要在车辆之间建立连接性，还需要在车辆与岸基基础设施之间建立连接性，采用混合通信方式来发现和分发云所提供的服务。这种通信方式涉及更密集的网络，覆盖由于某些事件导致汽车数量众多的区域。因此，网络面临巨大的数据流量，从而引发传输拥塞。一种合适的中继节点选择机制可能为该问题提供解决方案。仅由选定的车辆或基础设施重传消息；在此方法中，发送消息车辆的覆盖范围作为选择重传器的基础。重传器可位于通信覆盖范围内的区域，或基于发送器与所连接节点之间的更大距离来确定。为了辅助通信，会利用发送器和潜在重传器的节点位置。该位置信息还用于监测邻近事件区域的路线，以检查交通拥堵情况，并通过监测与解释事件区域及邻近区域的数据，提出替代路线方案。

基础设施即服务（INaaS） ：云应提供服务，以采集与交通状况以及道路上发生的事件（如事故）相关的车辆信息。该采集服务通过传播有关某些事件的数据以及建立车辆之间连接的消息来实现。该服务从移动设备接收信息，以获取特定区域的更多数据，从而对正在发生的情况做出更准确的推断。云拥有来自附近区域的事件地理数据，可用于对数据进行分析和解释。这种数据分析和解释采用数学方法，用于计算拥堵情况、预测个人出行情况、估算绕行拥堵的替代路线，并估算下一事件所需的计算需求

需要。在对涉及交通灯重新编程的资源分配进行解释后，将分配计算资源，以便下一个事件及该事件附近的区域能够满足信息需求。

由所述服务开发的应用程序的详细信息可参见第7章，该章节描述了智能交通系统（ITS）使用的主要应用程序以及这些应用程序所涉及的挑战。然而，需要注意的是，车载云（VC）中的一个重要研究挑战是确定车载云支持大数据应用的条件。显然，对于具有严格数据处理要求的大数据应用而言，难以由短暂的车载云支持，因为在这些车载云中车辆的驻留时间太短，无法支持虚拟机（VM）的设置和迁移。最近，弗洛林等人[12]确定了在停车场车辆基础上构建的数据中心有效支持大数据应用的充分条件。这项研究首次代表了研究人员对车载云概念的可行性及其支持大数据应用能力的评估。[12]的主要研究发现是，如果车辆的驻留时间足够长，并且互连结构具备足够的带宽，则车载云可以有效地支持大数据应用。尽管取得了这一成果，但仍需开展大量研究，以深入了解车载云如何以合理的方式支持数据和处理密集型应用。

6.2.2 虚拟机迁移

为了向物理资源提供更大的灵活性和可扩展性，云采用虚拟机（VM），使用户能够使用可执行其进程的环境，而无需重新占用相关的物理资源 [33]。因此，服务器被划分为多个虚拟机，用户被分配到这些虚拟机，从而可以完全隔离地使用其他机器的物理环境 [32]。虚拟机的管理通过管理程序实现，管理程序在虚拟层面上实现了虚拟机之间的隔离。尽管虚拟机位于同一台机器上，管理程序仍会根据使用情况分别为每个虚拟机分配资源。

在云中执行服务期间，为特定用户分配的虚拟机可以在物理主机之间进行迁移，以实现能效、增强利用率和热点缓解等多个目的[40]。因此，虚拟化资源允许将逻辑资源（虚拟机）从一台机器迁移到另一台机器。虚拟机从一个物理位置移动到另一个物理位置的过程相对简单，并且可能是无缝的 [33]。许多研究探讨了在可运行云环境中处理虚拟机迁移所遇到问题的挑战与解决方案。可靠性和效率是处理虚拟机迁移时的重要方面[2]。在文献中，可以找到大量研究提出了针对传统云局限性和挑战的解决方案[8]。然而，车载云带来了新的挑战和限制，导致传统云技术难以直接适用。

在车载云中表现不同。两者之间的区别之一在于虚拟机迁移的初始化，在传统云中，迁移可由热点预防、负载均衡和维护触发。由于车载网络的特性，资源的移动性和普遍性是车辆云固有的主要方面。因此，由于物理服务器（通常是联网车辆）的移动性，车载云数据中心是一个更加动态的环境。此外，由于车辆的高移动性，车载云数据中心网络的拓扑结构变化更为迅速。

Refaat 等人[33]提出了三种称为车载虚拟机迁移（VVMM）的车载虚拟机迁移机制。这些机制旨在通过移动数据中心拓扑和主机异构性提高迁移效率，同时最大限度地减少路侧单元干预。第一个提出的模型 VVMM‐U 在车辆离开 RSU 覆盖范围前短时间内进行虚拟机迁移，并以均匀方式选择目标节点。第二个模型 VVMM‐LW 旨在将虚拟机迁移到工作负载最轻的车辆上。最后，VVMM‐MA 模型结合了移动感知，将虚拟机迁移到具有最轻工作负载且预计停留在车载云地理边界内的车辆上。结果表明，最后一个模型 VVMM‐MA 显著减少了迁移失败，并提高了车载云系统中车辆容量利用率的公平性。

余等人[42]提出了高效的虚拟机实时迁移机制来应对该问题。具体而言，设计了选择性脏页传输策略以提高虚拟机实时迁移中的数据传输效率。此外，作者还提出了一种最优资源预留方案，以确保目标云站点具有充足的物理资源，从而显著减少迁移丢弃。在作者所采用的范式中，车辆可访问三种类型的云站点以获取服务：车载云、路侧云和中心云。由于车辆移动性，云服务必须从一个云迁移到另一个云，以维持正在进行的服务。该机制减少了迁移丢弃，降低了丢弃率。

车载云中虚拟机迁移的主要挑战之一与网络开销以及资源的搜索与管理有关[5]。因此，虚拟机迁移方法不仅必须考虑车辆移动性问题，还必须考虑这些车辆可用于虚拟机创建的资源数量。此外，迁移必须对网络产生显著影响，以确保迁移开销不会影响云所提供的服务和资源的使用。

6.2.3 车辆云中的任务分配

由于车辆意外地加入和离开车载云，导致计算资源的动态变化可用性，从而形成不稳定的计算环境，在此环境中将用户到达任务分配给车辆的任务极具挑战性。

要理解这一挑战，假设一项作业刚刚被分配给当前位于车载云（VC）中的 一辆车辆。如果该车辆在作业完成前一直留在车载云中，则一切正常。但当车辆在作业完成前离开车载云时，问题就出现了。在这种情况下，除非采取特殊的预防措施，否则工作将丢失，必须在另一辆车辆上重新启动该作业，并不断尝试，直到作业最终完成。一旦车辆提前离开导致其全部工作丢失，这种情况必须得到缓解。一种可能的方法是使用检查点（checkpointing），这是一种最初在数据库中提出的策略。该策略要求定期备份作业状态，并将其存储在独立的位置。当车辆在作业完成前离开车载云时，可以在新车辆上利用最后一次备份重启该作业。另外，也可以通过采用各种冗余作业分配策略来提高可靠性和可用性，这在传统云和其他分布式系统中十分常见。事实上，车辆云（Vcs）中资源的波动性表明，应采用这样的任务分配策略：将每个作业分配给车载云中的两辆或更多车辆，并由它们同时执行。

文献中的一些研究采用了这种机制。例如，加齐扎德等人[15]研究了车载云中的基于冗余的任务分配策略，并推导出相应的平均故障时间MTTF的解析表达式。类似地，弗洛林等人[11]研究了军事车载云(MVCs)中的可靠性问题，这是一种适用于战术应用需求的车载云形式。这些研究描述了如何通过一系列基于冗余的任务分配策略来增强此类车载云的系统可靠性与可用性，以减轻计算资源波动的影响。这些调度策略展示了在车载云中作业分配时MTTF的效率。

车载云的另一个重要问题是作业完成时间，这是车辆云的基本服务质量属性之一。在所有现有的相关研究中，一些方法试图估算作业完成时间[13, 16, 21, 44]。在这些研究中，值得一提的是弗洛林等人[13],的研究，他们提出了一种分析模型，用于在假设采用冗余任务分配策略的情况下估算车载云中的作业完成时间。

由于车载网络以及人类行为特征的影响，车辆中资源时间分配以及工作执行时间的估计已成为车载云性能的一个日益重要的因素，从而通过提高资源可用性来满足云用户的需求。

6.3 车联网中的资源管理

云载体中的资源管理必须考虑一系列因素。这些因素至关重要，包括效率、服务质量（QoS）和正确性。（1）效率指的是资源分配策略应优化资源利用率，使资源被充分利用。（2）服务质量涉及所分配的资源必须足以满足服务质量要求。（3）正确性表示资源必须具有相同的执行可能性和时间。

本章节对车载云中的资源管理进行了全面研究，其中相关研究工作分为两类：由（1）基础设施或（2）车辆进行的资源管理。第一类指资源管理直接与云的静态结构相关联的研究，即资源的处理与管理由云（数据中心）和云微粒（由路侧单元提供的计算资源）共同完成。第二类则与本研究的重点相关，即资源的管理和处理仅由车辆执行，外部设备（如路侧单元）的介入程度最小。换句话说，资源管理仅利用路侧单元结构所提供的部分功能，例如信号强度。

6.3.1 基础设施的资源管理

基于车载云的基础设施中的资源管理需要处理资源分配，这通常通过创建虚拟机来实现。此外，资源管理引擎必须允许路侧单元（云微粒）之间的数据传输，并避免由于无法满足服务质量要求或高车辆移动性而导致的资源故障。另一个需要考虑的方面是对资源的分析，这决定了请求被满足的顺序。图 6.3描述了由车载云基础设施执行的资源管理的抽象结构。

从图中所示的场景来看，车辆1首先向数据中心（中心云）和云微粒请求云服务。因此，在数据中心和云微粒中预留了虚拟机。一旦该中心云提供资源，运行在云微粒中的虚拟机就会向车辆1发送消息，使其驾驶员能够使用请求的资源。当车辆1沿道路行驶并进入云点2的覆盖范围时，存在于云点1中的虚拟机必须迁移到云点2。因此，请求的资源将一直保持活动状态，直到不再需要为止。

6.3.1.1 整数线性规划

在车辆云中用于管理资源的技术之一是整数线性规划（ILP），它是一种数学优化方法，其中部分或全部变量必须为整数。ILP旨在高效分配有限资源以实现特定目标，通常为最大化收益或最小化成本[10]。因此，该目标通过一个称为目标函数的线性函数来表达。此外，还需明确哪些活动消耗资源以及资源的消耗比例。此信息被呈现

以线性方程的形式表示，每种资源对应一个方程。这些方程和不等式的集合称为模型约束在。各种活动之间分配稀缺资源通常有多种方式，只要这些分配符合给定模型的约束条件即可。然而，研究的重点是目标函数，关注利润最大化或成本最小化。该解决方案称为最优解。因此，一旦线性模型被定义，并明确了目标函数和线性约束，就可以使用线性规划来找到问题的最优解。

在车载云中，使用整数线性规划来最小化资源管理操作成本，从而减少将虚拟机从一个云迁移到另一个云或从一个网络元素迁移到另一个网络元素的需求。为此，该策略利用车载网络中的网络参数（如开销、带宽和虚拟机大小）以及其他元素作为约束模型。我们描述了一项采用此策略在车辆云中进行资源管理的研究。

例如，考虑一个能够处理服务请求的车载云，其容量为T。该车载云提供交通管理、事件告警或两者结合的服务。此车载云可用于处理这些服务的可用处理资源Rp和存储资源Rs是有限的。根据请求是交通管理(Rp1, Rs1)还是事件告警(Rp2,Rs2)，这些资源可以以不同的数量进行分配。假设处理资源的分配对系统产生的成本为Cp，存储资源分配的成本为Cs。因此，如果我们假设车辆发出了交通管理（tm）或事件告警（ea）的服务请求，则理想的服务请求数量

ser系统提供的服务可以被描述为一个线性规划问题 :

Minimize: Cp ∗ tm+ Cs ∗ ea (This is the objective function) Subject to: tm+ ea ≤ T (Total limit of requests met)
Rp1 ∗ tm+ Rp2 ∗ ea<= Rp (Processing resource limit)
Rs1 ∗ tm+ Rs2 ∗ ea<= Rs (Storage resource limit) tm ≥ 0 and ea ≥ 0 (Vehicles request services)
(6.1)

接下来，我们将介绍一些使用该策略在车载云中进行资源管理的研究。

[34]中描述的研究提出了一种基于整数线性规划的云资源管理（CRM）方法，旨在最小化重新配置开销。CRM的目标是减少基础设施延迟和服务复制。该整数线性规划模型通过联合最小化重新配置开销、虚拟机迁移、控制平面修改、服务主机数量以及云基础设施延迟来实现目标。为达到此目的，作者使用权重来控制重新配置开销的优先级，使得最小化虚拟机迁移的优先级高于控制平面修改。此外，整数线性规划模型还考虑了系统中消息之间的延迟以及网络带宽，以实现均衡的网络负载，并最小化服务主机数量和基础设施。

6.3.1.2 半马尔可夫决策过程

马尔可夫决策过程（MDPs）[6]旨在对结果部分随机且部分受决策者控制的情境中的决策进行建模。MDPs提供了一种数学框架，用于建模状态之间转移具有概率性的过程；可以观察到该过程所处的状态，并且可以通过执行动作在决策时刻周期性地干预该过程[31]。每个动作都会带来奖励或成本，具体取决于过程的状态。或者，奖励也可以仅由状态决定，而不依赖于所执行的动作。这类过程被称为马尔可夫或马尔可夫型，因为所建模的过程遵循马尔可夫性质：一个动作对状态的影响仅取决于该动作和系统的当前状态，而与过程如何到达该状态无关。决策过程这一术语源于模型中存在一个智能体或决策者，其通过周期性地执行动作来干预系统，这与马尔可夫链不同，在马尔可夫链中并不涉及如何干预过程的问题。

因此，马尔可夫决策过程（MDP）被定义为一个元组 (S, A, T, R)，其中
• S是一个状态集合，表示该过程可能处于的状态；
• A是一组可在不同决策周期内执行的动作；
• T：SXAXS →[0, 1]是一个函数，用于给出系统将转移到某一状态 s ′ εS 的概率。该函数假设过程之前处于状态 sεS，且智能体决定采取行动 aεA（记为 T(s ′|s,a)）；
• R: SXA → R 是一个函数，用于表示当过程处于状态 sεS 时，做出决策 aεA 所产生的成本（或奖励）。

为了说明马尔可夫决策过程的应用，我们假设车载云可以提供一个包含 R单位资源的资源池，以支持K类服务。此外，服务类别i, i ε{1,2,…, K}需要bi资源来满足其服务需求。此外，新请求到达的时间被建模为速率为λn的泊松过程。

因此，系统状态可以通过车载云中的资源占用情况来描述。因此，状态空间可以表示如下：
S={s|s=(n, e)}, e ε E={Req, Ter} (6.2)
其中n定义为
n={n1, n2,…, ni}, (6.3)
并且ni表示在车载云中请求服务类别i的车辆数量。同样，本地云中已分配资源的总和为∑K k=1 bk ∗nk ≤ R。e表示系统中发生的事件，事件集E描述如下：
•新请求到达表示一个新请求的到达，
•请求服务终止 表示来自云的k类请求的服务终止。

在马尔可夫决策过程（MDP）环境中，云需要在已知的时间间隔后根据其动作空间做出决策。因此，在每个决策时刻，云从动作空间a和As中选择一个行动，其定义如下：
As={{ −1}, e = Req
{0, 1, 2,…, K}, e= Req (6.4)
a= −1表示控制器不需要做出决策，而是更新系统中的资源消耗。a= 0表示控制器拒绝了类别为k的服务请求。a= k表示请求被接受，并且系统中已分配类别为k的服务。

在行动a下，从状态s到状态s′的转移概率由p(s′|s, a)定义
p(s ′|s, a)={ λ n
ϕ(s ′,a) e′= Req
μ k n k
ϕ(s
′
,a) e′= T erk (6.5)
其中 ϕ(s, a)= γ(s, a) −1。 γ(s, a) 表示直到下一个决策时刻的期望时间，可由下式给出
γ(s, a)= 1
λn+∑ K k μk ∗ nk
(6.6)

给定一个状态 s和一个行动 a，系统奖励定义为
r(s, a)= k(s, a) − g(s, a) (6.7)
其中k(s, a)为采取行动a时系统的一次性收入，g(s,a)为预期系统成本。k(s,a)可定义为
k(s, a)=
⎧ ⎪⎪⎪⎪⎨ ⎪⎪⎪⎪⎩
P e ε Req, a= 0
GReq e ε Req, a= 1… K
GT er e ε T er, a= −1 0 otherwise
(6.8)
P表示由于拒绝服务或车辆离开云而导致的系统惩罚。在Pr中，已提出请求以拒绝仍在云池中的车辆资源，但系统因云间消息交换而受到惩罚。因此，P定义为P−∑K k=1bk，其中P是系统惩罚。GReq表示接受新请求或迁移请求所带来的系统收入。GReq定义为G − bk，其中G是云使用车辆共享资源所带来的收入。尽管该车辆的资源增加了本地云的资源池，但该车辆占用了云中可用的bk资源。GT er表示服务终止（一个请求）或由迁移请求带来的系统收入。GReq定义为G+ bk。预期系统成本g(s,a)定义为
g(s, a)= c(s, a)γ(s, a) (6.9)
其中 c(s,a) 是系统的成本率，可以通过动态VC中的资源分配数量来表征；因此，它表示为
c(s, a)=
K
∑
k=1 bk ∗ nk (6.10)

因此，该建模旨在控制系统中服务请求的接受或拒绝，以寻求最大化云中这些资源的利用。在文献中，已提出一些模型，不仅考虑了服务，还考虑了车辆进出车载云的特征。接下来，我们描述一些采用此策略在车辆云中进行资源管理的研究。

在[45],中提出了一种最大化车载云奖励的资源分配方案。该方法基于无限时域半马尔可夫过程，通过四个阶段来构建资源分配问题。（1）状态空间表示车载云中的当前资源和请求状态。（2）动作空间是车载云根据其当前状态可采用的动作集合。（3）奖励由收入和成本组成，可用于应用折扣模型，计算并分析奖励总和。（4）转移概率计算在特定动作下系统状态从一个状态转移到另一个状态的概率。该方法使用迭代算法求解优化问题，目标是最大化车载云的长期期望总奖励。

在[27]中提出了一种最优方法，旨在最大化所提出方案的奖励并改善车辆的体验质量。作者构建了一个半马尔可夫决策过程（SMDP）以优化决策过程，从而获得最优方案。在这种最优方法中，奖励通过事件平均速率计算得出。该SMDP采用一致化方法，对离散时间模型的公式进行修改。此方法还使用了迭代算法。为最大化平均奖励，其基于[45]中定义的模型。然而，作者尝试提升处理能力以节省更多能量，如[45]所示。

6.3.1.3 博弈论

博弈论是一种数学策略，旨在对两个或更多决策者相互交互时可观察到的现象进行建模。该方案适用于一个智能体或参与者的决策依赖或影响其他参与者的选择的情况。

因此，一个博弈由一组参与者组成，表示为 G= g1, g2,…, gn。每位参与者 gi都具有一个有限的选项集合 Si，称为该参与者的策略。我们用 S表示所有策略组合的集合，其定义如下：
S=
n
∏
i=1
Si= S1XS2X… XSn (6.11)
每个元素sεS表示一个博弈结果，也称为博弈的策略向量或策略组合。

此外，每位参与者必须具有一个偏好顺序，该顺序必须是针对博弈可能结果的完备、传递、自反和二元关系。这种关系表明参与者倾向于改变其策略，从而导致博弈结果从一个策略向量变为另一个策略向量。一种简单的表示方法是为每位参与者i定义一个效用函数或收益ui: S → R，该函数对每个策略向量返回一个数值。因此，如果参与者i改变其策略，从策略向量s转移到向量s′，这一行动的发生仅因为u i( s′ )> u i( s)。

当参与者达到每个参与者都不愿意改变其策略的结果时，就实现了稳定结果。我们称表示这种结果的策略向量为策略中的纳什均衡。

为了说明该策略的工作原理，考虑一个车载云（VC），其中用户请求了两项服务（参与者）。这些服务可以被尝试或阻塞。如果两项服务都被尝试，则每项服务的成本为4。如果只有一项服务（A）被尝试，而另一项（B）被阻塞，则服务A的成本为1，另一项成本为5。同样地，如果B被尝试而A被阻塞，则B的成本为1，而A的成本为5。如果两者都被阻塞，则成本为2。

一个包含两个参与者的集合G= A,B中，每个参与者具有以下策略集：
SA=尝试,阻塞 SB=尝试, 阻塞 uA(尝试,尝试) = 4,uA(尝试, 阻塞) = 1, uA(阻塞,尝试) = 5,uA(阻塞, 阻塞) = 2, uB(尝试, 尝试) = 4, uB(尝试, 阻塞) = 1, uB(阻塞, 尝试) = 5, uB(阻塞, 阻塞) = 2

因此，在这个例子中，当两个状态均为尝试时的结果是一个纳什均衡，因为在在此结果下，任何一方单独改变其选择都无法最小化系统成本。

[43]中的研究提出了一种基于双边匹配理论的资源管理和空闲资源协作共享机制。该方法分为两个步骤：首先，云服务提供商分析其收益，并验证是单独运营还是加入云市场；然后，服务提供者从其他服务提供者处租赁或租用资源。该方法必须考虑若干选项：（1）当服务提供者的效用更优时，可以参与联盟；（2）服务提供者可以更换联盟以提升其效用，即服务提供者可以离开联盟A并加入联盟B；（3）无论是否能提高效用，服务提供者更倾向于独立工作。在该方法中，作者采用帕累托最优来指导服务提供者的行动，确保其效用能够增加或至少不会减少。帕累托最优集合在每一轮中逐步收敛。

在另一项研究[41],中提出了一种用于车载网络的云架构；该架构分为三层：（1）车载云，（2）路侧云，和（3）中心云。该方法旨在整合智能交通系统基础设施中的冗余物理资源。为此，作者采用博弈论方法以最大化分配的云资源。

为了说明该理论的应用，考虑云微粒中一组可用的虚拟机，其目标是获取尽可能多的资源。虚拟机根据请求的资源数量进行分配。在这种情况下，

云为每个虚拟机设置两个虚拟资源计数器（VRCs）。由于VRCs已达到其最大阈值，虚拟机无法分配不同类型的资源。因此，所有虚拟机的已分配资源总量相同。

在[37]中提出了一种针对城市场景的非合作云资源分配方案，该方案采用高斯‐赛德尔（G‐S）迭代法，可减少纳什均衡点（NEP）的计算时间。该研究进一步考虑了节点的加入和离开过程。因此，基于G‐S迭代法对非合作云资源分配博弈进行了分析。通过建立精度控制模型以优化流量的迭代过程。为此，该方法利用博弈论对车辆节点的传输行为进行建模，即云资源分配博弈。同时，采用云路侧单元（RSUs）来延长车辆节点与数据服务器之间的通信时间，足以使自私车辆完成云资源分配博弈的均衡计算，并以计算所得的传输速率访问数据。在云资源分配博弈中，每个车辆节点都试图最小化其成本或最大化其效用。该方法可通过G‐S迭代法在车辆之间进行云资源分配。G‐S迭代法通常用于求解一阶偏微分方程，可用于计算节点的最优效用和流量速率。为应对车载网络中资源分配的收敛问题，采用了G‐S迭代法的收敛性方法。

6.3.1.4 通信层

一些策略仅处理来自计算机网络中已建立协议的信息。其他方法则专注于捕获来自延迟、抖动和丢包的信息。某些策略旨在分析来自TCP以及网络层路由表的信息。利用这些信息，一些研究建立了数学模型来管理信息流和用户请求的服务。通过这些模型，它们能够操纵和管理云中的可用资源，以向用户提供服务。

实现资源操控的另一种方式是通过网络中已知的策略，例如在认知网络中所采用的策略。根据[38],中提出的定义，认知网络是一种具备认知能力的网络，能够感知网络的当前状态，并据此进行规划、决策并采取行动。该网络可以从这些适应中学习，并利用这些信息在考虑端到端传输目标的同时做出未来决策。与认知网络类似，认知无线电提供了以机会主义方式使用或共享频谱的能力。

一些研究不仅利用无线电信息，还利用其他协议的信息来进行资源管理。接下来，我们将介绍一些采用此策略的研究。

在[35]中提出了一种用于网络化雾计算中心（NetFCs）的资源调度器。NetFCs确保满足服务质量要求，同时力求实现最小/最大速率抖动、处理延迟和抖动率。该方法采用基础设施到车辆策略在车载网络中进行通信：车辆通过基于TCP/IP的单跳移动链路与基础设施通信。该方法的目标是在满足严格的服务质量要求（如严格边界）的前提下，最小化整个基于TCP/IP的雾计算平台所浪费的平均通信加计算能耗。节能调度联合执行以下功能：（1）输入流量管理；（2）对准入流量进行最小能耗调度；（3）设置并维护所托管虚拟机的配置；（4）对注入TCP/IP移动连接的流量进行自适应控制。此外，NetFCs通过管理待处理输入流量的随机且可能不可预测的波动以及所用TCP/IP连接的状态，对输入和输出流量进行自适应控制。该方法还考虑了每个虚拟机任务规模和处理速率的自适应重构，以及雾内每条链路通信速率的自适应重构。

本文提出了一种面向车载网络的基于认知无线电（CR）和软输入/软输出数据融合的自适应资源管理控制器[9]。在此方法中，最优控制器以分布式可扩展方式动态管理服务RSU处的接入时间窗口以及被服务车载云处的接入速率和流量。此外，该方法为通过无线通信骨干网传输的主业务流提供了严格的可靠性保证。为了以完全分布式和可扩展

第6章 车联云

6.3 车联网中的资源管理

的方式支持车载云对服务 RSU的基于认知无线电的接入，该方法采用了与簇内接入协议同步的帧格式，因此设计并采用了簇内接入协议。该方法包含七个阶段：（1）信道估计，（2）传播，（3）感知，（4）数据融合，（5）客户端调度，（6）客户端上传，（7）确认。此外，时隙被划分为非重叠微时隙。

6.3.1.5 讨论与遇到的挑战

为了总结现有研究的特征，编制了一个表格来描述这些研究所涉及的方面。该表格考虑了用于界定这些研究的最重要方面：资源分配、RSU之间的资源迁移以及资源调度。表6.1还描述了研究中使用的概率机制。

此类资源管理的一个问题是资源分配和迁移机制所需收敛的复杂性和时间。这两个方面对速度和效率施加了硬约束，以确保机制不受车辆移动性速度的影响，并且计算资源不会被浪费。当加入资源调度器后，这种复杂性进一步增加，导致资源可用性所需的时间延长。另一个重要问题是计算所需的高计算负载

表6.1 基于基础设施的资源管理器相关研究 分配资源资源
Work 资源调度迁移概率方法
Salahuddin et al.[34] √ √ ILP
Zheng et al.[45] √ √ SMDP贝尔曼方程
Meng 等人 [27] √ √ SMDP贝尔曼方程
Yu 等人[43] √ √ 博弈论
Yu 等人[41] √ √ √ 博弈论
Tao 等人[37] √ √ 博弈论
Shojafar 等人[35] √ √ √ 自有方法
Cordeschi 等人[9] √ √ 接入速率分配， 联合时间流 分配 ,和网络范围 优化

优化。这种高计算负载可能会影响单元的功耗，从而需要更高效的冷却机制。

尽管一些研究解决了受基础设施影响的车载云中资源管理问题，但由于分配机制、调度和资源迁移的复杂性，集成管理三个基本方面的挑战仍然存在。因此，需要一种有效的结构来包含这三种机制：一种能够快速分配资源并满足请求质量所需资源要求的解决方案。这可以最小化或促进路侧单元之间的资源迁移，使迁移能够快速发生而不会造成资源利用率损失，并在不丢失请求的情况下实现公平分配。

另一个需要考虑的问题是对时间和计算消耗的精确评估。为了高效处理分配的任务，必须采用优化技术来解决资源管理中的相关问题。

6.3.2 基于车辆的资源管理

由于基于基础设施的现有资源管理器依赖于资源分配的各个方面，因此在通过车辆间通信进行的资源管理中，还必须考虑路侧单元之间的资源传输和调度。因此，在过境车辆之间建立通信的方式是此类管理中的一个关键要素。图6.4展示了车辆进行资源管理的运作过程。

例如，假设车辆1需要从另一辆云车辆获取一些可用资源，因此它首先会发送对该资源的请求，并需要持续向特定的资源云发送请求，直到收到回复为止。

这种消息传递可以是一种数据传播机制或聚类机制。当另一辆车辆接收到请求，并且请求的资源变为空闲时，它将创建并保留一个虚拟机；然后将这些虚拟资源分配给请求者，并开始向车辆1发送消息。正如我们在接下来描述的研究中所看到的，数据传播机制或聚类机制被用于此类管理形式的创建和维护。

6.3.2.1 贝叶斯联盟博弈

联盟博弈是博弈论的一个类别，其中一组参与者被要求表现出合作行为，从而将博弈转变为群体之间的竞争，而非个体之间的竞争，如第6.3.1.3节所述。

联盟博弈由一个有限的参与者集合G（称为大联盟）和一个特征函数v： 2N → R 组成，该函数将联盟集合映射到奖励集合。该函数描述了参与者集合在形成联盟后能够累积的收益。这种博弈被称为值博弈或收益博弈。因此，参与者必须根据他们对联盟成员间奖励分配方式的预期来选择要形成的联盟。

因此，联盟博弈可以被视为对智能体组内收益分配的研究 [18]。

类似地，合作博弈可以定义为一个满足v: 2N → R 和 v(0)= 0 的特征成本函数。在这种情况下，参与者必须完成某项任务，该函数表示参与者集合共同执行任务所需的成本。这种类型的博弈称为成本博弈。

该技术可用于计算迁移虚拟机时云的成本，其中包含多个需要分析的参数，例如开销、虚拟机大小以及所需的带宽。

一项采用此类策略的[19]是。在这项[19]中，提出了一种名为基于学习自动机的争用感知数据转发（LACADF）的{算法}。该{算法}将可靠数据转发问题作为贝叶斯联盟处理

基于学习自动机概念的博弈（BCG）。LACADF假设车辆为参与者，每辆车辆分析其他车辆的博弈行为，从而确定应执行的移动动作。在博弈开始时，每辆车辆都有一个收益值，该值会根据车辆的动作而增加或减少。这些动作会根据其动作概率向量的更新情况，使车辆获得奖励或受到惩罚。经过若干次迭代后，所提出的方法基于贝叶斯定理分析的不同不相交集合来选择动作。所有这些动作均由一个自动机过程执行，若解收敛，则该过程可产生最优推断结果。

6.3.2.2 半马尔可夫决策过程

当没有中心节点来控制云服务时，也可以使用马尔可夫决策过程（MDP）。该马尔可夫决策过程可以建模为不仅考虑所管理资源的特定参数，还考虑车载网络的所有特性，例如高移动性、高度动态拓扑结构以及车辆之间的低连接时间。目前很少有研究通过马尔可夫决策过程实现这种调控。接下来，我们将介绍一项研究，该研究在车辆进入和离开车载云时，不仅考虑了请求的服务质量要求，还考虑了车辆移动性。

在[26]中提出了一种最优资源分配方案，以最大化可用资源的利用率。针对最大化系统期望平均奖励问题的最优解被建模为一个半马尔可夫决策过程（SMDP）。该SMDP问题通过一种迭代算法求解。作者考虑了一个由具有可共享资源的车辆组成的动态VC，这些资源可与车载网络共享。该云通过一组车辆形成，并被组织成一个簇。该簇根据[25],中定义的策略进行构建和维护，该策略认为分配请求由控制器管理。

6.3.2.3 讨论与挑战

这种管理模式的一个问题涉及在不因繁重计算而使车辆过载的情况下进行资源分配，其核心在于确定车辆使用分配的最佳方式。由于承载网络的特性，已分配资源的管理可能并不简单。例如，如果通过虚拟机（VM）分配资源，则需要足够的计算能力和显著的网络容量来支持虚拟机迁移。车载网络的另一个典型问题是传输时间，例如在网络碎片化存在的情况下。虽然可以采用一些辅助解决方案进行数据传播，但这些方案可能会引入较高的开销和数据包碰撞。聚类可用于防止这种情况。除了减少网络消息数量外，该机制还能更好地分配资源。然而，此类解决方案

表6.2 涉及车辆资源管理的研究
Work 机资制源 资调源度 迁资移源 概率方法
Arkian et al.[3] √ √ √ 模糊与学习方法
Kumar et al.[19] √ 贝叶斯联盟博弈
Sibai 等人[36] √ √ 时空相似性

可能会受到分配时间的限制，因为资源的提供直接依赖于构建簇所需的时间，而这一时间较长。

表6.2列出了所述研究中使用的特性与机制的总结。

由于车载网络资源管理的特性，必须解决车速、移动性和传输时间的问题。因此，必须开发一种高效资源分配机制，以便在车辆之间短通信时间内快速完成资源分配。此外，由于车辆资源有限，已分配资源的操作必须高效且不给车辆带来计算开销。

用于分配的结构直接影响车辆之间资源迁移的形式。因此，该结构应足够简单，以确保该特性的迁移快速高效，不影响资源的使用，也不会因控制消息而使网络过载。因此，挑战在于通信和信息聚合，以提供车辆之间的快速协作机制，满足请求资源的服务质量要求。

另一个挑战涉及调度机制功能的优化，该机制不仅必须考虑请求执行的需求，还必须考虑车辆的移动性特征。因此，该机制不仅应优化适合特定资源的车辆选择，还应在资源迁移时作为支持工具。

6.4 车载云中的服务发现

在本研究中，资源发现被定义为请求资源并向云控制器接收响应的过程。我们将此过程表述为依赖于资源请求。考虑一辆车辆或一组车辆需要来自车载云的特定资源r，该车载云具有一组可供用户请求的可用资源R。因此，这些用户向负责管理资源请求的车载云组件发送请求。在组件接收到请求后，会验证资源的可用性，然后向用户发送响应。当仅考虑一个车载云时，该组件可以是受控云；当考虑一组或多辆车载云组成的联盟时，该组件可以是代理。

我们考虑一系列通过路侧单元或车辆互连的车载云，当没有外部基础设施可用时，这些车载云可作为替代路径以到达数据中心或云微粒。为此，我们将关于资源发现的研究分为两部分：（1）路侧单元作为资源发现管理者；（2）车辆作为资源发现管理者。由于车载云是一个新兴领域，针对车载云资源发现的研究较少。因此，我们也纳入了与车载云中资源发现相关的技术。

6.4.1 路侧单元作为资源发现管理者

当多个云连接到单个路侧单元时，该路侧单元可作为这些云之间的代理，用于在车载网络中管理和发现资源。因此，当车辆向路侧单元发出服务请求时，它可以检查最适合处理该服务请求的云，并在请求被接受的情况下分配和管理资源。接下来，我们将描述在此背景下解决资源发现的相关研究。

6.4.1.1 数据传播

传播协议旨在快速高效地将相关信息传递给车辆和控制中心。然而，此类传播协议必须应对广播风暴，以避免网络因控制消息或先前已传播的信息而过载。

此类传播协议可用于传播特定资源的搜索信息。由于路侧单元（RSU）对网络的视野比车辆更广，因此可以选择一组车辆来执行资源搜索的传播。通过路侧单元进行控制，可以减少网络中请求消息的数量，因为只有少数车辆传播消息，从而减轻广播风暴。

接下来，我们将介绍一些利用数据传播作为资源搜索机制的解决方案。

在[28]中提出了一种云服务发现协议，该协议利用路侧单元作为云目录来存储有关车载云服务器的信息。因此，该协议形成了此类服务器的分布式动态索引。该协议将云服务器定义为通过路侧单元提供服务或资源的交通服务器（STAR）。此外，所提出的方法包括识别STAR可提供的服务及其属性。路侧单元存储其提供的服务的相关信息，例如每项服务的属性、每资源单位成本以及每项服务的质量。同时，路侧单元会选择最合适的候选STAR以满足用户需求。在此情况下，STAR是一辆协助路侧单元在车载云中管理和发现新资源与服务的车辆。STAR可以提供

在密集网络中，由于它比路侧单元更接近请求者，能够加快与路侧单元和云的通信速度，从而提供更高的服务质量。

提出了一种基于面向服务架构的中间件VsdOSGi，用于直接解决资源发现的问题[23]。该中间件基于OSGi框架，包含四个层次：设备捆绑、服务发现捆绑、DssOSGi捆绑和应用捆绑。VsdOSGi专注于发现最合适且智能的交通应用程序服务。基于服务质量的资源发现算法（SDQ）根据服务需求采用不同的服务质量计算方法，从而为多个请求者提供满足其需求和约束条件的最优服务。为此，该服务发现算法分为四个阶段。（1）将资源开放的车辆向路侧单元的服务目录发送消息，通知该路侧单元可提供服务；（2）车辆向路侧单元的服务目录发送请求，以订阅其服务；（3）路侧单元将订阅的服务与已发布的服务进行匹配，并向服务请求作出响应；（4）车辆接收对其请求的响应，并选择最终的服务提供者来绑定所需服务。

6.4.1.2 聚类

聚类是一种用于对车辆进行分组以促进通信的技术。车辆分组涉及多个准则，例如速度、方向、车辆数量和跟随车辆。在城市中对车辆进行分组的最简单方法是根据车辆所处的定位，将同一街道上相互跟随或在同一街区内的所有车辆划入同一个簇。因此，每条街道都有其对应的簇。另一种常见的分组方式是通过行驶方向，即将某一区域内朝相同方向行驶的邻近车辆划分到同一簇中。

一个簇包含以下元素：
- 集群头，负责管理簇及其资源；
- Gateway，负责促进多个簇之间的通信；
- 成员车辆，指参与特定簇的车辆；
- 未知车辆，指不参与任何簇的车辆。

集群头和网关通过选择过程从属于该簇的车辆中选出。选择完成后，此信息将分发给簇内的所有成员，以便它们了解哪些是网关以及该簇的控制器是谁。

聚类技术被广泛用于在车辆之间建立通信结构，以减少网络中发送的消息数量。簇内的任何请求或通信都首先通过集群头，再由其转发至目标车辆。

以下将介绍一些采用该策略的研究。

提出了一种名为COHORT的车载云（VC），其利用路侧单元（RSU）向车辆提供服务。COHORT还协助路侧单元在车载网络中管理和发现新资源。然而，路侧单元仅对位于其传输范围内的车辆可访问。因此，COHORT采用服务即集群（CaaS）作为云服务，以扩大可用服务的覆盖范围。CaaS通过车辆之间的通信，基于簇理论构建而成。这些簇是动态形成的，其中每个簇中会选出一个成员作为集群头。集群头负责与路侧单元及其他车辆通信，在车辆与路侧单元之间起到通信桥接的作用。集群头负责服务的创建、维护和删除，从而帮助路侧单元在云中实现对车辆服务与资源的管理与发现。

6.4.1.3 讨论与遇到的挑战

当我们考虑将路侧单元作为负责管理和发现新资源的元素时，可以考虑在传统云中使用已知的资源发现解决方案。这是因为云与路侧单元之间的通信可以是有线的，且这些元素不具备移动性。然而，车载云可以利用车辆网络作为资源和服务的提供者。因此，这些解决方案必然需要引入新的方面和组件，以应对车辆的高移动性、车辆与路侧单元之间的连接时间以及车载网络的其他方面。

表6.3 涉及通过路侧单元进行服务发现的研究
Work 主要特征 辅助功能不足之处 服务发现
协议 [28]
车辆云服务器搜索和 服务发现 STAR车辆移动性
COHORT [3]服务提供商选择 集群头复杂性 集群头 选择 VsdOSGi [23]服务发现中间件 – 缺乏服务 发现支持

在云中。然而，为了实现这一点，任何提出的解决方案都必须应对车载网络中存在的所有限制。因此，协议需要聚合车辆提供的资源，并满足车辆所请求服务的需求。

因此，此场景中的一个巨大挑战是创建一种信息存储结构，这种结构不会对计算资源造成高复杂性，因为路侧单元的计算能力可能较低，难以支持此类结构。此外，必须设计简单且动态的机制，以实现资源的聚合、搜索和管理，这些资源需满足数据中心的需求以及车载网络的独特约束。同时，假设这种新的资源发现方法不会因控制消息而导致网络过载。

6.4.2 车辆作为资源发现管理者

考虑一种场景，其中车辆无法与路侧单元或数据中心连接。车辆需要相互协作，以构建能够聚合资源并向其他车辆提供服务的基础设施。在这种场景下，我们考虑两种可能的情况：
- A vehicle is its own cloud。车辆代表一组可被车载网络中其他车辆使用的资源。在这种情况下，每辆车需要通过与其他车载云（VC）互连并传播控制消息来执行资源发现。因此，一辆车（控制云）可以验证自身是否拥有匹配服务请求的资源，或指示其他云（车辆）。
- 一组车辆形成一个云。一组车辆通过相互通信创建一个云。在此组中，选择一辆车辆来控制云中的请求和资源。此外，车辆可以选择一个元素（车辆）作为不同车辆组（车载云）之间的网关，因此这些网关被视为云之间的代理。

6.4.2.1 数据传播

在车载云中搜索资源的最简单方法之一是在车辆之间传播请求。因此，当我们将每辆车视为一个云时，通过在网络中洪泛控制消息成为资源发现的最简单技术。使用该技术，消息会被持续传播，直到到达包含所需资源的云。然而，这种机制会导致网络过载，因为它必然引发广播风暴。另一种策略是利用现有的车载网络数据传播协议。但这些协议大多旨在传播特定城市的道路事故和交通信息。

一些研究，例如[36],采用传统的数据传播协议来解决资源发现。服务提供基于车辆移动性、请求服务的可用性以及其他网络参数而建立。服务提供机制选择能够提供请求资源的车辆。为此，该方案假设车辆分为两类：（1）请求车辆和（2）服务提供车辆。请求车辆在云中请求一个或多个可用服务。请求车辆是车载云的发起者，因此被称为领导者车辆。领导者车辆负责（1）搜索愿意提供服务的候选车辆，（2）发起云，（3）维护云，以及（4）销毁云。

服务提供车辆则向请求车辆提供服务。服务提供者可以是车载网络中的静止或移动车辆。该方法采用时空相似性算法来计算存在请求者/服务提供者关系的两辆车之间的共同通信区间。时空相似性算法的输出结果为通信持续时间，由通信持续时间和限定的通信间隔决定。这些数值用于在车载云中搜索和分配资源，当请求者通过重传机制发送请求消息时实现此过程，该机制旨在解决广播风暴并降低网络开销。

6.4.2.2 发布‐订阅

减少由于分组传播而导致的网络消息数量的一种方法是通过发布‐订阅机制。在这种策略中，一个车辆组在云中发布其提供的一组功能或服务。这种发布方式通过网络广播完成。希望使用这些资源的车辆将订阅以使用或接收有关该服务的信息。随后，通信仅限于发布服务或资源的车辆和订阅该服务的车辆之间，从而减少了在网络上传播的消息数量。

一种新颖的分布式基于位置的服务发现协议（DLSDP）在[22]中被提出。该协议将车辆分为三类：（1）分布式

目录服务车辆、(2) 网关车辆和 (3) 成员车辆。该方法利用兴趣区域来组织资源发现的基础设施。该基础设施基于多生成树结构，生成树的根是领导者，其根据所在兴趣区域使用服务发现功能。基于位置的请求由相应的领导者车辆独立响应，无需依赖服务需求提供者被发现。

6.4.2.3 P2P

P2P 是一种计算机网络架构，其中网络中的每个节点同时充当客户端和服务器，允许在无需中心服务器的情况下共享服务和数据。这种网络通常在网络上的车辆之间创建一个抽象层，以促进通信和资源管理。该架构可以是去中心化或混合式的。去中心化架构不包含用于资源控制的中心节点，所有节点具有相同的权限。在这种架构中，当某个节点需要服务时，它会向其邻居节点广播消息。如果邻居节点包含请求的资源，则向请求者发送响应；否则，邻居节点将请求继续广播给它们的邻居节点。

在混合式结构中，节点可以分为超级节点和普通节点。超级节点是指具有更强处理能力、内存和其他资源的节点。普通节点则由具有与其他所有节点相同容量的节点组成。超级节点拥有一部分可用资源，因此仅管理云中部分可用资源。因此，当一个普通节点需要某个资源时，它会向其连接的超级节点发送请求。超级节点在接收到该信息后，会验证是否能够响应此请求。如果可以，则超级节点向普通节点发送响应；否则，它会检查其他超级节点是否拥有请求的资源。

该技术不仅用于促进车辆间通信，还可创建连接层。此外，该技术还允许在车辆之间进行资源分发，从而实现资源搜索，而不会因控制消息导致网络过载。

接下来，我们将介绍一些利用P2P架构在云中实现资源发现的研究。

基于发布‐订阅模式的车载云架构已被提出，用于处理资源管理与发现 [20]。在此研究中，资源完全通过P2P通信相互连接。因此，关于资源共享的协商直接在车辆之间进行。然而，云中的某一辆车辆可被选为代理，以管理和发现其他车辆（云）之间的资源。在该架构中，云领导者被定义为运行某一应用程序的车辆。该领导者根据此应用程序的需求招募能够提供资源的成员，以生成车载云。在领导者评估了应用程序所需的资源后，它会在搜索范围内向车辆广播资源请求消息。搜索范围由道路路段限定。

一个交叉路口，或预定义距离。愿意共享其资源的车辆会向领导者的请求响应其资源能力在。[25]中定义了一种用于车载云（VC）中资源的搜索与管理的P2P协议。该协议基于Gnutella概念，并引入覆盖网络以协助云中资源的发现与管理。该协议分为两个主要组件：（1）资源管理，负责创建和控制覆盖网络，并协助资源的发现与管理；（2）路由，负责请求和响应消息的传播。所提出的协议将网关视为代理，帮助请求者或控制器在车载云中实现互联。因此，车辆和云控制器通过网关来查找其他云中满足服务需求的资源。资源发现考虑车辆位置、平均速度、消息时延及其他参数，以估计车辆的位置并促进资源的搜索。

6.4.2.4 讨论与遇到的挑战

本章节所述研究中所使用的特性与机制的总结见表6.4。以下将对这些方面进行更详细的描述。

车载云中资源发现面临的主要挑战之一是缺乏能够支持和促进车辆云内可用资源搜索与管理的外部基础设施。集中式方法在一定程度上有所帮助，因为车辆能够快速通信且不会通过大量控制消息造成网络过载。[20, 36]中描述的研究提出了一种满足上述需求的资源发现机制；然而，这些解决方案需要大量消息来应对网络断连，并保持支持结构的稳定。[22, 25]中讨论的研究采用了更高效的通信机制；但这些方法在云的构建与维护方面具有更高的复杂性，因而需要更多的计算迭代。

Table 6.4关于车辆服务发现的研究工作概述 研究 支持技术 传播方法 缺点
MAP 数据传播 广播受限 开销
发布/订阅虚拟通道 架构 [20]
发布‐订阅 广播 开销
DLSDP [22] 生成树 分层的 协议复杂性 点对点
协议 [25]
Gnutella 簇 协议复杂性
数据传播
协议 [36]
数据传播 广播受限 开销

因此，一种理想的用于解决车载云中资源发现的协议必须简单，并尽量减少控制消息的数量。这种设想的协议需要创建一种基础设施，以满足车辆云的需求并克服移动网络的限制。

由于车载网络的特性，在没有外部基础设施的情况下实现资源发现成为车载云中最复杂的挑战。车辆必须自我管理和协调其嵌入式资源，并动态地创建一个聚合其他车辆资源的结构，以提供所需服务。从这一角度来看，车载云可以由单个车辆或一组车辆组成。每辆车都可以构建一个车载云，管理其资源并向邻近车辆提供这些资源。另一方面，车辆也可以协作，共同创建一个以协调方式聚合和管理大量可用资源的结构。

如果我们将车辆视为一个云，资源发现解决方案需要足够简单，以避免发送可能导致车载网络开销的不必要消息。此外，这些解决方案应对车载设备轻量，使其能够在不同时过载本地资源的情况下运行。因此，挑战在于信息的通信聚合，以在车辆之间建立快速协作机制，创建代理服务，从而促进其他云（车辆）之间的资源发现。

另一个挑战涉及创建一种结构，用于聚合不同车辆的可用资源以提供云服务。该结构需要具备足够的动态性，以支持车辆在云中的加入和离开。此外，必须开发简单的选择算法，以确定哪辆车辆将作为集合领导者，以及哪些车辆可以作为网关与其他车辆云通信，并作为代理协助资源发现。最终，此类结构的维护不应影响车载网络的性能。

6.5 最终讨论

在本章中，我们介绍了车载云（VC）的概念，不仅展示了云元素的架构愿景，还展示了构成车载云的网络元素的愿景。我们描述了车载云中的资源管理问题，该问题具有许多需要克服的挑战；这些挑战涉及资源分配、云内迁移资源以及考虑承载网络独特特性的资源调度。我们还提出了车载云中的资源发现难题，这是该研究领域的一个新颖课题，展现出潜在的研究机会和多个可探索的问题。这些挑战涉及信息存储结构、通信机制、车辆之间的协调与协作机制。随后，我们列出并解释了资源管理与发现方面的最新技术。我们还讨论了在车载云中动态识别资源并对其进行协调的主要挑战以及研究机会。