Our next release of ASN1C (v 7.3) will include improved support for TBCD and BCD strings for Java and C#. In short, for these types, the toString/ToString function will return the TBCD/BCD interpretation of the octets, rather than merely their hexadecimal representation. This also improves the print functionality.
TBCD stands for Telephony Binary-coded Decimal and BCD stands for Binary-coded Decimal. So, what are TBCD and BCD strings? They are OCTET STRINGS in which a series of digits or telephony digits are encoded, using one nibble (4 bits) per digit. There isn't an authoritative definition, but there are a few standards out there that provide definitions of TBCD or BCD and these are what we've followed, as described below.
As you will see in the following descriptions, TBCD and BCD strings are similar. The differences are 1) the set of digit characters and 2) the ordering of the nibbles within the bytes.
TBCD Strings
For TBCD, we follow 3GPP 29.002. This is also the document that happens to be referenced in the section on TBCD in the Wikipedia entry for BCD. Here is how 29.002 defines TBCD:
TBCD-STRING ::= OCTET STRING -- This type (Telephony Binary Coded Decimal String) is used to -- represent several digits from 0 through 9, *, #, a, b, c, two -- digits per octet, each digit encoded 0000 to 1001 (0 to 9), -- 1010 (*), 1011 (#), 1100 (a), 1101 (b) or 1110 (c); 1111 used -- as filler when there is an odd number of digits. -- bits 8765 of octet n encoding digit 2n -- bits 4321 of octet n encoding digit 2(n-1) +1
Note that 3GPP 24.008 §10.5.4.7 "Called party BCD number" specifies the same encoding, though it simply refers to it as "BCD". 24.008 also calls for BCD in §10.5.1.4 "Mobile Identity" (for the IMSI, IMEI and IMEISV), (presumably) meaning BCD as defined in §10.5.4.7, i.e. TBCD.
BCD Strings
For BCD, we have followed the TAP3 (GSM TD.57) specification of BCD. Here is how they define BCD:
-- The BCDString data type (Binary Coded Decimal String) is used to represent -- several digits from 0 through 9, a, b, c, d, e. -- Two digits are encoded per octet. The four leftmost bits of the octet represent -- the first digit while the four remaining bits represent the following digit. -- A single f must be used as a filler when the total number of digits to be -- encoded is odd. -- No other filler is allowed.
To summarize the characteristics of TAP3 BCDString:
ITU-T Q.825 TBCD-STRING
Q.825 was another candidate for a definition of TBCD strings. At this point, we haven't added special support for it. This section merely points out the differences between Q.825 TBCD-STRING and 3GPP 29.002 TBCD-STRING. The differences are:
- In Q.825, TBCD-STRING is defined as part of an OCTET STRING, not as a standalone type. Prior to the TBCD-STRING content, the OCTET STRING contains an odd/even indicator octet, and, in some cases, another octet.
- Q.825 orders the nibbles differently.
- Q.825 uses the F nibble to mark the end of the TBCD string ("end of pulsing signal-ST")
- Q.825 uses the 0 nibble as filler when there is an odd number of digits. So, in some cases, a zero nibble is merely filler, but in other cases it is a '0' digit. [Note: we're not sure why Q.825 specifies that filler is required when there is an odd number of digits; it seem it should be required when there is an even number of digits. By our reading, "123" would map to 0x123F (no filler), while "1234" would map to 0x12340F (filler).]