VoIP/NG E9-1-1 IP-based E9-1-1 Migratory

1
VoIP/NG E9-1-1 IP-based E9-1-1 Migratory Long
Term Solutions A Trial/Demo Update
2

• Purpose of Project
• Conduct research in support of NENAs Next
  Generation E9-1-1 initiative
• Conduct that research without endangering public
  safety
• Share the results of that research with the
  public safety community

3

• 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

4

• 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

5

• Project Description (continued)
• Explore lower cost off-the-shelf call taking
  equipment in Public Safety Answering Points,
• Validate many of NENAs 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

6

• 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

7

• Project Overview
• Columbia University
• Dr. Henning Shulzrinne
• Internet Real-Time (IRT) labs
• Developed prototype
• Continue development work
• Participate in testing
• Draft RFCs

8

• 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

9

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

10

• 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

11

• 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

12

• 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

13

• 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

14

• Next steps
• Refine PSAP equipment configuration
• Adding features and functionality
• Improve reliability and diversity
• Develop method for location validation
• Address nomadic users

15

• Lessons Learned
• VoIP can provide a strong foundation for PSAP
  call processing
• PSAP equipment can be based on non-proprietary
  VoIP equipment
• General location for routing can typically be
  determined by DNS

16
Components of emergency calling
now
transition
all IP
dial 112, 911 signal sos_at_
Contact well-known number or identifier
112 911
112 911
Route call to location-appropriate PSAP
selective router
VPC
DNS
phone number ? location (ALI lookup)
Deliver precise location to call taker to
dispatch emergency help
in-band
in-band ? key ? location
17
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 ( 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
18
The core problem
VSP sees emergency call but does not know caller
location
ISP/IAP knows user location but does not handle
call
19
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)

20
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 cross-jurisdictional 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

21
Three stages to VoIP 911
spec. available? use 10-digit admin. number? mobility callback number to PSAP? caller location to PSAP? PSAP modification 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 in-band GNP multimedia international calls
22
I3 Location-based call routing UA knows its
location
GPS
INVITE sipssos_at_
48 49' N 2 29' E
outbound proxy server
DHCP
48 49' N 2 29' E ? Paris fire department
23
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 doesnt have
  wire database information
• VSP needs assistance from access provider (DSL,
  cable, WiMax, 802.11, )

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

25
DHCP for locations

• modified dhcpd (ISC) to generate location
  information
• use MAC address backtracing to get location
  information

8020abd5d
DHCP server
CDP SNMP 8020abd5d ? 458/17
DHCP answer staDC locRm815 lat38.89868
long77.03723
458/17 ? Rm. 815 458/18 ? Rm. 816
26
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

27
Call routing
28
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
29
Call taker setup
SIPc client receives calls
GeoLynx software displays caller location
30
GeoLynx displays location
GeoLynx listens for commands from SIPc
31
Emergency call conferencing
PSAP brings all related parties into a
conference call
Hospital
Fire department
INVITE
Conference server
Recorder
3rd party call control
PSAP
Caller
32
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

33
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

34
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