Thursday, January 2, 2020

What's New in 2020 - OSS ASN.1 and NAS Tools


2020 is going to be an exciting year for our customers. We will update our ASN.1 and NAS Tools to support 3GPP LTE and 5G Releases 15 and 16. In addition to enhancing our existing tools with new value added features, we will also introduce new NAS/C# Tools for LTE and 5G as well as our new S1/X2 ASN.1 API for Java.

The ASN.1 Tools will be upgraded to support LTE and 5G Releases 15 and 16. The OSS NAS/C, NAS/C++, and NAS/Java Tools, and NAS-1Step will be available for LTE and 5G Release 16.

Following the success of our NAS/C, NAS/C++, NAS/Java and NAS-1Step Tools, we are releasing the first version of our NAS/C# Tools available for LTE and 5G Release 16 in the second half of 2020. Users will be able to serialize/parse NAS messages from/to C# objects. In addition, the Tools will provide direct conversion of NAS messages to XML or JSON format. 

This year OSS is releasing our new S1/X2 ASN.1 API for Java supporting LTE Releases 14 and 15. This API will significantly reduce your S1/X2 protocol implementation efforts and provide an easier and less error prone upgrade path to newer 3GPP Releases. In addition, OSS will be updating the existing S1/X2 ASN.1 APIs for C and Java to support LTE Release 16 in 3Q2020.

ASN.1 Studio will be enhanced to automatically create several messages based on an input ASN.1 specification. This feature is particularly useful for customers when testing, as it will automatically generate several different types of test messages for their specification.

The ASN.1/C# Tools will support partial decoding to enable you to quickly decode preselected fields from incoming messages. A significant advantage of using partial decoding is that, when looking for a particular component in a large message, you can directly receive the value of the component you are looking for without having to navigate through the large message structure. This feature is useful in many application areas including Lawful Intercept, routers, protocol analyzers, and Self-Organizing Networks (SON).

3GPP is currently working on Release 16 which is expected to be finalized by June 2020. This Release will include support for Multimedia Priority Service, Vehicle-to-everything (V2X) application layer services, 5G satellite access, Local Area Network support in 5G, wireless and wireline convergence for 5G, terminal positioning and location, communications in vertical domains, network automation, and novel radio techniques, etc. The OSS ASN.1 Tools will support Release 16. New samples will be added and existing samples will be updated to demonstrate how Release 16 ASN.1 based protocols can be used with the OSS ASN.1 Tools.



3GPP Protocol Based Products
Availability
3GPP LTE Release 15 Support
3GPP LTE Release 16 Support
3GPP 5G Release 15 Support
3GPP 5G Release 16 Support
NAS/C LTE
Now
1Q2020
N/A
N/A
NAS/C 5G
N/A
N/A
Now
2Q2020
NAS/C++ LTE
Now
1Q2020
N/A
N/A
NAS/C++ 5G
N/A
N/A
Now
2Q2020
NAS/Java LTE
Now
1Q2020
N/A
N/A
NAS/Java 5G
N/A
N/A
Now
3Q2020
NAS-1Step LTE
Now
1Q2020
N/A
N/A
NAS-1Step 5G
N/A
N/A
Now
2Q2020
NAS/C# LTE
N/A
3Q2020
N/A
N/A
NAS/C# 5G
N/A
N/A
N/A
3Q2020
S1/X2 ASN.1 API for C
Now
3Q2020
N/A
N/A
S1/X2 ASN.1 API for Java
1Q2020
3Q2020
N/A
N/A

N/A - Not Applicable



Thursday, October 3, 2019

At the beginning there was a schema.


Recently we developed a simple “in house” JSON-based protocol for fetching user details from a directory, where apps would submit a ticket (a string identifying a user) to get user info. For example:
app request
server response
{ ”ticket” : ”T9yIC4c2mzR” }
{
   "authorized" : true, 
   "name" : "John Johnson", 
   "email" : "jj@....", 
   "licenses" : [....]
}  

To communicate in JSON we utilized our own DCodec library, which is capable not only of JSON serialization, but also of JSON validation against an ASN.1 schema when one is provided. So we defined this ASN.1 schema:
UserInfo ::= SEQUENCE 
{
  authorized  BOOLEAN DEFAULT FALSE, 
  name        UTF8String (SIZE (3..161)),
  email       UTF8String (SIZE (5..100)),
  licenses    SEQUENCE (SIZE (0..MAX)) OF License
}
...

Since the protocol was simple, the schema was not mandatory (some nodes couldn’t use it even if they wanted to), but it was convenient as informal documentation for developers (defining the message structure, field optionality, value ranges, defaults, etc), as well as for message validation. Yet, there were a few more benefits of having a schema, which we realized only after we implemented it

The logic for handling the UserInfo.authorized field appeared to be very simple: the user is authorized only when the field is set to TRUE, while in all other conditions, including when something is wrong with the message (e.g. wasn't received), would result in a non-authorized user. Such logic proved correct during testing, so the code went into production.

While in production, on rare occasions, we noticed that some responses included an extra field (a way for the directory server to tell about an internal problem):
{
   "error" : 5,
   "authorized" : false, 
   "name" : "", 
   "email" : "", 
   "licenses" : []
}  

We’d never have caught the problem of a message carrying an extra field if not for the “invalid message” events logged due to the schema mismatch, since from the app point of view there was nothing wrong, and the user just appeared to be “non-authorized”, so there was no visible interruption.

Hence we updated the schema to allow a new field “error”, but we immediately caught another schema mismatch. This time it was for “name” and “email” SIZE violation, which cannot be empty. This time we realized that we’re re-using a single message for different cases - success and failure of fetching user info. So we changed the schema one more time to add a new message type for errors:
Response ::= CHOICE 
{
  user  UserInfo, -- successful response
  error Error     -- unsuccessful response
}

UserInfo ::= SEQUENCE 
{
  authorized  BOOLEAN DEFAULT FALSE, 
  name        UTF8String (SIZE (3..161)),
  email       UTF8String (SIZE (5..100)),
  licenses    SEQUENCE (SIZE (0..MAX)) OF License
}

Error ::= SEQUENCE
{
  code        INTEGER (0..255), 
  description UTF8String (SIZE (0..256))
}
Now the response could be either user info, say:
{"user":{"authorized":true, "name":"John Jonson", .... }}
or an “error”, like:
{"error":{"code":5, "description":"...."}}

Without the schema we could have just patched the app code (as “it’s not my problem”) by either ignoring the error, or allowed empty fields, or custom-handled every issue somewhere and somehow. Doing so would result in masking the problem and/or spreading the validation logic all over the application stack.

Another not-so-obvious benefit of using a schema is that the data definition could be stored together with the app sources, so data become a versioned part of Infrastructure as Code, Continuous Integration and Continuous Deployment - following the best practices of DevOps.


WITH SCHEMA
  • Clear boundary of data validation, when the data just entered the system (layer, node).
  • Catch the problem early.
  • Data and code are in sync, defined and implemented together.
  • Precise logic for data definition/validation.
WITHOUT SCHEMA
  • Debug the entire app stack to pinpoint the data at consumption location.
  • Vendor-specific validation logic.
  • Certain conditions might be left unchecked/undetected (e.g. outside the app logic).

Tuesday, August 20, 2019

New Use of ASN.1 - Nuclear Instrumentation


Among various new uses of ASN.1, nuclear instrumentation has taken ASN.1 to new heights in the critical world of sensors. The IEC International Standard, “Nuclear instrumentation – Data format for list mode digital data acquisition used in radiation detection and measurement”, uses ASN.1 to encode digital data acquired from various sensors, including radiation, environmental condition, and geolocation sensors. The standard specifies the ASN.1 encoding format of the binary data which represents the results of measurements of signals generated by various sensors.

For example, the radiation level detected by a sensor (called an event) is passed to an Amplifier/Anti-aliasing filter and an Analog to Digital converter (ADC). The digital signal is then processed by a DSP/FPGA to extract the pulse characteristics, e.g. shape, energy, timestamp, etc. This information is then encoded in ASN.1 COER (Canonical Octet Encoding Rules) and stored in a data file, or streamed to remote computers (receivers). It’s also possible to combine the data acquired from different sensors into a single data file or stream.


The IEC 63047 standard group chose ASN.1 and COER to specify data structures and encoding format because ASN.1 is an international standard that is vendor-, platform-, and language-independent. ASN.1 supports an extensibility feature which ensures backward and forward compatibility between different editions of the standard. Applications implemented using a revised edition of the standard will be able to exchange encodings with applications implemented using the previous editions and vice versa. The use of Canonical OER ensures that there is exactly one binary representation for each possible data value, which allows the use of digital signature and encryption to protect the encodings during transfer to a file or a stream. Several characteristics - it being an international standard; vendor, platform, and language independence; extensibility to ensure backward and forward compatibility; and canonical encodings - which often are taken for granted, made ASN.1 the ideal choice for use in such critical solutions.

All the encodings stored to a IEC63047 database file or sent to the receivers are of the Listmodedata ASN.1 type which is a choice of a “Header”, an “EventList”, or a “Footer” type. The first encoding should be of the “Header” type, followed by a set of encodings of the type “EventList”. The last encoding should be of the type “Footer” (see the diagram below). The EventList type is defined as a SEQUENCE type which contains a SEQUENCE OF “Event”, and one “Event” is a CHOICE of different types of Events.

The ASN.1 specification uses IEEE 754 single- and double-precision REAL types which yield very efficient encodings. The OER encodings of these REAL types are the same as the in-memory unencoded/decoded values. The values can be directly copied to/from the encodings from/to the in-memory representations, making the encoding and decoding process extremely efficient. 


The OSS ASN.1 Tools, available for C, C++, Java, and C# programming languages, can be used to generate the COER encodings of the types “Header”, “EventList”, and “Footer”. The ASN.1 compiler maps the Listmodedata ASN.1 type to the structure/class of the programming language in use. An encoder application can fill an instance of the structure/class and call the high performance COER encoder to create the IEC 63047 encoding. On the receiver side, the encoding can be decoded, using the COER decoder, to an instance of the structure/class. There is no need for the encoder/decoder applications, built using the OSS ASN.1 Tools, to be aware of the intricacies of ASN.1 or COER.

Please visit OSS website to learn more about the OSS ASN.1 Tools and access the documentation of the Tools.