简介：本资源是一份面向5G网络优化工程师与通信专业学习者的VoNR（Voice over New Radio）信令流程深度解析文档，聚焦5G语音业务核心机制与外场部署实践痛点。文档系统梳理VoNR端到端信令流程，涵盖RRC连接建立、SIP信令承载（5QI=5）、IMS会话协商、RTP/RTCP媒体流承载（5QI=1）、紧急呼叫分级处理（普通用户/受限用户）、EVS多模式编解码适配及MAC CE动态调速等关键技术细节，并结合电信协优考试题库、HW网管配置逻辑、iPhone驻留异常分析等真实案例强化工程落地理解。资源为单个1.37MB的Word文档（.docx），内容结构完整，图文并茂，含流程图、编码速率对照表与业务状态模型，便于快速查阅与技术复盘。目前已有2416人学习下载，适合5G网优人员备考协优认证、开展VoNR现网优化或深入理解5G语音架构与互操作机制。
1. VoNR信令流程不是PPT动画，而是5G语音业务落地的“心跳图谱”：它决定通话接通率、掉话位置、IMS互通成败，一线优化工程师每天要对着它查链路断点、定位SIP失败码、比对UE与核心网时间戳差异
VoNR（Voice over New Radio）信令流程文档，表面看是份.docx文件，实则是5G SA组网下语音业务能否真正商用的“临床诊断书”。它不讲原理推导，不堆协议编号，只呈现真实网络中UE发起呼叫、AMF触发IMS注册、PCF策略下发、SMF建立QoS流、SIP会话协商、媒体面锚点切换等关键环节的完整交互时序——每一条箭头背后，都对应着一个可能被丢弃的NAS消息、一个超时未响应的Diameter请求、或一个因QoS参数不匹配导致的Bearer Setup Failure。这份文档的价值，不在格式美观，而在能否让传输工程师快速识别“注册卡在3GPP TS 23.228第5.2.2节定义的P-CSCF发现阶段”，让核心网工程师一眼看出“INVITE 403 Forbidden是否源于PCF未下发正确的STN-SR值”，让无线侧同事确认“B1事件上报后gNB是否在500ms内完成SN添加”。它不是教学材料，而是故障树分析（FTA）的起点；不是验收交付物，而是现网KPI劣化时第一份必须打开的“黑匣子日志索引”。如果你正负责5G语音端到端优化、IMS对接联调、或VoNR商用割接保障，这份文档就是你排查“主叫接通率低于98%”“被叫延迟超3秒”“弱场切换掉话”问题时，最该先盯住的那张图。
2. 从原始协议栈到可执行流程图：用Wireshark+3GPP TS 23.228/24.501提取VoNR信令骨架
VoNR信令流程文档的源头，从来不是人工手绘。它必须基于真实信令跟踪（Trace）或标准协议文本逐条还原。我一般会跳过直接编辑Word的低效方式，先构建可验证、可复现的信令骨架——这一步决定了后续所有分析的可信度。
2.1 抓取真实VoNR呼叫全流程PCAP，过滤出关键协议栈层级
实际项目中，我优先使用现网gNB侧的SCTP/IP层抓包（需开通gNB信令镜像功能），而非UE侧模拟器数据。原因很实在：UE侧抓包无法反映gNB内部处理延迟、AMF重定向决策、以及UPF媒体面路径选择等关键环节。以下命令是在支持SCTP镜像的gNB上执行的最小化抓包指令（以华为设备为例）：
# 启动SCTP信令面抓包，仅捕获与IMS域交互的SCTP流（端口5060/5061） start capture sctp port 5060-5061 duration 300 filter "sctp && (ip.src == 10.10.10.1 || ip.dst == 10.10.10.1)" file /data/capture/vonr_call_20240615.pcap提示：
10.10.10.1是IMS核心网P-CSCF的IP地址，需根据实际网络配置替换。务必开启duration限制，避免抓包文件过大导致Wireshark解析崩溃——VoNR一次完整呼叫（含注册、呼叫、挂机）通常产生200~500个SIP/SDP/Diameter包，但若包含大量重传或异常重协商，PCAP可能超200MB，此时Wireshark会卡死在解析SIP头字段阶段。
抓包完成后，在Wireshark中应用显示过滤器精准定位VoNR主流程：
# 过滤出一次完整VoNR呼叫的全部相关包（含注册、呼叫、媒体协商、释放） (sip.Method == "REGISTER" || sip.Method == "INVITE" || sip.Method == "BYE") && (diameter.cmd.code == 280 || diameter.cmd.code == 272) && (icmp.type == 8 || icmp.type == 0) # 补充ICMP用于定位网络连通性问题点2.2 依据3GPP TS 23.228和TS 24.501，标注每条消息的协议层归属与触发条件
光有PCAP不够，必须映射到标准协议条款。VoNR信令不是孤立消息堆砌，而是严格遵循3GPP定义的状态机迁移。我习惯用Excel表格固化这个映射关系，作为Word文档的底层数据源：
| 消息方向 | 协议层 | 消息类型 | 触发条件 | 关键字段示例 | 对应3GPP条款 |
|---|---|---|---|---|---|
| UE → AMF | NAS | Registration Request | UE开机或TAU后首次注册 | 5GS Registration Type = 1 (initial) | TS 24.501 §8.2.1 |
| AMF → PCF | N7 | Policy Association Request | AMF收到注册请求后 | Supi, Snssai, Dnn | TS 23.502 §6.2.2 |
| PCF → SMF | N7 | QoS Flow Setup Request | PCF决策QoS参数后 | QosFlowIdentifier, QosParameters | TS 23.502 §6.2.3 |
| UE ↔ P-CSCF | SIP | REGISTER | UE完成5GS注册后 | Contact: sip:ue@ims.mnc001.mcc001.3gppnetwork.org | TS 23.228 §5.2.2 |
| P-CSCF → I-CSCF | SIP | REGISTER (forwarded) | P-CSCF路由至I-CSCF | Via, Route, Max-Forwards | TS 23.228 §5.2.3 |
注意：表格中
Supi（Subscription Permanent Identifier）和Snssai（Single Network Slice Selection Assistance Information）必须与现网UDM中配置完全一致，否则PCF无法关联用户签约策略——这是VoNR注册失败最常见的根因之一，却常被误判为IMS侧问题。
2.3 用PlantUML生成可版本管理的信令序列图（SDL），替代手工绘制Word流程图
.docx文件最大的缺陷是无法diff、无法版本回溯、无法自动化校验。我坚持用PlantUML生成SVG/PNG序列图，并将.puml源文件纳入Git仓库。以下是最小可行VoNR注册流程PlantUML代码：
@startuml title VoNR Initial Registration Sequence actor UE participant "AMF" as amf participant "PCF" as pcf participant "SMF" as smf participant "P-CSCF" as pcscf participant "I-CSCF" as icscf UE -> amf: NAS: Registration Request\n(5GS Registration Type=1) amf -> pcf: N7: Policy Association Request\n(Supi=imsi-001011234567890,\nSnssai={sst=1,sd=010203}) pcf -> smf: N7: QoS Flow Setup Request\n(Qfi=5,QosParameters={5QI=5,ARP=1}) smf --> amf: N11: PDU Session Establishment Accept\n(QosRules, QosFlowDescription) amf --> UE: NAS: Registration Accept\n(5GS Registration Result=1) UE -> pcscf: SIP: REGISTER\n(Contact: <sip:ue@ims.mnc001.mcc001.3gppnetwork.org>) pcscf -> icscf: SIP: REGISTER (forwarded)\n(Via: P-CSCF, Route: <sip:icscf.ims.mnc001.mcc001.3gppnetwork.org>) icscf --> pcscf: SIP: 302 Moved Temporarily\n(Contact: <sip:scscf.ims.mnc001.mcc001.3gppnetwork.org>) @enduml生成命令（需安装plantuml.jar）：
java -jar plantuml.jar -tsvg vonr_registration.puml逻辑说明：此图强制体现三个关键约束：① NAS注册必须先于SIP注册（否则P-CSCF无法获取UE的5GS位置信息）；② PCF必须在AMF向UE返回Registration Accept前完成QoS策略下发（否则SMF无法建立QoS Flow）；③ I-CSCF返回302而非200，表明VoNR必须经过SCSCF路由——这是与VoLTE最本质的区别，也是IMS互通失败的高发点。
3. VoNR信令流程文档的四大必填字段：为什么“消息时长”比“消息类型”更能暴露网络瓶颈
一份合格的VoNR信令流程文档，绝不能只罗列消息名称和箭头方向。我在交付给运营商客户的每份.docx中，强制要求包含以下四个字段——它们直接关联现网KPI劣化定位效率：
3.1 字段一：各消息间的RTT（Round-Trip Time）实测区间（单位：ms）
VoNR对时延极度敏感。SIP INVITE到100 Trying的RTT超过100ms，就可能触发UE侧重传；AMF到PCF的N7接口RTT超过300ms，会导致QoS策略下发超时，进而引发Bearer Setup Failure。因此，我在文档中为每个关键接口标注实测RTT范围：
| 接口 | 消息对 | 典型RTT（ms） | 门限值（ms） | 超限时现象 |
|---|---|---|---|---|
| N1/N2 | UE ↔ gNB (Registration Request/Accept) | 15~45 | >80 | UE注册超时，重试次数>3 |
| N12 | AMF ↔ SMF (PDU Session Request/Response) | 25~60 | >120 | PDU Session建立失败，错误码Cause=27 |
| N7 | AMF ↔ PCF (Policy Association Request/Response) | 30~90 | >200 | QoS Flow未建立，媒体面无QoS保障 |
| SIP | UE ↔ P-CSCF (REGISTER/200 OK) | 20~70 | >150 | IMS注册失败，SIP 408 Request Timeout |
参数说明：RTT非单次测量值，而是连续100次VoNR呼叫的P95值。采集方法为Wireshark中选中一对Request/Response包，右键→"Follow"→"SIP Stream"→查看"Time since request"列。门限值来自3GPP TS 23.502 Annex A的推荐值，但必须结合现网设备型号微调——例如某厂商AMF在高负载下N7 RTT P95达180ms仍属正常，而另一家则要求≤120ms。
3.2 字段二：关键消息携带的QoS参数快照（5QI、ARP、GBR/MBR）
VoNR语音流必须绑定5QI=5（Enhanced Mobile Broadband）或5QI=1（Conversational Voice），且ARP（Allocation and Retention Priority）必须≥1。文档中需截图SMF下发的QosFlowSetupRequest消息中的QoS参数：
QosFlowSetupRequest { QosFlowIdentifier: 5 QosParameters: { 5QI: 5 ARP: {PriorityLevel=1, PreemptionCapability=NOT_PREEMPTABLE, PreemptionVulnerability=PREEMPTABLE} GBR: {UL=128000, DL=128000} // VoNR语音流典型GBR值 MBR: {UL=256000, DL=256000} } }逻辑说明：若此处5QI=8（Default EMBB），则VoNR降级为VoLTE；若ARP.PriorityLevel=3，则语音流在拥塞时被优先抢占——这正是弱覆盖区掉话的根源。必须与PCF策略服务器中配置的QoS模板完全一致，否则SMF会拒绝建立QoS Flow。
3.3 字段三：SIP消息中SDP Offer/Answer的Codec协商结果
VoNR强制要求使用EVS（Enhanced Voice Services）编解码器，且必须支持EVS-WB（Wideband）或EVS-SWB（Super Wideband）。文档中需截取INVITE和200 OK中的SDP内容：
v=0 o=- 3214567890 3214567890 IN IP4 10.10.10.10 s=- c=IN IP4 10.10.10.10 t=0 0 m=audio 50000 RTP/AVP 96 a=rtpmap:96 EVS/16000/1 a=fmtp:96 bitrate=24400; mode-set=0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15; octet-align=1参数说明：
bitrate=24400表示EVS 24.4kbps模式，mode-set必须包含0（AMR-WB fallback）以保障兼容性。若SDP中出现m=audio ... 0或a=rtpmap:96 AMR/8000，则VoNR已降级，需检查IMS侧编解码器策略配置。
3.4 字段四：gNB侧记录的QoS Flow状态机迁移日志片段
仅靠核心网信令无法定位无线侧QoS Flow建立失败。必须从gNB日志中提取QoS Flow状态变更记录，与信令流程对齐：
[2024-06-15T10:23:45.123] QOS_FLOW_SM: [QFI=5] State=IDLE -> PENDING_SETUP (cause=QOS_FLOW_SETUP_REQUEST_RECEIVED) [2024-06-15T10:23:45.189] QOS_FLOW_SM: [QFI=5] State=PENDING_SETUP -> ACTIVE (cause=QOS_FLOW_SETUP_COMPLETE) [2024-06-15T10:23:45.201] QOS_FLOW_SM: [QFI=5] State=ACTIVE -> PENDING_RELEASE (cause=QOS_FLOW_RELEASE_REQUEST_RECEIVED)逻辑说明：若日志中缺失
-> ACTIVE行，或出现State=PENDING_SETUP -> IDLE (cause=QOS_FLOW_SETUP_FAILURE)，则问题在无线侧——可能是gNB未正确解析SMF下发的QoS参数，或空口资源不足。此时需比对gNB日志中的QosFlowSetupRequest与SMF发送的原始消息字节是否一致。
4. VoNR信令流程文档的避坑指南：5个让优化工程师凌晨三点还在改Word的致命细节
写VoNR信令流程文档，最怕的不是技术复杂，而是细节失真导致现网问题定位南辕北辙。以下是我在12个VoNR商用项目中踩过的血泪坑，每一条都曾让整支优化团队返工：
4.1 现象：文档中标注“AMF向UE发送Registration Accept后，UE立即发起SIP REGISTER”，但现网抓包显示间隔达2.3秒
原因：忽略了UE侧的“Registration Timer T3512”启动逻辑。T3512在Registration Accept中携带（IE: 5GS Tracking Area Update Timer），UE必须等待该定时器启动并运行至少1秒后才允许发起IMS注册。若文档未标注T3512值及UE行为约束，会导致误判为IMS侧响应慢。
解决：在文档中Registration Accept消息旁强制添加注释：“含5GS TAU Timer=30min，UE在T3512启动后≥1s发起SIP REGISTER”。
4.2 现象：SIP流程图显示“P-CSCF → I-CSCF → S-CSCF”，但实际网络中I-CSCF返回404 Not Found
原因：文档未体现DNS SRV记录查询环节。I-CSCF必须通过DNS查询_sip._tcp.ims.mnc001.mcc001.3gppnetwork.org获取S-CSCF地址，若DNS服务器未配置该域名SRV记录，I-CSCF无法路由。而Wireshark默认不显示DNS流量，易被忽略。
解决：在SIP REGISTER流程前增加DNS查询步骤框，并注明“需验证DNS服务器中存在SRV记录：_sip._tcp.ims.mnc001.mcc001.3gppnetwork.org. 3600 IN SRV 10 60 5060 scscf.ims.mnc001.mcc001.3gppnetwork.org.”。
4.3 现象：QoS Flow建立成功，但语音质量差（MOS<2.5）
原因：文档中QoS参数只写了GBR/MBR，却遗漏了“Reflective QoS Indicator (RQI)”字段。VoNR要求RQI=1，否则UE无法启用反射式QoS，导致上行语音包无QoS保障。该字段在QosFlowSetupRequest中为可选IE，但现网设备默认不携带，需PCF显式配置。
解决：在QoS参数表格中增加RQI字段，并标注“RQI=1 mandatory for VoNR uplink”。
4.4 现象：文档标注“gNB在收到SIP INVITE后触发QoS Flow修改”，但gNB日志显示QoS Flow未修改
原因：混淆了“QoS Flow Modification”与“QoS Flow Addition”。VoNR呼叫建立时，gNB需为语音流新增QoS Flow（QFI=5），而非修改已有QoS Flow。若文档错误写作“Modification”，会导致gNB配置脚本编写错误。
解决：统一术语为“QoS Flow Addition for Voice Bearer”，并在流程图中用虚线箭头明确指向“New QFI=5”。
4.5 现象：VoNR切换失败，文档中切换流程显示“gNB向AMF发送Handover Required”，但AMF未响应
原因：未标注Handover Required消息中的“Target ID”字段必须为gNB ID（而非小区ID）。若填写错误，AMF无法识别目标节点，直接丢弃消息。该字段在NAS消息中为必填，但Wireshark解析时常被折叠。
解决：在Handover Required消息旁截图显示Target ID字段值，并加粗标注：“Target ID = Target gNB Global NG-RAN Node ID (not Cell ID)”。
5. 用VoNR信令流程文档做“故障预演”：把3GPP TS 23.502 Annex B的Failure Scenarios转化为可执行检查表
真正的价值，不是把信令流程画出来，而是让它成为现网问题的“预测引擎”。我坚持将3GPP TS 23.502 Annex B中定义的VoNR失败场景，反向映射到信令流程文档的每个环节，生成一张可勾选的故障预演检查表。这张表不是事后分析工具，而是割接前必须完成的“压力测试清单”。
5.1 构建Failure Scenario Checkpoint矩阵：按信令阶段锁定检查项
我将VoNR全流程划分为6个关键阶段，每个阶段对应Annex B中3~5个典型Failure Scenario，并给出可验证的检查动作：
| 阶段 | 信令节点 | Failure Scenario（TS 23.502 Annex B） | 检查动作 | 验证方式 | 失败标志 |
|---|---|---|---|---|---|
| 注册 | UE→AMF | 5GS Registration Reject (Cause=86: No Suitable Cells In Tracking Area) | 检查TA List配置 | 对比gNB广播的TAI与AMF中配置的TA List | UE日志出现"REGISTRATION REJECT, Cause=86" |
| 注册 | AMF→PCF | Policy Association Failure (Cause=5003: Unknown Subscriber) | 检查PCF与UDM互通 | 在PCF侧执行curl -X GET http://udm:8080/subscription-data/{supi}/authentication-data | PCF日志出现"UDM connection timeout" |
| IMS注册 | UE→P-CSCF | SIP 403 Forbidden (Forbidden due to missing STN-SR) | 检查HSS/UDM中STN-SR配置 | 查询UDM数据库SELECT stn_sr FROM subscriber WHERE supi='imsi-00101...' | SIP REGISTER中Contact头缺失STN-SR参数 |
| 呼叫 | P-CSCF→I-CSCF | SIP 404 Not Found (No S-CSCF found) | 检查DNS SRV记录 | dig _sip._tcp.ims.mnc001.mcc001.3gppnetwork.org SRV | 返回结果为空或TTL=0 |
| 媒体面 | SMF→UPF | QoS Flow Setup Failure (Cause=52: Service not supported) | 检查UPF支持的5QI列表 | upf-cli show qos-profiles | UPF日志出现"5QI=5 not supported" |
| 切换 | gNB→AMF | Handover Preparation Failure (Cause=21: Target not accessible) | 检查Xn接口状态 | gnb-cli show xn-status | Xn接口状态为DOWN或Ping不通 |
逻辑说明：这张表的核心是“验证方式”列——它必须是运维人员能一键执行的命令，而非“检查配置”这类模糊描述。例如
dig _sip._tcp... SRV比“检查DNS配置”更可执行；upf-cli show qos-profiles比“确认UPF能力”更确定。每个失败标志都来自真实设备日志，确保一线人员能直接匹配。
5.2 将检查表嵌入CI/CD流水线：用Python脚本自动校验VoNR信令流程合规性
为避免人工检查疏漏，我把上述检查表封装成Python脚本，集成到VoNR割接前的自动化验证流水线中。脚本不依赖现网设备，仅通过解析.docx文档中的表格和文字，即可完成静态合规性校验：
# vonr_compliance_checker.py import docx import re def check_stn_sr_in_docx(doc_path): """检查文档中是否明确标注STN-SR配置要求""" doc = docx.Document(doc_path) found = False for para in doc.paragraphs: if re.search(r'STN[-_]?SR', para.text, re.I): if 'UDM' in para.text and '配置' in para.text: found = True break return found def check_dns_srv_in_docx(doc_path): """检查文档中是否包含DNS SRV验证命令""" doc = docx.Document(doc_path) for para in doc.paragraphs: if 'dig' in para.text and '_sip._tcp' in para.text and 'SRV' in para.text: return True return False # 主校验逻辑 if __name__ == "__main__": doc_path = "VoNR信令流程.docx" checks = [ ("STN-SR配置说明", check_stn_sr_in_docx(doc_path)), ("DNS SRV验证命令", check_dns_srv_in_docx(doc_path)), ("QoS Flow Addition术语", "QoS Flow Addition" in open(doc_path, "rb").read().decode("utf-8", errors="ignore")), ("T3512定时器标注", "T3512" in open(doc_path, "rb").read().decode("utf-8", errors="ignore")) ] print("VoNR信令流程文档合规性检查报告：") for name, result in checks: status = "✅ PASS" if result else "❌ FAIL" print(f"- {name}: {status}") if all([r for _, r in checks]): print("\n🎉 文档通过全部合规性检查，可进入现网验证阶段") else: print("\n⚠️ 存在未通过项，请修正后重新提交")参数说明：脚本采用
docx库解析Word文档，避免依赖Office COM组件；errors="ignore"处理中文编码异常；所有检查项均对应前述避坑指南中的致命细节。运行后生成的报告直接嵌入Jenkins构建日志，失败项自动触发邮件告警给文档作者。
5.3 用信令流程文档驱动现网KPI基线建设：把“接通率98%”拆解为23个可监控信令节点
最后，我坚持把VoNR信令流程文档，变成KPI监控体系的“神经末梢”。不是笼统监控“VoNR接通率”，而是将98%的目标，拆解为23个信令节点的成功率基线，并在Zabbix/Prometheus中配置对应指标：
| 信令节点 | 监控指标 | 基线值 | 数据来源 | 告警阈值 |
|---|---|---|---|---|
| UE注册成功率 | vonr_reg_success_rate{node="UE"} | ≥99.5% | UE侧日志统计 | <99.0% |
| AMF注册接受率 | vonr_reg_accept_rate{node="AMF"} | ≥99.8% | AMF性能统计 | <99.5% |
| PCF策略关联成功率 | vonr_pcf_assoc_rate{node="PCF"} | ≥99.9% | PCF日志 | <99.7% |
| SIP注册成功率 | vonr_sip_reg_rate{node="P-CSCF"} | ≥99.0% | P-CSCF CDR | <98.5% |
| INVITE 180 Ringing响应率 | vonr_invite_180_rate{node="I-CSCF"} | ≥95.0% | I-CSCF CDR | <90.0% |
| QoS Flow建立成功率 | vonr_qos_flow_setup_rate{node="SMF"} | ≥99.9% | SMF性能统计 | <99.5% |
逻辑说明：每个指标都必须有明确的数据来源，杜绝“人工统计”“后台报表”等模糊表述。例如
vonr_invite_180_rate必须从I-CSCF的CDR（Call Detail Record）中实时提取，而非依赖OMC汇总报表——后者存在15分钟延迟，无法支撑实时故障定位。基线值不是拍脑袋定的，而是取过去7天现网P95值向上取整。
我带过的每支VoNR优化团队，都养成一个习惯：每次现网KPI劣化，第一件事不是查设备告警，而是打开这份.docx文档，对照23个信令节点的监控曲线，3分钟内圈定问题域。文档里多写一行RTT门限，少画一个无关箭头，就能让故障定位时间从4小时缩短到22分钟。这份文档的价值，从来不在格式有多规范，而在于它是否真的能让你在凌晨三点，一眼看出哪个消息的RTT超了80ms——希望帮到你。
本文还有配套的精品资源，点击获取
