1、MEC的優勢
      MEC 運行於網路邊緣，邏輯上並不依賴於網路的其他部分，這點對於安全性要求較高的應用來說非常重要。另外，MEC 伺服器通常具有較高的計算能力，因此特別適合於分析處理大量資料。同時，由於 MEC 距離使用者或資訊源在地理上非常鄰近，使得網路響應使用者請求的時延大大減小，也降低了傳輸網和核心網部分發生網路擁塞的可能性。最後，位於網路邊緣的 MEC 能夠實時獲取例如基站 ID、可用頻寬等網路資料以及與使用者位置相關的資訊，從而進行鏈路感知自適應，並且為基於位置的應用提供部署的可能性，可以極大地改善使用者的服務質量體驗。
2、MEC架構
      從 2014 年 12 月開始，ETSI MEC ISG 開始致力於 MEC 的研究，旨在提供在多租戶環境下執行第三方應用的統一規範。經過努力，ISG MEC 已經公佈了關於 MEC 的基本技術需求和參考架構的相關規範。在參考文獻[1]中，ISG MEC 對MEC 的網路框架和參考架構進行了定義。圖 1 是MEC 的基本框架，該框架從一個比較巨集觀的層次出發，對 MEC 下不同的功能實體進行了網路（network）、ME（mobile edge）主機水平（ME host level）和 ME 系統水平（ME system level）這 3 個層次的劃分。其中，MEC 主機水平包含 MEC 主機（ME host）和相應的 ME 主機水平管理實體（ME host-level management entity），ME 主機又可以進一步劃分為 ME 平臺（ME platform）、ME 應用（ME application）和虛擬化基礎設施（virtualization infrastructure）。網路水平主要包含 3GPP 蜂窩網路、本地網路和外部網路等相關的外部實體，該層主要表示 MEC 工作系統與區域網、蜂窩移動網或者外部網路的接入情況。最上層是 ME 系統水平的管理實體，負責對 MEC 系統進行全域性掌控。

      圖 2 是一個更為詳細的 MEC 參考架構，該架構在圖 1 所示的高水平框架的基礎之上還詳細定義了各個功能實體之間的相互關聯，並抽象出 3 種不同型別的參考點。其中，Mp 代表和 ME 平臺應用相關的參考點，Mm 代表和管理相關的參考點，Mx 代表和外部實體相關的參考點。

      在圖 2 所示架構下，ME 主機由 ME 平臺、ME 應用和虛擬化基礎設施組成。虛擬化基礎設施可以為 ME 應用提供計算、儲存和網路資源，並且可以為 ME 應用提供持續的儲存和時間相關的資訊，它包含一個數據轉發平面來為從 ME 平臺接收到的資料執行轉發規則，並在各種應用、服務和網路之間進行流量的路由。ME 平臺從 ME平臺管理器、ME 應用或 ME 服務處接收流量轉發規則，並且基於轉發規則向轉發平面下發指令。另外，ME平臺還支援本地域名系統（domain name system，DNS）代理伺服器的配置，可以將資料流量重定向到對應的應用和服務。ME 平臺還可以通過 Mp3 參考點與其他的 ME 平臺進行通訊，在分散式 MEC 系統的協作機制中，Mp3 參考點可以作為不同 ME 平臺互聯的基礎。
      ME 應用是執行在 ME 虛擬化基礎設施上的虛擬機器例項，這些應用通過 Mp1 參考點與 ME 平臺相互通訊。Mp1 參考點還可提供標識應用可用性、發生 ME 切換時為使用者準備或重定位應用狀態等額外功能。
      ME 平臺管理器（ME platform manager，MEPM）具有 ME 平臺元素管理、ME 應用生命週期管理以及 ME 應用規則和需求管理等功能。ME應用生命週期管理包括 ME 應用程式的建立和終止，並且為 ME 編排器（ME orchestrator，MEO）提供應用相關事件的指示訊息。ME 應用規則和需求管理包括認證、流量規則、DNS 配置和衝突協調等。ME 平臺和 MEPM 之間使用 Mm5 參考點，該參考點實現平臺和流量過濾規則的配置，並且負責管理應用的重定位和支援應用的生命週期程式。Mm2 是操作支援系統（OSS）和 MEPM 之間的參考點，負責 ME 平臺的配置和效能管理。Mm3是 MEO 和 MEPM 之間的參考點，負責為應用的生命週期管理和應用相關的策略提供支援，同時為 ME 的可用服務提供時間相關的資訊。
      MEO 是 ME 提供的核心功能，MEO 巨集觀掌控 ME 網路的資源和容量，包括所有已經部署好的 ME 主機和服務、每個主機中的可用資源、已經被例項化的應用以及網路的拓撲等。在為使用者選擇接入的目標 ME 主機時，MEO 衡量使用者需求和每個主機的可用資源，為其選擇最為合適的 ME主機，如果使用者需要進行 ME 主機的切換，則由MEO 來觸發切換程式。MEO 與OSS 之間通過Mm1 參考點來觸發 ME 應用的例項化和終止。MEO 與虛擬化基礎設施管理器（VIM）之間通過Mm4 參考點來管理虛擬化資源和應用的虛擬機器映像，同時維持可用資源的狀態資訊。
      從 ME 系統的角度來看，OSS 是支援系統執行的最高水平的管理實體。OSS 從面向使用者服務（customer-facing service，CFS）門戶和使用者終端（UE）接收例項化或終止 ME 應用的請求，檢查應用資料分組和請求的完整性和授權資訊。經過OSS 認證授權的請求資料分組會通過 Mm1 參考點被轉發到 MEO 進行進一步處理。
      CFS 門戶實體相當於第三方接入點，開發商使用該介面將自己開發的各種應用接入運營商的ME 系統中，企業或者個人使用者也可以通過該介面選擇其感興趣的應用，並指定其使用的時間和地點。CFS 通過Mx1 參考點與 OSS 實現通訊。
      使用者應用生命週期代理（user app LCM proxy）是供 ME 使用者使用來請求應用相關的例項化和終止等服務的實體。該實體可以實現外部雲和 ME 系統之間的應用重定位，負責對所有來自外部雲的請求進行認證，然後分別通過 Mm8 和Mm9 參考點發送給 OSS 和 MEO 做進一步處理。值得注意的是，LCM 只能通過行動網路接入，Mx2 參考點提供了 UE 與 LCM 相互通訊的基礎。
      VIM 用於管理 ME 應用的虛擬資源，管理任務包括虛擬計算、儲存和網路資源的分配和釋放，軟體映像也可以儲存在VIM上以供應用的快速例項化。同時，VIM 還負責收集虛擬資源的資訊，並通過 Mm4 參考點和 Mm6 參考點分別上報給MEO 和 MEPM 等上層管理實體。
3、MEC、微雲及霧計算
      微雲是由移動計算和雲端計算融合而來的新型網路架構元素，它代表移動終端、微雲和雲 3 層架構的中間層，可以被視作“盒子裡的資料中心”。微雲是 OEC（Open Edge Computing）的研究成果，該專案最初由美國卡耐基梅隆大學發起，而後受到了包括 Intel（英特爾）、華為、Vodafone（沃達豐）在內的多家公司的廣泛支援，主要致力於對邊緣計算應用場景、關鍵技術和統一 API 的研究。OEC 基於 OpenStack 開源專案進行擴充套件，從而得到了微雲，目前其原始碼以及搭建方法也可以在OEC 的官網上免費獲得。微雲的設計靈感來自於觸覺網際網路（tactile network），致力於實現資訊的超低時延傳輸。相比於 MEC 和霧計算來說，微雲主要用於移動增強，能夠為移動裝置提供豐富的計算資源，尤其關注邊緣的視訊分析應用，能夠提取邊緣資料的標籤和元資料並傳輸到雲，以實現高效的全域性搜尋。此外，微雲還可以直接執行在終端上，比如車輛、飛機等。
——”移動邊緣計算綜述”（李子姝（北京郵電大學）等. 《電信科學》2018.1）
      Cloudlet是2009年由卡內基梅隆大學的Satyanarayanan和Bahl等人提出的移動雲端計算的實現模式之一，稱為朵雲，也就是微雲，它很好的解決了移動雲端計算中的高延遲問題。Cloudlet為擁有完整計算和儲存能力的計算機或計算機叢集，且本地化的部署在與移動裝置同一個區域網絡中，使用者不需要經過核心網就可直接連線到朵雲端。Cloudlet的架構圖如圖1-4所示，Cloudlet通過穩定的回傳鏈路與核心網雲端連線，將雲端計算服務前置，最大限度地發揮雲端的處理能力的同時，又能使使用者與計算資源的距離控制在一跳範圍內。這裡所說的＂一跳＂範圍是指的Cloudlet—般會通過WIFI和使用者連線，WIFI覆蓋範圍內的移動裝置都可以使用Cloudlet提供的計算和儲存服務。與普通的移動雲端計算模式相比，Cloudlet同樣具有豐富的計算能力，且與移動使用者只存在一跳的傳輸距離，面對實時性要求較高的業務時，能夠有效地減少服務的延遲。Cloudlet這樣的移動雲端計算實現模式雖然解決了高時延的問題，而它與使用者的連線靠的是本地區域網或者WIFI，導致使用者在使用移動雲端計算服務的時候，移動性會受到極大的影響，不能做到“隨時隨地”地接入雲端。

      為了使移動使用者能夠享有移動雲端計算服務，時解決移動雲端計算中的高時延、使用者移動性受限的問題，2012年，歐盟的FP7專案組提出了：基於聯合小小區的分散式計算、儲存、無線資源配置（Distributed computing, storage, and radio resource allocation over cooperative smallcells, ROPIC）專案。該專案提出賦予小小區基站額外的、有限的計算功能，稱這樣的基站為小小區雲增強型節點（SmallcellcloudenhancedeNodeB, SCceNB）。通過這樣的方式，移動使用者能夠在短距離內通過小小區蜂窩網，訪問雲端計算伺服器，獲得計算功能。SCceNB的部署場景如圖1-5所示，多個SCceNB連線著具有計算和儲存能力的微雲（Femtocloud），微雲控制器通過這些SCceNB給連線的使用者提供虛擬機器和雲端計算服務。與此同時，多個微雲連線至核心網內計算能力更強大的雲伺服器。當用戶的計算請求能夠被本地的SCceNB或者微雲所服務的時候，資料的傳輸和計算就在本地端完成，當請求超出了微雲的能力時，資料會通過回傳鏈路傳輸到核心網的雲端完成計算。基於聯合小小區的分散式移動雲端計算架構使得行動網路資源和計算資源更接近使用者，提高了網路和計算方面的可擴充套件性，解決了傳統移動運算的高時延問題。

——”基於移動邊緣計算的任務遷移策略研究”（鄧茂菲.北京郵電大學碩士畢業論文.2017.3）
      霧計算是指將計算、通訊、控制和儲存資源與服務分佈給使用者或靠近使用者的裝置與系統，從而將雲端計算模式擴充套件到網路邊緣。霧計算最初是由思科提出來的，更側重於在物聯網上的應用。2015 年 11月，ARM、思科、戴爾、英特爾、微軟和美國普林斯頓大學聯合成立了開放霧聯盟（Open Fog Consortium），該聯盟旨在通過開發開放式架構、分散式計算、聯網和儲存等核心技術以及實現物聯網全部潛力所需的領導力，加快霧計算的部署。Open Fog 架構利用開放的標準方法，將雲端的無縫智慧與物聯網終端聯合在一起。2017 年 2 月，開放霧聯盟宣佈釋出了 Open Fog參考架構（reference architecture，RA），這是一個旨在支援物聯網、5G 和人工智慧應用的資料密集型需求的通用技術架構，該架構為霧節點（智慧互聯裝置）與網路、部署模式、層次模型和用例提供了一箇中高層次的系統架構檢視，標誌著霧計算向制定標準邁出了重要的一步，未來的工作將更偏向於新需求和底層細節的研究。
      MEC 與微雲、霧計算的概念相似，其基本思想都集中在將雲端計算能力遷移至網路邊緣，都屬於邊緣計算的範疇。但三者在一些基本細節上仍存在一些需要區分之處，表 1 對這 3 種概念的不同之處進行了簡要的歸納和總結。

4、基於MEC的線上視訊系統
      圖 3 是英特爾中國研究院與英特爾網路平臺事業部、中國移動及愛奇藝合作開發的一款線上視訊系統。該系統利用 MEC 進行視訊加速，視訊提供商利用 MEC 的計算、儲存和網路功能，通過對使用者視訊請求資料分組進行分析，為特定的高清付費使用者提供充足頻寬，以保證其觀看體驗。OTT（網際網路應用服務） 在使用上述系統時，無需對自己的應用網路進行架構性變動，由此可以大幅降低使用成本，加速業務創新。該系統目前已在業界知名的世界行動通訊大會（Mobile World Congress，MWC）上現身，並引起廣泛關注，並被 ETSI MEC ISG採納為典型業務場景之一。

5、MEC應用於VR
      中興也提出了基於 5G 的 MEC 解決方案，該方案適用於 VR 這一典型應用場景。MEC部署在 RAN 或 C-RAN（cloud RAN）側以獲取利於統計分析的關鍵資訊，提供低時延的本地化業務服務。運營商不僅可以有效減少核心網的網路負載，還能通過本地化的部署，提供實時性高、低時延的 VR 體驗，增強 VR 實時互動。該系統的架構如圖 4 所示。

6、MEC關鍵技術
（1）虛擬化技術
      虛擬化技術與網路的結合催生了網路功能虛擬化（network function virtualization，NFV）技術，該技術將網路功能整合到行業標準的伺服器、交換機和儲存硬體上，並且提供優化的虛擬化資料平面，可通過伺服器上執行的軟體實現管理從而取代傳統的物理網路裝置。
（2）雲技術
      雲技術與行動網路的結合還促進了C-RAN 這一創新性應用的產生。C-RAN將原本位於基站的基帶處理單元等需要耗費計算和儲存資源的模組遷移到雲上，在很大程度上解決了基站的容量受限問題，提高了行動網路的系統能量效率。
      MEC 技術在網路邊緣提供計算和儲存資源，NFV 和雲技術能夠幫助 MEC 實現多租戶的共建。由於 MEC 伺服器的容量相對於大規模資料中心來說還是較小，不能提供大規模資料中心帶來的可靠性優勢，所以需要結合雲技術引入雲化的軟體架構，將軟體功能按照不同能力屬性分層解耦地部署，在有限的資源條件下實現可靠性、靈活性和高效能。
（3）SDN技術
      SDN 技術是一種將網路裝置的控制平面與轉發平面分離，並將控制平面集中實現的軟體可程式設計的新型網路體系架構。SDN 技術採用集中式的控制平面和分散式的轉發平面，兩個平面相互分離，控制平面利用控制—轉發通訊介面對轉發平面上的網路裝置進行集中控制，並向上提供靈活的可程式設計能力，這極大地提高了網路的靈活性和可擴充套件性。
      利用 SDN 技術將核心網的使用者面和控制面進行分離，可以實現閘道器的靈活部署，簡化組網。在參考文獻[2]中，結合 NFV 技術、SDN 技術和 MEC，設計了一個新型的行動網路系統 SD-MEC。該系統在不同接入點分散式部署 MEC 伺服器，將業務進行本地解除安裝，從而降低了核心網的信令開銷，降低了由於長距離傳輸而發生網路突發狀況的可能性，增強了使用者的服務質量體驗。另外，SD-MEC 有專門的控制器對系統進行管控，從而降低了管理的複雜性，同時使得新服務的部署變得更加靈活。
7、MEC與CDN
      研究表明，在移動資料流量中有超過一半的部分是視訊流量，並且該比例呈逐年上升趨勢。從使用者角度來說，觀看視訊可以分為點播和直播。點播是指在被請求視訊已經存在於源伺服器的情況下使用者向視訊伺服器傳送視訊觀看請求，直播則指在內容產生的同時使用者對內容進行觀看。在傳統的視訊系統中，內容源將產生的資料上傳到Web 伺服器，然後再由 Web 伺服器響應使用者的視訊請求。在這種傳統方式下，內容基於 TCP 和HTTP 進行下載，或是以流的形式傳遞使用者。但是TCP 並不能快速適應 RAN 的變化，通道環境改變、終端的加入和離開等都會導致鏈路容量的變化，另外，這種長距離的視訊傳輸也增大了鏈路故障的概率，同時造成很大的時延，從而不能保證使用者的服務質量體驗。為了改善上述問題，當下學術界和產業界普遍採用 CDN 分發機制，將內容分發到各個 CDN 節點上，再由各個 CDN 節點響應對應區域中的使用者請求。CDN 分發機制的引進的確在一定程度上緩解了上述問題，但這種改進對於直播這種高併發，並且對實時性和流暢性要求很高的場景來說仍然有力不從心之處。
      MEC 技術的引入可以解決上述問題，內容源可以直接將內容上傳到位於網路邊緣的 MEC 伺服器，再由 MEC 伺服器響應使用者的視訊請求，這樣可以極大地降低使用者觀看視訊的時延。同時，由於MEC 具有強大的計算能力，可以實時感知鏈路狀態並根據鏈路狀態對視訊進行線上轉碼，從而保障視訊的流暢性，實現智慧視訊加速。另外，MEC伺服器還可以負責本區域使用者的空口資源的分配和回收，從而增加網路資源的利用率。
8、MEC運用於車聯網
      車聯網場景下有大量的終端使用者，如車輛、道路基礎設施、支援 V2X 服務的智慧手機等，同時對應著多種多樣的服務，例如一些緊急事件的廣播等基本的道路安全服務以及一些由應用開發商和內容提供商提供的增值服務，例如停車定位、增強現實或其他娛樂服務等。MEC 伺服器可以部署於沿道路的 LTE 基站上，利用車載應用和道路感測器接收本地資訊，對其加以分析。並對那些優先順序高的緊急事件以及需要進行大量計算的服務進行處理，從而確保行車安全、避免交通堵塞，同時提升車載應用的使用者體驗。在此方面，德國已經研發了數字高速公路試驗檯來提供交通預警服務，該試驗檯用於在 LTE 環境下在同一區域內進行車輛預警訊息的釋出[3]。
9、MEC伺服器部署場景
      在設計 MEC 解決方案時，還必須考慮 MEC伺服器在網路中的部署位置。MEC 伺服器可以被部署在網路的多個位置，例如可以位於 LTE 巨集基站（eNode B）側、3G 無線網路控制器（radio network controller，RNC）側、多無線接入技術（multi-radio access technology，multi-RAN）蜂窩匯聚點側或者核心網邊緣。本節旨在介紹 MEC 伺服器的幾個主要的部署場景，並且對不同部署方式的優勢和存在問題加以簡要分析。
<<1>> 4G EPC 架構下的 MEC 部署
（1）MEC 伺服器部署在無線接入網（RAN）側
      如圖 5 所示，MEC 可以部署在 RAN 側的多個eNode B 匯聚節點之後，這是目前比較常見的部署方式。MEC 伺服器也可以部署在單個 eNode B 節點之後，如圖 6 所示，這種方式適合學校、大型購物中心、體育場館等熱點區域下 MEC 的部署。將 MEC 伺服器部署在 RAN 側的優勢在於可以更方便地通過監聽、解析 S1 介面的信令來獲取基站側無線相關資訊，但是該方案需要進一步解決計費和合法監聽等安全性問題。


（2）MEC 伺服器部署在核心網（CN）側
      MEC 伺服器也可以部署在核心網邊緣，在PGW 之後（或與 PGW 整合在一起），從而解決RAN 部署方案下的計費和安全問題。但部署在核心網側會存在距離使用者較遠、時延較大和佔用核心網資源的問題。圖 7 所示方案是不改變現有的 EPC架構，將 MEC 伺服器與 PGW 部署在一起。UE 發起的資料業務經過 eNode B、匯聚節點、SGW、PGW+MEC 伺服器，然後到網際網路。圖 8 所示方案需要改變現有的 EPC 架構，將原 PGW 拆分成P1GW 和 P2GW（即 DGW），其中，P1GW 駐留在原位置，DGW 下移到 RAN 側或者核心網邊緣，DGW 負責計費、監聽、鑑權等功能，MEC 伺服器和 DGW 部署在一起。在此方案下，P1GW 和 DGW之間為私有介面，需由同一裝置廠商提供。


<<2>> 5G 架構下的 MEC 部署
      如圖 9 所示，在 5G 架構下，MEC 伺服器也有兩種部署方式，分別如圖 9 中 MEC 伺服器 1和 MEC 伺服器 2。MEC 伺服器可以部署在一個或多個 Node B 之後，使資料業務更靠近使用者側，如圖 9 中粗實線所示，UE 發起的資料業務經過Node B、MEC 伺服器 1，然後到達網際網路，同樣地，在該方式下計費和合法監聽問題需進一步解決。MEC 伺服器也可以部署在使用者平面閘道器GW-UP 後，如圖 9 中粗虛線所示，UE 發起的資料業務經過 Node B、GW-UP、MEC 伺服器 2，最後到達網際網路，同理，此部署方法將以犧牲一部分時延為代價。

——”移動邊緣計算綜述”（李子姝（北京郵電大學）等. 《電信科學》2018.1）

[1]ETSI. Mobile edge computing (MEC); framework and reference architecture[S]. 2016.
[2]SALMAN O, ELHAJJ I, KAYSSI A, et al. Edge computing enabling the internet of things[C]//Internet of Things, Dec 14-16, 2015, Milan, Italy. Piscataway: IEEE Press, 2015: 603-608.
[3]AHMED A, AHMED E. A survey on mobile edge computing[C]//2016 10th International Conference on Intelligent Systems and Control (ISCO), Jan 7-8, 2016, Coimbatore, India. Piscataway: IEEE Press, 2016: 1-8.
[4]HU Y C, PATEL M, SABELLA D, et al. Mobile edge computing—a key technology towards 5G[S]. ETSI White Paper, 2015: 1-16.