网络问题排查实战：速率低、MOS低与随机接入失败的端到端定位方法

1. 网络问题排查的总体思路：先把问题“翻译”清楚

1.1 现象描述是第一步，也是最关键的一步

很多工单推进不下去，不是技术不行，而是现象没问清楚。用户说“网速慢”，背后可能是一百种完全不同的场景：是在家里慢还是公司慢？是下载慢还是网页打不开？是某个APP慢还是所有业务都慢？是全天都慢还是某个时段慢？是新的5G手机还是老款终端？这些问题不搞清楚，排查方向就很容易被带偏。

我自己的习惯是接到任何问题先列一个“三问清单”：

• 什么业务？网页、视频、游戏、文件传输各不相同，对速率和时延的敏感度差异很大。
• 什么时间？忙时和闲时现象可能完全不同，忙时出现的问题大概率与容量或拥塞相关。
• 什么位置？室内外、近中远点、是否在小区边缘，决定了覆盖和干扰的排查优先级。

这三问看起来简单，真能坚持做下来的工程师不多。但恰恰是这一步，决定了后面排查是走无线、传输、核心网还是终端方向。例如“整个小区所有用户都慢”和“只有某个用户慢”，处理路径完全不同；前者大概率是小区级配置或资源问题，后者基本就是用户自身或终端问题。

还有一点要特别提醒。处理问题之前，先把现象发生时间点的告警数据拉出来看看。无线侧告警往往是最先暴露问题的，比如小区退服、RRU链路异常、传输断链、光模块告警等等。很多时候，看似复杂的业务问题，追根溯源就是一条告警引起的，先看告警能省掉大量无用功。我见过太多同行拿着路测设备跑到现场，测了半天发现是光模块收发光异常，早知道就该先看告警。

1.2 端到端分层定位的思路

速率低、MOS低、随机接入失败，表面是不同指标，但底层都是端到端的链路问题。所以排查的核心思路，可以统一归纳成“从终端到空口、从无线到核心网的逐层剥离”。这也就是业内常说的“分层排除法”。

具体来说，我会把整条链路分成四段：

• 终端侧：终端能力、射频状态、软件版本、业务配置。
• 无线接入侧：覆盖、干扰、资源调度、RRC与承载状态。
• 传输侧：S1/X2（或5G的NG/Xn）接口的带宽、时延、丢包。
• 核心网侧：用户面转发路径、网关配置、策略控制。

定位的通用方法是“同一时刻对比多段指标”。比如速率低时，如果空口SINR很好、RB分配充足、MCS也高，那么问题大概率不在空口，就要往传输和核心网方向查；反过来如果空口指标就不好，那就老老实实处理覆盖和干扰。

这个思路其实就是常说的“分层排除法”。网络优化的大部分工作，不是在某个单一环节解决多高深的问题，而是快速把问题定位到正确的层次，然后用对应层次的工具去处理。后面三个章节，我会用速率低、MOS低、随机接入失败三个典型场景，把这套分层思路具体展开。

1.3 常用的数据采集工具和手段

设备厂商不同，实际使用的工具也会不同，比如中兴的网管与路测软件、华为的U2020与Probe、爱立信的操作维护系统等。但采集数据的手段大体一致，我按类型总结下：

• 网管侧数据：小区级KPI，包括RRC建立成功率、E-RAB建立成功率、切换成功率、丢包率、PRB利用率等，以及告警与历史告警记录。这类数据用来做小区级问题初判，比如整个小区KPI恶化，那问题很可能是共性问题，不用先跑现场。
• 路测数据：用路测软件记录覆盖、干扰、调度、信令流程。这类数据的优势是能看到具体位置和对应信令，适合处理局部性、位置相关的问题。
• 信令平台数据：核心网信令平台可以拉取指定用户或指定业务的详细信令记录，适合查接入失败、鉴权失败、业务挂起等问题。
• 终端侧数据：手机工程模式、路测终端，或者直接用运营商网优APP查看参考信号接收功率、信噪比、调制方式等信息。

对于5G网络，还要特别关注SSB（同步信号块）的测量和波束覆盖情况，因为5G窄波束下，同位置RSRP飘忽不定往往是波束选择问题，这在后面速率排查部分会专门展开。工具不在多，关键是会用、用对。很多新同事问我推荐什么工具，我一般建议先把网管和路测这两样吃透，其余的按需补充就够用了。

2. 速率低问题的排查：从“用户说慢”到定位根因

2.1 速率低问题怎么分类：先判断是覆盖、容量还是传输

速率低是最常见的投诉类型，但“速率低”这三个字过于笼统。拿到工单后，我通常会先按两个维度把问题粗分：一是影响范围（单个用户还是整个小区），二是业务方向（下行还是上行，或者特定业务）。

按我的经验，先看影响范围基本能定一半方向：

• 整个小区速率都低：优先看是不是小区PRB利用率打满（容量受限）、小区级参数配置问题、传输带宽缩水、或者外部干扰。
• 单个用户速率低：优先看用户的空口质量、终端能力、用户签约速率、当天流量是否触发限制策略等。

再看上行还是下行：

• 下行速率低，常见原因包括：弱覆盖、下行干扰导致MCS低、PDCCH调度受限、TCP窗口小、传输下行带宽不足。
• 上行速率低，常见原因包括：终端发射功率不足（比如在覆盖边缘）、上行干扰、上行RB分配不足、功率控制参数不合理等。

判断阈值方面，不同网络制式和带宽差异很大，但可以给你一个经验参考值。比如20MHz带宽的LTE，单用户满调度下（理想条件）下行峰值速率理论上约150Mbps左右（64QAM、2×2 MIMO），实际业务一般能达到100Mbps以上就算正常；如果峰值只有30到50Mbps，明显低于预期，就该系统性排查了。5G NR 100MHz带宽（30kHz子载波间隔）单用户理论峰值受调制阶数和流数影响较大，一般使用终端实测速率与理论峰值做对比，正常业务环境下差距应该在30%以内，若差距过大就需要逐项排查。

2.2 无线侧排查的关键指标和动作

无线侧排查是速率低问题的重头戏，因为大部分速率异常都源于空口。我建议按下面的顺序逐个检查。

先看参考信号接收功率（RSRP）和信噪比（SINR）。RSRP反映覆盖，SINR决定调制编码方式（MCS）等级。LTE/5G里，SINR直接决定终端能不能用高阶调制（256QAM）和多流传输。经验阈值：RSRP低于-110dBm时属于弱覆盖，SINR低于10dB时速率基本会明显打折扣。在路测软件里，你可以直接看到当前终端使用的MCS等级，如果MCS一直徘徊在低等级（比如10左右），那基本可以判断是信道质量受限。

这里有个容易踩的坑：在5G网络里，RSRP看着还行（比如-95dBm），但SINR很差，这时候不要只盯着覆盖，优先查干扰和波束。5G的窄波束特性决定了某个具体位置很可能落在波束边缘，SSB的RSRP看起来可以，但PDSCH实际调度的波束增益不够，速率就会低。

再查CQI（信道质量指示）。CQI上报反映了终端对当前信道质量的评估，网络侧根据CQI选择MCS。如果CQI上报低，而RSRP/SINR指标看着又正常，就要看终端上报的CQI是否存在异常，比如CQI延后、上报周期过长、或者终端天线遮挡等问题。CQI从15掉到6、7的水平，速率几乎对半砍。

接着查资源调度情况，包括：RB分配是否满、PDCCH调度次数、上下行授权是否充足、MCS分布。在路测软件里，直观的现象是“RB没满但MCS也不高”，这种情况常见于干扰受限，而不是容量受限。如果RB满、MCS高、但流量就是上不去，那问题大概率在传输或核心网。

还有一个5G特有的问题：空口时隙配置。5G中上下行时隙比配置（比如7:3、8:2、4:1）直接决定下行和上行吞吐率上限，如果配置异常或基站与终端支持的时隙配置不匹配，会导致速率骤降。NSA组网初期这类问题尤其常见，因为NSA双连接需要对LTE和NR的调度进行协同，终端能力协商不完整时，NR侧调度就会受限。

2.3 传输侧和核心网侧的排查重点

空口指标都正常时，事情就转向传输和核心网了。这一层很多网优工程师不太熟，但排查逻辑是一样的：看带宽是否够、时延是否低、有没有丢包。

传输侧关键检查点：

• S1-U（4G）或NG-U（5G）接口带宽配置。比如基站侧传输接口协商成了100Mbps，用户实际速率也就是百兆封顶。这种情况在运营商项目里不少见，传输部门按带宽套餐开的数据，未必和基站侧期望配置一致。
• 传输链路上是否拥塞。特别是高峰期，上游传输设备转发能力不足时，吞吐率会呈现“锯齿状”波动。
• 分组的丢包率与时延。在基站侧抓包，看用户面的丢包和时延，与传输承载的承诺指标做对比。一般要求单向时延10ms以内，丢包率低于0.1%，超过这个范围，TCP就会明显降速。
• 传输VLAN配置。遇到过几次“速率忽高忽低”的投诉，最后查明是传输设备上VLAN规划重叠，导致广播流量把链路带宽吃掉了。

核心网侧主要检查用户面的转发路径和策略：

• 用户签约速率等限制（QoS模板设置）。
• PGW/UPF的用户面处理能力及负载情况。
• 是否触发限速策略，比如某些套餐存在达量降速。
• 核心网网元之间的路由配置是否优化，是否存在绕路。

有一种情况容易忽略：TCP吞吐率优化。移动网络里大文件下载速率往往受TCP拥塞窗口增长限制，尤其在高时延场景下。如果空口、传输、核心网都正常，建议直接用多线程或UDP灌包做对比测试，能快速区分是不是TCP参数问题。我记得有一次查一个速率低的问题，各方面指标全部正常，最后用Iperf灌UDP，速度能跑满，而TCP就卡在30Mbps，查了一圈发现是终端到服务器跨省链路时延太高，TCP窗口增长太慢导致。

2.4 终端侧容易被忽略的问题

最后再讲终端。别笑，终端侧的问题占我个人处理类工单的比例，真的能到三成左右。

最常见的是终端能力与网络不匹配，比如老款终端不支持256QAM、不支持4×4 MIMO、不支持5G载波聚合，这些都会制约速率上限。在4G网络里，很多用户用了好多年的手机只支持单天线接收，速率自然跑不起来；5G初期更是如此，一些手机虽然显示5G图标，但实际只支持NSA单载波，峰值速率和5G载波聚合的终端差距巨大。

其次是终端的省电策略和后台应用。手机电量低进入省电模式时，会主动降低基带性能和天线接收增益；后台如果有一堆应用在跑，虽然业务层显示没有大流量，但会占用终端侧的调制解调器资源，影响空口调度表现。排查时可以建议用户开启飞行模式再关闭，或者换一台终端做对比测试，基本就能定位。

还有终端的应用程序本身：某些APP的服务器部署在外地，链路长了吞吐率自然不行；APP的并发能力、TCP连接复用等问题也都会让用户体验变差。这类问题测速软件是测不出来的，因为测速服务器通常就在本省或本地。这也是为什么我建议处理速率类投诉时，一定要先让用户分别测“运营商测速服务器”和“实际业务APP”两种场景，结果往往截然不同。

3. 语音MOS＜3问题的排查

3.1 先搞清楚MOS是啥

MOS的全称是Mean Opinion Score，中文叫平均意见得分，是评估语音质量的主观评分。在LTE/5G网络中，语音业务主要走VoLTE（4G）或VoNR（5G），MOS分就是衡量语音通话主观感受的核心指标。

这里必须说明一点：MOS和电子电路里的MOS管完全是两回事。有些做硬件设计的同事看到“MOS”两个字可能以为是金属氧化物半导体场效应管，但在通信网优领域，MOS是语音质量评分，评分范围一般是1到5分：5分表示非常好，4分是较好，达到4分以上是运营商普遍期望的水平；3分属于中等水平，能听但已经有明显失真感；低于3分就是较差，常有断续、杂音、回声等问题。所以“MOS＜3”在语音优化里是明确的劣化阈值，说明语音质量已经差到用户会明显感知甚至投诉了。

MOS分的计算主要通过两种算法：PESQ（语音质量感知评估，主要针对窄带语音）和POLQA（感知客观语音质量评估，适用于宽带及超宽带语音）。在VoLTE/VoNR中通常使用POLQA，它会将实际采集到的语音信号与参考信号做比对，综合时延、丢包、抖动、编码类型、噪声等维度给出一个1到5的分数。路测软件、信令监测平台和部分网管，都可以输出实时的MOS值。

3.2 哪些因素会把MOS拉低

MOS<3的原因，可以按影响机制分为几大类。

第一类是空口无线质量问题。这是VoLTE/VoNR下最直接的影响因素。语音数据包在空口传输时，如果SINR差、RSRP弱或存在干扰，会导致数据包重传甚至丢包。语音业务对丢包非常敏感，1%的随机丢包就可能让MOS掉到3分以下。重传带来的额外时延也同样致命，因为语音是实时业务，超过一定时延就无法还原，等效于丢包。

第二类是切换和移动性问题。语音通话过程中如果发生频繁切换、切换失败、或者跨基站切换时的数据转发延迟增大，会造成短暂的语音中断或语音变形。在高铁、高速等场景，移动性导致的MOS劣化尤其突出。我一直建议处理这类问题的时候，把切换事件和MOS曲线放到同一个时间轴上看，对应关系特别明显。

第三类是编码和协商问题。VoLTE/VoNR使用AMR-NB（窄带）、AMR-WB（宽带）、EVS（增强语音服务）等编码。编码带宽越宽，语音自然度和清晰度越高。当网络或终端协商导致用了低带宽编码，或者编码模式在通话过程中因信道质量自动降级，MOS分就会明显下降。比如从EVS降到AMR-NB，MOS分通常会下降1到1.5分。

第四类是网络侧配置和传输质量问题。包括：抖动缓冲（Jitter Buffer）设置不合理、核心网媒体面处理节点时延波动、承载语音的QCI=1承载配置有问题等。这些属于“背景层”问题，空口看起来很好，但通话质量就是差。说实话这类问题最难查，因为指标都在正常范围，但主观体验就是不好。我遇到过一例，最后是核心网媒体面节点做了软件升级后自动解决的，说明底层还有不少黑盒因素。

第五类是终端自身问题。终端的麦克风拾音质量、扬声器回放质量、是否开了免提、降噪算法是否生效，都会影响主观听感。这也是为什么在路测评估时，会要求统一使用指定测试终端，就是为了减少终端差异造成的评估误差。

3.3 MOS＜3排查的具体动作

处理MOS<3问题，我习惯的步骤是先分场景，再做专项测试。

第一步：把MOS差的场景切分清楚。是全网性的还是局部性的？是固定位置还是只出现在移动过程中？是通话建立阶段差还是通话中段差？这些不同场景对应的原因差异很大。比如固定位置差，大概率是覆盖或干扰；移动过程中差，大概率是切换或邻区问题；建立阶段差，重点看QCI承载建立和编码协商；通话中段差，重点看丢包和抖动。

第二步：拉取话统和路测数据做关联分析。在路测数据里，把MOS差的时段与空口指标放一起对齐：看该时段的SINR、RSRP、PDCP丢包率、RTP丢包率、抖动、重传率、切换事件。绝大多数情况下，MOS差都能在这些空口指标里找到对应关系。这里给大家一个排查时常用的对照参考：

• RTP丢包率大于1%，MOS基本就会到3以下。
• 抖动大于50ms且持续较长时间，MOS会明显下降。
• 频繁切换（比如一分钟内多次切换）的场景，MOS往往在3左右徘徊。
• 编码协商为AMR-NB且信道质量一般，MOS很难到3.5以上。

第三步：针对原因做专项优化。若是覆盖问题，调整天线方向和倾角或增加补点；若是干扰，做MOD3/PCI优化或外部干扰排查；若是切换问题，调整CIO、切换迟滞等参数或者优化邻区关系；若是编码协商问题，在核心网侧检查AMR配置和语音编码优先级，确认是否启用了EVS。

这里我有一个建议：处理MOS问题别只盯着一项指标。MOS是端到端体验指标，它反映的是整条语音链路的情况。如果丢包、时延、编码、抖动四个维度里有两项同时不佳，MOS会掉得非常快。所以排查时最好把四个维度同时打出来，再一个个过滤，而不是只看到丢包率高了就只处理丢包。

4. 随机接入失败问题的排查

4.1 随机接入为什么这么重要

随机接入是终端接入网络的第一步，也是很多业务失败问题的“源头”。终端从空闲态转到连接态、发起切换、进行RRC重建、恢复上行同步，都要先做随机接入。随机接入失败，后续一切业务都无从谈起。所以这类问题通常表现得最直接：用户“没信号”“打不出电话”“无法上网”，或者某些业务断断续续。

在LTE/5G中，随机接入分为两类：

• 基于竞争的随机接入（CBRA）：终端发起呼叫、位置更新、RRC重建等场景使用，多个终端可能同时选择相同的前导序列，存在碰撞概率。
• 基于非竞争的随机接入（CFRA）：主要用于切换场景，基站提前为终端分配专用前导序列，不涉及竞争。

从优化角度看，基于竞争的随机接入是排查重点，因为它涉及前导序列碰撞、功率攀升、资源冲突等，出问题的概率远高于非竞争接入。

4.2 随机接入失败原因分类

我习惯把随机接入失败分成四类来看。

第一类：前导序列发射问题。终端在PRACH信道上发送前导序列（Preamble），如果基站收不到或解调不出终端的前导序列，MSG1就失败了。常见原因包括：终端发射功率不足（覆盖边缘场景）、上行干扰严重（PRACH频域位置正好被干扰）、PRACH配置不合理（前导序列格式与小区覆盖半径不匹配）。在5G里，PRACH格式的选择和子载波间隔配置会直接影响小区覆盖能力，配置过紧时远点终端基本无法接入。这里非常推荐系统性看一下LTE/5G的PRACH格式规范，业界常说的“LTE葵花宝典”里这部分也讲得很细，值得反复读。

第二类：随机接入响应（RAR）接收失败。终端发送MSG1后，基站会通过PDCCH/PDSCH下发MSG2（RAR）。如果终端没有收到MSG2，可能原因包括：PDCCH搜索空间配置问题、MSG1重传次数过多导致终端侧等待超时、基站侧处理时延过大等。

第三类：竞争冲突解决失败。多个终端同时选择了相同的前导序列并都收到了MSG2，就会发生竞争。终端发送MSG3后，基站通过MSG4进行冲突仲裁。如果MSG3上行质量差，或MSG4下发失败，终端会判定随机接入失败，重新发起接入尝试。这种情况在高并发场景（如演唱会、火车站、地铁站）特别常见。

第四类：系统侧配置和资源问题。包括小区接入控制参数配置错误、PRACH资源配置不足、RRC连接超时、核心网响应慢等。这类问题通常是小区级共性现象，拉取小区KPI基本能发现接入成功率大面积下降。

4.3 排查随机接入失败的具体步骤

排查随机接入失败，第一步仍然是做现象剥离：是整个小区失败率高，还是某个用户反复失败？是特定时间内失败，还是全天持续？是特定位点失败，还是随机分布？

如果是小区级失败率高，重点查四块：

• 小区是否处于高负荷或半锁状态。
• PRACH配置和格式，检查前导格式选择的覆盖半径是否匹配实际场景。
• 上行干扰情况，尤其是PRACH上行频带内是否存在干扰。
• 查看基站侧告警，确认RRU通道是否存在异常。

如果是单用户或特定位点失败，建议现场路测加信令跟踪。路测要重点看MSG1到MSG4四步信令在哪一步中断，这是最直接的判断依据：

• MSG1发不出去：终端上行动态功率控制问题、终端功率受限、或者上行失步。
• 收到MSG1但MSG2收不到：基站处理异常或下行覆盖问题。
• 发出MSG2但MSG3接收失败：上行资源和干扰问题、终端上行功率不够。
• MSG3发出了但MSG4没有确认：竞争冲突或下行信道质量问题。

还有一种非常隐蔽的场景：终端随机接入成功，但后续在RRC连接建立阶段失败，表现为随机接入成功率指标不高。这种情况要把信令记录完整拉出来看，确认是接入层失败还是非接入层失败，是核心网拒绝了还是无线侧超时了。曾经遇到过一个案例，随机接入一直正常，但E-RAB建立失败率极高，最后查出来是核心网侧用户面IP地址池配置错了。

另外提醒一下5G的特殊之处：5G的随机接入引入了波束和SSB关联，终端在随机接入时需要根据SSB索引选择对应的PRACH资源。如果SSB与PRACH资源的映射关系配置得不对，或者波束赋形增益不足，终端选择了一个覆盖较差的波束进行接入，就会出现“信号看着有、接不进去”的怪象。5G网络优化中排查这类问题，第一步就是确认SSB与PRACH的映射配置与现网覆盖需求一致。

5. 养成一套自己的排查工作流

5.1 排查前必做的准备工作

这么多年的经验告诉我，真正高水平的网优工程师，不是技术知识碾压别人，而是准备工作做得足、流程走得踏实。每次排查前，我建议养成一个固定动作：先把能拿到的数据全部拿齐，再出门。

具体清单大致是：

• 问题发生时间和持续时长
• 问题位置及经纬度（能精确到楼宇或楼层更好）
• 涉及用户数量和终端类型
• 该时段小区KPI与告警记录
• 之前是否有同类问题的处理记录

准备好这些再决定是否跑现场，能避免很多“到了现场不知道看啥”的尴尬。现场路测不是漫无目的地跑，而是带着假设去验证：假设是覆盖问题，就围绕报告点做扇形路测，确认RSRP/SINR分布；假设是干扰，就扫频找干扰源；假设是切换失败，就重点在切换带内复测。

5.2 容易踩的坑和细节提醒

这里挑几个我反复踩过、后来总结出来的坑，分享给你。

第一个坑：只信路测软件，不看基站告警和话统。路测只能反映测试路线的空口情况，无法反映小区整体状态。有时候路测数据正常，但小区接入成功率就是低，查到最后是基站单板异常，需要先看告警。所以一定要记住：路测是“点”的数据，告警和话统是“面”的数据，问题的最终定性必须“面”和“点”结合。

第二个坑：忽略了时间对齐。对比指标时，一定要确保对比的是同一时间点的数据。时区、采样周期不一致会导致误判。比如路测软件记录的是终端本地时间，而网管/KPI记录的是基站时间，两者如果没有对齐，就会出现“路测明明很好，但KPI显示很差”的错觉。

第三个坑：在5G问题里继续用4G思维。5G从架构、频率到调度机制都和4G差异巨大，比如波束管理、SSB配置、上下行时隙配置、网络切片、载波聚合，这些在4G里要么不存在，要么机制完全不同。遇到5G速率和接入问题时，先检查5G特有配置，不要一上来就套4G的排查模板。还有人问“5G基站向下兼容4G吗”，这个要看组网架构和终端能力，NSA模式下LTE作为锚点，网络侧确实承担了接入与控制功能，但这和无线侧的5G特有配置是两码事，排查时不能混为一谈。

第四个坑：忽略了用户环境。用户家的路由器干扰、室内信号屏蔽、手机壳遮挡天线，很多看起来“奇怪”的问题，其实都有非常朴素的原因。曾经处理过一个“连续几天某用户无服务”的工单，跑过去一看，用户把手机放在金属保温杯里充电，信号被完全屏蔽，哭笑不得。

5.3 团队协作里的经验传承

排查思路和方法这类东西，靠个人摸索成长太慢了。公司或团队如果能建一个“问题案例库”，把每次问题现象、排查过程、根因和解决方案记录下来，对新人的成长和团队的整体效率帮助非常大。

我在实际项目里常用一个简单的记录模板：

• 问题现象（用户原话+测试现象）
• 影响范围和时间
• 排查过程（按时间顺序记录关键动作和数据）
• 根因定位（无线/传输/核心网/终端哪个层面）
• 解决方案和效果验证
• 后续预防建议

这个方法你也可以直接用在自己的工作笔记里。坚持半年下来，再遇到类似问题基本不用从头查，直接翻记录对照就行。很多所谓“十年老网优经验”，说白了就是踩过足够多的坑，并且把坑都记录下来了。

最后说点我个人体会。网络优化这个工作，看着是和人打交道，实际上更多是在和数据打交道。数据骗不了人，但前提是你得用对方法去读它。速率低、MOS<3、随机接入失败，这三类问题的排查框架其实是相通的：先把现象问明白，再分层定位，最后用工具验证。每一次把疑难杂症查到底，都是对“端到端思维”的一次加深。

我自己还有一个习惯，每次解决完一个复杂问题，都会在工单记录里多写一段“回头总结”，哪怕只有三五句话。半年后再看，自己成长的轨迹全都在里面。这个方法虽然土，但真的很有效。希望这篇文章里的思路和方法，能帮你少走一些弯路，遇到问题的时候更从容。