Transcript Supporting Emergency-Response by Retasking Network

Supporting EmergencyResponse by Retasking
Network Infrastructures
Presented by: Michael LeMay
Carl A. Gunter
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
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
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
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
Traditional Emergency Response
• Dedicated ERNs: Often governmentfunded
– 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
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
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
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
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
Platform Support Examples
GSM Gateway
ZigBee
Meters
GSM Mobile Phone
Wired networks
ZigBee Gateway
ZigBee Programmable
Communicating Thermostat with
ERN Enhancements
Rescuer
Communicator
w/ ZigBee
Interface
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
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
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-atbulk approximation algorithm proposed by
C. Chekuri, et. al. and adapt it to ERN
planning
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.
Example Topology
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
250kbps
100Mbps
11Mbps
Future Research
• Application-level protocols suitable for
emergency-response
• Security and QoS protocols for ERNs
• Routing on dynamic networks with
redundancy
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 emergencyresponse
– Software platform support for emergencyresponse
Questions?
• Michael LeMay: [email protected]
• Carl A. Gunter: [email protected]
• Parent project page:
http://seclab.uiuc.edu/attested-meter