ttcn3: BSSGP_Types.ttcn MCC-MNC

[Harald Welte]

Hi Neels,

On Fri, Mar 16, 2018 at 03:08:03AM +0100, Neels Hofmeyr wrote:
> which at first glance looks like they got the MCC-MNC digits ordered wrongly.
> It is correct as long as the less significant nibble comes first. And using
> these in PLMN tests gives the expected results.

I am not sure why Ericsson wrote those definitions the way they are.  I think
its stupid (sorry) to define lots of single-length hexstrings rather than one hexstring.

> Now I assume that the HEX1 means that it's a nibble, where the less significant
> nibble comes first, 

HEX1 is a hexstring of length(1), see General_Types.ttcn:

General_Types.ttcn:  type hexstring HEX1 length(1) with {variant "FIELDLENGTH(1)"};

> sort of a "network nibble order" if that makes any sense.

The order is not part of the HEX1 definition but it's defined in an attribute/variant
of the RAW type.  You can use FIELDORDER() to define the encoding order of the fields
of a record.

You can also use the "BYTEORDER()" and "BITORDER()" or "HEXORDER()" to
define the respective parameters, see the TITAN documentation on the RAW
coder for more details.

> It is weird, though -- do we need to compose hex strings "reversed" as well??

I'm not sure what you're asking here?

In the type definitions I wrote I simply use a construct like

GSM_RR_Types.ttcn:      type hexstring GsmBcdString with { variant "HEXORDER(low)" };

Which Makes sure that something like "123456" is encoded as "213265"
like in IMSIs, MSISDNs etc.

However, for those type definitions that are provided by Ericsson, I
think it makes more sense to use them as-is rather than create our own
fork.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)