Cellular Network Infrastructure » Distributed GSM

neels wrote:

So it would make sense to have a built-in scheme that definitely and always avoids CS vs. PS IND collisions.
We could simply assign even-numbered INDs to CS and odd INDs to PS.

This part is not as trivial as I thought at first. It is of course easy to make sure that a CS IND is always even and a PS IND is always odd, but what also plays into this is that the source_name also differs for MSC vs. SGSN.

Example: site A has 'MSC-A' and 'SGSN-A'.
My first idea would be to keep one table of known source_name entities, and apply the CS/PS bit after that.
This plays out as:

I get 2 and 5, where I would have liked to get 0 and 1.
It is not actually a problem that it starts with 2, so I am fine with geting 2 and 3.
But since SGSN-A has table index 2, I get 2 and 5.
Imagine every site always showing up with MSC and SGSN in sequence, then we would have

i.e. the cumulative effect of SGSN getting only every other table index + the separation makes us use only half the IND space by skipping every other IND, and actually upon IND number space wrapping, makes us wrap exactly back to the already used IND instead of those in-between: we use 2 and 6 for MSC, but never 0 or 4.

I would still like to separate CS and PS INDs for certain, though, yet not rely on the MSCs and SGSNs to always turn up nicely in sequence.
So I need separate tables for CS and PS.

(Separate tables allow using SQLite PRIMARY KEY autoincrement independently.)

found a way to have both in one table with disctinct indexes for each cn_domain,
with the benefit that the cn_domain is just a number, and arbitrary other cn_domains could be invented without needing to change the db scheme.

((We could use a separate cn_domain (OSMO_GSUP_CN_DOMAIN_NONE == 0) for those SendAuthInfo requests that failed to send a CN domain at all.
The benefit would be nil though -- I'm not going to <<1 another bit to assign actually half of all IND space for omitted CN domain indicators. Ok, nice feat but not useful unless we actually have more valid CN domains.))

CREATE TABLE ind (
       cn_domain INTEGER NOT NULL,
       -- 3G auth IND bucket to be used for this VLR, where IND = (idx << 1) + is_ps
       ind     INTEGER NOT NULL,
       -- VLR identification, usually the GSUP source_name
       vlr     TEXT NOT NULL,
       PRIMARY KEY(ind),
       UNIQUE (cn_domain, vlr)
);
insert into ind (cn_domain, ind, vlr) select $cn_domain, count(ind)*2+$cn_domain-1, $vlr from ind where cn_domain = $cn_domain;

meh, that looks nice because it directly shows the actually used IND, but leads to problems adding new entries as soon as one of them is removed from the middle. Separate tables may be necessary after all, unless I find something nifty to also cover that.

Another aspect is that we might like an IND to become re-used if it was deleted, instead of first wrapping around the entire number space.
So unless some SQL magic shows up that converges in finite time, we'll actually need to read all IND entries into RAM and handle all those constraints in C instead.

This does exactly what we want:

CREATE TABLE ind (
        cn_domain INTEGER NOT NULL,
        -- 3G auth IND bucket to be used for this VLR, where IND = (idx << 1) + cn_domain -1
        ind     INTEGER PRIMARY KEY,
        -- VLR identification, usually the GSUP source_name
        vlr     TEXT NOT NULL,
        UNIQUE (cn_domain, vlr)
);

insert into ind (cn_domain, ind, vlr)
SELECT  $cn_domain,
        CASE WHEN EXISTS(SELECT NULL from ind where cn_domain = $cn_domain LIMIT 1)
        THEN
                (
                SELECT ((ind + 2) - ((ind + 2)%2) + ($cn_domain-1))
                FROM    ind as mo WHERE   NOT EXISTS (SELECT NULL FROM ind as mi
                WHERE cn_domain = $cn_domain and mi.ind = ((mo.ind + 2) - ((mo.ind + 2)%2) + $cn_domain-1)) ORDER BY ind LIMIT 1
                )
        ELSE ($cn_domain-1)
        END ind
        , $vlr;

Patch is implemented and passes C tests. Next up is test in a live environment and verify that ttcn3 suite still passes.

Turns out that bit-shifting separation isn't such a great idea after all.
See https://osmocom.org/issues/4318#note-7

We do need some way or other of getting adjacent sites into distinct IND pools,
all of:
- CS and PS of the same site
- 4G and 23G of the same site
- physically adjacent separate sites.
By now I think my bit shifting idea is not a good one at all, because it
addresses only one of the above points. We need a solution for all of them.

Instead, I will roll back that complexity and use a simple incrementing IND across all VLR names.

https://gerrit.osmocom.org/c/osmo-hlr/+/16764

waiting for merge

merged

whoops sorry, this one is still waiting on gerrit

19.07.2021 "Change has been successfully rebased and submitted as 3f9d1977df0df33f69f0b23cd10a26afd551111d by laforge"