Using Public Buses as Mobile Gateways in VANET Clouds

HANYANG UNIVERSITY ERICA INFORMATION SECURITY & PRIVACY LAB.

Rasheed Hussain PhD Candidate, Hanyang University, South Korea

[email protected]

IEEE ICCE 2014, January 10, Las Vegas, USA

Using Public Buses as Mobile Gateways in Vehicular Clouds

Rasheed Hussain*, Fizza Abbas*, Junggab Son*, Sangjin Kim**, and Heekuck Oh* *Dept. of Computer Science and Engineering, Hanyang University, South Korea

**Department of Computer Science and Engineering, Korea University of Technology and Education, South Korea

mailto:[email protected]

Information Security & Privacy Laboratory @ Hanyang University ERICA ` [email protected]

Agenda

Theme

Motivation

Problem Statement

Introduction

Baseline

Proposed Scheme

Benefits of the Proposed Scheme

Conclusion

2


Main Theme

Role of public transport in VANET and its successor VANET-based Clouds

Using the highly predictable mobility dynamics of buses (time and space) for services in vehicular clouds

Using buses as mobile gateways in the gradual deployment of VANET-based clouds

For instance Data aggregation in VANET-based clouds

Do we really need RSUs in urban areas?!

3


Motivation

Trust in VANET

User and location privacy requirements in VANET

Uniformity of transmission range

Vehicular density

Initial stages of VANET

Deployment of RSUs

Advantages of Tall vehicles

How to make a successful comm. among cars and infrastructure

Cost-effective way to use the already-established infrastructure

4


Problem Statement

Initial stage of VANET is likely to face infrastructure deployment problem

For instance deployment of RSUs

Governments might get reluctant in spending money while being not sure of its success

There are schemes and/or standards that enable V2V and V2I communications, but in V2I, the ‘I’ part is to be deployed beforehand in optimized fashion

How to enable vehicles to communicate with each other and with Infrastructure efficiently?

These questions will be answered in this research

5


Introduction [1/4]

VANET Key players: Vehicles, RSUs, Mgt. and Revocation authorities

Communication paradigms: V2X (𝑋 ∈ {𝑉, 𝐼})

Zero infrastructure

Infrastructure-based

Application Classes: Safety, Non-safety, and Infotainment

Standards

DSRC (Dedicated Short Range Communication) IEEE 802.11p

Communication Range: Up to 1000m but normally 300m

Situation awareness is achieved through beacon messages

Local and extended traffic views

Despite of a fairly good amount of research, VANET still couldn’t make it to the deployment stage!

6


Introduction [2/4]

Vehicles are not century old boxes anymore!

Today’s vehicles are resource-rich

Different perspectives Vehicles will waste resources (and they are doing now)

Vehicles on their own cannot handle some applications

VANETs evolved to VANET-based clouds and it is becoming buzzword in the research community

VANET-based clouds services are still underway and being researched

We aim at the services that use beacons as input

7


Introduction [3/4]

VC Taxonomy [Hussain et al. IEEE CloudCom 2012]

8

VANET Clouds

Vehicular Clouds

Static

Clouds

IaaS

Data Storage

Dynamic Clouds

Rented Resources

IaaS and NaaS

Vehicles using Clouds

CAA

Traffic Information

Infotainment

Hybrid (Inter-Vehicle Clouds)

Rent-out Resources

P2P

IaaS and NaaS

Pay-as-you-go


Introduction [4/4]

Traffic Lights Management on a large scale Rush hours or a concert at a city hall

A jammed highway Traffic directed to another route

Worst case would jam the new route instead of jammed highway

Cloud in a parking lot Rent out resources

Planned Evacuation and more

Dynamic HoV (High Occupancy Veh.) Lane designation

NaaS (Network as a Service) Internet, advertisements, pay-as-you-go services, Storage as service

VWaaS (Vehicle Witnesses as a Service) [Hussain et al.] To appear in IEEE CloudCom 2013

9


Preliminaries [1/2]

Network and System Model VANET

Public, semi-public, and private vehicles

Registration and Revocation Authorities

Road-side Infrastructure

Public Buses infrastructure

Cloud Infrastructure

Cloud service provider(s)

Multi-cloud environment

Network Model

Urban scenario with public transport (Buses)

Road network with fixed routes and bus stops

Almost all or at least major part of the urban locality is covered by the bus routes

10


Preliminaries [2/2]

Bus network (Seoul Station)

11


Baseline

Related work on Public Transport in VANET Key Updates ()

Routing ()

Next Hop & Relayer ()

Mobile Gateway ()

Aggregation ()

Service Providers ()

Our Emphasis Generalized approach as full fledge MGs (Mobile Gateways)

Infotainment, Aggregation

Use-Case Aggregation in VANET-based Clouds

V2C Communication

12


Proposed Scheme [1/7]

13

Communication Model MG is intermediate between vehicles and Infra.

MG collects data from vehicles, classifies, compresses, aggregates and sends it to cloud for processing

Skip List concept in case of unicast communication

Vehicles

Broadcast beacons according to DSRC standard

Service requests

MG

Broadcasts service messages from service providers with QoS information

Receives messages from neighbors and aggregates them

Sends Aggregated Messages (AMs) to cloud

Disseminates warning messages and traffic information among vehicles



Architecture

14

Aggregated

Message

Services

Gateway

SL Level 2

SL Level 1

SL Level 3

4G

DSRC

SL Skip List

VANET Cloud


Proposed Scheme [3/7] Road is dissected into segments beforehand and buses construct 𝐴𝑀

for every segment it passes through (one-hop)

If there are more than one bus in the segment, then at certain time,

one of them will be elected as segment leader and it will rotate

Messages

Beacon: 𝐵𝑖 = 𝐷𝑎𝑡𝑎||𝑖𝑛𝑡𝑒𝑛𝑡||𝑆𝑒𝑐𝑢𝑟𝑖𝑡𝑦 𝑃𝑎𝑟𝑎𝑚𝑒𝑡𝑒𝑟𝑠 𝑖𝑛𝑡𝑒𝑛𝑡 = 𝑠𝑒𝑟𝑣𝑖𝑐𝑒 𝑟𝑒𝑞. , 𝑒𝑣𝑒𝑛𝑡 𝑖𝑛𝑓𝑜𝑟𝑚𝑎𝑡𝑖𝑜𝑛, 𝑒𝑡𝑐.

AM (Aggregated Message)

𝐴𝑀𝑖 = 𝐴𝑀𝑖𝑎||𝐴𝑀𝑖

𝑏, 𝑎: 𝑎ℎ𝑒𝑎𝑑, 𝑏: 𝑏𝑒ℎ𝑖𝑛𝑑

𝐴𝑀𝑖𝑗[𝑗 ∈ (𝑎, 𝑏)] =

𝑡𝑖𝑚𝑒𝑠𝑡𝑎𝑚𝑝||𝐵𝑢𝑠𝐼𝐷||𝑟𝑜𝑢𝑡𝑒𝐼𝐷||𝑙𝑜𝑐𝑐𝑢𝑟||𝐴𝑔𝑔. 𝐷𝑎𝑡𝑎𝑑𝑖𝑟||(𝑆𝑅1, 𝑆𝑅2, … , 𝑆𝑅𝑛)

𝐴𝑔𝑔. 𝐷𝑎𝑡𝑎𝑑𝑖𝑟 can be either 𝐴𝑔𝑔. 𝐷𝑎𝑡𝑎𝑎or 𝐴𝑔𝑔. 𝐷𝑎𝑡𝑎𝑏

𝑙𝑜𝑐𝑐𝑢𝑟 is the starting point of current segment, 𝑆𝑅 is the service request

𝑆𝑅𝑖 = ∆𝑡||𝑠. 𝑡𝑦𝑝𝑒||∆𝑙𝑜𝑐||ℎ𝑒𝑎𝑑𝑖𝑛𝑔||𝑄𝑜𝑆 𝑖𝑛𝑑𝑒𝑥

15



Warning Messages

𝑊𝑀: 𝑡𝑖𝑚𝑒𝑠𝑡𝑎𝑚𝑝||𝑤. 𝑡𝑦𝑝𝑒||𝑙𝑜𝑐𝑠𝑡𝑎𝑟𝑡||𝑙𝑜𝑐𝑒𝑛𝑑||𝑛𝑒𝑐𝑒𝑠𝑠𝑎𝑟𝑦 𝑎𝑐𝑡𝑖𝑜𝑛

Overlapping segments Should MG handle it or Cloud?

Both approaches have pros and cons

Dynamic is more challenging (segment size?)

Static approach puts the load on cloud where dynamic does it on MG

Handover is the problem in dynamic approach

Best choice seems to be Cloud

16

A

B

C

D

E



Algorithm 1. Procedure: Aggregate

2. Input: 𝑩𝒊 ∈ 𝑩[𝒕𝒊−𝟏,𝒕𝒊]

3. Output: 𝑨𝑴𝒕𝒊, Aggregated message at time 𝒕𝒊

4. Receive beacons from neighbors in the broadcast period and receive SA (

Service Advertisements) from service providers

5. Broadcast SAs to the neighbors in transmission range

6. Examine the receive buffer

7. Do {

8. Extract mobility data and 𝑆𝑅 from 𝐵𝑖 and store in 𝐴𝑀 buffer and 𝑆𝑅

buffer respectively}

9. While (End of receive buffer)

10. Construct 𝐴𝑀

11. Send 𝐴𝑀 to the cloud

17



Feasibility

18



Advantages of our Proposed Scheme No need for extensive location and user privacy concerns in MGs

Synchronization in Key updates

Initial stages of VANET would get much out of this scheme

No static infrastructure needed at the first deployment stage

Mobile gateways add flexibility to the system at daytime

Potential Issues Night time

But at night time keeping the traffic density in mind, such mechanism would not be necessary

Future Plan Look into the financial comparison between two approaches

19


Conclusions

Public Transport buses used as mobile gateways to cloud and VANET infrastructure

Urban scenario where buses cover almost all the roads of the city

Buses are tall and have an edge for better beacon reception rate

Targets the problems posed by the static RSU infra.

Separate comm. channels (DSRC and 3/4G)

Aggregation is taken as a use-case in the proposed scheme

20