好的,我们继续本次的深度探索之旅,进入5G智能网络中一个精巧而实用的分析领域——PFD决策分析。
深度解析 3GPP TS 23.288:6.16 PFD Determination Analytics (PFD决策分析)
本文技术原理深度参考了3GPP TS 23.288 V18.9.0 (2025-03) Release 18规范中,关于“6.16 PFD Determination Analytics”的核心章节。本文旨在为读者详细剖析NWDAF如何化身“流量侦探”,通过分析用户面流量,智能地“反向工程”出未知应用的流量特征,从而辅助网络功能(主要是NEF/PFDF)生成或更新PFD(Packet Flow Description),实现对应用流量更精准、更自动化的识别与管理。
在5G网络中,为了实现对应用流量的精细化策略控制(如QoS保障、计费、路由等),网络首先需要能够识别出这些流量。PFD(Packet Flow Description)就是用于描述应用流量“指纹”的一套规则。它通常由一组IP 3元组(服务器IP地址、端口号、协议)或URL/域名等组成。
传统上,PFD主要靠手动配置,这面临着诸多挑战:应用层出不穷,其服务器地址和端口频繁变更,手动维护PFD费时费力且容易出错。那么,有没有一种方法能让网络“自主学习”和“自动发现”应用的PFD呢?
PFD决策分析 (PFD Determination Analytics) 正是NWDAF“小慧”为解决这一痛点而生的专属能力。她通过“偷窥”UPF上的实际流量,智能地总结出某个已知应用的流量模式,并将其“推荐”给PFD的管理者——PFDF (PFD management Function),一个通常与NEF合设的功能。
场景设定:一款名为“闪速云盘”的新兴应用广受用户欢迎,运营商希望为这款应用制定专门的QoS保障策略。但“闪速云盘”使用了大量动态变化的云服务器地址和端口,手动配置PFD变得异常困难。为此,负责管理PFD的NEF(PFDF)向NWDAF“小慧”发起了一项特殊的“侦察”任务:“请帮我找出‘闪速云盘’这个应用的流量特征(PFD)”。
1. “流量侦察”任务书:如何请求PFD决策分析 (TS 23.288 Clause 6.16.1)
NEF(PFDF)在向“小慧”下达“侦察”任务时,需要明确哪些信息?6.16.1节“General”对此进行了定义。
To assist determination of PFDs for known application identifiers… an NWDAF may perform data analytics on existing PFD information and user plane traffic and provide analytics results in the form of new or updated PFD determination statistics… to an analytics consumer in the 5GC. The NEF(PFDF) as the consumer uses the suggested PFD information…
“小慧”的核心任务是:分析已知应用的用户面流量,提供新建或更新的PFD建议。
1.1 核心请求参数
Analytics ID = "PFD Determination": 明确任务主题。Target of Analytics Reporting: “any UE”: 分析对象是使用该应用的所有用户。Application identifier: 必填项,明确要侦察的应用,例如“闪速云盘”的应用ID。Analytics Filter Information: 可选的过滤条件,如S-NSSAI(s)或DNN(s),以将侦察范围限定在特定切片或数据网络。Analytics Reporting Parameters: 报告方式。可以是周期性报告,或者更有用的是差异化报告。reporting when threshold is reached…to indicate that the report shall only occur when the information differs from the previous report. 这意味着,只有当“小慧”发现了新的或需要更新的PFD时,她才会上报,极大减少了不必要的通知。
2. “侦察工具”与“线索”:PFD分析的数据来源 (TS 23.288 Clause 6.16.2)
要成为一名出色的“流量侦探”,“小慧”需要两样东西:一是强大的“侦察工具”(能够看到真实流量),二是已有的“案件档案”(已知的PFD信息)。Table 6.16.2-1 列出了她需要的所有“线索”。
The NWDAF collects information on user data traffic from the UPF for a known Application ID… and retrieves the existing PFDs from the NEF(PFDF).
2.1 来自UPF的“实时流量录像” (User Plane Traffic)
这是最关键的“第一手线索”,由UPF通过深度包检测(DPI)提供。
表格用途解读与重绘 (节选):
Table 6.16.2-1: Input data to detect known application from NFs
| Information | Source | Description |
|---|---|---|
| Application ID for detection of suggested PFD… | UPF | UPF用于识别该应用的检测算法ID。 |
| Application Traffic Flow Information (1..max) | UPF | 识别出的与该应用相关的具体业务流信息。 |
| > IP 5-tuple | UPF | 业务流的IP五元组。 |
| > UL/DL Data volume & Rate | UPF | 该业务流的流量和速率。 |
| > URL list / Domain Name list | UPF | 从该业务流中提取的URL或域名。 |
这里有一个非常重要的概念:Application ID for detection of suggested PFD information。这表明UPF可能拥有比PFDF更高级、更智能的应用识别能力(例如,基于行为模式的启发式识别算法)。当UPF的这个高级算法识别出某个流量属于“闪速云盘”时,即使这个流量的五元组不在PFDF的现有PFD规则中,UPF依然会将其作为“闪速云盘”的流量上报给“小慧”。这正是“小慧”能够发现新PFD的基础。
2.2 来自NEF(PFDF)的“现有PFD档案”
PFD Information
… PFD(s) (1..max)
“小慧”会从NEF(PFDF)获取当前所有已知的、关于“闪速云盘”的PFD规则。这有两个目的:
- 避免重复建议:如果UPF上报的一个流量模式已经存在于现有的PFD中,“小慧”就知道无需再次建议。
- 建议更新:如果“小慧”发现某个现有的PFD规则(例如,一个旧的服务器IP)已经长期没有流量了,她可能会建议将其删除或更新。
3. “侦察报告”:PFD分析的输出 (TS 23.288 Clause 6.16.3)
在分析了海量的实时流量和现有的PFD档案后,“小慧”将提交一份简洁而精准的“侦察报告”。Table 6.16.3-1 定义了这份报告的格式。
表格用途解读与重绘:
Table 6.16.3-1: PFD Determination statistics
| Information | Description |
|---|---|
| Application ID | 对应的应用ID,即“闪速云盘”。 |
| List of suggested PFD information (1..max) | 建议的PFD信息列表。 |
| > PFD ID | 建议的PFD的ID。如果是全新的,由NWDAF分配;如果是更新,则是现有ID。 |
| > IP 3-tuple list | 建议的IP三元组(协议、服务器IP、端口)。 |
| > URL list | 建议的URL。 |
| > Domain Name list | 建议的域名。 |
| > Confidence | 对此条建议的置信度。 |
报告解读: NEF(PFDF)收到的报告可能包含以下内容:
- 应用: “闪速云盘”
- 建议列表:
- 建议1 (新增):
PFD ID:new-pfd-001Domain Name list:*.fast-disk.cloudConfidence:0.95
- 建议2 (新增):
PFD ID:new-pfd-002IP 3-tuple list: {TCP,110.242.68.4,443}Confidence:0.88
- 建议3 (更新/删除):
PFD ID:old-pfd-123(一个已存在的PFD)- (内容为空,或有特殊标记)
Confidence:0.99(表明“小慧”非常确信这个旧规则已失效)
- 建议1 (新增):
置信度 (Confidence) 在这里至关重要。“小慧”会根据一条流量模式出现的频率、流量大小、持续时间等多种因素,来评估这条模式成为“闪速云盘”官方PFD的可能性。NEF(PFDF)可以根据置信度来决定是自动采纳这条建议,还是需要人工审核。
4. “侦察行动”:PFD决策分析的完整流程 (TS 23.288 Clause 6.16.4)
Figure 6.16.4-1: A procedure for NWDAF-assisted PFD Determination 描绘了从任务下达到报告提交的完整流程。
- NEF(PFDF)发起订阅: NEF(PFDF)向NWDAF订阅“闪速云盘”的PFD决策分析。
- NWDAF订阅PFD档案: “小慧”反向订阅NEF(PFDF)的
Nnef_PFDManagement服务,以便在现有PFD发生变化时能得到通知。 - NWDAF订阅实时流量: “小慧”向SMF发起订阅,要求SMF指示UPF上报所有被其高级算法识别为“闪速云पान”的流量的详细信息(
User Data Usage Measures事件)。 - UPF上报流量线索: UPF持续监控流量,并将符合条件的流量信息上报给“小慧”。
- NWDAF分析与决策: “小慧”将收到的实时流量与已有的PFD档案进行比对和分析,利用聚类、关联规则挖掘等算法,总结出新的、高频出现的、且不在现有档案中的流量模式,并为它们计算置信度。
- NWDAF提交侦察报告: 当“小慧”发现了置信度足够高的新/更新PFD建议时(根据订阅时的差异化报告设置),她会将这些建议通过
Notify消息主动推送给NEF(PFDF)。 - NEF(PFDF)采纳与应用: NEF(PFDF)收到建议后,根据其本地策略(例如,置信度>0.9的建议自动采纳),将新的PFD规则存入UDR,并可能将更新后的PFD分发给SMF,以便SMF能基于新的PFD来指导UPF进行更精准的流量匹配和策略执行。
通过这个智能化的闭环,5G网络实现了从“手动配置规则”到“自动学习规则”的跨越式发展。
FAQ - 常见问题解答
Q1:PFD和PCC规则中的SDF Filter有什么关系? A1:它们是“模板”和“实例”的关系。PFD (Packet Flow Description) 是由PFDF管理的、与特定应用ID关联的流量特征模板。它定义了“某个应用‘长’什么样”。而SDF (Service Data Flow) Filter 是PCC规则的一部分,由PCF下发给SMF,SMF再据此生成PDR(Packet Detection Rule)下发给UPF。SDF Filter定义了“需要对具体某个数据流采取什么策略”。PCF在生成SDF Filter时,可以引用一个或多个PFD,从而大大简化PCC规则的配置。例如,PCF可以下发一条规则:“对所有匹配‘闪速云盘’这个应用ID的流量(其具体特征由PFDF管理的PFD定义),执行QCI=7的QoS策略。”
Q2:如果UPF没有高级的应用识别能力,PFD决策分析还能工作吗? A2:效果会大打折扣,但理论上仍可工作。如果UPF只能进行简单的五元组匹配,那么它就无法发现那些使用动态IP和端口的新流量模式。在这种情况下,NWDAF的作用就从“发现新PFD”退化为“验证和优化现有PFD”。例如,它可以分析现有PFD规则的“命中率”,向PFDF建议删除那些长期没有流量匹配的“僵尸规则”。要真正实现“发现新PFD”,拥有高级DPI能力的UPF是关键前提。
Q3:NWDAF如何计算建议PFD的“置信度(Confidence)”? A3:规范没有定义具体的算法,这取决于实现。但通常会综合考虑以下因素:
- 出现频率: 该流量模式在多少个不同的用户、多少个不同的PDU会话中出现过?
- 流量占比: 该流量模式产生的流量,占该应用总流量的比例有多大?
- 行为一致性: 该流量模式是否总是与应用的其他已知行为(如访问特定域名)同时出现?
- 与已知PFD的关联度: 该流量模式的IP地址是否与某个已知PFD的IP地址在同一个C段? 通过一个加权评分模型,NWDAF可以为每个新发现的模式计算出一个综合的置信度分数。
Q4:这项分析对网络安全有什么意义? A4:有积极意义。通过持续监控一个应用的流量模式,PFD决策分析可以帮助识别异常。例如:
- 检测仿冒应用: 如果突然出现大量流量,其特征与某个知名应用的PFD非常相似,但又略有不同(例如,访问的是一个山寨域名),NWDAF可以生成低置信度的PFD建议,这可能就是一个需要安全审计的信号。
- 识别流量劫持: 如果一个应用的流量突然开始流向一些从未出现过的、可疑的IP地址,这可能预示着DNS劫持或中间人攻击。
Q5:PFDF采纳NWDAF的建议是自动的还是手动的? A5:可以是自动的,也可以是手动的,取决于运营商的策略。在高度自动化的自智网络(Autonomous Network)的愿景中,理想状态是全自动闭环。例如,NEF(PFDF)可以设置一条策略:“凡是NWDAF提交的、置信度高于0.95的PFD新增建议,一律自动采纳并生效。” 对于置信度较低的建议,则可以推送到一个待审核列表,由网络运维人员进行人工确认。