深度解析 3GPP TS 38.423：8.3.13 Secondary RAT Data Usage Report (双连接下的“账单”同步)
本文技术原理深度参考了3GPP TS 38.423 V18.5.0 (2025-03) Release 18规范中，关于“8.3.13 Secondary RAT Data Usage Report”的核心章节，旨在为读者深入剖析在多RAT双连接（MR-DC）场景下，网络如何精确统计并同步流经次节点的数据量，以支持精确计费、策略控制和网络分析。
1. 引言：双连接背后的“经济账”
在之前的篇章中，我们已经深入探讨了5G双连接（DC）如何为用户“小杰”的8K直播提供强大的带宽支持。主节点（MN）和次节点（SN）如同两位配合默契的搭档，共同完成了数据的传输任务。然而，在电信网络这个庞大而精密的商业系统中，每一次数据传输的背后，都关联着一笔“经济账”。
我们的工程师小林在分析一份EN-DC（E-UTRA-NR Dual Connectivity，即4G作主站，5G作从站）的网络日志时，发现了一个他从未见过的XnAP消息：SECONDARY RAT DATA USAGE REPORT。他感到困惑，向导师陈工请教：“陈工，双连接的建立、修改、释放我们都学过了，为什么SN还需要周期性地向MN发送一份‘数据使用报告’？MN自己不知道总的数据量吗？”
陈工笑了笑，在白板上画出了一个架构图：“小林，你的问题触及了双连接运营的现实核心。在EN-DC场景下，MN（eNB）是唯一面向5G核心网（5GC）的‘总接口’。核心网的所有计费策略、QoS策略都通过NG接口下发给MN。对于核心网来说，它看到的只有一个‘黑盒子’——MN。它知道给小杰的PDU会话总共下发了多少数据，但它并不知道这些数据在无线接入网内部，有多少是通过MN（LTE）的空口发送的，又有多少是被分流到SN（NR）并通过5G空口发送的。”
陈工继续说道：“这个问题至关重要。想象一下小杰的手机套餐：‘每月包含50GB通用流量，和额外的100GB 5G专属高速流量包’。运营商的计费系统要如何区分，小杰下载一个10GB的文件时，哪些流量应该扣除‘通用流量’，哪些应该扣除‘5G专属包’？唯一的办法，就是让实际处理了5G流量的SN，定期向‘总账房’MN汇报它的‘工作量’。这份‘工作报告’，就是SECONDARY RAT DATA USAGE REPORT。它是一份精确到PDU会话和QoS流的‘账单’，是连接无线侧资源消耗与核心网计费策略的桥梁。”
2. 8.3.13.1 General (概述) - 为何需要一份“副手”的工作报告
This procedure is initiated by the S-NG-RAN node to provide information on the used resources of the secondary RAT (e.g. NR resources during MR-DC operation) as specified in TS 23.501. The procedure uses UE-associated signalling.
这段概述精准地定义了该流程的本质和目的：
- 发起方 (Initiator)：S-NG-RAN node (次节点)。报告工作量，自然是由干活的“副手”来发起。
- 接收方 (Recipient)：M-NG-RAN node (主节点)。作为“总账房”，MN负责收集所有报告并进行汇总。
- 核心目的 (Purpose)：提供关于**第二RAT（Secondary RAT）**所使用资源的信息。在EN-DC场景下，第二RAT就是NR。
- 根本驱动力 (Driving Force)：规范明确指向了TS 23.501。这直接告诉我们，该流程的根本目的并非为了无线资源管理本身，而是为了满足上层系统架构（如计费、策略控制PCC、QoS监控等）对数据分流的可见性需求。
- 信令性质 (Signalling Type)：UE关联信令（UE-associated signalling）。这份报告是针对特定UE的，每一份“账单”都必须明确属于哪个用户。
3. 8.3.13.2 Successful Operation (成功操作) - “账单”的构成与传递
SECONDARY RAT DATA USAGE REPORT是一个Class 2流程。SN作为发起方，只需单向地将报告发送给MN，无需等待MN的确认。
The S-NG-RAN node initiates the procedure by sending the SECONDARY RAT DATA USAGE REPORT message to the M-NG-RAN node.
陈工的解读：“为什么设计成Class 2？因为这是一种周期性、信息性的报告。它不像切换准备那样，一步错就全盘皆输。即使偶尔丢失了一份报告，也不是灾难性的。在下一个报告周期，SN会发送一份包含了最新累计数据量的新报告。计费系统在后台进行数据整合时，有足够的鲁棒性来处理这种偶尔的数据缺失。因此，为了效率，采用‘发后不理’的Class 2模式是最高效的选择。”
接下来，我们深入剖析SECONDARY RAT DATA USAGE REPORT这封“工作报告”的详细内容，它体现了3GPP设计的精细与严谨。
3.2.1 报告的层级结构
这份报告是一个层层递进的结构，从UE级别一直细化到具体的时间窗口。
- 消息顶层：包含
M-NG-RAN node UE XnAP ID和S-NG-RAN node UE XnAP ID，明确这份报告属于哪个UE。 - PDU会话列表 (
PDU Session Resource Secondary RAT Usage List)：一个UE可能同时有多个PDU会话（例如，一个用于上网，一个用于IMS通话）。这份列表允许SN在一个消息里，上报所有相关PDU会话的数据使用情况。 - PDU会话级报告 (
PDU Session Resource Secondary RAT Usage Item): 每一项都包含：PDU Session ID: 明确这是哪个PDU会话的账单。Secondary RAT Usage Information: 这是报告的核心载体。
3.2.2 Secondary RAT Usage Information IE的深度解析
这个IE内部，又分为两个更细粒度的报告列表：
PDU Session Usage Report: 对整个PDU会话在SN侧的总流量进行统计。QoS Flows Usage Report List: 对该PDU会话内，每一个流经SN的QoS流的流量进行单独统计。这提供了更精细的计费和策略控制依据。例如，小张的游戏流量是一个QoS流，普通的网页浏览是另一个，运营商可能对这两个流有不同的计费策略。
而无论是PDU会话级还是QoS流级报告，最终的数据都落在一个名为Volume Timed Report List的结构中。
3.2.3 Volume Timed Report List - 精确到时间戳的流量统计
这是整份报告中最核心的数据单元，它详细记录了在某个时间窗口内，SN处理的上行和下行数据量。
我们以其中一个Volume Timed Report Item为例：
Start Timestamp: 一个UTC时间戳，精确记录了本次统计周期的开始时间。End Timestamp: 另一个UTC时间戳，记录了统计周期的结束时间。Usage Count UL: 一个64位的整数，记录了在该时间窗口内，SN从UE处接收到的上行数据总量，单位是字节（octets）。Usage Count DL: 一个64位的整数，记录了在该时间窗口内，SN向UE发送的下行数据总量，单位是字节。
场景代入：
假设SN的报告周期被配置为1分钟。那么，SN会周期性地向MN发送如下内容的SECONDARY RAT DATA USAGE REPORT消息：
- UE: 小杰
- PDU Session ID: 5 (用于上网和游戏)
- QoS Flow ID: 9 (游戏流)
- Timed Report:
- Start: 14:30:00 UTC
- End: 14:31:00 UTC
- UL Bytes: 50,240,000 (约50MB)
- DL Bytes: 10,120,000 (约10MB)
- QoS Flow ID: 12 (网页浏览流)
- Timed Report:
- Start: 14:30:00 UTC
- End: 14:31:00 UTC
- UL Bytes: 120,000 (约120KB)
- DL Bytes: 2,500,000 (约2.5MB)
MN收到这份报告后，会将其缓存，并在需要时（例如，收到核心网的查询请求，或者在UE上下文释放时）将这些统计信息汇总，通过NGAP接口上报给核心网（AMF/SMF）。核心网的计费域（Charging Domain）最终根据这些精确的、按RAT和QoS流区分的数据，来计算小杰的手机账单。
4. 8.3.13.3 & 8.3.13.4 (失败与异常) - Class 2的“无忧”哲学
8.3.13.3 Unsuccessful Operation Not applicable.
8.3.13.4 Abnormal Conditions Not applicable.
陈工指着这两节对小林强调：“再次看到‘Not applicable’，你应该已经非常熟悉这种设计模式了。作为一个单向的、周期性的状态报告，协议设计者认为没有必要为它定义复杂的应用层失败响应机制。”
- 健壮性设计：如果MN收到了一个格式错误或内容无法解析的报告，它会简单地丢弃该报告。
- 容错性设计：如果一份报告在传输中丢失，MN只是暂时缺少了一个数据点。在下一个周期，SN会发送一份新的报告。后台的计费和分析系统在设计时，就已经考虑到了数据源可能存在的不完美，它们有自己的数据校准、插值或告警机制来处理长时间的数据缺失。
这种“信任下层、简化上层”的设计，使得Secondary RAT Data Usage Report流程本身极为轻量，不会给本已繁忙的Xn接口增加过多的信令负担。
5. 总结：从比特流到价值流的桥梁
Secondary RAT Data Usage Report流程虽然在XnAP的众多移动性管理流程中显得有些“另类”，但它却是连接技术与商业、连接无线资源消耗与运营商收入模型的关键桥梁。它使得5G网络，特别是早期依赖与LTE协同的EN-DC网络，能够实现精细化的计费和策略执行。
- 它是精细化计费的基础：提供了按RAT、按PDU会话、按QoS流区分的数据使用量，是实现5G多样化资费套餐（如专属流量包）的技术前提。
- 它是策略控制的“眼睛”：让核心网的PCF能够看到数据在不同RAT上的实际分流情况，从而可以做出更精准的策略决策（例如，当发现NR路径拥塞时，可以动态调整策略，将更多流量引导回LTE）。
- 它是网络分析的宝贵数据源：运维人员通过分析这些报告，可以了解在实际网络中，双连接的分流效率如何、不同业务在不同RAT上的流量分布，为网络优化和规划提供依据。
对于协议开发者小林来说，这个流程的挑战在于实现一个高性能、低开销、且绝对准确的字节计数器。任何计数的偏差，最终都可能导致用户的账单错误。对于网络运维和计费部门的工程师来说，这个流程产生的日志和数据，是他们日常工作中不可或缺的“金矿”。
FAQ
Q1：这个报告是由SN主动发起的，那么报告的周期是多长？由谁来配置？
A1：报告的周期是由主节点（MN）在建立或修改SN时，通过RRC容器（CG-ConfigInfo）中的reportInterval字段来配置的。这体现了MN对整个双连接会话的主导权。报告周期是一个可配置的参数，运营商可以根据计费的精细度要求和网络信令负荷的平衡来设定，常见的可能在分钟级别。
Q2：这个流程只适用于EN-DC（LTE+NR）吗？在NR-NR双连接中需要吗？ A2：这个流程的名称是“Secondary RAT”，是通用术语。它最典型的应用场景确实是MR-DC（如EN-DC），因为需要区分两种不同技术的RAT。但在NR-NR双连接中，如果运营商的计費或策略系统需要区分数据是由哪个gNB（MN或SN）处理的（例如，某些gNB可能属于合作伙伴，需要进行网间结算），那么这个流程同样适用。此时，SN（一个gNB）会向MN（另一个gNB）报告它所处理的NR数据量。
Q3：报告的数据量是PDCP层的，还是更下层的？为什么？ A3：通常是PDCP层的SDU（Service Data Unit）数据量。因为PDCP层是用户面数据进入无线协议栈进行加密、完整性保护和头压缩的“第一站”，也是与核心网QoS流直接对应的层次。在PDCP层进行计数，能够最准确地反映核心网下发的IP包实际消耗的无线资源，也最便于与QoS流进行关联。
Q4：如果MN在收到报告后，自己发生了切换，这些报告数据会如何处理？
A4：这是一个很好的问题，体现了移动性的复杂性。当MN自身发生切换时（例如，从eNB A切换到eNB B），旧的MN（eNB A）在向新的MN（eNB B）传递UE上下文时，会将它已经从SN收集到的Secondary RAT Data Usage Report信息一并传递过去。这样，新的MN（eNB B）就拥有了UE在SN上的完整历史数据使用记录，保证了计费数据的连续性。
Q5：User Plane Traffic Activity Report (在8.3.11中) 和 Secondary RAT Data Usage Report (本章) 有什么区别？
A5：两者都是SN向MN报告用户面情况，但目的和内容完全不同。
Activity Notification(8.3.11)：报告的是**“有没有”数据活动。它是一个简单的二进制状态（active/inactive），目的是为了节能和RRC状态管理**。Data Usage Report(8.3.13)：报告的是**“有多少”数据。它是一个精确的、带时间戳的字节计数**，目的是为了计费和策略控制。 前者是“心跳监测仪”，后者是“流量计”。