nena next generation 9 1 1 architecture n.
Skip this Video
Loading SlideShow in 5 Seconds..
NENA Next Generation 9-1-1 Architecture PowerPoint Presentation
Download Presentation
NENA Next Generation 9-1-1 Architecture

Loading in 2 Seconds...

play fullscreen
1 / 17

NENA Next Generation 9-1-1 Architecture - PowerPoint PPT Presentation

  • Uploaded on

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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'NENA Next Generation 9-1-1 Architecture' - yetta-terrell

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
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

  • 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
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
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
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
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.
  • Normally endpoint does dialstring to service URN translation, network can do it
routing emergency calls
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
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
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
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
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
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
3 rd party calls
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
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
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
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
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