4G/5G分組流描述管理及其優(yōu)化方法

孫悅，龍彪

（中國電信股份有限公司研究院，廣東 廣州 510630）

0 引言

PFD（Packet Flow Description，分組流描述）是一組用于檢測由第三方服務提供商提供的應用程序流量的信息[1]。4G 中，PFD 管理是在PCEF（Policy and Charging Enforcement Function，策略及計費執(zhí)行功能）/TDF（Traffic Detection Function，流量檢測功能） 中使用PFDF（Packet Flow Description Function，分組流描述功能），通過SCEF（Service Capability Exposure Function，服務能力開放功能）新建、更新或刪除PFDF 中PFD 的能力，以及從PFDF 到PCEF/TDF的分發(fā)。當PCEF/TDF 被配置為檢測由ASP（Application Service Provider，應用程序服務提供商）提供的特定應用程序時，可以使用此特性[2]。類似地，在5G 中PFD 管理指的是在NEF（Network Exposure Function，網(wǎng)絡開放功能）（PFDF）中創(chuàng)建、更新或刪除PFD 的能力，以及從NEF（PFDF）分發(fā)到SMF（Session Management Function，會話管理功能）和最終到UPF（User Plane Function，用戶面功能）的能力。PFD 管理使PCEF/TDF/UPF 能夠在ASP 提供PFD 時執(zhí)行準確的應用程序檢測，然后按照PCC（Policy and Charging Control，策略和計費控制）規(guī)則的指示執(zhí)行操作[3]。

1 PFD管理方法

3GPP 從Release14 開始對后向數(shù)據(jù)連接進行標準化工作。PFD 管理方法主要用于解決后向數(shù)據(jù)相關(guān)規(guī)則傳輸過多時出現(xiàn)的負載過大問題，可動態(tài)推送PFD 和相應計費規(guī)則。PFDF 用于存儲和管理PFD 及后向數(shù)據(jù)業(yè)務的計費規(guī)則。

PFD 主要有如下信息組成：

◆PFD id；

◆一組或多組以下內(nèi)容；

◆三元組信息包括協(xié)議、服務器端IP 地址和端口號；

◆URL（Uniform Resource Locator，統(tǒng)一資源定位器）中需要匹配的重要部分，例如主機名；

◆域名匹配標準和適用協(xié)議的信息。

根據(jù)運營商與ASP 之間的SLA（Service Level Agreements，服務等級協(xié)議），ASP 可在PFDF 通過PFD管理為每個application identifier（應用程序標識符）提供單獨的或一組PFD 給PCEF/TDF/SMF。PFD 在PCEF/TDF/SMF/UPF 中成為應用程序檢測過濾器的一部分，因此作為邏輯的一部分來檢測應用程序生成的流量。ASP 可能會刪除或修改之前為一個或多個application identifier 提供的部分或全部PFD。PFDF 與PCEF/TDF 之間通過diameter 信令（如圖1 和圖2）、與SMF 之間通過服務化接口（如圖3）發(fā)送目標application identifier 的PFD。在4G/5G 中有兩種模式來管理PFD，一種是PCEF/TDF/SMF 向PFDF 請求目標application identifier 的PFD（即拉模式）；另一種為ASP 通過PFDF 將目標application identifier 的PFD 推送給PCEF/TDF/SMF（即推模式）。

圖2 Gwn參考模型

圖3 Nnef_PFDmanagement服務參考架構(gòu)

1.1 Pull mode（拉模式）實現(xiàn)方法

在3GPP pre-Release16 規(guī)范中，拉模式 的應用場景為： 當某一PFDF 推送的PFD 對 應application identifier 的PCC 規(guī)則沒有被激活或推送時，或者當某一application identifier 的caching timer（緩存計時器）耗盡但其PCC 規(guī)則仍然活躍，PCEF/TCF/SMF 應當向PFDF 請求目標application identifier 的所有PFD。

如圖4 所示，PCEF/TDF 可發(fā)送HTTP GET 消息給PFDF 來拿取一個或多個application identifier 的PFD[4]。

圖4 4G中PFD請求流程

在收到pull mode 操作的HTTP 請求后，如果pull mode 操作成功，則PFDF 應：

◆在HTTP 回復中提供目標application identifier 的PFD；

◆如果有配置的緩存時間值，則應在HTTP 回復中設置緩存時間。如果PFDF 回復消息中不包括緩存時間值，則設置為已配置在PCEF 中的缺省緩存時間值。

如圖5 所示，NF 服務消費者（即SMF）通過GET方法來請求目標application identifier 的PFD。

圖5 5G中PFD請求流程

如果請求成功，則PFDF 將回復目標application identifier 的PFD 及緩存時間值（如果有配置）。如果PFDF 沒有回復目標application identifier，則SMF 應刪除該application identifier 的PFD。

1.2 Push mode（推模式）實現(xiàn)方法

如 圖6 所 示，在4G 中push mode 可通過PFDF 發(fā)送HTTP POST 請求實現(xiàn)。PFDF 可以新建、更新或刪除一個或多個PCEF 中某application identifier 相關(guān)聯(lián)的PFD。當從SCEF 收到新建、更新或刪除某application identifier 的請求時，對于push mode，PFDF 應針對它服務的每個PCEF 選擇執(zhí)行如下操作：

（1）立即向PCEF 發(fā)送HTTP POST 消息，包括一個或多個application identifier 的變更；

（2）等待一段允許延遲的時間內(nèi)（例如，聚合多個application identifier 的所有PFD），然后向PCEF 發(fā)送一條HTTP POST 消息，其中包括要推送的PFD 更改。

當PCEF 收到HTTP POST 消息時，PCEF 應：

（1）如果對目標application identifier 沒有提供任何flag（標識），刪除當前所有PFD 并更新所有新PFD；

（2） 如果對目標application identifier 提 供removal-flag（刪除標識），則刪除所有當前PFD；

（3）如果對目標application identifier 提供partialflag（部分標識），則：

1）若提供了新PFD 則新增；

2）若提供已存在PFD id 的PFD，則更新；

3）若只提供PFD id 而沒有對應的PFD，則刪除。

圖6 4G中PFD推送流程

如圖7 所示，5G 中定義了PFD 變更通知流程，與4G 中push mode 推送內(nèi)容相似，但用于PFD 簽約流程中。PFDF 通過POST 推送變更標識符（如removalFlag、partialFlag）及PFD，NEF（PFDF）將從UDR（Unified Data Repository，統(tǒng)一數(shù)據(jù)存儲）取回的PFD 分發(fā)給可接入目標application identifier 的SMF[5]。

圖7 5G中PFD變更通知流程

對于push mode，在stage 2 定義三種將PFD 從NEF（PFDF）推送給SMF 的方法：

1）根據(jù)運營商在NEF（PFDF）的配置，將所有PFD 推送給SMF；

2）在PFD 集里有選擇的推送ASP 變更（即根據(jù)運營商配置定義何時推送）；

3）根據(jù)ASP 請求在PFD 集里有選擇的推送ASP 變更（即在允許時延里在一定時間間隔后推送）。

2 PFD管理優(yōu)化方法

由于在pull mode 中PFDF 會回復全部PFD 給PCEF/TDF/SMF，這樣會增加信令傳輸負荷，同時5G 在stage 3 沒有定義用于push mode 的方案，因此在3GPP R17 階段，CT3基于以上需求新增立項pfdManEnh，主要用以解決pull mode減少信令傳輸?shù)膯栴}及5GS 中定義push mode 優(yōu)化方案。

2.1 4G中pull mode優(yōu)化方法

在pre-R16 中，由于每次pull mode 執(zhí)行時，PFDF 都會推送全部application identifier 的PFD，在優(yōu)化方案中標識為full pull（全拉模式），如果全部采用此方法會增加PCEF/TDF 和PFDF 間的信令負荷。因此本優(yōu)化方案新增partial pull（部分拉模式），通過HTTP POST 消息只向PFDF 請求目標application identifier，即根據(jù)已有push mode 的方法，在每次收到PCEF/TDF 的請求時，PFDF 只推送有變更的（新建、更新或刪除）application identifier 的PFD。電信已將此方案在3GPP 會議上寫入TS 29.251 中，具體方案如下：

（1）當目標application identifier 的PFD 沒有變化時，PFDF 在HTTP 回復中不提供application identifier。

（2）當目標application identifier 的所有PFD 刪除時，PFDF 只提供application identifier，不提供任何PFD。

（3）當目標application identifier 的部分PFD 變化時，PFDF 應提供partial-flag 及更新的PFD。

（4）當目標application identifier 的所有PFD 變化時，PFDF 應提供所有新的PFD。

2.2 5G中pull mode優(yōu)化方法

在5G 中同樣增加partial pull，該優(yōu)化方案中，PFDF 每次推送PFD 時會攜帶“pfdTimestamp”（時間戳），在partial pull 模式時，SMF 會在POST 請求中帶時間戳，這樣PFDF 可以通過時間戳知道SMF 目前的PFD 版本，然后PFDF 可根據(jù)此回復SMF 需要新建、更新或刪除目標application identifier 的PFD。具體流程如圖8 所示：

圖8 Partial pull PFD請求流程圖

（1）SMF 應 在POST 中包括目標application identifier 及PFDF 在最新一次推送中攜帶的時間戳。

（2）如果PFDF 接受HTTP POST 請 求，PFDF 應回復目標application identifier、當前時間戳以及要新增、更新或刪除的PFD，即：

1）當目標application identifier 有新增PFD 時，提供有新PFD id 的PFD；

2）當目標application identifier 現(xiàn)有PFD 更新時，提供現(xiàn)有PFD id 的新PFD；

3）當目標application identifier 的現(xiàn)有某一PFD id對應PFD 刪除時，提供PFD id 但不提供任何對應PFD；

4）當目標application identifier 的PFD 刪除時，不提供任何PFD。

5G 中對push mode 也相應有所優(yōu)化，即在push mode 中會有 “pfdOp”屬性，包括“RETRIEVE”和“REMOVE”兩種選項，當“pfdOp”設置為“RETRIEVE”時，則SMF 會執(zhí)行full pull 或partial pull 模式。

2.3 優(yōu)化方案分析

表1 以4G 中pull mode 為例，從不同維度對優(yōu)化前后方案進行對比。優(yōu)化后在保留原有pull mode（即full pull）基礎上，新增了partial pull 模式，使用此模式可以減少信令傳輸量，同時對于兩種模式，未來也會在標準中明確機制來決定網(wǎng)絡何時使用full pull 或partial pull。

表1 4G pull mode優(yōu)化前后方案對比

此方案盡可能地減小對現(xiàn)有標準的改動，同時利用已存在的flag 及機制，既實現(xiàn)了減小PFDF 和PCEF/TDF/SMF 之間信令傳輸負荷，又不會引起pre-R16 規(guī)范的NBC（Non-backward Compatible，非后向兼容）問題。

3 結(jié)束語

PFD 管理使PCEF/TDF/UPF 能夠在ASP 提供PFD 時執(zhí)行準確的應用程序檢測，然后按照PCC 規(guī)則中的指示執(zhí)行操作。在3GPP pre-R16 中，pull mode 只有一種方式，即PFDF 將會推送給PCEF/TDF/SMF 所有PFD，這樣會增加PFDF 和PCEF/TDF/SMF 之間信令負荷。因此在PFD 管理中，從減小信令傳輸負荷及流程完整性的角度出發(fā)，對已在4G和5G 中定義的拉模式（pull mode）和推模式（push mode）進行了補充和優(yōu)化。減小信令傳輸負荷一直是通信運營商所追求的，本優(yōu)化方案是對4G/5G 中PFD 管理流程進行優(yōu)化，提高信令傳輸效率，預防出現(xiàn)信令風暴等問題。然而，目前在4G 和5G 中partial pull 的實現(xiàn)方式略有差異，在4G、5G協(xié)同中是否會有兼容問題，仍需要進一步探討。