Bug #5895


LC15: Audio Quality Problem sometime after cf7a7fcebf625a14fd764355c3b96fa86c77458c

Added by keith about 1 year ago. Updated 11 months ago.

Target version:
Start date:
Due date:
% Done:


Spec Reference:


Writing this up now while it's a bit fresh...

I have spent the last 12 hours or so working with people on site to try to track down these problems:

Fierce complaints about audio quality (no audio, unintelligible, intermittent, chopped)

Observation of a lot of very variable Q in meas reps, especially on downlink (associated with bad audio) and more pronounced when the call B-leg was using another codec such as G.729 on the other side of the PBX, - in fact not transcoding at site and sending AMR to our data centre and trancoding there to PCMA/U for the upstream VoIP was giving better results most of the time.

However, today I discovered the extent of how bad this was on local MS to MS calls.

After exhausting everything I could think of, we went back to the timeline and there were some opinions that this started around a date last year which seemed to be around the time I changed this site away from osmo-nitb. Given I wasn't seeing any signalling problems, I had been looking for problems with maybe the MGW or something with RTP that would have changed. but I could find nothing.

Of course none of that was at fault, what happened was that along with the move to osmo-bsc, I built v1.4.0 of osmo-bts - I think not 1.5.0 because at the time 1.4.0 built against the libs I had on the BTS, anyway, going back to the binary I had built before from cf7a7fce "solves" the problem.

Given the current somewhat tense situation I don't envisage "test"-ing anything at this site for the time being so I can't exactly try to dissect between cf7a7fce and 1.4.0 not that it would be very easy to run each commit against a bunch of manual tests that annoy the local people, asking them to make calls to each other.

So what to do? Well note it at least. I don't have another lc15 to test on.
Maybe shout-out to the main devs who committed code that touched lc15 or common, (which seems to have to do with power control, interference measurements) to see if they have any ideas. My feeling is that something that was done is not happy on the LC15 PHY.

There's the chance that this was fixed since 1.4.0 or in another lib.

Trivia: cf7a7fce is the last commit that can do RSL/OML bring-up against osmo-nitb.. that's why that one.

Actions #1

Updated by keith about 1 year ago

  • Description updated (diff)
Actions #2

Updated by pespin about 1 year ago

Hi keith ,

which version of osmo-bsc are you running there to?

We have been indeed working a lot on power control loop improvements over the last 2 years as you already know, and indeed at some point in time some versions may have flaws.

The one which I think is worth looking at is the fact that we added support for C/I based control loop and we (I) decided to enable it by default, which turned out to be a bad decision on some backends like osmo-bts-trx. After a while, the C/I based control loop was disabled by default.

C/I based control loop was added in a bunch of commits around osmo-bts.git 0617afdb5f4c0e38e9576c82092517197fbe478a (after the commit you mentioned that broke stuff and before 1.4.0 afaict).
The C/I based control loop was later on disabled by default through osmo-bsc.git 90b689b577e65a49e3bd0a8f2a9a8cdf2ca2955c.

So maybe you have the C/I based control loop enabled and that's giving bad results? Though I'd expect the lc15 lower layers to provide good measurements. But perhaps we have a bug in lc15 backend where we don't pass the measurements correctly to upper layers.

Actions #3

Updated by keith about 1 year ago

Hi pespin Thanks for taking the time to look at it!

osmo-bsc is 75d9a5c3e3618b320f1812a603ab2a661fff6bc1 + a couple of personal patches (only related to LCLS)

I think it's probably not worth spending a lot of time on this. I don't know who else in the world is running a LC15 and as it is, I can run the pretty old commit I mentioned, which seems to be OK. In this site, Voice call is 100% priority, so anything that might help with PCU/data is taking a back seat. I wrote this ticket because I think it's good to have it out there, just in case, somebody else has a lc15 and finds a problem.

I also think this is a little more "weird" than just some C/I based power control loop. (that's UL only right?) It's hard for me to describe the audio artifact that is experienced. I also don't see anything unexpected in uplink power, at least not in the meas_reps. Did we do anything with DOWNLINK power control? per TS?

With the downlink, It's one of those things where a "sound (picture) is worth a thousand words". Unfortunately, if I capture RTP at the BTS, it doesn't sound like at the speaker on the phone, So i'd have to record at the MS. Possible I suppose, if I had a lc15.

wildy guessing, I'd assume somehow the DL power per TS is wrong, (if that is a thing), or the burst is on the wrong TS ~20% of the time, or some processing is affecting timing pushing data to the PHY. something like that.

I've gone through the (many) commits from there to now and I see a couple of things, like mem leaks, assuming they are not fixes to something introduced later, I might just cherry-pick whatever looks like it might be a good thing and run that. Or even just leave it at c7fa.

Actions #4

Updated by laforge 12 months ago

  • Priority changed from Normal to Low
Actions #5

Updated by fixeria 11 months ago

keith wrote:

Trivia: cf7a7fce is the last commit that can do RSL/OML bring-up against osmo-nitb.. that's why that one.

IMO, this problem itself deserves its own ticket. I also faced OML bootstrapping issues few months ago while trying to run recent osmo-bts against osmo-nitb (AFAIR, I wanted to quickly test something MNCC related). I guess what causing this is that openbsc does violate the OML specs. while recent osmo-bts expects the correct behavior from it. One idea to solve this would be adding configurable OML quirks...


Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)