Information Dissemination & Retrieval via Vehicular Mesh Networks

1. University of California, Davis Information Dissemination & Retrieval viaVehicular Mesh Networks Principle investigators: C-N. Chuah, Electrical & Computer Engineering D. Ghosal, Computer Science M. Zhang, Civil & Environmental Engineering

2. Outline • Problem Statement • Overview of solution • Example VMesh • Feature comparisons of different types of VMesh and recommendations • Addressing key requirements and goals • Qualitative evaluation of VMesh • Architectural components of VMesh • Research and development issues • Deliverable and milestones • Budget

3. Enabling Network for Demand Response (DR) • Multiple utility meters at user premise • Electricity, water, and gas • Electric meters are equipped with wireless sensors • Transmit usage information (inbound message) • Receive/process pricing information (outbound message) • A DR backbone wide area network (WAN) to the utility provider • Objective • How to connect the end-users to the DR backbone using a LOW COST, SCALABLE, and FAULT-TOLERANT network?

4. VMesh – A Vehicular-based Mesh Network • Distributed, low cost, vehicular mesh network to inter-connect end-users to the DR backbone WAN • Combine static and mobile concentration points (SCPs & MCPs) • Leverage various types of vehicles to participate as MCPs and form the VMesh • buses, light rail, postal vans, utility/garbage trucks • FEDEX, UPS, and other vendor trucks • police cars and personal automobiles

5. Architectural Components of VMesh • Sensors at end-users (STUs) • STUs can form user side networks to route inbound and outbound messages • User-side concentration points as gateways to VMesh • These could be specific STUs or special nodes deployed at appropriate locations • Each STU can act as a gateway • Mobile Routers • Various types of vehicles equipped with storage and wireless networking to form ad hoc networks with other mobile routers and connect to static gateways • Utility-side gateways to VMesh • These are gateways to the DR backbone network

6. An Example VMesh Inbound/ outbound message flow Electrical user Gateway to DR WAN located at a bus depot Utility Center wireless DR Backbone WAN

7. Classification of Vehicles • Types of vehicles • Personal automobile • Public transit – busses and light rails • US postal vans • Garbage trucks • Vendor trucks – UPS/FEDEX and ice cream • Police cars • Classification Parameters • Coverage: How many end-users are directly accessed? • Schedule and Periodicity: If there is a schedule, what is the period? • Redundancy: Are there overlaps/redundancy in paths? • Cost: What is the cost of deployment and maintenance cost in terms of number of SCPs, MCPs, and gateways?

8. Feature Comparison of Different Vehicles (1)

9. Feature Comparison of Different Vehicles (2)

10. Feature Comparison of Different Vehicles (3)

11. Addressing R&D Task Goals (1) • Support for dynamic tariffs and DR strategies • Enables location marginal pricing (LMP) • Vehicles equipped with GPS and intelligence to support various other DR strategies • Scalable to large deployment • Minimize the number of concentration points • Minimize maintenance cost – MCPs (e.g., buses) can drive to a station for repairs and software upgrades • Leverage the vehicular mesh network for other applications • Vehicular traffic flow control and management • Enhanced amber alert

12. Addressing R&D Task Goals (2) • Minimal latencies • Deflection Routing to minimize message latency and increase survivability • Deflect messages until a valid path is found towards destination instead of dropping them • Deflect messages using other vehicles to form a secondary mesh network in the event of failures/delay in the primary network • Broadcast and multicast capability • High level of redundancy via overlapping vehicular routes • Different vehicles provide different granularity in spatial coverage and temporal samplings, e.g., • garbage trucks visit “every household” but only once a week • postman visits “every household” once/twice a day • public buses travel only along “nearby main streets” but more frequently, say every 30 minutes

13. Qualitative Evaluation of VMesh (1) • Adaptive Fidelity (or Flexibility) • Provide reliable and predictable connectivity in densely populated downtowns • In densely populated areas, cellular infrastructure will have very high usage (and hence higher probability of a busy signal) during time of day when energy consumption peaks. • VMesh is a more reliable than cellular networks. • Provide low-cost connectivity in remote areas • In remote areas that have no cellular coverage, VMesh has tremendous cost advantage over building new cellular infrastructure (e.g., antenna sites, base stations). • Provide a redundant network in medium populated areas • Even in areas where cellular infrastructure is ideal for DR, VMesh can provide a secondary network for redundancy and more naturally support LMP

14. Qualitative Evaluation of VMesh (2) • Predictable performance with multiple granularity of spatial and temporal coverage • Fixed schedule • Predictable message delivery time/delay • Schedule is also favorable for this application, e.g., buses are more frequent at peak traffic hours (in the evening), which also coincides with peak electricity usage when people get home from work. • Natural clustering • Bus routes are designed to provide efficient coverage of residential, especially areas with heavy concentration of apartment buildings • Amortize cost over other applications of vehicular network • Amber alert • Collecting real-time information about traffic to ease congestions • Support localized response • Price information (outbound messages) can vary depending on the demand/supply in different neighborhoods

15. Qualitative Evaluation of VMesh (3) • Survivability and Redundancy • Leverage overlapping bus routes to provide multiple paths for routing DR messages • Primary/secondary vehicular mesh (VMesh) networks • When the primary mesh networks fails (e.g., buses running late, accidents), leverage other vehicles, e.g., FEDEX/UPS trucks or vendor vehicles, as backup “information collector/disseminator” to form a secondary VMesh • Use deflection routing algorithms to hand-off between primary and secondary VMesh to ensure that messages are forward around trouble spots towards the destinations • Secondary vehicles, e.g., ice cream vendors are usually touring the neighborhood when people (particularly kids) are at home (3-6pm), which also coincides with the high utility usage period.

16. Research and Development Challenges (1) • Intelligent clustering of end-users (STUs) • Propagate information towards bus routes • Optimized static multicast tree for routing and data aggregation among STUs; tree construction and membership maintenance issues • Multihop and multipath routing • Failure resilient forwarding via VMesh • leverage intersections of bus route • enable bus-to-bus communications in the event of accidents/failures • deflection routing algorithm to hand-off between primary & secondary VMesh

17. Research and Development Challenges (2) • Centralized vs. distributed demand response • Local “intelligence” to adapt outbound messages based on several input parameters (e.g., local temperature, inbound response, living cost, etc.) • Concept of active messages • Leverage temporal & spatial properties • different price based on neighborhood • more frequent transmissions during peak hours • Vehicular mesh network management • AI logic for decision making • Interface in the VMesh node (bus) equipped with GPS, radio interface for communications

18. Deliverables and Milestones (1) • Task1 (6 months): Extended PARAMICS* vehicular simulator • Realistic freeway and city streets • Realistic background vehicular traffic • Need to implement radio model, transceiver characteristics, MAC and ad-hoc routing layers • VMesh components • electric users sensors/transceivers units (STUs) • concentration points for data aggregation (MCPs and SCPs) • wireless LAN connectivity between buses and concentration points (Vnode) • staging points (SPs) to backbone WAN via wireless LAN or CDPD *PARAMICS, http://www.paramics-online.com

19. Deliverables and Milestones (2) • Task 2: Design, develop and evaluate VMesh mechanisms(3 months design, 3 months evaluation + refinement) • Track propagation of messages within primary VMesh from buses to end-users and vice versa • Determine the upper-bound for end-to-end latency • how fine-granularity can the DR feedback loop be? 30 minutes? 1 hour? • Deflection routing • Evaluate the agility of the system • how long does it take to switch from primary to secondary VMesh in the event of failures?

20. Future Research Agenda -- Phase 2 • Prototype/Demos (12-18 months) • Start a year from now after Phase 1 • Leverage UNITRANS • Off-the-shelf sensors in the buses and wireless access points along the main Davis street • Prototypes of our algorithms

21. Budget

22. Citris Initiative • How to link it to other non-overlapping Citris efforts? • Potential collaboration after the first phase

24. Collaboration with Berkeley • R.Katz’s SAHARA project • provides core network functionality • P. Wright • provides enabling technologies (e.g., sensors) for end users • We provide complementary strengths • bridge between the core and access networks