简介《VoNR信令流程》文档是一份面向5G网络优化与信令分析人员的技术资料系统讲解5G语音业务从呼叫建立到释放的完整信令过程适合网优工程师在实际工作中参考。文档仅包含1个Word格式文件压缩包整体1.37MB内容紧凑、便于直接查阅。目前已有2412人学习下载是5G网优领域较受关注的资料。文档重点梳理了主被叫UE建立RRC连接、5GC创建5QI5的SIP信令承载与5QI1的RTP/RTCP语音承载、gNodeB建立对应DRB等关键步骤并配有流程示意图同时还涵盖弱覆盖切换策略、紧急呼叫用户分类、EVS语音编解码模式及MAC CE调速机制等进阶知识点可帮助读者快速掌握VoNR信令全流程并将理论用于实际参数配置和问题排查中。1. VoNR信令流程一份 docx 把核心网信令从黑匣子变成可查的表格做 VoNR 信令流程排查时最难受的不是抓不到包而是抓了一大串 SIP 消息却不知道每一步该看哪个字段。我手里这份《VoNR信令流程.docx》把从 PDU 会话建立、IMS 注册到 INVITE、183、专用 QoS Flow 建立的完整信令路径拆成了可编辑的文档。它解决的是“流程看起来都懂一到现场就翻车”的问题你不需要重新画架构只需要按目录找到对应消息对着表格查字段、查 Cause Code、查超时定时器。适合三类人——核心网工程师定位信令失败用例网优人员分析语音质量前先确认资源建立时序协议栈开发做字段级自测。2. 理解 VoNR 信令流程前先把 VoNR 协议栈里那几张表对齐网元、接口与 Cause Code2.1 VoNR 不是 LTE 加两句 SIP会话建立的整体视图VoNR 和 LTE 语音最大的差别是承载语义变了。LTE 时代经常说要建“专用承载”网优人员翻 QCI1 的 EPS Bearer到了 VoNR承载改叫 QoS Flow类型也不再是“Bearer ID QCI”而是“PDU Session Flow”。这个变化是很多新手绕晕的第一个点在 Wireshark 里看到 NAS 消息里同时出现 PDU Session ID 和 QoS Flow ID就想当然地套 LTE 的 DRB 概念结果把流程节点对错了。这份 docx 文档在前几页就会把这种对应关系做成表我一般会先把这张表从头到尾过两遍等脑子里建立起“PDU Session 管会话、QoS Flow 管质量”的边界后再往下看。VoNR 呼叫从无线侧看分为两条并行的信令线一条是 5G 核心网流程UE 与 AMF 之间跑 NAS 消息AMF 通过 N11 与 SMF 协作建立 PDU 会话并分配 QoS Flow另一条是 SIP 语音会话UE 与 IMS 之间跑 INVITE、183、ACK经 P-CSCF 转发P-CSCF 又与 PCF 通过 Rx 接口交互。两条线在 P-CSCF 和 PCF 这里汇合SIP 会话里协商出的 SDP 参数最终要映射成 5G 侧的 QoS Flow 参数也就是 5QI5 语音媒体流的预留。文档里通常会用一张时序图把这个“双线汇合”的节点标出来你看图的时候重点看有没有一条从 PCF 指向 SMF 的箭头这条箭头就是后面找“专用 QoS Flow 建立”流程的起点。阶段关键消息负责网元5G 侧对应流程注册阶段UE-AMF: PDU Session Establishment RequestAMF/SMF建立 IMS PDU 会话默认 QoS Flow 5QI5语音会话UE-P-CSCF: SIP INVITE (SDP offer)P-CSCF, S-CSCF无走既有的 PDU 会话资源协商P-CSCF-PCF: Rx/Session EstablishmentPCF触发 SMF 修改 PDU 会话专用资源SMF-UE: PDU Session Modification CommandSMF/UPF/gNB建立专用 QoS Flow通常 5QI1确认UE-P-CSCF: SIP ACK各网元会话建立完成读这张表要记住一点VoNR 不强制把语音全部切成专用 QoS Flow部分运营商首版开通时就用 5QI5 的默认 Flow 传语音。文档里如果写“专用 QFI1”那只是常见的“QoS Flow 增强型”配置不是唯一解。我现在看任何一份厂商提供的信令流程文档都不会直接拿表当真理而是先看标题页有没有注明版本号、适用范围和是否面向 5G SA 组网遇到不写这些的版本只当参考。2.2 接口、网元、Cause Code文档最开始那几张表才是全局视图真正读文档时一份好的信令流程 docx 不会一上来就贴消息而是先给一张网元接口表。我在拆这份文档时发现最容易被跳过的恰恰是前两页的表格一页列出 UE、gNB、AMF、SMF、UPF、PCF、P-CSCF、S-CSCF、HSS/UDM另一页列出 N1、N2、N3、N5、N7、N8、N10、N11、Gm、Mw 接口。后面所有流程图里出现的箭头、信令点都与这张表一一对应不去核对这张表就很容易把 N11 上的 HTTP/2 消息看成 SIP把 Diameter 的 Result-Code 与 SIP 的 Status-Code 混在一起。我拿到文档后第一件事是复制这张接口表再插入两列一列叫“现网对应设备”一列叫“备注”。因为原文档是按标准网元写的而现网往往是多厂商混组网SBC 同时承担 P-CSCFSMF 里还带了 PCF 功能接口的 IP 地址也可能与文档里不同。常见做法是先在表格里把“标准角色 / 实际网元”对应上再回到流程图确认每个接口两侧是谁。这一步做完后续在 Wireshark 里抓包时才知道要去看哪个端口、哪个信令面。另一张重要的表是 Cause Code 对照表。VoNR 信令失败经常不是一个 Cause Code 就能说明白SIP 层面返回 403、Diameter 层面返回 5001、NAS 层面返回 29三者之间是映射关系不是独立事件。文档里如果有一张“Cause Code 跨层映射表”排查时能省大量时间。没有的话我建议自己创建一张六列表格消息方向、协议层、Cause Code、描述、常见触发网元、排查动作。这张表是这份 docx 最有价值的部分比正文里的时序图还值得每天翻。2.3 把接口表拆成自己的速查卡一个可执行的提取脚本前面说了文档前几页的表格重要但 Word 里一行一行复制到 Excel 很费劲。我的办法是直接用 Python 把 docx 里的表格批量导出成 CSV放在手边当速查卡。注意 docx 本质上是一个 zip 包正文在 word/document.xml 里用 python-docx 可以透明地读到段落和表格from docx import Document # 打开你手上这份 VoNR信令流程.docx路径按实际情况修改 doc Document(VoNR信令流程.docx) # 只取前 5 张表前几页网元表、接口表一般都在这里 for idx, table in enumerate(doc.tables[:5]): print(f----- Table {idx 1} -----) for row in table.rows: # 将单元格里的换行符拍平成单行避免 CSV 错行 cells [cell.text.strip().replace(\n, ) for cell in row.cells] print( | .join(cells))这段脚本做的事情很简单Document() 打开 docx遍历 doc.tables 列表取前 5 张表通过 row.cells 逐一读取每个单元格文字。注意 table.rows 会包含表头的合并单元格同一行可能取出多个重复 cell这是 python-docx 的常见行为不要当成数据多了一份。输出到屏幕适合先看结构真正要存速查卡我会改成写入 CSV 并带上 utf-8-sig 编码否则 Excel 打开中文会乱码import csv from docx import Document doc Document(VoNR信令流程.docx) with open(vonr_interfaces.csv, w, newline, encodingutf-8-sig) as f: writer csv.writer(f) for table in doc.tables[:5]: # 在每张表前插入一个分隔行方便分清网元表还是接口表 writer.writerow([----, ----, ----]) for row in table.rows: cells [cell.text.strip().replace(\n, ) for cell in row.cells] writer.writerow(cells)参数说明doc.tables[:5] 是只处理前 5 张表如果你的文档结构不同可以在循环前打印 len(doc.tables) 看一下总表数再改utf-8-sig 会让 Excel 正确识别 UTF-8 编码避免一到 Excel 里问号遍地。导出之后我一般把 CSV 和原 docx 放在同一目录然后在 Windows 搜索里按表格关键字定位比如直接搜“N7”马上能看到这行在哪个表格、前后是什么接口。这样原版 docx 就能保持干净不因为我的标注而改坏。3. 把 docx 当“调试手册”用Windows 搜索正文与字段级比对3.1 先回答docx 可以在 Windows 搜索结果里看到正文吗很多人问“docx可以在Windows搜索出正文吗”我的回答是能但默认状态下不一定立刻能而且被 Everything 误导过的人不在少数。Everything 在文件管理器里也能搜索但它只读 NTFS 的 MFT 和文件名根本不打开 docx 内部所以你拿 Everything 搜“P-Media-Authorization”一定搜不到正文这会让人误以为 docx 不能全文检索。实际上 Windows 自带的资源管理器搜索框可以检索 docx 正文前提是相关的数据流建立“文件内容索引”而且搜索框的默认筛选不是“文件名”。要让 Windows 搜到 docx 正文按这两步走。第一步打开控制面板“索引选项”确认“索引位置”里包含你的文档所在目录。很多人的资料放在 D 盘或移动硬盘Windows 默认只索引库和桌面外部目录常常不在索引范围内。第二步进入索引选项的“高级 → 文件类型”在列表里找到 DOCX确保它同时勾选了“属性信息”和“文件内容”两项只勾属性当然搜不到正文。完成后打开控制面板“重新索引”等索引重建完再去搜索。一个细节如果你在资源管理器搜索框输入的是“P-Media-Authorization”默认条件下 Windows Search 会把内容切词后做全文匹配正常情况下能命中。如果系统里 docx 的默认打开程序被 WPS 或第三方工具劫持系统 IFilter 仍指向 Office 组件偶尔会出现“能打开但搜不到”。在控制面板“默认程序”里把 .docx 的打开方式改回 Microsoft Word再重建索引就能解决。下面这条 PowerShell 命令可以直接查询当前 .docx 的关联程序cmd /c assoc .docx如果你看到输出不是“Word.Document.12 或 Word.Document.14”就要考虑关联程序被改了。输出里 12 对应 Office 200714 对应 Office 2010后面 16 对应 Office 2016 以上这不是版本号陷阱只是 COM ProgID 的尾号。3.2 用 Word 的查找和导航窗格做流程跳转索引问题解决后docx 在 Windows 里就像一个可检索的信令数据库。但资源管理器搜索只能看到“命中了哪个文件”定位到文件内部还是得靠 Word 的“导航窗格”和“查找”功能。打开“视图 → 导航窗格”文档左侧会列出带标题样式的小节把光标放进搜索框输入“INVITE”Word 会立刻标出全部同名段落并且按出现位置分组。查找时最好用“区分大小写”配合“在结果中查找”避免把“Invite”和“invite”混在一起。再配合 CtrlG 打开“定位”对话框可以跳到书签。书签在 Word 里默认是隐藏的我建议在关键流程节点比如 INVITE、183、ACK、P-Media-Authorization分别插入书签命名规则用消息名加数字INVITE_1、INVITE_2。这样以后在正文其他位置提到“183 之后的 QoS Flow 建立”只需按住 Ctrl 点击交叉引用就能跳过去不用来回滚动时序图。3.3 把信令流程表格转成自己的参数速查表下面这个是文档类资源最容易出成果的操作把 docx 里的“流程表”改造成“排障速查表”。原始文档往往按照标准流程把消息一行行列出来消息名是“INVITE / 183 / UPDATE”这对熟悉协议的人已经够用但对现网排障不够因为没有异常分支和现场取值。我一般会新建一个 Word 表格列头固定为消息名、关键字段、正常值参考、异常表现、可能原因、排查动作。然后从 docx 原文摘录字段填进去比如“INVITE”这一行关键字段填“Request-Line、Route、Contact、Content-Type”正常值参考填“Request-Line 中以 sip: 开头Route 包含 P-CSCF 地址”异常表现填“Route 缺少第一个节点注册发现失败”排查动作填“在 P-CSCF 前抓包核对 SIP Route 是否经 SBC”。这张速查表做好之后处理现场问题的效率会高很多。转成 PDF 存在手机里也可以但我的习惯是保留 docx 原版因为要改错时直接改表格里的字段名称比改 PDF 方便。唯一注意不要在原始文档上直接改特别是你手里这份是拿来当基线用的标准流程时用“另存为”加后缀“_with_local_notes”保留干净原件。这会减少很多“文档被改成什么样已经记不清”的后悔。4. 从文档到现场按 VoNR 信令流程手工梳理一次完整 INVITE4.1 从 UE 发起 INVITE 到网络返回 183逐行看字段文档中间最核心的部分一般是一整页的呼叫建立流程UE、gNB、AMF、SMF、PCF、P-CSCF 之间画了十几条带序号的消息。这里不要被图吓到从 UE 的视角拆成四步就够了。第一步UE 在注册阶段已经建立好 IMS PDU 会话这个会话的默认 QoS Flow 通常是 5QI5用于传输 SIP 信令。第二步用户拨号后 UE 构造 SIP INVITE消息里带 SDP offer描述了主叫侧的音频编码、RTP 端口和 IP 地址INVITE 由 PDU 会话发给网络侧第一个 SIP 实体就是 P-CSCF/SBC。第三步P-CSCF 向 IMS 核心网转发 INVITE核心网完成用户和业务鉴权然后向被叫侧发送被叫返回 183 Session Progress 后主叫侧才进入媒体资源协商阶段。第四步网络在合适时机下发 PDU 会话修改命令把语音媒体的专用 QoS Flow 建起来通常 5QI1、QFI 由 SMF 分配此时端到端语音承载才真正就绪。用这份文档做排查时我建议在 INVITE 和 183 两条消息上各建立一个“必看字段清单”。INVITE 上重点看 Request-Line 里的 Request-URI 是不是完整的 sip: 地址Route 头是否携带 P-CSCF 地址Contact 头是否有 UE 的 IPContent-Type 必须是 “application/sdp”Content-Length 与实际正文长度一致。SDP 里看 maudio 一行、c 行的 RTP IP、artpmap 的编码以及 aptime 是否合理。很多 VoNR 呼叫建立失败不是 5G 侧不通而是 SDP 里带的媒体地址是 IPv6网络侧没配好 IPv6 路由导致后续媒体不通。183 消息需要额外关注两个头P-Media-Authorization 和 Session-Expires。P-Media-Authorization 是网络下发的授权令牌后续所有重协商消息都要带它文档里会强调这一点。Session-Expires 常用于会话保活如果文档里写 1800 秒但现网配了 600 秒实际呼叫频繁被挂断就要怀疑是这里不一致。这些具体值不会每个都写在正文里有的藏在表格“定时器参数”页排查时用 Word 查找输入“Session-Expires”再把所有出现位置对比一遍。4.2 把文档里的流程节点转成 Wireshark 过滤条件文档是静态的抓包是动态的最难的是把图里的每个箭头翻译成 Wireshark 显示过滤器。我拿到文档后会把每一类消息与抓包会话对应起来SIP 信令走标准 5060/5061 端口用 sip 协议过滤5G 核心网 N11 接口跑 HTTP/2需要在抓包里看 http2NAS 消息在无线侧抓包要看 nas-5gs 协议。建立一个过滤器清单从会话里快速锚定流程阶段消息类型常用过滤器说明SIP INVITEsip sip.Method INVITE找到会话起点183 响应sip sip.Status-Code 183看响应与 SDP answerP-Media 授权sip frame contains P-Media-Authorization定位授权令牌下发点PDU 会话修改nas-5gs frame contains PDU Session Modification Command定位专用 QoS Flow 建立QoS Flow 参数nas-5gs frame contains 5QI配合 Display Filter 进一步过滤sip sip.Method INVITE sip sip.Status-Code 183 sip frame contains P-Media-Authorization这些过滤器先把流量收敛到语音会话再按帧内容定位授权令牌。注意如果抓包点不在 SIP 网元上可能只看到 5G 核心网 HTTP/2 和 NGAP看不到 SIP此时需要用 NGAP 消息里的 QoS Flow ID 与 SIP 的 Call-ID 做时间轴关联。文档里的“方向箭头”不会直接告诉你抓包点在哪个接口你要做的就是把文档中“183 - 专用 QoS Flow 建立”这个顺序在抓包里按时间戳手动对齐一遍能对齐说明现网实现和文档一致对不齐就该查网络侧配置了。5. 避坑VoNR 信令流程 docx 使用中的五个常见问题与排查5.1 现象双击打开提示“文件损坏无法打开”现象从聊天工具或网盘拿到的《VoNR信令流程.docx》双击后 Word 弹出“文件已损坏无法打开”文件大小看起来却有几 MB。原因docx 本质是 zip 包网上传输时被浏览器或聊天工具改了扩展名比如把 zip 改成 docx也可能是杀毒软件在检查时破坏了文件内部结构或者文件本来就不完整传输中断导致 zip 尾部缺失。解决先把文件复制一份改后缀为 .zip用 7-Zip 打开看内部结构。能看到 “word/document.xml” 说明 zip 核心没坏只是 Word 的打开方式被误导此时用 Word 的“文件→打开→选择文件→打开下拉框→打开并修复”最省事。如果解压直接报错说明文件真的损坏只能重新取源文件。从那以后我收到 docx 的第一步永远是先复制副本再改后缀检查不死磕原文件双击这能省下大量时间。5.2 现象Windows 搜索只能搜到文件名搜不到正文现象在 Windows 资源管理器搜索框里搜“QoS Flow”结果里只有《VoNR信令流程.docx》这项但我想定位正文里“QoS Flow”出现的位置双击进去 CtrlF 却明明能搜到。原因Windows Search 可能没有对这个目录建立“文件内容索引”或者 .docx 关联程序被 WPS 改过导致系统 IFilter 失效。你用的是 Everything 这类文件名搜索工具时也只会搜文件名不搜正文两者机制不同。解决去控制面板“索引选项”检查目录是否在索引范围内再进“高级→文件类型”确认 DOCX 勾选了“文件内容”。如果目录在网络共享盘上Windows 默认不索引网络驱动器把文件夹同步到本地再搜。关联程序问题按 3.1 里的方法改回 Word 后重建索引。注意搜正文时不要在 Everything 里找要用资源管理器自己的搜索框。5.3 现象文档流程方向与现网拓扑对不上拿图直接排障被带偏现象文档里画的是 INVITE 从 P-CSCF 直接到 S-CSCF现场信令跟踪却看到两段 P-CSCF IP中间多了一个 SBC 池怎么也对不上文档的箭头。原因原文档是标准架构现网 SBC 即承担 P-CSCF 功能又做了拓扑隐藏对外显示地址和内部转发地址不同。文档只画标准流程不会把每个厂商的组网细节都画出来不等于文档错。解决用第 2 章做的“网元对照表”把文档里的 P-CSCF 节点配置成现网 SBC 池先确认“顺序”能对上再去纠结“地址”对不对。标准文档的价值是流程顺序和字段取值不是每个点的 IP。我在现网排查时会把文档打印成 A4 夹在手边每一步只对“流程顺序”不对“网元进程号”这样效率高很多。5.4 现象在 Wireshark 里按文档找 Cause Code找不到对应位置现象文档的 Cause Code 对照表里写了一个数字比如 403 或 5001在 Wireshark 里用搜索功能找这个数字要么搜到一大堆无关包要么干脆搜不到。原因Cause Code 是有作用域的。SIP 的 403 在 SIP 状态行里Diameter 的 5001 在 Result-Code 字段里NAS 的 cause 在 nas-5gs 层的 message 里。三个字段名称不同直接搜裸数字会命中 IP 分片、TCP 端口等无关内容。解决先用显示过滤器限定协议层再搜字段。比如 SIP 只搜sip.Status-Code 403Diameter 搜diameter.Result_Code 5001NAS 搜nas-5gs里的 cause 字段。不要用frame contains 403这种笨办法。文档里的 Cause Code 表一般会写明协议层看表格标题旁边的小字别只看数字列。5.5 现象转 PDF 后表格错位时序图变成空白或糊成一团现象用 Word 另存为 PDF或通过 WPS 转 PDF 后原本对齐的表格整列跑到页边距外几张信令时序图里的箭头和文字也变成黑块。原因Word 表格默认固定列宽PDF 页面宽度不够时不会自动压缩列宽文档里的图如果是嵌入型 Visio 或 PPT 对象Word 能显示但 PDF 导出用打印渲染会丢失部分矢量信息。解决转 PDF 前先全选表格切到“表格工具→布局→自动调整→根据窗口调整表格”把列宽改成可伸缩百分比。图片段落全部改成“嵌入型”对齐。用 Office 自带的“文件→另存为→PDF”别用第三方打印机驱动。导出后必须翻一遍前几页确认不能直接发出去尤其是信令时序图多的章节。6. 进阶把 VoNR 信令流程文档变成可检索的知识库6.1 用书签和交叉引用把“流程正文”和“排障记录”串起来当你已经在文档里插入过 INVITE_1、183_1 这类书签下一步就是让文档真正可跳转。在排障记录表里凡是提到某条消息就把消息名选中插入“交叉引用→书签”引用类型选“书签文本”这样后面 Ctrl单击 就能跳到对应流程段落。同一个书签可以重复引用比如在 Cause Code 映射表里每个原因都指向相同 INVITE 书签。这个动作看起来小但长期维护价值很大文档不再是线性 PDF而是一张流程网。我一般在每个网络更新后花十几分钟补一次书签成本很低。6.2 用修订模式维护现网差异而不是直接改写流程文档作为单源基线一定要保留一份永远不改的“clean 版”。现网差异全部通过“修订”和“批注”记录在副本里。在 Word 里切到“审阅→修订”然后修改网元名或加批注系统会留下痕迹避免误把临时配置当成标准。每隔两个版本我接受所有修订另存为带日期后缀的版本。这样下载包里那份原始文档不会因为多次编辑变得面目全非也方便回溯哪个字段在哪个版本被改成什么样都能查。从那以后我每次拿到厂商更新的信令流程 docx都强制走一遍“解压检查副本→重建索引→加书签→修订差批注→转 PDF 核对”这条流水线五步下来没再因为文档翻车。希望帮到你。本文还有配套的精品资源点击获取
