Senster: Cooperative Vehicular Sensing with Smartphones

Motivation

• VANET is slowly evolving: WAVE standards– Ever increasing popularity of 3G and WiMAX (or

WiBro)

• Smartphones: vehicular sensing enablers– Nokia N95:

• WiFi, Bluetooth, 3G• Voice, Video, Image, Accelerometer, GPS

• Application scenarios– Emergency message dissemination– Traffic information reporting– Mobile surveillance (using photos taken by cameras)

Senster Scenario

V2I

Internet

Celluar: 2/3G

V2V

V2I-I2V

WiFi Hotspots

V2V communications using WiFi

V2I communications using Cellular or WiFi

Senster Scenario• Sensors

– Built-in sensors in Smartphones• Nokia N95: voice, video, image, accelerometer etc.

– Other sensors are connected using Bluetooth• On-board diagnostic system (OBD)• Health monitoring sensors (e.g., ECG)

• Wireless communications– Sensors Smartphones: Bluetooth

• E.g., BlueSentry (Bluetooth DAQ)– Vehicle to vehicle: WiFi– Vehicle to infrastructure: Cellular (or Wibro optional)

• Resource constraints– Battery consumption

• Won’t be a big issue since we can use a car charger– Storage

• Iphone 2.0: 8GB of NAND flash disk• Given there are many sensing applications, GB of

storage may not be enoughBlueSentry

iPhone 3G

P2P for Mobile Cellular Users• Difficulties of providing P2P services for mobile users?

– Lack of common addressing: GGSN acts as a NAT– Large RTT (~500ms)– Management issues: ISPs won’t let users use P2P applications

• Previous approaches– Centralize approach

• All P2P communications via a single server– Hybrid approaches

• Putting everything in the operator’s domain (Andersen04)– GGSN solves addressing– Index server provides content resolution– P2P proxy enables efficient file transfer

• P2P over SIP (Liu07)– SIP application server (SIP-AS) implements the super peer functionality

• P2P proxy (Sarjakoski05/Koto)– Proxy relays control/data traffic

Our Approach

• Two-tier Architecture• Users download PC and

mobile client s/w• PC s/w

– Distributed data storage– Mobile user location tracking

• Mobile client s/w – Data access (put/get)

• Large amount of data will be published– Mobile node only push meta-data

by default– (Users can still upload the raw

data)

Static Tier (S-Tier)

Mobile Tier (M-Tier)

Design Consideration

• Localized traffic patterns – Localized sensed data publish and lookup

• Complex queries (range query and beyond)– Data access pattern has some range (e.g.,

commuting path) – More high level query could be possible (will

investigate)

• Data access from mobile users– Need some form of distributed SIP to enable other

users to access data stored in mobile users

Senster Architecture• Structured overlay routing using DHT

– Support unicast/multicast to peers– Provide packet forwarding to mobile users

• SensterDB for data management and query processing – Sensed (meta-)data, control data (e.g., location tracking for SIP)– put/get DB engine over DHT overlay key space

• Query processing, optimization, etc.

• Applications over SensterDB– Pub-sub over SensterDB

• After collecting information, it is pushed via DHT overlay “multicast routing”– Data harvesting application

DHT001

002000

003

M2M1

X

Mobile users

Structuredoverlay routing

SensterDB ProcessorQuery

Optimizer

Catalog Manager

SensterDB

Apps User App Pub/Sub

Key Space Manager

RDB storage

Unicast/multicast routingPacket forwarding

Query processingKey space management

DHT Overlay Routing and Data Management

• Current trends of DHT research– Simple to complex queries

• put/get complex queries (range query, segment query, etc)– Changing overlay structures optimized for complicated queries

• Layered approach is known to be less efficient (e.g., SIGCOMM05)– Complicated queries dirtying the DHT layer

• Additional data management functions: scan, multicast, re-new (VLDB03)

• Putting data management over overlay routing– Key space data management can be handled in the upper layer

• Overlay layer only need to inform the key space information– Data management is application driven– Applications can be easily built on top of data management layer– Easily support more complex queries– Giving more opportunities of optimization

A Case Study in Building Layered DHT Applications (PHT), SIGCOMM’05

Querying the Internet with PIER, VLDB’03

DHT Overlay Routing

• Traditional DHTs (ID space ≠ key space)– DHT maps a node to a random position in the key space– Vehicle density-based load balancing is infeasible– Key space (geo-tagged sensed data)

• Node ID is mapped to geographic space

• Use “Mercury DHT”– Support dynamic load balancing/multi-attribute range query

• Multi-attribute to single attribute– Data duplication in the multiple rings – Coarse grain data range; not suitable for geographic information

storage/retrieval • Grid based approach is recommended (as in typical GIS

applications)

Mercury: Supporting Scalable Multi- Attribute Range Queries, SIGCOMM'04

DHT Overlay Routing• Hilbert curve mapping• Utilize neighbor links

– In CAN, a node maintains a list of neighbors in the coordinate space

– Hilbert curve preserves TWO of its physical neighbors

• Routing table:– Mercury’s routing table– Links to the remaining 2 neighbors (not

covered by the Hilbert curve) • E.g., area 3 and 4 are not covered

• DHT for overlay routing– Lookup(x): geo-ID IP address– Key space change must be notified to

SensterDB• DHT overlay multicast routing

– Adopt SCRIBE

Chawathe05: Case Study in Building Layered DHT Applications, SIGCOMM’05

1

A2 3

4

DHT Overlay Routing

• Mobile user’s location Geo-ID– Mobile user associates with a node that is closest to Geo-ID– Publish/Lookup is localized!

• Mobile user “Association” to DHT– Mobile user has an active connection to the DHT peer– User changes its associated DHT nodes by simply following its

physical neighbor link

• Mobile user tracking– Mobile user publishes its location (association point) in DHT– Geo-ID is a rendezvous point for location access (as in GHT)

• DHT client forwards packets to associated mobile users

SensterDB

• SensterDB overtakes DHT data management – Expressiveness and optimization are possible– Relational model

• Declarative query language (SQL)– + stream database processing

• Relaxed DB requirements (Huebsch03)– Relax ACID transaction requirements– Best-effort (+approximate) query answering

• Data access patterns– Spatio index + temporal filtering

• For a given area, time is used for filtering• Spatial range query is frequent (e.g., commuting path)

– One time vs. continuous queries

Huebsch03: Querying the Internet with PIER, VLDB’03

SensterDB• Mobile client

– Data processing• Data aggregation or filtering

– Data publishing to DHT nodes– Data retrieval request processing from other peers

• Internet client– Data management

• Replication • Key space (name space) management

– Query processing • Planning, optimization• Remote request processing

– Interaction w/ DHT• Load information (for DHT load balancing)• Key space management (for data migration and replication)

• SensterDB is responsible for data replication and caching – DHT was responsible for that in conventional systems

Supporting Pub/Sub?

• Application layer pub/sub over SensterDB

• Pub/Sub types– Topic-based pub/sub: (group multicast)

• What’s the topic? Must define high level topics• SCRIBE can be used as DHT multicast routing

– Content-based pub/sub• Can be easily implemented using continuous

queries• Not sure whether it’s feasible or not..

Discussion

• Utilizing WiFi?– 3G has large latency, but WiFi may bring low

latency data access• Safety applications…

– Data aggregation via multi-hopping?

• Sensor data archiving?– Currently data will disappear after a certain

period of time..– Data crawling from DHT may be considered…

Security/Privacy Issues

• False data injection problems– Statistical filtering– Context aware filtering

• E.g., mobility model based, geographic information based, etc.

• Privacy– Location tracking

• Mobile users can associate with multiple locations• Every time it changes its association

– Anonymous data reporting