Dieter Spaar's blog
   

RSS

Dieter's Web
mirider.com

Projects I am participating
OsmocomBB
OpenBSC

Categories

Archives

Other Bloggers
Harald Welte
David Burgess


blosxom


Contact/Impressum

       
Sun, 09 Sep 2018
A Pico Base Station from Ericsson

The RBS6401 is a small indoor base station from Ericsson for WCDMA or LTE. The device is about two times the size of an ip.access nanoBTS. It is based on a KeyStone I SoC from TI and runs Linux (in fact there are two KeyStone I SoCs inside, but it seems that only one of them is used, at least for WCDMA).

Compared to the other commercial base stations I have seen so far the RBS6401 makes it quite hard to get access to the operating system. It tries to setup a VPN to a Security Gateway for Autointegration into the operator's network and there is only a simple Web Interface to set the network parameters of the device.

Unfortunately I have only found the WCDMA software on the three devices I have access to. It would really be nice to use the RBS6401 with LTE, WCDMA is not that interesting (I am not aware of any Open Source RNC). If anyone has the LTE software for the RBS6401, please let me know.

[ /gsm | permanent link ]

Sun, 21 Jan 2018
More LTE Base Stations

Since running my first own LTE eNodeB in 2013, I acquired a few more. I now have one from NSN, Ericsson and Huawei. All of them are fully functional including the required Remote Radio Heads to actually transmit.

Operating an LTE eNodeB is not very complicated, these days it is even easier with software like NextEPC. The tricky part is setting up and configuring the LTE eNodeB because there is no standard to do so and every manufacturer has its own way. If you are lucky, you might get an already configured system and there is not much you have to adjust. If your system is new or the configuration has been erased, than it can get complicated, at least for the Ericsson eNodeB I have.

[ /gsm | permanent link ]

Sun, 04 Aug 2013
Tracing LTE on the phone

As a short additional note to my first experiments running an LTE eNodeB: I wanted to know how this looks on the phone. The protocol I am interested in is RRC (Radio Resource Control) for LTE (specified in TS 36.331). RRC also transports the NAS messages which are exchanged between the eNodeB and the MME.

The USB LTE Dongle I use for my experiments is based on a Qualcomm chipsets. I used Qualcomm based phones for quite a while so I already know some parts of how tracing works on them. I was able to locate the LTE messages in the traces and extend GSMTAP slightly so that it is able to handle LTE RRC messages too.

Here is how it looks in WireShark when a phone registers to the LTE cell:

The red colored lines are uplink messages (from UE to eNodeB), the blue lines are the response from the eNodeB. The trace also contains a few of the System Information messages the phone has to decode to get all the required information to communicate with the eNodeB. Otherwise you can see that the NAS messages exactly match those seen on the S1-AP interface (of course, this is expected).

[ /gsm | permanent link ]

Tue, 30 Jul 2013
Running your own LTE eNodeB

Finally I got all the required parts together for a fully functional LTE eNodeB. The eNodeB (E-UTRAN Node-B or Evolved Node-B) is the LTE equivalent of a GSM BTS or a 3G Node-B. Considering that its was only less than two years ago when I started to experiment with 3G Node-Bs, obtaining LTE equipment went faster than expected, especially considering that LTE is still in the deployment phase.

Compared to what is needed to run a 3G Node-B, an LTE eNodeB really deserves the "Evolved" in its name. All the functionally of the 3G RNC is contained in the eNodeB (e.g. all the RLC/MAC and radio functionality) and only the higher layers are exposed through the so called "S1" interface. This interface is IP based, there are no such things like E1/T1 or ATM any more.

In case you wonder from where all the configuration parameters for the eNodeB like EARFCN or RF Output Power come from: They have to be configured when setting up the eNodeB, in my case you can configure a few hundred parameters. Luckily most of them have default values which for a start can be taken without modification.

The S1 interface is divided into S1-AP (Application Part) which is specified in TS 36.413. This is the interface to the MME (Mobility Management Entity) which is somehow comparable to a GSM MSC and it uses SCTP. The communication between MME and phone (abbreviated UE like in 3G) are the so called NAS (Non-access stratum) messages, in LTE this is mainly Mobility Management and Session Management, there is no Call Control. LTE NAS is specified in TS 24.301.

The second part of S1 is called S1-U for the user plane traffic which is GTP-U (GPRS Tunneling Protocol) specified in TS 29.281 and using UDP. S1-U connects to the S-GW (Serving Gateway), basically comparable to a GPRS SGSN.

The eNodeB also has a second interface called "X2-AP" (TS 36.423), it is used to interconnect multiple eNodeBs (this is needed for example for handling handover which is done be the eNodeBs themselves). I did not care about X2-AP yet because right now I only have one eNodeB.

So far I wrote a very simple "Proof-of-Concept" so that a phone (in my case an LTE USB Dongle) can register to the LTE cell and transfer data (IP traffic). Just to mention a few of the differences to 3G/GSM:

  • The keys generated by the USIM in the UE (you can use a 3G USIM for LTE too) are not directly used for integrity protection or ciphering. Instead they are used to derive various keys, two of them are the ones used for ciphering/integrity protection on the air interface, this is done in the eNodeB.
  • The NAS messages between UE and MME are also protected (integrity protected and optionally ciphered), another derived set of keys is used for this. This means that even if the keys in the eNodeB can be obtained, the NAS messages are still protected.
  • One Mobility and one Session Management message can be transferred at once in one message over the S1-AP interface, this is for improving speed and saves data transfer on the core network.

Here is how it looks in WireShark when a phone registers to the LTE cell (recent versions of WireShark can handle S1-AP):

The colored lines are uplink messages (from UE to MME), the white lines are the response from the MME. You can see that a default bearer is configured together with attaching to the network. This means that without any further S1-AP messages user plane traffic can start immediately afterwards, at least if the default bearer is sufficient (e.g. the offered quality of service is good enough).

This all is just a very first start with LTE, I hope to find more time for it in the future and explore my eNodeB and LTE further.

[ /gsm | permanent link ]

Sun, 31 Mar 2013
Sometimes you need Wireshark to get an RF Power Amplifier running

I recently had the need for an RF Power Amplifier for the UMTS 2100 MHz band. As I didn't have a suitable amplifier at hand, I though of using one of the RF Power Amplifier modules of my Nokia Ultrasite cabinet which is a Node-B configured for UMTS 2100 MHz. The RF Power Amplifier modules in the cabinet can easily be removed, they are directly connected to the power supply line of the cabinet and they have standard RF connectors for RF In and RF Out. So it should be quite easy to operate them outside the cabinet.

Connecting power to the RF Power Amplifier module was easy, however this wasn't enough, the amplifier didn't amplify any RF although the status LED of the module was on. Also the power consumption was quite low, so obviously the actual RF Power Amplifier in the module was not yet on. I didn't want to modify the electronic inside the module so I had to find out how the module gets enabled in the cabinet.

Nearly all of the various modules in the Nokia Ultrasite cabinet are connected at the backplane to Ethernet through a hub (yes, a hub, there is no switch). This Ethernet network is mainly used for controlling the modules, fast data transfer between the modules is done somewhere else. The RF Power Amplifier module is no exception, it's connected to this control Ethernet network too. The configuration and management port of the cabinet is also an Ethernet port connected to the same control network. And because an Ethernet hub is used, all the traffic on this network can be monitored without any further tricks if you are connected to the cabinet's configuration and management port.

So I run Wireshark and captured a trace of the traffic on the cabinet's control network. I already knew the IP address of the RF Power Amplifier module from running it externally, however it only responded to a ping but no TCP or UDP port was open. (BTW, if you wonder how the module gets its IP address: depending on the slot where the module is inserted into the cabinet, different ID pins of the module are grounded. The levels on those ID pins define the MAC and IP address of the module).

From the trace I was able to find out hot it works, it's actually quite evolved:

  • First a certain UDP packet has to be send to the RF Power Amplifier module. Not just destination IP address and port have to match, also the source IP address and port have to be a specific value, if not the module just reports an ICMP error that the port is unreachable (that's the reason why I didn't find an open port during my first try).
  • This UDP package causes the module to initiate a TCP connection back to the sender, when the TCP connection is open the module sends some kind of initialization message and expects an acknowledgment.
  • Only after the TCP connection is open and properly initialized, another UDP package can be send to the module which finally turns the RF Power Amplifier inside the module on.
I am not sure why the TCP connection is necessary, so far I only found out that it is used to control the status LED of the module and to return the operational status (e.g. if a fault was detected). Over UDP it's also possible to query the serial number of the module or to tell it to periodically return RF power measurements. So as you can see, sometimes even just a "simple" thing like an RF Power Amplifier can require quite complicated interaction to run it.

[ /gsm | permanent link ]

Mon, 10 Sep 2012
Getting voice to work for OpenBSC and Ericsson RBS

When Harald Welte visited me for the Osmocom User Group meeting, he took the chance to experiment with OpenBSC and my RBS2206, a large GSM BTS in a cabinet. This inspired me to do some more investigations to get the RBS2206 actually run with OpenBSC including voice calls.

When OpenBSC configures a channel for voice, the RBS closes the channel after a few seconds with a "remote transcoder failure" error. I found some information which seems to indicate that there are O&M TRAU frames involved to signal the usage of the correct codec between BTS and TRAU. So I started to analyze the traffic between the RBS and the Racal 6113, a BTS tester which is able to run the RBS including voice calls. To analyze the traffic, I used a Siemens/Tektronix K1103 which can trace E1/T1 traffic.

To my surprise I did not find any O&M TRAU frames in the trace. After doing some more experiments it turned out that the RBS expects to receive speech TRAU frames of the same type (e.g. FR or EFR) as soon as it starts to transmit speech TRAU frames after the channel was configured for voice. So far OpenBSC sends Idle Speech frames as long as the voice channel is not yet connected to the other phone. This worked fine for the Siemens BS-11 or Nokia MetroSite/InSite BTS, but obviously did not work for the Ericsson RBS.

After adjusting the idle TRAU frame generation in OpenBSC with a quick workaround and solving some minor problems when configuring the RBS (depending on the software versions in the RBS some configuration messages are slightly different) I was finally able to run OpenBSC including voice calls with the RBS2206 over an E1 line and an RBS2401 over T1. The modifications are not yet in OpenBSC, but should be there soon after cleaning them up.

[ /gsm | permanent link ]

Tue, 24 Apr 2012
A bit of 3G Layer-1

While experimenting with my Node-B, I had the need to generate a RACH message without having to use a phone. Such an approach can for example be used for performance testing of the Node-B receiver or evaluating the RACH handling capacity of the radio network (no, I don't call it RACH DoS ;-)

First a little bit of theory: The RACH in UMTS works different than in GSM, its not just about sending a single RACH burst. Because WCDMA is very sensitive to interference, the phones have to send with a transmit power as low as possible. For the RACH procedure this means that the phone starts to send a short RACH preamble with very low power and looks for the acknowledgement if the preamble has been received by the Node-B on the AICH (Access Indication Channel) channel. If the phone doesn't receive the acknowledgement, it increases the transmission power and resends the preamble. If there is the acknowledgement from the Node-B, the phone sends the actual RACH message. The RACH message itself is not just a few bits containing the access cause and a random reference like in GSM, it is a complete message. "RRC Connection Request" is used for accessing the network but other message can also be sent on the RACH channel (e.g. "Cell Update" which is besides other things used for indicating unrecoverable RLC errors. One can see this message frequently when starting to implement an RNC ;-).

Now where to get a RACH preamble and message without having to use a phone? I started to look at Agilent's Signal Studio for WCDMA which should be able to generate a RACH messages with user defined content which can be replayed with a signal generator. However even after lots of trials I never managed to generate a RACH message which can be properly decoded by the Node-B, only the RACH preamble is detected without errors but the RACH message itself just produces garbage and CRC errors.

So I started to write my own code to generate the RACH message. The relevant 3GPP specification for WCDMA FDD is TS 25.212 (Multiplexing and channel coding) and TS 25.213 (Spreading and Modulation). Basically the steps to create a RACH message requires adding a CRC to the message bits, Convolutional encoding, 1st Interleaving, Rate Matching, 2nd Interleaving, Spreading, Scrambling and finally Modulation. I and Q signal on the Uplink carry different things, Data is on the I signal, Control (pilot bits and transport format information) on the Q signal. Luckily the RACH message does not require any fancy multiplexing and rate matching of multiple transport channels on a physical radio channel. This can get really funny, especially if Turbo Coding is involved which results in multiple bit streams (systematic and parity bits) which are treated differently. After some trial-and-error and lots of experimenting and testing I was finally able to create a well formed signal of a RACH preamble and message which the Node-B can properly decode.

After that I also tried to decode the RACH message generated by Agilent's Signal Studio to find out why it didn't work. It seems that the wrong scrambling code sequence is used (the scrambling code number looks OK, but the offset into the code bits is wrong). I really wonder why no one noticed this problem with Signal Studio before or maybe I am just doing something wrong. Anyway, I can now use my own code to generate RACH messages. Maybe in the future I will also look into generating a signal which a phone will consider as valid signal of a 3G cell, this requires generating the P-CPICH (Primary Common Pilot Channel), P-SCH/S-SCH (Primary/Secondary Synchronization Channel) and P-CCPCH (Primary Common Control Physical Channel) carrying the BCH.

[ /gsm | permanent link ]

Mon, 16 Apr 2012
3G User Plane

Continuing with my Node-B experiments I started to implement handling the user plane. I can now do voice calls, video calls and data connections. Just to make it clear, those are the very first steps only without any optimisation for speed and far from being complete or ready for release. I consider it as the essential "building blocks" necessary for the next steps towards a small Open Source RNC.

So how does it work? One way to allocate a channel for user data is to modify the existing signalling channel by sending the RRC "Radio Bearer Setup" message to the phone and the NBAP "Radio Link Reconfiguration Prepare/Commit" messages to the Node-B. Besides being much more complex due to the number of possible parameters and options this is somehow comparable to TS 04.08 "Channel Mode Modify" and A-bis TS 08.58 "Mode Modify" in GSM. If the commands succeed the Node-B will allocate another UDP port for the User Plane data besides the existing UDP port for the Control Plane data (UDP ports because I use "Iub over IP" to talk with the Node-B).

The User Plane data are embedded in FP (Frame protocol, TS 25.427). For voice the data are the AMR class A, B and C bits. To ease testing with a single phone I use a loopback which simply sends the received uplink AMR class bits back to the downlink.

Signalling for a Video Call is very similar to a Voice call. The main difference is in the CC Setup message, the bearer capability indicates UDI (Unrestricted Digital Information) for Video. UDI is basically a 64 kbit/s channel which transports video according to the 3GPP umbrella protocol 3G-324M) for video telephony. Loopback is not as easy as for voice because first the four-way H.245 protocol handshake has to be completed to agree on communication parameters, after that the uplink video data can be resent to the downlink.

Although UMTS is generally much more complex than GSM/GPRS, handling of data connections is easier than for GPRS because there is no need for a PCU (Packet Control Unit) with all its complexity. There is the optional protocol PDCP (Packet Data Convergence Protocol, TS 25.323) on top of RLC which is used for things like header compression. But if you don't use it, you get the raw IP packets embedded inside RLC.

[ /gsm | permanent link ]

Thu, 02 Feb 2012
Running your own Node-B

Its now nearly 3 and a half year ago that I wrote the first "Proof-of-Concept" code to get the Siemens BS-11 GSM Basestation up and running. So I think it was time to start with 3G, now that LTE is being actively deployed. You also can sometimes find reasonable priced, used Node-Bs which makes getting access to the equipment possible. A Node-B is the 3G equivalent of a GSM BTS.

So I spent quite a lot of time spread of several months to get a Node-B up and running. Compared with the BS-11 this was a lot more difficult and required much more time. Of course the Air Interface is completely different, in my case I looked at WCDMA FDD so far, there a few more standards used in other parts of the world. Then you have to deal with a huge, different specification, the most important when dealing with a Node-B are NBAP (TS 25.433) and RRC (TS 25.331), around 3000 pages in total. NBAP, the Node-B Application Part, is used to configure the Node-B and do things like creating Radio Links (communication channels) to the phone. RRC, the Radio Resource Control, is the Layer-3 protocol for the control plane between the phone and the access network. It is responsible for accessing the network, setting up and releasing connections or paging a phone. Both NBAP and RRC make use of ASN.1 which makes things not necessarily easier ;-) There are a few more protocols on the lower layers involved like MAC (TS 25.321), RLC (TS 25.322) and FP (TS 25.435 and TS 25.427).

The Node-Bs I used can run "Iub over IP" (Iub is the interface between the Node-B and the RNC, similar to Abis in GSM between the BTS and BSC). Originally Iub is based on ATM which runs over E1/T1 or similar lines with higher data rates. However "Iub over ATM" adds a few more protocol layers for dealing with ATM and I really wanted to avoid this additional complexity. Not all Node-Bs can automatically do "Iub over IP", usually it requires an additional hardware option (interface card). When using "Iub over IP" you have to deal with protocols like UDP and SCTP which are much more convenient.

The current status is a very minimal implementation of something like an RNC to run the Node-B so that a phone can register on the network and do simple things like SMS on the control plane. No user plane like speech or data yet, but this is the next steps I plan to do. The code is not yet public but it will be when it gets more evolved.

There is still a lot left to research and experiment with. For example I haven't looked at things like HSPA yet, I completely ignore handover to other cells as there is only one cell in my experimental setup. So I am sure 3G will give a few more years of a very interesting field to play with before looking at LTE ;-)

[ /gsm | permanent link ]

Sun, 30 Jan 2011
GPRS Air Interface

To get a better understanding of how GPRS looks like at the air interface, I implemented some first experimental code in Airprobe (this is not yet ready to be released). The output of this code are the RLC/MAC blocks on the downlink (no uplink yet). As far as I am aware, WireShark cannot decode RLC/MAC yet.

The GPRS air interface is not that different than "standard" GSM (signalling or voice). The PDCH (Packet Data Channel) uses its own multiframe structure with a length of 52 frames, the biggest difference are four coding schemes (CS-1 to CS-4, CS-1 and CS-2 use puncturing) which are chosen depending on the quality of the radio link. If the link quality is good, a coding scheme with less forward error correction and more information bits is used which results in a higher data rate. As a side note, you can test how good your receiver really is if CS-4 is used (very good radio link quality, no forward error correction at all), you should have nearly no bit errors in the decoded data (the phone also receives error free data, otherwise CS-4 would not be used).

I have not yet implemented decoding EDGE, besides other coding schemes EDGE can also use a different modulation (8-PSK instead of GMSK).

Please note that being able to decrypt the A5 encryption does not help with GPRS, it does not use A5 encryption at all, it uses its own encryption algorithm (GEA) at a higher level. If you want to experiment with GPRS encryption, the easiest to start with is probably using a GPRS setup with OpenBSC plus the nanoBTS and look at the traces to the SGSN with WireShark (you have to implement a GPRS encryption algorithm in osmo-SGSN first, the specification of GEA3 is publicly available).

[ /gsm | permanent link ]

Sat, 22 Jan 2011
GSM Ciphering Algorithms in mobile phones

You are probably aware that the A5/1 and A5/2 GSM ciphering algorithms are broken, A5/2 is so weak that even the GSMA mandates that it is no longer used in new mobile phones. A secure alternative would be A5/3, however it is not yet deployed in GSM networks, at least those networks I am aware of, and only some newer phones support it.

I had a brief look at some phones I have access to, most of them came out in the last four years. Interestingly quite a lot of them still support A5/2 and only very few support A5/3. If a phone does not indicate A5/3 support, this does not necessarily mean that it is not capable to run A5/3, for example on one of my test phones, a BlackBerry Bold 9000, A5/3 is disabled (for whatever reason). The phones in my collection with enabled A5/3 support are some new, cheap features phones from India based on a MediaTek chipset. And as a side note: The iPhone 4 I looked at does not have A5/3 enabled but at least A5/2 is disabled.

I also did a few quick tests to make sure that A5/2 cannot be used on those phones which claim that they do not support it, and so far this seem to be the case. The reason for this test: The phones can most certainly run A5/2 if they can run A5/1 (which all of my phones can), A5/2 is very similar to A5/1. If a phone claims to support only A5/1, it does not necessarily mean that the phone will not use A5/2 if you force it to do so, if there are bugs in the phone firmware, the phone could still run A5/2.

The short tests I did are only a first look at this issue. Additionally the same phone model could behave different when sold by a different operator or in a different country, as I already wrote, most of the time the supported ciphering algorithms can be configured by the phone manufacturer. So this is an area which should be investigated further.

[ /gsm | permanent link ]

Sun, 05 Sep 2010
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 ]

Sun, 15 Aug 2010
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 ]

Mon, 09 Aug 2010
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 ]

Tue, 03 Aug 2010
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 ]

Sun, 01 Aug 2010
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 ]

Sat, 31 Jul 2010
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 ]