# Analysis of Mobile Edge Computing for Vehicular Networks +
## 1 Introduction
Any information relevant to a particular location can be cached at a nearby Base Station and, made readily available to vehicles. This technique could also be extended to include file sharing between vehicles, assuming sufficient storage space is available on the vehicles hardware. Incorporating a new source of data also has a significant impact on the computational and storage requirements. While it is safe to assume that an autonomous vehicle will process a large amount of its data in real-time, it is not unrealistic to assume that additional data must be transferred to remote locations for storage and later processing. Moving and processing data is costly and requires careful planning to minimize resource impact. In an environment as demanding as vehicular networks, the utilization of resources must be carefully managed. In traditional cloud computing, tasks and associated data are transmitted to more powerful remote resources. However, the network overhead of this scheme may not suffice for the real-time applications of VANETs. In a VANET scenario, numerous vehicles will rely on a single base station for requests and data upload. Forwarding large amounts of data to a single node would likely results in network congestion and would be exacerbated in areas of high traffic. One possible solution lies in the concept mobile edge-computing (MEC), which is a paradigm in which computational tasks distributed throughout the network and often kept closer to the end-user. Ref. [13] emphasizes the importance of NFV and software defined networking (SDN) in MEC and note that vehicular networks are a primary market driver. A method to optimize the usage of a single cloud resource is presented in [14] and could prove useful for groups of users that are in close proximity to a single edge resource. Expanding this method to MEC would allow users to be clustered based on their nearest resource and could provide optimal utilization of that resource. Two main goals of MEC are to reduce network congestion and minimize delay experienced by the user. By reducing the distance the data must travel over the network, executing tasks at an edge node minimizes the impact on the network. This also reduces delay as both the request and response will reach their destination sooner. While the reduction in delay for trivial requests will be negligible, situations involving transmission of data could see significant reductions. For computational tasks, these reductions in delay are also dependent on computational capability of each resource. For example, when delegating a task to a less powerful nearby resources; the reduction in delay may be overshadowed by an increased computational time of the local resource. The task of resource provisioning in a vehicular network would be complex and requires a sophisticated system to monitor resources and distribute tasks accordingly. Vehicular networks present a unique opportunity for use in both MEC and what is known as fog computing (FC). Similar to MEC, FC seeks to perform computational tasks on the most logical resource so as to reduce the overall impact on the storage, computational, and network resources [15]. However, fog computing will employ resources even closer to the end-user, including the end node itself. Vehicular networks with appropriate infrastructure can utilize edge computing by off-loading some tasks to the RSUs, base stations, cell towers, or other infrastructure that provides connection to the network backbone. Additionally, vehicular networks can further leverage FC by employing powerful on-board computational hardware that is expected to reside on future vehicles. The inclusion of such hardware in the network creates a new architecture that could contextually execute, store, or transmit any data in the most logical and efficient fashion. The SDFC-VeNET architecture proposed in [16] employs a combination of both SDN and FC to provide an effective mechanism to minimize the delay associated with handover.