SIST EN 61334-6:2002

SLOVENSKI STANDARD
01-april-2002
[Not translated]
Distribution automation using distribution line carrier systems -- Part 6: A-XDR encoding
rule
Verteilungsautomatisierung mit Hilfe von Trägersystemen auf Verteilungsleitungen -- Teil
6: A-XDR-Codierungsregel
Automatisation de la distribution à l'aide de systèmes de communication à courants
porteurs -- Partie 6: Règles d'encodage A-XDR
Ta slovenski standard je istoveten z: EN 61334-6:2000
ICS:
29.240.20 Daljnovodi Power transmission and
distribution lines
33.200 Daljinsko krmiljenje, daljinske Telecontrol. Telemetering
meritve (telemetrija)
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD EN 61334-6
NORME EUROPÉENNE
EUROPÄISCHE NORM November 2000

ICS 29.240.20;33.200
English version
Distribution automation using distribution line carrier systems
Part 6: A-XDR encoding rule
(IEC 61334-6:2000)
Automatisation de la distribution  Verteilungsautomatisierung
à l'aide de systèmes de communication mit Hilfe von Trägersystemen auf
à courants porteurs Verteilungsleitungen
Partie 6: Règles d'encodage A-XDR Teil 6: A-XDR-Codierungsregel
(CEI 61334-6:2000) (IEC 61334-6:2000)

This European Standard was approved by CENELEC on 2000-08-01. CENELEC members are bound to
comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this European
Standard the status of a national standard without any alteration.

Up-to-date lists and bibliographical references concerning such national standards may be obtained on
application to the Central Secretariat or to any CENELEC member.

This European Standard exists in three official versions (English, French, German). A version in any other
language made by translation under the responsibility of a CENELEC member into its own language and
notified to the Central Secretariat has the same status as the official versions.

CENELEC members are the national electrotechnical committees of Austria, Belgium, Czech Republic,
Denmark, Finland, France, Germany, Greece, Iceland, Ireland, Italy, Luxembourg, Netherlands, Norway,
Portugal, Spain, Sweden, Switzerland and United Kingdom.

CENELEC
European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung

Central Secretariat: rue de Stassart 35, B - 1050 Brussels

© 2000 CENELEC - All rights of exploitation in any form and by any means reserved worldwide for CENELEC members.

Ref. No. EN 61334-6:2000 E
Page 2
Foreword
The text of document 57/451/FDIS, future edition 1 of IEC 61334-6, prepared by IEC TC 57, Power
system control and associated communications, was submitted to the IEC-CENELEC parallel vote and
was approved by CENELEC as EN 61334-6 on 2000-08-01.
The following dates were fixed:
– latest date by which the EN has to be implemented
at national level by publication of an identical
national standard or by endorsement (dop) 2001-05-01
– latest date by which the national standards conflicting
with the EN have to be withdrawn (dow) 2003-08-01
Annexes designated "normative" are part of the body of the standard.
Annexes designated "informative" are given for information only.
In this standard, annex ZA is normative and annexes A, B and C are informative.
Annex ZA has been added by CENELEC.
__________
Endorsement notice
The text of the International Standard IEC 61334-6:2000 was approved by CENELEC as a European
Standard without any modification.
__________
Page 3
Annex ZA
(normative)
Normative references to international publications
with their corresponding European publications
This European Standard incorporates by dated or undated reference, provisions from other publications.
These normative references are cited at the appropriate places in the text and the publications are listed
hereafter. For dated references, subsequent amendments to or revisions of any of these publications
apply to this European Standard only when incorporated in it by amendment or revision. For undated
references the latest edition of the publication referred to applies (including amendments).
NOTE When an international publication has been modified by common modifications, indicated by (mod), the relevant EN/HD
applies.
Publication Year Title EN/HD Year
IEC 61334-4-41 1996 Distribution automation using distribution line EN 61334-4-41 1996
carrier systems
Part 4: Data communication protocols --
Section 41: Application protocols -
Distribution line message specification
IEC 61334-4-42 1996 Part 4: Data communication protocols -- EN 61334-4-42 1996
Section 42: Application protocols -
Application layer
ISO/IEC 8825-2 1997 Information technology - ASN.1 Encoding - -
rules: Specification of packed encoding rules
(PER)
ITU-T
1988 Specification of Abstract Syntax Notation - -
Recommendation
One (ASN.1)
X.208
ITU-T 1988 Specification of basic encoding rules for - -
Recommendation
Abstract Syntax Notation One (ASN.1)
X.209
NORME CEI
INTERNATIONALE IEC
61334-6
INTERNATIONAL
Première édition
STANDARD
First edition
2000-06
Automatisation de la distribution à l'aide
de systèmes de communication
à courants porteurs –
Partie 6:
Règles d'encodage A-XDR
Distribution automation using distribution
line carrier systems –
Part 6:
A-XDR encoding rule
 IEC 2000 Droits de reproduction réservés  Copyright - all rights reserved
Aucune partie de cette publication ne peut être reproduite ni No part of this publication may be reproduced or utilized in
utilisée sous quelque forme que ce soit et par aucun procédé, any form or by any means, electronic or mechanical,
électronique ou mécanique, y compris la photocopie et les including photocopying and microfilm, without permission in
microfilms, sans l'accord écrit de l'éditeur. writing from the publisher.
International Electrotechnical Commission 3, rue de Varembé Geneva, Switzerland
Telefax: +41 22 919 0300 e-mail: inmail@iec.ch IEC web site http://www.iec.ch
CODE PRIX
Commission Electrotechnique Internationale
W
PRICE CODE
International Electrotechnical Commission
Pour prix, voir catalogue en vigueur
For price, see current catalogue

61334-6 © IEC:2000 – 3 –
CONTENTS
Page
FOREWORD . 5
INTRODUCTION .7
Clause
1 Scope and object . 9
2 Normative references . 9
3 General characteristics of A-XDR . 11
4 Structure of an encoding . 11
5 Rules for encoding . 17
5.1 The Identifier field . 17
5.2 The Length field . 19
5.3 The Contents field. 19
6 Encoding procedures. 21
6.1 Encoding of an INTEGER value. 21
6.2 Encoding of a BOOLEAN value . 27
6.3 Encoding of an ENUMERATED value . 29
6.4 Encoding of a BIT STRING value . 29
6.5 Encoding of an BYTE STRING value . 31
6.6 Encoding of a CHOICE value. 35
6.7 Tagged types (implicit, explicit and ASN.1 explicit tagging) . 37
6.8 OPTIONAL and DEFAULT components . 41
6.9 Encoding of a SEQUENCE value. 43
6.10 Encoding of a SEQUENCE OF value . 45
6.11 Encoding of the VisibleString type . 49
6.12 Encoding of the GeneralizedTime type . 51
6.13 Encoding of the ASN.1 NULL type/value . 51
Annex A (informative) Extensibility. 53
Annex B (informative) ASN.1 types and keywords used in DLMS. 55
Annex C (informative) Examples of A-XDR encoding for DLMS PDUs . 57
Figure 1 – The basic BER structure . 11
Figure 2 – The structure of a constructed BER encoding . 13
Figure 3 – The structure of a constructed A-XDR encoding . 13
Figure 4 – Structure of the variable-length integer encoding . 25

61334-6 © IEC:2000 – 5 –
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
DISTRIBUTION AUTOMATION
USING DISTRIBUTION LINE CARRIER SYSTEMS –
Part 6: A-XDR encoding rule
FOREWORD
1) The IEC (International Electrotechnical Commission) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of the IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, the IEC publishes International Standards. Their preparation is
entrusted to technical committees; any IEC National Committee interested in the subject dealt with may
participate in this preparatory work. International, governmental and non-governmental organizations liaising
with the IEC also participate in this preparation. The IEC collaborates closely with the International Organization
for Standardization (ISO) in accordance with conditions determined by agreement between the two
organizations.
2) The formal decisions or agreements of the IEC on technical matters express, as nearly as possible, an
international consensus of opinion on the relevant subjects since each technical committee has representation
from all interested National Committees.
3) The documents produced have the form of recommendations for international use and are published in the form
of standards, technical specifications, technical reports or guides and they are accepted by the National
Committees in that sense.
4) In order to promote international unification, IEC National Committees undertake to apply IEC International
Standards transparently to the maximum extent possible in their national and regional standards. Any
divergence between the IEC Standard and the corresponding national or regional standard shall be clearly
indicated in the latter.
5) The IEC provides no marking procedure to indicate its approval and cannot be rendered responsible for any
equipment declared to be in conformity with one of its standards.
6) Attention is drawn to the possibility that some of the elements of this International Standard may be the subject
of patent rights. The IEC shall not be held responsible for identifying any or all such patent rights.
International Standard IEC 61334-6 has been prepared by IEC technical committee 57: Power
system control and associated communications.
The text of this standard is based on the following documents:
FDIS Report on voting
57/451/FDIS 57/474/RVD
Full information on the voting for the approval of this standard can be found in the report on
voting indicated in the above table.
This publication has been drafted in accordance with the ISO/IEC Directives, Part 3.
Annexes A, B and C are for information only.
The committee has decided that the contents of this publication will remain unchanged until
2003. At this date, the publication will be
reconfirmed;
withdrawn;
replaced by a revised edition, or
amended.
61334-6 © IEC:2000 – 7 –
INTRODUCTION
ITU-T Recommendation X.208 specifies a formal language (ASN.1 = Abstract Syntax Notation
1)
One) which enables application layer specifications to define the types of information they
need to exchange. A representation of this information can be derived by applying a set of
encoding rules to values of types defined using the ASN.1 notation. Application of these
encoding rules produces a transfer syntax for such values.
Although many such sets of encoding rules could be imagined, for a long time only one single
set – the BER = Basic Encoding Rules – has been standardized (see ITU-T Recommendation
X.209). This is mainly because BER is quite adequate for a wide range of applications. On the
other hand, in some particular cases, BER can obviously be redundant. Avoiding this
redundancy by providing alternative encoding rules for those particular cases is the scope of
some recently developed new transfer syntax standards (DER, CER, PER). Clearly, the aim is
not to provide general-purpose, but rather specialized, alternatives to the BER, which are more
suitable than the BER in some respects.
Contrary to these general-purpose encoding rules, this standard specifies a new, special-
purpose set of encoding rules – A-XDR – which fits in best with the DLMS context (see
IEC 61334-4-41). The principal objective is to encode DLMS PDUs in such a way that the
PDUs byte count and encoding/decoding complexity – the length of the required code, its
2)
processing performance and time – are optimized . This objective is fulfilled by two basic
principles.
a) A-XDR specifies encoding rules only for a subset of ASN.1 types: for the subset which is
used for the DLMS specification. (That is why A-XDR is special-purpose.)
b) A-XDR specifies byte-oriented encoding rules.
——————
1)
ASN.1 also specifies a notation for the specification of the value of a defined type.
2)
With respect to the PDU size only, PER over-performs A-XDR. However, this better compacting performance –
the principal objective of PER – is achieved by a much more extensive use of bit fields instead of byte fields to
encode different values. To reduce encoding sizes further, the more complex PER variant (the Unaligned PER)
also benefits from the limitation of values of constrained types. Gain on compactness is thus obtained at the
expense of computational overhead. Furthermore, PER comes with two, incompatible variants (Aligned and
Unaligned), and it is recommended that implementations should support both of them. This complexity means
that PER is not optimal for the DLMS context. The 'lighter-weight' A-XDR encoding rules are more suitable to
that simple environment, which is in some cases very poor in resources.

61334-6 © IEC:2000 – 9 –
DISTRIBUTION AUTOMATION
USING DISTRIBUTION LINE CARRIER SYSTEMS –
Part 6: A-XDR encoding rule
1 Scope and object
3)
This part of IEC 61334 defines a set of encoding rules – the A-XDR encoding rules – that
may be used to derive the specification of a transfer syntax for values of types defined in the
DLMS core standard using the ASN.1 notation (see IEC 61334-4-41). These A-XDR encoding
rules are also to be applied for decoding such a transfer syntax in order to identify the data
values being transferred.
The A-XDR encoding rules
• are used at the time of communication;
4)
• provide optimal encoding for DLMS PDUs.
NOTE Provided that A-XDR ensures optimal encoding for DLMS PDUs, it is intended to be the default encoding
rule for DLMS-based communication protocols. Nevertheless, the default – and also the possibly usable optional –
encoding rules will be specified in the Application Layer document of the given protocol (for example,
IEC 61334-4-42), as part of the Application context.
2 Normative references
The following normative documents contain provisions which, through reference in this text,
constitute provisions of this part of IEC 61334. For dated references, subsequent amendments
to, or revisions of, any of these publications do not apply. However, parties to agreements
based on this part of IEC 61334 are encouraged to investigate the possibility of applying the
most recent editions of the normative documents indicated below. For undated references, the
latest edition of the normative document referred to applies. Members of ISO and IEC maintain
registers of currently valid International Standards.
IEC 61334-4-41:1996, Distribution automation using distribution line carrier systems – Part 4:
Data communication protocols – Section 41: Application protocols – Distribution line message
specification
IEC 61334-4-42:1996, Distribution automation using distribution line carrier systems – Part 4:
Data communication protocols – Section 42: Application protocols – Application layer
ISO/IEC 8825-2:1997, Information technology – ASN.1 Encoding rules: Specification of packed
encoding rules (PER)
ITU-T Recommendation X.208:1988, Specification of Abstract Syntax Notation One (ASN.1)
ITU-T Recommendation X.209:1988, Specification of basic encoding rules for Abstract Syntax
Notation One (ASN.1)
——————
3)
A-XDR stands for Adapted XDR. In fact, these encoding rules are derived from a proven and de facto standard
of the Unix world, called XDR (eXternal Data Representation, rfc1014).
4)
See footnote 2 of the introduction.

61334-6 © IEC:2000 – 11 –
3 General characteristics of A-XDR
A-XDR specifies encoding rules which can be used to encode and decode the values of an
abstract syntax defined as the values of a single ASN.1 type (the outermost type). This single
ASN.1 type is either a simple type or a composite type. A component of a composite type may
be a simple type or a composite type itself.
The A-XDR encoding rules exploit the fact that the sender and the receiver of a DLMS PDU are
operating exactly the same specification of the abstract syntax. While with BER the encoding of
every value of any type of abstract syntax is constructed in type-length-value (TLV) style,
A-XDR encodes the type and the length of the value only when this information is necessary.
This implies that without knowledge of the type of value encoded it is not possible to determine
the structure of the encoding.
NOTE This encoding method gives the result that A-XDR encoding rules are not extensible (see annex A).
In order to keep A-XDR as simple as possible, some restrictions apply with respect to the
abstract syntax to be encoded as follows:
5)
• no encoding support is provided for ASN.1 types which are not used in DLMS ;
6)
• the CHOICE ASN.1 type should contain only explicitly tagged components.
A-XDR specifies byte-oriented encoding rules. This means that each part of the encoding – and
therefore also the encoding of the whole – is an integral number of bytes.
4 Structure of an encoding
The basis of BER encoding (see ITU-T Recommendation X.209) is a structure, made up of
three parts: type, length and value, as shown in figure 1. In BER, these three parts are termed
identifier (I), length (L) and contents (C). The identifier part identifies the type, the length part
7)
allows the end of the contents to be found, and the contents part conveys one of the possible
values of that type.
Identifier Length Contents
IEC  730/2000
Figure 1 – The basic BER structure
8)
The contents field can be simply a series of bytes (primitive encoding) or a series of nested
encoding (constructed encoding), as shown in figure 2.
——————
5)
Annex B enumerates the ASN.1 types and keywords which are used in the DLMS specification.
6)
The terms "explicit tagging" and "implicit tagging" have a slightly different meaning in A-XDR than that specified
for ASN.1 and BER. Subclause 6.7 deals with these notions and also introduces the new "ASN.1 explicit
tagging" term.
7)
In fact, for BER, the length field does not always literally represent the length of the contents. BER specifies two
forms (definite and indefinite) of the length field. Although, when the definite form is used, the length field
effectively represents the number of bytes in the contents field, for the indefinite form the length field indicates
that the contents are terminated by end-of-contents bytes.
8)
Zero or more.
61334-6 © IEC:2000 – 13 –
I1 L1 I2 L2 I3 L3 C3 I4 L4 C4 I5 L5 C5 I6 L6 C6
C2
C1
IEC  731/2000
Figure 2 – The structure of a constructed BER encoding
The nesting can be as deep as needed and stops either with a primitive encoding or with a
constructed encoding with empty contents.
A-XDR is based upon the same encoding structure, but in order to benefit from the fact that the
sender and the receiver of a DLMS PDU are operating exactly the same specification of the
abstract syntax, A-XDR does not encode the Identifier (I) and/or the Length (L) fields when
those fields convey redundant information (when not to encode one or both of these fields does
not result in uninterpretable, ambiguous encoding). A constructed A-XDR encoding therefore
results in a structure as shown in figure 3.
I1 L1 L2 C3 I4 L4 C4 L5 C5 C6 L7 C7 C8 I9 L9 C9
C2
C1
IEC  732/2000
Figure 3 – The structure of a constructed A-XDR encoding

61334-6 © IEC:2000 – 15 –
A-XDR encoding rules specify
• encoding rules for the contents fields;
• the conditions when the L field should be present, and the encoding of that field;
• the conditions when the I field should be present, and the encoding of that field.
Example
Taking the following ASN.1 composite type:
value ::= SEQUENCE {
A Integer16,
B Unsigned16
}
Integer16 ::= INTEGER(–32768.32767)
Unsigned16 ::= INTEGER(0.32767)
9)
and supposing that the values to be encoded for A and for B are 0x1234 and 0x5678
respectively, the BER encoding of that sequence may result in the following series of bytes:
30 08 02 02 12 34 02 02 56 78
Identifier of the SEQUENCE
Length of the SEQUENCE
Identifier of A (INTEGER)
Length of A
Value of A
Identifier of B (INTEGER)
Length of B
Value of B
A-XDR encoding of the same sequence is as follows:
I 123456 78
10)
Identifier of the SEQUENCE
Value of A
Value of B
——————
9)
The term 0x… indicates that the following digits represent hexadecimal digits.
10)
A-XDR requires encoding identifier only in special cases (for example, when the SEQUENCE of this example is
one of the choices of a CHOICE type).

61334-6 © IEC:2000 – 17 –
5 Rules for encoding
A-XDR encoding of any ASN.1 type results in an integral number of bytes, each containing
eight bits. This series of bytes begins with the first byte of the encoding of the Identifier field of
the outermost ASN.1 type – in these terms, this byte can be considered as the most significant
byte. For the purpose of this standard, the following identification schema applies:
• the bytes of the A-XDR encoding are not systematically numbered, but sometimes, when it
helps for clear understanding, comments apply (for example, 1 byte of the value, etc.);
• bits of any byte are numbered from 1 to 8, where bit 8 is the most significant.
5.1 The Identifier field
The purpose of the Identifier field is to indicate the type of the encoded value. Provided that the
sender and the receiver are operating exactly the same specification of the abstract syntax, the
Identifier field conveys information only in cases when
a) one type of data should be selected between different alternatives – CHOICE;
b) the presence of an OPTIONAL component in a SEQUENCE type should be indicated;
c) the presence of a DEFAULT component in a SEQUENCE type should be indicated.
A-XDR encoding contains an Identifier field only in these cases. In addition, A-XDR encodes an
Identifier when encoding the Identifier is required by the ASN.1 specification (ASN.1 explicit
tagging, see 6.7).
In case a), A-XDR requires that all the alternatives of the CHOICE will be specified at ASN.1
level as explicitly tagged types (see 6.7). In these cases, the encoded tag forms the identifier
field.
In cases b) and c), the presence or the absence of the OPTIONAL or DEFAULT component is
indicated by a so-called BOOLEAN presence flag. The Identifier field for these component
values is the A-XDR encoding of the value of the presence flag (see 6.9).
On the other hand, A-XDR may be forced to encode the Identifier field, when the ASN.1
definition contains ASN.1 explicit tags (see 6.7). A-XDR encoding of such types is defined to be
the same as their BER encoding. The aim of this support is to force the length to be encoded,
for example, in order to allow for the easy omission of some structures. The Identifier field for
those types is the encoded value of the ASN.1 tag and occupies an integral number of bytes, at
least one, as specified in ITU-T Recommendation X.209.

61334-6 © IEC:2000 – 19 –
5.2 The Length field
In A-XDR the Length field (when this field is present) immediately precedes the Contents field,
represents explicitly the length of the Contents field and occupies an integral number of bytes.
Provided that the sender and the receiver are operating exactly the same specification of the
abstract syntax, the Length field conveys information only in cases when a variable length
ASN.1 type is to be encoded. The possible cases are
a) variable length INTEGER;
b) variable length BIT STRING;
c) variable length BYTE STRING;
d) variable length SEQUENCE OF type.
A-XDR encodes the Length field only in the above cases, and, in addition, in one more case,
when it is required by the ASN.1 specification (ASN.1 explicit tagging, see 6.7).
In a), b), c) and d), the Length field is encoded as a variable length integer. For the additional
case, the same encoding applies as defined in BER (see ITU-T Recommendation X.209)
except for the restriction that only the definite form can be used. Using the indefinite form
(footnote 7) for the Length field is not allowed within A-XDR.
5.3 The Contents field
The Contents field is the substance of the encoding, conveying the actual value. It consists of
zero or more bytes, and shall encode the data value as specified in the following clauses.

61334-6 © IEC:2000 – 21 –
6 Encoding procedures
6.1 Encoding of an INTEGER value
A-XDR provides two types of encoding for the ASN.1 INTEGER type, depending on whether the
ASN.1 definition of an INTEGER is value-constrained or not. When an INTEGER is specified to
be within a restricted range of values, for example INTEGER(–128.127), it is encoded as
a fixed-length integer. Otherwise, when no range is specified, the INTEGER is encoded as a
variable-length integer.
6.1.1 Encoding of a fixed-length integer value
Two different encodings are provided by A-XDR for fixed-length integers: integers which are
specified to be within a non-negative value range are represented and encoded as unsigned
binary numbers, while integers which may take negative values are represented and encoded
as two’s complement binary numbers. In both cases, only the value of the integer is encoded,
forming the contents field of the encoding. The aim is to provide minimal-length encoding.
6.1.1.1 Encoding of fixed-length, unsigned integer values
When an INTEGER is specified to be within a non-negative value range, it is encoded as an
unsigned binary number. The number of bytes of the encoding is determined by the specified
value-range: it is equal to the minimum number of necessary bytes which is required to
represent any value within the specified range. The range of a fixed-length unsigned integer is
always aligned on byte boundary.
Example
INTEGER(0.255) is encoded in 1 byte
INTEGER(0.256) is encoded in 2 bytes
INTEGER(237.256) is encoded in 2 bytes
A fixed-length unsigned integer is presented in unsigned binary notation. The encoding is an
unsigned binary number equal to the integer value and consists of bits 8 to 1 of the first byte,
followed by bits 8 to 1 of the second byte, followed by bits 8 to 1 of each byte in turn, up to and
including the last byte of the encoding.
Example
A-XDR encoding of the 61478 value of an INTEGER(0.65535) is as follows:
st nd
1 byte 2 byte
87654321 87654321
11110000 00100110
61334-6 © IEC:2000 – 23 –
6.1.1.2 Encoding of fixed-length, signed integer values
When an INTEGER is specified to be within a value range which includes negative values, it is
encoded as a two's complement binary number. The number of bytes of the encoding is
determined by the specified value-range; it is equal to the minimum number of necessary bytes
which is required to represent any value within the specified range. The range of a fixed-length
integer is always aligned on byte boundary.
Example
INTEGER(–32768.32767) is encoded in 2 bytes
INTEGER(–14300.8700) is also encoded in 2 bytes
INTEGER(–32768.32768) is encoded in 3 bytes
The encoding is a two’s complement binary number equal to the integer value, and consists of
bits 8 to 1 of the first byte, followed by bits 8 to 1 of the second byte, followed by bits 8 to 1 of
each byte in turn, up to and including the last byte of the encoding.
Example
A-XDR encoding of the –45783 value of an INTEGER(–50000.1) is as follows:
st nd rd
1 byte 2 byte 3 byte
87654321 87654321 87654321
11111111 01001101 00101001
6.1.2 Encoding of a variable-length integer value
When the range of values of an INTEGER is not specified, that INTEGER is encoded as a
variable-length integer. Encoding of a variable-length integer may be given in two forms,
depending on the value to be encoded.
When the value of a non-constrained INTEGER is between 0 and 127 (0 ≤ value < 128), only
the value is encoded as a single byte. Bit 8 of this byte is obviously 0 (zero).
Example
A-XDR encoding of the INTEGER value 123 (= 0x7B) is as follows:
61334-6 © IEC:2000 – 25 –
Encoding of a non-constrained INTEGER value when it is out of the above 0 ≤ value < 128
range contains two fields: the first, fixed-length field – Length – represents the length of the
second, variable-length field, in bytes. This second, variable-length field – Contents – conveys
the encoded value, and contains an integral number of bytes.
11)
The Length field is encoded in one byte , with bit 8 set to 1 (indicating the presence of the
Length field). The remaining seven bits are encoded as a fixed-length, unsigned integer, the
value of which represents the number of bytes in the contents field.
The number of bytes of the encoding is determined by the value to be encoded: it is equal to
the minimum number of necessary bytes which is required to represent the given value.
The encoding of the value is a two’s complement binary number equal to the integer value, and
consists of bits 8 to 1 of the first byte, followed by bits 8 to 1 of the second byte, followed by
bits 8 to 1 of each byte in turn, up to and including the last byte of the encoding – as specified
also for fixed-length, signed integers (6.1.1.2). The structure of a variable length integer
encoding is shown in figure 4.
st th th
1 byte of value i byte of value n byte of value
87654321 87654321 87654321
1XXXXXXX XXXXXXXX . XXXXXXXX
Length (=n) Contents
Length is present
Figure 4 – Structure of the variable-length integer encoding
Examples of A-XDR encoding of variable-length integers
a) Encoding of the 0 (zero) value is as follows:
No Length is present
b) Encoding of the –1 value is as follows:
87654321 87654321
10000001 11111111
Length (=1) Contents
Length is present
——————
11)
The value of the Length field thus can be any value between 0.127, which allows the encoding of INTEGERS
represented in maximum 1016 bits.

61334-6 © IEC:2000 – 27 –
c) Encoding of the 128 value is as follows:
st nd
1 byte of value 2 byte of value
87654321 87654321 87654321
10000010 00000000 10000000
Length (=2) Contents
Length is present
d) Encoding of the –128 value is as follows:
st nd
1 byte of value 2 byte of value
87654321 87654321 87654321
10000010 11111111 10000000
Length (=2) Contents
Length is present
6.2 Encoding of a BOOLEAN value
A BOOLEAN type may take only two values: it is either TRUE or FALSE. A-XDR encoding of a
BOOLEAN value contains only the Contents field, which consists of one byte. If the value to be
encoded is FALSE, this byte is zero (all bits are zero), otherwise – when the value is TRUE –
this byte can be any non-zero value, as a sender’s option.
Example
A-XDR encoding of the FALSE BOOLEAN value is as follows:
A valid encoding of the TRUE BOOLEAN value is as follows:
61334-6 © IEC:2000 – 29 –
6.3 Encoding of an ENUMERATED value
The value range for the ENUMERATED type is restrained for A-XDR encoding between 0.255.
A-XDR encoding of an ENUMERATED value shall be that of the constrained INTEGER(0.255)
value encoded as a fixed-length, unsigned integer in one byte.
6.4 Encoding of a BIT STRING value
A-XDR provides two types of encoding for the ASN.1 BIT STRING type, depending on whether
the ASN.1 definition of the BIT STRING specifies the size of the BIT STRING or not. Fixed-
length encoding is provided when the size of a BIT STRING is specified in the ASN.1 definition,
while BIT STRINGS with no specified size are encoded in variable-length manner. In both
cases, the encoding of a BIT STRING value is aligned on byte boundary by adding 0 value
trailing bits.
6.4.1 Fixed-length encoding for specified size BIT STRING values
If the size of the BIT STRING is specified in the ASN.1 description, the A-XDR encoding of that
BIT STRING contains only a Contents field. The number of bytes in the Contents field is
determined by the specified size: it is equal to the minimum number of necessary bytes to
convey the number of bits in the BIT STRING.
Example
BIT STRING(SIZE(3)) is encoded in 1 byte
BIT STRING(SIZE(8)) is encoded in 1 byte
BIT STRING(SIZE(14)) is encoded in 2 bytes
The bits in the BIT STRING, commencing with the first bit and proceeding to the trailing bit(s),
shall be placed in bits 8 to 1 of the first subsequent byte, followed by bits 8 to 1 of the second
subsequent byte, followed by bits 8 to 1 of each byte in turn, followed by as many bits as are
needed of the final subsequent byte, commencing with bit 8.
Each byte of the encoding, with the exception of the last, shall contain eight bits of the BIT
STRING. The last byte of the encoding shall contain the remaining bits of the BIT STRING
followed by 0 value trailing bits.
Example
A-XDR encoding of the 01100111 01010 value of BIT STRING(SIZE(13)) is as follows:
st nd
1 b y te 2 b y te
87654321 87654321
01100111 01010000
Bits of the BIT STRING
Trailing bits
61334-6 © IEC:2000 – 31 –
6.4.2 Variable-length encoding for non-specified size BIT STRING values
A-XDR encoding of a BIT STRING value when the size of the BIT STRING is not specified in
the ASN.1 definition contains two fields: a Length field and a Contents field.
The value represented by the Length field is equal to the number of bits in the encoded value
of the BIT STRING. The Length field itself is encoded similarly to the variable-length integer
encoding, except that (because negative values have no meaning for the Length field) integers
are encoded as binary numbers and not as two's complement binary numbers. (It is like an
encoding for variable-length unsigned integers.)
The Contents field conveys the encoded value of the BIT STRING, and contains an integral
number of bytes. Encoding rules for this field are the same as specified for the fixed-length BIT
STRING values in 6.4.1.
Example
A-XDR encoding of the 01100111 01010 value of a BIT STRING is as follows:
st nd rd
1 b y te 2 b y te 3 b y te
87654321 87654321 87654321
00001101 01100111 01010000
Bits of the BIT STRING
Length (=13 )
Only the value of the Length is Trailing bits
encoded in one byte
Example
A-XDR encoding of a BIT STRING value consisting of 131 bits is as follows:
th
st nd rd th
N byt e
1 b y te 2 b y te 3 b y te X b y te
87654321 87654321 87654321 87654321 87654321
10000001 10000011 XXXXXXXX . XXX00000
Length of the Encoding of the Bits of the BIT STRING Trailing
Length Length (= 131 ) bits
encoding (=1)
The Length field of the BIT STRING The Contents field of the BIT STRING
The Length information is encoded in more
than one byte
6.5 Encoding of an BYTE STRING value
A-XDR provides two types of encoding for the ASN.1 BYTE STRING type, depending on
whether the ASN.1 definition of the BYTE STRING specifies the size of the BYTE STRING or
not. Fixed-length encoding is provided when the size of the BYTE STRING is specified in the
ASN.1 definition, while BYTE STRINGS with no specified size are encoded in variable-length
manner.
61334-6 © IEC:2000 – 33 –
6.5.1 Fixed-length encoding for specified size BYTE STRING values
If the size of the BYTE STRING is specified in the ASN.1 description, the A-XDR encoding of
that BIT STRING contains only a Contents field. The number of bytes in the Contents field is
equal to the specified size.
The bytes in the BYTE STRING, commencing with the first byte and proceeding to the last byte
shall simply be placed in the bytes of the Contents field.
Example
A-XDR encoding of the value of "ABCD" BYTE STRING(SIZE(4)) is as follows:
st nd rd th
1 b y te 2 b y te 3 b y te 4 b y te
87654321 87654321 87654321 87654321
01000001 01000010 01000011 01000100
Bytes of the BYTE STRING
6.5.2 Variable-length encoding for non-specified size BYTE STRING values
A-XDR encoding of an BYTE STRING value when the size of the BYTE STRING is not
specified in the ASN.1 definition contains two fields: a Length field and a Contents field.
The value represented by the Length field is equal to the number of bytes in the Contents field.
The Length field itself is encoded exactly in the same way as specified for the Length field
encoding of variable-length BIT STRINGS (see 6.4.2).
The Contents field conveys the encoded value of the BYTE STRING. Encoding rules for this
field are the same as specified for the fixed-length BYTE STRING values in 6.5.1.
Example
A-XDR encoding of the "ABC" value of an BYTE STRING is as follows:
st nd rd th
1 b y te 2 b y te 3 b y te 4 b y te
87654321 87654321 8765432 87654321
00000011 01000001 01000010 01000011
Length (= 3 ) Contents = bytes of the BYTE STRING
Only the value of the Length is encoded
on one byte
61334-6 © IEC:2000 – 35 –
Example
A-XDR encoding of an BYTE STRING value consisting of 347 bytes:
nd
12)
st rd th th
1 b y te 2 b y te 3 b y te 4 b y te X byte n b y te
87654321 87654321 87654321 87654321 8.1 87654321
10000010 00000001 01011011 XXXXXXXX X.X XXXXXXXX
Encoding of the Length (= 347) Bytes of the BYTE STRING
Length of the
Length
encoding (=2)
= 0x015B
The Length field of the BYTE STRING The Contents field of the BYTE STRING
The Length information is encoded in more than
one byte
6.6 Encoding of a CHOICE value
One of the principal concepts of A-XDR is that, when both the sender and the receiver of a
message operate the same abstract syntax, in most cases the Identifier field of a BER
encoding conveys redundant information. In these cases, not encoding the Identifier field does
not result in unambiguous encoding. Consequently, A-XDR encoding does not systematically
encode the identifier for ASN.1 types.
The CHOICE ASN.1 type is defined in terms of a collection of component types, its
alternatives, which must all be distinct. Each value of a CHOICE type is a value of just one of
13)
the alternatives . The encoding rules should ensure that the encoded value of any of the
alternatives might be unambiguously identified – therefore A-XDR encoding of a value of a
CHOICE type shall contain an identifier field.
To ensure unambiguity, all component types of the ASN.1 specification of a CHOICE type
14)
should be an explicitly tagged type. CHOICE types with not explicitly tagged components
cannot be encoded in A-XDR.
A-XDR encoding of a CHOICE value shall be the A-XDR encoding of a value of the chosen
alternative type preceded by the identifier (tag), encoded in one byte as a fixed-length unsigned
integer.
Example
Taking the following ASN.1 CHOICE structure:
Dummy_PDU::= CHOICE {
a [0] INTEGER,
b [1] BYTE STRING(SIZE(4))
}
——————
12)
n = size of (Length field in bytes) + size of (Contents field in bytes) = 3 + 347 = 350
13)
The ASN.1 CHOICE type is similar to the C UNION type.
14)
The term 'tag' will be defined in 6.7.

61334-6 © IEC:2000 – 37 –
A-XDR encoding of the value of that CHOICE type when the ‘a’ alternative is chosen, and
a = 3715 is as follows:
st nd rd th
1 b y te 2 b y te 3 b y te 4 b y te
87654321 87654321 87654321 87654321
00000000 10000010 00001110 10000011
Identifier Length (=2) Contents
Length is present
Tag encoding Variable length INTEGER encoding (3715 = 0xE83)
When the ‘b’ alternative is chosen, with the value of b = "ABCD", A-XDR encoding of the value
of the CHOICE type is as follows:
st nd rd th th
1 b y te 2 b y te 3 b y te 4 b y te 5 b y te
87654321 87654321 87654321 87654321 87654321
00000001 01000001 01000010 01000011 01000100
Identifier Contents
Tag encoding Fixed length BYTE STRING encoding
6.7 Tagged types (implicit, explicit and ASN.1 explicit tagging)
Coming back to the Dummy_PDU, specified in 6.6:
Dummy_PDU::=CHOICE {
a [0] INTEGER,
b [1] BYTE STRING(SIZE(4))
}
The notations [0] INTEGER and [1] BYTE STRING (obtained by preceding the original type
notation by a number in square brackets) is the ASN.1 type notation for tagged types. Tagging
serves to ensure distinctness.
In fact, every ASN.1 type (even the built-in ASN.1 types like INTEGER, BIT STRING, etc.) has
15)
a tag . Four distinct tag classes are specified, and each tag within its class is numbered with
a non-negative integer. The four classes are: universal, context-specific, application-wide and
private-use. Built-in ASN.1 types have tags in the universal class and are called base types.
The tags of all classes other than universal serve to form tagged types.
Every tag is either implicit or explicit. The selection can be made in the tagged type notation by
adding the keyword IMPLICIT or EXPLICIT between the "]" and the base type. If neither
keyword appears, th
...