HK1172771B - Method and apparatus for supporting location services with roaming - Google Patents

Abstract

Techniques for supporting location services with roaming are described. A mobile station interacts with a home mobile positioning center (H-MPC) in a home network for location services even when roaming. The mobile station communicates with a visited network for a data session and receives a request for its location. The mobile station sends first information (e.g., SID and NID) indicative of its current network location to the H-MPC. The H-MPC determines a serving mobile positioning center (S-MPC) in the visited network based on the first information. The S-MPC determines a serving position determining entity (S-PDE) in the visited network based on the first information. Depending on the selected positioning method, the H-MPC may receive an S-PDE address or a position estimate of the mobile station from the S-MPC and may forward this information to mobile station. The mobile station may communicate with the S-PDE for positioning using the S-PDE address.

Description

Method and apparatus for supporting location services with roaming

Related information of divisional application

The scheme is a divisional application. The parent of this division is the invention patent application entitled "method and apparatus for supporting location services with roaming" having application date of 11/30 2006, application number 200680044286.7.

This application claims priority to provisional united states application No. 60/741,324, filed on 30/11/2005, which is assigned to the present assignee and is incorporated herein by reference.

Technical Field

The present disclosure relates generally to communication, and more specifically to techniques for supporting location services.

Background

It is often desirable, and sometimes necessary, to know the location of a mobile station, such as a cellular telephone. The terms "position" and "orientation" are synonymous and may be used interchangeably. For example, a user may utilize a mobile station to browse a website and may click on location sensitive content. The location of the mobile station may then be determined and used to provide the appropriate content to the user. There are many other situations where it is useful or necessary to know the location of a mobile station.

A mobile station may be provisioned such that it can obtain location services from a local network to which the user has subscribed. The mobile station may communicate with various network entities in the home network in order to determine the location of the mobile station whenever needed. The mobile station may roam to other networks to which the user is not subscribed. The main challenge is to provide location services to mobile stations in this roaming situation.

Disclosure of Invention

Techniques for supporting location services with roaming (LCS) are described herein. In an aspect, a mobile station interacts with a home mobile positioning center (H-MPC) in a home network to obtain location services even when the mobile station is roaming. The mobile station may communicate with the visited network for a data session and receive a request for the location of the mobile station from, for example, an application resident on the mobile station (an MS-resident application), an LCS client, or an H-MPC. The mobile station may then send the first information to the H-MPC. The first information may indicate the current network location of the mobile station and may depend on the radio technology used by the visited network. For example, the first information may include a System Identifier (SID) and a Network Identifier (NID) of the visited network or some other information obtained from the visited network. A serving position determination entity (S-PDE) in the visited network may be determined based on the first information. Depending on the selected positioning method, the mobile station may receive (a) an address of the S-PDE from the H-MPC and may then communicate with the S-PDE to locate the mobile station, or (b) a position estimate for the mobile station, which may be determined by the S-PDE based on the first information.

In another aspect, an H-MPC may receive a request for a location of a mobile station (e.g., from an MS-resident application or LCS client), receive first information from the mobile station, and determine a serving mobile positioning center (S-MPC) in a visited network based on the first information. The H-MPC may then receive second information from the S-MPC and send the second information to the mobile station. Depending on the selected positioning method, the second information may include an S-PDE address or position estimate. The H-MPC may also perform other functions such as authorization, handoff, etc.

In yet another aspect, a mobile station may receive a request for a location of the mobile station and may send a query for an address of an S-PDE to a Domain Name System (DNS) server. The mobile station may include a domain name formed based on the SID and NID in the query sent to the DNS server. The mobile station may receive the address of the S-PDE from the DNS server and may then communicate with the S-PDE to locate the mobile station.

Various aspects and features of the disclosure are described in greater detail below.

Drawings

Fig. 1 shows a visiting network, a home network, and a requesting network.

Fig. 2 shows another deployment of a visited network, a home network, and a requesting network.

Fig. 3-25 show various message flows for positioning with roaming.

FIG. 26 shows a block diagram of a mobile station, a Radio Access Network (RAN), an S-PDE, an S-MPC, and an H-MPC.

Detailed Description

The techniques described herein may be used for various wireless networks such as Code Division Multiple Access (CDMA) networks, Time Division Multiple Access (TDMA) networks, Frequency Division Multiple Access (FDMA) networks, orthogonal FDMA (ofdma) networks, and the like. A CDMA network may implement radio technologies such as CDMA2000, wideband-CDMA (W-CDMA), and so on. cdma2000 covers IS-2000, IS-856, and IS-95 standards. The TDMA network may implement radio technologies such as global system for mobile communications (GSM), digital advanced mobile phone system (D-AMPS), etc. W-CDMA and GSM are described in literature from an organization known as the third Generation partnership project (3 GPP). cdma2000 is described in the literature from an organization known as the third generation partnership project 2 (3GPP 2). The 3GPP and 3GPP2 documents are publicly available. For clarity, techniques for a 3GPP2 network are described below.

Fig. 1 shows a deployment with access/service network 102a, local network 104a, and requesting network 106. The terms "access" and "service" are used interchangeably herein. Home network 104a is a wireless network to which Mobile Station (MS)110 has subscribed. Visited network 102a is the wireless network that currently serves mobile station 110. If the mobile station 110 roams out of the coverage area of the home network, the visited network and the home network may be different networks. Networks 102a and 104a support location services (LCS), which may include any service based on or related to location information. LCS may also be referred to as Location Based Services (LBS), and the like. Requesting network 106 may be part of visiting network 102a or local network 104a, or may be separate from these networks. For example, the requesting network 106 may be a data network maintained by an Internet Service Provider (ISP).

Mobile station 110 may be stationary or mobile and may also be referred to as User Equipment (UE), a terminal, a subscriber unit, a station, etc. Mobile station 110 may be a cellular telephone, Personal Digital Assistant (PDA), wireless device, cell phone, laptop computer, telemetry device, tracking device, or the like. Mobile station 110 may communicate with a Radio Access Network (RAN)120 in visited network 102a to obtain communication services such as voice, video, packet data, broadcast, messaging, and so on. The mobile station 110 may also receive signals from one or more satellites 190, which satellites 190 may be part of the united states Global Positioning System (GPS), the european galileo system, the russian Glonass system, or some other satellite positioning system. Mobile station 110 may measure signals from satellites 190 and/or signals from base stations in RAN 120 and may obtain pseudorange measurements for the satellites and/or timing measurements for the base stations. Pseudorange measurements and/or timing measurements may be used to derive a position estimate for mobile station 110 using one or a combination of positioning methods, such as assisted GPS (a-GPS), standalone GPS, advanced forward link trilateration (a-FLT), enhanced observed time difference (E-OTD), observed time difference of arrival (OTDOA), enhanced cell ID, and so forth.

The RAN 120 provides radio communication for mobile stations located within the coverage area of the RAN. The RAN 120 may include base stations, Base Station Controllers (BSCs), and/or other network entities supporting radio communications. A Mobile Switching Center (MSC)124 supports circuit-switched calls and also routes Short Message Service (SMS) messages. Message Center (MC)144 supports SMS and is responsible for storing, relaying, and forwarding SMS messages for mobile stations. A Packet Control Function (PCF)132 supports packet data switching between the RAN 120 and a Packet Data Serving Node (PDSN) 134. PDSN 134 supports packet-switched calls for mobile stations and is responsible for the establishment, maintenance, and termination of data sessions. In some wireless networks (e.g., IS-95 networks), an inter-working function (IWF) may be used in place of PDSN 134.

Serving position determining entities (S-PDEs) 140, 141 and 142 support positioning of mobile stations and may serve different geographical areas. Positioning refers to the process of measuring/calculating an estimate of the geographic position of a target device. The position estimate may also be referred to as a position estimate, a position fix, a fix, etc. The S-PDEs 140, 141, and 142 may exchange messages with the mobile stations for position location, computing position estimates, supporting the delivery of assistance data to the mobile stations, performing security functions, and so forth. Serving mobile positioning centers (S-MPCs) 150 and 152 perform various functions for location services and may serve different geographic areas. S-MPCs 150 and 152 may support subscriber privacy, authorization, authentication, roaming support, charging/billing, service management, location calculation, etc. Mobile station 110 may be initially served by S-MPC150 and S-PDE140 and may be handed off to S-PDE141 or to S-MPC152 and S-PDE142 when roaming thereafter. A local MPC (H-MPC)160 in the local network 104a supports location services for mobile stations in the local network and may perform various functions as described below. The H-MPC160 may provide information to the S-MPCs 150 and 152 to support positioning and may receive location information (e.g., position estimates, PDE addresses, etc.) from the S-MPCs.

Home location register/visitor location register (HLR/VLR)126 stores registration information for mobile stations that have registered on visited network 102 a. Com, Domain Name System (DNS) server 136 translates domain names (e.g., www.domain-name.com) into Internet Protocol (IP) addresses (e.g., 204.62.131.129) that are used by entities to communicate with each other via an IP network. DNS server 136 receives queries for IP addresses of domain names, determines the IP addresses of the domain names, and sends responses with the IP addresses to the requesting entity.

The Applications (APP)112 and 170 may include LCS clients and/or higher layer applications. An LCS client is a function or entity that requests location information for an LCS target. The LCS target is the mobile station whose location is being searched. In general, the LCS client may reside in the network entity or the mobile station, or may be external to both. The LCS client 170 may communicate with the H-MPC160 to obtain location information for the mobile station 110.

Fig. 1 also shows the interfaces between the various network entities. Message center 144 may communicate with MSC 124 via a short messaging point-to-point bearer Service (SMDPP) interface and may communicate with H-MPC160 via a short messaging point-to-point protocol (SMPP) interface. PDEs 140-142 may communicate with PDSN 134 via an IS-801 interface and may communicate with S-MPCs 150 and 152 via an E5' interface. S-MPCs 150 and 152 may communicate with PDSN 134 via an MS-MPC interface and may communicate with H-MPC160 via an MPC-MPC interface. The H-MPC160 may communicate with the LCS client 170 via an L1 interface. These various interfaces are known in the art.

Fig. 2 shows a deployment with a visited network 102b, a local network 104b, a requesting network 106, and a third party network 108. In this deployment, visited network 102b includes RAN 120, PCF 132, PDSN 134, DNS server 136, VLR 126, PDE140, and S-MPC150 described above with respect to FIG. 1. PDSN 134 may be a Foreign Agent (FA) through which mobile station 110 exchanges packet data while roaming. The visited network 102b further includes an authentication, authorization, and accounting (AAA) entity 138 and a Base Station Almanac (BSA) 144. AAA entity 138 performs authentication and authorization for LCS and other services. BSA 144 stores assistance data for satellites and/or base stations, which may be used to assist in locating mobile station 110. Network entities in visited network 102b may communicate with each other and with external entities via data network 192, which may be an IP network or some other network.

Local network 104b includes H-MPC160, PDSN 174, DNS server 176, AAA entity 178, VLR 166, local PDE (H-PDE)180, and BSA 184, which may operate in a similar manner as corresponding network entities in visited network 102 b. PDSN 174 may be a Home Agent (HA) on which mobile station 110 HAs registered and may be responsible for forwarding packets to mobile station 110. A network entity in local network 104b serves mobile stations that communicate with local network 104 b. Network entities in local network 104b may communicate with each other and with external entities via a data network 194, which may be an IP network, the internet, or some other network.

The third party network 108 may include a BSA server 172, which may be coupled to PDEs in other networks not shown in fig. 2. Entities in requesting network 106 and third party network 108 may communicate with entities in visited network 102b and local network 104b via data network 196, which may be an IP network or some other network.

Fig. 1 and 2 show two examples of a visiting network and a local network. In general, a network may include any combination of entities that may support any service provided by the network.

In the following description, visiting network 102 may refer to visiting network 102a in fig. 1 and/or visiting network 102b in fig. 2. Local network 104 may refer to local network 104a in fig. 1 and/or local network 104b in fig. 2. Networks 102 and 104 may support a user plane location structure. The user plane is a mechanism for carrying messages/signaling for higher layer applications and employs user plane bearers, which are typically implemented using protocols such as User Datagram Protocol (UDP), Transmission Control Protocol (TCP), and Internet Protocol (IP), all of which are known in the art. Messages/signaling supporting location services and positioning (from a network perspective) may be carried as part of the data in the user plane structure.

The networks 102 and 104 may implement any user plane architecture, such as V1 or V2 user plane from CDMA development organization (CDG), x.s0024 user plane from 3GPP2, Secure User Plane Location (SUPL) from Open Mobile Alliance (OMA), and so on. S0024 is applicable to 3GPP2 networks. SUPL is applicable to 3GPP and 3GPP2 networks. The V2 user plane is described in document 80-V6410-2NP entitled "Location-Based Services V2 System Specification" (1/19/2005). All the user plane structures are described in publicly available literature.

In the description herein, the term "MPC" generally refers to an entity that supports location services, the term "PDE" generally refers to an entity that supports positioning, the term "mobile station" generally refers to an entity that can communicate with the MPC for location services and/or the PDE for positioning, and the term "LCS client" generally refers to an entity that requests the location of the mobile station. The MPC may be MPC in V1 and V2 user planes, SUPL Location Center (SLC) in SUPL, location server (PS) in x.s0024, Gateway Mobile Location Center (GMLC) in 3GPP, etc. The PDE may be a PDE in the V1 and V2 user planes, a SUPL Positioning Center (SPC) in SUPL, a Serving Mobile Location Center (SMLC) or stand-alone SMLC (sas) in 3GPP, etc. The mobile station may be a mobile station in V1 and V2 user planes, a SUPL Enabled Terminal (SET) in SUPL, a User Equipment (UE) in 3GPP, and the like. MPC, PDE, mobile station, and LCS client may also be referred to by other names in other networks or other location structures.

Networks 102 and 104 may support LCS for roaming mobile stations based on trusted and/or untrusted models. Table 1 gives a short description about the trusted and untrusted models.

TABLE 1

For both trusted and untrusted models, the LCS may be requested by a Wireless Application Protocol (WAP) pull application, a network initiation application, an MS-resident application, and the like. A WAP pull application is an application that pulls data from the network. The network-initiated application is an application (e.g., LCS client 170) that resides on or interacts with the network side. MS-resident applications are applications resident on mobile station 110 and may be a wireless binary runtime environmentAn application program,Application programs, and the like.

Various location sessions may be supported, such as single fix, track fix, gpsOne positioning, cell/sector positioning, and so on. Single fix refers to the return of a single position fix for a target mobile station to the LCS client. Track-pointing refers to the return (e.g., periodically) of multiple position fixes of a target mobile station to an LCS client. The tracking fix may be initiated by the LCS client or the mobile station and cancelled by the LCS client or the mobile station. The mobile station may also be handed off from one S-MPC to another S-MPC and/or from one S-PDE to another S-PDE during tracking fix.

Various positioning methods/types may also be supported, such as gpsOne positioning, cell/sector positioning, and so on. gpsOne positioning refers to satellite-based positioning methods such as GPS, a-GPS, etc. Cell/sector positioning refers to network-based positioning methods such as A-FLT, E-OTD, OTDOA, enhanced cell ID, etc.

Various message flows may be used for different location sessions initiated by different applications in the trusted and untrusted models. The message flow may also be referred to as a call flow, procedure, etc. Some exemplary message flows are described below. In the following message flow, mobile station 110 may conduct a data session with home network 104 using mobile IP, Session Initiation Protocol (SIP), layer 2 tunneling protocol (L2TP), or some other communication protocol that supports packet data roaming. For each message flow, service authorization may be performed for the untrusted model and omitted for the trusted model.

Fig. 3 shows a message flow 300 for WAP pull single fix using gpsOne positioning. The mobile station 110 attempts to access a location-sensitive Uniform Resource Locator (URL) and sends a hypertext transfer protocol (HTTP)/Wireless Session Protocol (WSP) request to the LCS client 170 (step a). LCS client 170 recognizes that mobile station 110 is gpsOne enabled and proceeds with the appropriate message flow. The LCS client 170 responds to the HTTP request with an HTTP response containing a gpsOne trigger (step b). Mobile station 110 receives the HTTP response and may prompt the user to allow location (step c). Upon receiving the user permission, the mobile station 110 sends a start positioning procedure request (SPPReq) message to the H-MPC160 (step d), if applicable. The SPPReq message may include information such as the application type (in this case set to WAP), System Identifier (SID) and Network Identifier (NID), single fix indication, quality of service location (QoS) information, and the like. The SID/NID identifies the visited network 102 currently serving the mobile station 110 and may be obtained via a system parameter message broadcast by base stations in the visited network.

In general, mobile station 110 may send any information that may provide the current network location of mobile station 110. This network location information may be radio technology dependent. For example, SIDs, NIDs, and/or base station identifiers (BaseID) may be used for IS-2000 Release 0 and A, which are commonly referred to as CDMA 20001X. Sector identifier (SectorID) may be used for IS-856, which IS commonly referred to as CDMA 20001 xEV-DO. Mobile Country Code (MCC), Mobile Network Code (MNC), Location Area Code (LAC) and/or cell identity Code (CI) may be used for GSM. MCC, MNC and/or UTRAN cell identity (UC-ID) may be used for W-CDMA. An access point identifier (AP ID) or a Media Access Control (MAC) address may be used for the WLAN. The network location information may also include location coordinates (e.g., abscissa and ordinate) of a base station in a cellular network, an access point in a WLAN, or some other transmitting station in a wireless network. For clarity, much of the description below assumes that the SID and NID are used for network location information.

The H-MPC160 receives the SPPReq message and (if applicable) performs authorization to ensure that this particular user and LCS client are authorized to obtain the requested location (step e). The H-MPC160 may use the QoS information in the SPPReq message and the LCS client profile to determine whether a gpsOne bearing is appropriate (as opposed to a cached bearing or a cell/sector based bearing). H-MPC160 determines that mobile station 110 is roaming and selects an appropriate S-MPC (which in this example is S-MPC 150) based on the SID/NID information. H-MPC160 then sends a roaming request message to S-MPC150, which may include information such as the application type, International Mobile Subscriber Identifier (IMSI) of mobile station 110, gpsOne location type, SID/NID, PDE access duration, etc.

S-MPC150 receives a roam request message from H-MPC160 with instructions to perform gpsOne positioning and determines the appropriate S-PDE, which in this example is S-PDE140, based on the SID/NID information. S-MPC150 then sends a GPOSREQ' message that invokes and seeds S-PDE140 so that S-PDE will accept the incoming Mobile Originated (MO) IS-801 location session from mobile station 110 (step f). The IS-801 positioning session IS a session for satellite-based positioning (e.g., to obtain assistance data, position estimates, etc.), and IS also referred to as an IS-801 session, a gpsOne session, a GPS session, etc. The GPOSREQ' message may include information such as IMSI, gpsOne positioning type, PDE access duration, etc. The S-PDE140 returns a GPOSREQ 'message containing a position pending acknowledgement for the GPOSREQ' message (step g). S-MPC150 receives the gposreq' message from S-PDE140 and sends a roaming request acknowledgement message with the address of S-PDE140 to H-MPC160 (step H). The H-MPC160 receives the acknowledgement from the S-MPC150 and sends an SPPRes message indicating that the mobile station 110 IS performing an IS-801 session and including the address of the S-PDE140 (step i).

The mobile station 110 and the S-PDE140 then perform an MO IS-801 session (step j). A position estimate for mobile station 110 IS obtained and made available to the mobile station at the end of the IS-801 session. S-PDE140 then sends a gposreq' message informing S-MPC150 that the IS-801 session IS terminated normally and includes a position estimate (step k).

The S-MPC150 sends a location report message to the H-MPC160 reporting a successful position fix and providing a position estimate (step 1). H-MPC160 may store the position estimate, which may be used later as a cache position for subsequent requests. Mobile station 110 then re-requests the location sensitive URL and provides a position estimate along with the request (step m). The LCS client 170 downloads the requested content to the mobile station 110 (step n).

Messages between various entities are described in the following publicly available documents:

80-V5456-2NP, titleIs'UserPlane MS-MPC Protocol Specification (1, 5, 2005) which describes messages between a mobile station and an MPC (e.g., SPPReq and SPPRes), and between a mobile station and an LCS client (e.g., HTTP/WSP requests and responses),

80-V6195-2NP entitled "Mobile Position Center (MPC) V2 protocol specification" (21/1/2005), which describes messages between MPCs (e.g., roaming request acknowledgement, and location report),

80-V5458-2NP, titled "UserPlane E5 ' V2 Protocol Specification "(12/13/2003), which describes messages between MPC and PDE (e.g., GPOSREQ ' and GPOSREQ '), and

TIA/EIA/IS-801 entitled "Position Determination Service Standards for Dual mode spread Spectrum Systems" which describes messages between a mobile station and a PDE.

Fig. 4 shows a message flow 400 for WAP pull single fix using cell/sector positioning. Steps a through d of message flow 400 are the same as steps a through d of message flow 300 in fig. 3. In step e, H-MPC160 determines that mobile station 110 is roaming based on the SID/NID information and that cell/sector positioning is appropriate. The H-MPC160 determines an appropriate S-MPC (which in this example is the S-MPC 150) based on the SID/NID information and sends a roaming request message with a cell/sector positioning type, etc. to the S-MPC 150.

The S-MPC150 receives a roaming request message with an instruction to perform cell/sector positioning from the H-MPC160 and sends a GPOSREQ' message including a cell/sector positioning type, etc. to the S-PDE140 (step f). S-PDE140 responds to S-MPC150 with a gposreq' message containing a cell/sector based position estimate for mobile station 110 (step g). The S-MPC150 sends a location report message to the H-MPC160 reporting a successful location and including a position estimate (step H). H-MPC160 sends an SPPRes message containing the position estimate to mobile station 110 (step i). Steps j and k of message flow 400 are the same as steps m and n, respectively, of message flow 300 in fig. 3.

Fig. 5 shows a message flow 500 for pulling a single fix using WAP located with gpsOne with DNS queries. Steps a through c of message flow 500 are the same as steps a through c of message flow 300 in fig. 3. Mobile station 110 recognizes that it is roaming and sends a query to DNS server 136 for the address (e.g., IP address) of S-PDE140 (step d). The query may include a location specific DNS string or URL, e.g., sid. DNS server 136 responds with the address of S-PDE140 (step e). The mobile station 110 and the S-PDE140 then perform a MOIS-801 session and make a position estimate available to the mobile station at the end of the IS-801 session (step f). Steps g and h of message flow 500 are the same as steps m and n, respectively, of message flow 300 in fig. 3.

Typically, mobile station 110 may send a location-specific DNS query to DNS server 136(V-DNS) in visited network 102 (as shown in FIG. 5) or to DNS server 176(H-DNS) in local network 104 (not shown in FIG. 5). For the V-DNS option, DNS server 136 may be assigned by PDSN/FA 134 during PPP negotiation data call setup. Mobile station 110 may send a DNS query to DNS server 136, which DNS server 136 may recognize and resolve the location-specific URL and return the IP address of the S-PDE in visited network 102 to mobile station 110. For the H-DNS option, mobile station 110 may send a DNS query that may be redirected to DNS server 176 by home agent 174. DNS server 176 may resolve the location-specific URL and return the S-PDE IP address back to mobile station 110. For both DNS options, SID/NID information may be omitted in the DNS query if the visited network 104 has one PDE or designates one PDE to serve roaming mobile stations.

Fig. 6 shows a message flow 600 for network-initiated single fix using gpsOne positioning. The LCS client 170 requests the location of the mobile station 110 from the H-MPC160 via a Mobile Location Protocol (MLP) Location Immediate Request (LIR) message (step a). H-MPC160 may verify that LCS client 170 is authorized to obtain the location of the user (step b). Upon successful authorization (if applicable), H-MPC160 sends a Mobile Termination (MT) SMS location request message to mobile station 110 indicating a gpsOne location and including information such as notification and authentication procedures, a Correlation Identifier (CI) for identifying the location session, and so on (also step b). Mobile station 110 receives the SMS message and, if applicable, prompts the user for consent. The mobile station 110 then sends an SPPReq message to the H-MPC160, which serves as a reply to the MT SMS message in step b, and may include information such as CI, IMSI, SID/NID, etc. (step c).

H-MPC160 determines that mobile station 110 is roaming and selects S-MPC150 based on the SID/NID information. The H-MPC160 then sends a roaming request message to the S-MPC150, which may include information such as CI, IMSI, SID/NID, PDE access duration, etc. (step d). S-MPC150 receives the roam request message with instructions to perform gpsOne positioning and sends a GPOSREQ' message that invokes and seeds S-PDE140 (step e). The S-PDE140 returns a gposreq' message containing a position pending acknowledgement (step f). S-MPC150 receives the gposreq' message and sends a roaming request acknowledge message with the address of S-PDE140 to H-MPC160 (step g).

H-MPC160 receives the acknowledgement message from S-MPC150 and sends an sppras message to mobile station 110 instructing mobile station 110 to perform an IS-801 session and including the address of S-PDE140 (step H). The mobile station 110 performs a MO IS-801 session with the S-PDE140 to obtain a position estimate for the mobile station (step i). S-PDE140 then sends the position estimate to S-MPC150 in a gposreq' message (step j). The S-MPC150 forwards the position estimate to the H-MPC160 in a position report message (step k). The H-MPC160 then provides the position estimate to the LCS client 170 in an MLP Location Immediate Answer (LIA) message (step l).

Fig. 7 shows a message flow 700 for network initiated single fix using cell/sector positioning. Steps a to e of message flow 700 are similar to steps a to e of message flow 600 in fig. 6, except for the positioning method. The SMS message sent by the H-MPC160 in step b indicates a cell/sector location instead of a gpsOne location. The SPPReq message sent by the mobile station 110 in step c includes information related to the cell/sector anchor point (e.g., SID/NID, etc.). The roaming request message sent by the H-MPC160 to the S-MPC150 in step d indicates cell/sector location. The GPOSREQ' message sent by S-MPC150 to S-PDE140 in step e indicates cell/sector location and may include a base station ID, etc. S-PDE140 provides the cell/sector based position estimate to S-MPC150 in a gposreq' message (step f). The S-MPC150 forwards the position estimate to the H-MPC160 in a position report message (step g). H-MPC160 sends the SPPRes message with acknowledgement to mobile station 110 (step H) and provides the position estimate to LCS client 170 (step i).

Fig. 8 shows a message flow 800 for a network-initiated positioning session rejected by mobile station 110. Steps a and b of message flow 800 are the same as steps a and b of message flow 600 in fig. 6. H-MPC160 may verify that LCS client 170 is authorized to obtain the location of mobile station 110. The H-MPC160 then sends an MT SMS location request message to the mobile station 110 indicating a gpsOne or cell/sector location and including information such as notification and authentication procedures (step c). Mobile station 110 receives the SMS message and, if applicable, prompts the user for consent (step d). If the user rejects the request or if the request cannot be serviced (e.g., because a voice call is in progress, etc.), mobile station 110 sends a MOSMS message to H-MPC160 that rejects the location request and acts as a reply to the MT SMS message (step e). The MO SMS message may include an appropriate reject cause code. If the user rejects the gpsOne location request, no IS-801 session occurs. If the reject cause indicates that user consent was obtained but the TCP/IP socket cannot be opened, the H-MPC160 may trigger a lower accuracy (e.g., cell/sector) location session. The H-MPC160 provides the location state to the LCS client 170 (step f).

Fig. 9 shows a message flow 900 for network-initiated tracefix using gpsOne positioning. The LCS client 170 requests the location of the mobile station 110 from the H-MPC160 via an MLP-Triggered Location (TL) report request message (step a). This request may include a start time, a stop time, and a time interval (T) between position fixes for a track-fix session, QoS information, and the like. The H-MPC160 may verify for the user that the LCS client 170 is authorized to make this type of request (step b). The H-MPC160 may also use the QoS information and LCS client profile to determine whether a gpsOne bearing is appropriate (as opposed to a cached or cell/sector based bearing). In this case, the H-MPC160 determines that a gpsOne location is appropriate. The H-MPC160 may determine the number of setpoints based on the start time, stop time, and time interval received from the LCS client 170.

Upon successful authorization of the LCS client 170, the H-MPC160 sends an MT SMS location request message to the mobile station 110 indicating an IS-801 session and including information such as notification and authentication procedures, CI, number of fixes (N), time interval between fixes (T), H-MPC ID, etc. (step c). Mobile station 110 receives the SMS message and, if applicable, prompts the user for consent. The mobile station 110 then sends an SPPReq message to the H-MPC160, which serves as a reply to the MT SMS message in step c and may include information such as user approval or disapproval, CI, IMSI, SID/NID, session duration, etc. (step d). The session duration is equal to the number of fixed points times the time interval between fixed points.

H-MPC160 determines that mobile station 110 is roaming and selects S-MPC150 based on the SID/NID information. The H-MPC160 then sends a roam request message to the S-MPC150 with information used by the S-MPC150 to support a tracking session using gpsOne positioning (step e). This information may include CI, IMSI, SID/NID, session duration, stop time, etc. S-MPC150 receives the roam request message with instructions to perform gpsOne positioning and sends a GPOSREQ' message to S-PDE140 that invokes and seeds S-PDE140 and includes information for tracking the session (e.g., PDE access duration) (step f). The S-PDE140 returns a gposreq' message containing an acknowledgement (step g). S-MPC150 receives the gposreq' message and sends a roam request acknowledge message with the address of S-PDE140 to H-MPC160 (step H).

The H-MPC160 sends an MLP TL report reply to the LCS client 170 (step i), which may occur after step b (if no user consent is required) or after step d (if user consent is required and obtained). After receiving the acknowledgement in step H, the H-MPC160 sends an SPPRes message to the mobile station 110 indicating that the mobile station 110 IS performing an IS-801 session and including the address of the S-PDE140 (step j). Mobile station 110 performs a MO IS-801 session with S-PDE140, e.g., to download assistance data to mobile station 110 (step k). The S-PDE140 then provides the S-MPC150 with relevant information about IS-801 session completion in a gposreq' message (step l). The S-MPC150 forwards information about the completion of the session to the H-MPC160 in a session state report message (step m).

For the first position fix, the mobile station 110 provides the position information to the H-MPC160 in a position report message (step n). The H-MPC160 returns a position report response confirming the position report message (step o). H-MPC160 reports the location of mobile station 110 via an MLP TL report message sent to LCS client 170 (step p). For the second position fix (which occurs after time interval T), steps n, o and p are repeated as steps q, r and s, respectively. The mobile station 110 and the S-PDE140 may perform additional MO IS-801 sessions whenever needed to download assistance data and provide updated location information. Steps k, l and m are repeated as steps t, u and v, respectively. Each additional fix may be achieved by repeating steps n, o and p. For the last azimuth fix, steps n, o and p are repeated as steps w, x and y, respectively. MS-assisted tracking can be used for situations where the time between fixes is greater than a certain time interval (e.g., 1800 seconds).

Fig. 10 shows a message flow 1000 for canceling a network-initiated trace session by an LCS client 170. A network-initiated trace session for mobile station 110 may begin as shown in fig. 9 and may proceed normally (step a). At any time during the tracking session, the LCS client 170 may send an MLP TL report stop request message to the H-MPC160 to cancel the tracking session (step b). H-MPC160 then sends an MT SMS traceback session cancel message to mobile station 110 indicating that no other fix is required (step c). When it is confirmed that the MT SMS message is delivered to the mobile station 110, the H-MPC160 sends a location report cancellation message to the S-MPC150 (step d). The S-MPC150 receives the location report cancellation message and sends a CANCEL 'message to the S-PDE140 (step e), the S-PDE140 returns a CANCEL' message to the S-MPC150 (step f). The S-MPC150 sends a location report message to the H-MPC160 indicating that the tracking session has been cancelled and the position result is set to "not applicable" (step g). The H-MPC160 completes the trace session close by sending an MLP TL report stop acknowledgement to the LCS client 170 (step H).

Fig. 11 shows a message flow 1100 for canceling a network-initiated trace session by mobile station 110. A network-initiated trace session for mobile station 110 may begin as shown in fig. 9 and may proceed normally (step a). At any time during the tracking session, mobile station 110 may send a MO SMS cancel location notification message to H-MPC160 to cancel the tracking session (step b). Steps c through g of message flow 1100 are the same as steps d through h, respectively, of message flow 1000.

Mobile station 110 may have a pending network-initiated tracking session and may roam out of coverage of current S-MPC150 and S-PDE 140. H-MPC160 may receive a session state report message from S-MPC150 indicating that mobile station 110 is outside the service area of S-PDE 140. The H-MPC160 may then send a position report response message to the mobile station 110 containing information about the new S-PDEs that may serve the mobile station 110 at the current location of the mobile station 110.

Fig. 12 shows a message flow 1200 for network-initiated tracking fix using inter-MPC handoff. Steps a through m of message flow 1200 are used to initiate a trace session and are the same as steps a through m, respectively, of message flow 900 in fig. 9. Steps n, p, and q of message flow 1200 are for the first azimuth fixed point and are the same as steps n, p, and q, respectively, of message flow 900.

At a later time, the mobile station 110 and the S-PDE140 perform another MO IS-801 session, which fails because the mobile station 110 IS outside the service area of the S-PDE140 (step q). S-PDE140 then informs S-MPC150 by sending a gposreq' message with an error cause of "S-PDE is not within the service area" (which means that mobile station 110 is outside the service area of S-PDE 140): the IS-801 session fails (step r). The S-MPC150 reports the state of the IS-801 session to the H-MPC160 via a session state report message containing the IS-801 session information and the error cause indicated by the S-PDE140 (step S). The H-MPC160 determines that the mobile station 110 is roaming and is outside the service area of the S-PDE140 (step t).

After the time interval T has elapsed, the mobile station 110 sends a position report message to the H-MPC160 (step u). The H-MPC160 uses the SID/NID information in the position report message to determine a new S-MPC (which in this example is S-MPC 152). The H-MPC160 then triggers a roaming procedure. To determine the new S-PDE, the H-MPC160 sends a roam request message to the S-MPC152 with information used by the S-MPC152 to support the remaining tracking session using gpsOne positioning (step v). This information may include the stop time, the remaining session duration, etc. The S-MPC152 receives the roam request message with instructions to perform a gpsOne position fix and sends a GPOSREQ' message to the new S-PDE, which in this example is S-PDE142, which invokes the S-PDE142 and includes information for the remaining tracking sessions, such as PDE access duration (step w). The GPOSREQ' message also seeds the S-PDE142 so that it will accept the incoming MO IS-801 session for the trace session. The S-PDE142 returns a gposreq' message containing the acknowledgement (step x). The S-MPC152 receives the gposreq' message and sends a roam request confirm message with the address of the S-PDE142 to the H-MPC160 (step y).

The H-MPC160 then sends a position report reply message to the mobile station 110 confirming the position report message in step u and including information about the new S-PDE142 (step z). The H-MPC160 reports the location of the mobile station 110 to the LCS client 170 in an MLP TL report message (step aa). The H-MPC160 also sends a location report cancellation message to the original S-MPC150 to inform the S-MPC150 to: it shall clear the resources allocated to the tracking session (step bb). The S-MPC150 receives the location report cancellation message and sends a CANCEL 'message to the original S-PDE140 (step cc), which original S-PDE140 sends a CANCEL' message back to the S-MPC150 (step dd). The S-MPC150 then sends a location report message to the H-MPC160 acknowledging the location report cancellation message (step ee). The mobile station 110 may perform an MO IS-801 session with the new S-PDE142 (step ff). The S-PDE142 provides information about IS-801 session completion to the S-MPC 152. Although a session is conducted with the new S-MPC152 and the new S-PDE142, the remaining trace sessions may be conducted as described above for the message flow 900 in fig. 9.

Mobile station 110 may have a pending network-initiated tracking session and may roam out of coverage of current S-PDE140 but may still be within coverage of S-MPC 150. The H-MPC160 may then send information about the new S-PDEs that may serve the mobile station 110 at the current location of the mobile station 110.

Fig. 13 shows a message flow 1300 for network-initiated tracking fix using intra-MPC handoff. Steps a to u of message flow 1300 are the same as steps a to u, respectively, of message flow 1200 in fig. 12. H-MPC160 determines that S-MPC150 may serve mobile station 110 based on the SID/NID information received from mobile station 110 in step u. To determine a new S-PDE, H-MPC160 sends a roam request message to S-MPC150 that includes information (e.g., stop time, remaining session duration, etc.) used by S-MPC150 to support the remaining tracking session using gpsOne positioning (step v). S-MPC150 receives a roam request message from H-MPC160 with instructions to perform gpsOne positioning and sends a GPOSREQ' message to the new S-PDE (which is S-PDE141 in this example) that invokes and seeds S-PDE141 and includes information for the remaining tracking sessions (e.g., PDE access duration) (step w). The S-PDE141 returns a gposreq' message containing an acknowledgement (step x). S-MPC150 receives the gposreq' message and sends a roaming request confirm message with the address of S-PDE141 to H-MPC160 (step y). The H-MPC160 then sends a position report reply message to the mobile station 110 acknowledging the position report message in step u and containing information for the new S-PDE141 (step z). The H-MPC160 reports the location of the mobile station 110 to the LCS client 170 in an MLP TL report message (step aa). Steps bb, cc, dd, and ee of message flow 1300 are the same as steps cc, dd, ff, and gg, respectively, of message flow 1200. Although in session with original S-MPC150 and new S-PDE141, the remaining trace sessions may proceed as described above for message flow 900 in fig. 9.

Fig. 14 shows a message flow 1400 for network-initiated tracking fix using cell/sector positioning. Steps a and b of message flow 1400 are similar to steps a and b of message flow 900 in fig. 9. However, in this case, the H-MPC160 determines that cell/sector location is appropriate. The H-MPC160 sends an MT SMS location request message to the mobile station 110 indicating the cell/sector location and including information such as notification and authentication procedure, CI, number of fixes (N), time interval between fixes (T), H-MPC ID, etc. (step c). Mobile station 110 receives the SMS message and, if applicable, prompts the user for consent. The mobile station 110 then sends an SPPReq message to the H-MPC160, which serves as a reply to the MT SMS message in step c and may include information such as user approval or disapproval, CI, IMSI, SID/NID, session duration, etc. (step d). The H-MPC160 sends an MLP TL report reply to the LCS client 170 (step e). The H-MPC160 also sends an SPPRes message to the mobile station 110 indicating that the mobile station 110 uses cell/sector positioning (step f).

H-MPC160 determines that mobile station 110 is roaming and selects S-MPC150 based on the SID/NID information. The H-MPC160 then sends a roaming request message to the S-MPC150 with information used by the S-MPC150 to support a tracking session using cell/sector location (step g). S-MPC150 receives the roaming request message with the instruction to perform cell/sector positioning and sends a GPOSREQ' message with information for cell/sector positioning to S-PDE140 (step h). The S-PDE140 returns a gposreq' message containing the cell/sector based position estimate for the mobile station 110 (step i). The S-MPC150 forwards the position estimate to the H-MPC160 in a position report message (step j). The H-MPC160 provides the LCS client with a position estimate for the first fix in an MLP TL report message (step k).

For the second position fix after the time interval T has elapsed, the mobile station 110 sends a position report message to the H-MPC160 containing information such as the current SID/NID, BASE _ ID, etc. (step l). The H-MPC160 returns a position report response message confirming the position report message (step m). The subsequent steps n to r for the second fix are the same as steps g to k for the first fix, respectively. Each additional fix may be achieved by repeating steps l through r. The tracking session continues until the last position fix is reported in steps s to y. For S-MPC150 and S-PDE140, tracking fix using cell/sector location is achieved using a series of single fix points.

LCS client 170 may terminate message flow 1400 by sending an MLP TL report stop request message (as shown in fig. 10) or some other message. Mobile station 110 may terminate message flow 1400 by sending an MT SMS cancel track session message (as shown in fig. 11) or some other message. The LCS client 170 or the mobile station 110 may also terminate the message flow 1400 in a manner similar to terminating a fixed-point tracked message flow for mobile stations within an area served by the mobile station's H-MPC.

FIG. 15 shows a message flow 1500 for MS-resident single fix using gpsOne positioning. MS-resident application 112 calls a gpsOne Application Programming Interface (API) to request a single fix using gpsOne positioning (step a). User notification and/or authentication may occur before step a and/or after step a. If the user triggers the MS to host a single-time fixed-point application, steps b through i, k, and l are performed as described above for steps c through k, respectively, of message flow 600 in fig. 6. In step i, a position estimate for mobile station 110 IS obtained via the MO IS-801 session. In step j, the gpsOne API returns the position estimate to the MS-resident application 112.

Fig. 16 shows a message flow 1600 for MS camping single fix using cell/sector positioning. MS-resident application 112 calls the gpsOne API to request a single fix using gpsOne positioning (step a). User notification and/or authentication may occur before step a and/or after step a. The mobile station 110 then sends a SPPReq message to the H-MPC160, which may include information such as the application type, application ID, session duration (set to 0 for single fix), IMSI, SID/NID, etc. (step b). H-MPC160 may verify that location is allowed for this user/application combination (step c). The H-MPC160 may also check to see if a gpsOne bearing is needed, and in this case, it is appropriate to determine that a cell/sector based bearing is appropriate.

H-MPC160 determines that mobile station 110 is roaming and selects S-MPC150 based on the SID/NID information. The H-MPC160 then sends a roaming request message to the S-MPC150 that may include information such as IMSI, SID/NID, cell/sector location type, etc. (step d). S-MPC150 receives the roaming request message with instructions to proceed with cell/sector positioning and sends a GPOSREQ' message to S-PDE140 (step e). S-PDE140 returns the cell/sector based position estimate for mobile station 110 to S-MPC150 in a gposreq' message (step f). The S-MPC150 forwards the position estimate to the H-MPC160 in a position report message (step g). H-MPC160 then sends the position estimate to mobile station 110 in a SPPRes message (step H). The gpsOne API then returns the position estimate to the MS-resident application 112 (step i).

Fig. 17 shows a message flow 1700 for MS-resident tracking fix using gpsOne positioning. MS-resident application 112 calls the gpsOne API to request a tracking fix located using gpsOne (step a). User notification and/or authentication may occur before step a and/or after step a. The request may include the number of fixes (N), the time interval between fixes (T), etc. The mobile station 110 then sends a SPPReq message to the H-MPC160, which may include information such as the application type, application ID, session duration (determined based on N and T), IMSI, SID/NID, etc. (step b). H-MPC160 may verify that location is allowed for this user/application combination (step c). In this case, the H-MPC160 may determine that a gpsOne location is appropriate. Steps d to g of message flow 1700 are the same as steps e to h, respectively, of message flow 900 in fig. 9.

The H-MPC160 transmits an SPPRes message to the mobile station 110 indicating that the mobile station 110 performs an IS-801 session and including the address of the S-PDE140 (step H). The mobile station 110 performs a MO IS-801 session with the S-PDE140 and makes a position estimate available to the mobile station 110 at the end of the IS-801 session (step i). If MS-based positioning IS used and the mobile station 110 has current ephemeris information for GPS satellites, then an IS-801 session may be skipped. S-PDE140 then informs S-MPC 150: the IS-801 session terminates normally (step j). The S-MPC150 may return a session status report message to the H-MPC to report the status of the IS-801 session (step k).

The gpsOne API returns the position estimate as the first fix to the MS-resident application 112 (step l). After time interval T, the gpsOne API returns the second fixed point to the MS-resident application 112 (step m). Whenever needed, the mobile station 110 and the S-PDE140 may perform additional MO IS-801 sessions until the final fix IS complete (step n). Position estimates may be made available to mobile station 110 at the end of each IS-801 session. After each additional MO IS-801 session, S-PDE140 may inform S-MPC150 to: the IS-801 session IS normally terminated (step o), and the S-MPC may return a session status report message to the H-MPC160 to report the status of the IS-801 session (step p). The gpsOne API returns the position estimate for the last fix to the MS-resident application 112 (step q).

Fig. 18 shows a message flow 1800 for canceling an MS-resident tracking session by mobile station 110. The MS-resident tracking session for mobile station 110 may begin as shown in fig. 17 and may proceed normally (step a). At any time during the tracking session, the MS-resident application 112 may request to cancel the tracking session (step b). The mobile station 110 may then send a MO SMS cancel location notification message to the H-MPC160 to cancel the tracking session (step c). Steps d to g of message flow 1700 are the same as steps d to g, respectively, of message flow 1000 in fig. 10.

Mobile station 110 may have an MS-resident tracking session pending and may roam out of coverage of current S-MPC150 and S-PDE 140. Upon detecting that the IS-801 session failed due to a PDE handoff error condition, the H-MPC160 may send an MT SMS message to update the MS resident trace session. Upon receiving this MT SMS message, the mobile station 110 may send a new SPPReq message to the H-MPC160 for updated information about the new S-PDE, and may then continue to track position location via the new S-PDE.

Fig. 19 shows a message flow 1900 for MS camping tracking fix using inter-MPC handoff. Steps a through k of message flow 1900 are used to initiate a trace session and are the same as steps a through k, respectively, of message flow 1700 in fig. 17. Steps l and m of message flow 1900 are used for the first two position fixes and are the same as steps l and m of message flow 1700.

At a later time, the mobile station 110 and the S-PDE140 perform another MO IS-801 session, which fails because the mobile station 110 IS outside the service area of the S-PDE140 (step n). S-PDE140 then informs S-MPC150 by sending a gposreq' message with the error cause set to "S-PDE not in service area": the IS-801 session fails (step o). The S-MPC150 then reports the state of the IS-801 session to the H-MPC160 via a session state report message containing the IS-801 session information and the error cause indicated by the S-PDE140 (step p). The H-MPC160 detects that a PDE handoff is required and sends an MT SMS message to the mobile station 110 with a reason code set to "PDE not in service area" (step q). H-MPC160 also cancels the trace session with S-MPC150 and S-PDE140 via steps r through u, which are identical to steps d through g, respectively, of message flow 1000 in fig. 10.

The mobile station 110 receives the MT SMS message and sends a SPPReq message with information for the remaining tracking session (e.g., IMSI, SID/NID, remaining duration, etc.) to the H-MPC160 (step v). The H-MPC uses the SID/NID information in the SPPReq message to determine that the mobile station 110 is roaming and selects a new S-MPC (which in this example is S-MPC 152). The H-MPC160 then sends a roam request message to the S-MPC152 with information (e.g., remaining session duration, etc.) used by the S-MPC152 to support the remaining tracking session using gpsOne positioning (step w). The S-MPC152 receives the roam request message with instructions to perform a gpsOne position fix and sends a GPOSREQ' message to the new S-PDE, which in this example is S-PDE142, which invokes and seeds the S-PDE142 for the tracking session (step x). The S-PDE142 returns a gposreq' message containing the acknowledgement (step y). The S-MPC152 receives the gposreq' message and sends a roam request acknowledge message with the address of the S-PDE142 to the H-MPC160 (step z).

Upon receiving the acknowledgement message, the H-MPC160 sends an SPPRes message instructing the mobile station 110 to perform an IS-801 session and including the address of the S-PDE142 (step aa). The mobile station 110 performs a MO IS-801 session with the S-PDE142 (step bb). After completing the IS-801 session, the S-PDE142 informs the S-MPC 152: the IS-801 session terminates normally (step cc). The S-MPC152 may return a session status report message to the H-MPC160 to report the status of the IS-801 session (step dd). For each subsequent fix, the gpsOne API returns the current position estimate to the MS-resident application 112 (step ee). While the session is in progress with the new S-MPC152 and the new S-PDE142, the remaining trace session may proceed in the normal manner as described for message flow 1700.

Mobile station 110 may have an MS-resident tracking session pending and may roam out of coverage of current S-PDE140 but may still be within coverage of current S-MPC 150. The H-MPC160 may send an MT SMS message to update the MS-resident tracking session and the mobile station 110 may send a new SPPReq message for updated information about the new S-PDE.

Fig. 20 shows a message flow 2000 for MS camp tracking fix using intra-MPC handoff. Steps a to m of message flow 2000 are the same as steps a to m, respectively, of message flow 1700 in fig. 17. Steps n to q of message flow 2000 are the same as steps n to q of message flow 1900 in fig. 19.

The mobile station 110 receives the MT SMS message in step q and sends an SPPReq message with information for the remaining tracking session (e.g., IMSI, SID/NID, remaining duration, etc.) to the H-MPC160 (step r). H-MPC uses the SID/NID information in the SPPReq message to determine that mobile station 110 is roaming and to select S-MPC 150. The H-MPC160 then sends a roam request message to the S-MPC150 with information (e.g., remaining session duration, etc.) used by the S-MPC150 to support the remaining tracking sessions using gpsOne positioning (step S). S-MPC150 receives the roam request message with the instruction to perform gpsOne positioning and sends a GPOSREQ' message to the new S-PDE, which in this example is S-PDE141, which invokes and seeds S-PDE141 for the remaining tracking session (step t). The S-PDE141 returns a gposreq' message containing an acknowledgement (step u). S-MPC150 receives the gposreq' message and sends a roam request acknowledge message with the address of S-PDE141 to H-MPC160 (step v).

Upon receiving the acknowledgement message, the H-MPC160 sends an SPPRes message instructing the mobile station 110 to perform an IS-801 session and including the address of the S-PDE141 (step w). The S-MPC150 sends a CANCEL 'message to release the tracking session with the previous S-PDE140 (step x), and the S-PDE140 returns a CANCEL' message to the S-MPC150 (step y). Steps z to cc of message flow 2000 are the same as steps bb to ee of message flow 1900 in fig. 19. While in session with the new S-PDE141, the remaining tracking session may proceed in a normal manner.

Fig. 21 shows a message flow 2100 for MS-resident single fix using gpsOne positioning. MS-resident application 112 calls the gpsOne API to request a single fix using gpsOne positioning (step a). User notification and/or authentication may occur before step a and/or after step a. The mobile station 110 recognizes that it is roaming and sends a query for the address of the S-PDE to the DNS server 136 (step b). DNS server 136 responds with the address of S-PDE140 (step c). The mobile station 110 and the S-PDE140 then perform a MO IS-801 session and make the position estimate available to the mobile station 110 at the end of the IS-801 session (step d). The gpsOne API returns the position estimate to the MS-resident application 112 (step e).

Message flows 300-2100 show various timers T1-T22 that may be used for different transactions or message pairs. Each timer is shown by a thick dashed line from the point/event where the timer starts to the point/event where the timer stops. If no response or acknowledgement is received by the time the timer expires, appropriate action (e.g., retry action, terminate action, clear resource, send notification, etc.) may be taken. Any suitable duration may be used for each timer.

The local network 104 may support V1 user plane locations and the visiting network 102 may support V2 user plane locations. The following message flow covers the case where the mobile station 110 roams from the home network 104 having a V1 user plane location to the visited network 102 having a V2 user plane location. In these message flows, the H-MPC160 and the S-MPC150 may use the V1 MPC interface, and the S-MPC150 and the S-PDE140 in the visited network 102 may use the V2E 5' interface.

Fig. 22 shows a message flow 2200 for WAP pull single fix using gpsOne positioning. Steps a through e of message flow 2200 are the same as steps a through d of message flow 300 in fig. 3. H-MPC160 sends a roaming request message to S-MPC150 containing a WAP application type, IMSI, gpsOne location type, SID/NID, PDE access duration, etc. (step f). S-MPC150 receives the roaming request message and responds with a roaming request acknowledgement message indicating that S-MPC150 is able to accept the request and including the address and port number of S-PDE140 (step g). The H-MPC160 sends an SPPRes message instructing the mobile station 110 to perform an IS-801 session and including the address and port number of the S-PDE140 (step H).

S-MPC150 sends a GPOSREQ' message that invokes and seeds S-PDE140 and may include information such as IMSI, gpsOne location type, PDE access duration, etc. (step i). S-PDE140 returns a GPOSREQ 'message acknowledging the GPOSREQ' message (step j). The mobile station 110 performs a MOIS-801 session with the S-PDE140 and obtains a position estimate for the mobile station 110 and makes the position estimate available to the mobile station at the end of the IS-801 session (step k). S-PDE140 then sends a gposreq' message to S-MPC150 indicating that the IS-801 session terminated normally and included the position estimate (step l). The S-MPC150 sends the position estimate to the H-MPC160 in a location report message, and the H-MPC160 may store the position estimate for later use (step m). Steps n and o are the same as steps m and n, respectively, of message flow 300.

Fig. 23 shows a message flow 2300 for network initiated single fix using gpsOne positioning. The LCS client 170 requests the location of the mobile station 110 from the H-MPC160 via an MLP LIR message (step a). H-MPC160 may verify that LCS client 170 is authorized to obtain the location of the user (step b). The H-MPC160 may also check to see if gpsOne positioning is appropriate. If the request is authorized, H-MPC160 sends a location request (LOCREQ) message to HLR 166 to determine the current network location of mobile station 110 (step c). The HLR 166 responds by sending the current network location to the H-MPC160 in a logreq message (step d). The H-MPC160 receives the logreq message and checks the current serving MSC ID (MSCID) of the mobile station 110 to determine if the mobile station is within the service area of the H-MPC 160. In this case, the mobile station 110 is outside the service area of the H-MPC 160. H-MPC160 determines the S-MPC for mobile station 110 (which is S-MPC150 in this example) based on the MSCID. The H-MPC160 then sends a roaming request message to the S-MPC150 indicating a gpsOne location (step e). S-MPC150 receives the roaming request message and sends a roaming request acknowledgement indicating that it is able to accept the request and including the address and port number of S-PDE140 (step f). S-MPC150 sends a GPOSREQ' message that invokes and seeds S-PDE140 and includes information such as PDE access duration (step g). The S-PDE140 returns a gposreq' message with a position pending acknowledgement (step h).

The H-MPC160 transmits an MT SMS message indicating that the mobile station 110 performs an IS-801 session and including the address and port number of the S-PDE140 to the mobile station 110 (step i). If verification is required, the user is prompted to allow (step j). The mobile station 110 sends a MO SMS message with information such as user approval or disapproval, SID/NID, etc. to the H-MPC160 (step k). The mobile station 110 performs an MO IS-801 session with the S-PDE140 (step l). S-PDE140 then sends a gposreq' message to S-MPC150 indicating that the IS-801 session terminated normally and including the position estimate for mobile station 110 (step m). The S-MPC 160 forwards the position estimate to the H-MPC160 in a position report message (step n). The H-MPC160 provides the position estimate to the LCS client 170 (step o).

Fig. 24 shows a message flow 2400 for network-initiated single fix in the case of mobile station 110 rejecting a gpsOne positioning request. Steps a through j of message flow 2400 are the same as steps a through j of message flow 2300 in fig. 23. In this case, no user consent is obtained in step j. The mobile station 110 then sends a MO SMS message with the consent indicator set to "user reject request" to the H-MPC160 (step k). The H-MPC160 sends a cancellation message to the S-MPC150 (step l). S-MPC150 sends a CANCEL 'message to S-PDE140 (step m), and the S-PDE140 responds with a CANCEL' message (step n). The S-MPC150 then sends a location report message to the H-MPC160 with the position result set to "not applicable" (step o). The H-MPC160 provides the location state to the LCS client 170 (step p).

FIG. 25 shows a message flow 2500 for MS-resident single fix using gpsOne positioning. MS-resident application 112 calls the gpsOne API to request a single fix using gpsOne positioning (step a). User notification and/or authentication may occur before step a and/or after step a. The mobile station 110 then sends a SPPReq message to the H-MPC160, which may include information such as application type, QoS, SID/NID, IMSI, etc. (step b). The H-MPC160 may perform authorization to ensure that this particular user has access to the requested location application (step c). The H-MPC160 may also check to see that gpsOne positioning is appropriate.

If an IS-801 session IS appropriate, H-MPC160 checks the SID/NID information to determine if mobile station 110 IS within the service area of H-MPC 160. In this case, the mobile station 110 is outside the service area of the H-MPC 160. H-MPC160 selects S-MPC150 based on the SID/NID information and sends a roaming request message to S-MPC150 (step d). S-MPC150 receives the roaming request message and sends a roaming request acknowledgement message indicating that S-MPC150 is able to accept the request and including the address and port number of S-PDE140 (step e). The H-MPC160 transmits an SPPRes message to the mobile station 110 indicating that the mobile station 110 performs an IS-801 session and including the address and port number of the S-PDE140 (step f). S-MPC150 sends a GPOSREQ ' message that invokes and seeds S-PDE140 (step g), which S-PDE140 returns a GPOSREQ ' message to acknowledge the GPOSREQ ' message (step h).

The mobile station 110 performs a MO IS-801 session with the S-PDE140 and makes a position estimate available to the mobile station 110 at the end of the IS-801 session (step i). S-PDE140 sends a gposreq' message to S-MPC150 indicating that the IS-801 session terminated normally and included the position estimate (step j). The gpsOne API returns the position estimate to the MS-resident application 112 (step k). The S-MPC150 sends the position estimate to the H-MPC160 in a position report message (step l).

Fig. 26 shows a block diagram of mobile station 110, RAN 120, S-PDE140, S-MPC150 and H-MPC 160. For simplicity, fig. 26 shows: (a) a controller/processor 2610, a memory 2612, and a transceiver 2614 for the mobile station 110; (b) a controller/processor 2620, a memory 2622, a transceiver 2624, and a communication (Comm) unit 2626 for RAN 120; (c) a controller/processor 2640, a memory 2642, and a communications unit 2644 for the S-PDE 140; (d) a controller/processor 2650, a memory 2652, and a communications unit 2654 for S-MPC 150; and (e) a controller/processor 2660, a memory 2662, and a communication unit 2664 for the H-MPC 160. In general, each entity may include any number of controllers, processors, memories, transceivers, communication units, and the like.

On the downlink, base stations in the RAN 120 transmit traffic data, messages/signaling, and pilot to mobile stations that are within its coverage area. These various types of data are processed by processor 2620 and conditioned by transceiver 2624 to generate a downlink signal that is transmitted via an antenna. On the mobile station 110, downlink signals from the base stations are received via the antennas, conditioned by the transceivers 2614, and processed by a processor 2610 to obtain various types of information for positioning, location services, and other services. For example, the processor 2610 may decode messages for the message stream described above. Memories 2612 and 2622 store program codes and data for mobile station 110 and RAN 120, respectively. On the uplink, mobile station 110 may transmit traffic data, messages/signaling, and pilot to base stations in RAN 120. These various types of data are processed by processor 2610 and conditioned by transceiver 2614 to generate an uplink signal, which is transmitted via the mobile station antenna. At the RAN 120, uplink signals from the mobile station 110 and other mobile stations are received and conditioned by the transceiver 2624 and further processed by a processor 2620 to obtain various types of information, such as data, messages/signaling, and so forth. The RAN 120 may communicate with other network entities via a communication unit 2626.

Within the S-PDE140, a processor 2640 performs processing for the S-PDE, a memory 2642 stores program codes and data for the S-PDE, and a communication unit 2644 allows the S-PDE to communicate with other entities. Processor 2640 may perform processing for S-PDE140 in the message flows described above.

Within the S-MPC150, the processor 2650 performs position and/or location processing for the S-MPC, the memory 2652 stores program code and data for the S-MPC, and the communication unit 2654 allows the S-MPC to communicate with other entities. Processor 2650 may perform processing for S-MPC150 in the message flow described above.

Within the H-MPC160, the processor 2660 performs position and/or location processing for the H-MPC, the memory 2662 stores program code and data for the H-MPC, and the communication unit 2664 allows the H-MPC to communicate with other entities. The processor 2660 may perform processing for the H-MPC160 in the message flow described above.

The techniques described herein may be implemented in a variety of ways. For example, these techniques may be implemented in hardware, firmware, software, or a combination thereof. For a hardware implementation, the processing units used to perform the techniques at each entity (e.g., mobile station 110, S-PDE140, S-MPC150, H-MPC160, etc.) may be implemented within one or more Application Specific Integrated Circuits (ASICs), Digital Signal Processors (DSPs), Digital Signal Processing Devices (DSPDs), Programmable Logic Devices (PLDs), Field Programmable Gate Arrays (FPGAs), processors, controllers, microcontrollers, microprocessors, electronic devices, other electronic units designed to perform the functions described herein, a computer, or a combination thereof.

For a firmware and/or software implementation, the techniques may be implemented with modules (e.g., procedures, functions, and so on) that perform the functions described herein. The firmware and/or software codes may be stored in a memory (e.g., memory 2612, 2642, 2652, or 2662 in fig. 26) and executed by a processor (e.g., processor 2610, 2640, 2650, or 2660). The memory may be implemented within the processor or external to the processor.

The previous description of the disclosure is provided to enable any person skilled in the art to make or use the disclosure. Various modifications to the disclosure will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other variations without departing from the spirit or scope of the disclosure. Thus, the present disclosure is not intended to be limited to the examples described herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims (19)

1. A method of supporting location services, LCS, for a secure user plane location, SUPL, enabled terminal, SET, roaming from a home network and communicating with a visited network, comprising:

receiving, at a local SUPL location center H-SLC in the local network, a location request for a location of the SET, wherein the location request is received from an entity;

determining whether the entity is authorized to obtain the location of the SET prior to determining the location of the SET;

receiving first information from the SET, wherein the first information comprises an indication of a network location of the SET;

determining a serving SUPL location center S-SLC based on the indication of network location of the SET;

requesting a location of the SET from the S-SLC;

receiving second information including a location of the SET from the S-SLC; and

sending the location of the SET received from the S-SLC to the entity as the location of the SET when the entity is authorized to obtain the location of the SET.

2. The method of claim 1, further comprising:

determining that the SET is roaming out of coverage of the H-SLC based on the first information; and

selecting an S-SLC that covers a network location of the SET.

3. The method of claim 1, further comprising:

receiving the location request from an LCS client, wherein the entity is the LCS client;

sending a positioning request to the SET; and

receiving the first information from the SET in response to the positioning request.

4. The method of claim 1, wherein the location request comprises a location request for a plurality of position fixes for the SET.

5. The method of claim 4, further comprising:

receiving the location request from an LCS client, wherein the entity is the LCS client; and

for each of the plurality of position fixes, obtaining a position estimate for the SET and sending the position estimate to the LCS client.

6. The method of claim 5, further comprising:

receiving an indication from the LCS client to cancel reporting the location of the SET; and

sending a notification to the SET to cancel a location report.

7. The method of claim 5, further comprising:

receiving an indication from the SET to cancel reporting of the location of the SET; and

sending a notification of the indication to the LCS client to cancel reporting the location.

8. The method of claim 1, wherein the indication of network location of the SET comprises at least one of a Mobile Country Code (MCC), a Mobile Network Code (MNC), a Location Area Code (LAC), a Cell Identity (CI), and a UTRAN cell identity (UC-ID).

9. The method of claim 1, further comprising instructions to send the location of the SET from the S-SLC to an entity that initiated the location request.

10. An apparatus supporting location services, LCS, for a secure user plane location, SUPL, enabled terminal, SET, roaming from a home network and communicating with a visited network, comprising:

means for receiving a location request for a location of the SET at a local SUPL location center H-SLC in the local network, wherein the location request is received from an entity;

means for determining whether the entity is authorized to obtain the location of the SET prior to determining the location of the SET;

means for receiving first information from the SET, wherein the first information comprises an indication of a network location of the SET;

means for determining a serving SUPL location center S-SLC based on the indication of network location of the SET;

means for requesting a location of the SET from the S-SLC;

means for receiving second information from the S-SLC including a location of the SET; and

sending the location of the SET received from the S-SLC to the entity as a device of the location of the SET when the entity is authorized to obtain the location of the SET.

11. The device of claim 10, wherein the indication of the network location of the SET comprises a System Identifier (SID) and a Network Identifier (NID).

12. The device of claim 10, wherein the indication of the network location of the SET comprises an identifier of an access point.

13. A method of supporting location services, LCS, in a network, comprising a secure user plane location, SUPL, enabled terminal, SET, a local SUPL location center, H-SLC, and a serving SUPL location center, S-SLC, the method at the H-SLC comprising:

receiving, at the H-SLC, a location request message from an LCS client for a location of the SET;

determining whether the LCS client is authorized to obtain the location of the SET prior to determining the location of the SET;

sending a positioning request message to the SET;

receiving, from the SET, a message including an indication of a network location of the SET in response to the positioning request message;

sending a roaming request message to the S-SLC containing the indication of the network location of the SET;

receiving, from the S-SLC in response to the roaming request message, a location report message containing a bearing of a network location of the SET; and

sending a report message to the LCS client containing a position of the network location of the SET as the location of the SET when the LCS client is authorized to obtain the location of the SET.

14. The method of claim 13, wherein the location request message triggers a network initiated tracking fix for cell and sector positioning used.

15. The method of claim 13, further comprising:

receiving a position report message from the SET, the position report message including an indication of a second network location of the SET for a second position fix;

sending a second roaming request message to the S-SLC including the indication of the second network location;

receiving, from the S-SLC in response to the second roaming request message, a second location report message including a cell/sector based position estimate for the SET for the second position fix based on the indication of the second network location; and

sending a Mobile Location Protocol (MLP) -Triggered Location (TL) report message to the LCS client containing the SET's cell/sector based position estimate for the second position fix.

16. A method of supporting location services, LCS, in a network, comprising a secure user plane location, SUPL, enabled terminal, SET, a local SUPL location center, H-SLC, and a serving SUPL location center, S-SLC, the method at the H-SLC comprising:

receiving, at the H-SLC, a location request message for a location of the SET from an application resident on the SET, wherein the location request message includes an indication of a network location of the SET;

determining whether the application resident on the SET is authorized to obtain the location of the SET prior to determining the location of the SET;

transmitting a roaming request message to the S-SLC in response to the location request message;

receiving, from the S-SLC, a location report message containing a bearing of the network location in response to the roaming request message; and

when the application resident on the SET is authorized to obtain the location of the SET, a report message is sent to the application resident on the SET that includes a fix of the network location of the SET as the location of the SET.

17. The method of claim 16, wherein the indication of the network location of the SET comprises a sector identifier SectorID.

18. A secure user plane location, SUPL, enabled terminal, SET, apparatus, comprising:

means for communicating with an access network for a data session;

means for receiving a request for a location of the SET from a location services (LCS) client or an application resident on the SET;

means for sending a first information to a local SUPL location center H-SLC in a local network in response to receiving the request, wherein the first information includes an indication of a network location of the SET;

means for receiving a position estimate for the SET from the H-SLC, the position estimate for the SET determined based on the indication of the network location; and

means for sending the position estimate for the SET received from the H-SLC to the LCS client or the application resident on the SET.

19. The SET device of claim 18, wherein,

means for receiving the request comprises means for receiving the request from the application residing on the SET; and

the means for sending the position estimate for the SET comprises means for sending the position estimate for the SET to the application resident on the SET.