仿真跑完日志导出来热力图在屏幕上铺开。很多新手到这一步就觉得任务完成了其实真正决定项目价值的工作才刚开始结果分析。我做无线网络仿真这几年最深的感受就是仿真能不能对上问题靠的不是建模多细、参数多全而是最后那层解读有没有做到位。这篇把这个系列里最容易被低估的一块单独拎出来讲透——5G网络仿真结果分析。不管你是学生做毕设还是刚入行的网规网优工程师照着这套思路走基本可以少走两个月的弯路。1. 动手分析前先把原始数据这层窗户纸捅破1.1 你的仿真日志里到底藏了哪些数据每个仿真平台导出的东西长得很不一样但拆开看本质上是三层栅格级统计、节点级统计、事件级日志。栅格级就是地图上每个小格子的RSRP、SINR、接收功率这类数值适合做覆盖热力图节点级是每个小区或者每个UE的吞吐、时延、BLER等聚合统计适合做性能对标事件级则是切换、接入、掉话、RRC重建这类带时间戳和坐标的记录是定位问题的关键线索。我见过不少人在这一步就栽了跟头——打开文件夹看到一堆CSV不知道从哪看起干脆把文件全拖进表格软件硬翻翻到半夜也看不出所以然。正确的做法是先做一次数据盘点搞清楚每个文件是哪个时间片、哪个场景、哪个随机种子跑出来的再按“栅格—节点—事件”三类归档。这一步虽然琐碎但能帮你后面省下一大半时间。还有一点容易被忽略平台的输出单位。同一个仿真里吞吐量有的给bps有的给Mbps有的给KBps时延有的给毫秒有的给微秒。我吃过大亏一份报告里把微秒当毫秒标了结果时延数据漂亮得不像话后来重跑才发现单位搞错了。所以拿到数据第一件事先看表头和单位这个习惯救过我好几次。1.2 统计口径不统一再漂亮的曲线都是垃圾分析结果之前必须先搞清楚平台的统计口径。这个环节几乎决定了你后面所有结论是否成立但也是新手最容易忽略的。先说时间维度。很多指标在仿真里是做“时间平均”还是“瞬时值”差别巨大。比如小区吞吐量如果整个仿真时长是一个小时那平均吞吐是包含业务波动、用户进出、切换中断在内的综合值瞬时吞吐则只反映某一时刻的速率。你不能拿瞬时值和平均值去对比那是拿橘子和苹果比大小。我习惯统一用“统计稳态期”内的平均值加CDF曲线来看冷启动阶段的数据一律剔除这个下面会详细说。再说空间维度。覆盖率这类指标有的平台按“满足门限的栅格数 / 总栅格数”来算有的则是先按 UE 采样点或用户数加权。同一份结果按面积算和按用户数算覆盖率可能差出去好几个百分点。我们在做城区场景时南边高密度住宅区用户多、信号差北边是空地、信号好按栅格面积算覆盖率能到94%但按用户分布加权一下就掉到87%——后者才是真实体感。所以写报告之前先在方法论里写清楚口径定义别让别人猜。第三个是用户维度。有效用户数和连接用户数不是一回事。有效用户数是指有业务传输、正在产生流量的用户连接用户数则包含所有RRC连接、哪怕在发呆的用户。算单用户速率时必须用前者否则按连接用户数一分每个用户都被发着呆的“僵尸用户”拖低了。很多平台默认导出的用户数是连接用户数需要额外过滤。1.3 异常值和冷启动瞬态该扔就得扔仿真不是一开局就进入稳定状态的。最开始的一段时间里UE入网、业务建立、资源分配都在收敛过程中这期间的统计数据带有明显的“冷启动噪声”。如果你把整个仿真时长的数据平均在一起这部分噪声会污染全局结论。我一般会留仿真时长的前10%到20%做预热期统计只取后面的稳态部分。随机性带来的另一个坑是单次仿真的偶然性。5G网络仿真里用户到达、业务请求、小尺度衰落都带随机性换一个随机种子结果可能差不少。严谨的做法是同一组配置同一场景至少跑5到10个种子把结果取平均并计算置信区间。如果两组不同配置的吞吐差异还在置信区间里打架那就不能说“优化有效”。还有一个数据清洗点容易被漏掉节点刚启动或刚切换完的那几毫秒统计值会异常偏低。比如一个UE刚完成切换目标小区还没有给它调度上资源这时候记录下行速率很可能是0如果把这个点算进平均吞吐整体就被拉低。平台日志里这类采样点建议直接剔除或者至少要能识别出来时间戳紧跟着切换事件之后的采样都检查一下。2. 结果分析绕不开的5类关键指标2.1 覆盖指标RSRP、RSRQ、SINR怎么组合着看覆盖分析三个最基础的指标是RSRP、RSRQ和SINR。RSRP是参考信号接收功率解决的是“信号强不强”的问题SINR是信号与干扰加噪声比解决的是“信号干不干净”的问题RSRQ是参考信号接收质量它同时反映信号电平和干扰水平相当于前两者的小综合。单看RSRP是最容易误判的。我见过一个场景某个区域RSRP非常高接近-90 dBm热力图上红得发紫看起来覆盖很好。但SINR只有-2 dB相当于信号虽然强、干扰也强UE实际体验依然很差。这时候如果只盯着RSRP做优化去加基站功率问题反而会更严重因为功率一加干扰跟着也上去了。所以覆盖分析的核心不是单指标好而是组合达标通常可以设双重门限比如RSRP -110 dBm 且 SINR -3 dB 才算是有效覆盖点。覆盖率计算也是按这两个条件一起去数。还有一种少见但有意思的情况RSRP低、SINR却高。这通常是因为该位置距离基站远、信号弱但周边没有其他同频干扰源所以信号“不干净”的问题不存在。这时候UE的速率会被接收灵敏度限制属于覆盖受限加干扰协调没用得补站或者加功率。不同组合对应完全不同的优化方向这个判断是做覆盖分析的基本功。2.2 吞吐量指标平均、边缘、峰值一个都不能少吞吐量是最直观、也是最多人只用一个数去代表的指标。实际上一次完整的吞吐量分析需要同时看至少三个值平均吞吐、边缘吞吐比如5%分位、峰值吞吐或最好小区的吞吐。只看平均吞吐的问题在于平均会被少数好用户拉高把大多数人的真实体验掩盖掉。我举个例子。一个宏站加微站的仿真场景平均下行吞吐320 Mbps看起来不错。但拉出用户级吞吐的CDF曲线一看5%分位只有12 Mbps也就是说最差的5%用户体验连12 Mbps都不到——这些用户往往分布在边缘或被遮挡区域看视频都卡。平均吞吐和边缘吞吐的差距本质上描述了网络体验的“贫富差距”。这份差距足够大说明网络存在明显的覆盖短板或干扰热点而不是均匀的性能瓶颈。峰值吞吐用来判断小区单用户能拿到的最高能力也可以用来检查参数配置有没有异常如果峰值异常低先怀疑一下调度策略或MCS配置是不是被限制住了。上下行还需要分开看。5G里下行占主导是常态但很多应用场景视频上传、云存储、直播推流对上行业务的要求已经越来越高。如果只分析下行上行的瓶颈可能一直藏在阴影里。上行吞吐受限的原因和下行完全不同往往是功率受限和终端能力问题居多翻车的概率比下行大不少。2.3 时延指标控制面和用户面要分开数时延分析最大的误区就是拿一个“平均时延”走天下。我习惯把时延拆成控制面时延和用户面时延然后分别看平均值、95%分位和99%分位。控制面时延指的是从UE发起连接建立到可以传数据的时间包含随机接入、RRC连接建立、鉴权、默认承载建立等过程的全部耗时。在仿真平台上这些事件是能从日志里逐段拆出来的RACH发送时间点到收到随机接入响应的间隔RRC连接请求到RRC连接建立完成的间隔等等。如果控制面时延偏高要区分是接入信道拥塞、资源等待还是参数配置不合理解决办法方向完全不一样。用户面时延是业务数据包从发送端到接收端的单向时间更贴近用户体验。我强烈建议在分析时把99%分位作为重点关注对象平均时延12毫秒听起来没什么问题但99%分位飙到300毫秒意味着游戏玩家会在某些时刻体验短促的卡顿。评价实时业务尾部的稳定性往往比平均更能说明问题。另外要提醒一句端到端时延和空口时延是两个概念。很多平台默认给出的是包含传输、核心网、服务器处理的全链路时延。如果你在做的是无线接入网优化要把范围限定在空口和接入段否则你把核心网的缓冲时延也算进来不管怎么调基站参数指标改善都很微弱。2.4 移动性指标切换失败往往不是切换的错切换类指标包括切换成功率、切换失败率、乒乓切换率、切换中断时延等。切换成功率反映的是切换过程本身的可靠程度一般要追求到98%甚至99%以上乒乓切换率则反映了邻区关系和滞迟参数是否合理高了会造成信令开销增加、用户体验波动。先说切换成功率。仿真日志里每次切换都有上下文消息源小区、目标小区、触发原因、结果失败的原因通常可以归为三类目标小区信号不满足RSRP低于门限、随机接入失败目标小区拥塞或参数错误、时间提前量超限等。分析时要把失败记录按坐标画出来看有没有空间聚集判断是覆盖问题还是配置问题。再说乒乓切换。乒乓切换率高很多人第一反应是增大迟滞或者调偏置。这个方向没错但别急着动手——先看看是什么原因导致UE在两个小区边界来回切换。如果是因为两个小区信号强度本就接近且波动大调大迟滞能改善如果是因为其中一个小区的导频污染严重那单调迟滞只是治标核心要清理导频污染的区域。我遇到过一次乒乓率高达5%的情况把邻区关系表里一个不该配的邻区删掉之后乒乓率直接掉到了1%以内。还有个经验之谈切换失败率偏高时先别怀疑切换参数先回去看覆盖和干扰。大量切换失败其实是目标小区信号强度本身不足UE切换过去也站不住这时候你把切换门限调松或调紧都无济于事加站或者做波束优化才是正解。这就像换了一个环境更差的办公室问题不是你要不要换而是那个办公室根本没法办公。3. 从“看到图”到“说明白问题”的四轮分析法3.1 第一轮地图叠加先用眼睛扫雷我习惯把结果分析分成四轮第一轮不做任何统计计算先把栅格级热力图和仿真地图叠加起来肉眼扫一遍。热力图重点看三类区域覆盖空洞、重叠覆盖、干扰热点。覆盖空洞在地图上表现为RSRP色带出现明显断裂或骤降重叠覆盖则表现为RSRP都高但在同一栅格里SINR掉得很低干扰热点经常出现在两个强信号小区交界处。一轮看下来脑子里已经有一个初步的问题地图后面做统计时才有目的性。地图叠加需要一个细节颜色映射的阈值不能随便用默认值。不同场景对RSRP高低的定义不一样常规宏站场景可以用-100到-80 dBm作为绿色到红色的区间但室分或微站场景信号普遍更强默认色带会把整张图全部压成同一个颜色等于没看。我调整色带的原则只有一个让问题的区域在视觉上清晰跳出来而不是让图好看。这一步建议出截图存档后面写报告时直接能用。肉眼扫描也有局限性所以第一轮只能用来“发现问题线索”不能用来“下结论”。真正严谨的判断还是要靠下一轮的统计输出。3.2 第二轮拉CDF曲线用统计说话第二轮从节点级数据里挑关键指标拉CDF曲线。CDF累积分布函数就是把所有用户或栅格的某个指标值从小到大排纵轴表示“小于等于某个值的比例”。比如下行吞吐的CDF曲线上5%分位对应的读数是12 Mbps意思是表现最差的5%用户只有不到12 Mbps的速率。CDF上我必看三个点50%分位中位数、5%分位边缘、以及曲线的形状。曲线整体靠右说明大多数用户体验好5%分位单独掉出去很远说明边缘用户被抛弃了曲线如果在中段出现明显的“台阶”往往意味着有一批用户受到了某种同质化限制比如被某个拥塞小区的调度策略压制。不同场景或不同配置的结果可以在同一张图上叠加对比这种视觉差异比一长串数字直观得多。画CDF之前一定要先做完数据清洗和口径统一否则统计出来的曲线虽然漂亮结论可能是错的。我在上面提过的预热期剔除、切换瞬间采样点剔除在这里都会直接影响CDF低段的形状。通常我还额外统计“对标达成度”把每个指标的中位数、5%分位、覆盖率跟设计目标或现网指标做差值标注达标与否。这一步看起来简单但非常能打动人——领导不关心你跑了多少万次仿真只关心你那个指标到底达没达标。我一般会把结果整理成一张表比如| 指标 | 仿真值 | 设计目标 | 是否达标 | | ---: | ---: | ---: :--- | | 覆盖率RSRP-110dBm SINR-3dB | 91.8% | ≥98% | 未达标 | | 边缘用户下行吞吐5%分位 | 16 Mbps | ≥30 Mbps | 未达标 | | 平均下行吞吐 | 312 Mbps | ≥250 Mbps | 达标 | | 切换成功率 | 97.2% | ≥99% | 未达标 | | 乒乓切换率 | 2.8% | ≤1% | 未达标 | | 用户面时延95%分位 | 28 ms | ≤20 ms | 未达标 |这一张表基本就把仿真的家底盘清了后续问题和优化都是围绕这张表里的缺口展开的。3.3 第三轮事件日志逐条追溯定位根因统计告诉你“哪里有问题”事件日志告诉你“问题是怎么发生的”。第三轮就是从事件日志里找出问题对应的具体记录逐条琢磨。沿用上面的案例覆盖率和边缘吞吐都表明问题集中在东北角一片被高层建筑遮挡的区域。这时候我打开切换事件日志把时间窗内发生在该区域的切换失败记录筛出来发现大量切换失败集中在几栋高层建筑背后失败原因千篇一律目标小区RSRP低于门限。这就闭环了——覆盖空洞导致弱信号区域的UE切来切去都找不到好小区切换失败率高只是覆盖问题的“症状”不是“病因”。如果只看切换成功率低就去调切换参数等于在投错药。接入失败事件也很值得抠。如果某个小区出现多次RRC连接建立失败我需要看时间分布——如果集中在某一段业务高峰多半是随机接入资源或上行干扰问题如果散布在全时段可能是参数或覆盖导致。事件日志里通常还会带上重传次数、等待时长等细节这些信息对判断是资源拥塞还是信道恶劣非常关键。这个环节是最耗耐心的也是最容易收获真知灼见的。我见过有些人嫌麻烦事件日志从来不翻结果统计出十个问题一个都解释不了最后只能写“现象待进一步分析”。那不是结果分析那是结果复读。3.4 第四轮从结果反推参数形成优化假设分析做到这一步不要停在你“发现了问题”要趁热打铁形成“优化假设”。每一个问题都得配上至少一个具体的参数调整方向以及一个可量化的预测结果。比如覆盖率不足假设微站功率提升2 dB可以补上东北角空洞如果补了之后边缘吞吐的5%分位能提升到25 Mbps上下那这个假设就值得跑一轮仿真验证。这一步的逻辑是仿真本身不创造答案它只负责检验你的假设。没有假设的结果分析就是一个高成本的数据观测站。我一般会在分析报告里单独开一栏叫“问题—根因—假设—验证方法”把每一条路都写清楚。这一栏的价值非常大重跑之后拿新数据和预测值一对比假设成立与否立刻见分晓。参数假设也不是拍脑袋。比如发现SINR差但RSRP高那干扰受限的可能性大我可以假设开启或调整干扰协调参数比如ICIC或者调整波束方向和下倾角让覆盖更集中如果是覆盖空洞导致的边缘体验差那优先假设补站或提升功率。不同根因对应的参数动作完全不同这也是我一直强调要先定位根因、再谈参数的原因。仿真跑一轮成本不低参数猜错了几轮下来时间全烧没了。4. 常见异常场景排查速查表与避坑清单4.1 六个高频异常场景的定位思路把多年分析经验浓缩成一张排查表照着方向去查能省不少时间。常见异常可以归成六类现象高概率原因验证方法解决方向热力图出现覆盖空洞建筑物遮挡、站间距过大、功率不足看空洞位置与建筑分布的叠加、看栅格RSRP分布补站、调整天线倾角/方位角、提升功率RSRP高但SINR差同频干扰/邻区干扰看干扰热点与小区边界是否重合、查邻区表开启干扰协调、波束优化、调整小区偏置边缘吞吐骤降覆盖受限或干扰受限对比5%分位用户的地理分布、看CDF尾部补站/功率/波束按根因对症处理切换失败集中目标小区弱覆盖、随机接入失败筛失败日志按坐标画点、看失败原因字段加站补覆盖、优化邻区、检查接入参数乒乓切换率高边界信号波动、邻区配置冗余统计切换时间序列和小区对调迟滞/偏置、清理邻区关系表时延异常高拥塞、重传、参数配置拆分控制面/用户面时延、看重传率调度优化、拥塞控制、调定时器这个表不是万能药但能帮你把80%的仿真异常引导到正确的排查路线上。剩下的20%基本要结合具体场景的空间特征去单独拆解这时候就没别的好办法只能逐条翻日志。4.2 我踩过的坑你最好别再踩第一个坑只拍照不解释。有人花三天导出热力图然后报告里放十张图每张图下面只写“如图所示”。图不会自己说话你得告诉读者这是覆盖空洞原因是站间距太大建议在A点补一个微站。没有解读的图是装饰品不是分析结果。第二个坑所有数据一把梭。冷启动数据混进统计期、瞬时值当平均值用、用户级和小区级混在一起比较这些都是我踩过的坑。现在我的规矩很死数据清洗脚本固定跑一遍清洗规则写清楚每次分析都过同一套流程坚决不搞临时起意。第三个坑拿单次仿真下结论。我最初做优化前后对比时只跑了一次仿真结果优化指标反而变差了差点把正确方向给否定掉。后来才知道那一轮随机种子正好赶上波动高峰。现在任何对比至少跑5个种子取平均值个别关键场景我跑10个种子宁可多烧点算力也不要给自己挖“结论不稳定”的坑。第四个坑盲目迷恋高版本或高配参数。很多仿真平台默认给了一堆看起来很先进的开关但你的建模精度可能根本撑不起这些特性。开了功能开关结果变好看了但说不清楚好在哪里这种结果拿到复盘会上就是给自己挖坑。分析结果之前先确认每项配置都有建模层面的依据不解释不清楚的配置不如不开。第五个坑忘记保存中间版本。分析过程中会反复调整参数配置我习惯每次改动都完整保存配置文件和结果导出目录文件名带时间戳。否则一旦新的一组仿真跑出来不理想想回头找旧数据对照发现已经被覆盖了那种欲哭无泪的感觉只有经历过的人才懂。做结果分析这些年最大的体会就是仿真的终点从来不是那一串数字和一堆图而是你对这些数字和图的解读能不能变成下一步动作。一次合格的5G网络仿真结果分析至少应该产出一份问题清单、一张达标对照表、一组定位到根因的解释以及至少一条可执行的优化假设。这套四轮分析流程是我自己在多个宏站、微站、室内场景项目里反复打磨出来的虽然不敢说覆盖所有情况但至少可以让刚接触仿真结果分析的人少走点弯路。最后再建议大家一件事别急着把报告写完美先把结论讲给一个不懂仿真的同事听如果他听懂了你的分析才算真正过关。