We’ve updated our V2X API for the latest revision of SAE J2735, revision 202007.
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 and Go wrappers enable easy conversion between binary and text encodings by providing a simple Python and Go interface on top of the C++ API.
For more, go here.
We have updated the 3GPP LTE and NAS ASN.1 API’s we have available for use with ASN1C. These API’s are available at the following URL:
There are 5G API’s available for releases 15 and 16, and LTE API’s available for releases 14 through 16.
The NAS API’s contain support for the latest release 16 versions of the TS 24.501, 24.301, and 24.008 specifications.
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
Users evaluating our ASN1C SDK frequently find they don’t get the encoding or decoding performance they hoped for. The libraries we provide for evaluation have less-than-optimal performance for two reasons: they are not optimized and they include license checking overhead. Customers who need to evaluate performance characteristics can request access to optimized libraries, but without doing that, what are some reasonable expectations?
We recently did some performance analysis to help a potential customer evaluate performance. The analysis was for decoding of LTE RRC messages using C++. We used ASN1C 7.4, the statically-linked ASN1C libraries, and Visual Studio 2019. Due to possible variations in specifications, data sets, and hardware, I don’t report absolute measurements here, but rather relative measurements of elapsed wall clock time.
|Non-optimized, limited (license-checked) library (baseline)
|Non-optimized (debug), unlimited (license-check free) library
|Optimized, limited (license-checked) library
|Optimized, unlimited (license-check free) library
|Optimized, unlimited (license-check free) library, with code generation changes (see below for details)
||<2% (8.5% of the time for the same library without the code generation changes)
In this test, we found that the optimized, unlimited library used roughly 20% of the time used by the non-optimized, limited library provided with the evaluation SDK (that’s an 80% reduction in elapsed time).
In this particular case, we did some further experimentation to see what could be done with the generated code to get even better performance using the optimized, unlimited library. We found that by removing some generated diagnostics-related code and using dynamic arrays instead of linked lists, we achieved a tremendous further performance boost. (We generated code using the -dynamicArray option and compiled it with _COMPACT defined). By doing this, we found the time used was less than 2% of the baseline, and only 8.5% of the time used by the optimized, unlimited library.
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.