internet real-time lab, columbia university next generation 9-1-1 project jong yul kim, wonsang...
Post on 19-Dec-2015
214 views
TRANSCRIPT
Internet Real-Time Lab, Columbia University
Next Generation 9-1-1 Project
Jong Yul Kim, Wonsang Song, and Henning Schulzrinne
9/28/2006
2/ 30
Overview
• Project Introduction
• Architecture and implementation
• References
• Demo
9/28/2006
6/ 30
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
7/ 30
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 http://www.fcc.gov/cgb/consumerfacts/voip911.html
9/28/2006
8/ 30
Three Fundamental Problems
1. Where is the caller?
2. To which PSAP should the call go to?
3. How to identify the emergency call?
Problems 2 and 3 arise from problem 1.
9/28/2006
9/ 30
• 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)
Project Goals
9/28/2006
10/ 30
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
12/ 30
911112
sip:psap@domain2w/location
geo location
POTS/Wireless Network
SIP UA
911
sip:psap@domain2with location
GeoLynx /Google Maps
DHCP Server
civil location
PSAP Info
Location
Mapping Server
geo locationcivil location
psapd
3PCC Controller
IP Gateway
Local SIP Proxy
PSAP
PSAP SIP Proxy
sip:psap@domain2with location
sip:rep@domain2with location
urn:service:sosw/out location
LIS
Location InfoLocation
key
Our Much Simpler Picture
9/28/2006
13/ 30
Phase 1 Phase 2 Phase 3 Phase 4
Determine Location
Present Call to
Calltaker
Route to Correct PSAP
IdentifyEmergencyCalls
Four Phases of Emergency Calls
9/28/2006
14/ 30
911112
sip:psap@domain2w/location
geo location
POTS/Wireless Network
SIP UA
911
sip:psap@domain2with location
GeoLynx /Google Maps
DHCP Server
civil location
PSAP Info
Location
Mapping Server
geo locationcivil location
psapd
3PCC Controller
IP Gateway
Local SIP Proxy
PSAP
PSAP SIP Proxy
sip:psap@domain2with location
sip:rep@domain2with location
urn:service:sosw/out location
LIS
Location InfoLocation
key
phase1
phase2
phase3 phase4phase3
phase1
System Components
9/28/2006
15/ 30
• 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)
Phase1: Determining Location
9/28/2006
16/ 30
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
17/ 30
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
18/ 30
LLDP-MED for Location
• Mainly for stationary and nomadic users• Link Layer Discovery Protocol – Media Endpoint Discovery(Layer2)• Switch broadcasts location data periodically.• A Switch covers a floor, a port leads to a jack in a room
-> room-level accuracy
Segment from switch 2/port 5
Switch 2
Path of CDP advertisement
SIP UA
InvokecdpCap
cdpCap listens to advertisements
Send switch/port information
Physical location
Switch/port
Location DB
9/28/2006
19/ 30
SkyHook for Location
Taken from http://www.skyhookwireless.com
• 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
9/28/2006
20/ 30
INVITE urn:service:sos SIP/2.0
To: urn:service:sosCall-ID: [email protected]: SIP/2.0/TCP 192.168.1.106:4064;rportContent-Type: multipart/mixed; boundaryFrom: sip:[email protected]: <sip:[email protected]:5060>CSeq: 1 INVITEContent-Length: 1379
------ =_ZGY1NTFlZDJkMDkxY2FkMTIxMWI2MzIzNjE1M2U0OTY=MIME-Version: 1.0content-Type: application/sdpContent-Transfer-Encoding: 8bit
v=0o=eddie 1127764654 1127764654 IN IP4 192.168.1.106s=SIPC Callc=IN IP4 160.39.54.70t=0 0m=audio 10000 RTP/AVP 0 3m=video 20000 RTP 31
SDP
header fields
request line ------- =_ZGY1NTFlZDJkMDkxY2FkMTIxMWI2MzIzNjE1M2U0OTY=MIME-Version: 1.0Content-Type: application/pidf+xmlContent-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:[email protected]"> <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:[email protected]:5060</contact> <timestamp>2005-09-26T15:57:34-04:00</timestamp> </tuple></presence>------- =_ZGY1NTFlZDJkMDkxY2FkMTIxMWI2MzIzNjE1M2U0OTY=--
PIDF-LO
Location Info inside a SIP message
9/28/2006
21/ 30
• 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
Phase2: Identifying SOS
9/28/2006
22/ 30
• 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
Phase2: Identifying SOS (cont’d)
9/28/2006
23/ 30
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 planse.g., [911 -> urn:service:sos]
9/28/2006
24/ 30
• 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)
Phase3: Routing to Correct PSAP
9/28/2006
25/ 30
• 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
LoST Server
req
ues
tresp
on
se
LoST (Location-to-Service Translation)
<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>
<mapping> <response expires="2006-03-09T01:53:33.396Z"> <service>urn:service:sos</service> <displayName>New York City PSAP</displayName> <uri>sip:[email protected]</uri> <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>
9/28/2006
26/ 30
Call Taker 1
Call Taker 2
Call Taker n
Hospital Police Fire
Controller (psapd)
Policy
Conference Mixer
select available call taker
(2) create conference
(3) INVITE to conference
(4)
(5) join conference
INVITE to conference
(7)
join conference
(8)
(1) psap@domain w/location
(6)
REFER police to conference
Phase4: Call Presentation in PSAP
9/28/2006
27/ 30
Calltaker’s Screen
• SIPc as SIP User Agent• Location Mapping software to display caller’s location
– Geolynx
– Google Maps
9/28/2006
28/ 30
Web Interface
• Manage PSAP systems• Show call logs, details, incident information
and statistics
9/28/2006
29/ 30
LoST Server
SIP proxy call takerSOS caller
(1) Location
Location + Service Identifier
(2)
PSAP URL + emergency dial-string
(3)
INVITE PSAP URLTo: urn:service:sos
<Location>
(5)INVITE PSAP URLTo: urn:service:sos
<Location>
(6)(4)
dial emergency dial-string
or
push emergency button
All Together Now
9/28/2006
30/ 30
• Related Websites– ng911.tamu.edu– www.nena.org– www.ietf-ecrit.org
• 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
References