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

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

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

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

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)

5. Why SUPL? • Overlay location architecture almost independent of access [1] • Simpler model compared with control plane

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

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)

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

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…

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

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.

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

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

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)

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

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

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

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

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)

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 • SUPL Introduction and SUPL 1.0 functionality • SUPL2.0 New Feature Overview • SUPL2.0 Features In Detail • SUPL2.0 from an Emergency Services Perspective

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

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 • Emergency requests are NI-LR • The E-SLP initiates the emergency location procedure

31. Emergency Services • Basic call flow (Proxy mode)

32. Emergency Services • Basic call flow (Non-proxy mode)

33. Emergency Services • E-SLP enlisting V-SLP to help locate SET (V-SPC Positioning)

34. Emergency Services • Compatible with 3GPP TS 23.167 (IMS Emergency Sessions) 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

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

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

39. SIP Push and Emergency IMS Core