Introduction:

ASN.1 sends information in any form (audio, video, data, etc.) anywhere it needs to
be communicated digitally. ASN.1 only covers the structural aspects of information (there are
no operators to handle the values once these are defined or to make calculations with).
Therefore it is not a programming language.
One of the main reasons for the success of ASN.1 is that this notation is associated
with several standardized encoding rules such as the BER (Basic Encoding Rules), or more
recently the PER (Packed Encoding Rules), which prove useful for applications that undergo
restrictions in terms of bandwidth. These encoding rules describe how the values defined in
ASN.1 should be encoded for transmission (i.e., how they can be translated into the bytes
'over the wire' and reverse), regardless of machine, programming language, or how it is
represented in an application program. ASN.1's encodings are more streamlined than many
competing notations, enabling rapid and reliable transmission of extensible messages -- an
advantage for wireless broadband. Because ASN.1 has been an international standard since
1984, its encoding rules are mature and have a long track record of reliability and
interoperability.
An ASN.1 definition can be readily mapped (by a pre-run-time processor) into a C or
C++ or Java data structure that can be used by application code, and supported by run-time
libraries providing encoding and decoding of representations in either an XML or a TLV
format, or a very compact packed encoding format.
ASN.1 is widely used in industry sectors where efficient (low-bandwidth, low-
transaction-cost) computer communications are needed, but is also being used in sectors
where XML-encoded data is required (for example, transfer of biometric information).

CASE STUDY
Suppose a company owns several sales outlets linked to a central warehouse where
stocks are maintained and deliveries start from. The company requires that its protocol have
the following features:
the orders are collected locally at the sales outlets ;
they are transmitted to the warehouse, where the delivery procedure should be
managed ;
an account of the delivery must be sent back to the sales outlets for following through
the client's order.



Module-order DEFINITIONS AUTOMATIC TAGS ::=
BEGIN

Order ::= SEQUENCE {header Order-header,
items SEQUENCE OF Order-line
}
Order-header ::= SEQUENCE {
number Order-number,
date Date,
client Client,
payment Payment-method
}

Order-number ::= NumericString(SIZE (12))

Date ::= NumericString(SIZE (8)) -- MMDDYYYY

Client ::= SEQUENCE {
name PrintableString(SIZE (1..20)),
street PrintableString(SIZE (1..50)) OPTIONAL,
postcode NumericString(SIZE (5)),
town PrintableString(SIZE (1..30)),
country PrintableString(SIZE (1..20)) DEFAULT default-country
}

default-country PrintableString ::= "France"

Payment-method ::= CHOICE {
check NumericString(SIZE (15)),
credit-card Credit-card,
cash NULL
}

Credit-card ::= SEQUENCE {
type Card-type,
number NumericString(SIZE (20)),
expiry-date NumericString(SIZE (6))-- MMYYYY --
}

Card-type ::= ENUMERATED {
cb(0), visa(1), eurocard(2), diners(3), american-express(4)}

Order-line ::= SEQUENCE {
item-code Item-code,
label Label,
quantity Quantity,
price Cents
}

Item-code ::= NumericString(SIZE (7))

Label ::= PrintableString(SIZE (1..30))

Quantity ::= CHOICE {
unites INTEGER,
millimetres INTEGER,
milligrammes INTEGER
}

Cents ::= INTEGER

Delivery-report ::= SEQUENCE {
order-code Order-number,
delivery SEQUENCE OF Delivery-line
}

Delivery-line ::= SEQUENCE {item Item-code,
quantity Quantity
}

END

Protocol DEFINITIONS AUTOMATIC TAGS ::=
BEGIN

IMPORTS
Order, Delivery-report, Item-code, Quantity, Order-number
FROM Module-order;

PDU ::= CHOICE {
question
CHOICE {question1 Order,
question2 Item-code,
question3 Order-number,
...},
answer
CHOICE {answer1 Delivery-report,
answer2 Quantity,
answer3 Delivery-report,
...}
}

END

The Encoding control notation:
Encoding rules are used to define how messages travelling between the various parts
of a telecoms system are represented along the cable or air interface that connects them. If the
representation (or encoding) can be made smaller then clearly more messages can be sent in
the same space. In mobile systems especially, this efficiency of encoding for the messages
between the mobile station and the base station transmitter is vitally important since the
available bandwidth is fixed, you can't just connect a thicker cable!
The techniques and notations are already available for specifying the required data
structures in a machine (encoding) independent way, most notable Abstract Syntax Notation
1 (ASN.1). Such ASN.1 protocol descriptions can be used in combination with standardized
encoding rules such as the Basic Encoding Rules (BER) and the Packed Encoding Rules
(PER). In some of the new application areas however generalized encoding rules such as
BER and PER are not efficient or flexible enough, what is needed is a unique application
specific set of encoding rules. This has lead to some standards using informal non-standard
solutions such as tables to specify these required new encoding rules. Such informal encoding
solutions normally are not directly machine processable and this together with lack of tool
support often makes them extremely error prone.
The goal of the ASN.1 Encoding Control Notation (ECN) is to replace these informal
encoding schemes with a standardized machine processable solution which will be powerful
enough and flexible enough to handle the encoding needs of present and future application
areas.

ECN will prove useful in application domains that require a particularly optimized
transfer syntax (in terms of size or speed of encoding/decoding). All these standards describe
data transfer as bit- or octet-fields in tables or (English) texts, sometimes without providing
any ASN.1 modules. ASN.1's ability to model emerging protocols such as Bluetooth makes it
ideal for working with protocols whose messages were originally defined without use of
ASN.1.

ASN.1 is independent of the programming languages used to implement
communications. Whether you prefer to work in C, C++, Java, C#, or even COBOL, you can
still transfer information. One end of transfer could be written in Java while the other end is
written in C, and they will still be able to exchange information using ASN.1 with its
encoding rules.
ASN.1 is also independent of any hardware or operating system you might choose
to use. This allows exchange of information whether one end is a cell phone and the other end
is a super computer, or anything in between. ASN.1 is flexible, allowing simple easily
understood descriptions, yet has the power, for those who need it, to enforce complex
constraints in which the type of information in one component of a message could be
determined by the value of another component in the message.
So ASN.1 is robust, precise, programming language independent, hardware
independent, operating-system independent, flexible, and powerful.


(http://www.oss.com/asn1/resources/asn1-made-simple/example.html

ASN.1 Made Simple Example
Suppose I need to create a Purchase Order to send electronically. The components my
Purchase Order contains are the date, customer information, items purchased, etc.
In ASN.1 language the Purchase Order may look like this:
MyShopPurchaseOrders DEFINITIONS AUTOMATIC TAGS ::= BEGIN

PurchaseOrder ::= SEQUENCE {
dateOfOrder DATE,
customer CustomerInfo,
items ListOfItems
}

CustomerInfo ::= SEQUENCE {
companyName VisibleString (SIZE (3..50)),
billingAddress Address,
contactPhone NumericString (SIZE (7..12))
}

Address::= SEQUENCE {
street VisibleString (SIZE (5 .. 50)) OPTIONAL,
city VisibleString (SIZE (2..30)),
state VisibleString (SIZE(2) ^ FROM ("A".."Z")),
zipCode NumericString (SIZE(5 | 9))
}

ListOfItems ::= SEQUENCE (SIZE (1..100)) OF Item

Item ::= SEQUENCE {
itemCode INTEGER (1..99999),
color VisibleString ("Black" | "Blue" | "Brown"),
power INTEGER (110 | 220),
deliveryTime INTEGER (8..12 | 14..19),
quantity INTEGER (1..1000),
unitPrice REAL (1.00 .. 9999.00),
isTaxable BOOLEAN
}
END

Note: Each type (such as PurchaseOrder) in ASN.1 must begin with
an uppercase letter. Items that are components of a message (such
as dateOfOrder, customer and items) are called identifiers and
must begin with a lowercase letter.

In ASN.1, all definitions are placed inside of a module which beings with the BEGIN
keyword and ends with the END keyword.
AUTOMATIC TAGS
An ASN.1 Tag is an internal identification for each component in an ASN.1 message.
Although tags can be explicitly assigned by specification writers, it is better to always use
AUTOMATIC TAGS when creating new specifications. Using AUTOMATIC TAGS makes
specifications much easier to read and understand. It also eliminates any potential ambiguity
from a specification writer mistakenly forgetting to add a tag, or potentially inadvertently
adding conflicting tags. Use of AUTOMATIC TAGS changes Address internally to:
Address::= SEQUENCE {
street [0] VisibleString (SIZE (5 .. 50)) OPTIONAL,
city [1] VisibleString (SIZE (2..30)),
state [2] VisibleString (SIZE(2) ^ FROM ("A".."Z")),
zipCode [3] NumericString (SIZE(5 | 9))
}
Since all tags are unique, there is no difficulty determining which values are present or
absent in a message, and which components those values are for (e.g. during the decoding
process).
IMPORTS
When you are creating a type in one ASN.1 module and need to use a definition from
a different module, the easiest way to do so is to IMPORT the definition. The imported item
can be used as if it was defined locally in the module. For example, importing Address from a
different module may look like this:
MyShopPurchaseOrders DEFINITIONS AUTOMATIC TAGS ::= BEGIN
IMPORTS Address FROM PostalInformation;
.

ASN.1 Made Simple Most Common ASN.1 Types
TYPE DESCRIPTION USAGE EXAMPLE
BOOLEAN
Similar to boolean type in programming
languages. Has two possible values: TRUE
and FALSE.
doorOpen BOOLEAN ::= TRUE
INTEGER
Similar to integer type in programming
languages, yet it can be of any magnitude
(your platform may use arrays of bytes to
accommodate unconstrained integers).
speed INTEGER (0..60) ::=
40
BIT STRING
Used for bits arrays that are not necessarily
multiple of 8 bits, e.g. bitmasks. You can
assign meanings to each bit individually.
Values have 3 possible forms: binary -
'011'B, hex - '6'H, and named -
{windowOpen, engineOn}. These are
identical values for myStatus in the example.
Sensors ::= BIT STRING {
doorOpen(0),
windowOpen(1),
engineOn(2)
}
myStatus Sensors ::=
{windowOpen, engineOn}
OCTET
STRING
Used when you have binary data that is
multiple of 8 bits. Values have 2 possible
forms: binary - '01100110'B or hex - '66'H.
MyBinaryFile ::= OCTET
STRING
DATE
Used when you need to represent a date.
Values have the form "YYYY-MM-DD".
harvardEstablished DATE ::=
"1636-09-18"
TIME-OF-DAY
Used when you need to represent a time of
the day. Values have the form "HH:MM:SS".
callTime TIME-OF-DAY ::=
"18:30:23"
DATE-TIME
Used when you need to represent a date
with a time. Values have the form "YYYY-
MM-DDTHH:MM:SS"
callTime DATE-TIME ::=
"2000-11-22T18:30:23"
REAL
Used when you need numbers that include a
decimal point. Values have 2 possible forms:
decimal format such as 245.34 or sequence
format such as {mantissa 2.4534, base 10,
exponent 2}. These two values are identical.
Total ::= REAL
ENUMERATED
Used when you have a list of items which
you prefer to identify by name rather than
by a number. Note that the names of values
always begin with a lowercase letter.
CarColors
::= ENUMERATED {black, red,
white}
myCar CarColors ::= white
OBJECT
IDENTIFIER
Used when you need a globally unique
identifier for something. A common example
of this is a digital certificate. An object
identifier value is a list of arcs from the root
to a node in the object identifier tree.
{joint-iso-itu-t(2)
country(16) us(840)
organization(1)}
SEQUENCE
Used when you have a collection of items to
group together.
Contact ::= SEQUENCE {
name VisibleString,
phone NumericString
}
driver Contact ::= {name
"J.Smith", phone
"7325555555"}
SEQUENCE
OF Used when you have list or array of a
repeated item.
breakTimes SEQUENCE
OF TIME-OF-DAY::=
{"10:00:00", "12:00:00",
"14:45:00"}
CHOICE
Used when you have a collection of items for
which only one of the items can be present
at a time.
Location ::= CHOICE {
streetAddress Address,
intersection Intersection,
landmark LandMarkName,
gpsCoordinates GpsInfo
}
meetAt Location ::=
landmark: "Statue of
Liberty"
IA5String
Used when you need to use ASCII including
control characters
TextWithLayout
::= IA5String
VisibleString Used when you need to use the subset of
LineOfText
ASCII that does not include control
characters.
::= VisibleString
NumericString
Used when you need to use only digits and
spaces.
LineOfNumbers
::= NumericString
UTF8String
Used when you need to handle Unicode
characters.
TextInAnyLanguage
::= UTF8String
NULL
Used when you need a placeholder for which
there is no value. This most often is used as
an alternative in a CHOICE type, or as an
optional component of a SEQUENCE type.

Types To Avoid Using
TYPE DESCRIPTION
UTCTime
The UTCTime type was originally for representing dates and times in a form that
was independent of what time zone you were currently in. Note, however, that
a 2-digit year is used here which potentially causes ambiguity regarding which
century is being represented by the date. The new TIME type fully handles
dates and times without potential ambiguity caused by the 2-digit year of
UTCTime.
GeneralizedTime
The GeneralizedTime type was originally for representing local dates and times,
with the possibility of indicating local time zone as an offset from UTC time.
Although a 4-digit year is used here, eliminating some potential ambiguities,
the new TIME type is preferred since it fully supports ISO 8601 which is the
definitive standard for time and date representations.
GraphicString
The GraphicString type was originally for supporting different character sets
which could be displayed on a screen. It uses special "escape" characters to
switch to different character sets. This type should be avoided since UTF8String,
BMPString or UniversalString cover all character sets without needing to
"escape" into different character sets.
TeletexString
The TeletexString type was originally for supporting different character sets
which could be printed by Teletex machine. It uses special "escape" characters
to switch to different character sets. This type should be avoided since
UTF8String, BMPString or UniversalString cover all character sets without
needing to "escape" into different character sets.
SET
The SET type is similar to the SEQUENCE type except that items can be sent in
any order. The reason this should be avoided is that it unnecessarily makes
decoders slower and more complex without adding any significant benefit. In
particular for some encoding rules (such as BER) the decoders are slower since
each check for a component must cover every possible component in the SET.
SET OF
The SET OF type is similar to the SEQUENCE OF type except that items can
potentially be received in a different order than in which they originally sent.
The reason this should be avoided is that it unnecessarily makes encoders and
decoders slower and more complex without adding any significant benefit. In
particular, some encoding rules (such as DER or PER) require the components
to be sorted in ascending order based on their content.


ASN.1 Made Simple Encoding Rules
ASN.1 has sets of rules precisely specifying how messages must be "encoded" for
communication with other machines. Each set of "encoding rules" has specific
characteristics, such as compactness or decoding speed, which make it best suited for
particular environments. Note that all of the encoding rules are able to represent any
messages you would like to exchange.
BER, DER, CER
The oldest encoding rule, BER (BASIC ENCODING RULES), uses a Tag-Length-
Value (TLV) format for encoding all information. BER always sends a tag to indicate what
kind of data follows, then a length indicating the length of the data that follows, then the
value which is the actual data. Two related encoding rules, DER (DISTINGUISHED
ENCODING RULES) and CER (CANONICAL ENCODING RULES) are subsets of BER
which eliminate some of the extra flexibility provided by BER. Note that DER is commonly
used in security-related applications such as X.509 digital certificates.
OER
The fastest of the ASN.1 encoding rules is OER (Octet Encoding Rules). The Octet
Encoding Rules (OER), like the Packed Encoding Rules (PER), produce compact encodings
by taking advantage of information present in the ASN.1 schema to limit the amount of
information included in each encoded message. However, in contrast to PER, OER favors
encoding/decoding speed and ease of implementation over compactness of the encodings.
Unlike PER Aligned, OER is completely octet-oriented. Whereas in PER Aligned a fixed-
size encoding occupying less than 8 bits may begin at any bit position within an octet and
may end at any bit position within the same or another octet, in OER the encoding of every
possible value of every ASN.1 type occupies a whole number of octets, and all the fields of
the encoding are octet-aligned. OER is used in Intelligent Transportation protocols and is
highly suited for any protocol for which the speed of encoding/decoding is essential.


PER
The most compact of the encoding rules is PER (PACKED ENCODING RULES).
PER differs from BER in that PER does not send the Tag of the TLV since the order in which
components of the message occur is known. PER also does not send the Length of the TLV if
the Value has a fixed length. PER also uses additional information from the ASN.1 message
description to eliminate redundant information from the Value portion of the TLV, thus
making PER messages quite compact and suitable for environments in which bandwidth
conservation is important. There are two ways to encode messages in PER - Aligned and
Unaligned. With the Aligned PER, a field can be aligned to 8-bit octet boundaries by
inserting padding bits. With the Unaligned PER, pad bits are never inserted between fields.
Unaligned PER is commonly used in 3GPP cellular technologies such as UMTS (3G) or LTE
(4G) for protocols likeRANAP, NBAP or RRC.
XER, E-XER
The least compact of the encoding rules, XER (XML ENCODING RULES), uses a
textual XML format for its encodings of the form <start-tag> value <end-tag>. The XER and
E-XER (Extended XER) differ in that the default encodings produced by E-XER are more
suitable for exchanging information with XML Schema Definition (XSD) engines. Note that
the same ASN.1 specification can be used with multiple encoding rules, which means that a
PER message from a cell phone could be converted to E-XER for display and manipulation
in a web browser.

Workflow - Developing with ASN.1
Developing ASN.1 applications is a 4-stage process:
Stage 1: Specify Design your protocol in ASN.1
Stage 2: Translate Compile your ASN.1 specification into your programming
language
Stage 3: Build Write your Application
Stage 4: Run Put your Application to use


Stage 1: Specify Design your protocol in ASN.1
In the first stage, application designers decide on the types of messages their final
application(s) will need to send/exchange. Based on the message requirements, a new ASN.1
specification is drafted or an existing one is used.
When drafting new ASN.1 specifications, it is helpful to decide on the encoding rules (e.g.,
BER, DER, PER andOER) which will be used in sending messages. Doing so will enable the
final application to take full advantage of efficiencies supported in the various encoding rules
(such as ASN.1 subtype constraints resulting to smaller encodings when PER is used).
Drafters of ASN.1 specifications should also keep in mind possible future requirements (such
as message extensibility and a change in the encoding rules used).
Example:
The below abstract syntax is designed to carry simple control and status messages between
electric machinery and a remote operator. The machine has two states: on and off. The
operator can give the machine a turn on instruction, a turn off instruction, or a no action
instruction.

ASN.1 Specification:
Machine Control Abstract Syntax
MCAS DEFINITIONS::=
BEGIN
ControlPacket ::= SEQUENCE {
currentStatus INTEGER {off(0), on(1)},
nextAction INTEGER {noAction(0), turnOn(1), turnOff(2)}
}
END
Most ASN.1 specifications are much more complicated than our simple example.
Such specifications, when being drafted, often contain typographical and syntax errors which
need to be corrected. Manually finding and correcting such errors in long and complex
ASN.1 specifications can be an arduous task. Quality ASN.1 tools, such as the compilers and
the ASN.1 Studio IDE offered by OSS Nokalva, can pinpoint these errors allowing them to
be quickly resolved.

Stage 2: Translate Compile your ASN.1 specification into your programming
language
Once all specification errors are fixed, the ASN.1 specification can be input to the
ASN.1 compiler to produce data structures and related code for inclusion into your
application program. The target language in which the data structures and code are produced
varies according to the capabilities of the ASN.1 compiler in use. For example, OSS Nokalva
offers ASN.1 compilers that use C, C++, Java, or C# as their target language.

Stage 3: Build Write your application
In your application code, you can use the data structures produced by the ASN.1
compiler in much the same way as you would use your own data structures. Additionally, you
can use runtime library functions (such as the OSS-provided ossEncode() and ossDecode()
functions) to encode, decode, and perform various other functions on application data. You
will find that using full function runtime libraries, such as those offered by OSS Nokalva,
will both cut down on the time needed to develop your application and increase its final
reliability and correctness.
Aids such as the OSS ASN.1 Tools allow you to develop ASN.1 applications for a wide
variety of platforms and embedded systems. Application development is made easier, and the
range of solutions you can offer is extended.


Stage 4: Run Put your application to use
Once your application is debugged and tested, you can put it into use to send and
receive ASN.1 encoded messages. The diagram below illustrates a message exchange
between the embedded chip controller and remote computer operator application mentioned
in the Stage 1 example.