library/GSM_Types: fix encoding of BcdMccMnc (3 octets)

In [1] I copied the hexstring concatenation statement for the 3-digit
MNC from the original function f_enc_BcdMccMnc(), which was renamed
to f_enc_BcdMccMnc_int().  Unfortunately, this statement (originally
introduced in commit [2]) is incorrect.

In our implementation a pair of MCC and MNC is encoded as follows:

  | MCC digit 1 | MCC digit 2 |  octet 1
  | MNC digit 3 | MCC digit 3 |  octet 2
  | MNC digit 1 | MNC digit 2 |  octet 3

Additionally, in the case of a 2-digit MNC, the original variant
of f_enc_BcdMccMnc() (before [1]) would swap MCC and MCC in the
2nd octet, generating even more unpredictable results.

According to 3GPP TS 24.008, Figure 10.5.13, the correct coding is:

  | MCC digit 2 | MCC digit 1 |  octet 1
  | MNC digit 3 | MCC digit 3 |  octet 2
  | MNC digit 2 | MNC digit 1 |  octet 3

So far the only user of this API is the PCU_Tests module.  Looking
at the PCAPs of testcases invoking this function, Wireshark indeed
shows weird MCC/MNC values (expected 262/42):

  Routing area identification: 23-43-423-2
    Mobile Country Code (MCC): Unknown (23)
    Mobile Network Code (MNC): Unknown (43)
    Location Area Code (LAC): 0x01a7 (423)
    Routing Area Code (RAC): 0x02 (2)

Change-Id: Ifa3083fdd6307b56baa1ef3ac85a3e7a2efab728
Related: [1] 7a92d5fbc0
Fixes: [2] 0637ba0728
This commit is contained in:
Vadim Yanitskiy 2023-02-08 04:23:51 +07:00
parent 7a92d5fbc0
commit e9858efb90
1 changed files with 5 additions and 1 deletions

View File

@ -440,7 +440,11 @@ function f_enc_BcdMccMnc(GsmMcc mcc, GsmMnc mnc) return BcdMccMnc {
if (lengthof(mnc) == 2) {
mnc := mnc[0] & mnc[1] & 'F'H;
}
return mcc[0] & mcc[1] & mnc[2] & mcc[2] & mnc[0] & mnc[1];
/* 3GPP TS 24.008, Figure 10.5.13
* | MCC digit 2 | MCC digit 1 | octet 1
* | MNC digit 3 | MCC digit 3 | octet 2
* | MNC digit 2 | MNC digit 1 | octet 3 */
return mcc[1] & mcc[0] & mnc[2] & mcc[2] & mnc[1] & mnc[0];
}
/* Compute BcdMccMnc from integer values */