I guess we could still be using an older osmorelease... a major pain vector of mine ☹

Thank you for making MSCR changeable though. That will hopefully help, and if it doesn't I'll ask you to make a test change on the SI2quat which should liven up the UE actually using the information contained within it (which it currently ignores).

Since it's the MSC's release indicator, I somehow expected that the MSC tells the BSC about it over BSSMAP, but that doesn't seem to be the case. So then the BSC has to "guess"/know what the MSC is capable of.

osmo-bsc has an 'msc' section in its config, I would intuitively place this config in there, see osmo_bsc_vty.c. I would name the config option:

msc r99 no r99

or maybe

r99_or_later r98_or_earlier

(I think the first is nicer)

The question that remains for me is, does it make sense to set it per BTS instead? After all it is a system information setting, and assuming that all MSCs we encounter in the field will anyway be R99+ capable (?), the user might instead want to configure individual BTSes to advertise R98 for hacking reasons?

Assuming this is useful, my deeper question is: does it make sense at all to advertise an MSC as R98 when it is in fact R99, and without the MSC knowing about that? Would the MSC still encode things in R99 ways and the subscriber might be stunned by that?

Authentication: as soon as there are UMTS AKA tokens in osmo-hlr, osmo-msc will send an AUTN challenge. So a BTS might advertise R98 or earlier in SI, but the MSC still sends AUTN -- weird. Notably, since the MSC has no way to tell what the BSC's config for R99-ness is, the MSC can't switch that off per BTS.

I remember this bit of code: "#define gsm48_hdr_msg_type gsm48_hdr_msg_type_r99" in libosmocore/include/osmocom/gsm/protocol/gsm_04_08.h. Funnily enough both gsm48_hdr_msg_type_r99() and gsm48_hdr_msg_type_r98() appear to do the exact same thing, even though it looks slightly different on first sight. Whatever happened there...

But considering authentication, to me it makes sense to only set the bit according to what the MSC actually is capable of.So that brings me to conclude: add this configuration in the 'msc' section of osmo-bsc.cfg.

More questions asked by osmith in the WIP gerrit patch:

'How do I set the default to "1" instead of "0"?'

You have full control over the default config setting and whether/what the VTY outputs during 'write'.

So you see that you can choose to always output the vty config, or to choose "potato" as the default, or whatever.There are also various ways to shoot yourself in the foot, e.g. typos in vty_write() or outputting options that aren't parseable.That's why we have VTY tests that try to ensure we write config back in a parseable way. Point being that anything is possible.

Techincally in the BSC we still are able to maintain several different MSCs, and would select the MSC per subscriber.

However, the SI bits get sent to the BTS on OML bootstrapping; we could technically update the SI information also after the BTS has connected. But obviously we don't send different SI bits per subscriber, but per cell. That doesn't fit at all. So it doesn't even make sense to have separate MSCs with separate R99 capability, because there is no way to communicate that in a useful way.

So, on the one hand, it doesn't make sense to say "R98" in the SI when the MSC is in fact R99 -- i.e. set R99 per cell doesn't make sense.It also doesn't make sense to keep a per-MSC "R99" flag, because should we ever have differing MSCs on the same cell, that would be impossible to match.

The only thing I see making sense now is one single global R99 flag for the entire BSC.

So now I'm at

network
r98
r99

or maybe

network
release (r98|r99)

In the meantime laforge said "I think (R98|R99+) would be more user friendly" but the VTY will trigger on the capital R to interpret as a free-form value instead of a fixed token. So it has to be lower case, and not sure whether the + is allowed. If it is, then feel free to add it, like "release (r98-|r99+)"

So after all I'm saying to add a cfg_net_release command in bsc_vty.c.

From my perspective I am 100% happy to have NO option if we are definitely advertising as R99+. This whole line of enquiry started because of two things:

1) on my QualiPOC, the SI3 decoded message shows our osmoBTS as MSCR of R98. It is possible that the QualiPOC is wrong but on a commercial GSM cell it shows MSCR of R99 onwards..

2) we need SI2quat to function correctly and not one single UE we have ever tested honours the message - which means that:

the message is formatted wrongly (although it displays correctly on the QualiPOC).

one of the parameters is wrong so the message is never executed.

the MSCR release is such that the UE doesn't process the message because the system release is too old to support such functionality.

Given that my reference test handset tells me we're R98, it seemed that the latter was a definite possibility. I am happy to re-validate later this evening and will send some versions etc. as I am keen not to waste anyone's time.