View page as slide show

Communications software and architecture



  • Message is series of bits logically divided into various fields
    • At minimum there is a field describing the message type
  • In order for receiver to understand the message, there has to be set of rules to define the message structure
    • Putting variables in application in correct format to create message is called message encoding
  • Message consists of header, payload (body) and sometimes trailer
    • header gives information about the packet and its handling
      • header is parsed
    • payload is the data that is carried by the protocol
    • trailer contains information dependent on the content of the message e.g. checksum

Message description challenges

  • Protocol can be implemented in variety of devices with variety of tools which can have big principal differences
  • Hardware differences
    • little endian vs big endian
  • Internal representation differences
    • encoding: ASCII, utf-8 …
  • Data structures exchanged between applications are more and more complicated
    • Differences in representation of data structures at programming languages

Message Format

  • Describes
    • The structure of message e.g. how different fields are separated from each other
    • the datatype of each field (binary, integer, character…)
  • fields can be separated by
  1. Predetermined set structure
    • Bit/Byte count
  2. Notation that states the beginning and end of different fields
    • Bit oriented
    • Character oriented

Bit/Byte count

  • The message size and structure is set
    • Each field has a set location in the message
    • In principle the size of each field is predetermined
    • For fields that can have variable size (e.g. payload), a separate field is required where the current size is stated.
  • Messages are hard to interpret by human
  • No overhead
    • except the possible size fields
  • used in e.g. TCP/IP

Bit oriented


  • Fields are separated with a small set of unique bit patterns i.e. flags
    • At minimum the start and end message flags
  • Fields are usually on predetermined order
    • only field separation flag is required along with start and end message flags.
  • Bit stuffing required if data in fields can consist of bit patterns used as identifiers
  • Used in lower communication layers e.g. HDLC

Character oriented

  • Message size is multiplier of character size (usually n* 8 bits)
    • Depends on the used character type (ASCII, UTF …)
    • Character type has to be defined in specification or in message
  • Character stuffing may be required.
    • Binary data can contain any set of characters
  • Is easier to understand for human than bit oriented
  • More overhead than in bit oriented formats
  • On higher layers the notation expresses the meaning of the field
  • high level notations e.g. XML

Message envelopes

  • Communication in layered architecture
    • PDU for horizontal communication
    • Primitive for vertical communication
  • The upper layer data is enveloped by the lower layer
  • Layer n-PDU is encoded in n-1-primitive and transmitted to lower layer
    • layer n-1 uses primitive headers as help to generate layer n-1 PDU
  • layer n-1 PDU may contain whole layer n PDU or just part of it
    • n-1 layer may divide the layer n data to smaller packets
    • At the receiving side the data is reassembled by layer n-1 before given to layer n inside primitive.

Message size

  • The more data there is the better is header/data ratio.
  • The longer the message the more likely it is that there will be error during it's transmission
    • lot of retransmissions in
    • Issue in transport layer and below
  • Message have to arrive completely before it can be handled.
    • Big messages can fill buffers

Abstract notation

  • Abstract notation describes the message content in abstract format
    • Is independent from implementation environment
    • Is independent from the encoding (bitcount, Byte oriented, xml…)
      • Can be used to derive different encodings
  • Abstract notation is needed because
    • The message in the format in which it is transmitted (encoded format) can be sometimes hard to understand
      • Helps to understand the content of message
    • Can help implementation of communication protocol in different environments

What is ASN.1

  • Defined by ISO, as generic means of allowing differing computer systems, with different internal data representations to interchange data.
    • Vendor, platform & language independent notation for specifying data structures at a high level of abstraction
    • Supported by encoding rules that determine the precise bit patterns to represent values of these data-structures that will be transferred over computer network.
    • Supported by tools which map ASN.1 notation into data structure definition in a computer language of choice.
  • International standard
    • defined in several ITU-T standards
      • X.680,X.681,X.682,X.683
      • X.690,X.691 for encoding rules
  • Used extensively by ISO and ITU-T to define protocol messages
    • 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.
  • There is tendency to use ASN.1 in specification of conformance tests even when the protocol specification is not defined in ASN.1

ASN.1 notation

  • 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
  • Basic datatypes
    • Builtin: INTEGER, REAL, BOOLEAN, BITSTRING, NULL,VisibleString, UTF8String, UTCTime…
    • ANY type is used when the type is out of asn.1 scope
  • Production Mechanisms for constructing more complex data types
  • parameter options
    • DEFAULT is used to set default value
    • OPTIONAL is used to denote optional fields in complex datatypes

Additional features

  • Subtyping
    • possibility to take subset of existing type e.g. INTEGER (1..56)
    • complex subtyping allows using complex constructions
  • Macros
    • Help

Structuring an ASN.1 Specification

  • 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

Encoding ASN.1

  • An abstract syntax is converted into a transfer syntax using an encoding rule.
  • ASN.1 has several encoding rules that can be used to provide different ways to represent data during transmission
    • Octet stream (BER), XML …
  • ASN.1 ASN.1 compilers can be used to create C structures or C++ classes from ASN.1 specifications.
    • Public domain compilers do not support all features of ASN.1

Basic Encoding rules

  • 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
  • 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

Summary of ASN.1

  • 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 (e.g. casn) are available which provide support for ASN.1 data manipulation and encoding/decoding for various OSs and programming languages
Last modified: 2013/07/01 14:42