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

       
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 ]