Cellular Network Infrastructure

Various patches have already been merged for libosmocore, osmo-bsc, osmo-msc, osmo-iuh.
Still pending are osmo-bts, osmo-pcu, osmo-sgsn (manually testing now) -- the osmo-sgsn patches also require some testing for gb-proxy.
All of the above should also see some ttcn3 tests for leading-zero three-digit MNC.

manual test with CS and PS (on 2G) verifies successful subscription on a 901-070 network complete LU, CM-Service, Paging, GMM Attach, data access, ...
The phones explicitly list the network as 901070 (as opposed to the SIM-cards' "native" 90170 net).

The only instances of PLMN other than 901-070 I can find are:

• the SIM indicating its "home PLMN" in the LU Request as 901-70 == 0x09f107, which is correct; the network "overrules" that with its 0x090170 returned subsequently.
• a curious instance of a samsung app calling home and including mnc=70:
  "GET /product/appCheck.as?appInfo=com.sec.android.app.sbrowser@1.5.28x%x%deviceId=GT-I9195&mcc=901&mnc=70&csc=DTM&openApi=19&pd= HTTP/1.1\r\n"
• the IMSI digits "90170000..." interpreted by wireshark as "901-700".

All proper protocols, GPRS-NS, MM, GMM, RSL, what-have-you, consistently pass around 901-070 (i.e. 0x090170) where they should.

I should note that for testing I have applied the PCU reverts
https://gerrit.osmocom.org/6976 thru 6979 (see #3013)
and an osmo-bsc patch disabling the conn_loss_counter in a_iface.c by a brute #if 0 (see #3041)

the sgsn patch is the only one not merged yet, pending testing of the gb-proxy part. The sgsn part of the patch has been tested manually along with the pcu patch; a formal ttcn3 test for it is planned, and there should probably also be mnc3 tests for the bts and bsc in ttcn3... So to be able to merge the sgsn patch I at least need to manually test mnc3 in the gb-proxy (and promise to follow up with ttcn3 tests).

I was going to do that, but actually at least one function that needs changes for the sgsn is also used by gb-proxy. I'll rather test gb-proxy and commit together.

just verified with manual testing that the gbproxy MNC3 patch works.
I configured my SGSN to move in behind a gbproxy, and verified in wireshark that all GPRS-NS packets are duplicated by the hop via the gb-proxy.
Furthermore again could find no failures to communicate the leading zero in the MNC. Attach works, browsing works.

So I think we can merge the osmo-sgsn.git patch now, and leave this issue open until we have some 3-digit MNC tests in ttcn3.

Writing ttcn3-tests with three-digit MNC is made hard by the fact that the SGSN doesn't re-authenticate the second time a subscriber shows up.
Once we tested TC_attach(), the osmo-sgsn needs to be restarted for the test to succeed again.
So I can't run TC_attach() and then add a TC_attach_mnc3() after that; I need to change the IMSI that is attaching. Trying that...

ah the imsi suffix, of course...

the mnc3 attach test works, only it wasn't so easy to reverse-verify that it fails before the 3-digit MNC patch to osmo-sgsn.git: actually most of the GPRS related MNC3 changes already took place in libosmocore! The remaining bits are only the SGSN matching the PLMN to the IMSI "prefix", and the gb-proxy (if so configured) patching over the PLMN. I had to actually go back to an earlier libosmocore as well to verify that the old behavior of truncating 023-042 to 023-42f triggers failure in the ttcn3 test.

So here is the first ttcn3 test for mnc3 in the sgsn: https://gerrit.osmocom.org/7316

a backport to openbsc.git is https://gerrit.osmocom.org/7417

The remaining bit of this issue is more tests in the ttcn3 suite that use a leading zero 3-digit MNC, not only in the SGSN, but also in the MSC, BSC.
Testing the gb-proxy like this is pending an actual ttcn3 gb-proxy test suite.

Today tested the openbsc.git backport manually: set up a local network with osmo-nitb and a sysmoBTS and verified that the leading zero is preserved in all CS communication. For completeness' sake I also ran data services alongside -- even though that was already tested, the osmo-nitb config is communicated to the PCU and technically could configure a wrong PLMN.

all merged and done