Phones jumping ship from commercial networks to test network

[Mychaela Falconia]

Hello GSM community,

I have a question for those who operate their own GSM networks (be it
for fun or for research or for any other purpose) in places that DO
have regular commercial cell service, i.e., NOT ship-at-sea, middle of
desert or Rhizomatica-type environments: how do you deal with, and
ideally prevent, the highly undesirable situation of other people's
phones, not related to your operation, "jumping ship" from being
registered to their regular commercial network to trying to register
to your test network instead?

I live and operate in an area where ONE commercial operator still
provides GSM/2G service (although only to "grandfathered" customers,
closed to new subscribers), plus there are super-strong 4G and 5G
signals from all 3 USA-wide carriers.  I also operate my own "pirate"
GSM network on a test/experimental basis, meaning not always on, but
only turned on for brief intervals when I am playing with it.

When I do turn on my test GSM network, I squat on an ARFCN in the
middle of a 5 MHz wide "dead" spot (SA shows noise floor over the
whole 5 MHz block in question), and most of the time I set my power
output to the lowest possible setting: I set max_power_red to the
maximum of 20, which should result in 3 dBm output from the sysmoBTS
box.  I also recently changed my MCC-MNC from 310-222 (an unallocated
MNC within MCC 310) to 001-325 (MCC meaning test network, MNC is a
feeble attempt to indicate that it's me - I got 00440325 as my test
IMEI range in my "other" capacity as ME manuf), but the problematic
behaviour of at least some phones erratically "jumping ship" from
T-Mobile GSM to the test network still occurs.

Here is a concrete example of inexplicable erratic behaviour I am
seeing:

* Last night I powered up my test network at around 19:41 local time.
My wife was with me the whole evening; her primary personal phone is
Nokia C3-00 (circa 2011, late in GSM terms, but still 2G-only in terms
of RAN support) with service on T-Mobile.

* About 3.5 hours later, at around 23:14 local time, my wife noticed
that her phone "went into the black hole" (our term for times when
phones show "no service" even though T-Mobile GSM signal is there just
fine), and she alerted me.  I looked at OsmoCNI logs in syslog, and I
saw that just a little earlier, at around 22:38 local time, there was
an attempt from my wife's phone (her T-Mobile IMSI) to register to our
test network.  Of course that registration attempt failed - I don't
have a roaming agreement with T-Mobile, there is no MAP roaming support
in OsmoCNI, I don't have any T-Mobile or other operators' IMSIs in my
OsmoHLR, and I am NOT running with "create sub on demand" feature.

* At around 23:14 local time, when my wife noticed that her phone went
into the black hole, she immediately proceeded to reboot it - such
reflexive reboots are now an "autopilot" action for her - and on its
next boot cycle, it immediately proceeded to make another attempt to
register to our test network instead of T-Mobile, as evidenced by
OsmoCNI logs!

* At that point I turned off the test network GSM signal, as there did
not appear to be any other way to convince my wife's Nokia phone to go
back to its rightful network of T-Mobile.

Now let me add some noteworthy details:

* The ARFCN on which I squat for my test network is NOT listed in the
neighbor cell list advertised by the sole and single commercial GSM/2G
operator we have around here.

* When I mentioned this issue previously in an OsmoDevCall USSE, I was
asked if perhaps the ARFCN I squat on might be listed as a 2G neighbor
in the neighbor list of some newer-G cell.  I don't have any direct
way to disprove this idea, but my wife's phone, the one that exhibits
this inexplicable behaviour, is a 2G-only model, NOT supporting LTE or
even UMTS.  And the last 3G/UMTS service in our area was shut down
last summer, leaving only LTE+5G for the masses and GSM for the tiny
sliver of "grandfathered" users who won't give it up until we die.

* In last night's episode, my wife's phone sat quite happily within
our dwelling, mere meters from the sysmoBTS antenna putting out its
3 dBm, for almost 3 hours before it made its first attempt to jump
ship.  During the entirely of this almost-3-hours interval, the signal
from our test network as received by the phone was overwhelmingly
stronger than the commercial signal (being meters away from the BTS),
yet the phone behaved like it should (listened to its serving cell and
advertised neighbor cells, no searching around) for almost 3 h.

* The location update interval set by T-Mobile's network is 1 hour -
thus periodic LU could not have been the trigger that told Nokia's
bugger to abandon its serving cell and go into open-ended search of
all possible ARFCNs.  So what in the world could have been the trigger
then, that caused the bugger to misbehave after almost 3 hours of
behaving properly and correctly?

* Aside from whatever the trigger might be, once that Nokia bugger
attempts to register to the test GSM network and fails, why in the
bloody hell is it not going back to the weaker (in terms of RSSI) but
working T-Mobile network, why does it "park" itself in no-service
state instead?

I have heard of other people operating test GSM cells/networks in
areas where commercial services do exist: I have heard that Neels, of
Sysmocom team, operates a test cell under a test license, and when
Keith gave an OsmoDevCall presentation on Rhizomatica back in 2021,
that presentation was done from an office in some "big" city in Oaxaca,
a place where test signals had to coexist peacefully with commercial
operators' signals.  So how do you guys do it?  What additional magic
are you doing, which I must be missing, to prevent the situation of
phones jumping ship from commercial networks to the test network when
the signal from the test network is much stronger due to proximity?

Perplexed,
Mother Mychaela