Abstract

In the Vehicle-to-Vehicle-to-Infrastructure (V2V2I) VANET data offloading scenario, the source vehicle Vs that wants to have VANET data offloading can use (i) a Vehicle to Infrastructure (V2I) link to do VANET data offloading when V <inf xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">s</inf> is inside the signal coverage of a Road Side Unit (RSU), which is the traditional self-offloading scenario, i.e., V <inf xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">s</inf> connects the RSU directly by itself, or (ii) a V2V2I path, which denotes a n-hop V2V2I path connecting V <inf xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">s</inf> and the ahead/rear RSU, to do VANET data offloading when V <inf xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">s</inf> is outside the signal coverage of the corresponding RSU. When the signal coverages of some ahead/rear RSUs are overlapped, the RSU handoff processing between the signal-overlapped RSUs need to be tackled such that the V2V2I data offloading time can be extended. This work uses the Multi-Access Edge Computing (MEC) architecture to find the n-hop V2V2I offloading path. Based on the periodically received context reports from vehicles and a time-extended prediction mechanism, the MEC server can find whether there are some candidate V2V2I offloading paths that exist in the coming time period or not. Then, the MEC server selects the best one as the V2V2I offloading path. The performance evaluation shown that the proposed method is better than the traditional self-offloading method and can enhance the data offloading performance.

Full Text
Published version (Free)

Talk to us

Join us for a 30 min session where you can share your feedback and ask us any queries you have

Schedule a call