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

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