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 ]
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 ]
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 ]
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 ]