Transcript Document

SUPL 2.0 Overview
Introducing 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
SDOEmergency
EmergencyServices
Services Workshop,
Workshop 23Khiem
October
Tran
2008
1
www.openmobilealliance.org
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
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
What is SUPL?
SET
H-SLP
» A user plane location protocol
» Based around a trust relationship between a terminal (SET) and
its “Home” location server (H-SLP)
SDO Emergency Services Workshop 23 October 2008
4
Why SUPL?
GERA
N
Gb
U
m
U
E
A
I
u
I
u
U
u
UTRAN
I
u
I
u
ECSCF
PP
R
2
MS
G
C
2
SGS
G
N
*Note 3
Lg
Lp
p
OSA SCS
OSA
API
Proprietary
Lc
LRF
Lg
GMLC
* Note 6
Le
Le
Lh
* Note 2
Proprietary
Li
Lg
3
SGS
G
N
Lg
H-SLP
MS
C
server
gsmSC
F
Lid
HS
S 1
*Note
External
LCS
Client
LIMSIWF
SET
* Note 5
PM
D
*Note 4
» Overlay location architecture almost independent of access [1]
» Simpler model compared with control plane
SDO Emergency Services Workshop 23 October 2008
5
SLP network relationship
Home
Network
H-SLP
Home Network
Infrastructure
Visited
Network
SET
Visited Network
Infrastructure
GSM
Visited SLP
» SET always talks only to H-SLP, regardless of access network
» H-SLP has responsibility for finding and enlisting other
resources to locate SET
SDO Emergency Services Workshop 23 October 2008
6
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)
V-SLP
SUPL Agent
Bearer
Networks
WAP PPG
SLP
CDMA
GSM
TLS
over
TCP/IP
SMS/MC
SUPL INIT
delivery via
SMS
WCDMA
SET
SDO Emergency Services Workshop 23 October 2008
7
SUPL INIT
delivery via
WAP
High level characteristics
» Utilises secure
userplane pipe
between SET and
SLP
» Requires explicit
support for each
bearer network
» Trust relationship
between SET and HSLP
» Trusted zone
extends to SET
SDO Emergency Services Workshop 23 October 2008
SUPL Agent
Bearer
Networks
WAP PPG
SLP
CDMA
GSM
TLS
over
TCP/IP
SMS/MC
SUPL INIT SUPL INIT
delivery via delivery via
SMS
WAP
WCDMA
SET
8
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 HSLP, we need…
SLP
TLS
over
TCP/IP
SET
SDO Emergency Services Workshop 23 October 2008
9
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
WAP PPG
H-SLP
SMS/MC
SUPL INIT SUPL INIT
delivery via delivery via
SMS
WAP
SET
SDO Emergency Services Workshop 23 October 2008
10
Proxy Mode vs Non-Proxy Mode
» Two modes of operation. In Proxy Mode, SET connects with HSLP via SLC component. In Non-Proxy Mode, it connects to
both SLC and SPC components.
SUPL
Agent
A
B
H-SLP
SUPL
Agent
MLP SLIR (ms-id, client-id, eqop)
A
SET Lookup,
Routing Info
H-SLC
H-SLP
MLP SLIR(ms-id, client-id, eqop)
SET Lookup, Routing info
Internal Initialization
C
Data Connection
Setup
ST2
SUPL INIT (session-id, SPC address, posmethod, SLP mode)
D
SUPL POS INIT (session-id, lid, SET capabilities, ver)
E
PT1
E
UT2
SUPL POS (session-id, RRLP/RRC/TIA-801)
F
Target SET
H-SPC
B
SUPL INIT (session-id, posmethod, SLP mode)
C
D
Target SET
Data Connection
Setup
SUPL AUTH REQ (session-id, ver)
F
ST2
SUPL END (session-id)
G
H
UT3
MLP SLIA (posresult)
UT4
SUPL AUTH RESP (session-id, SPC_SET_Key, SPC-TID )
Internal Communication
G
SUPL POS INIT (session-id, lid, SET capabilities)
H
Internal Communication
UT2
I
SUPL POS (session-id, RRLP/RRC
/TIA-801)
J
SUPL END (session-id)
K
Internal Communication
L
M
SDO Emergency Services Workshop 23 October 2008
11
MLP SLIA (posresult)
UT3
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 (AGPS)
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
SDO Emergency Services Workshop 23 October 2008
12
SUPL 1.0 Scope
In Scope
Out of Scope
SET and
Network Initiated
Immediate
Requests
Selection of
positioning
technology
How H-SLP
determines
SET is
roaming
Timeliness of
SUPL INIT
delivery
SMS-MT/WAP
Push delivery
Transport for
rest of ULP
(TLS1.0 over
TCP/IP)
Support for
emergency
queries
SUPL INIT
delivery to
visited
network
Is device even
a SET?
Verification of
IP address/
MSISDN for
ACA method
Security for
ULP
One
mandatory
PosProtocol
per bearer
SDO Emergency Services Workshop 23 October 2008
RRLP, RRC,
IS-801
Which methods
of SUPL INIT
delivery
supported by
SET
GSM, CDMA,
WCDMA only
13
Required
network
interactions
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
14
SUPL2.0 Additional Features
Size of SUPL2.0 vs SUPL1.0
(in pages)
» 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
SDO Emergency Services Workshop 23 October 2008
15
SUPL 2.0
» Five new bearer networks
» Two new mechanisms for
SUPL INIT delivery
» Concept of Emergency SLP
(E-SLP)
UDP/IP
Push
Emergency
IMS Core
SUPL Agent
Bearer
Networks
WAP PPG
SLP
CDMA
GSM
WCDMA
WiMAX
SMS/MC
SUPL INIT
delivery via
SMS
HRPD
SET
LTE
UMB
SDO Emergency Services Workshop 23 October 2008
TLS
over
TCP/IP
I-WLAN
16
SUPL INIT
delivery via
WAP
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
17
SUPL INIT Delivery Mechanisms
SIP Push Utilizes existing
secure connection to SET
H-SLP
SIP/IP Core
Target SET
MESSAGE (SUPL INIT)
MESSAGE (SUPL INIT)
200 OK
200 OK
• UDP/IP Push
- UDP datagram to IP address of SET
- Requires IP address to be known
• Neither mandatory for any bearer
SDO Emergency Services Workshop 23 October 2008
18
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
SDO Emergency Services Workshop 23 October 2008
19
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
SDO Emergency Services Workshop 23 October 2008
20
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.
SDO Emergency Services Workshop 23 October 2008
21
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
Out here, the SET doesn’t
need to check its position.
In here, the SET needs to
check its position against
the geographic target
area.
Geographic Target
Area
Area ID list
Out here, the SET needs
to check its position
against the geographic
target area.
In here, the SET doesn’t
need to check its position.
SDO Emergency Services Workshop 23 October 2008
22
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
SDO Emergency Services Workshop 23 October 2008
23
First report
Second report
SET starts here
No more reports until
SET re-enters and
leaves area again
Target area
Third report
Repeated reports at
minimum interval
Repeated reports at
minimum interval
SET starts here
Reports continue until
SET returns to area
Target area
Repeated reports at
minimum interval
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
SDO Emergency Services Workshop 23 October 2008
24
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)
SDO Emergency Services Workshop 23 October 2008
25
Llp Interface
» Standardized interface
between SLC and SPC
» Uses ILP (Internal Location
Protocol)
SLP
SUPL Location
Center
SLC
SUPL Location
Center
SPC
SDO Emergency Services Workshop 23 October 2008
26
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.
SDO Emergency Services Workshop 23 October 2008
27
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
28
Emergency Services
» Network Initiated Only
» Intended for NI
Immediate only too
Home
Network
SUPL INIT
» SET must now respond
to E-SLPs as well as its
H-SLP
E-SLP
H-SLP
TLS
Visited
Network
» Priority given to
Emergency requests
SET
SUPL INIT
E- SLP
SDO Emergency Services Workshop 23 October 2008
29
Emergency Services
• Emergency requests are NI-LR
- The E-SLP initiates the emergency location
procedure
SUPL INIT
?
PSAP
E-SLP
TLS
VSP
Call
SET
SUPL INIT
E- SLP
»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
SDO Emergency Services Workshop 23 October 2008
30
Emergency Services
» Basic call flow
(Proxy mode)
SUPL
Agent
A
B
E-SLP
Target SET
MLP ELIR (ms-id, client ID, eqop)
Non-roaming Verification
Routing Info
SUPL INIT (session-id, posmethod, SLP mode, E-SLP address)
C
Data Connection
Setup
ST2
D
SUPL POS INIT (session-id, lid, SET capabilities, ver)
E
UT2
SUPL POS (session-id, RRLP/RRC/TIA-801)
F
SUPL END (session-id)
G
H
SDO Emergency Services Workshop 23 October 2008
MLP ELIA (posresult)
31
UT3
Emergency Services
SUPL
Agent
» Basic call flow
(Non-proxy
mode)
A
E-SLC
E-SLP
Target SET
E-SPC
MLP ELIR(ms-id, client-id, eqop)
Non-roaming Verification, Routing info
B
Internal Initialization
C
SUPL INIT (session-id, SPC address, posmethod, SLP mode, E-SLP Address)
D
PT1
E
Data Connection
Setup
SUPL AUTH REQ (session-id, ver)
F
ST2
UT4
SUPL AUTH RESP (session-id, SPC_SET_Key, SPC-TID)
Internal Communication
G
SUPL POS INIT (session-id, lid, SET capabilities)
H
Internal Communication
UT2
I
SUPL POS (session-id, RRLP/RRC
/TIA-801)
J
SUPL END (session-id)
K
Internal Communication
L
M
SDO Emergency Services Workshop 23 October 2008
MLP ELIA (posresult)
32
UT3
Emergency Services
» E-SLP enlisting V-SLP to
help locate SET (V-SPC
Positioning)
SUPL
Agent
E-SLP
V-SLC
V-SPC
Target SET
V-SLP
A
MLP ELIR (msid, client-id, eqop)
B
Home
Network
Roaming Verification
Routing Info
RLP-SSRLIR(SUPL START (session-id, msid, eqop))
C
D
SUPL INIT
ST3
E
RLP-SSRLIA(SUPL RESPONSE (session-id, posmethod V-SPC address))
E-SLP
SUPL INIT (session-id, V-SPC address, posmethod, SLP mode, E-SLP address)
F
TLS
RLP
Visited
Network
G
SUPL AUTH REQ (session-id, ver)
RLP-SSRP(AUTH RESP(session-id, SPC_SET_Key, SPC-TID)
Internal Communication
I
SUPL AUTH RESP (session-id, SPC_SET_Key, SPC-TID)
J
ST2
K
V- SLP
SUPL POS INIT (session-id, lid, SET capabilities)
Internal Communication
UT2
SUPL END (session-id)
M
Internal Communication
N
RLP-SSRP (SUPL END(session-id, posresult)
O
SDO Emergency Services Workshop 23 October 2008
UT4
SUPL POS (session-id,
RRLP/RRC/TIA-801)
L
P
Data connection
setup
PT1
H
SET
Internal Initialization
MLP ELIA (posresult)
33
UT3
Emergency Services
» Compatible with 3GPP
TS 23.167 (IMS
Emergency Sessions)
IP-CAN
UE
IMS
Core
LRF
MGCF/
MGW
1. Init. Emerg.Call
UE-initiated with SUPL must use H-SLP
2. Acquire location
3. INVITE (emergency)
UE
(SET)
LRF
(E-SLP)
1. Non-Roaming
Verification
4. Retrieve Location-routing information
5. Procedure to obtain the UE’s location
6. Return Location-routing information
2. SUPL INIT
7a. INVITE (emergency)
7b. IAM
3. Data
connection setup
7c. INVITE (emergency)
4. SUPL POS INIT
8. Complete Emergency Call Establishment
5. SUPL POS (RRLP/RRC/TIA-801) if more
accurate position required
6. SUPL END
9. Retrieve location
10. Procedure to obtain the initial or
updated location
11. Return location
12. Release Emergency Call
13. Release call record
SDO Emergency Services Workshop 23 October 2008
Emerg.
Centre
34
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.
35
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
SDO Emergency Services Workshop 23 October 2008
36
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.
37
SIP Push and Emergency IMS Core
» SIP Push for SUPL INIT delivery supported via Emergency IMS Core
Emergency IMS
Core
Target SET
E-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
SDO Emergency Services Workshop 23 October 2008
38
SIP Push and Emergency IMS Core
IP-CAN
UE
UE
(SET)
LRF
(E-SLP)
IMS
Core
1. Non-Roaming
Verification
LRF
IMS
Core
MGCF/
MGW
1. Init. Emerg.Call
2. Acquire location
3. INVITE (emergency)
2. MESSAGE( SUPL INIT)
4. Retrieve Location-routing information
3. MESSAGE (SUPL INIT)
5. Procedure to obtain the UE’s location
3. Data
connection setup
6. Return Location-routing information
7a. INVITE (emergency)
4. SUPL POS INIT
7b. IAM
7c. INVITE (emergency)
5. SUPL POS (RRLP/RRC/TIA-801) if more
accurate position required
8. Complete Emergency Call Establishment
6. SUPL END
9. Retrieve location
10. Procedure to obtain the initial or updated location
11. Return location
12. Release Emergency Call
13. Release call record
SDO Emergency Services Workshop 23 October 2008
39
Emerg.
Centre