此係列文章作者分爲上中下三部分進行闡述，本文主要分享下部分內容，大綱簡述如下：
MEC 部署場景
MEC 在 4G 網絡中的部署
MEC 在 5G 網絡中的部署
MEC 應用場景
上部分內容概要：
ETSI MEC 標準化參考模型
MEC 架構設計原則
ETSI MEC 存在的問題
中部分內容概要：
MEC 與 5G 融合
MEC 接入 5GC 的方式
MEP 的服務開發框架
MEC 與 5G 融合架構示
1
MEC 部署場景
設計 MEC 解決方案時，還必須考慮 MEC 服務器在網絡中的位置。例如：可以位於 4G LTE eNB（宏基站）側、3G RNC（Radio Network Controller，無線網絡控制器）側、multi-RAN（multi-Radio Access Technology，多無線接入技術）蜂窩匯聚點側以及核心網側。
MEC 在 4G 網絡中的部署
MEC 的概念早在 4G 建設的前期就已經被提出，所以 MEC 在 4G 和 5G 網絡中均可部署。但是在 4G 網絡中因爲 MEC 提出時 LTE 網絡標準已完成制定，所以 4G 網絡下的 MEC 部署目前大多采用非標的串聯部署或者廠家私有標準部署模式，在計費、監聽、業務移動性支持方面並不完善。
MEC 部署在 RAN（無線接入網）側 ：MEC 可以部署在單個 eNB 節點之後，也可以部署在多個 eNB 的匯聚節點之後，這是 4G 中比較常見的部署方式。稱爲無線側 TOF（Traffic Offload）。這種部署方式適合用於學校、大型購物中心、體育場館等熱點區域下。將 MEC 部署在 RAN 側的優勢在於可以更方便地通過監聽、解析 S1-C 接口的信令來獲取基站側無線相關信息，也可以通過解析 S1-U 接口的 GTP-U 報文將業務數據流量卸載到邊緣進行處理，以此降低網絡時延到毫秒級。但是該方案需要進一步解決計費和合法監聽等安全性問題。
MEC 服務器部署在 CN（核心網）側：MEC 部署在 PGW 之後（或與 PGW 集成在一起）。這種方式可以解決 RAN 側部署方案下的計費和安全問題，但在 C/U 沒有分離 4G EPS 架構中，MEC 部署的位置通常與用戶距離較遠，存在時延較大和佔用核心網資源的問題。好處就是該方案不需要改變現有的 EPC 架構，而且 SGi 接口出來的是 IP 報文，也就不需要 MEC 去處理 GTP 報文解析了。
而在 4G EPC CUPS 架構中，PGW 被拆分成了 PGW-C 和 PGW-U（即 DGW）。其中，PGW-C 駐留在原位置，DGW 下沉到 RAN 側或者核心網邊緣，DGW 負責計費、監聽、鑑權等功能，也解決了網絡時延大的問題。缺點在於，4G C/U 分離技術並不完全，PGW-C 和 DGW 之間爲私有接口，需要由同一設備廠商提供。
2、MEC 在 5G 網絡中的部署
3GPP 的 5G 核心網在標準上天然支持用戶數據面的下沉及邊緣計算的部署，解決了 4G 網絡中 MEC 部署存在的計費監聽等問題。ETSI MEC 規範包括了用戶數據平面功能以及邊緣計算平臺功能，而 3GPP 的 5G 標準裏面主要定義了 UPF 網元，UPF 作爲 5GC 的用戶面下沉網元，關注的是網絡功能。兩大組織一直在合作推進將 UPF 作爲 MEC 系統中的一個組成網元，充當 DP 模塊，UPF 負責將邊緣網絡的流量卸載到 MEC 平臺。邏輯上 UPF 與 MEC 平臺是鬆耦合的，一般認爲 5G 場景中 MEC 與 UPF 的關係如下圖所示：
實際建設時對於 MEC 與 UPF 是否合設集成部署與統一承載存在以下多種方案：
MEC 與 UPF 集成部署，基於 ICT 綜合邊緣雲統一承載：建設包括 UPF 在內的統一 MEC 系統， MEC 系統的建設也通常被鎖定在提供 UPF 的核心網廠家，MEC 業務系統與 UPF 共享 NFV 電信邊緣雲基礎設施以及統一納管，節約部分投資，另外靠近基站的邊緣接入點資源比較緊張，集成部署有利於資源的充分利用。但是該方案需要既可以滿足 UPF 等 NFV 高性能網絡轉發處理需求，還需要支持 IT 類業務應用的容器化部署與編排管理、邊緣 AI 類以及視頻類業務應用的 GPU/FPGA 等加速及異構計算處理，之前主要面向網絡通信處理的 NFV 電信雲需要擴展成爲 ICT 綜合邊緣雲，包括 MANO 也需要相應的擴展。
MEC 與 UPF 分離部署，基於不同的邊緣雲各自承載：MEC 業務系統與 UPF 分離部署，支持分廠家建設，支持引入 IT 廠家或者自研提供 MEC 業務系統，並且 UPF 作爲 5G 核心網元，與承載自有及第三方業務應用的 MEC 業務系統物理隔離也有利於 5G 網絡的安全保障。但是該方案下 MEC 業務系統如果提供網絡流量業務鏈處理類服務，不能與 UPF 共享網絡處理，有一定的重複投資，並且部分資源受限的邊緣點也很難建設提供兩朵邊緣雲，兩朵雲的利用率不如集成部署的統一邊緣承載方案。
MEC 與 UPF 部分共享部署：MEC 業務系統分爲 CT 類 VNF 與 IT 類 APP 兩大類業務服務，其中 CT 類 VNF 與 UPF 統一承載集成部署，IT 類 APP 獨立部署。對於 CT 類業務服務共享 NFV 邊緣雲，仍然由運營商網絡運維部門負責統一運營管理。同時獨立建設 IT 邊緣雲，滿足 IT 類邊緣業務靈活性，這部分 IT 邊緣雲可以考慮由運營商負責公有云的部門統一集約運營。這種模式的問題在於增加了邊緣業務的統一管理複雜度，同時部分融合業務也很難簡單的是化爲 IT 類還是 CT 類業務，比如遠程駕駛控制等。
3、ME Host 的部署方案
5G 網絡原生採用雲化建設，更加輕盈和靈活，以中心 DC（大區中心機房）、區域 DC（省層面機房）、核心 DC（本地網核心機房）、邊緣 DC（本地網匯聚機房）、接入局所 DC、基站機房爲基礎架構的分層 DC 化機房佈局模式成爲各運營商傳統機房改造演進的共同路線。
其中，MEC 系統級網管（包括 MEPM、MEAO）需要協調不同 ME Host（包括 MEP、UPF、ME APP）之間以及 ME Host 與 5GC 之間的操作（e.g. 選擇主機、應用遷移、策略交互等），一般部署在區域 DC（省層面）或者中心 DC（大區中心）；而 ME Host 部署方面應以業務爲導向按需部署，並與 UPF 的下沉和分佈式部署相互協同，在實際組網中，根據對操作性、性能或安全的相關需求，ME Host 可以靈活地部署在從基站附近到中央數據網絡的不同位置。但是不管如何部署，都需要由 UPF 來控制流量指向 ME APP 或是指向網絡。下圖概述了 ME Host 物理位置的一般可行選項。
ME Host 在接入局所 DC：此種模式一般採用 ME Host 和基站 CU 共機房，部署在基站後面，數據業務離用戶更近，終端發起的業務經過基站、ME Host 到互聯網/第三方內容服務，主要針對新型超低時延業務在邊緣才能滿足需求的場景，時延可控制在 1ms-10ms 之內，例如：無人機投遞業務（10ms，15Mbit/s）、智慧場館（10ms，1Gbit/s）、自動駕駛（1ms，50Mbit/s以上）、遠程醫療診斷（10ms，50Mbit/s）、機器人協作（1ms，110Mbit/s）、遠程手術（1ms10ms，300Mbit/s）等。
ME Host 部署在邊緣 DC：此種模式 ME Host 一般部署在本地網匯聚機房，邏輯位置在 UPF/PGW-U 之後，會增加一部分回傳網絡的時延，可以爲用戶提供低時延、高帶寬服務，例如：AR/VR業務（20ms，1Gbit/s）、移動視頻監控（20ms，50Mbit/s）、移動廣播（小於100ms，10Mbit/s）、公共安全（20ms，10Mbit/s）、高清視頻（20ms，10Mbit/s）等。
4、MEC 應用場景
MEC 應用於 VR
基於 5G 的 MEC 解決方案，該方案適用於 VR 這一典型應用場景。MEC 部署在 RAN 或 C-RAN 側以獲取利於統計分析的關鍵信息，提供低時延的本地化業務服務。運營商不僅可以有效減少核心網的網絡負載，還能通過本地化的部署，提供實時性高、低時延的 VR 體驗，增強 VR 實時互動。
MEC 應用於在線視頻系統
下述爲英特爾中國研究院與英特爾網絡平臺事業部、中國移動及愛奇藝合作開發的一款在線視頻系統。該系統利用 MEC 進行視頻加速，視頻提供商利用 MEC 的計算、存儲和網絡功能，通過對用戶視頻請求數據分組進行分析，爲特定的高清付費用戶提供充足帶寬，以保證其觀看體驗。OTT（互聯網應用服務） 在使用上述系統時，無需對自己的應用網絡進行架構性變動，由此可以大幅降低使用成本，加速業務創新。該系統目前已在業界知名的世界移動通信大會（Mobile World Congress，MWC）上現身，並引起廣泛關注，並被 ETSI MEC ISG 採納爲典型業務場景之一。
MEC 應用於支持 OTT 業務
中國聯通在 2018 年 3 月首次參與 ETSI MEC 標準化工作。在 MEC#13 次會議中，中國聯通主導的《PoC12：MEC Platform to Enable OTT Business》國際標準項目成功立項，獲得審覈委員會全票通過。這是 ETSI 在邊緣計算領域首個實現 ICT（IT&CT）融合的立項，填補了 MEC 應用研究方面的空白。自此，中國聯通牽頭開啓了 ETSI MEC 標準化組織與 OTT（互聯網應用服務）的應用合作，具有里程碑式的重要意義。
如下這張中國聯通的構架圖所示，電信運營商將部份服務移到 MEC 上，而開發者（OTT 提供者，如 Youtube 或愛奇藝）及用戶，可以透過一些服務化的 API 來存取電信運營商於此 MEC 上提供的服務。
該立項建議由中國聯通聯合中興通訊、INTEL 共同向 ETSI MEC#13 提交，並由中國聯通網絡研究院標準專家進行立項申請陳述和答辯。該標準項目將基於業界最大的天津邊緣雲測試牀，依託輕量化 OpenStack、Kubernetes 等虛擬化技術，以商用化部署爲目標，研究 vCDN、VR/AR 等 OTT 應用對 MEC 邊緣雲業務平臺能力及 API 的需求，併爲 ETSI GS MEC 003 系統架構的進一步完善提供強有力的參考依據。
目前 MEP 平臺的最大的問題就是平臺封閉性嚴重，不同廠家平臺制式不同很難互通，接口私有化定義。造成的後果就是一旦規模部署，每款 APP 都要分別部署在各方開發的 MEP 上，因此就都要針對各家平臺進行定製化的開發和業務對接，這種不友好的方式是不會被第三方 APP 所接收，因爲這種方式極大地增大了第三方的業務重複開發和維護工作。目前的解決方法是，由運營商主導 MEP 平臺，同時由運營商統一開展平臺接口標準化和平臺架構標準化，集合設備商的各類平臺能力和資源，這樣第三方 APP 只需要一次開發和對接即可實現快速業務部署，對第三方 APP 非常友好，平臺也更爲開放。