Cellular Network Infrastructure » Radio Access Network » OsmoBTS

h1. BER Testing

This page is a work-in-progress about the upcoming BER (Bit Error Rate) testing infrastructure in OsmoBTS.

The goal here is to perform Receiver BER testing of the BTS uplink receiver, in line with the the conformance testing requirements for GSM base stations, but in a way that should work for all the hardware supported by OsmoBTS, as well as with as minimal as possible requirements in terms of test equipment.

The idea roughly goes like this:

* establish a traffic channel between BTS and MS

* activate a special "loop" mode in the MS, looping back the received bits 1:1 to the BTS

* add some RF impairment in the uplink, such as path loss, RF channel/fading simulator, ...

* transmit PRBS inside RTP stream to BTS

* receive looped PRBS back via RTP stream from BTS

* correlate transmitted with received PRBS; compute BER/RBER

h2. What to measure

h3. FER (Frame Erasure Rate)

* every frame with invalid CRC is dropped

* FER can be displayed right from BTS for each lchan

h3. RBER (Residual Bit Error Rate)

* computed on those bits not protected by CRC

* we assume transmitter uses one of the ITU pseudo-random sequences

* we can compare received bits against PNR sequence, sync to it and then compute the RBER from that

* using RTP frames for this seems most natural, given that they are already exported and in a standardized format

** doesn't work for PDTCH, special mode required (via PCU socket?)

* transmitting single 1-bit at given bit positions can help with bit re-ordering and the like

h2. What's required to be different from a normal call

h3. A phone that can loop the TCH

3GPP TS 44.014 specifies a special TCH loop mode inside MS.  In fact, not just one type of loop, but different types of loops.

It's unknown if all MS support this, but at least a Sony/Ericsson K800i supports it.

What's requires is a special "flag" on the SIM card.  The point of this is probably to make sure that this doesn't accidentially get activated in production networks.

h3. Indefinite radio link timeout

Normally, when the uplink is subject to many bit-errors, the BTS will at some point close the channel (T200 expired N200+1 times).  We need to circumvent this for testing, as the test should not be aborted even if there is a lot of BER.

In [[osmobsc:|OsmoBSC]] from version 1.0.1 we implemented this using the @radio-link-timeout infinite@ VTY command.  *DO NOT USE THIS IN PRODUCTION NETWORKS*

h3. Activation of a given timeslot/channel in a given mode

The VTY command @bts <0-255> trx <0-255> timeslot <0-7> sub-slot <0-7> (activate|deactivate) (hr|fr|efr|amr) [<0-7>]@ was introduced to [[osmobsc:|OsmoBSC]] from version 1.0.1 to achieve this manual activation.  However, it is a "blind" activation without any associated paging etc.  and hence not 1:1 suited for this approach.  It was implemented for an external signal generator that would be informed out-of-band to use the given timeslot/sub-slot, without any IMMEDIATE ASSIGNMENT or other L3 siganlling.

h2. Misc notes, unsorted

h3. Preparing a SIM card for activating the traffic loops in a MS

Basically you have to authenticate to the card using the proper ADM1 PIN of your card, and then modify the EF.AD file. The ADM1 in the below example will of course only work for the one particular card I used while doing this experiment.

<pre>

# auth with ADM1

0020000A083939343631353334

# update EF.AD (after auth with ADM1)

00d60000048000ff02

</pre>

Interesting by-product:

* K800i will no longer roam but only register to home network!

h3. closing the actual loop in an active TCH

<pre>

subscriber imsi 262423203000003 silent-call start tch/f

subscriber imsi 262423203000003 ms-test close-loop a

<0002> gsm_04_14.c:129 FIXME: Received TEST class message 'CLOSE_TCH_LOOP_ACK'

</pre>