VoNR 呼叫 Rx 接口 QoS 授权信令全链拆解

一、为什么 IMS 呼叫需要 Rx/N5 授权

VoNR/VoLTE 的语音承载并不像普通上网流量那样"尽力而为"。一段 EVS 或 AMR-WB 语音媒体一旦建立，必须在 NG-RAN 与 5G 核心网之间获得一条 GBR（Guaranteed Bit Rate）保证比特率的专用 QoS 流——5G 中对应 5QI=1（会话语音，PDB 100ms，PER 1e-2，GBR）。问题是：SIP 信令面只描述"想用什么编解码、多大带宽、哪个 RTP 端口"，并不知道无线侧应该建多少条 QoS 流、用什么 5QI/ARP。SIP 与 5G QoS 之间，需要一个"翻译官"。

这个翻译官就是 Rx 接口（4G 称 Rx，5G 称 N5），它把 P-CSCF（作为 Application Function，AF）从 SDP 中解析出的媒体描述，翻译成 PCF 能够理解的、可被绑定到具体 QoS 流的授权请求。PCF 再通过 N7（Npcf_SMPolicyControl）把 PCC 规则下发给 SMF，SMF 才会触发 NG-RAN 建立/修改专用 QoS 流。

设计意图有三层：

1. 解耦业务面与承载面：IMS 域（SIP/P-CSCF）与移动承载域（SMF/gNB）通过 PCF 这个"策略中枢"间接交互，避免 SIP 协议栈直接耦合到 5G QoS 信令中。
2. 集中式策略控制：运营商可以在 PCF 上统一配置"VoNR 语音最多授权 64kbps、ARP 抢占优先级、是否允许 GBR"等策略，P-CSCF 只负责"汇报媒体需求"，不需要自己决策 QoS。
3. 资源门控（Gating）：PCF 可根据业务状态（如用户欠费、呼叫挂起）通过 Flow-Status 开关媒体流，实现精细的承载管控。

Rx/N5 的完整定义见 3GPP TS 29.214（Policy and charging control over Rx reference point） 与 TS 29.514（Policy Authorization Service，即 SBI 版的 Npcf_PolicyAuthorization），PCC 框架总则见 TS 23.503。

二、Rx（Diameter）与 N5（SBI）的关系

一个常见误区是认为"5G 已经全 SBI 化，Rx 接口被淘汰了"。事实并非如此。Rel-18 中 TS 29.214 依然有效，大量现网 P-CSCF/SBC 仍只支持 Diameter；PCF 则同时提供两副面孔：

多数运营商在 5G 部署初期让 PCF 同时支持 Diameter Rx 与 SBI Npcf_PolicyAuthorization，以兼容既有 P-CSCF（参考 Cisco UCC PCF、Open5GS 的 N5/Rx 双栈实现）。下文以 Diameter Rx 为主线拆解，N5 的语义完全对应。

三、核心信令时序：一次 VoNR 主叫的 Rx 授权

下图以"被叫摘机后确认最终 SDP"的经典 VoNR 主叫为例，聚焦 P-CSCF↔PCF 的 Rx 交互（含 N7 侧联动）：

sequenceDiagram
    autonumber
    participant UE
    participant PCSCF as P-CSCF (AF)
    participant PCF
    participant SMF
    participant UE_RAN as UE/gNB/UPF

    UE->>PCSCF: SIP INVITE (SDP offer, EVS)
    Note over PCSCF: 解析SDP→媒体组件<br/>但尚未拿到Answer
    PCSCF->>PCF: AAR (Service-Info-Status=PRELIMINARY)<br/>含 Media-Component-Description
    PCF->>SMF: N7: 提供PCC规则 (5QI=1, GBR, ARP)<br/>Npcf_SMPolicyControl Update
    SMF->>UE_RAN: N11/N2/N4: 建立专用QoS流(QFI=1)
    PCF-->>PCSCF: AAA (授权成功, 已绑定)
    PCSCF-->>UE: 100 Trying
    Note over UE,PCSCF: ... 183/PRACK/UPDATE 协商编解码 ...
    UE->>PCSCF: 200 OK (SDP answer, 最终编解码=AMR-WB)
    PCSCF->>PCF: AAR (Service-Info-Status=FINAL)<br/>确认最终媒体参数
    PCF->>SMF: N7: 更新PCC规则(MBR/GBR)
    PCF-->>PCSCF: AAA
    PCSCF-->>UE: ACK
    Note over UE,UE_RAN: 通话进行中...;挂起/恢复→再发AAR
    UE->>PCSCF: SIP BYE
    PCSCF->>PCF: STR (Session-Termination-Request)
    PCF->>SMF: N7: 删除PCC规则,释放GBR QoS流
    PCF-->>PCSCF: STA

关键看点：一次呼叫通常产生 2~3 次 AAR。第一次在收到 SDP offer 时（PRELIMINARY，做"预授权"并触发专用 QoS 流建立），第二次在收到 200 OK 携带最终 SDP answer 时（FINAL，把 GBR/MBR 收敛到实际协商值），呼叫中途挂起/恢复或编解码切换时还会有修改型 AAR。这是排错时最容易判错的点——"为什么我的呼叫开了好几个 AAR"。

四、AAR 关键 AVP 逐项解析

AAR（AA-Request，Diameter 命令码 265）的核心是一个嵌套的 AVP 树。最外层是会话级 AVP，内层通过 Media-Component-Description（分组型）描述每一个媒体流（音频、视频、消息等）。其结构见下图：

flowchart TD
    A[AAR 会话级 AVP] --> B1[Subscription-Id<br/>IMSI / MSISDN]
    A --> B2[AF-Application-Identifier<br/>如 'IMS']
    A --> B3[Service-Info-Status<br/>0=FINAL / 1=PRELIMINARY]
    A --> B4[Specific-Action<br/>订阅承载丢失/恢复事件]
    A --> B5[SIP-Forking-Indication<br/>单/多分支]
    A --> B6[Called-Station-Id]
    A --> MC[Media-Component-Description ★分组]
    MC --> C1[Media-Component-Number]
    MC --> C2[Media-Type<br/>AUDIO/VIDEO...]
    MC --> C3[Max-Requested-BW-UL/DL]
    MC --> C4[AF-Application-Identifier]
    MC --> C5[Flow-Status<br/>ENABLED/DISABLED]
    MC --> C6[Media-Sub-Component ★分组]
    C6 --> D1[Flow-Number]
    C6 --> D2[Flow-Description<br/>5元组过滤规则]
    C6 --> D3[Codec-Data]
    C6 --> D4[Flow-Usage<br/>RTP/RTCP]
    style MC fill:#e8f5e9
    style C6 fill:#fff3e0

下表对照说明每个关键 AVP 的取值与作用（依据 TS 29.214 第 5 章）：

设计精妙处：Flow-Description 把"哪条 IP 五元组流属于这个媒体"明确告诉 PCF，PCF 据此生成 SDF（Service Data Flow）过滤器绑定到具体 QoS Flow。这就是为什么 gNB 上只对 RTP 流量保证 GBR、而对 SIP 信令（走默认 QoS 流 5QI=5）不保证——两者过滤器不同，绑定到不同 QFI。

五、从 SDP 到 QoS 流：授权绑定链路

把 SDP 翻译成 5G QoS 流是一条贯穿多协议的"绑定链路"：

flowchart TD
    S1["SDP<br/>m=audio 5004 RTP<br/>a=rtpmap EVS"] --> S2["P-CSCF 解析"]
    S2 --> S3["AAR: Media-Component +<br/>Flow-Description(permit ...:5004)"]
    S3 --> S4["PCF 授权: 5QI=1, GBR, ARP<br/>生成PCC规则 + QoS规则"]
    S4 --> S5["N7→SMF: 安装QoS规则<br/>绑定QFI=1"]
    S5 --> S6["SMF→gNB: PDU Session<br/>Resource Setup (QFI=1)"]
    S6 --> S7["专用GBR QoS流建立<br/>仅RTP流量享受保证"]

这条链路的"粘合剂"是 Flow-Description 生成的 SDF 过滤器。当 RTP 包到达 UPF 时，UPF 根据 N4 规则匹配到该过滤器，将其映射到 QFI=1 的专用 QoS 流，享受 GBR；而非 RTP 流量则落到默认 QoS 流。这种"按应用层五元组精细化绑定"正是 PCC 架构的灵魂，定义见 TS 23.503 第 6 章（Binding Mechanism） 与 TS 29.512（Npcf_SMPolicyControl）。

六、Service-Info-Status 与早期/延迟 Offer 的交互

Service-Info-Status 是 Rx 授权最容易踩坑的 AVP。它取决于 IMS 采用早期 Offer（Early Offer）还是延迟 Offer（Delayed Offer）模型：

• 早期 Offer：UE 在 INVITE 中已给出完整 SDP offer（编解码、端口齐备）。P-CSCF 此时拿到的是 offer，但还没有 answer（对端选哪个编解码未定），所以第一次发 AAR 时置 PRELIMINARY，让 PCF 做"预授权"并先把专用 QoS 流建起来（按 offer 中的最大带宽）。等收到 200 OK 的 answer 后，再发 FINAL 的 AAR 收敛参数。
• 延迟 Offer：UE 的 INVITE 不带完整 SDP，等对端 183 才给 answer。P-CSCF 必须等拿到 answer 才能发 AAR，此时往往直接 FINAL。

为什么需要 PRELIMINARY：移动承载建立耗时（gNB 调度、空口资源），如果等 SDP answer 完整协商完再建承载，会显著拉长呼叫建立时延。运营商普遍偏好早期 Offer + PRELIMINARY 预授权，以预建承载、降低接通时延。Cisco PCF 的实现即明确：AAR message having Service-Info-Status AVP set to PRELIMINARY 时仅做媒体组件级授权，不最终提交（参考 Cisco UCC PCF 配置指南）。

七、Rx 会话生命周期状态机

整个 Rx 会话的状态流转如下（对应 AAA/STR/RAR/ASR 的触发点）：

stateDiagram-v2
    [*] --> 无会话: P-CSCF 收到 INVITE 前
    无会话 --> 预授权: AAR(PRELIMINARY) / AAA成功
    预授权 --> 已授权: AAR(FINAL) / AAA成功<br/>专用QoS流已建
    已授权 --> 修改中: AAR(挂起/恢复/编解码切换)
    修改中 --> 已授权: AAA成功
    已授权 --> 承载告警: PCF发RAR/ASR<br/>(承载丢失)
    承载告警 --> 已授权: 承载恢复(RAR)
    承载告警 --> 终止: SIP BYE→STR
    已授权 --> 终止: SIP BYE→STR/STA
    终止 --> [*]: 释放GBR QoS流

注意 PCF 也能主动发起消息（不是只有 P-CSCF→PCF 单向）： - RAR/RAA（Re-Auth，258）：PCF 触发 P-CSCF 重新授权，常用于策略变更或承载恢复通知。 - ASR/ASA（Abort-Session，274）：当承载不可恢复（如无线丢失、QoS 流被抢占释放），PCF 主动要求 P-CSCF 终止会话，P-CSCF 进而释放 SIP 对话。这是"承载丢失→呼叫掉话"的控制通路，与 P-CSCF 在 AAR 中订阅的 INDICATION_OF_LOSS_OF_BEARER/RECOVERY_OF_BEARER 配套。

八、挂起/恢复、分叉与 RTCP 的处理细节

挂起/恢复（Hold/Resume）：用户按静音/保持，UE 发 re-INVITE 或 UPDATE，SDP 中 a=sendonly/a=sendrecv 变化，方向变了但媒体流五元组通常不变。P-CSCF 检测到方向变化，发修改型 AAR，PCF 据此调整门控（如把下行 Flow-Status 改为 DISABLED），但 GBR QoS 流不释放，保证恢复时无重建时延。

SIP 分叉（Forking）：一次 INVITE 被分叉到多个分支，可能同时振铃。SIP-Forking-Indication=SEVERAL_DIALOGS 告诉 PCF 存在多个媒体分支，PCF 需要为每个分支分别绑定资源并在最终选定分支后释放其余分支的授权，避免资源泄漏。

RTCP：媒体子组件中通常包含两条流——RTP（Flow-Usage=RTP，承载语音）和 RTCP（Flow-Usage=RTCP，承载控制反馈）。启用 RTP/RTCP 复用（RFC 5761）时，端口相同，仅一条 Flow-Description；否则需要两条过滤规则。这是抓包时常见的"一个媒体组件却绑定了两个 Flow-Number"的原因。

九、实战：抓包识别与故障定位

1. 抓包识别要点：在 P-CSCF 与 PCF 之间抓包（Diameter 走 TCP 3868 或 SCTP 3868），过滤 diameter.cmd.code == 265（AAR/AAA）。一个正常 VoNR 主叫应在 INVITE 后数毫秒内看到第一条 AAR，且 Result-Code=2001（DIAMETER_SUCCESS）。若 5G 纯 SBI 部署，则过滤 HTTP/2 :path 含 /npcf-policyauthorization/v1/app-sessions。

2. 常见故障与排错思路：

• Cisco PCF：明确支持 Service-Info-Status=PRELIMINARY 的媒体组件级授权，且对 Diameter Rx 与 SBI N5 双栈（参考 Cisco UCC 5G PCF 配置指南 Rel 2025.01）。
• 华为/中兴 PCF：通常对 VoNR 业务预置 5QI=1 的 PCC 模板，AAR 的 AF-Application-Identifier 命中即下发，但 ARP/抢占策略需在策略矩阵中显式配置。
• 开源 Open5GS：PCF 支持 N5（SBI Npcf_PolicyAuthorization），社区有 VoNR over N5 的 QoS Flow（5QI=1/5）实践与若干 issue（如 IP Flow Filter 方向问题），适合学习与原型验证。
• P-CSCF/SBC 侧（如 Ribbon、Oracle SBC、Kamailio ims_qos 模块）：决定何时发 PRELIMINARY、如何从 SDP 填充 Flow-Description，各家对延迟 Offer 的兼容处理细节不同，是现网互通问题的高发区。

十、设计反思：为什么是"AF→PCF→SMF"三段而不是直连

回头看整个机制，一个值得深思的设计是：为什么不让 P-CSCF 直接告诉 SMF 建承载？ 答案在于"策略的归策略、会话的归会话"。P-CSCF 只懂业务（这个媒体值多少带宽），不懂用户的套餐、欠费、漫游地策略；SMF 只懂承载（建 QoS 流），不懂业务语义。PCF 居中，把"业务需求 + 签约策略 + 网络状态"三者融合，输出统一的 PCC 规则。这种分层使 VoNR、VoLTE、URLLC、IMS 视频乃至第三方 AF 业务（如游戏、直播低时延）都能复用同一套 QoS 授权框架，是 5G PCC 架构得以横向扩展的根本。

代价是多一跳、多一点时延与故障域——AAR→N7→N2 的任何一环失败都会影响呼叫。理解这条链路的每一跳，是定位"为什么我的 VoNR 呼叫建不起来"的关键。

常见问题

Q1：Rx 和 N5 是同一个接口吗？为什么现网两个名字都在用？ A：语义上是同一个参考点（AF↔PCF）。Rx 是 4G/5G 通用名（TS 29.214，Diameter），N5 是 5G SBA 命名（TS 29.514，HTTP/2 SBI Npcf_PolicyAuthorization）。现网为兼容老 P-CSCF，PCF 常同时支持 Diameter Rx 与 SBI N5，二者消息族一一对应。

Q2：一次 VoNR 呼叫为什么有多个 AAR？是不是异常？ A：通常正常。主叫一般在 INVITE（SDP offer）时发 PRELIMINARY 的 AAR 预授权并预建专用 QoS 流，在 200 OK（最终 SDP answer）时发 FINAL 的 AAR 收敛 GBR/MBR；中途挂起/恢复/编解码切换还会触发修改型 AAR。只有当 AAA 一直不成功或反复重发才需排查。

Q3：语音媒体为什么是 5QI=1，SIP 信令却是 5QI=5？ A：5QI=1 是会话语音 GBR QoS（PDB 100ms、保证比特率），由 Rx/N5 授权并通过 N7 安装的 PCC 规则绑定到专用 QoS 流；SIP 信令不需要 GBR，走默认 QoS 流 5QI=5（信令交互，非 GBR）。两者通过 Flow-Description 的 SDF 过滤器分流到不同 QFI。

Q4：Service-Info-Status 设成 PRELIMINARY 和 FINAL，对承载有什么实际区别？ A：PRELIMINARY（值 1）表示 SDP 尚未最终确定，PCF 仅做媒体组件级预授权、可先触发承载建立以降低时延，但通常不最终确认计费/资源提交；FINAL（值 0）表示 SDP 完备，PCF 据此最终确定 PCC 规则、收敛带宽并确认资源提交。早期 Offer 模型下二者配合使用。

Q5：通话中突然掉话，怎么看是不是 Rx 侧的问题？ A：先看是否出现 ASR（Abort-Session，274）——若 PCF 主动向 P-CSCF 发 ASR，说明承载不可恢复（无线丢失/QoS 流被抢占），P-CSCF 据此释放 SIP 对话导致掉话。此时需进一步排查空口 RF 质量、ARP 抢占策略、gNB 资源；若没有 ASR，则掉话可能源于 SIP/BYE 或无线链路失败，与 Rx 关系不大。

参考来源

1. 3GPP TS 29.214 — Policy and charging control over Rx reference point — Rx 接口 Diameter 协议、AAR/AAA/RAR/STR 命令与 AVP 定义（第 5 章）
2. 3GPP TS 29.514 — Policy Authorization Service (Npcf_PolicyAuthorization) — 5G SBI 版 N5 接口定义
3. ShareTechnote — 5G VoNR — VoNR 中两个数据流映射到专用 QoS 流的呼叫流程图解
4. Cisco UCC 5G PCF Configuration Guide — Rx Authorization — PCF 对 Service-Info-Status=PRELIMINARY 的媒体组件级授权实现
5. iTecSpec — TS 29.214 Section 5 (Rx protocol) — Rx 协议支持、初始化与 AVP 详解
6. Kamailio — The IMS QoS Module — P-CSCF 如何从 SDP 填充 Flow-Description AVP 的开源实现参考
7. DeepWiki — N5 and Rx Policy Interfaces (Open5GS) — 开源 PCF 的 N5/Rx 双栈实现与 VoNR QoS（5QI=1/5）实践

本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。

[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。