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