阅读[23SIGCOMM]CellFusion: Multipath Vehicle-to-Cloud Video Streaming with Network Coding in the Wild

最新推荐文章于 2024-11-14 13:48:50 发布

woshicaiji12138

最新推荐文章于 2024-11-14 13:48:50 发布

阅读量586

点赞数 1

分类专栏：论文阅读笔记文章标签： python 5G 计算机网络网络协议车载系统智能路由器媒体

本文链接：https://blog.csdn.net/woshicaiji12138/article/details/133421483

版权

论文阅读笔记专栏收录该内容

17 篇文章 1 订阅

订阅专栏

文章描述了一种名为CellFusion的系统，旨在解决车辆到云实时视频流中的挑战，如高比特率低延迟需求、蜂窝链路波动和突发损耗。作者提出了一种基于XNC的解决方案，包括软硬件设计、数据包处理流程和性能优化。实验结果显示CellFusion显著降低了数据包延迟和流量冗余成本。

摘要由CSDN通过智能技术生成

一、背景

1.1 研究背景

当前算法无法有效处理复杂情况，远程操作驾驶依赖车辆的实时数据远程操作（例如，当算法无法有效处理复杂情况时，远程操作驾驶(ToD)是一种远程超越自动驾驶汽车的机制，它需要将高清摄像头的反馈信息从车辆实时传输到云端。另一个应用是远程诊断程序，由医疗保健专业人员指导护理人员远程实施紧急治疗。通过将救护车内部的高清图像以及病人的生命体征传输到云端，这样的程序就可以成为现实。），车辆和云之间建立可靠的连接变得越来越重要；
过去关于车辆连接的研究建议侧重于下载非实时负载，无法实时服务于高吞吐量的情形。

1.2 挑战

在车辆驱动时，需要在高度波动的蜂窝链路上持续支持高比特率低延迟视频流；
当车辆行驶时，每个蜂窝链路变得高度不稳定和不可预测。

1.3 贡献

提出了第一个支持高质量、实时车辆到云流的系统CellFusion，满足当今的远程操作驾驶要求；
给出了详细的软硬件设计和XNC传输方案。

1.4 通过单个蜂窝链路的车辆到云流的挑战

为了表现这些挑战，我们对移动车辆将实时视频上传到云服务器进行了实验，下图展示了从移动车辆上传输10Mbps和30Mbps视频时，单个5G或LTE蜂窝链路的特性。
物理层指标：接收信号接收功率(RSRP)和信号干扰和噪声比(SINR)
传输层指标：丢包率和包延迟时间
在这里插入图片描述

RSRP和SINR都表现出明显的随机波动。结果表明，随着车辆行驶，蜂窝信号覆盖变得非常不稳定。
5G和LTE链路都表现出严重的突发损耗，都遭受了许多延迟峰值。
下图显示了相应的视频QoE测量结果，包括每秒帧数(FPS)、视频停顿率和SSIM评分结果。
在这里插入图片描述

5G和LTE链路都会出现帧率降低、视频停顿率高、SSIM评分低的问题。
无论是5G链路还是LTE链路都无法持续支持10Mbps以上的实时流。

二、系统建模

2.1 服务架构

2.1.1 总体架构

在这里插入图片描述
系统架构分为3个部分：
(1)由视频客户端(发送方)和CellFusion CPE组成的车辆域
(2)由多蜂窝网络和CellFusion边缘代理服务器组成的边缘域
(3)承载CellFusion控制器和云应用程序(接收器)的云域

2.1.2 核心部件

CellFusion CPE
安装在车辆中的专用硬件，可在异构移动运营商上实现多路径传输
CellFusion代理服务器
分布在云边缘CDN pops上的程序，作为车辆到云流量的边缘接入点
CellFusion隧道客户端
运行在CellFusion CPE上的程序，驱动XNC的客户端堆栈执行数据包编码、丢失检测和丢失恢复
CellFusion隧道服务器
运行在CellFusion代理服务器中的程序，驱动XNC的服务器端堆栈执行数据包解码和转发
CellFusion控制器
部署在中心云，作为CellFusion的控制和管理平面

2.1.3 数据包处理流程

数据包:(CPE的虚拟tun接口—隧道客户端—MPQUIC客户端)—XNC将数据包封装—多蜂窝接口传输—(代理服务器—隧道服务器—MPQUIC服务器)—XNC解码QUIC的有效载荷—虚拟tun接口—云应用
PS:括号中包括的组件和步骤表示在同一个域中或在同一个域中进行的
在这里插入图片描述

2.2 XNC设计

2.2.1 XNC设计的四个主要目标

A支持低延迟的实时视频—>QUIC- datagram
B通过有效的多路径使用获得高数据速率—>XNC将多路径QUIC特性与QUIC- datagram结合
C克服突发损失和链接不可预测性—>
D低冗余和低计算复杂度—>
1缩短反馈恢复回路，提高重传成功率
2基于qoe感知策略的快速丢失检测
3用于重传数据包的Q-RLNC
4提高重传成功率的机会性单次恢复

2.2.2 Q-RLNC编码方案

A RLNC基本操作

1RLNC 是一种网络编码技术，通过对数据包进行线性组合，以增强数据的冗余性，从而提高数据传输的可靠性;
2为了对数据包执行RLNC而不是对单个符号执行，我们将每个数据包视为𝑚-bits符号的数组
3在XNC中，将𝑚设置为8，其中符号的长度为一个字节。选择此值是为了使SIMD加速算法
在这里插入图片描述

B 数据包编码

在这里插入图片描述
数据包：编码器模块中注册(数据包池保存原始数据包副本，分配数据包号和时间戳)—>封装到QUIC数据报帧中—>多蜂窝接口传输—>解码器模块解码

2.2.3 qoe感知的丢失检测

设置丢包检测阈值
应用程序定义的时间阈值和QUIC的PTO中较小的值。
确定丢包的编码范围边界
XNC进一步将重传队列中丢失的数据包划分为连续的范围，在这些范围上分别应用Q-RLNC。
检查三个条件，以便在最近发送的数据包之后相应地插入范围边界：当前范围至少包含𝑟数据包、当前范围跨度至少𝑡秒、检测到视频帧边界。
范围过期和丢包
XNC只在给定的时间内跟踪丢失的数据包，使用一个可配置的依赖于应用程序的时间阈值𝑡𝑒x𝑝i𝑟𝑒来确定数据包是否过期，经验地设置𝑡𝑒x𝑝i𝑟𝑒为700ms。

2.2.4 机会性的一次性恢复

计算最小编码包数𝑛’
不能绝对保证生成的数据包的每个子集的线性独立性
如果发送𝑛’ =𝑛+𝑘个编码包成功，则XNC解码成功的概率至少为在这里插入图片描述
为了平衡带宽开销和解码概率k=3
一次性恢复
得到𝑛’后，XNC计算每条可用路径上的可用的拥塞窗口的和，记为𝑏。如果𝑏<𝑛’，则延迟恢复操作。
如果存在足够的可用拥塞窗口（即𝑏 ≥ 𝑛′), XNC最多可分发𝑏 编码分组到所有可用路径上（与每个路径的可用窗口大小成比例）。
进一步限制每条路径上发送的数据包数量小于𝜌×𝑛’，其中1 <𝜌< 1.2。
当𝑛= 1时，我们只需在每个可用路径上发送一个数据包以最小化延迟。

2.3 CELLFUSION’S CPE

2.3.1 CPE硬件设计

CPE由四个子系统组成:CPU子系统、蜂窝网络子系统、接口和电源管理子系统、Wifi/LAN子系统。
对于CPU子系统，选择瑞芯RK3399作为核心CPU；它具有双Cortex-A72四核Cortex-A53；核心CPU还支持SIMD指令。
蜂窝网子系统采用2个Quectel RM500Q-GL作为5G模块，2个Quectel EP06-E作为LTE模块；使用MIMO来进一步提高蜂窝性能：5G模块具有2TX/4RX天线，LTE模块具有1TX/2RX天线。
Wifi/LAN子系统用于连接车内的视频流源。

2.3.2 XNC的加速

可并行计算：每个数据包视为𝑚-bits symbols的数组，通过单独组合每个数组中相同索引的symbols来生成编码的数据包
加速方法：使用ARM NEON高级SIMD指令执行RLNC
具体实现：
借助vmull_p8(8位多项式乘法)NEON内在特性实现了8路在这里插入图片描述的乘法
中的加法是简单的位级异或
使用SIMD，在CPE机上支持30Mbps视频流时，CPU使用率低于20%。

2.4 CELLFUSION的后端服务

2.4.1 后端包括两部分:CellFusion代理服务器和CellFusion控制器

2.4.2 CellFusion控制器

对CPE设备进行认证，只允许合法用户访问业务
管理cpe和代理服务器的配置
负责实现高可用性：控制器持续监视每个代理服务器的运行状况状态和负载，并在需要时执行故障转移
作为一个协调器，根据服务器的可用性和负载，指示CPE可连接到的服务器。CPE测量到这些服务器的网络延迟，并选择延迟最小的服务器。

2.4.3 多用户Multi-tenant

当多辆车连接到同一个代理服务器时，控制器将为它们的CPE的虚拟tun接口分配一个唯一的私有IP地址，对通过它的每个数据包执行源NAT
同一CPE的视频数据包将具有相同的源IP地址，构建了一个映射表，将CPE的地址与其在服务器上的隧道客户端的QUIC连接ID (CID)关联起来
当服务器收到返回方向的数据包时，可以通过该数据包的目的地址找到相应的CID，并通过QUIC连接将该数据包发送到正确的车辆。

三、实验结果

3.1 设置

CellFusion的基本协议栈基于RFC9000
基于RFC9221实现了不可靠的QUIC-Datagram，并结合了IETF WG Draft的多路径特性
将XNC实现为由QUIC堆栈调用的软件模块
隧道客户端运行在CPE上的OpenWRT中
隧道服务器运行在CentOS容器中
控制器是一个构建在Java Spring框架上的HTTPs服务器
野外测试：CellFusion已经在100辆自动驾驶汽车上进行了6个多月的测试。CellFusion边缘接入的覆盖范围和接近性是确保低延迟和服务可用性的关键。我们在三个省的50个阿里云CDN pops上运行代理服务器。控制器部署在中心云中，为cpe和代理服务器提供服务。

3.2 端到端道路试验

3.2.1 评价方法

将参考视频上传到云中的RTSP服务器。
参考视频是一个特别制作的视频剪辑，我们在其中为每一帧分配了一个序列号戳，可以根据原始视频分析接收到的视频，以提取视频QoE指标，如视频停顿率、帧率和标准化SSIM分数。

3.2.2 对比中使用的其他方案

MPQUIC
MPTCP
cellular bonding

3.2.3 QoE指标：帧率、视频停顿率、归一化结构相似性指数(SSIM)

在这里插入图片描述
CellFusion实现了最高的帧率、最低的停顿比例和最显著的SSIM评分。

3.3 部署的统计结果

在线指标的收集面临两个挑战:(1)在实际使用中，车辆上传的是实时摄像头视图，而不是参考视频;(2)存储7 × 24高清视频成本高。因此，我们不使用视频qoe，而是报告在线环境中经常记录的两个指标:视频数据包延迟和流量冗余。
在这里插入图片描述
在100辆自动驾驶汽车上进行的CellFusion测试统计结果
CellFusion显著降低了数据包延迟；与5G相比，在第95、99和99.9百分位数上分别减少了15.05%、71.53%和76.72%的尾部延迟
CellFusion每天的流量冗余成本在1%到9%之间变化，在线使用CellFusion具有很高的成本效益。

3.4 基准和消融研究

进一步将XNC与过去的几种多路径优化和编码方案进行了比较研究，并对XNC进行了消融研究，以验证我们的设计要点。我们在一个受控的环境中进行了两项研究，以确保在相同的网络条件下进行测试。

3.4.1 对比中使用的其他方案

将XNC与过去的几种多路径优化和编码方案进行了比较
多路径调度优化：minRTT、RE、XLINK、ECF
多路径和网络编码方案：Pluribus
在这里插入图片描述

3.4.2 对比结果

**基准测试结果与其他多路径优化的对比。**在本次测试的所有解决方案中，XNC的帧率最高，失速率最低，SSIM评分最高。XNC的性能变化也比其他nc小得多。与minRTT、XLINK和ECF相比，XNC的平均失速率分别降低了86.56%、82.22%和92.75%。虽然可再生能源有合理的平均失速率，但它需要极高的冗余交通成本(高达300%)。因此，当网络链路带宽受限时，RE无法有效利用带宽进行传输，因此在尾部分布时，其失速率远高于XNC。相比之下，XNC以低冗余率(<10%)高效融合多个网络链路，即使在尾部也能实现低失速比。

在这里插入图片描述
**基准测试结果与Pluribus。**我们进一步介绍了XNC与Pluribus的比较结果。图12(a)显示了QoE指标。我们观察到XNC在所有帧率、失速率和SSIM评分方面都优于Pluribus。例如，与Pluribus相比，XNC将平均视频失速降低了81.67%以上。同时，如图12(b)所示，XNC使用的冗余流量也减少了89.49%。上述结果表明，与传统的网络和文件传输解决方案相比，视频到云流是一项更具挑战性的任务，因此需要新的创新。