淺談5G 核心網(wǎng)N4 解耦的技術探討

［林國強 王鵬 張愛華］

1 引言

但長期以來，異廠商實現(xiàn)SMF（Session Management Function，即會話控制功能）與UPF 互通的N4 接口沒有統(tǒng)一標準，缺乏互操作性，最終造成SMF 與UPF 同廠商深度綁定[1]。從而對5G 的商用場景造成諸多限制，無法滿足向千行百業(yè)提供輕量化、低成本和靈活的部的業(yè)務需求[2]，急需推動行業(yè)提供支持N4 接口解耦的輕量化UPF。

2 5G 核心網(wǎng)簡介

核心網(wǎng)作為5G 網(wǎng)絡的大腦，為了適配未來不同服務的需求，5G 核心網(wǎng)絡架構(gòu)如圖1 所示，可見5G 核心網(wǎng)網(wǎng)元采用了SBA 架構(gòu)（Service Based Architecture，即基于服務的架構(gòu)），它基于軟件定義網(wǎng)絡（SDN）和網(wǎng)絡功能虛擬化（NFV）技術，將原來具備多個業(yè)務功能的整體，拆解成多個具有獨自功能的個體，并對外提供自己的服務。其中，UPF 作為5G 核心網(wǎng)與用戶側(cè)的契合點，是發(fā)展5G 行業(yè)應用、邊緣計算（MEC）業(yè)務的關鍵網(wǎng)元，配合控制面打通UE、RAN、DN 的通信通路，即會話/承載。北向接口支持N4 接口的策略控制，東西向接口支持N3、N6、N9，中間基于會話/承載轉(zhuǎn)發(fā)，為用戶提供高速可靠的數(shù)據(jù)傳輸。而N4 接口作為SMF 與UPF 之間的重要業(yè)務控制連接接口[3]，對接入的用戶下發(fā)各種業(yè)務數(shù)據(jù)轉(zhuǎn)發(fā)控制指令和數(shù)據(jù)轉(zhuǎn)發(fā)策略規(guī)則，引導UPF 依次按照不同業(yè)務等級完成數(shù)據(jù)轉(zhuǎn)發(fā)。

圖1 5G 核心網(wǎng)絡架

2.1 N4 接口解耦基礎知識

2.1.1 N4 接口協(xié)議（PFCP）

SMF 和UPF 之間的N4 接口使用的控制面協(xié)議是PFCP（Packet Forwarding Control Protocol）協(xié)議，主要用于傳輸SMF 和UPF 間的控制面及用戶面信息，通過該接口使控制面和用戶面配合完成用戶面規(guī)則下發(fā)和隧道建立功能。其控制層面的協(xié)議棧，如圖2 所示。

圖2 N4 控制面的協(xié)議

一般情況下，我們所了解的N4 接口主要用于UPF 和信令面NF 進行信令交互，但實際上N4 接口同時也涉及到部分用戶面數(shù)據(jù)包的傳輸。例如，處理下行數(shù)據(jù)包時在SMF 中進行緩存、DNN 網(wǎng)絡認證等場景，都需要通過N4 接口傳輸GTP 數(shù)據(jù)包。N4 接口的用戶面協(xié)議使用GTP-U，協(xié)議棧如圖3 所示。

我很少在拍攝時用超過ISO 1000的設置，所以如果我在室內(nèi)進行拍攝，就會讓拍攝對象坐在窗戶旁邊，這樣就能拍出一張對比鮮明的照片了。

圖3 N4 用戶面的協(xié)議

2.1.2 SMF 與UPF 偶聯(lián)建立信令（PFCP Association）

SMF 與UPF 之間互通對接的第一步應首先建立一個偶聯(lián)PFCP Association，并且需要在傳遞PFCP Session 相關信令之前建立。PFCP Association 的發(fā)起方可以是CP（SMF）節(jié)點也可以是UP（UPF）節(jié)點，但是CP 節(jié)點默認必須一定可以發(fā)起PFCP Association 的建立，而由UP節(jié)點觸發(fā)PFCP Association 的建立則是作為可選功能。因此，SMF 和UPF 之間的偶聯(lián)建立發(fā)起在異廠家設備互通對接時需要注意。CP 節(jié)點和UP 節(jié)點偶聯(lián)建立的關鍵信息可通過唯一的Node ID 進行識別，而Node ID 可以是FQDN 或者IP 地址。

2.1.3 SMF 與UPF 會話建立信令（PFCP Session）

SMF 與UPF 之間互通對接的第二步是在建立PFCP Association 基礎之上，進行PFCP Session 相關的流程。對于PFCP Session 的建立、更新、釋放的發(fā)起者只能由SMF。另 外，PFCP Session 和UE 的PDU Session 的 建立是強相關的，一般情況下一個PDU Session 對應一個PFCP Session。當存在匹配不上任何PFCP Session 的數(shù)據(jù)包時，通常處理操作就是直接丟棄或者轉(zhuǎn)發(fā)給SMF 處理。UE 在發(fā)起數(shù)據(jù)業(yè)務的時候都會創(chuàng)建一個PDU Session。在SMF 發(fā)送UPF 的PFCP Session Establishment 流程中就會創(chuàng)建一個PFCP Session。PFCP Session Establishment 流程的結(jié)果就是在UPF中創(chuàng)建一個PFCP Session Context（PFCP Session 上下文），后續(xù)用戶面數(shù)據(jù)包的轉(zhuǎn)發(fā)都是基于查找PFCP Session Context 來完成的。PFCP Session Context就是UPF 保存的PDR、FAR 等數(shù)據(jù)轉(zhuǎn)發(fā)規(guī)則，并將UE的標識信息（UE IP 地址等）、PDU Session ID、PDR（Packet Detection Rule）、FAR（Forwarding Action Rule）、URR（Usage Reporting Rule）、QER（QoS Enforcement Rule）、BAR（Buffering Action Rule）等規(guī)則信息關聯(lián)起來的數(shù)據(jù)結(jié)構(gòu)，UPF可以根據(jù)這個數(shù)據(jù)結(jié)構(gòu)中記錄的規(guī)則進行數(shù)據(jù)包轉(zhuǎn)發(fā)。

2.1.4 UPF 數(shù)據(jù)包轉(zhuǎn)發(fā)流程

UPF 依 據(jù)SMF 下 發(fā) 的PDR、FAR、QER、URR、BAR 等規(guī)則執(zhí)行數(shù)據(jù)包的轉(zhuǎn)發(fā)。當數(shù)據(jù)包進入到UPF 后，首先執(zhí)行的是PDR；再根據(jù)PDR 中包含的PDI（Packet Detection Information）信息來與數(shù)據(jù)包進行匹配，之后對匹配上的數(shù)據(jù)執(zhí)行FAR 關聯(lián)的FAR、QER 中定義的規(guī)則。其轉(zhuǎn)發(fā)流程如圖4 所示。

圖4 數(shù)據(jù)轉(zhuǎn)發(fā)流程

（1）SMF 向UPF 下發(fā)一對PDR，UPF 收到的這一對PDR 均用于后續(xù)數(shù)據(jù)報文轉(zhuǎn)發(fā)的匹配條件。

（2）用戶報文從基站（gNB）到達UPF。

（3）UPF 對用戶報文進行匹配，查找用戶所屬PDU（Protocol Data Unit）Session。

（4）UPF 根據(jù)PDR 優(yōu)先級、報文中的關鍵信息（如域名、IP 等）進行PDR 匹配，命中PDR。

（5）UPF 根據(jù)PDR 中的相關信息以及本地配置的相關規(guī)則信息等，執(zhí)行數(shù)據(jù)流的相關動作并轉(zhuǎn)發(fā)到Internet。

（6）對于下行數(shù)據(jù)，UPF 進行類似的轉(zhuǎn)發(fā)流程，查找用戶的PDU 之后，對報文進行匹配、命中PDR 并轉(zhuǎn)發(fā)，最終到達UE。

3 異廠商UPF 與SMF 解耦技術方案探討

在開放N4 解耦之前，3GPP 對于CP 節(jié)點和UP 節(jié)點之間定義的N4 接口功能實現(xiàn)現(xiàn)狀，既存在功能實現(xiàn)方案的冗余，即為實現(xiàn)同一功能特性有多種實現(xiàn)方案，由廠家自行選擇；又存在常用功能技術方案缺失，一些在現(xiàn)網(wǎng)中常用的功能特性由廠家私有實現(xiàn)完成，缺乏標準化支撐。上述原因直接導致了N4 接口缺乏互操作性。而N4 接口的全面開放，結(jié)合運營商與廠商的最佳實踐，提升N4 接口標準化程度，無疑將解決當前設備功能復雜、容量起步過大、與SMF 同廠商綁定的現(xiàn)狀，從而有利于降本增效，同時滿足行業(yè)客戶的多樣化需求。當形成標準化后，為電信運營商推進開放、可靠、靈活、可管的UPF提供標準支持。將會有更多的產(chǎn)業(yè)鏈廠商參與其中，降低產(chǎn)業(yè)進入門檻，繁榮產(chǎn)業(yè)生態(tài)；也將給電信運營商更多的選擇，從而達成降低網(wǎng)絡建設成本的目標，也降低了5G 進入千行百業(yè)的門檻。

為更好實現(xiàn)N4 接口解耦的目標，目前業(yè)界進行了創(chuàng)新性的實踐與探索，形成了以下幾種主流解決方案。

3.1 方案一：直接解耦

由運營商牽頭，聯(lián)合各設備制造廠商共同推進N4 接口的開放與標準化，構(gòu)建開放合作聯(lián)盟，進行設備之間的直接解耦。

該方案以運營商設備集采作為主要推動力，協(xié)調(diào)主流廠商（華為、中興等設備制造廠商）進行UPF 和SMF 的直接解耦，但是截止到目前三大運營商的直接解耦測試均無突破。其主要原因初步分析，有以下幾點。

（1）主流廠商對開放N4 解耦的積極性不高，導致測試進度慢，原因不言而喻。

（2）主流廠商針對某些關鍵功能項的實現(xiàn)機制完全不一樣，如ULCL 分流功能就無法直接解耦互通。

（3）主流廠商對3GPP 規(guī)范定義的信元和條款理解有偏差，但是均能實現(xiàn)此功能。如UPF 和SMF 進行偶聯(lián)建立時，SMF 設備只識別IP，UPF 只識別FQDN，出現(xiàn)此類功能實現(xiàn)方式二選一的互通情況，只能協(xié)調(diào)廠商研發(fā)進行修改版本，否則無法推進測試，偶聯(lián)是互通的第一步。在互通測試過程中為實現(xiàn)同一功能特性有多種實現(xiàn)方案，由廠家自行選擇，導致解耦失敗的例子比比皆是。

因此，主流廠商直接互通難度是位列所有解耦方案中最難的一個。

3.2 方案二：主動適配解耦

由運營商自主研發(fā)5G 用戶面UPF 設備，與主流廠商5G 核心網(wǎng)進行解耦對接。

該方案解耦的進展已超預期，截止到目前三大運營商均已先后實現(xiàn)。

（1）中國電信基于自主研發(fā)的輕量級UPF 設備URANUS 1000S。

（2）中國移動主導的首批Open UPF 功能及一致性驗證測試。

（3）中國聯(lián)通首批白盒UPF 功能和N4 接口的兼容性驗證測試。

可見，運營商在推動解耦是篤定前行，不遺余力解難題，加快推進與實施。特別是在與主流廠商互通測試過程中出現(xiàn)廠商私有化定制、非標準化的信元和功能實現(xiàn)流程和邏輯各異的情況下，運營商研發(fā)的UPF 均能較好的進行適配，實現(xiàn)既能支持華為又能支持中興的SMF 等主流廠商的解耦測試。

因此，運營商自主研發(fā)互通難度適中，其關鍵在于與主流廠商對齊解耦必需的信元、流程和邏輯機制，否則無法解耦。

3.3 方案三：間接解耦

由第三方開發(fā)中間件進行信令面與主流廠商5G 核心網(wǎng)進行解耦對接；

該方案實現(xiàn)的原理是通過第三方的中間件C-IWF（Customized-Inter Working Function，定制化信令互通網(wǎng)關）作為UPF 和SMF 的信令中轉(zhuǎn)站，由它負責將主流廠商SMF 的控制信令轉(zhuǎn)換（或透傳）成異廠商UPF“聽得懂”的信令，從而完成解耦。因為引入了定制化信令互通網(wǎng)關，對SMF 和UPF 的改動最小，解耦最方便。通過此方案可以很好的解決主流廠商無法解耦的部分關鍵功能，如前面提到的ULCL 分流，如圖5 所示。

圖5 中間件解耦示意圖

綜上所述，根據(jù)N4 接口解耦的技術難度對比分析，3 種解耦方案既有利也有弊。但本文建議遵循設備改動最小、低成本和互操作性較強的原則，優(yōu)先選擇解耦方案三，次之方案二，最后方案一。

4 總結(jié)

5G 核心網(wǎng)在建設過程中面臨著各種挑戰(zhàn)，UPF 作為核心網(wǎng)用戶面的關鍵設備，系統(tǒng)級的UPF 部署和維護成本相對較高，UPF 與SMF 同廠商的綁定，運營商也將承擔較高的網(wǎng)絡部署成本。為此，促使UPF 朝著更加開放、可靠、可管、靈活的方向發(fā)展；建議優(yōu)先選用解耦方案三，共同推動N4 接口解耦與構(gòu)建開放產(chǎn)業(yè)生態(tài)，實現(xiàn)網(wǎng)絡平滑演進以及高效、低成本維護已成為運營5G 網(wǎng)絡成敗的關鍵。