# Augmenting CCAM Infrastructure for Creating Smart Roads and Enabling Autonomous Driving
## 4 Literature Review
Most of the above-mentioned entities in the CarMap architecture rely on GPS position (a radius of 50 m) and keyframes. The implementation consists of:  
* An alienware laptop (Intel i7 4.4 GHz CPU, 16 GB DDR4 RAM, NVIDIA 1080p GPU with 2560 CUDA cores),
* MobileNetV2 (DeepLabv3+) for semantic segmentation,
* OpenCV for image transformations,
* The Point Cloud Library (PCL) for point cloud operations,
* QuickSketch for stitching,
* The C++ Boost library for serializing and transferring the map files over the network,
* Software modules for the aforementioned architectural components,
* Modification to ORB-SLAM2 (feature extraction, index generation, and feature matching modules),
* The open-source visual odometry algorithm for mono, stereo, and RGB-D cameras in the KITTI vision-based benchmarks. In the CarMap simulations, three scenarios are considered and map data are taken for validation of end-to-end latency and map updates. In addition, the accuracy of end-to-end localization with reduced map size is assessed for localization scenarios. Latency is as low as less than a second (<1 s) in CarMap, since the integration of map updates (50 ms) and stitching/reconstruction (500 ms) is 550 ms. Localization accuracy is 28\(\times\) (50\(\times\)) better for the static (dynamic) map as compared to ORB-SLAM2 and QuickSketch. Map size is 75\(\times\) reduced. CarMap is also capable of localizing in situations where other approaches fail. It is notable that CarMap does not consider denser (high-dimensional) representations of maps, which is a challenge that needs to be addressed for future autonomous vehicles. Additionally, the CarMap does not rely on road-side units for storage and processing, which can improve latency and localization. In SURROGATES [16], a physical OBU is virtualized into a VNF (i.e., vOBU) within the MEC layer to make it available for performing computationally-intensive tasks and caching data. The contributing factors of the study include: OBUs virtualization; NFV and MEC architectures; and real-world implementation, deployment, and validation of the system. The architecture consist of entities from vehicle and virtualized edge-&-cloud such as OBUs, RSUs, OBU manager module, REST protocols and API, virtualized infrastructure manager (VIM), cellular base stations, 802.11 OCB and 4G technologies, WiFi access points, and an IPv6-based network middleware. The middleware is used to share navigation data, monitor statistics, etc. A MANO entity orchestrates the vOBUs as VNFs that utilize the network node's computing capabilities and feed user applications such as traffic efficiency, safety, pollution monitoring, tracking, and healthy mobility. It is noteworthy that the physical OBUs proactively communicate with vOBUs to feed a set of services (user applications) by providing monitoring parameters. Accessing and processing data takes place at three locations: the data analytics module, the vOBU, and the physical OBU. Thus, it addresses the issue of multiple services requiring data from the same vehicle, reduces request resolution delays, and saves wireless resources. Using the 5 GINFIRE project ecosystem, SURROGATE is deployed and tested at the University of Murcia, Spain (UMU). The authors deployed three network services (NS) for vOBUs, platform management, and final services. Using open source MANO and OpenStack, it performs resources virtualization and data gathering from in-vehicle sensors. It allows the implementation of software services (VNFs) by using x86_64 (CISC) equipment. To further the implementation process, the following steps were taken:  
* An On-Board Diagnosis (OBD)-II interface (OBDLink SX) was used to connect a Laguna LGN-20 OBU (with a TP-LINK MA-180 modem) with in-vehicle CAN bus for gathering vehicle (Renault Clio 4 th generation) state data. * An OpenVPN tunnel (router) managed the IPv6 network mobility since the telecom operator does not support IPv6 traffic.