企业官网建设流程全解析

简介：面向5G网络优化工程师的实战资料，聚焦外场测试中常见的速率不达标、接入异常等问题的定位与分析方法。文档以1Gbps下行平均速率目标为主线，从NR上下行吞吐率公式出发，系统拆解调度次数、RB资源、MCS/Rank、误码率等关键指标，并给出调度次数＞1550、RB＞260、Rank*MCS>72等量化达成条件。结合SSB RSRP均值、IBLER、NR_DL_RB等实际DT数据，覆盖了核心网限速、锚点异频GAP、射频电源告警、频繁切换及D4/D5干扰等典型案例的排障思路。包体为单个PDF文件，压缩包约902KB，内容紧凑、便于离线查阅。目前已有731人学习下载，适合从事5G网优外场测试、精品路线优化及用户感知提升的技术人员参考。文档还涵盖NR小区搜索、B1测量控制、SgNB添加流程及PCI重复等接入阶段问题，可帮助读者建立从覆盖、调度到控制面的完整排查框架。

1. 5G网优外场：常见问题翻来覆去就是这几类

5G网优外场问题，一半是无线环境本身，另一半是参数与配置没对齐，后者本来可以在前期规划里避免。外场跑下来真正高频的，是接入失败、切换失败、速率不达标、覆盖空洞这几类；现象看起来都是“信号差”，但定位路径完全不同。做垂直行业也一样，室外远程驾驶、5G实训室这类项目，第一轮测试往往摔在同一批坑上。《5G网优外场常见问题分析》这类文档的价值，就是把散在几十个工单里的雷提前排一遍。这篇笔记适合准备带队外场或刚接手5G垂直行业交付的工程师照着核查，也适合老手拿来当复查清单用。下面从外场最先看的三个指标说起，再一路拆到接入、切换、速率和典型的“翻车现场”。

2. 先从LOG里读三张表：RSRP、SINR与TA怎么用

2.1 外场排查为什么要先看这三项

RSRP、SINR、TA是外场排查绕不开的三件套，但各自回答的问题完全不同。RSRP是参考信号接收功率，描述的是UE收到的信号绝对电平，说白了就是“这里有没有信号、信号强不强”；SINR是信号与干扰加噪声的比值，决定高层能不能把数据解出来，它回答的是“这个信号能不能用”。TA是时间提前量，反映UE与基站的往返时延，间接给出UE离站点有多远，它回答的是“UE是不是在它该在的位置上”。

这三项对应三类问题：覆盖空洞看RSRP，干扰和质量问题看SINR，越区覆盖和时序问题看TA。新手最容易犯的错是拿RSRP单指标定界“信号差”，但实际外场经常出现两种反直觉情况：RSRP只有-105dBm，SINR却有15dB以上，低速率数据业务照样跑得起来；反过来RSRP是-85dBm，SINR掉到2dB，页面都刷不出来。所以拿到LOG第一步不是看谁红谁绿，而是把三项指标放在同一时间轴上对照着看。

2.2 一条LOG的标准化核查顺序：五步定位问题段

外场测试软件（Probe、Assistant这一类路测工具）导出的LOG里，事件、测量量、空口消息都混在一起。我一般按固定顺序查，避免被某个刺眼的红色事件带偏。

第一步：在地理栅格图上过滤无效点。测试路线外、室内回单、设备重启产生的异常采样点全部剔除，保留连续行驶路段的有效数据。第二步：按RSRP、SINR、TA三个维度分别统计分布，确认整体水平，而不是只看平均值——平均值是最会骗人的统计量，一个-120dBm的深坑能被一段好路段拉回“正常”。第三步：把LOG里所有接入失败、切换失败、低速率事件点标出来，逐个抓事件前10秒到后10秒的测量量曲线和信令。第四步：拿工参核对问题点周边小区，重点看PCI、SSB频点、波束配置、天线方位角和下倾角有没有与规划台账不一致。第五步：把问题点归类，落到下面这张表里。

五步走完，问题基本能分成“覆盖类”“干扰类”“移动性类”三堆，后面接入、切换、速率三个方向分开查，效率比在事件列表里乱翻高很多。

2.3 RSRP不低但SINR差的典型误判

外场最常见的误判，就是RSRP看着正常、SINR却上不去，于是直接下结论“覆盖差”，派人上塔调天线，调完没变化。这种情况通常不是覆盖问题，而是干扰问题。干扰来源分三类：同频邻区干扰、外部干扰源、以及系统内的PCI混淆或互调干扰。

区分方法也不复杂。锁频复测一遍，如果问题路段换个时间测仍然固定出现，优先怀疑外部干扰，用扫频仪扫一下该频段底噪；如果只是部分时段出现，多半是邻区负荷上来后的同频干扰，看干扰小区的PCI和方向相关性；如果问题点和某个PCI强相关，查PCI混淆和SSB时频位置冲突。还有一个容易被漏掉的干扰源是馈线接头松动或天线老化产生的无源互调，现象同样是RSRP尚可、SINR差，而且换频点测试时底噪有明显抬升。判断清楚了再动手，能省掉一整轮无意义的塔上作业。

3. 接入类问题：从RACH到T300，把失败链路拆开查

3.1 先分清MSG1失败还是MSG3失败

接入失败排查的第一步，是看信令走到哪一步断的，而不是直接改参数。5G随机接入过程里，UE先发前导（MSG1），基站回随机接入响应RAR（MSG2），UE再发RRC建立请求（MSG3），基站回竞争解决和RRC建立（MSG4）。每一步断掉，原因完全不同。

MSG1失败指的是UE发了Preamble后一直等不到RAR，信令里能看到反复重发前导直至preambleTransMax耗尽。这种基本是上行覆盖不够、前导接收功率设置太低，或者TA越区导致时序对不上。MSG3失败是UE发了MSG3后没有收到MSG4，或竞争解决失败，这种情况更常见于参数冲突、小区拥塞、以及波束配置让部分UE收不到下行响应。如果MSG4发了但UE不回，那要看T300定时器、RRC配置里的公共信道参数。外场拿到一条Access Failure日志，先看是重复Preamble还是重复MSG3，这一步选错方向，后面所有调整都是白费。

3.2 波束配置与TA越区引发的接入故障

5G的波束配置比4G多一层变量。SSB广播波束决定小区公共覆盖范围，CSI-RS波束决定业务信道覆盖；两者配置不一致时，会出现UE能收到SSB、能发起接入，但业务信道质量差导致MSG3或后续RRC流程反复失败的现象。外场看工参时，不能只看天线方位角和下倾角，还要核对SSB功率偏移、波束个数和CSI-RS配置是否与覆盖目标匹配。

TA越区是另一个高频坑。站点天线挂高过高、下倾角不足时，信号可以飘到几公里外，UE收到很强的RSRP，但实际距离远超站点设计覆盖，RAR窗口错位，接入失败。现象上很有迷惑性：问题点距离近的基站很远，但RSRP很高，TA值大得离谱。处理优先级是先把越区压住，再谈接入参数。常见做法是先下调SSB功率或增加机械下倾角，把覆盖收回到设计范围内；如果越区伴随上行干扰，才考虑调整PRACH根序列和前导格式。

3.3 RACH参数核查与最小调整集

接入问题确认是MSG1或MSG3方向后，核查参数要按影响面从小到大来，避免一上来就动preambleTransMax这种重参数。

网管侧查询NR小区RACH参数，不同设备商命令格式有差异，但查询目标一致。以常见网管为例，命令形态大致是：

LST NRCELLRACH:; # 查询NR小区RACH参数 LST NRCELLPRACH:; # 查询PRACH资源配置 LST NRCELLRACHCFG:; # 查询RACH配置与定时器

参数说明：这三条命令分别对应前导配置、PRACH资源、RACH流程定时器。注意不同设备商的MML命令名不同，按现场网管手册为准。查询后优先核对rootSequenceIndex是否与邻区冲突、preambleInitialReceivedTargetPower是否在合理区间，这两个参数错配导致的接入失败占比最高。Preamble重发次数过高但RSRP不差时，别急着加powerRampingStep，先回去看是不是干扰导致MSG2没下发。

接入参数调整有个原则：一次只动一个变量，复测一轮，再决定是否继续。外场最怕同时改了三四个参数，问题解决了，但不知道是哪个改好的；问题没解决，也不知道该回退哪个。

4. 切换与移动性：A3、A4、A5不是选一个就行

4.1 同频与异频事件怎么选

切换问题在外场LOG里表现很直接：速率骤降、空口重建立、掉话。但定位到“切换失败”之后，还要再拆一层——是同频切换失败还是异频切换失败，因为两者用的是完全不同的测量事件。

同频切换通常用A3事件，即邻区质量高于服务小区一定偏移量后触发；异频或异系统切换一般用A4或A5。A4是邻区绝对质量高于门限即触发，A5是服务小区低于门限1且邻区高于门限2同时满足才触发，A5的抗干扰和防乒乓能力更强。

配置原则是：能用A3的同频场景不要换成A4，否则主服务小区还在强覆盖时就提前切换走，形成“假切换”；异频/异系统场景优先A5，比A4更稳。外场很多切换失败，不是信号问题，而是事件选错导致测量报告在错误的时机上报。

4.2 锚点与NSA/SA场景的常见错配

当前外场还会大量碰到NSA/SA混合组网。NSA场景里LTE锚点就是5G的“生命线”，UE要先在LTE侧建立RRC连接，再通过锚点添加5G辅小区。如果锚点小区信号弱或锚点邻区漏配，就会看到终端图标显示5G，但业务始终建立在LTE上，速率上不去。

SA场景则要重点看EPS Fallback，即语音业务回落到LTE的流程。这个流程本身是正常机制，但外场经常误报成“掉线故障”。判断标准是看信令里是否有Redirection或Handover到E-UTRAN的流程，以及回落目标LTE小区信号是否满足驻留条件。如果回落目标小区质量差，终端会回到5G或者直接掉网，现象像是“打电话断线”。

检查移动性配置时，按这个顺序来：先查邻区关系是否完整，再查测量事件与门限是否匹配，最后查黑名单和PCI混淆。外场遇到切换失败但邻区关系明明“有”的情况，多半是目标小区PCI在邻区表里配置了多个同频小区，或者黑名单里误加了不需要的黑名单条目。

4.3 从信令倒推切换失败原因

切换失败的信令定位，按三步走能覆盖绝大多数场景。

第一步，找到切换发起前的测量报告MR。看服务小区和邻区的RSRP、SINR是不是真的触发了A3/A4/A5；如果测量报告里邻区质量本来就不好，那失败根源是覆盖，不是参数。第二步，看基站有没有下发切换命令。UE上报MR后基站不下发HO Command，优先查目标小区准入条件、资源是否拥塞、以及SgNB/目标节点之间接口状态。第三步，看UE切到目标小区后的随机接入是否成功。目标侧MSG1或MSG3失败，查目标小区上行覆盖和PRACH配置，别在源小区的切换参数上反复调。

三种失败原因在外场很容易分辨：切换命令一直不下发，问题在基站侧策略或资源；切换命令下发后目标小区接入失败，问题在目标侧覆盖或配置；切换完成后立即掉线，问题在目标小区邻区或重配置完整性。按这个顺序查，能在三两轮内收敛，而不是把切换相关的几十个参数都试一遍。

5. 外场避坑：四条高频翻车记录与排查顺序

5.1 现场改了参数没生效，复测毫无变化

现象：塔上调了下倾角，后台改了功率，复测同一路段指标纹丝不动。

原因：八成是配置只改在了局部生效层，没有同步到真正承载业务的基站版本；或者改动时间与测试时间之间基站发生了一次配置回退。还有一种是参数改了但SIB里广播的还是旧值，UE侧行为没有变化。

解决：复测前先核对网管上配置下发时间戳和当前生效配置，确认SIB版本号与工参一致；同时用信令抓包确认UE读到的广播参数已经更新。现场调天线也一样，调完要在LOG里确认波束覆盖确实变了，而不是只看台账。

5.2 终端显示5G却打不通，查了半天不是覆盖问题

现象：市区道路测试，终端状态栏显示5G图标，但点开网页一直转圈，电话也拨不出去。

原因：NSA场景锚点丢失或锚点邻区异常，UE显示5G图标只是表示注册上或驻留在5G能力网络，不代表数据承载建立在5G上；SA场景则可能是EPS Fallback后回落目标LTE小区无法承载业务。

解决：把测试软件切到信令视图，看PDU Session建立在哪个RAT上、有没有辅小区添加失败记录。如果锚点LTE信号差，优先处理锚点侧覆盖；如果辅小区添加失败，查目标5G小区PCI混淆和资源配置。记住一条：5G图标≠5G业务，一切以信令里的承载建立为准。

5.3 天线参数台账全对，覆盖还是塌了一块

现象：工参上方位角、下倾角与规划完全一致，但某个方向出现明显覆盖空洞。

原因：台账只记录了机械下倾角，没算电子下倾角和波束权值叠加后的实际辐射角；或者SSB功率偏移设置太保守，广播覆盖范围小于天线物理辐射范围。

解决：用覆盖仿真工具把机械下倾角、电子下倾角、波束权值合起来算实际波束指向，再和实测RSRP分布对比。外场特别是城区站点，电子倾角往往比机械倾角变化更灵敏，台账对不上时先查波束配置，不要直接上塔。

5.4 同一路段两次测试指标差异巨大，结果是测试终端不一样

现象：上午测完速率900Mbps，下午换了一台终端复测只有400Mbps，当晚被怀疑“基站退化了”。

原因：不同终端接收灵敏度、天线数量、支持的MIMO层数和调制阶数不同；测试软件的采样窗口和测量量统计口径也可能不一样。

解决：外场对比测试必须固定终端型号、软件版本、天线形态和终端摆放方式。拉网测试和定点测试分开记录，所有速率结论注明终端能力，否则前后数据根本没有可比性。

6. 速率问题不只看均值：一条LOG回查MCS、BLER与调度

速率低是最难靠直觉判断的问题，因为高层速率是“资源 × 调制 × 编码 × 层数”的乘积结果，任何一个因子掉了都会体现为速率下降。与其对着平均值猜，不如把一条低速率LOG按时间轴拆开，画三条曲线：MCS分布、BLER、PDSCH调度RB数。MCS均值高但调度RB数长期偏少，问题在调度策略或邻区干扰；MCS低且BLER高，问题在信道质量，回到SINR那条线去查；MCS和RB都正常但速率仍低，查Rank和MIMO层数，很多终端的Rank被限制到1，多流没建立起来。

实际定位时，先按理论速率公式做一次逆向拆算：把目标速率除以实际RB数、实际调制阶数、实际编码效率和空间层数，看差距落在哪一层。比如100MHz带宽、30kHz子载波、273个PRB，配256QAM、编码效率0.926、4层时理论峰值在1.3Gbps量级；实测只有300Mbps，拆下来往往是编码效率掉到0.5以下或Rank只有2。一段一段回放，把“低速率段”和RSRP、SINR曲线重合起来看，比盯着一整条LOG的平均值定位快得多。

我现在的习惯是每次外场测试固定导出一份完整信令LOG，回来后不管当天指标好不好，都选一段正常路段和一段问题路段做MCS/BLER回放，把当日结论和之前的记录叠在一起看趋势。这个习惯救过我很多次，因为很多外场问题不是一次性故障，而是缓慢劣化，单看一天的LOG永远看不出来。希望帮到你，下次外场也留一份可回放的LOG，比多带一台测试终端管用。

本文还有配套的精品资源，点击获取