5G MEC UPF選擇及本地分流技術(shù)分析

陳云斌　王全　黃強(qiáng)　白云龍

【摘? 要】邊緣計(jì)算的本質(zhì)是一場架構(gòu)革命，為滿足超低時(shí)延和超大帶寬等業(yè)務(wù)需求，應(yīng)用從傳統(tǒng)Client-Server架構(gòu)轉(zhuǎn)向Client-Edge-Server三級架構(gòu)，實(shí)現(xiàn)云網(wǎng)融合。在5G網(wǎng)絡(luò)中，如何為邊緣應(yīng)用選擇合適的UPF，實(shí)現(xiàn)高效的本地分流成為關(guān)鍵問題。為解決這個(gè)問題，分析了采用5G核心網(wǎng)基于UL CL上行分流、IPv6多歸屬或者LADN本地?cái)?shù)據(jù)網(wǎng)策略為MEC選擇UPF，以及MEC上的應(yīng)用能夠通過MEC與5G核心網(wǎng)控制面交互，動態(tài)或半動態(tài)選擇UPF的本地分流方法。研究表明，通過上述方法，可實(shí)現(xiàn)MEC UPF的靈活選擇及本地高效分流。

【關(guān)鍵詞】5G核心網(wǎng);MEC;UPF;本地分流

doi：10.3969/j.issn.1006-1010.2020.01.009? ? ? ? 中圖分類號：TN929.5

文獻(xiàn)標(biāo)志碼：A? ? ? ? 文章編號：1006-1010（2020）01-0048-06

引用格式：陳云斌，王全，黃強(qiáng)，等. 5G MEC UPF選擇及本地分流技術(shù)分析[J]. 移動通信， 2020，44（1）： 48-53.

0? ?引言

在2010年以前，基于2G/3G網(wǎng)絡(luò)的早期互聯(lián)網(wǎng)時(shí)代，業(yè)務(wù)和內(nèi)容相對貧乏，應(yīng)用Server基本上是集中式架構(gòu)，運(yùn)行在大型機(jī)或小型機(jī)上，典型場景如銀行、電信等行業(yè)。2010年開始，4G網(wǎng)絡(luò)讓互聯(lián)網(wǎng)業(yè)務(wù)爆發(fā)式增長，高性能、高并發(fā)、高可用的應(yīng)用需求驅(qū)動大型應(yīng)用系統(tǒng)從集中式架構(gòu)轉(zhuǎn)向分布式架構(gòu)，典型場景如阿里巴巴、騰訊等互聯(lián)網(wǎng)企業(yè)。

5G時(shí)代，為了滿足AR/VR、物聯(lián)網(wǎng)、工業(yè)自動化、無人駕駛等新業(yè)務(wù)帶來的高帶寬、低時(shí)延業(yè)務(wù)需求，將5G網(wǎng)絡(luò)進(jìn)行邊緣分布式重構(gòu)將成為必然選擇?；赟BA（Service-based Architecture）架構(gòu)的5G網(wǎng)絡(luò)，網(wǎng)元將控制面（CP）和用戶面（UP）分離，可以靈活地將用戶面下層到網(wǎng)絡(luò)邊緣，一跳直達(dá)，滿足毫秒級業(yè)務(wù)需求。5G網(wǎng)絡(luò)特征是去中心化[1-2]，C/U分離架構(gòu)與移動邊緣計(jì)算技術(shù)（MEC）方向吻合。MEC將云端分布式應(yīng)用下沉到電信網(wǎng)絡(luò)邊緣，與用戶面UPF結(jié)合，在業(yè)務(wù)第一出口提供算力。MEC改變現(xiàn)有網(wǎng)絡(luò)和業(yè)務(wù)分離的現(xiàn)狀（運(yùn)營商網(wǎng)絡(luò)管道化），實(shí)現(xiàn)云網(wǎng)融合。所以說，MEC的本質(zhì)是一場架構(gòu)革命，為滿足超低時(shí)延和超大帶寬業(yè)務(wù)需求，應(yīng)用Server將從Client-Server架構(gòu)轉(zhuǎn)向Client-Edge-Server架構(gòu)[4]，如圖1所示。

CES架構(gòu)的核心是云端業(yè)務(wù)與網(wǎng)絡(luò)的融合，高質(zhì)量的邊緣網(wǎng)絡(luò)出口是發(fā)展MEC的前提條件，也是運(yùn)營商發(fā)展MEC的核心優(yōu)勢。在5G網(wǎng)絡(luò)中，如何高效地為MEC選擇UPF，實(shí)現(xiàn)本地分流成為關(guān)鍵，也是本文討論的重點(diǎn)。

1? ?MEC與5G的關(guān)系

按照歐洲技術(shù)標(biāo)準(zhǔn)委員會ETSI的定義，MEC（Multi-access Edge Computing）[5]指在包含一種或者多種接入技術(shù)的接入網(wǎng)絡(luò)中，靠近用戶的網(wǎng)絡(luò)邊緣，提供無線網(wǎng)絡(luò)能力、IT業(yè)務(wù)環(huán)境和云計(jì)算能力的系統(tǒng)[6]。5G網(wǎng)絡(luò)下MEC與UPF（User Plane Function）的關(guān)系如圖2所示[3]。

具體來說，MEC是一個(gè)邊緣云平臺，通過與5G網(wǎng)絡(luò)結(jié)合（UPF是結(jié)合點(diǎn)），提供一種新的網(wǎng)絡(luò)架構(gòu)，將移動接入網(wǎng)與互聯(lián)網(wǎng)業(yè)務(wù)深度融合，一方面通過本地分流來降低時(shí)延，滿足用戶極致體驗(yàn)需求，并節(jié)省帶寬資源。另一方面將計(jì)算能力下沉到網(wǎng)絡(luò)邊緣位置，提供第三方應(yīng)用集成，為移動邊緣入口的服務(wù)創(chuàng)新提供了無限的想象空間。

2? ?MEC與5G交互框架

3GPP早期定義AF（Application Function）時(shí)，參考了IP多媒體系統(tǒng)架構(gòu)，即一個(gè)應(yīng)用產(chǎn)生的業(yè)務(wù)流可以分為控制面和用戶面。AF最早是多媒體業(yè)務(wù)的控制面，在與網(wǎng)絡(luò)中，與PCF（Policy Control Function）等交互，這樣可以簡化應(yīng)用控制面設(shè)計(jì)。

在5G網(wǎng)絡(luò)架構(gòu)中，5GC的控制面與用戶面分離，用戶面UPF可以靈活地下沉部署到網(wǎng)絡(luò)邊緣，而策略控制PCF以及會話管理SMF（Session Management Function）等控制面功能可以集中部署。5GC（5G Core Network）對外交互依然是控制面和用戶面。然而，OTT應(yīng)用架構(gòu)沒有控制面和數(shù)據(jù)面，基于HTTP的Web業(yè)務(wù)本質(zhì)上混合了業(yè)務(wù)控制和業(yè)務(wù)數(shù)據(jù)。因此，3GPP提出了邊緣計(jì)算AF的定義需求，MEC作為AF需要能夠從“業(yè)務(wù)控制面和/或業(yè)務(wù)用戶面”感知到OTT應(yīng)用的業(yè)務(wù)狀態(tài)，然后才能代表應(yīng)用和5GC交互。

MEC與5G交互框架如圖3所示：

當(dāng)5G網(wǎng)絡(luò)支撐邊緣計(jì)算時(shí)，Application Function向NEF（非授信域）或者向PCF（授信域）發(fā)送AF Request[1-2]，其中包含目標(biāo)DNN和S-NSSAI、應(yīng)用ID、N6路由需求、應(yīng)用位置（DNAI信息集）、UE信息、應(yīng)用移動性指示、空間和時(shí)間有效條件等一系列參數(shù)。PCF根據(jù)AF提供的這些信息參數(shù)，結(jié)合自身策略控制，為目標(biāo)PDU（Protocol Data Unit）Session業(yè)務(wù)流生成PCC規(guī)則，通過SMF為其選擇一個(gè)合適的UPF（如：靠近UE的DNAI），并配置UPF如何把目標(biāo)業(yè)務(wù)流通過N6接口傳輸?shù)侥繕?biāo)應(yīng)用實(shí)例。同時(shí)，5GC通過用戶面管理事件消息通知AF UPF位置改變，這樣AF可以對應(yīng)改變應(yīng)用的部署位置。此時(shí)，Application Function相當(dāng)于應(yīng)用控制面的角色，提供應(yīng)用與網(wǎng)絡(luò)控制面之間的交互。

3? ?5GC為MEC選擇UPF

5G MEC需要針對特定的流量進(jìn)行本地分流，在為用戶建立邊緣計(jì)算的用戶面承載時(shí)，首先要解決的問題是選擇UPF網(wǎng)元，實(shí)現(xiàn)本地流量分流。

5GC SMF可以根據(jù)來自終端設(shè)備的信息或者AF的請求來選擇UPF[1-2]。為了能縮短傳輸時(shí)延，提高傳輸效率，選擇UPF時(shí)，主要考慮因素包括：UPF的動態(tài)負(fù)載、支持相同DNN的UPF中的相對靜態(tài)容量、UPF位置、UE的位置、DNN、PDU會話類型、UE的簽約數(shù)據(jù)和本地運(yùn)營商策略等。

5G MEC為本地流量分流可以采用以下三種方案：上行分流（UL Classifier）、IPv6多歸屬（IPv6 Multi-homing）以及本地?cái)?shù)據(jù)網(wǎng)（Local Area Data Network）。

3.1? UL CL上行分流

針對IPv4、IPv6和以太網(wǎng)的PDU會話，由SMF決定給會話的數(shù)據(jù)路徑插入上行分類標(biāo)記（UL CL）。支持UL CL功能的UPF通過匹配SMF提供的流過濾器將某些流量進(jìn)行分流。在PDU會話建立過程中或者建立后，SMF可能決定在PDU會話的數(shù)據(jù)路徑上插入一個(gè)支持UL CL功能的UPF;或者在PDU會話建立之后刪除PDU會話的數(shù)據(jù)路徑上支持UL CL功能的UPF。SMF可能在PDU會話數(shù)據(jù)路徑上包含多個(gè)支持UL CL功能的UPF。UL CL目的是將滿足業(yè)務(wù)過濾規(guī)則的數(shù)據(jù)包轉(zhuǎn)發(fā)到指定的路徑去，這就有點(diǎn)像路由表的作用。

UE不感知UL CL的分流，不參與UL CL的插入和刪除。對于IPv4或IPv6或IPv4v6類型的PDU會話，UE將網(wǎng)絡(luò)分配的單一IPv4地址或者單一IP前綴或者兩者關(guān)聯(lián)到該P(yáng)DU會話。

當(dāng)一個(gè)UL CL被插入到一條PDU會話數(shù)據(jù)通道中時(shí)，這條PDU會話就有了多個(gè)錨點(diǎn)，這些錨點(diǎn)提供接入到同一個(gè)數(shù)據(jù)網(wǎng)絡(luò)的多條不同的路徑。UL CL的功能是將上行業(yè)務(wù)數(shù)據(jù)按照過濾器要求轉(zhuǎn)發(fā)到不同的PDU會話錨點(diǎn)，將該UE的多個(gè)錨點(diǎn)的下行數(shù)據(jù)合并。UL CL提供到不同的PDU會話錨點(diǎn)的上行流量的分流和到UE的下行流量的聚合，即聚合從不同PDU會話錨點(diǎn)發(fā)送到UE的流量。分流和聚合是根據(jù)SMF提供的流檢測和流轉(zhuǎn)發(fā)規(guī)則來實(shí)現(xiàn)的。UL CL采用流過濾規(guī)則（例如檢查UE發(fā)送的上行IP數(shù)據(jù)包的目的IP地址/前綴）來決定數(shù)據(jù)包如何路由。

圖4展示了一個(gè)PDU會話擁有兩個(gè)錨點(diǎn)的場景。上行分類器（UL CL）插在N3口終結(jié)點(diǎn)的UPF上，錨點(diǎn)1和錨點(diǎn)2終結(jié)N6接口，上行分類器UPF和錨點(diǎn)UPF之間通過N9接口傳輸。

該方案適用于訪問本地業(yè)務(wù)場景，如本地內(nèi)容訪問、企業(yè)網(wǎng)、增強(qiáng)移動寬帶（eMBB）場景本地分流業(yè)務(wù)和車聯(lián)網(wǎng)等。

3.2? IPv6多歸屬分流

一個(gè)PDU會話可能關(guān)聯(lián)多個(gè)IPv6前綴，這就是multi-homed PDU會話。多歸屬PDU會話通過多個(gè)PDU會話錨點(diǎn)訪問數(shù)據(jù)網(wǎng)絡(luò)（DN）。各個(gè)PDU會話錨點(diǎn)對應(yīng)的數(shù)據(jù)通道最后都會匯聚于一個(gè)公共的UPF，在這個(gè)公共UPF形成分支，這個(gè)公共的UPF被稱為支持“Branching Point ”功能的UPF。Branching Point UPF轉(zhuǎn)發(fā)上行流量到不同PDU會話錨點(diǎn)，并聚合發(fā)送到UE的下行流量，即聚合從不同PDU會話錨點(diǎn)發(fā)送到UE的流。

在PDU會話建立過程中或者建立后，SMF決定在PDU會話的數(shù)據(jù)路徑上插入或者刪除一個(gè)UPF以支持Branching Point功能。Branching Point UPF根據(jù)SMF下發(fā)的過濾規(guī)則，通過檢查數(shù)據(jù)包源IP地址進(jìn)行分流，向上轉(zhuǎn)發(fā)上行業(yè)務(wù)包到不同的PDU錨點(diǎn)去，向下將各個(gè)錨點(diǎn)下來的數(shù)據(jù)合并。IPv6多歸屬分流如圖5所示。

多歸屬PDU會話僅僅應(yīng)用于IPv6的PDU會話，UE在請求建立類型為IPv6或IPv4v6的PDU會話時(shí)，UE要告知網(wǎng)絡(luò)其是否支持Multi-homing IPv6 PDU會話。

該方案適用于物聯(lián)網(wǎng)、高可靠性專網(wǎng)等場景，但由于要采用IPv6，目前實(shí)施難度較大。

3.3? LADN本地?cái)?shù)據(jù)網(wǎng)絡(luò)

LADN[2]是和區(qū)域服務(wù)（應(yīng)用）相關(guān)聯(lián)的DN設(shè)計(jì)，當(dāng)用戶使用該應(yīng)用時(shí)，一定是通過LADN進(jìn)行訪問的，當(dāng)用戶的位置不在LADN的服務(wù)區(qū)內(nèi)時(shí)，不能接入LADN。通過LADN PDU會話接入DN只在特定的LADN服務(wù)區(qū)有效。LAND服務(wù)區(qū)用一組TA標(biāo)識，支持LADN是5G支持邊緣計(jì)算的會話管理機(jī)制之一。使用LADN用于邊緣計(jì)算流量分流時(shí)，通常LADN的TA和邊緣計(jì)算上應(yīng)用的服務(wù)區(qū)域是對應(yīng)的。

LADN信息，即LADN服務(wù)區(qū)信息和LADN DNN，以DN粒度配置在AMF中，對于不同的UE接入同一個(gè)LADN，LADN服務(wù)區(qū)都是相同的。SMF針對LADN DNN在AMF簽約“UE位置變化通知”。AMF跟蹤終端的位置信息，并通知SMF終端位置和LADN服務(wù)區(qū)的關(guān)系，包括：在服務(wù)區(qū)、不在服務(wù)區(qū)和不確定在不在服務(wù)區(qū)等。

4? ?MEC半靜態(tài)/動態(tài)配置5GC UPF

MEC本質(zhì)就是ICT融合平臺，邊緣應(yīng)用通過MEC平臺作為AF，與5GC對接，調(diào)用5G網(wǎng)絡(luò)能力，為邊緣應(yīng)用提供網(wǎng)絡(luò)服務(wù)。邊緣應(yīng)用可以根據(jù)業(yè)務(wù)需要，主動觸發(fā)5GC選擇邊緣UPF，包括半靜態(tài)方式和動態(tài)方式兩種。

4.1? 基于UE和App部署位置，半靜態(tài)配置PDU會話

MEC在應(yīng)用部署完成之后，通過AF向5GC配置分流規(guī)則，UE直接將PDU會話建立在邊緣UPF，MEC無需介入業(yè)務(wù)流程。采用半靜態(tài)部署邊緣分流，UE無論有無邊緣業(yè)務(wù)，網(wǎng)絡(luò)根據(jù)UE位置選擇接入邊緣UPF，并事先插入邊緣UPF的分流規(guī)則。這樣每個(gè)邊緣UPF上的分流規(guī)則可以盡可能地控制在最小集合，有利于提升UPF性能。

如圖6所示，半靜態(tài)配置模式以邊緣App部署為中心，讓5GC在UE會話建立階段選擇插入邊緣UPF并下發(fā)分流規(guī)則，一旦UE發(fā)起邊緣業(yè)務(wù)直接分流到邊緣應(yīng)用。這種方式不是以一個(gè)個(gè)UE會話流程為對象，而是以App部署為對象，讓5GC部署和流程來適配App部署。

4.2? 基于邊緣業(yè)務(wù)的AF交互，動態(tài)配置PDU會話

AF動態(tài)配置PDU會話模式是先發(fā)起邊緣業(yè)務(wù)，后插入邊緣UPF。一開始UE的PDU會話建立在全局集中UPF上，默認(rèn)所有業(yè)務(wù)流都從全局集中UPF出入。然后，MEC實(shí)時(shí)監(jiān)測該UE的業(yè)務(wù)流狀態(tài)，發(fā)現(xiàn)這個(gè)UE有邊緣業(yè)務(wù)即將或者已經(jīng)發(fā)起，通過動態(tài)下發(fā)規(guī)則將該業(yè)務(wù)導(dǎo)向邊緣UPF。

UE會話建立的PDU會話錨點(diǎn)位于集中UPF（如：省級UPF），此時(shí)5GC對于邊緣業(yè)務(wù)一無所知。UE應(yīng)用層的業(yè)務(wù)控制消息都只能從省級UPF出入，即UE和AF的初始交互過程只能從集中UPF出入。AF的本質(zhì)是應(yīng)用控制器，UE發(fā)起業(yè)務(wù)控制過程需要先和AF交互，這樣AF才能探測到UE需要發(fā)起業(yè)務(wù)。動態(tài)配置流程如圖7所示：

（1）UE與MEC交互，發(fā)現(xiàn)并發(fā)起邊緣業(yè)務(wù);

（2）MEC發(fā)現(xiàn)UE要發(fā)起邊緣業(yè)務(wù)，為其選擇邊緣業(yè)務(wù)Host，并通知5GC該業(yè)務(wù)DNAI（DN Access Identifier）等信息;

（3）PCF/SMF重新配置UE PDU會話UP路徑，插入邊緣UPF;

（4）動態(tài)配置PDU會話策略是先發(fā)起邊緣業(yè)務(wù)，后插入邊緣UPF。

AF動態(tài)配置需要包含兩個(gè)層面交互，即AF與5GC交互以及AF與UE交互。AF動態(tài)配置PDU會話首先需要考慮AF如何介入與UE之間的邊緣業(yè)務(wù)發(fā)起控制過程。

5? ?結(jié)束語

2020年以后，隨著5G網(wǎng)絡(luò)的規(guī)模建設(shè)，大量低時(shí)延、高帶寬的創(chuàng)新業(yè)務(wù)出現(xiàn)，CES將成為主流的應(yīng)用架構(gòu)。MEC將云端業(yè)務(wù)下沉到網(wǎng)絡(luò)邊緣，實(shí)現(xiàn)云網(wǎng)融合，運(yùn)營商分布在全國各地的邊緣DC資產(chǎn)將被盤活。運(yùn)營商依托邊緣網(wǎng)絡(luò)出口，結(jié)合無線網(wǎng)絡(luò)感知優(yōu)化和無線能力開放，將實(shí)現(xiàn)從連接管道向業(yè)務(wù)使能平臺跨越式轉(zhuǎn)型。

未來，運(yùn)營商邊緣機(jī)房的算力是稀缺資源，要用來處理高優(yōu)先級的低時(shí)延業(yè)務(wù)流，對于非實(shí)時(shí)性的業(yè)務(wù)流則會被調(diào)度到遠(yuǎn)端或者云端處理。也就是說，MEC UPF選擇及本地分流還需要結(jié)合運(yùn)營商網(wǎng)絡(luò)算力分布情況和業(yè)務(wù)需求，為業(yè)務(wù)選擇合適的算力位置，讓邊緣業(yè)務(wù)能夠調(diào)用不同機(jī)房的算力資源，實(shí)現(xiàn)業(yè)務(wù)、連接和算力的最佳匹配，這將是后續(xù)要重點(diǎn)研究的課題。

參考文獻(xiàn)：

[1]? ? 3GPP. 3GPP TS 23.501： System Architecture for the 5G System Stage 2 （Release 15）[S]. 2017.

[2]? ? 3GPP. 3GPP TS 23.501： System Architecture for the 5G System （5GS） Stage 2 （Release 16）[S]. 2019.

[3]? ? ETSI. ETSI White Paper No.28： MEC in 5G Networks[S]. 2018.

[4]? ? ETSI. ETSI White Paper No.24： MEC Deployments in 4G and Evolution Towards 5G[S]. 2018.

[5]? ? ETSI. ETSI GS MEC 001 V2.1.1： Multi-access Edge Computing （MEC）;Terminology[S]. 2019.

[6]? ?ETSI. ETSI GS MEC 003 V2.1.1： Multi-access edge computing （MEC）; framework and reference architecture[S]. 2019.

作者簡介

陳云斌（orcid.org/0000-0001-8688-6890）：學(xué)士畢業(yè)于重慶大學(xué)，現(xiàn)任中興通訊股份有限公司電信云及核心網(wǎng)產(chǎn)品規(guī)劃總工程師，主要研究方向?yàn)殡娦旁?、核心網(wǎng)及MEC，獲10項(xiàng)發(fā)明專利。

王全：學(xué)士畢業(yè)于南京大學(xué)，現(xiàn)任中興通訊股份有限公司電信云及核心網(wǎng)產(chǎn)品副總經(jīng)理，主要研究方向?yàn)殡娦旁?、核心網(wǎng)及MEC產(chǎn)品規(guī)劃，獲得多項(xiàng)國家發(fā)明和實(shí)用新型專利。

黃強(qiáng)：碩士畢業(yè)于上海大學(xué)，現(xiàn)任中興通訊股份有限公司系統(tǒng)架構(gòu)師，主要研究方向?yàn)?G系統(tǒng)及MEC，獲5項(xiàng)發(fā)明專利。