Project

General

Profile

Actions

BER Testing » History » Revision 5

« Previous | Revision 5/8 (diff) | Next »
laforge, 01/21/2019 05:07 PM


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

What to measure

FER (Frame Erasure Rate)

  • every frame with invalid CRC is dropped
  • FER can be displayed right from BTS for each lchan

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

What's required to be different from a normal call

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.

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 from version 1.0.1 we implemented this using the radio-link-timeout infinite VTY command. DO NOT USE THIS IN PRODUCTION NETWORKS

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

Misc notes, unsorted

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.

# auth with ADM1
0020000A083939343631353334
# update EF.AD (after auth with ADM1)
00d60000048000ff02
Interesting by-product:
  • K800i will no longer roam but only register to home network!

closing the actual loop in an active TCH

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'
Files (0)

Updated by laforge about 5 years ago · 5 revisions

Add picture from clipboard (Maximum size: 48.8 MB)