12 <concept xml:lang="en" id="GUID-CC3454B1-21DA-542E-8949-52C30755AC77"><title>SUPL Protocol Module Overview</title><shortdesc>The SUPL Protocol Module is a Network Protocol Module provided by Symbian to support the OMA SUPL v1.0 standard. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody><p>Note: The SUPL Protocol Module is deprecated. </p> <section><title>Contents</title> <ul><li id="GUID-AAF9E414-916C-5810-97EE-6CF84A460F3D"><p><xref href="GUID-CC3454B1-21DA-542E-8949-52C30755AC77.dita#GUID-CC3454B1-21DA-542E-8949-52C30755AC77/GUID-21D4CD8B-F260-5552-874B-4D64AE62A082">Purpose</xref>  </p> </li> <li id="GUID-08141A19-B382-546A-8000-ED8F75E40D0D"><p><xref href="GUID-CC3454B1-21DA-542E-8949-52C30755AC77.dita#GUID-CC3454B1-21DA-542E-8949-52C30755AC77/GUID-257A73E7-0B40-5FED-983E-7259379CC462"> Introduction</xref>  </p> </li> <li id="GUID-7B12F3E6-7626-5D81-84F7-3AB2A4BAF89E"><p><xref href="GUID-CC3454B1-21DA-542E-8949-52C30755AC77.dita#GUID-CC3454B1-21DA-542E-8949-52C30755AC77/GUID-F5609EFC-F390-539C-98DB-7A9316DA4087">Key concepts/terms</xref>  </p> </li> <li id="GUID-F803D253-A923-52DD-8412-75B0F74991EC"><p><xref href="GUID-CC3454B1-21DA-542E-8949-52C30755AC77.dita#GUID-CC3454B1-21DA-542E-8949-52C30755AC77/GUID-8D5C2C68-C354-5F07-A430-67A2D77F2484">Architecture</xref>  </p> </li> <li id="GUID-92202EFC-7FFC-5C4C-BDD5-369D8BE2AE87"><p><xref href="GUID-CC3454B1-21DA-542E-8949-52C30755AC77.dita#GUID-CC3454B1-21DA-542E-8949-52C30755AC77/GUID-A5936ED6-6DCD-523E-9C69-D169B3651DED">APIs</xref>  </p> </li> <li id="GUID-32F5425C-8BFB-557E-9FA4-4B0CB7FA81F3"><p><xref href="GUID-CC3454B1-21DA-542E-8949-52C30755AC77.dita#GUID-CC3454B1-21DA-542E-8949-52C30755AC77/GUID-C534504E-AC26-5DBD-8ACB-77D3451CE1B3">SUPL Protocol Module features</xref>  </p> </li> <li id="GUID-CFFD7878-C871-5CA3-B713-5C6EFE0077F0"><p><xref href="GUID-CC3454B1-21DA-542E-8949-52C30755AC77.dita#GUID-CC3454B1-21DA-542E-8949-52C30755AC77/GUID-D5FD2E64-14A2-576C-A23B-7C31932E9FC9">See also</xref>  </p> </li> <li id="GUID-6FC78812-1EF5-517F-A93D-F3AB8EC8DC4A"><p> <xref href="GUID-CC3454B1-21DA-542E-8949-52C30755AC77.dita#GUID-CC3454B1-21DA-542E-8949-52C30755AC77/GUID-CA68D2C5-CEDB-54B7-926F-5866F2C2C12A">References</xref> </p> </li> </ul> </section> <section id="GUID-21D4CD8B-F260-5552-874B-4D64AE62A082"><title>Purpose</title> <p>This document gives an overview of the Symbian SUPL Protocol Module. It describes the module at a high level, including the module's interfaces, dependencies and how it fits into the LBS subsystem. </p> <p>It is intended that Symbian device creators use the reference SUPL Protocol Module in their products. In general, Symbian device creators will not need to write their own SUPL Protocol Module implementation. </p> </section> <section id="GUID-257A73E7-0B40-5FED-983E-7259379CC462"><title>Introduction</title> <p>Secure User Plane Location (SUPL) v1.0 is a standard for enabling Location Based Services defined by the Open Mobile Alliance (OMA) [<xref href="GUID-CC3454B1-21DA-542E-8949-52C30755AC77.dita#GUID-CC3454B1-21DA-542E-8949-52C30755AC77/GUID-CA68D2C5-CEDB-54B7-926F-5866F2C2C12A">1</xref>]. SUPL defines how location requests, responses and assistance data are exchanged between a SUPL Location Platform (SLP) (also referred to as a "SUPL server") and a SUPL Enabled Terminal (SET). Much of the communication between the SLP and a SET is carried on a TCP/IP connection, but WAP or SMS messages are sent from the network to the SET to start a network initiated location request. </p> <p>Using SUPL for network communications offers advantages to network operators. As a 'user plane' protocol supported over TCP/IP, network operators typically find SUPL less expensive to deploy than 'control plane' protocols that use the telephony stack. It must be recognised however, that SUPL v1.0 does not support emergency services location requests and such requests are therefore not supported by the Symbian SUPL Protocol Module. Sending a location from the </p> <p>The SUPL Protocol Module is a <i>reference component</i> supplied by Symbian as an optional part of the LBS subsystem. Its purpose is to enable the Symbian LBS subsystem to support the OMA SUPL v1.0 standard. The Symbian SUPL Protocol Module supports the OMA UserPlane Location Protocol [<xref href="GUID-CC3454B1-21DA-542E-8949-52C30755AC77.dita#GUID-CC3454B1-21DA-542E-8949-52C30755AC77/GUID-CA68D2C5-CEDB-54B7-926F-5866F2C2C12A">2</xref>] with the Radio Resource LCS Protocol (RRLP) [<xref href="GUID-CC3454B1-21DA-542E-8949-52C30755AC77.dita#GUID-CC3454B1-21DA-542E-8949-52C30755AC77/GUID-CA68D2C5-CEDB-54B7-926F-5866F2C2C12A">3</xref>] as the protocol payload. </p> <p>In addition to the SUPL Protocol Module, Symbian also provides supporting plug-ins and APIs to enable the LBS subsystem for SUPL. </p> </section> <section><title>Required background</title> <p>The reader should have some familiarity with the OMA SUPL v1.0 standard. </p> </section> <section id="GUID-F5609EFC-F390-539C-98DB-7A9316DA4087"><title>Key concepts and terms</title> <dl><dlentry><dt>SUPL v1.0</dt> <dd><p>Secure User Plane Location v1.0. A standard defined by the OMA to support Location Based Services. SUPL v1.0 is supported in Symbian LBS by the SUPL Protocol Module. </p> </dd> </dlentry> <dlentry><dt>SET</dt> <dd><p>SUPL Enabled Terminal. A mobile device that can send and receive SUPL messages. The SUPL Protocol Module enables the LBS subsystem to act as a SET in the Proxy Mode as defined by the OMA SUPL v1.0 specification. </p> </dd> </dlentry> <dlentry><dt>SLP</dt> <dd><p>SUPL Location Platform. The server-side platform that supports the SUPL standard. It consists of several functional components [<xref href="GUID-CC3454B1-21DA-542E-8949-52C30755AC77.dita#GUID-CC3454B1-21DA-542E-8949-52C30755AC77/GUID-CA68D2C5-CEDB-54B7-926F-5866F2C2C12A">1</xref>], but includes a networked server to send SUPL messages to SETs and handle responses. Network operators deploy SLPs to support SUPL. The SLP can: </p> <ul><li id="GUID-46C6FA34-6AC6-58EE-8D23-F1A3AB7EC38B"><p>Send WAP Push and/or SMS messages to SETs (via a WAP Push gateway or SMSC) to initiate MT-LRs </p> </li> <li id="GUID-771A6549-DE57-5770-9EB2-B114D1E254D4"><p>Send assistance data to SETs to aid GPS calculations </p> </li> <li id="GUID-F5C1D4E1-D93A-5BF2-AA35-9E050347D65F"><p>Receive GPS measurements from the SET (for terminal assisted GPS positioning mode) </p> </li> <li id="GUID-000BE2B1-7797-5DD0-93E7-E1900AFABB5D"><p>Return calculated GPS position fixes to SETs (for terminal assisted and terminal based GPS positioning modes) </p> </li> </ul> </dd> </dlentry> <dlentry><dt>SPM</dt> <dd><p>SUPL Protocol Module. The reference protocol module provided by Symbian that supports the SUPL v1.0 standard [<xref href="GUID-CC3454B1-21DA-542E-8949-52C30755AC77.dita#GUID-CC3454B1-21DA-542E-8949-52C30755AC77/GUID-CA68D2C5-CEDB-54B7-926F-5866F2C2C12A">1</xref>]. This is a term used by Symbian and is not an OMA defined abbreviation. </p> </dd> </dlentry> <dlentry><dt>SET initiated location request </dt> <dd><p>A request for location that originates from the SET (from an application installed on the device). The SUPL Protocol Module supports SET initiated location requests. </p> <p>The term <i>SET initiated location request</i> is defined by the OMA as part of the SUPL v1.0 standard [<xref href="GUID-CC3454B1-21DA-542E-8949-52C30755AC77.dita#GUID-CC3454B1-21DA-542E-8949-52C30755AC77/GUID-CA68D2C5-CEDB-54B7-926F-5866F2C2C12A">1</xref>]. 3GPP defines the term Mobile Originated Location Request (MO-LR) to describe a location request that originates from a mobile device. </p> <p>The Symbian LBS documentation uses the term MO-LR to describe any location request that originates from a mobile device. </p> </dd> </dlentry> <dlentry><dt> Network initiated location request </dt> <dd><p>A request for location that originates from the SLP and is sent over the network. The SUPL Protocol Module supports network initiated location requests. </p> <p>The term <i>network initiated location request</i> is defined by the OMA as part of the SUPL v1.0 standard [<xref href="GUID-CC3454B1-21DA-542E-8949-52C30755AC77.dita#GUID-CC3454B1-21DA-542E-8949-52C30755AC77/GUID-CA68D2C5-CEDB-54B7-926F-5866F2C2C12A">1</xref>]. 3GPP defines the term Mobile Terminated Location Request (MT-LR) to describe a location request that originates from the network. </p> <p>The Symbian LBS documentation uses the term MT-LR to describe a location request that originates from the network. </p> </dd> </dlentry> <dlentry><dt> WAP Push</dt> <dd><p>In SUPL, WAP Push is the mechanism for sending <codeph>SUPL

    12 <concept id="GUID-CC3454B1-21DA-542E-8949-52C30755AC77" xml:lang="en"><title>SUPL

    13                 INIT</codeph> messages from an SLP to a SET (via a WAP Push gateway) as one method of starting an MT-LR. </p> <p>Symbian provides a WAP Push plug-in that extends the Symbian WAP Push Framework to handle <codeph>SUPL INIT</codeph> messages. The WAP Push plug-in receives <codeph>SUPL INIT</codeph> messages and forwards them to the SUPL Protocol Module. </p> </dd> </dlentry> <dlentry><dt>SMS Trigger</dt> <dd><p>In SUPL, SMS Trigger is an alternative to WAP Push for sending <codeph>SUPL INIT</codeph> messages from an SLP to a SET. </p> <p>Symbian provides a test SMS Trigger plug-in that extends the Symbian Messaging Watcher Framework to handle <codeph>SUPL INIT</codeph> messages. Device creators can use the test SMS Trigger plug-in as the basis for their own implementation. </p> </dd> </dlentry> </dl> </section> <section id="GUID-8D5C2C68-C354-5F07-A430-67A2D77F2484"><title>Architecture</title> <p>Figure 1 shows a component diagram for the SUPL Protocol Module and its relationships with other LBS and Symbian components. </p> <fig id="GUID-48A120E4-D943-5FEF-AFFA-18D898F2B86B"><title>

    13 Protocol Module Overview</title><shortdesc>The SUPL Protocol Module is a Network Protocol Module provided

    14              Figure 1. SUPL Protocol Module and associated Symbian APIs. 

    14 by Symbian to support the OMA SUPL v1.0 standard. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>

    15           </title> <image href="GUID-75BA4518-45DE-5EB4-937E-46C1CFDD0CEB_d0e441123_href.png" placement="inline"/></fig> <p><b>Subsystem components</b> </p> <p>This section describes the subsystem components and APIs that support the SUPL Protocol Module. </p> <p><b>SUPL Protocol Module (SPM) </b> </p> <p>The SUPL Protocol Module implements the <xref href="GUID-8985B028-4BCD-5858-B22F-EECC52B7B9EB.dita">Network Protocol Module API</xref>, which all LBS Network Protocol Modules must use to interface with the LBS subsystem. By installing and configuring the SPM, a device creator can enable a mobile device to act as a SET [<xref href="GUID-CC3454B1-21DA-542E-8949-52C30755AC77.dita#GUID-CC3454B1-21DA-542E-8949-52C30755AC77/GUID-CA68D2C5-CEDB-54B7-926F-5866F2C2C12A">1</xref>]. The SPM is a Symbian reference component and is validated with a commercial SUPL server. </p> <p>The module is an optional LBS component and can be built into a mobile device ROM if SUPL support is required. Note that the SPM is not included in ROM by default. See <xref href="GUID-91F95D0C-E4CF-510E-B280-E27F89274ACE.dita">SUPL Protocol Module Quick Start</xref> for details of how to include the SPM in ROM. </p> <p><b>WAP Push plug-in </b> </p> <p>The WAP Push plug-in is a component that receives <codeph>SUPL

    15 <p>Note: From Symbian^3 the SUPL Protocol Module is deprecated.

    16              INIT</codeph> messages sent via WAP push. The plug-in can be built into devices that operate in networks where WAP Push in the mechanism for delivering <codeph>SUPL INIT</codeph> messages to SETs. The plug-in uses the SUPL Push API to send details of the WAP Push message to the SPM. </p> <p>See <xref href="GUID-91F95D0C-E4CF-510E-B280-E27F89274ACE.dita">SUPL Protocol Module Quick Start</xref> for details of how to include the WAP Push plug-in in ROM (and how to exclude it). </p> <p><b>SMS Trigger plug-in </b> </p> <p>The SMS Trigger plug-in is a test component that receives <codeph>SUPL

    16 For the preferred way of using SUPL see <xref href="GUID-1F7F543A-8A9C-4460-BDB1-A6866E9DF0B9.dita">SUPL

    17              INIT</codeph> messages sent via SMS. The plug-in can be built into devices that operate in networks where SMS Trigger is the mechanism for delivering <codeph>SUPL INIT</codeph> messages to SETs. The plug-in uses the SUPL Push API to send details of the SMS Trigger message to the SPM. </p> <p>See <xref href="GUID-91F95D0C-E4CF-510E-B280-E27F89274ACE.dita">SUPL Protocol Module Quick Start</xref> for details of how to include the SMS Trigger plug-in in ROM (and how to exclude it). </p> <p><b>SUPL Push API </b> </p> <p>The LBS subsystem provides the partner <xref href="GUID-E7DD9CFD-F477-5D25-BC10-BEBFB1022F7E.dita">SUPL Push API</xref>. The API is used to send network initiated location requests (received as <codeph>SUPL INIT</codeph> messages) into the LBS subsystem. </p> <p>The API is used by a WAP Push plug-in or an SMS Trigger plug-in to send notification of a new network initiated location request into the LBS subsystem. </p> <p>If a device creator creates their own WAP Push plug-in or SMS Trigger handler to process <codeph>SUPL INIT</codeph> messages, the components must use the SUPL Push API to send the messages to the SPM. </p> <p><b>Host Settings API </b> </p> <p>The SPM must communicate with one or more SLPs to process MO-LRs and MT-LRs. The SPM needs to know how to read details of SLP host settings. These settings are: </p> <ul><li id="GUID-CA131DC6-B96F-5358-88C7-2F68E708ECD0"><p>The default SLP to use when in the home network and when roaming </p> </li> <li id="GUID-C7DA4720-1BDB-5CA2-9448-58EBD94256AE"><p>The network access point to use for SUPL TCP/IP connections </p> </li> <li id="GUID-A9BEAE36-90F1-5D1F-A930-FCD43DA25619"><p>The type of authentication and data encryption to use over the TCP/IP connection with the SLP </p> </li> </ul> <p>The <xref href="GUID-FE4794F8-2519-5AC2-BCF7-168ECA6645EA.dita">Host Settings API</xref> provides a set of methods to add, modify and delete server host settings. The SPM reads SLP host settings via the Host Settings API. </p> <p>Host Settings can be configured in the following ways: </p> <ul><li id="GUID-BF51896A-B48F-5D95-AAC8-F747E25B7431"><p>Remote configuration of SLP host settings over the network by a Device Management server </p> <p>Symbian provides a Host Settings DM Adapter plug-in that allows a Device Management server to send OMA Device Management messages for SUPL configuration to a mobile device. </p> </li> <li id="GUID-2F0D2F29-A363-5AA2-B77E-B550D4B9459C"><p>Remote configuration of SLP host settings via the Client Provisioning framework </p> <p>Symbian provides a Host Settings CP Adapter plug-in that allows the SUPL host settings to be configured via the Client Provisioning framework. </p> </li> <li id="GUID-81A18847-8F3E-59A7-89CD-AE0B5061F734"><p>Manual configuration of settings </p> <p>The Host Settings API can be used by a device creator's LBS "settings application" to configure the settings manually. </p> </li> </ul> <p><b>Host Settings DM Adapter plug-in </b> </p> <p>The Symbian Device Management (DM) Framework provides the infrastructure to provision mobile device settings remotely (using an OMA Device Management message). As part of its support for SUPL, Symbian provides a Host Settings DM Adapter plug-in. The plug-in manages a DM Management Object for SLP host settings and calls the <xref href="GUID-FE4794F8-2519-5AC2-BCF7-168ECA6645EA.dita">Host Settings API</xref> to set the SUPL server host settings that are used by the SUPL Protocol Module. </p> <p>The DM Adapter plug-in extends the <xref href="GUID-701DB449-D9F6-50D3-A1AF-11808D6570CC.dita">Device Provisioning Framework</xref>. </p> <p><b>Host Settings CP Adapter plug-in </b> </p> <p>The Symbian Client Provisioning (CP) Framework provides the infrastructure to provision mobile device settings either remotely or locally. As part of its support for SUPL, Symbian provides a Host Settings CP Adapter plug-in. The plug-in calls the <xref href="GUID-FE4794F8-2519-5AC2-BCF7-168ECA6645EA.dita">Host Settings API</xref> to set the SUPL server host settings that are used by the SUPL Protocol Module. </p> <p>The CP Adapter plug-in extends the <xref href="GUID-701DB449-D9F6-50D3-A1AF-11808D6570CC.dita">Client Provisioning Framework</xref>. </p> <p><b>ETel Multimode API </b> </p> <p>The SUPL Protocol Module uses the ETel Multimode API to obtain the following information: </p> <ul><li id="GUID-453AB24E-44E6-561F-A4B2-3E875BBBA7B2"><p>Cell ID, location area code, network and country code </p> </li> <li id="GUID-7AB5F949-04D3-5376-A71D-65DE13E4EF4D"><p>The timing advance information required for enhanced Cell ID positioning mode </p> </li> <li id="GUID-3709B390-399A-5C77-B99C-053350270A41"><p>The International Mobile Subscriber Identity (IMSI), which can be used to derive the fully qualified domain name of the home network SLP (H-SLP) as described in [<xref href="GUID-CC3454B1-21DA-542E-8949-52C30755AC77.dita#GUID-CC3454B1-21DA-542E-8949-52C30755AC77/GUID-CA68D2C5-CEDB-54B7-926F-5866F2C2C12A">1</xref>] if the host settings for the H-SLP have not been provisioned by some other means via the <xref href="GUID-FE4794F8-2519-5AC2-BCF7-168ECA6645EA.dita">Host Settings API</xref>. </p> </li> </ul> <p>See <xref href="GUID-91F95D0C-E4CF-510E-B280-E27F89274ACE.dita">SUPL Protocol Module Quick Start</xref> for details of extensions that may need to be added to a device creator's ETel TSY to support the SUPL Protocol Module. </p> <p><b>Pre-Shared Keys (PSK) API </b> </p> <p>Pre-shared keys is a strategy in which keys are pre-shared between a SET and an SLP. PSK-TLS is not currently supported by the SPM. In the future the PSK API will be implemented to obtain a key from a secure location on the handset to allow the SPM to use PSK-TLS. </p> <p><b>Conflict control rules </b> </p> <p>The SUPL Protocol Module supports only one outstanding location request (one session) at any time. Multiple simultaneous location requests (multiple sessions) are not supported by the SUPL Protocol Module or by the LBS subsystem. </p> <p>A conflict occurs if a second location request is received by the SPM while the first request is still outstanding. The SUPL Protocol Module must decide what action to take to resolve the conflict. It must decide which location request is processed and which one is terminated or ignored. </p> <p>The SPM uses a default set of conflict control rules to decide which location request to process. </p> </section> <section id="GUID-A5936ED6-6DCD-523E-9C69-D169B3651DED"><title>APIs</title> <p>This section describes new APIs to support SUPL and APIs that are extended to support SUPL. </p> <p id="GUID-8D47E4F9-020D-53E2-81A5-9A4532AB2E31"><b>New LBS APIs to support SUPL</b> </p> <p>The following lists the LBS APIs introduced to the LBS subsystem to support the SPM. Links can be followed to more detailed documentation: </p> <ul><li id="GUID-A1DA5DD0-AC80-56F8-8A15-C8B7B0BA73BB"><p>The <xref href="GUID-E7DD9CFD-F477-5D25-BC10-BEBFB1022F7E.dita">SUPL Push API</xref> enables WAP Push and SMS Trigger plug-ins to send ULP <codeph>SUPL

    17 Proxy Protocol Module</xref></p>

    18                   INIT</codeph> messages to the SPM. </p> </li> <li id="GUID-A3D471AF-B6C6-5416-871E-6876B1786245"><p>The <xref href="GUID-FE4794F8-2519-5AC2-BCF7-168ECA6645EA.dita">Host Settings API</xref> enables provisioning of SUPL server host settings, or manual configuration of the settings. </p> </li> </ul> <p id="GUID-C3592DBA-E255-55E4-A64F-8220623CF704"><b>LBS APIs extended to support SUPL</b> </p> <p> <i>Note that all extensions to existing LBS APIs to support the SUPL Protocol Module maintain binary compatibility with previous versions of LBS.</i>  </p> <p>In addition to the APIs listed in the previous section, some of the existing LBS APIs are extended to support the SUPL Protocol Module. The following sections describe these API changes: </p> <p id="GUID-E3E19F2B-45E7-58D8-AA1F-9604499BDDB4"><b>Network Protocol Module API </b> </p> <p>A new Network Protocol Module class <xref href="GUID-AD071127-974A-35B4-A39F-340CDC6A1A81.dita"><apiname>CLbsNetworkProtocolBase2</apiname></xref> contains an overloaded method <xref href="GUID-AD071127-974A-35B4-A39F-340CDC6A1A81.dita#GUID-AD071127-974A-35B4-A39F-340CDC6A1A81/GUID-372E95A8-C405-3F95-B778-7D5B4EBECCD9"><apiname>CLbsNetworkProtocolBase2::RespondPrivacyRequest()</apiname></xref> to allow the LBS subsystem to specify to a protocol module the reason why a location request was rejected. The overloaded method contains an output parameter to describe the reason why the request was rejected. </p> <p>The SUPL Protocol Module implements <xref href="GUID-AD071127-974A-35B4-A39F-340CDC6A1A81.dita"><apiname>CLbsNetworkProtocolBase2</apiname></xref> and so can be informed if a location request was rejected because of a conflict between two requests (for example if a network initiated location request is rejected because a SET initiated location request is currently being processed). </p> <p>See <xref href="GUID-8985B028-4BCD-5858-B22F-EECC52B7B9EB.dita">Network Protocol Module API</xref> for more information about <codeph>CLbsNetworkProtocolBase2</codeph> and the Network Protocol Module API extensions. </p> <p>See <xref href="GUID-D9EA897E-71FB-5012-8208-49300A19D22C.dita">LBS sequence diagrams</xref> for details of how the Network Protocol Module API is used at runtime by LBS and the SUPL Protocol Module. </p> <p><b>A-GPS Location Data Source API</b> </p> <p><b>Velocity information </b> </p> <p>The ULP specification [<xref href="GUID-CC3454B1-21DA-542E-8949-52C30755AC77.dita#GUID-CC3454B1-21DA-542E-8949-52C30755AC77/GUID-CA68D2C5-CEDB-54B7-926F-5866F2C2C12A">2</xref>] states that a velocity (a bearing and a speed) should be returned with a position if possible. If a device creator's A-GPS Integration Module is capable of returning a velocity it should do so. An A-GPS Integration Module returns a position info object of class <xref href="GUID-54AE0674-C49D-3329-8B77-3A58EFFC03D7.dita"><apiname>TPositionSatelliteInfo</apiname></xref> when it calculates a position. Class <codeph>TPositionSatelliteInfo</codeph> derives from <xref href="GUID-B4CD3637-0FC6-38B8-AE89-C03EEC83C50D.dita"><apiname>TPositionCourseInfo</apiname></xref>, which contains velocity data members. If the device creator's A-GPS Integration Module can calculate a velocity then it can be returned to the LBS subsystem. </p> <p><b>Assistance data requests </b> </p> <p>As described in <xref href="GUID-8F2BA0D3-1549-5837-A105-3AB484CDB80B.dita">A-GPS Location Data Source API</xref> an A-GPS Integration Module requests the assistance data it requires when it is asked to obtain a position fix. The SUPL Protocol Module may be configured for use when the user is roaming, when data costs are likely to be high. It is therefore important that the device creator's A-GPS Integration Module request only the assistance data it requires, and specify that it does not require any assistance data otherwise. </p> <p><b>Message timing </b> </p> <p>The timing of the messages sent from the SUPL Protocol Module to the LBS subsystem is different to that when using another network protocol. Device creators should not expect precisely the same timing of messages as with any control plane Protocol Module that they may have created. </p> <p>See <xref href="GUID-D9EA897E-71FB-5012-8208-49300A19D22C.dita">LBS sequence diagrams</xref> for more information about runtime behaviour of LBS and the SUPL Protocol Module. </p> <p><b>ETel API</b> </p> <p>Enhanced Cell ID is one of the positioning modes supported by the SUPL Protocol Module. To support this, the ETel API is extended to provide timing advance data to the SUPL Protocol Module. </p> <p>The SPM uses the <xref href="GUID-AA81AFA4-6FAC-3B0D-A082-BE0AEC58CCA8.dita"><apiname>RMobilePhone</apiname></xref> class of the ETel API to obtain Cell ID and timing advance information for basic and enhanced Cell ID positioning. The class <xref href="GUID-AA81AFA4-6FAC-3B0D-A082-BE0AEC58CCA8.dita#GUID-AA81AFA4-6FAC-3B0D-A082-BE0AEC58CCA8/GUID-9E76264C-D087-3D4F-AFC1-523C90231C81"><apiname>RMobilePhone::TMobilePhoneCellInfoV9</apiname></xref> contains the Cell ID and timing advance information. </p> <p>A device creator must implement their ETel TSY to support Cell ID and timing advance information if the SUPL Protocol Module must use Cell Based positioning to obtain a position fix. </p> <p><b>Administration API </b> </p> <p>The <xref href="GUID-23BBC1D8-B3A0-5148-A4F1-22ECF3043E4E.dita">LBS Administration API</xref> is extended to support more than one Network Protocol Module. See <xref href="GUID-91F95D0C-E4CF-510E-B280-E27F89274ACE.dita">SUPL Protocol Module Quick Start</xref> for more information about configuring LBS to use the SUPL Protocol Module. </p> </section> <section id="GUID-C534504E-AC26-5DBD-8ACB-77D3451CE1B3"><title>SUPL Protocol Module features</title> <p>The SPM is a Symbian reference component and it is intended for use by device creators without major modifications. This section describes the features supported by the SPM. </p> <p><b>SUPL v1.0 support </b> </p> <p>The SPM supports the following features of the OMA SUPL 1.0 standard: </p> <ul><li id="GUID-60C920B7-F99D-5156-BA65-B32C3038265C"><p>The SPM supports the OMA SUPL v1.0 standard (version OMA-ERP-SUPL-V1_0-20070615-A). </p> </li> <li id="GUID-54A05D1B-6612-5C2A-A8A6-6E9DCE1B2244"><p>The SPM supports only the SUPL Proxy Mode as defined by the OMA specification. Proxy Mode is the only mode supported on GSM and WCDMA networks. </p> </li> <li id="GUID-566CC5AA-D77D-56F5-8D98-23848D479C05"><p>The SPM supports RRLP as the protocol payload within <codeph>SUPL

    18 <section id="GUID-6EC5D929-C997-4E95-B9C6-90D10011841E"><title>Contents</title> <ul>

    19                 POS</codeph> messages. </p> </li> <li id="GUID-189B1969-990C-5733-B417-8B74F2CE8BAB"><p>The SPM supports SET initiated location requests (known as MO-LR in 3GPP standards). </p> </li> <li id="GUID-F57B3731-0E74-5BF1-BC66-F0936332BC2A"><p>The SPM supports network initiated location requests (known as MT-LR in 3GPP standards). </p> </li> </ul> <p>The following table lists the UserPlane Location Platform [<xref href="GUID-CC3454B1-21DA-542E-8949-52C30755AC77.dita#GUID-CC3454B1-21DA-542E-8949-52C30755AC77/GUID-CA68D2C5-CEDB-54B7-926F-5866F2C2C12A">2</xref>] messages supported by the SPM for MT-LR and MO-LR and the RRLP messages supported within a <codeph>SUPL POS</codeph> message. </p> <table id="GUID-17BFFEFB-5561-5F7F-8780-DDD1FA895558"><tgroup cols="3"><colspec colname="col0"/><colspec colname="col1"/><colspec colname="col2"/><thead><row><entry>MT-LR</entry> <entry>MO-LR</entry> <entry>SUPL POS &lt;RRLP&gt;</entry> </row> </thead> <tbody><row><entry><p> <codeph>SUPL INIT</codeph>  </p> </entry> <entry><p> <codeph> SUPL START</codeph>  </p> </entry> <entry><p>Assistance Data </p> </entry> </row> <row><entry><p> <codeph> SUPL POS INIT</codeph>  </p> </entry> <entry><p> <codeph>SUPL RESPONSE</codeph>  </p> </entry> <entry><p>Assistance Data Ack </p> </entry> </row> <row><entry><p> <codeph> SUPL POS</codeph>  </p> </entry> <entry><p> <codeph> SUPL POS INIT</codeph>  </p> </entry> <entry><p>Measure Position Request </p> </entry> </row> <row><entry><p> <codeph>SUPL END</codeph>  </p> </entry> <entry><p> <codeph>SUPL POS</codeph>  </p> </entry> <entry><p>Measure Position Response </p> </entry> </row> <row><entry><p> </p> </entry> <entry><p> <codeph>SUPL END</codeph>  </p> </entry> <entry><p> </p> </entry> </row> </tbody> </tgroup> </table> <p>A set of sequence diagrams explains the runtime behaviour of the SPM and LBS subsystem. See <xref href="GUID-D9EA897E-71FB-5012-8208-49300A19D22C.dita">LBS sequence diagrams</xref> for full details. </p> <p><b>Support for SET initiated location requests </b> </p> <p>Applications installed on the mobile device use the <xref href="GUID-D0318BB6-0B9F-5A1C-AB0B-61BA22D28661.dita">Location Acquisition API</xref> as usual to obtain a position fix. </p> <p>Location requests are supported using assisted GPS (A-GPS) or cell-based positioning. </p> <p>For SET initiated location requests the SPM performs the following functions for assisted GPS modes: </p> <ul><li id="GUID-A580DA6E-FFED-5BFD-9DD2-DA357D1AE87D"><p>Sends a request to the network to start a positioning session with the SLP. </p> </li> <li id="GUID-F891B82A-B2F6-5F73-885F-788E333F27A0"><p>Receives a response from the SLP that may contain assistance data from the network. The SPM delivers the response to the LBS subsystem. </p> </li> <li id="GUID-1A54750B-790B-520F-94C6-E5F53AC89E82"><p>If the mobile device is in Terminal Assisted Mode it sends the GPS measurements received from the LBS subsystem to the SLP. In Terminal Based Mode the SET sends a location update. </p> </li> <li id="GUID-BD5F21EA-C532-5B4C-8C63-F41D16252C76"><p>If the mobile device is in Terminal Based Mode (and the SLP sent a 'measurement control' message to the terminal) it returns the calculated GPS position to the network. </p> </li> </ul> <p>Note that transmit to third party location requests are not supported by the SUPL v1.0 specification and so are not supported by the SPM. </p> <p><b>Support for network initiated location requests </b> </p> <p>The SUPL Protocol Module supports non-emergency network initiated location requests as specified in SUPL v1.0. </p> <p>Network initiated location requests are sent from the SLP to the SET as a <codeph>SUPL INIT</codeph> message via WAP Push or SMS Trigger. </p> <p><b>Supported positioning modes </b> </p> <p>The SUPL Protocol Module supports the following positioning modes: </p> <ul><li id="GUID-1F9D4FA9-6CEC-5D86-A3C1-8BC2C613F06B"><p>A-GPS SET Based (also known as Terminal Based Mode) </p> </li> <li id="GUID-C025E2B7-DEDB-5057-B58A-0951F55171FB"><p>A-GPS SET Assisted (also known as Terminal Assisted Mode) </p> </li> <li id="GUID-1F874FE4-7717-5E23-A5A6-8AB12D148305"><p>A-GPS Autonomous </p> </li> <li id="GUID-46A82D2F-4D0A-5DE5-9004-39ECECCA5FCC"><p>Cell Based Mode using Cell ID </p> </li> <li id="GUID-76F2237F-05B9-5EE9-962D-66B66E2C7BDE"><p>Cell Based Mode using Enhanced Cell ID (requires a device creator ETel TSY that can supply timing advance information from the network). Note that the positioning methods Enhanced Observed Time Difference (E-OTD) and Observed Time Difference on Arrival (OTDoA) are not supported. </p> </li> </ul> <p>The SPM requests only <b>one</b> positioning mode when it calls the Network Protocol Module API function <xref href="GUID-A97ABAA7-46B0-3E26-97C6-123C92CCEEE4.dita#GUID-A97ABAA7-46B0-3E26-97C6-123C92CCEEE4/GUID-676C6200-0A3A-331D-9776-17CA53E8A1D7"><apiname>MLbsNetworkProtocolObserver::ProcessLocationRequest()</apiname></xref>. Simultaneous support of Terminal Based Mode and Terminal Assisted Modes is not supported by the SPM. </p> <p><b>Configurable conflict control </b> </p> <p>Note that configurable conflict control is not yet supported by the SPM. Details of the rules currently used to handle multiple simultaneous location requests can be found <xref href="GUID-91F95D0C-E4CF-510E-B280-E27F89274ACE.dita">here</xref>. </p> <p>The following describes how configurable conflict control will be implemented in a future release of the SPM: </p> <p>The SPM may be requested to process two location requests simultaneously, for example, it may be processing an MO-LR when an MT-LR is received. This situation may lead to a <i>conflict</i> that must be resolved. </p> <p>To support different strategies for handling conflicts, the SPM will in future use a conflict control plug-in to decide on the action to be taken. A plug-in contains the rules that are applied to resolve a conflict. Different rules can be applied for different conflict situations, for example, conflict between two MO-LRs, two MT-LRs or an MO-LR and an MT-LR. </p> <p><b>SUPL security and authentication </b> </p> <p>The SUPL v1.0 architecture [<xref href="GUID-CC3454B1-21DA-542E-8949-52C30755AC77.dita#GUID-CC3454B1-21DA-542E-8949-52C30755AC77/GUID-CA68D2C5-CEDB-54B7-926F-5866F2C2C12A">1</xref>] mandates mutual authentication between the SLP and the SET. The specification defines two authentication modes: </p> <ul><li id="GUID-6DD2266B-605A-5081-8706-86817B7B9C5C"><p>Pre-Shared Key Ciphersuites for Transport Level Security (PSK-TLS) with the Generic Bootstrapping Architecture (GBA) [<xref href="GUID-CC3454B1-21DA-542E-8949-52C30755AC77.dita#GUID-CC3454B1-21DA-542E-8949-52C30755AC77/GUID-CA68D2C5-CEDB-54B7-926F-5866F2C2C12A">4</xref>]. </p> <p>SUPL v1.0 supports the use of PSK-TLS if both the SET and the SLP support it. The pre-shared key is used for mutual authentication between the SET and the SLP. </p> <p>If PSK-TLS is not supported then Alternative Client Authentication can be used. </p> </li> <li id="GUID-28BA8B23-478B-5487-BC94-8DFE76158B48"><p>Alternative Client authentication (ACA) </p> <p>SUPL v1.0 supports the use of Alternative Client Authentication with server certificates for TLS. </p> </li> </ul> <p>Entries in the SUPL <xref href="GUID-FE4794F8-2519-5AC2-BCF7-168ECA6645EA.dita">Host Settings</xref> data store define the type of authentication and encryption that the SUPL Protocol Module must use for MO-LR and MT-LR. The following levels of authentication and encryption are supported in the SPM (from most to least secure): </p> <ol id="GUID-57A7CAFC-F42D-547D-9AB9-BAFBBD5D2CB4"><li id="GUID-5735297A-8810-5010-88AA-5A53DC9DCD0D"><p>PSK-TLS authentication </p> </li> <li id="GUID-758AFEA4-75A9-532C-BC55-2EA463C301A5"><p>Alternative Client authentication + TLS allowed </p> </li> <li id="GUID-5A74CB5D-EDF4-5AB3-B34E-9A4ADD9870CA"><p>TLS authentication allowed </p> </li> <li id="GUID-7044274C-07C1-5E10-B4D2-89B33DD6F390"><p>No authentication allowed </p> </li> </ol> <p>Note that [<xref href="GUID-CC3454B1-21DA-542E-8949-52C30755AC77.dita#GUID-CC3454B1-21DA-542E-8949-52C30755AC77/GUID-CA68D2C5-CEDB-54B7-926F-5866F2C2C12A">1</xref>] specifies that methods 1 or 2 must be used. Methods 3 and 4 are provided to facilitate testing in non-operational environments. During a SUPL positioning session, the SPM and the SLP negotiate to use the most secure authentication and encryption scheme supported by both of them. </p> <p>The SUPL Protocol Module does not currently support PSK-TLS. ACA-TLS can be configured as described in <xref href="GUID-91F95D0C-E4CF-510E-B280-E27F89274ACE.dita">SUPL Protocol Module Quick Start</xref>. </p> </section> <section id="GUID-CA68D2C5-CEDB-54B7-926F-5866F2C2C12A"><title>References</title> <p>[1] <xref scope="external" href="http://www.openmobilealliance.org">Open Mobile Alliance</xref> Secure User Plane Location (SUPL) Architecture OMA-AD-SUPL-V1_0-20070615-A </p> <p>[2] <xref scope="external" href="http://www.openmobilealliance.org">Open Mobile Alliance</xref> UserPlane Location Protocol (ULP) OMA-TS-ULP-V1_0-20070615-A </p> <p>[3] <xref scope="external" href="http://www.3gpp.org/specs/specs.htm">3GPP</xref> Radio Resource LCS Protocol (RRLP) (3GPP TS 44.031 version 7.5.0 Release 7) </p> <p>[4] <xref scope="external" href="http://www.3gpp.org/specs/specs.htm">3GPP</xref> TS 33.220 Generic Bootstrapping Architecture </p> </section> </conbody></concept>

    19 <li id="GUID-AAF9E414-916C-5810-97EE-6CF84A460F3D"><p><xref href="GUID-CC3454B1-21DA-542E-8949-52C30755AC77.dita#GUID-CC3454B1-21DA-542E-8949-52C30755AC77/GUID-21D4CD8B-F260-5552-874B-4D64AE62A082">Purpose</xref>  </p> </li>

    20 <li id="GUID-08141A19-B382-546A-8000-ED8F75E40D0D"><p><xref href="GUID-CC3454B1-21DA-542E-8949-52C30755AC77.dita#GUID-CC3454B1-21DA-542E-8949-52C30755AC77/GUID-257A73E7-0B40-5FED-983E-7259379CC462"> Introduction</xref>  </p> </li>

    21 <li id="GUID-7B12F3E6-7626-5D81-84F7-3AB2A4BAF89E"><p><xref href="GUID-CC3454B1-21DA-542E-8949-52C30755AC77.dita#GUID-CC3454B1-21DA-542E-8949-52C30755AC77/GUID-F5609EFC-F390-539C-98DB-7A9316DA4087">Key concepts/terms</xref>  </p> </li>

    22 <li id="GUID-F803D253-A923-52DD-8412-75B0F74991EC"><p><xref href="GUID-CC3454B1-21DA-542E-8949-52C30755AC77.dita#GUID-CC3454B1-21DA-542E-8949-52C30755AC77/GUID-8D5C2C68-C354-5F07-A430-67A2D77F2484">Architecture</xref>  </p> </li>

    23 <li id="GUID-92202EFC-7FFC-5C4C-BDD5-369D8BE2AE87"><p><xref href="GUID-CC3454B1-21DA-542E-8949-52C30755AC77.dita#GUID-CC3454B1-21DA-542E-8949-52C30755AC77/GUID-A5936ED6-6DCD-523E-9C69-D169B3651DED">APIs</xref>  </p> </li>

    24 <li id="GUID-32F5425C-8BFB-557E-9FA4-4B0CB7FA81F3"><p><xref href="GUID-CC3454B1-21DA-542E-8949-52C30755AC77.dita#GUID-CC3454B1-21DA-542E-8949-52C30755AC77/GUID-C534504E-AC26-5DBD-8ACB-77D3451CE1B3">SUPL Protocol Module features</xref>  </p> </li>

    25 <li id="GUID-CFFD7878-C871-5CA3-B713-5C6EFE0077F0"><p><xref href="GUID-CC3454B1-21DA-542E-8949-52C30755AC77.dita#GUID-CC3454B1-21DA-542E-8949-52C30755AC77/GUID-D5FD2E64-14A2-576C-A23B-7C31932E9FC9">See also</xref>  </p> </li>

    26 <li id="GUID-6FC78812-1EF5-517F-A93D-F3AB8EC8DC4A"><p> <xref href="GUID-CC3454B1-21DA-542E-8949-52C30755AC77.dita#GUID-CC3454B1-21DA-542E-8949-52C30755AC77/GUID-CA68D2C5-CEDB-54B7-926F-5866F2C2C12A">References</xref> </p> </li>

    27 </ul> </section>

    28 <section id="GUID-21D4CD8B-F260-5552-874B-4D64AE62A082"><title>Purpose</title> <p>This

    29 document gives an overview of the Symbian SUPL Protocol Module. It describes

    30 the module at a high level, including the module's interfaces, dependencies

    31 and how it fits into the LBS subsystem. </p> <p>It is intended that Symbian

    32 device creators use the reference SUPL Protocol Module in their products.

    33 In general, Symbian device creators will not need to write their own SUPL

    34 Protocol Module implementation. </p> </section>

    35 <section id="GUID-257A73E7-0B40-5FED-983E-7259379CC462"><title>Introduction</title> <p>Secure

    36 User Plane Location (SUPL) v1.0 is a standard for enabling Location Based

    37 Services defined by the Open Mobile Alliance (OMA) [<xref href="GUID-CC3454B1-21DA-542E-8949-52C30755AC77.dita#GUID-CC3454B1-21DA-542E-8949-52C30755AC77/GUID-CA68D2C5-CEDB-54B7-926F-5866F2C2C12A">1</xref>]. SUPL defines how location requests, responses and assistance data

    38 are exchanged between a SUPL Location Platform (SLP) (also referred to as

    39 a "SUPL server") and a SUPL Enabled Terminal (SET). Much of the communication

    40 between the SLP and a SET is carried on a TCP/IP connection, but WAP or SMS

    41 messages are sent from the network to the SET to start a network initiated

    42 location request. </p> <p>Using SUPL for network communications offers advantages

    43 to network operators. As a 'user plane' protocol supported over TCP/IP, network

    44 operators typically find SUPL less expensive to deploy than 'control plane'

    45 protocols that use the telephony stack. It must be recognised however, that

    46 SUPL v1.0 does not support emergency services location requests and such requests

    47 are therefore not supported by the Symbian SUPL Protocol Module. Sending a

    48 location from the </p> <p>The SUPL Protocol Module is a <i>reference component</i> supplied

    49 by Symbian as an optional part of the LBS subsystem. Its purpose is to enable

    50 the Symbian LBS subsystem to support the OMA SUPL v1.0 standard. The Symbian

    51 SUPL Protocol Module supports the OMA UserPlane Location Protocol [<xref href="GUID-CC3454B1-21DA-542E-8949-52C30755AC77.dita#GUID-CC3454B1-21DA-542E-8949-52C30755AC77/GUID-CA68D2C5-CEDB-54B7-926F-5866F2C2C12A">2</xref>] with the Radio Resource LCS Protocol (RRLP) [<xref href="GUID-CC3454B1-21DA-542E-8949-52C30755AC77.dita#GUID-CC3454B1-21DA-542E-8949-52C30755AC77/GUID-CA68D2C5-CEDB-54B7-926F-5866F2C2C12A">3</xref>] as the protocol payload. </p> <p>In addition to the SUPL Protocol

    52 Module, Symbian also provides supporting plug-ins and APIs to enable the LBS

    53 subsystem for SUPL. </p> </section>

    54 <section id="GUID-EC68CF0D-4CB7-48D8-9357-5F43EAAAE613"><title>Required background</title> <p>The reader should have some

    55 familiarity with the OMA SUPL v1.0 standard. </p> </section>

    56 <section id="GUID-F5609EFC-F390-539C-98DB-7A9316DA4087"><title>Key concepts

    57 and terms</title> <dl>

    58 <dlentry>

    59 <dt>SUPL v1.0</dt>

    60 <dd><p>Secure User Plane Location v1.0. A standard defined by the OMA to support

    61 Location Based Services. SUPL v1.0 is supported in Symbian LBS by the SUPL

    62 Protocol Module. </p> </dd>

    63 </dlentry>

    64 <dlentry>

    65 <dt>SET</dt>

    66 <dd><p>SUPL Enabled Terminal. A mobile device that can send and receive SUPL

    67 messages. The SUPL Protocol Module enables the LBS subsystem to act as a SET

    68 in the Proxy Mode as defined by the OMA SUPL v1.0 specification. </p> </dd>

    69 </dlentry>

    70 <dlentry>

    71 <dt>SLP</dt>

    72 <dd><p>SUPL Location Platform. The server-side platform that supports the

    73 SUPL standard. It consists of several functional components [<xref href="GUID-CC3454B1-21DA-542E-8949-52C30755AC77.dita#GUID-CC3454B1-21DA-542E-8949-52C30755AC77/GUID-CA68D2C5-CEDB-54B7-926F-5866F2C2C12A">1</xref>], but includes a networked server to send SUPL messages to SETs

    74 and handle responses. Network operators deploy SLPs to support SUPL. The SLP

    75 can: </p> <ul>

    76 <li id="GUID-46C6FA34-6AC6-58EE-8D23-F1A3AB7EC38B"><p>Send WAP Push and/or

    77 SMS messages to SETs (via a WAP Push gateway or SMSC) to initiate MT-LRs </p> </li>

    78 <li id="GUID-771A6549-DE57-5770-9EB2-B114D1E254D4"><p>Send assistance data

    79 to SETs to aid GPS calculations </p> </li>

    80 <li id="GUID-F5C1D4E1-D93A-5BF2-AA35-9E050347D65F"><p>Receive GPS measurements

    81 from the SET (for terminal assisted GPS positioning mode) </p> </li>

    82 <li id="GUID-000BE2B1-7797-5DD0-93E7-E1900AFABB5D"><p>Return calculated GPS

    83 position fixes to SETs (for terminal assisted and terminal based GPS positioning

    84 modes) </p> </li>

    85 </ul> </dd>

    86 </dlentry>

    87 <dlentry>

    88 <dt>SPM</dt>

    89 <dd><p>SUPL Protocol Module. The reference protocol module provided by Symbian

    90 that supports the SUPL v1.0 standard [<xref href="GUID-CC3454B1-21DA-542E-8949-52C30755AC77.dita#GUID-CC3454B1-21DA-542E-8949-52C30755AC77/GUID-CA68D2C5-CEDB-54B7-926F-5866F2C2C12A">1</xref>].

    91 This is a term used by Symbian and is not an OMA defined abbreviation. </p> </dd>

    92 </dlentry>

    93 <dlentry>

    94 <dt>SET initiated location request </dt>

    95 <dd><p>A request for location that originates from the SET (from an application

    96 installed on the device). The SUPL Protocol Module supports SET initiated

    97 location requests. </p> <p>The term <i>SET initiated location request</i> is

    98 defined by the OMA as part of the SUPL v1.0 standard [<xref href="GUID-CC3454B1-21DA-542E-8949-52C30755AC77.dita#GUID-CC3454B1-21DA-542E-8949-52C30755AC77/GUID-CA68D2C5-CEDB-54B7-926F-5866F2C2C12A">1</xref>]. 3GPP defines the term Mobile Originated Location Request (MO-LR)

    99 to describe a location request that originates from a mobile device. </p> <p>The

   100 Symbian LBS documentation uses the term MO-LR to describe any location request

   101 that originates from a mobile device. </p> </dd>

   102 </dlentry>

   103 <dlentry>

   104 <dt> Network initiated location request </dt>

   105 <dd><p>A request for location that originates from the SLP and is sent over

   106 the network. The SUPL Protocol Module supports network initiated location

   107 requests. </p> <p>The term <i>network initiated location request</i> is defined

   108 by the OMA as part of the SUPL v1.0 standard [<xref href="GUID-CC3454B1-21DA-542E-8949-52C30755AC77.dita#GUID-CC3454B1-21DA-542E-8949-52C30755AC77/GUID-CA68D2C5-CEDB-54B7-926F-5866F2C2C12A">1</xref>]. 3GPP defines the term Mobile Terminated Location Request (MT-LR) to describe

   109 a location request that originates from the network. </p> <p>The Symbian LBS

   110 documentation uses the term MT-LR to describe a location request that originates

   111 from the network. </p> </dd>

   112 </dlentry>

   113 <dlentry>

   114 <dt> WAP Push</dt>

   115 <dd><p>In SUPL, WAP Push is the mechanism for sending <codeph>SUPL       

   116          INIT</codeph> messages from an SLP to a SET (via a WAP Push gateway)

   117 as one method of starting an MT-LR. </p> <p>Symbian provides a WAP Push plug-in

   118 that extends the Symbian WAP Push Framework to handle <codeph>SUPL INIT</codeph> messages.

   119 The WAP Push plug-in receives <codeph>SUPL INIT</codeph> messages and forwards

   120 them to the SUPL Protocol Module. </p> </dd>

   121 </dlentry>

   122 <dlentry>

   123 <dt>SMS Trigger</dt>

   124 <dd><p>In SUPL, SMS Trigger is an alternative to WAP Push for sending <codeph>SUPL

   125 INIT</codeph> messages from an SLP to a SET. </p> <p>Symbian provides a test

   126 SMS Trigger plug-in that extends the Symbian Messaging Watcher Framework to

   127 handle <codeph>SUPL INIT</codeph> messages. Device creators can use the test

   128 SMS Trigger plug-in as the basis for their own implementation. </p> </dd>

   129 </dlentry>

   130 </dl> </section>

   131 <section id="GUID-8D5C2C68-C354-5F07-A430-67A2D77F2484"><title>Architecture</title> <p>Figure

   132 1 shows a component diagram for the SUPL Protocol Module and its relationships

   133 with other LBS and Symbian components. </p> <fig id="GUID-48A120E4-D943-5FEF-AFFA-18D898F2B86B">

   134 <title>              Figure 1. SUPL Protocol Module and associated Symbian

   135 APIs.            </title>

   136 <image href="GUID-75BA4518-45DE-5EB4-937E-46C1CFDD0CEB_d0e463037_href.png" placement="inline"/>

   137 </fig> <p><b>Subsystem

   138 components</b> </p> <p>This section describes the subsystem components and

   139 APIs that support the SUPL Protocol Module. </p> <p><b>SUPL Protocol Module (SPM) </b> </p> <p>The SUPL Protocol Module implements

   140 the <xref href="GUID-8985B028-4BCD-5858-B22F-EECC52B7B9EB.dita">Network Protocol

   141 Module API</xref>, which all LBS Network Protocol Modules must use to interface

   142 with the LBS subsystem. By installing and configuring the SPM, a device creator

   143 can enable a mobile device to act as a SET [<xref href="GUID-CC3454B1-21DA-542E-8949-52C30755AC77.dita#GUID-CC3454B1-21DA-542E-8949-52C30755AC77/GUID-CA68D2C5-CEDB-54B7-926F-5866F2C2C12A">1</xref>]. The SPM is a Symbian reference component and is validated with a commercial

   144 SUPL server. </p> <p>The module is an optional LBS component and can be built

   145 into a mobile device ROM if SUPL support is required. Note that the SPM is

   146 not included in ROM by default. See <xref href="GUID-91F95D0C-E4CF-510E-B280-E27F89274ACE.dita">SUPL

   147 Protocol Module Quick Start</xref> for details of how to include the SPM in

   148 ROM. </p> <p><b>WAP Push plug-in </b> </p> <p>The WAP Push plug-in is a component that

   149 receives <codeph>SUPL              INIT</codeph> messages sent via WAP push.

   150 The plug-in can be built into devices that operate in networks where WAP Push

   151 in the mechanism for delivering <codeph>SUPL INIT</codeph> messages to SETs.

   152 The plug-in uses the SUPL Push API to send details of the WAP Push message

   153 to the SPM. </p> <p>See <xref href="GUID-91F95D0C-E4CF-510E-B280-E27F89274ACE.dita">SUPL

   154 Protocol Module Quick Start</xref> for details of how to include the WAP Push

   155 plug-in in ROM (and how to exclude it). </p> <p><b>SMS Trigger plug-in </b> </p> <p>The SMS Trigger plug-in is a test component

   156 that receives <codeph>SUPL              INIT</codeph> messages sent via SMS.

   157 The plug-in can be built into devices that operate in networks where SMS Trigger

   158 is the mechanism for delivering <codeph>SUPL INIT</codeph> messages to SETs.

   159 The plug-in uses the SUPL Push API to send details of the SMS Trigger message

   160 to the SPM. </p> <p>See <xref href="GUID-91F95D0C-E4CF-510E-B280-E27F89274ACE.dita">SUPL

   161 Protocol Module Quick Start</xref> for details of how to include the SMS Trigger

   162 plug-in in ROM (and how to exclude it). </p> <p><b>SUPL Push API </b> </p> <p>The LBS subsystem provides the partner <xref href="GUID-E7DD9CFD-F477-5D25-BC10-BEBFB1022F7E.dita">SUPL Push API</xref>. The

   163 API is used to send network initiated location requests (received as <codeph>SUPL

   164 INIT</codeph> messages) into the LBS subsystem. </p> <p>The API is used by

   165 a WAP Push plug-in or an SMS Trigger plug-in to send notification of a new

   166 network initiated location request into the LBS subsystem. </p> <p>If a device

   167 creator creates their own WAP Push plug-in or SMS Trigger handler to process <codeph>SUPL

   168 INIT</codeph> messages, the components must use the SUPL Push API to send

   169 the messages to the SPM. </p> <p><b>Host Settings API </b> </p> <p>The SPM must communicate with one or more

   170 SLPs to process MO-LRs and MT-LRs. The SPM needs to know how to read details

   171 of SLP host settings. These settings are: </p> <ul>

   172 <li id="GUID-CA131DC6-B96F-5358-88C7-2F68E708ECD0"><p>The default SLP to use

   173 when in the home network and when roaming </p> </li>

   174 <li id="GUID-C7DA4720-1BDB-5CA2-9448-58EBD94256AE"><p>The network access point

   175 to use for SUPL TCP/IP connections </p> </li>

   176 <li id="GUID-A9BEAE36-90F1-5D1F-A930-FCD43DA25619"><p>The type of authentication

   177 and data encryption to use over the TCP/IP connection with the SLP </p> </li>

   178 </ul> <p>The <xref href="GUID-FE4794F8-2519-5AC2-BCF7-168ECA6645EA.dita">Host Settings

   179 API</xref> provides a set of methods to add, modify and delete server host

   180 settings. The SPM reads SLP host settings via the Host Settings API. </p> <p>Host

   181 Settings can be configured in the following ways: </p> <ul>

   182 <li id="GUID-BF51896A-B48F-5D95-AAC8-F747E25B7431"><p>Remote configuration

   183 of SLP host settings over the network by a Device Management server </p> <p>Symbian

   184 provides a Host Settings DM Adapter plug-in that allows a Device Management

   185 server to send OMA Device Management messages for SUPL configuration to a

   186 mobile device. </p> </li>

   187 <li id="GUID-2F0D2F29-A363-5AA2-B77E-B550D4B9459C"><p>Remote configuration

   188 of SLP host settings via the Client Provisioning framework </p> <p>Symbian

   189 provides a Host Settings CP Adapter plug-in that allows the SUPL host settings

   190 to be configured via the Client Provisioning framework. </p> </li>

   191 <li id="GUID-81A18847-8F3E-59A7-89CD-AE0B5061F734"><p>Manual configuration

   192 of settings </p> <p>The Host Settings API can be used by a device creator's

   193 LBS "settings application" to configure the settings manually. </p> </li>

   194 </ul> <p><b>Host Settings DM Adapter plug-in </b> </p> <p>The Symbian Device Management

   195 (DM) Framework provides the infrastructure to provision mobile device settings

   196 remotely (using an OMA Device Management message). As part of its support

   197 for SUPL, Symbian provides a Host Settings DM Adapter plug-in. The plug-in

   198 manages a DM Management Object for SLP host settings and calls the <xref href="GUID-FE4794F8-2519-5AC2-BCF7-168ECA6645EA.dita">Host

   199 Settings API</xref> to set the SUPL server host settings that are used by

   200 the SUPL Protocol Module. </p> <p>The DM Adapter plug-in extends the <xref href="GUID-701DB449-D9F6-50D3-A1AF-11808D6570CC.dita">Device Provisioning Framework</xref>. </p> <p><b>Host Settings CP Adapter plug-in </b> </p> <p>The Symbian Client Provisioning

   201 (CP) Framework provides the infrastructure to provision mobile device settings

   202 either remotely or locally. As part of its support for SUPL, Symbian provides

   203 a Host Settings CP Adapter plug-in. The plug-in calls the <xref href="GUID-FE4794F8-2519-5AC2-BCF7-168ECA6645EA.dita">Host

   204 Settings API</xref> to set the SUPL server host settings that are used by

   205 the SUPL Protocol Module. </p> <p>The CP Adapter plug-in extends the <xref href="GUID-701DB449-D9F6-50D3-A1AF-11808D6570CC.dita">Client Provisioning Framework</xref>. </p> <p><b>ETel Multimode API </b> </p> <p>The SUPL Protocol Module uses the ETel

   206 Multimode API to obtain the following information: </p> <ul>

   207 <li id="GUID-453AB24E-44E6-561F-A4B2-3E875BBBA7B2"><p>Cell ID, location area

   208 code, network and country code </p> </li>

   209 <li id="GUID-7AB5F949-04D3-5376-A71D-65DE13E4EF4D"><p>The timing advance information

   210 required for enhanced Cell ID positioning mode </p> </li>

   211 <li id="GUID-3709B390-399A-5C77-B99C-053350270A41"><p>The International Mobile

   212 Subscriber Identity (IMSI), which can be used to derive the fully qualified

   213 domain name of the home network SLP (H-SLP) as described in [<xref href="GUID-CC3454B1-21DA-542E-8949-52C30755AC77.dita#GUID-CC3454B1-21DA-542E-8949-52C30755AC77/GUID-CA68D2C5-CEDB-54B7-926F-5866F2C2C12A">1</xref>] if the host settings for the H-SLP have not been provisioned by

   214 some other means via the <xref href="GUID-FE4794F8-2519-5AC2-BCF7-168ECA6645EA.dita">Host

   215 Settings API</xref>. </p> </li>

   216 </ul> <p>See <xref href="GUID-91F95D0C-E4CF-510E-B280-E27F89274ACE.dita">SUPL Protocol

   217 Module Quick Start</xref> for details of extensions that may need to be added

   218 to a device creator's ETel TSY to support the SUPL Protocol Module. </p> <p><b>Pre-Shared Keys (PSK) API </b> </p> <p>Pre-shared keys is a strategy in

   219 which keys are pre-shared between a SET and an SLP. PSK-TLS is not currently

   220 supported by the SPM. In the future the PSK API will be implemented to obtain

   221 a key from a secure location on the handset to allow the SPM to use PSK-TLS. </p> <p><b>Conflict control rules </b> </p> <p>The SUPL Protocol Module supports

   222 only one outstanding location request (one session) at any time. Multiple

   223 simultaneous location requests (multiple sessions) are not supported by the

   224 SUPL Protocol Module or by the LBS subsystem. </p> <p>A conflict occurs if

   225 a second location request is received by the SPM while the first request is

   226 still outstanding. The SUPL Protocol Module must decide what action to take

   227 to resolve the conflict. It must decide which location request is processed

   228 and which one is terminated or ignored. </p> <p>The SPM uses a default set

   229 of conflict control rules to decide which location request to process. </p> </section>

   230 <section id="GUID-A5936ED6-6DCD-523E-9C69-D169B3651DED"><title>APIs</title> <p>This

   231 section describes new APIs to support SUPL and APIs that are extended to support

   232 SUPL. </p> <p id="GUID-8D47E4F9-020D-53E2-81A5-9A4532AB2E31"><b>New LBS APIs to support

   233 SUPL</b> </p> <p>The following lists the LBS APIs introduced to the LBS subsystem

   234 to support the SPM. Links can be followed to more detailed documentation: </p> <ul>

   235 <li id="GUID-A1DA5DD0-AC80-56F8-8A15-C8B7B0BA73BB"><p>The <xref href="GUID-E7DD9CFD-F477-5D25-BC10-BEBFB1022F7E.dita">SUPL

   236 Push API</xref> enables WAP Push and SMS Trigger plug-ins to send ULP <codeph>SUPL

   237                   INIT</codeph> messages to the SPM. </p> </li>

   238 <li id="GUID-A3D471AF-B6C6-5416-871E-6876B1786245"><p>The <xref href="GUID-FE4794F8-2519-5AC2-BCF7-168ECA6645EA.dita">Host

   239 Settings API</xref> enables provisioning of SUPL server host settings, or

   240 manual configuration of the settings. </p> </li>

   241 </ul> <p id="GUID-C3592DBA-E255-55E4-A64F-8220623CF704"><b>LBS APIs extended to support

   242 SUPL</b> </p> <p> <i>Note that all extensions to existing LBS APIs to support

   243 the SUPL Protocol Module maintain binary compatibility with previous versions

   244 of LBS.</i>  </p> <p>In addition to the APIs listed in the previous section,

   245 some of the existing LBS APIs are extended to support the SUPL Protocol Module.

   246 The following sections describe these API changes: </p> <p id="GUID-E3E19F2B-45E7-58D8-AA1F-9604499BDDB4"><b>Network Protocol Module

   247 API </b> </p> <p>A new Network Protocol Module class <xref href="GUID-AD071127-974A-35B4-A39F-340CDC6A1A81.dita"><apiname>CLbsNetworkProtocolBase2</apiname></xref> contains

   248 an overloaded method <xref href="GUID-AD071127-974A-35B4-A39F-340CDC6A1A81.dita#GUID-AD071127-974A-35B4-A39F-340CDC6A1A81/GUID-372E95A8-C405-3F95-B778-7D5B4EBECCD9"><apiname>CLbsNetworkProtocolBase2::RespondPrivacyRequest()</apiname></xref> to

   249 allow the LBS subsystem to specify to a protocol module the reason why a location

   250 request was rejected. The overloaded method contains an output parameter to

   251 describe the reason why the request was rejected. </p> <p>The SUPL Protocol

   252 Module implements <xref href="GUID-AD071127-974A-35B4-A39F-340CDC6A1A81.dita"><apiname>CLbsNetworkProtocolBase2</apiname></xref> and so can be

   253 informed if a location request was rejected because of a conflict between

   254 two requests (for example if a network initiated location request is rejected

   255 because a SET initiated location request is currently being processed). </p> <p>See <xref href="GUID-8985B028-4BCD-5858-B22F-EECC52B7B9EB.dita">Network Protocol Module API</xref> for

   256 more information about <codeph>CLbsNetworkProtocolBase2</codeph> and the Network

   257 Protocol Module API extensions. </p> <p>See <xref href="GUID-D9EA897E-71FB-5012-8208-49300A19D22C.dita">LBS

   258 sequence diagrams</xref> for details of how the Network Protocol Module API

   259 is used at runtime by LBS and the SUPL Protocol Module. </p> <p><b>A-GPS Location Data Source API</b> </p> <p><b>Velocity information </b> </p> <p>The ULP specification [<xref href="GUID-CC3454B1-21DA-542E-8949-52C30755AC77.dita#GUID-CC3454B1-21DA-542E-8949-52C30755AC77/GUID-CA68D2C5-CEDB-54B7-926F-5866F2C2C12A">2</xref>] states that a velocity (a bearing and a speed) should be returned

   260 with a position if possible. If a device creator's A-GPS Integration Module

   261 is capable of returning a velocity it should do so. An A-GPS Integration Module

   262 returns a position info object of class <xref href="GUID-54AE0674-C49D-3329-8B77-3A58EFFC03D7.dita"><apiname>TPositionSatelliteInfo</apiname></xref> when

   263 it calculates a position. Class <codeph>TPositionSatelliteInfo</codeph> derives

   264 from <xref href="GUID-B4CD3637-0FC6-38B8-AE89-C03EEC83C50D.dita"><apiname>TPositionCourseInfo</apiname></xref>, which contains velocity data

   265 members. If the device creator's A-GPS Integration Module can calculate a

   266 velocity then it can be returned to the LBS subsystem. </p> <p><b>Assistance data requests </b> </p> <p>As described in <xref href="GUID-8F2BA0D3-1549-5837-A105-3AB484CDB80B.dita">A-GPS

   267 Location Data Source API</xref> an A-GPS Integration Module requests the assistance

   268 data it requires when it is asked to obtain a position fix. The SUPL Protocol

   269 Module may be configured for use when the user is roaming, when data costs

   270 are likely to be high. It is therefore important that the device creator's

   271 A-GPS Integration Module request only the assistance data it requires, and

   272 specify that it does not require any assistance data otherwise. </p> <p><b>Message timing </b> </p> <p>The timing of the messages sent from the SUPL

   273 Protocol Module to the LBS subsystem is different to that when using another

   274 network protocol. Device creators should not expect precisely the same timing

   275 of messages as with any control plane Protocol Module that they may have created. </p> <p>See <xref href="GUID-D9EA897E-71FB-5012-8208-49300A19D22C.dita">LBS sequence diagrams</xref> for

   276 more information about runtime behaviour of LBS and the SUPL Protocol Module. </p> <p><b>ETel API</b> </p> <p>Enhanced Cell ID is one of the positioning modes

   277 supported by the SUPL Protocol Module. To support this, the ETel API is extended

   278 to provide timing advance data to the SUPL Protocol Module. </p> <p>The SPM

   279 uses the <xref href="GUID-AA81AFA4-6FAC-3B0D-A082-BE0AEC58CCA8.dita"><apiname>RMobilePhone</apiname></xref> class of the ETel API to obtain Cell

   280 ID and timing advance information for basic and enhanced Cell ID positioning.

   281 The class <xref href="GUID-AA81AFA4-6FAC-3B0D-A082-BE0AEC58CCA8.dita#GUID-AA81AFA4-6FAC-3B0D-A082-BE0AEC58CCA8/GUID-9E76264C-D087-3D4F-AFC1-523C90231C81"><apiname>RMobilePhone::TMobilePhoneCellInfoV9</apiname></xref> contains

   282 the Cell ID and timing advance information. </p> <p>A device creator must

   283 implement their ETel TSY to support Cell ID and timing advance information

   284 if the SUPL Protocol Module must use Cell Based positioning to obtain a position

   285 fix. </p> <p><b>Administration

   286 API </b> </p> <p>The <xref href="GUID-23BBC1D8-B3A0-5148-A4F1-22ECF3043E4E.dita">LBS

   287 Administration API</xref> is extended to support more than one Network Protocol

   288 Module. See <xref href="GUID-91F95D0C-E4CF-510E-B280-E27F89274ACE.dita">SUPL Protocol

   289 Module Quick Start</xref> for more information about configuring LBS to use

   290 the SUPL Protocol Module. </p> </section>

   291 <section id="GUID-C534504E-AC26-5DBD-8ACB-77D3451CE1B3"><title>SUPL Protocol

   292 Module features</title> <p>The SPM is a Symbian reference component and it

   293 is intended for use by device creators without major modifications. This section

   294 describes the features supported by the SPM. </p> <p><b>SUPL v1.0 support </b> </p> <p>The SPM supports the following features

   295 of the OMA SUPL 1.0 standard: </p> <ul>

   296 <li id="GUID-60C920B7-F99D-5156-BA65-B32C3038265C"><p>The SPM supports the

   297 OMA SUPL v1.0 standard (version OMA-ERP-SUPL-V1_0-20070615-A). </p> </li>

   298 <li id="GUID-54A05D1B-6612-5C2A-A8A6-6E9DCE1B2244"><p>The SPM supports only

   299 the SUPL Proxy Mode as defined by the OMA specification. Proxy Mode is the

   300 only mode supported on GSM and WCDMA networks. </p> </li>

   301 <li id="GUID-566CC5AA-D77D-56F5-8D98-23848D479C05"><p>The SPM supports RRLP

   302 as the protocol payload within <codeph>SUPL                 POS</codeph> messages. </p> </li>

   303 <li id="GUID-189B1969-990C-5733-B417-8B74F2CE8BAB"><p>The SPM supports SET

   304 initiated location requests (known as MO-LR in 3GPP standards). </p> </li>

   305 <li id="GUID-F57B3731-0E74-5BF1-BC66-F0936332BC2A"><p>The SPM supports network

   306 initiated location requests (known as MT-LR in 3GPP standards). </p> </li>

   307 </ul> <p>The following table lists the UserPlane Location Platform [<xref href="GUID-CC3454B1-21DA-542E-8949-52C30755AC77.dita#GUID-CC3454B1-21DA-542E-8949-52C30755AC77/GUID-CA68D2C5-CEDB-54B7-926F-5866F2C2C12A">2</xref>]

   308 messages supported by the SPM for MT-LR and MO-LR and the RRLP messages supported

   309 within a <codeph>SUPL POS</codeph> message. </p> <table id="GUID-17BFFEFB-5561-5F7F-8780-DDD1FA895558">

   310 <tgroup cols="3"><colspec colname="col0"/><colspec colname="col1"/><colspec colname="col2"/>

   311 <thead>

   312 <row>

   313 <entry>MT-LR</entry>

   314 <entry>MO-LR</entry>

   315 <entry>SUPL POS &lt;RRLP&gt;</entry>

   316 </row>

   317 </thead>

   318 <tbody>

   319 <row>

   320 <entry><p> <codeph>SUPL INIT</codeph>  </p> </entry>

   321 <entry><p> <codeph> SUPL START</codeph>  </p> </entry>

   322 <entry><p>Assistance Data </p> </entry>

   323 </row>

   324 <row>

   325 <entry><p> <codeph> SUPL POS INIT</codeph>  </p> </entry>

   326 <entry><p> <codeph>SUPL RESPONSE</codeph>  </p> </entry>

   327 <entry><p>Assistance Data Ack </p> </entry>

   328 </row>

   329 <row>

   330 <entry><p> <codeph> SUPL POS</codeph>  </p> </entry>

   331 <entry><p> <codeph> SUPL POS INIT</codeph>  </p> </entry>

   332 <entry><p>Measure Position Request </p> </entry>

   333 </row>

   334 <row>

   335 <entry><p> <codeph>SUPL END</codeph>  </p> </entry>

   336 <entry><p> <codeph>SUPL POS</codeph>  </p> </entry>

   337 <entry><p>Measure Position Response </p> </entry>

   338 </row>

   339 <row>

   340 <entry><p> </p> </entry>

   341 <entry><p> <codeph>SUPL END</codeph>  </p> </entry>

   342 <entry><p> </p> </entry>

   343 </row>

   344 </tbody>

   345 </tgroup>

   346 </table> <p>A set of sequence diagrams explains the runtime behaviour of the

   347 SPM and LBS subsystem. See <xref href="GUID-D9EA897E-71FB-5012-8208-49300A19D22C.dita">LBS

   348 sequence diagrams</xref> for full details. </p> <p><b>Support for SET initiated location requests </b> </p> <p>Applications

   349 installed on the mobile device use the <xref href="GUID-D0318BB6-0B9F-5A1C-AB0B-61BA22D28661.dita">Location

   350 Acquisition API</xref> as usual to obtain a position fix. </p> <p>Location

   351 requests are supported using assisted GPS (A-GPS) or cell-based positioning. </p> <p>For

   352 SET initiated location requests the SPM performs the following functions for

   353 assisted GPS modes: </p> <ul>

   354 <li id="GUID-A580DA6E-FFED-5BFD-9DD2-DA357D1AE87D"><p>Sends a request to the

   355 network to start a positioning session with the SLP. </p> </li>

   356 <li id="GUID-F891B82A-B2F6-5F73-885F-788E333F27A0"><p>Receives a response

   357 from the SLP that may contain assistance data from the network. The SPM delivers

   358 the response to the LBS subsystem. </p> </li>

   359 <li id="GUID-1A54750B-790B-520F-94C6-E5F53AC89E82"><p>If the mobile device

   360 is in Terminal Assisted Mode it sends the GPS measurements received from the

   361 LBS subsystem to the SLP. In Terminal Based Mode the SET sends a location

   362 update. </p> </li>

   363 <li id="GUID-BD5F21EA-C532-5B4C-8C63-F41D16252C76"><p>If the mobile device

   364 is in Terminal Based Mode (and the SLP sent a 'measurement control' message

   365 to the terminal) it returns the calculated GPS position to the network. </p> </li>

   366 </ul> <p>Note that transmit to third party location requests are not supported

   367 by the SUPL v1.0 specification and so are not supported by the SPM. </p> <p><b>Support for network initiated location requests </b> </p> <p>The SUPL

   368 Protocol Module supports non-emergency network initiated location requests

   369 as specified in SUPL v1.0. </p> <p>Network initiated location requests are

   370 sent from the SLP to the SET as a <codeph>SUPL INIT</codeph> message via WAP

   371 Push or SMS Trigger. </p> <p><b>Supported positioning modes </b> </p> <p>The SUPL Protocol Module supports

   372 the following positioning modes: </p> <ul>

   373 <li id="GUID-1F9D4FA9-6CEC-5D86-A3C1-8BC2C613F06B"><p>A-GPS SET Based (also

   374 known as Terminal Based Mode) </p> </li>

   375 <li id="GUID-C025E2B7-DEDB-5057-B58A-0951F55171FB"><p>A-GPS SET Assisted (also

   376 known as Terminal Assisted Mode) </p> </li>

   377 <li id="GUID-1F874FE4-7717-5E23-A5A6-8AB12D148305"><p>A-GPS Autonomous </p> </li>

   378 <li id="GUID-46A82D2F-4D0A-5DE5-9004-39ECECCA5FCC"><p>Cell Based Mode using

   379 Cell ID </p> </li>

   380 <li id="GUID-76F2237F-05B9-5EE9-962D-66B66E2C7BDE"><p>Cell Based Mode using

   381 Enhanced Cell ID (requires a device creator ETel TSY that can supply timing

   382 advance information from the network). Note that the positioning methods Enhanced

   383 Observed Time Difference (E-OTD) and Observed Time Difference on Arrival (OTDoA)

   384 are not supported. </p> </li>

   385 </ul> <p>The SPM requests only <b>one</b> positioning mode when it calls the

   386 Network Protocol Module API function <xref href="GUID-A97ABAA7-46B0-3E26-97C6-123C92CCEEE4.dita#GUID-A97ABAA7-46B0-3E26-97C6-123C92CCEEE4/GUID-676C6200-0A3A-331D-9776-17CA53E8A1D7"><apiname>MLbsNetworkProtocolObserver::ProcessLocationRequest()</apiname></xref>.

   387 Simultaneous support of Terminal Based Mode and Terminal Assisted Modes is

   388 not supported by the SPM. </p> <p><b>Configurable conflict control </b> </p> <p>Note that configurable conflict

   389 control is not yet supported by the SPM. Details of the rules currently used

   390 to handle multiple simultaneous location requests can be found <xref href="GUID-91F95D0C-E4CF-510E-B280-E27F89274ACE.dita">here</xref>. </p> <p>The

   391 following describes how configurable conflict control will be implemented

   392 in a future release of the SPM: </p> <p>The SPM may be requested to process

   393 two location requests simultaneously, for example, it may be processing an

   394 MO-LR when an MT-LR is received. This situation may lead to a <i>conflict</i> that

   395 must be resolved. </p> <p>To support different strategies for handling conflicts,

   396 the SPM will in future use a conflict control plug-in to decide on the action

   397 to be taken. A plug-in contains the rules that are applied to resolve a conflict.

   398 Different rules can be applied for different conflict situations, for example,

   399 conflict between two MO-LRs, two MT-LRs or an MO-LR and an MT-LR. </p> <p><b>SUPL security and authentication </b> </p> <p>The SUPL v1.0 architecture

   400 [<xref href="GUID-CC3454B1-21DA-542E-8949-52C30755AC77.dita#GUID-CC3454B1-21DA-542E-8949-52C30755AC77/GUID-CA68D2C5-CEDB-54B7-926F-5866F2C2C12A">1</xref>]

   401 mandates mutual authentication between the SLP and the SET. The specification

   402 defines two authentication modes: </p> <ul>

   403 <li id="GUID-6DD2266B-605A-5081-8706-86817B7B9C5C"><p>Pre-Shared Key Ciphersuites

   404 for Transport Level Security (PSK-TLS) with the Generic Bootstrapping Architecture

   405 (GBA) [<xref href="GUID-CC3454B1-21DA-542E-8949-52C30755AC77.dita#GUID-CC3454B1-21DA-542E-8949-52C30755AC77/GUID-CA68D2C5-CEDB-54B7-926F-5866F2C2C12A">4</xref>]. </p> <p>SUPL

   406 v1.0 supports the use of PSK-TLS if both the SET and the SLP support it. The

   407 pre-shared key is used for mutual authentication between the SET and the SLP. </p> <p>If

   408 PSK-TLS is not supported then Alternative Client Authentication can be used. </p> </li>

   409 <li id="GUID-28BA8B23-478B-5487-BC94-8DFE76158B48"><p>Alternative Client authentication

   410 (ACA) </p> <p>SUPL v1.0 supports the use of Alternative Client Authentication

   411 with server certificates for TLS. </p> </li>

   412 </ul> <p>Entries in the SUPL <xref href="GUID-FE4794F8-2519-5AC2-BCF7-168ECA6645EA.dita">Host

   413 Settings</xref> data store define the type of authentication and encryption

   414 that the SUPL Protocol Module must use for MO-LR and MT-LR. The following

   415 levels of authentication and encryption are supported in the SPM (from most

   416 to least secure): </p> <ol id="GUID-57A7CAFC-F42D-547D-9AB9-BAFBBD5D2CB4">

   417 <li id="GUID-5735297A-8810-5010-88AA-5A53DC9DCD0D"><p>PSK-TLS authentication </p> </li>

   418 <li id="GUID-758AFEA4-75A9-532C-BC55-2EA463C301A5"><p>Alternative Client authentication

   419 + TLS allowed </p> </li>

   420 <li id="GUID-5A74CB5D-EDF4-5AB3-B34E-9A4ADD9870CA"><p>TLS authentication allowed </p> </li>

   421 <li id="GUID-7044274C-07C1-5E10-B4D2-89B33DD6F390"><p>No authentication allowed </p> </li>

   422 </ol> <p>Note that [<xref href="GUID-CC3454B1-21DA-542E-8949-52C30755AC77.dita#GUID-CC3454B1-21DA-542E-8949-52C30755AC77/GUID-CA68D2C5-CEDB-54B7-926F-5866F2C2C12A">1</xref>]

   423 specifies that methods 1 or 2 must be used. Methods 3 and 4 are provided to

   424 facilitate testing in non-operational environments. During a SUPL positioning

   425 session, the SPM and the SLP negotiate to use the most secure authentication

   426 and encryption scheme supported by both of them. </p> <p>The SUPL Protocol

   427 Module does not currently support PSK-TLS. ACA-TLS can be configured as described

   428 in <xref href="GUID-91F95D0C-E4CF-510E-B280-E27F89274ACE.dita">SUPL Protocol Module

   429 Quick Start</xref>. </p> </section>

   430 <section id="GUID-CA68D2C5-CEDB-54B7-926F-5866F2C2C12A"><title>References</title> <p>[1] <xref href="http://www.openmobilealliance.org" scope="external">Open Mobile Alliance</xref> Secure

   431 User Plane Location (SUPL) Architecture OMA-AD-SUPL-V1_0-20070615-A </p> <p>[2] <xref href="http://www.openmobilealliance.org" scope="external">Open Mobile Alliance</xref> UserPlane

   432 Location Protocol (ULP) OMA-TS-ULP-V1_0-20070615-A </p> <p>[3] <xref href="http://www.3gpp.org/specs/specs.htm" scope="external">3GPP</xref> Radio Resource LCS Protocol (RRLP) (3GPP TS 44.031

   433 version 7.5.0 Release 7) </p> <p>[4] <xref href="http://www.3gpp.org/specs/specs.htm" scope="external">3GPP</xref> TS 33.220 Generic Bootstrapping Architecture </p> </section>

   434 </conbody></concept>