本模拟器把原本固定的平均带宽假设，扩展为逐时隙变化的带宽、丢包和断连状态，使候选动作的可行性、端到端时延和后台更新积压能够随网络条件变化。模拟器作为云边协同强化学习调度系统的网络韧性层，核心目标是在弱网环境下仍能维持业务连续性，并保证实时交互的端到端时延不超过硬性阈值。
正式验收指标：
business_continuity_rate >= 90%
avg_foreground_e2e_delay_ms <= 200 ms
最终网络测试指标为业务功能保持率不低于90%，平均前台端到端时延不高于200ms。
每个调度时隙的网络状态定义为：
n_t = (R_t, p_t, RTT_t, d_t)
| 变量 | 含义 | 单位 |
|---|---|---|
R_t |
当前物理带宽 | Mbps |
p_t |
当前丢包率 | - |
RTT_t |
往返时延 | ms |
d_t |
断连标志 | bool |
有效带宽和时隙容量由当前脚本按以下方式计算：
R_eff_t = R_t * (1 - p_t)
B_t = R_eff_t * slot_duration / 8
断连时，将 bandwidth_mbps 置为 0，将 loss_rate 置为 down_loss_rate，并令 B_t=0、disconnect_flag=True。
网络状态由网络模式决定，step() 负责完成一次网络状态采样，并把结果保存为 current_state。后续的候选过滤、网络惩罚、端到端时延计算和队列更新都读取这一份状态，因此同一时隙内不会重复采样网络。
为系统评估调度决策在不同网络环境下的表现，模拟器提供四种递进的网络模式，从固定的基线逐步过渡到复杂弱网环境，全面验证云边协同系统在各类实际部署条件下的鲁棒性。
| 模式 | 定义 | 状态采样规则 | 用途 |
|---|---|---|---|
static |
固定网络 | 由 b_avg 和 slot_duration 反推固定带宽，丢包固定为 loss_rate_min |
基线 |
jitter |
带宽/丢包抖动 | 每时隙从带宽范围和丢包范围独立采样，无主动断连 | 抖动消融 |
jitter_outage |
抖动 + 断连 | 非断连时同 jitter；断连由 disconnect_prob 或 outage_period/outage_duration 触发 |
弱网/断连实验 |
markov |
三状态弱网 | 在 GOOD/WEAK/DOWN 之间按转移矩阵演化；DOWN 表示断连 |
主实验 |
这四档模式从基线到复杂弱网逐级增强。static 用来确认旧的固定带宽逻辑不被破坏；jitter 用来观察带宽和丢包变化对容量的影响；jitter_outage 用来验证断连时能否降级；markov 用来模拟连续弱网、突发断连和恢复过程。
markov 模式使用三状态集合：
S = {GOOD, WEAK, DOWN}
默认转移矩阵为：
| 当前状态 | 到 GOOD |
到 WEAK |
到 DOWN |
|---|---|---|---|
GOOD |
0.92 | 0.07 | 0.01 |
WEAK |
0.15 | 0.75 | 0.10 |
DOWN |
0.30 | 0.20 | 0.50 |
GOOD状态具有强自持性（0.92），偶发转移至 WEAK，极少直接断连；WEAK状态同样自持较高（0.75），但有一定概率恶化为DOWN，也有可观概率恢复至GOOD（0.15）；DOWN状态恢复概率最大（0.30 到GOOD，0.20到WEAK），但仍有一半概率持续断连。
默认状态参数如下：
| 状态 | 带宽范围 Mbps | 丢包率范围 | 断连 |
|---|---|---|---|
GOOD |
40 到 120 | 0 到 0.02 | 否 |
WEAK |
2 到 20 | 0.05 到 0.20 | 否 |
DOWN |
0 | down_loss_rate，默认 1.0 |
是 |
每个时隙只调用一次 step()。同一时隙内，所有候选动作共享同一个 network_state、B_t、loss_rate 和 disconnect_flag。因此，外部主循环应先采样网络，再生成或过滤候选，而不是为每个候选单独调用 step()。这样 Critic 输出的 G_raw 和网络模块输出的 G_effective 才是在同一网络条件下比较得到的。
网络状态确定后，它会通过两个反馈点影响调度：
- 反馈到物理传输队列，
- 反馈到实时链路时延。
第一个反馈点处理后台任务积压。当前模拟器维护逐任务 AsyncPacket 队列。Q_net 只统计已经就绪、但尚未下发完成的后台payload：
Q_net[t] = sum(remaining_mb_j for packet_j in async_queue if ready_slot_j <= t)
未就绪的任务只计入 pending_comm，不计入 Q_net。模拟器中，pending_comm 表示云端尚未生成完成、还不能下发的任务；Q_net 表示已经具备下发条件，但被当前网络容量限制住的真实物理积压。因此 TTL、队列上限和强制本地自治只面向就绪任务。
队列硬上限可由 --q-net-max-mb 指定。当前 默认使用 Q_net_max=200 MB，也可以通过命令行参数覆盖；若直接使用 NetworkSimulator API 且未显式传入队列上限，则回退到以下自动公式：
Q_net_max = max(4 * b_avg, S_max)
S_max = max(S_adapter, SCL_weights)
TTL 丢弃规则：
current_slot - enqueue_slot >= queue_ttl_slots
-> 丢弃该任务剩余 payload
超限丢弃规则：
Q_net > Q_net_max
-> 丢弃最旧 ready 包
-> 直到 Q_net <= Q_net_max
强制本地自治与队列保护配合使用。_enforce_queue_limit() 会先处理超限；若 enable_queue_force_local=True 或 queue_policy in {"force_local", "hybrid"}，还会触发 force_local_mode/force_local_remaining。在 enable_queue_force_local=True 时，脚本还会按高低水位更新可恢复的强制本地状态：
Q_raw >= Q_net_max
-> force_local_mode = True
Q_net <= Q_net_threshold
-> force_local_mode = False
其中：
Q_net_threshold = q_net_threshold_ratio * Q_net_max
默认 q_net_threshold_ratio=0.8。进入 force_local_mode 后，filter_candidates() 只保留 u=0 本地自治；当 Q_net 回落到阈值以下后，脚本恢复正常候选评估。
第二个反馈点处理当前时隙的实时业务时延。脚本将端到端时延拆为边端时延、通信时延和云端时延之和。
T_e2e = T_edge + T_comm + T_cloud
T_cloud 按动作定义：
| 动作 | T_cloud |
说明 |
|---|---|---|
u=0 |
0 | 本地自治，无云端计算 |
u=1 |
0 | 默认异步口径下 Adapter 后台生成；开启--include-adapter-in-foreground 后，Adapter 下发进入当前实时链路 |
u=2, sync_u2=False |
0 | 默认异步后台重训/蒸馏，不进入当前实时链路 |
u=2, sync_u2=True |
retrain_cloud_delay_ms |
显式同步时，把重训时延计入T_cloud |
通信时延只计算进入当前实时链路的通信量：
if realtime_comm <= 0:
T_comm = 0
elif disconnect_flag or R_eff <= 0:
T_comm = +inf
else:
T_comm = 8 * realtime_comm / R_eff * 1000 + RTT
异步后台下发仍会消耗 B_t，但不会叠加到当前业务的 compute_e2e() 中；其交付时延通过 completed_events 中的 task_latency_ms、queue_latency_ms 和 ready_to_complete_ms 记录。因此，实时业务链路和后台更新交付链路在文档中必须分开描述。同步动作才把云端计算放进当前 T_e2e；异步动作的生成等待和下发等待通过后台事件呈现。
在当前模拟中，u=1 支持两种通信口径，默认异步口径通过 update_queues() 创建后台 Adapter 任务；开启 --include-adapter-in-foreground 后，Adapter 下发量进入当前前台 T_comm，后台不再重复入队。默认 u=2 仍通过 update_queues() 创建异步后台 SCL 任务：
选择动作
-> 逻辑通信量进入 Y_bw 记账
-> 后台任务 created 或前台实时 payload 生效
-> 云端生成完成后进入 ready
-> 使用剩余 B_t 下发后台 payload
-> 下发完成后产生 completed_event
对应函数是 comm_cost_mb()、realtime_comm_mb()、background_comm_mb()、background_ready_delay_slots() 和 background_task_type()。其中，S_query=5 MB 只作为长期通信记账量进入 Y_bw，默认不作为每时隙前台实时 payload。u=1 的实时与后台 payload 由以下开关决定：
realtime_comm_mb(u=1)
= foreground_query_size_mb
+ (S_adapter if include_adapter_in_foreground else 0)
background_comm_mb(u=1)
= 0 if include_adapter_in_foreground else S_adapter
| 动作 | 逻辑通信记账 | 前台实时 payload | 后台 payload | 传输特点 |
|---|---|---|---|---|
u=1 默认异步口径 |
S_query+S_adapter=6.2 MB |
foreground_query_size_mb |
S_adapter = 1.2 MB |
Adapter 后台异步下发，不阻塞当前业务 |
u=1 Adapter 前台口径 |
S_query+S_adapter=6.2 MB |
foreground_query_size_mb + S_adapter |
0 | Adapter 进入当前前台T_comm，不重复进入 Q_net |
u=2, sync_u2=False |
S_query+ SCL_weights = 55 MB |
0 | SCL_weights = 50 MB |
大包，进入Q_net 跨槽消化 |
u=2, sync_u2=True |
S_query + SCL_weights = 55 MB |
c_comm |
0 | 强制实时，realtime_comm_mb() 返回完整 c_comm，cloud_delay_ms() 返回 retrain_cloud_delay_ms |
因此，默认叙事是：u=1/u=2 均不阻塞当前业务实时链路；Adapter 前台对比口径只改变 u=1 的前台 T_comm，用于验证 1.2 MB Adapter 下发进入实时链路后的影响。只有 --sync-u2 才把 u=2 强制变成实时同步动作。由于异步任务会同时影响通信记账和物理积压，需要明确 Y_bw 与 Q_net 的理论边界。
Q_net 是物理传输积压队列，不进入效用 G 的罚项。长期平均带宽约束仍由单一虚拟队列 Y_bw 保证。Lyapunov 证明不变。
Y_bw：
Y_bw[t+1] = max(Y_bw[t] + c_comm[t] - b_avg, 0)
Critic 仍使用原有长期通信预算项：
G_raw = V_lya * U_t - Y_bw[t] * c_comm[t]
网络模块只在 G_raw 之后追加实时容量溢出的软惩罚：
G_effective = G_raw - P_network
其中：
P_network = overflow_penalty * max(realtime_comm - B_t, 0) / max(B_t, epsilon)
这个惩罚来自当前时隙实时传输容量，不是把 Q_net 加进 Lyapunov 目标。Q_net 只是网络侧物理状态，用来描述后台任务积压与保护动作；长期平均通信预算仍由 Y_bw 单独承担，原有证明口径不变。完成上述边界划分后，接口层只需要把网络状态、候选过滤、时延计算和队列更新暴露即可。
| 接口 | 来源 | 作用 |
|---|---|---|
NetworkSimulator.__init__() |
CLAUDE.md 基础契约 + 扩展 |
初始化网络模式、时隙长度、带宽、丢包、TTL、队列上限等参数 |
step() |
CLAUDE.md 基础契约 |
每时隙采样一次网络状态 |
filter_candidates() |
CLAUDE.md 基础契约 |
断连、强制本地和严格带宽过滤 |
compute_e2e() |
CLAUDE.md 基础契约 |
计算当前实时业务时延 |
update_queues() |
CLAUDE.md 基础契约 |
更新Y_bw/Q_net，创建后台任务，处理 TTL/上限和调度下发 |
is_business_available() |
CLAUDE.md 基础契约 |
计算单时隙业务是否可用 |
compute_network_penalty() |
扩展 | 计算实时容量溢出惩罚 |
apply_network_penalty() |
扩展 | 得到G_effective |
comm_cost_mb() |
扩展 | 统一给出u=0/1/2 的逻辑通信记账 |
enqueue_job() |
扩展 | 手动创建异步后台任务 |
schedule_ready_downloads() |
扩展 | 按剩余容量调度 ready 任务下发 |
summarize_records() |
扩展 | 汇总business_continuity_rate 和 avg_foreground_e2e_delay_ms |
接口调用需要遵守状态依赖关系：必须先调用 step() 生成当前网络状态，再调用依赖网络状态的过滤、惩罚、时延和队列接口。若未先调用 step()，当前脚本会通过 _require_state() 抛出错误。
网络波动模拟器当前只保留两项正式验收指标：
business_continuity_rate >= 90%
avg_foreground_e2e_delay_ms <= 200 ms
其中，平均前台端到端时延由 summarize_records() 对有限 e2e_delay_ms 样本求平均得到。业务连续性指标不要先定义成“本地自治比例”或“未断连比例”，而应定义为业务可用时隙在总时隙中的占比：
业务连续性 = 业务可用时隙数 / 总时隙数
单时隙业务可用由 is_business_available() 判定，定义为：
business_available =
decision_success
and transmission_success
and e2e_delay_ms <= deadline_ms
and active_views >= business_min_active_views
and proxy_acc >= acc_floor
各条件含义如下：
decision_success：当前时隙成功产生业务决策。transmission_success：实时链路没有传输失败。e2e_delay_ms <= deadline_ms：端到端时延达标，当前默认deadline_ms=200。active_views >= business_min_active_views：可用视角数足够。proxy_acc >= acc_floor：Critic 的质量代理值达标；当前默认acc_floor=0.8。
上述条件联合判定避免单一指标虚高,可以避免“断连时切到 u=0 本地自治就天然 100% 可用”的虚高口径。u=0 只是系统降级路径，仍必须同时满足决策成功、传输成功、时延达标、视角数达标和质量达标，才算该时隙业务可用。
综上，当前两项正式指标的计算方式和目标为：
| 指标 | 字段 | 公式 | 目标 |
|---|---|---|---|
| 业务连续性 | business_continuity_rate |
sum(business_available) / total_slots |
>= 90% |
| 平均前台端到端时延 | avg_foreground_e2e_delay_ms |
mean(finite e2e_delay_ms) |
<= 200 ms |
当前测试汇总还会输出 disconnect_rate、deadline_met_rate、transmission_success_rate、quality_ratio_pass_rate 等字段，但这些作为诊断信息。
本节使用 version4 两套测试结果，均设置 S_query=5.0 MB、S_adapter=1.2 MB、SCL_weights=50.0 MB、Q_net_max=200 MB：
- 默认异步口径：
u=1和默认异步u=2的后台下发不进入当前前台compute_e2e()，因此平均端到端时延保持 80 ms； - Adapter 前台下发口径：用于验证
u=1的 1.2 MB adapter 下发进入前台实时链路后的影响。
正式验收仍看两项硬指标：business_continuity_rate >= 90% 与 avg_foreground_e2e_delay_ms <= 200 ms；disconnect_rate、deadline_met_rate、quality_ratio_pass_rate、后台队列结果作为诊断信息。
口径说明（重要）：本节 99.8% 量级的业务保持率是代理精度仿真口径——proxy_acc 采用 Critic 的 β_actual，且 u=0 时 realtime_comm=0。使用真实模型输出驱动网络模拟器后，四档业务保持率为 90.28–90.32%（main_edge_cloud_real_model.py、8/12 clean-guard Adapter、acc_floor=0.8），该数作为申报指标；它仍属于网络仿真，不代表真实网络与边缘硬件的现场测试。本节 99.8% 仅用于说明调度算法相对效果与异步架构连续性，不作为硬指标申报数。
原始版本覆盖 BoxCars116k 和 ModelNet40 两类场景数据集，并分别运行 static / jitter / jitter_outage / markov 四档网络模式。markov 模式使用 42、43、44 三个随机种子取均值，避免单次随机采样导致结论波动。
| 数据集 | 网络模式 | 业务保持率 | 平均端到端时延（ms） | 断连率 | 时延达标率 | 质量保持达标率 | 是否达标 |
|---|---|---|---|---|---|---|---|
| BoxCars116k | static |
99.85% | 80.00 | 0.00% | 100.00% | 100.00% | 是 |
| BoxCars116k | jitter |
99.85% | 80.00 | 0.00% | 100.00% | 100.00% | 是 |
| BoxCars116k | jitter_outage |
99.80% | 80.00 | 19.03% | 100.00% | 99.97% | 是 |
| BoxCars116k | markov |
99.83% | 80.00 | 6.16% | 100.00% | 99.98% | 是 |
| ModelNet40 | static |
99.92% | 80.00 | 0.00% | 100.00% | 100.00% | 是 |
| ModelNet40 | jitter |
99.96% | 80.00 | 0.00% | 100.00% | 100.00% | 是 |
| ModelNet40 | jitter_outage |
99.96% | 80.00 | 18.40% | 100.00% | 100.00% | 是 |
| ModelNet40 | markov |
99.96% | 80.00 | 6.65% | 100.00% | 100.00% | 是 |
在 18% 到 19% 随机/周期断连以及约 6% Markov 断连条件下，原始异步口径的前台业务保持率均高于 90%，平均端到端时延为 80 ms，满足 0.2s 约束。这里的 80 ms 表示后台更新未阻塞前台实时链路，因此该版本主要用于说明默认异步架构下的业务连续性。
将 u=1 的 S_adapter=1.2 MB 放入前台 compute_e2e()，同时 foreground_query_size_mb=0，避免额外引入轻量请求包。该口径下，u=1 前台实时通信量为 1.2 MB，u=1 后台 adapter 下发量为 0 MB，避免前后台重复计算；u=1 长期通信记账仍为 S_query + S_adapter = 6.2 MB。
| 数据集 | 网络模式 | 业务保持率 | 平均端到端时延（ms） | 断连率 | 时延达标率 | 质量保持达标率 | 是否达标 |
|---|---|---|---|---|---|---|---|
| BoxCars116k | static |
99.85% | 111.14 | 0.00% | 100.00% | 100.00% | 是 |
| BoxCars116k | jitter |
94.42% | 92.86 | 0.00% | 94.72% | 99.95% | 是 |
| BoxCars116k | jitter_outage |
94.13% | 92.96 | 19.03% | 94.44% | 99.95% | 是 |
| BoxCars116k | markov |
94.21% | 93.32 | 6.16% | 94.49% | 99.95% | 是 |
| ModelNet40 | static |
99.96% | 110.27 | 0.00% | 100.00% | 100.00% | 是 |
| ModelNet40 | jitter |
94.57% | 93.36 | 0.00% | 94.61% | 100.00% | 是 |
| ModelNet40 | jitter_outage |
94.85% | 92.18 | 18.40% | 94.89% | 100.00% | 是 |
| ModelNet40 | markov |
94.22% | 93.06 | 6.65% | 94.26% | 100.00% | 是 |
将 1.2 MB adapter 放入前台实时链路后，平均端到端时延从原始异步口径的 80 ms 上升到约 92 到 111 ms，但仍低于 200 ms；业务保持率在四档网络下仍均高于 90%。这说明系统在计入 adapter 前台下发时延后仍满足业务连续性和实时性指标。
前两组四档实验主要验证前台业务保持率和 adapter 前台下发后的实时性，但还不能充分说明 u=2 大包后台更新机制是否真实生效。由于 u=2 对应 50 MB SCL 权重包，默认不进入当前前台 T_comm，而是进入 Q_net 进行跨时隙消化，因此需要额外观察队列积压、服务量、丢弃原因和完成事件等指标。为避免原始轨迹中 u=2 触发不足，本节使用高结构漂移轨迹作为压力场景，专门验证 Q_net 后台队列机制是否符合设计。在高结构漂移轨迹中，Markov 网络下自然触发 u=2 共 643 次，触发率为 5.22%。关于 u=2 的结果摘要如下：
| 指标 | 数值 |
|---|---|
| 总时隙数 | 12322 |
| 后台队列容量上限 | 200.00 MB |
| 业务保持率 | 98.21% |
| 平均端到端时延 | 80.00 ms |
| 断连率 | 6.39% |
| 时延达标率 | 100.00% |
| 动作二触发次数 / 触发率 | 643 / 5.22% |
| 最大后台队列积压 | 149.31 MB |
| 后台累计服务通信量 | 17567.88 MB |
| SCL 权重字节服务比例 | 54.64% |
| 后台更新丢弃比例 | 45.07% |
| 生存期到期丢弃量 | 14491.02 MB |
| 容量上限丢弃量 | 0.00 MB |
| 完整下发完成事件数 | 2 |
高结构漂移轨迹能够触发 u=2，50 MB SCL 权重包会进入异步队列并被跨时隙消化。将 Q_net_max 放大到 200 MB 后，队列不再因为容量上限丢弃更新包，cap_drop_mb=0，但在 Markov 弱网下仍会有部分更新因 TTL 到期被丢弃；同时出现 2 个完整下发完成事件，说明后台队列服务、TTL 和完成事件记录均被实际触发。由于本版本开启 Adapter 前台下发，后台 adapter 任务完成率为 0 属于预期现象；该节主要用于验证 Q_net 机制，前台业务仍保持 98% 以上连续性。