Harald Welte's blog
   

RSS

Harald's Web
gnumonks.org
hmw-consulting.de
sysmocom.de

Projects
OpenBSC
OsmocomBB
OsmocomTETRA
deDECTed.org
gpl-violations.org
gpl-devices.org
OpenMoko
gnufiish
OpenEZX
OpenBeacon
OpenPCD
librfid
openmrtd
opentom.org
netfilter/iptables

Categories

Archives

Other Bloggers
David Burgess
Zecke
Dieter Spaar
Michael Lauer
Stefan Schmidt
Rusty Russell
David Miller
Martin Pool
Jeremy Kerr
Tim Pritlove (German)
fukami (German)
fefe (German)
Bradley M. Kuhn
Lawrence Lessig
Kalyan Varma

Aggregators
kernelplanet.org
planet.netfilter.org
planet.openezx.org
planet.openmoko.org
planet.foss.in

Ohloh profile for laforge
identi.ca
twitter
flattr
Linked in
Xing

Creative Commons License
Articles on this blog/journal are licensed under a Creative Commons Attribution-NoDerivs 2.5 License.


blosxom


Contact/Impressum

       
Fri, 17 Dec 2010
Learning how GPS _really_ works in order to truly understand RRLP

Back one or two years ago, when I first discovered the RRLP as a mechanism how operators can get very precise GPS positioning of a mobile phone (without any authentication or a way for the user to prevent or at least notice it), I was frankly speaking shocked.

We've done some experiments at HAR2009 and obtained a number of great position fixes, mostly from iPhones. The nice aspect of RRLP is that it is buried down inside Layer3 of the GSM protocol stack in the baseband processor. This is at a much lower level than all the web or App based location based services that are running in an application program in userspace of the application processor.

Now RRLP comes in a number of different flavors. What we have done so far is called ms-based positioning, where the phone works as an autonomous GPS receiver, pretty much like a personal navigation device or any hand-held GPS receiver. So the network simply asks "tell me your GPS coordinates if you know them" and the phone will respond. Some phones ask for assistance data in order to do A-GPS. But that's it.

What has been more of a mystery to me is the ms-assisted GPS RRLP mode, where the phone just performs some measurements and forwards the resulting data to the network. I never really understood the details of how it works, but always wanted to. Last week I finally found some time to do the research required to fully understand it:

The network tells the phone the exact bit timing, Doppler shift and other parameters for each of the satellites that it _knows_ the phone would be receiving given the current cell the phone is registered to. The phone then performs some measurements within very narrow time/frequency/synchronization windows, and passes back the timing of those received signals relative to the current GSM cell signal. Using this information, the actual position estimate will be completely computed inside the network, not inside the phone.

Presumably this ms-assisted mode was implemented to not have to put a full-blown GPS receiver into every phone, requiring sophisticated processing in either hardware or software. Also, this method should be much quicker as the network _knows_ all the current ephemeris data and GPS signal timing, whereas a stand-alone GPS receiver would have to take quite a lot of effort to acquire a signal from cold-start, even if there is some assistance data.

Unfortunately I don't have the time to actually implement the network side for this. It would be a fun project, but I have already way too many of them (and customers who only pay for other features in our Free Software GSM stack).

There's now a RRLP wiki page at security.osmocom.org. As short as it is it still contains more information about RRLP than I could find on any other public source on the network - except the protocol specs.

[ /gsm | permanent link ]

Wireshark patches enhancing IPA Abis/IP dissector accepted

The wireshark project recently accepted two of my patches related to the Abis/IP dissector. The first of them makes the TCP/UDP port numbers that are interpreted as IPA multiplex a configurable preference. This is really useful, as the actual port numbers used in production setups seem to differ from site to site (with no real standard port numbers and only some that are 'best practise'). Without this patch, in many case you always need to click 'Decode as... GSM IPA' every time you open a pcap file.

The second patch adds support for printing the debug messages that the Hay Systems Ltd. HSL Femtocell includes as stream identifier 0xDD in its Abis/IP variant.

I hope I can find some time to clean up / finish some of the other wireshark patches that we have pending for quite some time. The main problem here is that we imported some definitions from OpenBSC, which use gcc extensions and are thus not permissible for wireshark inclusion.

[ /gsm | permanent link ]