A Hierarchical Vehicular-Based Architecture for Vehicular Networks: A Case Study on Computation Offloading

In order to realize an intelligent transportation system (ITS) which will provide smooth urban traffic, autonomous driving, accurate route navigation, etc., enormous computations need to be migrated from cloud centers to edge nodes, especially for the services requiring stringent latency. In addition to base stations and road side units (RSUs), vehicles can be alteratively considered as a kind of computation resources. In this article, a hierarchical vehicular-based architecture which consists of cloud centers and vehicles is investigated. Computation offloading performance in the hierarchical architecture is also studied. In specific, the main components in vehicular networks and their characteristics on communication and computations are presented firstly. Several communication techniques that are essential in enabling computation offloading among these components are then discussed. Secondly, a hierarchical vehicular-based architecture, which integrates the main components, is constructed. Thirdly, a case study on computation offloading in the proposed architecture is conducted. In the concerned scenario, the computation offloading problem is modelled as a multi-dimensional multiple knapsack problem (MMKP). Two algorithms are investigated, among which, the first algorithm is a greedy heuristic method providing a sub-optimal solution with a low computational complexity. The second algorithm is a modified branch and bound (B&B) method, which can obtain the best solution with a high computational complexity. Numerical results are also presented to verify the performance of the two algorithms. It can be demonstrated that the proposed architecture can migrate more computations from cloud centers to vehicular nodes, when the computations require more communication resources.

Abstract licence: CC BY-NC-ND

52 more references, whose wording the paper’s licence keeps private.

A person counts once a day per paper. We keep no cookie and no address: a reader is a hash that changes every day. Any month under five reads shows no number.