Embed Size (px)
DESCRIPTION
ASN.1 is that this notation is associated with several standardized encoding rules such as the BER
Citation preview
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 — ExampleSuppose 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 TAGSAn 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).
IMPORTSWhen 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 ::= BEGINIMPORTS Address FROM PostalInformation;.
ASN.1 Made Simple — Most Common ASN.1 Types
TYPE DESCRIPTION USAGE EXAMPLE
BOOLEANSimilar 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-TIMEUsed 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 SyntaxMCAS 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.
