Thoughts on the current state of ASN.1 and XML technologies.

Easy V2X Conversions with Python

You can now use Python and our V2X ASN.1 API to easily convert binary V2X messages to text – whether JSON or XML – and vice versa.

Our V2X API is a C++ API, but the latest update provides a Python wrapper that can be used to convert V2X ASN.1-encoded data. There are three classes, each with methods for converting between binary (unaligned PER) and text (JSON or XML), in either direction.  The classes are:

  • For SAE J2735 DSRC (Dedicated Short Range Communications):
    • MessageFrame
  • For ETSI ITS:
    • CAM (Cooperative Awareness Message), ETSI EN 302 637-2
    • DENM (Decentralized Environmental Notification Message), ETSI EN 302 637-3

The API kit includes a sample Python program that handles things like using files for input/output and working with hexadecimal representations of the binary data, but at the end of the day, the conversion itself is simple, using one of the following function calls:

  • binary to JSON: buf = cls.to_json(inp_data, len(inp_data))
  • binary to XML: buf = cls.to_xml(inp_data, len(inp_data))
  • JSON to binary: buf = cls.from_json(inp_data)
  • XML to binary: cls.from_xml(inp_data)

(where cls is one of the provided classes: MessageFrame, CAM, or DENM.)

Download our V2X ASN.1 API and give it try!  Be sure to choose one of the 64-bit downloads, as the Python wrapper is not available for 32-bit systems.  Full documentation for the API is available on our website and included in the download.

No Comments

ASN.1 Tag Path Filtering in ASN2TXT

The latest release of our ASN.1 to Text Translation Tool (ASN2TXT) contains a new feature called “tag path filtering”. The purpose of this is to allow users to target specific items within a BER-encoded message without the need for full ASN.1 schema information. One use case for this would be the case where a user has a Call Detail Record (CDR) specification which has snippets of ASN.1 code, but which does not have the full specification. Another use case is where the user has the full specification, but is only interested in accessing a few specific items within the encoded data.

The way it works is the “tag path” to specific elements within the message is specified in an XML file along with other information such as the data type of the item and names to be used. The tag path is a concatenated list of ASN.1 tag values using a special compact syntax. So instead of using the full name for a tag such as [UNIVERSAL 22], only the first letter of the tag class would be used and there would be no space between the letter and the tag number. Therefore, [U22] would be the shorthand name for this tag.

In addition to the tag path, the following items can be used in a tag path specification:

  • name – a name that will be used in some types of output formats in place of the generated tag name.
  • type – the data type of the element used to format the value for output.
  • value – a textual value that would replace the actual data at the tag location.

The specification of a complete tag path is expressed in XML as follows:

  <path> path in tag path format </path>
  <name> name of the element </name>
  <type> data type of the element </type>
  <value> value to use for the element </value>

A tag path filter consists of one or more of these elements wrapped in an <asn1TagFilter> element.

This is just a brief summary of the basic idea behind tag paths. Full details can be found in the ASN2TXT User’s Manual in the section on ASN.1 Tag Path Filtering.

No Comments

ASN1C v7.3 released

Objective Systems is proud to announce the release of version 7.3 of its ASN1C ASN.1 Compiler product.

ASN1C is an ASN.1 compiler (code generator) capable of generating C, C++, C#, or Java source code from Abstract Syntax Notation 1 (ASN.1) or XML Schema Definition Language (XSD) syntax.

One of the key new features in this release is support for the JSON Encoding Rules (JER) introduced this past year in the ITU-T X.697 standard. Support has been added for generating encoders and decoders in all supported programming languages.

In addition, support was added for 3GPP TS 24.501 NAS Protocol for 5GS. Although this is not an ASN.1 standard, the ASN1C compiler can be used to generate 3GPP layer 3 encoders and decoders that support these message types in the C language. An ASN.1 specification was developed that provides an approximation of the data structures in ASN.1. To work around the parts that can’t be encoded or decoded using standard ASN.1 PER bit-wise operations, special control directives and custom code were used. The specification is available in our ASN1C NAS/RRC Add-on Kit.

The following other new capabilities have been added in this release:

– New compact libraries for PER and UPER encoding and decoding in C that reduce code size by as much as half.

– Support for Canonical Octet Encoding Rules (COER) in Java and C#

– Generation of build artifacts for the Maven or Gradle build frameworks

Further information can be found on the release notes page. A free 30-day trial version may be downloaded from from

No Comments

Improved TBCD and BCD Support for Java/C#

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:

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

To summarize the characteristics for 3GPP 29.002 TBCD-STRING:
• Uses characters 0-9,*,#,a-c.
• F nibble is used as filler when there is an odd number of digits.
• The low nibble contains the first digit.

Note that 3GPP 24.008 § “Called party BCD number” specifies the same encoding, though it simply refers to it as “BCD”.  24.008 also calls for BCD in § “Mobile Identity” (for the  IMSI, IMEI and IMEISV), (presumably) meaning BCD as defined in §, 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:

• Uses characters 0-9,a-e.
• F nibble is used as filler when there is an odd number of digits.
• The high nibble contains the first digit.


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).]


No Comments

New 5G NR (New Radio) 3GPP/LTE APIs available

We have added the new 3GPP/LTE 5G NR (New Radio) ASN.1 API’s for use with ASN1C.  These 5G API’s are extended sample programs that contain the complete ASN.1 specifications extracted from the relevant 3GPP 5G standard documents.  The API’s are available at the following URL (“LTE ASN.1 APIs” tab):

There are API’s available for 3GPP release 15 of the different 5G AP specification types.  API’s are currently available for LTE-RRC 5G NR, E1AP 5G NR, F1AP 5G NR, NGAP 5G NR, and XnAP 5G NR LTE ASN.1 specifications.

Additionally, the existing 3GPP LTE APIs (such as S1AP, e.g.) have been updated to their latest releases (rel 14 or 15).

Finally, support for specification TS 24.501 (NAS protocol for 5G Systems) has been added to the NAS DLL.  Support for the SDK add-on will be included in the next release of ASN1C.

No Comments