51学通信

深度解析 3GPP TS 29.552：5.7.19 PDU Session Traffic Analytics (PDU会话流量分析)

21分钟阅读

好的，我们继续深入5G“智慧大脑”NWDAF的能力图谱。在前文中，我们已经探讨了多个宏观和端到端的分析领域。现在，我们将把分析的“显微镜”聚焦到构成5G网络数据业务的最小独立单元——PDU会话上，看看‘洞察者’(Insight-AI)是如何扮演一位“流量审计师”，对单个PDU会话的流量特征进行精细化画像和合规性审计的。

深度解析 3GPP TS 29.552：5.7.19 PDU Session Traffic Analytics (PDU会话流量分析)

本文技术原理深度参考了3GPP TS 29.552 V18.7.0 (2024-12) Release 18规范中关于“5.7.19 PDU Session Traffic Analytics”的核心章节，旨在为读者详细拆解NWDAF是如何监控和分析单个或多个PDU会话的流量特征，并将其与预期的策略（如S-NSSAI、DNN、应用描述）进行比对，从而为策略执行的有效性验证、异常流量识别和精细化计费提供关键洞察。

前言：审计每一条“数据管道”的真实流量

PDU会话，是用户UE与数据网络（DN）之间建立的一条逻辑“数据管道”。5G的策略控制与服务质量（QoS）保障，其最终的落脚点，都是在这条管道上执行的。例如，PCF会为一条PDU会话规定：

  • 它应该属于哪个网络切片（S-NSSAI）。

  • 它应该连接到哪个数据网络（DNN）。

  • 它被授权使用哪些应用（由Traffic Descriptor描述）。

  • 它的总带宽（Session-AMBR）是多少。

然而，策略的“规定”与用户面“实际发生”的情况，有时可能并不完全一致。例如：

  • 一个PDU会话被标记为“视频业务”，但它实际承载的却可能是P2P下载流量。

  • 一个UE通过某个PDU会话，访问了策略中未授权的应用或服务器。

  • 某个物联网终端的PDU会话，其流量模型与签约时定义的“心跳”模式大相径庭。

要发现这些“言行不一”的情况，就需要有一种能力，能够深入到用户面，对每一条PDU会话的真实流量进行“审计”，并将其与控制面下发的“预期策略”进行比对。这，正是**PDU会话流量分析（PDU Session Traffic Analytics）**的核心使命。

这项分析将‘洞察者’(Insight-AI)的角色，定位为PCF的“飞行监察员”或“流量审计师”。PCF在下发了一条复杂的策略指令后，可以委托‘洞察者’去用户面“现场督查”，看看这条指令是否被正确执行了，实际的流量是否符合预期。

在“未来科技博览会”的企业专网切片（S-NSSAI for Enterprise）中，为了保障业务安全，PCF制定了严格的策略：该切片内的PDU会话，只允许访问企业内部的服务器（由一组IP地址定义）。为了验证这项“白名单”策略的有效性，并检测是否存在违规访问互联网的行为，PCF向‘洞察者’发起了这项分析的请求。

本文将深入5.7.19节的信令流程，看看“流量审计师”‘洞察者’是如何完成这次精细化的“合规性审计”的。

1. 任务简报：核对“计划”与“现实”

这项分析的目标是，为一个或多个PDU会话，提供其流量的统计信息，并分析这些流量是否符合消费者提供的预期信息（如Traffic Descriptor）。

规范原文引用 (Clause 5.7.19 Introduction):

This procedure is used by the NWDAF service consumer (e.g. PCF) to subscribe or request PDU Session Traffic analytics statistics on whether traffic of UEs via one or multiple PDU sessions is according to the information provided by the service consumer.

‘洞察者’解读道：“我的任务就像海关的X光机。客户（PCF）给了我一份‘报关单’（预期流量描述），我的职责就是扫描通过的每一个‘集装箱’（PDU会话），看看里面的‘货物’（实际流量）是否与报关单上写的一致。”

  • 分析对象: 一个或多个PDU会话，可以由SUPI、DNN、S-NSSAI等来圈定。

  • 核心输入 (Traffic Descriptor): 这是由消费者（PCF）提供的一份“报关单”，用于描述预期的流量应该是什么样子。它可以包含：

    • appId: 预期的应用ID。

    • ip3Tuple: 预期的IP三元组（目的IP、目的端口、协议）。

    • dnn, snssai 等。

  • 情报来源: 核心情报完全来自于UPF。因为只有UPF才能看到PDU会话中流过的每一个真实的数据包。

  • 分析ID: PDU_SESSION_TRAFFIC

  • 输出 (PduSessionTrafficInfo): “审计报告”通常包含两部分：

    • 符合预期的流量统计: 有多少流量是“合规”的。

    • 不符合预期的流量统计: 有多少流量是“不合规”的，以及这些“不合规”流量的具体特征是什么。

2. 行动方案：解构PDU会话流量分析的信令流程

规范中的 “Figure 5.7.19-1: Procedure for PDU Session Traffic Analytics” 为我们展示了“流量审计师”的工作流程。

阶段一：任务下达 (步骤1 - 2)

PCF向‘洞察者’发起订阅：“请为‘企业专网切片’内的所有PDU会话进行流量审计。报关单（Traffic Descriptor）是：只允许访问IP地址范围为10.0.0.0/8的流量。请将所有访问此范围之外的流量（不合规流量）统计并上报给我。”

步骤1a-1c：PCF发起订阅

PCF通过Nnwdaf_EventsSubscription_Subscribe发起请求，analyticsId为PDU_SESSION_TRAFFIC，eventFilter中包含了snssai和关键的trafficDescriptor。

步骤2：制定“审计”计划

规范原文引用 (Step 2):

The NWDAF determines whether it needs to collect the data and, if needed, it collects the data either directly from the UPF or indirectly via the SMF and identifies the SMF(s) and/or UPF(s) to retrieve the data.

‘洞察者’收到这份明确的“审计任务”后，立刻开始计划：

  1. 它需要知道，当前有哪些PDU会话属于“企业专网切片”。

  2. 这些会话都由哪些SMF管理，并经过了哪些UPF。

  3. 然后，它需要向这些UPF下发具体的“流量扫描”指令。

阶段二：深入用户面，执行“流量扫描” (步骤3 - 6)

这是获取一手审计证据的核心环节。

步骤3a-6b：向UPF下发“审计”规则

‘洞察者’有两种方式来指示UPF进行流量审计，这两种方式对应了流程图中的Conditional Option 1和Conditional Option 2。

Option 1: 通过SMF代理 (Indirect subscription)

规范原文引用 (Step 3a-3b):

[Conditional Option 1] The NWDAF shall invoke the Nsmf_EventExposure_Subscribe service operation…to subscribe via the SMF to UPF to retrieve “UserDataUsageMeasures” UPF event.

  1. NWDAF → SMF (3a-3b): ‘洞察者’向管理目标PDU会话的SMF发起Nsmf_EventExposure_Subscribe订阅，请求订阅名为UserDataUsageMeasures的UPF事件。

  2. SMF → UPF (4a-4b): SMF收到请求后，将这个需求转化为具体的N4规则，下发给UPF。这个N4规则会指示UPF，为目标PDU会话创建两个流量测量规则（URR）：

    • URR-1: 匹配符合Traffic Descriptor的流量（即访问10.0.0.0/8的流量）。

    • URR-2: 匹配不符合Traffic Descriptor的流量（即访问10.0.0.0/8之外的所有流量）。

  3. UPF上报 (6a-6b): UPF会对这两个URR分别进行流量统计，并将统计结果（例如，URR-1的流量为100MB，URR-2的流量为5MB）通过N4上报给SMF，SMF再通过_Notify通知‘洞察者’。

Option 2: 直接订阅UPF (Direct subscription)

规范原文引用 (Step 5a-5b):

[Conditional Option 2] The NWDAF may directly invoke the Nupf_EventExposure_Subscribe service operation…to retrieve “UserDataUsageMeasures” UPF event from the UPF.

如果UPF支持直接的服务化接口，‘洞察者’可以跳过SMF，直接向UPF发起Nupf_EventExposure_Subscribe订阅，请求上报UserDataUsageMeasures。这种方式路径更短，效率更高。

阶段三：生成“审计报告”并交付 (步骤7 - 8)

规范原文引用 (Step 7):

The NWDAF derives analytics indicating a list of UEs and the traffic they route according to the provided information…and a list of UEs which route traffic that it is not expected…

‘洞察者’收到了来自UPF的、分类统计好的流量数据。

  1. 分析与报告生成 (Step 7): AnLF的“流量审计师”开始撰写报告：

    • 审计发现: 发现用户“终端-007”的PDU会话中，有5MB的流量访问了公网IP 8.8.8.8。

    • 结论: “用户‘终端-007’存在违规访问互联网的行为，违反了企业专网的安全策略。”

    • 报告内容: ‘洞察者’生成一份PduSessionTrafficInfo报告，其中清晰地列出了：

      • matchingTraffic: 合规流量的统计。

      • nonMatchingTraffic: 不合规流量的统计，并可能附带这些流量的五元组信息（如8.8.8.8:53），为进一步排查提供了精确线索。

  2. 交付报告 (Step 8a-8c): ‘洞察者’将这份“审计报告”通过_Notify或请求响应，交付给PCF。

闭环完成: PCF收到了这份明确的“违规报告”后，可以立即采取行动：

  1. 策略收紧: PCF可以下发一条更严格的PCC规则给SMF/UPF，明确**阻断（Block）**所有访问10.0.0.0/8之外的流量。

  2. 安全告警: PCF可以将该事件上报给安全运营中心（SecOps），触发对“终端-007”的安全审查，检查其是否被恶意软件感染。

通过这个“策略定义 → 智能审计 → 策略修正/告警”的自动化闭环，网络的策略执行得到了有效的监督和保障。

总结：让策略“看得见、管得住”

5.7.19节的PDU会话流量分析，是NWDAF将智能分析能力与5G核心的策略控制框架（PCC）深度结合的典范。它解决了策略执行中“最后一公里”的可见性问题，确保了控制面的“意图”能够在用户面得到不折不扣的“执行”。

  • 策略的“审计师”: 它为PCF提供了一双深入用户面的“眼睛”，能够验证QoS策略、路由策略、安全策略的实际执行效果，是实现策略保障（Policy Assurance）的关键工具。

  • 未知流量的“发现者”: 当面对新兴应用或可疑流量时，这项分析能力可以帮助网络快速为其“画像”，识别其流量特征，为制定新的管控策略提供依据。这与PFD决策分析（5.7.17）的能力相辅相成。

  • 精细化运营的“放大镜”: 通过对单个PDU会话进行“显微镜”级别的流量分析，运营商可以实现更精细的计费（如对不同应用流量采用不同费率）、更个性化的QoS保障和更精准的故障定位。

PDU会话流量分析，让5G网络的策略控制不再是一个“开环”的指令下发过程。它通过引入智能的、数据驱动的“反馈”机制，构建了一个能够自我监督、自我修正的“闭环”智能策略体系，让网络的管理真正做到了“看得见、管得住、控得精”。

在下一篇文章中，我们将探讨一个与地理位置强相关的分析——5.7.20 Relative Proximity Analytics (相对邻近性分析)，看看‘洞察者’是如何判断用户之间的相对远近，从而赋能LBS和公共安全等应用的。

FAQ 环节

Q1：这项分析和UPF自带的DPI（深度包检测）功能是什么关系？

A1：它们是协作关系，DPI是实现这项分析的基础能力。

  • UPF的DPI: 是执行者。UPF上的DPI引擎（或更广义的L3-L7层流量分类引擎）负责根据SMF下发的规则（这些规则源自PCF的策略和NWDAF的trafficDescriptor），对流经的每一个数据包进行实时匹配和分类。

  • NWDAF的分析: 是**“大脑”和“审计师”**。它定义了“要审计什么”（通过trafficDescriptor），并对UPF上报的分类统计结果进行分析、解读和报告。NWDAF关心的是统计性的、带有业务洞察的结果，而不是单个数据包的内容。

可以理解为，UPF是执行“安检”的机器，而NWDAF是制定“安检规则”并分析“安检报告”的官员。

Q2：Traffic Descriptor中可以包含哪些信息来描述一个应用的流量？

A2：Traffic Descriptor是一个非常灵活的数据结构，可以包含多种“指纹”来描述流量：

  • 应用标识 (appId): 最高层的逻辑标识，如“微信”。

  • IP三/五元组: 包括源/目的IP地址（或网段）、源/目的端口、协议号。这是最经典的过滤器。

  • 域名 (domainName): 如*.wechat.com。

  • 以太网包过滤器: 用于非IP类型的流量。

  • DNN, S-NSSAI: 用于在更高层面对流量进行圈定。

消费者（PCF）可以提供这些描述符的任意组合，来精确地定义它所关心的“预期流量”。

Q3：为什么这项分析的流程图中，NWDAF可以直接订阅UPF（Option 2）？这在真实网络中常见吗？

A3：规范中定义直接订阅UPF的选项，体现了5G架构向**控制面与用户面进一步分离和融合（CUPS+）**的演进方向。

  • 理论上: 让分析功能（NWDAF）直接与数据源（UPF）交互，可以缩短信令路径，降低SMF的负担，效率更高。

  • 现实中: 这种部署模式在当前（Rel-16/17）的商用网络中还不常见。因为：

    • SMF的中心地位: SMF是N4会话的“主人”，所有对UPF用户面行为的配置，都通过SMF经由N4接口下发，这是最基础、最稳固的架构。

    • UPF的复杂性: 要求UPF支持一个完整的、面向NWDAF的服务化接口，会增加UPF的复杂性和开发成本。

    • 安全考虑: 直接向UPF开放外部接口，需要更复杂的安全机制。

因此，通过SMF代理（Option 1）是目前最主流、最现实的实现方式。Option 2则为未来的网络架构演进指明了一个方向。

Q4：这项分析可以用来识别哪些安全威胁？

A4：这项分析对于识别多种“策略绕过”型的安全威胁非常有效：

  • 数据外泄 (Data Exfiltration): 在一个企业专网切片中，如果一个被感染的终端试图将内部数据，通过一个PDU会话发送到外部的、未授权的互联网服务器，这项分析可以立即检测到这种“不合规”的流量。

  • 僵尸网络C&C通信: 僵尸网络的控制（C&C）流量，通常会访问一些动态变化的、未知的域名或IP。通过定义一个“白名单”式的Traffic Descriptor（只允许访问已知的、合法的服务器），所有访问白名单之外的流量都可以被识别为可疑流量。

  • 策略绕过: 用户可能试图通过一些技术手段（如使用非标准端口），将P2P下载等流量伪装成普通网页流量，以绕过运营商的限速策略。通过精细的流量审计，可以发现这种描述与实际不符的行为。

Q5：分析结果中的“不合规流量（non-matching traffic）”报告，可以有多详细？

A5：报告的详细程度，取决于UPF的能力和SMF/NWDAF的配置。一个理想的报告可以非常详细：

  • 基础统计: 不合规流量的总数据量、包数。

  • 流量特征: 上报导致匹配失败的流量的五元组信息（源/目的IP、端口、协议）。这对于安全分析和问题定位至关重要。

  • 时间戳: 首次和末次检测到不合规流量的时间。

  • UE信息: 产生该流量的UE的标识。

通过这些详细的信息，网络管理员或安全系统就可以非常精确地知道“谁，在什么时间，通过哪个PDU会话，访问了哪个不该访问的目标”。

关系图谱