I'd like to share some basic concepts about Assisted GPS used for Geo/Localization in Mobile Network.

1. Assisted GPS
Some applications benefit from very high accuracy that can be achieved by GPS receivers
integrated into mobile terminals. Latency, usability and accuracy of this GPS receiver can be
improved by sending GPS assistance data from the network to the UE. With the assisted GPS
method it is possible to:
reduce the GPS initialisation and acquisition times; the search window can be limited
and the measurement speed increased significantly for improved Time-To-First-Fix
(TTFF),
consume less handset power than the conventional GPS; this is because of rapid start-
up times as the GPS receiver can be in idle mode when it is not needed,
increase the GPS sensitivity and coverage; navigation messages are obtained through
UTRAN, so the GPS can operate in situations when GPS data is disturbed (for example
indoors, in urban environment).
The basic idea in Assisted GPS is to establish a GPS reference network whose receivers have
clear views of the sky, and can operate continuously. The RAN collects the required GPS data
from this reference network to be able to generate the required assistance data elements to the
UE to assist and speed up the:
location calculation function (see Figure LCS – UE based GPS)
or
signal measurement function (see Figure LCS – NW based GPS).
Also at the request of a User Equipment (UE) or network-based application, only the assistance
data from the reference network can be transmitted to the UE to improve performance of the GPS
receiver (see Figure LCS – UE based GPS).
Figure 6: LCS – UE based GPS
21/07/2010 Assisted GPS
http://127.0.0.1:43231/NED/NED?ser… 1/2

2. GPS and assistance data
The principle of GPS positioning is very simple. GPS positioning is based on measuring relative
times of arrival (TOA) of signals sent simultaneously from a multiplicity of satellites. The distance
between the satellites and the receiver is solved indirectly from the TOA measurements together
with the exact GPS time.
The exact time is needed to calculate the satellites' positions from the received navigation data,
basically to find where they were at the time the signals left the satellites. The GPS satellites are
Medium Earth Orbit (MEO) satellites that move along their orbits very fast, generally a few
kilometres per second. This way, an error of even a few milliseconds induces considerable errors
in SV positions and consequently in the user's position.
In theory, three TOA measurements would be enough to calculate the receiver's position, and also
the velocity in global coordinates assuming that the exact time was already known. In practice,
low-cost and low-accuracy oscillators are used in receivers as local clocks, so a fourth TOA
measurement is required to correct and estimate the error in local time. The fourth measurement
reformulates the 3D position calculation problem into a four-dimensional position-time problem,
where the time error becomes the fourth dimension.
The 50-Hz navigation message includes data unique to the transmitting satellite and data common
to all satellites. The navigation message contains time information, satellite clock correction data,
ephemeris (that is, precise orbital parameters), almanac (that is, coarse orbital parameters),
health data for all satellites, coefficients for the ionospheric delay model and coefficients to
calculate the Universal Coordinated Time (UTC) from the GPS system time. It takes 12.5 minutes
to receive all the satellite data from the GPS System.
GPS positioning depends on the accurate GPS time, navigation data containing satellite orbital
parameters, and distance measurements. If any of these three elements is missing, it can
completely paralyse the GPS-based positioning. This is easily the case in urban areas or indoors,
where constructions or dense foliage attenuate GPS signals, hindering signal reception, and
navigation data demodulation. Moreover, most of the people using positioning services are living
in these areas, which is inherently unsuitable for GPS.
Figure 8: Attenuation of GPS signals
21/07/2010 GPS and assistance data
http://127.0.0.1:43231/NED/NED?ser… 1/2

3. Navigation data reception depends greatly on the signal propagation path. In order to recover
positioning, the missing elements (except distance measurements) can be delivered through a
cellular network. The cellular network can be equipped with a reference GPS receiver located in a
place having an unobstructed view to the sky. Using the reference receiver, the network can
receive navigation data, exact time and other data, and can relay them over the cellular air
interface. By giving satellite orbital parameters and exact time through the network, the availability
and latency of the GPS can be improved. Despite that GPS is not meant for indoor or urban
positioning, the Assisted GPS (AGPS) can be harnessed for that purpose by cellular networks.
However, the indoor environment is badly contaminated by reflected multipath components.
The GPS receiver usually fails when losing line of sight visibility to satellites. The AGPS receiver
can overcome much of the problems, but when brought indoors, it becomes totally dependent on
network assistance and network support. If there is no network coverage and no fresh data in the
receiver's memory, positioning cannot be done. There are also practical constraints on how weak
signals can be acquired and tracked by the receiver. There are cases where even network
assistance cannot improve sensitivity enough to enable the UE to make the TOA measurements.
The A-GPS has different values for latency according to its operational status. In autonomous
operation with line of sight conditions, the cold start, that is searching the satellite signals
independently and receiving the necessary navigation data from the satellites, takes about 35
seconds. If valid navigation data is already in memory or received as assistance, the latency is
from 1-2 seconds up to 10 seconds. In very weak signal conditions, acquisition of satellite signals
takes approximately 1.5 seconds per satellite causing a total of 10 seconds latency. The latency of
network assistance is within a few seconds.
Id: 0900d8058074e284 ©2010 Nokia Siemens Networks
DN70132977
21/07/2010 GPS and assistance data
http://127.0.0.1:43231/NED/NED?ser… 2/2

4. Broadcast of A-GPS Assistance Data
UE-based A-GPS Using External Reference Network and Network Based A-GPS Using External
Reference Network features utilize assistance data sent from Serving Mobile Location Centre
(SMLC) to UE over dedicated connections. Assistance data of A-GPS positioning method can be
broadcasted using SIBs instead of dedicated signaling.
This feature can be activated/deactivated on operator request. Operator is able to activate this
feature for BTS basis. Operator is able to activate broadcasting of SIB15, SIB15.2 and SIB 15.3
separately but to be able to activate SIB15.2 or SIB 15.3 broadcasting of SIB 15 must be
activated.
The UEs which are in other state than Cell_DCH read the SIB information primarily from the cell
broadcast. UE stores the GPS assistance data and uses the stored data as long as it is valid. If
the assistance data stored in the UE's memory is valid, the UE can start the positioning
immediately and the delay caused by the dedicated signaling is avoided. In typical cases A-GPS
positioning can be speeded up to two to three seconds.
When this feature is activated RNC shall broadcast assistance data to all UEs in particular area
by sending assistance data in System Information Blocks. The assistance data to be broadcasted
for assisted GPS may contain a subset of or all of the following information: reference time,
reference position, ephemeris and clock corrections, almanac, UTC model, ionospheric model
and RTI data.
When requested by RNC, SAS generates the GPS assistance data and sends it to the RNC over
the Iupc interface. RNC forwards the data to BTS over Iub interface for possible broadcast over
the Uu interface.
This feature requires that SAS supports OnModification reporting.
Id: 0900d805805955db ©2010 Nokia Siemens Networks
DN70132977
21/07/2010 Broadcast of A-GPS Assistance Data
http://127.0.0.1:43231/NED/NED?ser… 1/1

5. Cell coverage-based (Ci+RTT) with geographical
coordinates
Cell coverage-based positioning is based on the knowledge of the serving cell ID, the
geographical coordinates of the serving cell, the corresponding antenna direction, cell range and
other cell parameters. The information about the serving cell is obtained by, for example, paging,
location area update, cell update, or routing area update.
The accuracy of the cell coverage-based method depends directly on the cell size; in small micro
or pico cells, the accuracy is much better than in large macro cells. The accuracy of the cell-based
method is also improved (as shown in Figure Cell ID + RTT location method) by combining cell-
specific information with the supplementary signal Round Trip Time (RTT), and the UE Rx-Tx Time
Difference (TD) measurements.
Figure 1: Cell ID + RTT location method
The cell coverage-based location result can be provided as the service area identity or as an X-Y-
Z estimate of the geographical coordinates of the UE including the uncertainty of the estimate.
If the LCS client requests the service area identifier (SAI), the serving mobile location centre
(SMLC) maps the cell ID to the SAI, and returns the SAI location of the UE to the core network. If
the geographical coordinates are requested, the LCS calculation algorithms return the estimate of
the UE location in geographical coordinates with altitude, including the uncertainty of the estimate.
RTT and TD measurements
Network architecture and signalling flow
Id: 0900d8058074e284 ©2010 Nokia Siemens Networks
DN70132977
21/07/2010 Cell coverage-based (Ci+RTT) with ge…
http://127.0.0.1:43231/NED/NED?ser… 1/1

6. Network architecture and signalling flow
The network architecture and its elements for the cell coverage-based positioning method are
shown in Figure Network architecture and its elements for cell ID-based positioning method. An
LCS client can request the UE location, for example, from the iGMLC. After validating the location
requestor and the need to locate the UE, the iGMLC performs a request to the MSC. The MSC
does the UE search with, for example, paging and privacy checks and subsequently sends a
location-reporting request to the Serving RNC (SRNC). The SRNC pages the UE if no cell ID is
available, and it also requests the RTT measurement for the UE from the BTS and the Rx-Tx (=TD)
measurements from the UE. The SMLC functionality calculates the UE location and sends the
result to the iGMLC through the core network.
Figure 4: Netw ork architecture and its elements for cell IDbased positioning method
The Figure Cell ID-based positioning method - signalling flowfor MT-LR describes the flow of
the signals and messages in the case of a mobile terminated location request procedure (MT-LR).
All requests are defined according to 3GPP standards and RAN responds with the actual
geographical location information.
21/07/2010 Network architecture and signalling fl…
http://127.0.0.1:43231/NED/NED?ser… 1/3

7. Figure 5: Cell ID-based positioning method - signalling flow for MT-LRMac-hs
From the RAN point of view, the location procedure begins when the SRNC receives a location
request from the Iu interface (RANAP: Location Reporting Control message). This message is
forwarded to the integrated SMLC within the RNC. With this message, the SMLC gets vital
information about the location request. The message includes information such as message
priority (emergency/high/normal), time limit for serving this message (low delay/delay tolerant),
required location accuracy and so on.
SMLC then puts the received Location Reporting Control message into the internal LCS queue.
The queue is organised in such a manner that all Location Reporting Control-messages which are
related to emergency calls are served first. When there are no requests related to emergency calls
left in the queue, all messages with high priority are served. When there are no high priority
messages left in the queue, all messages with normal priority are served. SMLC also constantly
monitors the length of the queue and the location requests within it. When SMLC notices that a
request cannot be served in the given time limits because of the location capacity per second and
21/07/2010 Network architecture and signalling fl…
http://127.0.0.1:43231/NED/NED?ser… 2/3

8. the amount and priority of the requests, SMLC rejects the request and sends the RANAP:
Location Report message to the CN with proper cause value.
SMLC takes as many Location Reporting Control-messages as possible from the queue into
processing. The amount is managed with LCS capacity limitations, which is 15 location request
per second including all types of requests. Capacity limitation is valid also when operating in SAS
centric mode.
In the first stage, SMLC initiates RTT and Rx-Tx measurements for all cells in the active set of the
UE. RTT measurements are initiated over the Iub or Iur interfaces (with the NBAP: Dedicated
Measurement Initiation Request or RNSAP: Dedicated Measurement Initiation Request), and Rx-
Tx measurements are initiated over the control plane RRC signalling (with the RRC: Measurement
Control message). If the UE does not support Rx-Tx type 2 measurements, Rx-Tx type 1
measurements are requested. All WCDMA UEs support rx-Tx type 1 measurements. (They are
also used for call setup purposes to compensate propagation delay of DL and UL in the UE.) After
the SMLC receives the measurements from the UE (with the RRC: Measurement Report
message) and from the BTSs (with the NBAP: Dedicated Measurement Initiation or RNSAP:
Dedicated Measurement Initiation Responses), the SMLC calculates the CI+RTT location with
uncertainty with all the available information from the measurements and with the radio network
database information related to the active set cells (WLCSE elements). If all measurements fail,
SMLC uses the radio network database information related to the active set cells to calculate the
CI location for the UE, as backup method.
The location estimate of the UE is sent to the CN through the Iu interface (with the RANAP:
Location Report message). The message contains the location estimate or suitable failure cause.
Id: 0900d8058074e284 ©2010 Nokia Siemens Networks
DN70132977
21/07/2010 Network architecture and signalling fl…
http://127.0.0.1:43231/NED/NED?ser… 3/3

9. Figure 7: LCS – NW based GPS
GPS and assistance data
Id: 0900d8058074e284 ©2010 Nokia Siemens Networks
DN70132977
21/07/2010 Assisted GPS
http://127.0.0.1:43231/NED/NED?ser… 2/2