1 / 17

NENA Next Generation 9-1-1 Architecture

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

channer
Download Presentation

NENA Next Generation 9-1-1 Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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”

  3. 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, …)

  4. 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)

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

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

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

  8. 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)

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

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

  11. 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, …

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

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

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

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

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

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

More Related