Ultra provides support for parsing a subset of ASN.1 definitions, which can be used to decode from and encode to the corresponding BER or PER encoded data. ASN.1 parsing is requested in UFDL via the asn_block construct. The syntax of the  ASN.1 blocks  is declared as follows:

asn_block {
   -- ASN.1 definitions here
};

All ASN.1 constructed types declared either SEQUENCE, SET, or CHOICE, are treated as external format declarations. The name of the resulting external format will be the name of the ASN.1 definition. Any ASN.1 module name is added to the name space. That is, the total name space for the ASN.1 definition is <folder>.<configuration name>.<ASN.1 module name>.

All occurrences of the dash character (-) in identifiers are converted to underscores since dashes are not valid in Ultra type naming.

Any in-map or out-map using an external ASN.1 type will by default specify BER encoding. PER encoding can be selected by specifying one of the map options to PER_aligned or PER_unaligned.

Notes on ASN.1

Inter Module References

It is currently not possible to refer to non-constructed types or list types (that is, SEQUENCE OF and SET OF) declared in other modules. These must be contained within the asn_block to where they are referred. Any constructed ASN.1 types referred to must be specified in an ASN.1 IMPORT statement to be available. For instance,

^{MyType ::= SET(field1 TAC, field2 MobileOriginatedCall)} 

If TAC and MobileOriginated are declared in another asn_block in the same module,

^{TAC ::= OCTET STRING; MobileOriginatedCall ::= SET ( .... )}

The following applies:

1. The TAC declaration must be duplicated in the asn_block of MyType.

2. MobileOriginatedCall must be imported within the asn_block containing MyType.

ASN.1 Primitive Type Mapping

ASN.1 types are automatically mapped by Ultra as follows (this applies when there are automatic statements in the in-maps):

//Create a flat internal that will be used to populate with integer and bigdecimal values.
internal flatInternal {
    int calledNumber;
    bigdec duration;
};

Ultra Extensions

Within a UFDL  asn_block  it is possible to use some extensions which are not part of the ASN.1 standard. These are added to provide better  automatic decoding support for some formats.

Direct BCD Support

A bcd type is introduced. The ASN.1 formats encoded in BER frequently use the OCTET STRING to describe BCD data, leading to complicated processing. By replacing these entries with the bcd type, Ultra automatically converts such entries. The syntax for the bcd type declaration is declared as follows:

bcd(lsn_fd)
bcd(msn_fd) 
bcd(lsn_fd) terminated_by(<expr>) 
bcd(msn_fd) terminated_by(<expr>)

Data Support

Many ASN.1 formats declare date and time information as OCTET STRING. The date type converter is introduced to manage an automatic conversion to date instances. A possible syntax of date declaration is declared as follows:

Time ::= OCTET STRING date({HH,mm,ss}) (SIZE(3))
Date ::= OCTET STRING date({yy,MM,dd})(SIZE(3)) 
Date ::= OCTET STRING date({cc,yy,MM,dd} , {yy,MM,dd}) 
DateTime ::= OCTET STRING date({cc,yy,MM,dd,HH,mm,ss})

Using Sequential Record Types

Some ASN.1 definitions contain data with an OCTET STRING declaration that contains additional structures. In order to manage this, it is possible to split such declarations into sequential record types.

It is also possible to use sequential formats to describe constructed ASN.1 types. In this case the tag must be declared as constructed (a  specific keyword) to allow Ultra to correctly encode the type.

AddressString ::= OCTET STRING (SIZE(1..20))

external GSM.AddressString {
    bit_block : static_size(1) {
      int npi : msb(3), lsb(0);
      int ton : msb(7), lsb(4);
   };
   bcd(msn_fd) msisdn : dynamic_size(udr_size-1),
   terminated_by(0xF);
};

ComplexType ::= [APPLICATION 1] SEQUENCE {
   fieldA INTEGER,
   fieldB OCTET STRING
}

external ComplexType_Seq {
   int tagA: static_size(1);
   int lengthA: static_size(1);
   int fieldA: dynamic_size(lengthA);

   // Definitions of SubType1 and SubType2 not included
   // in this example.
   SubType1 fieldB1: present if( fieldA == 1 );
   SubType2 fieldB2: present if( fieldA == 2 );
};

ComplexType ::= [APPLICATION 1 constructed] ComplexType_Seq

Mapping of ASN.1 INTEGER type and bigint Support

Since INTEGER types are automatically mapped to int, which is a 32-bit integer type, INTEGERs longer than 4 bytes cause decoding errors. This can be avoided by using the bigint type in place of INTEGER. The only difference between bigint and INTEGER is that bigint is automatically mapped to the bigint type, which can support INTEGERs of any size.

Options for in and out maps

By default, ASN.1 external formats are decoded and encoded as BER. However, the decoding and encoding behavior can be modified by options on the in_map and out_map declarations. The available options are:

ASN Language Limitations

The ASN.1 compiler is mostly concerned with the type notation of ASN.1. Elements of type notation not supported are:

• COMPONENTS OF

• WITH COMPONENT

• WITH COMPONENTS

• ABSENT/PRESENT

• ANY, ANY DEFINED BY

• ObjectDescriptor

• DEFAULT

• DEFINITIONS

• EXPLICIT, EXPLICIT TAGS

• INCLUDES

• MACRO

• PRIVATE

• UTCTime

• EXTERNAL

• GeneralizedTime

• OPERATIONS

There are also limitations regarding the support of value notation or macro notation. It is only supported to declare INTEGER constants and use them in constraint specifications.

There is also limited support for information object classes and OBJECT IDENTIFIER types. Object identifiers are decoded to bytearrays and the information object content is only decoded according to the class definition.

BER Limitations

In addition to the general ASN.1 limitations there are also some limitations regarding BER that must be taken in consideration:

• Explicit tags are not supported - All tags are by default implicit (except for tags of CHOICE types, which are always assumed to be explicit according to the ASN.1 standard). Any attempt to specify explicit tagging will result in a compilation error.

• All string fields are encoded/decoded according to ISO8859-1 except for UTF8String.

• No validation to ensure that mandatory fields are actually present is performed for SEQUENCE and SET types.

• Not all character types are supported. However, GraphicalString, IA5String, VisibleString, NumericString, and UTF8String are supported.

PER Limitations

In addition to the general ASN.1 limitations there are also some limitations regarding PER that must be taken in consideration:

• For string types, constraints on the permitted alphabet are not handled.

• Fragmented encoding (encoding for large-size fields) is not supported.

• Not all character types are supported. However, GraphicalString, IA5String, VisibleString, NumericString, and UTF8String are supported.