51学通信

深度解析 3GPP TS 29.552：5.7.17 PFD Determination Analytics (PFD决策分析)

21分钟阅读

好的，我们继续深入探索TS 29.552规范，进入一个与5G策略控制体系（PCF）和应用识别紧密相关的特定分析领域。在前文中，我们已经看到‘洞察者’(Insight-AI)如何评估网络侧的性能。现在，我们将看到它是如何化身为一位“应用侦探”，智能地帮助网络识别和理解新兴的应用流量，从而制定更精细、更准确的控制策略。

深度解析 3GPP TS 29.552：5.7.17 PFD Determination Analytics (PFD决策分析)

本文技术原理深度参考了3GPP TS 29.552 V18.7.0 (2024-12) Release 18规范中关于“5.7.17 PFD Determination Analytics”的核心章节，旨在为读者详细拆解NWDAF是如何通过分析用户面的应用流量，智能地生成或更新PFD（Packet Flow Description，包流描述），从而赋能PCF和NEF实现对未知或动态应用的自动化识别与策略控制。

前言：为应用流量“精准画像”的挑战

在5G网络中，为了实现对不同应用流量的差异化计费、QoS保障和策略控制，网络必须首先能够精确地识别出这些应用的流量。这项工作主要由PCF（策略控制功能）主导，并由UPF（用户面功能）执行。

PCF通过下发PCC（Policy and Charging Control）规则给SMF，SMF再将其转化为N4规则给UPF。这些规则的核心部分，就是用于匹配特定应用流量的**“过滤器（Filter）”。这个“过滤器”最常见的形式就是PFD（Packet Flow Description，包流描述）**。

一个PFD本质上是一组“指纹”，用于描述一个应用可能产生的流量特征，最典型的就是它会访问的**“域名列表”、“URL模式”或“IP三/五元组”**。例如，一个视频应用的PFD可能包含*.videostream.com这样的域名通配符。

然而，在飞速发展的互联网世界，这种机制面临着巨大挑战：

  • 新应用层出不穷：每天都有新的App和在线服务诞生，它们的PFD是什么？网络如何快速“认识”它们？

  • 应用动态变化：一个已知的应用，其后台服务器的域名和IP地址可能会频繁变更（例如，使用CDN、云服务）。如果PFD更新不及时，策略就会失效。

  • 加密流量的挑战：越来越多的流量被加密，使得传统的DPI（深度包检测）技术越来越难以通过“嗅探”内容来识别应用。

手动地、静态地去维护一个覆盖数百万应用的、实时更新的PFD库，对于运营商来说是一项几乎不可能完成的任务。网络迫切需要一种**智能的、自动化的PFD“发现”和“决策”能力。这，正是PFD决策分析（PFD Determination Analytics）**的使命。

这项分析将‘洞察者’(Insight-AI)的角色，定位为PCF的“应用侦察兵”。当PCF对某个应用的流量“一无所知”时，它可以委托‘洞察者’去用户面进行“侦察”，通过分析真实流量，智能地“反向工程”出这个应用的PFD。

在“未来科技博览会”上，一款名为“StarExplorer”的全新AR观星应用突然爆火。PCF的策略库里完全没有这款应用的信息，无法对其进行有效的QoS保障。为此，PCF的一个功能模块——PFDF（PFD Function，负责PFD管理）向‘洞察者’发起了这项分析请求。

本文将深入5.7.17节的信令流程，看看“应用侦探”‘洞察者’是如何为“StarExplorer”这款未知应用精准“画像”的。

1. 任务简报：智能“抓包”与“指纹”提炼

这项分析的目标是，为一个或多个已知的应用（由Application Identifier标识），决策出一组能够描述其流量特征的PFD。

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

This procedure is used by the NWDAF service consumer e.g. NEF(PFDF) to obtain PFD determination analytics for the know application(s), which is calculated by the NWDAF based on the information collected from the UPF and the NEF(PFDF).

‘洞察者’解读道：“我的任务是为一款‘神秘APP’制作一份‘身份档案’（PFD）。为此，我需要拿到它的‘作案工具’（流量包），这需要我的同事NEF(PFDF)和UPF的通力合作。”

  • 分析对象: 一个已知的Application Identifier（应用标识符），但其对应的PFD是未知的或需要更新的。

  • 核心消费者: NEF(PFDF)。这里的PFDF（PFD管理功能）逻辑上是PCF的一部分，它通过NEF（网络能力开放功能）的服务接口与NWDAF交互。可以简单理解为就是策略控制系统。

  • 情报来源:

    • NEF(PFDF): 它不仅是消费者，也是任务的发起者和初始情报的提供者。它会告诉NWDAF：“我需要为‘StarExplorer’这个应用（Application ID）决策PFD”。

    • UPF: 最核心的情报来源。‘洞察者’会指示UPF对流向该应用（通常应用服务器地址的IP范围是已知的）的流量进行“侦察”，提取出关键的流量特征。

  • 分析ID: PFD_DETERMINATION

2. 行动方案：解构PFD决策分析的信令全流程

规范中的 “Figure 5.7.17-1: Procedure for PFD Determination Analytics” 为我们展示了“应用侦探”的工作流程。

阶段一：任务下达与前期准备 (步骤1 - 3)

PFDF向‘洞察者’发起订阅：“请为应用ID为‘StarExplorer-AR’的应用，决策其PFD。”

步骤1a-1b：PFDF发起订阅

PFDF（作为消费者）通过Nnwdaf_EventsSubscription_Subscribe发起请求，analyticsId为PFD_DETERMINATION，eventFilter中包含了applicationId = "StarExplorer-AR"。

步骤2a-2d：从NEF(PFDF)获取应用基础信息

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

The NWDAF may invoke Nnef_PFDmanagement_Subscribe service operation…to subscribe to retrieve PFDs for an Application Identifier(s) from the NEF (PFDF).

在开始“侦察”之前，‘洞察者’需要先从任务发布方那里获取一些基础情报。

  • 动作: ‘洞察者’反过来向**NEF(PFDF)**发起Nnef_PFDmanagement_Subscribe订阅。

  • 目的: 获取关于“StarExplorer-AR”这个应用的所有已知信息。即使它的PFD是未知的，PFDF的数据库里通常也存有该应用的服务器IP地址范围等基础信息。这些信息是后续在UPF上设置“侦察”目标的关键。

  • 信息流 (2c-2d): PFDF通过_Notify将这些基础信息提供给‘洞察者’。

步骤3：制定“侦察”计划

‘洞察者’拿到应用的服务器IP地址范围后，开始制定下一步的行动计划，即决定需要向哪些SMF/UPF下发侦察任务。

阶段二：深入用户面，“抓包”与特征提取 (步骤3a - 5b)

这是获取一手情报的核心环节。

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

The NWDAF may invoke Nsmf_EventExposure_Subscribe service operation…to subscribe via the SMF to UPF to retrieve the application traffic flow related information for the application.

  1. 通过SMF下发任务 (3a-3b):

    • 动作: ‘洞察者’向相关的SMF发起Nsmf_EventExposure_Subscribe订阅。

    • 订阅内容: “请指示你所管辖的、且服务于‘StarExplorer-AR’应用（目标IP地址在XX范围内）的UPF，为我收集该应用的流量信息。”

  2. SMF指示UPF (4a-4b):

    • SMF收到指令后，通过N4接口向目标UPF下发一个特殊的报告规则。

  3. UPF执行“侦察”与上报 (5a-5b):

    • 动作: UPF的用户面引擎开始对流向目标服务器IP地址范围的所有流量进行精细化的特征提取。这就像一个智能的“抓包”工具。

    • 提取内容: UPF会从数据包的头部（特别是对于未加密的HTTP/TLS流量）提取关键信息，例如：

      • HTTP Host Header (域名): api.starexplorer.com, cdn.starexplorer-media.net

      • TLS SNI (服务器名称指示): 在TLS握手阶段暴露的域名。

    • 上报 (5a-5b): UPF将提取到的这些域名/URL列表，通过N4上报给SMF，SMF再通过Nsmf_EventExposure_Notify通知‘洞察者’。

阶段三：分析决策与“档案”生成 (步骤6 - 7)

规范原文引用 (Step 6):

The NWDAF calculates the PFD determination analytics based on the data collected from UPF and NEF (PFDF).

所有“作案工具”的特征都已收集完毕。

  1. 分析与决策 (Step 6): AnLF的“应用侦探”开始对收集来的大量域名和URL进行分析、去重、泛化和决策：

    • 统计与聚类: 发现api-1.starexplorer.com, api-2.starexplorer.com等域名出现的频率最高，将它们聚类为*.starexplorer.com。

    • 关联分析: 将这些域名与从PFDF获取的应用基础信息进行比对，确认其归属性。

    • 生成PFD: 最终，‘洞察者’决策出了一组能够高精度覆盖“StarExplorer-AR”应用流量的PFD：

      • pfdData:

        • flowDescriptions: ["domain:*.starexplorer.com", "domain:*.starexplorer-media.net"]

  2. 交付“身份档案” (Step 7a-7b): ‘洞察者’将这份新鲜出炉的PFD分析报告，通过Nnwdaf_EventsSubscription_Notify服务，交付给PFDF。

闭环完成: PFDF收到了这份由AI自动生成的PFD后，欣喜若狂。它立即将这组PFD添加到了自己的策略库中。

  1. 策略生效: 下一次，当有用户使用“StarExplorer-AR”应用时，PCF就可以利用这组新的PFD，生成精确的PCC规则。

  2. 精准控制: UPF根据新的规则，能够准确地识别出“StarExplorer-AR”的流量，并为其执行特定的QoS保障、计费或流量监控策略。

通过这个闭环，网络实现了对一个全新应用的自动化识别和策略适配，整个过程无需人工干预。

总结：赋能策略体系的“自我学习”

5.7.17节的PFD决策分析，是NWDAF将AI能力深度赋能5G核心策略控制体系的一次完美展示。它解决了传统策略控制中最棘手、最耗费人力的“应用识别”问题。

  • 从“静态配置”到“动态学习”: 它将PFD的管理，从一个需要专家手动配置、频繁更新的静态数据库，转变为一个能够通过分析真实流量进行自我学习、自我更新的动态系统。

  • 提升策略控制的精准度和时效性: 面对日新月异的应用生态，这种自动化的PFD决策能力，能够确保PCF的策略始终是精准、有效和及时的，不会因为应用的变更而失效。

  • 降低运维成本: 将网络工程师从繁琐的“抓包”、“分析日志”、“更新PFD”等工作中解放出来，极大地提升了运维效率，降低了人力成本。

PFD决策分析，让5G的策略控制系统（PCF）也拥有了一个“智能大脑”。这个大脑能够帮助它不断“学习”和“认识”新的应用，使其策略库能够与时俱进，永不落伍。这对于在多变的应用环境中，实现精细化、差异化的网络服务，具有不可估量的价值。

在下一篇文章中，我们将继续5.7节的探索，进入另一个与端到端性能密切相关的分析领域——5.7.18 E2E data volume transfer time analytics (端到端数据卷传输时间分析)。

FAQ 环节

Q1：PFD决策分析能处理加密流量吗？

A1：部分可以。这是这项分析面临的主要挑战之一，也是其智能性的体现。

  • 对于未加密的HTTP流量: UPF可以直接读取HTTP头中的Host字段，获取域名信息。

  • 对于加密的HTTPS/TLS流量: 在TLS握手阶段，客户端通常会通过一个名为SNI（Server Name Indication）的扩展，以明文形式告诉服务器它想访问的域名。具备相应能力的UPF可以从TLS Client Hello消息中提取SNI信息。这是目前识别加密流量应用归属的最主要手段。

  • 对于完全加密、无SNI的流量: 识别难度会大大增加。此时，NWDAF/UPF可能需要依赖于更高级的、基于机器学习的**加密流量识别（Encrypted Traffic Classification）**技术。例如，通过分析数据包的大小、时序、方向等“行为特征”，来推断其可能属于的应用类型。这项技术是当前研究的热点。

Q2：这项分析的消费者为什么是NEF(PFDF)？PCF为什么不直接和NWDAF交互？

A2：这是一个体现5G SBA架构演进和功能解耦的设计。

  • PFDF的独立性: 在Rel-16及以后的架构中，PFD的管理功能（PFDF）被视为一个相对独立的功能模块，它可能由一个专门的团队或系统来维护。

  • NEF作为统一接口: NEF不仅仅用于对外部AF开放能力，也越来越多地被用作核心网内部不同子系统之间进行能力交互的标准化“网关”。让PFDF通过NEF的PFDManagement服务与NWDAF交互，可以：

    • 解耦: PCF的核心逻辑（策略决策）与PFD的管理和获取逻辑解耦。

    • 统一: 所有与PFD相关的操作（无论是从AF获取，还是从NWDAF获取），都通过统一的NEF接口进行，简化了PCF的实现。

在逻辑上，我们仍然可以理解为是PCF在消费这项分析，只不过它将这个任务委托给了其下属的PFDF模块，并通过标准的NEF接口来执行。

Q3：NWDAF生成的PFD一定准确吗？如果它把两个应用的流量搞混了怎么办？

A3：NWDAF生成的PFD是基于数据分析的**“决策（Determination）”或“推荐（Recommendation）”**，它确实存在出错的可能性。

  • 置信度: NWDAF在交付分析结果时，通常会附带一个**置信度（confidence）**评分，告诉PFDF它对这个决策的把握有多大。

  • 人工审核与闭环: 在实际的运营流程中，PFDF在收到NWDAF的推荐后，通常不会直接将其投入生产环境。一个常见的做法是，将其放入一个“待审核”列表，由网络策略工程师进行人工审核和确认。工程师确认无误后，再将其正式发布到策略库中。

  • 持续学习: 如果发现NWDAF的决策出错了，工程师可以将正确的结果作为“反馈”输入回NWDAF，帮助其在下一轮的学习中进行修正。这个“AI推荐 → 人工审核 → 反馈 → AI再学习”的闭环，是当前MLOps在电信领域的典型落地模式。

Q4：这项分析和DPI（深度包检测）是什么关系？

A4：它们是实现应用识别这一共同目标的不同技术手段，可以相互结合。

  • DPI: 是一种**“检测”**技术。它通过深入数据包的载荷（内容），匹配已知的应用协议特征库，来识别应用。它很强大，但对加密流量无能为力，且特征库需要频繁更新。

  • PFD决策分析: 是一种**“学习”**技术。它通过分析流量的元数据（如目标域名、IP），智能地生成用于识别应用的“规则”（即PFD）。它不直接识别流量，而是为其他系统（如UPF上的DPI引擎）提供识别所需的“弹药”。

在UPF上，一个轻量级的、基于PFD的L7分类引擎（可以看作一种DPI），会利用NWDAF学习到的PFD，来对实时流量进行分类。

Q5：如果一个应用完全没有域名，只通过裸IP地址进行通信，这项分析还能工作吗？

A5：难度会大大增加，但仍有方法。

  1. 基于IP的PFD: 如果应用的服务器IP地址是固定的或在一个有限的IP段内，那么UPF仍然可以捕获这些目标IP地址。NWDAF分析后，生成的PFD就不是基于域名，而是基于IP地址或网段了（例如，flowDescriptions: ["ipv4:1.2.3.0/24"]）。

  2. AF提供信息: 这种情况下，最可靠的信息来源是应用开发者（AF）自己。AF可以直接向运营商的NEF注册其应用的服务器IP列表。

  3. 加密流量分析: 如Q1所述，对于既无域名也无固定IP的P2P等应用，最终需要依赖更高级的加密流量行为分析技术来对其进行聚类和识别。

关系图谱