CellFusion: Multipath Vehicle-to-Cloud Video Streaming with Network Coding in the Wild 论文翻译

论文摘要：本文介绍了 CellFusion，这是一个专为从车辆到云端的高质量实时视频流而设计的系统。它利用了多路径 QUIC 传输和网络编码的创新组合。CellFusion超越了单个蜂窝运营商的局限性，使用独特的最后一英里覆盖层****，将多个蜂窝网络集成到一个统一的云连接中。这种集成是通过使用车载客户端设备（CPE） 和边缘云代理服务器**实现的。
为了有效处理不稳定的蜂窝连接，这些连接在车辆移动时容易出现强烈的突发损失和意外的延迟峰值，CellFusion 引入了 XNC。这种基于网络编码的创新传输解决方案可实现高效且有弹性的多路径传输。XNC 旨在同时实现 低延迟、最小流量冗余和降低计算复杂性。CellFusion 本质上是安全和透明的，不需要对连接到它的车辆应用进程进行修改。
我们在 100 辆自动驾驶汽车上测试了 CellFusion 超过六个月，我们的云原生后端在 50 个 CDN PoP 上运行。通过广泛的道路测试，我们发现XNC在第99个百分位数与5G相比，将视频数据包延迟降低了71.53%。
在30Mbps的速率下，CellFusion与最先进的多路径传输解决方案相比，在流量冗余不到10%的情况下，实现了66.11%至80.62%的视频卡顿比率的降低。

---

1.名词解释

① QUIC(Quick UDP Internet Connections)是一种基于UDP的传输层协议，由Google开发，旨在提供更快的连接建立时间和更低的延迟。QUIC协议支持多路径传输，可以通过多个物理路径同时发送数据，以此提高吞吐量和连接的稳定性。

②CPE(Customer Premises Equipment):用户终端设备。

③带宽：带宽指的是网络连接能够传输的最大数据量，通常以每秒比特数（bps，bits per second）来衡量。例如，一个100 Mbps（兆比特每秒）的网络连接意味着在理想情况下，该网络每秒可以传输100百万比特的数据。

④吞吐量：吞吐量是实际传输的数据量，通常也以每秒比特数来衡量，它反应的是网络在实际使用中的表现。例如，如果一个网络的带宽是100Mbps，但由于网络拥塞、数据包丢失或其他原因，实际数据传输速率只有50Mbps，那么这个网络的吞吐量就是50Mbps。

⑤LTE(Long-Term Evolution，长期演进)是由3GPP(第三代合作伙伴计划)开发的无线通信标准，是移动通信技术的第四代（4G）。LTE提供高速数据传输、低延迟和更高的网络效率，旨在满足日益增长的移动数据需求。

⑥网络连接：网关连接不同的网络，比如一个企业的内部网络与互联网。它使得内部网络设备可以通过网关访问外部网络

⑦ SIMD使用单个指令对具有相同类型和大小的多个数据元素并行执行相同的操作。

2. Introduction

由特斯拉 [1]、Waymo [2]、保时捷 [3] 和丰田 [4] 等公司推动的自动驾驶和电动汽车的兴起正在将汽车重塑为“车轮上的智能手机”[5]。随着这种转变的展开，在这些车辆和云之间创建可靠的连接变得越来越重要。从车辆到云端的视频流解锁了许多新颖的应用，从车载娱乐和游戏到需要更高可靠性和性能的关键任务。例如，远程驾驶（ToD）[6,7]是一种在算法无法有效处理复杂情况时远程操作自动驾驶汽车的机制[8]，需要将高清摄像头从车辆实时传输到云端。另一个应用是远程诊断进程[9,10]，医疗保健专业人员指导护理人员远程进行紧急治疗。通过将救护车内部的高清视图以及患者的生命体征传输到云端，这些程序可以成为现实。

实现上述新应用的根本挑战是如何在车辆行驶时通过高度波动的蜂窝链路持续支持高比特率、低延迟的视频流。然而，我们面临着两种相互矛盾的情况：

① 高延迟和脆弱蜂窝链路的速率有限。 众所周知，蜂窝连接是脆弱的，许多因素，如靠近蜂窝塔和障碍物，都会影响其带宽、抖动和损耗[11,12]。有限的覆盖范围通常会导致有限的数据速率和高数据包延迟。 此外，当车辆行驶时，它很容易发现自己处于细胞“死角”[13]。5G的出现并没有解决这个问题。由于5G信号的工作频率高于4G，因此它们受到更大的波动和衰减，导致覆盖范围更小[14,15]。

②数据密集型和低延迟的车辆应用。 在延迟和带宽方面，新兴的车载应用可能比传统的实时应用（如VoIP和视频会议[16,17]）要求更高，后者通常需要300Kbps-2Mbps，延迟<300ms。以ToD为例，为了让车辆清晰地“看到”周围环境，具有足够的感知深度，它必须依靠许多高清摄像头的聚合视图，要求在100ms的单向延迟下<∼30Mbps[18,20]。

今天部署的汽车到互联网解决方案[21–23]，如威瑞森连接汽车和特斯拉高级连接，受到单一运营商的覆盖范围的限制。因此，它们遭受频繁的信号丢失和有限的链路速率[24,25]。过去关于车辆连接的研究方案[26-28]侧重于下载非实时负载，而不能为实时的高吞吐量流量提供服务。

在本文中，我们介绍了 CellFusion 来应对新出现的挑战，并首次实现连续、高质量、低延迟的车到云视频流。我们的想法是超越单个蜂窝网络的限制，构建一个弹性覆盖的最后一英里，有效地将多个异构蜂窝网络融合到云中。为了实现这一想法，CellFusion协同了两个领域：多路径传输和网络编码。（multipath transport and network coding）

首先，CellFusion构建了一个新颖的软硬件系统，该系统聚合了多个异构蜂窝网络资源（§3），如图1（a）所示。它在车辆中部署了一个专门的车载客户端设备（用户终端设备）（CPE）盒（§5），如图2所示。并在CDN接入点（PoP）（§6）部署一组分布式边缘代理，以在顶部创建多路径隧道。 如图1（b）所示。我们的实施聚合了来自三家运营商的四个蜂窝网络，结合了 5G 和 LTE。通过这种方式，CellFusion包含两种类型的多样性：（1）不同运营商的地理多样性和（2）不同技术的频率多样性，从而实现多样化的蜂窝覆盖。因此，CellFusion通过利用相互补偿的多样化细胞资源，显着降低了细胞“死点”的可能性。


其次，CellFusion引入了XNC，如图1（b）中的蓝色和绿色部分所示，以有效地将这些底层网络资源融合到云中（§4）。车辆到云流中多路径传输的一个基本问题是，当车辆行驶时，每个蜂窝链路都变得高度不稳定且不可预测，这使得很难确保数据包在截止日期之前延迟[29]。正如我们稍后所展示的，高速车辆的蜂窝链路会遭受高达 100% 的严重突发损耗和可能意外达到几秒钟的高延迟峰值。通常，多路径调度器会预测路径特征（如带宽和延迟），以选择传输数据包的路径。因此，当路径变得波动时，调度器可能会对路径做出错误的预测，而该路径可能会在以后降级，从而导致过多的延迟和带宽资源利用率低[30,31]。为了解决这个问题，XNC利用网络编码，通过与多路径的独特合作，跨时间混合数据，以获得针对脆弱蜂窝链路的弹性和效率。

尽管网络编码[32,33]和多路径[30]传输是相对成熟的研究领域，但过去的解决方案在车到云流方面本质上是无能为力的。首先，传统的基于网络编码的协议，如FEC [34]、COPE [32]、随机线性码[35]、TCP-NC [36]、演化码[26]、LT码[37]、PACE和流码[39]等，由于以下一个或多个原因而存在不足：（1）为随机或有界损失设计的代码在恢复重度突发损失方面表现不佳。（2）编码引入了高延迟，因为中继节点（例如CPE）必须等待足够的数据包来执行块编码，（3），代码带来了大量的冗余流量成本，并降低了有效视频传输的带宽。（4） 代码的计算成本太高，无法在高比特率下使用。其次，目前部署的多径传输，如MPTCP [40]、MPQUIC [41]和XLINK [29]，被设计为完全可靠的传输，因此，它们在发送实时流量时会在高损耗下造成过多的延迟。

CellFusion的XNC引入了多种创新手段，可同时应对上述挑战。在基础传输层，XNC没有使用可靠的QUIC [42]，而是利用新标准化的QUIC-Datagram [43]作为不可靠的介质，并集成了多路径功能（§4.2）。 在此过程中，它尽可能多地重用已经存在的 QUIC 传输功能（例如，拥塞控制、加密、中间盒遍历）。在基础层之上，XNC引入了一种部分可靠的传输机制，包括**基于QUIC的随机线性网络编码（Q-RLNC）（§4.3），QoE感知丢失检测（§4.4）和机会性单次恢复（§4.5）。**简而言之，XNC 基于 QoE 感知策略快速检测视频丢失，并通过重新传输足够数量的丢失数据包的随机线性组合（方程）来利用所有路径的瞬时备用容量，从而通过机会性的一次性恢复最大限度地提高其恢复概率。正如我们将在本文后面展示的那样，XNC 的设计具有以下良好的特性：

• 对突发性损失的鲁棒性。 我们的方案不是直接前向纠错（direct forward error correction），而是通过Q-RLNC重新传输丢失的数据包，Q-RLNC具有非常灵活的冗余率，可以实时匹配不可预测的丢失率，因此XNC对重度突发丢失具有很强的鲁棒性，甚至可以达到100%的丢失率。
• 对不可预测的多路径具有弹性。 每个编码的数据包都等效于丢失数据包的线性方程。只要接收器获得足够的方程，它就可以恢复整个丢失的范围。通过这种方式，XNC大大减少了“错误”路径调度的影响，因为编码数据包对任何路径的丢失影响都变得相同，并且可以在另一个方程到达时立即补救。
• 低延迟的动态编码。 在我们的方案中，一个新的数据包被立即转发，而编码只应用于丢失的数据包。因此，在编码之前不需要额外的延迟来积累一个代码块。我们的重传方案是一次性的，并且机会性地使用路径的瞬时备用容量，因此我们也避免了由于编码数据包消耗的带宽而延迟新数据包。
• 低冗余和低复杂性。 我们的方案基本上是一个系统化的代码，主要包含原始数据包。因此，在良好的网络条件下，它实现了几乎零的流量冗余，没有损失。此外，我们的编码方案可以在嵌入式系统上使用SIMD指令有效地加速。

在架构上，CellFusion被设计为连接即服务解决方案（§6）。CellFusion的后端是云原生的。由于我们的传输堆栈具有用户空间特性，部署CellFusion的代理就像在边缘云上运行轻量级容器一样简单，该容器可以轻松自动扩展和管理，以增加容量并提供高度可用的边缘访问。重要的是，CellFusion本质上是安全和透明的。与过去的split-TCP [44]等工作不同（这个工作会破坏用户的连接），CellFusion对原始IP数据包进行隧道传输，因此它在后台透明地运行并保留了原始流量的安全性。作为 IP 隧道，CellFusion 支持广泛的乘客协议，包括 RTP/RTCP、RTSP 和 HTTP。

结果： 我们已经在 100 辆自动驾驶汽车上测试了 CellFusion 超过六个月，我们的后端在三个州的 50 个 CDN PoP 上运行。部署照片如图2（c）所示。通过广泛的道路测试评估，我们发现XNC在73.8ms时实现了第99个百分位的视频数据包延迟，与5G相比降低了71.53%。在5000km行驶距离内以30Mbps和30fps的速度流式传输视频时，CellFusion的平均帧率、视频失速率和归一化结构相似性指数测量（SSIM）得分分别为29.11fps、0.99%和0.93，流量冗余率低于10%。与最先进的多径传输解决方案相比，它实现了 66.11% ∼ 80.62% 的视频失速率降低。

贡献： 据我们所知，CellFusion是第一个支持高质量、实时车辆到云的实时实时流的系统，满足当今的ToD要求。CellFusion的核心技术贡献在于我们的设计、实施和云原生解决方案，该解决方案独特地协同了多路径传输和网络编码。我们介绍了详细的软硬件设计和XNC传输算法。我们相信，CellFusion在云和CDN提供商的广泛部署方面具有巨大的潜力。CellFusion在通用范围内提供连接即服务，可以提供塑造移动未来所需的强大流媒体基础设施。

3.Background and Motivation

3.1 Teleoperated driving for autonomous vehicles

预计到2030年，全自动驾驶的市场规模将达到2.3万亿美元[45]。然而，尽管大公司和众多初创公司在过去十年中投入了数十亿美元，但它还没有接近大规模的商业部署[46]。真正的差距是所谓的“无穷无尽”的边缘情况[47]：能见度差、临时绕道、倒下的树木、道路上的天坑和意外事件等情况可能超出当今算法的能力，并造成损坏、伤害甚至死亡。

远程驾驶（ToD）[6,7,48]，当需要人类经验时，允许远程操作员远程干预和控制车辆，是一项新兴技术，被视为当今自动驾驶遇到的各种问题的答案，特别是在算法仍在学习的早期阶段。目前，一些倡议、项目和协会正在研究ToD的详细用例和要求，包括欧盟的5GMobix和5GCoCor [49]，以及5G汽车协会（5GAA）[19]。

然而，ToD 的成功很大程度上取决于我们支持高质量、高比特率和实时车辆到云视频流的能力，以首先捕获车辆的 360o 视图。5GAA 需要支持 ∼ 30Mbps 的视频比特率和 <100ms 延迟。5GCoCor 需要 8-30Mbps 的上行链路和 <80ms 的延迟才能进行间接控制。虽然ToD对于实现自动驾驶时代至关重要，但上述要求是有远见的，超出了当今车辆解决方案的能力。

3.2 Challenges in vehicle-to-cloud streaming via a single cellular link

为了了解这些挑战，我们描述了 5G 和 LTE 中的蜂窝链路，当实时视频从移动的车辆上传到云服务器时。在我们的测量过程中，我们通过单个蜂窝链路以 30fps 的比特率流式传输 RTSP（Real-Time Streaming Protocol，即实时流传输协议） 视频，以 10Mbps 和 30Mbps 的比特率进行实验。
这些实验是在典型的大都市地区驾驶车辆时进行的。对于流会话期间的每一秒，我们从蜂窝模块驱动进程的物理层收集了两种类型的信号指标：接收信号接收功率 （RSRP） 和信号干扰比和噪声比 （SINR）。
在传输层，我们利用 appPacketID 和 timestamp 字段确定了每秒丢包率和数据包延迟。丢包率的计算方法是将接收到的应用进程数据包数 （recv_app_pkt_cnt） 除以 appPacketID 字段的范围。数据包延迟计算为接收时间和发送时间之间的差值。
在应用层， 我们计算了 Appx C中定义的 QoE 指标。我们在图 3 中的测量结果显示：

• 信号覆盖不稳定。 图3（a）显示，RSRP和SINR都表现出显着的随机波动，在几秒钟内变化可能超过30dB。我们还注意到，5G的信号比LTE经历了更明显的波动，5G的SINR在3分钟内多次下降到0dB。这些观察表明，当车辆行驶时，蜂窝信号覆盖范围变得非常不稳定。
• 严重的突发丢失和较大的延迟峰值。 图3（b）和图3（c）分别显示了传输层测得的丢包率和单向延迟。在损耗方面，5G和LTE链路都出现了严重的突发损耗，可能高达100%，持续数十秒。关于延迟，5G和LTE都遭受了许多延迟峰值，可能长达几秒钟。更令人惊讶的是，由于覆盖范围缩小，5G的损耗和延迟有时甚至比LTE还要严重。随着视频比特率的增加，丢失和延迟也变得更糟。
  -
• 视频QoE不佳。 图3（d）显示了相应的视频QoE测量值，包括每秒帧数（FPS）、视频失速比和SSIM分数。不出所料，在如此严重的突发损失和高延迟峰值下，所有案例都出现了帧率降低、视频失速率高、SSIM分数低等问题，导致用户体验不尽如人意。
• Remark： 因此，5G 链路和 LTE 链路都无法始终如一地支持超过 10Mbps 的实时流媒体。值得注意的是，**严重的突发丢失与传统的数据包擦除信道中轻微的随机丢失概念有很大不同，这使得许多过去的编码方案无效。**了解这些细胞特性对于设计正确的传输解决方案至关重要，并促使我们重新思考传输层设计。

4. OverView

为了解决车到云流媒体中蜂窝信号的不可预测性，我们推出了 CellFusion。CellFusion的高级端到端架构如图1（a）所示，该架构分为三个域：（1）由视频客户端（发送方）和CellFusion CPE组成的车辆域，（2）由多蜂窝网络和CellFusion边缘代理服务器组成的边缘域，以及（3）托管CellFusion控制器和云应用进程（接收器）的云域。下面，我们将介绍它们的功能，然后是图1（b）所示的CellFusion的数据包流。

4.1 Core components

CellFusion CPE： 一种安装在车辆上的专用硬件，作为车载局域网到互联网的分组（packet）网关。它有四个蜂窝模块，可以在异构移动运营商上实现多路径传输。
CellFusion 代理服务器： 代理服务器是分布在云边缘 PoP（接入点） （CDN） 上的容器进程，用作车辆到云流量的边缘接入点。
CellFusion 隧道客户端： 在 CellFusion CPE 之上运行的进程。它设置多路径 QUIC （MPQUIC） 客户端。在上行链路中，它是不可靠的多路径 QUIC 隧道的起点，它驱动 XNC 的客户端堆栈执行数据包编码、丢失检测和丢失恢复。
CellFusion 隧道服务器： 在 CellFusion 代理服务器中运行的进程。它设置多路径 QUIC 服务器。在上行链路中，它是不可靠的多路径 QUIC 隧道的终点，它驱动 XNC 的服务器端堆栈执行数据包解码和转发。
CellFusion控制器： 控制器部署在中央云上，作为CellFusion的控制和管理面。

4.2 CellFusion’s packet flow

在车载域中，视频客户端（发送方）通过CPE发送发往云应用（接收方）的原始IP报文。这些数据包从CPE的虚拟TUN接口捕获到用户空间的隧道客户端中，然后传递给MPQUIC客户端。QUIC 堆栈中的 XNC 将数据包封装为 XNC 数据包中，从而扩展 QUIC-Datagram。XNC 在触发丢失重传时应用网络编码，并立即转发首次到达的数据包。tunnel-client 的输出是 QUIC 数据包，其目标 IP 指向代理服务器，并通过多蜂窝接口传输。
在边缘域中，代理服务器接收的数据包将传递到 MPQUIC 服务器。QUIC 堆栈调用 XNC 来解码 QUIC 的有效负载并提取原始 IP 数据包。然后，解码后的 IP 数据包将发送到虚拟 tun 接口并转发到云应用。在数据包离开代理服务器之前，将应用源 NAT，以便将来自云应用的返回流量路由到代理服务器。
上述流程有效地构建了透明的多路径覆盖隧道。因此，CellFusion 不需要从视频客户端或云应用进程进行修改。视频客户端和云应用进程之间的 IP 数据包可以进行端到端加密，CellFusion 将无法破译其内容。CellFusion 进一步增加了 QUIC 的 TLS 加密 （传输层安全协议） 和报头保护机制的额外层，因此安全性永远不会受到损害。

4.3 Organization of the following sections

在下面的章节中，我们首先介绍XNC的设计，这是我们在QUIC(4)之上的基于核心网络编码的多路径传输。然后我们描述了CellFusion的CPE硬件设计(5)。之后，我们将展示CellFusion的云原生后端服务(6)。最后，我们讨论了我们目前对CELLFUSION的部署和评估（7,8）。

5. XNC DESIGN

5.1 Logical description

目标 A 意味着 XNC 不应该像 TCP 那样完全可靠，因为 TCP 存在行头阻塞问题。因此，在基础层，XNC 创建在 QUIC-Datagram（是QUIC不可靠的版本) 之上。基础层提供基本的构建块，例如加密和拥塞控制。关于目标 B，XNC 将多径 QUIC 特征与 QUIC-Datagram 相结合。多路径调度是在数据包级粒度上完成的，以允许同时传输的路径聚合。

给定目标 C，我们还需要一个部分可靠性机制来对抗不可靠的多径 QUIC 之上的损失。有两种基本方法：主动方法（在首次传输原始数据包时发送前馈冗余数据包）和反应方法（执行基于反馈的丢失恢复）。 主动方法不适合严重的突发丢失，因为要克服许多连续数据包的丢失，它需要非常高的冗余率。但是，由于几乎不可能预测何时会发生丢失以及丢失多少数据包，因此即使丢失率很低，也必须始终如一地应用如此高的冗余率。这导致了高冗余和令人望而却步的计算复杂性，违反了目标 D。然而，反应方法的问题在于，由于反馈回路，恢复自然会延迟。如果重新传输的数据包丢失（即丢失恢复数据包的丢失），延迟可能会进一步加剧。

因此，要使用反应式方法，我们必须缩短反馈恢复回路，提高重传成功率。 为了实现这一目标，XNC抓住了在云边缘更接近车辆的机会，并引入了三种技术来解决这个问题：基于QoE感知策略的快速丢失检测，用于重传数据包的Q-RLNC，以及提高重传成功率的机会主义一次性恢复。 我们的主要见解是，当需要重传时，应尽早触发，并通过利用编码保护和充分利用多路径资源，以最大的努力一次性执行。为了将这个想法付诸实践，首先，我们在 CDN PoP 上部署了 CellFusion 的代理，以物理方式缩短隧道的往返时间。 其次，我们根据视频的QoE要求（比特率和延迟要求）快速检测丢失了哪些数据包 ，以便尽可能及时地开始丢失数据包的重传。第三，我们首次将 RLNC 引入 QUIC 堆栈，在重传过程中，我们的 Q-RLNC 将每个重传的数据包编码为来自 QUIC 上一系列丢失数据包的随机线性组合。我们应用Q-RLNC是因为以下良好的特性：

• 它具有灵活的编码范围，不限于固定长度或滑动窗口。
• 它是无速率的，因此 XNC 可以对任何范围的任意数量的数据包进行编码。
• 每个编码数据包等效于一个线性方程。接收到足够多的方程序后，我们可以恢复所有丢失的数据包。
• 它旨在与 QUIC 无缝协作。

最后，我们展示了Q-RLNC的机会主义一次性恢复的优势，它在每条路径上发送了许多随机线性方程，这些丢失数据包与该路径的瞬时可用窗口成比例。这种恢复方法通过机会性地利用每条路径的可用网络资源来利用路径多样性，并且对丢失恢复数据包的潜在丢失也具有高度的弹性。由于 XNC 将每个原始数据包的信息分散到所有可用路径上，因此当来自任何其他路径的编码数据包到达时，可以补救一条路径上的数据包故障。 请注意，实际编码仅在一系列丢失的数据包上执行。我们的编码是动态的，因为我们不需要在编码前故意积累数据包。此外，XNC在良好的网络条件下实现了几乎零冗余，并且没有损失，因此可以有效地利用带宽资源。

5.2 Base protocol

XNC 使用 QUIC-Datagram 作为其基础层协议栈，并在其上集成了多路径 QUIC 功能。QUICDatagram 是一个不可靠的 QUIC 扩展，最近由 RFC9221 [43] 标准化，而 IETF QUIC 工作组正在标准化多路径 QUIC 的可靠版本 [41]。协商多路径 QUIC 连接后，XNC 会扩展数据报帧（类型 0x30、0x31）以封装视频数据包。基于 QUIC 的 XNC 提供了几个重要的好处：

• 由于 QUIC 的用户空间特性，与基于内核的协议栈（例如内核 TCP）相比，部署和升级基于 QUIC 的协议要容易得多。
• 我们可以尽可能多地重用 QUIC 的机制，例如 TLS 1.3 加密、RTT 和带宽测量、拥塞控制和 PMTU（路径MTU发现） 发现。
• QUIC是端到端加密的，QUIC的header也受到保护[42]，这防止了WAN中间盒（NAT设备，防火墙）检查它。这样的属性对于CellFusion的流量在不受干扰的情况下遍历公共互联网上的中间盒非常重要。

多路径调度器（Multipath scheduler） 我们默认的多路径调度器是 min-RTT 调度器，它将首次发送的数据包放在具有可用拥塞窗口的最低延迟路径上。但是，正如后面所讨论的，我们不会在机会主义的一次性恢复中使用此调度器。

拥塞控制器（Congestion controller） 我们使用 BBR [50] 作为拥塞控制器，因为它对数据包丢失具有弹性，并且能够快速获取可用带宽。

5.3 Coding scheme of Q-RLNC

5.3.1 Basic RLNC operations

RLNC [36] 在伽罗瓦场 GF （$2^m$） 中进行计算，如图 4 所示。编码时，RLNC 计算具有随机系数的原始符号的线性组合，以获得编码符号（m 位整数），因此每个编码符号等于GF （$2^m$） 中的线性方程。解码时，RLNC 通过求解线性方程组来恢复原始符号，前提是它已经接收到足够多的线性无关编码符号。
为了对数据包而不是单个符号执行 RLNC，我们将每个数据包视为 m 位符号数组，如图 5 所示。在编码之前，我们首先通过零填充较短的数据包来确保每个原始数据包的长度相等。然后，我们通过分别组合每个数组中相同索引的符号来生成编码的数据包。在 XNC 中，我们将 m 设置为 8，其中符号的长度为 1 个字节。选择此值是为了启用 GF （$2^m$） 算法（§5.2） 的 SIMD 加速度。

5.3.2 Packet format

编码的数据包必须携带有关线性组合的信息，以便接收方执行解码。在 XNC 中，我们始终对一系列连续数据包应用 RLNC，以便我们可以将此类信息编码为XNC_Header,如图 6 所示，图 6 由三个 32 位整数字段组成：

• packetCount：连续范围内的数据包计数，用于对该数据包进行编码的原始数据包。
• randomSeed：用于生成串行的随机种子的随机系数来编码该数据包 [51]。
• startID：原始序列中第一个报文的 ID，用于对该数据包进行编码的数据包。

发送方和接收方需要就相同的随机系数达成一致，因此在连接协商时，我们在发送方和接收方上初始化两个相同的伪数生成器（记为𝑔），得到𝑔生成的系数序列，种子值𝑠为{𝑔𝑠(1)，𝑔𝑠(2)，…}，∀𝑠，𝑖，𝑔𝑠（𝑖）∈𝐺𝐹（$2^8$）\ {0}。假设𝑝𝑘为ID为𝑘的原始包，𝑝为编码包，包计数、随机种子和startID的值分别为𝑛、𝑠、𝑘，则：

一个特殊的情况，如上所示，是当𝑛=1。在这种情况下，𝑝等于原始包。𝑝𝑘，𝑠被忽略。我们将在Appx A中讨论关于我们的编码算法的更多细节。

5.3.3 Enabling RLNC in QUIC

XNC 将编码器和解码器实现为 QUIC 堆栈调用的软件模块，我们在图 7 中说明了工作流程。数据包的编码和解码在 QUIC 的数据报层之上执行。具体来说，在发送方，传入的数据包首先在编码器模块中填充和注册，然后才能用于编码。在此过程中，编码器模块将每个原始数据包的副本保存在其数据包池中，并分配数据包编号和时间戳。为了发送数据包，QUIC 层调用编码数据包的编码器 API，并将其封装到 QUIC-Datagram 帧中，该帧由新类型 XNC_NC （0x32） 标记 ，如图 6 所示。在接收器端，接收到的XNC_NC帧的有效载荷被传递到解码器模块。每次将有效负载传递到解码器模块时，XNC 都会为任何可能解码的原始数据包调用解码器 API。解码器从其数据包池中获取方程（矢量），通过高斯消元法减少矢量，并存储约化的结果。解码新数据包后，解码器会将其交给 QUIC 堆栈。

5.4 QoE-aware loss detection

XNC 将 QUIC 的默认丢失检测策略替换为 QoE-aware 丢失检测策略，以加速上述恢复过程。其背后的基本原理是，实时视频帧只有在应用进程截止日期之前交付时才有用，因此应立即重新传输具有高风险超过截止日期的数据包。

5.4.1 Set threshold for loss detection

XNC 应用新的丢失检测阈值，**该阈值是应用进程定义的时间阈值和 QUIC 的 PTO [52] 的较小值，**因此，在此阈值之后未确认的任何数据包都将被标记为“丢失”并添加到重传队列中。应用进程定义的时间阈值根据应用进程的端到端延迟需求进行调整。 请注意，我们修改后的损失检测使 XNC 的损失恢复比传统的 QUIC 更具侵略性。但是，拥塞窗口有助于限制 XNC 的飞行中数据包总数，并保持其对其他用户的友好性。

5.4.2 Determine encoding range borders among lost packets.

XNC 进一步将重传队列中丢失的数据包划分为连续范围，我们分别在这些范围内应用 Q-RLNC。每个范围都跨越一个连续的数据包串行。Q-RLNC根据视频流和计算成本的要求生成范围。首先，应同时恢复属于同一视频帧的丢失数据包。为了更有效地使用带宽，XNC 要么恢复一个完整的帧，要么不重新传输该帧中的任何数据包;其次，范围过大也是不可取的，因为它可能会在编码过程中引入额外的延迟并增加计算复杂性。在 XNC 中，我们检查三个条件，以相应地在最近发送的数据包之后插入范围边界。

因为XNC对应用程序的流量是透明的，并且可能不总是检测加密用户流量中的帧边界，所以第三个条件被设置为一个选项。在实践中，对于30Mbps的视频会话，我们将𝑟设置为10，𝑡设置为60 ms。

5.4.3 Expiration of ranges and lost packets.

与在成功传送之前跟踪丢失的数据包的完全可靠的传输不同，XNC 仅跟踪给定时间段内丢失的数据包。
因为恢复过期的视频数据包不会增加视频 QoE，而是延迟新数据包的传输。
在 XNC 中，我们使用可配置的与应用进程相关的时间阈值 $t_{expire}$ 来确定数据包是否过期。如果编码范围内的最后一个数据包已过期，则该范围已过期。在这项工作中，我们经验地将$t_{expire}$设置为700ms。

5.5 Opportunistic one-shot recovery

定义了编码方案(5.3)和范围边界(5.4)后，我们现在指定了 XNC 的机会主义单次丢失恢复的行为，其目的是利用所有路径的瞬时可用带宽来最大限度地提高一次性恢复率。

5.5.1 计算编码数据包的最小数量𝑛′

假设在某个范围内检测到 n 个数据包丢失，XNC 首先计算 XNC 接收方恢复该 n 个丢失数据包所需的编码数据包 n ′ 的数量。我们注意到 n ′ ≠ n。理想情况下，我们可以提供正好 n 个线性独立编码的数据包来解码所有 n 个原始数据包。但是，由于 XNC 使用随机系数对数据包进行编码，因此无法绝对保证生成的每个数据包子集的线性独立性。因此，我们必须传送 n ′ > n 个数据包。幸运的是，在我们的随机系数抽样方案下，我们只需要少量的额外数据包即可获得 n 个独立的数据包。从理论上讲，我们可以证明：

如果发送𝑛’ =𝑛+𝑘个编码包成功，则XNC解码成功的概率至少为

证据可以在 Appx B中找到。根据上面的结果，如果n > 1，我们设 n ′ = n + 3。选择该值是为了平衡带宽开销和解码概率。
当 n = 1 时，编码范围只包含一个数据包，因此接收方不需要解码，因此我们设 n ′ = 1。（特殊情况）

5.5.2 One-shot recovery

在得到 n ′ 后，XNC 将每个可用路径上所有可用的拥塞窗口相加，用 b 表示。如果 b < n ′ ，则恢复操作延迟。XNC 可以在丢失的数据包到期之前的任何时间执行恢复 （§5.4.3）。
如果有足够的可用拥塞窗口（即 b ≥ n ′ ），XNC 最多分发b 个编码的数据包到所有可用路径上（与每个路径的可用窗口大小成正比）。
进一步限制在每条路径上发送的数据包数小于 ρ × n ′ ，其中 1 < ρ < 1.2。
当 n = 1 时，我们只需在每个可用路径上发送一个数据包，以最小化延迟。
之后，XNC会忘记恢复操作中涉及的任何丢失的数据包。

6. CellFusion CPE

6.1 Customized hardware design

CellFusion的车载CPE盒是一种特殊设计的硬件，可以同时通过四个蜂窝网络进行高性能通信，如图2(a)和图2(b).所示CPE由四个子系统组成：CPU子系统、蜂窝网络子系统、接口和电源管理子系统和Wifi/LAN子系统。
对于CPU子系统 ，我们选择Rockchip RK3399 [53]作为核心CPU，它具有Cortex-A72四Cortex-A53双核。核心CPU还支持SIMD指令，这对加速XNC操作是至关重要的。
蜂窝网络子系统 有2个Quectel RM500Q-GL [54]作为5G模块，2个Quectel EP06-E [55]作为LTE模块。我们使用MIMO（多输入多输出）来进一步提高蜂窝网络的性能：5G模块有2个TX(输入天线)/4个RX（输出天线）天线，LTE模块有1个TX/2个RX天线。
Wifi/LAN子系统用于连接车辆内的视频流源。 CPE的峰值功耗小于50W，待机功率小于25W。

6.2 Acceleration of XNC

为了实现高比特率的视频传输，尽可能高效地执行网络编码至关重要。回想一下，在 XNC 中，每个数据包都被视为一个 m 位符号数组，并且通过将每个数组中相同索引的符号单独组合来生成编码数据包，这些符号可以并行计算 （§4.3.1）。我们使用 ARM NEON 高级 SIMD 指令 [56] 执行 RLNC 以利用这种并行性。 在 XNC 中，我们借助 vmull_p8（8 位多项式乘法）NEON 固有函数实现 8 路 GF（$2^8$） 乘法。此外，GF （$2^8$） 中的加法只是位级 XOR，可以由编译器自动矢量化。借助 SIMD，我们的 CPE 盒子支持 30Mbps 的视频流，CPU 使用率< 20%。

7 CELLFUSION’S BACK-END SERVICE

7.1 Cloud-native architecture

我们设计了CellFusion的后端，采用易于部署和管理的云原生架构。后端由两部分组成：CellFusion 代理服务器和 CellFusion 控制器。
代理服务器。 为了减少访问延迟，CellFusion代理服务器部署在云的边缘（即CDN）。QUIC 的用户空间特性允许我们将它们部署为在 CDN PoP 上运行的容器。容器化使自动缩放这些代理服务器可以轻松满足需求变化，从而提供良好的可伸缩性和成本效益。
控制器。 CellFusion的控制器实现了控制平面，并部署在中央云中。它有五个主要功能：
（1）它对CPE设备进行身份验证，以便只允许合法用户访问该服务。（2） 它管理CellFusion的CPE和代理服务器的配置，在设置多路径隧道和XNC之前获取必要的配置参数。
（3）负责实现高可用性。控制器持续监视每个代理服务器的运行状况和负载，并在需要时执行故障转移。
（4） 它充当编排器，根据服务器的可用性和负载将 CPE 指示到它应该连接到的多个服务器。CPE 测量这些服务器的网络延迟，并选择延迟最小的服务器。

7.2 Multi-tenant

每个代理服务器都旨在为许多用户提供服务，以降低部署成本。因此，CellFusion 隧道服务器实现了多租户支持。当多辆车连接到同一个代理服务器时，控制器将为其 CPE 的虚拟 TUN 接口分配一个唯一的私有 IP 地址，以对通过它的每个数据包执行 Source-NAT。这样一来，来自同一 CPE 的视频数据包将具有相同的源 IP 地址，并且服务器将在来自其他 CPE 的数据包中看到不同的源地址（解封装外部标头后）。利用这些独特的信息，我们构建了一个映射表，将 CPE 的地址与其隧道客户端在服务器上的 QUIC 连接 ID （CID） 相关联。
这样，当服务器在返回方向上接收到数据包时，它可以通过该数据包的目标地址找到相应的 CID，并通过 QUIC 连接将该数据包发送到正确的车辆。
换句话说，在数据包流中，我们实际上使用了两次 NAT，第一次是在 CPE 的 tun 接口，第二次是在代理服务器的公网接口。

8 IMPLEMENTATION AND TESTING IN THE WILD

Implementation details。 CellFusion的基本协议栈基于RFC9000 [57]，在此基础上，我们实现了基于RFC9221 [43]的不可靠的QUIC-Datagram，并结合了IETF WG Draft [41]的多径特性。我们将 XNC 实现为由 QUIC 堆栈调用的软件模块。整个传输是用 C 语言编写的，具有 30K LoC，只需稍作修改即可移植到不同的平台。我们的隧道客户端在 CPE 上的 OpenWRT [58] 中运行，而我们的隧道服务器在 CentOS 容器中运行。我们的控制器是一个基于 Java Spring 框架构建的 HTTPs 服务器。一个实际问题是 MTU 问题，我们在 Appx E中对此进行了讨论。
Testing in the wild。 CellFusion已经在100辆自动驾驶汽车上进行了超过六个月的测试。这种部署的照片如图2（c）所示。这些测试车辆每天都在几个大都市地区运行。CellFusion边缘访问的覆盖范围和邻近性是确保低延迟和服务可用性的关键。我们在三个州的 50 个阿里云 CDN PoP 上运行代理服务器。控制器部署在同时为 CPE 和代理服务器提供服务的中央云中。

9. EVALUATION

在本节中，我们将介绍CellFusion的评估，它由三个部分组成：

• 端到端道路测试：首先，我们展示了端到端道路测试的结果，其中我们通过CellFusion将实时高比特率视频从移动的车辆上行到云服务器。流式视频是一个特制的参考视频，使我们能够提取视频QoE指标。我们从超过 5000 公里的驾驶中收集了结果。
• 部署的统计结果：然后，我们展示了在 100 辆自动驾驶汽车上部署 CellFusion 超过六个月的统计结果。这些车辆经常在大都市地区运行，以测试自动驾驶算法。
• XNC的基准和消融研究：最后，我们进一步实施了一些最先进的多路径解决方案和编码方案，并在受控环境中进行了实验，与XNC进行了比较。我们还进行了消融研究，以验证XNC中各个组件的设计点。
  常规设置。除非另有说明，否则在路试、基准测试和消融研究中，我们使用 ffmpeg [59] 和基于 UDP 的 RTSP 协议来上行实时视频。流媒体比特率为 30Mbps，帧率为 30fps。

9.1 End-to-end road tests

9.1.1 Evaluation methods.

在这项测试中，我们的测试人员在大都市地区驾驶配备CellFusion的CPE的车辆，同时通过部署在CDN PoP中的CellFusion代理服务将参考视频上行到云中的RTSP服务器。参考视频是一个特制的视频剪辑，我们在其中为每一帧分配了一个串行号戳，因此我们以后可以将收到的视频与原始视频进行分析，以提取视频 QoE 指标，例如视频停顿（video stall）、帧率和归一化 SSIM 分数。我们将进一步讨论如何使用我们在 Appx C中开发的工具进行视频分析。我们的测试人员在不同的道路上进行了测试，总测试距离超过5000公里。

9.1.2 Other solutions used in the comparison.

在此测试中，我们还将 CellFusion 与 MPQUIC、MPTCP 和细胞键合 （BONDING） 进行了比较。请注意，BONDING 通过将视频流的 5 元组散列到蜂窝接口来对视频流执行负载平衡，因此它不使用代理服务器。为了公平地比较不同的解决方案，我们通过不同的CPE同时将视频流式传输到RTSP服务器，以便在相同的网络条件下进行评估。

9.1.3 Video trace samples.

我们首先在图8中说明了接收到的视频轨迹的采样对。顶部的视频痕迹来自MPQUIC，而底部的视频痕迹来自CellFusion。根据视频帧的序列号标记进行对齐。我们计算每秒的视频帧数来计算帧率，并进一步分析帧间隔来计算失速比。这种对齐使我们能够通过比较接收到的视频帧和具有相同序列号的参考视频帧来测量SSIM分数。如图8所示，MPQUIC的轨迹经历了阻塞和严重的视频失速，而CellFusion的视频则非常清晰、流畅，说明QoE要好得多。

9.1.4 QoE metrics.

接下来，我们展示了图 9 中端到端道路测试的整体 QoE 指标，包括帧率、失速率和归一化 SSIM 分数。在所有被测解决方案中，CellFusion的帧率最高，失速率最低，SSIM得分最高。值得注意的是，CellFusion的性能变化也比其他方法小得多。BONDING表现出最大的变化，因为它无法聚合多个链接。即使 MPQUIC 和 MPTCP 聚合链路，它们也无法在车辆行驶时处理脆弱的蜂窝链路。相比之下，CellFusion有效地融合了多个蜂窝网络，并克服了严重的突发损耗和信道不可预测性的挑战。因此，CellFusion 的平均帧率、视频失速率和归一化 SSIM 得分分别为 29.11fps、0.99% 和 0.93。CellFusion在所有QoE指标上的表现都优于比较解决方案。例如，与MPQUIC、MPTCP和BONDING相比，CellFusion的平均失速率分别降低了66.11%、69.35%和80.62%。

9.2 Statistical results from deployment

9.2.1 Evaluation methods.

在这一部分中，我们报告了CellFusion在100辆自动驾驶汽车中为期六个月的测试的统计结果。CellFusion通常用于实现远程控制和干预。在线指标的收集面临两个挑战：（1）在实际使用中，车辆上游的实时摄像头视图而不是参考视频;（2） **存储 7 个 24 小时×视频成本高昂。因此，我们没有使用视频QoE，**而是报告了在线环境中不断记录的两个指标：视频数据包延迟和流量冗余。

9.2.2 Video packet delay

图10（a）显示了使用CellFusion进行流式传输与仅使用LTE和仅5G流式传输时的视频数据包延迟的CDF。我们观察到，CellFusion显着降低了数据包延迟，尤其是在尾部。使用CellFusion时，第95、99、99.9个百分位数的延迟分别为47.4ms、73.8ms和222.3ms。相比之下，纯LTE的相应时延分别为76.1ms、267.2ms和791.9ms，而仅5G的时延分别为55.8ms、259.2ms和954.7ms。与仅5G相比，CellFusion在第95、99和99.9个百分位分别降低了15.05%、71.53%和76.72%

9.2.3 Traffic redundancy.

图10（b）显示了2022年11月1日至2023年1月10日部署在车辆中的CellFusion的流量冗余日志跟踪。每日冗余成本在 1% 到 9% 之间。这种变化源于车辆移动到具有不同网络条件的不同位置这一事实。由于 XNC 仅将网络编码应用于丢失恢复，因此只有在网络条件较差的情况下才需要冗余流量。因此，CellFusion在线使用具有很高的成本效益。

9.3 Benchmarks and ablation studies

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

9.3.1 Controlled experiment.

我们使用来自Mahimahi [60]的跟踪驱动网络模拟器的外壳构建了我们的受控测试环境。我们扩展了这个工具来支持4路仿真。使用中的痕迹是从不同道路上移动的车辆中收集的(更多的细节在Appx D中列出。).每个结果都是从一个有100条痕迹的实验中收集出来的。我们控制的测试台由同一局域网中的两个服务器组成。
在第一个服务器上，我们运行了隧道-客户端和隧道-服务器，它们通过mpshell模拟器连接。第一个服务器还托管了视频客户端（使用ffmpeg），它将视频流媒体传送到隧道客户端。
在第二个服务器上，我们部署了一个来自隧道服务器的RTSP服务器 来接收流流量，以及一个从RTSP服务器接收流的流接收器（使用ffmpeg）。在每个实验开始时，我们用指定的跟踪启动模拟器的外壳，然后在这个shell中运行隧道客户端和视频客户端 来上传一个参考视频。

9.3.2 Other solutions used in the comparison.

我们将XNC与两类现有解决方案进行了比较：多路径调度优化和多路径和网络编码解决方案。在第一类中，我们选择了四种最先进的调度器，它们可以支持 4 种路径（即调度算法是可扩展的）：minRTT 调度器 [30]、全冗余调度器 （RE） [61]、XLINK [29] 和 ECF [62]。我们注意到，该类别中还有其他解决方案仅限于 2 条路径（例如，Musher [63] 和 STMS [64]），因此本研究未选择它们。在第二类中，我们选择了Pluribus [26]，它实际上为Web流量设计了多路径传输中的网络编码。

9.3.3 Benchmark results vs. other multipath optimizations.

我们首先将 XNC 与过去的多路径调度优化进行比较。我们在图 11（a） 中显示了 QoE 指标，在图 11（b） 中显示了冗余流量成本。在本次测试的所有解决方案中，XNC的帧率最高，失速比最低，SSIM得分最高。XNC的性能变化也比其他产品小得多。其中，XNC相对于minRTT、XLINK和ECF的平均失速率分别降低了86.56%、82.22%和92.75%。尽管 RE 具有合理的平均失速率，但它需要非常高的冗余流量成本（高达 300%）。因此，当网络链路带宽受到限制时，RE无法有效地利用带宽进行传输，因此在尾部分布处，其失速率远高于XNC。相比之下，XNC以低冗余率（<10%）有效地融合了多个网络链路，这有助于它即使在尾部也能实现低失速率。

9.3.4 Benchmark results vs. Pluribus.

我们进一步介绍了将XNC与Pluribus进行比较的结果。图 12（a） 显示了 QoE 指标。我们观察到，XNC 在所有帧率、失速率和 SSIM 分数方面都优于 Pluribus。例如，与 Pluribus 相比，XNC 将平均视频失速减少了 81.67% 以上。同时，如图12（b）所示，XNC使用的冗余流量也减少了89.49%。上述结果表明，与传统的 Web 和文档传输感知解决方案相比，视频到云流是一项更具挑战性的任务，因此需要新的创新。

9.3.5 Ablation study.

我们进行了一项消融研究，其中我们研究了 Q-RLNC 和我们的 QoE 感知损失检测模块的影响。图 13（a） 显示了有和没有 XNC 的 QRLNC 的丢失率，其中我们重新传输原始数据包而不是编码数据包。Q-RLNC模块通过提高失重概率，显着降低了尾部分布处的损耗率，在第95个和第99个百分位处分别降低了15.55%和41.70%。图13（b）显示了在不同百分位数下，使用QoE感知丢失检测与不进行QoE感知丢失检测的平均数据包延迟降低。QoE 感知丢失检测在缩短数据包恢复时间方面发挥了至关重要的作用。在第 95 个和第 99 个百分位，改善分别为 8.48% 和 28.44%。

9.3.6 CPU costs of XNC.

图 14 显示了在不同比特率下通过不使用网络编码的 MPQUIC、XNC 和 SSIM 加速 XNC （SIMD-XNC） 流式传输视频的 CPU 成本。在 30Mbps 时，XNC 平均消耗的 CPU 比 MPQUIC 多 43.77%。在硬件加速的帮助下，SIMD-XNC 平均比 MPQUIC 多消耗 23.44% 的 CPU，比 XNC 降低 26.56% 的 CPU 使用率。

10. Related Work

多路径传输。 多路径传输 [40] 提供了单个连接同时使用多个路径的能力。然而，基于内核的多路径传输（如MPTCP [40]和MPUDP [65]）的采用速度很慢，因为需要操作系统级支持和中间盒僵化[30]。为了解决这个问题，人们越来越有兴趣在QUIC中引入多路径功能，但最近的提案，如IETF Multipath QUIC [41]、XLINK [29]和PQUIC [66]被设计为非实时流量的完全可靠的传输。相比之下，CellFusion旨在应对实时应用的挑战。
多路径的网络编码。 网络编码通过跨时间和流量混合数据来提高有损信道的传输可靠性[36]，过去受到广泛关注[32,33]。然而，将网络编码扩展到多路径的实际实现和实证研究很少。FMTCP[67]、ADMIT [68]和SC-MTCP [69]探讨了将FEC应用于多径的想法，但仅限于仿真或仿真。Pluribus [26] 在公司总线上试验了两条路径的演化代码，但仅限于较小的非实时负载 （<86KB） 和有限的链路速率 （<1.5Mbps）。CellFusion与以往作品的不同之处在于：（1）它解决了高移动性下高质量实时视频流的独特挑战，这是一个更复杂的问题。（2）在野外全面实施和大规模部署。
细胞键合（cellular bounding） 一些SD-WAN解决方案[70\u201272]实现了蜂窝绑定功能，这有时会与多路径传输混淆。OpenWRT 的 mwan3 [73] 也实现了这一功能。蜂窝绑定的工作原理是跨不同接口对会话进行负载均衡，这在链路故障转移时非常有用。但是，它缺乏对单个链路同时使用多个路径的传输支持，并且无法适应数据包级粒度的链路更改。相比之下，CellFusion是一种多路径传输解决方案。CellFusion可以支持更高的速率，并且对弱蜂巢连接更具弹性。
移动视频流 最近，包括比特率选择[17,74–76]、视频预处理[77,78]、QoE感知视频重新编码[79,80]、CDN放置优化[81]、使用无线AP反馈[82]和服务器端超分辨率[83]在内的各种方法已被用于视频流应用的性能增强。与这些方法不同，CellFusion在不修改终端主机应用进程的情况下优化了底层网络性能。我们的方法是与以前的工作正交的，并且可以与以前的工作一起使用。

11. DISCUSSIONS AND LIMITATIONS

CellFusion展示了将高质量的实时视频流带到车辆到云通信的新可能性。然而，我们目前的原型仍然没有一些限制，留给未来的工作。
服务器迁移。 CellFusion 在 CPE 和边缘服务器之间创建连接，以最大限度地减少通信延迟。服务器在初始化过程后保持其稳定性。但是，当车辆必须在更大的区域上移动时，就需要迁移服务器。目前，RFC9000 [42] 不支持服务器迁移，但它确实允许扩展在将来合并此功能。
超越蜂窝连接的冒险。 我们的系统创建在多个蜂窝链路之上。然而，CellFusion基于网络编码的多路径连接方法可能不仅限于蜂窝连接，并且可能适应其他无线技术，例如卫星通信。这可能会扩大其实用性，特别是在蜂窝基础设施稀疏的地区。但是，当然，要充分实现这一潜力，还需要进一步的调查和开发。

12. CONCLUSION

在本文中，我们介绍了 CellFusion，该系统可实现从车辆到云端的高质量实时视频流。CellFusion通过创新的软件硬件设计，将多路径传输与网络编码相结合，巧妙地将多个异构蜂窝网络集成到统一的云连接中。
我们在真实场景中对CellFusion进行了测试：在六个月的时间里，CellFusion被部署在100辆自动驾驶汽车上。我们的后端基础设施在分布在三个州的 50 个 CDN 接入点 （PoP） 中进行维护，我们进行了超过 5000 公里的广泛道路测试。我们的结果表明，CellFusion比当前技术具有显着的改进。我们观察到，与5G相比，第99个百分位的视频数据包延迟减少了71.53%。此外，当以 30Mbps 的速度进行流媒体传输时，与领先的多路径传输解决方案相比，CellFusion 实现了 66.11% 至 80.62% 的视频失速率降低，并且以不到 10% 的流量冗余实现了这一目标。
我们相信，CellFusion在云和CDN提供商的广泛部署方面具有巨大的潜力。CellFusion提供通用的连接即服务，可以提供塑造移动未来所需的强大流媒体基础设施。

附录A

附录 C

我们使用内部平台来分析视频流 QoE 指标。该平台包括三个部分：（i）上传参考视频的直播客户端，（ii）流媒体接收器，以及（iii）分析工具。
对于第（i）部分， 我们使用了ffmpeg [59]，它可以在许多不同的操作系统和设备上运行，作为视频流客户端。在道路测试中，视频流客户端运行在通过以太网连接到我们的 CPE 的树莓 4 [86] 上。至于参考视频，我们首先在行驶中的车辆上使用摄像头记录道路场景（30fps）。然后，我们为每个帧分配一个帧 ID。图 15 显示了三个连续帧的示例，其中标有帧 ID 1、2 和 3，分别代表参考视频中的第一帧、第二帧和第三帧。通过分析工具，使用帧标记来识别每个帧。
对于第 （ii） 部分， 我们使用了 ffmpeg 的修改版本，该版本打印了有用的信息，包括帧解码时间戳和帧状态（即正常、损坏和丢失）。在实验过程中，流接收器拉取流并将其保存为.mp4文档。
对于第（iii）部分， 我们开发了一个工具来分析接收器日志和录制的视频文档中的三个QoE指标：FPS，失速率和结构相似性指数测量（SSIM）分数：
• FPS。我们将每秒解码帧数（正常帧数）计算为 FPS。
• 失速比。失速率是根据帧间延迟间隔计算的。在我们的评估中，我们采用了流媒体服务中使用的典型值，即 200 毫秒。因此，当观察到大于 200 毫秒的帧间延迟间隔时，我们的工具会将其添加到总失速时间中。然后，它计算出失速比为：
• SSIM 分数。SSIM分数计算为参考视频与录制视频之间的结构相似性指数。但是，这两个视频可能以不同的帧 ID 开头和结尾，这使得计算正确的结构相似性指数变得困难。为了解决这个问题，我们首先使用光学字符识别（OCR）来识别录制视频的开始和结束帧ID（带有标记的标签）。然后，我们将录制的视频与参考视频对齐。最后，我们使用 OpenCV 的 API [87] 根据对齐的视频计算 SSIM 分数。

附录D TRACE COLLECTION

如8中所述，我们使用一个跟踪驱动的网络模拟器，mpshell [88]，来进行我们的控制实验。mpshell中的原始跟踪收集器（即饱和收集器[89]）通过饱和TCP流量来测量链路的容量。由于拥塞控制算法的反应性行为，这种方法并不能真正饱和波动的蜂窝链路。在这项工作中，我们使用了一个基于udp的跟踪收集器来代替。在每个蜂窝接口上，我们的收集器以一个可配置的恒定速率发送数据包，并对不同容量的5G和LTE网络作出响应。收集器接收器记录每个数据包的到达时间戳，并将其转换为与mpshell兼容的格式。

我们将5G路径的发送速率设置为100Mbps，LTE路径的发送速率设置为50mbps（上行）。我们认为这是合理的，因为100Mbps比我们的测试应用速率（30Mbps）要大得多，而且LTE的理论最大上传速率不大于50Mbps。在不同的路段上收集了100多个痕迹，用于控制实验部分。

附录E HANDLING MTU PROBLEM

在 CellFusion 中，隧道头开销（包括来自 IP 头、UDP 头、QUIC 头和 XNC 头的额外字节）最大为 60 字节，我们的设备接口 MTU 为 1500 字节。因此，要转发全尺寸（1500字节）用户数据包，CellFusion发送方必须将其拆分为两个数据包，并在接收方重新组装它们。为了避免这种情况，我们将 CPE 的 tun 接口的 MTU 设置为 1500 - 60 = 1440 字节。使用此设置，PMTU 协商后 TCP 数据包将小于 1408 字节;对于UDP数据包，我们建议用户选择较小的UDP数据包大小（例如，1300字节），就像一些流行的基于UDP的协议一样[57,90,91]。对于存在超大（>1408 字节）数据包的最坏情况，tun 接口可以通过 IP 分段自动拆分它们。然后，CellFusion将把这些分段的数据包识别为不同的IP数据包，并且不需要进一步拆分/重新组合。