Geographical Position Supply ChainPresentation Transcript
Geographical Position Supply Chain Steinar Hidle Andresen (Assisted by Bjørn Næss, Tommy Rafos and Jan Morten Henriksen) Norwegian Network Research Seminar 2004 NTNU
Classes of users
Stationary user (device):
User is connected to the network at a fixed, long-term-stable geographic location. Examples include a home PC or a payphone.
Nomadic user (device):
User is connected to the network temporarily, for relatively short durations, but does not move significantly during the lifetime of a network connection or during the emergency call. Examples include a laptop using an 802.11 hotspot or a desk IP phone that is moved from one cubicle to another.
Mobile user (device):
User who changes geographic location and possibly their network attachment point during an emergency call.
Stationary User Location (Traditional Approach) PSAP (Public Safety Answering Point) Network Provider Emergency Call 1. Emergency call <CLI and A- number> Provider’s or national database 2. Location Request <CLI> 3. Location Data <CLI, Address> CLI: Calling Line Identification
Mobile User Location (main traditional approach) Enterprise Fleet Management Centre GPS enabled device Reporting position by SMS or GPRS Example: Trondheim Taxi Fleet
Mobile User Location (proposed approach for E-merge calls) PSAP (Public Safety Answering Point)
Position conveyed in the UUS fields
GSM/GPS enabled device Problem: Most operators has disabled the UUS feature due to misuse. This function has to be reconsidered. Petition has been sent to the 3 G. PSAP (Public Safety Answering Point)
Mobile and Nomadic user location determined by the infrastructure PSAP Location Systems 2. Location Request <A-number/SIP address> 3. Location Data <A-number, Geographical Coordinates> GSM with no GPS Laptop or IP phone with WLAN 1. Emergency call <A- number > 1. Emergency call <SIP address>
Geographical Position Supply Chain Architecture - Producer side GPoS ( G eographical Po sition S ervice) GSM UMTS WLAN Network Dependent Data Extraction ND (Navigation Devices) Units with on-board computation of position, e.g GPS/GNSS based LAN (by cable) Fixed line CS Network Dependent Data Extraction Network Dependent Data Extraction Network Dependent Data Extraction Network Dependent Data Extraction Network Dependent Access Gateway Req/Response Interface. SLAs with Multiple Service Providers/ ND owners SIP Telephony?
Geographical Position Supply Chain Architecture – Consumer Side May feature different levels of data rendering according to authorisation. Also possible to provide anonymous data for statistical purposes GPoS Data assembly, authorisation, and control Statistical Services SLA ” Blue light” Services Emergency and Public Preparedness SLA Commercial ASPs (Serves groups of “subscribers”) SLA GPos for the individual (oneself) SLA
Geographical Position Service (Server)
Should be regarded as a “Trusted Entity” in the network
Provides a ”point” for legal audition and control.
Provides a common unified access point to authorised geographical position data for:
“ Blue light” services (Police, Fire brigade, Ambulance). Authorisation to track everyone.
Application Service Providers: stolen property tracing, fleet management systems, etc. Authorisation to track “subscribers”.
Single user applications: providing navigational services, Navigational assistant for the blind, etc.. Authorisation to track “oneself”.
Statistical data (e.g. link driving times on in the road network), data about the individuals to be hided.
Hides the details of technology and networks/ acts as a “Fire Wall” to prevent unauthorised access to the data providers.
Geographical Position Service
From a market perspective a GPoS will benefit 3. Party Service Developers and Providers by
hiding the technological details of data acquisition
giving a stable platform for implementation
This may foster a rapid and strong development of the services offered.
A GPoS can be realised as
a centralised server, managed by an authorised party, or
alternatively in a distributed fashion as modules installed at the premises of the network service providers. In this latter case, the function should act as it where centralised (providing a universal service like e.g. the DNS does).
Geographical Position Supply Architecture -Main Principle INTERROGATING THE DEVICE ITSELF GPoS User device obtains its own location Admin domain/ Network Dependent Access Gateway Local Adm. Location Service Location Request/ response GPS SLA or Location Request/ response Screening?
Geographical Position Supply Architecture Optional Principle INTERROGATING THE LOCAL POSITION SERVICE GPoS Local Adm. Location Service SLA Location Request/response Surveillance/ reporting
Geographical Position Supply Implementation Sample GPoS Network Administration System (NAV) SLA POSNAV (local GPoS) Surveillance/ reporting
Geographical Position Supply Implementation Sample INTERROGATING THE DEVICE ITSELF User device obtains its own location GPS GPoS GPS module SLA 2 Network Administration System (NAV) SLA 1 POSNAV (local GPoS) Surveillance / reporting Location update Location request/response
What are we currently doing?
3 persons are busy designing and implementing
The “framework” and a prototype lab version of the server including interfaces to:
ITEA’s Network Administration System (NAV).
GPS enabled GSM phones
AMK (Health emergency Communication Centre) at St. Olavs Hospital
A simple web based map application on the user side.
UML and XMLschema
the server is programmed in Java and runs on a Linux server
we also considering to implement/use
IETF Geopriv specification,
The requirements established by the Norwegian authorities, for emergency calls
OpenGIS (a Geographical Markup Language version)
What are we aiming at
A beta specification and a prototype implementation by 31. of Dec. 2004
(we have offered a demonstration at the NTNU/TEKNA seminar in January)
Utilising the platform as a lab-tool for further studies in
architecture (also security issues) - with a special focus on IP solutions
how to “produce” location data
how to use location data (including business models)
Developing the concept or the “product” for deployment and use in normal networks - not only for the lab (financial support applied for)
Our contact network
The Norwegian Post and Tele Authority
ITEA (Data and Telecom administration at NTNU)
Uninett (c/o Faltinsen)
ETSI’s EMTEL work with liaisons to e. g.:
The European E-merge consortium
IETF’s Working groups. on Geopriv and Sipping (c/o Schulzrinne)
NENA (The “911” organisation in the US)
Back up slides
Indication of the emergency caller's location ETSI SR 002 180 V1.1.1 (2003-12), Special Report Requirements for communication of citizens with authorities/organizations in case of distress (emergency call handling) Paragraph: 22.214.171.124
Each emergency call should be accompanied with information that enables the emergency control centre to determine the caller's location at the time of calling. This information may be a geographical address or a set of geographical co-ordinates. The information should be accessible by the emergency control centre via a standardized interface after the initial contact is made. Location information should be accessible for as long as the emergency lasts.
NOTE 1: This information is required and has importance in the case of co-ordinating disaster relief. The impact this requirement has on the Network operator may vary on a national basis. The PSAP/Emergency Control Centre may only make requests for Location information in conjunction with an emergency call.
Typically, location information is based on the CLI received with the call for wireline networks, and on the geographical co-ordinates of the caller for wireless networks. For roaming cordless terminals due to emergency provision of the home base station CLI may be desirable.
126.96.36.199 Indication of the emergency caller's location
NOTE 2: due to the support for Number portability or the inter-working with VoIP services determinating location information solely from the CLI may be impossible with some database arrangements, where the interrogation of the data is dependant on the network operator's database requested.
Recommendations 4 and 9 of the commission recommendation C(2003)2657 are quoted below:
4. "For every emergency call made to the European emergency call number 112, public telephone network operators should, initiated by the network, forward (push) to public safety answering points the best information available as to the location of the caller, to the extent technically feasible".
9. "For each emergency call for which the subscriber or user number has been identified, public telephone network operators should provide the capability to public safety answering points and emergency services of renewing the location information through a call back functionality (pulling)for the purpose of handling the emergency."
Current Geopriv drafts http://www.ietf.org/ids.by.wg/geopriv.html
"Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information", Henning Schulzrinne, 6-Oct-04.
"A Document Format for Expressing Privacy Preferences for Location Information", Henning Schulzrinne, 6-Oct-04.)
"A Presence-based GEOPRIV Location Object Format", Jon Peterson, 10-Sep-04..
"A Presence Architecture for the Distribution of GEOPRIV Location Objects", Jon Peterson, 9-Sep-04..
"A Document Format for Expressing Privacy Preferences", Henning Schulzrinne, 6-Oct-04.
"Carrying Location Objects in RADIUS", Hannes Tschofenig, 6-Oct-04. (94758 bytes)
Coming IETF WG Sipping Emergency Drafts
Emergency Services for Internet Telephony Systems <draft-schulzrinne-sipping-emergency-arch-02>
Requirements for Session Initiation Protocol (SIP)-based Emergency Calls <draft-schulzrinne-sipping-emergency-req-01>
Geographical Position Supply Implementation Sample INTERROGATING THE DEVICE ITSELF User device obtains its own location GPS GPoS GPoS GPS SLA 2 Location update 1. User updates its location from GPS 2. User sends a Location update to GPoS GPS 3. GPoS GPS may allow other GPoS users to lookup this users position, according to the SLA GPS GPS
Geographical Position Supply Implementation Sample INTERROGATING THE DEVICE ITSELF User device obtains its own location GPS GPoS Network Administration System (NAV) SLA 1 POSNAV (local GPoS) Surveillance / reporting Location request/response X
A nomadic user visits a foreign network domain. There is no GPS available.
It sends an Location request to a local GPoS. E.g. POSNAV.
Geographical Position Supply Implementation Sample Two possible scenarios User device obtains its own location GPoS GPoS GPS SLA 2 Network Administration System (NAV) SLA 1 POSNAV (local GPoS) Surveillance / reporting Location update Location request/response GPS
SIP emergency call User device obtains its own location GPS SIP Server GPoS INVITE (posdata as payload) Location request/response This may be needed to verify the posdata GPoS is used as demonstrated in the two scenarios ECC/PSAP ECC: Emergency Control Center GPS