Cellular Network Infrastructure » Core Network (CN) » OsmoMSC

The underlying problems seems to be that '12345'H is expanded to '12345F'H somehow:

15:55:14.419444 12 BSC_ConnectionHandler.ttcn:442 Matching on port BSSAP .dtap.msgs.cc.setup_NW_MS.callingPartyBCD_Number.digits := '12345F'H 
with '12345'H unmatched: First message in the queue does not match the template:

The encoder is being told to pad the digits string with '1' bits:

type record CallingPartyBCD_Number {
  OCT1  elementIdentifier, // '5C'O -table 9.70
  LIN1  lengthIndicator, // 1..12
  CallingOrCalled_Number_oct3   oct3,
  hexstring  digits  optional
} with { variant (lengthIndicator) "LENGTHTO (oct3,digits)";
         variant (digits) "PADDING(yes)";
         variant (digits) "PADDING_PATTERN('1'B)"};

This results in an '12345F'H hexstring:

                    callingPartyBCD_Number := {
                        elementIdentifier := '5C'O ("\\"),
                        lengthIndicator := 4,
                        oct3 := {
                            numberingPlanIdentification := '0001'B,
                            typeOfNumber := '001'B,
                            ext1 := '1'B,
                            screeningIndicator := omit,
                            spare1_3 := omit,
                            presentationIndicator := omit,
                            ext2 := omit
                        },
                        digits := '12345F'H
                    },

I am unsure how the receiver is supposed to detect whether padding is present.

Are any 'F' digits simply invalid?

Can we derive the presence of padding from the lengthIndicator field (4)? If so, how?

This patch adds trailing 'F'H to odd-length digit strings and
makes the related tests pass with such strings:
https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/11743

Above change has been merged.