50 likes | 62 Views
Ensure the integrity and accuracy of location information used for emergency calls to prevent dispatching responders incorrectly. Address the challenges of multiple locations, resolve ambiguities, and establish guidelines for handling default and accurate locations. Introduce new fields for postal and legal communities, capture the date/time of location determination, enhance information on confidence and uncertainty, define additional "placetypes", and include relevant associated information. This document aims to recharter geopriv and propose accepted solutions for these issues.
E N D
NENA geopriv Requirements draft-rosen-nena-geopriv-requirements-00 Brian Rosen
Integrity of Location Information • When location is forged, and used for an emergency calls, responders are dispatched incorrectly, which can cause harm • Location may go through multiple protocols and representations (e.g. DHCP, then SIP) • Need end to end signature over the location
Multiple Locations • When multiple locations are given in a PIDF-LO, or multiple PIDF-LOs are transported in a message, what does that mean? • For emergency calls, we can’t have unresolvable ambiguity; we route on ONE location • BUT sometimes there is a default (more coarse grained) location, PLUS a more accurate one (tower location vs handset location). Need to deal with that. • Need rules/guidelines/fields to figure out how to do this
Other changes needed • Need “Postal Community” and “Legal” Community fields • Need Date/Time location was determined (when PIDF-LO was created may be useful for integrity protection) • Confidence and Uncertainty is not enough information. Need more work • Need more “Placetypes” (?SIMPLE?) • Need other information associated with location (or caller)
What do we want to do? • Recharter geopriv to deal with these issues • Turn this into one or more requirement/solution documents that get accepted as WG items