Hi Tom and List,
we're currently introducing some code that will make more use of measurement related information associated with the PH-RACH.req and PH-DATA.ind coming from the PHY up into L2.
The first part is to introduce a reasonable BER limit fo 17% for RACH ghost elimination, but I have more plans for unifying the measurement processing/generation accross all supported BTS models.
For osmo-bts-{sysmo,lc15,octphy} it is clear to me how to get the related information on RSSI, BER and LinkQuality for each of the RACH and DATA indications from the PHY.
However, how can I get the related information from osmo-bts-trx?
osmo-bts-trx seems to lack any BER reporting toward the common part, which among other things is the reason why link/rate adaption in the PCU can not work with it.
Could you sched some light on this?
Hi Harald,
On Tue, Jun 21, 2016 at 11:51 AM, Harald Welte laforge@gnumonks.org wrote:
The first part is to introduce a reasonable BER limit fo 17% for RACH ghost elimination, but I have more plans for unifying the measurement processing/generation accross all supported BTS models.
For osmo-bts-{sysmo,lc15,octphy} it is clear to me how to get the related information on RSSI, BER and LinkQuality for each of the RACH and DATA indications from the PHY.
However, how can I get the related information from osmo-bts-trx?
osmo-bts-trx seems to lack any BER reporting toward the common part, which among other things is the reason why link/rate adaption in the PCU can not work with it.
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.
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.
On Tue, Jun 21, 2016 at 11:36 AM, Alexander Chemeris alexander.chemeris@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
Hi Tom,
On Jul 7, 2016 7:58 AM, "Tom Tsou" tom@tsou.cc wrote:
On Tue, Jun 21, 2016 at 11:36 AM, Alexander Chemeris alexander.chemeris@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
On Wed, Jul 6, 2016 at 10:19 PM, Alexander Chemeris alexander.chemeris@gmail.com wrote:
On Jul 7, 2016 7:58 AM, "Tom Tsou" tom@tsou.cc wrote:
The full BER calculation takes the re-coded and re-punctured sequence (performed after decoding and CRC verification)
Why after CRC?
Assume that we lower the detection threshold in the TRX and allow the OsmoBTS to perform most of the burst gating based on the CRC. If we calculate BER before the CRC, then the BER will be computed mostly on garbage data.
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?
Yes, there is overhead. But, more simply, re-puncturing doesn't gain very much. If we increase the accuracy of our BER calculation by some fraction of a percent, will that really improve UE performance?
-TT
-
Alexander Chemeris -
Harald Welte -
Tom Tsou