Upload
venice
View
30
Download
1
Embed Size (px)
DESCRIPTION
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 - PowerPoint PPT Presentation
Citation preview
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