1. Next Generation 9-1-1 Project
Jong Yul Kim, Wonsang Song,
and Henning Schulzrinne

2. Overview Project Introduction Architecture and implementation
References
Demo
9/28/2006

3. Growth of VoIP Subscribers
Global Subscribers
16 million in 2005
62% year-over-year subscriber growth rate in 2005
55 million by 2009
Numbers from instat.com
Released on Jan. 31, 2006
9/28/2006

4. But there were problems…
VoIP service did not connect to 911;
VoIP service rang to the administrative line of the public safety answering point (PSAP), which is not often staffed after hours, and is usually not staffed by trained 911 operators;
VoIP service rang to the correct line of the PSAP, but did not automatically include the consumer’s phone number and/or location information.
Consumer must provide certain information (such as location information) in order for the VoIP provider to set up 911 service, but failed to do so
Consumer moved VoIP service to another location (the phone number can be used anywhere the customer has a broadband connection) but the VoIP service did not reflect the new address;
VoIP service did not work during a power outage;
VoIP service did not work when the broadband connection (cable modem or DSL) went down or was congested.
Taken from
9/28/2006

5. Three Fundamental Problems
Where is the caller?
To which PSAP should the call go to?
How to identify the emergency call?
Problems 2 and 3 arise from problem 1.
9/28/2006

6. Project Goals
Develop a prototype system that routes emergency calls over SIP based VoIP networks.
Implement requirements for IP-based PSAP
Provide opportunities to enhance 911 system:
Multimedia (audio, video, text)
Data delivery (floor plan, medical information)
Delivering video (CPR how-to)
Load balancing and redundancy
Location delivery (location with forwarded, transferred calls)
9/28/2006

7. A Collaborative Effort
Funding
U.S. Department of Commerce
National Telecommunications and Information Administration (NTIA)
Requirements
National Emergency Number Association (NENA)
Software Development
Columbia University
Deployment and Testing
Texas A&M University
Standardization
IETF ECRIT, GEOPRIV WG
Contributions
States of Texas and Virginia 911 offices
Corporations like Cisco, Nortel, MapInfo, etc.
9/28/2006

8. The Big Picture from NENA
9/28/2006

9. Our Much Simpler Picture 
Simpler because we’re focusing on 1) IP environments including IP-based PSAPs, and 2) the three fundamental problems in a working prototype.
9/28/2006

10. Four Phases of Emergency Calls
9/28/2006

11. System Components
phase1
phase1
phase2
phase3
phase3
phase4
9/28/2006

12. Phase1: Determining Location
Purpose
To get emergency dial strings (Phase2)
To resolve the correct PSAP URL (Phase3)
To present the caller’s location on the call taker’s screen using mapping software (Phase4)
9/28/2006

13. Phase1: Determining Location (cont’d)
Problem
User can be stationary, nomadic or mobile
Solution
Apply different methods for different situations
DHCP, CDP (LLDP-MED), SkyHook (Wireless AP Location Database), GPS, and Manual Entry
The result is either civic address or geospatial coordinates.
Location will be included in the body of the INVITE request as PIDF-LO object.
9/28/2006

14. DHCP for Location Mainly for stationary users
We modified ISC’s dhcpd to generate location information
Use MAC address to get location information
DHCP Server or
request
response
DHCPINFORM
[MAC=00:11:20:9d:a0:03]
DHCPACK
[option=0:US:1:NY:2:NEW YORK:
3:NEW YORK:6:AMSTERDAM:19:1214]
9/28/2006

15. CDP for Location Mainly for stationary and nomadic users
Cisco Discovery Protocol (Layer2)
Cisco switches broadcast switch/port ID periodically.
A Switch covers a floor, a port leads to a jack in a room
-> room-level accuracy
9/28/2006

16. 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
9/28/2006

17. Location Info inside a SIP message
=_ZGY1NTFlZDJkMDkxY2FkMTIxMWI2MzIzNjE1M2U0OTY=
MIME-Version: 1.0
Content-Type: application/pidf+xml
Content-Transfer-Encoding: 8bit
<?xml version="1.0" encoding="ISO "?>
<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"
<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
<timestamp> T15:57:34-04:00</timestamp>
</tuple>
</presence>
=_ZGY1NTFlZDJkMDkxY2FkMTIxMWI2MzIzNjE1M2U0OTY=--
INVITE urn:service:sos SIP/2.0
request line
To: urn:service:sos
Call-ID:
Via: SIP/2.0/TCP :4064;rport
Content-Type: multipart/mixed; boundary
From:
Contact:
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 IN IP
s=SIPC Call
c=IN IP
t=0 0
m=audio RTP/AVP 0 3
m=video RTP 31
SDP
PIDF-LO
9/28/2006

18. Phase2: Identifying SOS
Purpose
For UA : To send caller’s location information
For Proxies: To handle the emergency call specially
Problem
Different emergency dial strings
different in countries (e.g., 911 for North America, 112 for Europe)
some countries uses separate numbers for ambulance/police/fire
Required to support both home and visited emergency dial strings
e.g., for an American traveler who is visiting Europe, both 911 and 112 should be recognized as emergency
9/28/2006

19. Phase2: Identifying SOS (cont’d)
Use Emergency Services URN (instead of emergency numbers)
Service URN identifies a generic service, not a specific resource
Examples of emergency services URN:
urn:service:sos
urn:service:sos.ambulance
urn:service:sos.fire
urn:service:sos.police
Can be used in request URI and To header.
Will be resolved into PSAP URL in phase 3
9/28/2006

20. Phase2: Identifying SOS (cont’d)
What if a user dials an emergency number?
User can set his/her home country through configuration.
In initial time, UA gets the home emergency dial strings using mapping protocols.
Whenever current location is changed, UA gets the visited emergency dial strings using mapping protocols.
UA keeps all emergency dial strings in the local dial plans
e.g., [911 -> urn:service:sos]
9/28/2006

21. Phase3: Routing to Correct PSAP
Which PSAP should the call go to?
Usually to the PSAP that covers the area
Sometimes to a backup PSAP
If no location, then ‘default’ PSAP
PSAP determination
mapping problem:
Work in progress for standardization of LoST
( LoST = A Location-to-Service Translation Protocol )
Caller’s location
Service identifier
(urn:service:sos) +
Service provider
(PSAP URL)
9/28/2006

22. LoST (Location-to-Service Translation)
Translates a service identifier and location information to {PSAP URL & emergency dial-string}
Supports both civic and geo location information
Uses web service (SOAP base) as underlying protocol
<mapping>
<response expires=" T01:53:33.396Z">
<service>urn:service:sos</service>
<displayName>New York City PSAP</displayName>
<civicMatch>
<gp:location-info>
<cl:civicAddress>
<cl:country>US</cl:country>
<cl:A1>NY</cl:A1>
<cl:A3>New York</cl:A3>
<cl:A6>Amsterdam</cl:A6>
<cl:HNO>1214</cl:HNO>
</cl:civicAddress>
</gp:location-info>
</civicMatch>
<dialstring>911</dialstring>
</response>
</mapping>
<mapping>
<request>
<operation>recurse</operation>
<service>urn:service:sos</service>
<gp:location-info>
<cl:civicAddress>
<cl:country>US</cl:country>
<cl:A1>NY</cl:A1>
<cl:A3>New York</cl:A3>
<cl:A6>Amsterdam</cl:A6>
<cl:HNO>1214</cl:HNO>
</cl:civicAddress>
</gp:location-info>
</request>
</mapping>
request
response
9/28/2006
LoST Server

23. Phase4: Call Presentation in PSAP
join conference
(8)
INVITE to conference
(7)
(5)
join conference
INVITE to conference
(4)
create conference
(3)
(6)
REFER police to conference
select available call taker
(2)
(1)
w/location
9/28/2006

24. Calltaker’s Screen SIPc as SIP User Agent
Location Mapping software to display caller’s location
Geolynx
Google Maps
9/28/2006

25. Web Interface Manage PSAP systems
Show call logs, details, incident information and statistics
9/28/2006

26. All Together Now 9/28/2006 LoST Server INVITE PSAP URL INVITE PSAP URL
Location + Service Identifier
(2)
PSAP URL + emergency dial-string
(3)
(1)
Location
LoST Server
(4)
dial emergency dial-string or
push emergency button
INVITE PSAP URL
To: urn:service:sos
<Location>
(5)
INVITE PSAP URL
To: urn:service:sos
<Location>
(6)
SOS caller
SIP proxy
call taker
9/28/2006

27. References Related Websites Standards and Internet Drafts
ng911.tamu.edu
Standards and Internet Drafts
SIP: Session initiation protocol, RFC 3261
Requirements for Emergency Context Resolution with Internet Technologies, draft-ietf-ecrit-requirements-04
Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information, draft-ietf-geopriv-dhcp-civil-07
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-01
LoST: A Location-to-Service Translation Protocol, draft-hardie-ecrit-lost-00
Best current practices for third party call control (3pcc) in the session initiation protocol (SIP), RFC 3725
9/28/2006

28. Thank you!
Please join us for a demo
of the prototype system
9/28/2006