NENA Next Generation Architecture

Slides:



Advertisements
Similar presentations
Building Information Services and Control System (BISACS), a Framework For a Safer Tomorrow Alan Vinh Building Environment Division Building and Fire Research.
Advertisements

1 Number Portability Administration Center Change Orders NANC 399 & NANC 400 NANC Meeting March 15, 2005 Tom McGarry NeuStar, Inc.
Saif Bin Ghelaita Director of Technologies & Standards TRA UAE
Emergency Services Chitra S VOIP Security Fall 2008.
The current System Landline caller The emergency call process starts with a caller dialing (highly simplified) © 2011 Colorado Resource.
NG9-1-1 Call handling using PC 3 (Persistent Contextual Collaborative Conferencing) Mark J. Fletcher, ENP Product Line Manager – Public Safety Solutions.
Telecommunication Relay Service (TRS) Emergency Call Handling Federal Communications Commission Emergency Access Advisory Committee January 14, 2011.
Preparing for the Future.  Emergency calls today are primarily voice.  People expect to reach PSAP when dials 911.  People have multiple ways and devices.
NENA 2008 Breakout Session Template
Brian Rosen Chair, Long Term Definition WG.  i1 = document older strategies for VoIP into  i2 = standard way to support VoIP on current E9-1-1.
What’s Next for i3? Dan Mongrain, Senior Solutions Consultant Bell Canada Terry Reese NENA NG9-1-1 Architecture Evolution Subcommittee Chair Senior Consultant,
H. 323 Chapter 4.
Voice over IP Fundamentals
IP Communications Services Redefining Communications Teresa Hastings Director WorldCom SIP Services Conference – April 18-20, 2001.
What Makes It Work? A Panel Discussion on Next Generation 9-1-1
Internet Real-Time Lab, Columbia University NG9-1-1 Prototype Demo Jong Yul Kim, Wonsang Song, and Henning Schulzrinne.
August 2005IETF 63 VOIPEER1 Issues in Numbering, Naming and Addressing voipeer BoF IETF 63 – Paris, August 2005 Richard Stastny ÖFEG.
Emergency Services IAB Tech Chat 28 th February 2007 Hannes Tschofenig.
Internet Real-Time Lab, Columbia University Next Generation Project Jong Yul Kim, Wonsang Song, and Henning Schulzrinne.
IETF 61 (November 2004) ECRIT1 Requirements and Architecture for Emergency Calling draft-schulzrinne-sipping-emergency-arch draft-schulzrinne-sipping-emergency-req.
Internet Real-Time Lab, Columbia University Emergency Calling for VoIP Wonsang Song, Jong Yul Kim, and Henning Schulzrinne.
Internet Telephony Helen J. Wang Network Reading Group, Jan 27, 99 Acknowledgement: Jimmy, Bhaskar.
Subnetting.
North American Emergency Services Brian Rosen Emergicom.
The Next Generation Proof-of-Concept System.
Alternatives for Providing Routing and Location Information to support Emergency Calling from IP Enterprises Prepared For: NENA VoIP Meeting on behalf.
North American Emergency Services Brian Rosen Emergicom.
Ernst Langmantel Technical Director, Austrian Regulatory Authority for Broadcasting and Telecommunication (RTR GmbH) The opinions expressed in this presentation.
1 © NOKIA Presentation_Name.PPT / DD-MM-YYYY / Initials Emergency calls related work done in IETF Gabor Bajko May 22, 2006.
© 2008 AT&T Knowledge Ventures. All rights reserved. AT&T and the AT&T logo are trademarks of AT&T Knowledge Ventures. 1 Video Relay Service and Assignment.
NG911 technology Henning Schulzrinne
ESW – May 2010 UK Architecture for VoIP 999/112s John Medland – BT 999/112 Policy Manager.
PART 2: Product Line. Tenor Switches & Gateways Tenor AX Series Solution For Medium to Large Enterprises  Available in 8, 16, 24 and 48 port Available.
-framework Brian Rosen. -11 version deals with IESG comments All comment resolved one way or another One open issue – spec(t)
PSTN – User ENUM – „Infrastructure ENUM“ An ETSI View Richard Stastny IETF60 San Diego.
COMT 6251 Network Layers COMT Overview IP and general Internet Operations Address Mapping ATM LANs Other network protocols.
Status and Development of VoIP based emergency calls Alexander Mayrhofer, nic.at GmbH The 1st European Security and Safety Summit Brussels, June 2007.
NENA Development Conference | October 2014 | Orlando, Florida Emergency Incident Data Document (EIDD) Transfer Protocols Jerry Schlesinger, PMP – City.
Practical Considerations for supporting Emergency Calls Brian Rosen Emergicom.
Building Information Exchange with First Responders (BIEFR) David Holmberg, NIST June 11, 2009 Slides credit to Alan Vinh.
Draft-rosen-ecrit-emergency- framework-00 Brian Rosen NeuStar CPa
1 Location Hiding Henning Schulzrinne Laura Liess Hannes Tschofenig.
IETF – ECRIT Emergency Context Resolution using Internet Technologies ESW 5 – Vienna October 2008 Marc Linsner.
CP-a Emergency call stage 2 requirements - A presentation of the requirements from 3GPP TS Keith Drage.
Discovery issues in atoca Brian Rosen. We need to handle several cases Some alerts are broadcast via some access network specific mechanism (multicast,
PSAP Callback draft-ietf-ecrit-psap-callback Phone BCP Status Usage Scenarios.
The State of VoIP Peering Charles Studt Director of Product Management, VoEX.
Next Generation Standards, Transitions and Challenges Brian Rosen Senior Director, Neustar Chair, Long Term Definition WG, NENA.
July 2006IETF66 - ECRIT1 LoST: A Location-to-Service Translation Protocol draft-ietf-ecrit-lost-00 Ted Hardie Andrew Newton Henning Schulzrinne Hannes.
GIS and Next Generation Public Safety
Together, we’re changing the world of NG9-1-1 Deployments and Standards Nate Wilcox CTO.
Core VoIP and 911 issues and alternatives Henning Schulzrinne Columbia University August 2003.
1 911 Background  Traditional 911 ~6,000 PSAPs in the US Selective routers route calls to correct PSAP –Operated by carriers –Relies on DB of fixed subscriber.
ECRIT Basic Reqs draft-stastny-ecrit-requirements Richard Stastny Brian Rosen IETF62 Minneapolis.
ECRIT - Getting Certain URIs, and Alternatives to Getting Emergency Dialstring(s) draft-polk-ecrit-lost-server-uri-00 draft-polk-dhc-ecrit-uri-psap-esrp-00.
Doc.: IEEE /0xxxr0 Submission March, 2007 Gabor/SriniSlide 1 Joint TGu : Location Configuration for Emergency Services Notice: This document.
Internet Real-Time Lab, Columbia University NG9-1-1 Prototype Demo Jong Yul Kim, Wonsang Song, and Henning Schulzrinne.
Internet Real-Time Lab, Columbia University NG9-1-1 Prototype Demo Jong Yul Kim, Wonsang Song, and Henning Schulzrinne.
Emergency Text Messaging using SIP MESSAGE draft-kim-ecrit-text-00
© 2015 Airbus DS Communications, Inc. All rights reserved. Lights, Camera, NG9-1-1 Diana Gijselaers/ Solutions Engineer – NG9-1-1 GIS and Core Services.
Emergency Context Resolution with Internet Technologies (ecrit) Hannes Tschofenig, Marc Linsner IETF 66, Montreal, June 2006.
October 4-7, 2004 Los Angeles, CA E9-1-1 In a VoIP World Timothy Lorello SVP, Chief Marketing Officer TeleCommunication Systems (TCS) (410)
How GIS will support Ng911 in Indiana
IP Telephony (VoIP).
THIS IS THE WAY ENUM Variants Jim McEachern
Joint TGu : Location Configuration for Emergency Services
Preparing for the Future
Jong Yul Kim, Wonsang Song, and Henning Schulzrinne
Thoughts on VoIP and Emergency Calling
Presentation transcript:

NENA Next Generation 9-1-1 Architecture Brian Rosen Senior Director, NeuStar Chair, NENA Long Term Definition WG

Background NENA = North American Emergency Number Association Sets standards (among many other things) for emergency calls in U.S./Canada Next Generation 9-1-1 project Complete overhaul of the entire 9-1-1 system Based on IP Includes changes to processes, funding, training, etc, etc The initial version of the technical standards part is known as “i3”

i3 is based on IETF Emergency Call Mechanisms Endpoint (phone) “determines” its location by measurement (e.g. GPS) or from the access network via a “Location Configuration Protocol” Endpoint “maps” the location to the URI of the PSAP with a new protocol, LoST Endpoint learns LOCAL dialstring (9-1-1, 1-1-2) from LoST Endpoint recognizes emergency call dialstring when dialed Call is marked with service urn (urn:service:sos) Call is sent to PSAP with mapped URI Location is “conveyed” with the call Call arrives at PSAP with location and call back info Works for all media (voice, video, text, IM, …)

Location Determination How location is actually figured out Measurement (GPS) or wiretrace or manual configuration Can be done by the endpoint or the access network Can be civic (street address) or geo (lat/lon/altitude)

Location Configuration Protocols How the access network provides location Exchange an identifier of some kind, implicitly (e.g. what port on the switch) or explicitly (e.g. MAC address, IP address) for location Location can be civic or geo Current discussion on whether it can be a reference (e.g. URI) which must be dereferenced by some other protocol, or must be a value DHCP is an example LCP There is a “Layer 7” LCP in development LLDP-MED is another example of an LCP

Marking an Emergency Call Single global standard to denote an emergency call (does not rely on local dialstrings) Uses a newly defined Service urn Local dialstring is detected, and call is then marked with the service urn Single number countries (9-1-1) use urn:service:sos Number-per-service countries (1-1-6=police) use e.g. urn:service:sos.police Extends to commercial location based routing, e.g. urn:service:restaurant.pizza.pizzahut) Normally endpoint does dialstring to service URN translation, network can do it

Routing Emergency Calls Location to Service Translation = LoST Service URN + Location in, URI out A “Mapping” function Accepts civic/geo and service urn, returns URI, e.g. SIP and/or XMPP URI of where to route the call Normal (SIP) routing of that URI LoST is global, distributed, and replicated Normally endpoint maps, network can do it LoST will also supply the dialstring(s) for a location LoST will also validate a civic location

Back to NENA i3 All calls answered as IP calls at PSAP Implies gateways between older TDM switches and PSAPs All calls routed with LoST Implies TN to location lookup prior to routing All calls arrive at PSAP with location and call back address (can be URI or e.164)

Emergency Services IP Network An IP network FOR ALL OF PUBLIC SAFETY, not just 9-1-1 A regular routed IP network DOES have (firewalled) connections to the Internet Conceived as LOCAL networks (e.g. County level) interconnected with neighbors, perhaps a backbone for efficiency Most local carriers will have private connections to the local ESInet Option of using the Internet to introduce calls

Multi-Stage Routing Emergency Services Routing Proxies at edge of ESInet onward route calls to PSAP Uses LoST with authentication User LoST query may return URI of ESRP ESRP will foreward to PSAP Could have more than one level of ESRP

More Data will be accepted Additional Information about the call Includes carrier contact info, subscriber class of service, etc Call marked with URI of a datastructure to be retrieved by the PSAP Also used for pointer to telematics data Additional Information about the caller Refers to the person, independent of home/office/mobile telephone Could be medical info, “in emergency, please contact”, …) Also a URI (anonymous), supplied by subscriber to carrier Additional Information about the location Comes from LoST Two calls from same location will have same info, regardless of caller or carrier Could be floor plans, hazardous materials, surveillance video, …

i3 PSAPs will be multimedia Voice, Video, Text Will support a variety of codecs (but not all of them, carriers don’t decide) Will support both IM and interactive (character at a time codecs) Full Offer/Answer negotiation Will use codec choice to automatically engage relay operators if needed Will use Language preference info to route calls to appropriate call takers, and automatically engage interpreters

3rd Party Calls Used when user contacts a call center first Text/Video/IP Relay Telematics (OnStar) Central Alarm Monitoring Authorized 3rd parties can directly introduce calls, routed by location of user, with all 3 parties conferenced at the PSAP

PSAPs use LoST to route to responders A PSAP will make LoST dips with caller’s location to determine the responding police, fire, ems, … services A different service urn Requires authentication Same underlying database This replaces the “ESN” of the current system

Notes to endpoint vendors Read –phonebcp (will be draft-ietf-ecrit-phonebcp-00) Implement ALL OF a short list of LCPs Map location to PSAP URI and cache it Recognize local (and maybe home) dialstrings as emergency calls Mark emergency calls with service URN Try to update location and LoST mapping at call time, use cached values if needed Several other SIP things to support PSAP operations on calls Support manual override of determined location, but make it possible, not easy to use

Notes to Access Network Providers Need to choose one of the LCPs the phones will implement and deploy it The only way to choose something not on the –phonebcp list is to force every endpoint to do something else But watch out for Ethernet connected phones behind a router/switch with an uplink to your network; you may not be able to control them Probably will be asked to supply a hint to a local LoST service Validate (use LoST) civic locations when you put them in your location server

Notes to Communications (e.g. VoIP) Carriers Prepare to route marked emergency calls to PSAP/ESRP Prioritize marked emergency calls in softswitches Deploy connections to local ESInets Add the “Info about the call” URI with your contact data, etc. Support Interactive Text & Video codecs all the way through the system for the disabled