1. 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 Emergency Services Workshop, Khiem Tran
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. 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

4. What is SUPL? 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

5. Why SUPL?
Overlay location architecture almost independent of access [1]
Simpler model compared with control plane
SDO Emergency Services Workshop 23 October 2008

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
SDO Emergency Services Workshop 23 October 2008

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)
SDO Emergency Services Workshop 23 October 2008

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
SDO Emergency Services Workshop 23 October 2008

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…
SDO Emergency Services Workshop 23 October 2008

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
SDO Emergency Services Workshop 23 October 2008

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.
SDO Emergency Services Workshop 23 October 2008

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
SDO Emergency Services Workshop 23 October 2008

13. SUPL 1.0 Scope
SDO Emergency Services Workshop 23 October 2008

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

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)
SDO Emergency Services Workshop 23 October 2008

16. SUPL 2.0 Five new bearer networks
Two new mechanisms for SUPL INIT delivery
Concept of Emergency SLP (E-SLP)
SDO Emergency Services Workshop 23 October 2008

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

18. SUPL INIT Delivery Mechanisms
SIP Push Utilizes existing secure connection to SET
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

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
SDO Emergency Services Workshop 23 October 2008

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
SDO Emergency Services Workshop 23 October 2008

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.
SDO Emergency Services Workshop 23 October 2008

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
SDO Emergency Services Workshop 23 October 2008

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
SDO Emergency Services Workshop 23 October 2008

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
SDO Emergency Services Workshop 23 October 2008

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)
SDO Emergency Services Workshop 23 October 2008

26. Llp Interface Standardized interface between SLC and SPC
Uses ILP (Internal Location Protocol)
SDO Emergency Services Workshop 23 October 2008

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.
Out of scope – how user updates privacy profiles
Similar functionality could also be achieved on SET itself without this feature
SDO Emergency Services Workshop 23 October 2008

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

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
During an Emergency Call, SET SHALL terminate non-emergency SUPL sessions and ignore non-emergency SUPL INITs
Note that this means SUPL 1.0 SUPL INITs will be ignored
OUT OF SCOPE: conditions on when SET will accept Emergency SUPL INITs (may be determined by local regulatory requirements)
Note that this may include a period of time after an Emergency call.
SDO Emergency Services Workshop 23 October 2008

30. Emergency Services Emergency requests are NI-LR Not covered:
The E-SLP initiates the emergency location procedure
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

31. Emergency Services Basic call flow (Proxy mode)
SDO Emergency Services Workshop 23 October 2008

32. Emergency Services Basic call flow (Non-proxy mode)
SDO Emergency Services Workshop 23 October 2008

33. Emergency Services
E-SLP enlisting V-SLP to help locate SET (V-SPC Positioning)
SDO Emergency Services Workshop 23 October 2008

34. Emergency Services
Compatible with 3GPP TS (IMS Emergency Sessions)
UE-initiated with SUPL must use H-SLP
SDO Emergency Services Workshop 23 October 2008

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

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
SDO Emergency Services Workshop 23 October 2008

37. Emergency Services Unregistered SETs Trust Model
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

38. SIP Push and Emergency IMS Core
SIP Push for SUPL INIT delivery supported via Emergency IMS Core
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
Note: The E-SLP receives the emergency location request from the Emergency IMS Core over 3GPP Ml interface or from the PSAP over the Le interface. The emergency location request contains the SIP URI or TEL URI of the SET initiated the IMS emergency call. The Emergency IMS Core uses the Request URI to correlate the SIP MESSAGE with the IMS emergency call and routes the SIP MESSAGE to the SET via the signaling path of the IMS emergency call. The specifics of 3GPP Ml interface and Le interface are considered outside scope of SUPL.
SDO Emergency Services Workshop 23 October 2008

39. SIP Push and Emergency IMS Core
SDO Emergency Services Workshop 23 October 2008