VoNR信令流程详解：从5G注册到IMS语音QoS Flow建立

简介：面向5G网络优化与维护人员，这份VoNR信令流程文档系统梳理了VoNR语音业务的关键信令过程。内容从主被叫UE发起呼叫、建立RRC连接开始，逐步讲解5GC创建5QI=5的SIP信令承载、IMS会话协商，以及5QI=1的RTP/RTCP语音数据承载建立与释放，完整呈现VoNR端到端语音流程；同时涵盖弱覆盖切换策略、EVS语音编解码、紧急呼叫分类、MAC CE调速等进阶知识点，对理解5G语音承载机制、优化VoNR参数和开展网优排错具有直接参考价值。资源为单个docx文档，压缩包大小仅1.37MB，已有2412人学习浏览，适合具备无线网络基础、从事或准备从事VoNR优化与IMS语音保障工作的工程师查阅。

1. VoNR信令流程只是一份文档，真正要解决的是把五段信令串成一条可验证的链路

收到一份名为“VoNR信令流程.docx”的交付物，很多人的第一反应是打开看有多少页、图多不多。但真正值钱的不是那张能当海报看的时序图，而是图背后的每一跳消息、每个参数、每个状态转移是否能对上现网动作。VoNR语音流程本质上可以拆成五段：5G注册、IMS注册、默认PDU会话与IMS信令承载、SIP呼叫与专用QoS Flow建立、以及释放。这五段在文档里如果只是按顺序摆出来，新手照着走都会出偏差。这篇文章我会按这个标题展开，告诉你如何把一份“VoNR信令流程”文档从“能看”变成“能联调、能排障、能交付”。适合刚接触5G语音的无线/核心网测试工程师，也适合手里拿着半成品文档不知道从何补起的方案交付人员。

2. 先把注册与呼叫拆开：VoNR信令流程的两条主时间线

一份合格的VoNR信令流程文档，最难画的部分往往不是呼叫本身，而是“注册”和“呼叫”这两条时间线的关系。很多文档把它们画成一条从头到尾的长直线，结果读者看到一半就乱了。实际上，VoNR存在两层会话：一层是5G系统层面的注册与PDU会话，另一层是IMS会话。两层需要先后出现、嵌套承载，但消息类型完全不同。

2.1 5G注册与默认PDU会话：P-CSCF地址是怎么“塞”进来的

所有业务的第一步都是无线和核心网的5G注册。UE开机后先做NAS层的REGISTRATION，AMF完成接入鉴权，随后UE发起PDU Session Establishment，而且这个PDU会话的DNN必须是IMS。为什么一定要先建这个PDU会话？因为IMS信令包需要一条“能到达互联网域”的数据通道，而PDU会话正是这条通道。SMF从UDM取签约信息后，PCF参与策略授权，最终返回PDU Session Establishment Accept。

这里有一个VoNR特有的细节：P-CSCF的地址不是UE查配置查出来的，而是核心网在PDU会话建立过程中下发给UE的。下发的位置就在NAS消息里的Protocol Configuration Options，也就是协议配置选项。VoNR协议栈中，这个阶段的PDU会话内部只携带一条Non-GBR的QoS Flow，5QI通常为5，专门用来承载后续的SIP REGISTER和SIP INVITE等控制面消息。因为语音呼叫还没开始，RTP端口尚未协商，此时没有必要建立任何GBR承载。

整理文档时，我给这一段的建议是画一张“三消息表格”，把关键字段列出来：

这张表里最容易被区域割裂画错的地方在第三步到第四步：N2消息是给gNB建立无线侧DRB用的，N1消息才是给UE用的。两者存在先后关系，但并不像一条管道那样两边同时落字，实际文档需要在时序图里用两条平行消息表示，并标注“UE在收到Accept后才获得P-CSCF地址”。

2.2 IMS注册：REGISTER 与 200 OK 之间发生了什么

PDU会话建好，UE拿到IP地址和P-CSCF地址之后，VoNR才开始真正进入IMS流程。UE在5QI=5这条QoS Flow上发送SIP REGISTER，目的地就是P-CSCF。P-CSCF不负责用户认证，它只是把REGISTER继续转发给S-CSCF。S-CSCF回复401 Unauthorized，携带挑战参数。UE需要重新计算鉴权响应，发起第二次REGISTER，这次消息中携带Authorization头里的响应值。随后S-CSCF返回200 OK，IMS注册完成。

这里要提醒：很多文档把两次REGISTER画成都是发给P-CSCF，这没错，但P-CSCF这里的地址来源必须和上一节呼应。如果你画的REGISTER直接指向某个固定代理IP，而前面的PDU会话建立PCO空白，那这份文档就没法指导实际联调。现场会在PDU会话建立失败或PCO解析异常时，UE根本无法发起REGISTER。

IMS注册成功后，VoNR文档还要回答一个问题：语音呼叫所需的专用QoS Flow是何时建立的？答案不是开机时，而是呼叫建立过程中。所以真正的主链路，是SIP INVITE触发核心网追加QoS Flow的过程。

2.3 呼叫主链路：INVITE 如何触发专用 QoS Flow

主叫用户拨号后，UE先通过已经存在的5QI=5 QoS Flow发送SIP INVITE，SDP offer里携带AMR-WB语音编码、RTP端口、IP地址等信息。P-CSCF收到INVITE后，需要去PCF申请语音QoS策略。PCF根据号码/业务优先级判断这次呼叫需要一条保证带宽的QoS Flow，于是SMF构造“PDU Session Resource Modify Request”通过AMF发给gNB，请求新增一条5QI=1的QoS Flow并分配新的QFI。RAN收到后为这条QoS Flow建立对应的DRB，并向UE下发RRC重配置，告诉它这条QoS Flow的DRB映射关系。

在这里，顺序最容易出错。不少文档把语音QoS Flow建立放在INVITE之前，理由是“没有承载怎么发呼叫”，但这是错的。INVITE走的是现有5QI=5信令承载，不需要语音专用承载；而语音专用承载的RTP端口是SDP offer里写明的，核心网必须拿到SDP才能选择QoS参数并向RAN下发QoS Flow。先画5QI=1建立再发INVITE，等于在RTP端口未知的情况下白白建了一条不知道发给谁的承载。

正确的时间线应该是：

这条链路如果能画通，VoNR信令流程文档的核心价值就体现出来了。后面所有排障，比如“为什么主叫发了INVITE没收到100 Trying”“为什么语音通了但双声”之类的问题，都能沿着这张表定位。

3. 把VoNR信令流程画成Word文档：时序图分区、参数注释与状态表

手里有素材，不等于能交付。真正的文档工作是把信令流“翻译”成别人能复现的图、表、参数注释。这一章讲讲我在做VoNR信令流程Word文档时的排版与内容组织。

3.1 时序图分三个泳道区，别把SIP画到5G核心网上

最常见的败笔，是把所有网元拉成一个平面，UE在左边，HTTP/2、SIP、NGAP全在中间交叉。我自己一般会强制把一张时序图分成三个泳道区：无线接入区、5G核心网区、IMS区。

无线接入区画UE和gNB，两者之间的消息是RRC和NAS，Uu接口；5G核心网区画AMF、SMF、PCF、UPF，消息是N1/N2/N4，其中N2实际上是NGAP消息；IMS区画P-CSCF、S-CSCF和AS，消息是SIP。为了让图不乱，每条消息都要画在属于它的分区内，跨分区消息一定要标注接口名。例如AMF收到gNB发来的N2消息后，需要调用SMF服务，这条属于核心网内部消息，不要跨到IMS区。

字体和线型也要统一。常用做法是：NAS消息用实线，NGAP消息用虚线，SIP消息用加粗实线，RTP媒体流用灰色点划线。图例放在时序图左上角。这样读者一眼能分清承载层和控制层。

3.2 参数注释：至少标出5QI、QFI、SDP媒体行与计时器

时序图画好后，不要直接在消息旁堆参数。正确做法是给每条消息一个编号，比如SIP-01、N2-03，然后在消息下方用括号标注关键参数。至少需要标注下列这些。

5QI：区分信令与语音的关键。5QI=5是IMS信令，Non-GBR；5QI=1是VoNR语音，GBR，优先级较高。QFI：由核心网分配，PDU会话内唯一。SDP媒体行：m=audio端口、a=rtpmap:AMR-WB或“EVS”。对于VoNR文档，可以给出一个推荐SDP示例，并说明其中端口是动态协商结果，不是固定值。计时器：SIP层有Timer B、Timer F，NAS层有T3502，核心网也有配置的等待计时器。

文档交付时，我会在后面附一张参数注释表，把每条消息中该看什么字段列出。这样现场测试时不用翻协议标准。

参数注释表示例：

3.3 配一张状态迁移表，覆盖“网络事件→UE动作”

时序图只能看一条时间线，状态迁移表才能看“UE当前在哪一步，下一步该干什么”。对VoNR这类长流程，状态表能帮助测试人员在异常时判断是UE没发消息，还是网络没响应。

我通常在Word里插入一个三列表格。第一列是UE状态，第二列是触发事件，第三列是UE动作与预期消息。示例：

这张表看着简单，真写起来需要覆盖所有分支：拒绝、无应答、挂断、核心网下发Bearer修改等。如果文档里缺少状态表，测试人员只能靠看图猜，效率很低。

4. VoNR信令流程避坑指南：5个最容易翻车的细节

以下是我在核验多份VoNR信令流程文档时踩过的一些典型坑，每一条都对应过真实的联调问题。按“现象、原因、解决”的方式整理，方便直接对照修订。

4.1 把5G注册和IMS注册画成同一条信令线

现象：文档把NAS REGISTRATION和SIP REGISTER画在一条直线上，开头是UE发REGISTER，结尾也写REGISTER，读者以为IMS注册是5G注册的延续，还共用同一套鉴权。原因：两者都有“注册”这两个字，画图时图省事。解决：强制分成两个泳道区，NAS注册归5GC区，SIP注册归IMS区。在文档开头加一句：“IMS注册必须建立在已完成默认PDU会话之后，且P-CSCF地址来自PDU会话建立Accept。”

4.2 漏掉P-CSCF发现

现象：UE直接向某个固定的SIP服务器IP发送REGISTER，文档里看不到IP从哪来。原因：写文档的默认读者是IMS组的人，只关注SIP流程，忽略了5GC组下发的PCO字段。解决：在流程图上将PDU Session Establishment Accept消息放大，在消息框内写下“PCO携P-CSCF地址”；在REGISTER目的地处用注释框标注“由前文PCO获得”。同时建议在文档附录中给出MCC/MNC下P-CSCF地址的配置来源。

4.3 时序错位：语音QoS Flow画在INVITE之前

现象：时序图中先出现“建立QoS Flow 5QI=1”，再出现“UE发送INVITE”。原因：画图人认为所有媒体必须预先建立承载，否则语音无法传输。解决：明确两条消息的先后关系，即INVITE在5QI=5上发送，SDP offer内携带RTP端口；核心网解析SDP后，通过PDU Session Resource Modify Request新增5QI=1。修改图时，把“SIP INVITE”画在“PDU Session Resource Modify Request”之前，并加一条注释“语音QoS流由核心网根据SDP内容发起”。

4.4 术语混淆：QoS Flow、DRB与Bearer分不清楚

现象：文档中超半数“承载”字眼出现在5G部分，比如“建立承载”“承载修改”。原因：作者可能做过4G VoLTE，把EPS Bearer概念直接搬进5G。解决：在文档“定义”章节一次性澄清三个概念。QoS Flow是端到端的QoS流，由QFI标识；DRB是无线侧的数据承载，负责空中接口传输；Bearer只在4G网络或者互操作场景中使用。文档正文里，5G流程部分不要使用“Bearer”表述。

4.5 计时器与重传消息不标

现象：一条INVITE在文档里只出现一次，向后直接跳180 Ringing。原因：把SIP当作TCP假设不会丢包。解决：在INVITE发送后，标注“若Timer B超时则重传INVITE，最多重传次数参考IMS配置”。同样，REGISTER如果遇到401重传，也要预留状态表。如果不想画得太拥挤，至少要在参数注释表里列一次Timer B与Timer F的值，并说明依赖UDP传输时需要这些机制。

5. 验证一份VoNR信令流程文档：抓包、日志与参数反查的实操清单

画好的流程图，不代表现网就按图走。做完文档之后必须进行验证。验证不是拿着Wireshark看一两个包，而是系统性对照流程图核对三条层：SIP层、NAS/N2层、无线参数层。

5.1 用Wireshark验证SIP与SDP

针对VoNR主叫侧的SIP信令，抓包位置通常在UE调试端口或P-CSCF侧。Wireshark打开抓包后，用显示过滤器快速定位：

sip.Method == "INVITE" || sip.Method == "REGISTER"

这段过滤器把SIP控制消息过滤出来。要点是确认INVITE确实在REGISTER之后出现。REGISTER成功后，INVITE的请求URI必须是被叫号码，消息体必须包含SDP。进一步查看SDP内容，可以展开“Session Description Protocol”层，重点看媒体行中的“m=audio 端口 RTP/AVP 96”。如果看到媒体端口是0，说明文档会与实际环境矛盾，实际环境中端口为0表示媒体关闭。

再做一步关联过滤，看SIP消息是否是在IMS信令专用承载上发送。这里依赖底层信息，需要同时抓NAS解包。如果终端日志中显示NAS产生了PDU Session Establishment Accept，且PCO内容里有P-CSCF的IP，再对比Wireshark中REGISTER目的地址，二者应一致。

5.2 从RRC/NAS日志反查QoS Flow建立

5G侧的语音专用QoS Flow建立，关键看两条消息：PDU Session Resource Modify Request和RRCReconfiguration。在gNB侧日志里，可以用以下命令提取相关消息：

grep -E "PDU Session Resource Modify|QosFlowSetup|QFI|5QI" /var/log/gnb/gnb.log -A 10

输出中要能看到QFI分配，以及该QFI对应的QosFlowLevelQoSParameters里5QI是否为1。如果5QI是2或者非GBR，说明网络配置错误。随后再查RRC重配置消息，确认SDAP配置里把QFI映射到哪个DRB。这一映射最终决定上行数据走哪条无线承载。

同时建议检查UE侧NAS消息里的PDU Session Modification Command。这条消息会告诉UE新增的QoS Flow的QFI和对应QoS规则。如果UE迟迟没有收到这条命令，但gNB已经收到Modify Request，此时问题多半在AMF与SMF之间的转发。

5.3 参数反查：用现网配置核查5QI/ARP

协议文档写得好不好，还要看参数设计是否贴近真实网络。很多VoNR文档默认5QI=1、ARP=2，但没有说明来源。实际上不同运营商的ARP优先级可能不同。这时需要反查AMF/SMF的QoS参数配置文件。重点核查三项：5QI=1是否是GBR，ARP值是否与其他业务冲突，最大上行比特率是否被错误限制。

下面是一份参数核查表，把它打印出来逐项打勾：

6. 把信令流程做成“编号脚本化”文档，维护成本降一半

最后分享一个我的习惯。以前画VoNR信令流程图，总是把时序图画得很大，消息线交叉成网。后来我改成“编号脚本化”：文档里每一段信令步骤不再用节点坐标表示，而是给每个消息分配一个全局唯一的步骤编号，比如NAS-05、N2-11、SIP-08，然后在时序图旁放一张“信令步骤表”。表格栏位包括编号、接口、消息名、关键参数、依赖上一步编号、超时重传备注。这样流程图只需要保留一条主干，分支统统用编号引用。

举例：画主叫流程时，SIP INVITE的编号是SIP-05，依赖NAS-02；语音QoS Flow建立是N2-09，依赖SIP-05。新增一个SIP 183会话进程时，不需要重画整条线，只需要在表格SIP-05和SIP-08之间插入一行，给它编号SIP-06，并把原有SIP-08改成依赖SIP-06。我的经验是，用这种方式维护一份VoNR信令流程，半年后再改版本，不会像以前那样一改全乱。

另外给文档的每个阶段加一个小节标题，比如“主叫流程”“被叫流程”“异常流程”，正文引用时直接写“参见主叫流程步骤SIP-05”。这套方法不仅适用于VoNR，也适用于其他IMS信令流程文档。坚持这样做以后，我从“画图两小时、改图两小时”变成了“表格二十分钟、改图五分钟”。希望这套经验对你管理信令文档有帮助。

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