Location-Based Services System Specification: Submit Technical Questions at

Location-Based Services System
Specification
80-V6410-1NP D
December 3, 2003
Submit technical questions at:

https://support.snaptrack.com
QUALCOMM is a registered trademark and registered service mark of QUALCOMM Incorporated. cdma2000® is
a registered trademark of the Telecommunications Industry Association (TIA USA). Other product and brand names
may be trademarks or registered trademarks of their respective owners.
Export of this technology may be controlled by the United States Government. Diversion contrary to U.S. law
prohibited.
QUALCOMM Incorporated
5775 Morehouse Dr.
San Diego, CA 92121-1714
U.S.A.
Copyright © 2005 QUALCOMM Incorporated and SnapTrack® Inc. All rights reserved.
Contents
1 Introduction...................................................................................................... 5
1.1 Purpose and scope ............................................................................................................... 5
1.2 Conventions......................................................................................................................... 5
1.3 Revision history................................................................................................................... 5
1.4 References ........................................................................................................................... 6
1.5 Technical assistance ............................................................................................................ 6
1.6 Acronyms ............................................................................................................................ 7
2 Network Architecture ...................................................................................... 8
3 Assumptions.................................................................................................... 9
4 gpsOne Call Flows ........................................................................................ 11

4.1 WAP Pull applications ...................................................................................................... 11
4.1.1 Trusted WAP applications.................................................................................... 12
4.1.1.1 Successful gpsOne ................................................................................... 12
4.1.1.2 User rejects positioning attempt............................................................... 13
4.1.2 Nontrusted WAP applications .............................................................................. 14
4.1.2.2 Cell/sector position estimate .................................................................... 15
4.1.2.3 Cached position estimate ......................................................................... 17
4.1.2.4 User rejects positioning attempt............................................................... 18
4.1.2.5 Authorization failed ................................................................................. 19
4.2 Network-initiated applications .......................................................................................... 20
4.2.1 Successful gpsOne................................................................................................ 20
4.2.2 Cell/sector position estimate................................................................................. 21
4.2.3 Cached position estimate ...................................................................................... 22
4.2.3.1 Consent needed ........................................................................................ 22
4.2.3.2 Consent not needed.................................................................................. 23
4.2.4 User rejects positioning attempt ........................................................................... 24
4.2.5 Authorization failed.............................................................................................. 25
4.2.6 Cell/sector position estimate after gpsOne failure................................................ 26
4.3 MS-resident applications................................................................................................... 27
4.3.1 Nontrusted MS-resident applications ................................................................... 27
4.3.1.2 Cell/sector position estimate .................................................................... 28
80-V6410-1NP D 2 QUALCOMM Incorporated

Location-Based Services System Specification Contents
4.3.1.3 Cached position estimate ......................................................................... 29

4.3.1.4 Authorization failed ................................................................................. 30
4.3.2 Trusted MS-resident applications ......................................................................... 31
4.4 Timers and events.............................................................................................................. 32
5 Legacy Call Flows ......................................................................................... 34

5.1 WAP pull applications....................................................................................................... 34
5.2 Network-initiated applications .......................................................................................... 35
6 Protocols and Interfaces............................................................................... 36

6.1 gpsOne PDE – MPC interface; E5′ ................................................................................... 36
6.2 MS – MPC interface.......................................................................................................... 36
6.3 gpsOne PDE – MS interface; IS-801................................................................................. 36
6.4 MC-MPC interface ............................................................................................................ 36
6.5 LIF MLP............................................................................................................................ 36
7 SMS Implementation Guidelines .................................................................. 37

7.1 SMS options ...................................................................................................................... 37
7.1.1 Mobile-terminated SMS ....................................................................................... 37
7.1.2 Mobile-originated SMS ........................................................................................ 37
7.1.2.1 Direct routing........................................................................................... 38
7.1.2.2 Indirect routing ........................................................................................ 39
8 Service Interactions ...................................................................................... 40

8.1 WAP browser applications................................................................................................ 40
8.2 Multiple network-initiated applications ............................................................................ 41
8.3 Nontrusted MS-resident applications ................................................................................ 41
8.4 Trusted MS-resident applications...................................................................................... 42

Location-Based Services System Specification Contents
Figures
Figure 2–1 Location services network architecture ........................................................... 8
Figure 4–1 Trusted WAP pull, successful gpsOne .......................................................... 12
Figure 4–2 Trusted WAP pull, user rejects positioning attempt...................................... 13
Figure 4–3 WAP pull, successful gpsOne ....................................................................... 14
Figure 4–4 WAP pull, cell/sector position....................................................................... 15
Figure 4–5 WAP pull, cached position ............................................................................ 17
Figure 4–6 WAP pull, user rejects positioning attempt ................................................... 18
Figure 4–7 WAP pull, authorization failed...................................................................... 19
Figure 4–8 Network-initiated, successful gpsOne ........................................................... 20
Figure 4–9 Network-initiated, cell/sector position .......................................................... 21
Figure 4–10 Network-initiated, cached position – consent needed ................................. 22
Figure 4–11 Network-initiated, cached position – consent not needed ........................... 23
Figure 4–12 Network-initiated, user rejects positioning attempt..................................... 24
Figure 4–13 Network-initiated, authorization failed........................................................ 25
Figure 4–14 Network-initiated, cell/sector position after gpsOne failure........................ 26
Figure 4–15 MS-resident application, successful gpsOne ............................................... 27
Figure 4–16 MS-resident application, cell/sector position .............................................. 28
Figure 4–17 MS-resident application, cached position.................................................... 29
Figure 4–18 MS-resident application, authorization failed.............................................. 30
Figure 4–19 BREW application, successful gpsOne ....................................................... 31
Figure 5–1 WAP pull, legacy mobile............................................................................... 34
Figure 5–2 Network-initiated, legacy mobile .................................................................. 35
Figure 7–1 SMS direct routing ........................................................................................ 38
Figure 7–2 SMS indirect routing ..................................................................................... 39
Tables
Table 1-1 Revision history................................................................................................. 5
Table 1-2 Reference documents and standards.................................................................. 6
Table 4-1 Timer values for WAP-originated positioning ................................................ 32
Table 4-2 Timer values for network-initiated positioning ............................................... 33
Table 4-3 Timer values for nontrusted MS-resident application-originated
positioning............................................................................................................... 33

1 1 Introduction
2 1.1 Purpose and scope

3 This document represents a system specification for the deployment of location-based services on
4 a CDMA network. The location-based services are based on QUALCOMM’s User Plane
5 architecture for gpsOne™-enabled mobiles and proprietary IS-41 techniques for legacy mobiles.
6 A complete range of applications can be supported, including BREW™, JAVA™, WAP, SMS,
7 and network-initiated services. In addition, the applications may reside in either the mobile
8 directly or in the network. This document can serve as the basis of an RFP in the procurement
9 process of a Mobile Positioning Center (MPC) and a SnapTrack® Position Determination Entity
10 (PDE).
11 1.2 Conventions
12 Shading indicates content that has been added or changed in this revision of the document.
13 1.3 Revision history

14 The revision history for this document is shown in Table 1-1.
15 Table 1-1 Revision history
Version Date Description

A Jan 2003 Initial release.
B Jun 2003 Editorial changes.
C Jul 2003 Added chapters for assumptions, SMS implementation options, and service
interactions. Added trusted WAP applications section. Added timers and
events section. Updated trusted MS-resident applications section. Updated
protocols and interfaces chapter. Updated references and technical
assistance.
D Dec 2003 Added handling for receipt of a second SPPReq from a mobile. Corrected
timer T1 in Figure 4–3.
16

Location-Based Services System Specification Introduction
1 1.4 References
2 Reference documents, which may include QUALCOMM, standards, and resource documents, are
3 listed in Table 1-2.
4 Table 1-2 Reference documents and standards
Ref. Document
QUALCOMM
Q1 Application Note: Software Glossary for Customers CL93-V3077-1
Q2 gpsOne™ Mobile Station Sensor Interface Application CL93-V2246-1
TCP/IP Wrapper Interface Specification
Q3 gpsOne™ User Plane E5′ Protocol Specification 80-V5458-1
Q4 gpsOne™ User Plane MS-MPC Protocol Specification 80-V5456-1
Q5 gpsOne™ User Plane Handset Protocol Specification 80-V6114-1
Standards
S1 Enhanced Wireless 911 Phase 2 TIA/EIA/IS-J-STD-036 (Aug 2000)
S2 Enhanced Wireless 911 Phase 2, Addendum 1 TIA/EIA/IS-J-STD-036-1 (Jan 2001)
S3 Enhanced Wireless 911 Phase 2, Rev. A TIA/EIA/IS-J-STD-036-A (Jun 2002)
S4 Location Services Enhancements PN-4747
S5 OMA/LIF MLP, Version 3.0.0 (Apr 2002)
S6 Position Determination Service Standards for Dual-Mode TIA/EIA/IS-801-1 (Mar 2001)
Spread Spectrum Systems, Addendum 1
S7 SMPP Forum SMPP Protocol, V3.4 (Oct 1999)
S8 Enhanced Wireless 911 Phase 2 TIA/EIA/IS-J-STD-036-A-1 (Mar 2003)
5
6 1.5 Technical assistance

7 For assistance or clarification on information in this guide:
8 Submit a Service Request to QUALCOMM CDMA Technologies at
9 https://support.cdmatech.com/
10 If you do not have access to the Internet, you may send email to
11 support.cdmatech@qualcomm.com.
12 Contact the regional SnapTrack® office
13 For BREW™ application assistance or clarification, send email to
14 brew-oem-support@qualcomm.com

Location-Based Services System Specification Introduction
1 1.6 Acronyms
2 The following terms are used throughout this document:
3
AFLT Advanced forward-link trilateration

A-GPS Assisted GPS
API Applications programming interface
BREW Binary runtime environment for wireless
BS / BTS Base station
BSC Base station controller
CDMA Code division multiple access
DBM Data burst message
GPS Global positioning system
HLR Home location register
HTTP Hyper text transfer protocol
IWF Interworking function
JAVA A general-purpose, high-level, object-oriented, cross-platform programming language
developed by Sun Microsystems
LCS Location services
LIF Location interoperability forum
LIR Location immediate request
MC Message center
MLP Mobile location protocol
MO Mobile-originated
MPC Mobile positioning center
MS Mobile station
MSC Mobile-switching center
MT Mobile-terminated
OMA Open mobile alliance
PDE Position determination entity
PDSN Packet data service node
RFP Request for proposal
SMDPP Short message delivery point-to-point bearer service
SMPP Short message peer-to-peer protocol
SMS Short message service
SS7 Signaling system 7
URL Uniform resource locator
VLR Visited location register
WAP Wireless application protocol
WSP Wireless session protocol
4

1 2 Network Architecture
2 The location services network architecture is shown in Figure 2–1.
SMDPP MC
SMPP
IS-41
MSC / VLR /
Legacy PDE
HLR
Apps
Wireless Network L1
MS MS-MPC L1
PDSN / IWF MPC Apps
IS-801 E5'
gpsOne
PDE
Apps
4 Figure 2–1 Location services network architecture
5 Some key interfaces are:

6 MPC-PDE interface – this is based on the E5 interface from the 3GPP2 Standards [S1] and
7 [S4]. However, the actual details of this interface are fully defined in [Q3]. To distinguish this
8 interface from that strictly defined in [S1] and [S4], this interface is labeled E5′.
9 L1 interface – this is defined by OMA and is compliant with the LIF MLP 3.0.0 protocol
10 ([S5]).
11 Legacy PDE IS-41 interface – this is an IS-41-compliant interface, but the mechanisms by
12 which a cell/sector-based position estimate is obtained are implementation specific. Such
13 details are not found in this specification and must be provided by the Legacy PDE vendor.
14 gpsOne IS-801 interface – this is just a TCP/IP interface. The IS-801 messages are standards
15 compliant ([S6]) and encapsulated in a TCP/IP Wrapper [Q2] and carried end-to-end between
16 the mobile and the gpsOne PDE.
17 MS-MPC interface – this is used to support many location-specific service aspects, including
18 authorization, gpsOne triggers, notification and verification events, and so on. The details can
19 be found in [Q4].
20 MPC-MC interface – this interface is compliant with SMPP V3.4 ([S7]). This will be used to
21 carry special location-specific SMS messages performing such tasks as gpsOne triggers,
22 notification and verification events, and so on. The details can be found in [Q4].

1 3 Assumptions
2 This chapter summarizes assumptions that were made in the creation of this location-based
3 services specification:
4 While a good portion of the gpsOne user plane specifications include details regarding how
5 an MPC is used to manage location-based services, it is important to note that the MPC is
6 optional. In particular, WAP applications, network-initiated applications, and MS-resident
7 applications can all be treated as trusted and, thus, the MPC is not required.
8 The architecture defined in this specification is limited to a single MPC and a single PDE
9 providing service to one service area. The service area may be large or small and is not
10 related to the coverage area of any particular wireless network. It may even span multiple
11 wireless networks. In future versions of this architecture, multiple MPCs and multiple PDEs
12 will be supported, and inter-MPC roaming will be enabled.
13 For all call flows except trusted MS-resident application call flows, the solution described in
14 this specification is limited in its support of the IS-801 modes of operation in that it only
15 supports MS-assisted mode. Trusted MS-resident applications can use the MS-based mode of
16 operation as well.
17 Within a network, all BREW™ applications must be either trusted or nontrusted. A
18 combination of trusted and nontrusted BREW applications is not allowed.
19 Within a network, all JAVA applications must be either trusted or nontrusted. A combination
20 of trusted and nontrusted JAVA applications is not allowed.
21 If the MS supports cdma2000® Release A, the mobile can support simultaneous voice and
22 data. Without this capability, the mobile cannot initiate an IP connection while on a voice
23 call. If the network or mobile does not support cdma2000 Release A and the mobile is on a
24 call when an MT-SMS triggering a gpsOne positioning session is received, then the MS shall
25 send an MO-SMS message to the MPC with the busy error code.
26 If a mobile initiates a second MO IS-801 session while an MO IS-801 session is in progress,
27 the PDE will release any resources allocated to the first session and start a new session.

Location-Based Services System Specification Assumptions
1 For WAP and MS-resident nontrusted location applications, if a second SPPReq is received
2 from the mobile, the MPC will release any resources allocated to the first SPPReq and then
3 process the new incoming SPPReq. If there is an outstanding GPOSREQ’ for the first
4 SPPReq, the MPC will send a CANCEL to the PDE. For WAP and MS-resident applications,
5 this could happen if a problem occurred that caused the user to restart the positioning process.
6 This is not applicable for network-initiated applications.
7 The MS will never send more than one gpsOne-related SPPReq message to the MPC, nor will
8 the MPC send more than one gpsOne-related GPOSREQ' message to the PDE.
9

1 4 gpsOne Call Flows
2 The following sections describe the call flows to be used by gpsOne-enabled mobiles in WAP
3 Pull applications, network-initiated applications, and MS-resident applications such as BREW
4 and JAVA.
5 4.1 WAP Pull applications

6 WAP Pull applications can be treated as either trusted or nontrusted. When treated as trusted, the
7 browser performs an MO IS-801 session directly with the PDE after receiving the trigger and
8 getting permission from the user, without interacting with the MPC. This allows for WAP to be
9 deployed without an MPC, but assumes that the WAP content is controlled by the carrier.

Location-Based Services System Specification gpsOne Call Flows
1 4.1.1 Trusted WAP applications
2 4.1.1.1 Successful gpsOne

3 Figure 4–1 illustrates a WAP Pull application where gpsOne was used successfully.
LCS
MPC PDE MS
Client
HTTP/WSP Request
a
HTTP/WSP Response (App Level Position Request)
b
Permissions Pop-up
c
Screen
T10
MO IS-801 Session d
HTTP/WSP Request (App Level Position Response)

e
HTTP/WSP Response
f
5 Figure 4–1 Trusted WAP pull, successful gpsOne

6
NOTE The letters for the following paragraphs correspond to the preceding figure.
7
a. The mobile attempts to access a location-sensitive URL. The LCS client recognizes that the
MS is gpsOne-enabled and proceeds with the appropriate call flow.
b. The LCS client responds to the HTTP request with an HTTP response containing the
gpsOne trigger. The details of this message can be found in [Q3].
c. The user is prompted for permission.
d. The mobile and gpsOne PDE perform an MO IS-801 session. The position estimate is made
available to the MS at the end of the session.
e. The mobile rerequests the location-sensitive URL, this time providing a position estimate
along with the request. The details of this message can be found in [Q3].
f. The LCS client downloads the requested content.
8

1 4.1.1.2 User rejects positioning attempt

2 Figure 4–2 illustrates a WAP Pull application where the user fails to grant permission. The
3 mobile is required to revisit the LCS client to ensure a smooth ending to the call flow from the
4 user’s perspective.
LCS
MPC PDE MS
Client
HTTP/WSP Request
a
b
Permissions Pop-up
c
Screen
T10
HTTP/WSP Request (No Position)

d
HTTP/WSP Response
e
6 Figure 4–2 Trusted WAP pull, user rejects positioning attempt

7
8
c. The user is prompted for permission and refuses the request.
d. The mobile rerequests the location-sensitive URL and does not provide a position estimate
e. The LCS client downloads the appropriate error message.
9

1 4.1.2 Nontrusted WAP applications

3 Figure 4–3 illustrates a WAP Pull application where gpsOne was used successfully.
4
NOTE The following graphic has been updated.

5
LCS
MPC PDE MS
Client
HTTP/W SP Request
a
b
Permissions Pop-up
c
Screen
MS-MPC Request
d
Service T7
Authorization MS-MPC Response
e
GPOSREQ’
T8 f
T10
T1 MO IS-801 Session g
gposreq'
h
i
HTTP/WSP Response
j
7 Figure 4–3 WAP pull, successful gpsOne

8
9
d. Once the user grants permission, the mobile sends a request for positioning to the MPC via
the MS-MPC protocol. The details of this message can be found in [Q3].

e. The MPC performs an authorization step to ensure that this particular user has access to the
location application being requested. Additionally, the MPC checks to see that gpsOne is in
fact necessary (as opposed to either a cached position or a cell/sector-based position). Once
it has been determined that a gpsOne session is required, the MPC sends a response message
to the mobile instructing it to perform a gpsOne session. The details of this message can be
found in [Q3]. The scenarios for when the MPC decides to use either a cached position or a
cell/sector fix are described in the next two call flows.
f. At the same time, the MPC invokes the gpsOne PDE. This invoke message seeds the PDE
such that it will accept the incoming MO IS-801 session. The GPOSREQ’ message and
protocol are defined in [Q2].
g. The mobile and gpsOne PDE perform an MO IS-801 session. The position estimate is made
h. The gpsOne PDE informs the MPC that the IS-801 session terminated normally. The
gposreq’ message will contain a position estimate of the MS, potentially to be used by the
MPC as a cached position on a subsequent request. The details of the gposreq’ message,
including how abnormal termination is handled, are described in [Q2].
i. The mobile rerequests the location-sensitive URL, this time providing a position estimate
j. The LCS client downloads the requested content.
1
2 4.1.2.2 Cell/sector position estimate

3 Figure 4–4 illustrates a WAP Pull application where gpsOne was deemed unnecessary and a
4 cell/sector-based position estimate is used instead.
LCS
MPC PDE MS
Client
HTTP/WSP Request
a
HTTP/W SP Response (App Level Position Request)
b
Permissions Pop-up
c
Screen
MS-MPC Request
d
Service
Authorization GPOSREQ’
e
T2
T10 gposreq' T7
f
MS-MPC Response
g
HTTP/W SP Request (App Level Position Response)
h
HTTP/WSP Response
i
6 Figure 4–4 WAP pull, cell/sector position

2
fact necessary (as opposed to either a cached position or a cell/sector-based position). In this
case, it has been determined that a gpsOne session is not required, and that there is either no
cached position or that the cached position has an unacceptable accuracy, and thus a
cell/sector-based position estimate is needed. The MPC invokes the gpsOne PDE requesting
a cell/sector-based position estimate. The GPOSREQ’ message and protocol are defined in
[Q2].
f. The gpsOne PDE provides the MPC with a cell/sector-based position estimate. The details
of the gposreq’ message, including how abnormal termination is handled, are described in
[Q2].
g. The MPC sends a response message to the mobile providing a position estimate for the
mobile to use in its rerequest of content. The details of this message can be found in [Q3].
h. The mobile rerequests the location-sensitive URL, this time providing a position estimate
i. The LCS client downloads the requested content.
3

1 4.1.2.3 Cached position estimate

2 Figure 4–5 illustrates a WAP Pull application where gpsOne was deemed unnecessary and a
3 cached-based position estimate is used instead.
LCS
MPC PDE MS
Client
HTTP/WSP Request
a
b
Permissions Pop-up
c
Screen
T10
MS-MPC Request
d
Service
T7
Authorization
MS-MPC Response
e
f
HTTP/WSP Response
g
5 Figure 4–5 WAP pull, cached position

6
7
case it has been determined that a gpsOne session is not required, and that a cached position
estimate will suffice. The MPC sends a response message to the mobile providing a position
estimate for the mobile to use in its rerequest of content. The details of this message can be
found in [Q3].
f. The mobile rerequests the location-sensitive URL, this time providing a position estimate
g. The LCS client downloads the requested content.

2 4.1.2.4 User rejects positioning attempt

3 Figure 4–6 illustrates a WAP Pull application where the user fails to grant permission. The
4 mobile is required to revisit the LCS client to ensure a smooth ending to the call flow from the
5 user’s perspective.
LCS
MPC PDE MS
Client
HTTP/WSP Request
a
b
Permissions Pop-up
c
Screen
MS-MPC Request (Reject)

T10 d
T7
MS-MPC Response (Ack)
e
f
HTTP/WSP Response
g
7 Figure 4–6 WAP pull, user rejects positioning attempt

8
9
c. The user is prompted for permission and refuses the request.
d. The mobile sends the reject notification to the MPC.
e. The MPC acknowledges the reject notification.
f. The mobile rerequests the location-sensitive URL and does not provide a position estimate
g. The LCS client downloads the appropriate error message.
10

1 4.1.2.5 Authorization failed

2 Figure 4–7 illustrates a WAP Pull application where authorization fails. The mobile is required to
3 revisit the LCS client to ensure a smooth ending to the call flow from the user’s perspective.
LCS
MPC PDE MS
Client
HTTP/WSP Request
a
b
Permissions Pop-up
c
Screen
T10
MS-MPC Request
d
Service
T7
Authorization
MS-MPC Response
e
f
HTTP/WSP Response
g
5 Figure 4–7 WAP pull, authorization failed

6
7
e. The MPC sends a response message to the mobile indicating that authorization has failed.
The details of this message can be found in [Q3].
f. The mobile rerequests the location-sensitive URL and does not provide a position estimate
g. The LCS client downloads the appropriate error message.
8

1 4.2 Network-initiated applications
2 4.2.1 Successful gpsOne

3 Figure 4–8 illustrates a network-initiated application where gpsOne was used successfully. This
4 call flow applies whether or not consent is needed.
LCS
MPC PDE MS
Client
MLP LIR
a
Service GPOSREQ’
b
Authorization
MT SMS (gpsOne Trigger, Notification, etc)
c
T3 MO SMS (Consent, SID/NID, etc)
d
T12
T1 MO IS-801 Session e
gposreq'
f
MLP LIA
g
6 Figure 4–8 Network-initiated, successful gpsOne

7
8
a. An LCS client requests the position of a mobile from the MPC via the LIF MLP protocol.
b. If the request is authorized, the MPC sends a GPOSREQ’ message to the PDE, seeding the
PDE such that it will accept the soon-to-be-coming MO IS-801 session from the mobile.
The GPOSREQ’ message and protocol are defined in [Q2].
c. Simultaneously, the MPC sends an MT SMS message to the mobile indicating that a gpsOne
session is needed, along with other things such as notification and verification procedures.
d. The mobile, if requested, sends the MPC the user consent or lack of consent, along with
other parameters such as SID, NID, and so on. The details of this message can be found in
[Q3].
e. The mobile and gpsOne PDE perform an MO IS-801 session.
f. The gpsOne PDE provides the position estimate to the MPC. The gposreq’ message and
g. The MPC provides the position estimate to the LCS client.
9

1 4.2.2 Cell/sector position estimate

2 Figure 4–9 illustrates a network-initiated application where gpsOne was deemed unnecessary and
3 a cell/sector-based position estimate is used instead. This call flow applies whether consent is
4 needed or not.
LCS
MPC PDE MS
Client
MLP LIR
a
Service MT SMS (gpsOne Trigger, Notification, and so on)
b
Authorization T3
MO SMS (Consent, SID/NID, and so on)
c
GPOSREQ’
T12 d
T2
gposreq'
e
MLP LIA
f
6 Figure 4–9 Network-initiated, cell/sector position

7
8
b. If the request is authorized, the MPC sends an MT SMS message to the mobile indicating
that a cell/sector fix will be used, along with other things such as notification and
verification procedures. The details of this message can be found in [Q3].
c. The mobile, if requested, sends the MPC the user consent or lack of consent, along with
other parameters such as SID, NID, and so on. These other parameters are needed for the
cell/sector fix to occur. The details of this message can be found in [Q3].
d. The MPC sends a GPOSREQ’ message to the PDE containing SID, NID, and so on, such
that the PDE can perform a cell/sector-based position estimate. The GPOSREQ’ message
and protocol are defined in [Q2].
e. The gpsOne PDE provides the position estimate to the MPC. The gposreq’ message and
f. The MPC provides the position estimate to the LCS client.
9

1 4.2.3 Cached position estimate
2 4.2.3.1 Consent needed

3 Figure 4–10 illustrates a network-initiated application where gpsOne was deemed unnecessary
4 and a cached-based position estimate is used instead. Based on user profile information in the
5 MPC, it was determined that user notification and verification were necessary.
LCS
MPC PDE MS
Client
MLP LIR
a
Service MT SMS (Notification, etc)
b
Authorization
T3
MO SMS (Consent, SID/NID, etc)
c
T12
MLP LIA
d
7 Figure 4–10 Network-initiated, cached position – consent needed

8
9
b. If the request is authorized and the MPC determines that a cached position is adequate, but
the MPC determines that consent is necessary, the MPC sends an MT SMS message to the
mobile to start the notification and verification procedures. The details of this message can
be found in [Q3].
c. The mobile sends the MPC the user consent or lack of consent. The details of this message
can be found in [Q3].
d. The MPC provides the position estimate to the LCS client.
10

1 4.2.3.2 Consent not needed

2 Figure 4–11 illustrates a network-initiated application where gpsOne was deemed unnecessary
3 and a cached-based position estimate is used instead. Based on user profile information in the
4 MPC, it was determined that user notification and verification were unnecessary.
LCS
MPC PDE MS
Client
MLP LIR
a
Service
b
Authorization
T12
MLP LIA
c
6 Figure 4–11 Network-initiated, cached position – consent not needed

7
8
b. The request is authorized, and the MPC determines that a cached position is adequate, and
that consent is unnecessary.
c. The MPC provides the position estimate to the LCS client.
9

1 4.2.4 User rejects positioning attempt

2 Figure 4–12 illustrates a network-initiated application where gpsOne was deemed necessary but
3 the user rejected the request.
LCS
MPC PDE MS
Client
MLP LIR
a
Service GPOSREQ’
b
Authorization
MT SMS (gpsOne Trigger, Notification, etc) c
T3 T1 MO SMS (Reject)
T12 d
CANCEL
e
MLP LIA
f
5 Figure 4–12 Network-initiated, user rejects positioning attempt

6
7
d. The mobile rejects the request. The details of this message can be found in [Q3].
e. The MPC sends a CANCEL message to the gpsOne PDE.
f. The MPC provides the appropriate error message to the LCS client.
8

1 4.2.5 Authorization failed

2 Figure 4–13 illustrates a network-initiated application where the MPC authorization step fails.
LCS
MPC PDE MS
Client
MLP LIR
a
Service
T12 b
Authorization
MLP LIA
c
4 Figure 4–13 Network-initiated, authorization failed

5
6
b. The request fails authorization.
c. The MPC provides the appropriate error message to the LCS client.
7

1 4.2.6 Cell/sector position estimate after gpsOne failure

2 Figure 4–14 illustrates a network-initiated application where the gpsOne session failed to produce
3 a fix and the MPC then initiates a cell/sector-based positioning attempt.
Cell /
LCS gpsOne
MPC Sector MS
Client PDE
PDE
MLP LIR
a
Service GPOSREQ’
b
Authorization
MT SMS (gpsOne Trigger, Notification, and so on)
c
T3 MO SMS (Consent, SID/NID, and so on)
d
T12
gposreq' (Failure)
f
MLP LIR
g
MLP LIA
h
MLP LIA
i
5 Figure 4–14 Network-initiated, cell/sector position after gpsOne failure

6
7
d. The mobile, if requested, sends the MPC the user consent or lack of consent, along with
other parameters such as SID, NID, and so on. The details of this message can be found in
[Q3].
e. The mobile and gpsOne PDE perform an MO IS-801 session, but for whatever reason this
fails to produce a position estimate.
f. The gpsOne PDE informs the MPC of the failure.
g. The MPC queries the cell/sector PDE for a position estimate.
h. The cell/sector PDE provides the position estimate to the MPC.
i. The MPC provides the position estimate to the LCS client.

1 4.3 MS-resident applications

2 MS-resident application types can be classified as trusted or nontrusted. Trusted application
3 types, such as BREW, have carrier-controlled distribution and billing through authenticated and
4 authorized channels. JAVA applications may also fall into the trusted application category,
5 depending on carrier implementation of the JAVA application deployment. Nontrusted
6 applications will be required to interface with the MPC to obtain position determination
7 privileges, whereas trusted applications may access the PDE directly.
8 4.3.1 Nontrusted MS-resident applications

9 The following sections describe the call flows to be used for nontrusted-based MS-resident
10 applications.

12 Figure 4–15 illustrates an MS-resident application where gpsOne was used successfully.
MS
MPC PDE MS
App
MS API Request
a
MS-MPC Request
b
MS-MPC Response T7
c
GPOSREQ’
d
gposreq'
f
MS API Response
g
13
14 Figure 4–15 MS-resident application, successful gpsOne

15
16
a. An MS-resident application invokes the gpsOne API. Note that any user notification and
verification steps occur prior to this step.
b. The mobile sends a request for positioning to the MPC via the MS-MPC protocol. The
details of this message can be found in [Q3].

c. The MPC performs an authorization step to ensure that this particular user has access to the
fact necessary (as opposed to either a cached position or a cell/sector-based position). Once
it has been determined that a gpsOne session is required, the MPC sends a response message
to the mobile instructing it to perform a gpsOne session. The details of this message can be
found in [Q3].
d. The MPC invokes the gpsOne PDE. This invoke message seeds the PDE such that it will
accept the incoming MO IS-801 session. The GPOSREQ’ message and protocol are defined
in [Q2].
e. The mobile and gpsOne PDE perform an MO IS-801 session. The position estimate is made
f. The gpsOne PDE informs the MPC that the IS-801 session terminated normally.
g. The gpsOne API returns the position estimate to the calling application.
1
2 4.3.1.2 Cell/sector position estimate

3 Figure 4–16 illustrates an MS-resident application where gpsOne was deemed unnecessary and a
4 cell/sector-based position estimate is used instead.
MS
MPC PDE MS
App
MS API Request
a
MS-MPC Request
b
GPOSREQ’
c
T2 gposreq' T7
d
MS-MPC Response
e
MS API Response
f
6 Figure 4–16 MS-resident application, cell/sector position

7
8
details of this message can be found in [Q3].

c. The MPC performs an authorization step to ensure that this particular user has access to the
case, it has been determined that a gpsOne session is not required and that a cell/sector-
based position estimate will suffice. The MPC invokes the gpsOne PDE requesting a
cell/sector-based position estimate. The GPOSREQ’ message and protocol are defined in
[Q2].
d. The gpsOne PDE provides the MPC with a cell/sector-based position estimate.
e. The MPC sends a response message to the mobile providing a position estimate. The details
of this message can be found in [Q3].
f. The gpsOne API returns the position estimate to the calling application.
1
2 4.3.1.3 Cached position estimate

3 Figure 4–17 illustrates an MS-resident application where gpsOne was deemed unnecessary and a
4 cached-based position estimate is used instead.
MS
MPC PDE MS
App
MS API Request
a
MS-MPC Request
b
MS-MPC Response T7
c
MS API Response
d
6 Figure 4–17 MS-resident application, cached position

7
8
details of this message can be found in [Q3]. The MPC performs an authorization step to
ensure that this particular user has access to the location application being requested.
Additionally, the MPC checks to see that gpsOne is in fact necessary (as opposed to either a
cached position or a cell/sector-based position). In this case, it has been determined that a
gpsOne session is not required and that a cached position estimate will suffice.

c. The MPC sends a response message to the mobile providing a position estimate. The details
of this message can be found in [Q3].
d. The gpsOne API returns the position estimate to the calling application.
1
2 4.3.1.4 Authorization failed

3 Figure 4–18 illustrates an MS-resident application where MPC authorization has failed.
MS
MPC PDE MS
App
MS API Request
a
MS-MPC Request
b
MS-MPC Response T7
c
MS API Response
d
5 Figure 4–18 MS-resident application, authorization failed

6
7
details of this message can be found in [Q3]. The MPC performs an authorization step to
ensure that this particular user has access to the location application being requested. In this
case, the request is unauthorized.
c. The MPC sends a response message to the mobile providing an appropriate error message to
the mobile. The details of this message can be found in [Q3].
d. The gpsOne API returns an appropriate error message to the calling application.
8

1 4.3.2 Trusted MS-resident applications

2 The uplink MS-MPC protocol is not needed for trusted applications. In the case of BREW, for
3 example, the authorization, authentication, and billing are all performed prior to the gpsOne API
4 invocation. Thus the functions of the MPC are redundant. As a consequence of the MS-MPC
5 protocol being optional from a system-level perspective, the gpsOne PDE must be able to accept
6 any MO IS-801 session from any mobile. This dilutes the functionality of the E5′ interface in that
7 the MPC does not really control whether a gpsOne PDE will accept an IS-801 session. If this is a
8 requirement of the carrier, then implementation options exist, for example, a separate IP address
9 or port number can be provided on the PDE for trusted and nontrusted applications.
10 Also, for trusted applications there is no option to use the cached position within the MPC or to
11 use some positioning technology other than IS-801.
12 For network-initiated applications, it is possible to bypass the MPC by allowing the LCS client to
13 trigger trusted MS-resident applications directly. The mechanisms of this trigger are beyond the
14 scope of these specifications and have to be mutually agreed upon between the LCS client and
15 MS-resident application environments of any particular application space. The trigger will always
16 be based on an MT SMS, but the trigger needs to be specified. The expected implementations will
17 be based on special strings in the User Bearer Data field of the MT SMS. Service aspects such as
18 authentication, must be provided by the application and/or application space. Note that the
19 dedicated GPS teleservice mechanism is not available without an MPC.

21 Figure 4–19 illustrates an MS-resident application where gpsOne was used successfully.
MS
MPC PDE MS
App
MS API Request
a
MO IS-801 Session b
MS API Response
c
22
23 Figure 4–19 BREW application, successful gpsOne

2
a. A BREW application invokes the gpsOne API. Note that any user notification and
b. The mobile and gpsOne PDE perform an MO IS-801 session. The position estimate is made
c. The gpsOne API returns the position estimate to the calling application.
3
4 4.4 Timers and events

5 Table 4-1 through Table 4-3 summarize the timers and events used for this implementation.
6 Timers that are common to multiple positioning session origination types are repeated in the
7 appropriate tables. The timer value is usually the same for each type, but the action on expiration
8 may be specific to the origination type.
9 The default timer values shown are based on current understanding of generic network
10 implementations. The timer values may be adjusted to optimize operation for a specific network
11 implementation.
12 Table 4-1 Timer values for WAP-originated positioning
Default
Timer value Set at Description Action on expiration
(sec)
T1 36 MPC From sending of GPOSREQ’ to receipt Clear the session resources
of gposreq’ for gpsOne positioning at the MPC.
T2 8 MPC From sending of GPOSREQ’ to receipt Send an SPPRes to the
of gposreq’ for cell/sector positioning mobile indicating ‘no fix’.
T7 10 MS From sending of SPPReq to receipt of Send second WAP service
SPPRes request with no location.
T8 32 MS From receipt of SPPRes to completion Send second WAP service
of IS-801 session request with no location.
T10 60 LCS From sending of first WAP response to Clear the session.
client receipt of second WAP request
13

1 Table 4-2 Timer values for network-initiated positioning
Default
(sec)
T1 36 MPC From sending of GPOSREQ’ to Clear session resources at MPC.
receipt of final gposreq’ for Send LIA with failure to LCS
gpsOne positioning client.
receipt of gposreq’ for cell/sector Send LIA with failure to LCS
positioning client.
T3 60 MPC From sending of MT-SMS to Clear session resources at MPC.
receipt of MO-SMS Send LIA with failure to LCS
client.
T12 100 LCS From sending of LIR to receipt of Give failure notification to the
client LIA initiator.
T15 20 MS From appearance of permission Send MO-SMS message to MPC.
pop-up screen to user input
(consent or reject)
2
3 Table 4-3 Timer values for nontrusted MS-resident application-originated

4 positioning
Default
(sec)
receipt of gposreq’ for gpsOne
positioning
T2 8 MPC From sending of GPOSREQ’ to Send SPPRes with appropriate
receipt of gposreq’ for cell/sector Positioning Status indicator to
positioning MS.
T7 10 MS From sending of SPPReq to Give failure notification to
receipt of SPPRes application.

1 5 Legacy Call Flows
2 This chapter describes the call flows to be used for legacy mobiles in WAP Pull applications and
3 network-initiated applications.
4 5.1 WAP pull applications

5 Figure 5–1 illustrates a WAP Pull application for a legacy mobile.
LCS
MPC PDE MS
Client
HTTP/WSP Request
a
MLP LIR b
Service Authorization c
MLP LIR
d
HTTP/WSP Response
e
7 Figure 5–1 WAP pull, legacy mobile

8
9
MS is legacy mobile and proceeds with the appropriate call flow.
b. The LCS client requests the position of the legacy mobile from the MPC via the LIF MLP
protocol.
c. The request is authorized.
d. The MPC provides the position estimate to the LCS client.
e. The LCS client downloads the requested content.
10

Location-Based Services System Specification Legacy Call Flows
1 5.2 Network-initiated applications

2 Figure 5–2 illustrates a network-initiated application for a legacy mobile.
LCS
MPC PDE MS
Client
MLP LIR
a
Service Authorization b
MLP LIR
c
4 Figure 5–2 Network-initiated, legacy mobile

5
6
b. The request is authorized.
c. The MPC provides the position estimate to the LCS client.
7

1 6 Protocols and Interfaces
2 6.1 gpsOne PDE – MPC interface; E5′

3 The details of this interface can be found in [Q3].
4 6.2 MS – MPC interface

5 The details of this interface can be found in [Q4] and [Q5].
6 6.3 gpsOne PDE – MS interface; IS-801

7 The details of this interface are found in [Q2] and [S6].
8 6.4 MC-MPC interface

9 The MPC is connected to an MC for SMS messaging. This interface is defined in [S7]. More
10 details on the location-specific SMS message can be found in [Q4]. The MC is connected to the
11 CDMA network via IS-41 links. More details on how the SMS messaging should work can be
12 found in Chapter 7 of the SMS Implementation Guidelines.
13 6.5 LIF MLP

14 The interface between the MPC and the application space is compliant with the OMA MLP
15 protocol. However, only a small portion of this protocol is supported in the initial release. In
16 particular, only the LIR Response operation is supported. The Deferred and Trigger functionality
17 is for further study.
18

1 7 SMS Implementation Guidelines
2 7.1 SMS options
3 7.1.1 Mobile-terminated SMS

4 To optimize performance in terms of delivery time of the MT SMS message used in the network-
5 initiated applications, a dedicated MC is strongly recommended.
6 The dedicated MC should process the MT SMS messages as single-shot messages. In other
7 words, the MC need not perform a database write to the store and forward database associated
8 with an MC as these messages should not be retransmitted. If the SMDPP Invoke indicates that
9 the SMS was not delivered, the MPC should be notified such that the LCS client can be informed
10 that the position request has failed.
11 7.1.2 Mobile-originated SMS

12 To optimize performance in terms of delivery time of the MO SMS message used in the network-
13 initiated applications, IS-41 Direct Routing is strongly recommended.
14 MO SMS messages can be routed to the destination or terminating Message Center (MC-T),
15 associated with the MPC, either directly or via the originating (or initiating) mobile’s MC
16 (MC-O). For many applications indirect routing has advantages, as it allows the home system to
17 apply supplementary services, filter short messages, and perform accounting for billing purposes.
18 For location services, however, direct routing is preferred.
19 MSCs are typically provisioned to send MO SMS messages to the MC-O but in most cases can
20 also be provisioned to route certain messages directly. The advantages of direct routing are a
21 reduction in message latency, less risk of loss of messages, and less likelihood of LCS messages
22 becoming delayed due to unusually high levels of text messaging.
23 One approach would be to directly route MO SMS messages being sent to the destination address
24 of the MPC’s MC. This would require every MSC to have the complete list of such addresses,
25 something that may be impractical if intercarrier roaming is ever supported. A simpler approach
26 would be to directly route messages based on the Teleservice Identifier (65001). This approach is
27 recommended. Depending on the MSC vendor, this may be provisionable.

Location-Based Services System Specification SMS Implementation Guidelines
1 7.1.2.1 Direct routing

2 Direct routing must be controlled by the Serving MSC. There is no support in CDMA SMS
3 protocols to specify direct routing. This is not an oversight, for to allow the MS to specify direct
4 routing would also allow it to bypass billing and filtering, in some cases.
5 At step b in Figure 7–1, the MSC would examine the Teleservice Identifier associated with the
6 short message and, if it matches 65001, the MO SMS message will be routed in an ANSI-41
7 SMDPP message directly to the MPC’s MC.
8 Figure 7–1 is a generic case from ANSI-41. In this case, the Destination Home System will be
9 MC associated with the MPC, but this makes no difference to the protocol.
Originator
Serving Destination
Originator System Home System
MS MSC
MC HLR
SME BS
SMD-REQ
a
SMDPP
b
SAOT
SMT
smdpp [ACK]
c
SMD-ACK
d
10
11 Figure 7–1 SMS direct routing

Location-Based Services System Specification SMS Implementation Guidelines
1 7.1.2.2 Indirect routing

2 Indirect routing, shown in Figure 7–2, is more suitable for generic SMS (for example, text
3 messaging). In this case, the MSC sends the SMDPP to the MC-O, addressed by the MSID of the
4 originating MS. This MC then routes the SMDPP to the MC-T based on the destination address
5 (for example, the destination MS’ MDN).
Originator Originator
Serving Home Destination
Originator System System Home System
MS MSC
MC MC HLR
SME BS
SMD-REQ
a
SMDPP
b
SAOT
SMT
smdpp [ACK] c
SMD-ACK
d
SMDPP
e
SMT
smdpp [ACK]
f
7 Figure 7–2 SMS indirect routing

1 8 Service Interactions
2 The previous chapters described how each application space works in isolation. This chapter
3 offers some guidance on how these various application spaces may interact.
4 It should be noted that the cell/sector and cached call flows pose no interaction issues. For
5 example, an incoming network-initiated request that does not require an IS-801 session, can
6 coexist with either a WAP Browser session or an MS-resident application regardless of what type
7 of positioning activity is ongoing within the MS.
8 The area where service interaction needs further clarification is where gpsOne call flows occur in
9 a simultaneous fashion. For example, how does an incoming network-initiated request, that
10 requires an IS-801 session, interact with an application running on the MS, such as a WAP
11 Browser session or an MS-resident application that also requires an IS-801 session. The actual
12 details of these interactions are inherently an implementation detail and there are too many details
13 to describe the exact behavior in this specification, but some guidance is provided.
14 The text that follows is in the context of simultaneous requests for IS-801 sessions. Also note
15 there is a fundamental assumption that the MS will never send more than one gpsOne-related
16 SPPReq message to the MPC nor will the MPC send more than one gpsOne-related GPOSREQ’
17 message to the PDE.
18 8.1 WAP browser applications

19 In general, the WAP Browser needs to run in isolation. Suspending the WAP Browser and
20 starting another WAP Browser or running an MS-resident application is not a practical use case.
21 As such, this specification assumes that the WAP Browser session needs to be terminated before
22 another application can be executed on the MS.
23 The only service interaction left to discuss is how a WAP Browser interacts with a network-
24 initiated application. There are three scenarios to consider:
25 Scenario 1 – the network-initiated LIR message arrives at the MPC after the WAP SPPReq
26 message has arrived at the MPC.
27 Scenario 2 – the network-initiated LIR message has arrived at the MPC, and the
28 corresponding MT SMS gpsOne trigger has reached the MS, followed by the WAP SPPReq
29 being initiated.
30 Scenario 3 – the network-initiated LIR message has arrived at the MPC, but the WAP
31 SPPReq is initiated prior to the MT SMS gpsOne trigger reaching the MS.
32 For scenario 1, the MPC should spoof the LIR request at the MPC and provide the requesting
33 party with the position once the active positioning session is complete. If notification and
34 verification are required there will need to be an MT SMS and MO SMS exchange to convey
35 consent. In general, this should be possible, but it is an implementation detail as to whether the

Location-Based Services System Specification Service Interactions
1 MC, MSC, and MS will even allow the MT SMS message to be delivered, and then further
2 whether the MS can switch out the user interface without killing the WAP Browser. However,
3 nothing in this specification prevents such a service interaction.
4
NOTE The term spoof refers to the MPC using the results of the existing IS-801 session to provide a
position estimate to the subsequent requests.
5
6 For Scenarios 2 and 3, the MPC should hold the SPPRes message in the MPC and attempt to
7 provide a cached position based on the IS-801 session associated with the network-initiated
8 application. If no position is available or Timer T7 is set to expire, the MPC shall send a rejection
9 notification in the SPPRes to the MS.
10 8.2 Multiple network-initiated applications

11 As multiple LIRs arrive at the MPC they should be spoofed by the MPC such that the original
12 positioning session can proceed. Individual MT SMS and MO SMS exchanges should be
13 performed to ensure consent issues are managed according to the subscriber’s profile, but only
14 one underlying positioning session should ever exist. An exception exists in that if the first LIR
15 request generates a cell/sector-level positioning session and the next LIR request requires a
16 gpsOne positioning session, then this second request should be delayed and started immediately
17 following the completion of the cell/sector positioning session.
18 If the MO SMS introduces performance issues (long delays in delivery to the MPC), then an
19 alternative approach exists to handling multiple LIRs that require an IS-801 session, arriving at
20 the MPC. The MPC can serialize such incoming LIRs and use the associated gposreq’ as in
21 implicit consent. Note the MO SMS will still exist, but will just not be used by the MPC.
22 8.3 Nontrusted MS-resident applications

23 As stated, a WAP browser needs to be terminated to start such an application, but it is possible for
24 some MS-resident applications to be suspended and allow another MS-resident application to
25 start, including a WAP Browser. How MS-resident applications can be suspended is an
26 implementation detail beyond the scope of this specification, but the MS should ensure that only
27 one underlying positioning session be active at any given time. Options for how the suspended
28 MS-resident application behaves can range from terminating any outstanding positioning session,
29 to accepting the outcome of the new positioning session, to delaying its positioning session
30 request until it resumes its purpose.
31 The interactions between nontrusted MS-resident applications and network-initiated applications
32 shall be handled in the same way as WAP interactions with network-initiated applications (see the
33 three WAP scenarios).

Location-Based Services System Specification Service Interactions
1 8.4 Trusted MS-resident applications

2 For interaction with other MS-resident applications, be they trusted or nontrusted or even WAP,
3 there is no difference in logic than what was just described for how the nontrusted MS-resident
4 applications behave.
5 However, there are the unique scenarios to consider relating to the interaction with incoming
6 network-initiated applications. It is assumed that the trusted and nontrusted ports on the PDE can
7 share state information about existing sessions. As with many of the above scenarios, there are
8 many implementation details beyond the scope of these specifications. The MS may not even
9 receive the MT SMS trigger or may always reject the MT SMS with an MO SMS. But assuming
10 the MS could process the MT SMS in a fashion to move the network-initiated application
11 forward, the following scenarios need to be considered:
12
NOTE It may be necessary to implement intelligence in the MS to determine whether to accept or

reject a request based on the status and characteristics of the MS-resident application, such as
single-fix versus tracking, tracking with short intervals, and so on, as the PDE interaction is not
predictable.
13
14 Existing IS-801 session and an incoming LIR – call proceeds and the LIR attempts to use the
15 result of the existing IS-801 session. If the session turns out to be MS-based, then the PDE
16 can either fail the attempt or perform a cell/sector lookup.
17 No IS-801 session and an incoming LIR – call proceeds per the network-initiated application
18 call flows. Note this scenario is actually not an interaction scenario per se, but there could be
19 a tracking application running on the MS and the LIR is just being executed between
20 intervals.

Location-Based Services System Specification: Submit Technical Questions at

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Location-Based Services System Specification: Submit Technical Questions at

Uploaded by

Copyright:

Available Formats

Location-Based Services System

Submit technical questions at:

2 Network Architecture ...................................................................................... 8

4 gpsOne Call Flows ........................................................................................ 11

80-V6410-1NP D 2 QUALCOMM Incorporated

4.3.1.3 Cached position estimate ......................................................................... 29

5 Legacy Call Flows ......................................................................................... 34

6 Protocols and Interfaces............................................................................... 36

7 SMS Implementation Guidelines .................................................................. 37

8 Service Interactions ...................................................................................... 40

80-V6410-1NP D 3 QUALCOMM Incorporated

80-V6410-1NP D 4 QUALCOMM Incorporated

2 1.1 Purpose and scope

13 1.3 Revision history

15 Table 1-1 Revision history

Version Date Description

80-V6410-1NP D 5 QUALCOMM Incorporated

4 Table 1-2 Reference documents and standards

6 1.5 Technical assistance

80-V6410-1NP D 6 QUALCOMM Incorporated

AFLT Advanced forward-link trilateration

80-V6410-1NP D 7 QUALCOMM Incorporated

2 The location services network architecture is shown in Figure 2–1.

4 Figure 2–1 Location services network architecture

5 Some key interfaces are:

80-V6410-1NP D 8 QUALCOMM Incorporated

80-V6410-1NP D 9 QUALCOMM Incorporated

80-V6410-1NP D 10 QUALCOMM Incorporated

5 4.1 WAP Pull applications

80-V6410-1NP D 11 QUALCOMM Incorporated

1 4.1.1 Trusted WAP applications

2 4.1.1.1 Successful gpsOne

HTTP/WSP Request (App Level Position Response)

5 Figure 4–1 Trusted WAP pull, successful gpsOne

80-V6410-1NP D 12 QUALCOMM Incorporated

1 4.1.1.2 User rejects positioning attempt

HTTP/WSP Request (No Position)

6 Figure 4–2 Trusted WAP pull, user rejects positioning attempt

80-V6410-1NP D 13 QUALCOMM Incorporated

1 4.1.2 Nontrusted WAP applications

2 4.1.2.1 Successful gpsOne

NOTE The following graphic has been updated.

7 Figure 4–3 WAP pull, successful gpsOne

80-V6410-1NP D 14 QUALCOMM Incorporated

2 4.1.2.2 Cell/sector position estimate

6 Figure 4–4 WAP pull, cell/sector position

80-V6410-1NP D 15 QUALCOMM Incorporated

80-V6410-1NP D 16 QUALCOMM Incorporated

1 4.1.2.3 Cached position estimate

5 Figure 4–5 WAP pull, cached position

80-V6410-1NP D 17 QUALCOMM Incorporated

2 4.1.2.4 User rejects positioning attempt

MS-MPC Request (Reject)

7 Figure 4–6 WAP pull, user rejects positioning attempt

80-V6410-1NP D 18 QUALCOMM Incorporated

1 4.1.2.5 Authorization failed

5 Figure 4–7 WAP pull, authorization failed

80-V6410-1NP D 19 QUALCOMM Incorporated

1 4.2 Network-initiated applications

2 4.2.1 Successful gpsOne

6 Figure 4–8 Network-initiated, successful gpsOne

80-V6410-1NP D 20 QUALCOMM Incorporated

1 4.2.2 Cell/sector position estimate