Announcing project OpenBSC

Yesterday I was co-presenting with Dieter Spaar on Running your own GSM network at the 25C3. The talk went quite well, and received an overwhelming response.

Together with the talk, we also announced, described and released the current development version of OpenBSC, a software implementation of the minimal subset of the GSM BSC/MSC/HLR in order to get a GSM BTS up and working.

The code is available in svn, there's a wiki describing it's current status and features (or lack thereof).

Some more progress with the BS11 Abis (BSC) implementation

Very infrequently I've been reporting about my humble attempts in talking the A-bis protocol to the Siemens BS11 microBTS GSM base station.

Since Dieter Spaar and myself are going to have a talk about this at the 25C3 in a couple of days, I'm currently working every minute of each day to get that Free Software BSC-side A-bis implementation going.

While the actual code is getting more and more in shape, I'm now back to fixing the underlying infrastructure: mISDN. The mISDN kernel code base is _really_ hard to understand... if I have problems with it - despite about a decade of experience with network protocols and Linux kernel development - then that probably says quite a bit about it. It would definitely benefit from quite a bit more documentation. Anyway, it's FOSS, so no reason to complain. Use the source, Luke.

So just about one hour before I had to leave to travel to my parents (where I could not take a 48kg GSM BTS with me) I finally had mISDN in shape to be able to support multiple TEIs with different SAPIs on the D Channel of timeslot 1 of the E1 interface carrying A-bis. My userspace code was happily sending and receiving OML (Organization and Maintenance Layer) and RSL (Radio Signalling Link) frames, while the L2ML (Layer 2 Management Layer) is entirely handled by the slightly patched TEI manager that mISDN has in the kernel.

Funny enough, after initializing OML and RSL, the first unsolicited message I got was the error event report about the 'intrusion detection' at the BTS, since I was operating it with open connector panel ;)

So now I've returned to the actual BSC/MSC subset implementation. I'm still confident to finish something that can handle reliably handle voice calls between two handsets registered to that BTS. All on one TRX, no frequency hopping, not using any A5 encryption. POGS (Plain-Old-GSM-System).

I'm very excited about everything that I've learned about the various higher-layer parts of GSM in the last weeks since FOSS.in.

Let's hope that our software plus the presentation at 25C3 can trigger other people to show similar enthusiasm about this topic. There's an almost endless number of opportunities for GSM related security research out there.

GSM hackers meeting at 25C3

There's going to be a meeting of various GSM related hackers at the 25C3. This is exciting, finally some more folks in the FOSS community who are looking at the protocol stack side of things.

We currently loosely coordinated using the wiki page at the 25C3 event wiki.

Understanding the GSM Um Layer 1

More or less involuntarily I ended up spending the better part of the last couple of days understanding all the nasty details of the details about the Layer 1 of the GSM Um (MS-BTS) interface, i.e. the RF interface between your mobile phone and the BTS.

You can find a lot of secondary information about GSM both online and offline, but they all seem to address other issues, like layer 2 and layer3 protocols, even the actual logical channel multiplex (at least to some extent), network planning, etc. - But I've not found anything reasonably detailed about the actual channel coding, TDMA and synchronization, ie. what happens after demodulation and before layer 2. So I had to read the specs. Oh well...

I actually thought that all those parts are already there (in gssm and gsm-tvoid), but in reality that was just something like a proof-of-concept implementation. Restricted to only work on Timeslot 0, not demuxing the individual parts of the CCCH (PCH/AGCH/BCCH/..) and not properly dealing with frame-number counting in case of various receiver overflows or the like.

So I've now started on a new codebase specifically focussed on everything that happens between the differentially decoded GSM bursts and layer 2.

Normally, one would not assume a layer1 to be particularly complex. However, in the case of GSM, it really is. There are various different physical channel configurations, each with their own nasty little differences in the channel coding schemes... plus the synchronous nature with its necessity to know a lot of context and correctly count frames in order to correctly interpret and decode the incoming bits.

So where do we start. Most readers of this blog will know that GSM has 8 timeslots on each RF channel. Each timeslot forms one so-called physical channel, which can assume one of many physical channel configurations.

A physical channel configuration determines not only the particular logical channels residing in the physical channel, but also low-level aspects such as parity, convolutional code, training sequence, tail bits, etc.

In every timeslot on a physical channel we transmit something called a burst. Depending on the physical channel configuration, there can be different bursts:

Normal: A regular burst transmitting 142 bits of data

Frequency Correction: A burst that helps us finding the offset between sender and receiver clock rate, compensate for temperature drift, etc.

Synchronization: A burst for achieving TDMA-frame-number synchronization

Access: A specially (short) burst used in the uplink (MS->BTS) direction to request a channel allocation by the BTS.

Dummy: A burst that is transmitted in otherwise unused/empty timeslots, only on the ARFCN (radio frequency channel) that carries the CCCH/BCCH

All 8 successive timeslots form what is called a TDMA Frame. Every time the timeslot number changes from 7 to 0, the TDMA Frame Number is incremented by the receiver.

For all control channels, four such bursts need to be concatenated and go through convolutional decode and parity to form a 23-byte MAC block. On most, but not all control channels, those four bursts are sent in successive TDMA frames on one timeslot. The notable exception is the SACCH (Slow Associated Control Channel) which accommodates every TCH/F (Traffic Channel) and happens to get one burst at the 13th, 101st, 114th, 202nd, ... TDMA frame. Thus, on such TCH/F channels you need to wait for 202 TDMA frames to obtain the four bursts needed to generate one MAC block. A MAC block is what is then passed up to the layer 2.

Timeslot 0 of the primary radio channel of the BTS is called CCCH (Common Control Channel). It is the only channel about which we can at least make some assumptions about its physical configuration. However, the CCCH carries a number of different channels, such as the BCCH (Broadcast Control Channel), PCH (Paging Channel), RACH (Random Access Channel), SCH (Synchronization Channel), FCCH (Frequency Correction Channel) and possibly a NCH and maybe even a SDCCH/8 multiplexed into it. The "problem" here is that the actual configuration of the logical channels is determined by a layer2 System Information Type 3 message. So you have to work with the minimal guarantees (that there will be a FCCH burst, followed by a SCH burst, followed by four BCCH bursts which give one MAC block, in which you will at some point find the SI Type 3 message telling you how all the other bursts of the CCCH are mapped onto the various other logical channels.

From the System Information messages you can also learn on which timeslot the CBCH (Cell Broadcast Channel) is located. Typically, it is part of a SDCCH/8+SACCH/8C physical configuration. On all the BTS's I've seen protocol traces of (which are not yet that many), this is on Timeslot 1.

A SDCCH/8+SACCH/8C configuration is another weird but more logical multiplex. It consists out of 32 consecutive bursts, four for each of the 8 SDCCH instances that it carries. The following 16 bursts are divided to four, and they alternately serve SACCH0..3 or SACCH4..7. So you basically end up with two 51 multiframes , i.e. 102 bursts, out of which 8 bursts go to each of the SDCCH/8 instances, and four go to each SACCH/8C instance. (102-06 = 6, i.e. 3 bursts are dummy in each 51 multiframe.

For the TCH/F (full-rate traffic channel), the entire viterbi decode and parity is different than the control channels... and which is probably going to be part of another blog post.

Oh, in case you're interested: you can find the unfinished demultiplex code snippets at this git tree

Luckily, with a few days more work, we can actually properly demultiplex and decode all incoming frames, learn about the [dynamic] channel assignments and configurations that the BTS does, and reconstruct at least the MAC blocks for all control channels, if not even the actual speech codec data of the TCH's (on those unencrpted BTS that exist in India). However, actually following a conversation is not possible (and not of interest to me anyway) due to the frequency hopping.

Open source SIM card emulation, SIM card proxying: BLADOX

I've been extremely positively surprised as I recently discovered bladox, a company specializing in providing development tools and custom hardware to simulate, proxy and extend SIM cards. And not only that, they are completely based on gcc + binutils as well as their own open source software. There couldn't be any better playground to play with the SIM interface of any mobile phone.

The general idea is to put an ATMega128 in between your real SIM card and the actual SIM card slot of the GSM mobile phone. On that ATMega128, you can then do whatever you want, e.g. forward only certain commands, such as "perform GSM algorithm" to the actual SIM, and implement the rest in your microcontroller. You can obviously also implement STK applications yourself for demonstration, or you can even block all STK commands and suppress the phone from ever knowing that the SIM actually supports STK.

This is an excellent playground. And it's even sold at a very affordable price. Now if I only had more time to look into all of its exciting possibilities while not forgetting about my other tasks (and paid work) :)

Maybe there are some readers of this blog who are just as interested but didn't even know that such products (and all the example code) did actually exist. Now you know :)

Some more GSM Abis experiments

It's been quite some time since I last mentioned Abis in this blog. Recently, I've again found some time to experiment with Abis. The last two days I was working on porting some proof-of-concept code of a fellow hacker from windows to Linux.

I now also have manufactured all the cables and adapters I need, plus installed a Windows 98 box in order to operate the Wandel+Goltermann MA-10 protocol analyzer that somehow made his way to my lab. The MA-10 can act both a a high-impedance passive sniffer on top of the E1 link (using the Abis Monitor software), or it can actually emulate the BSC by using a terminated E1 Rx+Tx interface and the AbisSim software.

I don't want to talk too much about things that haven't been implemented yet. But in the next weeks, I'll be diving all the way into mISDN and see what needs to be done to make it talk the specific Q.921 dialect that Abis uses.

Stay tuned. I'm working towards a first release at the 25C3 congress in late December.

Extending range of GSM cells by using only 4 channels

Today, while reading IT mainstream magazine "c't", I stumbled across an article about GSM deployments (and popularity) all over Africa.

One of the interesting things in that article was that one Operator had modified their network in a way to only use four timeslots (out of the eight available timeslots) per frequency in order to extend the range of a single cell to something like 70 kilometers.

For those who are not as familiar with the GSM Um air interface: It uses TDMA (multiple devices each get one timeslot on a given frequency). So let's assume we have eight timeslots on one frequency, all the transmitters (handsets) need to be synchronized with regard to that timeslot. Radio travels at speed of light and not with infinite speed. Therefore, since the handsets can be at a lot of distance to the receiver (base station), they might send in the correct timeslot, but the signal arrives out of the timeslot. GSM uses what's called "timing advance" in order to compensate for that effect. The base station tells the handset how much time earlier than the actual timeslot it needs to transmit to ensure arrival within the timeslot.

Now in that African GSM network in question, it seems like even the maximum timing advance is not sufficient. The frame still arrives late, i.e. in the next timeslot. By allocating only every second timeslot, there cannot be any clash and thus the range of a single cell can be extended. This is actually a very cool idea, I would almost call it a "hack", and it is possible within the GSM spec without requiring any change to existing mobile phones!

I only wonder how much of such cool hacks we would see if GSM base stations were more open and available. If there was a full FOSS stack that many people could use on off-the-shelf hardware, it would lead to a lot more innovative experiments and thus innovation. There would suddenly be more than a handful of GSM experts with access to proprietary technology looking at what kind of good, useful, cool and/or creative things one can do...

A Free software 3G protocol implementation: Wireless3G4Free

For quite some time there has been a project called Wireless3G4Free. I suspect it is little known outside a certain academic community. So what is it all about? Creating a FOSS based test platform for wireless 3G systems. Yes, this is the so-called baseband side. The parts that are usually very carefully locked away in the proprietary stack of cellular handsets and other equipments

Even though the project, funded by the European union and implemented at EURECOM in France, is 'finished', it is not as easy as to just use that software and get UMTS connectivity.

First of all, it implements the 3.84MChip/s TDD variant of the physical layer (layer 1), whereas most commercially deployed UMTS systems for cellular access use the FDD variant. For those not as familiar with 3G technology: There's three different layer 1 options: the 3.84MChip/s TDD, the low-chip-rate Chinese TDD variant, and the FDD variant. The layer 1 is separated in two parts, one that is TDD/FDD independent, and the other part that is shared.

Secondly, the Wireless3G4Free project uses IP on the layer 3, as opposed to the actual layer 3 protocol of UMTS (which borrows a lot from the layer 3 protocol for GSM, which in turn borrows a lot from Q.931 / Euro-ISDN).

So if one was to make that code interoperate with UMTS cellular networks, the lower half of layer 1 need to be rewritten for FDD, and layer 3 needs to be implemented.

What is exciting about 3G compared to GSM: GSM uses proprietary ciphers (A5/1, A5/2) for the actual air interface. Those ciphers have leaked quite some time ago, and they're no longer secret (and thus the GSM security is no longer existing), but still people are not supposed to know how it works.

In the 3G world, the corresponding cipher is public. This means that in theory, it should be possible to implement everything in Free Software based on publicly known information. Yes, it is a lot of work. But it definitely can be done.

Before actually using this on any official network, it would obviously need to be certified. Certification for this kind of protocol is a time-consuming and expensive process. It requires development cycles of going to a certified test lab, obtaining test results, going back to actually fixing the problems, re-running the test lab tests, and so on. Nevertheless, Free Software has already proven that this can be done. The isdn4linux project did a full EDSS1 certification some 10 years ago. ELSA, a maker of passive ISDN cards, sponsored that effort. And if you used an unmodified code version, then you were certified. As soon as the source code was changed, you were running an uncertified version. I don't see any big problem why the same scheme should not work for a 3G baseband software stack.

One important question though, is the question of hardware. None of the existing commercial vendors of 3G chipsets will ever provide you with the hardware documentation that you would need or want to run that kind of code on their hardware. It is their business to sell their proprietary 3G stack along with their chip, so they would only loose money if there was any FOSS implementation in competition.

Sure, you can use something like the USRP or USRP2 or any other software defined radio platform. But while that would be ok for a proof-of-concept, it is too large, expensive and power-consuming to be used or 'ported' to any actual handset-type product.

So any possible real-world plan of making this happen would probably go as far as to implement everything based on the USRP, then have a proof-of-concept prototype and then do a modem design based on existing, openly documented RF components and ADC as well as DSP+Processor combination that is suitable for low-power operation.

Sure, I'm just daydreaming. But sometimes you have to dare to dream in order to make things happen. Anyone wanting to turn this idea into a business, let me know ;)

Further studying of Abis protocols, moving towards implementation

The first quarter of 2008 is already gone, and I still haven't found all the time that I wanted to find to play with my BS11 base station[s].

However, I've spent quite a bit of time over the last couple of days further studying the GSM/3GPP 08.5x documents, as well as a thorough read through the mISDN source code.

GSM/3GPP 08.5x describe the layer1, 2 and 3 protocols of the Abis link between BSC (Base Station Controller) and BTS (Base Transceiver Station) in a GSM network. It's modelled on top of a E1 link in PCM30C configuration, i.e. TS0 is for CRC4 and synchronization, TS16 is used for the layer2+layer3 protocols, whereas the other time slots are used for transfer of the actual voice call data.

After looking at the various different driver options on Linux, I have determined that mISDN is the most promising and flexible architecture available. mISDN also has a layer0 + layer1 driver for the NT mode of the HFC-E1 card that I'm using. mISDN is great in a way that every layer is strictly separated from the other layer, and that at any layer parts of the stack can be implemented in userspace using library API.

Thus, I've started to write some mISDNuser based code to attach to the kernel-side hardware and lower-layer drivers. I'm not yet sure if the Q.921 (ISDN Layer2, also called LAPD) of the mISDN kernel side can be reused for Abis or not. The differences between standard Q.921 used on European ISDN and the Abis Layer2 are fairly small, so I hope to get it working with the existing LAPD code.

Unfortunately, I have paid work to take care of, so I will once again be distracted from this most interesting of my toy projects.

Documentation for GSM BTS arrived

Today I finally received PDF's of the Siemens BS-11 GSM BTS. This means that I'll now be able to actually connect the device to power, E1 and RS232.

Unfortunately I'm still lacking the configuration software for the device, and a corresponding E1 card for the Abis interface. Anyway, seems like we're slowly getting there. Maybe during Q1/Q2 2006 I can spend some time actually implementing code for that beast.

Proud owner of a GSM BTS

Starting today, I'm the 'proud' owner of a Siemens BS-11 GSM BTS.

If anyone has documentation on

• The polarity / signal / pin descriptions of the connectors
• The Siemens vendor specific extensions to Abis (The GSM protocol between BTS and BSC)
• Whatever other documentation/information on the BS-11

it would be greatly appreciated if you could contact me.

The whole purpose of this exercise is to do some [security] research in the GSM area, and to see whether it can be done to implement the BSC-side of Abis (and a minimum emulation of HLR, MSC, ..) in order to get a phone to talk to the BTS.

This is yet another of my many toy/pet projects, so please don't expect any even remotely useful code anytime soon. Chances are likely that this project won't go anyway due to lack of time.