企业官网建设流程全解析

简介：这份PDF面向5G网络优化工程师、核心网与无线维护人员，聚焦VoNR端到端高掉话这一典型疑难问题，提供从指标异常发现到根因定位、优化验证的完整排查思路。资源为1个PDF文件，压缩包约1.81MB，内容以案例文档形式呈现，便于随身查阅与团队内部分享。案例以AA市VoNR掉话率异常升高为切入点，逐层下钻厂家、区县与信令流程，剖析诺基亚MME处理TAU与X2切换冲突、MME与华为MSC位置更新时延过长、4G TDD语数分层功率引发二次切换等关键成因，并给出关闭语数分层后的指标评估数据。目前已有501人学习下载，适合需要掌握VoNR掉话分类、信令追踪与参数核查方法的读者，可据此建立可复用的端到端问题定位框架，提升实际网络优化效率。

1. VoNR 高掉话排查：一份端到端案例里的真实取舍

VoNR 商用后，很多优化工程师发现一个反直觉现象：语音质量差、掉话率高，问题往往不在无线侧。这份《5G网络优化案例：VoNR端到端高掉话问题排查案例.pdf》记录的就是一次典型的端到端排查过程——从核心网到无线接入网，再到终端侧，逐段定位 VoNR 高掉话的根因。它适合已经接触过 5G 基础优化、但对 VoNR 协议栈和端到端信令流程还不够熟悉的从业者。如果你正在处理 VoNR 掉话、IMS 注册失败或语音质量差的问题，这份案例能帮你建立一套可复用的排查路径，而不是只给一个结论。

2. VoNR 端到端链路拆解：从终端到核心网的信令路径

2.1 VoNR 与 VoLTE 的本质差异

VoNR 不是 VoLTE 的简单升级。VoLTE 的语音承载锚定在 LTE 的 EPC 上，而 VoNR 要求 NR 直接承载 IMS 语音，这意味着 NR 的覆盖、QoS 配置和互操作策略都会直接影响语音质量。常见做法是：先确认终端是否支持 VoNR 能力，再检查 NR 侧是否配置了 5QI=1 的专用承载。如果终端在 NR 上发起 IMS 注册但网络侧未配置 VoNR 开关，终端会回落到 EPS Fallback，这个过程本身就可能引入额外时延和掉话风险。

案例中一个关键细节是：终端在 NR 上发起 INVITE 后，网络侧没有及时建立 QCI=1 的承载，导致 SIP 信令超时。排查时需要在核心网侧抓取 N2 接口信令，确认 PDU 会话建立过程中是否携带了正确的 5QI 参数。很多优化工程师习惯只看空口信令，但 VoNR 的问题往往藏在核心网侧的策略配置里。

2.2 端到端信令抓取与关键节点

要复现案例中的排查过程，需要同时抓取三段信令：终端侧 QXDM 或 QCAT 日志、无线侧 Uu 接口信令、核心网侧 N2/N4 接口信令。常见做法是用 QXDM 抓取终端侧 NAS 和 RRC 信令，同时在 AMF 侧开启信令跟踪，对比同一时间窗口内的消息序列。

# 示例：在 AMF 侧开启针对特定 SUPI 的信令跟踪 # 进入 AMF 调试控制台后执行 amf-cli trace start --supi imsi-460001234567890 --output /tmp/amf_trace.pcap # 同时在 SMF 侧跟踪 PDU 会话建立过程 smf-cli trace start --supi imsi-460001234567890 --output /tmp/smf_trace.pcap

逻辑说明：这段命令用于在核心网侧针对特定用户开启信令跟踪，输出为 pcap 格式，便于后续用 Wireshark 分析。参数--supi指定用户永久标识，--output指定抓包文件路径。实际网络中，AMF 和 SMF 的调试命令可能不同，需要根据设备厂商文档调整。抓包后重点看 PDU Session Establishment Request 中是否包含 5QI=1 的 QoS Flow 描述，以及 PDU Session Establishment Accept 中网络侧是否接受了该请求。

如果终端侧日志显示 SIP INVITE 已发出，但核心网侧没有收到对应的 N2 消息，说明问题出在无线侧或终端侧的上行调度。这时需要检查 NR 侧的 SR（调度请求）配置和 BSR（缓冲区状态报告）上报是否正常。案例中一个容易被忽略的点是：终端在 NR 上发起 SIP 信令时，如果 SR 周期配置过长，会导致信令包排队等待上行授权，最终触发 SIP 超时。

2.3 关键参数与定时器配置

VoNR 对时延敏感，几个关键定时器直接决定掉话率。常见做法是：在 AMF 侧调整 T3512（周期性注册定时器）和 T3513（注册请求重传定时器），在 SMF 侧调整 T3591（PDU 会话建立定时器）。如果这些定时器设置过短，在网络拥塞时会导致信令重传失败，进而触发掉话。

案例中掉话的根因之一就是 T3591 设置为 10 秒，而核心网在忙时响应时间超过 12 秒，导致 PDU 会话建立超时，终端重新发起注册，语音业务中断。调整 T3591 到 20 秒后，掉话率明显下降。这个参数不是随便改的，需要结合核心网的实际处理能力评估。

3. 排查实操：从告警到根因的完整路径

3.1 第一步：确认掉话是无线侧还是核心网侧

拿到掉话问题，不要一上来就调无线参数。先看告警和 KPI：如果 NR 侧 RSRP 和 SINR 正常，但掉话率偏高，大概率是核心网侧或终端侧问题。常见做法是：提取掉话前 10 秒的终端侧日志，看是否有 SIP BYE 或 CANCEL 消息。如果终端主动发 BYE，说明是终端侧异常释放；如果网络侧发 BYE，需要看核心网侧是否触发了去注册。

# 示例：从 QXDM 日志中提取 SIP 消息时间线 import re from datetime import datetime def extract_sip_timeline(log_file): sip_events = [] with open(log_file, 'r', encoding='utf-8', errors='ignore') as f: for line in f: # 匹配 SIP 消息行，格式示例：2024-01-01 10:00:00.123 SIP INVITE match = re.search(r'(\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}\.\d{3}).*?(SIP \w+)', line) if match: timestamp = datetime.strptime(match.group(1), '%Y-%m-%d %H:%M:%S.%f') sip_events.append((timestamp, match.group(2))) return sorted(sip_events, key=lambda x: x[0]) # 输出 SIP 消息序列，观察是否有异常中断 for ts, msg in extract_sip_timeline('qxdm_log.txt'): print(f"{ts} - {msg}")

逻辑说明：这段脚本从 QXDM 日志中提取 SIP 消息时间线，帮助快速定位信令中断点。参数log_file是 QXDM 导出的文本日志路径。实际使用时，QXDM 日志格式可能不同，需要根据实际输出调整正则表达式。重点观察 INVITE 之后是否有 100 Trying、180 Ringing、200 OK 等响应，如果 INVITE 后没有 100 Trying，说明网络侧没有收到请求。

3.2 第二步：检查 IMS 注册状态与 QoS 配置

VoNR 掉话的另一个常见原因是 IMS 注册失败或 QoS 配置不匹配。案例中终端在 NR 上发起 IMS 注册，但 SMF 侧没有下发 5QI=1 的 QoS Flow，导致语音承载无法建立。排查时需要在 SMF 侧确认 PDU 会话的 QoS Flow 描述，看是否包含 5QI=1 和对应的 GBR（保证比特率）。

# 示例：在 SMF 侧查询特定 PDU 会话的 QoS Flow 信息 smf-cli session show --supi imsi-460001234567890 --pdu-session-id 5 # 输出示例： # QoS Flow ID: 1, 5QI: 1, GBR: 100 kbps, MBR: 200 kbps # QoS Flow ID: 2, 5QI: 9, GBR: 0, MBR: 0

逻辑说明：这段命令用于查询特定 PDU 会话的 QoS Flow 信息。参数--supi指定用户标识，--pdu-session-id指定 PDU 会话 ID。如果输出中没有 5QI=1 的 QoS Flow，说明网络侧没有为语音业务建立专用承载。这时需要检查 SMF 侧的 PCC 规则配置，确认是否针对 IMS APN 下发了正确的 5QI 参数。

3.3 第三步：无线侧参数核查与优化

如果核心网侧确认无误，问题可能出在无线侧。VoNR 对 NR 的覆盖和调度要求比数据业务更高。常见做法是：检查 NR 侧的 SR 周期配置，如果 SR 周期大于 20ms，语音信令包可能排队等待上行授权。案例中 SR 周期配置为 40ms，导致 SIP 信令包平均等待 30ms 以上，累积后触发 SIP 超时。

调整 SR 周期到 10ms 后，案例中的 SIP 信令时延从平均 45ms 降到 18ms，掉话率下降约 60%。这个调整需要权衡：SR 周期过短会增加 PUCCH 资源开销，在用户密集区域可能导致上行控制信道拥塞。

4. 避坑指南：VoNR 排查中的五个血泪教训

4.1 只看无线侧 KPI，忽略核心网信令

现象：NR 侧 RSRP、SINR、BLER 都正常，但掉话率居高不下。原因：VoNR 的语音承载建立依赖核心网侧 QoS 配置，如果 SMF 没有下发 5QI=1 的 QoS Flow，空口再好也无法建立语音承载。解决：排查时同步抓取 N2/N4 接口信令，确认 PDU 会话建立过程中是否携带正确的 5QI 参数。

4.2 定时器参数照搬 VoLTE 配置

现象：从 VoLTE 迁移到 VoNR 后，掉话率反而上升。原因：VoNR 的 PDU 会话建立流程比 VoLTE 的承载激活更复杂，T3591 等定时器如果沿用 VoLTE 的短值，容易在核心网响应慢时超时。解决：根据核心网实际处理能力调整 T3591 到 20 秒左右，并观察忙时表现。

4.3 忽略终端侧 IMS 注册状态

现象：终端在 NR 上发起呼叫失败，但网络侧无异常告警。原因：终端 IMS 注册可能已过期，但终端未及时重新注册，导致 INVITE 发出后无响应。解决：在终端侧日志中确认 IMS 注册状态，检查注册有效期和重新注册触发条件。

4.4 SR 周期配置过长导致信令排队

现象：SIP 信令包在终端侧已发出，但核心网侧延迟收到。原因：NR 上行调度采用 SR 机制，如果 SR 周期配置为 40ms，信令包需要等待上行授权，累积时延触发 SIP 超时。解决：将 SR 周期调整到 10-20ms，并观察 PUCCH 资源占用情况。

4.5 未区分 VoNR 与 EPS Fallback 场景

现象：终端在 NR 覆盖边缘发起语音呼叫，掉话率高。原因：终端可能触发了 EPS Fallback，回落到 LTE 过程中如果 LTE 覆盖不足，会导致掉话。解决：确认终端是否支持 VoNR，检查 NR 侧 VoNR 开关配置，避免不必要的回落。

5. 进阶技巧：用信令时间差定位隐藏的时延瓶颈

排查 VoNR 掉话时，一个很实用的技巧是计算关键信令节点之间的时间差。比如从 SIP INVITE 到 100 Trying 的时间差，正常应在 100ms 以内；如果超过 500ms，说明网络侧处理存在瓶颈。案例中通过计算发现，INVITE 到 100 Trying 的平均时间差为 320ms，进一步定位到 AMF 侧的鉴权流程耗时过长。

# 示例：计算 SIP INVITE 到 100 Trying 的时间差 def calc_invite_delay(sip_events): invite_time = None for ts, msg in sip_events: if 'INVITE' in msg: invite_time = ts elif '100 Trying' in msg and invite_time: delay = (ts - invite_time).total_seconds() * 1000 print(f"INVITE 到 100 Trying 时延: {delay:.0f} ms") invite_time = None # 调用示例 events = extract_sip_timeline('qxdm_log.txt') calc_invite_delay(events)

逻辑说明：这段脚本计算 SIP INVITE 到 100 Trying 的时间差，帮助定位网络侧处理时延。参数sip_events是前面提取的 SIP 消息时间线。如果时延超过 500ms，需要检查 AMF 侧的鉴权流程和 SMF 侧的会话建立流程。案例中通过这个分析发现，AMF 侧的 AUSF 鉴权平均耗时 280ms，优化鉴权流程后时延降到 80ms。

另一个进阶技巧是：在核心网侧开启 QoS Flow 级别的统计，观察 5QI=1 的 GBR 是否被满足。如果 GBR 未满足，说明无线侧资源不足或调度优先级配置不当。常见做法是调整 NR 侧的调度权重，将 5QI=1 的调度优先级提到最高。

从那以后我每次排查 VoNR 掉话，都强制走一遍「终端侧 SIP 时间线 → 核心网侧 QoS Flow 核查 → 无线侧 SR 周期确认」这三步，不再一上来就调无线参数。希望帮到你。

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