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.

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.

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.

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 ;-)