面向車聯(lián)網(wǎng)基于邊緣計算的點(diǎn)對點(diǎn)信息傳輸

沈大港，范鵬飛，周慧娟，周艷芳，高博文

(1.北方工業(yè)大學(xué)，北京 100144；2.中國科學(xué)院 計算機(jī)網(wǎng)絡(luò)信息中心，北京 100190；3.交通運(yùn)輸部公路科學(xué)研究院，北京 100088；4.中國聯(lián)通北京市分公司，北京 100035)

0 引 言

隨著智能交通的快速發(fā)展，安裝有車聯(lián)網(wǎng)設(shè)備的機(jī)動車數(shù)量不斷增加，而且車聯(lián)網(wǎng)設(shè)備的種類數(shù)量也獲得了發(fā)展。這些情況的出現(xiàn)，使車聯(lián)網(wǎng)技術(shù)具備了獲得大發(fā)展的應(yīng)用基礎(chǔ)，使得如今移動車載終端的業(yè)務(wù)環(huán)境更加復(fù)雜，消息的類型更加繁多。移動邊緣計算由ETSI國際標(biāo)準(zhǔn)組織提出并制定，是基于5G架構(gòu)將基站與互聯(lián)網(wǎng)業(yè)務(wù)相融合的技術(shù)；是利用無線接入網(wǎng),將就近電信用戶所需的服務(wù)融于云計算能力,所搭建的電信級服務(wù)環(huán)境[1]。無線資源有限，如何在有限的帶寬資源下，確保車輛和乘客的需求均能得到滿足，及確保帶寬資源的合理分配及利用，提高空口帶寬利用效用，成為一個有待解決的問題[2]。一方面是有限資源的競爭會增加消息處理的時延，另一方面是對車載終端設(shè)備造成較大的能量消耗[3]?，F(xiàn)有的信息傳輸過程主要有以下3點(diǎn)不足：

(1)當(dāng)控制方案與實際交通需求出現(xiàn)不適應(yīng)時，傳統(tǒng)的反饋至總控制云端(即總控中心)進(jìn)行運(yùn)算工作，處理后再下發(fā)控制的方案無疑會造成一段時間內(nèi)的交通資源浪費(fèi)。

(2)通常情況下，總控中心與具體交通設(shè)備的物理距離相對較遠(yuǎn)，所以會使交通信息在傳輸過程出現(xiàn)丟包、延時等情況。

(3)大量數(shù)據(jù)流匯集云端或者總控中心，加重服務(wù)器負(fù)擔(dān)的同時，擠占處理能力與方案下發(fā)能力，進(jìn)一步削弱方案的時效性。

目前車聯(lián)網(wǎng)的發(fā)展重點(diǎn)已逐漸從核心網(wǎng)轉(zhuǎn)向邊緣網(wǎng)，在靠近車載終端的網(wǎng)絡(luò)邊緣分布式地部署各類網(wǎng)絡(luò)資源，以盡可能地將各類消息任務(wù)從云平臺遷移到邊緣側(cè)進(jìn)行響應(yīng)實現(xiàn)[4]。邊緣計算在國內(nèi)外，在交通方面被研究應(yīng)用于軌道交通之中，以滿足鐵路信息化的高速發(fā)展。鐵路網(wǎng)絡(luò)對移動通信提出了越來越高的要求，高鐵網(wǎng)絡(luò)中、車地之間的數(shù)據(jù)通過無線進(jìn)行傳輸。而邊緣計算技術(shù)在車路協(xié)同應(yīng)用場景分為以用戶體驗為核心的信息服務(wù)類應(yīng)用、以車輛駕駛為核心的汽車智能化類應(yīng)用和以協(xié)同為核心的智慧交通類應(yīng)用三大類型[5]。如今在國內(nèi)，車聯(lián)網(wǎng)的發(fā)展正由核心網(wǎng)轉(zhuǎn)變?yōu)檫吘壘W(wǎng)?，F(xiàn)在關(guān)于邊緣網(wǎng)的研究主要集中在園區(qū)的局內(nèi)網(wǎng)處理與計算。根據(jù)各大研究機(jī)構(gòu)的預(yù)測，車聯(lián)網(wǎng)將是5G最先落地、也是最大的應(yīng)用[6]。而邊緣計算則是支持5G網(wǎng)絡(luò)低延時、高信息通道和低丟包的關(guān)鍵技術(shù)。目前在國內(nèi)外，如何邊緣部署MEC平臺以支持車聯(lián)網(wǎng)應(yīng)用是研究的重點(diǎn)。

文中的研究意義在于將MEC移動邊緣計算的思想融入車聯(lián)網(wǎng)。研究內(nèi)容旨在針對具體的車聯(lián)網(wǎng)交通信息傳輸系統(tǒng)，借助MEC邊緣計算環(huán)境，幫助其提高工作效率。針對具體的交通傳輸系統(tǒng)場景，在其結(jié)構(gòu)中加入MEC服務(wù)器。分析在其傳輸系統(tǒng)中加入MEC服務(wù)器后的傳輸特點(diǎn)并設(shè)計出對應(yīng)的點(diǎn)對點(diǎn)傳輸系統(tǒng)。針對同時滿足車與車和車與路直接的信息傳輸這一目的，分別編寫了用戶設(shè)備間數(shù)據(jù)傳輸子系統(tǒng)和數(shù)據(jù)傳輸輔助服務(wù)子系統(tǒng)，形成了一種新的傳輸系統(tǒng)機(jī)制。編寫完成后對標(biāo)之前分析的傳輸特點(diǎn)進(jìn)行優(yōu)化，設(shè)計并實現(xiàn)了對傳輸過程優(yōu)化的關(guān)鍵技術(shù)。從而達(dá)到降低服務(wù)響應(yīng)時延，優(yōu)化現(xiàn)有車聯(lián)網(wǎng)信息傳輸系統(tǒng)的目的。

1 車聯(lián)網(wǎng)傳輸系統(tǒng)現(xiàn)狀分析

為進(jìn)一步找出傳統(tǒng)車聯(lián)網(wǎng)場景下交通信息傳輸?shù)膯栴}，本研究利用Veins仿真平臺對傳統(tǒng)的車聯(lián)網(wǎng)信息傳輸系統(tǒng)進(jìn)行仿真。Veins仿真平臺是由OMNET++網(wǎng)絡(luò)模擬器和SUMO道路交通模擬器組成的仿真器[7]。其為車聯(lián)網(wǎng)環(huán)境下的仿真提供了一套開源的仿真架構(gòu)[8]。

經(jīng)發(fā)現(xiàn)，直線道路的車輛分布簡單，能比較直觀地反映不同的車輛密度下的路由跳數(shù)參數(shù)對通信情況的影響。利用Veins，該文設(shè)計了一段5 km的雙向四車道直線道路仿真場景。并且將仿真實驗設(shè)計為一般城市場景，采集2 500 m×2 500 m的城市道路區(qū)域的實時仿真數(shù)據(jù)。車輛是以每秒鐘給定的概率隨機(jī)生成，且生成的道路位置和速度均為隨機(jī)，生成的車輛服從泊松分布。網(wǎng)絡(luò)應(yīng)用層方面使用了UdpApp，車輛在道路生成后以0 s～5 s的隨機(jī)時間周期地發(fā)送信息，每個數(shù)據(jù)包的長度設(shè)置為不大于5 mb。網(wǎng)絡(luò)層格式為Ipv4報文格式。MAC層為802.11p標(biāo)準(zhǔn)，節(jié)點(diǎn)的有效通訊范圍設(shè)置為300 m。仿真運(yùn)行的時間根據(jù)車流密度和道路長度設(shè)計為300 s～600 s，仿真結(jié)果評價網(wǎng)絡(luò)的通信性能指標(biāo)為車輛密度、最大路由數(shù)對應(yīng)的投遞率和端到端延遲。

由圖1、圖2可以看出，傳輸?shù)男畔⒘颗c端到端延遲量之間幾乎成正比，即車輛密度越大，信息量越大，則延遲越大。當(dāng)延時過大時，用戶的網(wǎng)絡(luò)體驗越差，同時交通信息的時效性也會喪失[9]。而由包投遞率則可以看出，當(dāng)基站服務(wù)器與道路車聯(lián)網(wǎng)端的比值越多時，其丟包率就越小。而當(dāng)基站高于一個閾值時，便會出現(xiàn)網(wǎng)絡(luò)資源過剩的情況，因文中主要解決網(wǎng)絡(luò)資源不夠的問題，故不討論閾值以后的情況。綜上所述，車聯(lián)網(wǎng)傳輸?shù)倪^程中需對以下問題進(jìn)行改善：

圖1 不同車輛密度和最大路由的端到端延時

圖2 不同車輛密度和最大路由的包投遞率

(1)解決車輛通信端增多而造成的網(wǎng)絡(luò)堵塞現(xiàn)象：

(2)在不降低信息量的情況下降低丟包率：

(3)解決延時大、信息量多情況下的交通信息的時效性問題。

2 基于邊緣計算技術(shù)的車聯(lián)網(wǎng)傳輸系統(tǒng)設(shè)計與實現(xiàn)

2.1 基于邊緣計算技術(shù)的車聯(lián)網(wǎng)信息傳輸系統(tǒng)結(jié)構(gòu)設(shè)計

由上文可知，現(xiàn)今，傳統(tǒng)車聯(lián)網(wǎng)的信息傳輸系統(tǒng)存在丟包、延時、信息堵塞和時效性差等問題。隨著交通領(lǐng)域研究的不斷發(fā)展，利用車聯(lián)網(wǎng)治理交通擁堵的理論及實踐研究越來越多，但交通擁堵不是短期就可以解決的，要真正解決好城市交通擁堵問題，還需要進(jìn)行大量和細(xì)致的研究工作[10]。MEC(multi-access edge computing)邊緣計算產(chǎn)業(yè)聯(lián)盟對邊緣計算下的定義是在靠近端或者數(shù)據(jù)源頭的網(wǎng)絡(luò)邊緣側(cè)，通過部署融合了網(wǎng)絡(luò)、存儲、計算、應(yīng)用核心能力的開放平臺，就近提供邊緣智能服務(wù)，滿足行業(yè)數(shù)字化在敏捷聯(lián)接、實時業(yè)務(wù)、數(shù)據(jù)優(yōu)化、應(yīng)用智能、安全與隱私保護(hù)等方面的關(guān)鍵需求[11]。如果將邊緣計算技術(shù)的思路引入車聯(lián)網(wǎng)的信息傳輸系統(tǒng)中，情況將大為改觀。故為解決上述問題，針對現(xiàn)實情況下傳統(tǒng)的車聯(lián)網(wǎng)傳輸系統(tǒng)，在其匯聚節(jié)點(diǎn)前加入MEC服務(wù)器以下沉處理與計算工作。設(shè)計了一套利用邊緣計算技術(shù)思想，應(yīng)對當(dāng)前車聯(lián)網(wǎng)傳輸系統(tǒng)各類問題的新機(jī)制。

如圖3所示，將MEC服務(wù)器架設(shè)至總控中心與具體管理設(shè)施之間，其現(xiàn)實交通場景中通常表現(xiàn)為具有MEC服務(wù)器功能的網(wǎng)絡(luò)信號基站[12]。由于MEC服務(wù)器具有存儲、計算和處理數(shù)據(jù)的功能[13]，所以，原本需要在總控中心進(jìn)行的計算現(xiàn)在下沉到MEC服務(wù)器。而在新機(jī)制下，加載MEC服務(wù)器的車聯(lián)網(wǎng)交通信息傳輸系統(tǒng)相較于傳統(tǒng)的交通信息傳輸系統(tǒng)有三點(diǎn)優(yōu)勢：

圖3 基于邊緣計算的車聯(lián)網(wǎng)信息傳輸結(jié)構(gòu)

(1)降低了信息傳輸?shù)臅r延性，提高了數(shù)據(jù)傳輸?shù)乃俣扰c穩(wěn)定性；

(2)將處理工作下沉，減少了總控中心的工作量；

(3)提高了控制方案的時效性，實現(xiàn)控制系統(tǒng)更加靈敏，直接減少了交通資源的浪費(fèi)。

2.2 點(diǎn)對點(diǎn)傳輸系統(tǒng)的設(shè)計與實現(xiàn)

在以上新機(jī)制下的系統(tǒng)架構(gòu)下，進(jìn)一步設(shè)計了一套改進(jìn)的基于邊緣計算技術(shù)，應(yīng)用于此機(jī)制下的點(diǎn)對點(diǎn)傳輸系統(tǒng)。系統(tǒng)組成結(jié)構(gòu)與運(yùn)行邏輯如圖4所示。

圖4 點(diǎn)對點(diǎn)傳輸系統(tǒng)結(jié)構(gòu)

這一套系統(tǒng)主要由兩個分工明確的子系統(tǒng)組成——用于用戶設(shè)備間信息傳輸?shù)淖酉到y(tǒng)和用于數(shù)據(jù)傳輸輔助服子系統(tǒng)。其中前者進(jìn)行信息傳輸?shù)膬啥司鶠橛脩舳?，所以，此子系統(tǒng)的設(shè)計核心為提高用戶體驗。而數(shù)據(jù)傳輸輔助服子系統(tǒng)主要面向的是服務(wù)器對用戶端或者另一服務(wù)器端之間的傳輸，所以，此子系統(tǒng)的設(shè)計核心為優(yōu)化傳輸過程。兩個子系統(tǒng)的系統(tǒng)結(jié)果如圖5、圖6所示。

圖5 用戶設(shè)備間信息傳輸?shù)淖酉到y(tǒng)結(jié)構(gòu)

圖6 數(shù)據(jù)傳輸輔助服子系統(tǒng)結(jié)構(gòu)

2.3 傳輸系統(tǒng)優(yōu)化

根據(jù)第一節(jié)的仿真實驗結(jié)果和現(xiàn)實中實際情況發(fā)現(xiàn)，在具體的邊緣計算下的交通場景中，常常會涉及到大文件的傳輸。如何保證大文件傳輸過程的穩(wěn)定性和速度不可避免地成為一個待解決的重要問題。而通過研究發(fā)現(xiàn)，如若在其信息的傳輸過程中，采用邊緣計算技術(shù)中的信息分片、并發(fā)上傳技術(shù)，可以大大地優(yōu)化其傳輸速度并提高穩(wěn)定性。因此，該文針對具有切分信息能力的用戶端和服務(wù)器，設(shè)計了具有切分式并發(fā)上傳和斷點(diǎn)續(xù)傳功能的傳輸模塊。本程序的切分上傳步驟主要分為三個部分：確定切分?jǐn)?shù)量、上傳切分文件塊和合并切分文件塊。

第一步：上傳的文件會首先被讀取信息，并讀取數(shù)據(jù)庫檢測是否為已上傳。若不是，文件在后端讀取到的信息會放入數(shù)據(jù)庫等地方。若是則停止上傳并提醒用戶。

第二步：后端會得到根據(jù)已讀取到的文件信息預(yù)計總分塊個數(shù)，并開始對文件進(jìn)行切分。切分的分塊大小可根據(jù)文件的大小進(jìn)行調(diào)整。

第三步：后端會首先檢測當(dāng)前分塊文件數(shù)量是否為預(yù)計數(shù)量(即檢測是否上傳完畢)，并根據(jù)當(dāng)前時間已上傳的分塊文件個數(shù)，返回上傳文件的總進(jìn)度。如此循環(huán)直至上傳完畢。當(dāng)用戶上傳中想要停止上傳請求時,可通過點(diǎn)擊前端停止按鈕，如此，后端會停止上傳剩余待上傳的分塊文件并刪除緩存文件夾中現(xiàn)有的分塊文件。

信息分片化實現(xiàn)后，經(jīng)車聯(lián)網(wǎng)仿真實驗發(fā)現(xiàn)，當(dāng)一個區(qū)域內(nèi)車聯(lián)網(wǎng)用戶端達(dá)到一個比較大的值時，大量的交通數(shù)據(jù)匯集在當(dāng)?shù)鼗緦⒊霈F(xiàn)網(wǎng)絡(luò)堵塞的問題[14]，上傳會耗費(fèi)較多的時間，而上傳過程若耗費(fèi)太多時間相當(dāng)于耽誤了MEC服務(wù)器后臺處理或用戶分享這些交通數(shù)據(jù)的時間。為解決此問題，該子系統(tǒng)基于信息分片技術(shù)設(shè)計并實現(xiàn)了信息上傳、下載和信息處理同步進(jìn)行的方式。上傳下載同步的實現(xiàn)過程主要采用了文件塊合并進(jìn)度與下載進(jìn)度指針聯(lián)動的方式。

第一步：當(dāng)待上傳文件存入tmpfile(apacha臨時文件夾)時，后端會生成三個下載鏈接，分別是：平常的下載鏈接、二維碼化的下載鏈接和下載指針與合并進(jìn)度聯(lián)動的特殊下載鏈接。

第二步：當(dāng)用戶對未上傳完成的文件發(fā)出下載請求時，后端會將這一特殊下載鏈接返回給用戶，用戶在下載的時候，下載目標(biāo)并不是最終存放文件夾upload中的文件，而是uploading文件夾中與原文件屬性相同的特殊文件。這一特殊文件原為擁有上傳文件相同的屬性的空文件，并不斷地接受來自己上傳文件塊的文件合并，在合并的同時返回$blod_num序號，依此來控制用戶下載的進(jìn)度。

本功能實現(xiàn)后，大大提高了文件處理與分享的效率。

3 實驗及結(jié)果分析

3.1 實驗環(huán)境

實驗環(huán)境主要設(shè)置如下：

(1)傳輸平臺。

服務(wù)器端：

--windows下的Google chrome瀏覽器。

用戶端：

--windows下的Google chrome瀏覽器。

--Android手機(jī)上的Google chrome瀏覽器。

--Ios手機(jī)上的Safari瀏覽器。

(2)平臺擴(kuò)展模塊。

模塊1：apacha開發(fā)與瀏覽支持模塊，包括：apr-util-1.6.1、apr-1.7.0、pcre-8.43、httpd-2.4.41。

模塊2：websocket與webrtc的擴(kuò)展api。

模塊3：mysql數(shù)據(jù)庫平臺。

模塊4：瀏覽器內(nèi)置php編譯器。

(3)網(wǎng)絡(luò)傳輸主要協(xié)議。

協(xié)議1：http協(xié)議。

協(xié)議2：websocket協(xié)議。

3.2 實驗內(nèi)容

第1個要驗證的實驗問題為在邊緣計算中利用多線程并發(fā)傳輸技術(shù)的加入是否改善了傳輸過程，同時對邊上傳邊下載功能對傳輸過程的改善設(shè)計實驗驗證。采用的方法為控制變量法，不變的量為文件名、所用軟件、均在局域網(wǎng)等客觀因素。變量為傳輸?shù)倪^程是否采用并發(fā)傳輸技術(shù)，實驗過程為對照傳輸相同的文件，分析傳輸?shù)乃俣扰c質(zhì)量。對邊上傳邊下載功能的驗證為生成一個內(nèi)容由特定字符組成，大小為10M的記事本文件并上傳，分別下載其上傳進(jìn)度為20%～40%、100%時的文件，對照原文件檢測文件是否有存在丟包或損害。實驗中，傳輸兩端設(shè)定為pc發(fā)起端與服務(wù)器響應(yīng)端。

第2個要驗證的實驗問題為邊緣計算技術(shù)的加入是否改善了車聯(lián)網(wǎng)的傳輸過程。本實驗采用控制變量法，其中不變的量為文件、傳輸方式、使用軟件等客觀因素。變量為傳輸?shù)膬啥耸欠裨跒橥痪W(wǎng)絡(luò)下進(jìn)行傳輸。實驗過程為對照chorme瀏覽器下分片傳輸相同的文件，并分別對局域網(wǎng)下和互聯(lián)網(wǎng)下傳輸?shù)倪^程進(jìn)行記錄并分析。實驗中，局內(nèi)網(wǎng)設(shè)定為未連接互聯(lián)網(wǎng)的內(nèi)網(wǎng)，其傳輸過程需通過局內(nèi)網(wǎng)絡(luò)，但不需通過云端。而互聯(lián)網(wǎng)傳輸則由發(fā)起端通過互聯(lián)網(wǎng)上傳中間端，再通過中間端下載至響應(yīng)端。實驗過程中，兩傳輸端的物理距離始終為定量。圖7為部分實驗過程網(wǎng)絡(luò)示意圖。

圖7 網(wǎng)絡(luò)示意圖

3.3 實驗結(jié)果分析

如表1所示，傳輸為整塊，單個傳輸所花時間較慢，總體傳輸時間也偏慢。而若服務(wù)器切分之后進(jìn)行傳輸，單個傳輸比較快，且總體傳輸比起前者來說，同樣較快。

表1 實驗1 pc端下的網(wǎng)絡(luò)傳輸結(jié)果

可以看出，傳輸?shù)奈募K多線程并發(fā)上傳情況下，無論是傳輸速度還是總的傳輸時間，均比在整體上傳情況下進(jìn)行傳輸要有一定改善。同時，經(jīng)檢測得知，上傳下載功能對記事本文件的內(nèi)容不存在丟包或者損害，且其能夠改善用戶傳輸效率。綜上所述，在pc端下，多線程網(wǎng)絡(luò)分片化技術(shù)運(yùn)用于車聯(lián)網(wǎng)內(nèi)在改善網(wǎng)絡(luò)傳輸過程的同時，還能帶來諸如斷點(diǎn)續(xù)傳和上傳下載同時進(jìn)行等附加功能。而在手機(jī)端下，由于其端性能制約，帶來的傳輸改善并不明顯，其功能主要體現(xiàn)在防丟包與斷點(diǎn)續(xù)傳兩項上。而同時上傳下載的功能，無疑將大程度地改善用戶的使用體驗即總效率。

在測試的過程中，互聯(lián)網(wǎng)測試的速度與網(wǎng)絡(luò)質(zhì)量有關(guān)系，且相比于局內(nèi)網(wǎng)傳輸，互聯(lián)網(wǎng)傳輸測試更依賴于傳輸兩端的性能、網(wǎng)速和測試軟件環(huán)境等因素。而局內(nèi)網(wǎng)，通常情況下只與網(wǎng)絡(luò)質(zhì)量有關(guān)，傳輸兩端的性能、測試軟件環(huán)境等因素影響不大。

表2、表3為傳輸測試結(jié)果的主要參數(shù)?？梢钥闯?，傳輸?shù)奈募K邊緣計算技術(shù)在局內(nèi)網(wǎng)內(nèi)進(jìn)行傳輸，無論是傳輸速度的穩(wěn)定性，還是總的傳輸時間，均比在互聯(lián)網(wǎng)情況下進(jìn)行傳輸要快。其中，pc端的改善相較于手機(jī)端更加明顯。綜上所述，邊緣計算技術(shù)運(yùn)用在車聯(lián)網(wǎng)內(nèi)將極大地改善網(wǎng)絡(luò)傳輸過程。

表2 實驗2 pc端下的網(wǎng)絡(luò)傳輸結(jié)果

表3 實驗2 手機(jī)端下的網(wǎng)絡(luò)傳輸結(jié)果

3.4 實驗結(jié)論

由以上設(shè)計的實驗及其結(jié)果可以看出，邊緣計算技術(shù)的加入對于改善車聯(lián)網(wǎng)情況下用戶的網(wǎng)絡(luò)體驗和信息傳輸效率有很大提升。其使得在具體的交通場景中，網(wǎng)絡(luò)信息可以具有更好的時效性與穩(wěn)定性。同時使得總控中心和云端的運(yùn)算工作與網(wǎng)絡(luò)需求均得到了明顯的降低。由此可以看出，車聯(lián)網(wǎng)場景下的計算與處理工作邊緣化是今后車聯(lián)網(wǎng)想要進(jìn)一步獲得更大發(fā)展的方向與措施[15]。

當(dāng)邊緣計算技術(shù)應(yīng)用于車聯(lián)網(wǎng)下的交通后，如何設(shè)計其MEC服務(wù)器的系統(tǒng)部署就顯得尤為重要。而由文中設(shè)計部署于MEC服務(wù)器的傳輸系統(tǒng)及其子系統(tǒng)，并進(jìn)行實驗驗證后的結(jié)果可以明顯看出，邊緣計算技術(shù)中的信息分片并發(fā)傳輸與上傳、下載、處理同時進(jìn)行可以很明顯地加快傳輸速度和提高傳輸穩(wěn)定性?？梢哉f，今后邊緣計算系統(tǒng)的部署，這一方面的技術(shù)將在改善網(wǎng)絡(luò)情況和傳輸過程方面顯得尤為重要。

綜上所述，新機(jī)制可以顯著降低服務(wù)響應(yīng)時延，提升車聯(lián)網(wǎng)信息傳輸效率。

4 結(jié)束語

針對車聯(lián)網(wǎng)下利用邊緣計算技術(shù)進(jìn)行交通之間的信息傳輸，提出了一套從架構(gòu)部署到系統(tǒng)設(shè)計的完整的機(jī)制。充分利用了MEC服務(wù)器邊緣部署的優(yōu)勢，將信息的處理與傳輸下放，并采用與之相適應(yīng)的專門設(shè)計的系統(tǒng)支持，并通過設(shè)計實驗進(jìn)行驗證，證明了其相較以往大大提高了交通信息傳輸?shù)男省Ｔ撐牡淖畲髣?chuàng)新點(diǎn)是將邊緣計算的思想應(yīng)用于車聯(lián)網(wǎng)的信息傳輸系統(tǒng)中，通過仿真具體分析了車聯(lián)網(wǎng)信息傳輸?shù)奶攸c(diǎn)與傳輸需求。得到這些特點(diǎn)后，對標(biāo)算法，提出解決方案，并設(shè)計實驗驗證，完美解決了傳輸中出現(xiàn)的問題。

未來該系統(tǒng)還需要進(jìn)一步完善，方向可以是對前后端代碼進(jìn)行精簡優(yōu)化，使得系統(tǒng)能夠更加穩(wěn)定高效地運(yùn)行。并且也可以在當(dāng)前的基礎(chǔ)上進(jìn)一步開發(fā)更多功能，如：用戶端算法中更全的功能、服務(wù)器算法中更高的處理效率、更加細(xì)分化的管理功能等。