好的，我们继续本次的深度探索，进入5G智能网络中一个与策略控制和流量工程紧密相关的分析领域——PDU会话流量分析。

深度解析 3GPP TS 23.288：6.20 PDU Session traffic analytics (PDU会话流量分析)

本文技术原理深度参考了3GPP TS 23.288 V18.9.0 (2025-03) Release 18规范中，关于“6.20 PDU Session traffic analytics”的核心章节。本文旨在为读者深入剖析NWDAF如何化身“流量审计师”，对用户的PDU会话进行精细化审查，甄别出哪些流量是“合规”的，哪些是“异常”的，从而为网络的精细化运营和策略执行提供关键洞察。

在5G网络中，PDU会话是用户终端（UE）连接到数据网络（DN）的“高速公路”。为了实现差异化服务，网络策略控制的核心——PCF（策略与计费功能），会为这条高速公路制定详细的“交通规则”，即PCC（策略与计费控制）规则。这些规则规定了特定类型的流量（如微信视频通话）应该匹配哪条QoS Flow、如何计费等。

然而，规则制定后，用户实际的流量行为是否严格遵守了这些规则？是否存在“本应走普通车道的流量，却跑到了应急车道上”的情况？或者，是否存在一些网络无法识别的“神秘”流量？对这些问题进行解答，正是**PDU会话流量分析 (PDU Session traffic analytics)**的核心使命。

场景设定：某企业为其员工办理了“企业办公套餐”，并通过5G网络切片（S-NSSAI-Corp）提供服务。根据与运营商签订的协议，只有访问企业内网OA、ERP等白名单应用的流量（由一组Traffic Descriptor定义）才被允许通过该切片。作为策略的执行监督者，PCF需要验证员工的实际流量是否符合这一规定。为此，PCF向NWDAF“小慧”发起了一项“流量审计”任务。

1. “流量审计”：PDU会话流量分析的服务内容 (TS 23.288 Clause 6.20.1)

PCF在向“小慧”下达“审计任务”时，需要明确哪些审计要求？6.20.1节“General”对此进行了定义。

This clause specifies the procedure for an NWDAF to provide statistics on whether traffic of UEs via one or multiple PDU sessions is according to the information provides by the service consumer. The NWDAF collects traffic flow information of UE traffic via PDU session(s) established for a specific S-NSSAI and/or DNN and provides statistics of UEs that route traffic according to the information provided by the service consumer… and UEs that route traffic which is not expected…

“小慧”的核心任务是：审计并统计在一个PDU会话中，哪些流量匹配 (matching)了消费者（PCF）提供的预期流量描述，哪些流量不匹配 (which does not match)。

1.1 核心审计要求

• Analytics ID = "PDU Session traffic": 明确审计主题。
• Target of Analytics Reporting: 审计对象，可以是一个特定的员工“王总”（SUPI），也可以是整个公司的员工群组（Internal Group ID）。
• Traffic Descriptor: 这是最核心的输入。它定义了“什么是合规流量”。

  Traffic Descriptor: Application Identifier, IP Descriptions or Domain Descriptors are applicable. PCF会提供一个白名单列表，例如：

  • Application Identifier: “Corp-OA”, “Corp-ERP”。
  • IP Descriptions: 服务器IP地址段 10.0.1.0/24。
  • Domain Descriptors: *.my-company.com。
• Analytics Filter Information: 限定审计的范围。
  • S-NSSAI: S-NSSAI-Corp。
  • DNN: “corp-net”。
  • Area of Interest: 办公楼所在的TAI。

2. “审计证据”：流量分析的数据来源 (TS 23.288 Clause 6.20.2)

为了进行审计，“小慧”需要获取最直接的“证据”——详细的用户面流量记录。Table 6.20.2-1列出了这些关键证据。

NWDAF collects input data from the SMF and/or UPF. The detailed data are described in Table 6.20.2-1.

表格用途解读与重绘:

Table 6.20.2-1: Collected PDU Session User Plane Traffic Information

Information	Source	Description
SUPI	SMF, UPF	审计对象的UE ID。
S-NSSAI / DNN	SMF, UPF	PDU会话所属的切片和数据网络。
PDU Session Information		检测到的业务数据流（SDF）的详细信息。
> Packet Filter Set	SMF, UPF	检测到的SDF的数据包过滤器（即IP五元组等）。
> URL list	SMF, UPF	从SDF的数据包中提取的URL列表（如果可获得）。
> Domain Name list	SMF, UPF	从SDF的数据包中提取的域名列表（如果可获得）。
> UL/DL Data volume	SMF, UPF	该SDF在PDU会话期间的上/下行流量。

这份表格的核心在于PDU Session Information。数据采集的流程如下：

1. SMF配置UPF: SMF作为控制核心，根据PCF下发的PCC规则（或者NWDAF的订阅请求），在N4接口上对UPF进行配置。它会告诉UPF：“请为‘王总’的这个PDU会话启动流量监测。”
2. UPF进行DPI/L7分析: UPF作为用户面网关，具备深度包检测（DPI）能力。当“王总”的流量经过时，UPF会解析每一个数据包，识别出其IP五元组（Packet Filter Set），甚至能解析出HTTP请求中的URL或DNS请求中的域名。
3. UPF上报测量结果: UPF将识别出的每个SDF的详细信息（五元组、URL、流量等）上报给SMF或直接上报给NWDAF。

The NWDAF collects input data from the UPF either indirectly via the SMF, or directly from the UPF using the “UserDataUsageMeasures” event exposure event as described in clause 4.15.4.5 of TS 23.502.

“小慧”通过订阅这个UserDataUsageMeasures事件，就拿到了最详尽、最底层的流量“账单”，为接下来的审计工作提供了无可辩驳的证据。

3. “审计报告”：流量分析的输出 (TS 23.288 Clause 6.20.3)

在拿到流量“账单”后，“小慧”就开始了“对账”工作——将每一条流量记录与PCF提供的“合规”Traffic Descriptor进行比对，并最终生成一份清晰的“审计报告”。Table 6.20.3-1定义了这份报告的格式。

The output analytics is shown in Table 6.20.3-1.

表格用途解读与重绘:

Table 6.20.3-1: PDU Session traffic statistics

Information	Description
List of SUPIs or SUPI	审计对象
S-NSSAI / DNN	PDU会话所属的切片和数据网络。
Traffic matching the Traffic Descriptor	匹配（合规）流量的统计
> Traffic Descriptor	识别出的具体IP流描述（五元组、应用ID等）。
> Volume	该合规流量的数据量和/或包数量（UL/DL/总和）。
Traffic which does not match Traffic Descriptor	不匹配（非合规）流量的统计
> Traffic Descriptor	识别出的具体非合规IP流描述。
> Volume	该非合规流量的数据量和/或包数量。

报告解读： PCF收到的“审计报告”可能会是这样的：

• 审计对象: 员工“王总” (SUPI-Wang)
• PDU会话: S-NSSAI-Corp, DNN-corp-net
• 合规流量:
  • 访问 erp.my-company.com (Domain Descriptor)，总流量: 上行50MB, 下行200MB。
  • 访问 10.0.1.10:8080 (IP Flow descriptor)，总流量: 上行10MB, 下行5MB。
• 非合规流量:
  • 访问 www.douyin.com (Domain Descriptor)，总流量: 上行5MB, 下行3GB。
  • 使用 BitTorrent 协议 (Application ID)，总流量: 上行1GB，下行500MB。

这份报告一目了然地告诉PCF，“王总”在企业切片内，除了正常的办公流量外，还产生了大量的抖音视频和P2P下载流量。

4. “审计流程”：PDU会话流量分析的完整过程 (TS 23.288 Clause 6.20.4)

Figure 6.20.4-1: NWDAF providing PDU Session traffic analytics 描绘了从请求到报告的完整审计流程。

1. PCF发起审计请求: PCF向NWDAF发起订阅，请求对企业员工在S-NSSAI-Corp上的PDU会话进行流量审计，并提供了“合规流量”的Traffic Descriptor。
2. NWDAF确定数据源: “小慧”收到请求后，确定需要从服务这些员工的SMF/UPF获取详细的流量数据。
3. NWDAF发起数据采集: “小慧”向相关的SMF/UPF发起订阅，订阅UserDataUsageMeasures事件，要求上报PDU会话中所有SDF的详细信息。
4. UPF执行并上报: UPF对流经的用户流量进行DPI分析，并将结果上报。
5. NWDAF审计与统计: “小慧”将上报的每一条SDF与PCF提供的Traffic Descriptor进行比对，区分为“匹配”和“不匹配”两类，并分别进行流量统计。
6. NWDAF提供审计报告: “小慧”将最终的统计结果（如3.1节所述）格式化为一份清晰的报告，通过Notify消息发送给PCF。

PCF拿到这份报告后，就可以采取进一步的策略行动，例如：

• 动态调整策略：为“王总”PDU会话中识别出的抖音流量，动态下发一条新的PCC规则，将其QoS等级降到最低，或者进行流量封堵。
• 优化Traffic Descriptor：如果发现大量无法识别的流量都指向一个新的、合法的办公应用，PCF可以更新其Traffic Descriptor，将这个新应用也纳入白名单。

---

FAQ - 常见问题解答

Q1：PDU会话流量分析和传统的网络流量监控有什么区别？ A1：传统的网络流量监控通常是粗粒度的，例如监控一个基站的总流量，或者一个APN的总流量。而PDU会话流量分析是面向用户、面向应用、基于策略的精细化审计。它的核心区别在于：

• 精细粒度：分析深入到单个用户的单个PDU会话中的每一个业务数据流（SDF）。
• 策略驱动：它不是简单地统计流量，而是将实际流量与预期的策略（Traffic Descriptor）进行比对，核心目标是验证策略的执行情况和发现异常流量。
• 闭环联动：其分析结果可以直接驱动PCF进行动态的策略调整，形成“监控-分析-决策-执行”的智能闭环。

Q2：UPF是如何识别出应用（如抖音、BitTorrent）的？ A2：这依赖于UPF的深度包检测（DPI, Deep Packet Inspection）和L7层（应用层）分析能力。现代UPF内置了强大的流量识别引擎，它不仅能看到IP包的头部（源/目的IP、端口），还能深入分析TCP/UDP载荷的内容和模式。通过预置的、可频繁更新的应用特征库，UPF可以识别出成千上万种应用和协议的“指纹”，从而实现精准的应用识别。

Q3：这项分析会不会对UPF造成很大的性能压力？ A3：会。DPI本身就是一项资源密集型任务。因此，这项功能通常不会对全网所有用户的所用流量开启。如规范在NOTE中提到的，需要谨慎使用，避免对UPF造成过载。在实际应用中，通常会采取以下策略来控制开销：

• 按需开启：只对特定的、需要审计的用户群（如企业用户、高价值用户）或特定的S-NSSAI/DNN开启。
• 采样上报：可以配置UPF只对一部分流量进行采样分析和上报。
• 硬件加速：商用UPF通常会使用专门的硬件加速芯片来处理DPI任务，以降低对CPU的消耗。

Q4：如果流量是加密的（如HTTPS），UPF还能识别出URL和应用吗？ A4：这取决于加密的程度和UPF的能力。对于HTTPS流量，虽然载荷内容是加密的，但UPF仍然可以通过分析TLS握手过程中的SNI (Server Name Indication)字段来获取用户试图访问的域名 (Domain Name)。这在很多场景下已经足够识别出应用（例如，访问*.douyin.com）。对于一些更复杂的加密协议或试图伪装的流量，则需要更高级的、基于流量行为模式（如包大小序列、时间间隔等）的机器学习算法来进行识别。

Q5：这项分析的主要价值是什么？它能为运营商带来什么好处？ A5：其核心价值在于实现了网络流量的精细化可视、可控，带来了多方面的好处：

• 保障企业客户SLA：确保企业切片等专网资源的专用性，防止资源被非法滥用，提升客户满意度。
• 提升策略执行的智能化水平：从“静态配置策略”升级为“动态监控、智能调整”，使PCC策略体系真正“活”了起来。
• 发现新的计费与商业模式：通过精准识别应用流量，可以推出更灵活的定向流量套餐或基于应用QoS保障的增值服务。
• 增强网络安全：通过识别异常、未知的流量，可以辅助发现潜在的安全威胁，如僵尸网络、非法P2P应用等。