摘要：邊緣計算目前已經(jīng)成為產(chǎn)業(yè)界和學(xué)術(shù)界的研究熱點(diǎn)，在靠近業(yè)務(wù)的網(wǎng)絡(luò )邊緣側部署計算處理能力能夠極大地滿(mǎn)足未來(lái)業(yè)務(wù)對低時(shí)延、大帶寬、高可靠的要求，極大的支持了未來(lái)車(chē)聯(lián)網(wǎng)、工業(yè)控制、智能制造、大視頻等業(yè)務(wù)。同時(shí)邊緣計算也是5G原生使能技術(shù)，未來(lái)的5G網(wǎng)絡(luò )架構已經(jīng)明確支持邊緣計算的諸多特性。歐洲電信標準化組織ETSI是最早開(kāi)始進(jìn)行邊緣計算標準化的國際組織，目前該組織已經(jīng)完成第二階段的標準化，對外公布包括MEC平臺架構、業(yè)務(wù)需求、管理編排、API接口在內的20余份標準化文稿，對產(chǎn)業(yè)界和學(xué)術(shù)界具有極大的指導意義。本文重點(diǎn)分析ETSI MEC標準化組織的研究進(jìn)展，同時(shí)對該組織所提出的MEC架構進(jìn)行技術(shù)分析，最后提出中國聯(lián)通對于MEC標準化工作的一些看法。

關(guān)鍵詞：邊緣計算；ETSI；MEC；標準化

1 ETSI MEC標準化工作綜述

ETSI歐洲電信標準化組織，在2014年率先啟動(dòng)MEC標準項目。這一項目組旨在移動(dòng)網(wǎng)絡(luò )邊緣為應用開(kāi)發(fā)商與內容提供商搭建一個(gè)云化計算與IT環(huán)境的服務(wù)平臺，并通過(guò)該平臺開(kāi)放無(wú)線(xiàn)側網(wǎng)絡(luò )信息，實(shí)現高帶寬、低時(shí)延業(yè)務(wù)支撐與本地管理。聯(lián)盟的初創(chuàng )成員包括惠普、沃達豐、華為、諾基亞、Intel以及Viavi。目前ETSI MEC標準化組織已經(jīng)吸引了國內外數百家運營(yíng)商、設備商、軟件開(kāi)發(fā)商、內容提供商參與其中，ETSI MEC的影響力也逐漸擴大。

在2017年底，ETSI MEC標準化組織已經(jīng)完成了Phase I階段基于傳統4G網(wǎng)絡(luò )架構部署，定義邊緣計算系統應用場(chǎng)景、參考架構、邊緣計算平臺應用支撐API、應用生命周期管理與運維框架、以及無(wú)線(xiàn)側能力服務(wù)API（RNIS/定位/帶寬管理）。目前正在進(jìn)行的PhaseII階段，則主要聚焦在包括5G/Wi-Fi/固網(wǎng)在內的多接入邊緣計算系統，重點(diǎn)覆蓋MECin NFV參考架構、端到端邊緣應用移動(dòng)性、網(wǎng)絡(luò )切片支撐、合法監聽(tīng)、基于容器的應用部署、V2X支撐、Wi-Fi與固網(wǎng)能力開(kāi)放等研究項目，從而更好地支撐MEC商業(yè)化部署與固移融合需求，第二階段的標準化于2018年9月底之前完成，同期將開(kāi)啟第三階段的標準維護和標準新增階段。ETSI MEC標準化的內容主要包括以下內容：研究MEC需求、平臺架構、編排管理、接口規范、應用場(chǎng)景研究等。

圖1 ETSI MEC標準化的第一階段與第二階段工作示意圖

ETSI MEC還陸續發(fā)布了多本MEC白皮書(shū)，內容涉及到C-RAN、MEC從4G到5G的演進(jìn)、MEC關(guān)鍵技術(shù)以及MEC軟件實(shí)現等，如圖2所示。這些白皮書(shū)主要給出了MEC對現網(wǎng)和未來(lái)網(wǎng)絡(luò )架構的融合構想，提出了切實(shí)的解決方案和演進(jìn)規劃，但是對于具體的技術(shù)實(shí)現細節是沒(méi)有過(guò)多介紹的。

圖2 ETSI MEC標準化發(fā)布行業(yè)白皮書(shū)

ETSI MEC還鼓勵各會(huì )員單位和參與公司積極提交MEC PoC，PoC的內容主要是各大公司所開(kāi)展的MEC實(shí)際落地的工作。ETSI MEC認為，MEC非常偏向實(shí)踐和應用，需要結合具體業(yè)務(wù)場(chǎng)景進(jìn)行落地，因此標準組織非常希望能夠有更多的MEC落地方案能夠提交到組織中以產(chǎn)生更多的示范效應和指導意義。目前PoC的總數已經(jīng)達到12個(gè)，業(yè)務(wù)范疇覆蓋了IoT、V2X、CDN、工業(yè)控制等。

ETSI MEC標準化組織的成立具有非常重大的意義，一方面它填補了MEC標準化領(lǐng)域的空白，各個(gè)成員單位圍繞MEC在多個(gè)領(lǐng)域開(kāi)展了富有成效的研究工作，內容范圍非常廣泛，涵蓋了技術(shù)點(diǎn)、業(yè)務(wù)需求、業(yè)務(wù)場(chǎng)景和模塊接口定義；另一方面，MEC的標準化工作為MEC產(chǎn)業(yè)鏈的各家單位提供了寶貴的學(xué)習和參考文獻。由于MEC的相關(guān)領(lǐng)域技術(shù)還不夠成熟，很多相關(guān)企業(yè)和研究機構都將ETSI MEC的標準化文稿作為第一手學(xué)習材料，大量的研究和開(kāi)發(fā)工作都圍繞ETSI MEC標準化的成果進(jìn)行開(kāi)展和討論，這使得該標準化成果具有非常重要的指導意義和啟發(fā)性，從這個(gè)角度來(lái)講，ETSI MEC標準化組織的工作是非常成功的。

但是我們也不得不指出，ETSI MEC標準化的諸多工作依然存在大量的問(wèn)題，其所預期的引領(lǐng)MEC標準化實(shí)現商用落地的目標多少有些落空。首先，MEC標準化文稿學(xué)術(shù)氣息太重，缺乏商用指導和實(shí)踐部署的支持。由于這一標準化組織被歐洲的設備商和運營(yíng)商所把持，他們在組織中具有較大的話(huà)語(yǔ)權，但是卻缺乏有效的MEC實(shí)踐所支持，因此，大量的標準文稿都存在著(zhù)“技術(shù)濃厚，落地困難”的問(wèn)題。例如，標準文稿中所涉及的MEC參考架構封閉性極強，沒(méi)有過(guò)多的考慮實(shí)際部署和運營(yíng)商網(wǎng)絡(luò )架構，基本沒(méi)有實(shí)現設備和虛擬化之間的解耦，這和MEC開(kāi)放、開(kāi)源的宗旨背道而馳。另外，由于MEC平臺和架構沒(méi)有對實(shí)際網(wǎng)絡(luò )架構和業(yè)務(wù)需求進(jìn)行考慮，導致業(yè)界的設備商和平臺開(kāi)發(fā)商基本都不采用ETSI所提出的MEC架構，實(shí)際上沒(méi)有做到架構和標準的統一。目前華為、中興、諾基亞等廠(chǎng)商均已經(jīng)擁有自行研發(fā)的MEC平臺，但是所有的接口和功能模塊都是私有化的，非常封閉，長(cháng)期來(lái)看這是對產(chǎn)業(yè)界非常不利的。最后一點(diǎn)要強調的是，目前MEC標準化組織嘗試對相關(guān)的業(yè)務(wù)場(chǎng)景進(jìn)行標準化，包括V2X、WLAN互通等。但是這些技術(shù)本身還處于萌芽期，技術(shù)不夠成熟，因此嘗試對V2X和MEC進(jìn)行標準化本身就不適時(shí)宜。因此，大量的標準化文稿屬于“為了標準而標準”，嚴重脫離發(fā)展實(shí)際和產(chǎn)業(yè)現狀，成為了沒(méi)有任何存在價(jià)值的文稿，這也是當前ETSI MEC所面臨的問(wèn)題。

2 ETSI NFV-MEC平臺架構分析

ETSI MEC017協(xié)議于2018年2月最新發(fā)布，重點(diǎn)描述了MEC在NFV環(huán)境下的部署，如圖3所示。MEC作為與生俱來(lái)的帶有NFV屬性的一套生態(tài)，MEC017協(xié)議可以認為是MEC003協(xié)議的進(jìn)一步的擴展，更加面向實(shí)際部署和落地。MEC017中詳細的參考架構如圖所示。整個(gè)架構遵循以下原則：已有的電信網(wǎng)NFV架構網(wǎng)元部分盡可能的重用，MEC模塊可調用NFV部分功能，MEC內部功能模塊之間的信令不受NFV管理編排器控制，MEC同NFV之間的接口要重新定義。

整個(gè)參考架構可以看做是MEC003同ETSINFV架構（ETSI GS NFV 002）之間的一套融合方案。這一參考架構中，主要分為三個(gè)部分：重用NFV架構部分、MEC架構部分以及共用網(wǎng)元模塊部分。

以OSS、NFVO、VNFM（ME APP LCM）、VIM、NFVI為組合，被NFV參考點(diǎn)所連接的網(wǎng)元，是NFV架構部分。這些網(wǎng)元都是ETSI NFV中已經(jīng)定義的網(wǎng)元，在這里直接引入MEC架構中實(shí)現了網(wǎng)元功能的重用。要注意的是，NFV標準化要早于MEC。之所以考慮重用網(wǎng)元，是因為MEC中的各類(lèi)功能模塊和網(wǎng)元，也涉及到了虛擬化基礎設施的搭建、虛擬化基礎設施的管理、虛擬化管理和編排、生命周期管理等內容，因此這部分可以直接調用NFV的網(wǎng)元，而無(wú)需再進(jìn)行重復開(kāi)發(fā)。因為目前各大運營(yíng)商的網(wǎng)元虛擬化工作早已經(jīng)開(kāi)展，很多的開(kāi)發(fā)工作也已經(jīng)完成，現網(wǎng)正在運行，因此根據MEC業(yè)務(wù)和NFV業(yè)務(wù)的共性對NFV的網(wǎng)元進(jìn)行重用是非常有必要的。需要說(shuō)明的是，對于NFV網(wǎng)元之間的接口，其功能和信令交互流程可以保持不變，而對于NFV網(wǎng)元和MEC功能模塊之間的接口，可能需要新定義或者新開(kāi)發(fā)，比如：Mv2接口。

圖3 ETSI MEC017：MEC在NFV下的參考架構

以ME APP、MEP、MEPM-V、VNFM（MEPLCM）、dataplane、CFSPortal、UEAPP、UEAPPLCM proxy、OSS、MEAO為組合，被MEC參考點(diǎn)所連接的網(wǎng)元，是MEC原有架構部分，這部分已經(jīng)在MEC003中定義和說(shuō)明過(guò)。這些功能模塊是屬于MEC特有的網(wǎng)元，是基于NFV基礎上，根據MEC業(yè)務(wù)特性和業(yè)務(wù)需求所設定的全新的功能模塊架構。由于NFV的網(wǎng)元大多是面向電信網(wǎng)的網(wǎng)元，而MEC則更加偏向第三方APP和業(yè)務(wù)，業(yè)務(wù)種類(lèi)也比NFV更加多樣，如：定位、分流、IoT、視頻編解碼等等。所以，基于MEC業(yè)務(wù)種類(lèi)繁多的特性，有必要在NFV的基礎上增加若干個(gè)功能不一的模塊來(lái)協(xié)助MEP實(shí)現更多的功能。這里需要說(shuō)明一點(diǎn)，MEC需要虛擬化資源和管理，因此，MEC重用了NFVI和VIM的部分，可直接調用而無(wú)需二次開(kāi)發(fā)。MEC模塊同NFV網(wǎng)元之間的接口，也存在著(zhù)重新開(kāi)發(fā)和定義的問(wèn)題。

以NFVI、VIM、OSS為組合，可視為MEC和NFV重用的網(wǎng)元部分。這些網(wǎng)元在進(jìn)行電信網(wǎng)NFV開(kāi)發(fā)和部署的時(shí)候就已經(jīng)建設完成了，MEC相關(guān)業(yè)務(wù)在運行時(shí)也需要他們的支持，因此直接重用即可。

3 第三方APP的管理模式

APP的管理對MEC來(lái)說(shuō)是重要的部分，對APP的管理方式其背后代表了未來(lái)計算平臺的運維模式和管理策略。ME APP既受控于有MEC背景的MEPM-V，也受控于有NFV架構背景的VNFM（ME APP LCM），其本質(zhì)在于ME APP是否與MEP有交互，是否使用了ME service或獲取平臺能力進(jìn)行優(yōu)化。

（1）ME APP受控于MEPM-V。這種方式表明了ME APP部署在NFVI上，同時(shí)經(jīng)由Mp1接口，連接到MEP平臺，并可能使用ME service，遵從MEPM-V的管理。由于MEPM-V中包含了ME APP規則和需求管理，因此這種方式就默認了ME APP要受到MEP平臺的管理。通常MEP可以是運營(yíng)商自建也可以是設備商的集成設備，總之，這種管理方式就意味著(zhù)第三方APP部署在MEP上時(shí)必須受到平臺的管理，這種管理方式的好處顯而易見(jiàn)，有利用邊緣生態(tài)中APP的管理和調度，但是未來(lái)可能存在一個(gè)問(wèn)題，如果ME APP只是想用這些NFVI的資源，而對MEP上的ME service不敢興趣，那么這種管理就使得第三方APP難以接受，因為目前Mp1接口定義的還不夠充分，第三方也需要圍繞MEP進(jìn)行定制化開(kāi)發(fā)，這些都加重了第三方的工作量，需要考慮第三方的需求和想法。但是作為MEC構建生態(tài)的想法，我們更傾向于提供第三方APP足夠的PaaS能力。

（2）ME APP受控于VNFM（ME APP LCM）。這種管理方式，即ME APP僅受到NFV網(wǎng)元的管理，也就是只是對ME APP的生存周期進(jìn)行管理。這種方式表明第三方的APP僅僅是租用了邊緣數據中心的NFVI，進(jìn)行部署，但是不使用任何MEP中的service和平臺能力，因此ME APP僅僅從資源層面受到管理。這種商業(yè)模式其實(shí)就是租賃機房資源、租賃機架、租賃硬件資源、租賃虛擬機的商業(yè)模式，從實(shí)現來(lái)講受益更加直接，第三方直接獲取資源自行開(kāi)發(fā)相應服務(wù)，運營(yíng)商也無(wú)需在MEC平臺層面做過(guò)多的開(kāi)發(fā)。但是這種方式并不是在營(yíng)造MEC生態(tài)，因為這一管理方式徹底拋棄了APP同MEP之間的關(guān)聯(lián)， Mp1接口完全廢棄，那么MEP也沒(méi)有了存在的價(jià)值，因此這種方式只可在早期不成熟的時(shí)候采用，長(cháng)期發(fā)展對MEC生態(tài)和建設非常不利。

（3）ME APP同時(shí)受控于MEPM-V和VNFM（MEAPP LCM）。這種方式結合了MEC中APP管理和NFV中的APP管理。NFV僅對APP的生存周期和虛擬化資源進(jìn)行管理，而MEC則對ME APP規則和需求進(jìn)行管理，分工明確職責不同。同時(shí)定義好Mp1接口，提供ME APP使用MEP中ME service的途徑，借助邊緣云平臺能力可以進(jìn)行APP的定制優(yōu)化。這種方式一方面迎合了APP和MEC平臺搭建方的各方需求，同時(shí)也是未來(lái)比較合適的管理方式。

4 中國聯(lián)通對邊緣計算標準化工作的思考

中國聯(lián)通與2018年3月首次參與ETSI MEC標準化工作。在MEC#13次會(huì )議中，中國聯(lián)通主導的PoC12：MEC Platform to Enable OTT Business國際標準項目成功立項，獲得審核委員會(huì )全票通過(guò)。這是ETSI在邊緣計算領(lǐng)域首個(gè)實(shí)現ICT融合的立項，填補了MEC應用研究方面的空白。自此，中國聯(lián)通牽頭開(kāi)啟了ETSI MEC標準化組織與OTT的應用合作，具有里程碑式的重要意義。該立項建議由中國聯(lián)通聯(lián)合中興通訊、INTEL共同向ETSI MEC #13提交，并由中國聯(lián)通網(wǎng)絡(luò )研究院標準專(zhuān)家進(jìn)行立項申請陳述和答辯。該標準項目將基于業(yè)界最大的天津Edge-Cloud測試床，依托輕量化OpenStack、Kubernetes等虛擬化技術(shù)，以商用化部署為目標，研究vCDN、VR/AR等OTT應用對MEC邊緣云業(yè)務(wù)平臺能力及API的需求，并為ETSI GS MEC 003系統架構的進(jìn)一步完善提供強有力的參考依據，如圖4所示。

圖4 ETSI MEC PoC12：面向OTT業(yè)務(wù)的MEC參考架構

PoC12中所展示的APP部署在邊緣主機上，經(jīng)過(guò)Mp1同MEP對接，獲取MEP上的平臺能力，平臺能力的好壞直接決定了APP是否部署在邊緣主機并接受MEP管控。目前MEP平臺的最大的問(wèn)題就是平臺封閉性嚴重，不同廠(chǎng)家平臺制式不同很難互通，接口私有化定義。造成的后果就是一旦規模部署，每款APP都要分別部署在各方開(kāi)發(fā)的MEP上，因此就都要針對各家平臺進(jìn)行定制化的開(kāi)發(fā)和業(yè)務(wù)對接，這種不友好的方式是不會(huì )被第三方APP所接收，因為這種方式極大地增大了第三方的業(yè)務(wù)重復開(kāi)發(fā)和維護工作。目前的解決方法是，由運營(yíng)商主導MEP平臺，同時(shí)由運營(yíng)商統一開(kāi)展平臺接口標準化和平臺架構標準化，集合設備商的各類(lèi)平臺能力和資源，這樣第三方APP只需要一次開(kāi)發(fā)和對接即可實(shí)現快速業(yè)務(wù)部署，對第三方APP非常友好，平臺也更為開(kāi)放。

在MEC#15次會(huì )議上，中國聯(lián)通提出了基于NAPT的vCDN的方案。該方案最大的特點(diǎn)是，CDN提供方無(wú)需進(jìn)行大量開(kāi)發(fā)工作，只需要將OTT的CDN域名寫(xiě)入中國聯(lián)通的域名服務(wù)器即可。同時(shí)，基于NAPT的方案可以節約大量的公網(wǎng)IP出口，區域內用戶(hù)也可以快速的從本地服務(wù)器上獲取已經(jīng)緩存好的視頻資源。對于HTTPS代理的方法，本次PoC中沒(méi)有采用，由于當前MEC服務(wù)器對數據包的拆解和分析能力有限，如果采用代理的方式，將加重對MEC服務(wù)器的工作量。整體的NAPT方案分為NAPT規則建立部分和本地分流實(shí)現部分，詳細的流程規則如圖5所示。

圖5 基于NAPT的vCDN實(shí)現方案

從系統實(shí)現的角度來(lái)看，基于NAPT的vCDN方案主要是將NAPT規則寫(xiě)入MEC的data plane中，讓整個(gè)MEP平臺具備數據包截獲、建立NAPT規則、完成CDN緩存等一系列流程。而這一架構上的變化，從功能角度來(lái)看，就是讓MEC系統具備packet sniffer的功能。詳細的功能模塊變化如圖6所示。

圖6 基于NAPT的vCDN方案對MEC架構的映射

5 總結

未來(lái)邊緣計算標準化工作將主要面向三個(gè)方面進(jìn)行：首先是MEC同5G的結合。5G商用勢不可擋，全新的5G網(wǎng)絡(luò )架構如何更好地支持邊緣計算將是最為重要的研究方向。盡管3GPP已經(jīng)明確5G網(wǎng)絡(luò )將支持邊緣計算的諸多特性，但是具體如何支持這些特性并沒(méi)有在標準中指明，后續的工作需要運營(yíng)商、設備商和第三方業(yè)務(wù)提供方共同努力協(xié)作完成。其次，是各類(lèi)垂直行業(yè)同MEC的結合。MEC被認為是可以和各類(lèi)垂直行業(yè)如V2X、工業(yè)互聯(lián)網(wǎng)、CDN、安防監控等緊密相關(guān)，MEC的大帶寬、低時(shí)延、海量連接、就近計算等特性似乎可以很好地解決垂直行業(yè)中的技術(shù)難題。但是具體到每一個(gè)行業(yè)，如何讓MEC真正的使能業(yè)務(wù)，卻是一個(gè)非常重要的任務(wù)。以車(chē)聯(lián)網(wǎng)舉例，MEC的就近計算到底要解決車(chē)聯(lián)網(wǎng)中的什么問(wèn)題？MEC真正為車(chē)聯(lián)網(wǎng)的哪些業(yè)務(wù)能夠帶來(lái)質(zhì)變的優(yōu)化？MEC又是如何在車(chē)聯(lián)網(wǎng)業(yè)務(wù)中扮演了不可缺少的角色？這些問(wèn)題都是MEC標準化工作所需要面對的。最后，MEC同開(kāi)源的結合。目前在Linux基金會(huì )和OpenStack組織所分別成立的Akraino項目和Starlingx項目，都是著(zhù)眼于邊緣計算中虛擬化層的架構。未來(lái)在邊緣側，照搬照抄原有繁重的虛擬化部署方案已經(jīng)顯得不夠可取，尤其是邊緣側各類(lèi)資源緊缺的現狀。因此，如何在MEC中更好的加入開(kāi)源，也是未來(lái)標準化工作的重要方面，中國聯(lián)通也將致力于MEC標準化工作，攜手產(chǎn)業(yè)界推動(dòng)MEC商用與落地部署。

作者簡(jiǎn)介：

呂華章，碩士，2017年獲得中國傳媒大學(xué)電路與系統碩士學(xué)位?，F任職于中國聯(lián)通網(wǎng)絡(luò )技術(shù)研究院無(wú)線(xiàn)技術(shù)部邊緣計算團隊，主要負責邊緣云架構、邊緣云平臺研究、邊緣計算標準化、多天線(xiàn)譯碼算法等技術(shù)研究工作。目前已發(fā)表SCI/EI檢索期刊、會(huì )議20余篇。

陳　丹，博士，2012年獲得北京郵電大學(xué)信息與通信工程博士學(xué)位，2010-2011年加拿大不列顛哥倫比亞大學(xué)（UBC）訪(fǎng)問(wèn)學(xué)者&博士聯(lián)合培養?，F任中國聯(lián)通網(wǎng)絡(luò )研究院5G創(chuàng )新中心邊緣計算項目經(jīng)理，負責5G網(wǎng)絡(luò )架構、邊緣計算、C/U分離、網(wǎng)絡(luò )能力開(kāi)放平臺等技術(shù)研究工作。目前已在JSAC、IEEE Transaction on TVT、ICC、GLOBECOM等國際頂級期刊/會(huì )議發(fā)表20余篇SCI/EI論文，并已申請專(zhuān)利30余項，授權6項，被北京郵電大學(xué)聘為碩士研究生企業(yè)導師，榮獲中國聯(lián)通2017年度“5G技術(shù)研究及標準化”一等獎。

王友祥，畢業(yè)于韓國嶺南大學(xué)信息與通信專(zhuān)業(yè)，工學(xué)博士。中國聯(lián)通網(wǎng)絡(luò )技術(shù)研究院高級工程師， 5G技術(shù)經(jīng)理，主要從事無(wú)線(xiàn)通信新技術(shù)、標準化和無(wú)線(xiàn)組網(wǎng)方案等方面的研究工作。先后牽頭、參加了工信部和中國聯(lián)通4G、5G移動(dòng)通信關(guān)鍵技術(shù)多項研究課題，研究成果獲得部級科技進(jìn)步二等獎1次、三等獎1次，中國聯(lián)通科技創(chuàng )新一等獎2次、二等獎3次；牽頭完成中國聯(lián)通承擔的國家重大科技專(zhuān)項課題三項，在研三項；先后在國際及國內期刊、會(huì )議發(fā)表論文40余篇，其中SCI索引論文4篇，EI索引論文30余篇。申請專(zhuān)利30余項，完成專(zhuān)著(zhù)一本。

摘自《自動(dòng)化博覽》2018年增刊《邊緣計算2018專(zhuān)輯》