1 SUPL 2.0 Overview Introducing new features with a special focus on Emergency support SDO Emergency...

1

SUPL 2.0 OverviewIntroducing new features with a special focus on Emergency support

SDO Emergency Services Workshop | 23 October 2008

Khiem Tran, LOC Working Group, Open Mobile Alliance

SDO Emergency Services Workshop, Khiem Tran www.openmobilealliance.orgSDO Emergency Services Workshop 23 October 2008

2

Agenda

»SUPL Introduction and SUPL 1.0 functionality

»SUPL2.0 New Feature Overview

»SUPL2.0 Features In Detail

»SUPL2.0 from an Emergency Services Perspective

SDO Emergency Services Workshop 23 October 2008

3

Agenda






4

What is SUPL?

SETH-SLP


5

Why SUPL?

» Overlay location architecture almost independent of access [1]

» Simpler model compared with control plane

GMLC* Note 6

2G

- MSC

3G

- SGSN

2G

- SGSN

MSC

server

GERAN

UTRAN

UE

gsmSCF

Lg Gb

A

Lg

Lc

Le

Iu

HSS

*Note 1

Iu

Iu

Lg

Um

Uu

Lg Lh

External LCS

Client Iu

OSA API Proprietary

OSA SCS

Proprietary

* Note 2 PPR

*Note 3

Lpp

PMD

*Note 4

Lid

Le LIMS-IWF

* Note 5

LRF

E-CSCF

Li

SETH-SLP


6

SLP network relationship

» SET always talks only to H-SLP, regardless of access network» H-SLP has responsibility for finding and enlisting other

resources to locate SET

SET

H-SLP

Visited SLPGSMVisited NetworkInfrastructure

Home Network Infrastructure

Visited Network

Home Network


7

What SUPL covers» Lup, the interface between the

H-SLP and the SET» ULP, the protocol used on the

Lup interface» The behaviour of the SET and

H-SLP in their interactions between each other

» The interactions between the H-SLP and other SLPs involved in locating the SET

» Logical architecture of SLP, consisting of an SLC (SUPL Location Center) and an SPC (SUPL Positioning Center)

SLP

SET

WAP PPG

SMS/MC

CDMA

WCDMA

GSM

SUPL Agent

TLS over

TCP/IP SUPL INIT delivery via

SMS

SUPL INIT delivery via

WAP

Bearer Networks

V-SLP


8

High level characteristics

» Utilises secure userplane pipe between SET and SLP

» Requires explicit support for each bearer network

» Trust relationship between SET and H-SLP

» Trusted zone extends to SET

SLP

SET

WAP PPG

SMS/MC

CDMA

WCDMA

GSM

SUPL Agent

TLS over


SMS


WAP

Bearer Networks


9

ULP Transport

» Most ULP messages are transported via a secure TLS session

» SLP authentication» SET only ever uses stored FQDN to

address H-SLP» Shared secrets utilising control

plane mechanisms OR root certificate

» SET authentication » Shared secrets utilising control

plane mechanisms OR IP verification (requires control plane interaction)

» TLS session only ever initiated by SET» For SUPL sessions initiated by H-

SLP, we need…

SLP

SET

TLS over

TCP/IP


10

SUPL INIT Support• SUPL INIT messages can be

sent via WAP or SMS

• After receiving message, SET opens secure session to H-SLP

• WAP and SMS delivery both insecure

• Mechanisms in ULP validate if SUPL INIT was authentic once secure session established

H-SLP

SET

WAP PPG

SMS/MC


SMS


WAP


11

Proxy Mode vs Non-Proxy Mode» Two modes of operation. In Proxy Mode, SET connects with H-

SLP via SLC component. In Non-Proxy Mode, it connects to both SLC and SPC components.

SUPLAgent

H-SLP Target SET

MLP SLIR (ms-id, client-id, eqop)

SUPL INIT (session-id, posmethod, SLP mode)

MLP SLIA (posresult)

B

A

C

D

F

E

SUPL POS (session-id, RRLP/RRC/TIA-801)

SUPL END (session-id)

SUPL POS INIT (session-id, lid, SET capabilities, ver)

SET Lookup, Routing Info

Data Connection Setup

G

H

ST2

UT2

UT3

H-SLPSUPLAgent

Target SET

MLP SLIR(ms-id, client-id, eqop)

MLP SLIA (posresult)

B

A

C

D

F

E


G

H

H-SPCH-SLC

SET Lookup, Routing info

SUPL POS INIT (session-id, lid, SET capabilities)

I

J


K


Internal Initialization

Internal Communication


ST2

PT1

UT2

UT3

SUPL INIT (session-id, SPC address, posmethod, SLP mode)

SUPL AUTH REQ (session-id, ver)

L

M

SUPL AUTH RESP (session-id, SPC_SET_Key, SPC-TID )UT4



12

What can SUPL1.0 do?» Immediate Location Requests

» SET can ask for its own location - “SET Initiated”» H-SLP can initiate a location request on behalf of a SUPL Agent - “Network

Initiated”» SET can send measurements to SLP» ULP can transport positioning protocols such as RRLP, RRC and IS-801

» Location Technologies» Primarily A-GPS and Cell ID, but support for other SET based

measurements such as EOTD» Call flows built around a low accuracy method requiring one set of

measurements (Cell ID) and a high accuracy method requiring an exchange of messages using an encapsulated control plane positioning protocol (A-GPS)

» Different mechanisms for Roaming» H-SLP can ask visited SLP to help with positioning» H-SLP can ask visited SLP to translate a coarse position» H-SLP can do everything itself


13

SUPL 1.0 Scope

Support for emergency

queries

Timeliness of SUPL INIT

delivery

SUPL INIT delivery to

visited network

Security for ULP

Verification of IP address/MSISDN for ACA method

Is device even a SET?

Which methods of SUPL INIT

delivery supported by

SET

One mandatory

PosProtocol per bearer

SMS-MT/WAP Push delivery

Transport for rest of ULP

(TLS1.0 over TCP/IP)

GSM, CDMA, WCDMA only

Required network

interactions

How H-SLP determines

SET is roaming

Out of ScopeIn Scope

RRLP, RRC, IS-801

SET and Network Initiated

Immediate Requests

Selection of positioning technology


14

Agenda






15

SUPL2.0 Additional Features

» Triggered Positioning and Delayed Reporting

» Other GNSSs besides GPS» New positioning procedures» Notification and Verification

based on current location» Version negotiation between

SUPL versions» Enhanced ULP messaging

Size of SUPL2.0 vs SUPL1.0 (in pages)


16

SUPL 2.0» Five new bearer networks» Two new mechanisms for

SUPL INIT delivery» Concept of Emergency SLP

(E-SLP)

SLP

SET

WAP PPG

SMS/MC

CDMA

WCDMA

GSM

SUPL Agent

TLS over


SMS


WAP

Bearer Networks

Emergency IMS Core

UDP/IP Push

LTEWiMAX

UMB I-WLAN

HRPD


17

Agenda






18

SUPL INIT Delivery Mechanisms

• UDP/IP Push- UDP datagram to IP address of SET

- Requires IP address to be known

• Neither mandatory for any bearer

Target SET SIP/IP Core H-SLP

MESSAGE (SUPL INIT)

MESSAGE (SUPL INIT)

200 OK

200 OK

SIP Push Utilizes existing secure connection to SET


19

New Bearer Networks

» New bearers supported:» LTE» HRPD» UMB» I-WLAN» WiMAX» I-WiMAX

» New security mechanism (SEK) defined for WiMAX» Requires interaction with WiMAX AAA server» ACA method not supported for WiMAX, but new subset of ACA called

“E-SLC only” supported for emergency calls

SEK= SUPL Encryption Key GBA = Generic Bootstrap Algorithm ACA = Alternate Client Authentication


20

A-GNSS Support

» SUPL2.0 supports:» Galileo» Modernized GPS» QZSS» GLONASS» SBAS

» SET can indicate support for multiple GNSSs» SLP can allow SET to use multiple GNSSs for A-GNSS or Autonomous

GNSS

Note: “GNSS” refers to all Global Navigation Satellite Systems, “GANSS” refers to all GNSSs including Modernized GPS, but not the original GPS


21

Triggered Positioning and Delayed Reporting

» SUPL2.0 introduces triggered positioning

» Includes Area Event triggering and Periodic triggering

» Both Network Initiated and SET initiated

» Controlling logic for triggering is all on the SET

» SUPL2.0 also introduces Reporting Mode

» For batch mode, SET can store periodic reports (positions or measurements) and deliver them to the SLP as a batch

» For quasi-realtime mode, SET can store periodic reports if it wasn’t able to send them at the intended time (i.e. if there was no coverage)

» SLP can allow “intermediate” reports if SET runs out of memory

» SLP can instruct SET to discard oldest or newest data first if intermediate reports not allowed/supported.


22

Triggered Positioning – Area Event Triggering

» Area event triggering can be based on geographic target areas, serving areas of a combination of both

» When combined, serving areas can be used to tell the SET when it doesn’t need to do any positioning (i.e. to save battery life)

» Apart from this, it is up to the SET how often to check its position against the geographic target area

» In the illustrations, opposite, the dotted box is a geographic target area, the hexagons are serving areas

Area ID list

Geographic Target Area

In here, the SET needs to check its position against

the geographic target area.

Out here, the SET doesn’t need to check its position.

Area ID list

Geographic Target Area

In here, the SET doesn’t need to check its position.

Out here, the SET needs to check its position

against the geographic target area.


23

Triggered Positioning – Area Event Triggering II

» Four trigger types supported

» Entering

» Within

» Leaving

» Outside

» Distinction between Entering and Within, Leaving and Outside, happens when combined with repeated reporting

» Leaving trigger with Repeated Reporting

» Report each time SET leaves the area

» Outside trigger with Repeated Reporting

» Report periodically WHILE SET is outside the area

» Likewise for Entering/Inside

Target area

SET starts here

Third report

First reportSecond report

No more reports until SET re-enters and leaves area again

Target area

SET starts here

Reports continue until SET returns to area

Repeated reports at minimum interval Repeated reports at

minimum interval

Repeated reports at minimum interval


24

Triggered Positioning – Periodic Triggering

» For Periodic Triggering, SET initiates position attempts on a periodic basis» SUPL Session can remain open, or can be restarted as

needed» It is up to the SET to keep track of when the next position is

due» Can be combined with batch reporting

» Can be initiated by the SET or the SLP» Saves messaging, especially when combined with batch

reporting» SLP can provide the same functionality for SUPL1.0 SETs by

taking on responsibility of polling SETs at proper interval


25

New Positioning Procedures» Delivery of location to third party

» Allows SET to specify a third party to deliver location to for SI queries

» Delivery mechanism outside of scope of SUPL» SET initiated location retrieval of another SET

» Allows SET to request the location of another SET via the SLP

» Positioning procedure undefined» Retrieval of historical positions

» Allows SLP to request SET to send it stored historical positions

» No mechanism to tell the SET when to store positions in the first place (could interwork with batch reporting)


26

Llp Interface» Standardized interface

between SLC and SPC

» Uses ILP (Internal Location Protocol)

SLC

SPC

SLP

SUPL Location Center

SUPL Location Center


27

Notification and Verification based on current location

» SUPL1.0 allows SLP to instruct SET to

» “notify” user of the location request

» “verify” that the location is permitted (ie. by asking for a user response)

» neither notify or verify

» leave no trace at all (i.e. for lawful intercept, still requires SET cooperation)

» In SUPL2.0, notification and verification request can be sent to SET based on current location

» If user is inside/outside a certain zone, send/don’t send a notification

» Requires slightly different callflow

» Requires H-SLP to maintain privacy profiles for SET

» Defining and managing zones is out of scope for SUPL2.0.


28

Agenda






29

Emergency Services

» Network Initiated Only» Intended for NI

Immediate only too

» SET must now respond to E-SLPs as well as its H-SLP

» Priority given to Emergency requests SET

H-SLP

E- SLP

E-SLP

Visited Network

Home Network

SUPL INIT

SUPL INIT

TLS


30

Emergency Services

»Not covered:» How the query gets to the E-SLP in the first place» How the device is identified as a SET» How the E-SLP determines which SUPL INIT delivery mechanism to use

SET

E- SLP

E-SLP

SUPL INIT

SUPL INIT

TLS

PSAP ?VSP

Call

• Emergency requests are NI-LR-The E-SLP initiates the emergency location procedure


31

Emergency Services

» Basic call flow (Proxy mode)

SUPLAgent

E-SLP Target SET

MLP ELIR (ms-id, client ID, eqop)

SUPL INIT (session-id, posmethod, SLP mode, E-SLP address)

MLP ELIA (posresult)

B

A

C

D

F

E



SUPL POS INIT (session-id, lid, SET capabilities, ver)

Non-roaming VerificationRouting Info


G

H

ST2

UT2

UT3


32

Emergency Services

» Basic call flow (Non-proxy mode)

E-SLPSUPLAgent

Target SET

MLP ELIR(ms-id, client-id, eqop)


B

A

C

D

F

E


G

H

E-SPCE-SLC

Non-roaming Verification, Routing info


I

J


K





ST2

PT1

UT2

UT3

SUPL INIT (session-id, SPC address, posmethod, SLP mode, E-SLP Address)


L

M

SUPL AUTH RESP (session-id, SPC_SET_Key, SPC-TID)UT4



33

Emergency Services» E-SLP enlisting V-SLP to

help locate SET (V-SPC Positioning)

V-SLP

SUPLAgent

Target SET

MLP ELIR (msid, client-id, eqop)

RLP-SSRLIR(SUPL START (session-id, msid, eqop))


B

A

C

D

K

J



V-SLCE-SLP

RLP-SSRP (SUPL END(session-id, posresult)

E

F

G

I

Data connection setup

L

M

N

O

V-SPC



Roaming VerificationRouting Info


ST3

ST2

PT1

UT2

UT3

SUPL AUTH RESP (session-id, SPC_SET_Key, SPC-TID)

RLP-SSRLIA(SUPL RESPONSE (session-id, posmethod V-SPC address))

SUPL INIT (session-id, V-SPC address, posmethod, SLP mode, E-SLP address)


P

UT4

RLP-SSRP(AUTH RESP(session-id, SPC_SET_Key, SPC-TID)

H



SET

V- SLP

E-SLP

Visited Network

Home Network

SUPL INIT

TLSRLP


34

LRF (E-SLP)

UE (SET)

1. Non-Roaming Verification

4. SUPL POS INIT

6. SUPL END

5. SUPL POS (RRLP/RRC/TIA-801) if more accurate position required

2. SUPL INIT

3. Data connection setup

Emergency Services» Compatible with 3GPP

TS 23.167 (IMS Emergency Sessions)

IMS Core

Emerg. Centre

LRF IP-CAN UE

1. Init. Emerg.Call

3. INVITE (emergency)

MGCF/MGW

9. Retrieve location

8. Complete Emergency Call Establishment

11. Return location

7a. INVITE (emergency)

7b. IAM

7c. INVITE (emergency)

10. Procedure to obtain the initial or updated location

12. Release Emergency Call

4. Retrieve Location-routing information

6. Return Location-routing information

5. Procedure to obtain the UE’s location

13. Release call record

2. Acquire location UE-initiated with SUPL must use H-SLP


35

Emergency Services

» SET must accept Emergency SUPL INITs from any E-SLP» SET must have root certificate or shared secret for E-SLP» Whitelist to prioritize known E-SLPs over unknown ones» No explicit way to know for sure that E-SLP is in serving

network» SUPL INITs via secure channels (ie. SIP Push) get

processed immediately, ignoring whitelist

How SET obtains E-SLP whitelist.

How SET obtains credentials for E-SLP.

How ES infrastructure works out which E-SLP will be recognized by SET.

36

Emergency Services» Reduced security requirements for Emergency requests

» No SET-based integrity verification and message origin authentication of SUPL INIT messages

» No end-to-end protection of SUPL INIT messages» Mutual authentication MAY be supported between SLP and SET» For emergency calls initiated in circuit mode, SET IP address may

not be known to E-SLP, hence IP address may not be verified» If alteration of SUPL INIT is detected, SUPL INIT is resent (instead

of terminating the session)» Emergency Queries given priority

» SET must ignore non-emergency SUPL INITs when in emergency mode

» SET must devote all resources to emergency session» Note that this has implications for attempts to use SUPL1.0 for

emergency requests


37

Emergency Services

» Unregistered SETs » Unregistered SETs may respond to SUPL INITs from E-

SLP without any authentication of SET» Support for SIMless emergency requests

» Trust Model» SET is implicitly trusted as part of positioning process» Visited SLPs also implicitly trusted

How E-SLP determines which SLPs to enlist.

Reliable cross-network SUPL INIT delivery.

How E-SLP determines which SUPL INIT delivery mechanism SET supports.

How to tell if a location is being spoofed.

38

SIP Push and Emergency IMS Core

» SIP Push for SUPL INIT delivery supported via Emergency IMS Core

Target SETEmergency IMS

CoreE-SLP

MESSAGE (SUPL INIT)

MESSAGE (SUPL INIT)

200 OK

200 OK

• Takes advantage of secure session already open between SET and IMS Core

• More likely to get through to SET in Emergency mode

• More likely to get past firewalls for cross-network delivery

• Requires collaborative coupling between E-SLP and SIP server


39

SIP Push and Emergency IMS Core

IMS Core

Emerg. Centre

LRF IP-CAN UE

1. Init. Emerg.Call

3. INVITE (emergency)

MGCF/MGW

9. Retrieve location

8. Complete Emergency Call Establishment

11. Return location

7a. INVITE (emergency)

7b. IAM

7c. INVITE (emergency)

10. Procedure to obtain the initial or updated location

12. Release Emergency Call

4. Retrieve Location-routing information

6. Return Location-routing information

5. Procedure to obtain the UE’s location

13. Release call record

2. Acquire location

LRF (E-SLP)

UE (SET)

1. Non-Roaming Verification

4. SUPL POS INIT

6. SUPL END

5. SUPL POS (RRLP/RRC/TIA-801) if more accurate position required

3. Data connection setup

IMS Core

3. MESSAGE (SUPL INIT)

2. MESSAGE( SUPL INIT)


1 SUPL 2.0 Overview Introducing new features with a special focus on Emergency support SDO Emergency...

Documents

Transcript of 1 SUPL 2.0 Overview Introducing new features with a special focus on Emergency support SDO Emergency...