SUPL Protocol Module Overview

diff -r 4816d766a08a -r f345bda72bc4 Symbian3/PDK/Source/GUID-CC3454B1-21DA-542E-8949-52C30755AC77.dita --- a/Symbian3/PDK/Source/GUID-CC3454B1-21DA-542E-8949-52C30755AC77.dita Tue Mar 30 11:42:04 2010 +0100 +++ b/Symbian3/PDK/Source/GUID-CC3454B1-21DA-542E-8949-52C30755AC77.dita Tue Mar 30 11:56:28 2010 +0100 @@ -1,19 +1,434 @@ - - - - - -SUPL Protocol Module OverviewThe SUPL Protocol Module is a Network Protocol Module provided by Symbian to support the OMA SUPL v1.0 standard.

Note: The SUPL Protocol Module is deprecated.

Contents

Purpose
Introduction
Key concepts/terms
Architecture
APIs
SUPL Protocol Module features
See also
References

Purpose

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.

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.

Introduction

Secure User Plane Location (SUPL) v1.0 is a standard for enabling Location Based Services defined by the Open Mobile Alliance (OMA) [1]. 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.

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

The SUPL Protocol Module is a reference component 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 [2] with the Radio Resource LCS Protocol (RRLP) [3] as the protocol payload.

In addition to the SUPL Protocol Module, Symbian also provides supporting plug-ins and APIs to enable the LBS subsystem for SUPL.

Required background

The reader should have some familiarity with the OMA SUPL v1.0 standard.

Key concepts and terms

SUPL v1.0: 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.
SET: 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.
SLP: SUPL Location Platform. The server-side platform that supports the SUPL standard. It consists of several functional components [1], but includes a networked server to send SUPL messages to SETs and handle responses. Network operators deploy SLPs to support SUPL. The SLP can:

Send WAP Push and/or SMS messages to SETs (via a WAP Push gateway or SMSC) to initiate MT-LRs

Send assistance data to SETs to aid GPS calculations

Receive GPS measurements from the SET (for terminal assisted GPS positioning mode)

Return calculated GPS position fixes to SETs (for terminal assisted and terminal based GPS positioning modes)
SPM: SUPL Protocol Module. The reference protocol module provided by Symbian that supports the SUPL v1.0 standard [1]. This is a term used by Symbian and is not an OMA defined abbreviation.
SET initiated location request: 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.

The term SET initiated location request is defined by the OMA as part of the SUPL v1.0 standard [1]. 3GPP defines the term Mobile Originated Location Request (MO-LR) to describe a location request that originates from a mobile device.

The Symbian LBS documentation uses the term MO-LR to describe any location request that originates from a mobile device.
Network initiated location request: A request for location that originates from the SLP and is sent over the network. The SUPL Protocol Module supports network initiated location requests.

The term network initiated location request is defined by the OMA as part of the SUPL v1.0 standard [1]. 3GPP defines the term Mobile Terminated Location Request (MT-LR) to describe a location request that originates from the network.

The Symbian LBS documentation uses the term MT-LR to describe a location request that originates from the network.
WAP Push: In SUPL, WAP Push is the mechanism for sending SUPL - INIT messages from an SLP to a SET (via a WAP Push gateway) as one method of starting an MT-LR.

Symbian provides a WAP Push plug-in that extends the Symbian WAP Push Framework to handle SUPL INIT messages. The WAP Push plug-in receives SUPL INIT messages and forwards them to the SUPL Protocol Module.
SMS Trigger: In SUPL, SMS Trigger is an alternative to WAP Push for sending SUPL INIT messages from an SLP to a SET.

Symbian provides a test SMS Trigger plug-in that extends the Symbian Messaging Watcher Framework to handle SUPL INIT messages. Device creators can use the test SMS Trigger plug-in as the basis for their own implementation.

Architecture

Figure 1 shows a component diagram for the SUPL Protocol Module and its relationships with other LBS and Symbian components.

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

Subsystem components

This section describes the subsystem components and APIs that support the SUPL Protocol Module.

SUPL Protocol Module (SPM)

The SUPL Protocol Module implements the Network Protocol Module API, 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 [1]. The SPM is a Symbian reference component and is validated with a commercial SUPL server.

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 SUPL Protocol Module Quick Start for details of how to include the SPM in ROM.

WAP Push plug-in

The WAP Push plug-in is a component that receives SUPL - INIT 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 SUPL INIT messages to SETs. The plug-in uses the SUPL Push API to send details of the WAP Push message to the SPM.

See SUPL Protocol Module Quick Start for details of how to include the WAP Push plug-in in ROM (and how to exclude it).

SMS Trigger plug-in

The SMS Trigger plug-in is a test component that receives SUPL - INIT messages sent via SMS. The plug-in can be built into devices that operate in networks where SMS Trigger is the mechanism for delivering SUPL INIT messages to SETs. The plug-in uses the SUPL Push API to send details of the SMS Trigger message to the SPM.

See SUPL Protocol Module Quick Start for details of how to include the SMS Trigger plug-in in ROM (and how to exclude it).

SUPL Push API

The LBS subsystem provides the partner SUPL Push API. The API is used to send network initiated location requests (received as SUPL INIT messages) into the LBS subsystem.

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.

If a device creator creates their own WAP Push plug-in or SMS Trigger handler to process SUPL INIT messages, the components must use the SUPL Push API to send the messages to the SPM.

Host Settings API

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:

The default SLP to use when in the home network and when roaming
The network access point to use for SUPL TCP/IP connections
The type of authentication and data encryption to use over the TCP/IP connection with the SLP

The Host Settings API provides a set of methods to add, modify and delete server host settings. The SPM reads SLP host settings via the Host Settings API.

Host Settings can be configured in the following ways:

Remote configuration of SLP host settings over the network by a Device Management server

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.
Remote configuration of SLP host settings via the Client Provisioning framework

Symbian provides a Host Settings CP Adapter plug-in that allows the SUPL host settings to be configured via the Client Provisioning framework.
Manual configuration of settings

The Host Settings API can be used by a device creator's LBS "settings application" to configure the settings manually.

Host Settings DM Adapter plug-in

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 Host Settings API to set the SUPL server host settings that are used by the SUPL Protocol Module.

The DM Adapter plug-in extends the Device Provisioning Framework.

Host Settings CP Adapter plug-in

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 Host Settings API to set the SUPL server host settings that are used by the SUPL Protocol Module.

The CP Adapter plug-in extends the Client Provisioning Framework.

ETel Multimode API

The SUPL Protocol Module uses the ETel Multimode API to obtain the following information:

Cell ID, location area code, network and country code
The timing advance information required for enhanced Cell ID positioning mode
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 [1] if the host settings for the H-SLP have not been provisioned by some other means via the Host Settings API.

See SUPL Protocol Module Quick Start for details of extensions that may need to be added to a device creator's ETel TSY to support the SUPL Protocol Module.

Pre-Shared Keys (PSK) API

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.

Conflict control rules

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.

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.

The SPM uses a default set of conflict control rules to decide which location request to process.

APIs

This section describes new APIs to support SUPL and APIs that are extended to support SUPL.

New LBS APIs to support SUPL

The following lists the LBS APIs introduced to the LBS subsystem to support the SPM. Links can be followed to more detailed documentation:

The SUPL Push API enables WAP Push and SMS Trigger plug-ins to send ULP SUPL - INIT messages to the SPM.
The Host Settings API enables provisioning of SUPL server host settings, or manual configuration of the settings.

LBS APIs extended to support SUPL

Note that all extensions to existing LBS APIs to support the SUPL Protocol Module maintain binary compatibility with previous versions of LBS.

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:

Network Protocol Module API

A new Network Protocol Module class CLbsNetworkProtocolBase2 contains an overloaded method CLbsNetworkProtocolBase2::RespondPrivacyRequest() 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.

The SUPL Protocol Module implements CLbsNetworkProtocolBase2 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).

See Network Protocol Module API for more information about CLbsNetworkProtocolBase2 and the Network Protocol Module API extensions.

See LBS sequence diagrams for details of how the Network Protocol Module API is used at runtime by LBS and the SUPL Protocol Module.

A-GPS Location Data Source API

Velocity information

The ULP specification [2] 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 TPositionSatelliteInfo when it calculates a position. Class TPositionSatelliteInfo derives from TPositionCourseInfo, 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.

Assistance data requests

As described in A-GPS Location Data Source API 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.

Message timing

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.

See LBS sequence diagrams for more information about runtime behaviour of LBS and the SUPL Protocol Module.

ETel API

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.

The SPM uses the RMobilePhone class of the ETel API to obtain Cell ID and timing advance information for basic and enhanced Cell ID positioning. The class RMobilePhone::TMobilePhoneCellInfoV9 contains the Cell ID and timing advance information.

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.

Administration API

The LBS Administration API is extended to support more than one Network Protocol Module. See SUPL Protocol Module Quick Start for more information about configuring LBS to use the SUPL Protocol Module.

SUPL Protocol Module features

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.

SUPL v1.0 support

The SPM supports the following features of the OMA SUPL 1.0 standard:

The SPM supports the OMA SUPL v1.0 standard (version OMA-ERP-SUPL-V1_0-20070615-A).
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.
The SPM supports RRLP as the protocol payload within SUPL - POS messages.
The SPM supports SET initiated location requests (known as MO-LR in 3GPP standards).
The SPM supports network initiated location requests (known as MT-LR in 3GPP standards).

The following table lists the UserPlane Location Platform [2] messages supported by the SPM for MT-LR and MO-LR and the RRLP messages supported within a SUPL POS message.

MT-LR MO-LR SUPL POS <RRLP>

SUPL INIT

SUPL START

Assistance Data

SUPL POS INIT

SUPL RESPONSE

Assistance Data Ack

SUPL POS

SUPL POS INIT

Measure Position Request

SUPL END

SUPL POS

Measure Position Response

SUPL END

A set of sequence diagrams explains the runtime behaviour of the SPM and LBS subsystem. See LBS sequence diagrams for full details.

Support for SET initiated location requests

Applications installed on the mobile device use the Location Acquisition API as usual to obtain a position fix.

Location requests are supported using assisted GPS (A-GPS) or cell-based positioning.

For SET initiated location requests the SPM performs the following functions for assisted GPS modes:

Sends a request to the network to start a positioning session with the SLP.
Receives a response from the SLP that may contain assistance data from the network. The SPM delivers the response to the LBS subsystem.
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.
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.

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.

Support for network initiated location requests

The SUPL Protocol Module supports non-emergency network initiated location requests as specified in SUPL v1.0.

Network initiated location requests are sent from the SLP to the SET as a SUPL INIT message via WAP Push or SMS Trigger.

Supported positioning modes

The SUPL Protocol Module supports the following positioning modes:

A-GPS SET Based (also known as Terminal Based Mode)
A-GPS SET Assisted (also known as Terminal Assisted Mode)
A-GPS Autonomous
Cell Based Mode using Cell ID
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.

The SPM requests only one positioning mode when it calls the Network Protocol Module API function MLbsNetworkProtocolObserver::ProcessLocationRequest(). Simultaneous support of Terminal Based Mode and Terminal Assisted Modes is not supported by the SPM.

Configurable conflict control

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

The following describes how configurable conflict control will be implemented in a future release of the SPM:

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 conflict that must be resolved.

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.

SUPL security and authentication

The SUPL v1.0 architecture [1] mandates mutual authentication between the SLP and the SET. The specification defines two authentication modes:

Pre-Shared Key Ciphersuites for Transport Level Security (PSK-TLS) with the Generic Bootstrapping Architecture (GBA) [4].

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.

If PSK-TLS is not supported then Alternative Client Authentication can be used.
Alternative Client authentication (ACA)

SUPL v1.0 supports the use of Alternative Client Authentication with server certificates for TLS.

Entries in the SUPL Host Settings 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):

PSK-TLS authentication
Alternative Client authentication + TLS allowed
TLS authentication allowed
No authentication allowed

Note that [1] 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.

The SUPL Protocol Module does not currently support PSK-TLS. ACA-TLS can be configured as described in SUPL Protocol Module Quick Start.

References

[1] Open Mobile Alliance Secure User Plane Location (SUPL) Architecture OMA-AD-SUPL-V1_0-20070615-A

[2] Open Mobile Alliance UserPlane Location Protocol (ULP) OMA-TS-ULP-V1_0-20070615-A

[3] 3GPP Radio Resource LCS Protocol (RRLP) (3GPP TS 44.031 version 7.5.0 Release 7)

[4] 3GPP TS 33.220 Generic Bootstrapping Architecture

\ No newline at end of file + + + + + +SUPL +Protocol Module OverviewThe SUPL Protocol Module is a Network Protocol Module provided +by Symbian to support the OMA SUPL v1.0 standard. +

Note: From Symbian^3 the SUPL Protocol Module is deprecated. +For the preferred way of using SUPL see SUPL +Proxy Protocol Module

Contents

Purpose
Introduction
Key concepts/terms
Architecture
APIs
SUPL Protocol Module features
See also
References

Purpose

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.

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.

Introduction

Secure +User Plane Location (SUPL) v1.0 is a standard for enabling Location Based +Services defined by the Open Mobile Alliance (OMA) [1]. 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.

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

The SUPL Protocol Module is a reference component 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 [2] with the Radio Resource LCS Protocol (RRLP) [3] as the protocol payload.

In addition to the SUPL Protocol +Module, Symbian also provides supporting plug-ins and APIs to enable the LBS +subsystem for SUPL.

Required background

The reader should have some +familiarity with the OMA SUPL v1.0 standard.

Key concepts +and terms

SUPL v1.0: 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.
SET: 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.
SLP: SUPL Location Platform. The server-side platform that supports the +SUPL standard. It consists of several functional components [1], but includes a networked server to send SUPL messages to SETs +and handle responses. Network operators deploy SLPs to support SUPL. The SLP +can:

+
Send WAP Push and/or +SMS messages to SETs (via a WAP Push gateway or SMSC) to initiate MT-LRs

+
Send assistance data +to SETs to aid GPS calculations

+
Receive GPS measurements +from the SET (for terminal assisted GPS positioning mode)

+
Return calculated GPS +position fixes to SETs (for terminal assisted and terminal based GPS positioning +modes)

+
SPM: SUPL Protocol Module. The reference protocol module provided by Symbian +that supports the SUPL v1.0 standard [1]. +This is a term used by Symbian and is not an OMA defined abbreviation.
SET initiated location request: 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.

The term SET initiated location request is +defined by the OMA as part of the SUPL v1.0 standard [1]. 3GPP defines the term Mobile Originated Location Request (MO-LR) +to describe a location request that originates from a mobile device.

The +Symbian LBS documentation uses the term MO-LR to describe any location request +that originates from a mobile device.
Network initiated location request: A request for location that originates from the SLP and is sent over +the network. The SUPL Protocol Module supports network initiated location +requests.

The term network initiated location request is defined +by the OMA as part of the SUPL v1.0 standard [1]. 3GPP defines the term Mobile Terminated Location Request (MT-LR) to describe +a location request that originates from the network.

The Symbian LBS +documentation uses the term MT-LR to describe a location request that originates +from the network.
WAP Push: In SUPL, WAP Push is the mechanism for sending SUPL + INIT messages from an SLP to a SET (via a WAP Push gateway) +as one method of starting an MT-LR.

Symbian provides a WAP Push plug-in +that extends the Symbian WAP Push Framework to handle SUPL INIT messages. +The WAP Push plug-in receives SUPL INIT messages and forwards +them to the SUPL Protocol Module.
SMS Trigger: In SUPL, SMS Trigger is an alternative to WAP Push for sending SUPL +INIT messages from an SLP to a SET.

Symbian provides a test +SMS Trigger plug-in that extends the Symbian Messaging Watcher Framework to +handle SUPL INIT messages. Device creators can use the test +SMS Trigger plug-in as the basis for their own implementation.

Architecture

Figure +1 shows a component diagram for the SUPL Protocol Module and its relationships +with other LBS and Symbian components.

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

Subsystem +components

This section describes the subsystem components and +APIs that support the SUPL Protocol Module.

SUPL Protocol Module (SPM)

The SUPL Protocol Module implements +the Network Protocol +Module API, 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 [1]. The SPM is a Symbian reference component and is validated with a commercial +SUPL server.

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 SUPL +Protocol Module Quick Start for details of how to include the SPM in +ROM.

WAP Push plug-in

The WAP Push plug-in is a component that +receives SUPL INIT 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 SUPL INIT messages to SETs. +The plug-in uses the SUPL Push API to send details of the WAP Push message +to the SPM.

See SUPL +Protocol Module Quick Start for details of how to include the WAP Push +plug-in in ROM (and how to exclude it).

SMS Trigger plug-in

The SMS Trigger plug-in is a test component +that receives SUPL INIT messages sent via SMS. +The plug-in can be built into devices that operate in networks where SMS Trigger +is the mechanism for delivering SUPL INIT messages to SETs. +The plug-in uses the SUPL Push API to send details of the SMS Trigger message +to the SPM.

See SUPL +Protocol Module Quick Start for details of how to include the SMS Trigger +plug-in in ROM (and how to exclude it).

SUPL Push API

The LBS subsystem provides the partner SUPL Push API. The +API is used to send network initiated location requests (received as SUPL +INIT messages) into the LBS subsystem.

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.

If a device +creator creates their own WAP Push plug-in or SMS Trigger handler to process SUPL +INIT messages, the components must use the SUPL Push API to send +the messages to the SPM.

Host Settings API

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:

The default SLP to use +when in the home network and when roaming
The network access point +to use for SUPL TCP/IP connections
The type of authentication +and data encryption to use over the TCP/IP connection with the SLP

The Host Settings +API provides a set of methods to add, modify and delete server host +settings. The SPM reads SLP host settings via the Host Settings API.

Host +Settings can be configured in the following ways:

Remote configuration +of SLP host settings over the network by a Device Management server

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.
Remote configuration +of SLP host settings via the Client Provisioning framework

Symbian +provides a Host Settings CP Adapter plug-in that allows the SUPL host settings +to be configured via the Client Provisioning framework.
Manual configuration +of settings

The Host Settings API can be used by a device creator's +LBS "settings application" to configure the settings manually.

Host Settings DM Adapter plug-in

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 Host +Settings API to set the SUPL server host settings that are used by +the SUPL Protocol Module.

The DM Adapter plug-in extends the Device Provisioning Framework.

Host Settings CP Adapter plug-in

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 Host +Settings API to set the SUPL server host settings that are used by +the SUPL Protocol Module.

The CP Adapter plug-in extends the Client Provisioning Framework.

ETel Multimode API

The SUPL Protocol Module uses the ETel +Multimode API to obtain the following information:

Cell ID, location area +code, network and country code
The timing advance information +required for enhanced Cell ID positioning mode
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 [1] if the host settings for the H-SLP have not been provisioned by +some other means via the Host +Settings API.

See SUPL Protocol +Module Quick Start for details of extensions that may need to be added +to a device creator's ETel TSY to support the SUPL Protocol Module.

Pre-Shared Keys (PSK) API

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.

Conflict control rules

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.

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.

The SPM uses a default set +of conflict control rules to decide which location request to process.

APIs

This +section describes new APIs to support SUPL and APIs that are extended to support +SUPL.

New LBS APIs to support +SUPL

The following lists the LBS APIs introduced to the LBS subsystem +to support the SPM. Links can be followed to more detailed documentation:

The SUPL +Push API enables WAP Push and SMS Trigger plug-ins to send ULP SUPL + INIT messages to the SPM.
The Host +Settings API enables provisioning of SUPL server host settings, or +manual configuration of the settings.

LBS APIs extended to support +SUPL

Note that all extensions to existing LBS APIs to support +the SUPL Protocol Module maintain binary compatibility with previous versions +of LBS.

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:

Network Protocol Module +API

A new Network Protocol Module class CLbsNetworkProtocolBase2 contains +an overloaded method CLbsNetworkProtocolBase2::RespondPrivacyRequest() 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.

The SUPL Protocol +Module implements CLbsNetworkProtocolBase2 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).

See Network Protocol Module API for +more information about CLbsNetworkProtocolBase2 and the Network +Protocol Module API extensions.

See LBS +sequence diagrams for details of how the Network Protocol Module API +is used at runtime by LBS and the SUPL Protocol Module.

A-GPS Location Data Source API

Velocity information

The ULP specification [2] 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 TPositionSatelliteInfo when +it calculates a position. Class TPositionSatelliteInfo derives +from TPositionCourseInfo, 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.

Assistance data requests

As described in A-GPS +Location Data Source API 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.

Message timing

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.

See LBS sequence diagrams for +more information about runtime behaviour of LBS and the SUPL Protocol Module.

ETel API

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.

The SPM +uses the RMobilePhone class of the ETel API to obtain Cell +ID and timing advance information for basic and enhanced Cell ID positioning. +The class RMobilePhone::TMobilePhoneCellInfoV9 contains +the Cell ID and timing advance information.

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.

Administration +API

The LBS +Administration API is extended to support more than one Network Protocol +Module. See SUPL Protocol +Module Quick Start for more information about configuring LBS to use +the SUPL Protocol Module.

SUPL Protocol +Module features

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.

SUPL v1.0 support

The SPM supports the following features +of the OMA SUPL 1.0 standard:

The SPM supports the +OMA SUPL v1.0 standard (version OMA-ERP-SUPL-V1_0-20070615-A).
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.
The SPM supports RRLP +as the protocol payload within SUPL POS messages.
The SPM supports SET +initiated location requests (known as MO-LR in 3GPP standards).
The SPM supports network +initiated location requests (known as MT-LR in 3GPP standards).

The following table lists the UserPlane Location Platform [2] +messages supported by the SPM for MT-LR and MO-LR and the RRLP messages supported +within a SUPL POS message.

+ + + +MT-LR +MO-LR +SUPL POS <RRLP> + + + + +

SUPL INIT

SUPL START

Assistance Data

+ + +

SUPL POS INIT

SUPL RESPONSE

Assistance Data Ack

+ + +

SUPL POS

SUPL POS INIT

Measure Position Request

+ + +

SUPL END

SUPL POS

Measure Position Response

+ + +

SUPL END

+ + + +

A set of sequence diagrams explains the runtime behaviour of the +SPM and LBS subsystem. See LBS +sequence diagrams for full details.

Support for SET initiated location requests

Applications +installed on the mobile device use the Location +Acquisition API as usual to obtain a position fix.

Location +requests are supported using assisted GPS (A-GPS) or cell-based positioning.

For +SET initiated location requests the SPM performs the following functions for +assisted GPS modes:

Sends a request to the +network to start a positioning session with the SLP.
Receives a response +from the SLP that may contain assistance data from the network. The SPM delivers +the response to the LBS subsystem.
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.
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.

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.

Support for network initiated location requests

The SUPL +Protocol Module supports non-emergency network initiated location requests +as specified in SUPL v1.0.

Network initiated location requests are +sent from the SLP to the SET as a SUPL INIT message via WAP +Push or SMS Trigger.

Supported positioning modes

The SUPL Protocol Module supports +the following positioning modes:

A-GPS SET Based (also +known as Terminal Based Mode)
A-GPS SET Assisted (also +known as Terminal Assisted Mode)
A-GPS Autonomous
Cell Based Mode using +Cell ID
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.

The SPM requests only one positioning mode when it calls the +Network Protocol Module API function MLbsNetworkProtocolObserver::ProcessLocationRequest(). +Simultaneous support of Terminal Based Mode and Terminal Assisted Modes is +not supported by the SPM.

Configurable conflict control

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

The +following describes how configurable conflict control will be implemented +in a future release of the SPM:

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 conflict that +must be resolved.

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.

SUPL security and authentication

The SUPL v1.0 architecture +[1] +mandates mutual authentication between the SLP and the SET. The specification +defines two authentication modes:

Pre-Shared Key Ciphersuites +for Transport Level Security (PSK-TLS) with the Generic Bootstrapping Architecture +(GBA) [4].

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.

If +PSK-TLS is not supported then Alternative Client Authentication can be used.
Alternative Client authentication +(ACA)

SUPL v1.0 supports the use of Alternative Client Authentication +with server certificates for TLS.

Entries in the SUPL Host +Settings 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):

PSK-TLS authentication
Alternative Client authentication ++ TLS allowed
TLS authentication allowed
No authentication allowed

Note that [1] +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.

The SUPL Protocol +Module does not currently support PSK-TLS. ACA-TLS can be configured as described +in SUPL Protocol Module +Quick Start.

References

[1] Open Mobile Alliance Secure +User Plane Location (SUPL) Architecture OMA-AD-SUPL-V1_0-20070615-A

[2] Open Mobile Alliance UserPlane +Location Protocol (ULP) OMA-TS-ULP-V1_0-20070615-A

[3] 3GPP Radio Resource LCS Protocol (RRLP) (3GPP TS 44.031 +version 7.5.0 Release 7)

[4] 3GPP TS 33.220 Generic Bootstrapping Architecture

+ \ No newline at end of file