OsmoTRX / BER, RSSI and Link Quality

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Tom Tsou tom at tsou.cc
Thu Jul 7 04:58:33 UTC 2016


On Tue, Jun 21, 2016 at 11:36 AM, Alexander Chemeris
<alexander.chemeris at gmail.com> wrote:
> I introduced BER calculations in osmo-bts-trx some time ago for DATA,
> so the data is there - see gsm0503_coding.c, *_decode() functions. I
> also updated the code to pass this information to upper layers - see
> rx_tchf_fn(), rx_tchh_fn(), rx_pdtch_fn() in scheduler_trx.c. I tested
> that the data actually gets to measurement reports for TCH and SDDCH,
> but I don't remember if we tested this for GPRS. Are you sure it
> doesn't work with the current master? If so, it probably got broken
> during the rebase or after that.

Measurement reports do appear to be going out through
l1if_process_meas_res(), but the BER calculation is incorrect because
of puncturing, which is significant for higher CS/MCS values.

The full BER calculation takes the re-coded and re-punctured sequence
(performed after decoding and CRC verification) and compares to the
decision sliced receive sequence. But, the full calculation may be
unnecessary.

A close and simple approximation to the full BER calculation treats
all zero valued soft bits as punctured bits and removes them from the
calculation.

@@ -509,6 +509,8 @@ int osmo_conv_decode_ber(const struct osmo_conv_code
        if (n_errors) {
                *n_errors = 0;
                for (i=0; i< *n_bits_total; i++) {
+                       if (!input[i])
+                               continue;
                        if (! ((recoded[i] && input[i]<0) ||
                               (!recoded[i] && input[i]>0)) )
                                *n_errors += 1;

I think this is a reasonable approach to make the current BER measurement sane.

> I didn't do that for RACH, because currently RACH gating is performed
> in osmo-trx and works pretty well as far as I can tell, so
> osmo-bts-trx gets RACH's which are valid with high probability.
>
> We can introduce an option to turn osmo-trx built-in RACH gating and
> rely on osmo-bts instead and then compare which one works better. That
> should be a minor change - I'm happy to implement this a bit later.

We will always have some level of burst gating in the TRX to remove
clearly invalid or unrecoverable bursts (e.g. unrealistic TOA values).
One option is to reduce the detection threshold close to zero so that
any 'reasonable' burst is passed. This seems like another reason to
add configurable burst threshold detection to osmo-bts-trx.

  -TT



More information about the OpenBSC mailing list