OsmocomBB GSM Development

I have the impression that not a lot of people are developing for Layer-1 in OsmocomBB. Is it because GSM in that depth is too complicated ? Of course you need some GSM knowledge to start, but be assured you will learn a lot if you work on this level.

Besides the really cheap phones supported by OsmocomBB you also need a BTS or GSM Testset for doing serious work. You can use a BS-11 or nanoBTS with OpenBSC or an USRP-1 with OpenBTS. I understand that the price for this hardware might be too expensive for some of you.

However GSM Testsets are not that expensive any more. If you have the room for a large and heavy unit (around 30 Kg) the HP 8922 might be a good solution. You can buy them for a few hundred Euros and this unit is really nice: Besides the GSM Testset it can be used as a very accurate Signal Generator (10 MHz to 1 GHz) and it also comes with a simple Spectrum Analyzer (10 MHz to 1 GHz) as a hardware option. The unit is for GSM-900 but there is an additional converter available for GSM-1800 support. The converter doubles the size of the unit and you usually don't need it. One drawback is that the HP 8922 does not support Encryption. As far as I know this was a Hardware Option but I have never seen a unit for sale which has this option installed. Actually it would only require a different DSP code in one of the EEPROMs which includes the A5/1 or A5/2 encryption code, the rest (Layer-3 support and passing Kc to the DSP) is already there. As usual with most HP units, you can download the documentation from the HP/Agilent web site.

Another GSM Testset I use is the Racal 6103. Its smaller than the HP 8922 and has more Layer-3 options but is not that versatile on Layer-1. The "E" Variant of the unit also supports Encryption. You can sometimes find those units for a few hundred Euros, but be aware that it is not the "Anite" or "Aime" variant, those units require a special PC software to use them, without this software you can't do much with them. So far I have not seen this software, I only know that it is quite expensive.

If you use a GSM Testset, you have one big benefit: You can connect the phone to the Testset with a cable (there is no need for an attenuator) and don't have to care that much about emitting RF on the licensed spectrum.

A few notes about the TI Calypso audio path

While working on voice support for OsmocomBB I had to look in detail at how the audio path in the TI Calypso chipset works. Basically it is not very complicated:

The Uplink path consists of an amplifier for the microphone and an ADC, the digital samples are transferred to the DSP which takes care about the encoding according to the selected GSM voice codec.

In the Downlink path the decoded samples from the DSP are sent to a DAC which is followed by an amplifier and the loudspeaker.

Some additional details are that you can select the analog input/output (e.g. if the headset connector is used). Parameters which can be adjusted are the gain of the amplifiers and the sidetone level (a feedback between the uplink and the downlink audio path).

The digital samples for the DSP use a sample rate of 8 kHz. A not so obvious feature is that there are two FIR (Finite Impulse Response) digital filters with 31 taps in the DSP, one for the uplink, the other for the downlink. Those filters can be used to improve the voice quality or reduce ambient noise. So far those filters are set to not modify the signal (the filter coefficient of the first tap is 1, all others are 0). The format of the filter coefficients is signed fixed-point Q2.14, so for example 0x4000 means 1.

Nokia WCDMA UltraSite Basestation

I bought several components of a Nokia WCDMA UltraSite BTS. However the unit is not yet complete. What is missing:

• IFU - Interface Unit
• WTR - Transmitter and Receiver
• WPA - Power Amplifier
• Rack/Cabinet for all the components

If anyone knows where to get those parts for a reasonable price, please let me know. The final goal is to have support for this unit and similar WCDMA basestations from other manufactures in OpenBSC.

I am aware that UMTS Femtocells are cheaper and they do WCDMA too. Its surely possible to support them in OpenBSC, its mainly a matter of free time and/or who will start with it. But Femtocells have a different architecture than "real" BTS/Node B units, a Femtocell usually combines the RNC (Radio Network Controller) with the basestation and uses a different protocol for controlling the unit. So it still makes sense to have a "real" WCDMA BTS/Node B for OpenBSC integration.

Ciphering Indicator in mobile phones

According to GSM 02.07 B.1.26, there should be a Ciphering Indicator in the ME to allow a user to detect if ciphering is not switched on. The Ciphering Indicator can be turned off by the network operator clearing the OFM (Operational Feature Monitor) bit in the "administrative data" field of the SIM (see GSM 11.11, 10.3.18)

Usually the Ciphering Indicator is turned off, at least in those SIMs I have seen so far. And you usually cannot modify the administrative data in the SIM. But would a phone actually display something if the Ciphering Indicator is enabled and ciphering is not on ?

To find this out I used a Test SIM which allows modifying all fields of the SIM. Such a Test SIM is for testing handsets, you cannot use it with your official GSM network. The OFM bit was set to one to enable the Ciphering Indicator. To simulate encrypted and unencrypted calls I used a Racal 6103E GSM Testset. I could have also used OpenBSC, however with the 6103E switching between encrypted and unencrypted calls was faster, it just required the press of a button.

Here are the results for some phones I had access to, Yes means that I noticed a difference between encrypted and unencrypted calls and what this difference was and No means that I noticed no difference:

• Nokia 3310: Yes, Open Lock Symbol during Call
• Siemens M55: Yes, *!* Symbol during Call, regardless of OFM bit
• Mitsubishi MT-040: No
• P1300: Yes, Cx Symbol during Call
• Motorola C123: No
• Motorola W156: No
• Netzing NE110: Yes, C* Symbol during Call
• BlackBerry 9000: No
• BlackBerry 9520: No
• BlackBerry 9700: No
• Sony Erisson K800i: No
• HTC Touch Pro: No
• HTC Hermes: No

This is by no means a detailed investigation however it is at least some indication that a lot of phones do not care at all about the Ciphering Indicator, probably because it is usually turned off in the SIM anyway.

TCH Support for OsmocomBB

I started to implement Layer-1 support in OsmocomBB for traffic channels. Its not yet ready and in a rather crude state but I hope to clean it up in the next few days so that it can be released.

During testing I used a nice feature of my HP8922 GSM Testset: It can continuously generate Full-Rate TCH speech traffic on a timeslot without the need for any signalling. You can even connect an external audio source like a CD player and "broadcast" your own content. And while it is in this mode, the HP8922 can also receive speech traffic and you can hear it on its built-in loudspeaker.

The benefit of this for getting the Layer-1 code on the phone right is that you can concentrate on TCH receiving and transmitting without having to care about signalling. You just "tune" to the right ARFCN and timeslot (I don't use hopping during testing) and see that you get your code running.

I guess that having this special mode (setting an ARFCN and timeslot and "listen" to the TCH) in the phone can be quite useful for debugging non-hopping, non-encrypted, single ARFCN cells like OpenBSC and OpenBTS.

Microsoft Research and SDR

I wasn't aware of it, but Microsoft Research is doing SDR (Software Defined Radio): Sora.

Their approach is interesting, all the raw samples are transferred between the PC memory and the ADC/DAC of the Radio Front-end by a PCIe card and all the signal processing is done by the CPU of a PC. There is no DDC (Digital Down Converter) or DUC (Digital Up Converter) in an FPGA involved. They already implemented 802.11a/b/g and an LTE receiver this way.

The price of the hardware does not sound too expensive. The software only runs on Windows and I have not yet checked the license terms in detail.

I could imagine that combining this approach with the power of a GPU can be quite interesting.

Extending Airprobe's gsm-receiver

I spent some time to extend Airbrobe's gsm-receiver so that it now can be used to nearly fully decode the downlink traffic of a non-hopping, single ARFCN cell. "Nearly" means that it does not yet support Half-Rate speech TCH channels or TCH data channels (which are not widely used anyway with GPRS).

It might not be obvious, but I was also responsible for decoding/decrypting speech in gsm-receiver. In June 2009 I wrote a tool based mainly on parts of OpenBTS to solve a little "challenge" by Piotr Krysik posted on the Airprobe mailing list to get the speech out of an USRP capture. This standalone tool was later integrated into gsm-receiver by Piotr. Now at least you know who to blame why there is stuff from OpenBTS integrated into gsm-receiver ;-).

Besides being used in Karsten Nohl's A5/1 cracking attack, those features of gsm-receiver are quite handy for debugging OpenBSC or OpenBTS in the downlink direction.

A short tutorial of how to use gsm-receiver can be found here.

One of the next steps I plan to do is implementing the uplink direction. Please don't ask when this will be ready, if someone else is already working on it, please let me know so that the same thing is not done twice.

Starting to blog

I finally decided to start writing a small blog about what things I am working on. The reason is that it seems these days without talking or writing about what you do, your work won't get noticed or others might take what you have done and claim its theirs.