好的，我们继续5G计费规范的深度解读之旅。
在上一篇文章中，我们已经像语言学家一样，详细剖析了构成5G计费“语言”的核心词汇——Charging Data Request/Response消息和CDR中的关键信息元素。现在，我们将进入一个更为专注和精细的领域，聚焦于那些为了支持特定5G能力而设计的、更为专业的“术语”和“语法”。
本文将作为对第6章数据定义的收官之作，重点解读6.2节。我们将深入探讨PDU会话、PDU容器、漫游QBC以及跨CHF交互等高级场景下的专属数据结构，揭示5G计费是如何通过这些精巧的数据“模块”，来实现对复杂场景的灵活描述和精确计费的。
深度解析 3GPP TS 32.255：6.2 5G数据连接计费的特定参数 (Specific Parameters)
本文技术原理深度参考了3GPP TS 32.255 V18.6.0 (2024-12) Release 18规范中，关于“6.2 5G data connectivity charging specific parameters”的核心章节，旨在为读者深入解析5G计费中用于描述PDU会话、漫游QBC和跨CHF交互等高级场景的特定数据结构及其含义。
引言：从“通用语”到“专业术语”
如果说6.1节定义了5G计费的“通用语”，那么6.2节则为我们呈现了一系列“专业术语”。这些术语以“信息体”（Information Element, IE）的形式存在，它们就像一个个标准化的“数据模块”或“集装箱”，专门用于封装和传递特定场景下的计费上下文。当SMF需要向CHF描述一个复杂的场景时，它不再需要零散地汇报，而是直接将相关信息打包进一个对应的“集装箱”里，大大提升了通信的效率和准确性。
我们将扮演一位资深的计费系统架构师，审视这些精心设计的“集装箱”，理解它们的设计哲学和应用场景。
1. 计费的“户口本”：PDU会话计费信息 (6.2.1.2)
这是所有计费信息中最重要的“根容器”之一，它定义了一个PDU会话的所有静态和半静态属性，可以被视为这次计费服务的“户口本”。规范中的**“Table 6.2.1.2.1: Structure of PDU Session Charging Information”**详细列出了其内容。
我们将其核心字段划分为几个维度来解读：
1.1 核心身份标识 (Core Identities)
| Information Element | Category | Description & Architectural Insight |
|---|---|---|
| Charging Id | OM | PDU会话的计费唯一标识。 |
| Home Provided Charging Id | OC | 在HR漫游场景下，由H-SMF生成并下发给V-SMF使用的计费ID。V-SMF在后续与V-CHF的交互中，会用这个ID来代替自己生成的ID，从而保证VPLMN和HPLMN两侧的CDR能够通过同一个ID进行关联。 |
| PDU Session ID | M | 网络层面的PDU会话ID，是技术上的锚点。 |
| User Identifier / User Equipment Info | OC | 用户的GPSI/SUPI以及终端的PEI/MAC地址。在紧急会话等身份无法认证的场景，PEI是唯一的身份线索。 |
架构师视角：这些ID的设计体现了计费与网络会话管理、用户身份管理的紧密耦合。特别是Home Provided Charging Id的设计，巧妙地解决了跨运营商场景下计费数据关联的难题。
1.2 网络上下文 (Network Context)
| Information Element | Category | Description & Architectural Insight |
|---|---|---|
| S-NSSAI / HPLMN S-NSSAI | M/OM | 会话所属的网络切片标识（服务方网络/归属方网络）。这是实现网络切片计费的核心字段。CHF可以根据S-NSSAI将费用归属到不同的企业租户或业务线上。 |
| DNN Selection Mode | M | 数据网络名称（DNN），标识了用户要访问的目标网络（如互联网、企业内网、IMS网络等）。 |
| Serving Network Function Information | M | 服务网络功能信息，包含了提供服务的核心网元（如AMF、I-SMF）的详细标识。这是网络拓扑透明化的体现，为精细化的成本核算和故障定位提供了依据。 |
| RAT Type / MA PDU Non 3GPP RAT Type | OC | 接入技术类型。在多接入（MA-PDU）场景下，会分别记录3GPP和非3GPP接入的RAT类型，是实现按接入方式差异化计费的基础。 |
架构师视角：这些字段将PDU会话牢牢地锚定在5G的网络资源（切片、DNN）和拓扑结构（服务网元、接入技术）中。计费系统不再是简单地看流量，而是能看到流量“从哪里来，到哪里去，走了哪条路”。
1.3 业务与QoS信息 (Service & QoS Context)
| Information Element | Category | Description & Architectural Insight |
|---|---|---|
| SSC Mode | OC | 会话与业务连续性模式。CHF需要知道SSC模式，以便正确地理解和处理因锚点切换而产生的（可能中断或重叠的）计FF费会话。 |
| Authorized/Subscribed QoS Information | OC | 授权/签约的QoS信息。记录了PCF为该会话批准的QoS参数（如5QI, ARP, GFBR/MFBR），这是实现按服务质量计费（QoS-based charging）的直接依据。 |
| Charging Characteristics | OC | 计费特征。从UDM获取的用户签约属性，指导了CHF选择初始的计费策略（如默认离线、默认高优先级等）。 |
架构师视角：这些字段将计费与用户体验和业务承诺直接挂钩。计费系统能够知晓为这次服务承诺了何种等级的QoS和连续性保障，从而为“按价值付费”的商业模式提供了数据基础。
2. 计费的“事件快照”：PDU容器信息 (6.2.1.3)
如果说PDU会话计费信息是“户口本”，那么PDU容器信息（PDU Container Information）就是记录在案的每一次“事件快照”。它作为Used Unit Container的一部分，描述了某一段具体用量产生时的动态上下文。
规范中的**“Table 6.2.1.3.1: Structure of PDU Container Information”**列出了其构成。
| Information Element | Category | Description & Architectural Insight |
|---|---|---|
| Time of First/Last Usage | OC | 该段用量的首/末数据包的时间戳。为计费提供了精确到毫秒级的时间锚点。 |
| QoS Information | OC | 在这段用量期间，实际生效的QoS参数。与“户口本”里的签约QoS不同，这里记录的是动态变化中的实际QoS。 |
| User Location Information | OC | 在这段用量期间，用户所处的地理位置。 |
| Sponsor Identity | OC | 赞助商标识。如果这段流量是被赞助的，这里会明确标出“金主”是谁。 |
| Traffic Forwarding Way | OC | 流量转发路径。在5G LAN等场景，记录了这次通信是组内本地转发，还是出组访问，是实现按路径差异化计费的关键。 |
架构师视角：PDU容器的设计哲学是**“状态切片”**。每一次计费上报（Update），都会生成这样一个容器，它像一张高精度快照，定格了那段费用产生时的所有动态环境因素。后端的计费分析系统通过拼接这些“快照”，就可以完整还原出用户的整个业务体验旅程。
3. 漫游结算的“专用账本”：漫游QBC信息 (6.2.1.4 & 6.2.1.5)
在HR或LBO漫游场景下，VPLMN和HPLMN之间需要进行批发结算。Roaming QBC Information就是为此设计的专用“数据模块”，它承载了所有与网间结算相关的信息。
3.1 QBC信息顶层结构 (Table 6.2.1.4.1)
| Information Element | Category | Description & Architectural Insight |
|---|---|---|
| Multiple QFI container | OC | 多个QFI容器的列表。这是核心，表明QBC是以QoS流（QFI）为单位进行独立核算的。 |
| Roaming Charging Profile | OC | 漫游计费协议。记录了本次结算所遵循的、由HPLMN最终确认的“记账规则”。 |
| Partial record method | OC | 部分记录方法。指示了V-CHF在生成结算话单时，是采用“追加模式”还是“快照模式”，以匹配双方的系统要求。 |
3.2 QFI容器的内部 (Table 6.2.1.5.1)
Table 6.2.1.5.1: Structure of QFI Container Information
QFI Container是Roaming QBC Information的基本组成单元，它详细记录了某一个特定QoS流的使用情况。
| Information Element | Category | Description & Architectural Insight |
|---|---|---|
| QoS Flow Id | M | QFI，明确了这是为哪个QoS流记的账。 |
| Uplink/Downlink Volume | OC | 该QFI承载的上/下行流量。这是结算费用的直接依据。 |
| EPS bearer Charging Id | OM | 在4G/5G互操作漫游场景下，记录了该5G QoS流映射到的是哪个4G的EPS承载，保证了跨代结算的连续性。 |
架构师视角：漫游QBC信息体的设计，完美体现了“关注点分离”的原则。它将复杂的网间结算逻辑，从通用的PDU会话信息中剥离出来，封装到一个独立的、结构清晰的“专用账本”里。这个账本只关心一件事：VPLMN为HPLMN的每个QoS等级的服务，分别提供了多少容量的“管道”。
4. “跨国密电”：Inter-CHF信息 (6.2.1.6)
在高级的LBO漫游场景下，V-CHF和H-CHF需要直接“对话”。Inter-CHF Information就是它们之间传递的“密电”内容。
Table 6.2.1.6.1: Structure of Inter-CHF Information
| Information Element | Category | Description & Architectural Insight |
|---|---|---|
| Remote CHF resource | OC | 远程CHF资源标识。当V-CHF向H-CHF发起请求后，H-CHF会在响应中返回一个它内部的会话资源标识。V-CHF在后续的Update请求中必须带上这个标识，H-CHF才能快速定位到对应的计费上下文。这就像一个跨系统的“会话Cookie”。 |
| Original NF Consumer Id | OC | 原始请求方标识。当V-CHF代理V-SMF向H-CHF发起请求时，它会带上V-SMF的ID。这使得H-CHF能够知晓这次计费请求的“源头活水”在哪里，对于端到端的信令追踪和故障排查至关重要。 |
架构师视角：这个小而精悍的信息体，解决了跨运营商、跨系统进行有状态会话交互的核心问题。它通过一个“资源标识”和一个“溯源标识”，构建了一条稳固的、可追溯的跨CHF通信链路。
文章结尾
通过对6.2节的深度剖析，我们完成了一次对5G计费数据结构“精装修”级别的审视。我们看到，3GPP的专家们通过一系列精心设计的、模块化的“数据容器”，将不同场景下的计费信息进行了优雅的封装和隔离：
- PDU会话计费信息：定义了会话的“身份”和“静态画像”。
- PDU容器信息：记录了用量产生时的“动态环境快照”。
- 漫游QBC信息：构建了网间结算专用的“批发账本”。
- Inter-CHF信息：建立了跨运营商计费系统“密谈”的通道。
这些特定参数的设计，是5G计费系统能够灵活适应从个人业务到垂直行业、从本地连接到全球漫游等万千场景的根本保障。它们共同构成了5G计费这门精密语言的核心词典，使得全球运营商和服务提供商能够用统一、无歧义的方式，共同描绘和量化数字世界的价值流动。
至此，我们已经完成了对3GPP TS 32.255规范中最为核心的第5章和第6章的全面解读。我们已经掌握了5G计费的原则、架构、流程和数据结构。后续的章节和附录，更多的是对特定场景（如与旧系统互通）的补充和对参数的详细定义，我们已然掌握了理解它们所需的全部核心知识。
FAQ环节
Q1：为什么需要将PDU会话的计费信息（6.2.1.2）拆分成这么多字段，而不是简单地记录总流量？ A1：为了实现差异化和价值计费。简单地记录总流量是“一刀切”的模式，无法区分这1GB流量是来自低价值的网页浏览，还是来自高价值、需要网络切片保障的远程手术指导。通过拆分出S-NSSAI、QoS、DNN、RAT Type等详细字段，计费系统获得了对网络资源消耗的“CT扫描”级别的洞察力，从而能够实现“按切片收费”、“按QoS等级收费”、“按接入位置收费”等灵活的商业模式。
Q2：Home Provided Charging Id这个字段具体解决了什么问题？
A2：它解决了HR漫游场景下，跨运营商CDR关联的难题。在HR漫游中，VPLMN和HPLMN都会为同一次PDU会话生成CDR。如果没有统一的ID，两家运营商的后端系统很难将这两份记录（一份用于结算，一份用于用户账单）准确地关联起来。通过由H-SMF生成一个权威的Home Provided Charging Id并强制V-SMF使用，就保证了无论计费信息走到哪里，都有一个共同的“身份证号”，极大地简化了后续的数据核对与稽核工作。
Q3：我在CDR中看到了Subscribed QoS和Authorized QoS，它们有什么不同？
A3：Subscribed QoS是记录在您用户档案（UDM中）里的签约服务等级，代表了运营商对您的长期承诺，例如“您的套餐最高可享1Gbps速率”。而Authorized QoS是PCF（策略控制功能）在当前PDU会话中，根据实时网络状况和策略，实际批准授予您的服务等级，它可能低于或等于您的签约等级。例如，在网络非常繁忙时，即使您是1Gbps的签约用户，PCF可能也只授权给您100Mbps。在CDR中同时记录两者，有助于运营商进行SLA（服务水平协议）的监控与管理。
Q4：QFI容器（QFI Container）和PDU容器（PDU Container）是一回事吗？ A4：不是一回事，它们属于不同的“账本”。PDU容器服务于FBC（用户计费），它以Rating Group为中心，记录了一段业务流量（如视频、游戏）在产生时的详细上下文。而QFI容器服务于QBC（漫游结算），它以QoS流（QFI）为中心，只关心某个特定QoS等级的承载通道上传输了多少流量。两者在目的、内容和应用场景上都有本质区别。
Q5：这些复杂的IE结构是在哪里定义的？如果我想了解每个字段的具体取值范围（比如S-NSSAI的格式），应该去查哪个规范？ A5：这些IE的具体数据类型、取值范围和ASN.1/JSON定义，主要在更底层的Stage 3规范中定义。对于计费领域，最核心的参考是 TS 29.513 (Policy and Charging Control SBI) 和 TS 32.291 (Charging service, stage 3)，以及 TS 32.298 (CDR parameter description)。TS 32.255作为Stage 2规范，主要负责定义功能、流程和信息需求，而Stage 3规范则负责将其具体编码实现。