How RRLP 'MS assisted GPS' really works

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Harald Welte laforge at gnumonks.org
Sun Dec 12 16:01:22 UTC 2010


Hi all,

I believe I have finally figured out how this 'MS assisted' RRLP mode works.

Not sure if I am the first or the last one to understand it, just wanted to
share what I know:

Just to recap, RRLP has three modes:
 * E-OTD of different BTS signals (AFAIK not used)
 * MS-based GPS positioning (optionally with assistance data from the GSM net)
 * MS-assisted GPS positioning (what I'm talking about now)

On Wed, Dec 08, 2010 at 08:53:48AM +0000, Dieter Spaar wrote:
> This is from the RRLP specification, those are some of the data for
> assisted measurements (those "low-level" data I refered to):
> 
>  Data sent to the phone (for every satellite)
> 
>     Doppler
>     Doppler uncertainty
>     Code phase
>     Int code phase
>     GPS bit number
>     Code phase search window
>     Azimuth
>     Elevation

Basically this tells the phone:
* which doppler shift to expect (result from movement speed of satellite),
  typically in the range of +/- 5kHz of the GPS L1 frequency
* the 'code phase', i.e. the difference between a certain GSM bit (in a
  specified timeslot/frame number/bcch carrier) and a specified GPS bit
  (TOW, bit, chip, ...)
* which azimuth/elevation to expect (not sure how the phone should use this,
  unless it knows the orientation of the antenna and has a MIMO receiver)

what happens now is that the MS will lock onto one specific satellite. It can
do this quickly, as it altready knows 
 * a certain doppler frequency shift (range)
   in which it should apply a known scrambling code sequence (the satellite
   number corresponds to a given pseudo-random sequence), and the
 * expected 'code phase', i.e. the difference between the time at which a
   certain bit is transmitted on the BCCH carrier of a GSM cell, and which chip
   of the given satellite will be expected to be received within the GSM cell.

Once it acquires the signal, it will measure the number of whole (and
fractional) GPS chips that it has observed between
 * the start of a given GSM frame number (called 'reference frame') and the
 * wrap of the GPS 1023bit pseudo-random sequence

This is then sent back to the network:

>  Data sent back from the phone (for every satellite)
> 
>     Carrier Noise Ratio
>     Doppler

this is the actually measured doppler shift for this satellite in the MS receiver

>     Whole Chips (0..1022)
>     Fractional Chips (0..1023)

and this is the number of GPS chips between the wrap of the GSM reference frame
number and the wrap of the GPS 1023 bit chip sequence.  The specification
states "The resolution of the fractional portion is approximately 0.3m"

So all the phone actually ever does is measurement of timing difference.  It
will never try to decode the actual GPS signal at all.

The network (SMLC) can then compute the GPS position, as it can get the timing
information for all the satellites the phone has received, and it already knows
all the other data (almanac/ephemeris/...) from a local database and/or its own
reference receiver.

Pretty interesting.  If only I had the time to implement it ;)

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)




More information about the OpenBSC mailing list