Next-Generation Emergency
Calling (NG911)
Henning Schulzrinne
Dept. of Computer Science, Columbia University, New York
hgs@cs.columbia.edu
(with Jong Yul Kim, Wonsang Song, Anshuman Rawat, Matthew Mintz-Habib, Amrita Rajagopal
and Xiaotao Wu; LoST is joint work with Hannes Tschofenig, Andrew Newton and Ted Hardie)
IEEE NY Lecture
October 18, 2007
Outline
emergency call
alert
coordination
• Emergency calling
– the challenge of two transitions: mobility and VoIP
– Emergency alerts
• Emergency alerting
– beyond siren replacement
• Emergency coordination
– going beyond ad hoc networks
IEEE NY
2
Modes of emergency communications
emergency call
information
“I-am-alive”
emergency alert
(“inverse 911”)
dispatch
civic coordination
IEEE NY
3
Outline
• Emergency calling
– the challenge of two transitions
• mobility and VoIP
• Emergency alerts
• Emergency coordination
IEEE NY
4
Background on 9-1-1
• Established in Feb. 1968
–
–
–
–
1970s: selective call routing
late 1990s: 93% of population/96% of area covered by 9-1-1
95% of 9-1-1 is Enhanced 9-1-1
US and Canada
• Roughly 200 mio. calls a year (6 calls/second)
– 1/3 wireless
• 6146 PSAPs in 3135 counties
– most are small (2-6 call takers)
– 83.1% of population have some Phase II (April 2007)
• “12-15 million households will be using VoIP as either
primary or secondary line by end of 2008” (NENA)
IEEE NY
http://www.nena.org/
5
Local Switch
Automatic
Number
Identification
Automatic
Location
Identification
IEEE NY
Collaboration between
local phone providers and
local public safety agencies
6
911 technology failures
• NY Times (“An S O S for 911 Systems in Age of High-Tech”), 4/6/07:
– “40% of … counties, most of them rural or small-town …, cannot yet
pinpoint the location of the cellphone callers, though the technology to
do so has been available for at least five years.”
“In … Okmulgee, Okla., last November, 4-year-old Graciella MathewsTiger died in a house fire after a 911 operator who lacked the
technology to pinpoint the call misheard the address.”
• Phase II wireless; billions of dollars spent
• In Mississippi, only 1 of out 5 counties
– “As it ages, it is cracking, with problems like system overload,
understaffing, misrouted calls and bug-ridden databases leading to
unanswered calls and dangerous errors.”
• operator (CAMA) trunks, with 8-digit number delivery
• MSAG and ALI databases
IEEE NY
7
911 technology failures, cont’d
• “In Cherokee County [OK], for instance, the volume has increased
by 20 percent a year.”
“… answer 911 lines, then transfer calls to dispatchers for individual
fire and police departments in the county, a system that requires
callers to repeat themselves.”
– Inefficient call handling
– Vermont dispatch-by-printer
• “Officials in Riverside County, Calif., fed up with misrouted calls,
have been advising residents to call the sheriff or local fire
department directly.”
– incomplete MSAG
– cumbersome ALI update procedures
IEEE NY
8
911 technology failures, cont’d.
• “In Bessemer, Ala., city employees could not get through
to their own 911 system when a colleague had a seizure,
at a time when the city and others like it are struggling to
upgrade their systems at a cost of hundreds of
thousands of dollars.”
– specialized technology supplied by small vendors
– almost no R&D
• “Yet even the newest systems cannot adequately handle
Internet-based phone services or text messages, which
emerged as the most reliable form of communication
during Hurricane Katrina.”
– mostly voice-only
– plus TDD (TTY), plus deaf are switching to IM
IEEE NY
9
911 problems
• “Ellis is accused of a relatively new Internet-related crime
called "swatting.” Police believe Ellis, of Mukilteo, Wash.,
used an online service for the hearing impaired and
other high-tech methods to make false reports of
escalating violence to police departments across the
country. … The false reports ended with SWAT team
members taking down innocent people at gunpoint and
holding them for questioning.” (Erie Times News, Oct.
17, 2007)
– no location reporting for TDDs
– no user authentication or meta data
IEEE NY
10
Dept. of Transportation view
• The 9-1-1 system
– based on 30-year old technology
– expensive for local 9-1-1 call centers to maintain
– incapable of supporting the text, data, images, and video that are
increasingly common in personal communications.
– Travelers and other citizens cannot now use their “smart”
technologies such as telematics, medical alert devices, or
wireless computers to directly access 9-1-1 call centers and
emergency responders.
• Emergency centers cannot now send location-targeted
hazard alerts and evacuation guidance to motorists or
other mobile device users
Next-Generation 9-1-1 Initiative slides
IEEE NY
11
VoIP emergency communications
Contact wellknown number
dispatch
or identifier
Route call to
locationappropriate PSAP
Deliver precise
location to call
taker to dispatch
emergency help
IEEE NY
now
transition all IP (“NG911”)
112
911
112
911
112, 911
VPC
LoST
in-band 
key 
location
in-band (SIP)
SR
phone
number

location
(ALI
lookup)
urn:service:sos
12
Why is this a hard problem?
•
More than just installing software and buying new PCs
– mapping (GIS systems can’t use Google Maps)
– training
•
Decentralized system
– 6000+ PSAPs
– estimated cost of upgrade: $340m (=> $57,000/PSAP)
• 233 million US mobile phone subscribers
•
Cost-plus ILEC MSAG
–
–
–
–
•
the MSAG update protocol: fax
no incentive to upgrade
no incentive to cooperate with CLECs and VSPs
unclear ownership of database
Issues of control and “turf”
– consolidation
• efficiency vs. local knowledge
– funding: state vs. county vs. town (volunteer fire department)
IEEE NY
13
What makes VoIP 112/911 hard?
POTS
PSTN-emulation VoIP
(landline) phone
number limited to
limited area
landline phone number no phone number or
anywhere in US (cf.
phone number
German 180)
anywhere around the
world
regional carrier
national or continentwide carrier
enterprise “carrier” or
anybody with a peerto-peer device
voice provider = line
provider (~ business
relationship)
voice provider ≠ ISP
voice provider ≠ ISP
national protocols and
call routing
probably North
America + EU
international protocols
and routing
location = line location
mostly residential or
small business
stationary, nomadic,
wireless
IEEE NY
end-to-end VoIP
14
More than pain…
• Multimedia from the caller
– video capture from cell phones
– video for sign language
– text messaging and real-time text for the deaf
• Data delivery
– caller data: floor plan, hazmat data, medical alerts
– measurement data input: automobile crash data, EKGs, …
• Delivering video to the caller
– e.g., CPR training
• Load balancing and redundancy
– currently only limited secondary PSAP
– VoIP can transfer overload calls anywhere
• Location delivery
– carry location with forwarded and transferred calls
– multiple location objects (civic + geo)
IEEE NY
15
Four Phases of Emergency Calls
Phase 1
Determine
Location
IEEE NY
Phase 2
Identify
Emergency
Calls
Phase 3
Route to
Correct
PSAP
Phase 4
Present
Call to
Calltaker
16
IETF ECRIT working group
•
•
Emergency Contact Resolution with Internet Technologies
Solve four major pieces of the puzzle:
–
–
–
–
•
location conveyance (with SIP & GEOPRIV)
emergency call identification
mapping geo and civic caller locations to PSAP URI
discovery of local and visited emergency dial string
Not solving
– location discovery --> IETF GEOPRIV WG, IEEE
– inter-PSAP communication and coordination
– citizen notification
•
Current status:
– finishing general and security requirements
– agreement on mapping protocol (LoST) and identifier (sos URN)
– working on overall architecture and UA requirements
IEEE NY
17
Emergency numbers
• Each country and region
has their own
– subject to change
• Want to enable
– traveler to use familiar home
number
– good samaritan to pick up cell
phone
• Some 3/4-digit numbers are
used for non-emergency
purposes (e.g., directory
assistance)
IEEE NY
Emergency number
18
Service URN
• Idea: Identifiers to denote emergency calls
– and other generic (communication) services
• Described in IETF ECRIT draft draft-ietf-ecrit-service-urn
• Emergency service identifiers:
sos
sos.animal-control
sos.fire
sos.gas
sos.marine
sos.mountain
sos.physician
sos.poison
sos.police
IEEE NY
General emergency services
Animal control
Fire service
Gas leaks and gas emergencies
Maritime search and rescue
Mountain rescue
Physician referral service
Poison control center
Police, law enforcement
19
‘counseling’ services
urn:service:counseling
Generic counseling service (call
center)
…:counseling.children
run-aways, child abuse
…:counseling:mental-health
diagnostic, treatment, and preventive
care … mental health
…:counseling:suicide
suicide prevention hotline
IEEE NY
20
Services under discussion
• “211” (social service referral), “311” (non-emergency
government services)
• Emergency services (first responders)
– used by PSAP, not civilians
– e.g., urn:service:es:police
• Non-emergency commercial services
– urn:service:restaurant.italian
– urn:service:transportation.taxi
IEEE NY
21
Location, location, location, ...
Voice Service Provider (VSP)
sees emergency call
but does not know caller location
ISP/IAP knows user location
but does not handle call
IEEE NY
22
Locating Caller using LLDP-MED
LLDP-MED stands for: *
* From Wikipedia
Link Layer Discovery Protocol
“a vendor-neutral Layer 2 protocol that allows a network device
to advertise its identity and capabilities on the local network.”
Media Endpoint Discovery
“an enhancement to the LLDP that allows discovery of other
things including location “
“I am LLDP-MED Capable.
I can process location information.”
CALLER
EQUIPMENT
IEEE NY
LLDP-MED
SWITCH
“Your location is:
23
500 W 120TH st. New York NY 10027”
DHCP for Location
•
•
•
Use MAC address to get location information
Mainly for stationary users
We modified ISC’s dhcpd
DHCPINFORM
[MAC=00:11:20:9d:a0:03]
request
or
response
DHCPACK
[option=0:US:1:NY:2:NEW YORK:
3:NEW YORK:6:AMSTERDAM:19:1214]
IEEE NY
DHCP Server
24
DHCP elements: Administrative Subdivisions
A1
national subdivision
state, canton, region, province, prefecture
A2
county, parish, gun (JP), district (IN)
A3
city, township, shi (JP)
A4
city division, borough, city district, ward, chou (JP)
A5
neighborhood, block
A6
group of streets
NENA
PIDF
Description
Example
PRD
PRD
Leading street direction
N
POD
POD
Trailing street suffix
SW
STS
STS
Street suffix or type
Ave, Platz
HNO
HNO
House number
123
HNS
HNS
House number suffix
A, ½
LMK
LMK
Landmark or vanity address
Columbia University
LOC
LOC
Additional location information
South Wing
NAM
NAM
name (residence and office occupant)
Joe’s Barbershop
BLD
building (structure)
Low Library
UNIT
unit (apartment, suite)
Apt 42
FLR
floor number
4
room number
450F
postal/zip code
10027-1234
ZIP NY
IEEE
PC
support
multiple
characte
r sets for
each
25
SkyHook for Location
•
•
•
•
Mainly for nomadic, mobile users
Wireless device receives signals from Wi-Fi sites in range
Skyhook compares signals to its database of geographically known
locations
Location data is used to direct safety services
Taken from http://www.skyhookwireless.com
IEEE NY
26
Location determination options
Method
CDP or LLDPMED
DHCP
HELD
GPS
manual entry
Layer
L2
L3
L7 (HTTP)
-
user
advantages
• simple to
implement
• built into switch
• direct port/room
mapping
• simple to
implement
• network
locality
• traverses
NATs
• can be
operated by
L2 provider
• accurate
• mobile
devices
• no carrier
cooperation
• no
infrastructure
changes
• no carrier
cooperation
problems
may be hard to
automate for large
enterprises
mapping MAC
address to
location?
mapping IP
address to
switch port?
• indoor
coverage
• acquisition
time
• fails for
mobile
devices
• unreliable for
nomadic
Use
Ethernet LANs
Enterprise
LANs
Some ISPs
DSL, cable
mobile devices
fall back
IEEE NY
27
Components of NG911 system
•
•
•
•
Location determination
Call identification --> service URNs
Call routing --> LoST
PSAP functionality
– IVR, logging, multimedia conferencing, …
LoST
(public)
LoST
(private)
ESN
(county, state, …)
Internet
IEEE NY
PSAP
PSAP
28
UA recognition & UA resolution
location information
mapping
DHCP
LLDP-MED
9-1-1
(dial string)
INVITE urn:service:sos
To: urn:service:sos
Route: sip:psap@leonianj.gov
<location>
IEEE NY
leonianj.gov
identification
TBD
mapping
may
recurse
INVITE urn:service:sos
To: urn:service:sos
Route: sip:fire@leonianj.gov
<location>
29
LoST: A Protocol for Mapping
Geographic Locations to Public
Safety Answering Points
Henning Schulzrinne, Hannes Tschofenig,
Andrew Newton, Ted Hardie
Problem: Finding the correct PSAP
• Which PSAP should the e-call go to?
–
–
–
–
Usually to the PSAP that serves the geographic area
Sometimes to a backup PSAP
If no location, then ‘default’ PSAP
solved by LoST
I am at "Otto-Hahn-Ring 6, 81739
München"
I need contact the ambulance.
(Emergency Identifier)
Mapping
Client
Mapping
Server
Contact URI example@psap1.org
IEEE NY
34
LoST functionality
• Mapping of location to parameters (e.g., URL)
• Civic as well as geospatial queries
– civic address validation
• Recursive and iterative resolution
• Pre-querying and caching for efficiency and robustness
– query ahead of emergency call (e.g., at boot time for stationary devices)
– no re-querying while moving
• Fully distributed and hierarchical deployment
– can be split by any geographic or civic boundary
– same civic region can span multiple LoST servers
• Indicates errors in civic location data  debugging
– but provides best-effort resolution
• Supports overlapping service regions
– e.g., contested regions (Kashmir, Palestine, Taiwan, ...)
IEEE NY
35
LoST: Location-to-URL Mapping
VSP1
cluster serving VSP1
replicate
root information
cluster
serves VSP2
123 Broad Ave
Leonia
Bergen County
NJ US
LoST
NJ
US
sip:psap@leonianj.gov
root
NY
US
nodes
search
referral
Bergen County
NJ US
Leonia
NJ US
IEEE NY
36
LoST Architecture
G
tree guide
G
G
G
T1: .us
G
broadcast (gossip)
T2: .de
resolver
seeker
313 Westview
Leonia, NJ US
T2
T1
IEEE NY
(.us)
(.de)
T3
(.dk)
Leonia, NJ  sip:psap@leonianj.gov
37
LoST Properties
• Minimizes round trips:
– caching individual mappings
– returns coverage regions (“hinting”)
• civic (“all of C=US, A1=NY”) or geo (polygon)
• Facilitates reuse of Transport Layer
Security (TLS)
• Returns emergency service numbers for a
region
• Query for supported Service URN types
IEEE NY
38
LoST: Query example
• Uses HTTP or HTTPS
<findService xmlns="urn:…:lost1”
recursive="true" serviceBoundary="value">
<location profile="basic-civic">
<civicAddress>
<country>Germany</country>
<A1>Bavaria</A1>
<A3>Munich</A3>
<A6>Neu Perlach</A6>
<HNO>96</HNO>
</civicAddress>
</location>
<service>urn:service:sos.police</service>
</findService>
IEEE NY
39
LoST “Find Service” response/warning example
<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1">
<mapping expires=“1990-12-31T23:59:60Z” lastUpdated=“2006-11-01T01:00:00Z”>
<displayName xml:lang="de">München Polizei-Abteilung</displayName>
<service>urn:service:sos.police</service>
<serviceBoundary profile=”civic”>
<civicAddress xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>Germany</country>
<A1>Bavaria</A1><A3>Munich</A3><PC>81675</PC>
</civicAddress>
</serviceBoundary>
<uri>sip:munich-police@example.com</uri>
<serviceNumber>110</serviceNumber>
</mapping>
<path>
<via source=“lost:esgw.uber-110.de.example”/>
<via source=“lost:polizei.munchen.de.example”>
</path>
</findServiceResponse>
IEEE NY
40
Validation
• Determine if civic location is (partially) valid
• Returns XML tag names of components:
– validated and used for mapping
– no attempt to validate (and not used)
• e.g., house number
– known to be invalid
• Return (default) PSAP based on validated elements
• May return list of guesses for correct addresses, if
requested
<locationValidation>
<valid>country A1 A3 A6</valid>
<invalid>PC</invalid>
</locationValidation>
IEEE NY
41
Geo support
• Which geo types should be supported?
– Point (3D) 
– Polygon?  may yield ambiguous answers
– more complicated shapes?
• Current proposal
– always include 2D-point
– may include other shapes
• Caching of mappings
– return service region
– only query again if mobile leaves service region
– open issue: “holes” in service region
IEEE NY
42
Advanced LoST functionality
•
Get list of (emergency) services supported
– by server
– for a region
•
Obtain service regions
– identified by globally-unique tag
<listServicesByLocation>
<location profile="geodetic-2d">
<p2:Point srsName="urn:4326">
<p2:pos>-34.407 150.883</p2:pos>
</p2:Point>
</location>
<service>urn:service:sos</service>
</listServicesByLocation>
IEEE NY
<listServicesByLocationResponse>
<serviceList>
urn:service:sos.ambulance
urn:service:sos.animal-control
</serviceList>
<path>
<via source="auth.example"/>
<via source="res.example"/>
</path>
</listServicesByLocationResponse>
43
Server synchronization
• Synchronization of forest guides and server clusters
– push <mapping> information to peers
– get list of new elements and retrieve mappings
<getMappingsRequest>
<m sourceId="lost.example"
sourceId="abc123" lastUpdated=“..” />
</getMappingsRequest>
existing
server
new
server
<getMappingsResponse>
<mappings>...</mappings>
IEEE NY
44
Performance of CU LoST server
roughly 170 req/sec
--> ~17M / day
3.2
3.82
XML (ms)
database (ms)
dual-core P4/3.0 GHz
Linux 2.6.19
Postgresql 8.1.4
Tomcat 4.1
IEEE NY
45
SIP message for Location Info.
INVITE urn:service:sos SIP/2.0
To: urn:service:sos
Call-ID: 763782461@192.168.1.106
Via: SIP/2.0/TCP 192.168.1.106:4064;rport
Content-Type: multipart/mixed; boundary
From: sip:caller@irt.cs.columbia.edu
Contact: <sip:eddie@160.39.54.70:5060>
CSeq: 1 INVITE
Content-Length: 1379
request line
header fields
------ =_ZGY1NTFlZDJkMDkxY2FkMTIxMWI2MzIzNjE1M2U0OTY=
MIME-Version: 1.0
content-Type: application/sdp
Content-Transfer-Encoding: 8bit
v=0
o=eddie 1127764654 1127764654 IN IP4 192.168.1.106
s=SIPC Call
c=IN IP4 160.39.54.70
t=0 0
m=audio 10000 RTP/AVP 0 3
m=video 20000 RTP 31
SDP
IEEE NY
------- =_ZGY1NTFlZDJkMDkxY2FkMTIxMWI2MzIzNjE1M2U0OTY=
MIME-Version: 1.0
Content-Type: application/pidf+xml
Content-Transfer-Encoding: 8bit
<?xml version="1.0" encoding="ISO-8859-1"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:cl=" urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc"
xmlns:gml="urn:opengis:specification:gml:schema-xsd:feature:v3.0"
entity="sip:calltaker_ny2@irt.cs.columbia.edu">
<tuple id="28185">
<status>
<gp:geopriv>
<gp:location-info>
<cl:civilAddress>
<cl:country>us</cl:country>
<cl:A1>ny</cl:A1>
<cl:A2>new york</cl:A2>
<cl:A3>new york</cl:A3>
<cl:A6>amsterdam</cl:A6>
<cl:HNO>1214</cl:HNO>
</cl:civilAddress>
</gp:location-info>
<gp:method>Manual</gp:method>
</gp:geopriv>
</status>
<contact priority="0.8">sip:eddie@160.39.54.70:5060</contact>
<timestamp>2005-09-26T15:57:34-04:00</timestamp>
</tuple>
</presence>
------- =_ZGY1NTFlZDJkMDkxY2FkMTIxMWI2MzIzNjE1M2U0OTY=--
PIDF-LO46
NENA i3 architecture
IEEE NY
47
NENA i3 architecture
IEEE NY
48
Current activities
• IETF ECRIT working group
– finishing LoST, architecture, synchronization
• NENA
– architecture
– transition documents
– web services for queries
• DOT
– NG911 project with BAH, Columbia & TAMU as sub-contractor
– building proof-of-concept, based on earlier NTIA work
– “National architecture for NG9-1-1 system” & “Transition plan for NG9-11 implementation”
• Lots of other activities
– e.g., semi-annual Emergency Services Coordination Workshop
IEEE NY
49
NG9-1-1 Prototype Architecture
Location
GPS
Routing
LIS
Location
Info
DHCP Server
Location
key
Location
Info
LoST Cluster
Location
PSAP
Info
sip:psap@domain2
w/location
911
112
PSAP
sip:psap@domain2
with location
SIP UA
PSAP SIP Proxy
urn:service:sos
w/out location
Local SIP Proxy
Conference
Server
civil location
geo location
sip:psap@domain2
with location
sip:rep@domain2
with location
PSTN
911
POTS/Wireless
Network
IEEE NY
IP Gateway
psapd
3PCC Controller
GeoLynx /
Google Maps
50
Emergency Call Flow
(2)
Location +
Service
Identifier
(1) Location
LoST Cluster
(3)
PSAP URL +
emergency
dial-string
INVITE call taker
From: caller
(7) <Location>
(6)
(4)
SOS caller
(5)
dial emergency dialstring
or
INVITE PSAP URL
To: urn:service:sos
SIP proxy
INVITE PSAP URL
To: urn:service:sos
<Location>
<Location>
push emergency
button
call taker
Media Stream
IEEE NY
Media Stream
51
Calltaker screen
•
•
Columbia SIPc as SIP UA
Mapping software to display caller’s location
– Geolynx
– Google Maps
IEEE NY
52
Call logs and recorded sessions
IEEE NY
53
NG911 trial: Lessons learned
•
•
Tested NG911 prototype in 3 PSAPs in TX and VA
Surprise: PSAP is really a conferencing system
– LanguageLine, first responders, …
•
Surprise: no uniform incident description
– every jurisdiction uses their own variation and level of detail
•
What is desirable behavior
– rather than current behavior
– e.g., for transfer, overflow
•
Need to integrate call taker management
– presence (availability)
– a specialized call center
•
Special requirements: partial mute
– not typically supported on conference servers
IEEE NY
54
Challenges for NG911
• Technically, much simpler than E911 Phase II
–
–
–
–
hopefully, cheaper, too
but security challenges: location and identity verification
co-existence between E911 and NG911
integrating external data (e.g., OnStar) -- from silo to NG911
SOA
• Logistical challenges
– deployment of new infrastructure
• location and LoST servers
• Legal and regulatory challenges
– will ISPs give out location information to VSPs or customers?
– liability for misrouted calls?
IEEE NY
55
Outline
• Emergency calling
• Emergency alerts
– multi-modal alerting
– beyond siren replacement
• Emergency coordination
IEEE NY
56
Emergency alerting
• “You’d think that after six years, we would have learned something,
but when this fire broke out, there was no notification system in
place, and the people who live around here didn’t know what to do,
said Patricia L. Moore, who lives at 125 Cedar Street, in the shadow
of the burned building. Some of us left the building and some of us
stayed, but we’re all concerned.” (NY Times, August 20, 2007)
• So this summer, when St. John's carried out its annual review of
security procedures, Dr. Pellow lobbied for a change he had long
been considering: a text-messaging system that could send
information about an unfolding crisis to individual cellphones. That
system underwent the ultimate dry run on Wednesday when a
gunman in a mask strode onto the St. John's campus in Jamaica,
Queens. Though no one was hurt, the incident showed that large,
dispersed crowds -- at least 10,000 students were on the campus at
the time -- could respond calmly in the face of alarming information.
(NY Times, September 28, 2007)
IEEE NY
57
Alerting
• Current emergency notification:
– TV and radio (EAS)
• not helpful when watching YouTube
– “Inverse 911”
• landline only
• doesn’t alert care takers, relatives
– CAP (OASIS)
• doesn’t specify transport and event notification mechanism
• Need flexible alerting protocol
– authority-citizen
– authority-authority (FBI to local police)
– citizen-citizen (smoke detector to neighbor)
IEEE NY
58
CAP 1.1 example
<alert xmlns = "http://www.incident.com/cap/1.01">
<identifier>KSTO1055887203</identifier>
<sender>KSTO@NWS.NOAA.GOV</sender>
<sent>2003-06-17T14:57:00-07:00</sent>
<status>Actual</status>
<msgType>Alert</msgType>
<scope>Public</scope>
<info>
<category>Met</category>
<event>SEVERE THUNDERSTORM</event>
<urgency>Immediate</urgency>
<severity>Severe</severity>
<certainty>Likely</certainty>
<eventCode>same=SVR</eventCode>
<expires>2003-06-17T16:00:00-07:00</expires>
<senderName>NATIONAL WEATHER SERVICE SACRAMENTO CA</senderName>
<headline>SEVERE THUNDERSTORM WARNING</headline>
<description>NATIONAL WEATHER SERVICE INDICATED A SEVERE...</description>
<instruction>TAKE COVER.</instruction>
<area>
<areaDesc>EXTREME NORTH CENTRAL TUOLUMNE COUNTY </areaDesc>
<polygon>38.47,-120.14 38.34,-119.95 38.52,-119.74 38.62,-119.89 38.47,-120.14</polygon>
<geocode>fips6=006109</geocode>
<geocode>fips6=006009</geocode>
<geocode>fips6=006003</geocode>
</area>
</info>
</alert>
IEEE NY
59
New alerting architecture
national
authority
SUBSCRIBE
Event: chemical
Area: NJ
national
authority
state or local
authority
SUB/NOT
SMS, IM, voice
automated actions
(sirens, vents, ...)
email
IEEE NY
60
Outline
• Emergency calling
• Emergency alerts
• Emergency coordination
IEEE NY
61
General requirements
•
Low cost
–
•
Ease of use
–
–
–
•
may only be used very rarely
most users are non-techies (or worse)
volunteers with range of capabilities
tools that are familiar to volunteers (web browser vs. custom application)
Robust
–
spikes of usage
•
–
outdoor & hostile environment
•
•
•
•
example: FEMA application crash
example: sun glare rendered laptops useless
no chargers for cell phones
unreliable network connections --> delay-tolerant networks, data mules, 7DS, …
Daily use, not just major catastrophes
–
IEEE NY
nobody wants to learn a new tool during a hurricane
62
Emergency coordination
• Structured coordination
– directories (people, vehicles, equipment, ...)
• see COMCARE effort
–
–
–
–
resource tracking
“trouble tickets”
avoid current low-bandwidth radio-based coordination
most (?) police cars have laptops with data links
• Unstructured coordination
– unpredictable needs
– leverage existing content creation tools: Wikis, blogs, Google
Base, Backpack, ...
– combinations of existing tools (e.g., Google maps and
databases)
IEEE NY
63
Authentication and security
•
Need single-sign on
– but with highly dynamic
authorization
– e.g., mutual aid or volunteers
•
•
Currently, dominated by user
name/password
Use model of GETS card?
– USB key?
– cell phone as authenticator?
IEEE NY
0123 4567 8910
Disaster Response Team #1
US CITY EOC
64
Example: Sahana
• Developed in 2004 after
tsunami (in three weeks)
• Open source (PHP, mySQL)
• Component-based
– organization and people
registry
– inventory management
– situation mapping
– synchronization
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
• allows for disconnected
operation
– XML synchronization
© ACM CACM 2007 50(3)
IEEE NY
65
Peer-to-peer SIP
•
Why?
generic DHT service
p2p network
– no infrastructure available: emergency
coordination
– don’t want to set up infrastructure: small
companies
– Skype envy :-)
•
P2P provider B
P2P technology for
DNS
– user location
• only modest impact on expenses
• but makes signaling encryption cheap
P2P provider A
– NAT traversal
• matters for relaying
traditional provider
– services (conferencing, …)
• how prevalent?
•
New IETF working group just formed
– likely, multiple DHTs
– common control and look-up protocol?
IEEE NY
zeroconf
LAN
66
P2P SIP -- components
• Multicast-DNS (zeroconf) SIP
enhancements for LAN
– announce UAs and their
capabilities
• Client-P2P protocol
– GET, PUT mappings
– mapping: proxy or UA
• P2P protocol
– get routing table, join, leave, …
– independent of DHT
– replaces DNS for SIP, not proxy
IEEE NY
67
Conclusion
• Need for loosely-coupled suite of tools for emergency coordination
– connecting rather than stovepipe systems
– narrow interfaces rather than global master architecture
• NG911 as opportunity to update emergency calling
– robustness
– features (multimedia, connectivity)
– COTS
• Using P2P SIP for local emergency coordination
• Integrated alerting system
– part of broader structured communication system
– possible IETF effort
• Need for large-scale experiments, not yet another ad-hoc network
paper
– cooperation with non-technical users
IEEE NY
68
More information
•
A VoIP Emergency Services Architecture and Prototype
–
•
An Enhanced VoIP Emergency Services Prototype
–
•
M. Mintz-Habib, A. Rawat, H. Schulzrinne, and X. Wu, ICCCN 2005, Oct. 2005
Jong Yul Kim, Wonsang Song, and Henning Schulzrinne, ISCRAM 2006, May 2006
Providing emergency services in Internet telephony
•
– H. Schulzrinne & K. Arabshian, IEEE Internet Computing, May/June 2002
Requirements for Emergency Context Resolution with Internet Technologies, draft-ietf-ecritrequirements
Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses
Configuration Information, RFC 4776
Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration
Information, RFC 3825
A Presence-based GEOPRIV Location Object Format, RFC 4119
A Uniform Resource Name (URN) for Services, draft-ietf-ecrit-service-urn
LoST: A Location-to-Service Translation Protocol, draft-ietf-ecrit-lost
Best current practices for third party call control (3pcc) in the session initiation protocol (SIP), RFC
3725
GETS: http://gets.ncs.gov/
•
LoST server at http://honamsun.cs.columbia.edu/lost_homepage/
•
NG911 project information at http://ng911.tamu.edu and
•
•
•
•
•
•
•
IEEE NY
DOT 911 project
69