Transcript End to End IP-Enabled Emergency Calling Proof

VoIP/NG E9-1-1 IP-based
E9-1-1 Migratory & Long Term
Solutions – A Trial/Demo
Update
Purpose of Project
• Conduct research in support of NENA’s
Next Generation E9-1-1 initiative
• Conduct that research without
endangering public safety
• Share the results of that research with
the public safety community
Assumptions
• Existing circuit switched 9-1-1 network
will be replaced with a new network (NG
E9-1-1)
• PSAPs will have to be capable of
handling calls via packet switched links
• Independent research can help us to get
ready
Project Description
• Extend prototype architecture into a campus
environment and working PSAPs
• Conduct tests of IP enabled emergency
calling
• Explore nomadic location services
• Conduct long distance PSAP to PSAP
transfers
• Prove the value to public safety community of
multimedia information data transfer
Project Description (continued)
• Explore lower cost off-the-shelf call taking
equipment in Public Safety Answering Points,
• Validate many of NENA’s requirements for the
IP-enabled Public Safety Answering Point of
the future,
• Transfer knowledge to 9-1-1 community via
presentations and workshops
• Total project value - $1.5 million
Partners
• Columbia University, Texas A & M University,
and University of Virginia
• Internet2
• Texas and Virginia PSAPs
• NENA
• Texas and Virginia state 9-1-1 agencies
• Cisco and Nortel
• NTIA - grant funding
Project Overview
Columbia University
Dr. Henning Shulzrinne
• Internet Real-Time (IRT) labs
•
•
•
•
Developed prototype
Continue development work
Participate in testing
Draft RFC’s
Project Overview (continued)
Texas A & M University
Dr. Walt Magnussen
• Internet2 Technology Evaluation Center (ITEC)
• Additional development
• Coordinate field testing
• Facilitate workshops and project demonstrations
• Center for Distance Learning Research (CDLR)
• Independent, outside evaluation of the project
Project Overview (continued)
University of Virginia
• Coordinate testing of the remote PSAP
routing capabilities
Internet2 Consortium
• Coordinate efforts of this project with other
Internet2 projects
• Disseminate information to other Internet2
members.
Project Overview (continued)
PSAPs
• Brazos County Emergency Communication District
• City of College Station, Texas
• Charlottesville, Albemarle, UVA Emergency
Communications Center
• Call takers will participate in testing and
provide feedback for the evaluation portion of
the project
Project Overview (continued)
NENA
• Coordinate user requirements in the development
of the project
• Coordinate information dissemination to the user
community through white papers, workshops and
seminars
Texas and Virginia 9-1-1 Agencies
• Funding Support
• Information Dissemination
Project Overview (continued)
Cisco
• Provide hardware and software
• Provide access to one of their E-911 gateway
solutions
• Provide access to source code to Cisco equipment
and applications
Nortel Inc.
• Provide a SIP based switching platform
• Provide wireless system with the ability to provide
location information about the Access Point being
utilized for the connection
Progress to Date
•
•
•
•
Initial Formation of Project Team
Acquired NTIA matching grant funding
Development of network architecture
Establishment of lab environment at
Columbia University
• Creation of preliminary PSAP call handling
equipment to receive native VoIP
• Demonstration of call processing at the
National Press Club on May 26, 2005
Next steps
• Refine PSAP equipment configuration
• Adding features and functionality
• Improve reliability and diversity
• Develop method for location validation
• Address nomadic users
Lessons Learned
• VoIP can provide a strong foundation for
PSAP call processing
• PSAP equipment can be based on nonproprietary VoIP equipment
• General location for routing can typically
be determined by DNS
Components of emergency calling
now
Contact well-known
number or identifier
Route call to
location-appropriate
PSAP
Deliver precise location
to call taker to dispatch
emergency help
transition
all IP
112
911
dial 112,
911 signal
sos@
selective
router
VPC
DNS
phone
number 
location
(ALI lookup)
in-band 
key 
location
in-band
112
911
What makes VoIP 112/911 hard?
POTS
PSTN-emulation VoIP
end-to-end VoIP
(landline) phone number
limited to limited area
landline phone number
anywhere in US (cf. German
180)
no phone number or phone
number anywhere around
the world
regional carrier
national or continent-wide
carrier
enterprise “carrier” or
anybody with a peer-to-peer
device
voice provider = line provider voice provider ≠ ISP
(~ business relationship)
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
The core problem
VSP sees emergency call
but does not know caller location
ISP/IAP knows user location
but does not handle call
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)
Core long-term requirements
Media-neutral
•
voice (+TDD) first, IM and video later
Work in systems without a voice service provider
•
many enterprises will provide their own local voice services
Allow down-stream call data access
•
as well as access to other “tertiary” data about the incident
Globally deployable
•
•
•
independent of national emergency number (9-1-1, 1-1-2, etc.)
respect jurisdictional boundaries – minimize need for crossjurisdictional coordination
allow usage even if equipment and service providers are not local
• travel, imported equipment, far-flung locations
Testable:
•
•
verifiable civic addresses (“MSAG validation”)
call route validation
Secure and reliable
Three stages to VoIP 911
spec.
available?
use 10digit
admin.
number?
mobility
callback
number
to
PSAP?
caller
location
to
PSAP?
PSAP
modificatio
n
ALI (DB)
modification
new services
I1
now
allowed
stationary
no
no
no
no
none
I2
June
2005
no
stationary
nomadic
yes
yes
no (8 or 10
digit)
update
none
I3
2005
no
stationary
nomadic
mobile
yes
yes
IP-enabled
ALI not
needed
MSAG
replaced by
DNS
location inband
GNP
multimedia
international
calls
I3: Location-based call routing –
UA knows its location
GPS
INVITE sips:sos@
48° 49' N 2° 29' E
outbound
proxy server
DHCP
48° 49' N 2° 29' E  Paris fire department
Location, location, location
Location  locate right PSAP & speed dispatch
In the PSTN, local 9-1-1 calls remain geographically
local
In VoIP, no such locality for VSPs
•
most VSPs have close to national coverage
Thus, unlike landline and wireless, need location
information from the very beginning
Unlike PSTN, voice service provider doesn’t have wire
database information
•
VSP needs assistance from access provider (DSL, cable,
WiMax, 802.11, …)
Options for location delivery
L2: LLDP-MED (standardized version of CDP
+ location data)
• periodic per-port broadcast of configuration
information
L3: DHCP for
• geospatial (RFC 3825)
• civic (draft-ietf-geopriv-dhcp-civil)
L7: proposals for retrievals
• by IP address
• by MAC address
• by identifier (conveyed by DHCP or PPP)
DHCP for locations
modified dhcpd (ISC) to generate location information
use MAC address backtracing to get location information
8:0:20:ab:d5:d
DHCP
server
CDP + SNMP
8:0:20:ab:d5:d  458/17
458/17  Rm. 815
458/18  Rm. 816
DHCP answer:
sta=DC loc=Rm815
lat=38.89868 long=77.03723
NG-911 prototype
Goal: build prototype VoIP SIP-based
emergency calling system
• including caller end system
• call routing (DNS)
• PSAP infrastructure
Use commodity components where possible
Test reliability and redundancy
Call routing
DHCP Server
DHCP Inform
MAC Address
DNS Server
DNS Query
civil location
Envinsa Server
TCP Socket
Telephone Number
PSAP
Info
Location
Info
ALI Server
HTTP SOAP
geo location
Location
Info
PSAP
Info
PSAP
civil location
geo location
sip:sos@domain1
w/location or
w/out location
911
112
sip:psap@domain2
with location
sip:psap@domain1
without location
IP Network
Local SIP Proxy
PSAP SIP Proxy
civil location
geo location
sip:psap@domain2
with location
sip:rep@domain2
with location
911
POTS/Wireless
Network
IP Gateway
3PCC Controller
GeoLynx
Display
Components
sipd
SIP proxy server
database-backed DNS server
SIP phone
web server
SQL database for call routing
sipc
SIP user agent
geo-coding, PSAP boundaries
GIS software for call location plotting
No endorsement implied – other components likely will work as well
Call taker setup
SIPc client receives calls
GeoLynx software displays
caller location
GeoLynx displays location
GeoLynx listens for commands from SIPc
Emergency call conferencing
PSAP brings all related
parties into a conference call
Hospital
Fire
department
INVITE
INVITE
Conference
server
Recorder
3rd party
call control
media
INVITE info
REFER
INVITE
INVITE
REFER
REFER
INVITE
media
info
Caller
PSAP
Scaling
NENA: “estimated 200 million calls to 9-1-1 in
the U.S. each year”
 approximately 6.3 calls/second
• if 3 minute call, about 1,200 concurrent calls
typical SIP proxy server (e.g., sipd) on 1 GHz
PC can handle about 400 call arrivals/second
thus, unlikely to be server-bound
Current standardization efforts
NENA (National Emergency Number Association)
• I2 and I3 architecture
• requirements based on operational needs of PSAPs
ETSI OCG – EMTEL
• exploratory – also emergency notification
NRIC
• goals and long-term architecture
IETF:
• individual and SIPPING drafts for identifier, call routing,
architecture
• SIP and DNS usage
• possibly new protocols for lookups
• ECRIT WG for mapping part just getting started
Conclusion
Emergency calling services necessary
condition for first-line wireline-replacement
services
US: large numbers of PSAPs financially
exhausted from Phase II wireless support
• often 1970s technology – end of bailing wire
reached
Long-term opportunity for better services