NENA Requirements

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 ltgt 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