geographical position supply chain

NFS2004 NTNU, Dep of Telematics

1

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

Bjørn Næss

Husk å oppdatere commercial


2

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.


3

Stationary User Location (Traditional Approach)

PSAP(Public Safety

Answering Point)NetworkProvider

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


4

Mobile User Location (main traditional approach)

EnterpriseFleet

Management Centre

GPS enabled device

Reporting position by SMS or GPRS

Example: Trondheim Taxi Fleet


5

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)


6

Mobile and Nomadic user location determined by the

infrastructure

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


7

Geographical Position Supply Chain Architecture -

Producer side

GPoS(Geographical

Position Service)

GSM

UMTS

WLAN

Network Dependent

Data Extraction

ND (Navigation Devices)Units with on-boardcomputation 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

AccessGateway

Req/ResponseInterface.

SLAs with Multiple Service Providers/

ND owners


8

Geographical Position Supply Chain Architecture –

Consumer Side

Statistical ServicesSLA

May feature different levels of data rendering according to authorisation. Also possible to

provide anonymous data for statistical purposes

”Blue light” ServicesEmergency and Public

PreparednessSLA

Commercial ASPs (Serves groups

of “subscribers”)SLA

GPos for the individual(oneself)SLA

GPoSData assembly,authorisation,and control


9

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:1. “Blue light” services (Police, Fire brigade, Ambulance). Authorisation to

track everyone.2. Application Service Providers: stolen property tracing, fleet management

systems, etc. Authorisation to track “subscribers”.3. Single user applications: providing navigational services, Navigational

assistant for the blind, etc.. Authorisation to track “oneself”.4. 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.


10

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).


11

Geographical Position Supply Architecture -Main Principle

INTERROGATING THE DEVICE ITSELF

GPoS

User deviceobtains its own location

Admin domain/Network

DependentAccess

Gateway

Local Adm.LocationService

Location Request/response

GPSSLA

or Location Request/response


12

Geographical Position Supply Architecture

Optional Principle INTERROGATING THE LOCAL POSITION SERVICE

GPoS

Local Adm.LocationService

SLA

Location Request/response

Surveillance/reporting


13

Geographical Position Supply Implementation Sample

GPoS

Network Administration

System(NAV)

SLAPOSNAV

(local GPoS)

Surveillance/reporting


14



User device obtains its own location

GPS GPoSGPS

module

SLA2


System(NAV)

SLA1

POSNAV(local GPoS)

Surveillance / reporting

Location update

Location request/response

Bjørn Næss

Se vedlagt dokument for nærmere beskrivelse av scenarioene


15

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 serverwe also considering to implement/use

– IETF Geopriv specification, – The requirements established by the Norwegian authorities, for

emergency calls– OpenGIS (a Geographical Markup Language version)


16

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)

Bjørn Næss

Endre commercial use


17

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)


18

Back up slides


19

Indication of the emergency caller's location

ETSI SR 002 180 V1.1.1 (2003-12), Special ReportRequirements 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.


20

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. "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."


21

Current Geopriv draftshttp://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)


22

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>


23




GPS GPoSGPoS GPS

SLA2

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 SLAGPS

GPS


24




GPS

GPoS


System(NAV)

SLA1

POSNAV(local GPoS)



GPSX 1. A nomadic user visits a

foreign network domain. There is no GPS available.

2. It sends an Location request to a local GPoS. E.g. POSNAV.


25


Two possible scenarios


GPS GPoSGPoS GPS

SLA2


System(NAV)

SLA1

POSNAV(local GPoS)


Location update



26

SIP emergency call


GPSGPS

SIP Server

GPoS

INVITE (posdata as payload)


This may be needed to verify the posdata

GPoS is used as demonstrated in the

two scenarios

ECC/PSAP

ECC: Emergency Control Center

geographical position supply chain

Business

expressing privacy preferences

emergency control centre

geographical position service

user device obtains

mobile user location

emergency call

location request 3

jon peterson