此係列文章作者分爲上中下三部分進行闡述，本文主要分享上部分內容，大綱簡述如下：
ETSI MEC 標準化參考模型
MEC 架構設計原則
ETSI MEC 存在的問題
中部分內容概要：
MEC 與 5G 融合
MEC 接入 5GC 的方式
MEP 的服務開發框架
MEC 與 5G 融合架構示
下部分內容概要：
MEC 部署場景
MEC 在 4G 網絡中的部署
MEC 在 5G 網絡中的部署
MEC 應用場景
1、MEC 邊緣計算
MEC（Mobile Edge Computing，移動邊緣計算）概念最初於 2013 年出現。IBM 與 Nokia Siemens 當時共同推出了一款計算平臺，可在無線基站內部運行應用程序，並向移動用戶提供業務。ETSI（European Telecommunications Standards Institute，歐洲電信標準協會）於 2014 年成立移動邊緣計算規範工作組（Mobile Edge Computing Industry Specification Group），正式宣佈推動移動邊緣計算標準化。2016 年，ETSI 把 MEC 的概念擴展爲多接入邊緣計算（Multi-Access Edge Computing），將邊緣計算從電信蜂窩網絡進一步延伸至其他無線接入網絡（如 WiFi）。
下圖是 ETSI 在 MEC 白皮書中列出的 MEC 相關應用，包含了遠程手術（Remote surgery）、自動駕駛車（Autonomous car）、AR 等等要求低延時的應用。
在未來，MEC 將構成一個龐大的生態圈，包含了用戶、電信商、內容分發、設備商以及服務開發商等等。
2、ETSI MEC 標準化參考模型
ETSI 在 2014 年率先啓動了 MEC 標準化參考模型項目。該項目組旨在移動網絡邊緣爲（自己、合作伙伴或第三方）應用開發商與內容提供商構建一個雲化的計算與 IT 服務平臺，並通過該服務平臺開放無線側網絡信息，實現高帶寬、低時延業務支撐與本地管理。ETSI
MEC 標準化的主要內容包括：研究 MEC 需求、平臺架構、編排管理、接口規範、應用場景研究等。
在 2017 年底，ETSI MEC 標準化組織已經完成了第一階段（Phase I）基於傳統 4G 網絡架構的部署，定義了 MEC 的應用場景、參考架構、邊緣計算平臺應用支撐 API、應用生命週期管理與運維框架、以及無線側能力服務 API（RNIS/定位/帶寬管理）。
3、MEC 架構設計原則
網絡開放：MEC 可提供平臺開放能力，在服務平臺上集成第三方應用或在雲端部署第三方應用。
能力開放：通過開發 API 的方式爲運行在 MEC 平臺主機上的第三方應用程序提供包括無線網絡信息、位置信息等多種服務。能力開放子系統從功能角度可以分爲能力開放信息、API 和接口。API 支持的網絡能力開放主要包括網絡及用戶信息開放、業務及資源控制功能開放
資源開放：資源開放系統主要包括 IT 基礎資源的管理（如 CPU、GPU、計算能力、存儲及網絡等）、能力開放控制以及路由策略控制。
管理開放：平臺管理系統通過對路由控制模塊進行路由策略設置，可針對不同用戶、設備或者第三方應用需求，實現對移動網絡數據平面的控制。
本地流量卸載：MEC 平臺可以對需要本地處理的數據流進行本地轉發和路由。
移動性：終端在基站之間移動，在小區之間移動，跨 MEC 平臺的移動。
計費和安全。
4、MEC 分層架構
移動邊緣系統層（Mobile Edge System Level）：負責對 MEC ；平臺進行全局掌控。集中式部署在覈心網或中央機房。
移動邊緣主機層（Mobile Edge Host Level）：包含了移動邊緣主機（ME host）和移動邊緣主機層管理實體（ME host-level management entity）。其中，移動邊緣主機又可以進一步劃分爲移動邊緣平臺（ME platform）、移動邊緣應用（ME application）和虛擬化基礎設施（IaaS）。分佈式部署在基站機房或接入/匯聚機房。
網絡層（Networks Level）：包含了 3GPP 網絡、本地網絡和外部網絡，該層主要表示了 MEC 平臺與局域網、蜂窩移動網或者外部網絡的接入情況。
5、MEC 系統架構
MEC 虛擬化基礎設施層：基於通用的 x86 服務器，採用計算、存儲、網絡功能虛擬化的方式爲 MEC 平臺層提供計算、存儲和網絡資源，並且規劃應用程序、服務、DNS 服務器、3GPP 網絡和本地網絡之間的通信路徑。
MEC 平臺層：是一個在 VIM（虛擬化基礎設施架構）上運行 MEC 應用程序的必要功能的集合，包括 MEC 虛擬化管理和 MEC 平臺功能組件。其中，MEC 虛擬化管理利用 IaaS（基礎設施作爲服務）的思想，實現 MEC 虛擬化資源的組織和配置，MEC 應用層提供一個資源按需分配、多個應用獨立運行且靈活高效的運行環境；MEC 平臺功能組件通過開放的 API 爲 MEC 應用層的應用程序提供各項服務，這些服務包括無線網絡信息服務、位置服務、數據平面分流規則服務、訪問的持久性存儲服務以及配置 DNS 代理服務等。
MEC 應用層：是以虛擬機或容器方式運行的應用程序，如：本地內容快速交付、物聯網數據處理、任務遷移等。應用程序具有明確的資源要求和執行規則，如所需的計算和存儲資源、最大時延、必需的服務等，這些資源要求和執行規則由 MEC 系統管理器統一管理和配置。MEC 應用層可以通過標準的接口開放給第三方業務運營商，以此促進創新型業務的研發，實現更好的用戶體驗。
從 MEC 的框架可以看出，移動網絡基於 MEC 可以爲用戶提供諸如內容緩存、超高帶寬內容交付、本地業務分流、任務遷移等能力。需要注意的是，任務遷移能夠使得終端突破硬件限制，獲得強大的計算和數據存取能力，在此基礎上實現用戶內容感知和資源的按需分配，極大的增強用戶體驗。任務遷移技術對移動設備的計算能力的強化和移動應用的計算模式的改變，必然會對未來移動應用和移動終端的設計產生深遠的影響。任務遷移的流程，如下所示：
6、MEC 軟件架構
ME APP（移動邊緣應用）：是運行在 VI 上的應用實例，可以通過 Mp1 參考點與 MEP 進行交互，以獲取 MEP 平臺的服務化開放能力（ME Services）。
MEP（移動邊緣平臺）：爲 ME APP 提供 ME Services，包括：服務註冊、服務發現、狀態監控，本地分流（Traffic Rules Control）、DNS 服務（DNS handling），Local API 網關、負載均衡器、防火牆，以及無線網絡信息服務、位置信息服務、帶寬管理服務等一系列無線網絡能力服務。從 MEPM 或 ME APP 接收應用規則配置，並通過 Mp2 參考點指示 DP 執行數據路由，將數據流量重定向到相應的 ME APP 或 ME Services。在分佈式 MEC 系統的協作機制中，Mp3 參考點可以作爲不同 MEP 之間互聯的基礎。
DP（數據轉發平面軟件)：執行 MEP 下發的流量規則，處理 ME APP，ME Services，DNS 服務器、代理服務器，3GPP 網絡，其他訪問網絡，局域網和外部網絡之間路由流量。
VI（虛擬化基礎設施）：即 Hypervisor，可以是 KVM、Docker、ESXi 等一切爲 ME APP 提供運行載體的虛擬化管理程序。
ME Host（移動邊緣主機）：是一臺通用 x86 服務器，通常部署在局所 DC 或邊緣 DC。運行着 MEP、ME APP 和 VI 等軟件模塊。
VIM（虛擬化基礎設施管理器）：虛擬化資源管理程序，例如 OpenStack、Kubernetes。用於管理虛擬計算、存儲和網絡資源的分配和釋放，以及管理 ME APP 的鏡像文件，還負責收集虛擬化資源的信息，並通過 Mm4 參考點和 Mm6 參考點分別上報給 MEAO 和 MEPM 等上層管理實體。
MEPM（ME platform manager，移動邊緣平臺管理器）：負責 MEP 的基本運維、ME Services 的配置、ME APP 的生命週期管理以及 ME APP 的應用規則和需求管理等功能。其中，ME APP 的應用規則和需求管理包括：授權認證、分流規則、DNS 規則和衝突協調等。MEPM 和 MEP 之間通過 Mm5 參考點進行交互。
MEAO（Multi-access edge application orchestrator，移動邊緣編排器）：是 MEC 業務的編排中心，通常全國只部署一個。MEAO 宏觀掌控 MEC 平臺所有的資源和容量，主要包括 VIM 中的計算、存儲、網絡資源、應用程序鏡像資源，以及 MEPM、MEP 資源。在實例化 ME APP 時，MEAO 首先加載應用程序的鏡像（軟件包）、檢查軟件包的完整性和真實性，然後還需要衡量用戶資源需求以及各個 ME Host 的可用資源，爲其選擇最爲合適的 ME Host 進行部署。如果用戶需要進行 ME Host 切換，則由 MEAO 來觸發切換程序。MEAO 和 MEPM 之間通過 Mm3 參考點，爲 ME APP 相關的策略提供支持。MEAO 與 VIM 之間通過 Mm4 參考點來管理虛擬化資源和應用程序的鏡像，同時維持可用資源的狀態信息。
UE APP：用戶終端應用。
UE APP LCM proxy（用戶終端應用生命週期代理）：接收 UE APP 發起的操作請求。
CFS Portal（Customer-Facing Service Portal，面向客戶的服務門戶）：是運營商面向第三方客戶訂閱並監控 ME APP 的門戶。通過 CFS Portal，客戶可以選擇訂購一套滿足其特殊需求的 ME APP，或者將自己的應用程序接入到 MEC 平臺中，並指定其使用的時間和地點。
OSS（Operations Support System，操作支持系統）：是提供給運營商內部使用的 MEC 部署運維中心，作爲 MEC 平臺的最高級別的管理實體。OSS 從 CFS 或 UE APP LCM proxy 接收到 ME APP 的生命週期管理請求並決定是否授權，請求通過 OSS 認證授權後，OSS 與 MEAO 之間通過 Mm1 參考點來觸發 ME 應用程序的實例化或終止實例。也通過 Mm2 參考點，與 MEPM 進行交互完成 MEP 的配置、故障和性能管理。
7、MEC in NFV 融合架構
ETSI 在 2018 年 9 月完成了第二階段（Phase II）的工作內容，主要聚焦於包括 5G、Wi-Fi、固網在內的多接入邊緣計算系統，重點完成了 MEC in NFV 融合的標準化參考模型、端到端邊緣應用移動性、網絡切片支撐、合法監聽、基於容器的應用部署、V2X 支撐、Wi-Fi 與固網能力開放等研究項目。從而更好地支撐 MEC 商業化部署與固移融合需求，同期將開啓第三階段的標準維護和標準新增階段。
ETSI MEC 017 規範於 2018 年 2 月發佈，重點描述了 MEC 在 NFV（網絡功能虛擬化）環境下的部署。MEC 是與生俱來就內含了 NFV 屬性的一套生態，MEC 017 規範可以認爲是 MEC 003 規範的進一步的擴展，更加面向實際部署和落地。整個融合架構遵循以下原則：
已有的電信網 NFV 架構網元儘可能的被重用
MEC 可調用 NFV 部分功能
MEC 內部功能模塊之間的信令不受 NFVO 控制
MEC 同 NFV 之間的接口要重新定義
NFV 標準化參考模型：
由於 NFV 的網元大多是面向電信網的網元，而 MEC 則更加偏向第三方 APP 和業務，業務種類也比 NFV 更加多樣，比如：定位、分流、IoT、視頻編解碼等等。基於 MEC 業務種類繁多的特性，有必要在 NFV 的基礎上根據 MEC 業務特性和業務需求，增加若干個全新的功能模塊，比如：MEPM-V、VNFM（MEP LCM），來協助 MEP 實現更多的功能。另外，MEC 需要的虛擬化資源和管理重用了 NFVI 和 VIM 的部分，MEC 需要的運維部署中心重用了 OSS 部分，這些網元在進行電信網 NFV 開發和部署的時候就已經建設完成了，可直接調用而無需二次開發。
在標準構架上，MEC 和 NFV 看起來別無二致，但它們是有區別的，例如：MEC 模塊同 NFV 網元之間的接口存在着重新開發和定義的問題。核心的區別在應用服務平臺和相關服務上，MEC 根據 RAN 環境對 NFV 進行了優化，它將移動接入網與互聯網業務深度融合，並將雲計算和雲存儲下沉到邊緣數據中心，加速內容分發和下載，且向第三方提供開放接口以驅動創新。通過 MEC，PGW-U/SGW-U/UPF 等核心網用戶面的網元就可以下沉到了移動邊緣節點，且由 NFV VIM（虛擬基礎設施管理）、SDN 和 Orchestrator（編排器）控制管理。
需要注意的是，ME APP 的管理對 MEC 來說是非常重要的部分，對 ME APP 的管理方式代表了未來計算平臺的運維模式和管理策略。ME APP 既受控於有 MEC 背景的 MEPM-V，也受控於有 NFV 背景的 VNFM（ME APP LCM），其本質在於 ME APP 是否與 MEP 有交互，是否使用了 ME Service 或獲取 MEP 的能力進行優化。
ME APP 受控於 MEPM-V 模式：ME APP 部署在 NFVI 上，同時經由 Mp1 參考點與 MEP 交互，並可能使用 ME Service，統一遵從 MEPM-V 的管理。由於 MEPM-V 中包含了應用規則和需求管理，因此這種方式就默認了 ME APP 要與 MEP 進行交互。通常 MEP 可以是運營商自建也可以是設備商的集成設備。這種方式的好處是有利用到 MEC 生態開放性服務化能力，但是未來可能存在一個問題，如果第三方 APP 只是想用這些 NFVI 的資源，而對 MEP 及其上的 ME Service 不感興趣，那麼這種管理就使得第三方 APP 難以接受，因爲目前 Mp1 接口定義的還不夠充分，第三方很難圍繞 MEP 的服務化接口進行 APP 的定製化開發，無疑是加重了第三方軟件開發商的工作量。但是從構建 MEC 生態的角度出發，電信運營商肯定更傾向於向第三方軟件開發者提供足夠的 PaaS 賦能。
ME APP 受控於 VNFM（ME APP LCM）模式：這種管理方式中，ME APP 僅受到 NFV 的管理，即平臺只是對 ME APP 的生存週期進行管理。第三方 APP 僅僅是租用了邊緣數據中心的 NFVI 進行部署，讓自己的 APP 更加靠近用戶，對 MEP 的服務化能力並不感到興趣。因此 ME APP 僅僅從 NFVI 資源層面受到管理。這種商業模式其實就是租賃機房資源、租賃機架、租賃硬件資源、租賃虛擬機的商業模式，從實現來講受益更加直接，第三方軟件開發商直接獲取 APP 的部署資源，運營商也無需在 MEC 層面做過多的適配性開發。但這種方式並不利於營造 MEC 生態，因爲這一管理方式徹底拋棄了 APP 同 MEP 之間的關聯， Mp1 接口完全廢棄，那麼 MEP 也沒有了存在的價值。因此這種方式只應該在早期 MEC 不成熟的時候採用，長期發展對 MEC 生態建設非常不利。
ME APP 同時受控於 MEPM-V 和 VNFM（ME APP LCM）模式。這種方式結合了 MEC 中的 APP 管理和 NFV 中的 APP 管理。NFV 僅對 APP 的生存週期和虛擬化資源進行管理，而 MEC 則對 ME APP 規則和需求進行管理，分工明確，職責不同。同時定義好 Mp1 接口，爲 ME APP 提供 MEP 中 ME service，藉助邊緣雲平臺能力可以進行 APP 的定製優化。這種方式一方面迎合了 APP 和 MEC 平臺搭建方的各方需求，同時也是未來比較合適的管理方式。
總的來說，MEC 是雲網融合型的平臺，其基礎是提供邊緣本地分流這樣的基礎網絡服務，而其核心價值則是邊緣雲服務，包括：
提供邊緣虛機、存儲等資源型邊緣 IaaS 服務；
提供邊緣網絡能力開放 API、容器以及邊緣應用框架在內的平臺型邊緣 PaaS 服務；
提供自有以及第三方業務應用在內的邊緣 ICT 業務服務。
目前總體來說，BAT 等在內的互聯網公司主要需求是資源型邊緣 IaaS 服務，而政企等行業客戶則三種服務需求都有。單純從 MEC 業務需求角度來說，邊緣 IaaS 服務、邊緣 PaaS 以及邊緣 ICT 業務服務都是 MEC 可以提供的主要業務和獲取收益，但是 MEC 的就近處理會減少中心雲及 IDC 的處理，對運營商已有的雲及 IDC 收入有影響，並且運營商一直以來對於手握 IDC 資源卻沒能佔據 CDN 市場主要份額心有不甘，不希望在邊緣計算上面重蹈覆轍，所以運營商需要綜合考慮邊緣雲的建設成本、中心雲及 IDC 的定價、客戶的需求、市場發展態勢等進行綜合的分析以確定 MEC 邊緣雲的業務提供重點及經營策略，將 MEC 作爲一種邊緣數據中心的資源設施服務還是作爲業務平臺來經營，二者策略、定價是完全不同的。
8、ETSI MEC 存在的問題
注：該章節摘自《自動化博覽》2018年增刊《邊緣計算2018專輯》。
ETSI MEC 標準化組織的成立具有非常重大的意義，一方面它填補了 MEC 標準化領域的空白，各個成員單位圍繞 MEC 在多個領域開展了富有成效的研究工作，內容範圍非常廣泛，涵蓋了技術點、業務需求、業務場景和模塊接口定義；另一方面，MEC 的標準化工作爲 MEC 產業鏈的各家單位提供了寶貴的學習和參考文獻。由於 MEC 的相關領域技術還不夠成熟，很多相關企業和研究機構都將 ETSI MEC 的標準化文稿作爲第一手學習材料，大量的研究和開發工作都圍繞 ETSI MEC 標準化的成果進行開展和討論，這使得該標準化成果具有非常重要的指導意義和啓發性，從這個角度來講，ETSI MEC 標準化組織的工作是非常成功的。
但是我們也不得不指出，ETSI MEC 標準化的諸多工作依然存在大量的問題，其所預期的引領 MEC 標準化實現商用落地的目標多少有些落空。首先，MEC 標準化文稿學術氣息太重，缺乏商用指導和實踐部署的支持。由於這一標準化組織被歐洲的設備商和運營商所把持，他們在組織中具有較大的話語權，但是卻缺乏有效的 MEC 實踐所支持，因此，大量的標準文稿都存在着“技術濃厚，落地困難”的問題。例如，標準文稿中所涉及的 MEC 參考架構封閉性極強，沒有過多的考慮實際部署和運營商網絡架構，基本沒有實現設備和虛擬化之間的解耦，這和 MEC 開放、開源的宗旨背道而馳。另外，由於 MEC 平臺和架構沒有對實際網絡架構和業務需求進行考慮，導致業界的設備商和平臺開發商基本都不採用 ETSI 所提出的 MEC 架構，實際上沒有做到架構和標準的統一。目前華爲、中興、諾基亞等廠商均已經擁有自行研發的 MEC 平臺，但是所有的接口和功能模塊都是私有化的，非常封閉，長期來看這是對產業界非常不利的。最後一點要強調的是，目前 MEC 標準化組織嘗試對相關的業務場景進行標準化，包括 V2X、WLAN 互通等。但是這些技術本身還處於萌芽期，技術不夠成熟，因此嘗試對 V2X 和 MEC 進行標準化本身就不適時宜。因此，大量的標準化文稿屬於“爲了標準而標準”，嚴重脫離發展實際和產業現狀，成爲了沒有任何存在價值的文稿，這也是當前 ETSI MEC 所面臨的問題。