Cellular Network Infrastructure » Radio Access Network » OsmoBSC

I looked at MSCR just now on my QualiPOC and it seemed to be declaring MSCR as R98 or older.

This is weird, we have 1 hardcoded in osmo_bsc_main.c right now:

/* Indicate R99 MSC in SI3 */
  bts->si_common.chan_desc.mscr = 1;

I'll implement that it can be changed with the vty configuration.

Pondering about this:

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'.

The pattern for any default value would be, in pseudocode:

#define FOO_DEFAULT_VAL tomato

void cfg_init(){
  cfg.foo = FOO_DEFAULT_VAL;
}

DEFUN("foo (tomato|potato)")
{
  cfg.foo = argv[0];
}

void foo_vty_write(){
  if (cfg.foo != FOO_DEFAULT_VAL)
    vty_out("foo %s%s", cfg.foo, VTY_NEWLINE);
}

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.

Argh, it is even more complex.

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.

s/small caps/lower case

osmith, I hope I'm making sense here, maybe run my conclusion by laforge if he has the time. (In practice I don't really understand why we need to advertise R98- at all.)

ant wrote:

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

It seems, that the R99+ advertising was added as part of #1593 in March of 2017.

neels wrote:

I hope I'm making sense here, maybe run my conclusion by laforge if he has the time. (In practice I don't really understand why we need to advertise R98- at all.)

Yes, it makes sense. Thank you very much for the detailed explanations.

laforge: do you still want this feature? what do you think about implementing the network-level setting that neels described above?

ant wrote:

I should be able to find out what we're using build-wise in the next two hours. Will update then.

any results? :)

@ant: did you have any success with querying the version?

Closing, as the usefulness of having this configurable is highly questionable as Neels stated.

It doesn't solve Anthony's problem either, upgrading to a new osmo-bsc version that advertises R99+ support would be the solution.