Project

General

Profile

Bug #3395

Uplink CS/MCS control is broken osmo-pcu is used with osmo-bts-trx/osmo-trx

Added by ipse 11 months ago. Updated 24 days ago.

Status:
Stalled
Priority:
Urgent
Assignee:
Target version:
-
Start date:
07/14/2018
Due date:
% Done:

0%

Spec Reference:
TS 05.05

Description

Not sure which project to assign this to.

GprsMs::update_cs_ul() function (osmo-pcu/src/gprs_ms.cpp) is used to control the UL CS/MCS mode and in its current implementation is relies on the Quality "Q" value reported by L1. Osmo-trx does not really calculate the SNR of the link and thus osmo-bts-trx always report Q as 0. This misleads the current algorithm which always drops the CS/MCS to the lowest possible mode (CS-1/MCS-1).

Possible solutions I see:
1) Use another metric, like BER which are reported by osmo-bts-trx. A similar method is already used by the DL CS/MCS control.
2) Implement SNR calculation in osmo-trx. A better way, but much more involved.


Related issues

Related to OsmoBTS - Bug #1616: osmo-bts-trx / osmo-bts-octphy doesn't provide C/I information to PCU Stalled2016-02-23

Related to OsmoBTS - Bug #1855: provide actual BER or C/I values from osmo-bts-trx into the PCUNew2016-11-18

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

Related to OsmoPCU - Bug #3834: MS set_mode()/set_current_cs_*() inconsistent resultsNew2019-03-12

History

#1 Updated by laforge 10 months ago

this is not an osmo-pcu bug, but an osmo-bts-trx bug. It doesn't compute/fill-in all the values of the primitives at the PCU socket. See #1616 from two years ago, and #1855 from one year ago.

#2 Updated by laforge 10 months ago

  • Related to Bug #1616: osmo-bts-trx / osmo-bts-octphy doesn't provide C/I information to PCU added

#3 Updated by laforge 10 months ago

  • Related to Feature #1815: tool for building binary ipk from .list/.control added

#4 Updated by laforge 10 months ago

  • Related to deleted (Feature #1815: tool for building binary ipk from .list/.control)

#5 Updated by laforge 10 months ago

  • Related to Bug #1855: provide actual BER or C/I values from osmo-bts-trx into the PCU added

#6 Updated by laforge 10 months ago

on a more general notice, see https://osmocom.org/versions/122 for the various known issues of osmo-bts-trx compared with other osmo-bts-* variants.

#7 Updated by laforge 9 months ago

#8 Updated by laforge 9 months ago

#9 Updated by laforge 5 months ago

#10 Updated by laforge 5 months ago

#11 Updated by msuraev 4 months ago

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

#12 Updated by fixeria 4 months ago

  • Status changed from New to Feedback

2) Implement SNR calculation in osmo-trx. A better way, but much more involved.

A few days ago I did some research on this. As it turns out, OsmoTRX already does (AVG) noise measurements during IDLE frames, please see: https://git.osmocom.org/osmo-trx/tree/Transceiver52M/Transceiver.cpp#n627. After looking at debug output coming from Transceiver::logRxBurst(), I think that such noise measurements are being done correctly: in case of false-positive detections noise == rssi (that's expected), while the UL bursts coming from a MS have rssi > noise.

As far as I understand, we should attach noise level to every burst on TRXD (TRX Data interface) coming towards OsmoBTS. The problem is that the current version of TRX protocol is not flexible. A TRXD message (i.e. UL or DL burst) has a fixed header of fixed size, and there is no space left for noise level :/

As a possible solution, we can attach noise level at the end of TRXD messages - after the burst bits. OsmoTRX still does send two dummy (padding?) bytes at the end of UL TRXD messages (OsmoBTS just ignores them), so we can use one of them. But IMHO, this is more a hack than a proper solution. Ideally, we need a new version of TRX protocol, where we could use TLVs.

#13 Updated by msuraev 2 months ago

  • Related to Bug #3834: MS set_mode()/set_current_cs_*() inconsistent results added

#14 Updated by laforge about 1 month ago

  • Assignee set to lynxis

#15 Updated by laforge about 1 month ago

  • Priority changed from Normal to Urgent

#16 Updated by lynxis about 1 month ago

  • Spec Reference set to TS 05.05

#17 Updated by lynxis about 1 month ago

  • Status changed from Feedback to Stalled

#18 Updated by lynxis 24 days ago

  • Assignee changed from lynxis to tnt

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)