<p dir="ltr">Hi Tom,</p>
<p dir="ltr">On Jul 7, 2016 7:58 AM, "Tom Tsou" <tom@tsou.cc> wrote:<br>
><br>
> On Tue, Jun 21, 2016 at 11:36 AM, Alexander Chemeris<br>
> <<a href="mailto:alexander.chemeris@gmail.com">alexander.chemeris@gmail.com</a>> wrote:<br>
> > I introduced BER calculations in osmo-bts-trx some time ago for DATA,<br>
> > so the data is there - see gsm0503_coding.c, *_decode() functions. I<br>
> > also updated the code to pass this information to upper layers - see<br>
> > rx_tchf_fn(), rx_tchh_fn(), rx_pdtch_fn() in scheduler_trx.c. I tested<br>
> > that the data actually gets to measurement reports for TCH and SDDCH,<br>
> > but I don't remember if we tested this for GPRS. Are you sure it<br>
> > doesn't work with the current master? If so, it probably got broken<br>
> > during the rebase or after that.<br>
><br>
> Measurement reports do appear to be going out through<br>
> l1if_process_meas_res(), but the BER calculation is incorrect because<br>
> of puncturing, which is significant for higher CS/MCS values.<br>
><br>
> The full BER calculation takes the re-coded and re-punctured sequence<br>
> (performed after decoding and CRC verification)</p>
<p dir="ltr">Why after CRC? </p>
<p dir="ltr">> and compares to the<br>
> decision sliced receive sequence. But, the full calculation may be<br>
> unnecessary.<br>
><br>
> A close and simple approximation to the full BER calculation treats<br>
> all zero valued soft bits as punctured bits and removes them from the<br>
> calculation.<br>
><br>
> I think this is a reasonable approach to make the current BER measurement sane.</p>
<p dir="ltr">Why do you think re-puncturing is not a good approach - because of the added CPU load?</p>
<p dir="ltr">> > I didn't do that for RACH, because currently RACH gating is performed<br>
> > in osmo-trx and works pretty well as far as I can tell, so<br>
> > osmo-bts-trx gets RACH's which are valid with high probability.<br>
> ><br>
> > We can introduce an option to turn osmo-trx built-in RACH gating and<br>
> > rely on osmo-bts instead and then compare which one works better. That<br>
> > should be a minor change - I'm happy to implement this a bit later.<br>
><br>
> We will always have some level of burst gating in the TRX to remove<br>
> clearly invalid or unrecoverable bursts (e.g. unrealistic TOA values).<br>
> One option is to reduce the detection threshold close to zero so that<br>
> any 'reasonable' burst is passed. This seems like another reason to<br>
> add configurable burst threshold detection to osmo-bts-trx.</p>
<p dir="ltr">Sounds like a good approach.<br></p>
<p dir="ltr">Please excuse typos. Written with a touchscreen keyboard.</p>
<p dir="ltr">--<br>
Regards,<br>
Alexander Chemeris<br>
CEO Fairwaves, Inc.<br>
<a href="https://fairwaves.co">https://fairwaves.co</a></p>