Everything you wanted to know about ASN.1 Integration

ASN.1 [1] (Abstract Syntax Notation One) is a flexible notation for representing data structures in telecommunications and computer networks. ASN.1 was originally defined in 1984, and has been updated over the intervening years with the latest revision released in 2002.

ASN.1 describes records in a ‘compact’ binary format that supports transmission of complex telecom and network data in a minimum of bytes whilst supporting highly optional field population. Pre-agreed ‘record’ definitions include information about field encoding (e.g. string, numeric and date formats), and allows scope for lists, field groups, and sub-lists/sub-groups to be specified.

ASN.1 records definitions are similar to XML [3] in that they support nested definition structures, but without the tag names that make XML (human/machine) readable. In contrast ASN.1′s fields rely on details of what fields mean (e.g. ‘customer name’ or ‘product code’) from previously agreed ‘record’ definitions.

There are a number of ways of encoding ASN.1 records, for example BER format [2]. In the BER format, each data field is described in terms of a type identifier, its length and its value (TLV). The type identifier briefly and compactly identifies a field – in circumstances with highly optional field population, many fields may be unpopulated and not present in a specific data record. In one or more bytes, the length component identifies the length of the ‘value’ associated with the field.

Since the ASN.1 data is encoded in binary form, each component must be carefully read to address the possible ambiguities. For example, does a hexadecimal value in a specific byte (i.e. x’04′) mean the field is of ’type’ (T) 04 OCTET STRING, the field has a ‘length’ (L) of four bytes, or a binary field value (V) of four?

Whilst ASN.1 encoded data is primarily used within telecommunication and computer networks, it can also be passed from them to business applications that perform for example assurance reporting and monitoring. These data interfaces when passed from the network for downstream use may be wrapped with header/trailer records and compressed (e.g. gzip) to save disk space and transmission time.

The issue with ASN.1 is that many data tools are unable to read its binary formats natively. Raw ASN.1 data must be transformed from its binary encoding into a format which can be more readily processed, such as CSV or fixed field-width records. A solution to this issue is CR-X, which can decode ASN.1 binary files into these more accessible formats. Business rules can be applied to the decoded files before they are passed to downstream business applications for subsequent use.

Where multiple record formats exist in the ASN.1 source files, records can be omitted when not required, and compressed files are addressed natively by CR-X processing.