110 likes | 311 Views
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
E N D
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 • “i3” = Emergency Services system changes to accommodate IP
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
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
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
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
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
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
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
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
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