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

Canonical OER

With ASN1C v7.1 it’s possible to encode and decode OER in C according to the canonical OER rules. Canonical OER can be utilized by setting the ASN1CANON flag in the context before the encoding or decoding is done:

rtxCtxtSetFlag(&ctxt, ASN1CANON);

The Canonical sample in c/sample_oer illustrates using this flag.

With the upcoming ASN1C v7.2 it will be possible to generate canonical OER code directly by using the new -coer qualifier to the ASN1C command (or by choosing the new COER option in the ASN1C GUI). Setting the flag in the context will still enable canonical rules for code generated with -oer instead of -coer. Also in v7.2 it will be possible to generate C++ code for OER instead of just C code.

No Comments

Getting Started with ASN1C

So, you have an ASN.1 specification. And you have ASN1C. How do you use ASN1C in order to work with messages that conform to the specification?

The best way to find out how to use ASN1C with a given specification is to ask ASN1C itself. There are a few qualifiers to the asn1c command that, if used together, can get you started nicely working with your messages.

One qualifier is the -genwriter qualifier. This qualifier will cause ASN1C to generate a sample writer program in your chosen language (C, C++, Java, or C#). This sample writer program encodes a message according to the ASN.1 specification and writes the encoded message out to a file (message.dat by default). Many of the functions the writer calls are also generated code, so you can look at what needs to be done to encode the specific pieces of the message.

A second qualifier is the -genreader qualifier. This qualifier will cause ASN1C to generate a sample reader program in your chosen language. This sample reader program decodes a message from a file (message.dat by default). Many of the functions the reader calls are also generated code, so you can look at what needs to be done to decode the specific pieces of the message.

The third qualifier is the -gentest qualifier. This qualifier will cause ASN1C to generate code that populates an object instance with test data. The test data consist of meaningless, randomly generated values that conform to what the ASN.1 specification says the item should have. But this generated code, which is invoked by the writer, shows you how to populate an object before you encode it.

Sometimes ASN1C will need to choose a definition from the ASN.1 specification to use as the PDU in the generated writer and reader programs. You can tell ASN1C what definition to use for the PDU by adding the -usepdu qualifier.

All of these command line qualifiers have corresponding settings in the ASN1C GUI.

No Comments

Updated 3GPP/LTE APIs (including rel14) available

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

There are API’s available for 3GPP releases 8 through 14 (12 through 14 for M2AP and M3AP) of the different specification types.  API’s are currently available for the LTE-RRC, S1AP, X2AP, M2AP, and M3AP LTE ASN.1 specifications.


No Comments

V2X ASN.1 DLL now available

We have created new API’s that support encoding and decoding messages described in the Vehicle-to-Everything (V2X) ASN.1 standards.  These include SAE J2735 DSRC (Dedicated Short Range Communication) as well as the ETSI CAM (Cooperative Awareness Message) and DENM (Decentralized Environmental Notification Message) message sets.  API’s are available for C/C++ for Windows and Linux, and in Java.  Please see the V2X ASN.1 DLL information page for more details or to download a free, 30-day evaluation version.


No Comments

CSTADLL v2.3 Is Now Available

Objective Systems has released v2.3 of its CSTADLL software. You can find information about CSTADLL here, under the CSTA .NET DLL tab.

The new features in v2.3 are as follows:

  • Support for the Unify OpenScape 4000.
  • Much more robust CSTA XML support.
  • Multiple small DLLs instead of one large DLL.
  • A different licensing model.
  • Support for uaCSTA.
  • New device information helper methods.
  • Clearer definition of callback invocation mechanisms.
  • CDR support.
  • Configurable log file size.
  • A RequestSystemStatus helper method.

You can get more detail about these new features by looking at the v2.3 README file.

No Comments