Category Archives: Uncategorized

TAP 3 DLL Software for ASN1C v74

The Objective Systems TAP 3 DLL product provides a library of C functions for encoding and decoding messages formatted according to any of the following specifications:

  • TAP (Transferred Account Procedure) versions 0309 through 0312, as defined in the TD.57 documents.
  • RAP (Returned Account Procedure) version 0105-0312, as defined in the TD.32 document.
  • NRTRDE (Near Real Time Roaming Data Exchange) version 0201, as defined in the TD.35 document.

This product has recently been upgraded with the following new features:

  • C code generated with ASN1C v74.
  • Mechanisms for encoding to XML and decoding from XML.
  • Mechanisms for encoding to JSON and decoding from JSON.
  • A Python wrapper.
  • A TAP3VE GUI utility for examining TAP 3 messages, similar to our ASN1VE product.

You can find out more about the TAP 3 DLL software and download an evaluation distribution file here:
TAP 3 DLL download page

ASN1C v7.4 Release for 2020 Features Python Code Gen

We are pleased to announce a new major release of ASN1C for 2020, version 7.4.

The main new feature in this release is the capability to generate Python encoders and decoders. Currently supported is generation of code for the BER/DER and JSON (JER) encoding rules. The BER support includes options to generate forward encoders using indefinite lengths and also includes support for parsing and formatting 3GPP TS 32.297 headers as used in standard 3GPP CDR formats.

The new capability provides for generation of 100% Python code, not wrappers around platform-specific DLL’s or shared object files.

We plan to add support for PER, OER, and XER later this year.

In addition to Python, other features in the new release include:

  • Support for 5G ASN.1-based protocols as well as 5G NAS (3GPP TS 24.501)
  • Support for Visual Studio 2019 in the Windows versions
  • The capability to use ASN1C project files created with the GUI from the command-line

Further information can be found in the documentation on the product support page.

V2X Python Wrapper Updated for Python 3

We’ve updated the Python wrapper in our V2X API packages to support Python 3 (in addition to supporting Python 2.7).   Also, all platforms, not just 64-bit ones, now include the Python wrapper.

About Objective System’s V2X API

The V2X API is available for C++, Java, and C#.  It supports encoding/decoding V2X messages defined by SAE J2735 and ETSI standards.

The Python wrapper enables easy conversion between binary and text encodings by providing a simple Python interface on top of the C++ API.

For more, go here.

V2X API Library Update

With the recent release of ASN1C 7.3.3, we’ve also updated our V2X API library.  We’ve added support for ETSI TS 103 301 SPATEM, MAPEM, IVIM, SREM, and SSEM messages.

Our V2X API library provides support for encoding V2X (Vehicle-to-everything) messages.  The library is available for C++ (as a shared library) Java (JAR), and C# (DLL).   A simple Python wrapper for the C++ shared library is also provided.

Users of previous versions of the Java or C# library should be aware that a slight change was made: classes in the v2x package/namespace have been split into one of two sub-package/namespaces: v2x.j2735 or v2x.etsi.

Users of previous versions of the C++ or Python library should be aware that the shared library has been split into two files (*_j2735 and *_etsi).  Python users must have both libraries present as the Python wrapper library requires both of them.  C++ users can use whichever one is appropriate.

Extending JSON Encoding Rules (JER)

ITU-T standardized the JSON encoding of ASN.1 data in X.697 (JER), but we believe customers want to support use cases the standard doesn’t address.  This post briefly describes two extensions to JER that we’re planning to implement in our ASN.1 compiler, ASN1C.  We plan to implement the first extension (for contents constraints) as an undocumented feature in a 7.3.x patch release in the September-October time frame.

Extension for Contents Constraints

The first extension relates to encoding of BIT STRING or OCTET STRING with a contents constraint.  For example:

OCTET STRING (CONTAINING SomeType)

In short, the purpose of this first extension is to allow the contained type to be encoded in JSON just as it would be encoded if it weren’t a contained type, instead of encoding it as a string of hexadecimal characters.  This extension is all about making the JSON more human-readable.  Here’s an example:

Say your ASN.1 has something like this:

   my-bit-string BIT STRING ( CONTAINING TwoStrings )
…

TwoStrings ::= SEQUENCE {
   one UTF8String,
   two UTF8String
}

The standard JER encoding would look something like:

"my-bit-string" : { "value" : "7B20226F6E6522203A20226D6F6E6579222C202274776F22203A202273686F7722207D", "length" : 280 }

Our extension would instead produce something like:

"my-bit-string" : { "value+" : { "one" : "money", "two" : "show" } }

Extension for Values of Unknown Types

The second extension relates to encoding values of unknown types, which may appear as SEQUENCE/SET/CHOICE extension elements or in open types.  It isn’t possible to convert values of unknown types from BER or PER to standard JER.  Since its type isn’t known, the value is stuck in BER or PER, so to speak.  So, in short, the purpose of our second extension is to enable converting the rest of your data to JSON while preserving what can’t be properly converted (in case you need it) and making a round trip back to the original encoding possible.  This is done by embedding the original encoding in the JSON in hexadecimal form, along with some supplemental information where necessary.

Below are some examples of the JSON that would be produced using our extension.

Handling an unknown open type value:

"some-open-type-element" : { 
   "encoding-rules+" : "BER",
   "encoded-data+" : "03020101"
}

Handling unknown SEQUENCE or SET extension elements:

"extensions+" : {
   "encoding-rules+" : "BER",
   "encoded-data+": [ "hex for extension X", "hex for extension Y" ]
}

Handling an unknown CHOICE extension element:

some-choice-field : {
   "extension+" : {
      "encoding-rules+" : "PER",
      "encoded-data+" : "04020301",
      "encoded-per-index+" : 5
   }
}