Feature #3010

Implement 3-digit MNC with leading zeros

Added by neels about 3 years ago. Updated about 3 years ago.

Target version:
Start date:
Due date:
% Done:


Spec Reference:


So far we are not able to handle PLMN 001-001, we shorten it to 001-01, which is a distinct MNC.
Across libosmocore, osmo-bsc, osmo-msc, ..., implement support for leading zeros in a 3-digit MNC.

mnc3_works.pcapng mnc3_works.pcapng 6.28 MB neels, 03/11/2018 01:15 AM
osmo-nitb-mnc3-works.pcapng osmo-nitb-mnc3-works.pcapng 272 KB neels, 03/26/2018 02:39 PM

Related issues

Blocked by Cellular Network Infrastructure - Bug #3009: pcuif_proto.h has mismatching versions across osmo-bsc.git, osmo-bts.git and osmo-pcu.gitResolved02/27/2018


#1 Updated by neels about 3 years ago

  • Blocked by Bug #3009: pcuif_proto.h has mismatching versions across osmo-bsc.git, osmo-bts.git and osmo-pcu.git added

#2 Updated by neels about 3 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 70

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.

#3 Updated by neels about 3 years ago

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/ 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.

#4 Updated by neels about 3 years ago

I should note that for testing I have applied the PCU reverts 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)

#5 Updated by neels about 3 years ago

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).

#6 Updated by laforge about 3 years ago

you could probably also simply split the patch and apply the SGSN part now and postpone the gbproxy one?

#7 Updated by neels about 3 years ago

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.

#8 Updated by neels about 3 years ago

  • % Done changed from 70 to 80

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.

#9 Updated by neels about 3 years ago

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...

#10 Updated by neels about 3 years ago

ah the imsi suffix, of course...

#11 Updated by neels about 3 years ago

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:

#12 Updated by neels about 3 years ago

  • % Done changed from 80 to 90

a backport to openbsc.git is

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.

#13 Updated by neels about 3 years ago

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.

#14 Updated by neels about 3 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 90 to 100

all merged and done

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)