Commit
2ab6dbd32b47d175137e11cd33866d20e0c479c3
by falconchange default reject cause to plmn-not-allowed
Unless the Osmocom-based network operator has very carefully
considered what they are doing, returning MM/GMM reject cause #2
(IMSI unknown in HLR) to LU requests from bystander phones is a
very bad idea. Here is what typically happens when someone sets
up an Osmocom-based GSM network for development, testing or
research, without roaming interconnection with any commercial
operators:
* Even when the private network operates its BTS at very low power
levels, bystander phones in close proximity (e.g., in directly
adjacent neighbor apartments or office suites) will receive a much
stronger signal from the private/test network BTS than from any
commercial operator, i.e., the private/test network will be
the strongest signal.
* Many phones will attempt to "jump ship" to this strongest signal
even if it broadcasts a completely unknown PLMN ID that is not in
the preferred operator list, and even when they were previously
not roaming at all, registered to their most preferred home operator
with perfectly good reception quality.
* If these wayward phones receive reject cause #2 in response to their
LU attempt, the spec effectively requires them to go into a "black
hole" where they no longer attempt to register to any operator,
including their own legitimate one.
Returning reject cause #11 instead (PLMN not allowed) solves this
problem: wayward phones that erroneously attempted to register to the
private/test network go back to their own legitimate commercial
operator, and everyone is happy.
This bug should be considered critical: when the reject cause is set
to #2 by default, any private Osmocom-based network, no matter how
low-power, will effectively cause service disruption to all nearby
commercially-served phones even when there is no clash in terms of
used radio frequencies.
Change-Id: Icff1d19670c398b119ec68b1d5f0fad87b605702