1 / 11

NENA Requirements

NENA Requirements. draft-rosen-nena-ecrit-requirements Brian Rosen. NENA. North American (US/CA) Emergency Number Association VoIP/Packet Technical Committee Long Term Definition Working Group These requirements are a subset of the requirements of the LTD WG

venice
Download Presentation

NENA Requirements

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 Requirements draft-rosen-nena-ecrit-requirements Brian Rosen

  2. NENA • North American (US/CA) Emergency Number Association • VoIP/Packet Technical Committee • Long Term Definition Working Group • These requirements are a subset of the requirements of the LTD WG • “i3” = Emergency Services system changes to accommodate IP

  3. Basic North American Problem • 6,134 PSAPs with some irregular boundaries • Well developed civic and geo routing system • All civic addresses are validated against the Master Street Address Guide • Current system has good accountability for every entity along the signaling path

  4. Signaling • Need to know what happened – what elements were in the path, what they did • Need to have internationally useable method for determining an emergency call, but must be able to use 9-1-1 in North America • Must be able to gateway calls from PSTN in and have it work • Need a way to have calls go to an e.164 for those areas not served by 9-1-1. • Need Congestion Controls Everywhere

  5. Location • Location comes with the call, geo (x/y/z) or civic • Issues of multiple locations reported in the call – need to specify how to handle it • Separation of location provider from communication service provider • Need defaults for routing when missing or incomplete location is reported • Need a way to get location updates

  6. Additional Information • Need a way to associate additional info about the location • Need to reflect domain hierarchy = building, tenant, … • A URI in the database is enough • Need a way to associate additional info about the caller • Possibly distinguish between AoR and actual person • A URI in the database is enough

  7. Validation • You validate BEFORE you call • Valid = address is in the master database • In North America, we have multiple validation databases with irregular service boundaries (like PSAPs, and often coincident with a set of PSAP boundaries) • The Postal vs Actual Community Name problem

  8. Routing • Calls must be routed to the correct PSAP based on the location of caller and declared boundary of the PSAP • Routing must be possible on civic or geo • Cannot REQUIRE conversion (geo <> civic), but should allow it • PSAPs need control over routing & conversion data • PSAPs declare their boundaries • Some areas will have coarse boundaries (country/state). Others will have very irregular boundaries (river, all of a city minus 2 streets, …) • Routing data has to be available to a large number of routing entities

  9. Routing (2) • Routing data must be secure (authentication, integrity protection) • Routing data must be reliable, even in the face of disasters • Need a way to have alternate routes, including some with e.164s • Initial location may be inaccurate, requiring a re-route later on

  10. Others • Need a reliable call back mechanism • Some need a “no hang-up” mechanism • Need lots of redundancy to deal with failures of all sorts (not just routing data) • Need a test mechanism • Need mechanisms to distribute route failure information, and similar diagnostic data

  11. What to do with this draft • Make it the basis of the ECRIT requirements document OR • Create a “design team” from authors of this and the other requirements drafts and charge them with coming up with one ECRIT requirements draft

More Related