1. 拿到仿真数据之后先别急着画图每个做过5G网络仿真的人应该都有这种体验NS-3或MATLAB里跑完一轮仿真生成一堆.txt、.sca、.csv文件加起来可能几百MB甚至几个GB兴冲冲打开数据结果盯着屏幕不知道从哪看起。这个系列做到第8篇前面已经覆盖了无线网络仿真的场景搭建、参数配置、流量模型和模拟器选型现在终于进入大家最关心的环节——5G网络仿真结果分析。我的习惯是拿到任何一轮仿真结果先做三件事确认数据完整性、按指标分层、建立分析起点。这一步不做好后面画出来的图要么意义不明要么根本没法解释更别提拿去写报告、做决策了。先说数据完整性。很多朋友跑完仿真第一件事就是看吞吐量平均值但如果这时候日志里还报了一堆“Packet drop due to queue overflow”“CRC error rate abnormally high”之类的警告那结果可信度就要打折扣。我个人的经验是先看仿真日志尾部有没有正常结束标志再看丢包事件的时间分布最后才去看统计数据。丢包如果集中在某一个时间段大概率是场景里某个节点故障或者干扰源异常这时候算出来的平均值其实是被污染的。接下来按指标分层。5G网络仿真涉及的数据指标非常多我把它们归纳成以下三层链路层指标RSRP、RSRQ、SINR、CQI、MCS、BLER这些反映的是空口质量系统层指标吞吐量、时延、丢包率、抖动、切换成功率、接入成功率这些是最终用户能感知到的因果层指标调度器行为、缓存占用率、RB利用率、HARQ重传率、ARQ状态这些用来解释为什么系统层指标是这个样子。很多做分析的人卡住是因为一上来就看系统层指标跑到一半发现结果不合理才回头查链路层结果还得从头重跑仿真。正确做法是先建立这样一个三层分析框架从链路层看到系统层再从系统层倒推链路层形成闭环。我拿自己一个典型的仿真场景举例。当时搭的是城区宏站密集组网三扇区基站间距300米20MHz带宽30个子载波间隔帧结构用TDD模式上下行配比3:1。仿真跑完平均SINR大概19dB平均吞吐量下行能到42Mbps这个数字单独看没啥感觉但如果把它拆到三层去分析就可以判断出吞吐量还有多少提升空间、瓶颈在哪里、下一步应该调参数还是调场景。所以在动笔写分析或者画图之前先在表里把这三层指标列出来一份规划清晰的分析骨架就出来了。后面你每一步都填内容而不是东看一个西看一个效率会高很多。2. 吞吐量与时延两张图看清基站调度逻辑系统层的吞吐量和时延是最核心的KPI也是结果分析里绕不开的开胃菜。但我在前面说过这两项指标不能只看平均它们必须结合分布、累积曲线和调度器共同分析否则容易得出片面的结论。2.1 平均吞吐量背后的三种统计口径很多人习惯直接看平均吞吐量但在5G网络的仿真结果里平均吞吐量其实有至少三种统计口径混着用会出问题第一种是全网平均用户吞吐量也就是整个仿真时间内所有UE的吞吐量求平均。这个指标最容易算但它的参考价值其实有限——它混合了中心用户和边缘用户的性能通常会把结果拉到中间值左右掩盖真实差距。第二种是小区平均吞吐量按每一个gNB的小区粒度去统计。这个指标更能反映小区间的负载均衡情况。如果一个小区的吞吐量明显低于其他小区通常说明它的覆盖范围内用户分布太密或者干扰协调参数没调好。第三种是边缘用户吞吐量5%位吞吐量也就是把所有UE的吞吐量排序取第5百分位的值。这个指标在很多实际网络优化里比平均值重要得多因为它代表的是一般用户能感知到的最差体验。URLLC场景、车联网场景里边缘吞吐量直接决定业务能不能跑起来。我个人的建议是仿真分析报告里至少要同时看小区平均值和边缘极值两个都列出表格对比否则你没法判断高平均值到底是所有用户都很好还是一部分用户拉高了整体平均。具体到我自己跑过的一个案例一个室内场景60个UE均匀分布在两个楼层每个楼层一个gNB20MHz带宽使用TDD配比下行满负载。最终统计出来全网平均用户吞吐量是36Mbps但从小区粒度看gNB1覆盖的楼层UDP业务多峰值压力大边缘用户吞吐量只有8MbpsgNB2覆盖的楼层大部分时间空闲边缘用户吞吐量能到22Mbps。如果只看全网平均值你会觉得一切正常但边缘用户的差距说明两个小区间的业务均衡策略还需要调整。2.2 时延分布比时延平均值更值得关注时延同理。5G网络仿真的时延数据通常被分成两类接入时延Control Plane Delay和数据传输时延User Plane Delay。前者包含随机接入过程、RRC连接建立、承载建立等一整套信令交互的耗时后者则是数据包从应用层发出到接收端应用层收到的时间差。两者完全不是一回事但很多分析报告里会直接统称时延导致结论毫无说服力。我的经验是至少需要画两种情况下的时延累计分布函数CDF曲线用户面时延CDF用来观察传输时延的整体分布尤其是高时延尾部控制面时延CDF用来观察接入、切换、重建等关键流程的信令开销。举个例子有一次我们做面向智能制造场景的仿真目标控制面时延要求小于100ms。第一次跑完统计平均控制面时延居然只有45ms当时我觉得很满意。但画CDF曲线之后发现曲线尾部的第99百分位时延到了320ms——这意味着极端情况下某些用户要等300多毫秒才能完成接入。在工业控制场景里这个极值比平均值要命得多。后来排查发现问题出在调度器在接入压力大的时候把随机接入前导码冲突处理得过于激进部分用户的PRACH尝试次数达到上限触发了回退机制。所以说时延分析如果有条件一定要把CDF画出来再看光看平均值做判断很容易漏掉重要问题。2.3 吞吐量上不去先看MCS分布再看RB利用率很多朋友问过我明明信道条件不错SINR也有20多dB为什么吞吐量就是上不去这种情况十有八九不是信道问题而是调度器和链路自适应LA的配合出了问题。链路自适应的核心参数是MCSModulation and Coding Scheme。5G里MCS等级从0到28高MCS意味着高阶调制和更高编码效率但要求信道质量足够好。仿真里最常见的问题是CQI上报周期太长或者上报的MCS落后于实际信道变化导致基站始终用偏保守的MCS调度那吞吐量自然就趴在地上。我建议拿到仿真结果后做一件事统计MCS的使用分布画直方图。如果看到大量UE的MCS集中在较低档位比如5到10而且此时SINR明明很高那就大概率是链路自适应参数没调好或者CQI上报延迟过大。反过来如果MCS集中在25以上但吞吐量依然不高那就要看RB利用率了。RB利用率反映的是频谱有没有被用满。如果某个小区RB利用率只有60%左右但UE还在排队等着调度说明调度器可能配置了过大的上下行资源预留或者周期性业务触发的调度请求没有被及时处理。表现出的现象就是信道很好、MCS也很高、但吞吐量上不去一查RB利用率问题一目了然。我有一份实际跑过的仿真数据可以说明这个问题。当时一个8K视频流业务场景带宽100MHz子载波间隔30kHz基站调度周期1ms但CSI上报周期被设置成了80ms。结果SINR均值21dBMCS平均在22理论峰值吞吐量应该接近200Mbps实际平均只有68Mbps。分析之后发现MCS分布虽然不低但RB利用率只有52%——因为基站拿不到足够新的CSI大量RB在MCS通道给的是Proactive调度但实际数据包没有跟上。把CSI周期改成20ms之后同样场景下平均吞吐量提到了125Mbps。所以说看到吞吐量指标异常思路是这样的先看MCS分布判断链路自适应是否正常再看RB利用率判断资源是否被有效填满最后回看丢包调度队列判断是否存在拥塞。这三步走完吞吐量问题基本能有结论。3. 仿真结果必须可信三个方向验证模型真实性分析结果的时候如果只沉浸在自己的仿真结果是正确的假设里特别容易被表面数据骗过去。5G网络仿真的结果要真正可用于决策必须通过可信性验证。这部分我一般从三个方向做3.1 重传率与HARQ行为检验任何无线通信系统都会存在误码和丢包HARQ机制的目的正是为了纠错和恢复。仿真结果里如果重传率是0反而是可疑的——它要么说明信道建模过于理想要么说明数据包太小、BER模型没生效。正常的5G仿真里BLER应该在一定范围内波动通常控制在10%以内或者根据业务需求调整目标值。如果观察到大规模重传具体表现为HARQ传输次数分布里第3次、第4次传输占比显著上升需要立刻排查是干扰源过强、还是MCS选择过于激进、或者信道衰落模型设置得过于严苛。有个值得注意的细节HARQ重传率不能只看整体平均要看按MCS等级拆分的条件重传率。实际场景中往往高MCS档位的UE重传率不高低MCS档位的UE重传率异常升高说明边缘干扰或者功率控制有问题。如果反过来是高MCS档位的重传率更高那就是链路自适应优化过度、MCS选择盲目偏高。3.2 切换事件与小区边缘效应5G网络仿真里面移动性场景切换事件是验证系统级行为是否合理的试金石。具体做法是把仿真里的切换事件日志拎出来按发生时刻、源小区、目标小区去排时间线和UE的运动轨迹对照看。如果切换发生在UE接近小区边界的位置那说明切换逻辑是合理的如果切换点偏离了理论边界很远或者切换频繁在乒乓状态发生那要怀疑切换参数比如A3事件偏移量、TTT时长是否配置得太敏感。这里有个仿真新手常踩的坑在SINR分布图上小区边缘的SINR远低于中心区域这个本身是符合预期的。但如果边缘区域的RSRP已经低到-120dBm以下且SINR出现了断崖式下跌而不是渐变那大概率是场景里的干扰协调没有生效或者天线方向图设置挂了导致中心区域的波束能量被错误映射这不属于正常网络行为而是模型配置的问题。切换事件验证还有一个用处它能反过来检验用户在场景中的移动模型是否正确。如果明明设定的是步行场景结果切换事件频繁到像每小时跑60公里那移动模型大概率出了问题。3.3 RSRP、RSRQ、SINR三者的一致性检查这三个指标理论上应该是联动的RSRP反映参考信号接收功率RSRQ反映参考信号接收质量考虑了干扰和噪声SINR是信号与干扰加噪声的比率。在仿真结果里如果RSRP很高但SINR很低说明干扰功率很大如果RSRP和SINR都高但RSRQ突然掉了那说明带外噪声或者邻频干扰模型被打开了。我常用的做法是把这三个指标画在同一组坐标里观察它们之间的数学关系是否自洽。比如从RSRP和SINR推算干扰加噪声的功率再去和邻区RSRP对比如果推算结果远大于邻区RSRP之和说明场景里可能存在非建模干扰源。这时候要回头检查是不是有节点的发射功率没关或者天线极化方向设置不当这类错误在复杂多小区场景里经常出现。在验证完成后才建议开始做数据归并和可视化。否则你花了一晚上画出的精美图表可能基于的是一份跑得漏洞百出的仿真数据那和拿错了体检报告去开药没什么区别。4. 仿真结果里最常踩的四个坑这一部分的内容来自实际踩过的坑。无线网络仿真里结果分析阶段有四个高频问题几乎每个项目都会遇到。把它们单列出来希望能帮后来者省掉重复排查的时间。4.1 仿真时间太短导致统计不收敛仿真结果的统计置信度取决于数据包样本量和仿真时长。5G网络仿真里一个常见的错误是仿真时间只跑了不到2秒。夸张吗不夸张。很多初学用NS-3跑仿真的朋友把ApplicationStartTime设为1秒SimulationTime设为2秒实际有效统计时间就只有1秒左右。在这个时间内UE可能才完成小区搜索和随机接入还没来得及稳定传输数据仿真就结束了。你拿这些数据算平均吞吐量结果会严重偏低因为大量时间被控制面的初始化过程占用了。我的经验是仿真开始前先让网络完成初始化RRC建立、承载配置、初始测量报告至少预留0.5到1秒的settle时间正式业务数据的统计时间不要短于10秒建议在20秒以上。如果场景里有切换最好覆盖2-3次完整切换的移动过程。否则统计出来的KPI在时间维度上不具有代表性。具体数字可以这样推导一个20MHz带宽、最大吞吐量约100Mbps的小区在20秒仿真里理论上能传输250MB数据。如果有效统计时间只有1秒传输量就只有12.5MB在缓存管理和调度上根本无法反映稳态行为队列积压、时延抖动这些现象根本来不及出现。4.2 调度器参数和信道模型之间的隐性矛盾这是一个隐蔽的问题。很多仿真器特别是基于离散事件模拟的调度器的决策依赖信道质量反馈而信道模型本身又有时间相关性比如多普勒效应、快衰落。当调度器参数里的反馈周期和信道相干时间严重不匹配时仿真结果会出现一种很别扭的现象链路层SINR看着正常但系统层时延和重传率就是偏高。举例来说一个20km/h的移动用户在3.5GHz频段多普勒频移大约65Hz信道相干时间大约是15ms。如果CSI上报周期被设置成40ms那么基站在调度时使用的信道信息实际上已经过期了两轮衰落周期MCS的选择偏差就会扩大。这时即使有外环链路自适应去补偿HARQ重传率依然会偏高。这类问题在结果分析里不容易一眼看出来因为光看SINR和CQI分布都正常。要做的是把信道变化速率和反馈周期这两个时间常数放在一起对比如果它们之间的数量级关系不合理那就是配置层面的矛盾必须修改参数后重跑。4.3 多小区干扰模型没打开这个坑在UE数量少、小区规模不大的仿真里影响不明显一放到密集城区、多小区同时开启业务就会让结果完全失真。默认情况下某些仿真工具在用户面数据流量低的时候会产生一种伪空闲的干扰状态邻区基站此时没有业务既不上报互干扰也不会产生实际干扰功率于是中心UE的SINR变得异常好。等到流量一上来所有基站同时发射干扰突然全部出现SINR断崖式下跌。这在真实网络中对应的是负载相关干扰但在仿真里如果干扰模型是简化模型或者门控模型只有在RLC Buffer非空时才计算干扰那结果里的SINR变化就不是连续的而是一个台阶式的跳变。解决思路是查看仿真器的物理层干扰模型确认是每个TTI实时计算所有小区干扰还是按条件触发。如果是后者务必让邻居小区也配置背景业务数据避免出现干扰空窗期。否则你分析得出结论该场景下SINR良好其实只对无负载情况成立一旦考虑真实负载结论就站不住脚。4.4 启动阶段的瞬态数据污染平均时延还有一个细节仿真刚开始时空口缓冲区、接入响应、上行调度授权建立都需要时间。在这段时间内数据包经历的时延往往高于稳态值。如果统计窗口包含了这个启动阶段平均时延会被明显拉高尤其是URLLC这类对时延极其敏感的业务偏差可能大到从1ms级别变成5ms级别。我处理的办法是在仿真脚本里明确设置统计的冷启动窗口。比如仿真总时长30秒但只统计从第5秒到第28秒的数据。前5秒就算热身阶段不做统计。这样平均时延反映的是网络稳态行为而不是初始化开销。再进一步我会单独统计首包接入时延和稳态时延两个指标前者用于分析控制面流程后者用于分析用户面传输。两者混在一起谈只会让论文和项目报告里的结论都变得无法解释。5. 把仿真结果组织成能说服人的结论做到这里数据已经分析完毕坑也排掉了。最后一步是把结论呈现出来让其他人——可能是导师、技术评审、或者项目决策者——能快速看懂你证明了什么。这一步的技术含量不亚于前面的仿真工作。5.1 结论呈现的三个层级我的习惯是每个结论都按一张图、三句话、一个建议的形式组织。一张图这张图必须体现最核心的指标对比比如边缘用户吞吐量CDF曲线、时延分布直方图、SINR热力图挑最有代表性的一张即可。不要同时丢出十张图看起来覆盖全面实际上没有重点。三句话第一句说明现象该场景下平均吞吐量为XXMbps边缘用户吞吐量为XXMbps第二句说明原因主要受限于XX小区边缘干扰/MCS偏低/调度限制第三句说明影响这意味着该场景在XX业务模式下无法满足XX需求。一个建议提出基于该结论的下一步行动比如应优化CSI上报周期后重跑或者该场景不适合URLLC业务建议调整帧结构为FDD模式。这样做的好处是每个结论都有从现象到原因再到行动的完整链路而不是孤立地堆数据。5.2 用场景反推结论是否合理最后一步是反向验证。我会问自己如果这个结论放到现实网络里物理上是否讲得通举例来说如果你仿真出的边缘用户SINR是25dB、同时边缘用户吞吐量是120Mbps你要质疑在300米站间距的宏站场景里边缘用户SINR怎么可能有25dB这个结论从物理上就不太可能成立说明要么仿真场景太稀疏要么干扰模型没配对。反之如果你仿真出的控制面时延是15ms也要追问随机接入一次大约需要7-9个PRACH周期一个周期20ms起步如果仿真里还包含竞争冲突那么15ms的接入时延明显偏低除非你配置了免授权接入或者非竞争接入否则这个结论也要打问号。这种物理直觉反推的能力需要积累真实网络数据和多次仿真经验才能形成。我个人建议在做结论定性之前至少对照一遍3GPP标准里的典型时延和吞吐量范围。5G eMBB场景下IMT-2020给出的典型用户体验下行速率是100Mbps级别边缘也要到10Mbps以上URLLC场景要求用户面时延1ms级别控制面时延20ms级别Release 15标准里还有更多细分值。如果你的仿真结果偏离这些典型值几个数量级就不要硬解释回到参数配置找原因。5.3 报告写作上的几个小节关于报告写作这个很多人不重视、实际上很影响印象分的环节我也说几句。第一每个指标都要写明统计口径。平均吞吐量是每UE平均还是小区聚合平均时延是用户面还是控制面统计区间是从T1到T2这些必须在图表标题或者表注里写清楚否则读者只能靠猜。第二对照组必须有。很多项目报告只放本方案的结果没有基线对照组评审根本不知道这些数字算好还是差。我的习惯是至少跑三组纯空载基线、标准3GPP参数对照组、优化参数组。三组对比着分析优化的增量一目了然。第三不要只报告仿真结束时的结果。5G网络是一个动态系统时延和吞吐量随时间变化是有意义的。在报告里放一张横轴为仿真时间、纵轴为吞吐量的曲线能直观体现网络是否启动正常、是否收敛、中间是否出现异常抖动。第四软件和参数版本一定要记录。NS-3的某个版本和另一个版本对物理层模型的处理细节可能有差异MATLAB的5G Toolbox不同release的API也有变动。把版本号、随机种子、仿真场景配置都记录在附录里一方面方便复现另一方面也是对自己结果负责。做结果分析不是把仿真日志打开、按几个按钮导出折线图就算完了。它本质上是在仿真搭建、参数配置、物理模型的基础上做一次完整的科研验证而验证的核心不在工具在于你对系统的理解有多深。我这些经验是从一次次结果不合理、反复查参数、最后发现是配置细节出问题的过程中积累起来的希望这篇内容能帮你少走几段弯路。这个系列后面我还会碰移动性管理、多天线波束赋形仿真、以及与边缘计算结合的联合仿真——每一个都有完全不同的结果分析思路。到时候遇到了坑再回来更新分享。 5G网络仿真结果分析实战：吞吐量、时延与可信性验证要点
1. 拿到仿真数据之后先别急着画图每个做过5G网络仿真的人应该都有这种体验NS-3或MATLAB里跑完一轮仿真生成一堆.txt、.sca、.csv文件加起来可能几百MB甚至几个GB兴冲冲打开数据结果盯着屏幕不知道从哪看起。这个系列做到第8篇前面已经覆盖了无线网络仿真的场景搭建、参数配置、流量模型和模拟器选型现在终于进入大家最关心的环节——5G网络仿真结果分析。我的习惯是拿到任何一轮仿真结果先做三件事确认数据完整性、按指标分层、建立分析起点。这一步不做好后面画出来的图要么意义不明要么根本没法解释更别提拿去写报告、做决策了。先说数据完整性。很多朋友跑完仿真第一件事就是看吞吐量平均值但如果这时候日志里还报了一堆“Packet drop due to queue overflow”“CRC error rate abnormally high”之类的警告那结果可信度就要打折扣。我个人的经验是先看仿真日志尾部有没有正常结束标志再看丢包事件的时间分布最后才去看统计数据。丢包如果集中在某一个时间段大概率是场景里某个节点故障或者干扰源异常这时候算出来的平均值其实是被污染的。接下来按指标分层。5G网络仿真涉及的数据指标非常多我把它们归纳成以下三层链路层指标RSRP、RSRQ、SINR、CQI、MCS、BLER这些反映的是空口质量系统层指标吞吐量、时延、丢包率、抖动、切换成功率、接入成功率这些是最终用户能感知到的因果层指标调度器行为、缓存占用率、RB利用率、HARQ重传率、ARQ状态这些用来解释为什么系统层指标是这个样子。很多做分析的人卡住是因为一上来就看系统层指标跑到一半发现结果不合理才回头查链路层结果还得从头重跑仿真。正确做法是先建立这样一个三层分析框架从链路层看到系统层再从系统层倒推链路层形成闭环。我拿自己一个典型的仿真场景举例。当时搭的是城区宏站密集组网三扇区基站间距300米20MHz带宽30个子载波间隔帧结构用TDD模式上下行配比3:1。仿真跑完平均SINR大概19dB平均吞吐量下行能到42Mbps这个数字单独看没啥感觉但如果把它拆到三层去分析就可以判断出吞吐量还有多少提升空间、瓶颈在哪里、下一步应该调参数还是调场景。所以在动笔写分析或者画图之前先在表里把这三层指标列出来一份规划清晰的分析骨架就出来了。后面你每一步都填内容而不是东看一个西看一个效率会高很多。2. 吞吐量与时延两张图看清基站调度逻辑系统层的吞吐量和时延是最核心的KPI也是结果分析里绕不开的开胃菜。但我在前面说过这两项指标不能只看平均它们必须结合分布、累积曲线和调度器共同分析否则容易得出片面的结论。2.1 平均吞吐量背后的三种统计口径很多人习惯直接看平均吞吐量但在5G网络的仿真结果里平均吞吐量其实有至少三种统计口径混着用会出问题第一种是全网平均用户吞吐量也就是整个仿真时间内所有UE的吞吐量求平均。这个指标最容易算但它的参考价值其实有限——它混合了中心用户和边缘用户的性能通常会把结果拉到中间值左右掩盖真实差距。第二种是小区平均吞吐量按每一个gNB的小区粒度去统计。这个指标更能反映小区间的负载均衡情况。如果一个小区的吞吐量明显低于其他小区通常说明它的覆盖范围内用户分布太密或者干扰协调参数没调好。第三种是边缘用户吞吐量5%位吞吐量也就是把所有UE的吞吐量排序取第5百分位的值。这个指标在很多实际网络优化里比平均值重要得多因为它代表的是一般用户能感知到的最差体验。URLLC场景、车联网场景里边缘吞吐量直接决定业务能不能跑起来。我个人的建议是仿真分析报告里至少要同时看小区平均值和边缘极值两个都列出表格对比否则你没法判断高平均值到底是所有用户都很好还是一部分用户拉高了整体平均。具体到我自己跑过的一个案例一个室内场景60个UE均匀分布在两个楼层每个楼层一个gNB20MHz带宽使用TDD配比下行满负载。最终统计出来全网平均用户吞吐量是36Mbps但从小区粒度看gNB1覆盖的楼层UDP业务多峰值压力大边缘用户吞吐量只有8MbpsgNB2覆盖的楼层大部分时间空闲边缘用户吞吐量能到22Mbps。如果只看全网平均值你会觉得一切正常但边缘用户的差距说明两个小区间的业务均衡策略还需要调整。2.2 时延分布比时延平均值更值得关注时延同理。5G网络仿真的时延数据通常被分成两类接入时延Control Plane Delay和数据传输时延User Plane Delay。前者包含随机接入过程、RRC连接建立、承载建立等一整套信令交互的耗时后者则是数据包从应用层发出到接收端应用层收到的时间差。两者完全不是一回事但很多分析报告里会直接统称时延导致结论毫无说服力。我的经验是至少需要画两种情况下的时延累计分布函数CDF曲线用户面时延CDF用来观察传输时延的整体分布尤其是高时延尾部控制面时延CDF用来观察接入、切换、重建等关键流程的信令开销。举个例子有一次我们做面向智能制造场景的仿真目标控制面时延要求小于100ms。第一次跑完统计平均控制面时延居然只有45ms当时我觉得很满意。但画CDF曲线之后发现曲线尾部的第99百分位时延到了320ms——这意味着极端情况下某些用户要等300多毫秒才能完成接入。在工业控制场景里这个极值比平均值要命得多。后来排查发现问题出在调度器在接入压力大的时候把随机接入前导码冲突处理得过于激进部分用户的PRACH尝试次数达到上限触发了回退机制。所以说时延分析如果有条件一定要把CDF画出来再看光看平均值做判断很容易漏掉重要问题。2.3 吞吐量上不去先看MCS分布再看RB利用率很多朋友问过我明明信道条件不错SINR也有20多dB为什么吞吐量就是上不去这种情况十有八九不是信道问题而是调度器和链路自适应LA的配合出了问题。链路自适应的核心参数是MCSModulation and Coding Scheme。5G里MCS等级从0到28高MCS意味着高阶调制和更高编码效率但要求信道质量足够好。仿真里最常见的问题是CQI上报周期太长或者上报的MCS落后于实际信道变化导致基站始终用偏保守的MCS调度那吞吐量自然就趴在地上。我建议拿到仿真结果后做一件事统计MCS的使用分布画直方图。如果看到大量UE的MCS集中在较低档位比如5到10而且此时SINR明明很高那就大概率是链路自适应参数没调好或者CQI上报延迟过大。反过来如果MCS集中在25以上但吞吐量依然不高那就要看RB利用率了。RB利用率反映的是频谱有没有被用满。如果某个小区RB利用率只有60%左右但UE还在排队等着调度说明调度器可能配置了过大的上下行资源预留或者周期性业务触发的调度请求没有被及时处理。表现出的现象就是信道很好、MCS也很高、但吞吐量上不去一查RB利用率问题一目了然。我有一份实际跑过的仿真数据可以说明这个问题。当时一个8K视频流业务场景带宽100MHz子载波间隔30kHz基站调度周期1ms但CSI上报周期被设置成了80ms。结果SINR均值21dBMCS平均在22理论峰值吞吐量应该接近200Mbps实际平均只有68Mbps。分析之后发现MCS分布虽然不低但RB利用率只有52%——因为基站拿不到足够新的CSI大量RB在MCS通道给的是Proactive调度但实际数据包没有跟上。把CSI周期改成20ms之后同样场景下平均吞吐量提到了125Mbps。所以说看到吞吐量指标异常思路是这样的先看MCS分布判断链路自适应是否正常再看RB利用率判断资源是否被有效填满最后回看丢包调度队列判断是否存在拥塞。这三步走完吞吐量问题基本能有结论。3. 仿真结果必须可信三个方向验证模型真实性分析结果的时候如果只沉浸在自己的仿真结果是正确的假设里特别容易被表面数据骗过去。5G网络仿真的结果要真正可用于决策必须通过可信性验证。这部分我一般从三个方向做3.1 重传率与HARQ行为检验任何无线通信系统都会存在误码和丢包HARQ机制的目的正是为了纠错和恢复。仿真结果里如果重传率是0反而是可疑的——它要么说明信道建模过于理想要么说明数据包太小、BER模型没生效。正常的5G仿真里BLER应该在一定范围内波动通常控制在10%以内或者根据业务需求调整目标值。如果观察到大规模重传具体表现为HARQ传输次数分布里第3次、第4次传输占比显著上升需要立刻排查是干扰源过强、还是MCS选择过于激进、或者信道衰落模型设置得过于严苛。有个值得注意的细节HARQ重传率不能只看整体平均要看按MCS等级拆分的条件重传率。实际场景中往往高MCS档位的UE重传率不高低MCS档位的UE重传率异常升高说明边缘干扰或者功率控制有问题。如果反过来是高MCS档位的重传率更高那就是链路自适应优化过度、MCS选择盲目偏高。3.2 切换事件与小区边缘效应5G网络仿真里面移动性场景切换事件是验证系统级行为是否合理的试金石。具体做法是把仿真里的切换事件日志拎出来按发生时刻、源小区、目标小区去排时间线和UE的运动轨迹对照看。如果切换发生在UE接近小区边界的位置那说明切换逻辑是合理的如果切换点偏离了理论边界很远或者切换频繁在乒乓状态发生那要怀疑切换参数比如A3事件偏移量、TTT时长是否配置得太敏感。这里有个仿真新手常踩的坑在SINR分布图上小区边缘的SINR远低于中心区域这个本身是符合预期的。但如果边缘区域的RSRP已经低到-120dBm以下且SINR出现了断崖式下跌而不是渐变那大概率是场景里的干扰协调没有生效或者天线方向图设置挂了导致中心区域的波束能量被错误映射这不属于正常网络行为而是模型配置的问题。切换事件验证还有一个用处它能反过来检验用户在场景中的移动模型是否正确。如果明明设定的是步行场景结果切换事件频繁到像每小时跑60公里那移动模型大概率出了问题。3.3 RSRP、RSRQ、SINR三者的一致性检查这三个指标理论上应该是联动的RSRP反映参考信号接收功率RSRQ反映参考信号接收质量考虑了干扰和噪声SINR是信号与干扰加噪声的比率。在仿真结果里如果RSRP很高但SINR很低说明干扰功率很大如果RSRP和SINR都高但RSRQ突然掉了那说明带外噪声或者邻频干扰模型被打开了。我常用的做法是把这三个指标画在同一组坐标里观察它们之间的数学关系是否自洽。比如从RSRP和SINR推算干扰加噪声的功率再去和邻区RSRP对比如果推算结果远大于邻区RSRP之和说明场景里可能存在非建模干扰源。这时候要回头检查是不是有节点的发射功率没关或者天线极化方向设置不当这类错误在复杂多小区场景里经常出现。在验证完成后才建议开始做数据归并和可视化。否则你花了一晚上画出的精美图表可能基于的是一份跑得漏洞百出的仿真数据那和拿错了体检报告去开药没什么区别。4. 仿真结果里最常踩的四个坑这一部分的内容来自实际踩过的坑。无线网络仿真里结果分析阶段有四个高频问题几乎每个项目都会遇到。把它们单列出来希望能帮后来者省掉重复排查的时间。4.1 仿真时间太短导致统计不收敛仿真结果的统计置信度取决于数据包样本量和仿真时长。5G网络仿真里一个常见的错误是仿真时间只跑了不到2秒。夸张吗不夸张。很多初学用NS-3跑仿真的朋友把ApplicationStartTime设为1秒SimulationTime设为2秒实际有效统计时间就只有1秒左右。在这个时间内UE可能才完成小区搜索和随机接入还没来得及稳定传输数据仿真就结束了。你拿这些数据算平均吞吐量结果会严重偏低因为大量时间被控制面的初始化过程占用了。我的经验是仿真开始前先让网络完成初始化RRC建立、承载配置、初始测量报告至少预留0.5到1秒的settle时间正式业务数据的统计时间不要短于10秒建议在20秒以上。如果场景里有切换最好覆盖2-3次完整切换的移动过程。否则统计出来的KPI在时间维度上不具有代表性。具体数字可以这样推导一个20MHz带宽、最大吞吐量约100Mbps的小区在20秒仿真里理论上能传输250MB数据。如果有效统计时间只有1秒传输量就只有12.5MB在缓存管理和调度上根本无法反映稳态行为队列积压、时延抖动这些现象根本来不及出现。4.2 调度器参数和信道模型之间的隐性矛盾这是一个隐蔽的问题。很多仿真器特别是基于离散事件模拟的调度器的决策依赖信道质量反馈而信道模型本身又有时间相关性比如多普勒效应、快衰落。当调度器参数里的反馈周期和信道相干时间严重不匹配时仿真结果会出现一种很别扭的现象链路层SINR看着正常但系统层时延和重传率就是偏高。举例来说一个20km/h的移动用户在3.5GHz频段多普勒频移大约65Hz信道相干时间大约是15ms。如果CSI上报周期被设置成40ms那么基站在调度时使用的信道信息实际上已经过期了两轮衰落周期MCS的选择偏差就会扩大。这时即使有外环链路自适应去补偿HARQ重传率依然会偏高。这类问题在结果分析里不容易一眼看出来因为光看SINR和CQI分布都正常。要做的是把信道变化速率和反馈周期这两个时间常数放在一起对比如果它们之间的数量级关系不合理那就是配置层面的矛盾必须修改参数后重跑。4.3 多小区干扰模型没打开这个坑在UE数量少、小区规模不大的仿真里影响不明显一放到密集城区、多小区同时开启业务就会让结果完全失真。默认情况下某些仿真工具在用户面数据流量低的时候会产生一种伪空闲的干扰状态邻区基站此时没有业务既不上报互干扰也不会产生实际干扰功率于是中心UE的SINR变得异常好。等到流量一上来所有基站同时发射干扰突然全部出现SINR断崖式下跌。这在真实网络中对应的是负载相关干扰但在仿真里如果干扰模型是简化模型或者门控模型只有在RLC Buffer非空时才计算干扰那结果里的SINR变化就不是连续的而是一个台阶式的跳变。解决思路是查看仿真器的物理层干扰模型确认是每个TTI实时计算所有小区干扰还是按条件触发。如果是后者务必让邻居小区也配置背景业务数据避免出现干扰空窗期。否则你分析得出结论该场景下SINR良好其实只对无负载情况成立一旦考虑真实负载结论就站不住脚。4.4 启动阶段的瞬态数据污染平均时延还有一个细节仿真刚开始时空口缓冲区、接入响应、上行调度授权建立都需要时间。在这段时间内数据包经历的时延往往高于稳态值。如果统计窗口包含了这个启动阶段平均时延会被明显拉高尤其是URLLC这类对时延极其敏感的业务偏差可能大到从1ms级别变成5ms级别。我处理的办法是在仿真脚本里明确设置统计的冷启动窗口。比如仿真总时长30秒但只统计从第5秒到第28秒的数据。前5秒就算热身阶段不做统计。这样平均时延反映的是网络稳态行为而不是初始化开销。再进一步我会单独统计首包接入时延和稳态时延两个指标前者用于分析控制面流程后者用于分析用户面传输。两者混在一起谈只会让论文和项目报告里的结论都变得无法解释。5. 把仿真结果组织成能说服人的结论做到这里数据已经分析完毕坑也排掉了。最后一步是把结论呈现出来让其他人——可能是导师、技术评审、或者项目决策者——能快速看懂你证明了什么。这一步的技术含量不亚于前面的仿真工作。5.1 结论呈现的三个层级我的习惯是每个结论都按一张图、三句话、一个建议的形式组织。一张图这张图必须体现最核心的指标对比比如边缘用户吞吐量CDF曲线、时延分布直方图、SINR热力图挑最有代表性的一张即可。不要同时丢出十张图看起来覆盖全面实际上没有重点。三句话第一句说明现象该场景下平均吞吐量为XXMbps边缘用户吞吐量为XXMbps第二句说明原因主要受限于XX小区边缘干扰/MCS偏低/调度限制第三句说明影响这意味着该场景在XX业务模式下无法满足XX需求。一个建议提出基于该结论的下一步行动比如应优化CSI上报周期后重跑或者该场景不适合URLLC业务建议调整帧结构为FDD模式。这样做的好处是每个结论都有从现象到原因再到行动的完整链路而不是孤立地堆数据。5.2 用场景反推结论是否合理最后一步是反向验证。我会问自己如果这个结论放到现实网络里物理上是否讲得通举例来说如果你仿真出的边缘用户SINR是25dB、同时边缘用户吞吐量是120Mbps你要质疑在300米站间距的宏站场景里边缘用户SINR怎么可能有25dB这个结论从物理上就不太可能成立说明要么仿真场景太稀疏要么干扰模型没配对。反之如果你仿真出的控制面时延是15ms也要追问随机接入一次大约需要7-9个PRACH周期一个周期20ms起步如果仿真里还包含竞争冲突那么15ms的接入时延明显偏低除非你配置了免授权接入或者非竞争接入否则这个结论也要打问号。这种物理直觉反推的能力需要积累真实网络数据和多次仿真经验才能形成。我个人建议在做结论定性之前至少对照一遍3GPP标准里的典型时延和吞吐量范围。5G eMBB场景下IMT-2020给出的典型用户体验下行速率是100Mbps级别边缘也要到10Mbps以上URLLC场景要求用户面时延1ms级别控制面时延20ms级别Release 15标准里还有更多细分值。如果你的仿真结果偏离这些典型值几个数量级就不要硬解释回到参数配置找原因。5.3 报告写作上的几个小节关于报告写作这个很多人不重视、实际上很影响印象分的环节我也说几句。第一每个指标都要写明统计口径。平均吞吐量是每UE平均还是小区聚合平均时延是用户面还是控制面统计区间是从T1到T2这些必须在图表标题或者表注里写清楚否则读者只能靠猜。第二对照组必须有。很多项目报告只放本方案的结果没有基线对照组评审根本不知道这些数字算好还是差。我的习惯是至少跑三组纯空载基线、标准3GPP参数对照组、优化参数组。三组对比着分析优化的增量一目了然。第三不要只报告仿真结束时的结果。5G网络是一个动态系统时延和吞吐量随时间变化是有意义的。在报告里放一张横轴为仿真时间、纵轴为吞吐量的曲线能直观体现网络是否启动正常、是否收敛、中间是否出现异常抖动。第四软件和参数版本一定要记录。NS-3的某个版本和另一个版本对物理层模型的处理细节可能有差异MATLAB的5G Toolbox不同release的API也有变动。把版本号、随机种子、仿真场景配置都记录在附录里一方面方便复现另一方面也是对自己结果负责。做结果分析不是把仿真日志打开、按几个按钮导出折线图就算完了。它本质上是在仿真搭建、参数配置、物理模型的基础上做一次完整的科研验证而验证的核心不在工具在于你对系统的理解有多深。我这些经验是从一次次结果不合理、反复查参数、最后发现是配置细节出问题的过程中积累起来的希望这篇内容能帮你少走几段弯路。这个系列后面我还会碰移动性管理、多天线波束赋形仿真、以及与边缘计算结合的联合仿真——每一个都有完全不同的结果分析思路。到时候遇到了坑再回来更新分享。