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