RRLP and OpenBTS – Video

As promised a short YouTube video showing OpenBTS with RRLP in action:


RRLP and OpenBTS – Further Analysis and Final Thoughts

Following on from my previous testing (and mixed results) of RRLP with OpenBTS I decided to do some more experiments. Specifically into the effect of OpenBTS configuration options and also enabling of E-OTD positioning.

For my previous testing the RRLP configuration options have been:

config GSM.RRLP.ACCURACY 7 (default is 40)
config GSM.RRLP.EPHEMERIS.ASSIST.COUNT 6 (default is 9)

There are 32 satellites in the GPS constellation (which is the maximum that the control system can deal with). At least 24 GPS satellites in operation at any given time with a number of on-orbit spares in case one fails. The ephemeris data from the Trimble website (ftp://ftp.trimble.com/pub/eph) contain data for all 32 satellites in the GPS constellation. The satellites are arranged in a variety of six different orbits and each one is in a 12 hour orbit (meaning it takes 12 hours to orbit the earth). A GPS receiver needs to receive a signal from at least 3 of GPS satellites to function.

Accuracy (GSM.RRLP.ACCURACY) is not linear. Valid values are in the range 0 – 127 which corresponds to a real accuracy from 1 metre to 1800 km. 60 = 3km, 40 = 443m, 20 = 57.3m and 2 = 2.1m.

Configuration Option Testing


GSM.RRLP.ALMANAC.ASSIST – 1 means send almanac info to MS and 0 means do not

This resulted in ephemeris assistance data being sent to an iPhone 5:



The iPhone 5 in this case returned a Position Response location error Not Enough Satellites.


It seemed that there was a problem with the RRLP server returning assistance data with the GPS almanac so I ran some manual tests on the RRLP server:

info=”/tmp/ephemeris” is 0.0 hours old info=”/tmp/almanac” is 15.1 hours old {“init terminating in do_boot”,{{badmatch,error},[{rrlpserver,parseAlmanac,5},{rrlpserver,genAlmanacStuff,0},{rrlpserver,assist,0},{rrlpserver,run,0},{init,start_it,1},{init,start_em,1}]}}

I enabled some logging in rrlpserver.erl at line 746:


DEFECT: It looks as though the Almanac file downloaded from http://www.navcen.uscg.gov/?pageName=currentAlmanac&format=yuma is saved into /tmp/almanac as HTML rather than plain text:


As a quick fix I changed my Almanac URL:

config GSM.RRLP.ALMANAC.URL http://celestrak.com/GPS/almanac/Yuma/almanac.yuma.txt


This resulted in GPS almanac data being correctly sent to an iPhone 5:


And a position response being returned successfully:


Sending GPS almanac data as part of the assist data has greatly increased my success rate now. Reducing the value of GSM.RRLP.EPHEMERIS.ASSIST.COUNT e.g. the number of satellites to include in navigation model reduces the amount of assist data (APDUs) that need to be sent to the MS and hence the time taken to transfer assistance data. The value of this option is therefore a trade off against the response time (GSM.RRLP.RESPONSETIME).

My final RRLP configuration options are:


With these settings I can now get an accurate position response from an iPhone 5 most times (assuming an application with Location Services enabled is running at the time of the RRLP request).

E-OTD Testing

As a reminder, Enhanced Observed Time Difference (E-OTD) is based on measurements inside the mobile station (MS), where the phone measures the observed time difference of arrival of bursts sent by nearby pairs of BTS’s. In the RRLP source code the position method is specified in rrlpserver.erp at line 340 and also in sendrrlpbody.erl at line 52. The position method can be modified to request GPS or E.OTD positioning:



This made no difference whatsoever on RRLP response from any of the MS devices tested e.g. Nokia 3310, Nokia 7250i, Blackberry 9360 (Curve) or Apple iPhone 5 which is what I suspected since E-OTD is not widely implemented and would require multiple OpenBTS / BTS to test anyway!

Future Work

The primary function of the RRLP server is to provide assistance data. The current OpenBTS RRLP server acquires the current GPS almanac and ephemeris for from publicly available sources on the internet.

git://git.osmocom.org/osmocom-lcs contains source code that obtains GSM ephemeris data from a real GPS receiver and encodes it in the format needed by RRLP. The GPS receiver used is based on the u-blox GPS 5/6 chipset (http://www.u-blox.com). An example of a USB based GPS receiver which uses a u-blox chipset is the Navilock NL-602U (available on Amazon for £40):


In order to break the dependency on an internet connection (to download the GPS ephemeris data) in the current OpenBTS RRLP server implementation it should be possible to enhance the RRLP server using code from the Osmocom LCS project or some other source code and to obtain this information from a USB connected GPS receiver.

A simple solution would be to write a new daemon which downloads the GSM ephemeris data from a real GPS receiver, saves it to a file in a RINEX 2.10 format and then to modify the OpenBTS GSM.RRLP.EPHEMERIS.URL configuration option to point to this local GSM ephemeris data source.

The problem with Osmocom LCS is that it uses u-blox UBX which is a proprietary protocol to transmit GPS data. A more open solution would be based on National Marine Electronics Association (NMEA) NMEA 0183 which is the standard data communication protocol used by GPS receivers. In theory any GPS-enabled device that can export data in the NMEA format should work – so long as we can get at the GPS ephemeris data.

For u-blox based GPS receivers the NMEA messages sent by the GPS receiver are based on NMEA 0183 Version 2.3. The following diagram shows the structure of a NMEA protocol message:


There is also a C++ GPS Library which uses NMEA known as TinyGPS available here:


Another project that might be a better use of my spare time is investigation into Uplink-Time Difference of Arrival (U-TDOA) methods for locating mobile devices with a bit of GSM burst data analysis , Complex Event Processing (CEP) and data correlation thrown in …. I call this Mobile Fingerprinting … lets see!

Heads up:



RRLP and OpenBTS – Testing at last!

Ok fingers cross – lets try it … Please note that all testing to date has been based on the MS being indoors which might affect GPS results.

The RRLP request is shown in the diagram below. Note that MS-Based positioning method with GPS is requested:


If the MS / Phone does not support RRLP then following entries will be seen in the OpenBTS logs e.g. /var/log/OpenBTS.log:

MS says: message not implemented
RRLP not supported for xxxx

If the OpenBTS option Control.LUR.QueryIMEI has been defined a check is made to see if RRLP is supported by the MS. During a location update (LUR) by default RRLPSupported is set to 1 in the subscriber registry. However if a subsequent RRLP fails this flag is updated and no further RRLP requests are send. The only way the RRLPSupported flag can be set true again is during a LUR followed by a successful RRLP.

Hence for testing purposes it is recommended not to set QueryIMEI

e.g. unconfig Control.LUR.QueryIMEI

Not surprisingly an old Nokia 3310 declined to play and returned a Layer 3 data frame of 061261 e.g. a RR Status with cause 97 e.g. not implemented:



A Nokia 7250 returned a Layer 3 data frame of 0638000322041c e.g. PD RR with ADPU 22041c which is a Position Response location error with reason “Method Not Supported” since the Nokia does not support GPS positioning:



A Blackberry 9360 (Curve) with software 7.0.0 from mid 2011 declined to play like the Nokia 3310 and returned a Layer 3 data frame of 061261 e.g. a RR Status with cause 97 e.g. not implemented. This was strange as it is known to support GPS. Location settings all looked OK:

  • Options -> Device -> Location Settings -> GPS Data Source -> Device GPS
  • Options -> Device -> Location Settings -> Location Services -> On
  • Options -> Device -> Location Settings -> Location Aiding -> On (and also with off)

It suspected that an initial GPS fix was required for GPS to work correctly:

  • Options -> Device -> Device and Status Information -> Key “Test” -> Ok -> Start -> No [Click]
  • Select Location Settings then Run [Click]
  • Select Start Fixing

Having obtained a GPS fix still no success and always got back a RR Status with cause 97 e.g. not implemented.

For the iPhone 5 (on iOS 6.1.3) test I first ensured that GPS was turned on e.g. Settings -> Privacy -> Location Services -> On. The iPhone 5 returned a Layer 3 data frame of 0638000106 e.g. PD RR with ADPU 06 which is an assistance data ACK of NULL. This resulted in the RRLP server simply ACK-ing back from the assist and since there were no more APDU messages to process, exiting the RRLP transact without any location being decoded:



On the odd occasion the iPhone 5 would simply return a channel release:


I checked that the iPhone GPS status indoors was a good fix using an application named GPS Status from PocketGPSWorld.com. Then for some reason success  (even indoors)!

The iPhone 5 returned a Layer 3 data frame of 063800162211ffff619090b6412e8d37f921c8017818102c2110
e.g. PD RR with ADPU 2211ffff619090b6412e8d37f921c8017818102c2110 which is a Position Response with location information containing a position estimate:


In the Wireshark trace below note that the Position Response took 5 seconds:


Hence the location information was stored in the subscriber registry by OpenBTS. The following command was used to gather all of the data from the RRLP table:

sqlite3 /etc/OpenBTS/sqlite3.db “SELECT * FROM RRLP”


My success was short lived and sometimes the iPhone 5 returned a Layer 3 data frame of 063800142204991e1003018d08a4047608240a3034ae3a14 e.g. PD RR with ADPU 2204991e1003018d08a4047608240a3034ae3a14 which is a Position Response location error because  assistance data is missing.

UPDATE 07/04/2013 – To be continued!



It seems that there are some RRLP quirks with the iPhone as tested with iOS 6.1.3:

  • GPS based positioning only works with Settings -> Privacy -> Location Services -> On
  • GPS based positioning only works with another application accessing location services at that time e.g. location arrow is showing. Otherwise it simply returns a PD RR with ADPU 06 which is an assistance data ACK of NULL
  • This seems contrary to E911 regulations (although I tested with a UK iPhone). I suspect that when Emergency call mode is enabled on the MS that Location Services are enabled automatically. I suppose it is also possible that the networks are using some other type of location service based  on Uplink-Time Difference of Arrival  (U-TDOA) methods. This would make sense given GPS dependencies on GPS satellite visibility and also time to fix
  • Regardless if you are using an application with Location Services enabled at the time you receive a call or an SMS then a Position Response with location information containing a position estimate will probably be returned
  • Having WiFi turned on or off has no effect on RRLP behaviour
  • Having GPS turned on really “mullers” the iPhone battery life!

Note: In the process of testing RRLP during SMS and Call Control I found a defect.

DEFECT: With Control.Call.QueryRRLP.Early option set a crash occurs:

OpenBTS: ../CommonLibs/Vector.h:189: void Vector<T>::copyToSegment(Vector<T>&, size_t, size_t) const [with T = char, size_t= unsigned int]: Assertion `base+span<=other.mEnd’ failed.

Hence the solution for now is to unconfigure this option:

unconfig Control.Call.QueryRRLP.Early

As I said in the first RRLP blog post, with OpenBTS it is possible to configure an RRLP request to be sent during location updates (which can be configured on a timer in multiples of 6 minutes), at the start and end of a call or during SMS activity. Since the accuracy of GPS based location information is typically 5-30 metres this means through the use of RRLP in theory and sometimes in reality depending on the MS make and model you can build a pretty detailed map of Mobile Station (MS) and hence their users movements ….

I’ll post a YouTube video and some further thoughts soon.





RRLP and OpenBTS – In Practice (and problems!)

Back to where we started a couple of blog posts ago!

The “sendrrlp” command in OpenBTSCLI has been removed since it was for testing and should not be there. Secondly, sendrrlp.escript is similarly not supported.

There are 4 OpenBTS configuration options which determine when a RRLP query is performed e.g. during call setup, during call teardown, during a Location Update Request (LUR) or during a SMS:

  • Control.Call.QueryRRLP.Early
  • Control.Call.QueryRRLP.Late
  • Control.LUR.QueryRRLP
  • Control.SMS.QueryRRLP

The Location Update Request (LUR) occurs when a MS first camps as well as periodically by OpenBTS as defined by the GSM.Timer.T3212 configuration option. By default this is 30 minutes but in my test configuration I changed it to 6 minutes (must be a multiple of 6):

config GSM.Timer.T3212 6

Note that the Location Update Request (LUR) timeout is the T3210 timer on the MS which cancels the LUR request after 20 seconds. If assistance data is requested it takes about 15 seconds to transmit the GSM Ephemeris data. Hence if a LUR takes longer than 20 seconds without giving a location updating accept or reject the MS will abort the location updating attempt. For this reason OpenBTS 2.8 sends the RRLP after the LUR has completed.

A common problem as widely reported is:

range error=ephemURA of xx.0 (xx) doesn’t fit in (0,15)


In RRLPServer.cpp this causes method “transact” to return early without as MS location being determined:


This error is output in “roundAndCheck” at line 912 in rrlpserver.erl:


The valid range for ephemURA data is defined in the ephemeris Adjustment Table that is used for Ephemeris corrections, scaling, etc at line 1164 in rrlpserver.erl e.g. 0-15. The adjustment table defines: Correction, Scale, Min, Max.


URA is an abbreviation for User Range Accuracy. The URA index defined bounds are 0 to 15:


Lets fetch “CurRnxN.nav” and have a look at the raw data. The .nav data file is formatted as Receiver Independent Exchange Format (RINEX) 2.10 and contains GPS navigation methods. The specification of RINEX 2.10 is here: http://igscb.jpl.nasa.gov/igscb/data/format/rinex210.txt

An example is shown below:


SV accuracy is defined in Broadcast Orbit Record 6 and this value is used as the URA at line 1084 of rrlpserver.erl:



To check the raw data I parsed CurRnxN.nav with a RINEX 2.10 parser written in PHP from here: https://github.com/OzzyCzech/gpsrinex



The confusion arises due to differences between the Receiver Independent Exchange Format (RINEX) 2.10 format and Interface Specification IS-GPS-200 (http://www.gps.gov/technical/icwg/). IS-GPS-200 section states: “SV Accuracy – Bits 13 through 16 of word three shall give the URA index of the SV. The URA index (N) is an integer in the range of 0 through 15.”

Hence the RRLP server needs to be modified to support RINEX and specifically to add a mapping from SV accuracy to URA index like in the code example here:


For now I changed line 1084 in rrlpserver.erl to assume a URA index of 6 e.g. SV accuracy in the range 13.65 – 24 metres:

stuff(“ephemURA”, nmth(7,1,Tokens), AdjustTable),

Changed to:

stuff(“ephemURA”, “6” , AdjustTable),

Ok fingers cross – lets try it … and it does work!


RRLP and OpenBTS – RRLP Installation

apt-get install erlang
apt-get install apache2
apt-get install git-svn

cd /u01/app/openbts
git clone https://github.com/fairwaves/RRLP-2.8.git RRLP

cd /u01/app/openbts/RRLP


cd /u01/app/openbts/RRLP

sh setUpFiles.sh
ls -la /usr/lib/cgi-bin



cd /u01/app/openbts/RRLP
./rrfake loc
./rrfake assist
./rrfake testpos


If you see the error “range error=ephemURA of xx.0 (xx) doesn’t fit in (0,15)” then do not worry – I’ll show you later how to fix this!

./rrtest loc
./rrtest assist
./rrtest testpos

RRLP Configuration

The relevant OpenBTS configuration options are:

  • GSM.RRLP.ACCURACY – Requested accuracy of location request. K in 10(1.1**K-1)
  • GSM.RRLP.ALMANAC.REFRESH.TIME – How often the almanac is refreshed, in hours
  • GSM.RRLP.ALMANAC.URL – URL of almanac source
  • GSM.RRLP.EPHEMERIS.REFRESH.TIME – How often the ephemeris is refreshed, in hours
  • GSM.RRLP.EPHEMERIS.URL – URL of ephemeris source.
  • GSM.RRLP.RESPONSETIME – Mobile timeout. (OpenBTS timeout is 130 sec = max response time + 2.) N in 2**N
  • GSM.RRLP.SEED.ALTITUDE – Seed altitude in metres wrt geoidal surface.
  • GSM.RRLP.SEED.LATITUDE – Seed latitude in degrees
  • GSM.RRLP.SEED.LONGITUDE – Seed longitude in degrees
  • Control.Call.QueryRRLP.Early – query every MS for its location via RRLP during the setup of a call
  • Control.Call.QueryRRLP.Late – query every MS for its location via RRLP during the teardown of a call
  • Control.LUR.QueryRRLP – query every MS for its location via RRLP during LUR
  • Control.SMS.QueryRRLP – query every MS for its location via RRLP during an SMS

My config:


Note: You can find your own latitude, longitude and altitude for the seeds here:


Next – testing problems!









Path Intelligence

Very interesting …


The vast majority of visitors to any given location now carry a mobile (cell) phone. To be able to make and receive calls, the telephone network must understand the phone’s geographical location. The technology behind this is complicated, but in basic terms, the phone and the network continuously ‘talk’ (ping) to each other (sending a unique signal), sending and updating information every time the location of the phone changes.

Path Intelligence’s patent from 02/05/2007 is here : http://bit.ly/bpOsZf

“A plurality of receivers distributed throughout the specified area monitor the area for wireless communication from a mobile device. Mobile devices are identified by way of a unique identifier, e.g. IMSI, IMEI, MAC address, or similar transmitted on a control channel or the like. Whenever such wireless communication is detected, the direction from which the signal is received is detected. The position of the mobile device (and hence the person carrying it) may be calculated by triangulating results from two or more receiving devices, and the results stored.”

Path Intelligence contributed some of their code to the GNU Radio project, specifically the multiple USRP stuff.


RRLP and OpenBTS

Currently OpenBTS 2.8 only supports RRLP MS-Based positioning of GPS enabled Mobile Stations (MS) / phones. Hence RRLP experimentation with OpenBTS to date has only been based on MS-Based positioning. In simple terms the BTS e.g. OpenBTS simply asks the MS “tell me your GPS coordinates if you know them” and the phone will hopefully respond (if it supports RRLP).

The majority of RRLP is not implemented inside OpenBTS but rather in an external RRLP server which communicates with OpenBTS through an HTTP interface. The RRLP server in the OpenBTS trunk is written in Erlang (http://www.erlang.org/) and is deployed as CGI program in a standard web server such as Apache.

The role of OpenBTS is to transfer Layer 4 RRLP APDUs (Application Protocol Data Units) between the MS and the RRLP server. From OpenBTS to the RRLP server these APDUs are encoded in the URLs of HTTP requests. From the RRLP server to OpenBTS the APDUs are passed in HTTP responses.

The OpenBTS RRLP “hooks” are in CallControl.cpp, SMSControl.cpp and MobilityManagement.cpp :


In RRLPServer.cpp the request method is “sendRRLP”:


If the configuration OpenBTS option Control.LUR.QueryIMEI has been defined a check is made to see if RRLP is supported by the MS. During a location update (LUR) by default RRLPSupported is set to 1 in the subscriber registry. However if a subsequent RRLP fails this flag is updated and no further RRLP requests are send. The only way the RRLPSupported flag can be set true again is during a LUR followed by a successful RRLP:


If RRLP is supported an assist followed by a locate request is sent to the external RRLP server. The RRLP server receives GET queries from the OpenBTS core to encode and decode APDUs (Application Protocol Data Units) for RRLP. The HTTP GET request contains all the relevant configuration options. For example:


Note: query can be “assist“, “loc” or “apdu

The primary function of the RRLP server is to provide assistance data. The RRLP server acquires the current GPS almanac and ephemeris for from publicly available sources on the internet. These are downloaded depending upon configuration (passed with each HTTP GET request). By default the almanac is downloaded very hour and the ephemeris is downloaded every 24 hours:


As configured in the configuration option “GSM.RRLP.ALMANAC.URL” the RRLP server downloads GPS almanac data from the US Coastguard Navigation Centre (http://www.navcen.uscg.gov/?pageName=currentAlmanac&format=yuma)


Similarly as configured in the configuration option “GSM.RRLP.EPHEMERIS.URL” the OpenBTS RRLP server downloads ephemeris data from the Trimble website (ftp://ftp.trimble.com/pub/eph).

Rough current time comes from the time-of-day clock on the machine running the RRLP server (web server). The machine running the RRLP server should also be running NTP (network time protocol) to calibrate its time-of-day clock.

Back in RRLPServer.cpp the method “transact” does most of the grafting. It sends the assist or locate request as a HTTP GET to the external RRLP server and then builds a map of responses and any RRLP APDU (Application Protocol Data Unit) to send to the MS.

The APDU is sent to the MS as L3 Application Data and the response analysed. A Radio Resource (RR) management message with a Message Type Indicator (MTI) of Status or APDU is expected:


If an APDU is received the APDU is passed back to the external RRLP server with query set to “adpu” e.g. “query=apdu&apdu=xxxxx


Processing continues until the RRLP server returns an error or hopefully a location is received from the MS. In the case of the location being received method “RRLPUpdate” is called on the Subscriber registry and this causes a new record to be written into underlying RRLP table in the subscriber registry SQLite database:


More soon!


Radio Resource Location services (LCS) Protocol (RRLP) – The Theory

The first in a series of long blog posts …

When looking through the OpenBTS source code to investigate another issue I stumbled across an undocumented CLI command “sendrrlp” which made me look a bit closer at RRLP:


RRLP Overview

Radio Resource Location services (LCS) Protocol (RRLP) as specified first in GSM TS 04.31 is used to exchange messages between a mobile station (MS) and a Serving Mobile Location Centre (SMLC) in order to provide location information in the case of emergency calls. The protocol was developed in order to fulfil the Wireless Enhanced 911 requirements in the United States. However, since the protocol does not use require any authentication, and it can be used outside a voice call or SMS transfer, its use is not restricted to emergency calls and can be used by law enforcement to pinpoint the exact geolocation of a mobile station (MS).

Many modern smartphones with a GPS receiver support of the RRLP protocol. According to its specification RRLP enables the network (or anyone claiming to be the network) to obtain the current GPS fix of the MS without any form of authentication.

All handsets sold in the US market are required, under E911 regulations, to include LCS support. At least 90% of handsets in use in the US and EU today support this protocol. The GSM specifications define several possible techniques for determining the location of an MS, but by far the most commonly used is assisted GPS (A-GPS) and nearly every handset that supports RRLP also supports the A-GPS mode. A-GPS-capable handsets include GPS receivers.

Harald Welte (http://laforge.gnumonks.org/weblog/) proved at HAR2009 that many smartphones submit their GPS location to the mobile operator when requested via RRLP. This happened without any sort of authentication! In all known phones, RRLP operation is completely invisible to the user of the phone.

With OpenBTS it is possible to configure an RRLP request to be sent during location updates (which can be configured on a timer in multiples of 6 minutes), at the start and end of a call or during SMS activity. Since the accuracy of GPS based location information is typically 5-30 metres this means through the use of RRLP you can build a pretty detailed map of Mobile Station (MS) and hence their users movements ….

In summary if you have a mobile phone with GPS anyone can determine your current position without asking you. Hence apart from tracking your mobile cells over time, network operators (and all other parties) just can query your phone actively and without you knowing.

RRLP Positioning Methods

RRLP supports two positioning methods:

  • Enhanced Observed Time Difference (E-OTD) which is based on measurements inside the mobile station (MS), where the phone measures the observed time difference of arrival of bursts sent by nearby pairs of BTS’s. This method is rarely (if ever) used I believe
  • Global Positioning System (GPS). Obviously to support this the MS needs to have a built-in GPS receiver

Since the primary purpose of RRLP is provide geolocation information in the case of emergency call the time to provide a location e.g. GPS time-to-first-fix (TTFF) is important.

For information GPS signals include ranging signals which are used to measure the distance to the satellite as well as navigation messages. The navigation messages include ephemeris data which is used to calculate the position of each satellite in orbit and also information about the time and status of the entire satellite constellation. This is called the almanac.

The GPS almanac is a set of data that every GPS satellite transmits, and it includes information about the state (health) of the entire GPS satellite constellation, and coarse data on every satellite’s orbit. The almanac data tells the GPS receiver where each GPS satellite should be at any time throughout the day. Each satellite transmits almanac data showing the orbital information for that satellite and for every other satellite in the system.

GPS satellites transmit information about their location (current and predicted), timing and ‘health’ via what is known as ephemeris data. Ephemeris data is constantly transmitted by each satellite and contains important information about the status of the satellite (healthy or unhealthy), current date and time. This part of the signal is essential for determining a position. This data is used by the GPS receivers to enable them to estimate location relative to the satellites and thus position on earth.

Standalone GPS provides first position e.g. time-to-first-fix (TTFF) in approximately 30-40 seconds. A Standalone GPS system needs orbital information of the satellites to calculate the current position. The data rate of the satellite signal is only 50 bit/s, so downloading orbital information like almanac and ephemeris directly from satellites typically takes a long time, and if the satellite signals are lost during the acquisition of this information, it is discarded and the standalone system has to start from scratch.

Also some standalone GPS devices may not be able to fix a position due to the fragmentary signal and hence rendering them unable to function until a clearer signal can be received continuously for a long enough period of time. A fix may take as long as 12.5 minutes e.g. the time needed to download the GPS almanac and ephemeris.

Calculation of a position from GPS measurements requires the following information:

  • Pseduoranges. These are timing measurements made on the GPS signal. They are called pseudoranges because they are directly related to the distances from the GPS satellites. Pseudoranges are derived from signal delay measurements called “codephases”
  • Ephemerides. These are detailed descriptions of the current satellite orbits, used to calculate the exact location of each satellite in space
  • Ionospheric model. The radio propagation delay through the ionosphere can vary by hundreds or even thousands of nanoseconds and so must be corrected in the positioning calculations to prevent errors of hundreds of metres in the final positioning results.
  • Seed position. The GPS positioning signal (the “C/A code”) has a period of 1 ms, corresponding to a distance of about 300 km. This means that there are many potential solutions for the GPS positioning equations in an irregular lattice around the Earth. If the GPS receiver does not know its true position within about 200 km, it must check all of these potential solutions in a brute force search before making a reliable position estimate, a process that can take 20 minutes or longer. To avoid this delay, the GPS receiver requires a seed position within 200 km of its true location.
  • Rough current time. Current time must be known to within a few seconds to make rough estimates of satellite position and bootstrap the positioning calculations. Like seed position, rough time can determined through a brute-force search, but that is very time-consuming. Note: With OpenBTS the rough current time comes from the time-of-day clock on the machine running the RRLP server. The machine running the RRLP server should also be running NTP (network time protocol) to calibrate its time-of-day clock.

In normal GPS operation, the pseudoranges are measured directly from the GPS signal, the ephemerides and ionospheric model are encoded into the GPS signal and the seed position is taken from the most recent successful positioning attempt. Often, though, the GPS receiver in a cellular handset / Mobile Station (MS) has no useful seed position saved and receives the GPS signal too poorly to decode the critical data that is encoded in them. However, even under these conditions, the GPS receiver can often measure pseudoranges and “could” estimate a position if the other information were provided to it through some other channel. The process of providing this other information is called assistance.

Note: Until recently GPS enabled phones were banned in some countries:


“The Egyptian authorities have announced plans to loosen the restrictions on the use of GPS devices within the country. The National Telecommunications Regulatory Authority (NTRA) has lifted a ban on civilian use of GPS which had blocked the (official) import of most mid to high end mobile and smartphones. However, the NTRA will still need to authorise each type of GPS device imported into the country and will control any local manufacturing of the devices, it announced on its website at the weekend. While GPS devices will be authorised for sale, the use of GPS for vehicle location services, as used in most mapping applications will still be tightly controlled by the regulator.”

OK enough about GPS so back to RRLP ….

In a RRLP request the method type indicates whether MS-Assisted or MS-Based positioning is to be performed:

Mobile Station Assisted (MSA) / MS-Assisted positioning – The MS performs E-OTD or GPS measurements and passes the raw measurement data to the network. The computation of the geolocation is then performed inside the GSM network and not on the phone itself. Essentially with Mobile Station Assisted (MSA) positioning the calculation of position is undertaken by the network (SMLC) using information from the GPS receiver. This reduces the computational load on the MS.

MS-Assisted GPS is defined as an implementation where assistance data is provided to the MS, by the SMLC, such that the MS can acquire GPS satellite signals and determine their corresponding pseudorange measurements. These time-stamped satellite psuedoranges are returned to the SMLC, where the location estimate is then calculated.

For MS-assisted GPS the SMLC provides detailed information about the current GPS signal to the MS such as:

  • Which satellites are currently in the visible part of the hemisphere
  • The expected doppler shift observed at the MS location, caused by satellite movement relative to MS
  • The expected code phase e.g. the difference between a specified GSM bit and the GPS signal chip / bit
  • The azimuth and elevation of the satellite

Based on this information, the MS does not have to do a full search/acquisition like a stand-alone GPS receiver. Instead, it can do a very narrow search for each satellite in question, as it already knows :

  • At which doppler shift / range to expect the signal
  • Which pseudo-random scrambling sequence to use
  • A very narrow position within the scrambling sequence

This significantly reduces the need for cross-correlation inside the MS. From the RRLP specification the data sent from the SMLC to the MS (for every satellite) is:

  • Doppler
  • Doppler uncertainty
  • Code phase
  • Int code phase
  • GPS bit number
  • Code phase search window
  • Azimuth
  • Elevation

Basically this tells the MS:

  • 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’ e.g. 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

What happens next is that the MS will lock onto one specific satellite. It can do this quickly as it already 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’ e.g. 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 the MS measures 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 SMLC.

From the RRLP specification the data sent back from the MS to the SMLC (for every satellite) is:

  • Carrier Noise Ratio
  • The actual measured doppler shift for this satellite in the MS GPS receiver
  • Whole Chips (0..1022)
  • Fractional Chips (0..1023)

Hence all the MS 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 MS has received and it already knows all the other data e.g. GPS almanac and ephemeris.

Mobile Station Based (MSB) / MS-Based positioning – The MS performs E-OTD or GPS measurements and successively performs the complete computation of the geolocation inside the phone. The result of this computation is then sent back to the carrier network.

MS-Based GPS is defined as an implementation where assistance data is provided to the MS, by the SMLC, such that the MS can calculate its own location estimate.

For MS-based GPS positioning the MS effectively operates a stand-alone GPS receiver and within the phone the GPS receiver will do the regular GPS receive process e.g.

  • Iterate over the list of 64 possible scrambling codes and acquire the C/A signal
  • Decode the actual data signal modulated onto the C/A carrier
  • Measure the timing difference of arrival (TDOA) of the various satellite signals
  • Compute a location estimate (GPS coordinates) based on the measurements

This complete GPS position fix is then communicated to the SMLC.

With MS-based GPS positioning optionally RRLP capable phones will request GPS assistance data from the network. The operation of the GPS receiver is similar to the regular MS-Based GPS however the GPS receiver is now an A-GPS (assisted GPS) receiver.

As previously mentioned, standalone GPS provides first position e.g. time-to-first-fix (TTFF) in approximately 30-40 seconds since downloading orbital information like almanac and ephemeris directly from satellites typically takes a long time

An assisted GPS system can address these problems by using data available from a network. With Mobile Station Based (MSB) assistance the GSM network provides the almanac for the GPS satellites to the GPS receiver, thus enabling the GPS receiver to lock to the satellites more rapidly in some cases.

A list of Assisted GPS (A-GPS) devices can be found here:


RRLP Technical Details

The RRLP protocol is defined in GSM TS 04.31. On the Um interface (GSM 04.08) a Radio Resource (RR) Application Information Message carries the RRLP Message:


All Mobile Terminated (MT) Call Flows are requests for the MS’s current location. The Serving Mobile Location Centre (SMLC) is invoked via a Perform Location Request which contains Request Type (location estimate), Cell ID, Priority, QoS, Classmark, etc. The SMLC then sends an RRLP Measure Position Request message to MS containing the mode of operation (MS-Assisted or MS-Based ) and some amount of assistance data e.g. GPS almanac and ephemeris data.

MS-Assisted call flow (MT):


MS-Based call flow (MT):


In cases where the SMLC initially sends incomplete assistance data to the MS, the MS can request an explicit set of assistance data. The SMLC will then repeat the Measure Position Request message with the requested assistance data:


There are three types of broadcast GPS assistance data:

  • Differential GPS corrections (including Reference Time and Reference Location)
  • GPS Ephemeris and clock correction
  • GPS Almanac and other data

The call flow is generic for both MS-Based and MS-Assisted implementations. The GPS Assistance Data Broadcast Message is created in the SMLC and the whole message is transferred from the SMLC to the MS. The LCS Broadcast Data message from the BTS to MS is described in GSM 03.41.

OK that is enough for one blog post. Next time we will look at the reality of using RRLP with OpenBTS in my own GSM test network. Trust me – it gets more interesting!





Genesys SIP Architecture Changes

There have been some pretty big release announcements relating to Genesys SIP over the last few weeks:

SIP Proxy – [03/15/13] – General
SIP Proxy provides an interface for SIP communication between SIP devices and SIP Server components. It handles register requests, load-balances SIP transactions, and provides an alternative HA model that supports deploying primary/backup SIP Server instances within the same HA pair across different subnets and does not require a virtual IP address.

SIP Server – [03/15/13] – General
Support for a restricted release of SIP Cluster.
Support for Resource Manager in active-active HA mode.
Support for Genesys SIP Proxy

Sipspan2 – [03/15/13] – General
sipspan2 is a log navigation tool designed to simplify troubleshooting in a SIP Cluster environment. It processes log files generated by multiple Genesys components to build a troubleshooting view where each record represents a call flow event given as a clickable link to the corresponding place in a log file.

The primary focus of these releases are to improve the scalability and resilience of the Genesys SIP architecture. Of particular note is the introduction of a new component, SIP Proxy which removes the dependency on third party solutions such a Windows NLB, F5 BIG-IP LTM or IP Address Takeover to provide SIP server High Availability (HA).

The technical documentation relating to these releases is still being produced. However there is a link here which provides deployment information for SIP Proxy:


In summary:

The primary purpose of Genesys SIP Proxy is to provide high availability without requiring a virtual IP address.

An N+1 pool of proxy instances is defined for each SIP Server HA pair. The proxy instances monitor the SIP Server pair to determine which is active and which is backup.

Incoming SIP messages are proxied to the primary SIP Server instance. It is the responsibility of external SIP user agents to select a proxy instance based either on DNS or static configuration of multiple IP addresses, and to fall back to an alternate instance if the select instance is not responding.

In a standard deployment, an N+1 pool of SIP Proxy instances handles incoming and outgoing SIP transactions between a SIP Server HA pair and external SIP elements. Each SIP transaction would be handled by a single proxy instance.

SIP Proxy is responsible for proxying SIP messages from external SIP user agents to the appropriate SIP Server. It is the responsibility of each external user agent to choose a SIP Proxy instance when sending a SIP message.

In SIP Cluster mode, Session storage ensures that each message from the same or related SIP session is routed to the same SIP Server.

SIP Proxy acts as a SIP registrar. SIP Proxy has shared registration-info storage. Any endpoint can be reached by any SIP Proxy. SIP Proxy uses SIP Server as an authentication server. It passes REGISTER requests to SIP Server and waits for a response.

SIP Proxy provides load balancing of incoming traffic across SIP Servers. This is achieved by using a random or round-robin SIP Server selection routine.

SIP Proxy depends on DNS to resolve the SIP Proxy FQDN by A and SRV records (as described in RFC 2782). More specifically, SIP endpoints must support SIP SRV Server Resolution as defined in RFC 3263 – Locating SIP Servers (don’t worry – most IP Phones do). Basically, SRV records are a nameserver record type that return the port as well as weight and priority information for a request. Hence, the SRV records are used by the SIP endpoint to discover the IP address and port of a SIP proxy it should use.


SIP Mid Call Codec Re-Negotiation

Most of us usually work in a SIP environment which is fairly static and the primary codec is G.711 RTP. But in some networks such as Cellular radio networks that might not always be the case. For example in cellular networks codec re-negotiation could occur during Hand Over or Hand Off.

Some background:

The Mobile Telephone Switching Office (MTSO) is the mobile equivalent to a PSTN Central Office. The MTSO contains the switching equipment or Mobile Switching Center (MSC) for routing mobile phone calls. It also contains the equipment for controlling the cell sites that are connected to the MSC.


The most basic form of hand over is when a phone call from a Mobile Station (MS) in progress is redirected from its current cell to a new cell. The source cell and the target cells may be served from two different cell sites or from one and the same cell site. Such a hand over, in which the source and the target are different cells is called Inter Cell Hand Over. The purpose of inter-cell hand over is to maintain the call as the subscriber is moving out of the area covered by the source cell and entering the area of the target cell.

If during ongoing call a Mobile Station (MS) moves from one cellular system to a different cellular system which is controlled by different MTSO and Inter System Hand Over occurs to avoid dropping of the call. This can occur when a mobile signal becomes weak in a given cell and MTSO can not find other cell with in its system to which it can transfer the call. In the context of Inter System Hand Over different cellular systems include 2G Networks, 3G Networks e.g. Universal Mobile Telecommunications System (UMTS) and 4G Networks e.g. Long Term Evolution (LTE).

For the practical realisation of handoffs in a cellular network each cell is assigned a list of potential target cells, which can be used for handing-off calls from this source cell to them. These potential target cells are called neighbours and the list is called neighbour list e.g. a list of neighbour ARFCNs.

During a call one or more parameters of the signal in the channel in the source cell are monitored and assessed in order to decide when a handover may be necessary. The downlink (forward link) and/or uplink (reverse link) directions may be monitored. The handover may be requested by the MS or by the base station (BTS) of its source cell and, in some systems, by a BTS of a neighbouring cell. The MS and the BTSs of the neighbouring cells monitor each other others’ signals and the best target candidates are selected among the neighbouring cells.

From a Genesys perspective what could happen during a Hand Over?

The answer obviously depends on the core network architecture to which Genesys SIP components are connecting. Depending on core network topology a Hand Over could result in a SIP re-INVITE with a change in SDP to change the codecs offered by the network due to cellular Radio Area Network (RAN) conditions. Equally in the case of an Inter System Handover for example between 4G LTE and 3G UMTS networks this could result in a completely new call (SIP INVITE).

Genesys 8 SIP components (SIP Server, Resource Manager, Genesys Media Server, GVP) all support SIP re-INVITE which is specified in RFC3261. RFC3261 states that a SIP UA may change codecs during mid-call with re-INVITE. Effectively a re-INVITE is simply another INVITE on the same SIP dialog but with updated SDP information.

Lets assume we have a call from a Mobile Station (MS) in queue and receiving audio treatment from Genesys Media Server (GMS) under the control of a routing strategy. For an announcement treatment depending on the current codec negotiated GMS may or may not be performing transcoding. For a music treatment if we are using a RTSP streaming music content source then GMS will almost certainly be providing transcoding from MP3 to the negotiated codec.

A hand over then occurs.

SIP Server and hence GMS get re-INVITED and mid call codec re-negotiation occurs. During any current announcement treatment GMS must transcode for the remainder of the announcement. Subsequent announcements will use the audio content file encoded in the native codec format and no further transcoding is required.

The only exception to this is AMR codecs. For AMR, Radio Access Networks (RAN) typically only support a subset of AMR modes. Given that Genesys Media Server looks for AMR encoded files using the file extension we can only encode audio content with a single AMR mode. Therefore, audio content is recorded in the mode with the highest available bitrate and GMS is used to transcode to lower modes if required.

UPDATE 01/04/2013:

A further consideration when using secure RTP (SRTP). Is it a valid thing to change the SRTP media encryption keys during a session and signal this using a re-INVITE?

In RFC4568 (SDES) there is no exact statement regarding this.  In fact section 5.1.4. “Modifying the Session” suggests that this should work: “Once a media stream has been established, it MAY be modified at any time, as described in RFC 3264, Section 8.  Such a modification MAY be triggered by the security service, e.g., in order to perform a re-keying or change the crypto-suite.  If media stream security using the general security descriptions defined here is still desired, the crypto attribute MUST be included in these new offer/answer exchanges.”