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.