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

3. Assumptions
Existing circuit switched 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 NENA’s requirements for the IP-enabled Public Safety Answering Point of the future,
Transfer knowledge to 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 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 RFC’s

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 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. Refine PSAP equipment configuration
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
Contact well-known number or identifier
dial 112,
911 signal
112
911
112
911
Route call to location-appropriate PSAP
selective
router
VPC
DNS
Deliver precise location to call taker to dispatch emergency help
phone number  location
(ALI lookup)
in-band  key  location
in-band

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
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 Data delivery
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 I1 I2 I3 spec. available?
use 10-digit admin. number?
mobility
callback
number to PSAP?
caller
location to PSAP?
PSAP
modification
ALI (DB)
new services I1
now
allowed
stationary no
none I2
June 2005
nomadic
yes
no (8 or 10 digit)
update I3
2005
mobile
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
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 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, , …)

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
8:0:20:ab:d5:d
DHCP
server
CDP + SNMP
8:0:20:ab:d5:d  458/17
DHCP answer:
sta=DC loc=Rm815
lat= long=
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
REFER
INVITE
Conference
server
REFER
INVITE
INVITE
media
info
Recorder
INVITE
3rd party
call control
REFER
INVITE
media
info
PSAP
Caller

32. Scaling
NENA: “estimated 200 million calls to 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