Project

General

Profile

Actions

Feature #5865

open

Automate selection of LU Reject Cause

Added by keith 7 days ago. Updated 2 days ago.

Status:
New
Priority:
Low
Assignee:
Osmocom CNI Developers
Target version:
-
Start date:
01/20/2023
Due date:
% Done:

0%

Spec Reference:

Description

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

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

We could have a regex config option to let osmo-hlr know what is "our" SIM or not. Or maybe a GSUP client like osmo-msc can comunicate MNC-MCC info from the MSC network config over GSUP? I'm not familiar with GSUP.

Actions #1

Updated by neels 5 days ago

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.

Actions #2

Updated by keith 2 days ago

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.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)