Project

General

Profile

Actions

Bug #3032

closed

(Wrong?) measurement of both RSSI and ToA on TCH channels

Added by fixeria about 6 years ago. Updated over 3 years ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
osmo-bts-trx
Target version:
-
Start date:
03/05/2018
Due date:
% Done:

100%

Spec Reference:

Description

Unlike xCCH and PDTCH, where we measure both RSSI and ToA values for each burst:

// ...

/* update mask + RSSI */
*mask |= (1 << bid);
*rssi_sum += rssi;
(*rssi_num)++;
*toa256_sum += toa256;
(*toa_num)++;

// ...

/* Send uplink measurement information to L2 */
l1if_process_meas_res(l1t->trx, tn, *first_fn,
    trx_chan_desc[chan].chan_nr | tn, n_errors, n_bits_total,
    *rssi_sum / *rssi_num, *toa256_sum / *toa_num);

ber10k = compute_ber10k(n_bits_total, n_errors);
return _sched_compose_ph_data_ind(l1t, tn, *first_fn, chan,
    l2, l2_len,
    *rssi_sum / *rssi_num,
    4 * (*toa256_sum) / *toa_num, 0, ber10k,
    PRES_INFO_UNKNOWN);

// ...

both TCH/F and TCH/H are currently sending the measurements for the last burst:

// ...

/* Send uplink measurement information to L2 */
l1if_process_meas_res(l1t->trx, tn, *first_fn,
    trx_chan_desc[chan].chan_nr|tn, n_errors, n_bits_total,
    rssi, toa256);

// ...

/* FACCH */
_sched_compose_ph_data_ind(l1t, tn,
    (fn + GSM_HYPERFRAME - 7) % GSM_HYPERFRAME, chan,
    tch_data + amr, GSM_MACBLOCK_LEN,
    rssi, 4 * toa256,
    0, ber10k, PRES_INFO_UNKNOWN);

// ...

return _sched_compose_tch_ind(l1t, tn,
    (fn + GSM_HYPERFRAME - 7) % GSM_HYPERFRAME,
    chan, tch_data, rc);

Moreover, in case of FACCH carried on a TCH/H channel the ToA256 is
for some reason devided by 64, while in case of TCH/F it's passed as is:

/* TCH/F FACCH */
_sched_compose_ph_data_ind(l1t, tn,
    (fn + GSM_HYPERFRAME - 7) % GSM_HYPERFRAME, chan,
    tch_data + amr, GSM_MACBLOCK_LEN,
    rssi, 4 * toa256,
    0, ber10k, PRES_INFO_UNKNOWN);

/* TCH/H FACCH */
_sched_compose_ph_data_ind(l1t, tn,
    (fn + GSM_HYPERFRAME - 10 - ((fn % 26) >= 19)) % GSM_HYPERFRAME,
    chan, tch_data + amr, GSM_MACBLOCK_LEN,
    rssi, toa256/64,
    0, ber10k, PRES_INFO_UNKNOWN);

And finally, on TCH channels we only attach the measurements to
FACCH indications, while speech frames don't have such info:

/* TCH/F FACCH */
_sched_compose_ph_data_ind(l1t, tn,
    (fn + GSM_HYPERFRAME - 7) % GSM_HYPERFRAME, chan,
    tch_data + amr, GSM_MACBLOCK_LEN,
    rssi, 4 * toa256,
    0, ber10k, PRES_INFO_UNKNOWN);

// ...

/* TCH/F speech frame */
return _sched_compose_tch_ind(l1t, tn,
    (fn + GSM_HYPERFRAME - 7) % GSM_HYPERFRAME,
    chan, tch_data, rc);

I wish I could resolve this issue myself, but I didn't find anything
in GSM specifications about the BTS side measurement process...

According to the GSM TS 05.03, a single TCH/F frame is mapped over
8 bursts, while a TCH/H frame is mapped over 6 bursts. This should
be taken into account.

Any ideas are welcome.


Related issues

Related to OsmoBTS - Feature #2977: OsmoBTS measurment processing at L1SAP too complex / pass measurements along with dataStalleddexter02/21/2018

Actions
Related to OsmoBTS - Bug #2329: frequent "no space for uplink measurement" messageResolveddexter06/18/2017

Actions
Actions #1

Updated by laforge about 6 years ago

  • Assignee set to fixeria

Hi fixeria,

the measurement processing is specified in TS 48.058 4.5 ("The averaging period
is one SACCH block period (same as the basic period for MS)."

We implement "basic measurement reporting" only, not the not-fully-specified pre-processed measurement reporting.

This means that we are averaging all ToA and RSSI information over the period of one SACCH multiframe, which is 480ms. For that we use all the measurement information passed up on L1SAP for that lchan.

So the question is if the input values to this (reported at each block on l1sap) should already be the averages over the four bursts comprising the block? I think yes. After all, we don't want the average of short samples, but the average over all bursts in the SACCH multiframe.

Actions #2

Updated by laforge about 6 years ago

As a side-note, I think the entire handling of measurements across L1SAP is currently too complicated, I will add it as a 'related issue' here. Ideally, we should attach all measurement information in the best resolution (ber10k, toa256, rssi) to the PH-DATA.ind and remove the somwhat strange INFO-IND that we use separately at the moment. After all, we have the following cases:

  • measurements only, no valid data: Use PH-DATA.ind with zero-length payload (bad frame)
  • measurements + data: Use fully filled-in PH-DATA.ind
  • data without measurements: doesn't exist, doesn't make sense to support (but theoretically possible now).
Actions #3

Updated by laforge about 6 years ago

  • Related to Feature #2977: OsmoBTS measurment processing at L1SAP too complex / pass measurements along with data added
Actions #4

Updated by fixeria about 6 years ago

  • Related to Bug #2329: frequent "no space for uplink measurement" message added
Actions #5

Updated by laforge over 5 years ago

  • Assignee changed from fixeria to tnt
Actions #6

Updated by laforge over 5 years ago

  • Priority changed from Normal to High
Actions #7

Updated by laforge over 3 years ago

  • Assignee changed from tnt to dexter

I would argue that #2977 should address this?

fixeria, can we close this issue?

Actions #8

Updated by fixeria over 3 years ago

fixeria, can we close this issue?

No, I don't think so. dexter implemented proper RSSI handling:

https://gerrit.osmocom.org/c/osmo-bts/+/18035 scheduler_trx: fix RSSI calculation for SUB frames

but other measurements are still handled in a wrong way. That was the reason of my CR-1.

I suggested to help with rebasing this change and making it handle the other measurements during the last weekly review, but did not get any concrete answer. I also don't like the idea of doing memcpy() in this change - we should use a ring buffer instead. Shall I take this ticket over?

Actions #9

Updated by laforge over 3 years ago

On Sun, Jun 21, 2020 at 03:22:52PM +0000, fixeria [REDMINE] wrote:

I suggested to help with rebasing this change and making it handle the other measurements during the last weekly review, but did not get any concrete answer.

I (and I think dexter, too) understood your comment as "i will take care of it". Sorry for not
acknowledging that explicitly. Thanks for your assistance!

Shall I take this ticket over?

at least take over rebasing the patch, not sure if there are other things required beyond that
in the context of this ticket, i.e. if that patch alone will fix all of it?

Actions #10

Updated by fixeria over 3 years ago

  • Status changed from New to In Progress
  • Assignee changed from dexter to fixeria
Actions #11

Updated by fixeria over 3 years ago

  • Status changed from In Progress to Feedback
  • % Done changed from 0 to 90

Please see:

https://gerrit.osmocom.org/c/osmo-bts/+/18972/ osmo-bts-trx/scheduler: get rid of unused 'meas' in l1sched_chan_state
https://gerrit.osmocom.org/c/osmo-bts/+/18973/ osmo-bts-trx/scheduler: refactor UL burst measurement processing

Actions #12

Updated by fixeria over 3 years ago

  • Status changed from Feedback to Stalled

The only missing part is unit tests requested by laforge during code review. I'll come back to this task as soon as I finish other ones with higher priority.

Actions #13

Updated by fixeria over 3 years ago

  • Status changed from Stalled to Resolved
  • % Done changed from 90 to 100

As it turned out, adding unit tests for low-level burst processing is not trivial, so it has been merged as is.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)