1 / 39

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

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

alvaro
Télécharger la présentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related