Bug #4319
Updated by neels over 4 years ago
Each VLR requesting auth tuples should use a distinct IND bucket for 3G auth.
Currently we do that by assigning a different IND to each connected client.
Since MSC and SGSN for a given subscriber are two distinct GSUP peers, they will end up using distinct INDs.
However, in a distributed setup, a roaming subscriber has one direct GSUP peer proxying for both remote MSC and SGSN.
That means as soon as a subscriber roams to a different site, the site's MSC and SGSN compete for the same IND bucket and waste SQNs rapidly.
So instead of using the local client as IND, we need to keep a list of VLR names and assign a different IND to each.
Then we use the GSUP source_name as indicator, which reflects the actual remote VLR's name.
Hence MSC and SGSN will be distinct INDs also for remote sites.
This could be done in-mem like now, but would also be better to persist in the database.
In #4305, there is a discussion about IND collisions across remote sites.
The discussion goes about how often per day a subscriber is likely to pass between sites that have identical INDs set.
When thinking about MSC vs SGSN INDs, however, an IND collision would be far worse, because each and every CS and PS Complete-Layer-3 would waste SQNs and load osmo-hlr to generate auth all the time.
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.
Related: #4318: indicate the CN-Domain in GSUP SendAuthInfo Requests
