Next generation emergency calling ng911
Download
1 / 66

Next-Generation Emergency Calling (NG911) - PowerPoint PPT Presentation


  • 267 Views
  • Updated On :

Next-Generation Emergency Calling (NG911). Henning Schulzrinne Dept. of Computer Science, Columbia University, New York hgs@cs.columbia.edu

Related searches for Next-Generation Emergency Calling (NG911)

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Next-Generation Emergency Calling (NG911)' - chidi


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Next generation emergency calling ng911 l.jpg

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 l.jpg
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


Modes of emergency communications l.jpg
Modes of emergency communications

emergency call

information

“I-am-alive”

dispatch

emergency alert

(“inverse 911”)

civic coordination


Outline4 l.jpg
Outline

  • Emergency calling

    • the challenge of two transitions

      • mobility and VoIP

  • Emergency alerts

  • Emergency coordination


Background on 9 1 1 l.jpg
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)

http://www.nena.org/


Slide6 l.jpg

Local Switch

Automatic

Number

Identification

Automatic

Location

Identification

Collaboration between

local phone providers and

local public safety agencies


911 technology failures l.jpg
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 Mathews-Tiger 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


911 technology failures cont d l.jpg
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


911 technology failures cont d9 l.jpg
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


911 problems l.jpg
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


Dept of transportation view l.jpg
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


Voip emergency communications l.jpg
VoIP emergency communications

now

transition

all IP (“NG911”)

Contact well-known number or identifier

112

911

112

911

112, 911

urn:service:sos

dispatch

Route call to location-appropriate PSAP

LoST

SR

VPC

Deliver precise location to call taker to dispatch emergency help

phone number  location

(ALI lookup)

in-band  key  location

in-band (SIP)


Why is this a hard problem l.jpg
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)



More than pain l.jpg
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)


Four phases of emergency calls l.jpg
Four Phases of Emergency Calls

Phase 4

Phase 1

Phase 2

Phase 3


Ietf ecrit working group l.jpg
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


Emergency numbers l.jpg
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)

Emergency number


Service urn l.jpg
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 General emergency services

    sos.animal-control Animal control

    sos.fire Fire service

    sos.gas Gas leaks and gas emergencies

    sos.marine Maritime search and rescue

    sos.mountain Mountain rescue

    sos.physician Physician referral service

    sos.poison Poison control center

    sos.police Police, law enforcement



Services under discussion l.jpg
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


Location location location l.jpg
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


Locating caller using lldp med l.jpg
Locating Caller using LLDP-MED

LLDP-MED stands for: *

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“

* From Wikipedia

“I am LLDP-MED Capable.

I can process location information.”

“Your location is:

500 W 120TH st. New York NY 10027”


Dhcp for location l.jpg

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]

DHCP Server

DHCP for Location

  • Use MAC address to get location information

  • Mainly for stationary users

  • We modified ISC’s dhcpd


Dhcp elements administrative subdivisions l.jpg
DHCP elements: Administrative Subdivisions

support multiple character sets for each


Skyhook for location l.jpg
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



Components of ng911 system l.jpg
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, …)

PSAP

PSAP

Internet


Ua recognition ua resolution l.jpg
UA recognition & UA resolution

location information

mapping

mapping may recurse

DHCP

LLDP-MED

9-1-1

(dial string)

leonianj.gov

INVITE urn:service:sos

To: urn:service:sos

Route: sip:fire@leonianj.gov

<location>

INVITE urn:service:sos

To: urn:service:sos

Route: sip:psap@leonianj.gov

<location>

identification TBD


Lost a protocol for mapping geographic locations to public safety answering points l.jpg

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 l.jpg
Problem: Finding the correct PSAP Safety Answering Points

  • 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


Lost functionality l.jpg
LoST functionality Safety Answering Points

  • 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, ...)


Lost location to url mapping l.jpg
LoST: Location-to-URL Mapping Safety Answering Points

VSP1

cluster serving VSP1

replicate

root information

cluster

serves VSP2

123 Broad Ave

Leonia

Bergen County

NJ US

LoST

root

nodes

NJ

US

NY

US

sip:psap@leonianj.gov

search

referral

Bergen County

NJ US

Leonia

NJ US


Lost architecture l.jpg
LoST Architecture Safety Answering Points

G

tree guide

G

G

G

broadcast (gossip)

T1: .us

T2: .de

G

resolver

T2

(.de)

seeker

313 Westview

Leonia, NJ US

T3

(.dk)

T1

(.us)

Leonia, NJ  sip:psap@leonianj.gov


Lost properties l.jpg
LoST Properties Safety Answering Points

  • 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


Lost query example l.jpg
LoST: Query example Safety Answering Points

  • 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>


Lost find service response warning example l.jpg
LoST “Find Service” response/warning example Safety Answering Points

<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>


Validation l.jpg
Validation Safety Answering Points

  • 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>


Geo support l.jpg
Geo support Safety Answering Points

  • 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


Advanced lost functionality l.jpg
Advanced LoST functionality Safety Answering Points

  • Get list of (emergency) services supported

    • by server

    • for a region

  • Obtain service regions

    • identified by globally-unique tag

<listServicesByLocationResponse>

<serviceList>

urn:service:sos.ambulance

urn:service:sos.animal-control

</serviceList>

<path>

<via source="auth.example"/>

<via source="res.example"/>

</path>

</listServicesByLocationResponse>

<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>


Server synchronization l.jpg
Server synchronization Safety Answering Points

  • 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>


Performance of cu lost server l.jpg
Performance of CU LoST server Safety Answering Points

roughly 170 req/sec

--> ~17M / day

dual-core P4/3.0 GHz

Linux 2.6.19

Postgresql 8.1.4

Tomcat 4.1


Sip message for location info l.jpg
SIP message for Location Info. Safety Answering Points

------- =_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=--

INVITE urn:service:sos SIP/2.0

request line

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

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

PIDF-LO


Nena i3 architecture l.jpg
NENA i3 architecture Safety Answering Points


Nena i3 architecture45 l.jpg
NENA i3 architecture Safety Answering Points


Current activities l.jpg
Current activities Safety Answering Points

  • 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-1-1 implementation”

  • Lots of other activities

    • e.g., semi-annual Emergency Services Coordination Workshop


Ng9 1 1 prototype architecture l.jpg

Location Safety Answering Points

Routing

PSTN

NG9-1-1 Prototype Architecture


Emergency call flow l.jpg

(2) Safety Answering Points

Location + Service Identifier

(3)

PSAP URL + emergencydial-string

(1)

Location

INVITE call taker

From: caller

<Location>

(7)

INVITE PSAP URL

To: urn:service:sos

<Location>

(5)

(4)

INVITE PSAP URL

To: urn:service:sos

<Location>

(6)

dial emergency dial-string

or

push emergency button

Media Stream

Media Stream

Emergency Call Flow

LoSTCluster

SOS caller

SIP proxy

call taker


Calltaker screen l.jpg
Calltaker screen Safety Answering Points

  • Columbia SIPc as SIP UA

  • Mapping software to display caller’s location

    • Geolynx

    • Google Maps


Call logs and recorded sessions l.jpg
Call logs and recorded sessions Safety Answering Points


Ng911 trial lessons learned l.jpg
NG911 trial: Lessons learned Safety Answering Points

  • 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


Challenges for ng911 l.jpg
Challenges for NG911 Safety Answering Points

  • 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?


Outline53 l.jpg
Outline Safety Answering Points

  • Emergency calling

  • Emergency alerts

    • multi-modal alerting

    • beyond siren replacement

  • Emergency coordination


Emergency alerting l.jpg
Emergency alerting Safety Answering Points

  • “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)


Alerting l.jpg
Alerting Safety Answering Points

  • 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)


Cap 1 1 example l.jpg
CAP 1.1 example Safety Answering Points

<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>


New alerting architecture l.jpg
New alerting architecture Safety Answering Points

national

authority

national

authority

SUBSCRIBE

Event: chemical

Area: NJ

state or local

authority

SUB/NOT

SMS, IM, voice

automated actions

(sirens, vents, ...)

email


Outline58 l.jpg
Outline Safety Answering Points

  • Emergency calling

  • Emergency alerts

  • Emergency coordination


General requirements l.jpg
General requirements Safety Answering Points

  • Low cost

    • may only be used very rarely

  • Ease of use

    • 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

      • example: FEMA application crash

    • outdoor & hostile environment

      • 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

    • nobody wants to learn a new tool during a hurricane


Emergency coordination l.jpg
Emergency coordination Safety Answering Points

  • 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)


Authentication and security l.jpg

0123 4567 8910 Safety Answering Points

Disaster Response Team #1

US CITY EOC

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?


Example sahana l.jpg
Example: Sahana Safety Answering Points

  • Developed in 2004 after tsunami (in three weeks)

  • Open source (PHP, mySQL)

  • Component-based

    • organization and people registry

    • inventory management

    • situation mapping

    • synchronization

  • allows for disconnected operation

    • XML synchronization

© ACM CACM 2007 50(3)


Peer to peer sip l.jpg
Peer-to-peer SIP Safety Answering Points

generic DHT service

  • Why?

    • no infrastructure available: emergency coordination

    • don’t want to set up infrastructure: small companies

    • Skype envy :-)

  • P2P technology for

    • user location

      • only modest impact on expenses

      • but makes signaling encryption cheap

    • NAT traversal

      • matters for relaying

    • services (conferencing, …)

      • how prevalent?

  • New IETF working group just formed

    • likely, multiple DHTs

    • common control and look-up protocol?

p2p network

P2P provider B

DNS

P2P provider A

traditional provider

zeroconf

LAN


P2p sip components l.jpg
P2P SIP -- components Safety Answering Points

  • 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


Conclusion l.jpg
Conclusion Safety Answering Points

  • 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


More information l.jpg
More information Safety Answering Points

  • A VoIP Emergency Services Architecture and Prototype

    • M. Mintz-Habib, A. Rawat, H. Schulzrinne, and X. Wu, ICCCN 2005, Oct. 2005

  • An Enhanced VoIP Emergency Services Prototype

    • 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-ecrit-requirements

  • 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 DOT 911 project