Presentation is loading. Please wait.

Presentation is loading. Please wait.

Internet Real-Time Lab, Columbia University Next Generation 9-1-1 Project Jong Yul Kim, Wonsang Song, and Henning Schulzrinne.

Similar presentations


Presentation on theme: "Internet Real-Time Lab, Columbia University Next Generation 9-1-1 Project Jong Yul Kim, Wonsang Song, and Henning Schulzrinne."— Presentation transcript:

1 Internet Real-Time Lab, Columbia University Next Generation 9-1-1 Project Jong Yul Kim, Wonsang Song, and Henning Schulzrinne

2 9/28/20061/ 30 Overview Project Introduction Architecture and implementation References Demo

3 9/28/20062/ 30

4 9/28/20063/ 30

5 9/28/20064/ 30

6 9/28/20065/ 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

7 9/28/20066/ 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

8 9/28/20067/ 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 9/28/20068/ 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

10 9/28/20069/ 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.

11 9/28/200610/ 30 The Big Picture from NENA

12 9/28/200611/ 30 Our Much Simpler Picture

13 9/28/200612/ 30 Phase 1Phase 2Phase 3 Phase 4 Four Phases of Emergency Calls

14 9/28/200613/ 30 phase1 phase2 phase3phase4phase3 phase1 System Components

15 9/28/200614/ 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

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

17 9/28/200616/ 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]

18 9/28/200617/ 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

19 9/28/200618/ 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

20 9/28/200619/ 30 INVITE urn:service:sos SIP/2.0 To: urn:service:sos Call-ID: 763782461@192.168.1.106 Via: SIP/2.0/TCP 192.168.1.106:4064;rport Content-Type: multipart/mixed; boundary From: sip:caller@irt.cs.columbia.edu Contact: CSeq: 1 INVITE Content-Length: 1379 ------ =_ZGY1NTFlZDJkMDkxY2FkMTIxMWI2MzIzNjE1M2U0OTY= MIME-Version: 1.0 content-Type: application/sdp Content-Transfer-Encoding: 8bit v=0 o=eddie 1127764654 1127764654 IN IP4 192.168.1.106 s=SIPC Call c=IN IP4 160.39.54.70 t=0 0 m=audio 10000 RTP/AVP 0 3 m=video 20000 RTP 31 SDP header fields request line ------- =_ZGY1NTFlZDJkMDkxY2FkMTIxMWI2MzIzNjE1M2U0OTY= MIME-Version: 1.0 Content-Type: application/pidf+xml Content-Transfer-Encoding: 8bit <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:calltaker_ny2@irt.cs.columbia.edu"> us ny new york amsterdam 1214 Manual sip:eddie@160.39.54.70:5060 2005-09-26T15:57:34-04:00 ------- =_ZGY1NTFlZDJkMDkxY2FkMTIxMWI2MzIzNjE1M2U0OTY=-- PIDF-LO Location Info inside a SIP message

21 9/28/200620/ 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

22 9/28/200621/ 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)

23 9/28/200622/ 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 plans e.g., [911 -> urn:service:sos]

24 9/28/200623/ 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

25 9/28/200624/ 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 request response LoST (Location-to-Service Translation) recurse urn:service:sos US NY New York Amsterdam 1214 urn:service:sos New York City PSAP sip:psap_ny@irt.cs.columbia.edu US NY New York Amsterdam 1214 911

26 9/28/200625/ 30 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

27 9/28/200626/ 30 Calltaker’s Screen SIPc as SIP User Agent Location Mapping software to display caller’s location –Geolynx –Google Maps

28 9/28/200627/ 30 Web Interface Manage PSAP systems Show call logs, details, incident information and statistics

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

30 9/28/200629/ 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

31 9/28/200630/ 30 Thank you! Please join us for a demo of the prototype system


Download ppt "Internet Real-Time Lab, Columbia University Next Generation 9-1-1 Project Jong Yul Kim, Wonsang Song, and Henning Schulzrinne."

Similar presentations


Ads by Google