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.
[ /gsm |
permanent link ]
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.
[ /gsm |
permanent link ]
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.
[ /gsm |
permanent link ]
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.
[ /gsm |
permanent link ]
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.
[ /gsm |
permanent link ]
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.
[ /sdr |
permanent link ]
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.
[ /gsm |
permanent link ]
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.
[ |
permanent link ]
|