Category Archives: Research

Mobile phone network launched by remote town

The remote Mexican town of Villa Talea de Castro, which has a population of 2,500, now has its own mobile phone network.

equipment powering the network



Open-source telecom rocks at Dutch events

Moscow based Fairwaves recently deployed its open-source GSM solution in the Netherlands using the unlicensed GSM spectrum. Small GSM networks were launched during major music festivals in cooperation with Dutch solution provider Event Connection.

I just wish it was easier to find some unlicensed GSM spectrum in the UK ….


Open Source Telecom

The GSM Association (GSMA) ( is an association of mobile operators and related companies devoted to supporting the standardising, deployment and promotion of the GSM mobile telephone system.

Universal service funds (USF) are set up by levies on telecoms in individual countries, which are then used to increase consumer access based on criteria such as income distribution, rural and urban population ratios, literacy and geography.

Universal service funds (USF) set up to improve poor and rural access to mobile services worldwide are “inefficient and ineffective”, according to a recent GSMA report.

More than $11bn (£7.2bn) has yet to be spent, according to the GSMA. “Very few funds, if any, would appear to disburse all that they collect,” it said.

The GSMA report estimates that more than one-third of the 64 funds surveyed have yet to disburse any of the contributions they have collected and less than 12.5% of the funds are meeting their own targets.

This is where Open Source Telecom comes in …

“Fairwaves ( helps mobile operators radically widen subscriber base and boost profitability in low-income regions. With a minimal initial budget, operator could quickly roll-out his network and launch profit-generating services. Fairwaves sells equipment and provide hosted services for mobile operators.

In Fairwaves we believe that communications could be affordable for everyone and mobile networks could be profitable anywhere. We bet on a network of proven partners, the power of open-source and the latest IC technology.”

Below is a link the personal manifesto of Alexander Chemeris, CEO/Founder of Fairwaves:

“I believe that mobile/wireless industry is broken now — it lacks cooperation. Competition is a good thing, but cooperation is no less important. Without cooperation companies throw millions of $$$ to re-implement the wheel instead of implementing what’s important for a customer. And I believe open-source is a great (the only?) way to fix this. Personally, I love open-source exactly for this reason — it improves cooperation and cuts inefficiency. I can’t say how much I hate inefficiency, I can’t stand duplicated efforts which do not lead to innovation.”

Hopefully you now know why I have become so interested in OpenBTS, UmTRX, OsmocomBB etc. over the last few months!



OsmocomBB is an Free Software / Open Source GSM Baseband software implementation. It consists of 3 elements:

  • Firmware running on the baseband chip of a compatible Mobile Phone such as a Motorola C115. Normally this is the GSM Layer 1 (physical layer) firmware
  • A communication process (osmocon) running on a Unix host which relays communication between GSM Layer 2/3 (Data Link and Network layers) applications and the GSM Layer 1 firmware running on the Phone using a serial cable connection
  • GSM Layer 2/3 applications which run also run on the Unix host

The easy way to think of OsmocomBB is a physical NIC card (Mobile Phone and baseband firmware) with a host driver (osmocon) which can be accessed by GSM applications.

The beauty of OsmocomBB is that (ignoring the cost of the Unix host) a compatible Motorola Mobile Phone and USB serial cable can be bought on eBay for less than £10. A £30 Raspberry Pi ( can even be used as the Unix Host.

Playing with GSM and access to GSM Layer 1 does not come any cheaper than that!


osmocon is responsible for downloading custom baseband firmware into the phone. After downloading a firmware image, osmocon turns into an High-Level Data Link Control (HDLC) mulitplexer/demultiplexer allowing for multichannel communication with the phone.

When using the GSM Layer 1 firmware GSM L1CTL messages are received via a USB serial port by osmocon, which demultiplexes the different data streams and passes L1CTL on via a unix domain socket into whatever GSM Layer 2/3 application is running (e.g. mobile, cell_log, ccch_scan, bcch_scan, cbch_sniff or other naughty GSM applications such as RACHell).

./osmocon -p /dev/ttyUSB0 -m c123xor ../../target/firmware/board/compal_e88/layer1.compalram.bin

mobile is a L2/L3 application that implements most of the behavior of a regular GSM telephone but is extended in many ways. The mobile application is used in combination with the layer1.bin firmware.


ccch_scan is a L2/L3 application that can sync to a carrier ARFCN then logs power measurement and GSM Common Control Channel (CCCH) information such as Paging Requests and Immediate Assignments. Like mobile, ccch_scan is also used in combination with the layer1.bin firmware.

./osmocom-bb/src/host/layer23/src/misc/ccch_scan -a 512

As an alternative to the GSM Layer 1 firmware, the RSSI firmware can be downloaded. RSSI is an application that can be used to monitor the received signal indication (RSSI) of ARFCNs or the entire spectrum. RSSI is too big to be loaded directly so it has to be chainloaded e. g. osmocom first loads a little chainloader binary which in turn is used load actual payload (big RSSI binary) specified via “-c” option:

./osmocom-bb/src/host/osmocon/osmocon -p /dev/ttyUSB0 -m c123xor -c ./osmocom-bb/src/target/firmware/board/compal_e88/rssi.highram.bin ./osmocom-bb/src/target/firmware/board/compal_e88/chainload.compalram.bin

YouTube demo here …



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 ( 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 is saved into /tmp/almanac as HTML rather than plain text:


As a quick fix I changed my Almanac URL:



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:// 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 ( 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 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.