Hi.
I'm working on http://projects.osmocom.org/issues/1616 and wonder about $subj.
In case of sysmobts, osmo-pcu obtain this data directly from DSP: * RSSI (dBm) * burst timing (in quarter of bits) * link quality (in dB) * BER
The first and last value seems to be easy from what I see in src/osmo-bts-trx/scheduler_trx.c What about burst timing (necessary to compute TA in the absence of PTCCH) and link quality (measure of C / I where C is carrier and I is interference power) - how can I compute those or some estimator to those values?
Burst timing is also passed from osmo-trx to osmo-bts, so should be trivial to pass through.
For C/I we need a comment from Thomas. Currently we don't have it on the osmo-trx interface and I'm not even sure we calculate it.
Please excuse typos. Written with a touchscreen keyboard.
-- Regards, Alexander Chemeris CEO Fairwaves, Inc. https://fairwaves.co
On Jul 29, 2016 12:59, "Max" msuraev@sysmocom.de wrote:
Hi.
I'm working on http://projects.osmocom.org/issues/1616 and wonder about $subj.
In case of sysmobts, osmo-pcu obtain this data directly from DSP:
- RSSI (dBm)
- burst timing (in quarter of bits)
- link quality (in dB)
- BER
The first and last value seems to be easy from what I see in src/osmo-bts-trx/scheduler_trx.c What about burst timing (necessary to compute TA in the absence of PTCCH) and link quality (measure of C / I where C is carrier and I is interference power) - how can I compute those or some estimator to those values?
-- Max Suraev msuraev@sysmocom.de http://www.sysmocom.de/ =======================================================================
- sysmocom - systems for mobile communications GmbH
- Alt-Moabit 93
- 10559 Berlin, Germany
- Sitz / Registered office: Berlin, HRB 134158 B
- Geschaeftsfuehrer / Managing Director: Harald Welte
On Fri, Jul 29, 2016 at 5:18 PM, Alexander Chemeris alexander.chemeris@gmail.com wrote:
Burst timing is also passed from osmo-trx to osmo-bts, so should be trivial to pass through.
Yes. I don't know where the TOA value ends up in osmo-bts, but the value is definitely carried per-burst on the socket interface.
For C/I we need a comment from Thomas. Currently we don't have it on the osmo-trx interface and I'm not even sure we calculate it.
We don't have C/I directly. We do have a running average 'noise' level (calculated channel power on non-active uplink slots) and the RSSI value. The channel noise is queried with the NOISELEV command. RSSI is carried per-burst on the socket message. C/I can be calculated from those two values.
Do we need a periodically averaged C/I value or an update every burst?
-TT
Hi Tom,
On Mon, Aug 01, 2016 at 03:57:36PM -0700, Tom Tsou wrote:
On Fri, Jul 29, 2016 at 5:18 PM, Alexander Chemeris alexander.chemeris@gmail.com wrote:
Burst timing is also passed from osmo-trx to osmo-bts, so should be trivial to pass through.
Yes. I don't know where the TOA value ends up in osmo-bts, but the value is definitely carried per-burst on the socket interface.
For C/I we need a comment from Thomas. Currently we don't have it on the osmo-trx interface and I'm not even sure we calculate it.
We don't have C/I directly. We do have a running average 'noise' level (calculated channel power on non-active uplink slots) and the RSSI value. The channel noise is queried with the NOISELEV command. RSSI is carried per-burst on the socket message. C/I can be calculated from those two values.
This long-time average noise level would make sens on a per-timeslot basis, or evne on a per-lchan basis once osmo-bts started to send uplink interference indications to the BSC (which currently it doesn't, on any BTS model).
Do we need a periodically averaged C/I value or an update every burst?
The background of this current question is GPRS, where an average over multiple blocks inside a timeslot is not useful, as the resources are scheduled fully dynamic.
So to me, averaging over more than the four bursts of one block seems to make sense only in the context of circuit-switched channels, where the dedicated channel of a single MS is averaged. But for GPRS, every block might be a different MS, and the interference into the specific dynamically allocated uplink blocks within the TBF might be completely different than for other blocks scheduled to other MS.
I'm assuming that one of the most common interference patterns in GSM/GPRS is from other networks/cells, which most commonly use frequency hopping, and thus the uplink interference from one block to another (on a non-hopping OsmoBTS) could be significantly different.
Literature describes GPRS link adation algorithms based on either CIR or BLER, so we should have both available in the PCU to play with different algorithms.
For EGPRS, the values we need to report into the PCU (specifically the link adaption) are MEAN_BEP and CV_BEP.
Regards, Harald
Please have a look at gerrit #623 - am I computing BER properly? I've tried to follow what's done for meas. ind. Also, how would you recommend to compute/estimate C/I? In the current patch version I'm just using 0.
On 08/02/2016 12:57 AM, Tom Tsou wrote:
On Fri, Jul 29, 2016 at 5:18 PM, Alexander Chemeris alexander.chemeris@gmail.com wrote:
Burst timing is also passed from osmo-trx to osmo-bts, so should be trivial to pass through.
Yes. I don't know where the TOA value ends up in osmo-bts, but the value is definitely carried per-burst on the socket interface.
For C/I we need a comment from Thomas. Currently we don't have it on the osmo-trx interface and I'm not even sure we calculate it.
We don't have C/I directly. We do have a running average 'noise' level (calculated channel power on non-active uplink slots) and the RSSI value. The channel noise is queried with the NOISELEV command. RSSI is carried per-burst on the socket message. C/I can be calculated from those two values.
Do we need a periodically averaged C/I value or an update every burst?
-TT
Calculation looks correct. Have you tested it? IIRC I added tests for BER calculations which you could extend.
-- Regards, Alexander Chemeris CEO Fairwaves, Inc. https://fairwaves.co
On Aug 4, 2016 19:18, "Max" msuraev@sysmocom.de wrote:
Please have a look at gerrit #623 - am I computing BER properly? I've tried to follow what's done for meas. ind. Also, how would you recommend to compute/estimate C/I? In the current patch version I'm just using 0.
On 08/02/2016 12:57 AM, Tom Tsou wrote:
On Fri, Jul 29, 2016 at 5:18 PM, Alexander Chemeris alexander.chemeris@gmail.com wrote:
Burst timing is also passed from osmo-trx to osmo-bts, so should be
trivial
to pass through.
Yes. I don't know where the TOA value ends up in osmo-bts, but the value is definitely carried per-burst on the socket interface.
For C/I we need a comment from Thomas. Currently we don't have it on the osmo-trx interface and I'm not even sure we calculate it.
We don't have C/I directly. We do have a running average 'noise' level (calculated channel power on non-active uplink slots) and the RSSI value. The channel noise is queried with the NOISELEV command. RSSI is carried per-burst on the socket message. C/I can be calculated from those two values.
Do we need a periodically averaged C/I value or an update every burst?
-TT
-- Max Suraev msuraev@sysmocom.de http://www.sysmocom.de/ =======================================================================
- sysmocom - systems for mobile communications GmbH
- Alt-Moabit 93
- 10559 Berlin, Germany
- Sitz / Registered office: Berlin, HRB 134158 B
- Geschaeftsfuehrer / Managing Director: Harald Welte
-
Alexander Chemeris -
Harald Welte -
Max -
Tom Tsou