边缘辅助的车联网增强视觉系统

IEEE车辆技术汇刊，第69卷，第10期，2020年10月 12187

车联网中边缘辅助的增强视觉

周鹏远，IEEE会员，特里斯坦·布劳德，IEEE会员，亚历山大·扎沃多夫斯基，IEEE会员，刘志， IEEE高级会员，陈先富，IEEE会员，许攀，IEEE会士，和尤西·坎加沙尔朱，IEEE会员

摘要

车载通信应用需要高效的通信架构以实现及时的信息传输。基于云的集中式基础设施存在过高的延迟，无法满足紧急信息处理与传输的需求，而车对车通信则因可靠性不足而难以保证信息的及时传输。本文提出EAVVE，一种新型的车联网系统，该系统由具备和不具备全面数据处理能力的车辆组成，并由与路侧单元共址的边缘服务器提供支持。在网络边缘增加计算能力，相比车对云通信可显著降低总延迟，并弥补车载计算能力不足以满足服务需求的场景。为提高卸载效率，我们提出了一种用于实时任务调度的去中心化算法和一种用于信息过滤的客户端/服务器算法。我们通过一个高带宽需求、延迟受限的真实原型系统，展示了EAVVE的实际应用，该系统通过增强现实视觉实现车载视觉的连接。我们通过实际道路测试对该原型系统进行了评估，并结合基于真实世界基站和车辆交通数据的大规模仿真，验证了EAVVE在城市范围场景下的可扩展性和性能表现。与本地和远程云解决方案相比，EAVVE将延迟分别降低了42.6%和78.7%，同时在合理的基础设施支出下，使瓶颈处的拥塞减轻了99%。

索引术语

增强现实，边缘计算，车联网（V2X）。

一、引言

近年来，我们见证了多种辅助或取代人类驾驶车辆的系统出现。这些系统正变得越来越稳健，但同时也更加复杂。2018年，加利福尼亚和上海率先授权在公共道路上部署自动驾驶汽车用于测试，推动了自动驾驶汽车的大规模应用[1],[2]。现代车辆配备了多种驾驶辅助系统，适用于车道保持、紧急制动和自动泊车等各种场景。这些系统提升了驾驶体验，并显著提高了道路安全。然而，在大多数情况下，这些系统的感知能力仅限于单车视角。复杂的场景可能受益于整合多车视角。例如，当与障碍物的距离过短而无法安全实施紧急制动时，车辆可选择其他操作，如转向另一车道。该系统不仅应向其他附近车辆请求状态信息，还应向最邻近的车辆通告该操作。车辆通信系统在车辆与路侧单元（RSU）之间共享信息方面发挥着关键作用。当前的解决方案主要集中在四种通信类型：车对车（V2V）、车对基础设施（V2I）、车对云（V2C）和车联网（V2X）[3]–[8]。尽管这些方案满足了基本需求，高效地在大规模车辆间共享复杂且大量的数据仍然是一个挑战。

在本文中，我们更具体地探讨了大规模车辆间共享视野的问题。我们认为，为了进一步提高车辆安全性，车辆和路侧单元应将其传感器收集的信息进行聚合，以形成更完整的道路状况视野。图1展示了两种部分由于视线受阻而导致的车辆事故类型。

1) 前车的驾驶员看到行人跑过街道，于是减速直至停车。然而，后车驾驶员的视线被前车遮挡被前车遮挡。驾驶员并未察觉到行人，决定超车，导致了一起致命事故。
2) 一些车辆双排停车并堵塞了一条车道。这些汽车停在拐角处之后，处于右转车辆的视线盲区。前车转弯较慢，能够避免事故。然而，后一辆汽车转弯过快，未能避免碰撞。

如果车辆能够实时共享其视野，这两起事故都可以避免。在两辆车辆之间共享视野是一个复杂的问题。若进一步将此模式扩展到大规模、实时的多车辆场景，系统的复杂性将显著增加。在此场景下，车辆会接收到大量来自周围环境的广播消息。为了避免信息过载及其带来的后果（如驾驶员分心、性能下降、网络拥塞），车辆必须仅选择与其当前情境相关的数据。为应对这一挑战并提升车联网（V2X）系统的性能，我们提出了EAVVE（发音为“eevee”），这是首个详细的用于实时共享增强上下文信息的车联网（V2X）框架。车联网（V2X）结合了授权频谱技术（LTE、5G）的高可用性以及在非授权频谱中V2V和车对基础设施（V2I）通信的动态性和普遍性优势[9]。我们通过分析增强现实抬头显示（ARHUD）的一个具体案例来展示该系统的性能，其中视野共享可突出显示用户视线之外的障碍物。综上所述，本文的主要贡献如下：

• 我们设计并分析了EAVVE，一种基于边缘计算的新型车联网（V2X）系统。EAVVE能够使具备和不具备数据处理能力的车辆大规模实时共享上下文信息（第三节）。
• 我们将EAVVE应用于通过增强现实抬头显示连接车辆视野的具体案例中。这展示了EAVVE的优势，即提高上下文信息共享的可扩展性和效率，同时降低传输延迟（第七节）。
• 我们实现了一个原型，并通过真实道路测试对EAVVE进行评估。我们基于真实数据集和测试结果进行了大量仿真来扩展评估范围，仿真结果表明EAVVE在性能上有显著提升。与本地（150公里）和远程（2000公里）云服务相比，它将延迟分别降低了42.6%和78.7%，在不同交通密度下具有良好的可扩展性，并且基础设施开销合理，在伦敦市中心每平方公里仅需部署6.3个边缘服务器（第八节）。

II. 相关工作

新兴技术不仅为自动驾驶汽车实现了多种功能，也带来了新的挑战。EdgeComputing将计算能力贴近用户，是5G架构的关键组成部分。许多研究已经探讨了[10]–[12]这一主题。边缘计算在车辆环境中的应用已受到关注，例如[13],中探索的融合方案5G、软件定义网络（SDN）、多接入边缘计算（MEC）和车载网络。文献[14],研究了边缘服务部署的非协调策略，结果表明这些策略在此问题上表现良好。Tran et al 研究了在边缘进行最优任务卸载调度的方法，以实现更快的任务完成[15]。文献[16]提出了一种面向边缘的预测性任务卸载解决方案。Rodrigues etal 将先进的虚拟机迁移与传输功率控制相结合，以最小化智能车辆在使用边缘云时所经历的服务延迟[17]。文献[18],通过复杂的数学建模并应用粒子群优化算法，扩展了文献[17]中的混合方法。文献[19]强调了软件定义网络在车联网边缘计算中的潜力。Tang et al 展望了机器学习和6G在未来车联网环境中的作用[20]。然而，一些基础性问题，如架构设计、通信过程、网络协议以及实现方面的考虑，仍有待深入探索。在本研究中，我们提出了完整的系统设计与详细的功能设计，并基于公共数据集进行了部署评估。车联网（V2X）正受到学术界和工业界的越来越多关注[21],[22]。大多数研究聚焦于整体系统设计和网络协议栈设计[6],[23]。我们的工作通过集成边缘计算实现低延迟，提出信息过滤策略以提升数据处理效率，构建了实用原型，并通过道路测试对其性能进行了评估。

应用：车载应用的开发已取得一些成果[24]–[27], ，但从系统和网络角度缺乏改进，这些应用在实际情况下难以扩展。

III. 系统设计

在本节中，我们讨论系统设计。我们首先明确系统架构，然后介绍微服务及其之间的数据流的详细信息。

A. 系统架构

由于延迟是车联网系统的关键性能因素，我们简化了架构以加速数据流。EAVVE 定义为三层：设备、边缘和互联网，如图2所示。边缘层包含与基站或路侧单元共址的边缘服务器，并在其相应基础设施覆盖范围内运行。设备层包含参与通信的其他无线设备，例如车辆、行人使用的手机以及安装在自行车上的无线传感器单元。车辆、路侧单元和其他设备通过专用短程通信（DSRC）、蜂窝车联网（C‐V2X）或混合架构[6],[28],[29]等协议进行通信。在本研究中，我们将联网车辆愿景（CVV）作为用例。CVV 需要实时目标检测能力。因此，我们在边缘服务器和智能车辆的设计中集成了机器学习能力，如下一节所述。

B. 系统数据流

为了更好地介绍功能和数据流，我们将设备分为两类，即客户端设备和发送端设备。客户端设备指的是任何用于处理并显示接收到的上下文信息的单元，例如车辆中的接收器和增强现实抬头显示。发送端设备指的是任何发送上下文信息（如传感器数据、捕获的摄像头图像和目标检测结果）的单元。在此背景下，我们将配备目标检测器的发送端称为智能发送端，与之相对的是普通发送端（图3）。一个实体可能包含上述一种或多种单元。例如，具备目标检测能力的智能车辆拥有客户端设备和智能发送端，普通车辆拥有客户端设备和普通发送端，而智能手机、监控摄像头和自行车仅具有普通发送端。边缘服务器提供带有目标检测器和数据过滤模块的目标检测卸载与数据聚合功能。

客户端设备、发送端设备和边缘设备运行微服务持续处理数据。为了最小化运行延迟，我们需要一个高效的数据流。如图3中的编号箭头所示，主要数据流包括以下步骤：

1) 传感器设备收集并广播基本信息，包括唯一标识符（UID）、纬度、经度、运动状态（速度、航向角、加速度）、类型（行人、自行车、车辆）和对象的尺寸。
2) 智能车辆上的摄像头周期性地拍摄图像，并将其加载到车载目标检测器中。其他设备上的摄像头则将图像发送至附近边缘服务器。
3) 目标检测器广播检测结果，包括检测到的对象的类型、尺寸和位置（基于相对距离计算，参见第八节）。传感器数据和检测结果按照 SAE J2735 BSM标准通过专用短程通信（DSRC）以 10 Hz的频率进行广播[30]。
4–5) 客户端设备根据预定 义机制对接收的数据进行过滤和优先级排序。
6) 增强现实抬头显示显示更新后的信息（第七节）。
7) 边缘服务器更新所收集的传感器数据。
8) 边缘服务器将接收到的摄像头图像（步骤2）加载到目标检测器中。
9) 边缘服务器将检测结果发送回发送者。
10–11) 边缘服务器结合从附近智能车辆接收到的信息，利用自身的检测结果更新检测到的对象。
12–14) 边缘服务器定期更新道路状况，并将数据聚合至云数据库。

因此，每辆车都能够更新有效的道路状况，并实时显示，以辅助驾驶。同时，边缘服务器维护着附近的道路状况，从而具备细粒度交通监控与控制的潜力。在下一节中，我们将解释网络模型，并详细说明部署在车载单元（OBU）和边缘服务器上的算法。

IV. 模型描述

A. 网络模型

节点分类 ：在自动驾驶汽车成为常态之前，典型的道路场景将是普通车辆与越来越多的无人驾驶车辆共存。目前，大多数车辆通过蜂窝网络接入互联网，并使用谷歌地图等云服务来辅助驾驶员。未来，我们预计车辆不仅将连接到互联网，还将连接到其他车辆和路侧单元。因此，我们根据其角色和能力对网络节点进行分类，如下所述。智能车辆（配备强大车载单元（OBU）的车辆），普通车辆（未配备强大车载单元（OBU）的车辆，即标准汽车），边缘服务器，路侧单元（交通信号灯、路边传感器）以及互联网（基站、核心网络和云）。我们假设所有车辆都具备用于V2V和车对基础设施（V2I）连接的无线接口，例如蜂窝车联网的PC5接口[23]。为简化起见，我们假设所有路侧单元（未与边缘服务器共址的）均为不具备额外处理能力的简单网关，并将其工作负载卸载到附近的边缘服务器。因此，该网络为一种混合集成网络，包含V2V、V2E、车对基础设施（V2I）和V2C。每个节点通过发送单跳广播或多播消息与网络通信，并使用预定义规则对接收的消息进行过滤。

通信模型 ：在我们的实现中，信标和计算输入/输出数据的传输使用相同的频率，即30赫兹。每个信标包的尺寸为12字节，该应用的每个计算输入包尺寸为51.8千字节，每个计算输出包尺寸为512字节。由于信标的数据显示量远小于计算输入数据（图像帧）和输出数据包（检测结果），因此信标拥塞控制和信令开销优化对整体性能的影响极小。此外，这些主题已在大量文献[31]–[34]中得到充分研究。因此，我们将网络模型的重点放在参与计算卸载的实体上，即车辆V={V1, V2,…, Vv}和边缘服务器E={E1, E2,…, Ee}。VEj表示在某一时间点向Ej进行卸载的普通车辆集合。与边缘服务器共址的每个基站的上行链路和下行链路容量分别表示为Bul和 Bdl（bps）。车辆的瞬时上行链路和下行链路数据速率分别表示为 Rul和 Rdl（bps）。有效数据速率受信号强度、电磁干扰和噪声等多种因素影响，如公式[35]和[36]所示。为简化起见，我们假设每辆车获得 Bul和 Bdl的公平份额，即 Rul E j = Bul/|VE j |和 Rdl E j = Bdl/|VE j |。

B. 任务模型

我们假设每辆车 V 都有一个计算任务，该任务以一系列任务（或调用）的形式出现，即 τV (IV, CV, OV, TV, PV, DV)。其中 IV 和 OV 分别表示计算输入和输出数据的数据量。CV 表示执行时间，即完成 τV 处理所需的总 CPU 周期数乘以时钟周期。 TV 表示 τV 的周期。PV 表示 τV 的优先级（第六节）。 DV 表示 τV 的截止时间，即 OV 必须在此时间段内返回车辆才被视为有效（详见第四节‐C）。在我们的实现中，我们让所有车辆具有相同的 IV、CV 和 OV 值。

C. 系统特性

一个道路网络区域可以被视为一个大型多处理器系统，其中每个边缘服务器充当一个处理器，每辆车周期性地发送其任务的任务实例（任务 τ V ）。基于车载应用特征，我们采用多处理器调度中的一些术语来回顾系统特性，如下所示：

1) 同构 ：边缘服务器是相同的，因此执行所有任务的速率也相同。从优化的角度来看，每个边缘服务器执行的线程数量不会影响任务的复杂性调度算法。为简便起见，我们假设每个边缘服务器在单个线程中执行所有接收到的任务。
2) 任意截止时间 ：我们将每个任务的截止时间设置为其优先级的反比值，即 DV = t/PV t，其中是一个预定义周期值。其原理在于，更重要的任务应在处理和返回结果的速度上被优先考虑。
3) 任务级迁移 ：一个任务的任务项可以在不同的边缘服务器上执行。每个任务项只能在一个边缘服务器上执行。
4) 固定作业优先级 ：一个任务的任务项可能具有不同的优先级。每个任务项具有单一的静态优先级。
5) 可抢占 ：任何任务在任何时候都可以被更高优先级的任务抢占。

值得注意的是，与一般的多处理器系统相比，我们的系统有几个不同的关键点：

1) 优先级 的定义具有双重含义：任务的重要性，例如图像中识别出的对象的重要性的总和；以及任务在处理队列中的排序。假设使用最早截止时间优先（EDF）调度算法，则任务在队列中的排序与其重要性一致（第四节‐ B）。换句话说，越重要的任务截止时间越小，因此在处理队列中的优先级越高。
2) 每个任务的优先级只有在被边缘服务器处理后才能确定。因此，服务器在排队前无法得知每个任务的截止时间。为应对这一挑战，我们提出利用每辆车任务的历史轨迹来预测其当前作业的截止时间（第六节）。
3) 与集中式或集成系统不同，车联网（V2X）等分布式无线系统在从客户端收集统计信息时会带来显著的延迟，尤其是在执行实时全局调度时。因此，该系统需要采用除集中式调度之外的其他解决方案。

接下来，我们建立数学模型并描述问题。我们在第六节中提出了优化算法和优先级策略，以解决上述关键问题。

D. 卸载模型

普通车辆的卸载过程包括输入数据传输、在边缘服务器中的处理以及输出数据传输。将 τV 的计算输入数据传输到边缘服务器 E 的时间开销为：

$$ T_{off}(\tau_V) = \frac{I_V}{R_{ul}(E)} $$ (1)

将输出数据传输到 V 的时间开销为：

$$ T_{back}(\tau_V) = \frac{O_V}{R_{dl}(E)} $$ (2)

E 在 τV 上的执行时间是：

$$ T_{exec}(\tau_V) = C_V + \sum_{v \in queue} C_v $$ (3)

其中 ∑v ∈ queue Cv 是处理队列中排在 τV 之前的任务的执行时间之和。队列的长度，|queue| 等于边缘服务器中单线程执行所接收任务的数量（第四节‐C）。然后我们可以计算从普通车辆 V 卸载 τV 的总开销，以延迟表示：

$$ L_{\tau_E^V} = T_{off}(\tau_V) + T_{exec}(\tau_V) + T_{back}(\tau_V) $$ (4)

智能车辆在车内处理数据并发送结果。因此，延迟仅包含执行和下行链路延迟。由于智能车辆的数据传输对边缘卸载性能影响较小，我们在本文其余部分忽略该因素。

E. 边缘资源分配

为了提高系统性能，一个基本的挑战是如何高效利用边缘资源以实现更好的任务卸载性能。根据第四节‐A中对网络节点的定义，每辆普通车辆需要一个（多服务器卸载留待未来研究）边缘服务器来补充数据处理能力。我们用 aij ∈{0, 1}表示边缘服务器 Ei针对普通车辆 Vj的计算任务的卸载决策，定义如下。

$$ a_{ij} = \begin{cases} 1 & \text{if } V_j \text{ offloads to } E_i \ 0 & \text{otherwise} \end{cases} $$ (5)

分配可以表示为一个(0,1)矩阵，如下所示。

$$ A_{rv,e} = (a_1, a_2, …, a_e) = (a_{ij})_{rv \times e} $$ (6)

其中 rv, e分别表示普通车辆和边缘服务器的数量（如第四节‐A中所定义）。根据公式(1)‐(5)，可计算边缘卸载的总开销LτEV 为

$$ L_{E}^{\tau_V} = (\frac{C_V}{2} + \lambda) \sum_{j=1}^{e} |a_j|^2 + \frac{3C_V}{2} r_v $$ (7)

其中 λ= IV/B ul+ OV/B dl, |aj| 为卸载到 Ej 的车辆数量。有关（见公式7）的推导，请参见附录A。

V. 问题建模

优化的总体目标是在最小化总体延迟的同时，最大化及时返回的有效反馈结果的优先级之和。我们将 bij 表示为反馈结果的有效性矩阵：

$$ b_{ij} = \begin{cases} 1 & \text{if } L_{E_j}^{\tau_{V_i}} \leq D_{V_i} \ 0 & \text{otherwise} \end{cases} $$ (8)

其中 λ|aj| 是 Ej的卸载延迟。基于（见公式7），该问题可以表述为

G1: $$ \max \sum_{i=1}^{r_v} \sum_{j=1}^{e} a_{ij} b_{ij} PV_i $$
G2: $$ \min L_{\tau_E^V} $$

s.t. C1: ∀i ∈[1, rv], $$ \sum_{j=1}^{e} a_{ij} = 1 $$
C2: $$ \sum_{j=1}^{e} |a_j| = r_v $$ (9)

约束C1和约束C2确保每辆车在任意时间点仅卸载到唯一一个边缘服务器。换句话说，普通车辆始终有一个用于卸载的边缘服务器，即使在高峰期也是如此。然而，具有较长处理缓冲队列的边缘服务器将丢弃已过期的任务而不予执行。最小化问题(G2)等于如下：

$$ \min \sum_{j=1}^{e} |a_j|^2 $$ (10)

根据柯西‐施瓦茨不等式[37],，我们可知

$$ (\sum x_i y_i)^2 \leq (\sum x_i^2)(\sum y_i^2) $$ (11)

设 yi= 1, ∀i，我们得到

$$ (\sum x_i)^2 \leq (\sum x_i^2) $$ (12)

结合约束C2，我们得到LτEV 的下界：

$$ \min L_{\tau_E^V} = (\frac{C_V}{2} + \lambda)r_v^2 + \frac{3C_V}{2} r_v $$
s.t. |aj| = rv / e, ∀j ∈[1, e] (13)

这表明当任务被均匀分配到边缘服务器时，实现了G2。我们在附录B中简要描述了一种改编自全局最早截止时间优先（EDF）的多项式时间算法，作为G1和G2的集中式解决方案。然而，如第四节‐C中的关键点3所述，仍需进一步改进以应对集中式调度器带来的额外延迟影响。因此，我们将在下一节提出一种去中心化算法来解决这一挑战。

VI. 策略与算法

在本节中，我们提出了一种详细的解决方案，包含数据优先级策略和算法，以应对第四节和第五节中描述的挑战。

如第四节‐C中关键点2所述，该问题的一个重要特征是我们不假设事先已知任务优先级分配，而这一假设在大多数相关工作中被广泛采用。我们包含这一特征是有充分理由的，即大多数数据学习任务（如自然语言处理（NLP）或图像处理）只有在之后才能判断数据的价值（含义）处理。然而，数据中包含的信息对于优先级（截止时间）分配至关重要。为应对这一挑战，我们提出使用历史任务优先级的小批量作为参考，为新到达的任务分配优先级。例如，在批大小3的设置下，调度器会计算前三个任务的优先级平均值，并将该平均值作为下一个任务的优先级进行分配。

我们首先解决边缘服务器资源的分配问题。我们将一组附近边缘服务器定义为一个边缘服务器池。同一池中的服务器之间通过有线连接相互连接，能够以可忽略的延迟进行通信。每个池不与其他任何池重叠，并被分配不同的广播IP地址。在本研究中，我们依赖云，由其执行一项服务，负责向车辆提供其附近边缘服务器池的信息。每个区域内的边缘服务器数量取决于服务器部署策略和交通状况。详情请参见第八章D节。从技术上讲，车辆根据其位置和移动轨迹，从云服务地图预加载边缘服务器池的位置信息，并选择行进方向上最近的一个作为卸载候选。只要至少有一个可用的边缘服务器池处于无线链路覆盖范围内，车辆便通过其无线接口广播任务。池中可能存在多个边缘服务器可用于执行该任务。为了避免多个服务器同时调度同一任务执行的情况，我们引入了一种去中心化算法，如算法 1所示。当边缘服务器接收到任务时，使用小批量平均值为其分配优先级，并通过有线接口（用于边缘服务器之间的通信）广播其决策。随后，该任务将被放入一个特殊目的wait队列，仅在主队列中的任务耗尽时执行。在冲突解决过程中，拥有最短主队列的服务器获胜，其他边缘服务器则从其等待队列中丢弃该任务。最终，获胜的边缘服务器将该任务放入其主可抢占队列中。与集中式调度方案相比，所提出的去中心化算法由于具备两个优势，更适用于V2X卸载场景：

1) 它避免了单点故障的出现。算法1将通信分布在多个边缘服务器之间，而集中式解决方案在调度器发生故障时会失效。
2) 它具有更低的信令开销。算法1仅要求边缘服务器交换“预计完成时间”，而集中式解决方案则要求调度器收集等待队列长度和作业优先级。

接下来，我们介绍系统用于优先处理数据的详细策略。

A. 优先级策略

大多数安全应用要求车辆向其邻近区域内的所有车辆广播自身信息。然而，在大多数情况下，车辆仅需获取其直接邻近范围内部分车辆的信息。因此，设计数据共享策略以避免不必要的信息处理至关重要。对于辅助驾驶而言尤其重要，因为其目标是实时为驾驶员提供有价值的信息。例如，当增强现实抬头显示中充满代表所有附近车辆和路侧单元的图标时，反而会令驾驶员困惑，无法起到辅助作用。同样，传播无关信息将导致网络拥塞和延迟增加。我们提出一种信息优先级策略，用于过滤数据并选择最有价值的信息进行显示。

我们假设每个任务的处理结果 OV 包含一个对象列表，其中每个对象均指代对客户端具有一定重要性的元数据。更具体地说，在我们的用例中，每个图像帧的处理结果包含一个检测到的对象列表，每个检测到的对象的优先级由其对应的信息决定，例如距离、相关性和类别（行人、车辆、鸟）。每个对象定义为 Mi (Pi, Ii)，其中 Pi 和 Ii 分别表示对象 i 的优先级及其对应的信息。令 MV ={M1, M2,…, Mm} 表示 OV 中的对象列表。 τ V 的优先级计算为该对象中各检测到的对象优先级之和，即 P V =∑ m i=1 P i。

此外，对象 i 的优先级定义为 Pi ρ(DI i , REi , IM i)，其中 DI, RE, IM 分别表示该对象的 距离、相关性 和 重要性。关键假设是车辆和检测到的对象能够实现精确定位。随着 RTK GNSS 和深度估计等相关技术的发展，我们预计在可预见的未来，自定位以及检测到的对象的相关坐标将实现较高的精度。

距离 ：我们过滤掉来自关注半径之外区域发送的数据。例如，在图4中，边缘服务器接收由 R2 拍摄的图像，并广播提取的数据。 S1, S2, R1 将其过滤，因为 R2 距离较远消息包含即时相关信息的可能性较低。

相关性 ：我们根据消息与接收器之间的距离筛选后，再依据其相关性对消息进行排序。如果接收器当前正朝发送者的位置移动，则该消息被认为更具相关性。对于一辆行驶中的车辆而言，最相关的消息来自最近的前车（或位于车辆运动方向前方的最近路侧单元）；这可以通过消息中包含的发送者的运动方向和GPS坐标，以及接收器的当前位置和运动方向来估计。来自其他前车及后方车辆的消息相关性较低，而来自相反方向车道上车辆的消息相关性更低。例如，S1 从 R1 和 S2 接收数据，并优先选择前者，因为 S2 在另一车道上沿相反方向行驶，因此其观测结果相比 R1 而言相关性更低。

重要性 : 系统根据每个检测到的对象的重要性将其分类到优先级列表中。优先级的定义遵循普遍的社会规则，但在不同地区可能会略有差异。我们使用的一个基本示例规则是，例如， pedestrian> bicyclist> vehicle> obstacle。在大量检测到的对象中，边缘服务器和智能车辆应选择最重要的对象，并优先广播其存在。

B. 数据过滤算法

EAVVE的架构依赖于并行线程同时运行，以实时处理数据。在本节中，我们将讨论发送端设备、客户端设备和边缘服务器的数据过滤算法的详细信息。

发送端算法 ：发送端设备包括在数据处理能力上有所不同的智能车辆和普通车辆。智能车辆在其车载单元（OBU）上执行目标检测直接广播结果。普通车辆依赖边缘服务器进行目标检测。由于篇幅限制，我们重点关注智能车辆。该算法的细节如算法2所示。车辆默认每0.1秒采集并广播一次IMU数据（第4行和第14行）。同时，车辆周期性地拍照并广播检测结果。在本研究中，检测过程以单序列方式运行（即非多线程），以展示最低限度的性能（第9行）。通过采用多线程目标检测，EAVVE能够以更高的帧率处理图像，从而提供更好的服务体验。为了同步数据传输，车载单元（OBU）根据延迟调整拍照的倒计时定时器每个检测任务的时间（第10行）。通过这种方式，车辆尽力以最小的时间差广播IMU数据和检测结果。然而，由于网络问题和系统性能差异，来自不同车辆的数据包可能在不同的时间戳到达某一车辆。客户端设备使用缓冲区来解决此问题，具体如下。

客户端算法 ：如算法3所示，客户端单元使用缓冲区在周期tBuff内对接收到的数据包进行拼接（第4行），

$$ 0 < t_{Buff} \leq T - t_{policy} $$ (14)

其中 t(policy)是策略执行延迟，其平均时间复杂度为 O(1)，在我们的道路测试中约为1.2 ms。tBuff 可设置为（见公式14）区间内的任意值。并行线程将 时间内新到达的数据推入缓冲区尾部（第7行和第10行），同时显示缓冲区头部的数据。一旦与发送者广播的周期相同，客户端即重置缓冲区（第3行）。较大的 可能增加待显示的数据量，但同时也会增加跨线程操作的数量。在第八节中，tBuff 被设置为90 ms，以显示更多接收到的数据。

如前所述，车辆需要通过过滤接收的数据来仅显示最相关的信息。EAVVE通过三个步骤应对这一挑战：

1) 该系统仅处理来自关注半径内的数据包（第6行）。
2) 如果两个对象之间的距离小于默认容差偏差 Γ，则被视为重复项（第16行）。不同类型对象的容差偏差不同，规则是较大的对象具有较大的容差偏差。为最小化延迟，车载单元（OBU）会从重复项中随机选择一个进行显示。
3) 在重复项中，IMU数据始终具有最高优先级，因为其比检测结果更可靠且更准确（第20行）。

边缘服务器运行一种混合算法，结合了发送端算法的 thread-Detector 和客户端算法的 threadPreprocess。它通过 threadDetector 将目标检测任务从普通车辆卸载。同时，它通过 threadPreprocess 聚合附近车辆的IMU数据和检测结果，并去除重复数据。它还定期将聚合后的道路状况上传至云数据库或交通中心，用于交通监控。

VII. 车载网络的增强现实应用

在本节中，我们描述了为展示EAVVE而实现的增强现实（AR）应用的详细信息。增强现实抬头显示（ARHUD）是一种旨在通过在车辆挡风玻璃上显示交通信息来辅助驾驶员的新技术。目前，业界和学术界的努力主要集中在提供更好的可视化效果。而EAVVE则通过从附近车辆收集的大量信息来增强ARHUD的功能。在V2E场景中，边缘服务器为附近的普通车辆提供目标检测服务。车载物联网设备（例如安装在挡风玻璃后的智能手机）既作为发送端设备将数据传输到边缘服务器，客户端设备对接收的数据进行可视化。为了检测目标并增强用户的视野，物联网设备会定期将传感器数据和捕获的图像帧上传至边缘服务器。传输的数据包括来自摄像头的当前街景图像、GPS坐标、运动状态和时间戳。边缘服务器在接收到数据后，首先使用目标检测器对图像执行目标检测。借助先进的深度学习框架和GPU硬件加速，目标检测器能够实时检测对象。在部署过程中，我们在配备内置Nvidia GTX 1070 GPU的服务器上，使用YOLO版本3和OpenCV构建了原型系统，每张图像的处理时间约为20毫秒。对于每个检测到的目标，检测器还会返回一个矩形边界框（或代表性图标）。在具备全面数据处理能力的智能车辆情况下，该应用以类似方式运行于车载单元（OBU）上。此时应用程序直接分析车载摄像头拍摄的图像，而不是像与边缘服务器通信时那样通过网络接收图像。

VIII. 评估

A. 实现

在本小节中，我们描述EAVVE的实现。我们遵循前几节中所述的系统设计和用例，开发一个联网车辆视觉系统。该系统在摄像头图像中检测行人、汽车、公交车和交通信号灯，并将结果在车辆之间实时共享。

我们在Linux平台上部署了目标检测器（图3），并使用YOLO版本3的GPU实现，这是当前最先进的目标检测算法之一。我们使用OpenCV进行常规的图像处理，例如车辆之间的透视变换。客户端设备以及发送端设备的部分功能（摄像头、IMU数据采集器）在Android平台实现，以模拟车辆增强视觉系统的软硬件环境。GPS传感器报告车辆的GPS坐标，单目相机捕获车辆前方视角。我们使用OpenGL将增强信息渲染到摄像头画面之上。当前的原型系统使用单目相机（在Android手机上），而实际车辆很可能配备立体相机，这将使许多变换更加容易。尽管存在这一限制，我们的原型系统仍完全可运行，展示了其产品化的潜力。

B. 原型与道路测试

原型 ：我们使用第八节‐A中描述的原型。为了模拟车载设备，我们在两部华为Mate9 Pro智能手机上安装了客户端应用程序，每部手机均配备2.4（1.8）GHz八核海思麒麟 960 CPU和4 GB内存。我们的边缘服务器部署在一台MSI GS65 Stealth 8SG上，该设备配有6核I7‐8750H CPU、32 GB内存和Nvidia RTX 2080 Max‐Q GPU。我们边缘服务器的硬件性能类似于一款中等价位2018[38]中的通用边缘服务器。为了比较EAVVE相对于云计算的优势，我们在谷歌云平台上创建了一个虚拟机实例，配备6个vCPU、16GB内存和一个Nvidia Tesla V100 GPU。我们将两部手机放置在车辆挡风玻璃后方，作为车载摄像头、惯性测量单元和增强现实抬头显示使用，如图5所示。

道路测试 ：我们在一个大城市的市中心驾驶两辆车辆，一辆跟随另一辆。我们使用表I所示的网络配置进行以下四项道路测试。

• V2V ：该测试演示了智能车辆与普通车辆之间的通信。我们将背包放置在前车中，并通过系连方式将其与手机连接，以模拟一辆与后车无线通信的智能车辆。在此场景中，前车的智能车辆处理采集的数据并广播分析结果。后车的普通车辆接收该结果，并将其渲染到增强现实抬头显示上。
• V2E ：然后我们将背包放置在路边以模拟边缘服务器。我们将边缘服务器设置为接入点（AP）模式，使两辆车中的手机能够直接与边缘服务器通信。我们使用 IEEE 802.11ac 设置 AP 模式，并限制链路，以获得与 IEEE 802.11p（5.9 GHz，最高 27 Mbps）相似的频率和带宽。我们展示了由此带来的潜在改进通过模拟，研究新兴技术和基础设施（例如与基站和专用短程通信（DSRC）共址的边缘服务器）。
• 车对本地云通信（V2LC） ：作为对比，我们评估了谷歌云虚拟机在与目标检测器相同的本地区域内的性能。手机通过标准LTE连接将捕获的图像发送到云，并接收提取的数据。
• 车对远程云通信（V2RC） （车辆与约2000公里外的远程云通信）：最后，我们使用远程Google云虚拟机重新进行了之前的测试。

每轮次大约需要20分钟，以30帧每秒传输约36000张图像。

C. 增强现实车载通信愿景（CVV）

Showcase ：图6展示了CVV的两个典型应用场景，其中前车识别其视野中的对象，并将这些信息传输给后车。图 6(a) 显示了一个常见场景，即行人意外地横穿街道。该场景发生在狭窄道路上，后车驾驶员的视线容易被遮挡，而前车驾驶员则拥有清晰的视野（见图6(c)）。这种情况可能存在危险，因为后车无法预知前车前方发生的状况，当前车需要紧急制动时，后车的反应时间更少。CVV可帮助后车驾驶员意识到被前车遮挡的行人，并提前减速。在第二个场景中，一辆车已在交叉路口右转，另一辆车也准备右转。前车观察到路边有几辆停放车辆，阻塞了一条车道。如果后车在未谨慎驾驶的情况下转入被阻塞的车道，则可能发生事故。借助CVV，后车驾驶员也能“看到”拐角处视线盲区内的停放车辆，如图6(d)中带有名称标签的绿色矩形所示。这使得第二辆车的驾驶员能够避免驶入被阻塞车道。综上所述，EAVVE能够通过利用另一辆车辆观测到的信息增强驾驶员视野来提高道路安全。

测量 ：我们在道路测试的多个轮次中运行应用程序，并测量逐级延迟。图7显示了车对本地云通信（V2LC）、车对远程云通信（V2RC）和V2E的图像传输延迟。表II 展示了每次运行的集成逐级延迟。所示数据是在整个测试轮次（20分钟和约36000次图像传输与处理）中取的平均值。CVV的延迟可分为以下几个组成部分：客户端数据采集、上行链路延迟（图像传输）、目标检测、策略控制、下行链路延迟（检测结果传输）和显示渲染。

如表II所示，使用边缘服务器的CVV比使用云服务器的CVV快得多。由于硬件差异，算法在云服务器上的运行速度略快于在边缘服务器上的运行速度。然而，当使用边缘服务器时，与使用本地云服务相比，上行和下行延迟之和减少了超过132.9毫秒，这是造成大部分时间差的主要原因。在使用远程云服务的情况下，这一差异增加到663.1毫秒。这分别比本地云服务和远程云服务提升了42.6%和78.7%，总延迟低于200毫秒。这证实了我们的核心假设，即边缘计算通过在更靠近用户的位置执行数据处理，可以显著改善延迟敏感型工作负载。

V2V在所有解决方案中具有最低延迟，这得益于其直接的数据处理流水线，且不依赖第三方服务器。然而，它确实需要配备本地处理能力的智能车辆。

如第八节开头所述，专用短程通信（DSRC）和5G有望进一步提升EAVVE的性能。这两种技术均可显著降低 V2V和V2E的通信延迟，从而进一步扩大EAVVE相较于当前解决方案的优势。我们已通过展示车载计算或边缘计算在处理时间上的改进优于本地或远程云带来的增加的通信延迟，证明了其明显优势。在下一节中，我们将通过讨论边缘服务器部署，并基于真实数据集估算部署成本，进一步扩展该模型。

D. 边缘服务器部署

为了解决边缘服务器部署问题，我们考虑了三个不同人口密度城市（伦敦、诺丁汉和约克，均位于英国）的基站和交通分布模式。对于每个城市，我们聚焦于市中心周围4 km × 5 km范围内的区域。针对每个区域，我们使用公开的 LTE基站位置数据1以及交通量数据2。我们根据交通量数据进行聚类分析车辆的GPS坐标，并根据聚类结果将选定区域划分为更小的区域。交通分布和区域划分结果如图8所示。每个彩色点代表聚合交通的位置，其尺寸与白天12小时内的交通量成正比。在每个区域内，我们根据平均和峰值交通量显示部署的边缘服务器数量。接着，我们分析基站分布与交通密度之间的关系，因为这会影响我们的共址边缘服务器部署。表III显示了每个区域内的基站数量。一些基站的覆盖半径大于3公里；我们将这些称为“宏小区”。我们在图9中将这些宏小区标为红色，其余标为蓝色。基站分布均匀，并且合理匹配交通密度。因此，以基站作为部署点不太可能导致边缘服务器部署偏离实际交通模式。在高峰交通期间满足用户需求所需的边缘服务器最大数量分别为：伦敦125个、诺丁汉67个、约克33个。这分别对应每平方公里6.3、3.45和1.8个边缘服务器，这对于高可用性、实时边缘计算而言是一项合理的基础设施投资。因此，我们主要将边缘服务器部署在靠近聚合交通的宏小区内。

为了评估我们系统的可扩展性，我们在各种场景下测试了系统性能。在EAVVE的三个主要部分中，V2C和V2V分别依赖于互联网连接和智能车辆。而V2E则需要应对边缘服务器部署和车辆交通密度问题。因此，我们重点评估V2E的性能。我们复用了第八章D节中描述的实验设置。在上午7点至下午6点（12小时）内，伦敦、诺丁汉和约克所选区域每小时出现的车辆数量分别从7589增至12948、从8920增至10923、从3827增至5596。我们使用以下方法模拟交通场景Veins[39]。Veins 是一个用于运行车联网仿真的开源框架，基于 OMNeT++（一种基于事件的网络模拟器）和 SUMO（一种道路交通模拟器）。每个边缘服务器的覆盖范围为 3 公里，与其共址的宏蜂窝类似。我们使用的公共数据集仅包含每小时车辆数。为了增加粒度，我们根据从真实数据集中收集的相应数据，在每个区域内随机生成交通流量（见第八章D节）。因此，模拟交通在宏观层面上对应于真实交通。在仿真中，所有车辆均为不具备图像处理能力的普通车辆。在道路测试中，我们让系统以每秒 10 张图像的速度更新。在此帧率下，驾驶员在增强现实抬头显示上观察到对象闪烁，帧的平滑过渡无法实现，难以获取所有显示的信息。因此，在仿真中，我们让每辆车以每秒 1 张图像的速度持续将其捕获的图像发送至最近的边缘服务器。

E. 可扩展性

由于车联网边缘和边缘到车辆的所有传输都是广播形式，因此传输信道上可能会出现拥塞。根据车辆交通量的不同，这可能会产生忙时，从而影响车辆与边缘服务器之间的通信，或反之亦然。当一辆车发现信道繁忙时，它会等待一个指定的时间周期，然后尝试重新传输。在我们的仿真中，并未专门尝试寻找最优的退避策略，而是采用了广为人知的指数退避[40]。图10显示了每辆车经历的总忙时。在x轴上，我们展示了仿真中的所有车辆，y轴上的数值表示该车辆经历信道繁忙的秒数。图11显示了每辆车发送的数据包总数。仿真的前10分钟被视为预热阶段。我们计算在接下来的10分钟后进行测量。所有场景中的车辆平均速度均低于10 km/h，从而反映了在极度拥堵场景下系统性能的下限。表IV总结了具有99%置信区间的统计信息，并显示EAVVE能够很好地适应不同场景。例如，尽管由于交通量更大，伦敦和诺丁汉的繁忙时间通常比约克更长，但车辆经历信道繁忙的总时间比例仍然合理。信道仅在少数百分比的时间内处于繁忙状态（1.66%–2.59%）。此外，发送的数据包数量与驾驶时间段相符。车辆在退避状态中花费的时间很少，证明网络拥塞可以忽略不计。因此，EAVVE的V2E策略能够很好地扩展到具有不同交通密度的市中心区域。

表V展示了我们的演示应用在整整一天（模拟）过程中所需 的最小和最大带宽需求。在高峰时段，云服务器在中心城区（伦敦）需要超过680兆比特每秒（Mbps）的带宽。当使用带有边缘服务器的V2E时，共址基站的负载约为5兆比特每秒（Mbps），这在LTE网络上是可以实现的。V2V每辆车辆大约需要500千比特每秒（kbps），在LTE和专用短程通信（DSRC）上均可实现。总体而言，与V2C相比，V2E能够显著减轻瓶颈处的负载（最多达99%），同时为普通车辆提供计算能力。

总之： 我们的边缘服务器部署策略利用基站分布，能够很好地将需求与车辆交通模式相匹配。EAVVE通过降低传输延迟，改善了车载网络中的增强现实（AR）应用。EAVVE具有可扩展性，在不同交通密度下均表现良好，还可与云解决方案结合以优化成本。

IX. 结论

本文提出了一种面向车联网（V2X）应用的架构框架 EAVVE。我们的系统利用边缘服务器的低延迟特性，提供实时的紧急事件检测与通知。通过在网络中多个位置部署边缘服务器以及未来车载处理能力的支持，EAVVE能够基于过滤和优先级机制，在不同时间和空间尺度上为多种用途提供上下文信息共享服务。为了验证EAVVE背后的概念，我们构建了一个原型应用，并通过真实世界实验对其进行评估。该应用将车载视觉与增强现实抬头显示（ARHUD）相结合，以实现更全面的事故避免。此外，利用来自英国不同城市的实际交通数据，我们证明了EAVVE能够扩展以满足现实中的交通需求，并且所需的边缘服务器数量保持在可管理范围内，即使对于大都市也是如此，例如在伦敦市中心每平方公里仅需 6.3 台边缘服务器。我们的道路测试结果表明，与云解决方案相比，EAVVE降低了车载网络中增强现实（AR）应用的延迟，相对于本地和远程云服务，CVV的延迟分别降低了42.6%和78.7%。我们还研究了EAVVE的可扩展性，并表明其在不同交通密度的真实场景下均能降低延迟。总之，EAVVE是一种高效的车联网（V2X）解决方案，通过降低用户延迟和减少网络流量来提升系统性能。