ARVE: Augmented Reality Applications in Vehicle to Edge Networks

ARVE：車輛到邊緣網中的加強現實應用

本文爲SIGCOMM 2018 Workshop (Mobile Edge Communications, MECOMM)論文。

筆者翻譯了該論文。因爲時間倉促，且筆者英文能力有限，錯誤之處在所不免；歡迎讀者批評指正。

本文及翻譯版本僅用於學習使用。若是有任何不當，請聯繫筆者刪除。

本文做者包含4位，Pengyuan Zhou@University of Helsinki, Finland；Wenxiao Zhang@Hong Kong University of Science and Technology, Hong Kong; Tristan Braud@Hong Kong University of Science and Technology, Hong Kong; Pan Hui@Hong Kong University of Science and Technology, Hong Kong； Jussi Kangasharju@University of Helsinki, Finland

ABSTRACT (摘要）

Vehicular communication applications, be it for driver-assisting augmented reality systems or fully driverless vehicles, require an efficient communication infrastructure for timely information delivery. Centralized, cloud-based infrastructures present latencies too high to satisfy the requirements of emergency information processing and transmission. In this paper, we present a novel Vehicle-to-Edge (ARVE) infrastructure, with computational units co-located with the base stations and aggregation points. Embedding computation at the edge of the network allows to reduce the overall latency compared to vehicle-to-cloud and signifcantly trim the complexity of vehicle-to-vehicle communication. To demonstrate the efficiency of our solution, we apply these principles on an augmented reality head-up display. In this use case, vehicular communication is exploited to connect vehicle’s vision, and quickly propagate emergency information. ARVE is a general system framework, applicable to many practical scenarios. Our preliminary evaluation shows that ARVE noticeably decreases transmission latency with reasonable capital expenditure.

不管是駕駛輔助加強現實系統仍是徹底無人駕駛車輛，車輛通訊應用都須要有效的通訊基礎設施來及時傳遞信息。集中式、基於雲的基礎設施存在太高的延遲，沒法知足緊急信息處理和傳輸的要求。在本文中，咱們提出了一種新穎的車輛到邊緣（ARVE）基礎設施，其計算單元與基站和聚合點共存。與車輛到雲相比，在網絡邊緣嵌入計算容許減小整體延遲而且顯着地減小車輛到車輛通訊的複雜性。爲了展現咱們解決方案的效率，咱們將這些原則應用於加強現實汽車平視顯示器。在該用例中，利用車輛通訊來鏈接車輛的視覺，並快速傳播緊急信息。 ARVE是一個通用的系統框架，適用於許多實際場景。咱們的初步評估代表，ARVE經過合理的資本支出顯着下降了傳輸延遲。

1 INTRODUCTION （引言）

Connected automated driving has recently become closer to being a reality. In 2018, California and Shanghai authorized the deployment of autonomous vehicles on public roads for testing purposes [3, 21]. Vehicular communication systems play a key role in sharing information between vehicles and roadside infrastructure units (RSU) . Use cases include emergency warning system for vehicles, cooperative adaptive cruise control, collision warning etc. Current solutions focus on three types of communication: vehicleto-vehicle (V2V), vehicle-to-cloud (V2C), and vehicle-to-roadside infrastructure (V2I) [8, 10]. Although these solutions fulfll basic demands, efficiently sharing complex and large volumes of data among vehicles at scale remains a challenge. 

最近，鏈接自動駕駛變得更加接近現實。 2018年，加利福尼亞和上海受權在公路上部署自動駕駛汽車進行試驗[3,21]。 車輛通訊系統在車輛和路邊基礎設施單元（RSU）之間共享信息方面起着關鍵做用。 用例包括車輛緊急警告系統，協同自適應巡航控制，碰撞警告等。目前的解決方案集中在三種類型的通訊：車輛到車輛（V2V），車輛到雲（V2C）和車輛到路邊基礎設施 （V2I）[8,10]。 雖然這些解決方案知足了基本需求，可是在大規模車輛之間有效地共享複雜和大量的數據仍然是一個挑戰。

Figure 1 illustrates two related scenarios: (1) The leading truck encounters an unexpected pothole. The truck notifes the following cars to avoid a potential accident. (2) Congested traffic is out of sight for cars planning to take the road on the right. Once aware, these cars will choose a better path. In V2C, even though the leading truck immediately uploads the captured pothole information, the combined latency of transmission, processing and distribution may be too high for the following vehicles to avoid it. Similarly, the connection establishment time of V2V communication with the complexity of forwarding information in a constantly varying crowd of nodes can lead to vehicles having only partial knowledge of the situation. V2I provides better data distribution; however, sharing accurate emergency information entails nontrivial computation and coordination. Roadside infrastructures should therefore integrate computing features for fast and reliable emergency information propagation. 

圖1描述了兩個相關場景：（1）領頭的卡車遇到意外的坑洞。 卡車通知後續車輛以免潛在的事故。（2）對於計劃在右側行駛的汽車而言，擁擠的交通是不可見的。 一旦意識到擁擠，這些汽車將選擇更好的路徑。 在V2C中，即便領頭的卡車當即上傳捕獲的坑洞信息，傳輸、處理和分發的組合延遲對於後續車輛來講也可能過高從而沒法避免。 相似地，V2V通訊的鏈接創建時間與在不斷變化的節點羣中轉發信息的複雜性可致使車輛僅具備對狀況的部分了解。 V2I提供更好的數據分發; 然而，共享準確的緊急信息須要非凡的計算和協調。 所以，路邊基礎設施應集成計算功能，以實現快速可靠的緊急信息傳播。

圖1： 常見車輛鏈接場景

Edge computing facilitates latency-sensitive workloads by performing data processing in Edge Servers (ESes) located close to the user. The gain in latency provided by edge computing can be considerable. In Table 1, we measured the round trip latency for various servers through an LTE network: the first pingable IP, noted as Edge, a cloud server located in the same city and another server 1000 km away. Unsurprisingly, the latency to the closest server is half the round trip time to the furthest cloud server. Moreover, the ES presents a 20% improvement compared to the nearest cloud server, making it an attractive location for latency-sensitive applications. 

邊緣計算經過在靠近用戶的邊緣服務器（ESes）中執行數據處理來推動延遲敏感的工做負載。邊緣計算提供的延遲增益可能至關大。 表1中，咱們經過LTE網絡測量了各類服務器的往返延遲：第一個可ping的IP(標記爲Edge)、位於同一城市的雲服務器和1000千米外的另外一個服務器。 不出所料，到最近服務器的延遲是到最遠的雲服務器的往返時間的一半。 此外，與最近的雲服務器相比，邊緣服務器提升了20％，使其成爲延遲敏感的應用程序的有吸引力的位置。

表1：經過LTE到不一樣目標的平均網絡往返延遲。

We propose to use vehicle-to-edge (V2E) to enhance vehicular communications. Our design, ARVE, is a framework designed to be independent of the actual protocols, in order to allow it to apply equally to current as well as future networks. We choose to apply those principle to Connected Vehicle Views (CVV), a concrete use case of ARVE (see Section 3 for a detailed discussion of this use case) .

咱們提出使用車輛到邊緣（V2E）網絡來加強車輛通訊。 咱們設計的ARVE是一個獨立於實際協議的框架，使其可以同等地應用於當前和將來的網絡。 咱們選擇將這些原則應用於連通車輛視圖（CVV），這是ARVE的具體用例（有關此用例的詳細討論，請參閱第3節）。

Our contribution is threefold:

咱們的貢獻有三個：

• We present the design of ARVE, which equips RSUs with computation and cache capacity. 
• 咱們介紹了ARVE的設計，它爲RSU（路邊基礎設施單元）配備了計算和緩存容量。
• Concrete application of ARVE to CVV using Augmented Reality Head-up Display (ARHUD). This use case displays the advantages of ARVE while scaling the problem of vehicle vision from a network perspective. 
• ARVE在CVV中的具體應用，採用加強現實汽車平視顯示器（ARHUD）。 該用例展現了ARVE的優點，同時從網絡角度擴展了車輛視覺問題。
• We present a preliminary evaluation to show that ARVE offers noticeable performance improvements with reasonable expenditure in infrastructure. 
• 咱們給出初步評估，以代表ARVE在基礎設施方面的合理支出的情形下提供了顯着的性能改進。

The rest of paper is structured as follows. After a review of related work in section 2, we introduce the ARHUD use case in section 3. We then describe the system design, implementation and communication process of ARVE in section 4. The potential network protocols are discussed in section 5. Preliminary evaluation results are given in section 6. We conclude the paper in section 7. 

論文剩餘部分的結構以下。 在第2節回顧相關工做以後，咱們在第3節介紹了ARHUD用例。而後在第4節中描述ARVE的系統設計，實現和通訊過程。潛在的網絡協議將在第5節中討論。初步評估結果在第6節中給出。咱們在第7節中總結了這篇論文。

 3 USE CASE: CONNECTED ARHUD （用例：連通ARHUD）

One of the main concerns in the automotive world is safety. According to the 2015 National Motor Vehicle Crash Causation Survey by National Highway Traffic Safety Administration (NHTSA), 93% of crashes are attributed to drivers, of which, around 74% are due to erroneous recognition or decision [20]. However, autonomous vehicles can also get 「confused」 easily. For instance, GM Cruise autonomous cars sometimes slow down or stop if they see a bush on the roadside [13] and similar issues exist in lane changes. As such, the intervention of a human driver is still critical for safety. To assist the driver, vehicles are outftted with sensors and display devices which provide valuable information to the driver, such as about environmental condition and the driver’s driving habits. The most common display method is a heads-up-display (HUD). 

汽車領域的主要關注點之一是安全性。根據美國國家公路交通安全管理局（NHTSA）2015年全國機動車碰撞緣由調查，93％的車禍歸因於司機，其中約74％是因爲錯誤的承認或決定形成的[20]。 然而，自動駕駛汽車也容易「混淆」。例如，若是通用機器的Cruise自動駕駛汽車在路邊看到灌木叢時，它們有時會減速或中止[13]，而且在車道變換中存在相似的問題。 所以，人類駕駛員的干預對於安全仍然相當重要。 爲了幫助駕駛員，車輛配備有傳感器和顯示裝置，其向駕駛員提供有價值的信息，例如關於環境條件和駕駛員的駕駛習慣的信息。 最多見的顯示方法是汽車平視顯示器（HUD）。

In recent years, augmented-reality (AR) HUDs have attracted both academic and industrial attention [14, 22]. AR can embed 3-D views of the information into the rendering background on the HUD, enabling accurate obstacle recognition and emergency notifcation. Previous work has put effort on matching the embedded information with the real environment, cognitive usability, visibility, among others [17, 18]. However, connecting vehicle views via ARHUD remains a challenge. Recently, the authors in [19] explored how to share vision between two vehicles. Although the work proposed solutions for basic view transformation, it is still not enough to connect vehicle vision at scale under realistic concerns of bandwidth, latency and computational resources. 

近年來，加強現實（AR）HUD吸引了學術和工業界的關注[14,22]。 AR能夠將信息的三維視圖嵌入到HUD上的渲染背景中，從而實現準確的障礙識別和緊急通知。之前的工做已經將嵌入信息與真實環境、感知可用性和可見性等相匹配[17,18]。 可是，經過AR HUD鏈接車輛視圖仍然是一個挑戰。 最近，文獻[19]的做者探討了如何在兩輛車之間共享視覺。 儘管該工做提出了基本視圖轉換的解決方案，但在帶寬，延遲和計算資源的現實考慮下，仍然不足以大規模地鏈接車輛視覺。

Challenges are multiple: (1) A crowd-sourced map which is the combined 3D point cloud from the independent real-time views of the connected vehicles, acts as a reference coordinate system to localize incidents. This map is too voluminous for both real time generation and transmission, hence we need to develop additional mechanisms to address its proper generation and maintenance. (2) Proper network protocol stack needs to be explored. There are several protocols proposed and tested in vehicular network. An integrate protocol stack fit for different applications is still beingless. (3) Privacy and security concerns may arise in distributed V2V communications. 

挑戰是多方面的：（1）衆包地圖（來自連通車輛的獨立實時視圖的組合3D點雲）充當參考座標系統來定位事故。 這張地圖對於實時生成和傳輸而言太過龐大，所以咱們須要開發其餘機制來解決其正確生成和維護問題。（2）須要探索適當的網絡協議棧。 在車載網絡中提出並測試了多種協議。 針對不一樣應用程序的集成協議棧仍然沒法實現。（3）分佈式V2V通訊中可能出現隱私和安全問題。

In this paper, we design ARVE, a framework designed to enable Connected Vehicle Views (CVV) where nearby vehicles are able to share their views, assisted by the edge components, and form a more holistic view of their current situation. This enables fast distribution of critical information, i.e., obstacle detection, emergency report and collision notifcation. While we use CVV as an example, ARVE can serve any similar application, which requires computation and short latency. 

在本文中，咱們設計了ARVE，這是一個旨在實現連通車輛視圖（CVV）的框架，其中附近的車輛可以在邊緣組件的幫助下分享他們的視圖，並造成對其當前狀況的更全面的視圖。 這使得可以快速分發關鍵信息，即障礙物檢測，緊急報告和碰撞通知。 雖然咱們使用CVV做爲示例，ARVE能夠爲任何相似的應用程序(須要計算和短延遲)提供服務。

4 SYSTEM DESIGN (系統設計）

In this section, we describe the ARVE design. First, we explain our system architecture and describe the major communication processes in the system. Then, we propose an implementation scheme and present how to apply it to CVV. 

在本節中，咱們將介紹ARVE設計。 首先，咱們解釋咱們的系統架構並描述系統中的主要通訊過程。 而後，咱們提出了一個實現方案，並介紹瞭如何將其應用於CVV。

4.1 System Architecture （系統架構）

We now introduce the ARVE architecture model. It has three key elements: environment, vehicles and edge servers. Environment includes the background road network, roadside buildings, infrastructures and pedestrians, etc., while the others represent the computational elements in the system. Figure 2 depicts our system architecture in which ESes are distributed hierarchically in two tiers. Some are co-located with base stations, while others are colocated with aggregation points. We name the former Tier1 Edge Server (T1 ES) and the latter are Tier2 Edge Servers (T2 ES) .

如今，咱們介紹ARVE架構模型。它包含三個關鍵要素：環境、車輛和邊緣服務器。 環境包括背景道路網絡、路邊建築物、基礎設施和行人等，而其它表明系統中的計算元素。 圖2描繪了咱們的系統架構，其中邊緣服務器(ESes)分佈在兩層中: 一些與基站共存，而另外一些則與聚合點共存。 咱們將前者稱爲Tier1-邊緣服務器（T1 ES），後者命名爲Tier-2邊緣服務器（T2 ES）。

圖2： ARVE系統模型。數字表示通訊過程當中的步驟（見4.3節）。

The edge layer is the amalgamation of T1 and T2 ESes and is where ARVE operates. Edge layer communicates with vehicles and RSUs via nearby radio access network, and transmits data with remote cloud for synchronization. Each T1 ES has a range over the area covered by its connected macrocell and surrounded small cells. The hierarchical design of the edge layer allows applications with different requirements to be processed differently for better performance. T2 ES collects data from multiple areas (multiple T1 ESes) to provide larger scale of service and data backup, e.g., to improve traffic flow by sending cruise control messages. T1 ES, which is closer to vehicles, serves applications with higher latency sensitivity, e.g., emergency notifcations. 

邊緣層是T1和T2 ESes的融合，是ARVE運行的地方。邊緣層經過附近的無線接入網絡與車輛和RSU通訊，並經過遠程雲傳輸數據以進行同步。 每一個T1 ES的範圍均超過其鏈接的宏單元和周圍小單元所覆蓋的區域。 邊緣層的分層設計容許對具備不一樣要求的應用進行處理，以得到更好的性能。 T2 ES從多個區域（多個T1 ES）收集數據以提供更大規模的服務和數據備份，例如，經過發送巡航控制消息來改善流量流。 更靠近車輛的T1 ES服務於具備更高等待時間敏感性的應用，例如緊急通知。

4.2 ARVE Basic Operation （ARVE基本操做）

The basic operation of ARVE relies on the generation of a map around the vehicle, to enable awareness of the surroundings. The generation of the crowd-sourced map involves multiple steps. First, for each vehicle, we generate a 3D point cloud of the road in front of the vehicle using visual sensors present in the vehicle (e.g., LiDAR, RGBD camera). Then, the point clouds from multiple connected vehicles are transmitted to the edge server and combined into a 3D street view. Finally, the combined point cloud of the street is transmitted back to the vehicles, and each vehicle can display the street view according to its own position, so that the driver would be able to see the extended view of the whole street on the HUD.

ARVE的基本操做依賴於生成車輛周圍的地圖，以令人們可以意識到周圍環境。 衆包地圖的生成涉及多個步驟。 首先，對於每一個車輛，咱們使用車輛中存在的視覺傳感器（例如，LiDAR，RGBD相機）生成車輛前方道路的3D點雲。 而後，來自多個鏈接車輛的點雲被傳輸到邊緣服務器並組合成3D街道視圖。 最後，街道的組合點雲被傳輸回車輛，而且每輛車能夠根據其自身位置顯示街景，使得駕駛員可以在HUD上看到整個街道的擴展視圖。

4.3 Communication Process （通訊進程）

Next we describe the six basic steps (marked in Figure 2) in ARVE: neighbor notifcation, data processing, transmission, dissemination, aggregation, and upload. The exact details depend on the actual application; here we use an emergency notifcation application to showcase the communication process: 

接下來咱們介紹ARVE中的6個基本步驟（圖2中標記）:鄰居通知、數據處理、傳輸、傳播、聚合和上傳。詳細的細節依賴於真實應用；這裏，咱們使用緊急通知應用的展現通訊進程：

• Neighbor notifcation: The nearest vehicles require the fastest notifcation of emergencies. Therefore, upon emergency detection, a vehicle needs to warn its neighbor vehicles immediately, by sending simple notifcation via V2V. The notifcation includes only critical messages, e.g., name/type and coordinates of the emergency, to minimize V2V bandwidth usage and latency. The V2V notifcation is relayed until reaching a predefined maximum number of hops. Meanwhile, the vehicle sends a detailed report to nearest T1 ES via V2I. The report includes collected sensor and camera data with only the minimal, necessary data compression. 
• 鄰居通知：最近的車輛須要最快的緊急通知。 所以，在緊急檢測時，車輛須要經過V2V發送簡單的通知來當即警告其鄰近車輛。 該通知僅包括關鍵消息，例如，緊急狀況的名稱/類型和座標，以最小化V2V帶寬使用和等待延遲。 V2V通知被中繼，直到達到預約義的最大跳數。 同時，車輛經過V2I向最近的T1 ES發送詳細報告。 該報告包括收集的傳感器和攝像機數據，只有最小的必要數據壓縮。
• Data processing: Once a T1 ES receives a report, it processes the data and caches it for passing on to later passing vehicles. As discussed in [19], sharing views of incidents among vehicles is nontrivial. ESes maintain and update local map in real time, by collecting data from passing vehicles and synchronize it with a cloud data center. With the up-to-date map, T1 ESes serve as calibration points which map the reported incident onto absolute coordinates and notify nearby vehicles more efciently. 
• 數據處理：一旦T1 ES收到報告，它就會處理數據並對其進行緩存，以便傳遞給後來過往的車輛。 正如[19]中所討論的那樣，共享車輛事故的視圖是非凡的。 經過從過往車輛收集數據並將其與雲數據中心同步，ES實時維護和更新本地地圖。 利用最新的地圖，T1 ESes可用做校準點，將報告的事件映射到絕對座標上，並更有效地通知附近的車輛。
• Data transmission: The maintained map or other data, e.g., emergency or congestion information, can be transmitted between ESes via wired or wireless channels. 
• 數據傳輸：維護的地圖或其餘數據，例如緊急或擁塞信息，能夠經過有線或無線信道在ES之間傳輸。
• Data dissemination: Upon data updates, ESes disseminate data to vehicles in their coverage areas. 
• 數據傳播：在數據更新後，ESes將數據傳播到其覆蓋區域的車輛。
• Data aggregation: T1 ESes aggregate data before sending it to T2 ESes for applications requiring larger amounts of data (naturally assuming aggregation is acceptable for the application). 
• 數據聚合：對須要大量數據的應用程序，T1 ESes在將數據發送到T2 ESes以前聚合數據（固然假設聚合對於應用程序是可接受的）。
• Data upload: T2 ESes synchronize with cloud to update data and enable synchronization across a larger geographical area. 
• 數據上傳：T2 ESes與雲同步以更新數據並在更大的地理區域內實現同步。

This communication model has several important benefits, namely:

這一通訊模型具備多個重要的好處，即：

• Neighbor notifcationcombines two methods of which the simple notifcation warns closest vehicles with the lowest delay, while the detailed report sends all information for ESes to generate AR data for CVV. 
• 鄰居通知結合了兩種方法，其中簡單通知警告最近的車輛於是具備最低延遲，而詳細報告發送全部信息以使得ESes能夠生成CVV的AR數據。
• Cache capacityof an ES noticeably improves the performance of vehicular communication system. A common scenario is that vehicle detects an anomaly on road without nearby vehicles. The vehicle therefore cannot pass on the notifcation to other vehicles, but instead must upload it into the cloud. However, for a later vehicle to receive the notifcation in a timely manner, it needs to get the data all the way from cloud, or be in the coverage area of nearby RSUs when the data is still in transmission. ESes change this shortcoming by caching the data and broadcasting within predefned period, so that later vehicles receive the notifcation with lower latency. 
• ES的高速緩存容量顯着提升了車載通訊系統的性能。 常見的狀況是車輛在沒有附近車輛的狀況下檢測到道路上的異常。 所以，車輛不能將通知傳遞給其餘車輛，而是必須將其上傳到雲中。 然而，對於後來的車輛及時接收通知，它須要從雲端獲取數據，或者當數據仍在傳輸時位於附近RSU的覆蓋區域。 ESes經過在預約時間段內緩存數據和廣播來改變這一缺點，以便後來的車輛接收具備較低延遲的通知。
• Hierarchical edgeenables efcient handling of workloads with different requirement by processing the data at the different tiers, depending on the application requirements. 
• 經過根據應用程序要求處理不一樣層的數據，分層邊緣能夠根據不一樣的要求有效地處理工做負載。

4.4 Implementation （實現）

In terms of implementation, two key issues arise: the deployment and placement of ESes. Deployment refers to the internal implementation of an ES while placement refers to the physical placement of the ES. 

在實現方面，出現了兩個關鍵問題：ES的部署和放置。 部署是指ES的內部實現，而放置是指ES的物理位置。

Deployment: Our proposal to co-locate ESes with base stations and aggregation points are motivated by existing trends. The MEC standard developed by European Telecommunications Standards Institute (ETSI) proposes to deploy servers at the cellular base station to serve local mobile subscribers with fast response times [4]. Colocation with existing infrastructure also achieves cost-efciency. For these reasons, T1 ESes co-located with base stations is a straightforward solution. Next, we need to take a look at cellular network deployment in near future to understand the rationale of T1 ES deployment. According to the 2017 survey of Small Cell Forum (SCF), by 2025, new non-residential small cell deployments will reach almost 8.5 million, which is 22 times higher than in 2015 [9]. On the other hand, 5G will also accelerate the deployment of small cells. 58% of the operators, according to the same survey of SCF, expect to focus primarily on small cells in the frst 2-3 years of deploying 5G. However, the number of macrocell seems to grow much slower. According to Nokia, trafc density of a very busy US city increased fourfold from 2004 to 2014, yet the average density of macrocell sites did not change [5]. We conjecture that small cell deployment will increase much faster than macrocell deployment in the near future. As a result, capacities of T1 ESes are facing increasing challenges and therefore we propose to locate the T2 ESes at a higher layer in the network to enable more efcient aggregation and backup.

部署：咱們將ES與基站和聚合點共同放置的方案受到現有趨勢的推進。由歐洲電信標準協會（ETSI）開發的MEC標準建議在蜂窩基站部署服務器，以便爲本地移動用戶提供快速的響應時間[4]。與現有基礎設施的共置也能夠實現成本效益。因爲這些緣由，T1 ESes與基站位於同一位置是一個簡單的解決方案。接下來，咱們須要瞭解不久的未來的蜂窩網絡部署，以瞭解T1 ES部署的基本原理。根據2017年小型蜂窩論壇（SCF）的調查，到2025年，新的非住宅小型蜂窩部署將達到近850萬，比2015年高出22倍[9]。另外一方面，5G也將加速小型蜂窩的部署。根據對SCF的同一調查，58％的運營商預計在部署5G的前2 - 3年內主要關注小型蜂窩。可是，宏蜂窩的數量彷佛增加得慢得多。據諾基亞稱，美國一個很是繁忙的城市的交通密度從2004年到2014年增加了四倍，但宏蜂窩站點的平均密度沒有變化[5]。咱們推測，在不久的未來，小蜂窩部署的增加速度將遠遠快於宏蜂窩部署。所以，T1 ES的容量面臨愈來愈多的挑戰，所以咱們建議將T2 ESes定位在網絡的更高層，以實現更高效的聚合和備份。

Placement: To avoid unnecessary investment and complexity, the ESes location should be carefully determined. While T2 ESes are locate typically at aggregation points, which are relatively few in number, locations of T1 ESes have much more candidates, namely the macrocells. Cities like New York have macrocell deployments with 500 m inter-site distance or less [6]. Deploying one T1 ES per macrocell would be excessive in terms of investment, so to improve efciency, we need to optimize the selection of locations in some manner. Our proposed algorithm includes two steps, namely average traffic clustering and edge capacity assignment. We opt for a hierarchical clustering algorithm since our edge layer already is constructed hierarchically. Edge capacity assignment is solved as a primary facility location problem, where we simply assign edge capacity to each cluster center (both Tier 1 and 2), proportional to its average traffic. The order of edge capacity is calculated through edge server capacity, trafc density, and resource consumption of the application (section 6).

放置：爲避免沒必要要的投資和複雜性，應仔細肯定ESes的位置。雖然T2 ESes一般位於聚合點，其數量相對較少，可是T1 ESes的位置具備更多的候選者，即宏蜂窩。紐約等城市的宏蜂窩部署距離爲500米或更短[6]。在每一個宏蜂窩中部署一個T1 ES在投資方面會過多，所以爲了提升效率，咱們須要以某種方式優化位置選擇。咱們提出的算法包括兩個步驟，即平均交通量聚類和邊緣容量分配。咱們選擇層次聚類算法，由於咱們的邊緣層已是分層構造的。邊緣容量分配做爲主要設施位置問題獲得解決，咱們只需爲每一個集羣中心（第1層和第2層）分配邊緣容量，與其平均交通成比例。邊緣容量的順序是經過邊緣服務器容量、流量密度和應用程序的資源消耗來計算的（第6節）。

4.5 Use case solution Overview （用例解決方案概覽）

Now we describe how to implement an ARHUD-based CVV. To solve the challenges described in section 3, we need to implement the following components: (1) Map maintenance: Vehicles record the surrounding 3-D features with the coordinates of traversed streets and send to nearest T1 ESes. T1 ESes stitch together the collected segments to form 3-D neighborhood maps. (2) Incident report: Once a vehicle detects an incident, it sends the simple notifcation and detailed report to the nearest vehicle and T1 ES, respectively. (3) Data process: The ES extracts the data from the received report and localizes the incident in the map it maintains. The localization can use either the received coordinates or map the observed 3-D features within the map. (4) Transmission and dissemination: Meanwhile, the ES forwards the notifcation to nearby T1 ESes (directly or via T2 ES) and disseminates to vehicles within its coverage. The range of the dissemination area depends on the magnitude of the incident and the coverage area of the ES. (5) Aggregation: T2 ES aggregates data from T1 ESes to gather information of larger area. Use cases include, for example, crowd–sourcing the neighborhood maps to build an urban 3-D map or trafc light control. (6) Synchronization: ESes synchronize with the cloud periodically or when triggered by specifed incidents. 

如今，咱們描述如何實現基於ARHUD的CVV。爲了解決第3節中描述的挑戰，咱們須要實現如下組件：（1）地圖維護：車輛使用通過的街道的座標記錄周圍的3-D特徵併發送到最近的T1 ES。 T1 ES將收集的段拼接在一塊兒，造成3-D鄰域地圖。（2）事故報告：一旦車輛發現事故，它會將簡單的通知和詳細報告分別發送到最近的車輛和T1 ES。（3）數據處理：ES從接收到的報告中提取數據，並將在它維護的地圖中定位事件。定位可使用接收的座標或映射地圖中觀察到的3-D特徵。（4）傳輸和傳播：同時，ES將通知轉發到附近的T1 ES（直接或經過T2 ES）並傳播到其覆蓋範圍內的車輛。傳播區域的範圍取決於事件的嚴重程度和ES的覆蓋範圍。 （5）聚合：T2 ES聚合來自T1 ES的數據以收集更大區域的信息。例如，用例包括衆包鄰域地圖以構建城市3-D地圖或交通燈控制。 （6）同步：ESes按期與雲同步，或者由指定的事件觸發。

5 NETWORK ISSUES （網絡問題）

In this section, we discuss possible network protocols for V2E powered vehicle communication system. ARVE does not have any specifc requirements on the networking technologies or protocols that are used. We can accommodate different technologies including cellular, Wi-Fi, D2D and DSRC so that they complement each other to fulfll different kinds of workloads and constitute an integrated networking system. Considering Figure 2 as an example, the device layer includes V2V and V2I communication where DSRC and D2D protocols coexist to provide better performance. Stand-alone D2D (Wi-Fi Direct) and DSRC could support V2V in scenarios even without network coverage. Another D2D protocol, LTE Direct, needs network assist and supports long distance connection. As shown in [19], Wi-Fi Direct has better performance than LTE and higher theoretical throughput than DSRC. However, WLAN chipsets are unlikely to fulfill ad-hoc communication at high speeds which makes them unreliable for vehicle network [7]. Here we propose to use a combination of D2D and DSRC to serve large volumes of data and fast data transmission, respectively. For instance, in our communication process, vehicle sends out the simple notifcation to closest vehicle by DSRC, while sending the detailed report to nearby ES by D2D. The rest of the system communicates via wired and LTE or 5G network. Today’s cell phone connects to internet via cellular or Wi-Fi network, depending on local network coverage and subscription etc. Likewise, vehicular networks should also use multiple complementary protocols to function in different scenarios.

在本節中，咱們將討論V2E加強的車輛通訊系統的可能網絡協議。 ARVE對所使用的網絡技術或協議沒有任何特定要求。咱們能夠適應不一樣的技術，包括蜂窩、Wi-Fi、D2D和DSRC，以便它們相互補充知足不一樣類型的工做負載，並構成一個集成的網絡系統。以圖2爲例，設備層包括V2V和V2I通訊，其中DSRC和D2D協議共存以提供更好的性能。即便沒有網絡覆蓋，獨立的D2D（Wi-Fi Direct）和DSRC也能夠支持V2V。另外一種D2D協議（LTE Direct）須要網絡輔助並支持長距離鏈接。如[19]所示，Wi-Fi Direct具備比LTE更好的性能和比DSRC更高的理論吞吐量。然而，WLAN芯片組不太可能在高速率下知足ad-hoc通訊，這使得它們對車輛網絡不可靠[7]。在這裏，咱們建議使用D2D和DSRC的組合來分別提供大量數據和快速數據傳輸。例如，在咱們的通訊過程當中，車輛經過DSRC將簡單通知發送到最近的車輛，同時經過D2D將詳細報告發送到附近的ES。系統的其他部分經過有線和LTE或5G網絡進行通訊。今天的手機經過蜂窩或Wi-Fi網絡鏈接到互聯網，具體取決於本地網絡覆蓋和訂閱等。一樣，車載網絡也應該使用多種互補協議在不一樣的場景中運行。

6 PRELIMINARY EVALUATION （初步評估）

In this section, we will present a primary ES placement solution for a CVV application based on ARVE and elaborate the system improvement over current vehicular network. 

本節，咱們將爲基於ARVE的CVV應用提供主要的ES放置解決方案，並詳細說明對當前車載網絡的系統改進。

Data Collection and Analysis: To address the edge server placement problem, we study the base station and traffic distribution pattern in the center area of London as an example. The selected area has a size of 26km * 20km, and we collect the LTE base station location data and traffic volume data that fall into this area according to GPS coordinates. 

數據收集和分析：爲了解決邊緣服務器放置問題，咱們以倫敦中心區域的基站和交通分佈模式爲例進行研究。 所選區域的大小爲26km*20km，咱們根據GPS座標收集落入該區域的LTE基站位置數據和交通量數據。

First we cluster the traffic volume data according to their GPS coordinates, and divide the selected area into 20 small areas according to the clustering result. The traffic distribution and area partition results are shown in Figure 3, where each colored dot represents the location of the aggregated traffic, and the different sizes of the dots reflect the different traffic volumes in 12 hours during daytime. 

首先，咱們根據其GPS座標對交通量數據進行聚類，並根據聚類結果將所選區域劃分爲20個小區域。 交通分佈和區域劃分結果如圖3所示，其中每一個彩色圓點表明聚合交通的位置，不一樣尺寸的點反映出不一樣的交通量（白天12個小時）。

圖3：倫敦交通分佈

Next we want to see if base stations distribute differently from traffic, to understand if this would influence our co-located ES placement. There are 22041 LTE base stations located within this area, among which 1538 base stations have a coverage radius larger than 3000m, comparable to macrocell. We plot these 1538 base stations on the map, as shown in Figure 4. It can be easily observed that the base stations distribute evenly and reasonably match the amount of traffic in dense areas. As a result, using base stations as deployment points is not going to deviate the ES placement from the actual traffic patterns. 

接下來，咱們想看看基站分佈和交通量是否不一樣，以瞭解這是否會影響共存ES的位置。 該區域內有22041個LTE基站，其中1538個基站的覆蓋半徑大於3000m，與宏蜂窩至關。 咱們在地圖上繪製了這1538個基站，如圖4所示。能夠很容易地觀察到基站分佈均勻且合理地匹配密集區域中的交通量。 所以，使用基站做爲部署點不會使ES佈局偏離實際的交通模式。

圖4：倫敦選定區域的LTE基站（覆蓋半徑大於3000米）分佈

Edge Server Placement: H. Qiu et al. reported a typical Augmented Vehicle Reality system [19], where the AR related processing (e.g., point cloud manipulation) takes 1.337 sec on average. Considering this processing as the AR workload of the edge servers, one edge server is able to handle 2692 requests per hour, that is, serving around 32k vehicles during each daytime. 

邊緣服務器放置：H. Qiu等報告了一種典型的加強型車輛現實系統[19]，其中AR相關處理（例如，點雲操縱）平均須要1.337秒。 將此處理視爲邊緣服務器的AR工做負載，一臺邊緣服務器每小時可以處理2692個請求，即天天服務大約32,000個車輛。

The edge server placement is correlated with the traffic volume distribution, which is not uniform among the 20 small areas. The numbers of edge servers needed by each area are shown in Figure 5. In total 90 edge servers are needed in the selected center area of London and the largest clusters of ESes have a total of 8 ESes, while the bulk of them contain 3–4 ESes. 

邊緣服務器放置與交通量分佈相關，這在20個小區域中不均勻。 每一個區域所需的邊緣服務器數量如圖5所示。在倫敦選定的中心區域共須要90個邊緣服務器，最大的ESes集羣總共有8個ES，而其中大部分包含3-4個ESes。

圖5：不一樣區域須要的邊緣服務器的數量

Latency Comparison between Edge Server and Cloud Server. Edge servers bring the processing capability to the vicinity of vehicles. The latency of augmented vehicle reality consists of mainly two parts: the data transmission time and the server processing time. The data processing time taken by the edge server and the cloud server would not differ signifcantly, but the data transmission time is greatly influenced by the transmission distance. 

邊緣服務器和雲服務器之間的延遲比較。邊緣服務器將處理能力帶到車輛附近。加強車輛現實的延遲主要包括兩部分：數據傳輸時間和服務器處理時間。 邊緣服務器和雲服務器的數據處理的時間差別不大，但數據傳輸時間受傳輸距離的影響很大。

As reported in [19], the point cloud data size of the view generated by a 720P resolution stereo camera is 14.75 MB. Considering the edge server scenario, the uplink bandwidth between the vehicle and the LTE base station achieves on average 25 Mbps4, so that the transmission of the point cloud fnishes in 4.72 sec. On the other hand, the transmission between vehicles and cloud servers is obviously slower, as the data needs to traverse through the Internet. Taking Google Cloud Platform as an example, the average uplink bandwidth is 4.4 Mbps5, so that the transmission of the point cloud could take up to 26.82 sec. 

如[19]中所報道的，720P分辨率立體相機生成的視圖的點雲數據大小爲14.75 MB。 考慮到邊緣服務器場景，車輛和LTE基站之間的上行鏈路帶寬平均達到25Mbps，所以點雲的傳輸在4.72秒內完成。 另外一方面，車輛和雲服務器之間的傳輸速度明顯較慢，由於數據須要經互聯網傳輸。 以Google Cloud Platform爲例，平均上行帶寬爲4.4 Mbps，所以點雲的傳輸可能須要26.82秒。

Our preliminary evaluation shows that ARVE would decrease transmission latency noticeably.

咱們的初步評估代表ARVE能夠顯著下降傳輸延遲。