ns-3 虚拟现实突发流量框架实现与建模分析

ns-3 虚拟现实突发流量框架实现与建模分析

摘要

下一代无线通信技术将允许用户获得前所未有的性能，为新的沉浸式应用铺平道路。其中，虚拟现实（VR）是典型的高数据速率和低通信延迟应用场景。本文基于从商业 VR 流媒体软件获取的流量跟踪，提出了第一个 VR 应用流量模型，使社区能够进一步研究和改进管理此类流量的技术。这项工作实现了能够生成和处理大量数据包的 ns-3 应用程序，使分析应用程序级端到端指标成为可能，源代码及 VR 流量跟踪已开源。

引言

高性能电信网络的需求不断增长，推动行业和学术界突破可实现性能的界限。国际电信联盟（ITU）提出的 IMT-2020 eMBB 要求包括峰值下行数据速率 20 Gbps 和用户平面延迟 4 ms。类似地，无线局域网（WLAN）也在挖掘毫米波频段的潜力，如 IEEE 802.11ad 和 802.11ay。

这些规范使得高清晰度无线监视器、扩展现实（XR）耳机等高要求应用成为可能。特别是 XR，作为包含 VR 和 AR 技术的总称，在消费者市场上的兴趣日益增长。为了达到人类视觉的极限，需要高分辨率和高刷新率的显示器，这对无线连接造成了巨大压力。虽然实时视频压缩技术能降低吞吐量需求，但低延迟仍是 XR 应用成败的关键。运动到光子的延迟要求最多为 20 毫秒，转化为网络延迟约为 5–9 毫秒。

原始 XR 流量可建模为周期性流量，但真实流量经过压缩和优化后，帧大小和周期都是随机的。考虑到行业对 XR 应用的兴趣及流量的特殊性，优化网络协议以支持此类流量至关重要。据我们所知，此前没有关于 XR 流量建模的工作。云游戏虽密切相关，但 XR 有更严格的 QoS 约束。文献中大多数工作集中在网络性能和云游戏的局限性，仅有少数涉及流量分析和建模。本文的创新之处在于：

1. 首个基于 90 分钟以上采集 VR 流量的应用级 XR 流量生成模型；
2. 提供灵活的 ns-3 模块模拟具有突发行为的应用程序；
3. 提供了拟议 XR 流量模型的实现及基于跟踪的模型；
4. 公开了多个 VR 流量跟踪，供研究人员使用。

VR 流量：采集与分析

第 3 节将描述的流量模型基于一组 VR 流量采集。本节介绍采集设置和统计分析。

采集设置

设置包括一台台式 PC（i7 处理器，32 GB RAM，Nvidia GTX 2080Ti）作为渲染服务器，传输信息给充当被动 VR 耳机的智能手机。两个节点通过 USB 绑定连接以避免干扰。

为了流式传输 VR 流量，渲染服务器运行 RiftCat 2.0 应用，连接到智能手机上运行的 VRidge 应用。此设置允许用户在 SteamVR 平台上玩 VR 游戏长达 10 分钟。应用设置包括显示分辨率（1920×1080p）、帧速率（30 FPS 或 60 FPS）和目标数据速率（1 到 50 Mbps）。

为简化分析，未进行 VR 游戏操作，仅从 SteamVR 候诊室获取无音频痕迹。为了让 SteamVR 完全启动，每条轨迹被削减到大约 550 秒。我们注意到编码器能在场景静止时减小流大小，手机的小动作足以获得接近目标的数据速率。

流量轨迹使用 Wireshark 获取，运行在渲染服务器上嗅探 USB 连接。流量分析以 30 和 60 FPS 的速度进行，目标数据速率为 {10, 20, 30, 40, 50} Mbps，总计超过 90 分钟的 VR 流量。

流量分析

通过分析数据包跟踪，发现 VRidge 在 IPv4 上使用 UDP 套接字。上行链路（UL）流包含同步、视频帧接收信息和头跟踪信息包。下行链路（DL）则包含同步、确认和视频帧数据包突发。应用流基于 ENet，即 UDP 之上的简单网络通信层。

视频流量是数据传输的主要来源。视频帧被分割成多个较小的 1278 B 数据包发送。通过对 UDP 有效载荷位进行反向工程，识别出 31 B 应用层报头中的 5 个信息范围：帧序列号、片段数、片段序列号、总帧大小和校验和。这使得我们能够可靠地收集视频帧信息。

图 1b 显示 UL 流量占比很小，非视频 DL 流量也极少，因此在分析中被忽略。考虑到目标数据速率 R 和帧速率 F，平均视频帧大小接近理想值 S = R/F。

平均帧间到达（IFI）与预期的 1/F 完美匹配。

通常视频压缩利用帧内和帧间技术。I 帧类似静态图片，P 帧利用时间相关性，B 帧利用前后帧知识。H.264 标准定义了图片组（GoP）。流量跟踪显示 GoP 不是确定性的，较低的目标数据速率下 GoP 往往更大。由于映射策略专有，我们只能观察总体趋势。

流量模型

本节描述如何建模帧大小和帧间周期。

建模帧周期性

为了生成真实的帧周期，需要帧周期的分布、参数、连续周期相关性以及当前帧大小与周期的相关性。为简化模型，假设帧大小和周期独立，随机过程不相关。在所有测量中，Logistic 分布通常是最适合的。

因此，我们将帧周期建模为独立同分布的 Logistic 随机变量 X ~ Logistic(μ, s)，概率密度函数为： $$ f(x; \mu, s) = \frac{e^{-(x-\mu)/s}}{s(1+e^{-(x-\mu)/s})^2} $$ 其中 μ 是位置参数，s > 0 是尺度参数，E[X] = μ，std(X) = sπ/√3。

鉴于预期周期和经验周期的一致性，设置 E[X] = μ = 1/F。为了建模标准差，需处理获取的数据。对于足够强大的渲染服务器，标准偏差应与帧速率成反比。

图 2a 显示了 30 和 60 FPS 下的平均标准差。30 FPS 时为 2.7855 ms，60 FPS 时为 1.3646 ms，比率约为 2.04。这表明 IFI 的标准偏差几乎随帧速率减半而加倍。虽然数据不足以稳健泛化，但表明更高的帧速率 F 产生较低的 IFI 标准差 d，遵循逆定律：d = c/F。计算平均值 c = 0.0827。

建模帧大小

我们提出用混合高斯模型（GMM）建模视频帧大小分布，即 V(S) ~ GMM(μ(S), σ²(S))。

显然，均值较低的拟合正态变量与 P 帧相关，均值较高的与 I 帧相关。为了推广模型，GMM 参数应扩展到任意目标数据速率。从获取的流量轨迹 GMM 开始，I 帧和 P 帧的平均帧大小通过线性模型概括，标准差通过幂律拟合。

由于接近零的目标数据速率要求视频帧也接近零，强制线性拟合无截距。即 μ_I(S) = s_I * S, μ_P(S) = s_P * S, σ_I(S) = a_I * S^b_I, σ_P(S) = a_P * S^b_P。

为了使模型更鲁棒，首先用随机初始条件对 GMM 进行 50 次拟合，选择最佳模型，然后按拟合优度加权参数的线性拟合。为了提高可靠性，使用经验数据率作为自变量而非目标数据率。

图 2b 显示 GMM 均值在 S 域中由线性模型很好地拟合，得到参数 s_I = 1.1764 和 s_P = 0.9008。拟合斜率得出 w_P = 0.64。另一方面，GMM 标准差拟合较噪，得到参数 a_I = 26.2065, b_I = 0.5730, a_P = 9.0399, b_P = 0.6251。这表明平均帧大小 S 与 GMM 标准差之间存在近似平方根关系。

帧大小独立于混合模型抽取，而不是模拟 GoP，因为不同目标数据速率下发现了不同的 GoP。

ns-3 实现

为了在模拟网络上正确建模和测试 VR 流量性能，ns-3 中实现了一个灵活的应用程序框架并公开提供。该框架基于 ns-3.33 版本。

提出的框架允许用户通过 BurstyApplication 发送分为多个数据包的数据包突发，然后在可能的情况下，通过 BurstSink 在接收器处重新聚合。由于数据包突发的生成至关重要，定义了一个通用的 BurstGenerator 接口。用户可以扩展该接口实现任意生成器。每个片段都包含一个新的 SeqTsSizeFragHeader，其中包括关于片段和当前突发的信息。

突发应用

受获取的流量跟踪启发，BurstyApplication 定期发送被分割为多个较小片段的数据突发。突发统计信息的生成被委托给扩展 BurstGenerator 接口的对象。还实现了 BurstyHelper 以简化生成和安装。

每个片段携带 SeqTsSizeFragHeader，它是 SeqTsSizeHeader 的扩展，添加了片段序列号和组成突发的片段总数等信息。设置所需的 FragmentSize 后，应用程序将计算生成的碎片数量。

跟踪会通知用户何时发送片段和突发，同时跟踪发送的数量，便于直接计算高级度量。

突发生成器接口

通用 bursty 应用程序可能显示极其不同的行为。例如，应用程序可以以确定的方式周期性地发送数据，或者突发大小或周期可以是随机的。为了适应最广泛的可能性，定义了 BurstGenerator 接口。扩展类必须定义两个纯虚函数：

1. HasNextBurst：确保突发生成器能够生成新的突发大小和下一个周期；
2. GenerateBurst：生成当前突发以及下一个周期（如果存在）的大小。

三个扩展类被提出：

• Simple Burst Generator：受 OnOffApplication 启发，将当前突发大小和下一个周期定义为通用 RandomVariableStreams。局限性在于生成的随机变量的相关性。
• VR Burst Generator：第 3 节中提出的模型的直接实现，其中突发模拟视频帧。可以选择目标数据速率和帧速率。为了生成帧大小和下一个周期，在 ns-3 中加入了 LogisticRandomVariable 和 MixtureRandomVariable。
• Trace File Burst Generator：用户可能希望在 ns-3 中重现流量跟踪。引入了 TraceFileBurstGenerator，利用 CsvReader 解析文件。StartTime 属性允许控制使用文件的哪一部分。

突发接收器

对于已开发的 bursty 框架，提出了对现有 PacketSink 的修改，称为 BurstSink。这个新的应用程序希望从配备了 Bursty 应用程序的用户那里接收数据包，并尝试将片段重新聚合成数据包。

创建 BurstSink 的原因有两个：强调此框架对 UDP 而非 TCP 套接字的依赖，以及在片段和突发级别上跟踪接收。应用程序实现了一个简单的尽力而为聚合算法，假设突发传输持续时间比下一个周期短得多，且所有片段都需要来重新聚合突发。如果后续突发的片段在前一个突发的所有片段之前收到，则丢弃前一个突发。

模型验证与用例

本节介绍获取的虚拟现实轨迹与拟议模型之间的比较，以及一个示例用例。

模型验证

图 3 和图 4 显示了模拟分布和获取的交通轨迹之间的比较。IFI 标准差是松配合的，CDF 显示了模型与两个采集轨迹示例之间的相当大的偏差。这是可以预期的，尽管我们模型的目标是概括实际应用程序的行为。

图 4 显示了不同帧速率和目标数据速率下帧大小的 CDF。该模型对 30 FPS 的数据进行了整体拟合。另一方面，60 FPS 的数据显示了与模型不同的行为。第一种解释是，60 FPS 记录道的经验数据率始终高于目标记录道。尽管如此，我们的模型仍然能够捕获总体分布。

图 5 中的端到端结果显示，除了延迟的第 95 个百分位外，模型和经验数据之间具有良好的一致性。注意片段统计和突发统计之间的差异也很重要。对于 VR 等需要接收整个突发信号以获取所需信息的应用，测量突发级性能至关重要。

用例示例

为了举例说明所提出模型的用途，我们讨论了一个可能感兴趣的场景，其中我们测试了 IEEE 802.11ac 网络在多大程度上可以支持密集的虚拟现实流量。

在图 6 中，展示了多个用户在 Wi-Fi 网络中以 50 Mbps 的目标速率运行 VR 应用程序的场景的模拟结果。固定目标数据速率 R = 50 Mbps，平均视频帧大小 S 和帧速率 F 将具有相同的比率，从而使 30 FPS 流的帧大小是 60 FPS 流的两倍。对于具有固定信道容量的网络，这将转化为延迟也将加倍。

从图 6a 可以看出，平均突发延迟低于规定的最大可容忍延迟 5-9 ms，对于以 30 和 60 FPS 速度传输的最多 8 个用户。相反，如果应授予良好的整体体验质量，95% 延迟的相同界限将只允许系统中最多 5 个用户使用 30 FPS 流，或 7 个用户使用 60 FPS 流。

结论

在本文中，我们提出了一个简单的虚拟现实交通模型，基于超过 90 分钟的交通记录。该模型虽然简单，忽略了二阶统计，但它标志着为这种新颖而独特的流量类型量身定制的网络分析和优化的起点，将更现实的流量模型引入 ns-3。

针对突发应用程序提出的 ns-3 框架是公开的、开源的，以及提出的流量模型的实现和实验获得的实际流量跟踪。我们还试图将该模型推广到任意目标数据速率和帧速率。未来的工作将侧重于提高这种方法的质量和通用性，考虑二阶统计，并在几个虚拟现实应用程序上进行更多的采集。