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

一、背景

1.1 研究背景

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

1.2 挑战

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

1.3 贡献

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

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

为了表现这些挑战,我们对移动车辆将实时视频上传到云服务器进行了实验,下图展示了从移动车辆上传输10Mbps和30Mbps视频时,单个5G或LTE蜂窝链路的特性。
物理层指标:接收信号接收功率(RSRP)和信号干扰和噪声比(SINR)
传输层指标:丢包率和包延迟时间
阅读[23SIGCOMM]CellFusion: Multipath Vehicle-to-Cloud Video Streaming with Network Coding in the Wild_第1张图片

RSRP和SINR都表现出明显的随机波动。结果表明,随着车辆行驶,蜂窝信号覆盖变得非常不稳定。
5G和LTE链路都表现出严重的突发损耗,都遭受了许多延迟峰值。
下图显示了相应的视频QoE测量结果,包括每秒帧数(FPS)、视频停顿率和SSIM评分结果。
阅读[23SIGCOMM]CellFusion: Multipath Vehicle-to-Cloud Video Streaming with Network Coding in the Wild_第2张图片

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

二、系统建模

2.1 服务架构

2.1.1 总体架构

阅读[23SIGCOMM]CellFusion: Multipath Vehicle-to-Cloud Video Streaming with Network Coding in the Wild_第3张图片
系统架构分为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:括号中包括的组件和步骤表示在同一个域中或在同一个域中进行的
阅读[23SIGCOMM]CellFusion: Multipath Vehicle-to-Cloud Video Streaming with Network Coding in the Wild_第4张图片

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加速算法
阅读[23SIGCOMM]CellFusion: Multipath Vehicle-to-Cloud Video Streaming with Network Coding in the Wild_第5张图片
阅读[23SIGCOMM]CellFusion: Multipath Vehicle-to-Cloud Video Streaming with Network Coding in the Wild_第6张图片

B 数据包编码

阅读[23SIGCOMM]CellFusion: Multipath Vehicle-to-Cloud Video Streaming with Network Coding in the Wild_第7张图片
数据包:编码器模块中注册(数据包池保存原始数据包副本,分配数据包号和时间戳)—>封装到QUIC数据报帧中—>多蜂窝接口传输—>解码器模块解码
阅读[23SIGCOMM]CellFusion: Multipath Vehicle-to-Cloud Video Streaming with Network Coding in the Wild_第8张图片

2.2.3 qoe感知的丢失检测

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

阅读[23SIGCOMM]CellFusion: Multipath Vehicle-to-Cloud Video Streaming with Network Coding in the Wild_第9张图片
CellFusion实现了最高的帧率、最低的停顿比例和最显著的SSIM评分。

3.3 部署的统计结果

在线指标的收集面临两个挑战:(1)在实际使用中,车辆上传的是实时摄像头视图,而不是参考视频;(2)存储7 × 24高清视频成本高。因此,我们不使用视频qoe,而是报告在线环境中经常记录的两个指标:视频数据包延迟和流量冗余。
阅读[23SIGCOMM]CellFusion: Multipath Vehicle-to-Cloud Video Streaming with Network Coding in the Wild_第10张图片
在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
阅读[23SIGCOMM]CellFusion: Multipath Vehicle-to-Cloud Video Streaming with Network Coding in the Wild_第11张图片

3.4.2 对比结果

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

阅读[23SIGCOMM]CellFusion: Multipath Vehicle-to-Cloud Video Streaming with Network Coding in the Wild_第12张图片
**基准测试结果与Pluribus。**我们进一步介绍了XNC与Pluribus的比较结果。图12(a)显示了QoE指标。我们观察到XNC在所有帧率、失速率和SSIM评分方面都优于Pluribus。例如,与Pluribus相比,XNC将平均视频失速降低了81.67%以上。同时,如图12(b)所示,XNC使用的冗余流量也减少了89.49%。上述结果表明,与传统的网络和文件传输解决方案相比,视频到云流是一项更具挑战性的任务,因此需要新的创新。

3.5 消融研究

阅读[23SIGCOMM]CellFusion: Multipath Vehicle-to-Cloud Video Streaming with Network Coding in the Wild_第13张图片
研究了Q-RLNC和qoe感知损耗检测模块的影响
Q-RLNC模块通过提高损失恢复概率,显著降低了尾部分布的丢包率,在第95百分位和第99百分位分别降低了15.55%和41.70%
qoe感知丢包检测在第95百分位和第99百分位分别改善了8.48%和28.44%的平均延迟

3.6 XNC的CPU成本

对比方案:MPQUIC without network coding, XNC, and SSIM accelerated XNC
结果:SIMD-XNC比MPQUIC平均多消耗23.44%的CPU,比XNC减少26.56%的CPU使用
阅读[23SIGCOMM]CellFusion: Multipath Vehicle-to-Cloud Video Streaming with Network Coding in the Wild_第14张图片

四、评价

优点
基于新方法实现支持高质量、实时车辆到云视频流的系统
缺点
实际部署测试中未将CellFusion与其他方法,例如MPQUIC、MPTCP、cellular bonding进行比较
改进
引入数据包损失率,当存在足够的可用拥塞窗口即>,将损失率大的路径上的数据包多发送

你可能感兴趣的:(论文阅读笔记,python,5G,计算机网络,网络协议,车载系统,智能路由器,媒体)