<?xml version="1.0" encoding="utf-8"?>

<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->

<!-- This component and the accompanying materials are made available under the terms of the License 

"Eclipse Public License v1.0" which accompanies this distribution, 

and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->

<!-- Initial Contributors:

    Nokia Corporation - initial contribution.

Contributors: 

-->

<!DOCTYPE concept

  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">

<concept id="GUID-CC3454B1-21DA-542E-8949-52C30755AC77" xml:lang="en"><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: From Symbian^3 the SUPL Protocol Module is deprecated.

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

Proxy Protocol Module</xref></p>

<section id="GUID-6EC5D929-C997-4E95-B9C6-90D10011841E"><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 id="GUID-EC68CF0D-4CB7-48D8-9357-5F43EAAAE613"><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       

         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>              Figure 1. SUPL Protocol Module and associated Symbian

APIs.            </title>

</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              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              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

                  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                 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 href="http://www.openmobilealliance.org" scope="external">Open Mobile Alliance</xref> Secure

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

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

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>

</conbody></concept>