51学通信

深度解析 3GPP TS 23.503：附录 B, C, D - 兼容、变现与演进的现实考量

20分钟阅读

非常好，我们已经完成了对3GPP TS 23.503规范主体功能部分的全面解读。现在，我们将进入附录部分，这些章节虽然不是核心流程，但却揭示了PCC框架在现实世界中面临的重大课题：如何与庞大的存量系统共存、如何支撑关键的商业模式，以及如何在网络演进的浪潮中平滑过渡。

深度解析 3GPP TS 23.503：附录 B, C, D - 兼容、变现与演进的现实考量

本文技术原理深度参考了3GPP TS 23.503 V18.9.0 (2025-03) Release 18规范，将合并解读附录B“Deployment option to support of BSF and DRA coexistence”、附录C“Support for Application Functions supporting Rx interface”以及附录D“PCC usage for sponsored data connectivity”的核心内容。本文旨在剖析PCC框架在实际部署中必须解决的三大现实问题：如何兼容4G时代的Rx接口以支撑IMS等核心业务、如何实现赞助数据（定向免流）这一关键商业模式的计费上报，以及在网络从4G向5G演进过程中如何实现策略路由的平滑过渡。

在前几篇文章中，我们已经建立了一个近乎完美的PCC理论模型。然而，现实世界的网络远比模型复杂。运营商投入巨资建设的4G核心网和IMS系统不会在一夜之间消失；“定向免流”等深入人心的商业模式需要有坚实的技术实现；网络演进本身也是一个漫长而循序渐进的过程。

PCC框架能否经受住这些现实的考验？本篇将通过解读规范的三个关键附录，为你揭示PCC框架的“实战智慧”。

为了串联起这些看似独立的主题，我们引入一位新主角——Mark，一位跨国公司“Global Connect Corp”的高管。他正在一次重要的海外商务差旅中，而他的公司为他配备了顶级的全球5G商务套餐。这次差旅中，他将面临：

  1. 一次跨国VoNR高清视频会议：这需要与运营商传统的IMS系统进行交互。
  2. 下载一份大型商业计划书：流量由公司统一付费（赞助数据）。
  3. 他所在的运营商，正处于4G到5G的混合演进阶段。

让我们跟随Mark的脚步，看看PCC框架是如何在幕后，巧妙地解决兼容、变现与演进这三大难题的。

1. 握手过去：兼容4G时代的Rx接口 (Annex C - Normative)

5G虽新，但它无法脱离一个重要的现实：像IMS（IP多媒体子系统）这样承载着VoLTE/VoNR语音和视频通话的核心业务系统，是基于4G架构设计的，其与策略系统（PCRF）的沟通语言是Rx接口（基于Diameter协议）。为了保证这些关键业务在5G网络中的连续性，5G的PCF必须学会说“旧语言”。

[Annex C] To allow the 5G system to interwork with AFs related to existing services, e.g. IMS based services… the PCF shall support the corresponding IMS procedures defined in the main body of this TS via Rx interface. This facilitates the migration from EPC to 5GC without requiring these AFs to upgrade to support the Npcf_PolicyAuthorization services in Rel-16.

深度解析：PCF的“翻译官”角色

附录C是规范性（Normative）的，这意味着如果一个5G网络声称支持与传统IMS的互通，其PCF就必须实现这里定义的功能。PCF在这里扮演了一个**协议转换网关（IWF - Interworking Function）**的角色。

场景再现：Mark的跨国VoNR通话

  1. AF发起“旧时代”的请求：Mark发起VoNR通话。他手机上的IMS客户端通过SIP信令与IMS核心网的P-CSCF（代理呼叫会话控制功能）建立连接。P-CSCF作为本次通话的AF，需要为语音媒体流申请专用的QoS保障。由于它是一个“传统”AF，它并不知道5G的Npcf服务，而是熟练地构建了一条基于Diameter协议的AAR（AA-Request）消息，通过Rx接口发送出去。

  2. PCF的“同声传译”：这条AAR消息被路由到5G的PCF。PCF收到后，立即启动“翻译模式”：

    • 它解析AAR消息中携带的各种AVP（Attribute-Value Pair，属性值对）。
    • 它将Rx AVP中的Media-Component-Description（媒体组件描述），“翻译”成5G PCC规则中的SDF Template（业务数据流模板）和QoS参数。例如，AVP中描述的AMR语音编码和带宽需求，被PCF映射为一个5QI=1（IMS语音）的PCC规则。
    • 它将AVP中的用户IP地址，用于执行会话绑定（Session Binding），找到Mark当前正在使用的PDU会話。

  3. PCF下发“新时代”的指令：完成翻译后，PCF生成一条标准的5G动态PCC规则，通过N7接口（Npcf服务）下发给SMF。后续的流程就与我们之前学习的完全一致：SMF进行QoS流绑定，与RAN协商无线承载，配置UPF。

  4. PCF回传“旧时代”的响应：当SMF执行成功后，PCF会构建一条Diameter的**AAA（AA-Answer）**消息，通过Rx接口回复给P-CSCF，告知其QoS申请已成功。

通过这种方式，PCF像一位精通双语的翻译官，为新旧两个世界架起了沟通的桥梁。IMS系统感觉自己仍在与熟悉的PCRF对话，而5G核心网则完全在按自己的新流程运作。

规范中的Table C-1还定义了事件上报的翻译。例如，当5G网络中发生“Change of Access Type”（接入类型变更）事件时，PCF能将其翻译成Rx接口能够理解的事件通知，上报给P-CSCF。

2. 商业的生命线：赞助数据连接的实现 (Annex D - Informative)

“定向免流”、“企业流量统付”是运营商重要的收入来源和商业模式。附录D（信息性）通过图示和描述，为我们揭示了其背后的技术实现逻辑。

[Annex D.1 General] With sponsored data connectivity, the Sponsor has a business relationship with the operator and the Sponsor reimburses the operator for the user’s data connectivity in order to allow the user access to an associated Application Service Provider’s (ASP) services.

深度解析：两种计费上报模式

当Mark使用公司“Workplace One”应用下载计划书时，这部分流量应由“Global Connect Corp”（Sponsor，赞助商）付费。PCF从AF处获知了这是一个赞助连接请求。那么，SMF/UPF在统计了这部分流量后，如何上报给CHF，才能确保账单记在公司名下，而不是Mark个人头上呢？附录D.2描述了两种部署场景。

场景一：专属计费键 (Service specific Charging Key)

In the first scenario the PCF assigns a service specific Charging Key for a sponsored IP flow. The Charging key is used by the SMF to generate separate accounting records…

  1. PCF分配“专属标签”：PCF在为“Workplace One”应用的流量生成的PCC规则中，分配一个唯一的Charging Key，例如CK_GlobalConnect_WPO。
  2. SMF/UPF按标签统计：SMF指示UPF，为所有匹配这条规则的流量（即所有带有CK_GlobalConnect_WPO标签的流量）进行独立计量。
  3. CHF按标签记账：SMF将带有这个专属Charging Key的用量报告发送给CHF。CHF的计费系统中，这个Charging Key被预先配置为关联到“Global Connect Corp”的公司账户。CHF看到这个标签，就自然地将费用记在了公司账上。

优点：逻辑清晰，隔离度好。缺点：需要为每个赞助服务分配和管理一个唯一的Charging Key，当赞助服务非常多时，管理可能变得复杂。

场景二：携带身份标识 (Sponsor Identifier in PCC Rule)

In a second scenario the Sponsor Identifier and Application Service Provider Identity is included in PCC rules from the PCF to the SMF… the same Charging Key may be used both for IP flows that are sponsored and for flows that are not sponsored.

  1. PCF附加“身份证明”：PCF在PCC规则中，可能使用一个通用的Charging Key（例如，CK_MobileData），但同时会在这条规则里额外加入两个关键字段：Sponsor Identifier（“Global Connect Corp”）和Application Service Provider Identifier（“Workplace One Inc.“）。
  2. SMF上报“完整档案”：SMF在向CHF上报用量报告时，不仅上报了Charging Key和用量，还把这两个ID一并上报。
  3. CHF按身份记账：CHF收到这份“完整档案”后，其计费逻辑会进行判断：“虽然Charging Key是通用的，但报告中包含了Sponsor ID，因此这笔费用应该记在‘Global Connect Corp’的账上”。

优点：非常灵活，无需管理大量的专属Charging Key。缺点：要求CHF具备更复杂的计费逻辑，能够解析和处理这些额外的ID。

3. 演进的智慧：BSF与DRA的共存 (Annex B - Informative)

网络演进是一个漫长的过程。在从4G/EPC向5G核心网（5GC）迁移的过程中，必然会存在一个4G策略路由核心（DRA - Diameter Routing Agent）与5G策略查找核心（BSF - Binding Support Function）并存的混合组网阶段。附录B为这种场景提供了一种平滑的解决方案。

[Annex B] During the network migration, DRA and BSF may coexist in operator’s network. The DRA can be a consumer of Nbsf services…

深度解析：DRA的“智能升级”

问题背景：

  • 在纯4G网络，AF（如P-CSCF）发送Rx请求给DRA，DRA负责查找并路由到正确的PCRF。
  • 在纯5G网络，AF发送Npcf请求（或通过NEF），或者通过BSF查找正确的PCF。
  • 混合网络中的问题：一个传统的、只会说Diameter语言的AF（如P-CSCF）仍然配置为将所有Rx请求发送给DRA。但用户Mark已经是一个5G用户，他的策略由PCF管理，他的会话绑定信息存在于BSF中。DRA的“通讯录”里没有这个5G用户的信息，它该怎么办？

解决方案：让DRA学会“问路”BSF

  1. DRA的路由逻辑扩展：运营商对DRA进行配置升级。DRA的路由逻辑中增加一条规则：“当我收到一个Rx请求，如果根据请求中的用户信息（如IP地址段）判断这是一个5G用户，或者我在自己的4G绑定表中找不到该用户，那么我就不直接去查4G的PCRF，而是去向BSF问路。”

  2. DRA扮演“临时客户端”：此时，DRA会扮演一个临时的客户端角色，它向BSF发起一个Nbsf_Management_Discovery服务请求（这是一个标准的5G服务化接口调用），请求中携带了AF原始请求中的用户IP地址。

  3. BSF提供导航：BSF收到DRA的查询后，在自己的绑定表中查找该IP地址，找到了对应的PCF实例地址。

  4. DRA完成最终路由：DRA从BSF处获取到PCF的地址后，就将最初收到的那条Rx Diameter消息，准确地路由到这个5G的PCF上。

核心洞察：这个机制非常巧妙。它没有要求传统的AF进行任何升级（AF仍然只认识DRA），而是通过对DRA进行“智能化”改造，使其能够利用5G的BSF服务，从而将新旧两个时代的策略路由体系“粘合”在了一起。这为运营商提供了一条成本最低、改动最小、业务中断风险最低的网络演进路径。

FAQ

Q1：为什么附录C是“规范性(Normative)”的，而附录B和D是“信息性(Informative)”的？ A1：这取决于它们对标准遵从性的要求。规范性（Normative）附录是标准的一部分，如果设备或网络功能声称支持该特性，就必须按照附录中的规定来实现，否则就不符合标准。附录C定义了与IMS互通的基础，这是VoLTE/VoNR得以在5G延续的关键，因此具有强制性。而信息性（Informative）附录提供了示例、背景信息或推荐的实现方法，它们不具有强制性。运营商可以参考附录B和D的设计思想，也可以采用其他私有的方式来实现类似功能，只要能达到最终目的即可。

Q2：在赞助数据的场景中，AF、Sponsor和ASP之间是什么关系？ A2：它们是商业合作关系链。**ASP（Application Service Provider，应用服务提供商）**是业务的直接提供者，例如“Workplace One”应用的开发公司。**Sponsor（赞助商）**是为流量付费的实体，例如Mark的公司“Global Connect Corp”。AF（Application Function）是ASP部署在网络中或通过NEF接入的、代表其业务与运营商PCC框架交互的技术接口。在很多情况下，ASP和Sponsor是同一个实体（例如，视频网站自己为自己的用户提供免流服务），但规范将它们分开，以支持更灵活的“第三方付费”商业模式。

Q3：PCF支持Rx接口，是否意味着5G完全兼容了4G的PCC架构？ A3：不是完全兼容，而是实现了业务层的互通。PCF支持Rx接口，主要是为了让那些关键的、存量的、基于Rx接口的AF（如IMS P-CSCF）能够继续工作。但这并不意味着5G的核心网元（如SMF）也需要支持4G的Gx/Gy等接口。PCF在这里起到了一个“协议适配器”和“隔离层”的作用，它对外（对AF）说“旧语言”（Diameter/Rx），对内（对SMF/CHF等）则完全使用“新语言”（HTTP/2 / Service-Based Interface）。这使得5G核心网内部可以保持其先进的架构，同时又能平滑地继承4G时代的重要业务。

Q4：在BSF与DRA共存的架构中，如果一个用户同时有4G和5G的会话，DRA会如何处理？ A4：这取决于DRA的路由策略和收到的请求的具体信息。通常，DRA会优先在自己的绑定表中查找。如果AF的Rx请求中包含了可以明确指向4G会话的信息（例如，承载在4G网络上的IP地址），DRA会直接路由到4G的PCRF。如果请求中的信息（如5G分配的IP地址）明确指向5G会话，或者在4G绑定表中查无此人，DRA才会触发向BSF查询的逻辑。运营商会通过精细的IP地址段规划和DRA路由策略配置，来确保请求能够被正确地分发。

Q5：如果一个运营商不打算提供赞助数据服务，他们还需要实现附录D中描述的功能吗？ A5：不需要。附录D是信息性的，它描述的是一种商业模式的技术实现方式。如果运营商的商业策略中不包含赞助数据或定向免流，那么PCF、SMF和CHF就无需实现和配置处理Sponsor Identifier的逻辑。然而，PCC框架的灵活性就在于，它已经预先定义了这些接口和参数，一旦运营商决定开展此类业务，就可以在标准框架内快速实现，而无需进行大规模的架构改造。

关系图谱