Note: The SUPL Push API is deprecated.
This document describes the SUPL Push API which is used to process
This document is intended for Symbian licensees who want to create their own handlers to process
Secure User Plane Location (SUPL) is a standard for enabling Location Based Services using IP for most of the communication between a SET and an SLP. To start a network initiated request, the SLP must send a
To start a location request, the SLP sends a
To support SUPL, the LBS subsystem ROM is built to include the SUPL WAP Push plug-in or an SMS Trigger plug-in as described in
The
A licensee can also create their own
The SLP and the SET process the location request as described in
Symbian provides two plug-ins that can process
The SUPL WAP Push plug-in receives
The Symbian test SUPL SMS Trigger plug-in receives
The SUPL WAP Push handler plug-in and SUPL SMS Trigger plug-in use the SUPL Push API to notify the SUPL Protocol Module that an SLP is starting a network initiated location request.
SUPL WAP Push plug-in
The Symbian platform includes the WAP Push Framework to process WAP Push messages. If the Symbian SUPL WAP Push plug-in is installed, the WAP Push Framework uses it to process
The SUPL WAP Push handler plug-in is a production component. Licensees can install the plug-in in their ROM so that it is available to the WAP Push Framework. Licensees do not need to develop their own WAP Push handler plug-in. See
Source code for the WAP Push plug-in can be found at
SUPL SMS Trigger plug-in
If the Symbian SUPL SMS Trigger plug-in is installed, it is loaded on OS startup by the Watcher Framework, which uses it to process
Source code for the SMS Trigger plug-in can be found at
The SUPL Push API is used to notify the SUPL Protocol Module that a SUPL INIT message was received from an SLP to start a network location request.
The SUPL API has two different types of client:
Clients that receive
Clients that require notification of
The SUPL Push API has
SUPL Push API sender classes
This section describes the classes of the SUPL Push API that the SUPL WAP Push handler plug-in and SUPL SMS Trigger plug-in use to send
Request queueing
The SUPL Push API uses Publish and Subscribe (P&S) properties to store the details of
One potential problem with using P&S properties occurs in the situation where multiple calls to
The implementation of the SUPL Push API queues
API restrictions
The SUPL Push API can be used by up to two threads, each of which must use a different 'channel' as specified by
A single thread in an API client can create multiple instances of
The Symbian WAP Push Framework instantiates multiple copies of the SUPL WAP Push plug-in to handle multiple
There is only one instance of the Symbian test SUPL SMS Trigger plug-in which is loaded by the Messaging Watcher Framework and all messages are processed by the same thread.
Licensees who implement their own method of handing
A maximum total of two threads can use the API concurrently.
Each thread must use a different 'channel'.
SUPL Push API receiver classes
This section describes the classes of the SUPL Push API that the SUPL Protocol Module uses to receive
Figure 3 shows the SUPL Push API receiver classes. Symbian licensees do not need to use the receiver classes - they are used by the Symbian reference SUPL Protocol Module.
The SUPL Protocol Module implements
The SUPL Protocol Module calls
The SUPL Push API is packaged in
API clients require
Figure 4 is a simple sequence diagram showing the WAP Push plug-in receiving a
An SMS Trigger plug-in would use the channel
The error parameter
Note that the SUPL Protocol Module calls
[1]
Note: From Symbian^3 the SUPL Protocol Module is deprecated.
+For the preferred way of using SUPL see
This document describes the SUPL Push API
+which is used to process
This document is intended for Symbian
+licensees who want to create their own handlers to process
Secure User Plane Location (SUPL)
+is a standard for enabling Location Based Services using IP for most of the
+communication between a SET and an SLP. To start a network initiated request,
+the SLP must send a
To start a location
+request, the SLP sends a
To support SUPL, the
+LBS subsystem ROM is built to include the SUPL WAP Push plug-in or an SMS
+Trigger plug-in as described in
The
A licensee can also create
+their own
The SLP and the SET
+process the location request as described in
Symbian
+provides two plug-ins that can process
The SUPL WAP Push plug-in
+receives
The Symbian test SUPL
+SMS Trigger plug-in receives
The SUPL WAP Push handler plug-in and SUPL SMS Trigger plug-in use +the SUPL Push API to notify the SUPL Protocol Module that an SLP is starting +a network initiated location request.
SUPL +WAP Push plug-in
The Symbian platform includes the WAP Push Framework
+to process WAP Push messages. If the Symbian SUPL WAP Push plug-in is installed,
+the WAP Push Framework uses it to process
The SUPL
+WAP Push handler plug-in is a production component. Licensees can install
+the plug-in in their ROM so that it is available to the WAP Push Framework.
+Licensees do not need to develop their own WAP Push handler plug-in. See
Source code for the WAP Push plug-in can be found at
SUPL SMS Trigger plug-in
If the Symbian SUPL SMS Trigger plug-in
+is installed, it is loaded on OS startup by the Watcher Framework, which uses
+it to process
Source code for the
+SMS Trigger plug-in can be found at
The SUPL Push API is +used to notify the SUPL Protocol Module that a SUPL INIT message was received +from an SLP to start a network location request.
The SUPL API has +two different types of client:
Clients that receive
Clients that require
+notification of
The SUPL Push API has
SUPL +Push API sender classes
This section describes the classes of
+the SUPL Push API that the SUPL WAP Push handler plug-in and SUPL SMS Trigger
+plug-in use to send
Request queueing
The SUPL Push API uses Publish and Subscribe
+(P&S) properties to store the details of
One potential problem with
+using P&S properties occurs in the situation where multiple calls to
The implementation of the SUPL Push API queues
API restrictions
The SUPL Push API can be used by up to two
+threads, each of which must use a different 'channel' as specified by
A
+single thread in an API client can create multiple instances of
The Symbian WAP Push
+Framework instantiates multiple copies of the SUPL WAP Push plug-in to handle
+multiple
There is only one instance +of the Symbian test SUPL SMS Trigger plug-in which is loaded by the Messaging +Watcher Framework and all messages are processed by the same thread.
Licensees
+who implement their own method of handing
A maximum total of two +threads can use the API concurrently.
Each thread must use +a different 'channel'.
SUPL +Push API receiver classes
This section describes the classes of
+the SUPL Push API that the SUPL Protocol Module uses to receive
Figure 3 shows the SUPL Push API receiver +classes. Symbian licensees do not need to use the receiver classes - they +are used by the Symbian reference SUPL Protocol Module.
The SUPL Protocol Module implements
The SUPL Protocol Module calls
The SUPL Push API is packaged in
API clients require
Figure 4 is a simple sequence
+diagram showing the WAP Push plug-in receiving a
An SMS Trigger plug-in
+would use the channel
The
+error parameter
Note
+that the SUPL Protocol Module calls
[1]