RU2384021C2 - Efficient periodic location reporting in radio access network - Google Patents

Abstract

FIELD: physics; communication.

SUBSTANCE: invention relates to methods of providing position location services in a communication system. The result is achieved due to that, user equipment (UE) interacting with a radio access network (RAN) sends to a network object (for example MSC/SGSN) a request for periodically sending reports on location of UE to a client object. After approval of the request, the MSC/SGSN signals the RAN to initiate periodic transmission of reports on location of UE. RAN can send request the position location centre (for example SAS) to send assistance data to the UE. RAN can coordinate and control periodic transmission of location reports, or can handover control to the position location centre. For each location report transmission, UE sends location information to RAN (for example measurements taken by UE, or location evaluation by UE). SAS evaluates location if UE sends measurements. RAN then sends the location evaluation for UE to MSC/SGSN which sends the location evaluation to the client object.

EFFECT: more efficient provision for position location services, more specifically reduction of excess data traffic and duration of response time for sending location evaluation to the client object.

58 cl, 14 dwg

Description

This patent application claims the priority of provisional US patent application serial number 60/693003, entitled "METHOD AND APPARATUS FOR PROVIDING LOCATION SERVICES WITH SHORT-CIRCUITED MESSAGE FLOWS", filed 21 June 2005; US Patent Application Serial Number 60/711801 entitled "EFFICIENT PERIODIC LOCATION REPORTING IN A RADIO ACCESS NETWORK" (Method and apparatus for periodically transmitting location reports on a radio access network), filed August 25, 2005; US Patent Application Serial Number 60/718112 entitled "EFFICIENT PERIODIC LOCATION REPORTING IN A RADIO ACCESS NETWORK", filed September 16, 2005; US Patent Application Serial Number 60/771180, entitled "EFFICIENT PERIODIC LOCATION REPORTING IN A RADIO ACCESS NETWORK", filed February 6, 2006; US Patent Application Serial Number 60/771217 entitled "CLARIFICATION AND CORRECTION OF PERIODIC LOCATION PROCEDURE", filed February 7, 2006; US Patent Application Serial Number 60/771706, entitled "ADDITION OF PERIODIC LOCATION PROCEDURES", filed February 8, 2006, all assigned to the assignee of this invention and is hereby incorporated by reference in its entirety.

FIELD OF THE INVENTION

The present disclosure generally relates to a communication system, and more specifically to methods for providing location services.

BACKGROUND OF THE INVENTION

It is often desirable, and sometimes necessary, to know the location of a wireless communications device on a network. For example, a wireless user may use a wireless device to browse a website and may click on location-dependent content. The web server can then query the network for the location of the wireless device. The communications network will initiate location processing with respect to the wireless device to determine the location of the wireless device. The communication network then issues a location estimate of the wireless device to a Web server, which can use this location estimate to provide relevant content to the wireless user. There are many other scenarios in which knowing the location of the wireless device is useful or necessary. In the following description, the terms “location” and “position” are synonymous and are used interchangeably.

A message flow (which may also be called a call flow or procedure) is typically executed to obtain a location estimate for the wireless device and send this location estimate to a client entity (eg, a web server). Different messages are usually exchanged between one or more network entities, a wireless device, and a client entity. These messages ensure that each object is provided with relevant information, or that it can receive this information from another object to perform positioning with respect to the wireless communication device and / or deliver a location estimate to the client object. However, these messages add traffic between different network entities. The additional traffic can be especially significant for periodic location reporting, which periodically delivers a location estimate relative to the wireless device to the client entity. Messages can also increase the length of the response time to send a location estimate to a client entity, possibly an unacceptable amount.

Therefore, there is a need in the art for methods for efficiently providing location services.

SUMMARY OF THE INVENTION

This document describes methods for efficiently providing location services (LCS) for positioning using periodic LCS capabilities in a radio access network (RAN). These methods employ RAN-based periodic reporting to periodically report the location of the wireless device to the LCS client. RAN-based periodic location reporting can be used for mobile-complete "location request" (MT-LR) location requests, "network-prompted" location request (NI-LR), and "terminal-initiated" request (MO-LR) ) location determination.

In an embodiment of periodically transmitting location reports on MO-LR requests, the wireless device interacting with the RAN sends to the network entity (1) a request for periodically transmitting location reports of the UE to the client entity and (2) periodic location information. The wireless communication device is also called user equipment (UE), the network entity may be a mobile switching center (MSC) or a packet radio support generalized services (GPRS) support node (SGSN), and the client entity is also called an LCS client. The periodic location information may indicate a schedule of reported events and / or a set of predefined events that trigger (transmit) location reporting. After the request is approved, the MSC / SGSN sends signaling to the RAN to initiate periodic location reporting for the UE. The RAN may request a positioning center (which may also be called an autonomous location service center (SAS) for determining the location of the mobile device) to send assistance data (establishing a connection) to the UE. The RAN may coordinate and manage periodic reporting of location reports, or may transfer control of this SAS. In any case, for each location report determined by the periodic location information, the UE sends location information to the RAN. This location information may comprise (1) measurements made by the UE for base stations and / or satellites or (2) a location estimate for the UE. If the RAN receives measurements from the UE, then the RAN can send measurements to the SAS, which can calculate the location estimate for the UE and return the location estimate to the RAN. The RAN then sends the location estimate for the UE to the MSC / SGSN, which forwards the location estimate to the LCS client. RAN-based periodic location reporting reduces signaling for periodically sending an UE location estimate client to the LCS and also provides better response performance.

The various message flows for RAN-based periodic location reporting are described below. Various aspects and embodiments of the invention are also described below with further details.

BRIEF DESCRIPTION OF THE DRAWINGS

The features and essence of the present invention will become more apparent from the detailed description set forth below when taken in conjunction with the drawings, in which like reference numbers indicate corresponding throughout the description.

1A shows a 3GPP-based communication network (3rd Generation Communication Systems Partnership Project).

FIG. 1B depicts the deployment of a 3GPP-based system that includes many networks.

2A shows a message flow for periodic location reporting for MT-LR.

2B shows a message flow for periodic reporting of location reports for an NI-LR.

Figure 3 shows a message flow for periodically transmitting location reports for MO-LR.

4 shows a message flow for RAN-based periodic location reporting.

FIGS. 5 and 6 show message flows for RAN-based periodic reporting in a “central RNC” (radio network controller) mode and a “central SAS” mode, respectively.

7 shows a message flow for RAN-based periodic notification reporting.

Fig. 8 shows a message flow for RAN-based periodic auto-location for MO-LR.

9 and 10 show message flows for RAN-based periodic reporting for GERAN in packet mode and circuit mode, respectively.

11 shows another deployment of a communications network.

12 shows a block diagram of various network entities of FIG.

DETAILED DESCRIPTION

The word "exemplary" is used herein to mean "used as an example, instance, or illustration." Any embodiment or construct described herein as “exemplary” should not necessarily be construed as preferred or advantageous over other embodiments or constructs.

The methods for periodically transmitting location reports described herein can be used for various wireless networks, such as a code division multiple access (CDMA) network, a time division multiple access network (TDMA), a multiple access network frequency division multiple access (FDMA), orthogonal frequency division multiple access network (OFDMA), a network supporting a combination of the above technologies, a network with a global network coverage area, and the same area of the local area network (WLAN) wireless communication and so on. A CDMA network may implement one or more CDMA radio technologies, such as Broadband CDMA (W-CDMA, W-CDMA), cdma2000, and so on; cdma2000 covers the IS-2000, IS-856, and IS-95 standards. A TDMA network may implement one or more TDMA radio technologies, such as a global system for mobile communications (GSM, GSM), digital advanced mobile telephony (C-UMTS, D-AMPS) and so on. D-AMPS covers the IS-36 and IS-54 standards. These various radio technologies and standards are well known in the art. W-CDMA and GSM are described in documents from an organization called the 3rd Generation Communication Systems Partnership Project (3GPP); cdma2000 is described in documents from an organization called the “3rd Generation Communications Project Partnership Project 2” (GPP2). 3GPP and 3GPP2 documents are publicly available. For clarity, methods for a 3GPP-based network that uses one or more radio technologies and one or more network protocols published by 3GPP are described below. For example, a 3GPP-based network may be a universal mobile communications system (UMTS) network that uses W-CDMA as a radio technology for radio communications and a mobile application subsystem (MAP) as a network protocol for core network functionality.

FIG. 1A shows a 3GPP-based network 100 that provides communication and location services for wireless communication devices called user equipment (UEs) (3GPP terminology) in the following description. For simplicity, only one device UE 120 is shown in FIG. 1A. UE 120 may be fixed or mobile and may also be called a mobile station, terminal, subscriber unit, or some other terminology. UE 120 may also be a cellular telephone, laptop computer, personal digital assistant (PDA), telemetry device, tracking device, and so on. UE 120 may communicate with one or more base stations in a radio access network (RAN) 130. UE 120 may also receive signals from one or more satellites 190, which may be part of a global positioning system (GPS), the European Galileo system, or the Russian Glonass system . UE 120 may measure signals from base stations in RAN 130 and / or signals from satellites 190 and may receive pseudorange measurements for these base stations and satellites. These pseudorange measurements can be used to compute (derive) a location estimate for the UE.

RAN 130 provides wireless connectivity for UE devices located throughout the RAN service area. The RAN 130 interacts with a mobile switching center and / or a GPRS support service node (SGSN) (MSC / SGSN) 140 and also interacts with a mobile device location center (SMLC) and / or an autonomous SMLC (SAS) (SMLC) / SAS) 132. The MSC 140 performs switching functions for circuit-switched calls (eg, setup, routing, and possible (final) disconnection of dial-up voice calls and data requests) for UEs within their service area. The SGSN 140 performs switching and routing functions for packet switched calls and packet switched connections. SMLC / SAS 132 provides positioning services and can support UE-based, UE-based, and network-based positioning modes. Positioning refers to functionality that detects or determines the geographic location of a target UE. A SAS may include several coupled position measuring devices (LMUs) (not shown in FIG. 1A) to facilitate some positioning methods, for example, a positioning method based on an uplink arrival time difference (U-TDOA). An SMLC may be a physical and / or logical RAN subsystem, or it may be physically and logically separate in the case of an autonomous SMLC (SAS). In any case, in the following description, SMLC / SAS 132 is considered as a separate entity, whether it is physically and / or logically part of the RAN or separate from the RAN.

The Mobile Device Location Center (GMLC) 150 performs various functions to support location services, is an interface with external LCS clients, and provides services such as subscriber privacy, access authorization, authentication, subscription billing, and so on. The home subscriber home location register (HLR) / home subscriber server (HSS) 160 stores registration information for UE devices (eg, UE 120) that are subscribers of the network 100. LCS client 170 is a function or entity that requests and / or receives information locations relative to LCS destinations. The LCS destination is the UE whose location is the desired. In general, an LCS client can reside in a network entity or UE, or it can be external to both the network and the UE. LCS client 170 interacts with GLMC 150.

For simplicity, FIG. 1A shows network entities that are suitable for location services. These network entities are described in 3GPP TS 23.271 specification, entitled "Functional stage 2 description of Location Services (LCS) (Release 6)", in 3GPP TS specification 25.305, entitled “Stage 2 functional specification of User Equipment (UE) positioning in UTRAN (Release 6)” Functional stage 2 description of Location Services (LCS) in GERAN (Release 6) " provisions in GERAN (Version 6)), all of which are publicly available.

FIG. 1A shows a case in which the UE 120 communicates with a single network (eg, a core (home) network). All network entities in this network communicate via a core communications network and / or other data networks (not shown in FIG. 1A). UE 120 may be roaming and may interact with various visited networks.

FIG. 1B shows a deployment 101 of a 3GPP-based system that includes a visited / serving network 102, a home network 104, and a requesting network 106. The visited network 102 is the network that is currently serving the UE 120. Home (core) network 104 is a network with which the UE 120 has a subscription. The request network 106 is the network through which the LCS client 170 can create a location request to the UE 120 and / or receive the location of the UE 120. The home network 104 may be the same with or different from the visited network 102 and may be the same with the request network 106 or different from her. The requesting network 106 may also be the same as or different from the visited network 102. Each network may be called a public land mobile network (PLMN).

For the embodiment shown in FIG. 1B, the visited network 102 includes a second access (2G) radio access network 130a (GERAN) with GSM EDGE capabilities (GSM wireless communication system) and a universal terrestrial radio access network 130b (UTRAN) third generation (3G). GERAN 130a interacts with 2G-SGSN 140a and / or 2G-MSC 140b. GERAN 130a can also interact with 3G-SGSN 140c and / or 3G-MSC 140d. UTRAN 130b interacts with 3G-SGSN 140c and / or 3G-MSC 140d. Each MSC may act as a visited MSC (VMSC) and the 3G-MSC 140d may be an MSC server. Visited GMLC (V-GMLC) 150a supports location services for visited network 102 and interacts with multiple MSC 140b and 140d and SGSN 140a and 140c. SMLC / SAS 132 provides positioning services and can interact with GERAN 130a, UTRAN 130b, 2G-MSC 140a and so on.

Home network 104 includes GMLC (H-GMLC) 150b and HLR / HSS 160 own subscribers. H-GMLC 150b supports location services for home network 104. HLR / HSS 160 stores registration information for devices UEs that are subscribers of home network 104. Request network 106 includes a request (R-GLMC) 150c that supports location services for requesting network 106. Although not shown in FIG. 1B, R-GLMC 150c and / or H-GLMC 150b can communicate directly with SGSN 140a, MSC 140b, SGSN 140c and / or MSC 140d in visited network 102 via respective interfaces.

The network entities in FIGS. 1A and 1B may also be denoted by other names in other networks and other location architectures. For example, in the secure location architecture (SUPL) architecture of a user plane published by the Open Alliance (OMA) for mobile communications, the LCS client is sometimes referred to as the SUPL agent, the GLMC is called the SUPL location center (SLC), the UE that supports SUPL is called the terminal ( SET) with SUPL and SLMC support is called the SUPL Positioning Center (SPC). The functions and signaling performed by these SUPL-named entities are not exactly the same as those performed by the corresponding 3GPP-named entities, but are broadly similar and allow compatible services and capabilities. GLMC may also be called a location center, an LCS server, a location server, a positioning center (MPC) of mobile devices, and so on. An SMLC may also be called a positioning object, a positioning center, a position determination object (PDE), and so on. In general, each network can include any combination of network objects that can provide any volume of services. For clarity, much of the following description is for 3GPP-based network 100 of FIG. 1A.

The location of the UE 120 may be requested through (1) applications running in the UE, which results in a mobile device-initiated location request (MO-LR), (2) applications running in the LCS client 170, which results in terminating on the mobile the device requesting (MT-LR) the location, and (3) applications running within any of the PLMNs serving the target UE (e.g., 2G-SGSN 140a, 2G-MSC 140b, 3G-SGSN 140c or 3G-MSC 140d on 1B), which results in a network prompted location request (NI-LR). The location of the UE 120 may be requested once, which results in a single or immediate location report, or multiple using a single request, which results in periodic location reporting. Periodic location reporting can be done using a periodic message stream for MT-LR, a periodic message stream for NI-LR, or a periodic message stream for MO-LR. Periodic location reporting delivers a location estimate relative to the target UE on LCS

the client periodically based on the periodic location information that indicates when to report the location of the UE to the client entity. The periodic location information may be a report transmission event plan and / or a set of triggering events. The plan (schedule) can be set in various formats, such as, for example, the start time, the interval between reports, and one parameter from the stop time, duration or a specific number of reports. Triggering events may correspond, for example, to the UE becoming available, entering or leaving a UE in a predetermined geographical area, finding the UE within predetermined geographical areas, speed or acceleration of the UE exceeding predetermined threshold values, changing location, speed or acceleration of the UE to predetermined threshold values and so on.

A location estimate for UE 120 may be obtained using UE-based, “UE-based”, or “network-based” positioning modes. For UE-based mode, the location of the UE is determined by the UE, possibly together with assistance data from SMLC, GERAN, or UTRAN. For the “using the UE” mode, the location of the UE is determined by the SMLC using (eg, measurements) from the UE. For the “network-based” mode, the location of the UE is determined based on information obtained through the network or already known to it without any special assistance from the UE. For the "network-based" mode, the location of the UE can be determined by measurements in the uplink, made at one or more LMUs or base stations.

UE-based and UE-based modes can use various location methods, such as GPS, GPS assisted (A-GPS), hybrid, Advanced Forward Trilateration (A-FLT), Advanced Observed Time Difference Of Arrival based on Idle Period DownLink (OTDOA) and so on. The network-based mode can use various location methods, such as uplink signal arrival time (U-TOA), uplink signal arrival time difference (U-TDOA), cell-ID (cell identification) ), an improved method of cell-ID and so on. A number of location methods for one or more positioning modes can also be used in combination. The GPS and A-GPS methods compute a location estimate for the UE based on satellite measurements only and are highly accurate. The hybrid method calculates a location estimate based on both satellite and base station measurements and has high accuracy and high reliability. The A-FLT, E-OTD, and OTDOA methods derive a location estimate based on measurements made by a UE of a base station timing diagram and have more intermediate accuracy. The U-TOA and U-TDOA methods compute a location estimate based on UE timing diagrams taken by the network and have more intermediate accuracy. The cell-ID and advanced cell-ID methods compute a location estimate based on a cellular network and have grosser accuracy. These various location methods are known in the art.

Various message flows for supporting periodic transmission of UE location reports to LCS client 170 are described below for 3GPP network 100 in FIG. 1A. These message flows enable the core network (eg, MSC / SGSN 140) to execute and utilize the capabilities of the LCS periodic services in the RAN 130 to efficiently provide RAN-based periodic location reporting. RAN-based periodic location reporting refers to periodic location reporting that is coordinated and controlled by the RAN, unlike the MSC / SGSN, UE, or GMLC.

FIG. 2A shows an embodiment of a message flow 200 for the MT-LR of periodic location reporting. For LCS message flow 200, client 170 sends an LCS Service Request message to GMLC 150 that contains (1) a request to periodically transmit location reports of target UE 120 to LCS client 170 (i.e., a periodic location request) and (2 ) periodic location information ("periodic loc info") (step 1). The GMLC 150 may verify the LCS identity of the client 170, may authenticate the LCS of the client, and may determine whether the LCS client is authorized for the requested location service. If the LCS client 170 is authorized, then the GMLC 150 (1) determines the identifier of the UE 120 and the quality of service (QoS) of the LCS service based on the subscription data for the LCS client 170, the subscription data for the subscriber UE 120 and / or the data provided by the LCS client 170, (2) perform a privacy check based on the privacy profile for the subscriber of the UE, and (3) assigns a reference identifier (ID), which is used to associate subsequent location reports with the initial periodic location request. To verify confidentiality, the GMLC 150 checks whether the LCS client 170 or the LCS client of this type is allowed to request periodic reporting of location reports to the UE 120 and whether the UE needs to be notified of this request and to allow the acceptance or rejection of the request.

If the GMLC 150 does not know the current serving MSC or SGSN for the UE 120, then the GMLC 150 sends a Send Routing Info for LCS message to the HLR / HSS 160 to request routing information for the UE (step 2). HLR / HSS 160 then returns a Send Routing Info for LCS Acknowledgment message, which contains the MSC / SGSN 140 address (step 3). Steps 2 and 3 can be skipped if GMLC 150 already knows the MSC / SGSN 140 address. GMLC 150 then sends a Provide Subscriber Location message to the MSC / SGSN 140, which contains a periodic location request, UE ID, periodic information positioning, and / or other relevant information (step 4).

The MSC / SGSN 140 may authenticate that a periodic location request is permitted (also step 4). If the periodic location request is allowed, then the MSC / SGSN 140 may require the RAN 130 to perform paging and authentication of the UE 120, for example, if the UE 120 was in an inactive mode (step 5). If notification or confidentiality verification is required, the MSC / SGSN 140 notifies the UE 120 to notify the wireless device user of a periodic location request and to request the user to grant or refuse permission (also step 5). UE 120 may present its capabilities on RAN 130 and / or MSC / SGSN 140, for example, does the UE support UE-based and UE-based modes (also step 5). The MSC / SGSN 140 then sends to the UE 120 an LCS Periodic Location Invoke message that contains relevant information for requesting a periodic location (e.g., periodic location information, LCS service QoS, reference ID, and so on) ( stage 6). The LCS Periodic Location Invoke message may also include (1) a list of PLMNs that allow periodic reporting of location reports (for example, MO-LR requests can be triggered) and (2) an indication for each PLMN about whether PLMN is based on RAN periodic location reporting. If the PLMN list is not included, then subsequent MO-LR requests may be limited to the current serving PLMN.

UE 120 then sends an LCS Periodic Location Invoke Acknowledgment message to the MSC / SGSN 140, which indicates whether the periodic location request is received and whether it can be actively supported through subsequent MO-LR requests. The result of the confidentiality check will not be necessary in this message, since it is already included in step 5. If the periodic location request is not accepted, but some confidentiality check is passed in step 5, then the UE 120 will indicate the willingness to allow periodic reporting of location reports, but the impossibility or unwillingness to actively support it with subsequent MO-LR requests. In this case, the MSC / SGSN 140 may still cause periodic location reporting via RAN 130, as described below. Otherwise, an error response is generated by the MSC / SGSN 140 and returned to the GMLC 150. In any case, the MSC / SGSN 140 sends a Provide Subscriber Location Acknowledgment message to the GMLC 150, which indicates whether a periodic location request is received (step 8). This message may contain other relevant information, such as a PLMN list sent to UE 120. The GMLC 150 then sends an LCS Service Response message to the LCS client 170 that contains relevant information (for example, whether a periodic determination request is being received location) (step 9). After that, periodic reporting of the location of the UE to the LCS client 170 is performed using the capabilities of the periodic LCS services in the RAN 130, as described below (step 10).

FIG. 2B shows an embodiment of a message flow 210 for periodically transmitting location reports for NI-LRs. Message flow 210 can be used if the LCS client 170 is either permanently within the MSC / SGSN 140, or is constantly within the same PLMN and is directly connected to the MSC / SGSN 140. Steps 1, 5, 6, 7, 9, and 10 for message flow 210 corresponds to steps 1, 5, 6, 7, 9, and 10, respectively, of message flow 200 of FIG. 2A. For LCS message flow 210, client 170 sends an LCS Service Request message directly to the MSC / SGSN 140, which contains a periodic location request and periodic location information (step 1). The MSC / SGSN 140 may authenticate that the periodic location request is allowed and, if the request is allowed, may require the RAN 130 to complete the radio call and authentication of the UE 120 (step 5). Typically, step 5 does not notify or verify confidentiality. Steps 6 and 7 for message flow 210 are as described above for message flow 200. The MSC / SGSN 140 then sends a LCS Service Response message directly to the LCS client 170, which indicates whether a periodic location request is being received (step 9). After that, periodic transmission of UE location reports to the LCS client 170 is performed using the periodic LCS capabilities in the RAN 130 for periodic LCS, as described below (step 10).

FIG. 3 shows an embodiment of a periodic location reporting message flow 300 for MO-LR. If the UE 120 is inactive, then the UE requests a radio connection and sends a Connection Management (CM) Service Request message to the RAN 130

connection) indicating an independent supplementary service call request (step 1). If the UE 120 is in dedicated mode, then the UE sends a CM Service Request on the already established radio connection (also step 1). RAN 130 forwards the Service Request message to MSC / SGSN 140 (step 2). The MSC / SGSN 140 prompts authentication and encryption if the UE 120 is in an inactive mode, or returns a Direct Transfer CM Service Accept message if the UE 120 is in a dedicated mode (step 3). UE 120 may present its capabilities on RAN 130 and / or MSC / SGSN 140, for example, does the UE support UE-based and UE-based modes (also step 3). For clarity, steps 1-3 of establishing a connection in FIG. 3 involve the use of a circuit switched domain (CS) and signaling is sent to the MSC (rather than SGSN). The steps for establishing a connection for a packet-switched domain (PS) are different and signaling is sent to the SGSN via RAN 130. The connection setup for CS and PS domains is described in 3GPP TS 23.271 specification, which is publicly available.

UE 120 then sends an LCS MO-LR Location Services Invoke message to the MSC / SGSN 140, which contains (1) a request to periodically send location reports to UE 120 to the LCS client 170 (i.e., a request periodic positioning) and (2) relevant information for periodically transmitting location reports (step 4). Relevant information may include any combination of the following:

1) a plan (schedule) for transmitting location reports ("periodic loc info"),

2) specific events used to trigger (initiate) the transmission of location reports to LCS client 170 (also "periodic loc info"),

3) LCS client identification information 170 ("lcs-client-addr") (LCS client address),

4) the identification information of GMLC 150, through which you can access the LCS client 170,

5) QoS of an LCS service, such as accuracy and response time,

6) a preferred method for periodically transmitting location reports, for example MT-LR or MO-LR,

7) the maximum allowable period for any location assessment,

8) whether the UE 120 should be identified on the LCS client 170 using the actual identification information or the actual address of the UE or using an alias, and

9) other relevant information.

The MSC / SGSN 140 verifies that the UE 120 is authorized for the requested location service based on the subscription profile for the UE (also step 4). If the periodic location request is authorized, then the MSC / SGSN 140 sends a MAP Subscriber Location Report message to the GMLC 150 that contains a periodic location request and related information (e.g., periodic location information) (step 5 ) GMLC 150 then forwards the periodic location request and related information to LCS client 170 (step 6). The LCS client 170 sends a response to the UE request to the GMLC 150 (step 7). In an embodiment, any of the MSC / SGSN 140, GMLC 150, and LCS entities of client 170 may refuse or accept a periodic location request. If the request is accepted (for example, is not rejected by any entity), then the GMLC 150 assigns the reference ID to the request. The GMLC 150 then sends a MAP Subscriber Location Report Acknowledgment message to the MSC / SGSN 140 (MAP Subscriber Location Report Acknowledgment) (step 8). MSC / SGSN 140 may receive any combination of the following information:

1) reference ID assigned by GMLC 150,

2) a modified location reporting plan ("periodic loc info"),

3) modified specific events used to initiate the transfer of location reports to LCS client 170 (also "periodic loc info"),

4) the address of GMLC 150, and

5) other relevant information.

The MSC / SGSN 140 sends to the UE 120 an LCS MO-LR Return Result message (LCS service return for MO-LR) that contains information received from the GMLC 150 (step 9). The LCS MO-LR Return Result message may further include (1) a list of PLMNs that allow periodic location reporting and (2) an indication for each PLMN whether the PLMN supports RAN-based periodic location reporting. This applies if UE 120 plays an active role in subsequent periodic reporting of location reports via MO-LR requests. If the PLMN list is not provided, then any subsequent MO-LR requests may be limited to the current serving PLMN. After that, periodic reporting of the location of the UE to the LCS client 170 can be performed using the periodic LCS capability in the RAN 130, as described below (step 10).

In general, any entity (eg, UE 120) may cause RAN-based periodic reporting of the location of the UE to the LCS client 170. In order to support a call by the periodic reporting UE 120 to the RAN 130, the UE 120 may be informed whether each PLMN periodic periodic LCS capabilities in the RAN. This information may be included in the PLMN list sent to UE 120 in step 6 of message flow 200 or in step 9 of message flow 300. This information may also be broadcast by multiple RANs.

For periodic location reporting, the first location reporting usually occurs immediately after the completion of the messaging to initiate periodic location reporting. Location reporting can continue until one of the following events occurs:

1) the reporting period has expired or the total number of messages has been reached,

2) periodic location reporting is canceled by LCS client 170 or GMLC 150, or

3) UE 120 terminates periodic location reporting.

FIG. 4 shows an implementation of a message flow 400 for RAN-based periodic location reporting, which may be used for step 10 of the message flow 200 of FIG. 2A, step 10 of the message flow 210 of FIG. 2B, and step 10 of the message flow 300 of FIG. .3. Steps 1-3 of the message flow 400 are the same as steps 1-3 of the message flow 300. UE 120 then sends an LCS MO-LR Location Services Invoke message to the MSC / SGSN 140 to trigger periodic location reporting (step 4). The LCS MO-LR Location Services Invoke message sent in step 4 of the message flow 300 "requests" periodic reporting of location reports, whereas the LCS MO-LR Location Services Invoke message sent in step 4 of the message flow 400 "starts" "periodically transmitting location reports after a request for a periodic location has been authorized. The LCS MO-LR Location Services Invoke message sent in the message flow 400 contains relevant information, such as, for example, periodic location information, LCS service QoS, LCS identification information of client 170, indicating that the request has been authorized for periodic location determination and so on. The authorization indication may be, for example, the reference ID assigned by GMLC 150. The presence (in FIG. 4) or the absence (in FIG. 3) of the authorization in the LCS MO-LR Location Services Invoke message informs MSC / SGSN 140 whether to execute the flow 400 messages or a stream of 300 messages, respectively. The presence of periodic location information or other equivalent information in the LCS MO-LR Location Services Invoke informs the MSC / SGSN 140 that RAN-based periodic location reporting to the LCS client 170 is preferred rather than a one-time location report. In the case of a one-time location report, the UE 120 will be responsible for repeatedly issuing the LCS MO-LR Location Services Invoke message in step 4 (for example, repeating steps 1-4) for each scheduled or triggered location reporting that will be sent to the LCS client 170 When requesting RAN-based periodic reporting of location reports, the UE does not need to re-issue another LCS MO-LR Location Services Invoke until the planning and / or start of the transmission of location reports via RAN is completed, as described below.

The MSC / SGSN 140 verifies that the UE 120 is authorized for the requested location service, and then sends a Location Request message to the RAN 130, which initiates RAN-based periodic location reporting (step 5). This message may also contain periodic location information, QoS of the LCS service, and so on. RAN 130 selects the appropriate location method based on the location request, the required accuracy, and the capabilities of the UE.

Then, RAN 130 initiates an appropriate message flow to receive and return a first location estimate for UE 120 (step 6a). This message flow may depend on various factors, such as the capabilities of the UE (for example, “based on the UE” or “using the UE”), the selected location method (for example, A-GPS, A-FLT, E-OTD, OTDOA and so on) whether the UE 120, RAN 130, or SAS 132 will calculate a location estimate and so on. Several embodiments of the message flow for step 6a are described below. RAN 130 obtains a location estimate for UE 120 based on the message flow in step 6a and sends a Location Report message to the MSC / SGSN 140 that contains this location estimate and other relevant information (e.g., reference ID) (step 7a). The MSC / SGSN 140 then sends a MAP Subscriber Location Report message containing the location estimate and related information to the GMLC 150 (step 8a), which sends the location estimate and related information to the LCS client 170 (step 9a). The LCS client 170 responds by sending acknowledgment of location information to the GMLC 150 (step 10a), which sends a MAP / SCSN 140 MAP Subscriber Location Report Acknowledgment message that indicates whether the location estimate was successfully sent to the LCS client 170 (step 11a).

For each subsequent location reporting event i for i = b ... n, as determined by the periodic location information, a message flow is performed to obtain a location estimate for UE 120 (step 6i), and a location estimate is sent to the MSC / SGSN 140 (step 7i). The MSC / SGSN 140 then transmits the location estimate to the LCS client 170 (steps 8i-11i). After the location report transmission events are completed, the MSC / SGSN 140 sends an LCS MO-LR Return Result message to the UE 120 to confirm that the location estimates have been sent to the LCS client 170 and indicate the completion of the periodic location report transmission (step 12). The MSC / SGSN 140 may cause disconnection of the Connection Management (CM), mobility management (MM), or GPRS mobility management (GMM) and radio resource management (RR / RRC) connections from the UE 120 if the UE was previously inactive (step 13) . Step 13 may be omitted if UE 120 is required to remain in dedicated mode to interact with RAN 130, for example, to support other ongoing services.

RAN-based periodic reporting in the case of UMTS (eg, W-CDMA) can be performed using the central RNC mode and the central SAS mode. For Central RNC mode, the Serving Radio Network (SRNC) controller within the serving RAN coordinates and controls periodic reporting for the UE. For Central SAS mode, the SRNC transfers control to the SAS, which coordinates and controls periodic location reporting. For both “central RNC” and “central SAS” modes, the SRNC stores state information to facilitate interaction with the UE, SAS, and MSC / SGSN for periodic location reporting. The UE does not need to know if the “central RNC” or “central SAS” mode is used for periodic location reporting. The “central RNC” and “central SAS” modes can be used for “using UE”, “based on UE”, and “network based” modes.

FIG. 5 shows an embodiment of a message flow 500 for RAN-based periodic reporting in a “central RNC” mode. Message flow 500 is one embodiment of message flow 400 of FIG. 4 and can be used for step 10 of message flows 200, 210, and 300 of FIGS. 2A, 2B, and 3, respectively.

The message flow (which may include steps 1-4 of the message flow 400 of FIG. 4) is initially performed to trigger periodic location reporting to the LCS client 170 (step 1). The MSC / SGSN 140 then sends to the SRNC located within the RAN 130 (or simply to the RAN / SRNC 130) a Radio Access Network Application Part (RANAP) Location Reporting Control message that initiates a periodic transmitting location reports (step 2). This message may also contain periodic location information, QoS of the LCS service, and so on. In an embodiment, the RANAP Location Reporting Control message includes a Periodical Reporting Criteria information element (IE) with the following fields:

1) the number of reports - 1, 2, 4, 8, 16, 32, 64, unlimited, and

2) the interval for issuing the report is 250, 500, 1000, 2000, 3000, 4000, 6000, 8000, 12000, 16000, 20000, 24000, 28000, 32000, 64000 milliseconds (ms).

For this embodiment, each field is associated with a set of possible values given above. In general, the Periodical Reporting Criteria information item can include any field, and each field can include any set of possible values.

The fields of the Periodical Reporting Criteria information element can be set to be the same as the fields for the RRC Periodical Reporting Criteria information element in the RRC Measurement Control message that will be sent via RAN / SRNC 130 to UE 120 in step 5 of the message flow 500. In addition, the same set of values can be used for the corresponding fields in the Periodical Reporting Criteria information element and the RRC Periodical Reporting Criteria information element. This will then allow the RAN / SRNC 130 to simply retrieve the values in the Periodical Reporting Criteria information element received from the MSC / SGSN 140 and map these values directly to the RRC Periodical Reporting Criteria information element sent to the UE 120. The MSC / SGSN 140 will convert the periodic information locations (for example, start time, stop time and interval between reports) to the most appropriate values for the Amount of Reports and Reporting Interval fields in the Periodical Reporting Criteria information item. The MSC / SGSN 140 can use the value "unlimited" as the default for the Amount of Reports field and can send a "stop reporting" command to the RAN / SRNC 130 when location reports are no longer required. RAN / The SRNC 130 will then send a stop command to UE 120. Usually, if the corresponding fields in the various messages are not the same, then the MSC / SGSN 140 converts the periodic location information received from UE 120 (or received from any other entity in PLMN, such as, for example , MSC / SGSN 140 or LCS client 170), at most appropriate values for the RANAP Location Reporting Control message in step 2 (if necessary), and the RAN / SRNC 130 converts these values to the most suitable values for the RRC Measurement Control message in step 5 (if necessary).

In another embodiment, the Periodical Reporting Criteria information item in a RANAP Location Reporting Control message may include any value for the reporting interval (for example, any integer multiple of seconds) or any value for the number of reports. RAN / SRNC 130 or SAS 132 can use this information to decide whether to execute periodic RRC reporting or to periodically repeat the RRC Measurement Control / Measurement Report message sequence, as used for a single request. For example, RRC periodic reporting can be triggered when the values for the Periodical Reporting Criteria information element in the received RANAP Location Reporting Control RANAP message are compatible with the corresponding values in the RRC Periodical Reporting Criteria information element.

The RAN / SRNC 130 selects the appropriate location method based on the location request, the required accuracy, and the capabilities of the UE (also steps 2). If SAS 132 is available and the selected location method is A-GPS, then the RAN / SRNC 130 may send to the SAS 132 a Positioning Calculation Application Part (PCAP) Information Exchange Initiation Request message, to request GPS help data (step 3). SAS 132 then returns to the RAN / SRNC 130 a PCAP Information Exchange Initiation Response message that contains the required GPS assistance data (step 4). Steps 3 and 4 may be omitted for other location methods, either if GPS assistance data is not necessary or if the RAN / SRNC already has GPS assistance data (for example, from a previous request to SAS 132). The RAN / SRNC 130 then sends an RRC Measurement Control message to the UE 120 that contains the periodic location information (eg, the RRC Periodical Reporting Criteria information element) and GPS assistance data (step 5). Steps 3, 4, and 5 are part of positioning messages 1 for the first location report transmission event.

For each location reporting event i, for i = a ... n, as determined by the periodic location information, the UE 120 sends an RRC Measurement Report message that contains the location information to the RAN / SRNC 130 (step 6i). This location information may include measurements made by the UE 120 with respect to base stations and / or satellites observed by the UE (for the “using UE” mode), an estimate of the location of the UE 120 (for the “based on UE” mode), or an error indication, if measurements or location estimates are not available. Measurements can be, for example, pseudorange for A-GPS, SFN-SFN (system frame number - system frame number), observed time differences for OTDOA, or some other type of measurement. If the reporting interval is short (e.g. 2 seconds) and the selected location method is A-GPS, then the first few RRC Measurement Report messages may contain error messages until the GPS receiver in UE 120 detects satellites and is in tracking mode. After this, the RRC Measurement Report messages should provide good measurements and / or location estimates in the reporting interval.

If the RAN / SRNC 130 receives measurements from the UE 120 (for “using the UE” mode) and the SAS 132 is available, then the RAN / SRNC 130 sends a PCAP Position Calculation Request message to the SAS 132 that contains the UE measurements

and possibly other information, for example, to further determine the location “network-based” (step 7i).

The PCAP Position Calculation Request message sent in steps 7i may also contain periodic location information, such as the reporting interval and the number of unacknowledged requests for the complete periodic location procedure. The periodic location information allows the SAS 132 to maintain status information between separate PCAP requests for position calculation in order to better fulfill future such requests. SAS 132 calculates a location estimate for UE 120 based on measurements and any other information and sends to the RAN / SRNC 130 a PCAP Position Calculation Response message that contains a position estimate (step 8i). If the RAN / SRNC 130 receives the location estimate from the UE 120 (for the UE-based mode), then steps 7i and 8i may be skipped. If the RAN / SRNC 130 decides to use only “network-based” positioning (for example, an advanced cell identification method, U-TDOA), then steps 3, 4, 5 and 6i (for i = a ... n) are skipped, and The RAN / SRNC 130 sends to the SAS 132 in step 7i a PCAP Position Calculation Request message containing information for the selected network-based position determination methods. SAS 132 then returns in step 8i a PCAP Position Calculation Response message containing a location estimate resulting from the use of network based SAS 132 methods. In any case, the RAN / SRNC 130 sends a RANAP Location Report message containing the location estimate to the MSC / SGSN 140 (step 9i), which transmits the location estimate to the LCS client 170 (step 10i). Step 10i may include steps 8i-11i of the message flow 400 of FIG. 4.

As shown in FIG. 5, each location report transmission event includes positioning messages, transmitting a location estimate from the RAN / SRNC 130 to the MSC / SGSN 140 (step 9i), and transmitting the location estimate from the MSC / SGSN 140 to LCS client 170 (step 10i). Messages for positioning 1 for the first location report transmission event include steps 3-8a, and messages for determining location i for each subsequent location report transmission event include steps 6i-8i. Location messages 1 for the first location report transmission event may include additional steps 3, 4, and 5 to request and subsequently receive GPS assistance from SAS 132 (steps 3 and 4) and transmit this assistance data to UE 120 to cause periodic sending from the UE 120 location information (step 5). UE 120 may also request new assistance data in step 6i, instead of or in addition to sending location measurements to RAN / SRNC 130. This may be in circumstances, for example, if the number of messages originally requested (for example, in step 5) is large , and the requested location method is A-GPS. If the UE 120 requests new help data, then steps 3, 4 and 5 are repeated, and new or updated help data is sent to the UE 120 in the Measurement Control message or in the Assistance Data Delivery message together with other relevant information. The request for new assistance data in step 6i and their provision by repeating steps 3, 4 and 5 can occur repeatedly in the stream of 500 messages. After the location report transmission events are completed, a message flow (which may include steps 12 and 13 of the message flow 400 of FIG. 4) is performed to end the periodic transmission of location reports to the LCS client 170 (step 11).

The RAN / SRNC 130 may decide in step 5 not to request periodic reporting of the UEs, for example, omit the RRC Periodical Reporting Criteria information element from the RRC Measurement Control message, or include this information element with a value of one for the number of messages. As mentioned above, this may be the case if the periodic location information received in the RANAP Location Reporting Control message is not compatible with the corresponding available range of values in the RRC Measurement Control message. The RAN / SRNC 130 may then repeat the sending of step 5 at the desired periodic reporting interval. The positioning messages i for each location reporting event will then, in addition to steps 6i-8i, include step 5.

FIG. 6 shows an embodiment of a message flow 600 for RAN-based periodic SAS reporting. Message flow 600 is another embodiment of message flow 400 of FIG. 4 and can also be used for step 10 of message flows 200, 210, and 300 in FIGS. 2A, 2B, and 3, respectively.

Steps 1 and 2 of message flow 600 are similar to (for example, the same as) steps 1 and 2 of message flow 500 of FIG. The RAN / SRNC 130 receives, from the MSC / SGSN 140, a RANAP Location Reporting Control message that contains periodic location information, QoS of the LCS service, and so on (step 2). The RAN / SRNC 130 then sends to the SAS 132 a PCAP Position Initiation Request message that contains information received from the MSC / SGSN 140 and possibly other information, such as the cell ID and positioning capabilities of the UE (e.g., information regarding the location method or methods that the target UE 120 supports) (step 3). This message also transfers periodic reporting control to SAS 132. SAS 132 selects the appropriate location method based on the required accuracy and capabilities of the UE and determines the appropriate assistance data (if any) to send to UE 120. SAS 132 then sends a message to RAN / SRNC 130 PCAP Position Activation Request, which contains periodic location information (for example, the Periodical Reporting Criteria information element) and help data (step 4). SAS 132 in step 4 can convert the periodic location information received from the RAN / SRNC 130 in step 3 to the most appropriate values for the PCAP Position Activation Request message, if necessary. The RAN / SRNC 130 then sends a Measurement Control message to the UE 120 RRC, which contains periodic location information and assistance data (step 5). Steps 3, 4, and 5 are part of the location 1 messages for the first location report transmission event.

For each location report reporting event i, for i = a ... n, as determined by the periodic location information, the UE 120 sends an RRC Measurement Report that contains location information (to the RAN / SRNC 130) stage 6i). This location information may include measurements made by UE 120 for base stations and / or satellites (for “using UE” mode), a location estimate for UE 120 (for “using UE” mode), or an error indication if not Measurements or location estimates are available. The RAN / SRNC 130 sends to the SAS 132 a PCAP Position Periodic Request message that contains location information received from the UE 120 (step 7i). For the “using the UE” mode, the SAS 132 receives measurements from the UE 120 and calculates a location estimate for the UE based on the measurements and possibly other information (for example, information obtained by a “network-based” location). For the UE-based mode, the SAS 132 receives a location estimate from the UE 120 and can check the location estimate and / or modify it (for example, based on information obtained by network-based location determination). For both UE-based and UE-based modes, the SAS 132 sends a PCAP Position Periodic Response message to the RAN / SRNC 130 that contains the location estimate for the UE 120 (step 8i). The RAN / SRNC 130 then sends a RANAP Location Report message containing the location estimate to the MSC / SGSN 140 (step 9i), which transmits the location estimate to the LCS client 170 (step 10i). Step 10i may include steps 8i-11i of the message flow 400 of FIG. 4.

Following the receipt of the final RRC Measurement Report from UE 120 (step 6 n), the RAN / SRNC 130 may send to the SAS 132 in step 7 n a PCAP Position Activation Response message carrying the same type of information (e.g. measurements or location estimates), as well as the PCAP Position Periodic Request message in the previous steps 7i (for i = a ... n-1). SAS 132 may then return a PCAP Position Initiation Response message in step 8n carrying the same type of information (e.g., computed location estimate) as the PCAP Position Periodic Response message in previous steps 8i (for i = a. .. n-1). This difference may facilitate compliance with existing 3GPP conventions (defined in 3GPP TS 25.453) that any PCAP request message sent from either the RNC to the SAS or the SAS to the RNC should be answered with at least one different PCAP response message. In this case, the PCAP Position Initiation Response message sent in step 8n is a response to the PCAP Position Initiation Request message (PCAP Position Initiation Request) sent in step 3; a PCAP Position Activation Response message sent in step 7n — a response to a PCAP Position Activation Request message sent in step 4; and the PCAP Position Periodic Response sent in step 8i (for i = a ... n-1) is a response to the PCAP Position Periodic Request message sent in step 7i. These pairings correspond specifically to the elementary class 1 procedure in 3GPP TS 25.453. In addition, the first two pairs (steps 3 and 8n, and steps 4 and 7n) are applicable to single location requests (for example, if each pairing occurs only once), providing higher compatibility between single and periodic location requests and, possibly , a simpler implementation in RAN / SRNC 130 and SAS 132 to support both types of location requests. To enable greater compatibility with the “central RNC” action, PCAP request messages for periodic positioning and response to it, in steps 7i and 8i, can be replaced by the PCAP Position Calculation Request / Response messages used in mode "with a central RNC" and shown in Fig.5. In this case, the PCAP Position Calculation Request / Response messages can be slightly modified to also allow delivery of the location estimate received from the UE to the SAS, but new procedures are not required.

In an alternative embodiment, the message flow 600 after receiving the final RRC Measurement Report from UE 120 in step 6n, RAN / SRNC

may send a PCAP Position Periodic Request message to SAS 132 in step 7n, and SAS 132 may return a PCAP Position Periodic Response message in step 8n in the same manner as in previous steps 7i and 8i. In this case, after step 8n and not shown in FIG. 6, the RAN / SRNC 130 may send to the SAS 132 a PCAP Position Activation Response message that does not contain any measurements or a location estimate and the SAS 132 may return a PCAP Position Initiation Response message not contains a location estimate to respond to earlier messages of steps 3 and 4 and complete transactions associated with them in SAS 132 and RAN / SRNC 130.

In another alternative embodiment of the message flow 600, a Class 1 PCAP elementary procedure containing PCAP Position Periodic Request and PCAP Position Periodic Response messages in steps 7i and 8i may be replaced with the Class 2 PCAP elementary procedures defined in 3GPP TS 25.453. Class 2 elementary procedures are non-response procedures. In this embodiment, the PCAP Position Activation Response message in step 7n of the message flow 600 can be sent either immediately after the PCAP Position Activation Request message in step 4, or after the first RRC Measurement Report message has been received, which occurs after step 6a. In the first case, the PCAP Position Activation Response message will contain a confirmation of the requested action. In the latter case, the PCAP Position Activation Response message will additionally contain report information about the first measurement. The PCAP Position Activation Request message may contain some recommended location commands that the RAN / SRNC 130 can forward to the UE 120 in the RRC Measurement Control message in step 5. If the RAN / SRNC 130 cannot match the request for some location commands, then RAN / The SRNC 130 may inform the SAS 132 in the PCAP Position Activation Response message of the location commands used instead in the RRC Measurement Control message sent to the UE 120 in step 5. An example of such location commands may be information regarding go, in what state of the RRC the requested measurements are valid. Subsequent measurement report information received in RAN / SRNC 130 from UE 120 will then be transmitted to SAS 132 in Class 2 PCAP Position Periodic Report messages, which will be sent in steps 7i instead of the PCAP Position Periodic Request messages shown in a stream of 600 messages. SAS 132, in turn, will provide a RAN / SRNC 132 report on location estimates in PCAP Class 2 Position Periodic Result messages that will be sent in steps 8i instead of the PCAP Position Periodic Response messages shown in stream 600 messages. If SAS 132 decides to cancel the ongoing periodic RRC procedure, then SAS 132 may send to the RAN / SRNC 132 a PCAP Position Periodic Result message containing a request to complete the periodic procedure. Alternatively, SAS 132 may send a Class 2 PCAP Position Periodic Termination message to RAN / SRNC 130 to cancel the ongoing periodic procedure. This message flow may be more compatible with periodic location procedures that do not require RRC signaling, such as cell-ID or network-based U-TDOA positioning.

The class 2 embodiment described above allows SAS 132 to decide whether to initiate periodic RRC transmission of the measurement report or periodically repeat single requests (for example, if the periodic transmission information of the report received in SAS 132 in the PCAP Position Initiation Request message in step 3 is not compatible with the range of available values in the RRC Periodical Reporting Criteria information item). SAS 132 can then retry sending the PCAP Position Activation Request message to RAN / SRNC 132 in the requested periodic report interval. The RAN / SRNC 130 will repeat the pair of RRC Measurement Control / Report messages and transmit the measurement information to the SAS 132 in the PCAP Position Activation Response message. SAS 132 may then send individual position estimates to the RAN / SRNC 130 in a PCAP Position Periodic Result message.

An embodiment of Class 2 may be used, for example, to support periodic cell-ID positioning. In this case, the SAS 132 may periodically send a PCAP Position Activation Request RAN / SRNC 130 message (not shown in FIG. 6). RAN / SRNC 130 may then return a PCAP Position Activation Response message containing cell-related measurements for UE 120 obtained by RAN / SRNC 130. SAS 132 may then send a PCAP Position Periodic Result message containing location estimate to RAN / SRNC 130, obtained from these measurements.

An embodiment for Class 2 may also be used to support periodic U-TDOA based positioning. In this case, the RAN / SRNC 130 may return to the SAS 132 a PCAP Position Activation Response message containing channel related information for the UE 120 after receiving the PCAP Position Activation Request message in step 3 of FIG. 6. SAS 132 may then configure LMU devices to obtain periodic U-TDOA measurements for UE 120, and may return periodic location estimates to the RAN / SRNC 130 as a sequence of PCAP Position Periodic Result messages. In this embodiment, the U-TDOA may not be necessary for the RAN / SRNC 130 to send subsequent messages to the SAS 132, thereby saving transmission and processing resources and reducing delay.

Class 2 execution can be extended to support periodic U-TDOA-based positioning in parallel with periodic A-GPS and / or periodic OTDOA positioning. In this case, periodic U-TDOA positioning may be invoked as described above. Periodic A-GPS or OTDOA positioning can then be called using the implementation of the elementary PCAP class 2 procedure also described above. SAS 132 may obtain periodic location estimates for UE 120 using periodic U-TDOA measurements obtained by LMUs and periodic GPS measurements supplied to SAS 132 in a PCAP Position Periodic Report message. SAS 132 may then return each location estimate to RAN / SRNC 130 in a PCAP Position Periodic Result message.

As shown in FIG. 6, each location report transmission event includes positioning messages, transmitting a location estimate from the RAN / SRNC 130 to the MSC / SGSN 140 (step 9i), and transmitting the location estimate from the MSC / SGSN 140 to the LCS client 170 (step 10i). Messages for positioning 1 for the first location report transmission event include steps 3-8a, and messages for positioning i for each subsequent location report transmission event include steps 6i-8i. After the location report transmission events are completed, a message flow (which may include steps 12 and 13 of the message flow 400 of FIG. 4) is performed to end the periodic transmission of location reports to the LCS client 170 (step 11).

UE 120 may at some point request new or updated assistance data in step 6i, instead of sending or in addition to sending location measurements to RAN / SRNC 130. This may occur in circumstances, for example, if the number of messages originally requested (for example, step 5) was a large, and the requested location method was A-GPS. In an embodiment, a request for additional assistance data may be transmitted from the RAN / SRNC 130 to SAS 132 either as part of a PCAP Position Periodic Request message or a PCAP Position Periodic Report message (not shown in FIG. 6) sent in step 7i and the requested assistance data can be returned via SAS 132

on the RAN / SRNC 130 either in the PCAP Position Periodic Response message or in the PCAP Position Periodic Result message (not shown in FIG. 6) sent in step 8i. The RAN / SRNC 130 may then transmit assistance data to the UE 120 either in an RRC Measurement Control message or an RRC Assistance Data Delivery message (not shown in FIG. 6). This embodiment avoids the need for SAS 132 and RAN / SRNC 130 to re-launch A-GPS positioning support. In another embodiment, upon receiving a request for additional assistance data in step 6i, the RAN / SRNC 130 may transmit this request to SAS 132 in a PCAP Position Activation Response message (not shown in FIG. 6). SAS 132 then prepares the new requested assistance data and sends it, possibly with new periodic location information, in a new PCAP Position Activation Request message to RAN / SRNC 130 (not shown in FIG. 6), which starts a new transaction. The RAN / SRNC 130 then sends a new RRC Measurement Control message to the UE 120 indicating that the pre-initiated measurement (in step 5) is now modified with new help data (and possibly new reporting commands). This embodiment has the effect of restarting A-GPS positioning support in SAS 132 and RAN / SRNC 130 and possibly in changing periodic reporting commands to UE 120.

In another embodiment, the RAN / SRNC 130 may invoke the PCAP Information Exchange Procedure, as defined in 3GPP TS 25.453, to request assistance data from SAS 132, which is currently only used for central RNC. " In this embodiment, the RAN / SRNC 130 may request assistance data from the SAS 132 by reproducing steps 3, 4, and 5 of FIG. 5 (not shown in FIG. 6). When using this procedure also in the “central SAS” mode, SAS 132 is aware that this procedure belongs to the positioning event for UE 120, for example, by using the session identifier parameter (ID), which associates all PCAP messages with the same positioning event , or by using the existing signaling connection allocated for this particular positioning event for UE 120.

In any case, after receiving assistance data, the UE 120 continues to submit measurement reports in the RRC Measurement Report message to RAN / SRNC 130, which in turn continues with a pair of PCAP Position Periodic Request and PCAP Position Periodic Response messages or, alternatively, PCAP Position Periodic Report messages and PCAP Position Periodic Result, as described above. The request for new assistance data by the UE 120 in step 6i and their provision by one of the above embodiments may also occur several times in the message flow 600.

During the message flow 600 of FIG. 6, some exceptional situations may occur randomly that require some additional action. If the UE 120 changes the serving cell, but remains within the coverage area of the RAN / SRNC 130, then the RAN / SRNC 130 can notify the SAS 132 of the new cell by sending a PCAP Position Parameter Modification message to the SAS 132 containing the identification new cell information. This message may be the same as currently allowed (for example, in 3GPP TS 25.305) to change the cell inside the intra-RNC using a single, single positioning in “central SAS” mode. The RAN / SRNC 130 may also send a PCAP Position Parameter Modification message to the SAS 132 if there is an RRC state change during the ongoing RRC measurement procedure. In the case of some other exceptional situations, such as a hard handover to another RNC, the UE 120 and / or RAN / SRNC 130 may interrupt the periodic location procedure, and the MSC / SGSN 140 may repeatedly invoke the procedure (for example, by signaling to a new RAN / SRNC).

RAN-based periodic reporting reports of location reports shown in FIGS. 4, 5 and 6 with very small changes described below can be used for periodic reporting of location reports for (query) MT-LR (FIG. 2A) and for periodically transmitting location reports for the NI-LR (requests) (FIG. 2B), for example, if the UE 120 or the MSC / SGSN 140 cannot or do not agree to support the periodic location procedure through the MO-LR requests, which are FIG. 4, 5 and 6 now show silt suggest. RAN-based periodic location reporting may be used if the subscriber of the UE does not reject the location request in the case of MT-LR, where notification and confidentiality verification are used in step 5 of FIG. The changes for the message flows in FIGS. 4, 5 and 6 are as follows.

4, steps 1-4 are deleted. Instead, the MSC / SGSN 140 performs paging and authentication (for example, as described for step 5 in FIG. 2A) if the UE 120 has returned to inactive. However, there should be no notification and confidentiality check (shown in step 5 in FIG. 2A), as this has been done previously as part of the message stream 200 of FIG. 2A or (if necessary) the message stream 210 of FIG. 2B. If the UE 120 is not in an idle mode, then paging and authentication are not required. Step 12 is also deleted, but step 13 remains valid.

In FIGS. 5 and 6, step 1 should now only include paging and authentication if the UE 120 is in an inactive mode, as described above for the changes to FIG. 4. Step 11 now corresponds only to step 13 (and not both steps 12 and 13) in FIG. 4.

For the message flow 400 of FIG. 4, a relatively long MO-LR transaction (request) may occur from step 4 to step 12. During this time, the UE 120 may not have information about the success or failure of each location transmission (data) and is informed of the results of the periodic location report after completion of reporting. However, an open MO-LR transaction may be useful to maintain a CM and MM / GMM connection with the UE 120 and prevent the UE 120 from returning to sleep mode. It may be desirable to keep the UE 120 informed of the progress of periodic location reporting using LCS services for updates.

7 shows an embodiment of a message flow 700 for RAN-based periodic notification reporting. Message flow 700 may also be used for step 10 of message flows 200, 210, and 300 of FIGS. 2A, 2B, and 3, respectively. Steps 1-4 of the message flow 700 are the same as steps 1-4 of the message flow 400 of FIG. 4. UE 120 sends an LCS MO-LR Location Services Invoke message to the MSC / SGSN 140 to trigger periodic location reporting (step 4). The MSC / SGSN 140 sends an LCS MO-LR Return Result message to UE 120 to acknowledge the call (procedure) (step 5), thus providing immediate feedback to UE 120 that the MO-LR request will be supported. The MSC / SGSN 140 also sends a Location Request message to the RAN 130, which contains information about the periodic location and QoS of the LCS service (step 6).

A message flow is then performed to obtain a first location estimate for UE 120 and transmit the location estimate to LCS client 170 (step 7a). Step 7a may include steps 6a-11a of the message flow 400 of FIG. 4, steps 3-10a of the message flow 500 of FIG. 5, or steps 3-10a of the message flow 600 of FIG. 6. The MSC / SGSN 140 then sends an LCS Location Update Invoke message to the UE 120 to indicate that the first location estimate has been successfully transmitted to the LCS client 170 (step 8a). This message may also be used to notify UE 120 that a second location estimate will be transmitted to the next location report transmission event, for example, after the next periodic transmission interval. UE 120 sends an LCS Location Update Return Result message to the MSC / SGSN 140 to acknowledge receipt of the notification (step 9a). This message may include refusing the next transmission of the location report if the UE 120 desires to cancel the periodic location procedure at this point in time.

For each subsequent location reporting event i for i = b ... n, a message flow is performed to receive and transmit the location estimate for UE 120 to LCS client 170 (step 7i), an LCS Location Update Invoke message is sent to MSC / SGSN 140 to notify the UE 120 of the location transfer results (step 8i), and the LCS Location Update Return Result message is sent to the UE 120 to confirm the notification (step 9i). After all location reporting events have been completed, the MSC / SGSN 140 may prompt the disconnection of CM, MM or GMM and RR / RRC connections with UE 120 (step 10).

In another embodiment, the MOS-LR Return Result request LCS message is not sent in step 5 of FIG. 7, but instead is sent after step 9n in the same manner as the message flow 400 of FIG. 4. In this case, sending LCS Location Update Invoke messages from the MSC / SGSN 140 to the UE 120 in steps 8a ... 8n of FIG. 7 provides feedback to the UE 120 that the MO-LR request will be supported, as well as the result of each location transmission on UE 120.

In an alternative embodiment, the LCS Location Update Invoke message at each step 8i and the LCS Location Update Return Result message at each step 9i are replaced by the LCS Notification Invoke and LCS Notification Return Result messages, respectively which are existing 3GPP messages defined in 3GPP TS 24.080. Using an existing 3GPP message can reduce the impact of an implementation on the MSC / SGSN 140 and UE 120.

In the following embodiment, either a pair of LCS Location Update Invoke messages and LCS Location Update Return Result messages is exchanged, or a pair of LCS Notification Invoke messages and LCS Notification Return Result messages before each location report transmission event (not shown in FIG. 7) instead exchange after the event (as shown in Fig.7). For this embodiment, the LCS Location Update Invoke message or the LCS Notification Invoke message informs the UE 120 that a location estimate will be received and transmitted to the LCS client 170 in the next location report transmission event. The UE user may then be given the opportunity to reject the transmission or cancel the periodic transmission of location reports. The message may also inform UE 120 of the results of a previous transmission (for example, whether the transmission was successful or unsuccessful if a location estimate was not obtained). In another embodiment, either a pair of LCS Location Update Invoke messages and LCS Location Update Return Result messages is sent, or a pair of LCS Notification Invoke messages and LCS Notification Return Result messages before each location reporting event, and a final pair of these messages is sent after the last location reporting events. A pair of messages before each location report transmission event transmits to UE 120 the result of a previous location transmission (if any), allows UE 120 to reject the transmission or cancel the procedure, and informs UE 120 of the next transmission. A pair of messages after the last location report transmission event informs UE 120 about the completion of periodic transmission of location reports and results of location transfers.

It may be desirable for the UE 120 to perform periodic auto-location to periodically determine its own location for its own use or on behalf of some external application (for example, accessible via the Internet) with which the UE 120 is in communication. If the UE 120 supports the "based on the UE" mode, then the UE 120 can calculate the location estimates about itself whenever necessary, possibly without any signaling using the RAN 130. However, if the UE 120 only supports the "using the UE "Or does not have the ability to determine the location, then overhead will be incurred to periodically establish and terminate each location transaction in RAN 130 for each request MO-LR auto-location, if each such request prompts only a single One-time location request. These overheads can be reduced or avoided by using the periodic LCS capabilities of RAN 130 to periodically auto-locate.

FIG. 8 shows an embodiment of a message flow 800 for a RAN-based periodic auto-location request MO-LR. Periodic auto-location can be considered as a special case of periodic location reporting, where the LCS client is UE 120 instead of the external LCS client 170.

Steps 1-3 of message flow 800 are the same as steps 1-3 of message flow 400 of FIG. 4. Then, the UE 120 sends an LCS MO-LR Location Services Invoke message to the MSC / SGSN 140 to request periodic auto-location (step 4). This message contains relevant information, such as, for example, periodic location information (e.g., start time, reporting interval, and one parameter from stop time, reporting duration, or a predetermined number of reports), LCS QoS, and so on. The message also indicates that periodic location estimates should be sent to UE 120. MSC / SGSN 140 verifies that UE 120 is authorized for the requested location service based on the subscription profile for the UE (also step 4). If the location request is authorized, then the MSC / SGSN 140 sends an LCS MO-LR Return Result message to the UE 120 to indicate acceptance of the periodic auto-location request (step 5). The MSC / SGSN 140 also sends a Location Request message to the RAN 130, which contains a periodic auto-location request, periodic location information, UE capabilities, and LCS service QoS (step 6).

A message flow is then performed to obtain a first location estimate for UE 120 (step 7a). Step 7a may include steps 3-8a of the message flow 500 of FIG. 5 or steps 3-8a of the message flow 600 of FIG. 6. RAN 130 receives the location estimate for UE 120 from the message flow in step 7a and sends a Location Report message to the MSC / SGSN 140 that contains this location estimate and other relevant information (step 8a). The MSC / SGSN 140 then sends to the UE 120 an LCS Location Update message containing a first location estimate and related information (step 9a). UE 120 returns an LCS Location Update Acknowledgment message that acknowledges the receipt of the first location estimate (step 10a). This message may also include an instruction to cancel periodic auto-location, if desired for UE 120. For each subsequent i-location event i, for i = b ... n, a message flow is performed to obtain a location estimate for UE 120 (step 7i) and send a location estimate to the MSC / SGSN 140 (step 8i). MSC / SGSN 140 then returns a location estimate to UE 120 (steps 9i and 10i). After location reporting events have been completed, the MSC / SGSN 140 may prompt the disconnection of CM, MM or GMM, and RR / RRC connections with UE 120.

In another embodiment, the LCS MO-LR Return Result message is not sent in step 5 of FIG. 8, but instead is sent after step 10n in the same manner as the message flow 400 in FIG. 4. In a further embodiment, the LCS Location Update message in each step 9i and the LCS LCS Location Update Acknowledgment in each step 10i are replaced by the LCS Notification Invoke message and the LCS Location Update Acknowledgment message, respectively, which are existing 3GPP messages. Again, using existing 3GPP messages can reduce the impact of the implementation on the MSC / SGSN 140 and UE 120.

RAN-based periodic location reporting can also be used for mobile stations (MSs) that interact with GERAN. The periodic packet switched mode location reporting procedure may be used to periodically request a location received by the 2G-SGSN 140a of FIG. 1B. The procedure for periodically transmitting circuit-switched mode location reports may be used to periodically request a location received by 2G-MSC 140b. For periodic GERAN transmission of a position report in a circuit-switched mode, the MS can operate in a dedicated mode and a signaling channel (for example, an individual control channel, SDCCH) can be assigned for the total duration of the transmission of a periodic position report, since the base station subsystem (BSS) GSM does not have the ability to dynamically disconnect and subsequently reassign a dedicated signaling channel during periodic location intervals. For periodic GERAN transmission of the location report in the packet-switched mode of the MS, a signaling channel can be dynamically assigned when a message is to be sent between the MS and the BSS. In the following description, UE 120 (UMTS terminology) is referred to as MS 120 (GSM terminology). MS 120 interacts with BSS in GERAN 130a.

FIG. 9 shows an embodiment of a message flow 900 for RAN-based periodic reporting for GERAN in packet-switched mode. LCS client 170 or MS 120 may initiate a request to periodically send location estimates for MS 120 to LCS client 170 (step 1). Periodic positioning may be triggered by MT-LR, NI-LR, or MO-LR requests, for example, as described above for FIGS. 2A, 2B, or 3, respectively. A periodic location request may be transmitted to SGSN 140a via one or more GMLCs for MT-LR initiated by LCS client 170, or via BSS for MO-LRs initiated by MS 120. The request may include periodic location information establishing a plan or conditions (e.g., events) for sending location estimates. The request can be agreed upon by participating entities, for example several GMLC 150, SGSN 140a, MS 120, and LCS client 170. Periodic location delivery can then be started either via MO-LR from MS 120, or via SGSN 140a, which can perform a paging radio call and authentication if the MS 120 has returned to inactive mode.

SGSN 140a sends a BSSGP Perform Location Request message to the BSS currently serving the MS 120 (step 2). This message contains a periodic location request and further includes periodic location information, QoS, and / or other relevant information. The BSS receives the message and identifies that the request is more preferable for periodic positioning than for a single, single positioning. The BSS then sends a periodic location request and periodic location information in a BSSMAP-LE Perform Location Request message to the SMLC 132 (step 3).

SMLC 132 receives a message from the BSS, evaluates the periodic location request, and selects a location method. If A-GPS and / or E-OTD is selected, the SMLC 132 sends a BSSMAP-LE Connection Oriented Information message to the BSS that contains a BSSLAP MS Position Command message that further comprises an RRLP Measure Position Request message (step four). The BSSLAP MS Position Command message may indicate that periodic location determination is requested, and the BSS may record this information. The RRLP Measure Position Request message may contain periodic location information, a subset of this information, or a converted set or subset of this information. The RRLP Measure Position Request Request message may also contain assistance data to assist the MS 120 to perform A-GPS and / or E-OTD measurements and, if MS-based positioning is selected, help the MS 120 calculate the position estimate. If help data does not fit into any RRLP Measure Position Request message, the SMLC 132 can send some or all of the help data and other information, including periodic location information, to MS 132 in one or more RRLP Assistance Data messages (not shown in FIG. 9) before sending the RRLP Measure Position Request message. MS 120 will then acknowledge each RRLP Assistance Data message with an RRLP Assistance Data Acknowledgment message.

The BSS sends to the SGSN 140a a BSSGP Position Command message containing the RRLP Measure Position Request message received from the SMLC 132 (step 5). The SGSN 140a then sends to the MS 120 a Frame Unconfirmed Information (UI) message (Logical Logical Connection Control (LLC) frame) containing a TOM message that carries an RRLP Measure Position Request message received from SMLC 132 (step 6). MS 120 receives a message from SGSN 140a and recognizes a periodic location request based on the periodic location information included in the RRLP Measure Position Request message (or in the previous RRLP Assistance Data message). If the A-GPS method is selected, then the MS 120 can receive (track) and measure signals from GPS satellites using help data (if any) after receiving the RRLP Measure Position Request message or the previous Assistance Data message. If the E-OTD method is selected, then the MS 120 may begin to receive and measure signals from nearby base stations. MS 120 can also receive and measure signals from both GPS satellites and base stations if both E-OTD and A-GPS are selected.

When the first planned location estimate is the result or when there is a first set of conditions (for example, an event) for which the location estimate is necessary, the MS 120 performs A-GPS and / or E-OTD measurements (by the method). If MS-based positioning has been selected, then MS 120 further obtains a location estimate based on measurements. The MS 120 then sends the measurements or location estimate in the RRLP Measure Position Response message to the SGSN 140a (step 7a). The RRLP Measure Position Response message is transmitted in the TOM message, which in turn is transmitted in the LLC UI Frame message. The TOM message header includes a flag indicating that the RRLP Measure Position Response message is not the last. The RRLP Measure Position Response message may also indicate that several periodic position estimates will subsequently be provided. MS 120 may send multiple RRLP Measure Position Response messages if measurements or location estimates do not fit into a single message (not shown in FIG. 9).

The SGSN 140a receives the LLC UI Frame message from the MS 120 and transmits the RRLP Measure Position Response message in the BSSGP Position Response message to the BSS (step 8a). The BSSGP Position Response message header includes a flag indicating that this is not the last RRLP Measure Position Response message. The BSS receives the BSSGP Position Response message from the SGSN 140a and transmits the Measure Position Response RRLP message in the BSSLAP MS Position Response message contained in the BSSMAP-LE Connection Oriented Information message to the SMLC 132 (step 9a). The BSSLAP MS Position Response message header includes a flag indicating that this is not the last RRLP Measure Position Response message. The BSS is aware of the periodic location request (from step 2 and possibly from step 4) and also from the checkbox. The BSS thus awaits additional RRLP Measure Position Response messages from the MS 120 and does not interrupt periodic positioning before all measurements or position estimates (in the interior of the RRLP Measure Position Response messages) are transmitted from the MS 120.

SMLC 132 calculates a location estimate based on measurements provided by the MS 120, or checks any location estimate provided by the MS. The SMLC 132 then sends the calculated or verified location estimate in a BSSMAP-LE Perform Location Report message to the BSS (step 10a). This message informs the BSS that periodic positioning has not yet been completed and that additional location estimates will subsequently be provided by the SMLC 132. The BSS receives the location estimate from the SMLC 132 and sends this location estimate in the BSSGP Perform Location Report to the SGSN 140a (step 11a). This message informs SGSN 140a that the periodic location determination is not yet completed and that further location estimates will subsequently be provided. The SGSN 140a then transmits the location estimate to the LCS client 170, for example, through the GMLC using steps 8a-11a in FIG. 4 or via the BSS.

Steps 7a through 11a are for a single location report transmission event. These steps can be repeated for each additional location estimate that is planned or launched. If the MS 120 is unable to obtain measurements or a location estimate because the available assistance data is no longer valid, then the MS 120 may include requesting more assistance data in an RRLP Measure Position Response message sent in a subsequent step 7. This data request may be sent instead of or to addition to measurements or location estimation. Having accepted this request in step 9, the SMLC 132 will send the requested assistance data to the MS 120 using one or more RRLP Assistance Data messages. In one embodiment, both the SMLC 132 and the MS 120 process the assistance data transfer as an additional RRLP transaction occurring in parallel with the delayed RRLP transaction to periodically determine the location (e.g., started in steps 4, 5, and 6). MS 120 continues to send periodic measurements or location estimates to the SMLC 132, repeating steps 7-11a. In another embodiment, the MS 120 may terminate the transmission of periodic measurements or location estimates to the SMLC 132 when sending a request for more assistance data. For example, MS 120 may indicate the completion of periodic transmission of a location report by including an error indication in the RRLP Measure Position Response message containing a request for more assistance data. In this case, the TOM message header sent in the next step 7 may include a flag indicating that it is the last RRLP Measure Position Response message. When the BSS receives this flag from SGSN 140a in a subsequent step 8, the BSS forwards this last RRLP Measure Position Response message to the SMLC 132 and no longer expects the RRLP Measure Position Response message from the MS 120. The SMLC 132 can restart the transmission of periodic measurements or location estimates from MS 120 by repeating steps 4-11. SMLC 132 may send the requested assistance data to the MS 120 in an RRLP Measure Position Request message and / or one or more RRLP Assistance Data messages.

MS 120 sends the final measurements or location estimate for periodic location determination to SGSN 140a (step 7n). Measurements or location estimates are sent in the RRLP Measure Position Response message, which is transmitted in the TOM message, which is then transmitted in the LLC UI Frame message. These messages are the same as those used in step 7a, except that the TOM message header includes a flag indicating that it is the last RRLP Measure Position Response message. The RRLP Measure Position Response message may contain parameters indicating that it represents the latest periodic measurements or location estimates. Steps 8n-n are similar to steps 8a-11a. However, a flag indicating that the last RRLP Measure Position Response message is being sent can be included in the BSSGP Position Response message sent to the SGSN 140a in step 8n, as well as in the BSSLAP MS Position Response message sent to the BSS in step 9n. SMLC 132 may send a BSSMAP-LE Perform Location Report in step 10n instead of a BSSMAP-LE Perform Location Report in step 10a to inform the BSS that the periodic location procedure has completed. The BSS may send a BSSGP Perform Location Response message in step 11n instead of a BSSGP Perform Location Report in step 11a to inform the SGSN 140a that the periodic location procedure has completed. The BSS no longer expects an RRLP Measure Position Response message from the MS 120 unless the SMLC 132 prompts a new positioning procedure. SMLC 132 may cause several periodic transmissions of location reports by repeating steps 4-9n. SGSN 140a may continue to periodically transmit location reports by repeating steps 2-11n. Otherwise, the SGSN 140a may indicate to the LCS to the client 170 that periodic reporting of location reports has now been completed.

Some exceptions may occur during the message flow 900 of FIG. 9, which require additional action. If the MS 120 changes the serving cell but remains within the service area of the same BSS, the BSS can notify the SMLC 132 of the new cell by sending a BSSMAP-LE Perform Location Information containing the identification information about the location to the SMLC. new cell. For some other exceptional situations, such as switching a cell to a new BSS, updating the intra-SGSN GPRS routing area, or re-distributing the P-TMSI, the MS 120 and / or BSS may interrupt the periodic location procedure and the SGSN 140a may re-execute procedure, for example, by signaling to a new BSS.

10 shows an embodiment of a message flow 1000 for RAN-based periodic reporting for GERAN in circuit-switched mode. Message flow 1000 for circuit-switched mode is similar to message flow 900 for packet-switched mode. The differences are such that the SGSN 140a is replaced with 2G-MSC 140b, the BSSGP messages between the SGSN 140a and the BSS are replaced with the corresponding BSSMAP messages, and the transmission of RRLP messages between the BSS and the MS 120 is more direct.

LCS client 170 or MS 120 may initiate a request to periodically send location estimates for MS 120 to LCS client 170 (step 1). The request may be transmitted to the 2G-MSC 140b through one or more GMLCs or via BSS. The request may include periodic location information and may be agreed upon by participating entities, for example, several GMLC 150, 2G-MSC 140b, MS 120 and LCS client 170. Periodic location delivery may then be started or according to the MO-LR request from MS 120 or via 2G-MSC 140b, which can perform paging and authentication if the MS 120 has returned to inactive mode.

2G-MSC 140b sends a BSSMAP Perform Location Request message to the BSS currently serving MS 120 (step 2). This message contains a periodic location request and further includes periodic location information, QoS, and other relevant information. The BSS sends a periodic location request in a BSSMAP-LE Perform Location Request message to the SMLC 132 (step 3). SMLC 132 receives the message, evaluates the periodic location request, and selects a location method. If A-GPS and / or E-OTD is selected, the SMLC 132 sends to the BSS a BSSMAP-LE Connection Oriented Information message that contains a BSSLAP MS Position Command message that further comprises an RRLP Measure Position Request message (step 4).

The BSS sends to the MS 120 an RR Application Information message containing an RRLP Measure Position Request message received from the SMLC 132 (step 5). The MS 120 receives a message from the BSS and recognizes a periodic location request based on the periodic location information included in the RRLP Measure Position Request message (or in the previous RRLP Assistance Data message). The MS 120 can receive and measure signals from GPS satellites (for A-GPS) and / or an adjacent base station (for E-OTD).

When the first planned location estimate is the result, or when the first set of conditions (for example, an event) occurs for which the location estimate is necessary, the MS 120 performs A-GPS and / or E-OTD measurements and additionally obtains a location estimate if positioning has been selected based on MS. MS 120 then sends the measurement or location estimate in the RRLP Measure Position Response message, which is transmitted in the RR Application Information message to the BSS (step 6a). The RR Application Information message header includes a flag indicating that it is not the last RRLP Measure Position Response message. The RRLP Measure Position Response message may also indicate that more periodic position estimates will subsequently be provided.

The BSS receives the RR Application Information message from the MS 120 and transmits the RRLP Measure Position Response message in the BSSLAP MS Position Response message, which is transmitted to the SMLC 132 in the BSSMAP-LE Connection Oriented Information message (step 7a). The BSSLAP MS Position Response message header includes a flag indicating that it is not the last RRLP Measure Position Response message. The SMLC 132 calculates a location estimate based on the measurements provided by the MS 120, or checks any location estimate provided by the MS. The SMLC 132 then sends the calculated or verified location estimate to the BSS in the BSSMAP-LE Perform Location Report (step 8a). The BSS receives the location estimate from the SMLC 132 and sends this location estimate in a BSSMAP Perform Location Report message to the 2G-MSC 140b (step 9a). 2G-MSC 140b then transmits the location estimate to LCS client 170, for example via GMLC or BSS.

Steps 6a-9a are for a single location report transmission event. These steps can be repeated for each additional location estimate that is planned or initiated. MS 120 may receive more assistance data by sending a request to the RRLP Measure Position Response message in a subsequent step 6. SMLC 132 and MS 120

consider transmitting assistance data as an additional RRLP transaction occurring in parallel with the delayed RRLP transaction for periodic location determination. Alternatively, the MS 120 may complete the transmission of periodic measurements or location estimates, for example, by including a flag in the header of the RR Application Information message to indicate that it is the last RRLP Measure Position Response message. SMLC 132 may then re-execute the transmission of periodic measurements or location estimates from MS 120 by repeating steps 4-9.

MS 120 sends to the BSS final measurements or a location estimate for periodically determining the location (step 6n). Measurements or location estimates are sent in the RRLP Measure Position Response message, which is transmitted in the RR Application Information message. These messages are the same as those used in step 6a, except that the RR Application Information message header includes a flag indicating that it is the final RRLP Measure Position Response message. The RRLP Measure Position Response message may contain parameters indicating that this is the last periodic measurement or location estimate. Steps 7n-9n are similar to steps 7a-9a. However, the BSSLAP MS Position Response message sent by the BSS in step 7n includes a flag indicating that the final RRLP Measure Position Response message has been sent. The SMLC 132 may send a BSSMAP-LE Perform Location Response message in step 8n, and the BSS may send a BSSMAP Perform Location Response message in step 9n to indicate that the periodic location procedure has completed. SMLC 132 may cause several periodic transmissions of location reports by repeating steps 4-7n. 2G-MSC 140b may continue to periodically transmit position reports by repeating steps 2-9n. Otherwise, the 2G-MSC 140b may indicate to the LCS client 170 that periodic location reporting has now been completed.

During the message flow 1000 of FIG. 10, some exceptions may occur that require additional action. If the MS 120 changes the serving cell, but remains within the service area of the same BSS, or if some other RR control procedure is carried out between the BSS and the MS 120, which still leaves a circuit switched signaling channel between the BSS and the MS 120, then MS 120 may interrupt positioning, and SMLC 132 may re-execute positioning in MS 120 for either a single, single or periodic location determination. Alternatively, the BSS may inform the SMLC 132 of any change in the cell (for example, by sending a BSSMAP-LE Perform Location Information message), and the MS 120, BSS and SMLC 132 may continue to periodically position. For some other exceptional situations, such as handover to the new BSS, the MS 120 and / or BSS may interrupt the periodic location procedure, and the 2G-MSC 140b may re-execute the procedure, for example, by signaling to the new BSS.

Many of the messages of FIGS. 9 and 10 are described in 3GPP TS 43.059 and are used for a single MS location. These messages can be used to periodically determine the location, whenever possible, in order to simplify the implementation of periodic positioning. Other messages may also be used for FIGS. 9 and 10.

4-10 illustrate exemplary message flows that can be used for RAN-based periodic location reporting. The message flows of FIGS. 4-7, 9, and 10 can be used as part of the periodic procedures for MT-LR and MO-LR shown in FIGS. 2A and 3, respectively, after the periodic location request has been authorized. These message flows can also be used as stand-alone procedures and, therefore, are not limited to be part of the periodic procedures for MT-LR and MO-LR. Other message flows for RAN-based periodic location reporting may also be implemented for use with periodic procedures for MT-LR and MO-LR.

UE 120 may initially interact with a RAN (eg, GERAN), which does not have the capabilities of periodic LCS services and does not support the message flows of FIGS. 4-10. Periodic location reporting can then be achieved in another way, for example using UE 120 or a network entity (eg GMLC 150) periodically triggering a message flow to receive and transmit a single location estimate for UE 120 to LCS client 170. If the UE that 120 subsequently moves outside the RAN service area (e.g., UTRAN), which has the capabilities of the periodic LCS services, then the UE 120 can switch to the new RAN, and the capabilities of the periodic services of the LCS of this new RAN can be used to efficiently to ensure periodic reporting of location reports.

For simplicity, the description above for RAN-based periodic location reporting involves deploying a system with one GMLC (for example, as shown in FIG. 1A) and positioning performed for each location estimate. RAN-based periodic location reporting can also be used for multi-GMLC deployments (for example, as shown in FIG. 1B). Increased efficiency can be achieved by applying (1) a short GLMC scheme for deployment with many GMLCs and (2) a short MO-LR scheme for deployment with one or many GMLCs. The short GLMC scheme relates to messaging directly between the R-GMLC 150c and the MSC / SGSN 140 of FIG. 1B, thus bypassing or shorting the V-GMLC 150a and the H-GMLC 150b. The short circuit for MO-LR refers to a positioning bypass for each location reporting event, if an appropriate location estimate is available to UE 120, and the use of a short MO-LR circuit is allowed. The short GMLC scheme, the short MO-LR scheme, or both types of short schemes can be used to save system resources and provide a faster response for transmitting the location to the LCS client 170. Both the short MO-LR scheme and RAN-based periodic reporting can be used to determine the location based on "UE". However, if the UE does not support the short MO-LR scheme, or the LCS client or any of the PLMNs included reject the use of the short MO-LR scheme, then only RAN-based periodic positioning may be appropriate for UE-based location determination. In contrast, if a RAN (e.g., GERAN) does not support RAN-based periodic reporting, then only a short MO-LR scheme may be appropriate (if enabled and supported). To determine the location “using the UE” or the location “based on the network” (for example, for a UE that supports positioning only “using the UE”), a short MO-LR scheme is not used and only RAN-based positioning may be suitable. Therefore, the short MO-LR scheme and RAN-based periodic reporting can be applicable in various circumstances.

The use of the short MO-LR scheme can be controllable for various reasons, such as, for example, to consider the lack of trust in the accuracy and reliability of the UE, or the integrity of the UE (for example, when attempting unauthorized access) for billing and subscription issues and so on. For example, the use of the short MO-LR scheme may be permitted if the UE 120 is trusted to supply location estimates directly to the MSC / SGSN 140 without verification by RAN 130. The use of the short GLMC scheme may also be controllable for billing, subscription reasons and so on.

In an embodiment, one entity (e.g., UE 120, MSC / SGSN 140, or R-GMLC 150c) may request permission to use the short GMLC scheme and / or the short MO-LR scheme for a subsequent location report transmission event. Any other entity (e.g., MSC / SGSN 140, V-GMLC 150a, H-GMLC 150b, R-GMLC 150c, UE 120, and LCS client 170) may accept or reject a request for each type of short circuit. In another embodiment, a single entity (e.g., UE 120, MSC / SGSN 140, or R-GMLC 150c) may indicate willingness or ability to support a short GMLC scheme and / or a short MO-LR scheme without specifically requesting the use of these short schemes. Any object from among V-GMLC 150a, H-GMLC 150b, R-GMLC 150c, UE 120 and LCS of client 170 may then accept or decline the willingness or ability to support each type of short circuit. One entity (e.g., H-GMLC 152) may decide whether to use each type of short circuit if all entities indicate the availability and capability for this short circuit. For all embodiments, a request to use a short GMLC scheme and a request to use a short MO-LR scheme can be considered as independent requests. In addition, any agreement to use the short GMLC scheme and / or the short MO-LR scheme may be applicable for all PLMNs on the list sent by MSC / SGSN 140 to UE 120.

In a further embodiment, any of UE 120, MSC / SGSN 140, V-GMLC 150a, H-GMLC 150b, and R-GMLC 150c can autonomously decide whether to use the short GLMC scheme and whether to use the short MO-LR scheme.

For the MT-LR message flow 200 of FIG. 2A, the R-GMLC 150c can send an LCS Service Request message to the H-GMLC 150b, which can send an LCS Service Request message to the V-GMLC 150a, which can send a message Provide Subscriber Location on the MSC / SGSN 140 to request periodic location reporting. A message sent by each entity may contain (1) an R-GMLC address 150c if a short GMLC scheme is preferred, and (2) an indication as to whether a short MO-LR scheme is enabled or preferred. In an embodiment, R-GMLC 150c, H-GMLC 150b, V-GMLC 150a, and MSC / SGSN 140 may each accept or reject the use of the short GMLC scheme, and each may accept or reject the use of the short MO-LR scheme.

For the MO-LR message stream 300 of FIG. 3, the UE 120 may include (1) a request to use a short GMLC scheme and / or (2) a request to use a short MO-LR scheme (for example, if the UE 120 supports " based on the UE ") in the LCS MO-LR Location Services Invoke message sent to the MSC / SGSN 140 in step 4 of the message flow 300. In another embodiment, the MSC / SGSN 140 may decide one or both of the queries independently without a request from UE 120. In any case, the short circuit request (s) may be forwarded to the V-GMLC 150a, then to the H-GMLC 150b, then to R-GMLC 150c and then to LCS client 170. LCS client 170 sends a response to the request (s) of the UE to R-GMLC 150c, which sends its response to H-GMLC 150b, which sends its response to V-GMLC 150a, which sends its response to MSC / SGSN 140. The response sent by each entity includes the response received from the previous entity (if any) and indicates acceptance or rejecting a periodic location request, and accepting or rejecting each short-circuit request (if sent).

For both the MT-LR message stream 200 and the MO-LR message stream 300, the MSC / SGSN 140 can receive the following information (in the form of additional information above):

1) an indication of a short MO-LR scheme that indicates whether the UE 120 is allowed or expected to deliver location estimates directly to the MSC / SGSN 140 without checking in RAN 130,

2) an indication of a short GMLC scheme that indicates whether location estimates can or will be sent directly to the R-GMLC 150c,

3) the address of the H-GMLC 150b to be used to send location information to the H-GMLC 150b, for example, if a short GMLC scheme is not requested or rejected, and

4) the address of the R-GMLC 150c to be used to send location information directly from the MSC / SGSN 140 to the R-GMLC 150c, for example, if a short GMLC scheme is accepted.

If the short MO-LR scheme is enabled, then the UE 120 may include a location estimate available in the UE in the LCS MO-LR Location Services Invoke message sent to the MSC / SGSN 140. RAN 130 or SAS 132 will not need to calculate the location estimate for UE 120.

If the short GMLC scheme is adopted, then the MSC / SGSN 140 may store the address of the R-GMLC 150c, or the UE 120 may send the address of the R-GMLC in each location reporting event. The MSC / SGSN 140 may then send each location estimate directly to the R-GMLC 150c using the R-GMLC address and may bypass the V-GMLC 150a and the H-GMLC 150b.

For clarity, a specific sequence of steps is shown for each message from the message flow of FIGS. Each message stream may include additional steps, fewer steps, or different steps from those shown for this message flow. The steps for each message flow can be performed in the order shown in this message flow, or in a different order. Each step in each message flow can generally include any number of message exchanges, any type of processing at any object, and so on.

Also for clarity, for the message flows of FIGS. 2-10, specific messages are shown used according to (or applicable to) 3GPP. Other networks and other location structures typically use messages that are different from the messages described above. In general, any signaling can be used to exchange relevant information between different objects in order to implement the functionality described above for transmitting location reports. An alarm may contain messages, packets, indications, flags, or data sent in some other form.

For clarity, the above methods have been specifically described for 3GPP-based networks using a control plane to support location services. The methods may also be used for other networks and other location architectures, such as the SUPL architecture and the pre-SUPL architecture published by the Open Mobile Alliance (OMA), 3GPP2 control plane architecture described in IS-881 and 3GPP2 X.S0002, 3GPP2 user plane architecture described in X.S0024, and so on. The control plane (also commonly referred to as the signaling plane) is a mechanism for signaling transfer for higher level applications and can be implemented using network-specific signaling protocols and messages. The user plane is a data transfer mechanism for higher-level applications and uses a user plane carrier, which is 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 that support location and positioning services are portable (transmitted) as part of the signaling in the architecture of the control plane and as part of the data in the architecture of the user plane. Message content may, however, be similar or even identical in both architectures. Short circuit techniques can also be used for circuit based (CS) modes and packet based (PS) modes, although the messages may be different.

FIG. 11 shows a deployment 1100 of a SUPL system that includes a visited / serving network 1102, a home network 1104, and a requesting network 1106. A visited network 1102 includes a wireless communication network 1130 and a visit location SUPL platform (V-SLP) 1150a. Wireless communication network 1130 provides wireless communications for wireless communications devices located within the coverage area of a wireless communications network. A wireless device is also called a terminal (SET) with SUPL capability. V-SLP 1150a includes a SUPL location center (SLC) 1180 and may include a SUPL positioning center (SPC) 1182. SLC 1180 is similar to V-GMLC 150a and performs various functions for location services. The SPC 1182 is similar to the SMLC / SAS 132 and supports positioning for wireless devices. The home network 1104 includes a home SLP (H-SLP) 1150b that supports location and positioning services for the home network 1104. The interrogating network 1106 includes a requesting SLP (R-SLP) 1150c that supports location and positioning services for LCS customers.

The methods described in this document can be used in deploying 1100 SUPL. For RAN-based periodic location reporting, the V-SLP 1150a or H-SLP 1150b can coordinate and manage periodic reporting for the wireless communications device 1120, for example, as described above. In this case, the RAN will not be specifically involved, and the role of the RAN is performed through the V-SLP 1150a and / or H-SLP 1150b, and / or through the SPC within any of them (for example, through the SPC 1182). The message interaction (for example, transmitting an RRC Measurement Control message and an RRC Measurement Report message) between the UE 1120 and the V-SLP 1150a or the H-SLP 1150b will then be similar to the exchange of these messages between the UE 120 and the RAN / SRNC 130 of FIGS. 5 and 6 except that messages (eg, RRC messages) will be transmitted differently, for example, using TCP / IP and the SUPL positioning protocol defined by OMA, instead of using 3GPP control plane signaling. For a short GMLC scheme in unauthorized mode, the wireless device 1120 or V-SLP 1150a can send the location estimate directly to the R-SLP 1150c, which then forwards the location estimate to the LCS client 1170 and bypasses the H-SLP 1150b and possibly V-SLP 1150a. For the “short circuit” in authorized mode, the wireless device 1120 can send a location estimate to the H-SLP 1150b, which then forwards the location estimate to the R-SLP 1150c, which further forwards the location estimate to the LCS client 1170 and bypasses the interaction with the V-SLP 1150a.

FIG. 12 is a block diagram of various network entities and UE 120 in the 3GPP-based network 100 of FIG. 1. RAN 130 provides wireless communications for network 100 and typically includes at least one RNC and several base stations or nodes B. For simplicity, only one processor 1230, one storage device 1232, one transceiver 1234, and one communication unit 1236 are shown for RAN 130 Each RNC and each base station typically includes one or more processors, storage devices, communication units, and so on, and each base station typically includes a transceiver 1234. Also for simplicity, only one processor 1220, one storage device roystvo one transceiver 1222 and 1224 are shown for UE 120. UE 120 may support wireless communication and may process GPS signals via one or more receivers, one or more antennas, one or more processors and so forth.

On a downlink, base stations in RAN 130 transmit traffic data, signaling, and pilot signals to UEs within their coverage area. These various types of data are processed by processor 1230 and brought into desired state by transceiver 1234 to generate a downlink signal that is transmitted through an antenna. At UE 120, downlink signals from one or more base stations are received via an antenna, conditioned by transceiver 1224, and processed by processor 1220 to obtain various types of information for location services. For example, processor 1220 may obtain a signal arrival time of received signals (which may be used to determine location), decoded messages used for the message flows described above, and so on. Storage devices 1222 and 1232 store program codes and data for processors 1220 and 1230, respectively, in UE 120 and RAN 130. On the uplink, UE 120 can transmit traffic data, signaling, and pilot signals to one or more base stations in RAN 130. These various types of data are processed by processor 1220 and brought into desired state by transceiver 1224 to generate an uplink signal that is transmitted through an antenna of the UE. In RAN 130, an uplink signal from UE 120 and other UEs is received and adjusted by transceiver 1234 and further processed by processor 1230 to obtain various types of information (e.g., data, signaling, messages, and so on). Communication unit 1236 (Comm) enables RAN 130 to communicate with SMLC / SAS 132 and MSC / SGSN 140.

MSC / SGSN 140 includes a processor 1240 that performs processing for the MSC / SGSN 140, a memory 1242 that stores program codes and data for the processor 1240, and a communication unit 1244 that enables the MSC / SGSN 140 to communicate with the RAN 130, SMLC / SAS 132 and other network entities via data / core networks 1202. SMLC / SAS 132 includes a processor 1250 that performs processing for SMLC / SAS 132, a memory 1252 that stores program codes and data for processor 1250, and a communication unit 1254 that allows SMLC / SAS 132 to communicate with RAN 130 and MSC / SGSN 140. In general, each network entity may include one or more processors, storage devices, communication units, controllers, and so on. Data / core networks 1202 may include a core network and / or other private / public data networks.

The methods described herein can be implemented by various means. For example, the methods may be implemented in hardware, firmware, software, or a combination thereof. For hardware implementation, the blocks used to perform processing in each object can be implemented within one or more problem-oriented integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), programmable gate arrays (FPGAs), processors, controllers, microcontrollers, microprocessors, electronic devices, and other electronic devices designed to carry out the procedures described in this document nktsii, or combinations thereof.

For a software implementation, the methods can be implemented using modules (eg, procedures, functions, and so on) that perform the functions described in the document. Software codes may be stored in a storage device (e.g., storage device 1222, 1232, 1242 or 1252 of FIG. 12) and executed by a processor (e.g., processor 1220, 1230, 1240, or 1250). The storage device may be implemented in a processor or external to the processor.

The foregoing description of the disclosed embodiments is provided to enable a person skilled in the art to make or use the present invention. Various modifications to these embodiments will be apparent to those skilled in the art and the general principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Thus, the present invention is not intended to be limited by the embodiments described herein, but it should be accorded the broadest scope consistent with the principles and new features disclosed herein.

Claims (58)

1. A method for providing location services, comprising the steps of:
send one signaling message to a radio access network (RAN) to initiate periodic periodic transmission of user equipment (UE) location reports to a client entity, wherein one signaling message sent to RAN includes periodic location information indicating when send location estimates for the UE to the client entity, and the RAN coordinates and manages the periodic periodic reporting of the location of the UE to the client entity; and
for each location report indicated by the periodic location information,
receive a location estimate from the RAN for the UE and
send a location estimate of the UE to the client entity. 2. The method according to claim 1, additionally containing stages in which:
receive the request sent repeatedly by the client object to periodically transmit location reports of the UE to the client object and forward the request to the UE. 3. The method according to claim 1, additionally containing steps:
receive directly from the client entity a request for repeatedly transmitting UE location reports to the client entity and forward the request to the UE. 4. The method according to claim 1, additionally containing steps:
receive from the UE a request for repeatedly transmitting UE location reports to a client entity, and
forward the request to the client object. 5. The method of claim 1, wherein the RAN is associated with a first location center, and wherein the step of sending the location estimate of the UE to the client entity comprises the steps of sending the location estimate for the UE directly to the second location center and bypassing the first location center, wherein a second location center is connected to the client entity, and the first and second location centers are connected to different networks. 6. The method of claim 5, wherein the step of sending the location estimate of the UE directly to the second location center comprises the steps of sending the location estimate of the UE directly to the second location center and bypassing the first location center and the third location center, wherein the third location center connected to the home network for the UE. 7. The method of claim 5, further comprising storing the address of the second location center. 8. The method according to claim 1, further comprising the step of sending additional signaling to the UE after each transmission of the location report in order to transmit the results of the previous transmission of location reports, to allow the cancellation of repeated periodic transmission of reports, or a combination thereof. 9. The method according to claim 1, further comprising the step of sending additional signaling to the UE before each location report transmission, in order to transmit the results of the previous location report transmission, to inform the UE of the current location report transmission, to allow rejection of the current transmission of the location report location, allow the cancellation of repeated periodic reporting, or a combination thereof. 10. The method according to claim 1, additionally containing steps:
send additional signaling to the UE after completion of the repeated periodic reporting, to indicate completion of the repeated periodic reporting, to transmit the results of the repeated periodic reporting, or a combination thereof. 11. The method according to claim 1, wherein the step of sending the location estimate of the UE to the client entity comprises the steps of sending the location estimate for the UE to the location center associated with the client entity, the client entity being external to the UE. 12. The method of claim 1, wherein the step of sending the location estimate for the UE to the client entity comprises the step of sending the location estimate of the UE to the UE, the client entity being in the UE. 13. A device for providing location services, comprising:
a communication unit operable to facilitate signaling exchange between the network entity and the radio access network (RAN) and between the network entity and the location center; and
a processor operable to send one signaling message per RAN to initiate periodic periodic transmission of user equipment (UE) location reports to a client entity and, for each location report transmission, receive a UE location estimate from the RAN and send a location estimate for that UE to the location center, wherein one signaling message sent to the RAN includes information about repeatedly periodically determining the location indicating when send estimates of the location of the UE to the client, and the RAN coordinates and manages the periodic periodic reporting of the location of the UE to the client. 14. The device according to item 13, in which the location center is associated with a client entity, wherein the RAN is associated with another location center, and the processor acts to send a location estimate of the UE directly to the location center associated with the client entity, and Bypass the location center associated with the RAN. 15. The device according to item 13, in which the processor operates to send additional signaling to the UE before or after each transmission of the location report, to transmit the results of the previous transmission of the location report, to inform the UE of the current or next transmission of the location report, to allow rejection current or next transmission of a location report, allow the cancellation of repeated periodic transmission of reports, or a combination thereof. 16. The device according to item 13, in which the processor operates to send additional signaling to the UE after completion of the repeated periodic reporting, to indicate the completion of the repeated periodic reporting, to transmit the results of the repeated periodic reporting, or a combination thereof. 17. A device for providing location services, comprising:
means for sending one signaling message to a radio access network (RAN) to initiate a periodic periodic transmission of location reports of user equipment (software, UEs) to a client entity, wherein one signaling message sent to the RAN includes periodic location information indicating when to send UE location estimates to the client entity, and the RAN coordinates and manages the periodic periodic transmission of the UE location report to the client entity t; and
means for processing each transmission of a location report indicated by periodic location information containing
means for receiving from the RAN a location estimate for the UE, and
means for sending a location estimate of the UE to the client entity. 18. The device according to 17, in which the RAN is associated with the first location center, and wherein the means for sending the location estimate of the UE to the client object comprises means for sending the location estimate of the UE directly to the second location center and bypassing the first location center, in this, the second location center is connected to the client entity, and the first and second location centers are connected to different networks. 19. The device according to 17, additionally containing:
means for sending additional signaling to the UE before or after each transmission of the location report, to transmit the results of the previous transmission of the location report, to inform the UE of the current or next transmission of the location report, to allow rejection of the current or next transmission of the location report, to allow cancellation of repeated periodic reporting, or a combination thereof. 20. The device according to 17, additionally containing:
means for sending an additional signaling to the UE after completion of the repeated periodic reporting, intended to indicate the completion of the repeated periodic reporting, to transmit the results of the repeated periodic reporting, or a combination thereof. 21. A method for providing location services, comprising the steps of:
receive in the radio access network (RAN) one signaling message sent by the network entity to initiate periodic periodic transmission of location reports of the user equipment (software, UE) to the client entity, wherein one signaling message received from the network entity includes periodic determination information locations indicating when to send UE location estimates to a client entity;
coordinate and manage the repeated periodic transmission of the location report of the UE to the client entity; and
for each location report indicated by the periodic location information:
receive location information from the UE or regarding the UE,
performing positioning, if necessary, based on location information to obtain a location estimate for the UE, and
send a location estimate of the UE to the network entity. 22. The method of claim 21, wherein the periodic location information indicates a predetermined number of location report transmissions and a time interval between successive location reports. 23. The method according to item 21, further comprising the step of sending periodic location information to the UE. 24. The method according to item 21, in which the location information contains measurements obtained by the UE, or RAN, or both the UE and the RAN, and wherein the step, if necessary, perform positioning based on the location information to obtain a location estimate of the UE comprises the steps
sending measurements to the positioning object and
receiving an estimate of the location of the UE from the positioning object. 25. The method according to item 21, further comprising the step of exchanging additional signaling with the positioning object to transmit coordination and control of periodic reporting to the positioning object. 26. The method according A.25, in which the step of performing, if necessary, positioning based on location information to obtain a location estimate of the UE contains the steps
forwarding location information to a positioning object and
receiving from the positioning object a position estimate for the UE. 27. The method according to item 21, further comprising stages, in which
receiving assistance data from the positioning object for performing measurements used to obtain an estimate of the location of the UE; and
send help data to the UE. 28. A device for providing location services, comprising:
a communication unit operable to facilitate signaling exchange between the radio access network (RAN) and the network entity;
a transceiver operable to facilitate the exchange between the RAN and the user equipment (software, UE); and
a processor operable to receive a single signaling message sent by a network entity to initiate a periodic periodic transmission of UE location reports to a client entity, to coordinate and control a periodic periodic transmission of a UE location report to a client entity, and to receive location information from the UE for each location report transmission or regarding the UE, if necessary, perform positioning based on location information to obtain a location estimate I UE and sending the location estimate of UE to the network entity, and received from the network object one signaling message includes information on the periodic determination of the location indicating when to send UE position estimate to the client entity. 29. The device according to p. 28, in which the location information contains measurements obtained by the UE, or RAN, or both the UE and RAN, and the processor acts to send measurements to the positioning object and to receive for the UE a location estimate from the positioning object . 30. The device according to p. 28, in which the processor operates to exchange signaling with the positioning object to transmit coordination and control of repeated periodic reporting to the positioning object. 31. The device according to p. 28, in which the RAN is a universal terrestrial radio access network (UTRAN), and the network entity is a switching center of mobile services or a service node (SGSN) supporting GPRS. 32. The device according to p. 28, in which the RAN is a radio access network (GERAN) with the capabilities of EDGE GSM, and the network object is a center (MSC) switching mobile services or a serving node (SGSN) support GPRS. 33. A device for providing location services, comprising:
means for receiving in a radio access network (RAN) one signaling message sent by a network entity to initiate a periodic periodic transmission of location reports of a user equipment (software, UE) to a client entity, said signaling received from the network entity including information about the periodic determining a location indicating when to send location estimates for the UE to the client entity;
means for coordinating and managing repeated periodic reporting of the location of the UE to a client entity, and
means for processing each location report indicated by the periodic location information containing
means for receiving location information from the UE or relating to the UE,
means for performing, if necessary, positioning based on location information to obtain a location estimate for the UE, and
means for sending a location estimate for the UE to the network entity. 34. The device according to p. 33, in which the location information contains measurements obtained by the UE, or RAN, or both the UE and RAN, and in which the means for performing positioning if necessary based on the location information in order to obtain a location estimate for the UE contains
means for sending measurements to the positioning object and
means for receiving a location estimate for the UE from the positioning object. 35. The device according to p, optionally containing:
means for exchanging signaling with the positioning object to transmit coordination and control of repeatedly reporting to the positioning object. 36. A method for providing location services, comprising the steps of:
receive in the positioning object one signaling message sent via a radio access network (RAN) to initiate periodic periodic transmission of user equipment (UE) location reports to a client entity, wherein one signaling message received from the RAN includes periodic location information indicating when to send location estimates for the UE to the client entity;
coordinate and manage the repeated periodic transmission of the location report of the UE to the client entity; and
for each location report indicated by periodic location information
receive from the RAN location information sent by the UE or relating to the UE,
performing positioning as necessary to obtain a location estimate for the UE, and
send a location estimate for the UE on the RAN. 37. The method according to clause 36, further comprising the step of:
sending assistance data on the RAN to perform measurements used to obtain a location estimate for the UE. 38. A device for providing location services, comprising:
a communication unit operable to facilitate signaling exchange between the positioning entity and the radio access network (RAN); and
a processor operable to receive a single signaling message sent via the RAN to initiate periodic periodic reporting of location reports of user equipment (software, UEs) to a client entity, to coordinate and manage repeated periodic reporting of location reports of a UE to a client entity, and for each transmission location report — receive from the RAN location information sent by the UE or relating to the UE, so that, if necessary, to perform positioning for obtaining a location estimate for the UE and sending the location estimate for UE RAN, and thus adopted by RAN signaling includes information on the periodic location indicating when to send location estimates for the UE to the client entity. 39. The apparatus of claim 38, wherein the processor operates to send assistance data to the RAN to perform measurements by the UEs used to obtain a location estimate for the UE. 40. A device for providing location services, comprising:
means for receiving in the positioning object a single signaling message sent by the radio access network (RAN) to initiate a periodic periodic transmission of location reports of the user equipment (UE) to the client entity, wherein one signaling message received from the RAN includes periodic determination information locations indicating when to send location estimates for the UE to the client entity;
means for coordinating and managing repeated periodic reporting of location reports of the UE to the client entity, and
means for processing each location report indicated by the periodic location information containing
means for receiving from the RAN location information sent by the UE or relating to the UE,
means for performing positioning as necessary to obtain a location estimate for the UE, and
means for sending a location estimate of the UE to the RAN. 41. The device according to p, optionally containing:
means for sending assistance data to the RAN for performing measurements by the UEs used to obtain a location estimate for the UE. 42. A method for obtaining location services, comprising the steps of:
receive in the user equipment (software, UE) one signaling message sent via a radio access network (RAN) to initiate periodic periodic transmission of location reports of the UE to the client entity, wherein one signaling message received from the RAN includes periodic location information, indicating when to send location estimates for the UE to the client entity, and the RAN coordinates and manages the periodic periodic reporting of the location of the UE to the client th object; and
sending location information on the RAN for each location report indicated by the periodic location information, the location information including a location estimate for the UE, or measurements used to obtain a location estimate for the UE. 43. The method of claim 42, wherein the periodic location information indicates a predetermined number of location reporting transmissions and a time interval between successive location reporting transmissions. 44. The method of claim 42, wherein the periodic location information indicates at least one condition for initiating the transmission of a location information report. 45. The method according to § 42, further comprising the steps of:
receive, via RAN, a request sent by a client entity for repeatedly transmitting UE location reports to a client entity, and
send permission or denial regarding the request. 46. The method according to § 42, further comprising the steps of:
receive, by RAN, a request sent by a client entity for repeatedly transmitting UE location reports to the client entity, the client entity residing within the network entity supporting location services, or being directly connected to the network entity. 47. The method according to § 42, further comprising the steps of:
send a request for repeatedly sending periodic location reports of the UE to the client entity, and
accept authorization regarding the request. 48. The method according to § 42, further comprising the steps of:
receive assistance data via RAN to perform measurements; and
use help data to take measurements for each location report transmission. 49. The method of claim 42, further comprising the steps of:
measuring at least one transmitter for each location report transmission, each transmitter being a base station or satellite; and
provide measurements as location information. 50. The method according to § 42, further comprising the steps of:
measuring at least one transmitter for each location report transmission, each transmitter being a base station or satellite;
obtain a location estimate for the UE based on the measurements and
provide a location estimate as location information. 51. The method according to § 42, in which the location information contains measurements used to obtain a location estimate for the UE, the method further comprises the steps of:
receive, by the RAN, a location estimate for the UE for each location report transmission. 52. A device for providing location services, comprising:
a transceiver operable to facilitate communication between a user equipment (software, UE) and a radio access network (RAN); and
a processor operable to receive a single RAN signaling message sent by the RAN to initiate periodic periodic reporting of UE location reports to the client entity, determine when to send location estimates for the UE to the client entity based on the periodic location information included in the signaling received from the RAN, and for each location report indicated by the periodic location information, provide a location estimate for the UE, or the measurements used to obtain a location estimate, as location information, and send location information to the RAN, wherein the RAN coordinates and controls the periodic periodic transmission of the location report of the UE to the client entity. 53. The device according to paragraph 52, in which the processor for each transmission of the location report acts to obtain measurements for at least one transmitter and provide measurements as location information, and each transmitter is a base station or satellite. 54. The device according to paragraph 52, in which the processor for each transmission of the location report acts to obtain measurements for at least one transmitter, to calculate a location estimate for the UE based on the measurements, and provide a location estimate as location information, and when each transmitter is a base station or satellite. 55. The device according to paragraph 52, in which the alarm is created by the switching center for mobile communications (MSC) or the support node (SGSN) of generalized services (GPRS) packet radio. 56. A device for providing location services, comprising:
means for receiving in a user equipment (software, UE) one signaling message sent via a radio access network (RAN) to initiate periodic periodic transmission of location reports of the UE to a client entity, wherein one signaling message received from the RAN includes information about the periodic a location indicating when to send location estimates for the UE to the client entity, and the RAN coordinates and manages the periodic location reporting NII UE to the client object; and
means for sending location information on the RAN for each location report indicated by the periodic location information, the location information comprising a location estimate for the UE, or measurements used to obtain a location estimate for the UE. 57. The device according to p. 56, further comprising: means for taking measurements for at least one transmitter for each transmission of a position report, wherein each transmitter is a base station or satellite; and
means for providing measurements as location information. 58. The device according to p, optionally containing:
means for taking measurements for at least one transmitter for each transmission of a position report, wherein each transmitter is a base station or satellite;
means for calculating a location estimate for the UE based on the measurements and
means for providing a location estimate as location information.

Images