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

Archive for category ASN1C

The updated ASN1C Eclipse Plug-in

An updated version of our ASN1C Eclipse Plug-in is now available for Eclipse versions 4.6 (Neon) and higher.

A previous version of this plug-in had been available for Eclipse 3.x.  However, once Eclipse modified the way in which it installs and supports plug-ins, this version ceased to function and there was a significant delay in getting it up-to-date with newer Eclipse versions.  This upgrade is now complete.

Capabilities of this plug-in include:

  • ASN.1 editing and syntax checking
  • Code generation of C/C++, Java, and C# languages from ASN.1

Click on the “Eclipse Plugin” tab near the bottom of our ASN1C product page for more information and installation instructions.

No Comments

The ASN1C Visual Studio Wizard

You may or not be aware that ASN1C includes a Visual Studio Wizard that you can use from Visual Studio to build a library from one or more ASN.1 files. If you have at least ASN1C v732, the wizard is present and usable.

The files for the wizard are in the vswizard folder of your ASN1C installation. There are three files here that are the components of the wizard: ASN1CWizard.ico, ASN1CWizard.vsdir, and ASN1CWizard.vsz. There is also a README.txt file here that provides instructions for configuring and installing the wizard. One of the steps is to modify the .vsz file, and note in particular the instructions to remove the comment-like lines that are at the top. In ASN1C v7.4, which will likely be released in January, this .vsz file will be generated during the installation, and there will no longer be a need to edit it.

Once the files for the wizard are correct and in place, you can use Visual Studio to create a new project just like you normally would, but now you can choose ASN1C as the project type. The wizard will invoke the ASN1C GUI, with some of the irrelevant options disabled. You can use the GUI to choose the ASN.1 files and define how you want the code to be generated for your library. Then you click on the Compile button to generate the code and a Visual Studio project file. Once you exit the GUI, the project file will be loaded into Visual Studio.

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

Using -prttostrm (print-to-stream) vs -prttostr (print-to-string) in generated C code

The capability to print the contents of binary-encoded data in a human-readable form has always been an often used feature of our code generation products.  We have had since the beginning the standard -print code generation option for generating code that would print the contents of generated data structures to standard output.  These are straight-forward and simple to use.  But it was not long after that users wanted a way to print to other mediums, most commonly to a text buffer (i.e character array) so that the printed data could be sent to other places, for example, a display window within a GUI.

For this, the “print-to-string” capability was added.  The command-line option -prttostr was added for this purpose and the generated functions allowed a text buffer and size to be passed to receive the printed data.

This worked OK and was fine for printing small amounts of data.  But what we found was that users frequently wanted to print very large data structures using this capability and this led to very slow performance.  The primary reason for this was because in order to append to the buffer that was passed, the end of the string buffer had to be found and the only way to do this lacking any other state information was to make a call to the string length (strlen) run-time function.  If this was done over and over on a very large buffer containing a very large string, it quickly became a compute-intensive operation.

In order to remedy this, we introduced the “print-to-stream” capability.  This provided more flexibility in printing as a user-defined callback function could be declared that would be invoked to handle the printing of each individual data item.  Users could provide their own user-defined data structures to the callback functions making it possible to maintain state between operations.  One example of this would be in keeping track of where the end of a string buffer was after each print operation making the appending of additional data much faster.

We declared “print-to-string” to be deprecated in favor of the new “print-to-stream” capability, but what we have found 15 years down the road is print-to-string still being used.  A few possible reasons for this are 1) that is the way some users started doing it and did not want to change, and 2) it is simpler to use these functions as all that is necessary is to pass a string buffer directly to the function instead of having to design a callback function.

To address the latter point, as part of our next ASN1C release next year, we will provide a built-in callback function that can be used to model print-to-string using print-to-stream.  If users don’t want to wait that long, the code for the new callback is shown below:

void rtxPrintStreamToStringCB
(void* pPrntStrmInfo, const char* fmtspec, va_list arglist)
   OSRTStrBuf* bufp = (OSRTStrBuf*) pPrntStrmInfo;
   if (bufp->bufsize > bufp->endx) {
      vsnprintf (&bufp->strbuf[bufp->endx], bufp->bufsize - bufp->endx,
                 fmtspec, arglist);
      bufp->endx += strlen (&bufp->strbuf[bufp->endx]);

The OSRTStrBuf structure is defined as follows:

typedef struct {
   char* strbuf;
   OSSIZE bufsize;
   OSSIZE endx;
} OSRTStrBuf;

The code can then be inserted into a C program to print a populated type structure:

OSRTStrBuf strBufDescr;
char strbuf[10240];
/* Set up print-to-stream callback to write to character string buffer */
strBufDescr.strbuf = strbuf;
strBufDescr.bufsize = sizeof(strbuf);
strBufDescr.endx = 0;

rtxSetPrintStream (&ctxt, &rtxPrintStreamToStringCB, (void*)&strBufDescr);

asn1PrtToStrm_<type> (&ctxt, "Data", &data);

In this code snippet, <type> would be replaced with the type name of the data structure to be printed. The result of the call would be the data printed to the strbuf character array. Be sure to create a large enough array to hold all of the printed data. If not large enough, the data will be truncated.

No Comments