Cellular Network Infrastructure » Radio Access Network » OsmoBTS

{{>toc}}

h1. BER Testing

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

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.

There are multiple different approaches to do this

# tester-based (e.g. with R&S CMU-300)

#* test device generates blocks with PRBS in uplink

#* BTS loops back the blocks at the L1/L2 boundary

#* tester receives the blocks in downlink, correlates with transmitted uplink and computes BER

# BTS-based (if you don't have expensive test equipment)

#* network side generates blocks with PRBS in downlink

#* standard UE is used to loop back frames from downlink to uplink

#* network side receives the blocks from uplink, correlates with transmitted downlink and computes BER

h1. tester-based

The idea in this mode goes like this:

* establish a traffic channel between BTS and MS (== tester)

* activate special loopback mode *in the BTS*, looping back the received data to the MS (== tester) by means of the (hidden) @ts <0-0> trx <0-255> ts <0-7> (lchan|shadow-lchan) <0-7> loopback@ command of the @osmo-bts@ VTY.

h1. BTS-based

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

A tool to transmit PRS inside RTP and perform correlation + BER computation can be found in the @tnt/ber@ branch of osmo-bts at https://gitea.osmocom.org/cellular-infrastructure/osmo-bts/src/branch/tnt/ber - it contains a "README file":https://gitea.osmocom.org/cellular-infrastructure/osmo-bts/src/branch/tnt/ber/contrib/ber/README

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 or to 001-01 test 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>

h3. Tested phones

* K800i with TEMS firmware:

> * Loop works even without a 'test sim' (i.e. without the EF.AD file mod)

> * If the call gets disconnected, you will need to send an 'open-loop' command before you can use the 'close-loop' command again.

* Nokia 1661: Loop works but requires 'test sim'