What is ASN.1

  • Internationally standardised
  • independent
    • vendor
    • platform
    • language independent notation for specifying data structures at a high level of abstraction
  • It is supported by encoding rules that determine the precise bit patterns to represent values of these data-structures that will be transferred over computer network.
  • It is supported by tools which map ASN.1 notation into data structure definition in a computer language of choice.

ASN.1 Outline

  • ASN.1 Specification
  • ASN.1 Basic Encoding Rules
  • ASN.1 Compilers
  • ASN.1 & SDL

Abstract Syntax Notation 1 (ASN.1)

ASN.1 was defined by ISO, as generic means of allowing differing computer systems, with different internal data representations to interchange data. ASN.1 is now extensively used by the ITU & ISO to define protocol headers and formats. In OSI, ASN.1 is used to define presentation layer applications.

ASN.1 Standards

X.680 ASN.1: Specification of basic notation X.681 ASN.1: Information object specification X.682 ASN.1: Constraint specification X.683 ASN.1: Parameterization of ASN.1 specifications X.690 ASN.1 encoding rules - Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER) X.691 ASN.1 encoding rules - Specification of Packed Encoding Rules (PER)

ASN.1 Introduction

Basic Data Types INTEGER, BOOLEAN, UFT8String and other Production Mechanisms for constructing more complex data types SEQUENCE, SEQUENCE OF SET, SET OF CHOICE and other Elements for Structuring the ASN.1 specification Modules, Module Headers Exports/Imports Statements

ASN.1 Character Set

An ASN.1 item shall consist of a sequence of the characters: A to Z a to z 0 to 9 : = , { } < . @ ( ) [ ] - ' “ | & ^ * ; !

ASN.1 is case sensitive ! Font type (bold, italic, size …) is not significant

Naming Rules

Names of fields, elements & items can be arbitrarily long. Quite long names are common Names of Types must start with uppercase Names of Identifiers must start with lowercase

Built-In Types

BOOLEAN Type Has two values: TRUE and FALSE INTEGER Type Integer numbers … -2,-1, 0, 1, 2 … ENUMERATED Type - Enumeration is way to assign name (identifier) to integers Example:

LeadTime-type ::= ENUMERATED
{ tomorrow (0),
	three-day (1),
	week (2)}

REAL Type values: {mantissa 3.14159, base 10, exponent -5} , 0 , PLUS-INIFINITY, MINUS-INFINITY BITSTRING Type value example: ‘101100110001’B or ‘B31’H (in Hex) NULL Type NULL Type has just one value: NULL It is most often used in CHOICE constructs E.G. Toys ::= CHOICE { cars Cars, dolls Dolls, none NULL}

ANY Type

A type of type ANY can be set to any type e.g. MyThing ::= ANY This states that the definition of the type is beyond the scope of ASN.1 Sometimes is referring to items that are to be defined in future.

Object Identifier Type

Object identifiers are defining a globally unique naming space Object identifier name space is defined by hierarchically allocated tree-structure Each arc of the tree is labeled by a numeric value. Global authorities are responsible for allocation of top level arcs More local authorities are responsible for the lower-level arcs

Example Object Identifier

{iso standard 8571 pci (1)} or {1 0 8571 1} Would each identify an object, “pci”, defined in ISO 8571. With the following additional definition:

ftam OBJECT IDENTIFIER ::= {iso standard 8571}

Above defined pci object may be then also uniquely identified as

{ftam pci(1)}

Built-In Character String Types

PrintableString old “telex” character set (not very useful today) VisibleString all printiable ASCII characters plus “space” UTF8String any character (form Egyptian hieroglyphs to ASCII) Other like: NumericString, TeletexString, VideotexString, IA5String, GraphicString, GeneralString, UniversalString, BMPString Value Notation simple: “This is example of value notation” or more complex: {null,{0,0,4,29} cyrillicCapitalLetterIe, “ABC”}

Built-In Date/Time Types

UTCTime two digits for year (+49, -50 from the current year) value example: yymmddhhmmZ : 0003221830Z (Z is for GMT) GeneralizedTime same as UTCTime but with four digits for year


Each production consists of the following parts, on one or several lines, in order: a name for the new collection of production sequences; the characters ::= one or more alternative collections of production sequences (defined later)


SEQUENCE Production Mechanism

A SEQUENCE is a sequence of elements of differing type where the order is important. Example Type notation: SEQUENCE {name IA5String, age INTEGER} Value Notation: {name “John”, age 26}

A SEQUENCE OF is a sequence of elements of the same type where order is important. Example Type notation: SEQUENCE OF INTEGER Value Notation: {12,13,14}

SET Production Mechanism

A SET is a sequence of elements of differing type where the order is not important. Example Type notation: SET { name IA5String, age INTEGER } Value Notation: {age 26, name “John”,age 23, age 6}

A SET OF is a sequence of elements of the same type where the order is not important. Example Type Notation: SET OF INTEGER Example Value Notation: {12,13,14}

SETs are more expensive for encoding so SEQUENCES are preferable

Default & Optional

Keyword DEFAULT Identifies a default value for an element of a SEQUENCE or SET to be assumed if value for that element is not included Keyword OPTIONAL Identifies an element for which a value can be omitted


Person::= SEQUENCE {

			name			UTF8String, 
			number-of-parents	INTEGER DEFAULT 2,
			spouse-name		UTF8String OPTIONAL

CHOICE Production Mechanism

A CHOICE is an element that can be constructed as one of a finite set of types. Example of type notation:

CHOICE {name IA5String, nickname IA5String , TFN INTEGER}

value notation :

{name:“Brad”} or {nickname:“Braddles” } or {TFN:123456}

Tagged types

A tagged type is a new type which is decoded and encoded identically to the type it derives from, but has a different tag Tags are used to differentiate between items of the same base type Example: Flight ::= SEQUENCE { origin IA5String, stop1 [0] IA5String OPTIONAL, stop2 [1] IA5String OPTIONAL, destination IA5String }


Simple Subtyping INTEGER (1..56) subset of integers in the range of 1 to 56 inclusive It is used to improve encoding efficiency (subtypes require less bytes for encoding then full length types) Complex Subtyping involves using construct like: SIZE, FROM INTERSECTION, UNION, EXCEPT, ALL Example of Complex Subtyping INTEGER (ALL EXCEPT (1..20)) (“yes” UNION “no” UNION “maybe”) PrintableString (SIZE (10)) limit to exactly 10 characters PrintableString (SIZE (1..10))

Soft Typing

The value of ANY types can be constrained using the DEFINED BY syntax. Eg X.500 or CMIP; Soft typing When receiving a message containing these messages, a presentation entity should in theory look in an “attribute catalogue”, using the specific value of the “type” as a key. The attribute catalogue will specify, among other things, contain the ASN.1 specification of the attribute values.

Soft Typing Example

TextBook ::= SEQUENCE { author IA5String, CitationType INTEGER, reference ANY DEFINED BY CitationType }, Type TextBook requires a list of CitationTypes defined elsewhere that specifies the ASN.1 type for each permitted value of INTEGER Possible Values are: { author ”Milan Kundera”, CitationType 0, reference IA5String “ISBN0571178170” } or { author “Milan Kundera”, CitationType 1, reference INTEGER 1995 } or { author “Milan Kundera”, CitationType 2, reference PrintableString ”Slowness“ }

ASN.1 Macros

Macros are a mechanism for the user to define a new notation with which they can then construct and reference ASN.1 types or specify values of types. Shorthand notation.

Example Macro

Suppose it is desired to have a notation for type definition of the form PAIR TYPEX = . . . . TYPEY = . . . . with a corresponding value notation allowing (X = —-, Y = —-) Where the . . . . and the —- refer to any ASN.1 type and corresponding value respectively.

Production Rules

A macro definition consists of a set of “production rules”, described in “Bakus-Naur” like form. Several alternatives separated by “|” Each alternative described by a list of “tokens”, which can be: place holders for ASN.1 types or values, keywords enclosed within quotes, like “TYPEX”, ”=“ or ”=“ in our example, place holders for identifiers, or strings

Macro Definitions

A macro definition must always contain at least two production rules, called “TYPE NOTATION” and “VALUE NOTATION”. The “TYPE NOTATION”, preceded by the MACRO name, can be used wherever a “type definition” is expected within the ASN.1 language, the syntax defined in the “VALUE NOTATION” can be used to define a value for a type defined by a macro

Macro Type Notation

Macro Value Notation

Example Macro

Use of Macros in Protocol Definition

Its usually more important to know how to use a particular Macro than how to define new Macros. The following protocols use ASN.1 Macros.

Structuring an ASN.1 Specificatio

n ASN.1 definitions are defined in modules. Modules contain a complete set of type definitions that are self contained. Modules can import definitions from other modules, and export definitions to other modules.


IMPORTS - specifies list of types defined in other modules EXPORTS - specifies list of types defined in this module that are available for use in other modules if EXPORTS statements is omitted all types are available EXPORTS ; (empty list of types) means that nothing is available

IMPORTS/EXPORTS Statements are optional and if exist they should be located at the head of the module after BEGIN statement and before any type definition Semicolon is used to terminate EXPORT/IMPORT statements

Example ASN.1 Module

Basic Encoding Rules

An abstract syntax is converted into a transfer syntax using an encoding rule. ASN.1 has a set of basic encoding rules defined in ISO 8825/ X.690. X.690 is very inefficient, so Packed Encoding Rules (X.691) are defined which are more compact Basic Encoding Rules Each data item is encoded to contain: an identifier (tag or type) a length indicating the size of the data field a data, which contains the actual contents of the object. an optional end-of-content flag if data length is unknown

Aligned on octet boundaries Encoding Length - Definite Form If length < 128, use a single byte, with the high bit set to zero. if high bit is set to one, the low seven bits set to the length of length field. The length is then encoded in that many bytes. Encoding length - Indefinite Form. If length field has a value of 0 - i.e. [1000|0000]. The object is ended by sending two zero bytes. Basic Encoding Rules Constructor Types Types contained within types, are sent in the content portion of the message. ASN.1 Example Types ASN.1 Example Value ASN.1 Example Encoding ASN.1 Example Encoding (cont) Packed Encoding Rules Specialised encoding based on the data type. Only generates tags when they are needed to prevent ambiguity. Only generates lengths when the size of an object can vary. lengths represented in compact form. Packed Encoding Rules Encoding not always aligned on byte boundaries unless 'aligned' variant of the rules is used Optional elements in a sequence are indicated by a list of single bit flags placed at the start of a sequence . To implement a protocol defined in ASN.1 Hand code or feed the ASN.1 specification in an “ASN.1 compiler”, that will automatically generate the conversion routines. ASN.1 Compilers Using ASN.1 for Protocol Specification & Implementation. ASN.1 compilers can be used to create C structures or C++ classes from ASN.1 specifications. Public domain ASN.1 compilers available unfortunately, very few implement MACROs or SoftTyping required for most applications that use ASN.1 Comparison Between SDL and ASN.1 SDL and ASN.1 (ITU-Z.105) Z.105 describes ways in which ASN.1 code can be directly included in SDL specifications. Subset of both SDL and ASN.1 is used. Describes how to use SDL combined with ASN.1 as follows: the System structure and behavior are defined using SDL concepts the parameters of signals are defined by ASN.1 types or SDL sorts data can be defined with ASN.1 type definitions or with SDL sort definitions encoding of ASN.1 data values can be defined by reference to the relevant encoding rules. Encoding is not in the scope of this Recommendation. Other ways of using SDL and ASN.1 More common way is to describe structure and behavior using pure SDL Separately describe data using ASN.1, using the same names in both ASN.1 and SDL Encoding of ASN.1 data values using ASN.1 BER rules. Use of ASN.1 From the approximately 1000 ITU standards roughly 10% make use of ASN.1 Extensively used in areas like ISDN supplementary services, IN protocols and GSM. Tendency to use ASN.1 in specification of conformance tests even when the protocol specification is not defined in ASN.1

ASN.1 - Summary Provides notation for specification of complex data types base on simple types and production rules Specifies also how data values shall be specified Defines Encoding rules which define how data will be represented between two systems (on the “line”) ASN.1 Tools are available which provide support for ASN.1 data manipulation and encoding/decoding for various OSs and programming languages ASN.1 can be used in conjunction with SDL Summary: ASN.1Types, Values and BER

Last modified: 2013/07/01 14:42