電動汽車通信網(wǎng)絡(luò)的MEC部署策略研究

石珩臻

（華信咨詢設(shè)計研究院，浙江 杭州 310052）

0 引 言

自2006年云計算出現(xiàn)以來，人們的生活都享受到了其帶來的改變，如Google Apps，Weibo，Wechat，Tiktok等軟件即服務(wù)實例。新終端也更傾向于引入云計算技術(shù)。據(jù)愛立信預(yù)測，到2023年，將有320億臺終端設(shè)備連接到移動網(wǎng)絡(luò)。大量的終端設(shè)備給用戶帶來了便捷的服務(wù)，但是隨之帶來了可靠連接及低延遲連接等QoS方面的挑戰(zhàn)。為此，人們提出了移動邊緣計算（Mobile Edge Computing，MEC）的概念，以解決云計算存在較長的傳播時延的問題[1]。因此，邊緣計算也被廣泛認(rèn)為是實現(xiàn)下一代互聯(lián)網(wǎng)的關(guān)鍵技術(shù)。

邊緣計算的前身是CDN，它于1998年由Akamai公司提出；此時，只是強調(diào)對內(nèi)容進(jìn)行緩存，并不涉及到功能緩存。直到2005年，施巍松教授團(tuán)隊才在個性化的郵箱管理服務(wù)中使用了功能緩存的思想[2]。隨后，出現(xiàn)了強調(diào)云服務(wù)功能下行的Cloudlet；從此，國內(nèi)外出現(xiàn)了ETSI和ECC等聯(lián)盟，制定和完善了邊緣計算的行業(yè)標(biāo)準(zhǔn)[3,4]。2019年9月，IMT-2020（5G）推進(jìn)組支持創(chuàng)建的首批MEC與C-V2X融合測試床正式啟動。

當(dāng)前邊緣計算處于小范圍試商用階段，與邊緣計算有關(guān)的應(yīng)用場景眾多；總體上可分為傳統(tǒng)業(yè)務(wù)應(yīng)用場景及新業(yè)務(wù)應(yīng)用場景。

1 業(yè)務(wù)分析

傳統(tǒng)業(yè)務(wù)應(yīng)用場景有CDN/視頻流，新業(yè)務(wù)應(yīng)用場景包括V2X、智能制造、物聯(lián)網(wǎng)等。不同的業(yè)務(wù)有差異化的需求。典型業(yè)務(wù)的部署需求如表1所示。

表1 典型業(yè)務(wù)部署需求

其中，V2X業(yè)務(wù)對時延和帶寬的要求都比較高，時延要求小于10 ms，帶寬大于100 M。當(dāng)MEC服務(wù)器部署于接入網(wǎng)后的傳輸匯聚機房，可滿足V2X業(yè)務(wù)對時延和帶寬的需求。

2 關(guān)鍵技術(shù)

對于邊緣計算的典型業(yè)務(wù)V2X來說，需要綜合考慮服務(wù)發(fā)現(xiàn)，快速配置等問題[5]。

2.1 服務(wù)發(fā)現(xiàn)

命名數(shù)據(jù)網(wǎng)絡(luò)（Named Data Networking，NDN）架構(gòu)與傳統(tǒng)TCP/IP架構(gòu)類似，也是采用7層架構(gòu)[6]。不過，該架構(gòu)將中部的IP層替換成了內(nèi)容塊，并在該層上下加上了安全層和策略層。該網(wǎng)絡(luò)架構(gòu)解除了IP地址與終端設(shè)備之間的綁定關(guān)系，使消費者能更高效地獲取該節(jié)點所需的內(nèi)容。因此，在VANETs中使用NDN技術(shù)有助于克服因網(wǎng)絡(luò)拓?fù)鋭討B(tài)性造成的間歇性的連接問題。

NDN網(wǎng)絡(luò)的處理流程與傳統(tǒng)TCP/IP有所不同。在NDN網(wǎng)絡(luò)中，有興趣包和數(shù)據(jù)包兩種形式的包：

（1）當(dāng)一個節(jié)點（生產(chǎn)者或轉(zhuǎn)發(fā)者）收到一個興趣包時，它會檢查其CS（數(shù)據(jù)內(nèi)容緩存）內(nèi)容。如果興趣包的內(nèi)容名與CS中的內(nèi)容名一致，則直接依據(jù)興趣包按照請求的路徑返回給請求端（消費者）。

（2）如果不一致，則檢查其PIT（待處理信息表）中的條目。此時，如果有匹配的條目，則在對應(yīng)條目中添加與興趣包消費者對應(yīng)的接口；如果不匹配，再檢查其FIB（轉(zhuǎn)發(fā)信息表）。若有匹配項，則按照FIB中的接口進(jìn)行轉(zhuǎn)發(fā)；若仍不匹配，則丟棄或者回復(fù)NACK信息。

（3）當(dāng)一個節(jié)點（消費者或轉(zhuǎn)發(fā)者）收到一個數(shù)據(jù)包時，首先檢查其CS中的內(nèi)容。如果已有對應(yīng)的內(nèi)容，則丟棄；如果沒有對應(yīng)的內(nèi)容，則檢查其PIT中的條目。若與數(shù)據(jù)名稱匹配，則進(jìn)行轉(zhuǎn)發(fā)，并進(jìn)行緩存；反之則丟棄該數(shù)據(jù)包。

2.2 快速配置

車載自組織網(wǎng)絡(luò)屬于移動自組織網(wǎng)絡(luò)的分支；傳統(tǒng)網(wǎng)絡(luò)中控制邏輯和數(shù)據(jù)轉(zhuǎn)發(fā)緊耦合的方式使得網(wǎng)絡(luò)控制平面變得十分復(fù)雜。若將SDN技術(shù)用于車載自組織網(wǎng)絡(luò)中，可以動態(tài)地實現(xiàn)網(wǎng)絡(luò)資源的彈性分配和控制。在數(shù)據(jù)傳輸效率、高可靠性方面有明顯的優(yōu)勢。

SDN整體架構(gòu)分為數(shù)據(jù)平面、控制平面和應(yīng)用平面[7]?？刂破矫媾c應(yīng)用平面之間通過SDN北向接口NBI進(jìn)行通信；控制平面與數(shù)據(jù)平面之間基于OpenFlow協(xié)議，通過南向接口CDPI進(jìn)行交互；并實現(xiàn)了數(shù)據(jù)轉(zhuǎn)發(fā)與規(guī)則控制相分離。圖1為基于SDN的電動汽車通信網(wǎng)絡(luò)控制編排平面，部署在MEC服務(wù)器上。

3 建設(shè)方案

本文參考ETSI的MEC標(biāo)準(zhǔn)，基于OpenStack開源框架給出了一種在不影響現(xiàn)有業(yè)務(wù)的基礎(chǔ)上，將邊緣計算技術(shù)引入現(xiàn)有網(wǎng)絡(luò)的方案，其網(wǎng)絡(luò)拓?fù)鋱D如圖2所示。下面將從邊云基礎(chǔ)設(shè)施，業(yè)務(wù)承載網(wǎng)絡(luò)與業(yè)務(wù)部署三個層次對該方案進(jìn)行介紹。

3.1 邊云基礎(chǔ)設(shè)施

在該拓?fù)鋱D中，存在著MEC服務(wù)器與云服務(wù)器。云服務(wù)器一般部署在云端（5GC機房），而MEC服務(wù)器可根據(jù)業(yè)務(wù)場景不同，以標(biāo)準(zhǔn)服務(wù)器、多節(jié)點一體機、一體機、小盒子等形式部署在地市核心機房、傳輸匯聚機房、綜合接入機房、站點機房等不同位置。一般來說，MEC服務(wù)器越靠近終端用戶，緩存加速服務(wù)（Traffic Caching and Accelerating Service，TCAS）對QoE的提升效果越明顯，相應(yīng)的網(wǎng)絡(luò)傳輸資源要求和MEC設(shè)備的性能指標(biāo)要求會有所降低[8-9]。然而，MEC部署越靠近網(wǎng)絡(luò)邊緣，所需的MEC數(shù)量也會隨之增加，從而導(dǎo)致總成本以及管理復(fù)雜度的提升。

在電動汽車通信網(wǎng)絡(luò)中，MEC服務(wù)器與云服務(wù)器分別承擔(dān)著不同的功能。其中，近端的MEC服務(wù)器搭載訓(xùn)練好的自動駕駛算法，實時進(jìn)行精準(zhǔn)的自動駕駛。并由MEC服務(wù)器將處理后的部分?jǐn)?shù)據(jù)匯集到云服務(wù)器，以進(jìn)行進(jìn)一步的分析判斷，完成自主學(xué)習(xí)閉環(huán)。同時，邊緣的數(shù)據(jù)也在云端有備份；當(dāng)邊緣計算過程中出現(xiàn)意外情況，存儲在云端的數(shù)據(jù)也不會丟失。

3.2 業(yè)務(wù)承載網(wǎng)絡(luò)

5G承載網(wǎng)承載著多種業(yè)務(wù)。N4/N5口業(yè)務(wù)承載在IP承載網(wǎng)上，N6/N9口業(yè)務(wù)媒體面承載在CMNET上。對于N4/N5業(yè)務(wù)，位于地市MEC UPF的N4，AF的N5；通過IP專網(wǎng)CE，承載在IP專網(wǎng)“信令VPN”上；位于區(qū)縣MEC UPF的N4，AF的N5，通過傳輸專線就近接入到地市的IP專網(wǎng)CE實現(xiàn)承載。對于N6/N9口業(yè)務(wù)，在地市機房，MEC通過防火墻接入CR，承載在CMNET上；在區(qū)縣機房，部署在BRAS/SR機房，新增防火墻，通過BRAS承載在CMNET上；區(qū)縣以下的MEC業(yè)務(wù)通過傳輸專線（PON/SPN/PTN）接入就近區(qū)縣的BRAS，進(jìn)而承載在CMNET上。

然而，并不是所有的數(shù)據(jù)都需要經(jīng)過承載網(wǎng)上傳到云端，這就需要在MEC進(jìn)行分流。這樣做能避免傳統(tǒng)網(wǎng)絡(luò)中的流量迂回，降低業(yè)務(wù)時延。常見的分流方案有3種，分別是基于L3/L4規(guī)則及域名實現(xiàn)本地分流、基于APN/DNN的本地分流、基于UL CL（UPF下沉）實現(xiàn)本地分流[10]。

3.3 業(yè)務(wù)部署

就具體應(yīng)用而言，邊緣計算可應(yīng)用于電動汽車通信網(wǎng)絡(luò)。其中，采用了NDN技術(shù)，容器技術(shù)。電動汽車通信網(wǎng)絡(luò)應(yīng)用中涉及到大量的攝像頭、傳感器，這些采集設(shè)備每時每刻都在產(chǎn)生大量的數(shù)據(jù)；以一個包含8個720P攝像頭，4個其他傳感器的自動駕駛汽車為例，其每天產(chǎn)生的數(shù)據(jù)量就高達(dá)4 TB。在這些場景中，要想實現(xiàn)某些特定的功能，服務(wù)發(fā)現(xiàn)是一個不得不面對的問題。服務(wù)發(fā)現(xiàn)的主流方法有3種，分別是傳統(tǒng)集中式代理，客戶端嵌入式代理，主機獨立進(jìn)程方案[11]。這幾種服務(wù)發(fā)現(xiàn)方案的優(yōu)缺點對比如表2。

表2 服務(wù)發(fā)現(xiàn)三類方式比較

經(jīng)比較，電動汽車通信網(wǎng)絡(luò)應(yīng)用中的服務(wù)發(fā)現(xiàn)優(yōu)先選擇主機獨立進(jìn)程方案。

對于電動汽車通信網(wǎng)絡(luò)應(yīng)用，存在著異構(gòu)網(wǎng)絡(luò)；為了解決異構(gòu)網(wǎng)絡(luò)中的數(shù)據(jù)交互，需要用到容器技術(shù)。以電動汽車通信網(wǎng)絡(luò)應(yīng)用為例，根據(jù)有無車輛協(xié)同以及路側(cè)協(xié)同，其業(yè)務(wù)分為4類。最簡單的是單車與MEC進(jìn)行交互，如本地信息分發(fā)，動態(tài)高精度地圖。其次，是有車輛協(xié)同，無路側(cè)協(xié)同，如V2V信息轉(zhuǎn)發(fā)，車輛感知共享。還有，就是有路側(cè)協(xié)同，無車輛協(xié)同的情況，如危險駕駛提醒，車輛違章預(yù)警。此外，有時既有路側(cè)協(xié)同，又有車輛協(xié)同，如智慧交叉路口，大范圍協(xié)同調(diào)度[12]。

根據(jù)不同業(yè)務(wù)部署的需求，業(yè)務(wù)支撐系統(tǒng)向MEC下發(fā)部署指令，可在邊緣服務(wù)器上根據(jù)部署指令下載鏡像并創(chuàng)建容器，拉起多項服務(wù)。當(dāng)自動駕駛車輛需要某項服務(wù)時，可由自動駕駛車輛的OBU進(jìn)行處理；當(dāng)OBU無法處理時，才由部署于MEC的service進(jìn)行處理，且在處理完成后經(jīng)過網(wǎng)絡(luò)返回處理結(jié)果。由于MEC相較于云服務(wù)器更靠近終端，因此該操作可能在電動汽車通信網(wǎng)絡(luò)場景下實現(xiàn)更低的時延，帶來更加安全可靠的服務(wù)。

4 總結(jié)和展望

本文從應(yīng)用的角度對邊緣計算的典型業(yè)務(wù)進(jìn)行了分析，并將邊緣計算引入現(xiàn)有網(wǎng)絡(luò)。由于現(xiàn)階段的自動駕駛?cè)詫儆贚4及L4以下的自動駕駛；接下來的工作，可考慮在網(wǎng)絡(luò)邊緣部署電動汽車通信網(wǎng)絡(luò)業(yè)務(wù)；對電動汽車通信網(wǎng)絡(luò)中的邊緣緩存，計算遷移等問題進(jìn)行進(jìn)一步的研究。