企业官网建设流程全解析

简介：面向5G网络优化工程师与VoNR语音质量攻坚团队，以扬中市政府办公楼电梯区域用户通话卡断为真实案例，完整呈现从用户投诉受理、SEQ话单与PS信令分析、KPI/MRO指标核查，到逐楼层现场测试验证、定位弱覆盖区域的排障闭环。资源为单个docx文档，全文约11.76MB，内容包含问题描述、原因分析、1至11层及东西电梯和连廊等场景的4G/5G信号强度、SINR与速率对比实测数据，以及覆盖薄弱点识别与优化建议，可直接作为同类VoNR语音质量问题的分析模板。通过学习本案例，可掌握借助SEQ信令、KPI指标与现场测试相结合的多维度排查方法，理解宏站与室分覆盖切换对语音连续性的影响，为5G室内分布优化和VoNR专项保障提供参考。已有155人学习浏览，适合5G网络优化、无线网维护及VoNR专项工程师参考借鉴。

1. VONR通话异常优化：从信令、参数到eSRVCC的一整套排查路径

做5G网络优化的同行都知道，VoNR业务一开通，最先扑上来的问题永远是那几个老面孔——呼叫建立慢、语音断续、掉话、切到4G之后直接丢话。表面上看是无线侧弱覆盖，实际排查下来，一半以上的根因都藏在参数配置和信令交互流程里，根本不是加站能解决的。这份VONR通话异常优化案例，是我反复翻过的实战记录，覆盖从SIP信令到空口调度、从编解码协商到eSRVCC切换失败定位的完整排查思路，适合一线优化工程师、运维值班人员和刚转5G语音的测试工程师。里面有不少可以直接抄到日常优化里的参数核查套路，也有几处不跑一次仿真就发现不了的逻辑坑。

2. VoNR信令流程拆解与异常定位：先分清问题出在哪一段

2.1 呼叫建立的四个关键节点

VoNR呼叫从用户按下拨号键到听到回铃音，经历的不只是无线承载建立。我在定位异常时会先把流程切成四个节点：RRC建立、NAS层信令、SIP会话协商、用户面RTP建立。大多数问题只要确认卡在哪两个节点之间，方向就不会跑偏。RRC建立失败多半是覆盖或随机接入参数问题；NAS层慢通常是核心网交互或DRX寻呼参数；SIP协商慢最常见的根因是编解码与QoS Flow配置冲突；而RTP一旦建立后出现断续，就轮到空口调度和抖动缓冲策略上场。

这份案例集里对节点的划分特别细，把每个节点对应的时延预期也给出来了。我一般会把RRC建立到SIP 200 OK回传这段总时延控制在180ms以内，如果明显超了，就从SIP消息的时间戳反推每一段消耗。某一次在模拟项目X里遇到呼叫建立平均达到380ms的情况，信令平台打开一看，SIP会话花在资源预留上的时间就占掉了190ms，根本不是无线覆盖的事。

2.2 用抓包工具快速定位信令节点

不管是现场用便携信令仪还是核心网侧镜像抓包，第一步都是先把SIP消息的完整时序拉出来。以常见的抓包文件为例，在命令行下可以直接用tshark过滤出与VoNR呼叫相关的所有SIP消息：

tshark -r vonr_call.pcapng -Y "sip" -T fields \ -e frame.time_relative \ -e sip.Method \ -e sip.Status-Code \ -e sip.CSeq \ -e sip.Call-ID

这段命令把SIP消息按照相对时间逐条列出，每个消息带上方法名和状态码。逻辑上是对呼叫信令做链路级还原——从INVITE发出到100 Trying、180 Ringing、200 OK，再到ACK确认，每一步的时间差都能直接算出来。参数说明：-r指定输入文件，-Y是显示过滤器，这里只保留SIP协议；-T fields带着-e选项时是自定义输出列，对后续脚本处理比较友好。只看SIP还不够，想同时看到NAS层与SIP的对应关系，可以把过滤器加宽：

tshark -r vonr_call.pcapng -Y "sip || nas-eps || nr-nas" \ -T fields -e frame.time -e _ws.col.Protocol -e _ws.col.Info

逻辑上这是把空口NAS层消息和SIP消息放在同一条时间轴上看，方便确认「NAS层已经触发了QoS Flow建立，但SIP为什么迟迟没有收到资源预留成功回执」。参数说明：nas-eps和nr-nas是TSHARK里5G NAS的协议名，老的设备抓包软件可能把5G NAS归到nas-5gs，不同版本字段名会有差异，抓包前先用tshark -G protocols确认一下设备侧的协议注册名。

2.3 用户面质量：RTP抖动、丢包与编解码统计

信令正常不代表语音质量过关，用户面RTP包才能反映真实体验。常用的抓包软件基本都自带VoIP统计面板，但在自动化处理场景里我还是习惯用命令行把RTP流统计算出来。下面这段命令可以输出每个媒体流的基本指标：

tshark -r vonr_rtp.pcapng -Y "rtp" -qz rtp,streams

执行后按RTP流维度输出起始时间、包数、丢包率、抖动、平均MOS估值。逻辑说明：这里调用的是tshark内建的RTP流分析模块，它通过SSRC区分媒体流，再按RTP序号和时间戳计算丢包与抖动，MOS值是依据ITU-T P.563算法粗略估算出来的。参数说明：-q是安静输出模式，避免同时打印每个包的解析内容；-z后面跟着分析模块名，rtp,streams里的逗号不能少，换成rtp,all也可以列出每个单独包的信息，但那种输出量太大，日常定位不建议直接用。

2.4 从Metrics反推空口调度案例

信令和RTP都看过之后，如果业务面仍然异常，就要回到网络侧指标反推空口调度行为了。案例集里有一个典型处理路径：某园区场景用户反映语音断续，路测软件看到的RTP丢包率在3%上下，但BLER始终低于1%，干扰又不大。这时打开基站侧VoNR语音调度统计发现，上行语音包的平均调度周期被拉长到了60ms以上，问题锁定在上行调度请求资源配比不足，而不是覆盖或干扰。顺着这个方向查，最终是上行SR周期配置过稀疏，语音包在终端侧排队等待发送机会。

这个案例提醒我，优化语音质量不能只看Uu口的BLER，还要把上行SR周期、CQI上报周期和调度优先级几项联合起来看。很多工程师习惯说「BLER低就代表空口质量好」，在数据业务上大致成立，但VoNR是周期性强、时延敏感的业务，哪怕BLER低，只要调度不及时，抖动和丢包一样会出现。

3. 参数优化实操：把呼叫时延和语音质量调到可接受范围

3.1 AMR-WB与AMR-NB的协商策略

编解码协商直接决定VoNR话音质量上限。AMR-WB（宽带自适应多速率）的采样率是16kHz，比AMR-NB的8kHz翻了一倍，主观听感差距非常大。对支持VoNR的终端，核心网侧一般都会优先配置AMR-WB，但这里有门道：终端和网络在SIP的SDP协商里会带出一串Codec优先级列表，如果网络侧维护的Codec优先级顺序写反了，哪怕两端都支持AMR-WB，最终也会落到AMR-NB。

常见做法是在核心网侧检查SDP协商结果，重点看两个字段：rtpmap里声明的编码名称和fmtp里的mode-set参数。下面是用python简单解析抓包文件中SDP协商结果的思路：

import re sdp_text = open("sdp_section.txt", encoding="utf-8").read() codec_pattern = re.compile(r"a=rtpmap:(\d+)\s+(AMR|AMR-WB)/(\d+)/1") for m in codec_pattern.finditer(sdp_text): pt, codec, rate = m.group(1), m.group(2), m.group(3) print(f"PT={pt}, Codec={codec}, SampleRate={rate}Hz")

这段脚本把SDP里所有rtpmap字段枚举出来，目的是确认双方协商出来的是AMR-WB而不是AMR-NB。逻辑说明：SDP协商是文本协议，用正则把载荷类型号、编码名和采样率抽出来即可；实际生产环境看到的抓包里，同一编码可能同时出现两个载荷类型号（动态PT和静态PT），都要打印出来核对。参数说明：正式做判断前还要看a=fmtp里的mode-set、max-red这些限制参数，只靠rtpmap一列判断编解码带宽是不够的。

3.2 抖动缓冲（Jitter Buffer）管理的参数取舍

RTP抖动是语音断续的直接诱因，但一味把抖动缓冲加大也不是好主意。抖动缓冲的本质是牺牲时延换平滑：缓冲越大，网络抖动被吸收的能力越强，但端到端时延随之上升，超过150ms就有明显说话延迟感。实际优化中我看到多数商用设备默认使用自适应抖动缓冲，最小10ms、最大80ms这类区间配置。

参数调整上，如果现场统计显示RTP抖动峰值在30ms附近，但均值只有5ms，缓冲区设置成固定20ms就不合适，应当切换为自适应模式，让算法跟随网络波动动态伸缩。反之在传输链路经过多跳卫星或微波时，抖动呈周期性大波动，自适应算法会频繁调整，这时反而应该把固定缓冲适当抬高一点。通过这个案例集我能给出的直接建议是：优先启用自适应，但延时敏感的特殊承载要关掉自适应并重新设置固定深度。参数改了之后要复测RTP丢包率和端到端单通时延两个指标，两侧一起看才不会被单一指标改善迷惑。

3.3 上行功率控制与调度优先级

VoNR上行语音包是最容易翻车的环节。终端发射功率受限场景下，上行语音块错误率会突然抬升，直接体现为用户说话时对方听到断续。功率控制参数里，P0（目标接收功率）和α（路损补偿因子）是两大基础旋钮。语音业务建议P0取相对较高的值——数据业务里为了降低干扰会把P0压低，但VoNR对误块率更敏感，压太低会导致上行语音BLER常年下不来。α在密集城区要谨慎调整，开环补偿调得太激进，远点用户对邻区的干扰也会明显抬升。

调度优先级调整是另一个有效手段。VoNR业务的QCI=1（5QI=1），本身就有GBR承载保证比特率，但在多业务并发时，基站调度器还要决定是先让语音包走还是先让大流量数据包走。常见做法是把5QI=1的逻辑信道优先级设得比普通数据业务高两档到三档，并给上行语音配置更短的调度周期。这里面有一个实际的坑：调度周期改短固然能压时延，但控制信令开销会变大，小区用户多时反而造成PRACH或PDCCH资源拥塞，规模站点上线前务必做容量评估。

3.4 DRX周期与VoNR时延的平衡

DRX本来是省电机制，但配置不当会直接拖累呼叫时延。尤其VoNR这种持续小包业务，如果DRX周期设得太长，终端在空闲监听窗口之外到达的下行语音包就得等到下一个On Duration才能接收，表现为听筒里声音延迟加大甚至首个语音帧听不清。

从案例集里的实测数据看，VoNR语音承载使用短DRX周期（40ms以内）对时延改善收益最明显，而长DRX更适合纯数据业务。参数调整上，把ondurationtimer和drx-InactivityTimer往短调，能更快进入监听，代价是终端功耗上升。对固定电源供电的终端可以放心缩短，对手持终端要留出功耗余量。我在模拟项目X的试商用阶段把某热点区域的VoNR DRX周期从80ms压到40ms后，呼叫建立时延平均下降了约60ms，同时MOS统计也有小幅回升，但终端续航确实掉了将近10%，这个取舍要在参数表里提前说明白。

4. eSRVCC切换失败专项：从测量报告到切换命令的完整排查

4.1 eSRVCC流程中三个定时器和两次判决

VoNR用户从NR覆盖区进入LTE覆盖区时，如果NR信号持续恶化，网络会触发eSRVCC把语音会话平滑切到4G的VoLTE。这个流程看着简单，实际链路长得很：先要做NR测量评估，判定需要切换后发起SRVCC切换请求，核心网侧完成会话迁移，最后终端在LTE侧建立新的无线承载。整个过程涉及三个定时器：测量评估触发时间（TTT）、切换准备定时器、核心网会话迁移定时器，任何一个超时都可能导致切换失败或语音中断。

排eSRVCC问题我一般遵守两步走：先确认无线侧有没有正确下发测量控制，再确认核心网侧有没有完成会话迁移。很多工程师一看到eSRVCC失败就扑向邻区配置，实际上有不少案例是NR侧测量配置里漏掉了LTE频点，终端根本不知道该往哪测，自然永远切不过去。

4.2 典型失败场景分析：迟滞与触发时间的临界点

案例集里最典型的一个场景是：某跨层覆盖区域，用户从NR宏站往室内走，VoNR通话质量逐渐下降，触发A2事件后迟迟收不到eSRVCC命令，直到信号完全丢失后掉话。从测量报告看，RSRP已经低于-115dBm但仍未执行切换，问题出在A2门限和切换准备定时器配置的逻辑冲突上。

# 模拟核查命令：查看本地方案中eSRVCC相关参数当前配置 rsrp_trigger = -115 # 触发A2的RSRP门限，单位dBm ttt_ms = 256 # 测量报告的触发时间窗口 srvcc_prep_timeout = 2000 # 核心网迁移超时，单位ms if rsrp_trigger > -110: print("[警告] A2门限高于-110dBm，可能导致过早触发eSRVCC") if ttt_ms > 512: print("[警告] TTT偏大，严重衰落场景下误判风险上升") if srvcc_prep_timeout < 1000: print("[警告] 核心网迁移超时设置过短，切换流程容易被提前中止")

这段示例脚本的逻辑是：把三个关键参数拉出来和推荐范围比对，出现越界就提示风险。参数说明：不同设备商的参数名称不同，但对应的无线侧逻辑是一致的——A2门限代表切换触发条件；TTT代表持续多少个时间窗保持该条件才真正上报；核心网迁移定时器是在切换信令交互阶段给会话迁移留的最大等待时长。实际案例里这三个参数经常被分开调优，看起来各自都在合理区间，组合起来却互相打架。建议做eSRVCC专项时把这三个参数放进同一张参数表批量核查，不要分开看。

4.3 邻区关系核查与测量频点配置检查

eSRVCC第二次判决发生在LTE侧，也就是目标小区能否成功接纳这个语音会话。这一步失败往往和邻区关系不完整密切相关。很多时候NR侧RAN侧配置的eSRVCC目标频点里包含了LTE Band 3和Band 5，但邻区关系表里只加了Band 3的PCI，终端测量到Band 5信号更强也无法成功切换。排查测量配置时，第一步要确认终端上报的测量报告中包含哪些频点，第二步对照邻区配置看这些频点是否都有对应的外部小区和TAC纠偏。

从我处理过的案例看，邻区漏配是最隐蔽的坑。基站侧核查不出任何告警，参数也都齐，但就是切换失败，最后翻测量报告的原始日志才发现终端早就上报了目标小区PCI，只是这个PCI没有配置在邻区关系表里，网络侧不认识它，白白浪费了切换机会。这个现象在模拟项目X的边界区域特别多发，因为两个区域的邻区数据归不同人维护，漏配之后经常要拖到掉话投诉才暴露。

5. VoNR优化避坑记录：五组容易误判的现象与解决路径

5.1 上报MOS值低，但空口BLER不高

现象：路测软件统计的MOS值长期在3.0以下，但空口BLER始终低于1%，RSRP和SINR也都在良好区间。

原因：先排查编解码协商和RTP传输层，再回头怀疑空口。常见根因是AMR-WB协商失败回落到AMR-NB，或者RTP包在IP传输网排队抖动过大，空口本身没啥问题。

解决：查SIP SDP确认协商编码，查承载侧QoS Flow的丢包率和时延统计。之前处理过的一个案例是传输网交换机缓存不足导致RTP突发丢弃，空口无论怎么优化MOS都纹丝不动，换了大缓存交换机之后指标直接改善。

5.2 RTP丢包集中在语音包，数据业务正常

现象：同一个小区的数据业务时延和速率都正常，唯独VoNR业务丢包率高。

原因：QCI=1（5QI=1）的承载在核心网侧被错误映射到了非GBR的QoS Flow，或者RAN侧为该承载配置的调度优先级与数据业务拉不开差距。

解决：做端到端QoS参数溯源，从核心网PCRF/PCF策略到RAN侧QCI映射逐段核对。端到端QoS映射问题在现网中的出现率比想象中高得多，很多是核心网配置数据模板复制粘贴时改漏了参数。

5.3 eSRVCC切换命令迟迟不下发

现象：终端已经上报A2测量报告，且满足条件持续了数秒，但网络侧始终不下发切换命令，直到信号失锁掉话。

原因：没有配置B2事件——很多场景下只配了A2事件用于跳过直接切换到LTE，却漏掉了B2事件测量配置。A2事件只报告NR信号差，不触发真正的切换动作；缺少B2，网络侧不知道LTE目标小区是否满足条件，无法决策。

解决：核查事件配置列表。A2门限与B2门限要同时核查，B2的两个门限分别对应NR侧和LTE侧，LTE侧门限如果写得太苛刻，即使LTE信号满格也切不过去。

5.4 呼叫建立时延大但信令流程正常

现象：从拨号到振铃经历了4秒以上，但抓包看SIP消息都是正常顺序，没有中间失败重传。

原因：问题大概率在低层。RRC建立后到NAS层INITIAL CONTEXT SETUP之间出现长间隔，往往是寻呼时机或SIP消息触发的DRX周期太长，也可能是UE能力查询流程多耗了时间。

解决：抓包时把NAS层消息和RRC层消息放到同一时间轴对比，确认长时延出现在空口还是S1/N2接口。如果出现在空口，优先缩短DRX周期和UE能力查询相关定时器；如果出现在核心网分段，需要核心网侧定位具体网元的处理时延。

5.5 参数已下发但指标不变

现象：按优化建议修改了上行调度周期和功率控制参数，但第二天话统指标纹丝不动。

原因：参数没有在对应运营商维度的某个功能开关下生效。部分参数是功能级全局开关与细粒度子开关配合生效的两级结构，只改子开关而全局开关未打开，参数就会静默失效。

解决：参数修改后做信令级验证，用路测或用户面跟踪确认新参数是否真正附着到承载上。验证完再做指标对比，不要直接依赖话统报表。我养成了每次参数修改都做一次信令追踪的习惯，比话统反馈更即时、判断逻辑更明确。

6. 验证闭环：从单站标定到片区比对的VoNR优化习惯

6.1 外场验证的环境与动作分解

参数调整不能只看网管指标，外场验证是最后一道防线。我执行验证时有固定套路：选定目标区域后先做单站CQT（定点拨打测试），每个点位打三遍，覆盖近点、中点、远点，记录呼叫时延、单通、断续、掉话四类问题；单站通过后再做DT（路测），重点覆盖小区边缘和切换带。下面是每次测试前必跑的环境检查清单：

表格里的阈值是大致参考，具体项目要根据现场无线环境微调。我每次都会在测试记录表里保留原始截图和信令文件，方便参数回退时作为证据链使用。

6.2 参数回退与基线比对方法

参数验证不是跑完路测就结束了，一定要做回退对比。我的习惯是：拿参数修改前一天的指标做基线，修改后复测同一批点位，如果MOS提升不足0.3而配置风险较大，就要考虑回退。回退时又容易踩一个坑：设备网管上的参数是分版本管理的，直接改回旧值可能带上新版本的默认配置，所以回退后要再抓一次信令确认参数实际生效状态。

我之前在模拟项目X调整调度优先级时，第一次修改后MOS只涨了0.1，但调度开销涨了8个百分点，果断回退后重新调整策略——把目标从「全小区语音优先」改成「拥塞时语音优先」，指标才达到预期。从那以后我每次调VoNR参数都强制走一遍「参数快照—抓包基线—定点验证—回退对比—信令复核」的完整流程。这个习惯看起来慢，但能省下夜里翻日志的冤枉时间。

VoNR优化没有一招鲜的配方，每个参数背后都是功耗、时延、容量和质量四方的权衡。希望这篇案例拆解能帮你少走几趟弯路，遇到问题时手里多几把趁手的排查工具，落地到自己的网络里少一点玄学、多一点确定性。

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