摘要:邊緣計算目前已經成為產業界和學術界的研究熱點,在靠近業務的網絡邊緣側部署計算處理能力能夠極大地滿足未來業務對低時延、大帶寬、高可靠的要求,極大的支持了未來車聯網、工業控制、智能制造、大視頻等業務。同時邊緣計算也是5G原生使能技術,未來的5G網絡架構已經明確支持邊緣計算的諸多特性。歐洲電信標準化組織ETSI是最早開始進行邊緣計算標準化的國際組織,目前該組織已經完成第二階段的標準化,對外公布包括MEC平臺架構、業務需求、管理編排、API接口在內的20余份標準化文稿,對產業界和學術界具有極大的指導意義。本文重點分析ETSI MEC標準化組織的研究進展,同時對該組織所提出的MEC架構進行技術分析,最后提出中國聯通對于MEC標準化工作的一些看法。
關鍵詞:邊緣計算;ETSI;MEC;標準化
1 ETSI MEC標準化工作綜述
ETSI歐洲電信標準化組織,在2014年率先啟動MEC標準項目。這一項目組旨在移動網絡邊緣為應用開發商與內容提供商搭建一個云化計算與IT環境的服務平臺,并通過該平臺開放無線側網絡信息,實現高帶寬、低時延業務支撐與本地管理。聯盟的初創成員包括惠普、沃達豐、華為、諾基亞、Intel以及Viavi。目前ETSI MEC標準化組織已經吸引了國內外數百家運營商、設備商、軟件開發商、內容提供商參與其中,ETSI MEC的影響力也逐漸擴大。
在2017年底,ETSI MEC標準化組織已經完成了Phase I階段基于傳統4G網絡架構部署,定義邊緣計算系統應用場景、參考架構、邊緣計算平臺應用支撐API、應用生命周期管理與運維框架、以及無線側能力服務API(RNIS/定位/帶寬管理)。目前正在進行的PhaseII階段,則主要聚焦在包括5G/Wi-Fi/固網在內的多接入邊緣計算系統,重點覆蓋MECin NFV參考架構、端到端邊緣應用移動性、網絡切片支撐、合法監聽、基于容器的應用部署、V2X支撐、Wi-Fi與固網能力開放等研究項目,從而更好地支撐MEC商業化部署與固移融合需求,第二階段的標準化于2018年9月底之前完成,同期將開啟第三階段的標準維護和標準新增階段。ETSI MEC標準化的內容主要包括以下內容:研究MEC需求、平臺架構、編排管理、接口規范、應用場景研究等。
圖1 ETSI MEC標準化的第一階段與第二階段工作示意圖
ETSI MEC還陸續發布了多本MEC白皮書,內容涉及到C-RAN、MEC從4G到5G的演進、MEC關鍵技術以及MEC軟件實現等,如圖2所示。這些白皮書主要給出了MEC對現網和未來網絡架構的融合構想,提出了切實的解決方案和演進規劃,但是對于具體的技術實現細節是沒有過多介紹的。
圖2 ETSI MEC標準化發布行業白皮書
ETSI MEC還鼓勵各會員單位和參與公司積極提交MEC PoC,PoC的內容主要是各大公司所開展的MEC實際落地的工作。ETSI MEC認為,MEC非常偏向實踐和應用,需要結合具體業務場景進行落地,因此標準組織非常希望能夠有更多的MEC落地方案能夠提交到組織中以產生更多的示范效應和指導意義。目前PoC的總數已經達到12個,業務范疇覆蓋了IoT、V2X、CDN、工業控制等。
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所面臨的問題。
2 ETSI NFV-MEC平臺架構分析
ETSI MEC017協議于2018年2月最新發布,重點描述了MEC在NFV環境下的部署,如圖3所示。MEC作為與生俱來的帶有NFV屬性的一套生態,MEC017協議可以認為是MEC003協議的進一步的擴展,更加面向實際部署和落地。MEC017中詳細的參考架構如圖所示。整個架構遵循以下原則:已有的電信網NFV架構網元部分盡可能的重用,MEC模塊可調用NFV部分功能,MEC內部功能模塊之間的信令不受NFV管理編排器控制,MEC同NFV之間的接口要重新定義。
整個參考架構可以看做是MEC003同ETSINFV架構(ETSI GS NFV 002)之間的一套融合方案。這一參考架構中,主要分為三個部分:重用NFV架構部分、MEC架構部分以及共用網元模塊部分。
以OSS、NFVO、VNFM(ME APP LCM)、VIM、NFVI為組合,被NFV參考點所連接的網元,是NFV架構部分。這些網元都是ETSI NFV中已經定義的網元,在這里直接引入MEC架構中實現了網元功能的重用。要注意的是,NFV標準化要早于MEC。之所以考慮重用網元,是因為MEC中的各類功能模塊和網元,也涉及到了虛擬化基礎設施的搭建、虛擬化基礎設施的管理、虛擬化管理和編排、生命周期管理等內容,因此這部分可以直接調用NFV的網元,而無需再進行重復開發。因為目前各大運營商的網元虛擬化工作早已經開展,很多的開發工作也已經完成,現網正在運行,因此根據MEC業務和NFV業務的共性對NFV的網元進行重用是非常有必要的。需要說明的是,對于NFV網元之間的接口,其功能和信令交互流程可以保持不變,而對于NFV網元和MEC功能模塊之間的接口,可能需要新定義或者新開發,比如:Mv2接口。
圖3 ETSI MEC017:MEC在NFV下的參考架構
以ME APP、MEP、MEPM-V、VNFM(MEPLCM)、dataplane、CFSPortal、UEAPP、UEAPPLCM proxy、OSS、MEAO為組合,被MEC參考點所連接的網元,是MEC原有架構部分,這部分已經在MEC003中定義和說明過。這些功能模塊是屬于MEC特有的網元,是基于NFV基礎上,根據MEC業務特性和業務需求所設定的全新的功能模塊架構。由于NFV的網元大多是面向電信網的網元,而MEC則更加偏向第三方APP和業務,業務種類也比NFV更加多樣,如:定位、分流、IoT、視頻編解碼等等。所以,基于MEC業務種類繁多的特性,有必要在NFV的基礎上增加若干個功能不一的模塊來協助MEP實現更多的功能。這里需要說明一點,MEC需要虛擬化資源和管理,因此,MEC重用了NFVI和VIM的部分,可直接調用而無需二次開發。MEC模塊同NFV網元之間的接口,也存在著重新開發和定義的問題。
以NFVI、VIM、OSS為組合,可視為MEC和NFV重用的網元部分。這些網元在進行電信網NFV開發和部署的時候就已經建設完成了,MEC相關業務在運行時也需要他們的支持,因此直接重用即可。
3 第三方APP的管理模式
APP的管理對MEC來說是重要的部分,對APP的管理方式其背后代表了未來計算平臺的運維模式和管理策略。ME APP既受控于有MEC背景的MEPM-V,也受控于有NFV架構背景的VNFM(ME APP LCM),其本質在于ME APP是否與MEP有交互,是否使用了ME service或獲取平臺能力進行優化。
(1)ME APP受控于MEPM-V。這種方式表明了ME APP部署在NFVI上,同時經由Mp1接口,連接到MEP平臺,并可能使用ME service,遵從MEPM-V的管理。由于MEPM-V中包含了ME APP規則和需求管理,因此這種方式就默認了ME APP要受到MEP平臺的管理。通常MEP可以是運營商自建也可以是設備商的集成設備,總之,這種管理方式就意味著第三方APP部署在MEP上時必須受到平臺的管理,這種管理方式的好處顯而易見,有利用邊緣生態中APP的管理和調度,但是未來可能存在一個問題,如果ME APP只是想用這些NFVI的資源,而對MEP上的ME service不敢興趣,那么這種管理就使得第三方APP難以接受,因為目前Mp1接口定義的還不夠充分,第三方也需要圍繞MEP進行定制化開發,這些都加重了第三方的工作量,需要考慮第三方的需求和想法。但是作為MEC構建生態的想法,我們更傾向于提供第三方APP足夠的PaaS能力。
(2)ME APP受控于VNFM(ME APP LCM)。這種管理方式,即ME APP僅受到NFV網元的管理,也就是只是對ME APP的生存周期進行管理。這種方式表明第三方的APP僅僅是租用了邊緣數據中心的NFVI,進行部署,但是不使用任何MEP中的service和平臺能力,因此ME APP僅僅從資源層面受到管理。這種商業模式其實就是租賃機房資源、租賃機架、租賃硬件資源、租賃虛擬機的商業模式,從實現來講受益更加直接,第三方直接獲取資源自行開發相應服務,運營商也無需在MEC平臺層面做過多的開發。但是這種方式并不是在營造MEC生態,因為這一管理方式徹底拋棄了APP同MEP之間的關聯, Mp1接口完全廢棄,那么MEP也沒有了存在的價值,因此這種方式只可在早期不成熟的時候采用,長期發展對MEC生態和建設非常不利。
(3)ME APP同時受控于MEPM-V和VNFM(MEAPP LCM)。這種方式結合了MEC中APP管理和NFV中的APP管理。NFV僅對APP的生存周期和虛擬化資源進行管理,而MEC則對ME APP規則和需求進行管理,分工明確職責不同。同時定義好Mp1接口,提供ME APP使用MEP中ME service的途徑,借助邊緣云平臺能力可以進行APP的定制優化。這種方式一方面迎合了APP和MEC平臺搭建方的各方需求,同時也是未來比較合適的管理方式。
4 中國聯通對邊緣計算標準化工作的思考
中國聯通與2018年3月首次參與ETSI MEC標準化工作。在MEC#13次會議中,中國聯通主導的PoC12:MEC Platform to Enable OTT Business國際標準項目成功立項,獲得審核委員會全票通過。這是ETSI在邊緣計算領域首個實現ICT融合的立項,填補了MEC應用研究方面的空白。自此,中國聯通牽頭開啟了ETSI MEC標準化組織與OTT的應用合作,具有里程碑式的重要意義。該立項建議由中國聯通聯合中興通訊、INTEL共同向ETSI MEC #13提交,并由中國聯通網絡研究院標準專家進行立項申請陳述和答辯。該標準項目將基于業界最大的天津Edge-Cloud測試床,依托輕量化OpenStack、Kubernetes等虛擬化技術,以商用化部署為目標,研究vCDN、VR/AR等OTT應用對MEC邊緣云業務平臺能力及API的需求,并為ETSI GS MEC 003系統架構的進一步完善提供強有力的參考依據,如圖4所示。
圖4 ETSI MEC PoC12:面向OTT業務的MEC參考架構
PoC12中所展示的APP部署在邊緣主機上,經過Mp1同MEP對接,獲取MEP上的平臺能力,平臺能力的好壞直接決定了APP是否部署在邊緣主機并接受MEP管控。目前MEP平臺的最大的問題就是平臺封閉性嚴重,不同廠家平臺制式不同很難互通,接口私有化定義。造成的后果就是一旦規模部署,每款APP都要分別部署在各方開發的MEP上,因此就都要針對各家平臺進行定制化的開發和業務對接,這種不友好的方式是不會被第三方APP所接收,因為這種方式極大地增大了第三方的業務重復開發和維護工作。目前的解決方法是,由運營商主導MEP平臺,同時由運營商統一開展平臺接口標準化和平臺架構標準化,集合設備商的各類平臺能力和資源,這樣第三方APP只需要一次開發和對接即可實現快速業務部署,對第三方APP非常友好,平臺也更為開放。
在MEC#15次會議上,中國聯通提出了基于NAPT的vCDN的方案。該方案最大的特點是,CDN提供方無需進行大量開發工作,只需要將OTT的CDN域名寫入中國聯通的域名服務器即可。同時,基于NAPT的方案可以節約大量的公網IP出口,區域內用戶也可以快速的從本地服務器上獲取已經緩存好的視頻資源。對于HTTPS代理的方法,本次PoC中沒有采用,由于當前MEC服務器對數據包的拆解和分析能力有限,如果采用代理的方式,將加重對MEC服務器的工作量。整體的NAPT方案分為NAPT規則建立部分和本地分流實現部分,詳細的流程規則如圖5所示。
圖5 基于NAPT的vCDN實現方案
從系統實現的角度來看,基于NAPT的vCDN方案主要是將NAPT規則寫入MEC的data plane中,讓整個MEP平臺具備數據包截獲、建立NAPT規則、完成CDN緩存等一系列流程。而這一架構上的變化,從功能角度來看,就是讓MEC系統具備packet sniffer的功能。詳細的功能模塊變化如圖6所示。
圖6 基于NAPT的vCDN方案對MEC架構的映射
5 總結
未來邊緣計算標準化工作將主要面向三個方面進行:首先是MEC同5G的結合。5G商用勢不可擋,全新的5G網絡架構如何更好地支持邊緣計算將是最為重要的研究方向。盡管3GPP已經明確5G網絡將支持邊緣計算的諸多特性,但是具體如何支持這些特性并沒有在標準中指明,后續的工作需要運營商、設備商和第三方業務提供方共同努力協作完成。其次,是各類垂直行業同MEC的結合。MEC被認為是可以和各類垂直行業如V2X、工業互聯網、CDN、安防監控等緊密相關,MEC的大帶寬、低時延、海量連接、就近計算等特性似乎可以很好地解決垂直行業中的技術難題。但是具體到每一個行業,如何讓MEC真正的使能業務,卻是一個非常重要的任務。以車聯網舉例,MEC的就近計算到底要解決車聯網中的什么問題?MEC真正為車聯網的哪些業務能夠帶來質變的優化?MEC又是如何在車聯網業務中扮演了不可缺少的角色?這些問題都是MEC標準化工作所需要面對的。最后,MEC同開源的結合。目前在Linux基金會和OpenStack組織所分別成立的Akraino項目和Starlingx項目,都是著眼于邊緣計算中虛擬化層的架構。未來在邊緣側,照搬照抄原有繁重的虛擬化部署方案已經顯得不夠可取,尤其是邊緣側各類資源緊缺的現狀。因此,如何在MEC中更好的加入開源,也是未來標準化工作的重要方面,中國聯通也將致力于MEC標準化工作,攜手產業界推動MEC商用與落地部署。
作者簡介:
呂華章,碩士,2017年獲得中國傳媒大學電路與系統碩士學位。現任職于中國聯通網絡技術研究院無線技術部邊緣計算團隊,主要負責邊緣云架構、邊緣云平臺研究、邊緣計算標準化、多天線譯碼算法等技術研究工作。目前已發表SCI/EI檢索期刊、會議20余篇。
陳 丹,博士,2012年獲得北京郵電大學信息與通信工程博士學位,2010-2011年加拿大不列顛哥倫比亞大學(UBC)訪問學者&博士聯合培養。現任中國聯通網絡研究院5G創新中心邊緣計算項目經理,負責5G網絡架構、邊緣計算、C/U分離、網絡能力開放平臺等技術研究工作。目前已在JSAC、IEEE Transaction on TVT、ICC、GLOBECOM等國際頂級期刊/會議發表20余篇SCI/EI論文,并已申請專利30余項,授權6項,被北京郵電大學聘為碩士研究生企業導師,榮獲中國聯通2017年度“5G技術研究及標準化”一等獎。
王友祥,畢業于韓國嶺南大學信息與通信專業,工學博士。中國聯通網絡技術研究院高級工程師, 5G技術經理,主要從事無線通信新技術、標準化和無線組網方案等方面的研究工作。先后牽頭、參加了工信部和中國聯通4G、5G移動通信關鍵技術多項研究課題,研究成果獲得部級科技進步二等獎1次、三等獎1次,中國聯通科技創新一等獎2次、二等獎3次;牽頭完成中國聯通承擔的國家重大科技專項課題三項,在研三項;先后在國際及國內期刊、會議發表論文40余篇,其中SCI索引論文4篇,EI索引論文30余篇。申請專利30余項,完成專著一本。
摘自《自動化博覽》2018年增刊《邊緣計算2018專輯》