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

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

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

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

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

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

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

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

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

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

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

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

SUPL 1.0 Scope SDO Emergency Services Workshop 23 October 2008

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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