使用开源工具构建面向IoT-边缘-云连续体的低成本网络数字孪生

大家读完觉得有帮助记得关注和点赞！！！

摘要
在不中断实时基础设施的情况下，验证IoT-边缘-云环境中的网络配置并测试故障场景，仍然是一个开放的操作挑战。本文介绍了一种用于IIoT边缘部署的低成本、完全开源的网络数字孪生（Network Digital Twin, NDT），该孪生基于Containerlab、Open vSwitch、ONOS以及Prometheus/Grafana可观测性栈构建。该框架在一个可部署的单一工件中，集成了容器原生拓扑仿真、SDN驱动的流量工程和实时遥测。针对物理Raspberry Pi边缘WLAN的验证显示，在RTT中位数（Δ = 0.4毫秒）和UDP吞吐量（Δ = 0.03 Mbps）方面具有很强的分布收敛性。TCP吞吐量和数据包丢失方面的剩余偏差可归因于可识别的虚拟化伪影，本文提供了根本原因和修复路径。

I 引言

IoT-边缘-云连续体涵盖了资源受限的传感器节点、无线接入网络、边缘计算集群和云后端，创建了多层级环境，其中网络行为本质上是异构和非平稳的。在此类环境中，在不中断生产流量的情况下验证配置、压力测试故障恢复以及验证服务质量（QoS）策略，是一项基本的操作挑战。

网络数字孪生（NDT）通过提供物理网络的虚拟副本解决了这一挑战，该副本足够接近地镜像行为特征，以作为一个安全的实验沙盒。IETF/IRTF网络管理研究组将NDT定义为“一个先进的网络仿真平台，用作场景规划、影响分析和变更管理的工具”[12]，其特点是五个要素：数据、模型、映射、接口和逻辑。将NDT与经典仿真区分开的一个关键属性是交互式虚实映射：孪生体需要根据物理网络进行校准，并与之持续比较[12]。

尽管有如此明确的定位，但将容器原生拓扑仿真、可编程SDN控制和实时可观测性管道集成在一个可部署框架中的实用、开源、低成本NDT实现仍然稀缺。本文填补了这一空白。我们提出了一个从头开始，仅使用开源组件逐步构建的NDT：Containerlab、Open vSwitch、ONOS、Prometheus和Grafana。该框架在一个部署在fortiss IIoT实验室的边缘小型测试平台上进行了验证，该平台是一个Wi-Fi连接的Raspberry Pi边缘节点集群，代表了典型的IoT-边缘部署。从基本虚拟网络到完整数字孪生验证的进展，反映了工具本身的学习曲线，使该框架既可重复用作研究平台，也可用作教学工件。

具体贡献如下：

1. 一个面向IoT-边缘-云连续体的开源NDT架构，直接映射到IRTF参考模型[12]。

2. 四个从经验CODECO测量中导出的校准Wi-Fi损伤配置文件（基线、开放、典型、拥塞），并通过可重用的wifi-profile.sh工具链应用。

3. 一项五项实验评估活动：基线表征、拥塞影响、SDN流量工程、弹性测试以及NDT与物理保真度验证。

4. 识别并缓解了在Containerlab/OVS环境中，当iPerf3使用默认MTU大小的传输时观察到的TBF段饥饿伪影，并讨论了其重现条件及其对TCP吞吐量保真度的次级影响。

5. 对收敛失败及其根本原因的批判性分析，并为未来工作提供了具体方向。

II 相关工作

起源于工业制造的数字孪生概念[4]已逐步被调整应用于网络环境。早期的网络仿真平台如GNS3和CORE实现了拓扑虚拟化，但缺乏与实时遥测管道和SDN控制平面的集成。Mininet为SDN实验建立了一个标准[6]，但其内核空间架构限制了容器多样性、镜像灵活性和可扩展性。

Containerlab [3]通过提供一个声明式的、容器原生的拓扑引擎解决了这些限制，该引擎支持广泛的网络操作系统和轻量级Linux节点。与Mininet不同，Containerlab将容器作为一等抽象，允许每个节点拥有自己的网络栈、监控代理和配置。

关于NDT验证方法，先前的工作主要集中在数据中心场景或分析延迟模型上[2]。针对IIoT或无线边缘环境的NDT框架要少得多，且现有的框架通常不包含SDN控制平面测试或长期行为分布匹配。最接近的是[10]的工作，它使用Mininet进行IIoT场景仿真，但没有在孪生体内解决Wi-Fi配置文件校准、持久遥测或SDN驱动的流量工程问题。

使用tc netem进行无线损伤注入是成熟的做法[9]，但netem队列规则与Linux令牌桶过滤器（TBF）整形器在容器化环境中的交互，特别是第四节中描述的段饥饿伪影，在先前的工作中尚未被系统地表征。

III 背景

III-A IoT-边缘-云连续体

IoT-边缘-云连续体集成了各种信息物理系统和网络。它涵盖远端边缘设备/集群和近端边缘设备/集群，并延伸至云端。网络路径穿越多个管理域，并集成了多种网络技术，例如Wi-Fi、以太网和蜂窝网络等。流量工程应用于每一层。这种异构性使得连续体特别难以建模：边缘的策略变更可能对云端的遥测数据流产生级联影响。

诸如Kubernetes之类的容器编排平台正越来越多地部署在边缘端[8]，以管理跨此连续体的工作负载，但网络层验证工具并未跟上步伐。最近，针对跨层上下文感知的容器编排扩展，例如CODECO [11]，正在弥合通信与计算之间的鸿沟，旨在为IoT-边缘-云连续体的基础设施需要支持的内容提供整体视图。

III-B 网络数字孪生

IRTF NDT参考架构[12]定义了五个功能要素。数据从物理网络捕获实时和历史状态。模型提供基于该数据的仿真抽象。映射建立虚实对应关系，可以是一对一（持续同步）或一对多（联邦孪生）。接口标准化孪生体与外部系统之间的集成。逻辑编码分析、诊断和控制功能。该草案还列举了五个构建挑战：大规模数据管理、跨异构设备的互操作性、数据建模复杂性、实时同步和安全性。在IIoT-边缘规模下，前三个最为紧迫，并由我们的框架直接解决（第四节）。

III-C 容器原生网络仿真：Containerlab

Containerlab [3]是一个声明式拓扑引擎，它提供基于容器的网络节点，如路由器、交换机和端点主机，通过虚拟链路连接，所有这些都在一个YAML清单中描述。每个节点都是一个标准的Docker容器，拥有完整的Linux网络栈和运行任意监控代理的能力。拓扑部署和拆除仅需数秒，实现了可重复的实验周期。与Mininet [6]相比，Containerlab支持更广泛的节点镜像，自然地与现有容器基础设施（包括Kubernetes工作节点）集成，并且不需要内核补丁。

Containerlab/OVS环境中一个已知的限制是tc netem与Linux令牌桶过滤器（TBF）整形器之间的交互：标准MTU大小的传输可能在数据包离开容器接口之前耗尽TBF令牌桶，产生与配置带宽上限无关的人为低吞吐量。我们在第四节中描述了这一伪影并提供了可重现的缓解措施。

III-D 软件定义网络与ONOS

软件定义网络（SDN）[5]将控制平面与转发平面解耦，实现了网络行为的集中式、可编程管理。ONOS控制器[1]以运营商级水平实现了这一范式，公开了一个意图框架（Intent Framework），允许应用程序表达高级转发目标（例如，“以最小延迟将流量从A路由到B”），而无需指定底层流规则。ONOS将意图转换为安装在OVS网桥上的OpenFlow 1.3规则，通过对拓扑变化（例如链路故障、拥塞事件）做出反应，通过Dijkstra算法重新计算路径，并在不到一秒钟内更新流表。

在NDT上下文中，ONOS充当IRTF模型的逻辑层和控制接口层：它体现了优化和控制功能，并为仿真转发平面提供了标准化的南向接口（OpenFlow）。

III-E 可观测性：Prometheus和Grafana

Prometheus [7]是一个基于拉取模式的指标收集系统。部署在每个网络节点上的Node Exporter代理在标准HTTP端点（:9100）上公开每个接口的字节/数据包计数器、CPU利用率、内存和系统负载。Prometheus以可配置的时间间隔抓取这些端点，并将时间序列数据存储在本地TSDB中。Grafana提供将Prometheus作为数据源的可视化仪表板，实现在同一画布上对NDT和物理节点指标进行实时比较。

在我们的框架中，Prometheus实现了IRTF模型的数据存储库组件，而Grafana实现了网络可视化功能，包括评估孪生保真度所需的并排NDT与真实环境比较。

III-F 边缘Kubernetes及开放问题

轻量级Kubernetes发行版如K3s [8]现已部署在包括CODECO测试平台在内的边缘集群上。虽然Kubernetes处理工作负载调度和服务发现，但它引入了CNI（容器网络接口）覆盖网络，其与SDN控制的OVS网桥的交互带来了集成复杂性。具体来说，由ONOS安装的流表条目可能与CNI管理的iptables规则冲突，并且Prometheus ServiceMonitor资源必须与NDT的静态抓取目标对齐。这些摩擦点代表了NDT-Kubernetes边界的开放工程挑战，并促成了本工作中采用的手动配置方法。

为IoT-边缘-云连续体构建NDT的关键开放问题包括：(i) 在参数化netem模型之外，忠实再现重尾无线RTT分布；(ii) 随物理信道条件变化进行动态重新校准；(iii) 如IRTF [12]所预期的跨多个管理域的联邦孪生。

IV NDT架构与实现

IV-A 映射到IRTF参考模型

NDT围绕三个功能平面构建（图1）：仿真平面实例化虚拟拓扑并注入信道损伤；控制平面通过ONOS提供可编程SDN管理；可观测性平面从NDT和物理CODECO网络收集、存储和可视化遥测数据。表I总结了每个IRTF功能元素在实现中的对应关系[12]。

表I：IRTF NDT元素映射。

图1：NDT三平面架构及组件交互。

IV-B 仿真平面

网络拓扑在ndt-topology.yaml中声明，这是一个Containerlab清单，用于配置镜像六个CODECO测试平台Raspberry Pi节点和接入点（AP）的Linux容器。容器IP地址被分配以匹配物理网络（Pi节点为12.0.32.10-12.0.32.15，AP为12.0.32.1），因此相同的Prometheus抓取目标、Grafana仪表板和iPerf3命令无需修改即可应用于两种环境。

在AP节点，Open vSwitch网桥替代了标准的Linux网桥。每个网桥接口通过OpenFlow 1.3连接到ONOS控制器，允许以编程方式安装、修改和删除流规则。使用tc netem（延迟、抖动、丢包）结合令牌桶过滤器（TBF）整形器（带宽上限）在面向AP的虚拟接口上应用流量损伤，封装在wifi-profile.sh脚本中。四个预定义配置文件列于表II。

表II：定义的NDT Wi-Fi损伤配置文件。

第五个配置文件real_lab，通过使用映射关系delay = \bar{\tau} / 2,jitter = \sigma_{\tau},loss = \bar{p},bw = \hat{B}_{TCP}从实时CODECO基准测试自动生成，从而在物理信道条件变化时实现按需重新校准。

IV-B1 TBF饥饿伪影

在初始配置过程中，尽管成功注入了延迟，但在所有损伤环境下TCP吞吐量都降为0.00比特/秒。调查揭示了根本原因：默认情况下，iPerf3会向传输环形缓冲区涌入大量、不受限制的MTU（通常为1500字节块）。在Containerlab/OVS环境中，严格的TBF配置在接收到这些微突发时瞬间耗尽令牌桶，在流量离开节点之前在主机内核内部触发静默尾部丢弃。

缓解措施是通过-M 500限制TCP的iPerf3段大小（最大报文段大小），以及通过-l 500限制UDP的有效载荷长度。这将流量平滑为500字节的间隔，与内核的虚拟令牌刷新周期匹配。虽然有效，但此限制引入了一个次级伪影，降低了NDT相对于物理环境的TCP吞吐量（完整数据集NDT均值：3.68 Mbps vs. 物理均值：9.19 Mbps；见第八节）。增加的限制降低了容器内有效的TCP良好吞吐量上限，不能被视为中立的测量参数（见第八节）。此处记录了初始失败及后续修复，以防止使用类似栈的研究人员重蹈覆辙。

IV-C 控制平面

ONOS（v2.7）通过TCP端口6653上的OpenFlow 1.3连接到每个OVS网桥。转发生命周期如下进行：(i) 拓扑发现后，ONOS安装默认的PACKET_IN规则；(ii) 意图框架通过Dijkstra最短路径计算将高级路径意图转换为OpenFlow匹配/动作规则；(iii) 规则作为FLOW_MOD消息推送；(iv) 在链路状态变化时（通过PORT_STATUS消息），ONOS在一秒内重新计算路径并发布更新规则。

IV-D 可观测性平面

通过Containerlab的exec指令，Node Exporter代理被嵌入到每个仿真容器中，在9100端口公开每个接口的字节/数据包计数器、CPU使用率、内存和系统负载。Prometheus以15秒的间隔同时抓取两个任务：

• ndt-nodes：六个仿真的NDT容器

• real-nodes：六个物理CODECO Raspberry Pi节点

这种统一的抓取配置使得能够使用标准PromQL进行直接并排比较。实验中使用的示例查询：

promql

# 每个节点的TX吞吐量（Mbit/s）
rate(node_network_transmit_bytes_total{job=~"ndt-nodes|real-nodes", device="eth1"}[30s]) * 8 / 1e6
# 接收数据包丢弃率
rate(node_network_transmit_drop_total{job="ndt-nodes"}[1m])

V 实验环境

V-A 物理参考测试平台

物理参考网络基于一个真实的测试平台，即位于慕尼黑fortiss GmbH的CODECO IIoT边缘测试平台。该测试平台包含一个基于CODECO的多集群联邦环境，CODECO本身基于开放集群管理（OCM）项目。本文中的实验在单个集群中运行，该集群由五个Raspberry Pi（ARM架构，作为Kubernetes CODECO工作节点和一个控制平面节点）组成，所有节点通过共享Wi-Fi介质连接到典型办公室/实验室环境中的接入点。拓扑如图2所示。

图2：参考网络。

所有节点运行Node Exporter，指标由Prometheus实例抓取。Grafana仪表板提供跨物理和仿真环境的吞吐量、CPU利用率和接口统计信息的实时可视化。

WLAN并非隔离的，因此信道会受到网络使用、障碍物、信道干扰引起的常见变异性影响。为表征长期行为分布，收集了为期九天（2026-05-19至2026-05-27）的测量档案，产生所有指标共15,988行原始数据。在校准过滤（见第六节-C）后，使用14,665行进行分析。

V-B NDT基础设施

NDT部署在一台运行Ubuntu 22.04 LTS的专用机器上，预装了Docker、Containerlab和Open vSwitch。ONOS控制器（v2.7）作为本地进程运行，通过OpenFlow 1.3连接到OVS网桥。Prometheus和Grafana在物理和仿真测量域之间共享。NDT测量档案在两天内收集（2026-06-02至2026-06-03），产生五个指标类型共1,170行。在排除解析伪影和失败会话后（见第六节-C），使用1,113行进行分析。两天的覆盖范围限制了NDT侧分布分析，并在第八节作为局限性进行讨论。

VI 实验方法

表III：物理测试平台测量结果（RTT以毫秒计）。

表IV：网络数字孪生基准测试结果（RTT以毫秒计）。

表V：E4：完整数据集分布比较矩阵。 物理：来自校准档案（2026-05-19至2026-05-26 12:xx及2026-05-27；共14,665行）。NDT：来自校准档案（2026-06-02至2026-06-03；排除后共1,113行）。排除规则见第六节-C。

VI-A 基准测试套件

证据基础。 本文验证分析基于两个不同的证据基础，二者不可互换，并在全文中分开报告。(a) 10次运行受控会话（表III，测试平台；表IV，NDT测量）：于2026-06-02在稳定信道条件下连续收集的十次运行，用于报告RTT平均值、UDP抖动和UDP丢包率的点收敛数据。(b) 长期测量数据集（表V）：经过数据质量过滤后的完整9天物理档案和2天NDT档案，用于报告RTT中位数、UDP吞吐量、TCP吞吐量和丢包率的分布统计。

每次实验运行应用以下三条命令的跨层基准测试：

• 延迟平面（20次探测）：ping -c 20 <target>

• TCP传输平面（20秒，MSS受限）：iperf3 -c <target> -t 20 -M 500

• UDP传输平面（20秒，8 Mbit/s提供的负载）：iperf3 -c <target> -u -b 8M -t 20 -l 500

每次运行提取六个指标：RTT最小值/平均值/最大值（毫秒）、丢包率（%）、TCP吞吐量（Mbps）、UDP抖动（毫秒）和UDP丢包率（%）。

实验案例如下：

• E1：端到端吞吐量和延迟基线。 在应用任何Wi-Fi配置文件之前，为启用SDN的Containerlab拓扑建立性能基线。iPerf3服务器在目标节点上运行；源节点在没有tc规则激活的情况下执行基准测试套件。结果确立了NDT转发性能的上限，并确认OVS流安装正确完成。

• E2：Wi-Fi拥塞影响。 使用拥塞配置文件（延迟=20毫秒，丢包率=3%）评估模拟无线拥塞下的TCP和UDP行为。三个源客户端通过共享AP向单个目的地生成并行流量流。该实验特别针对TCP拥塞窗口（cwnd）崩溃：在丢包情况下，CUBIC的拥塞控制反复将cwnd减半，导致吞吐量远低于剩余可用带宽。

• E3：SDN流量工程。 演示在注入链路退化情况下ONOS控制的动态路径优化。对主要路由器间链路应用100毫秒的人工延迟。一个OpenFlow意图将流量引导至备用路由。指标包括重路由前后的延迟、吞吐量和收敛时间。

• E4：数字孪生验证。 量化校准后的NDT在多大程度上重现物理测试平台的行为特征。

• E5：流量优先级。 通过使用OpenFlow优先级规则区分不同流量类别的转发行为，演示SDN驱动的QoS实施。高优先级流（控制流量、延迟敏感的遥测）通过ONOS流规则被分配专用输出端口和队列资源，而尽力而为的背景流量竞争剩余容量。在并发负载下测量每类流量的延迟和吞吐量。

VI-B 数据质量与排除

在收集过程中识别出三个数据质量问题；在计算本文报告的任何统计量之前，所有受影响的行都从分析中排除。

物理数据集 - 5月26日损坏块。 从2026-05-26 14:00开始，物理数据集中收集的iPerf3结果（UDP吞吐量、TCP吞吐量和抖动）达到了似乎与iPerf命令不一致的值。具体来说，UDP吞吐量达到283-645 Mbps，而iPerf3命令限制为8 Mbps。同一块中的TCP值达到184-767 Mbps，远高于所有其他天观察到的1-48 Mbps的校准范围。该块的抖动达到95-183毫秒，而所有其他天的数据集范围最大值为23.8毫秒。同一时期的Ping延迟未受影响并保留。原因未知；原始iPerf3输出未保留。排除行数：1,323（所有时间戳 ≥ 2026-05-26 14:00的iPerf3指标）。排除后，校准后的物理数据集包含14,665行。

NDT数据集 - TCP解析伪影。 收集脚本使用awk '{print $7}'解析iPerf3输出以提取TCP接收器吞吐量。七个TCP条目包含与所有其他NDT TCP测量不一致的值：五个条目超过100 Mbps（385、471、838、870、925 Mbps），两个条目恰好显示52.4 Mbps。所有有效的NDT TCP值落在1.62和4.92 Mbps之间；52.4 Mbps的值是最高合法测量的10倍以上，并且出现在没有配置更改的单独会话中。最可能的原因是当iPerf3更改其输出单位前缀时，awk捕获了错误的列。原始iPerf3输出未保留，因此无法确认原因。排除行数：7个TCP条目。此外，返回0 Mbps的8个NDT TCP会话（iPerf3服务器不可达）和具有100%丢包率的5个UDP会话（原因相同）被视为失败运行，并从吞吐量和丢包率统计中排除。

物理数据集 - 缺少TCP值。 校准后的物理数据集中的53个TCP条目不包含值（NaN），表示iPerf3服务器不可达或测试超时的会话。这些从TCP分析中排除（不视为零吞吐量测量）。

应用的过滤规则如下：

• 物理：排除时间戳 ≥ 2026-05-26 14:00的行；然后排除值为NaN或0的TCP行。

• NDT：排除值为0或值≥10的TCP行；排除值为0的UDP行。

过滤后，校准的样本计数为：RTT：物理 N = 12,149，NDT N = 890；UDP：物理 N = 613，NDT N = 65；抖动：物理 N = 613，NDT N = 65；丢包率：物理 N = 613，NDT N = 70；TCP：物理 N = 576，NDT N = 55。

VII 结果

本节报告每个实验案例的结果。定量比较基于两个不同的证据基础，如第六节所定义：10次运行实验（表III，IV）和完整的可观测性数据集（表V）。

VII-A E1：基线性能

表VI报告了在没有任何活动Wi-Fi配置文件的情况下的NDT基线性能。2 Gbps的TCP吞吐量反映了OVS在单台物理主机上的以太网基本转发能力。亚毫秒级RTT确认了空闲条件下的最小内部排队。

表VI：E1：基线，无Wi-Fi损伤。

VII-B E2：Wi-Fi拥塞影响

表VII显示了在拥塞Wi-Fi配置文件下的前后对比。TCP吞吐量和抖动根据netem队列规则按预期反应。

表VII：实验2——拥塞对TCP和UDP的影响。

VII-C E3：SDN流量工程

表VIII总结了路径优化结果。ONOS检测到链路退化并在不到一秒内安装了备用路径上的更新OpenFlow规则，过渡期间无丢包。重路由后吞吐量达到9.5 Gbps，确认ONOS意图框架在NDT内正确执行路径选择。

表VIII：E3：SDN流量工程结果。

VII-D E4：NDT vs. 物理网络

表IX确认每个配置文件都产生了预期的行为状态，所有六个指标均呈现单调增加的损伤程度。

表IX：NDT配置文件表征。

表X展示了来自10次运行会话的时点比较。在RTT平均值（Δ = 2.67 毫秒）、UDP抖动（Δ = 0.11 毫秒）、UDP丢包率（Δ = 0.005%）和丢包率（Δ = 0.10%）上实现了高保真收敛。这些数字仅源自短期受控会话，不应外推至一般情况：此处记录的物理TCP平均值35.79 Mbps比9天物理平均值9.19 Mbps（表V）高出3.9倍，表明收集期间信道状况异常有利。三个指标显示出偏差，如下文第八节所述。

表X：E4：10次运行收敛分析，比较矩阵。

VIII 讨论

VIII-A 收敛性分析

校准后，NDT在测试指标上显示出强收敛性。

长期档案结果。 UDP吞吐量一致性是最强结果：物理均值7.12 Mbps vs. NDT均值7.15 Mbps（Δ = 0.03 Mbps）。RTT中位数收敛同样稳健：22.3毫秒 vs. 22.7毫秒（Δ = 0.4毫秒）。这些结果适用于全局收集的数据集，不依赖于短期信道条件。

10次运行会话结果。 RTT平均值对齐（Δ ≈ 2.6毫秒）、UDP抖动（Δ ≈ 0.11毫秒）和UDP丢包率（Δ < 0.1%）确认了“典型”损伤配置文件重现了收集时的物理工作点。由于10次运行的信道异常有利（平均RTT 24.5毫秒 vs. 9天平均值64.9毫秒），这些点收敛数据补充而非取代了长期档案分析。

VIII-B 已识别的偏差

TCP吞吐量差距。 NDT TCP吞吐量在55个校准会话中平均为3.68 Mbps，而物理环境在576个校准会话中平均为9.19 Mbps（Δ = -5.51 Mbps，为物理值的40%）。主要原因是防止TBF饥饿所需的500字节MSS约束。减小的段大小降低了TCP有效填充管道的能力，特别是在“典型”配置文件施加的RTT值下。10次运行会话的TCP值（NDT平均值11.57 Mbps；物理平均值35.79 Mbps）并不代表一般情况：10次运行的物理信道异常强（平均RTT 24.5毫秒 vs. 9天平均值64.9毫秒），在两侧都产生了异常高的TCP吞吐量。未来工作应研究HTB或HFSC作为不需要MSS缩减的替代整形机制。

RTT峰值波动性。 在整个档案中，物理RTT最大值可达2953毫秒（10次运行会话中#5运行最大值为1312毫秒），由瞬态Wi-Fi干扰突发驱动。NDT的确定性netem模型产生有界的最坏情况延迟（观察到最大值为1058毫秒，可归因于孤立事件）。因此，物理RTT平均值64.9毫秒与NDT平均值24.4毫秒不可比；中位数（22.3毫秒 vs. 22.7毫秒）是合适的收敛指标，并显示出强对齐。随机或轨迹驱动的损伤注入是解决此限制的自然扩展。

虚拟队列基线偏移。 NDT RTT最小值聚集在约19.9–26毫秒，显著高于物理最小值约2.0毫秒。这反映了OVS内部处理延迟以及在AP两个虚拟端口上对称应用的两跳netem延迟的持续性。偏移是稳定且可预测的，表明可以通过校准常数进行补偿。

丢包率模型的结构性不匹配。 物理丢包率分布是双峰的：19%的会话（613个中的117个）恰好显示0%丢包率，伴有周期性高丢包事件（最大67%）。NDT没有零丢包会话（70个中的0个）；由于tc netem Gilbert-Elliott概率模型独立于信道状态触发，所有会话都经历一些丢包。这导致NDT的平均丢包率为15.0%，而物理环境为8.5%；中位数为4.9% vs. 0.25%。这种结构性不匹配反映了固定概率丢包模型与真实802.11信道行为之间的根本差异，在真实环境中，丢包是突发性的且与干扰事件相关。在没有进一步调整NDT丢包模型的情况下，直接比较两个数据集的平均丢包率是不合适的。

VIII-C 数据集大小不对称与时间非重叠

物理数据集跨越九天，包含629个自动UDP/丢包会话和576个有效TCP会话。NDT数据集覆盖两天，包含65个有效UDP会话和55个有效TCP会话。这种10:1的会话计数不对称意味着无法分析NDT的日际变异性、一天中的时间效应或长期分布趋势。物理数据集显示RTT中位数有5倍的日际波动（10.0毫秒至47.7毫秒）；在一致的配置文件设置下，NDT中是否存在类似的变异性仍未测试。

此外，两个档案在时间上不重叠：物理数据收集于2026年5月，NDT数据收集于2026年6月。本文中的所有比较仅是分布性的；无法进行会话级或基于一天中时间的对齐比较。建议在两种环境中至少进行七天的并发收集，作为针对共享无线基础设施的NDT部署的标准方法。

VIII-D 关于10次运行验证充分性的讨论

10次运行研究构成了非平稳信道的短期快照。CODECO系列的第5次运行（RTT平均值 = 88.8毫秒，RTT最大值 = 1312.8毫秒）说明了任何固定的短期样本都无法捕捉的瞬态退化事件的幅度。

包含12,149个物理ping观测值和613个UDP会话的完整校准档案，通过捕捉物理网络的完整行为分布解决了这一局限性。在该档案中观察到的强UDP吞吐量收敛（Δ = 0.03 Mbps）和RTT中位数收敛（Δ = 0.4毫秒），提供了比单独的10次运行会话更稳健得多的验证基础。

IX 结论

本文介绍了一个面向IIoT边缘环境的轻量级、完全开源的网络数字孪生，基于Containerlab、Open vSwitch、ONOS以及Prometheus/Grafana可观测性栈构建。该框架在物理小型测试平台上进行了验证。主要发现如下：

• 四个校准的Wi-Fi损伤配置文件表明，以合理方式重现Wi-Fi信道退化是可行的。

• ONOS驱动的SDN流量工程实现了亚秒级故障恢复，延迟改进了三个数量级。

• 一个10次运行的短期受控会话展示了在RTT平均值、UDP抖动和UDP丢包率上的点收敛。提供宏观分布收敛的长期测量显示，在UDP吞吐量和RTT中位数方面具有一致性。

• 剩余差距可归因于可识别且可解决的虚拟化伪影：TBF整形施加的MSS约束（TCP吞吐量 Δ = -5.51 Mbps）、不能重现802.11信道零丢包聚集的概率丢包模型（丢包率中位数 Δ = +4.65 个百分点），以及不能重现物理Wi-Fi峰值事件的有界netem延迟。