PLMN identity: 04.08 vs. RANAP

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Neels Hofmeyr nhofmeyr at sysmocom.de
Wed Apr 6 12:20:26 UTC 2016


Hi list,

I've noted a subtle difference in specifications for BCD-coding MCC and MNC.

I'll illustrate by encoding the two sets
  MCC 123, MNC 45
and
  MCC 123, MNC 456

In Figure 10.5.3/3GPP TS 04.08, we have both the third digits in the second
byte, i.e. above are encoded as:
  21 f3 54
and
  21 63 54
respectively

In 3GPP TS 25.413 in 9.2.3.55 PLMN Identity, I see a very similar definition
for BCD coding, but it omits the detail to put the last MNC digit into the
second byte. So, by omittance, it defines a different coding from 04.08:
  21 f3 54 (same)
but
  21 43 65
respectively.

This strikes me as pretty odd, and I wonder whether the spec author overlooked
this detail. The definition in the RANAP spec is also squeezed into the
rightmost column of the IE description table, so it looks like a "quick hack".

I would like to replace the ranap_parse_lai() implementation with
gsm48_mcc_mnc_from_bcd() to have less code duplication, and hence I hit this
weird difference.

Does anyone have an idea how I should handle this?

We could test it by setting our hNodeB to a three digit MNC and see whether it
encodes it like 04.08 in the RANAP coding...
Daniel, could you check this out in wireshark while you're busy testing?

~Neels

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20160406/1c1b7d8c/attachment.bin>


More information about the OpenBSC mailing list