電動汽車通信網絡的MEC部署策略研究

石珩臻

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

0 引 言

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

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

當前邊緣計算處于小范圍試商用階段，與邊緣計算有關的應用場景眾多；總體上可分為傳統業務應用場景及新業務應用場景。

1 業務分析

傳統業務應用場景有CDN/視頻流，新業務應用場景包括V2X、智能制造、物聯網等。不同的業務有差異化的需求。典型業務的部署需求如表1所示。

表1 典型業務部署需求

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

2 關鍵技術

對于邊緣計算的典型業務V2X來說，需要綜合考慮服務發現，快速配置等問題[5]。

2.1 服務發現

命名數據網絡（Named Data Networking，NDN）架構與傳統TCP/IP架構類似，也是采用7層架構[6]。不過，該架構將中部的IP層替換成了內容塊，并在該層上下加上了安全層和策略層。該網絡架構解除了IP地址與終端設備之間的綁定關系，使消費者能更高效地獲取該節點所需的內容。因此，在VANETs中使用NDN技術有助于克服因網絡拓撲動態性造成的間歇性的連接問題。

NDN網絡的處理流程與傳統TCP/IP有所不同。在NDN網絡中，有興趣包和數據包兩種形式的包：

（1）當一個節點（生產者或轉發者）收到一個興趣包時，它會檢查其CS（數據內容緩存）內容。如果興趣包的內容名與CS中的內容名一致，則直接依據興趣包按照請求的路徑返回給請求端（消費者）。

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

（3）當一個節點（消費者或轉發者）收到一個數據包時，首先檢查其CS中的內容。如果已有對應的內容，則丟棄；如果沒有對應的內容，則檢查其PIT中的條目。若與數據名稱匹配，則進行轉發，并進行緩存；反之則丟棄該數據包。

2.2 快速配置

車載自組織網絡屬于移動自組織網絡的分支；傳統網絡中控制邏輯和數據轉發緊耦合的方式使得網絡控制平面變得十分復雜。若將SDN技術用于車載自組織網絡中，可以動態地實現網絡資源的彈性分配和控制。在數據傳輸效率、高可靠性方面有明顯的優勢。

SDN整體架構分為數據平面、控制平面和應用平面[7]。控制平面與應用平面之間通過SDN北向接口NBI進行通信；控制平面與數據平面之間基于OpenFlow協議，通過南向接口CDPI進行交互；并實現了數據轉發與規則控制相分離。圖1為基于SDN的電動汽車通信網絡控制編排平面，部署在MEC服務器上。

3 建設方案

本文參考ETSI的MEC標準，基于OpenStack開源框架給出了一種在不影響現有業務的基礎上，將邊緣計算技術引入現有網絡的方案，其網絡拓撲圖如圖2所示。下面將從邊云基礎設施，業務承載網絡與業務部署三個層次對該方案進行介紹。

3.1 邊云基礎設施

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

在電動汽車通信網絡中，MEC服務器與云服務器分別承擔著不同的功能。其中，近端的MEC服務器搭載訓練好的自動駕駛算法，實時進行精準的自動駕駛。并由MEC服務器將處理后的部分數據匯集到云服務器，以進行進一步的分析判斷，完成自主學習閉環。同時，邊緣的數據也在云端有備份；當邊緣計算過程中出現意外情況，存儲在云端的數據也不會丟失。

3.2 業務承載網絡

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

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

3.3 業務部署

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

表2 服務發現三類方式比較

經比較，電動汽車通信網絡應用中的服務發現優先選擇主機獨立進程方案。

對于電動汽車通信網絡應用，存在著異構網絡；為了解決異構網絡中的數據交互，需要用到容器技術。以電動汽車通信網絡應用為例，根據有無車輛協同以及路側協同，其業務分為4類。最簡單的是單車與MEC進行交互，如本地信息分發，動態高精度地圖。其次，是有車輛協同，無路側協同，如V2V信息轉發，車輛感知共享。還有，就是有路側協同，無車輛協同的情況，如危險駕駛提醒，車輛違章預警。此外，有時既有路側協同，又有車輛協同，如智慧交叉路口，大范圍協同調度[12]。

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

4 總結和展望

本文從應用的角度對邊緣計算的典型業務進行了分析，并將邊緣計算引入現有網絡。由于現階段的自動駕駛仍屬于L4及L4以下的自動駕駛；接下來的工作，可考慮在網絡邊緣部署電動汽車通信網絡業務；對電動汽車通信網絡中的邊緣緩存，計算遷移等問題進行進一步的研究。