Cellular Network Infrastructure » Core Network (CN) » OsmoHNBGW

I think we are moving too fast in rolling a backport release for this issue.

• customer reports pcap with two RAB Assignments -- it's the first time we see this anywhere.
• to understand the report, i wrote a ttcn3 test to model that situation.
• the particular customer is apt with compiling code, so i provide a patch for testing the particular situation.
• ever since, the customer has no more duplicated RAB Assignments, suddenly everything is as it usually was, so we have not seen a report of the patch working as intended.
• but now, these two patches are on gerrit and were merged -- maybe a bit quick but ok, shouldn't be harmful.
• because our 'latest' test suite is not independent from 'master', the new test obviously fails 'latest'.

I think this causal chain is not one that warrants a release, it feels too quick. I think we should just wait a little for the patch to settle, because whatever we release will have to be maintained "forever".

Personally, I would just accept that 'latest' fails on the new test.
If there are sentiments against that, maybe we should then disable the new test in the 'latest' test suite?
But whatever it is, let's try to stay low on the effort spent on this rather small corner case.

Does that sound acceptable?

On Mon, Nov 13, 2023 at 10:43:45PM +0000, neels wrote:

• ever since, the customer has no more duplicated RAB Assignments, suddenly everything is as it usually was, so we have not seen a report of the patch working as intended.

Additional RAB assignment can very well relate to very specific usage patterns (either in terms of whihc
specific UE, or which specific services are used by the user). Could be related to multiple voice calls active concurrently, or video calls, or whatever. So it's not unlikely that you'd see those only in very specific situations.

Personally, I would just accept that 'latest' fails on the new test.

fine with me until we [decide to] backport.

Additional RAB assignment can very well relate to very specific usage patterns (either in terms of whihc

(In this particular case, it was modifying an existing RAB ID rather than adding a new RAB ID,
only listing SDU subflows and no transportLayerInformation (ip:port), so I guessed it would seen regularly)