此係列文章作者分爲上中下三部分進行闡述，本文主要分享中部分內容，大綱簡述如下：
MEC 與 5G 融合
MEC 接入 5GC 的方式
MEP 的服務開發框架
上部分內容概要：
ETSI MEC 標準化參考模型
MEC 架構設計原則
ETSI MEC 存在的問題
下部分內容概要：
MEC 部署場景
MEC 在 4G 網絡中的部署
MEC 在 5G 網絡中的部署
MEC 應用場景
1、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 應支持如下功能：
1、在 PDU Session 建立時，5GC 爲用戶選擇部署在用戶接入側的 UPF。
2、支持業務的本地路由，由於 5GC 支持用戶通過多個 UPF 獲取服務的模式，用戶側的 UPF 可以只負責本地業務， 用戶發起的其他遠端服務將由其他 UPF執行。
3、流量引導功能，當存在多種本地業務時，區分業務類型並將流量引導到本地應用服務器。
4、保持會話和業務的連續性，確保業務體驗。
5、支持 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 相當於應用控制器的角色，提供應用與網絡控制面之間的交互。
2、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 接口的差異性。
3、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-3、CAPIF - 4 和 CAPIF-5 與 CAPIF core function 交互。對於非可信域內的 API provider domain function，則使用 CAPIF-3e、CAPIF-4e 和 CAPIF-5e 與可信域內的 CAPIF core function 交互。
4、MEP 的南向接口
MEP 定義了 3 個與 5G 網絡緊密關聯的 ME Services，分別是無線網絡信息服務、位置信息服務、帶寬管理服務。ME APP 可以調用這些服務的 API 優化其性能或者提供新的業務。比如：位置服務可以提供用戶室內定位，商業分析軟件可以利用位置服務統計分析商場室內人員流動信息，進一步優化室內商鋪業態。然而，MEC 目前並沒有定義這些 ME Service 如何獲取網絡信息與能力。當 MEC in 5G 部署，並進一步擴展無線接入網絡能力服務時，架構層面需要考慮這些接口。
3GPP 5G 系統架構中，核心網可以通過 NEF 向第三方 App 提供網絡。NEF 對外提供 3 種能力：
1、監控網絡狀態
2、爲外部應用提供諸如 UE 行爲等信息
3、對外提供策略配置能力
對於 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。