Sunday, July 15, 2018

ASN.1 in eCall

eCall is a European Commission initiative (CEN TC278/WG15) intended to bring swift assistance to vehicles involved in a collision anywhere in the European Union. Effective April 2018, eCall is mandatory in all new cars sold within the EU.

The eCall system relies on an In-Vehicle System (IVS) consisting of an eCall application, Cellular Network Connectivity (GSM), a Global Positioning System (GPS), Vehicle Connectivity (CAN), and a GSM modem to transmit vehicle information to an emergency call center, e.g. Public Safety Answering Point (PSAP). In the event of a collision or emergency, via an eCall communication session, the IVS transmits to the PSAP a Minimum Set of Data (MSD) which contains vehicle information, for example, vehicle type, current location, previous locations, propulsion storage type, number of occupants, etc.

The European Standard, EN 15722, “Road Transport and Traffic Telematics”, defines MSD using ASN.1, an international standard used to define data structures and encodings. MSD is encoded in ASN.1 Unaligned Packed Encoding Rules (UPER). The reliability and robustness of ASN.1, and the availability of the limited data space for MSD made ASN.1 and UPER an ideal choice for the eCall standard.

OSS Nokalva, a global leader in ASN.1 technology, provides several ASN.1 Tools which can be used by eCall applications to encode an MSD and by PSAP applications to decode it. The feature-rich ASN.1 Tools, optimized for performance and size, support C, C++, Java, and C# programming languages and have been ported to more than 500 platforms, including embedded and custom platforms.

The MSD ASN.1 specification is compiled by the OSS ASN.1 compiler to generate programming language specific structures or classes. The application code for the eCall system fills these structures/classes, calls the OSS ASN.1 runtime codec to encode the MSD to UPER encoding, and sends it to PSAP via the GSM modem in the In-Vehicle System. The PSAP application calls the OSS ASN.1 decoder to decode the MSD in the structures/classes and uses the decoded values for display on the PSAP operator’s console and/or notifying other emergency services.

For more information about the OSS ASN.1 Tools visit. Online documentation for the Tools can be accessed here. If you have any questions about using the OSS ASN.1 Tools in eCall and PSAP applications, please contact

Monday, December 11, 2017

ASN.1 in C-V2X Communications

Cellular Vehicle to Everything (C-V2X) communications, designed to improve road safety, achieve more efficient traffic flow, reduce environmental impacts, and provide new useful services to travelers, uses several ASN.1 based control plane signalling protocols - RRC, M2, and M3.
3GPP defines four types of C-V2X communications - vehicle to vehicle (V2V), vehicle to pedestrians (V2P), vehicle to roadside infrastructure (V2I), and vehicle to network (V2N).
V2V and V2P communications are based on broadcast capabilities between vehicles or between vehicles and pedestrians, and are designed  to avoid accidents by providing information about the location, velocity, and direction of vehicles.
V2I communication occurs between vehicles and roadside units (RSU) which may act as repeaters to extend the range of V2X messages. V2I also includes communication between vehicles and traffic control devices such as signs, markers, barricades, and signal devices which are used to inform, guide, and control traffic.
V2N communication, over 4G/5G networks, occurs between vehicles and servers (e.g. traffic operation servers) in order to provide a complete view of road events.
There are two modes of operation for C-V2X - direct communication, and network communication.  ASN.1 protocols are used in both of these modes of operation.
Direct communication mode uses the LTE PC5 interface based on  3GPP Proximity Services (ProSe). This mode is used for V2V, V2P, and V2I communications. ProSe supports three coverage scenarios, in-coverage, out-of-coverage, and partial coverage. In the in-coverage scenario, the network controls the resources used in ProSe communications. In the out-of-coverage mode, vehicles use pre-configured resources for sidelink communication with nearby vehicles. However, in the scenario of partial coverage, the vehicle out-of-coverage uses the preconfigured values, while the vehicle in-coverage gets its resources from the network.

The OSS ASN.1 Tools, development toolkits for ASN.1 based applications, can be used to develop C-V2X solutions.  A sample program included with the OSS ASN.1 Tools demonstrates how to implement C-V2X signaling using the partial coverage scenario. The sample demonstrates how an in-coverage vehicle, acting as synchronization reference for the transmitting (out-of-coverage) vehicle, receives SystemInformationBlockType21 (part of BCH-DL-SCH-Message) from the eNB, configures its sidelink, and transmits MasterInformationBlock-SL (part of SBCCH-SL-BCH-Message) message to the transmitting vehicle, which in turn modifies the received MasterInformationBlock-SL message and re-transmits it for C-V2X sidelink communication and discovery for other out-of-coverage vehicles. Using Sidelink discovery vehicles repeatedly broadcast short and fixed-size MasterInformationBlock-SL (SBCCH-SL-BCH-Message) messages that can be detected by nearby vehicles, so they can synchronize with each other to establish wireless connectivity.  The control plane messages in this exchange are based on ASN.1 RRC.
The other mode, mainly used for V2N communication, utilizes the LTE Uu air interface between UEs (vehicles) and eNBs. As an example of V2N mode, a vehicle sends a message via an eNB to an application server which, using Evolved Multimedia Broadcast Multicast Services (eMBMS) - a point-to-multipoint LTE interface for efficient delivery of broadcast and multicast service - in turn broadcasts the message to all nearby vehicles.. The control plane messages in this exchange are based on ASN.1 RRC, M2, and M3 protocols.

The OSS ASN.1 Tools are packaged with sample programs for 3GPP protocols such as RRC, M2, M3, and various other protocols.  These samples can be found under the “samples/standards” directory. To learn more about the ASN.1 Tools, please visit or contact us at

Friday, August 4, 2017

Reduce Your Application's Footprint

The enormous increase in the use of resource constrained IoT devices, presents an ever increasing challenge to developers to keep the size of their application code within very tight memory limitations. The OSS Time Optimized Encoder/Decoder (TOED) can meet these challenging requirements. It’s not only a high performance encoder/decoder, but when used with specific options, it yields a very small footprint, e.g. 60 kilobytes for a LTE RRC UPER encoder/decoder.

In the latest release (summer 2017) of the OSS ASN.1 Tools, a new feature has been added to reduce the footprint even further. With the new versions of the OSS ASN.1 C (10.5) and ASN.1/C++ (6.5) Tools , you can further reduce the size of your application by controlling the inclusion of error strings in your application. When using the -toed option of the ASN.1/C or ASN.1/C++ compiler, you can define the C manifest constant OSS_REDUCED_ERROR_MSGS when compiling the code generated by the ASN.1 compiler to reduce the runtime error messages to only the error prefix for each error message instead of the complete message. In addition, by defining OSS_DEBUG=0, you can remove the error messages completely.  Since error details will no longer be provided, these options are best be used after you have completed debugging your application.  

The elimination of the array of error strings from your application can significantly reduce the application code size on resource-constrained platforms.  For example, a full error message such as the following:

D0081S: End of input reached before message was fully decoded; check field 'b' (type: INTEGER) of PDU #3 'C'.

would be reduced to the following:


when OSS_REDUCED_ERROR_MSGS is defined. No error message text would be generated at all when OSS_DEBUG=0 is defined.

To give you an example of how much additional footprint reduction you can achieve, our testing of the new feature revealed that the footprint of the application was reduced by 18 kilobytes on  Linux x86 when we C compiled the code generated by the ASN.1 compiler with -DOSS_REDUCED_ERROR_MSGS. Using -DOSSDEBUG=0 further reduced the application footprint by an additional 3-4 kilobytes on the same platform.  Please note that you may achieve different results on your platform, depending on the operating system, processor, and C compiler you use.

While this new feature could be useful to anyone working on embedded devices where memory is precious, we expect that  developers working with 3GPP LTE-M and NB-IoT technologies will find it extremely valuable when developing solutions for Cat-0, Cat-1, Cat-M1, and Cat-NB1 devices.

For more information about the OSS ASN.1/C, OSS ASN.1/C++ Tools, or about this new feature, please click here, or contact

Thursday, May 25, 2017

The Memory Handle API - Making memory handling more efficient

Are dynamic memory allocation and the freeing of memory inefficient on your small device?  The OSS’ Memory Handle API can provide you with more efficient allocation and freeing of memory.  You can create a "memory handle" which is a linked list of large memory blocks, and allow the memory allocation function to allocate small segments of these memory blocks as needed, rather than inefficiently calling dynamic memory allocation functions (such as malloc() and free()) each time you need to allocate or release memory.  This is especially useful when the message you are decoding contains a large number of output memory fragments.  Rather than calling malloc() for each fragment, each decoder request for memory will be satisfied by a small segment of memory from the large blocks in the "memory handle", thus avoiding costly calls to malloc() for dynamic memory allocation.

When it is time to free the memory allocated for the complex structure that you decoded, you can either "release" those pieces of memory individually so that they can be reused by future requests for memory, or you can release or free all of blocks of memory for a particular "memory handle" in a single function call, thereby not needing to traverse the complex message structure to make sure each individual memory fragment is released.  This means that when you have several decode operations, you can simply release all memory between decode operations rather than freeing it, thus being able to reuse this memory for your next decode.

Using OSS’ Memory Handle API, you can also create different "pools" of memory which can be used for different purposes.  A simple function call can set which memory pool is currently active. This can be particularly useful in a multithreaded environment where you may have a different memory pool for messages which will only be handled by the current thread vs. a memory pool for messages which could be passed to other threads.

If you need further control over memory allocation and freeing, you can even replace the default system functions (malloc and free) with your own versions of these functions.

If your platform does not allow dynamic memory allocation, you can still use OSS’ Memory Handle API to use static memory as the "pool" from which fragments of memory are given to the encoder or decoder.

More information about OSS’ Memory Handle API can be found in the OSS ASN.1/C Product Documentation.

Friday, March 10, 2017

NB-IoT Support in OSS ASN.1 Tools

Ready for NB-IoT? OSS is here to help. Standardized by 3GPP, this narrow band radio technology is a stepping stone towards 5G. In the next few years, billions of intelligent devices will be connected to wireless networks. While NB-IoT will provide a ubiquitous platform for devices, ranging from mobile phones to automobiles, from tiny sensors to smart buildings, from wearables to complex medical devices, it will also pose challenges to solution providers. Not only will they need to provide mission-critical reliable low-latency services, but they will also need to support resource-constrained devices.

For several decades, OSS has been an ASN.1 industry leader, providing solutions for mission-critical and high-reliability applications. Super-fast, ultra-small, and industry-proven OSS ASN.1 codecs have been deployed in thousands of telecommunication, aviation, financial, and security applications. As the world is ready to embark on NB-IoT, OSS is ready with its solutions to contribute to NB-IoT adoption. In support of  RRC, S1, X2, and NAS protocol implementations, OSS offers a comprehensive NB-IoT development platform which includes  our ASN.1 Tools, S1/X2 ASN.1 API, and NAS Encoder/Decoder Tools.

The RRC ASN.1 specification is huge because it contains many messages addressing the needs of all application areas including NB-IoT. NB-IoT applications need to support only a subset of all these messages. The highly efficient design of the OSS ASN.1 codecs in conjunction with the compiler directives helps you to achieve an extremely small codec footprint. NB-IoT specific messages are specified in a separate ASN.1 module. The OSS ASN.1 Tools can be instructed to generate the codec only for those messages. You can further fine-tune the codec if your application has to encode and/or decode only a few of messages. For your convenience, the OSS ASN.1 Tools include sample programs to demonstrate the encoding/decoding of NB-IoT messages. These samples can be found in the subdirectories under the samples/standards directory of the shipments. The Tools include many other valuable features such as custom memory management, multi-threading support, rich debugging and diagnostic capabilities, etc.

In the S1 and X2 NB-IoT protocols, existing procedures/messages have been updated and new procedures have been added to support CP/UP CIoT (Control/User Plane Cellular IoT) optimizations, to convey information on the CE (Coverage Enhancement) and eDRX (Extended Discontinuous Reception) capabilities of the UE, etc. You can review the respective samples in the shipment of the OSS ASN.1 Tools to learn how you can work with the S1/X2 procedures/messages in your application. In addition, OSS offers an S1/X2 ASN.1 API, add-on to the OSS ASN.1/C Tools, for application level processing of  S1/X2 ASN.1 messages. The API supports NB-IoT specific procedures and messages, and can give you a jumpstart to your S1/X2 development.

The NAS Encoder/Decoder Tools, available on various platforms, is a tool that facilitates the creation, encoding, decoding, and processing of NAS messages. The NAS Encoder/Decoder library takes care of all of the unique aspects of NAS message serialization such as, required and optional information elements, bit-level format of each type of information element, bit order, half-octet order, and so on. The latest release of these tools support 3GPP Release 13 and can be used to work with the NAS messages in your NB-IoT supporting UEs and MMEs.

Moreover to meet the many and varied requirements of NB-IoT, the market will be flooded with many new hardware platforms. Porting your solutions to new platforms will be a daunting task. The highly portable OSS ASN.1 codec (ported to 500+ platforms) will help you rapidly switch to a new platform, accelerating your time-to-commercialize, optimizing cost, and giving you an edge over your competition.

Let’s make NB-IoT happen together! You can download a trial of the OSS solutions mentioned in this blog. If you need more information about how you can use the OSS solutions to meet your NB-IoT requirements, please contact OSS at

Monday, January 30, 2017

Partial/Selective Decoding

These days, many critical applications require real time processing of large volumes of data/messages. Often only the data contained in a few selected fields is of value.

Some such application areas include Big Data, Self Optimizing Networks (SON), Lawful Interception, Routers, Protocol Analyzers, V2X, etc. Big Data is characterized by three main elements - the “3Vs”, volume, variety, and velocity. Extremely large and complex data sets (volume) of different types and natures (variety) need to be processed in real time at very fast rates (velocity). SONs need to process in real time, huge numbers of messages received from different nodes. V2X applications need to work with huge amounts of data received from both vehicles and the roadside infrastructure.

When designing such applications, you will be challenged to process a few selected fields contained within a large set of ASN.1 messages at very fast rate without traversing the complex message structures. In addition, you may need to modify some of those fields without decoding and re-encoding the entire message. OSS’ new partial/selective decoding feature is specifically targeted to meet these requirements.

The partial/selective decoding feature of the OSS ASN.1 Tools is very easy to use. Simply mark the fields in your ASN.1 specification that  you are interested in decoding, and for each field specify a callback function which you want the decoder to invoke after decoding the field. That’s it! You are done. No need to decode the whole message, no need to traverse a complex decoded structure value to find the fields of interest. The decoder will start decoding the message, reach the first field as fast as possible, and call the callback function with the decoded value, along with its offset and length within the encoded message. The decoder will repeat this process for each of the marked fields. You can also instruct the decoder to skip the decoding of the remaining fields after decoding a particular field. This functionality is useful in implementing conditional decoding logic.

Here is a little insight into the implementation of the partial/selective decoding feature. The OSS ASN.1 Tools offer two directives OSS.DataCallback and OSS.InfoCallback to support this feature. The former should be applied to all fields you are interested in decoding. However, if a field is part of many types, the OSS.InfoCallback directive can be used to find which type contains the field being decoded. For example, if a ZipCode field is part of both the HomeAddress and CompanyAddress message and you are interested in decoding only the ZipCode of HomeAddress, you can mark ZipCode with the OSS.DataCallback directive, and HomeAddress and CompanyAddress with OSS.InfoCallback. The callback functions of the OSS.InfoCallback directives can be used to identify which ZipCode is being decoded.

In the callback function, it is also possible to change the encoding of a field within the encoded message. When the decoder invokes the callback function, along with the decoded value, it also returns the offset and length of the encoding of the field. If the encoding length of the modified value is same as the encoding length of its original value, the new encoding of the field can be updated in the message. This feature is useful for the router applications which need to update only an address field within the message. There is no need to decode the whole message, modify it, and re-encode it.

The partial/selective decoding feature can be used along with traditional (full) decoding, or the Tools can be instructed to generate code only for the partial/selective decoding feature. The latter significantly reduces the footprint, for it generates only code sufficient to decode the marked fields.

Please refer to this link for detailed technical information about this feature. If you are interested in a trial of this feature, you can download the trial tools, or contact OSS at This feature is currently supported in the ASN.1/C and ASN.1/C++ Tools.

Thursday, September 1, 2016

IoT Ready OSS ASN.1 Tools

Minimizing the ASN.1 encoder/decoder footprint is an increasingly common requirement of customers in various industries. It is a particularly critical requirement of customers developing solutions for IoT (Internet-of-Things) devices. A great numbers of the devices expected to be connected to the network will have very limited memory capacity, typically a few hundred kilobytes, available for the application.

The OSS ASN.1 Tools have several features customers can use to reduce the size of the ASN.1 encoder/decoder and meet this challenging memory requirement. In several cases, simply using these features we were able to achieve a footprint size of 200 kilobytes for the OSS PER (Packed Encoding Rule) encoder/decoder supporting a large ASN.1 protocol such as RRC (Radio Resource Control).  We were even able to achieve a footprint size of 61 kilobytes for one customer!

The OSS ASN.1 tools for C have two main components, an ASN.1 compiler and a set of runtime libraries. The ASN.1 compiler takes an ASN.1 specification as input and generates C structures for use by your application. The runtime library is linked with your application to support and complement the code generated by the ASN.1 compiler. These generic components have been designed to be easily configured by you to meet your specific needs.

The OSS ASN.1 compiler treats all unreferenced types in the ASN.1 specification as Protocol Data Unit (PDU) types, i.e. the compiler expects that your application will encode/decode messages of these types, and generates encoder/decoder code for all of these types. However, in your particular application, you can optimize space utilization if you don’t need to encode/decode all of these types. By applying the OSS.NOPDU directive, you can instruct the OSS ASN.1 compiler not to generate the code for those types you don’t need.

In cases where there are many message types which your application is not interested in encoding/decoding, applying the OSS.PDU directives to all of those types may not be very convenient. In such cases, simply apply the OSS.NOPDU directive globally and then apply the OSS.PDU directive only to the types you need to encode/decode. This approach, which reduces the number of directives applied is quite useful in applications which handle only a few selected message types.

After you have tailored the generated code to encode and decode only the types you need, it’s possible that you need to only encode some of these types, and only need to decode some other types. Such customization of the generated code is possible by using another set of directives, OSS.ENCODEONLY and OSS.DECODEONLY. If the OSS.ENCODEONLY directive is applied to a message type, only the encoder code will be generated for that type. The OSS.DECODEONLY directive can be used to generate only decoder code for a particular type.

In several cases message types contain many optional fields. If the values corresponding to those fields will not be present in the messages you are receiving, you can instruct the ASN.1 compiler not to generate encoder/decoder code for those optional fields. The ASN1.Remove directive can be used for this. Note, however, that this directive should be used with utmost care, since an incorrect change may invalidate the ASN.1 specification, resulting in unwanted decoding errors. You may refer to the ASN.1 Remove documentation for details.

There is no need to modify the ASN.1 specification to add these directives. You can write them in a separate configuration file and provide it as an input to the OSS ASN.1 compiler. You may even be able to use the same configuration file when you upgrade to a newer version of the specification.  Note that if there are new message types in the new version that your application needs to encode/decode, you may need to make minor adjustments to the configuration file.

The documentation of the OSS ASN.1 Tools for C can be found here.