Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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 where they are referred to. Any constructed ASN.1 types referred to must be specified in an ASN.1 IMPORT statement to be available. For instance,

...

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

...

ASN.1 Type:

Ultra Type mapped to:

BOOLEAN

boolean

bcd

string

All ASN.1 string types except OCTET STRING

string

OCTET STRING

bytearray

ENUMERATED

int

INTEGER

int

REAL

float or bigdec

By default, the float ultra type will be automatically mapped to the REAL ASN.1 type. Substituting ASN.1 type REAL with bigdec will cast the field as BigDecimal type.

Info
titleMapping to bigdecimal

Another method of mapping a REAL type to BigDecimal, is to use internal.

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



BIT STRING

bitset mapping is used. Bitset is mapped to Bit String and vice versa; bitset<->bitstring

For BER BIT STRING encoding: '0410'H is the correct encoding of the bit string '0001'B ("{3}" in APL debug, length of 4 bits.

Note
titleNote!

The string representation here does not actually give complete information since the length is not included. It can be inconvenient to have the same string representation for '0001'B and '000100'B, but the reason is that the same string representation as the Java BitSet class is used. In BER, these values are handled differently. For example, '0001'B is encoded as 0x0410, while '000100'B is encoded as 0x0210.

For further information about how BIT STRING is encoded/decoded in BER, see ITU-T specification X.690 (the first byte is not part of the bitstring itself - instead it encodes the number of unused trailing bits in the last byte in the bitstring encoding, which starts after the first byte).

NULL

bytearray (which will have the value null)


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

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

...

Note
titleNote!

There is a limitation when using terminated_by with bcd for specfying field sizes. A detailed explanation of the limitation can be found here.


Data Support

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

...

Note
titleNote!

These are applicable on OCTET STRINGS only.

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.

...

Info
titleExample - Complex sequential record type

An example of a complex type, occurs when a field fieldB is to be decoded differently depending on the value of another field fieldA. The ASN.1 definition

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

could then be replaced with the sequential format

Code Block
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 );
};

and the extended ASN.1

Code Block
ComplexType ::= [APPLICATION 1 constructed] ComplexType_Seq



bigint Support

Since INTEGER types are automatically mapped to int, which is a 32-bit integer type, INTEGERs longer than 4 bytes will 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.

ASN Language Limitations

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

...

There is also only limited support for information object classes and OBJECT IDENTIFIER types. Object identifiers will be decoded to bytearrays and the information object content will only be 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, which are:

  • 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. 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, which are:

...