Cellular Network Infrastructure » Radio Access Network » OsmoBTS

From a private conversation:

fixeria wrote:

there are some errors reported in osmo-bts.log when activate-all-lchan' command is sent

this is expected, because the BTS does not receive valid Uplink bursts on active channels. Instead, osmo-trx sends NOPE indications to osmo bts-trx, and some of them trigger Viterbi decoder. We can probably think about a possibility to suppress those NOTICE messages as they fill up systemd-journal quite quickly, but I don't see an easy way. AFAIK, there is no way to tell the BTS whether a given Channel Activation is for load testing or for normal subscriber connection.

• bad uplink radio channel and lack of uplink bursts are pretty normal in any real-world deployment, imagine
  somebody going into the basement while having a call. So it's questionable whether such behavior should
  trigger any logging at all, at leats not on a per-burst or per-frame level. One can see the bad
  RxLev/RxQual in measurements every 480ms, or maybe we can log the radio link timeout, but those happen at
  very high intervals and won't spam the logs.
• our old discussion whether or not to introdcue log rate limiting
• the possibility to represent such problems with error / rate counters, rather than log lines

https://gerrit.osmocom.org/c/osmo-bts/+/25270 osmo-bts-trx: add rate counter for Uplink block decoding errors [NEW]
https://gerrit.osmocom.org/c/osmo-bts/+/25271 osmo-bts-trx: use LOGL_DEBUG for Uplink block decoding errors [NEW]

fixeria wrote in #note-3:

https://gerrit.osmocom.org/c/osmo-bts/+/25270 osmo-bts-trx: add rate counter for Uplink block decoding errors [NEW]
https://gerrit.osmocom.org/c/osmo-bts/+/25271 osmo-bts-trx: use LOGL_DEBUG for Uplink block decoding errors [NEW]

patches are outdated and lacking review. Marking thicket as stalled. Would proably be good to get it solved.