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

孫悅，龍彪

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

0 引言

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

1 PFD管理方法

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

PFD 主要有如下信息組成：

◆PFD id；

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

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

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

◆域名匹配標(biāo)準(zhǔn)和適用協(xié)議的信息。

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

圖2 Gwn參考模型

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

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

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

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

圖4 4G中PFD請求流程

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

◆在HTTP 回復(fù)中提供目標(biāo)application identifier 的PFD；

◆如果有配置的緩存時間值，則應(yīng)在HTTP 回復(fù)中設(shè)置緩存時間。如果PFDF 回復(fù)消息中不包括緩存時間值，則設(shè)置為已配置在PCEF 中的缺省緩存時間值。

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

圖5 5G中PFD請求流程

如果請求成功，則PFDF 將回復(fù)目標(biāo)application identifier 的PFD 及緩存時間值（如果有配置）。如果PFDF 沒有回復(fù)目標(biāo)application identifier，則SMF 應(yīng)刪除該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。當(dāng)從SCEF 收到新建、更新或刪除某application identifier 的請求時，對于push mode，PFDF 應(yīng)針對它服務(wù)的每個PCEF 選擇執(zhí)行如下操作：

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

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

當(dāng)PCEF 收到HTTP POST 消息時，PCEF 應(yīng)：

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

（2） 如果對目標(biāo)application identifier 提 供removal-flag（刪除標(biāo)識），則刪除所有當(dāng)前PFD；

（3）如果對目標(biāo)application identifier 提供partialflag（部分標(biāo)識），則：

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

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

3）若只提供PFD id 而沒有對應(yīng)的PFD，則刪除。

圖6 4G中PFD推送流程

如圖7 所示，5G 中定義了PFD 變更通知流程，與4G 中push mode 推送內(nèi)容相似，但用于PFD 簽約流程中。PFDF 通過POST 推送變更標(biāo)識符（如removalFlag、partialFlag）及PFD，NEF（PFDF）將從UDR（Unified Data Repository，統(tǒng)一數(shù)據(jù)存儲）取回的PFD 分發(fā)給可接入目標(biāo)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 會回復(fù)全部PFD 給PCEF/TDF/SMF，這樣會增加信令傳輸負(fù)荷，同時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)化方案中標(biāo)識為full pull（全拉模式），如果全部采用此方法會增加PCEF/TDF 和PFDF 間的信令負(fù)荷。因此本優(yōu)化方案新增partial pull（部分拉模式），通過HTTP POST 消息只向PFDF 請求目標(biāo)application identifier，即根據(jù)已有push mode 的方法，在每次收到PCEF/TDF 的請求時，PFDF 只推送有變更的（新建、更新或刪除）application identifier 的PFD。電信已將此方案在3GPP 會議上寫入TS 29.251 中，具體方案如下：

（1）當(dāng)目標(biāo)application identifier 的PFD 沒有變化時，PFDF 在HTTP 回復(fù)中不提供application identifier。

（2）當(dāng)目標(biāo)application identifier 的所有PFD 刪除時，PFDF 只提供application identifier，不提供任何PFD。

（3）當(dāng)目標(biāo)application identifier 的部分PFD 變化時，PFDF 應(yīng)提供partial-flag 及更新的PFD。

（4）當(dāng)目標(biāo)application identifier 的所有PFD 變化時，PFDF 應(yīng)提供所有新的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ù)此回復(fù)SMF 需要新建、更新或刪除目標(biāo)application identifier 的PFD。具體流程如圖8 所示：

圖8 Partial pull PFD請求流程圖

（1）SMF 應(yīng) 在POST 中包括目標(biāo)application identifier 及PFDF 在最新一次推送中攜帶的時間戳。

（2）如果PFDF 接受HTTP POST 請 求，PFDF 應(yīng)回復(fù)目標(biāo)application identifier、當(dāng)前時間戳以及要新增、更新或刪除的PFD，即：

1）當(dāng)目標(biāo)application identifier 有新增PFD 時，提供有新PFD id 的PFD；

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

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

4）當(dāng)目標(biāo)application identifier 的PFD 刪除時，不提供任何PFD。

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

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

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

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

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

3 結(jié)束語

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