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

简介一份面向5G网络优化与通信技术人员的VoNR信令流程详解文档系统梳理5G语音业务端到端呼叫流程。内容涵盖RRC连接建立、SIP信令承载、5QI5/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层的问题而是5QI1的承载压根没建起来——这就是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 flowQoS flow再经SDAP映射到无线承载DRB然后走PDCP、RLC、MAC、PHY这四层空口栈。这个结构与VoLTE的“EPS bearer”体系有本质区别LTE用EPS承载直接绑定QCI5G则是“PDU会话- QoS flow - DRB”三级映射QoS flow由核心网SMF和PCF协商后通过RRC消息给到UE。网络侧对应关系是N1接口跑NAS5GMM5GSM由AMF处理N2接口跑NGAP连接gNB与AMFN3接口跑GTP-U承载用户面数据连接gNB与UPF。IMS域的SIP信令最终也是走这条用户面通道从UE发往P-CSCF而不是像很多人想的那样“SIP信令走控制面”。我在一线定位问题头一个月就踩过这个认知坑——抓NAS信令以为能看见SIP REGISTER翻完整包才发现SIP在GTP-U隧道里需要解GTP-U才能看到。2.2 端到端网元与接口信令绕不过的节点既然要读懂VoNR信令流程网元拓扑不能只看一张简化图。实际定位问题时一条呼叫会跨至少6类网元网元作用参与信令UE发起/接收语音5GMM、5GSM、SIPgNB接入与DRB建立RRC、NGAPAMF移动性管理与NAS转发N1/N2、HTTP/2SMFQoS flow与PDU会话控制N11、N4UPF用户面转发、GTP封装N3、N6PCF计费与QoS策略决策N5/N7/RxIMSP/I/S-CSCF会话控制与用户状态SIPUDM/UDR鉴权与签约数据N8/N10接口表里值得重点记住的是IMS与PCF的关系P-CSCF把语音业务需要的媒体资源信息送给PCFPCF通过N7接口给SMF下发策略。SMF拿到策略后才知道这个PDU会话要为语音建一条5QI1的GBR QoS flow。如果你看不懂“为什么SIP协商好了还是没有声音”九成是这一条策略链断了——P-CSCF没发AAR或者PCF没下发PCC ruleSMF自然不建GBR承载。排障时用一张接口表对照信令去重流程是我自己的习惯。比如根本没到SIP层就查N1/N2到了SIP但媒体建立失败查P-CSCF与PCF的策略交互RTP不连续查N3链路的GTP-U封装是否为语音正确标记QFI。2.3 承载与QoSVoNR信令流程里最容易被忽略的一环VoNR语音承载用的是5QI1这组参数直接决定通话体验也是信令流程能否走通的关键。5QI是5G QoS标识符相当于LTE里QCI的升级版语音用5QI1代表GBR、时延敏感。ARP分配与保留优先级在预占用资源时决定语音与数据谁先被踢QFI则是QoS flow的实例标识一个PDU会话里可以有多个QoS flow数据走默认flow5QI6/8/9语音走专有flow5QI1。参数典型取值说明5QI1语音媒体GBR时延预算100msARP1~2语音预留优先级决定抢占行为QFI动态分配在PDU会话内唯一标识QoS flowGBR/上行由P-CSCF下发SDP决定一般等同音频编码速率GBR/下行同上优先级高于AMBR做配置核查时我一般会在PDU会话建立接受PDU Session Establishment Accept消息里查两条QoS rule一条对应默认QoS flow一条对应语音QoS flow。语音这条必须携带QFI、5QI1、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 REGISTERP-CSCF把请求转发给I-CSCF再落到S-CSCFS-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 ProgressSDP 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接口建立专用DRBPDU会话更新加入5QI1的QoS flow。终端振铃与网络侧这些资源建立是并行完成的目的是让用户感知到的“等待接通时间”不包含空口资源准备。呼叫释放时任一方发起BYEIMS链路经S-CSCF、P-CSCF逐段转发并返回200 OK。随后SMF收到策略删除请求释放5QI1的QoS flowgNB将空口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 IndicatorAMF据此触发切换到LTEUE完成切换后PDN连接建立会带上语音专用的QCI1承载与VoLTE一致。这条路径在信令文档里往往占据独立小节。排障时常见的问题是NR侧为了语音紧急建了一个5QI1流程但网络还没下发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.port2152 rtp -T fields -e frame.time_relative -e gtp.payload -e rtp.ssrc第一条命令的问题是如果SIP经过了多个网元出口IP会变过滤条件建议在sip的基础上追加ip.addrx.x.x.x。第二条命令中GTP-U用UDP端口2152承载用户面RTP通过ssrc可以确认主叫和被叫媒体流的对应关系。如果你发现GTP-U内上层不是RTP而是普通TCP多半语音媒体没走专用QoS flow而是被默认承载转发这就是单通或音质差的直接证据。4.2 从跟踪平台拉取信令消息三个关键信号点抓包不是每个现场都有条件尤其是跨省呼叫基本拿不到端到端镜像。这时候最靠谱的做法是用核心网网管的信令跟踪。AMF、SMF、UPF各自都有跟踪能力UE侧还能用运营商调试模式抓modem日志。实际定位时我会同时挂三处AMF跟踪看NAS和NGAPSMF跟踪看N4/N11和策略交互P-CSCF跟踪看SIP与Rx接口。三条链路的时间戳对齐后VoNR信令流程就变成一张完整时间轴。抓取时的关键信号点有三个。第一个是PDU Session Establishment Accept里的QoS Rule列表第二个是N7接口上PCF返回的PCC Rule是否携带5QI1和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行的连接IPP-CSCF会把183错误转发主叫后续PRACK发到错误地址流程卡死。用tshark直接看SDP内容tshark -r call.pcap -Y sip sip.CSeq.methodINVITE -T fields -e sip.content-type -e sip.msg.body-e sip.msg.body输出消息体对照SDP字段检查是否有多个m行、codec是否受支持。我曾遇到某终端只报AMR-WB但网络只允许EVSP-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下发的5QI1动态PCC rule语音媒体被映射到默认QoS flowgNB按Non-GBR调度传输拥塞时直接丢包。解决查看SMF的N7接口日志里是否有PCC rule下发若没有检查P-CSCF是否发送AAR媒体描述到PCF。我在现网确认过一种翻车P-CSCF因为SDP里的带宽字段为0拒绝发送AARSMF侧白白等策略导致GBR承载缺失改配置后恢复。5.3 呼叫失败但信令停在UPDATE现象主叫发出UPDATE后无响应超时后屏幕显示“呼叫失败”抓包显示183正常。原因UPDATE里Precondition字段与对端网络不匹配或核心网SMF没有收到提前QoS请求。部分UE在qos前置协商时只发PRACK没发UPDATE使网络无法确认媒体资源。解决三个层面排查。第一看UE是否支持并启用了preconditionIMS配置里precondition值改为optional第二看P-CSCF是否转发UPDATE第三看SMF侧是否已建立5QI1若没有定位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而非普通切换确保核心网为语音建立QCI1的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确认5QI1的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.portyour_rtp_port -T fields -e rtp.seq -e rtp.timestamp -e rtp.ssrc | head -50seq和timestamp的组合可以还原RTP发送节奏。我在验收时见过一次低概率丢包案例全是PT值走默认承载、QoS flow建了又释放、RTP网关把SSRC改了三个问题叠加最后就是靠这套三步法逐个拆开的。VoNR信令流程这份材料本质上是把排障思路固化下来越早把它啃透你的定位路径就越短。希望这篇能帮你把现场那些“玄学”变成可复现的排查步骤。本文还有配套的精品资源点击获取