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/.
Alexander Chemeris alexander.chemeris at gmail.comHi 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.htm>