多彩编程 多彩编程MZPH · CODE BLOG
ARTICLE DETAIL

文章详情

深耕前端与后端开发技术的一线实战笔记与踩坑复盘。

5G网优外场常见问题分析:从路测指标到根因定位实战指南

5G网优外场常见问题分析:从路测指标到根因定位实战指南 简介《5G网优外场常见问题分析》是一份面向5G网络优化工程师与通信技术人员的实战文档聚焦外场拉网测试中下行平均速率1Gbps目标的达成条件与影响因素。文档从NR上下行MAC层吞吐率公式出发梳理了调度次数、调度RB数、Rank*MCS、初传误码率等关键阈值并结合DT数据案例给出SSB RSRP、NR_PDCCH_DL_Grant_Count、平均MCS/RANK、IBLER、NR_DL_RB等指标的检查顺序与判定方法。同时内容覆盖核心网AMBR限速、锚点异频GAP测量、射频单元供电告警、频繁切换、D4/D5/D1/D6干扰等速率低典型场景以及5G接入阶段B1测量控制下发、X2接口SgNB添加、外部小区PCI核查等接入信令流程。包内共1个PDF文件约902KB以图文公式结合呈现可直接作为日常网优排障的速查参考。已有731人学习下载适合具备一定NR基础、希望提升外场问题分析效率的读者参阅。1. 5G网优外场到底在解决什么从投诉工单到问题闭环的现场地图下午三点接到投诉说某个路口 5G 速率上不去用户站在路边测速只有 30Mbps旁边营业厅里同样手机能跑到 800Mbps。带上路测软件、扫频仪和测试终端赶到现场SS-RSRP 显示 -92dBm信号不弱SS-SINR 只有 2dB明显异常。后台查了小区状态、告警、负荷全部正常。这种“现场数据看着奇怪、后台又查不出毛病”的僵局就是 5G 网优外场常见问题分析要解决的核心场景把路测指标、信令流程、邻区关系和参数配置串成一条完整的证据链从现象定位到根因再落到整改和复测验证。这篇笔记适合刚转岗的网优测试人员也适合有 4G 经验但被 5G 波束、终端能力和协议栈细节绕晕的老手。2. 外场问题怎么定位覆盖、干扰、切换三大类问题的现场判断流程2.1 先分清问题类型信噪比才是第一现场指标外场拿到一组路测数据第一件事不是记速率而是把整条 log 按“覆盖、干扰、切换、速率时延”四个方向归类。4G 时代很多人习惯了先看 RSRP弱了就想加功率5G 里这个习惯很容易翻车因为 5G 的 SS-RSRP 和 SS-SINR 经常不同步——信号强不等于信道质量好SS-SINR 才是综合反映波束质量、干扰水平和调制能力的现场第一指标。我在外场判断问题时习惯按下面的组合先粗筛一遍问题类型关键指标组合优先怀疑方向现场要带的工具弱覆盖SS-RSRP -110dBmSS-SINR 尚可站间距大、遮挡、波束未对准路测软件、扫频仪、电子地图干扰SS-RSRP -100dBm 但 SS-SINR 5dB外部干扰器、越区覆盖、邻区 PCI 冲突扫频仪、干扰分析功能切换类服务小区 RSRP 渐变差、邻区强但迟迟不切A3/A5 参数、TTT、CIO、邻区漏配信令分析工具、邻区列表速率低MCS 低、CQI 差、BLER 偏高干扰、功控、终端能力、PRB 不足测试终端、后台话统、峰值速率公式这个表看着简单实际外场里最大的坑是混淆把干扰造成的 SINR 差误判成弱覆盖把终端能力造成的限速误判成基站功率不足。判断问题类型时至少看三组指标的组合不能只凭一个数下结论。2.2 外场测试准备清单终端、路线与工具核对外场测试最怕的是到了现场才发现工具没带齐或者带了测试终端却不清楚它支持哪些频段和带宽。我一般会在出发前做三件事第一确认测试终端开启了 SA 模式且支持目标小区的频段——比如 n78 或 n41如果终端只支持 60MHz 带宽而小区开 100MHz测出来的速率上限天然矮一截这不是网络问题第二准备扫频仪并把目标小区的 PCI、频点、邻区列表提前从后台导出进了现场先确认“当前占用的到底是不是目标小区”第三规划测试路线覆盖用户投诉点周边的所有主干道和典型室内位置。路线设计上DT 测试要注意车速对采样点的影响CQT 测试则要固定位置、固定终端方向。外场经常出现的情况是投诉点在某小区地库测试人员只在路面测了半小时就下结论说覆盖正常。这种“没覆盖到用户真实活动场景”的测试后半段的参数分析再漂亮也是白搭。宁可多花二十分钟进地库、上楼、穿巷道也别留一个说不清的场景缺口。2.3 扫频仪先扫一遍用扫频结果排除外部干扰到了现场我习惯先扫频再路测。原因是路测软件只能看到服务小区和已配邻区的信号扫频仪能看到频段内所有小区的信号特征包括没配置邻区关系的“隐性问题”。如果扫频显示整个频段底噪均匀抬高优先怀疑外部干扰源如果底噪只在某段 PRB 上抬高多半是特定设备或邻区信号叠加造成的。扫频结果要跟基站侧的上行干扰统计对照着看。一个常见做法是现场扫频上有强信号但 PCI 不在邻区列表里回后台查这个 PCI 的站址十有八九是越区覆盖。扫频仪的作用不是测速率而是把“地图”先铺出来——哪些方向有小区、哪些方向信号异常心里有了底后面路测数据才好解释。记住一点外部干扰在路测里往往表现为 SINR 差但后台小区发射功率正常这种情况继续调功率是浪费时间的应该把干扰源坐标和频谱特征记录下来走协调整改的路子。3. 从路测日志到根因结论信令指标核查与外场数据的实操拆解3.1 路测日志怎么读RSRP、SINR、MCS、BLER 五组指标一起看路测日志导出来以后不要盯着“下行速率”这一个字段翻。速率只是结果真正能定位的是它背后的调制与误码链路下行速率低先看 MCS 是多少MCS 低看 CQI 和 SINRBLER 高再看是功率不够还是干扰抬升。我经常用的一个过滤脚本是把 RSRP 好而 SINR 差的点全部筛出来这些点就是干扰或越区覆盖的嫌疑区import pandas as pd df pd.read_csv(dt_log_0512.csv, encodinggbk) # 过滤出 RSRP 较好但 SINR 较差的采样点 # 这类点优先怀疑干扰、越区覆盖或邻区漏配 bad df[(df[SS-RSRP(dBm)] -95) (df[SS-SINR(dB)] 5)] cols [时间, 纬度, 经度, SS-RSRP(dBm), SS-SINR(dB), 下行MCS, 下行BLER, 下行速率(kbps)] print(bad[cols].head(30))这段脚本的逻辑是如果信号强度超过 -95dBm 但信噪比掉到 5dB 以下说明不是弱覆盖造成的而是有东西在“污染”信道。参数说明里两个阈值要按场景调整密集城区 RSRP 底子好阈值可以放到 -100郊区弱覆盖场景要放宽到 -90否则会把弱覆盖点也筛进来。BLER 字段在日志里常有两种格式百分比或小数过滤前先确认单位不然很容易把正常点误判成异常点。筛选出嫌疑点后把它们的经纬度打到地图上看是否集中在某段路或某个楼宇附近。如果嫌疑点连成线通常是越区覆盖或外部干扰如果只是零星散点优先怀疑采样误差或终端在波束边缘快速移动。3.2 一次接入失败的信令分析流程从 MSG1 到 RRC 建立5G 接入失败是外场投诉的高频问题但很多测试人员看到“随机接入失败”这个提示就不知道往下怎么看了。接入过程不是一条黑匣子它有明确的阶段和判断节点按阶段核对就能定位信令阶段核心信令常见失败原因现场看什么随机接入MSG1 至 MSG2上行不同步、PRACH 资源受限是否收到 RARRAR 里的 TA 值是否异常竞争解决MSG3 至 MSG4冲突未解决、C-RNTI 分配失败MSG4 是否携带竞争解决 MAC CERRC 建立RRCSetup 至 RRCSetupCompleteT300 超时、小区拥塞、准入失败空口信令是否被拒绝拒绝原因值业务承载DRB 建立过程QoS 参数异常、核心网路径问题看建立失败是空口还是 NG 接口侧我排查接入失败最多的情况是 MSG1 发了但收不到 RAR——在 5G 里这不一定是网络问题终端上行功率不足、PRACH 格式和小区配置不匹配都能导致。现场做法是先看测试终端发射功率是否被压到上限以下再看小区 PRACH 相关参数是否与终端能力匹配。另一类高发是 RRCSetup 之后立刻释放这种要回后台查核心网侧的注册拒绝原因值不能在外场死磕空口。信令分析的核心原则是每一步失败都由上一步的“没收到/收到异常”来界定谁先断了根因就在谁那一段。3.3 MR 数据与参数核查做二次确认空口表现的反例有些投诉现场怎么测都测不出问题路测 RSRP、SINR、速率全正常但用户就是天天抱怨。这种就属于“路测没复现”的典型案例原因多半是外场测试轨迹覆盖不了用户室内的具体位置。这时候要回到后台拉覆盖区域的 MR 测量报告做栅格化分析看用户实际位置在 MR 分布里处于什么水平。如果 MR 显示某一栅格 RSRP 在 -105dBm 上下波动而路测跑的是它旁边的马路、信号在 -90 以内结论就清楚了不是网络“没毛病”是测试根本没测到用户所在的深度覆盖点。另一个反例是空口指标很好但切换失败率高这种要查 Xn 接口或 NG 接口的路径是否正常别在 RSRP 上浪费时间。外场分析最忌讳一条道走到黑路测数据只是入口MR、话统、信令跟踪三样俱全才敢下结论这也是把“常见问题分析”从经验玄学变成可复现方法论的关键。4. 常见问题避坑指南5 个反复出现的外场误判与处理教训4.1 换台手机测速差几倍不是网络波动而是终端能力假限速现象同一位置、同一个小区商用手机测速 300Mbps另一台只有 80Mbps重测多次结果稳定。原因测试终端没有开启 SA 模式或终端只支持部分频段带宽甚至某些机型在非官方版本里 CA 和 5G 能力被禁用导致实际调度带宽只有小区带宽的一半甚至更少。解决测试前确认终端型号、软件版本、SA/NSA 模式设置并在日志里记录终端能力如果条件允许至少准备两台不同芯片方案的商用机交叉验证。换终端后速率恢复正常就说明问题在终端侧而不是网络侧。4.2 SS-RSRP 不弱但路上信号差是波束没对准主路现象扫频仪在路边能看到小区广播信号但路测 RSRP 始终不稳定忽高忽低车速稍快就掉到 -110dBm 以下。原因5G 用的是波束赋形SSB 波束的扫描范围和功率配置决定了路面覆盖是否连续如果波束下倾角或水平扫描范围没按规划设置就会出现“盖了天、没盖地”的情况。解决现场先记下 AAU 的安装方位角和下倾角回到后台核查 SSB 波束参数和天线权值设置对照 5G 设备 AAU/DU/CU 安装指导书里对覆盖场景的建议配置调整波束后复测重点关注 RSRP 的连续性而不只是平均值。4.3 越区覆盖造成的“伪 SINR 差”查了半天外部干扰却查无实据现象某路段 SS-RSRP 长期在 -90dBm 以上但 SS-SINR 只有 2~3dB用户感知明显卡顿扫频和话统都没发现底噪抬升外部干扰排查无果。原因这不是外来干扰而是远端的另一个小区越区覆盖到本路段信号强但和当前服务小区形成强邻区干扰同时切换关系又没配置好导致终端一直挂在质量差的小区上。解决用扫频数据找到这个“隐藏邻区”回后台核查是否已配置邻区关系如果已配置看切换事件为什么没触发通常要调整 A3 事件的 TTT 或 CIO如果没配置先补邻区再复测SINR 往往马上就回来。4.4 上行速率上不去先别急着报上行干扰现象上行速率只有 10Mbps扫频仪看底噪正常后台话统上行干扰电平也正常但终端发射功率看起来也不高。原因上行功控参数把终端 PUSCH 发射功率压得过低或上下行时隙配比里上行时隙资源本身就少导致上行传输资源不足。5G 的 TDD 时隙配比对上下行速率影响极大很多人习惯用 4G 的经验直接判断“上行差上行干扰”这个直觉在 5G 里经常翻车。解决先核查上下行时隙配比和特殊子帧配置再查上行功控期望功率和调度算法参数最后才谈外部干扰。顺序反了容易把一个配置问题拖成无效排查。4.5 参数怎么调都无效最后发现是射频通道故障现象某个小区覆盖范围内的速率和 SINR 时好时坏每次测试结果都不一样后台参数改了几轮效果微乎其微。原因AAU 的某个射频通道增益异常或天线端口驻波比过高导致波束赋形增益损耗信号虽然“有”但质量始终不稳定。这种硬件问题在外场日志里往往没有直观体现只有综合分析时才能发现规律性异常。解决先查 AAU/DU 的射频告警、驻波比和通道校准状态做一次通道测试确认各通道增益是否一致确认硬件干净了再动参数。外场调整有一条铁律硬件问题不排除参数分析永远是玄学。5. 从分析到整改落地参数调整手段与验证闭环的执行细节5.1 覆盖类整改功率与波束参数怎么调覆盖类问题的参数调整思路分两层一是功率参数二是波束参数。功率方面常见调整对象是 SSB 功率和 CSI-RS 功率步进一般按 1~2dB 来不要一次调太大。调功率会同时改变干扰格局单独把某个小区功率抬上去很可能把邻区的 SINR 砸下来所以每次调整都要记录调整前后邻小区的指标变化。波束方面主要调 SSB 波束扫描范围和电下倾角常见做法是利用 5G 天线参数里的波束配置表选择更聚集或更展开的扫描模式。调整完成后要做的不是看单点 RSRP 涨了多少而是看目标覆盖区域的 RSRP 达标占比、SINR 分布和邻区重叠覆盖度三样指标。5G 外场覆盖整改最容易出的问题是把“点好”当成“面好”投诉点信号改善了转身两百米又掉链子这就是只调了单点功率、没解决波束连续覆盖的典型后果。覆盖整改验证至少要在整条路段或整个楼宇范围做两轮测试才能确认不是偶然采样。5.2 干扰类整改从外部干扰到邻区协调干扰类问题的整改手段取决于干扰源的类型。外部干扰源比如非法信号放大器、特定设备辐射没法靠基站参数解决正确的做法是把扫频采集到的频谱特征、干扰方向和大致坐标整理成报告移交给干扰协调环节处理站侧能做的只是临时调整功率或小区偏置把受害范围压到最小。内部干扰则不同常见的整改路径是核查目标小区邻区列表把漏配邻区补齐调整越区覆盖小区的功率或下倾角减少重叠覆盖区检查 PCI 模三或模三十冲突调整冲突小区的 PCI 规划调整控制信道功率配比避免 PDCCH 区域互相干扰对仍然无法消除的同频干扰考虑时域或频域协调策略。第 3 步最容易被忽略因为 PCI 冲突在路测 log 里不直接报错只有扫频或后台核查才能发现。做干扰类整改时我习惯把“改前干扰底噪、改后干扰底噪、受影响小区 SINR 变化”三条数据存下来作为判断整改是否有效的依据。5.3 切换类整改A3/A5、TTT 与 CIO 的参数手感切换问题在外场常见表现是“信号差还不切”或“来回切”。前者要看 A3/A5 事件的测量配置和 CIO后者要看 TTT触发时间是不是设置得太短或太长。常见开局里 TTT 在 160ms 到 480ms 之间密集城区为了防止乒乓切换一般取偏大值但过大的 TTT 会让终端在弱信号区停留太久反而降低用户体验。CIO 的调整手感是按 0.5dB 步进试一次不要超过 2dB。CIO 是小区级的偏置调整它会直接影响该小区和邻区之间的切换边界调大了可能出现非最佳服务小区驻留。换一句话说CIO 是后悔药但吃多了会掩盖邻区关系和覆盖规划的真正问题。切换类整改要一条一条地改、一条一条地复测批量调整多个小区的切换参数后一旦出现切换失败率上升排查范围会变得非常大。5.4 验证闭环改完测什么、测多久、和谁的基线对比参数调整完成不等于问题解决验证环节才是整个闭环的终点。验证测试讲究“三同”同路线、同终端、同业务模型。测速至少测三遍取中位数避免单次波动误导判断。对比指标不只看速率还要看这组组合下行速率、上行速率、SS-RSRP、SS-SINR、MCS、BLER、切换次数。阶段必测项目判断标准改前基线完整路线 DT 投诉点 CQT记录速率、SINR、MCS、BLER、切换次数改后复测同一路线相同细节与改前基线逐项对比速率提升 10% 以上才算有效回归观察周边邻区指标、后台告警确认没有因为本次调整引发新的邻区问题提示如果复测改善幅度小于 1dB 或速率提升不到 5%要重新评估这次调整是否值得保留。参数调整是有代价的为了单点 0.5dB 的提升牺牲了周边覆盖这个买卖不划算。6. 把经验转成可复用的分析套路外场问题归档模板与进阶习惯6.1 一个外场问题归档模板外场问题分析做久了会发现大量问题的分析路径是重复的。每次处理完一个投诉或一轮测试我会按固定格式把过程存档字段包括问题编号、日期、地点、场景类型道路/室内/地库、测试终端型号与版本、测试基线RSRP/SINR/MCS/BLER/切换次数/上下行速率、根因分类覆盖/干扰/切换/硬件/终端、参数调整记录、复测结果、是否闭环、备注。这个模板最大的价值是让下一次类似问题不用从零开始。见到“RSRP 好 SINR 差”的记录先翻归档里同场景的处理过程能省掉大半现场排查时间。6.2 每周复盘的进阶习惯我还有一个坚持了两年的习惯每周抽三个已闭环的问题重新看一遍原始日志。重点不是回忆怎么解决的而是看当时有没有“撞运气”的成分——有些问题调完参数好了但当时根本没搞清真正的根因复盘中会发现很多结论其实是侥幸。最典型的一跤是当年只调了 CIO 让切换提前发生、SINR 改善就以为完事后来才知道根因是越区覆盖参数调整只是把问题藏起来了。现在我对每个问题都要求自己能讲清楚“现象、根因、改了什么、为什么这个改动有效”四件事缺一件就不算真正闭环。这个习惯让后续类似问题的平均处理时间缩短了一大截。归档和复盘看起来不产生直接收益但它是从“会测”走向“会分析”最稳的一条路希望帮到你。本文还有配套的精品资源点击获取
返回列表