Cellular Network Infrastructure » Core Network (CN) » OsmoHLR

There is some suggestion in https://gerrit.osmocom.org/c/osmo-hlr/+/16808 that osmo-hlr could use some criteria to decide what cause/reason to send to the GSUP client when rejecting a Location/Routing Update

Could you please quote the part of interest here? That patch is a lot to read...

Possibly, sending "IMSI Unknown in HLR" is wrong when the SIM is foreign to our network.

It sounds right to me though.

Could you provide a definition, like a table or bullet points indicating what
cause values should be sent in which cases? To better understand the aim.

Thanks!

Or maybe a GSUP client like osmo-msc can comunicate MNC-MCC info from the MSC network config over GSUP?

Hmm, I could have sworn that osmo-msc sends the PLMN and current LAC to
osmo-hlr via GSUP, but in fact i can't find any such thing in GSUP.

neels wrote in #note-1:

There is some suggestion in https://gerrit.osmocom.org/c/osmo-hlr/+/16808 that osmo-hlr could use some criteria to decide what cause/reason to send to the GSUP client when rejecting a Location/Routing Update

Could you please quote the part of interest here? That patch is a lot to read...

Yes, it is quite a lot, but also difficult to summarize the discussion that went on. The below is incomplete:

me: "If I reject an MS because no HLR responds to a distributed request for a home HLR; this may have happened because, 1) there is no home HLR or 2) the home HLR was offline/unreachable at the moment of the LUR."

pespin: "If you have a specific case in dGSM where you'd like to change the returned cause based on case "1" or "2" you described, that should be done in the code automatically without need for the user to configure it.
I'd like to hear motivations from lynxis too regarding this patch."

lynxix: "My motivation is for c3 events. The problem here lies in the spec. There isn't the case, you're doing a small network outside of the 3GPP network. For c3 events we want to tell other SIM (normal operator) just roaming-not-allowed here. Because we will never reach their HLR. IMHO: Unknown-in-HLR is just wrong for foreign sim cards. In the best case we would have a regex to tell our HLR what are valid ranges for our simcards. Return Roaming-not-allowed for everything what not matches our regex and if it matches our regex but not in our return Unknown-in-HLR."

Possibly, sending "IMSI Unknown in HLR" is wrong when the SIM is foreign to our network.

It sounds right to me though.

Could you provide a definition, like a table or bullet points indicating what
cause values should be sent in which cases? To better understand the aim.

I actually don't know what cause values should be sent, if indeed there exists a value that should be sent.
What I observed was that "IMSI Unknown in HLR" results in continued attempts to attach to the network.

From gerrit:

me: "In the first case, I guess I would like the phone to go away and never LUR again, (at least until T3245 expires), in the second case, I might like it to try again rather soon. Now, as I said, accord the the spec i mentioned above, if I were to send a cause 2 "IMSI unknown in HLR" - which is the current default, I would expect: "The mobile station shall set the update status to ROAMING NOT ALLOWED (and store it in the SIM/USIM and delete any TMSI, stored LAI.... [etc] consider the SIM/USIM as invalid for non-GPRS services until switch-off or the SIM/USIM is removed or the timer T3245 expires as described in subclause 4.1.1.6."

However, All the ME I tried DON'T do this, but rather they try again every 20 seconds up to 8 times and then continuously on what seems like the T3212 timer. However, with cause 13 the ME seems to NOT retry in the cell again, at least not immediately. Anyway, seems like one might like to do some trial and error with one's own situation in this...."

Thanks!

Or maybe a GSUP client like osmo-msc can comunicate MNC-MCC info from the MSC network config over GSUP?

Hmm, I could have sworn that osmo-msc sends the PLMN and current LAC to
osmo-hlr via GSUP, but in fact i can't find any such thing in GSUP.

Also note: T3245 doesn't seem to be mandatory. If you read 24.008 4.1.1.6 it seays "applies for an MS that is configured to use timer T3245 (see 3GPP TS 24.368 [135] or
3GPP TS 31.102 [112])".

• 24.368 is something LTE NAS specific, not applicable in pure 2G/3G networks
• the reference to 31.102 (USIM spec) refers to EF.NASCONFIG, a rather new, optional (intrudocued with 4G/LTE) file which could contain a TLV enabling T3245.
• the default for T3245 is disabled. This means it is never started, and hence never expires, and hence the MS/UE should never come back unless power cycled or USIM is removed.

The implementation reality can of course be completely different. Just summarizing the spec situation here.

neels wrote in #note-1:

Or maybe a GSUP client like osmo-msc can comunicate MNC-MCC info from the MSC network config over GSUP?

Hmm, I could have sworn that osmo-msc sends the PLMN and current LAC to
osmo-hlr via GSUP, but in fact i can't find any such thing in GSUP.

If we look at MAP as a general model, the UpdateLocationReq can contain a PagingArea which is a sequence of 1..5 LocationAreas. So we might use that as a vehicle to convey the Location Area to the HLR.

In commercial/public networks, I presume the VLR number (Global Title) is used to identify the visited MCC/MNC. This is a E.164 country code / NDC which needs to be converted to E.212 MCC/MNC first. See TS 29.002 8.1.2.3:

roaming not allowed;
This cause will be sent if the MS is not allowed to roam into the PLMN indicated by the VLR number. The cause is qualified by the roaming restriction reason "PLMN Not Allowed", "Supported RAT Types Not Allowed" or "Operator Determined Barring". If no qualification is received (HLR with MAP Version 1), "PLMN Not Allowed" is taken as default.

Not really an option in our global-title-less GSUP protocol.