OsmoTRX / BER, RSSI and Link Quality

Alexander Chemeris alexander.chemeris at gmail.com
Thu Jul 7 05:19:23 UTC 2016


Hi Tom,

On Jul 7, 2016 7:58 AM, "Tom Tsou" <tom at tsou.cc> wrote:
>
> 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)

Why after CRC?

> 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.
>
> I think this is a reasonable approach to make the current BER measurement
sane.

Why do you think re-puncturing is not a good approach - because of the
added CPU load?

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

Sounds like a good approach.

Please excuse typos. Written with a touchscreen keyboard.

--
Regards,
Alexander Chemeris
CEO Fairwaves, Inc.
https://fairwaves.co
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20160707/9c1aed4a/attachment.html>


More information about the OpenBSC mailing list