VoNR信令流程详解：从协议栈到QoS承载的5G语音排障指南

简介：一份面向5G网络优化与通信技术人员的VoNR信令流程详解文档，系统梳理5G语音业务端到端呼叫流程。内容涵盖RRC连接建立、SIP信令承载、5QI=5/1的QoS Flow与DRB映射、RTP/RTCP数据传输，以及弱覆盖场景下NR/LTE切换策略；同时详解EVS语音编码（含NB/WB/SWB/FB等模式）、紧急呼叫场景分类（普通用户与受限用户差异）、MAC CE调速和上行RB预留等增强功能，可帮助网优工程师透彻理解VoNR实现原理与常见排障思路。资源为1个docx文档，约1.37MB，正文结构清晰、步骤拆解细致，并配有信令流程图示，适合5G网优初中级工程师、电信协优考试备考者及无线/核心网技术人员学习。已有2412人学习，结合现场测试案例可快速掌握VoNR信令关键节点，提升5G语音优化与问题定位能力。

1. VoNR信令流程是什么：5G语音业务的中枢神经

凌晨两点被拉起来处理“VoNR呼叫单通”，群里贴了两段抓包，一段在主叫侧，一段在被叫侧。盯着信令翻到天亮，最后发现不是SIP层的问题，而是5QI=1的承载压根没建起来——这就是VoNR信令流程最真实的样子：拨号只是一个动作，真正决定通话能不能建立、能不能听到声音的，是手机、基站、核心网和IMS之间一串看不见的握手。VoNR，即Voice over NR，是5G网络原生承载语音的方案，与VoLTE最大的差异在于语音走5G空口而非LTE。这份名为“VoNR信令流程.docx”的文档，本质上就是把UE、gNB、AMF、SMF、UPF、PCF、IMS之间每一次交互画成时间轴。适合核心网工程师、无线网优、IMS运维和协议栈开发，用来定位“注册不上”“呼叫失败”“接通没声音”这类问题。

2. 从协议栈到网元接口：VoNR信令流程的地图

2.1 VoNR协议栈分层：为什么又叫“vonr协议栈”

很多人第一次接触VoNR，尤其是做LTE语音转过来的，会习惯性把它当成“5G版VoLTE”，这个简化方向没错，但会漏掉关键差异。VoNR的协议栈比VoLTE多了一层“5G QoS模型”的约束，空口侧承载结构完全重写。注意，热词里提到的“vonr协议栈”，业内口语常直接叫这个名字，指的就是这套从物理层到应用层的端到端协议体系。

UE侧从上往下看，语音业务的数据流走向是：SIP/RTP承载在IP层之上，IP包进入PDU会话，PDU会话映射到QoS flow，QoS flow再经SDAP映射到无线承载（DRB），然后走PDCP、RLC、MAC、PHY这四层空口栈。这个结构与VoLTE的“EPS bearer”体系有本质区别：LTE用EPS承载直接绑定QCI，5G则是“PDU会话- QoS flow - DRB”三级映射，QoS flow由核心网SMF和PCF协商后通过RRC消息给到UE。

网络侧对应关系是：N1接口跑NAS（5GMM+5GSM），由AMF处理；N2接口跑NGAP，连接gNB与AMF；N3接口跑GTP-U，承载用户面数据，连接gNB与UPF。IMS域的SIP信令最终也是走这条用户面通道，从UE发往P-CSCF，而不是像很多人想的那样“SIP信令走控制面”。我在一线定位问题头一个月就踩过这个认知坑——抓NAS信令以为能看见SIP REGISTER，翻完整包才发现SIP在GTP-U隧道里，需要解GTP-U才能看到。

2.2 端到端网元与接口：信令绕不过的节点

既然要读懂VoNR信令流程，网元拓扑不能只看一张简化图。实际定位问题时，一条呼叫会跨至少6类网元：

接口表里值得重点记住的是IMS与PCF的关系：P-CSCF把语音业务需要的媒体资源信息送给PCF，PCF通过N7接口给SMF下发策略。SMF拿到策略后，才知道这个PDU会话要为语音建一条5QI=1的GBR QoS flow。如果你看不懂“为什么SIP协商好了还是没有声音”，九成是这一条策略链断了——P-CSCF没发AAR，或者PCF没下发PCC rule，SMF自然不建GBR承载。

排障时用一张接口表对照信令去重流程，是我自己的习惯。比如根本没到SIP层，就查N1/N2；到了SIP但媒体建立失败，查P-CSCF与PCF的策略交互；RTP不连续，查N3链路的GTP-U封装是否为语音正确标记QFI。

2.3 承载与QoS：VoNR信令流程里最容易被忽略的一环

VoNR语音承载用的是5QI=1，这组参数直接决定通话体验，也是信令流程能否走通的关键。5QI是5G QoS标识符，相当于LTE里QCI的升级版，语音用5QI=1代表GBR、时延敏感。ARP（分配与保留优先级）在预占用资源时决定语音与数据谁先被踢；QFI则是QoS flow的实例标识，一个PDU会话里可以有多个QoS flow，数据走默认flow（5QI=6/8/9），语音走专有flow（5QI=1）。

做配置核查时，我一般会在PDU会话建立接受（PDU Session Establishment Accept）消息里查两条QoS rule：一条对应默认QoS flow，一条对应语音QoS flow。语音这条必须携带QFI、5QI=1、ARP、GBR，缺一项都会导致后续UPF不建GTP-U隧道，或被gNB降级成Non-GBR调度，也就是典型的“能接通、一说话就断”或“空口无声音”的翻车现场。

3. 拆解完整VoNR呼叫信令流程：从IMS注册到挂机拆链

3.1 IMS注册：VoNR通话的入场券

VoNR呼叫最先看到的信令不是INVITE，而是一串REGISTER。UE要通话，必须先向IMS注册自己，这个过程会触发5G核心网与IMS的两段流程交织。

典型注册步骤是：UE先通过RRC建立与gNB的连接，然后发NAS消息里的PDU Session Establishment Request，请求建立一个能为IMS服务的PDU会话（DNN为IMS）。SMF收到后签约校验，然后和UPF建立N4会话，最终下发PDU Session Establishment Accept给UE，此时UE获得一个IP地址，可以收发SIP消息。之后，UE向P-CSCF的地址发SIP REGISTER，P-CSCF把请求转发给I-CSCF再落到S-CSCF；S-CSCF向UDM拉取鉴权向量，返回401 Unauthorized挑战。UE生成响应后再次发REGISTER，通过鉴权后S-CSCF返回200 OK，注册完成，并下发第三方注册到AS业务平台。

VoNR信令流程.docx里最重要的不是记住每一步的英文缩写，而是理解这条链上的每个“401挑战”都可能成为耗时瓶颈。我遇到过的注册失败案例，很多是UDM里鉴权算法与UE侧配置不一致，UE算出来的响应在S-CSCF校验不过，不断循环401，屏幕上表现为“SIM卡无法注册”。处理方式是先把IMS切换开关复位，再逐个核对核心网签约参数中的鉴权算法设置。

3.2 主叫发起与Precondition协商：QoS建立是核心

呼叫是否真正建立，观察点不是INVITE，而是183 Session Progress之后的QoS确认。VoNR沿用IMS里的Precondition机制，意思是媒体资源在振铃前先预留好，避免对方接听了却没有资源通话。

主叫侧完整序列大致是：UE通过P-CSCF发出SIP INVITE，携带SDP offer，包含音频编码、端口、带宽需求。被叫经过寻呼后振铃，同时其IMS网络返回183 Session Progress，SDP answer里带Precondition状态字段。主叫UE收到183后，经5G核心网触发语音QoS flow的建立：即SMF向PCF查询策略，得到动态PCC rule后请求gNB建立对应的DRB，分配空口资源；空口和用户面隧道都就绪后，UE回复PRACK确认，再发送UPDATE，把SDP里的Precondition标记为“confirmed”。之后被叫摘机，返回200 OK，主叫回ACK，对话建立。

这里有一个高频误判：只盯着SIP层的180 Ringing看“通没通”，实际真正的资源协商完成点在UPDATE之后。如果183带的是“Precondition not confirmed”而后续UPDATE没有到达或没有把SDP置为confirmed，即便被叫摘机，主叫也会在通话0秒后掉线。用抓包验证时，我习惯同时筛选CSeq和路由头，确认INVITE→183→PRACK→UPDATE的串行关系，任何一个环节被NAT或防火墙改了SDP的connection address，后面全乱。

3.3 被叫侧流程与呼叫释放：谁拆的链要看BYE和SIP日志

被叫侧的信令与主叫侧在INVITE到达后才开始并行走：被叫UE收到寻呼，建立无线资源，完成QoS流程的预留（与主叫类似，只是方向相反），随后被叫TAC的gNB通过N2接口建立专用DRB，PDU会话更新加入5QI=1的QoS flow。终端振铃与网络侧这些资源建立是并行完成的，目的是让用户感知到的“等待接通时间”不包含空口资源准备。

呼叫释放时，任一方发起BYE，IMS链路经S-CSCF、P-CSCF逐段转发并返回200 OK。随后SMF收到策略删除请求，释放5QI=1的QoS flow，gNB将空口DRB拆除，PDU会话回到只有默认QoS flow的状态。拆链信令常见翻车点是无线侧迟迟不释放DRB或核心网N4会话未删除，导致手机进入空闲态后再次发起呼叫时出现“网络正忙”假象。

3.4 EPS Fallback与VoNR互操作信令：一张兜底网

VoNR信令流程并不只包含纯5G路径，还要处理5G覆盖不足时的兜底方案——EPS Fallback。语音呼叫触发后，网络发现NR覆盖不满足或UE不支持VoNR，会通过N2信令让UE重定向或切换到LTE网络，再由VoLTE继续完成呼叫。

关键信令点是：gNB在NGAP消息里携带RAT Fallback Indicator，AMF据此触发切换到LTE；UE完成切换后，PDN连接建立会带上语音专用的QCI=1承载（与VoLTE一致）。这条路径在信令文档里往往占据独立小节。排障时常见的问题是NR侧为了语音紧急建了一个5QI=1流程，但网络还没下发RRC重配，UE就发出测量报告要切LTE，两者互相打架，最终表现为“呼叫建立时间6秒以上”，这时应当重点排查gNB的语音优先策略与切换门限配置。

4. 用Wireshark和日志实测VoNR信令流程：可复现的验证方法

4.1 抓包过滤条件：别把全量pcap拖进分析器

实操验证VoNR信令，首选工具是Wireshark加核心网网管平台的跟踪文件。很多人一上来就抓全量pcap，几百万包让Wireshark卡到没法操作。我一般会先在tshark里做一次预过滤，只留语音相关的信令和媒体。

# 提取所有SIP信令（含GTP-U里的IMS流量） tshark -r capture.pcap -Y "sip" -T fields -e frame.number -e ip.src -e ip.dst -e sip.Request-Line -e sip.Status-Line # 只看GTP-U隧道内的RTP包，确认语音媒体流QoS绑定 tshark -r capture.pcap -Y "gtp && udp.port==2152 && rtp" -T fields -e frame.time_relative -e gtp.payload -e rtp.ssrc

第一条命令的问题是：如果SIP经过了多个网元，出口IP会变，过滤条件建议在sip的基础上追加ip.addr==x.x.x.x。第二条命令中，GTP-U用UDP端口2152承载用户面RTP，通过ssrc可以确认主叫和被叫媒体流的对应关系。如果你发现GTP-U内上层不是RTP而是普通TCP，多半语音媒体没走专用QoS flow，而是被默认承载转发，这就是单通或音质差的直接证据。

4.2 从跟踪平台拉取信令消息：三个关键信号点

抓包不是每个现场都有条件，尤其是跨省呼叫，基本拿不到端到端镜像。这时候，最靠谱的做法是用核心网网管的信令跟踪。AMF、SMF、UPF各自都有跟踪能力，UE侧还能用运营商调试模式抓modem日志。实际定位时我会同时挂三处：AMF跟踪看NAS和NGAP，SMF跟踪看N4/N11和策略交互，P-CSCF跟踪看SIP与Rx接口。三条链路的时间戳对齐后，VoNR信令流程就变成一张完整时间轴。

抓取时的关键信号点有三个。第一个是PDU Session Establishment Accept里的QoS Rule列表，第二个是N7接口上PCF返回的PCC Rule是否携带5QI=1和ARP优先级，第三个是N2消息里的PDU Session Resource Setup Request，里面包含gNB要为语音建立的DRB配置。这三点对齐，QoS链路就确认了。如果只给到一个网元的日志，主动向对端网元要trace ID，跨网元关联常靠AMF的5G-S-TMSI或IMSI来串联。

有的平台支持直接搜索SIP Call-ID，强烈建议把Call-ID作为全局索引，而不是用IMSI或MSISDN。SIP事务里Call-ID贯穿整个呼叫，从REGISTER到BYE都不会变，用它串起UE、核心网、IMS三类日志，能省下一个上午的时间。

4.3 解析信令字段：定位失败落在哪个节点

抓到信令后，真正的功夫在字段解读。信令流程文档里每个消息都可能成为故障分界点。举一个真实排查过的案例：PDU会话已经建立，IMS注册也200 OK，但主叫一拨出INVITE就被P-CSCF回503 Service Unavailable。从SIP层看,P-CSCF没有把INVITE转发到S-CSCF,问题在IMS内部路由。此时我抓P-CSCF日志,发现它解析不了Request-URI里的domain，而S-CSCF地址配置错误。

另一种常见情况是信令流程停在183之后。字段定位方法如下：查SDP里m行和a行是否有sendrecv、ptime、maxptime，如果a行被NAT剥离了c行的连接IP，P-CSCF会把183错误转发，主叫后续PRACK发到错误地址，流程卡死。用tshark直接看SDP内容：

tshark -r call.pcap -Y "sip && sip.CSeq.method==INVITE" -T fields -e sip.content-type -e sip.msg.body

-e sip.msg.body输出消息体，对照SDP字段检查是否有多个m行、codec是否受支持。我曾遇到某终端只报AMR-WB但网络只允许EVS，P-CSCF拒绝转发导致呼叫失败。这种问题在信令流程文档里通常以“codec negotiation failure”标注，排障时别只看传输层，把SDP里的编码列表与自己网络的编解码白名单比对。

5. VoNR信令排障避坑：6条血泪经验

5.1 SIP 401循环，IMS注册卡死

现象：UE不断发REGISTER，网络一直回401 Unauthorized，界面显示“注册失败”。

原因：多数是UDM与UE间的鉴权向量不匹配，或UE侧AKA算法里密钥K/OPc配置错误，SIM卡数据与核心网HSS侧不一致。少数是S-CSCF选错了鉴权算法。

解决：先在AMF和UDM日志里查鉴权请求与响应，确认RAND/AUTN是否有效；再核对UE里的IMS APN和鉴权算法是否与核心网签约一致。若AUTN失效，优先检查核心网时间与UE时间偏差，VoNR的AKA对时间偏差的容忍度比2G/3G苛刻。

5.2 呼叫建立成功但单通，问题在QoS flow未建立

现象：通话显示接通，但主叫或被叫一侧听不到任何声音，挂断后信令无异常。

原因：SIP层协商完成后，SMF没有收到PCF下发的5QI=1动态PCC rule，语音媒体被映射到默认QoS flow，gNB按Non-GBR调度，传输拥塞时直接丢包。

解决：查看SMF的N7接口日志里是否有PCC rule下发，若没有，检查P-CSCF是否发送AAR（媒体描述）到PCF。我在现网确认过一种翻车：P-CSCF因为SDP里的带宽字段为0拒绝发送AAR，SMF侧白白等策略导致GBR承载缺失，改配置后恢复。

5.3 呼叫失败但信令停在UPDATE

现象：主叫发出UPDATE后无响应，超时后屏幕显示“呼叫失败”，抓包显示183正常。

原因：UPDATE里Precondition字段与对端网络不匹配，或核心网SMF没有收到提前QoS请求。部分UE在qos前置协商时只发PRACK没发UPDATE，使网络无法确认媒体资源。

解决：三个层面排查。第一看UE是否支持并启用了precondition，IMS配置里precondition值改为optional；第二看P-CSCF是否转发UPDATE；第三看SMF侧是否已建立5QI=1，若没有，定位PCF策略下发。

5.4 EPS Fallback后无法返回5G

现象：每次呼叫都触发到LTE的切换，通话结束后手机停留在4G，不返回NR，直到手动飞行模式才恢复。

原因：切换后的网络没有配置返回NR的测量和重选参数，或VoNR呼叫结束后释放了语音QoS flow，但重选优先级仍被设为LTE优先。

解决：核对目标LTE小区的RRC重选配置以及EPS Fallback的释放版本，确保核心网传递“voice call结束时返回NR”的指示。现网里最常用的后悔药是调整语音呼叫结束后LTE侧的测量门限，或者给UE下发单独的重选优先级配置。

5.5 跨运营商呼叫延迟大，原因是Rx接口路由不当

现象：VoNR呼叫建立时间超过5秒，但单网元日志里没有异常。

原因：P-CSCF选择PCF时没有区分本地PCF与对端网络的PCF，策略请求跨省绕行，或PCF查询签约数据的RTT过长。

解决：在P-CSCF里按SIP呼叫归属地配置PCF选择策略，同时在PCF侧开启N7接口的时延统计。把策略交互从呼叫链路挪到“媒体建立前”并行执行，能有效缩短呼叫前时延。

5.6 通话中途突然变VoLTE，核心网发出了RAT Fallback但未通知被叫

现象：主叫端到端都是VoNR，通话30秒后语音中断，随后自动切到VoLTE继续通话，期间有明显停顿。

原因：NR覆盖测量门限配置过低，基站触发了基于覆盖的RAT切换，但语音连续性没有通过SRVCC保护。gNB的切换策略与AMF的语音连续性策略不一致。

解决：检查gNB的A2/B2事件配置与AMF的SRVCC策略，语音场景下优先触发SRVCC而非普通切换，确保核心网为语音建立QCI=1的LTE承载。这类问题在跨厂组合（NR与LTE异厂家）时最容易出现，玄学感很强，实际查的是两家的参数表和版本兼容性。

6. 进阶技巧：三步确认VoNR端到端质量是否达标

前面解决了“能通不能通”，最后分享我自己验证VoNR语音质量是否真正达标的三步法。这个方法可以复制到每次版本升级或参数调整后的验收中，比单纯“打两通电话听一听”可靠得多。

第一步，核对SIP 200 OK里的媒体协商结果。用Wireshark筛选INVITE和200 OK，确认主被叫协商出的编码（EVS还是AMR-WB）、RTP端口、IP地址。记住payload type编号，后续RTP流的PT值必须与SDP协商一致，不一致就说明有中间网元改码或插入了媒体代理。

第二步，确认QoS flow确实承载了RTP。在SMF侧查N4会话的QoS rule，确认5QI=1的GBR值，同时对比UPF的RTP报文流量统计。如果GBR设成40kbps，但UPF实际流量是0或持续超限，说明空口与核心网之间调度不匹配，要调整gNB的DRB配置或核心网的MBR参数。

第三步，关注RTP的连续性。取通话0秒到10秒的pcap片段，计算RTP包间隔抖动和丢包率。抖动超过20ms时，即便网络里没有丢包，人耳也会有明显断续，此时优先检查UPF和gNB之间的传输时延抖动。这个数据一般从UPF的流采样统计里拿：

tshark -r voicencall.pcap -Y "rtp && udp.port==your_rtp_port" -T fields -e rtp.seq -e rtp.timestamp -e rtp.ssrc | head -50

seq和timestamp的组合可以还原RTP发送节奏。我在验收时见过一次低概率丢包案例，全是PT值走默认承载、QoS flow建了又释放、RTP网关把SSRC改了三个问题叠加，最后就是靠这套三步法逐个拆开的。VoNR信令流程这份材料，本质上是把排障思路固化下来，越早把它啃透，你的定位路径就越短。希望这篇能帮你把现场那些“玄学”变成可复现的排查步骤。

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