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

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)