VoNR语音质量优化实战：从信令分析到eSRVCC切换排查

简介面向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, encodingutf-8).read() codec_pattern re.compile(rartpmap:(\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(fPT{pt}, Codec{codec}, SampleRate{rate}Hz)这段脚本把SDP里所有rtpmap字段枚举出来目的是确认双方协商出来的是AMR-WB而不是AMR-NB。逻辑说明SDP协商是文本协议用正则把载荷类型号、编码名和采样率抽出来即可实际生产环境看到的抓包里同一编码可能同时出现两个载荷类型号动态PT和静态PT都要打印出来核对。参数说明正式做判断前还要看afmtp里的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业务的QCI15QI1本身就有GBR承载保证比特率但在多业务并发时基站调度器还要决定是先让语音包走还是先让大流量数据包走。常见做法是把5QI1的逻辑信道优先级设得比普通数据业务高两档到三档并给上行语音配置更短的调度周期。这里面有一个实际的坑调度周期改短固然能压时延但控制信令开销会变大小区用户多时反而造成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业务丢包率高。原因QCI15QI1的承载在核心网侧被错误映射到了非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路测重点覆盖小区边缘和切换带。下面是每次测试前必跑的环境检查清单检查项目预期范围失败表现SSB RSRP近点大于-85dBm接入失败、呼叫建立慢SINR大于15dB初传误码高、MCS低上行BLER低于3%语音断续、MOS下降RTP抖动低于30ms听感明显卡顿表格里的阈值是大致参考具体项目要根据现场无线环境微调。我每次都会在测试记录表里保留原始截图和信令文件方便参数回退时作为证据链使用。6.2 参数回退与基线比对方法参数验证不是跑完路测就结束了一定要做回退对比。我的习惯是拿参数修改前一天的指标做基线修改后复测同一批点位如果MOS提升不足0.3而配置风险较大就要考虑回退。回退时又容易踩一个坑设备网管上的参数是分版本管理的直接改回旧值可能带上新版本的默认配置所以回退后要再抓一次信令确认参数实际生效状态。我之前在模拟项目X调整调度优先级时第一次修改后MOS只涨了0.1但调度开销涨了8个百分点果断回退后重新调整策略——把目标从「全小区语音优先」改成「拥塞时语音优先」指标才达到预期。从那以后我每次调VoNR参数都强制走一遍「参数快照—抓包基线—定点验证—回退对比—信令复核」的完整流程。这个习惯看起来慢但能省下夜里翻日志的冤枉时间。VoNR优化没有一招鲜的配方每个参数背后都是功耗、时延、容量和质量四方的权衡。希望这篇案例拆解能帮你少走几趟弯路遇到问题时手里多几把趁手的排查工具落地到自己的网络里少一点玄学、多一点确定性。本文还有配套的精品资源点击获取