久久久91-久久久91精品国产一区二区-久久久91精品国产一区二区三区-久久久999国产精品-久久久999久久久精品

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

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

1 ETSI MEC標準化工作綜述

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

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

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

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

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

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

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

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

2 ETSI NFV-MEC平臺架構(gòu)分析

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

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

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

圖3 ETSI MEC017：MEC在NFV下的參考架構(gòu)

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

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

3 第三方APP的管理模式

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

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

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

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

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

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

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

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

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

圖5 基于NAPT的vCDN實現(xiàn)方案

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

圖6 基于NAPT的vCDN方案對MEC架構(gòu)的映射

5 總結(jié)

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

作者簡介：

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

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

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

摘自《自動化博覽》2018年增刊《邊緣計算2018專輯》