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

Archive for category LTE/3GPP

Compact code generation in ASN1C

ASN.1 is used in a lot of different areas and a new area that is within the Internet of Things (IoT).  In particular Narrowband IoT (NB-IoT) uses ASN.1 UPER-based messaging.

One characteristic of these devices is they are small, so code size is critical.  We have been working on ways to make our ASN1C generated code and run-time libraries as compact as possible for applications such as these.   In our latest ASN1C v7.2.1 patch release, we are now including a new set of compact libraries for Linux.  These can be found in the c/lib_compact directories.  They are built with gcc using maximum space optimization settings and with a lot of non-critical code stripped out.  The compact libraries are roughly 25% smaller than the standard libraries.

In addition to using the compact libraries, additional steps can be taken to reduce the size of the generated code.  We touched on some of these in a past blog post entitled “Optimizing PER Encoding and Code Footprint“.  We would also recommend using the following command-line options (the equivalent GUI option is in parentheses):

  • -compact  (Generate compact code)
  • -noinit  (uncheck the Generate Initialization Functions checkbox)
  • -noenumconvert (do not generate enum-to-string conversion functions – should only be enabled if print functions are generated)

Other options that you may or may not be able use:

  • -lax (Do not generate constraint checks)
  • -strict-size (Interpret size constraints strictly)

If all of these measures are employed, users could potentially see the size of their application reduced by one half or more.

 

No Comments

Performance Improvements in ASN1C v7.2

One of the new features announced in the release of ASN1C v7.2 was improved C/C++ PER encode and decode performance.  This blog post provides some details on the improvements.

We measured a number of different messages types, but two that stood out were the improvement in encoding and decoding unaligned PER messages for LTE RRC and DSRC – two commonly used specifications.   For LTE, we encoded a sample of DL-DCCH-Message messages.  For DSRC, a set of BasicSafetyMessage messages were used.

The time in milliseconds to decode and encode 100000 records between v71x and v72x is shown in the following charts:

The chart on the left shows decoding and on the right encoding.  As can be seen, decoding performance for LTE RRC improved by over 100% while for DSRC, the gain was approximately 50%.  Encoding performances gains were not as dramatic with improvements of 28% and 18% respectively.

So to what to attribute these gains?  The main improvement was in doing calculations that were being done in the run-time to be done at compile time and thus generating simpler code for things such as constraint checking.  Similar improvements were made in the generation of code specifically targeted as “unaligned PER” (or UPER as it is commonly known) through the use of the -uper command-line option.  This resulted in the removal of code that checked for aligned or unaligned PER at run-time.

Finally, we introduced a new kind of simplified memory management called static memory blocks that contains some limitations on use but which is much faster because rather than having to carve up blocks, it simply always sequentially allocates going forward.  Further details on this are available at the following URL:

https://www.obj-sys.com/docs/acv72/CCppHTML/ch08s04.html

 

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

http://www.obj-sys.com/lte_3gpp_apis.php

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

NAS/RRC ASN1C SDK Add-on Now Available

We recently released an add-on package for the ASN1C ASN.1 compiler that allows C code to be generated for encoding and decoding 3GPP layer 3 messages as defined in the NAS and GERAN RRC specifications.  The add-on installs ASN.1 specifications with special markup that provides an approximation of these message types.  It also provides custom C code snippets that are injected by the compiler into places where custom coding was required.   It also provides limited support for the compilation of specifications specified in Concrete Syntax Notation 1 (CSN.1).

Our white paper “Using ASN.1 to Describe 3GPP Messages” describes how the ASN.1 was modeled to accomplish this.

This offering complements our standalone DLL for encoding/decoding NAS/RRC messages.  The advantage in this case is that the provided specifications can be modified to support variations and/or future releases of the protocol messages.  An evaluation of the  SDK add-on and standalone DLL can be downloaded by accessing the following links:

NAS/RRC add-on for ASN1C SDK

NAS/RRC standalone C-based DLL with security handling

(Note: user registration is required).

Further information is available on our 3GPP/LTE API’s web page.

 

No Comments

Online 3GPP NAS Decoder Now Supports 44.018 GERAN RRC messages

We have upgraded our FREE web tool for decoding 3GPP messages, adding support for GERAN RRC messages (3GPP TS44.018) to our previously existing support for 3GPP TS 24.008 (Core Network Protocols), TS 24.011 (Point-to-point Short Message Service), and TS 24.301 (LTE NAS Protocol).

This service is available at the following URL:

http://www.obj-sys.com/webtools/nas_decoder2.php

The service allows for entering or pasting hexadecimal text that describes a binary message to be decoded.  There are a few rules that need to be followed on the format of this text:

  • It must contain an even number of characters with 2 hexadecimal character per octet
  • The characters that make up each octet may be space separated or contiguous; however, use of comma as a separator is currently not allowed
  • The hexadecimal octets may not be preceded by a ‘0x’ prefix

Once entered, the service will attempt to decode the message and present the results in brace text format in the text box below.  Here’s some sample output:

PDU {
   l3HdrOpts {
      skipInd = 0
   }
   protoDiscr = mobMgmt
   msgType = 20
   data {
      obj_AuthenticationResponse {
         respParam = 0xabfb454c
      }
   }
}

We encourage developers to try it out and welcome feedback as to whether the decoding results are as expected or not.

,

No Comments