基於5GC 關鍵技術的 MEC 邊緣計算（中）

此係列文章做者分爲上中下三部分進行闡述，本文主要分享中部份內容，大綱簡述以下：

MEC 與 5G 融合
MEC 接入 5GC 的方式
MEP 的服務開發框架

上部份內容概要：

ETSI MEC 標準化參考模型
MEC 架構設計原則
ETSI MEC 存在的問題

下部份內容概要：

MEC 部署場景
MEC 在 4G 網絡中的部署
MEC 在 5G 網絡中的部署
MEC 應用場景

一、MEC 與 5G 融合

注：該章節主要參考 《5G邊緣計算演進》。

據估計，將應用服務器部署於無線網絡邊緣，可在無線接入網絡與現有應用服務器之間的回程線路（Backhaul）上節省高達 35% 的帶寬使用。2018 年，來自遊戲、視頻和基於數據流的網頁內容將佔據 84% 的 IP 流量，這要求移動網絡提供更好的體驗質量。利用邊緣雲架構，可以使用戶體驗到的網絡延遲下降 50%。

據 Gartner 報告，全球聯網的物聯網設備至 2020 年將高達 208 億臺。在圖像識別方面，服務器的處理時間增長 50-100ms，能提升 10%-20% 的識別準確率，這意味着在不對現有識別算法作改進的狀況下，經過引入移動邊緣計算技術，就可經過下降服務器同移動終端之間的傳輸時延改善識別效果。

爲了知足業務的低時延需求同時節省沒必要要的網絡傳送需求，5G 也引入了 MEC 的概念。其核心是將部分核心網功能和業務功能以及內容資源部署在靠近用戶的一側。其基本思想是把雲計算平臺從移動核心網絡內部遷移到移動接入網邊緣，實現計算及存儲資源的彈性利用。這一律念將傳統電信蜂窩網絡與互聯網業務進行了深度融合，旨在減小移動業務交付的端到端時延，發掘無線網絡的內在能力，從而提高用戶體驗，給電信運營商的運做模式帶來全新變革，並創建新型的產業鏈及網絡生態圈。

然而，MEC 在與 5G 融合的演進中，卻遇到了挑戰，主要有如下幾個方面：

本地分流：MEC 直接實現了本地分分流，但沒有制定數據計費以及合法監聽的完備標準，這是 5G 商用化必須面對的。

服務開放框架：MEP 經過 Mp1 向 ME APP 開放無線網絡能力服務，Mp1 是一個獨立的服務開放框架。但運營商 5G 網絡還有其餘能力也須要開放，好比核心網的策略配置能力。MEC 須要考慮如何將邊緣無線網絡能力服務與整個運營商的能力開放框架有機結合起來。

服務南向接口：MEC 定義了面向 ME APP 的無線網絡能力服務，即 ME Service。但 MEC 並無定義這些服務到底如何獲取 5G 無線接入網絡信息和能力。

容器化演進：MEC 目前基於虛擬機部署第三方應用程序，而愈來愈多的垂直行業應用正在以 Container 方式部署，所以 5G 時代，MEC 須要知足這些應用部署需求。

MEC in 5G 部署：5G RAN 既有 Central Unit 和 Distributed Unit分離架構，也有單基站模式，MEC 在 5G 系統部署時須要考慮 5G RAN 架構演進。

爲了支持 MEC，3GPP 標準規定 5GC 應支持以下功能：

一、在 PDU Session 創建時，5GC 爲用戶選擇部署在用戶接入側的 UPF。

二、支持業務的本地路由，因爲 5GC 支持用戶經過多個 UPF 獲取服務的模式，用戶側的 UPF 能夠只負責本地業務， 用戶發起的其餘遠端服務將由其餘 UPF執行。

三、流量引導功能，當存在多種本地業務時，區分業務類型並將流量引導到本地應用服務器。

四、保持會話和業務的連續性，確保業務體驗。

五、支持 QoS 和計費功能，MEC 包含了用戶平面的功能，5GC 能夠對其進行計費和 QoS 控制。

以上功能要求將經過會話管理、策略控制機制、QoS 和計費等技術方案具體實現。當 5G 網絡支撐邊緣計算時，MEC 做爲 AF（Application Function）向非授信域（NEF）或者向授信域（PCF）發送 AF Request，其中包含 Target DNN 和 S-NSSAI、Application ID、N6 路由需求、應用位置（DNAI 信息集）、UE 信息、應用移動性指示、空間和時間有效條件等一系列參數。

PCF 根據 AF提供的這些信息參數，結合自身策略控制，爲目標 PDU Session 業務流生成 PCC 規則，經過 SMF 爲其選擇一個合適的 UPF（如靠近用戶附件的位置），並配置 UPF 把目標業務流經過 N6 接口傳輸到目標應用實例。同時，5G 核心網經過用戶面管理事件消息通知 AF 有關 UPF 位置改變信息，這樣 AF 能夠對應改變應用的部署位置。此時，AF 至關於應用控制器的角色，提供應用與網絡控制面之間的交互。

二、MEC 接入 5GC 的方式

從 MEC 角度，UPF 能夠做爲 MEC Host 中 Data Plane 的具體實現，MEP 能夠經過 Mp2 接口來配置 UPF 的策略和行爲。然而，UPF 也會從 N4 接口受到 SMF/PCF 控制，爲了消除 N4 接口和 Mp2 接口的分歧與衝突，2018 年 3 月 ETSI MEC 經過了 5G CoreConnect Feature，將 MEC 做爲 AF 影響 5G 核心網的特性進一步標準化。

5G CoreConnect Feature 的具體內容包括：

MEC 系統能夠表明應用向 5G NEF 發送業務路由以及策略控制請求。

MEC 系統能夠從 5G NEF 或者其餘 5GC NF 接收通知（UP path management event 通知），根據通知消息信息（如 DNAI 標識的 UPF 位置），MEC 能夠選擇一個 ME Host 並在其上實例化的一個 ME APP。

MEC 系統能夠從 5G NEF 或者其餘 5GC NF 接收通知（UP path management event 通知），MEC 能夠利用通知內容支持 ME APP 重定位到一個特定 ME Host。

在 MEC System level：加入 5G Core connect proxy 做爲 System level 管理域與 5G 核心網交互的代理模塊，實現與 5G 核心網控制面消息交互與流程處理。這是由於，MEC 做爲一個多接入系統，還須要處理與 WiFi、固定接入網絡等其餘系統的交互消息，而 OSS 負責運維，MEAO 編排，從功能設計角度，將 5G CoreConnect 特性用一個代理模塊單獨實現，可讓 MEC 針對 5G 系統的交互獨立升級演進，以減小對 OSS 與 MEAO 的技術影響。當 MEC 系統在必定區域內的 ME Host 集羣上實例化 ME APP 以後，5G CoreConnect proxy 能夠將該 ME APP 及其實例分佈信息（如一組 DNAI 信息）經過 AF Request 發送給 5G 核心網，當 UE 向移動網絡發起該 ME APP 的業務請求時，5G 核心網就能選擇合適邊緣位置的 UPF，該 UPF 鏈接的 ME Host 上部署了相應的 ME APP 實例。同時，當 UE 移動致使 UPF 位置改變時，5G CoreConnect proxy 能夠接收從 5G 核心網發送過來的 UP path management event 消息，該消息指示了目標 UPF 位置信息，MEC 根據該信息判斷是否須要在相應的 Target ME Host 上新建該 ME APP 或者重定位該 ME APP。

在 MEC Host level：加入 5G CoreConnect Service，MEP 管控的 ME APP 經過該服務能夠動態觸發 MEC 對 5G 核心網的 AF Request。好比針對當前正在進行邊緣業務的某個 UE 使用業務狀況，ME APP 經過 5G CoreConnect Service 直接調整該 UE 的 5G 核心網路由策略。

經過上述在 MEC System level 和 MEC Host level 引入的 5G CoreConnect 特性實現功能，MEC 將以 AF 的身份無縫部署到 5G 系統中。

5G Core Connect Proxy

做爲 OSS、MEAO、MEPM 提供以 5GC 交互的代理模塊。當 OSS、MEAO 或 MEPM 在指定的 ME Host 上實例化 ME APP 後，經過 5G Core Connect Proxy 將會 ME APP 的特徵屬性以及位置信息告知 5GC NF。當 UE 訪問該 ME APP 時，5GC 就能夠根據這些信息選擇接入指定的 Edge UPF 並進行分流分流。當 UE 移動離開 Edge UPF 的覆蓋範圍時，5GC 就會將 UP path management event 經過 5G Core Connect Proxy 上報到 MEAO、MEPM，再由 MEAP、MEPM 統籌是否在新的區域中實例化 ME APP 並完成 ME APP 的重定位。

5G Core Connect Service
經過穩定開放的北向 API，爲 MEP、ME APP 提供 5GC 交互服務，做爲 MEP 本地分流和服務開發框架的底層支撐，屏蔽各廠商 5GC 接口的差別性。

三、MEP 的服務開發框架

Mp1 做爲 ME APP 獲取 MEP 提供的 ME Services 的參考點，運營商除了無線接入網能力服務以外，還有核心網能力服務也須要開放給 ME APP。然而，隨 Mp1 缺乏計費、接入控制等標準定義，商用化並不完善。3GPP SA6 爲了不運營商網絡能力服務開放框架的碎片化，正在 R15 階段定義一個通用的 API 開放框架結構，即 Common API Framework for 3GPP Northbound APIs（CAPIF）。

上圖中，API Invoker 是第三方 APP。APP 提供商和運營商之間有相應的服務協議，而且 API Invoker 能夠部署在運營商的可信域內。若是 API Invoker 部署在運營商的可信域內，則經過 CAPIF-1 和 CAPIF-2 與 CAPIF 交互。若是 API Invoker 部署在非可信域內，則經過 CAPIF-1e 和 CAPIF-2e 與 CAPIF 交互。對於可信域內 API provider domain 中的 API exposing function、API publishing function 以及 API management function，則 各 自 通 過 CAPIF-三、CAPIF - 4 和 CAPIF-5 與 CAPIF core function 交互。對於非可信域內的 API provider domain function，則使用 CAPIF-3e、CAPIF-4e 和 CAPIF-5e 與可信域內的 CAPIF core function 交互。

四、MEP 的南向接口

MEP 定義了 3 個與 5G 網絡緊密關聯的 ME Services，分別是無線網絡信息服務、位置信息服務、帶寬管理服務。ME APP 能夠調用這些服務的 API 優化其性能或者提供新的業務。好比：位置服務能夠提供用戶室內定位，商業分析軟件能夠利用位置服務統計分析商場室內人員流動信息，進一步優化室內商鋪業態。然而，MEC 目前並無定義這些 ME Service 如何獲取網絡信息與能力。當 MEC in 5G 部署，並進一步擴展無線接入網絡能力服務時，架構層面須要考慮這些接口。

3GPP 5G 系統架構中，核心網能夠經過 NEF 向第三方 App 提供網絡。NEF 對外提供 3 種能力：

一、監控網絡狀態
二、爲外部應用提供諸如 UE 行爲等信息
三、對外提供策略配置能力

對於 MEC 而言，ME Service 就像無線接入網絡（RAN）的 NEF，即一個屬於 RAN 的 Local NEF。MEC in 5G時，將挖掘更多 RAN 能力服務支持 5G 業務，尤爲是低時延高可靠的業務。以 V2X 爲例，因爲 V2X 業務涉及大量道路輔助安全應用，其部署會下沉到無線接入網的 MEC 邊緣雲，並對無線接入網絡鏈路性能指標有很是嚴格的要求。對於 MEC 而言，能夠基於 ME Service 將無線網絡信息狀態暴露給邊緣 V2X App，讓 V2X App 能夠實時監控無線接入網絡運行狀態並調整業務策略。同時 ME Service 能夠將邊緣 V2X App 的實時業務需求轉換爲對 RAN 的網絡優化操做（好比根據 App 業務實時質量進行實時多 RAT 傳輸加強等）。如此，MEC 提供從基站到應用之間的協同優化，爲 5G 業務提供完整的性能保障。因爲這些基於 RAN 的 ME Service 對於無線信息和控制時延具備極其嚴苛的指標要求，所以在架構層面，ME Service 須要與基站直聯，從而達到最高效的邊緣性能協同。

5G gBN 能夠經過雙向交互接口，直接向 MEP 開放無線接入網絡信息以及基站策略控制能力。MEC Platform 經過 ME Service（或者說 Local NEF），向 ME APP 提供無線接入網絡能力 API。