MEC – 我們?cè)絹碓浇藛幔浚?/h1>
多接入邊緣計(jì)算(MEC)或之前的移動(dòng)邊緣計(jì)算在過去幾年中一直是很流行的術(shù)語,尤其是去年5G技術(shù)進(jìn)入了商業(yè)階段。MEC通常用于描述將服務(wù)推向網(wǎng)絡(luò)邊緣的概念,與霧計(jì)算等其他術(shù)語存在沖突,隨著這項(xiàng)技術(shù)與5G、容器等基礎(chǔ)設(shè)施技術(shù)聯(lián)系在一起,其中各種混淆也越來越多。本文從電信公司的角度揭開這一技術(shù)的神秘面紗。
MEC的定義和框架來自ETSI,歐洲電信標(biāo)準(zhǔn)化協(xié)會(huì),作為MEC行業(yè)規(guī)范小組(ISG)的一部分,于2014年12月開始工作。以下是ETSI的定義。
多接入邊緣計(jì)算(MEC)為應(yīng)用程序開發(fā)人員和內(nèi)容提供商提供了云計(jì)算功能,以及在網(wǎng)絡(luò)邊緣的IT服務(wù)環(huán)境。這種環(huán)境的特點(diǎn)是超低延遲和高帶寬以及對(duì)應(yīng)用程序可以利用的無線網(wǎng)絡(luò)信息的實(shí)時(shí)訪問。
這個(gè)定義為電信運(yùn)營(yíng)商繪制了一張路線圖,以便通過IaaS/PaaS模型在邊緣提供云計(jì)算功能。所以讓我們?cè)谶@里停住并指出,MEC的概念沒有與5G結(jié)合,盡管它可以在滿足5G的超延遲和千兆體驗(yàn)需求方面發(fā)揮重要作用。 ETSI MEC最初提供了一個(gè)框架和一個(gè)有趣的參考架構(gòu),如下所示。
該規(guī)范于2016年3月發(fā)布,在移動(dòng)運(yùn)營(yíng)商中引發(fā)了許多問號(hào)。下面列出了一些常見的問題,并附上了作者觀點(diǎn)。
網(wǎng)絡(luò)中的MEC主機(jī)位置是什么?它可以存在于BTS嗎?區(qū)域DC?它可以駐留在終端用戶場(chǎng)所嗎?
MEC被認(rèn)為距離終端用戶只有一步之遙,但是沒有明確表示它應(yīng)該駐留在BTS或Edge DC中。因此,我們可以認(rèn)為它不會(huì)觸及終端設(shè)備或物聯(lián)網(wǎng)設(shè)備,它只是網(wǎng)絡(luò)的一跳,可以匹配BTS和Edge DC。
在邊緣放置網(wǎng)絡(luò)功能的數(shù)據(jù)平面的機(jī)制是什么?
有了CUPS,現(xiàn)在就可以在邊緣分別部署用戶平面功能了。我認(rèn)為5G UPF和SGW/PGW-U完全吻合。此外,通過適當(dāng)?shù)姆?wù)/資源編排,可以在邊緣部署一些VNF,例如Gi-LAN功能和增值服務(wù)(緩存、FW、Parental Control等)。
MEC主機(jī)上可以運(yùn)行哪些服務(wù)(MEC App),它們是否需要特殊的基礎(chǔ)設(shè)施需求?
這些可以是由第三方開發(fā)人員開發(fā)的第三方應(yīng)用程序。因此,運(yùn)營(yíng)商基本上可以為那些公司或者開發(fā)商提供IaaS/PaaS,以開發(fā)需要MEC特性(如超延遲)的特殊用途應(yīng)用程序。 VR / AR、IoT和V2I應(yīng)用程序就是一個(gè)例子。
對(duì)于基礎(chǔ)設(shè)施來說,這些應(yīng)用程序很可能基于容器。因此,運(yùn)營(yíng)商必須利用可托管和“管理”容器的環(huán)境。
VIM(例如Openstack)如何管理有數(shù)百或數(shù)千個(gè)DC的遠(yuǎn)程基礎(chǔ)設(shè)施環(huán)境?
不是很清楚,目前有一些開源計(jì)劃、小組和論壇,但到目前為止還沒有什么實(shí)體。兩種趨勢(shì):
- 集中管理 - 所有OpenStack控制組件僅部署在主DC中,而代理和消息總線跨越所有DC。
- 分布式管理 - 每個(gè)DC都部署了整個(gè)OpenStack控制組件
應(yīng)該在邊緣部署什么樣的基礎(chǔ)設(shè)施?
應(yīng)該是輕便的、占地面積小,并且具有低功耗和相對(duì)良好的計(jì)算能力的廉價(jià)基礎(chǔ)設(shè)施。白盒似乎是一個(gè)合適的解決方案。
工作負(fù)載是否會(huì)在VM上運(yùn)行?容器?裸機(jī)?
出于某些原因,容器總是在MEC工作負(fù)載上下的表中。但是,工作負(fù)載可以在任何東西上運(yùn)行。上圖是SDx Central 2017年邊緣計(jì)算和MEC報(bào)告調(diào)查結(jié)果,其中問題是“什么將被用來管理邊緣平臺(tái)”,受訪者來自廠商和運(yùn)營(yíng)商團(tuán)隊(duì)。
MEC是5G的組成部分之一嗎?
它可以是,但是這是強(qiáng)制性的嗎?我不這么認(rèn)為。5G國(guó)際電聯(lián)的要求非常明確,如果運(yùn)營(yíng)商設(shè)法向終端用戶提供5G服務(wù)/特性,可以不必部署ETSI MEC概念。它們之間沒有緊密的聯(lián)系。
MEC如何與ETSI NFV參考架構(gòu)相關(guān)或匹配?
最近發(fā)布的ETSI MEC規(guī)范之一GR MEC 017 Mobile Edge Computing(MEC);在NFV環(huán)境中部署移動(dòng)邊緣計(jì)算。有趣的是,新的網(wǎng)絡(luò)元素已經(jīng)被引入,例如MEAO,多接入邊緣應(yīng)用編排,這引發(fā)了許多關(guān)于這種編排的功能以及它如何與NFVO集成的疑問。
MEAO應(yīng)該管理移動(dòng)邊緣應(yīng)用程序包的上載、跨邊緣DC的資源編排、為應(yīng)用程序?qū)嵗x擇適當(dāng)?shù)囊苿?dòng)邊緣主機(jī),以及使用以下參考點(diǎn)觸發(fā)應(yīng)用程序?qū)嵗⒔K止和重定位。
- 移動(dòng)邊緣編排器和OSS之間的Mm1參考點(diǎn)用于觸發(fā)移動(dòng)邊緣系統(tǒng)中的移動(dòng)邊緣應(yīng)用的實(shí)例化和終止。
- 用戶應(yīng)用程序生命周期管理代理與移動(dòng)邊緣系統(tǒng)的移動(dòng)邊緣編排器之間的Mm9參考點(diǎn)用于管理UE應(yīng)用程序請(qǐng)求的移動(dòng)邊緣應(yīng)用程序。
- 移動(dòng)邊緣編排器和移動(dòng)邊緣平臺(tái)管理器之間的Mm3參考點(diǎn)用于管理應(yīng)用程序生命周期、應(yīng)用程序規(guī)則和需求以及跟蹤可用的移動(dòng)邊緣服務(wù)。
- Mv1參考點(diǎn)連接MEAO和NFVO。它與Os-Ma-nfvo參考點(diǎn)有關(guān),如ETSI NFV中所定義的,仍在評(píng)估中。
現(xiàn)在要看到這種集成商業(yè)化還為時(shí)尚早。與任何其他標(biāo)準(zhǔn)或開源計(jì)劃一樣,它需要社區(qū)的支持。
原文鏈接:https://www.netmanias.com/en/?m=view&id=blog&no=13893