摘要
很多人听过“系统仿真”，但真正理解它在做什么的人并不多。有人把它当成“复杂版链路仿真”，也有人觉得它只是“跑 KPI 的工具”。
这篇文章不讲公式推导，也不堆概念，而是从工程实践出发，讲清楚五件事：系统仿真到底解决什么问题？它和链路级仿真的本质区别是什么？TTI 级建模在干什么？KPI 是怎么一步步算出来的？以及，为什么很多仿真结果并不可信。
如果你做过无线系统、调度、性能评估，这篇文章会帮你把很多“似懂非懂”的东西真正串起来。
系统仿真到底在解决什么问题？
先说结论：
系统仿真，本质是在回答：一个无线系统在真实复杂环境下能跑出什么结果。现实世界的问题有多复杂？
一个简单的吞吐问题，背后至少包含：
- 多用户 UE 竞争资源
- 调度算法，例如 PF、RR 或自定义策略
- 信道变化，包括快衰落和慢衰落
- 干扰，包括同频干扰和邻区干扰
- 业务模型，例如 FTP、视频、实时业务
- 移动性，例如切换、速度变化
这些因素不是独立存在的，而是耦合在一起的。一个模块单独看可能合理，但放进系统以后，结果可能完全变样。
单点分析解决不了系统问题
你可以分析：
- 单链路容量
- 单用户 MCS
- 单小区性能
但问题是，单点最优不等于系统最优。调度、干扰、业务突发、终端能力和移动性叠加以后，系统行为往往不是某个单模块性能的简单相加。
系统仿真在做什么？
一句话总结：
把所有影响因素放进一个动态系统里，跑时间演进，看最终结果。它不是算一个点，而是跑一个过程。
更抽象一点看，系统吞吐或体验变化可以写成：
这个公式不是为了精确求解，而是提醒我们：系统结果通常由多个变量共同决定，任何单因子解释都很容易失真。
系统仿真 vs 链路级仿真
很多人混淆这两个，这是认知上的大坑。
链路级仿真在做什么？
链路级仿真关注的是：
- 调制解调
- 编码性能
- BLER 曲线
- MCS 与 SINR 的关系
它的本质是逐比特的物理层建模，也就是 bit-level 建模。
系统仿真在做什么？
系统仿真关注的是：
- 调度
- 资源分配
- 多用户竞争
- KPI，例如吞吐、时延、边缘体验
它的本质是系统级行为建模，也就是 network-level 建模。
一个关键桥梁：L2S
系统仿真通常不会逐比特计算，而是通过 Link-to-System 映射，把链路级结论压缩成系统级可用的映射关系：
SINR -> BLER -> 是否成功 -> TBS -> 吞吐也就是说，系统仿真用“映射关系”代替复杂物理过程。这种替代带来了效率，也带来了可信度风险。
一句话区分
链路级仿真：一个用户在理想或受控环境下能跑多快。
系统仿真：一群用户在复杂环境下整体能跑出什么结果。TTI级建模到底在干什么？
TTI 级建模是系统仿真的核心引擎。
什么是 TTI？
TTI，全称 Transmission Time Interval，可以理解为系统调度的时间刻度。
例如：
- LTE 中常见 TTI 为 1ms
- NR 中可以是更灵活的 slot 级粒度
每个 TTI 发生什么？
系统仿真在每个 TTI 做一件事：
状态更新 -> 调度决策 -> 传输执行 -> 结果反馈展开来看：
Step 1：状态更新
- UE 位置变化
- 信道变化
- 缓冲区数据更新，例如 BSR
Step 2：调度决策
- 哪些 UE 被调度
- 分配多少 RB
- 使用什么 MCS
Step 3：传输执行
- 根据 SINR 和 MCS 计算 BLER
- 判断本次传输是否成功
Step 4：反馈更新
- HARQ 状态更新
- 缓冲区更新
- KPI 统计
然后进入下一个 TTI，循环往复。
本质是什么？
系统仿真的本质，是一个离散时间的动态系统仿真。它不是算一次，而是跑几万到几百万个 TTI，通过时间演进观察系统行为。
KPI是怎么来的？
很多人只看最终结果，却不知道结果是怎么“长出来”的。
KPI不是直接算的
比如吞吐，不是一个公式直接算出来的，而是：
每个 TTI 成功传输的数据量 -> 累加 -> 平均举个简化例子
TTI1：成功 1000 bits
TTI2：失败 0 bits
TTI3：成功 2000 bits
...最终：
常见 KPI 来源
- 吞吐：成功传输数据累计
- 时延：数据从到达到发送成功的时间
- BLER：失败次数除以总传输次数
- 边缘用户体验：最差一部分用户的性能，例如 5% 用户吞吐
关键点
KPI 不是“计算结果”，而是“行为结果”。它来自系统在长时间演进中的累计表现。
为什么仿真结果经常不可信？
这是最重要、也是最少人愿意认真讲的部分。
建模不完整
这是最常见的问题。例如：
- BSR 没建好
- 切换流程过度简化
- 调度逻辑和产品不一致
结果就是，仿真跑得很漂亮，但完全不符合真实网络。
随机性导致波动
系统仿真里存在大量随机性：
- 信道随机
- 用户分布随机
- 业务到达随机
- 移动轨迹随机
即使是同一个场景、同一个配置，结果也可能存在波动。所以仿真结论必须看统计稳定性，而不是只看一次运行结果。
L2S模型不准确
如果 SINR -> BLER 映射不准，后面的调度、重传、吞吐和时延都会跟着偏。L2S 是系统仿真的效率来源，也是误差来源。
并行和实现细节问题
真实工程里经常会遇到：
- 多线程调度顺序不同
- 状态更新顺序不一致
- 随机种子管理不严
- Trace 和 KPI 统计口径不一致
这些细节足以让仿真结果不稳定，甚至让团队误判算法收益。
KPI统计方式有问题
比如：
- 时间窗口选取不对
- warm-up 阶段没有剔除
- 收敛条件没有判断
- 只看均值，不看 P5、P95 或 P99
最后可能得到一个“看起来合理”的错误结果。
最本质的问题
仿真不是“真相”，而是“模型输出”。模型边界、参数口径、随机性和统计方式都会影响结论。
结语：你必须建立的三个认知
系统仿真是系统行为的近似，不是还原
不要把仿真当现实。它只是一个可控实验环境，用来帮助我们理解趋势、验证假设、比较方案。
仿真价值在对比，不在绝对值
系统仿真的价值更多在于：
- 看趋势
- 看增益
- 看退化点
- 看敏感因素
不要迷信绝对数值，更不要拿一个仿真数值直接当真实网络结论。
好的仿真工程师，会主动怀疑结果
不会质疑结果的人，不适合做系统仿真。真正有价值的仿真能力，不只是把 case 跑出来，而是能回答：
这个结果为什么可信？
它的边界在哪里？
换一个场景还成立吗？
如果结果反直觉，应该先怀疑模型、实现还是假设？系统仿真的长期价值，不是替代外场，而是在外场之前建立更高质量的判断。