Geographical Position Supply Chain
Upcoming SlideShare
Loading in...5
×
 

Geographical Position Supply Chain

on

  • 825 views

 

Statistics

Views

Total Views
825
Views on SlideShare
825
Embed Views
0

Actions

Likes
0
Downloads
15
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Geographical Position Supply Chain Geographical Position Supply Chain Presentation 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)
    • Emergency call
    • Position conveyed in the UUS fields
    • (PUSH)
    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:
        • Production side:
          • ITEA’s Network Administration System (NAV).
          • GPS enabled GSM phones
        • Consuming side:
          • AMK (Health emergency Communication Centre) at St. Olavs Hospital
          • A simple web based map application on the user side.
    • Tools
      • Specification
        • UML and XMLschema
      • Implementation,
        • 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: 4.2.1.2
    • 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.
  • 4.2.1.2 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. &quot;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&quot;.
    • 9. &quot;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.&quot;
  • Current Geopriv drafts http://www.ietf.org/ids.by.wg/geopriv.html
    • &quot;Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information&quot;, Henning Schulzrinne, 6-Oct-04.
    • &quot;A Document Format for Expressing Privacy Preferences for Location Information&quot;, Henning Schulzrinne, 6-Oct-04.)
    • &quot;A Presence-based GEOPRIV Location Object Format&quot;, Jon Peterson, 10-Sep-04..
    • &quot;A Presence Architecture for the Distribution of GEOPRIV Location Objects&quot;, Jon Peterson, 9-Sep-04..
    • &quot;A Document Format for Expressing Privacy Preferences&quot;, Henning Schulzrinne, 6-Oct-04.
    • &quot;Carrying Location Objects in RADIUS&quot;, 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.
    GPS
  • 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