1. Supporting Emergency- Response by Retasking Network Infrastructures Presented by: Michael LeMay Carl A. Gunter

2. Outline Introduction Emergencies and Hazards to Networks Networking Requirements During Emergencies Traditional Emergency-Response Network Topology and Application Trends Emergency-Response with Retaskable Networks Discussion

3. Introduction Networks face various hazards during emergencies, and may cease to function as a result Additional networking requirements may also arise during emergencies Network availability during emergencies could be improved by allowing users to route communications over robust network infrastructures that managed to survive

4. Emergencies and Hazards to Networks Katrina: Only significant operational network in downtown was wireless mesh for surveillance cameras –Hazards: Flooding, high winds 9/11: Disrupted many networks routed through WTC –Hazards: Terrorist bombing Kobe earthquake: ERNs could have helped prevent misdirection of recovery resources

5. Special Network Requirements During Emergencies Distress signaling from victims to rescuers Messaging (text, voice, or perhaps video) between and among victims and rescuers Command and control for rescuers

6. Traditional Emergency Response Dedicated ERNs: Often government- funded –Limited in scope according to budget Ad-hoc mobile nodes deployed on an as-needed basis –May not penetrate to central parts of hazardous disaster zones Manual retasking of existing networks (e.g. Katrina surveillance camera mesh) –Only utilizes a small portion of infrastructure elements, may not support necessary ERN application-level protocols

7. Network Topology and Application Trends Self-healing mesh networks being used in increasingly-practical applications: –Advanced electric meters –Building and home automation systems –Parking garage monitoring –Surveillance cameras –Municipal wireless May not be necessary for their original intended purpose when disaster occurs, so could support recovery efforts instead

8. Emergency-Response with Retaskable Networks Proposal: Retask robust networks that survive a disaster to be used for emergency-response applications Three primary challenges: –Emergency detection mechanisms and policies –Platform support –Topological readiness planning and assessment

9. Emergency Detection Mechanisms and Policies Mechanisms: –Emergency declarations from central authorities –Sensor inputs (e.g. power outage detection on meters) –Human inputs (e.g. panic button on programmable communicating thermostat [PCT]) Reasonable policy: –Digitally-signed indications from central authorities trusted absolutely –Sensor and human inputs weighted and compared to a threshold value

10. Hardware Platform Support Network compatibility: All communicating devices must use compatible network protocols, or appropriate gateways/bridges must be available –Not yet widely available for all interesting protocols Network availability: A sufficient subset of network devices and linkages must be operational to support ERN services Device availability: Devices must be adequately protected against prevalent hazards in the deployment zone, and equipped with sufficient power reserves

11. Platform Support Examples Wired networks GSM Gateway ZigBee Gateway ZigBee Meters Rescuer Communicator w/ ZigBee Interface GSM Mobile Phone ZigBee Programmable Communicating Thermostat with ERN Enhancements

12. Software Platform Support Software support must be provided for all desired ERN services Potential approaches: –Software extensibility: Make network elements reconfigurable, so they can load any software components required for ERN services dynamically –Protocol standardization: Standardize simple protocols for ERN services that will have longevity due to their simplicity

13. Proposed Software Platform Support IP tunneling over all network types –Challenging due to the packet size limitations of 802.15.4 and other popular networks –Routing is complicated due to redundant paths Simple text, voice, and video messaging services for victims and rescuers Emergency alert broadcast service –Useful for warnings of tornadoes, fires, biohazards, etc.

14. Security Challenges ERN functionality of retaskable networks must not negatively affect the network during normal operating conditions –Malicious users must not be able to trick network into falsely believing an emergency has occurred, to steal service Network should provide best QoS to those who are at the highest risk in the emergency and those best equipped to assist them

15. ERN Topology Planning ERNs must provide reliable connectivity in the presence of hazards prevalent in the area under consideration A comprehensive ERN planning methodology must be developed, that accounts for dedicated, re-taskable, and ad-hoc infrastructure elements The resulting network must support the bandwidth demands of its expected users, and potentially have redundancy

16. ERN Topology Planning Challenge: Varying capabilities of different types of networks (bandwidth, etc.), and unpredictable mobile nodes Current topology optimization algorithms can potentially be adapted to ERN planning problems We investigate the non-uniform buy-at- bulk approximation algorithm proposed by C. Chekuri, et. al. and adapt it to ERN planning

17. Adaptation of ERN Planning Algorithm Rather than optimizing strictly for financial cost of resulting network, use artificial cost that prefers network links that are: –Robust against the particular hazards prevalent in the area under consideration –Financially inexpensive; particularly favorable for existing, retaskable infrastructure –Low latency Provisional links that might be installed are included.

18. Example Topology 250kbps 100Mbps 11Mbps 1.Every node requires 50kbps bw. to every other node except the central ZigBee routers and A 2.Every node requires 100kbps bw. to gateway A

19. Future Research Application-level protocols suitable for emergency-response Security and QoS protocols for ERNs Routing on dynamic networks with redundancy

20. Concluding Remarks Robust networks are being deployed in practical applications By retasking such networks after a disaster, emergency-response can be aided There are significant problems to be overcome in: –Emergency detection –Hardware platform support for emergency- response –Software platform support for emergency- response

21. Questions? Michael LeMay: mdlemay2@cs.uiuc.edumdlemay2@cs.uiuc.edu Carl A. Gunter: cgunter@cs.uiuc.educgunter@cs.uiuc.edu Parent project page: http://seclab.uiuc.edu/attested-meter http://seclab.uiuc.edu/attested-meter