osmo-bts-trx / osmo-bts-octphy doesn't provide C/I information to PCU
osmo-bts-trx doesn't pass singal quality information to the PCU socket, meaning that link/rate adaption will of course not work as it i supposed to.
#4 Updated by msuraev over 3 years ago
According to void GprsMs::update_cs_ul(const pcu_l1_meas *meas) in src/gprs_ms.cpp the switch to higher/lower CS depends only on link_qual value. Not sure if some spec covers which measurement is supposed to be used for link rate adaptation. Also, it's unclear yet how to convert the values available in particular BTS to be similar to what is reported by sysmobts.
#8 Updated by laforge over 3 years ago
TS 45.008 Annex D contains an "Example Selection of Modulation and Coding Schemes" for 8PSK EGPRS (MCS5-MCS9) based on CV_BEP and MEAN_BEP. Those two values should be reported by a BTS model to the PCU.
For classic GPRS or EGPRS with GMSK, I'm still looking to find similar reference values.
Chapter 8.2 of TS 45.008 contains information on how RxQual and CV_BEP / MEAN_BEP values are computed and encoded.
#9 Updated by laforge over 3 years ago
In genreal, it seems there are BLER and CIR (C/I) based schemes, and that C/I is generally perceived to be superior.
I think the parameters RxLev/Rssi, BER, RxQual (averaged BER) should be provided by ever PHY/L1 and thus be a good candidate for reporting measurements to the PCU for GPRS/GMSK. Plus CV_BEP and CV_MEAN for EGPRS/8PSK
- Category changed from osmo-bts-octphy to osmo-bts-trx
- Status changed from Stalled to Resolved
- Assignee set to fixeria
- % Done changed from 50 to 100
Please see https://gerrit.osmocom.org/r/Ia58043bd2381a4d34d604522e02899ae64ee0d26, which is now merged.