Standardization, Interoperability and Coexistence & Regulation (IEEE SmartGridComm)

Comparison of the Communication Protocols

DLMS/COSEM, SML and IEC 61850 for Smart
Metering Applications
Stefan Feuerhahn∗ , Michael Zillgith∗ , Christof Wittwer∗ and Christian Wietfeld†
∗ Dept.
Electrical Energy Systems
Fraunhofer Institute for Solar Energy Systems, Freiburg, Germany
Email: stefan.feuerhahn@ise.fraunhofer.de
† Communications Networks Institute (CNI), Dortmund University of Technology, Germany

Email: christian.wietfeld@tu-dortmund.de

Abstract—Communication technology plays an increasingly
important role in the growing automated metering infrastructure
(AMI) market. This paper presents a thorough analysis and
comparison of four application layer protocols in the smart
metering context. The inspected protocols are DLMS/COSEM,
the Smart Message Language (SML), and the MMS and SOAP
mappings of IEC 61850. The focus of this paper is on their
use over TCP/IP. The protocols are first compared with respect
to qualitative criteria such as the ability to transmit clock
synchronization information. Afterwards the message size of
meter reading requests and responses and the different binary
encodings of the protocols are compared.
I. I NTRODUCTION
Advanced metering infrastructure (AMI) systems are
quickly growing in number and size. They consist of smart
meters in households that support two-way communication to
the back office of the meter service provider. The effort to
install these infrastructures is mainly driven by three goals:
1) Give consumers more feedback about their consumption
and costs and thereby promote economizing behavior.
2) Promote the shift of resource usage from times of high
demand to times of low demand.
3) Create an infrastructure that can be readily used for other
smart grid applications in the distribution grid.
Smart metering communication is the focus of several
standardization efforts (e.g. [1]) and part of national smart
grid roadmaps [2] [3]. But up to now the majority of the
installed AMIs uses proprietary protocols that do not conform
to open or international standards. In the future though it
will be necessary to focus on open standards. This will allow
competition on a free market leading to lower prices.
In this paper four different application layer protocols are
compared with regard to their support for smart metering
applications. By Application Layer we refer to the layer of
the Internet Protocol Suite, which includes the Session and
Presentation Layer of the OSI model and sits on top of TCP or
UDP. The protocols under investigation are the Smart Message
Language (SML, IEC 62056-58 Draft) [4], DLMS/COSEM as
defined in IEC 62056-53 [5] and IEC 62056-62 [6], and the
MMS [7] and SOAP [8] mappings for the IEC 61850 standard.
Smart metering protocols have been analyzed in differ-
ent ways in the past. In [9] a general overview of the
most common smart metering protocols at all layers is pre-
sented. In [10] protocols were briefly compared with respect
to their support for demand response applications. In [11]
DLMS/COSEM is thoroughly compared to IEC 60870-5-104.
In [12] DLMS/COSEM is analyzed in detail. This paper is the
first to compare DLMS/COSEM, SML and IEC 61850 based
on qualitative criteria and coding efficiency.
This paper is organized as follows: In Section II the most
common smart metering communication topologies are looked
at. It is pointed out where the protocols under investigation can
be used. In Section III the qualitative criteria are discussed by
which the protocols are analyzed and compared in Section IV.
Section V analyzes the message size and coding efficiency of
the protocols. Finally a conclusion is drawn.
II. S MART M ETERING C OMMUNICATION T OPOLOGY
Many different network topologies are being used for AMIs.
Most topologies though can be derived from the general form
displayed in Figure 1. In this figure the electricity, gas, water,
and heat meters communicate with a home gateway which
acts as the interface to the outside world. In many scenarios
this gateway is actually integrated in the electricity meter. In
this case the communication line (a) in Figure 1 will not
be needed. Gas, water, and heat meters are special in that
they are mostly battery driven. This has to be accounted for
when choosing a communication protocol for (b). The gateway
(or electric meter) can then communicate with the utility (or
metering service provider) directly over the Internet (c) or with
a concentrator as an intermediate step (d, e), where (d) is
usually a power line or mid-range wireless solution.
The application layer protocols that we look at can all be
used over the TCP/IP protocol stack and are thus applicable for
Internet communication on (c) and (e) and over local networks
such as Ethernet and Wi-Fi on (a). In addition the protocols can
be used over other lower layer protocols. DLMS/COSEM can
be used over UDP, HDLC, Meter-Bus, and different narrow
band power line protocols such as IEC 61334-5. SML can be

978-1-4577-1702-4/11/$26.00 ©2011 IEEE 410

 Electricity a Protocols can also be based on a peer-to-peer principle in
Meter
Home c
Utility
Gateway
d e
Gas/Water/ b
Heat Meter Concentrator
Fig. 1. Smart Metering Communication Topology
used over serial lines and Meter-Bus. MMS and SOAP do not
support any additional lower layer protocols.
III. Q UALITATIVE C RITERIA
In this section we describe the qualitative criteria by which
we analyze and compare the protocols in Section IV.
A. Information Type Support
Smart metering application layer protocols can be compared
regarding their support to transport different types of informa-
tion. AMIs need communication technology to usually transfer
a subset of the following information items to and from the
smart meter:
• Measured Data - Naturally all protocols under investiga-
tion support the communication of measured data such
as energy, power, voltage, or volume. But the protocols
can differ by their support for:
– Load Profile - A meter could store load profiles (e.g.
with a resolution of 15 min.). The protocol would
need to support the transmission of these profiles,
optionally with associated timestamps.
– Digital Signature - Measured data might have to be
associated with digital signatures in order to prove
the integrity of the data to third parties.
• Clock Synchronization Data - A synchronized clock is
important for meters that store load profiles or meters
that switch dynamically between tariff registers based on
a timetable.
• Firmware Updates - As gateways or meters and their
communication modules are getting more complex it be-
comes useful to be able to update the firmware remotely
to fix vulnerabilities or add features.
• Pricing Information - Communication of pricing informa-
tion can be realized in many different ways. An analysis
of different approaches to communicate tariffs and a
protocol comparison was done in [13]. This paper does
not analyze the protocols regarding their tariff support.
B. Ability to Push Metering Data
Application Layer protocols can follow a strict client-server
principle in that connections or associations can only be started
by the client. In the metering environment the server would
usually be within the device that stores the meter data (e.g.
the meter itself) and the client would be the entity that wants
to access the data or set parameters.
411
that the two communication entities have equal capabilities.
At any point in time an entity can act as a client or a server.
This principle allows a more flexible use of the protocol since
meters have the capability to send (actively push) data to others
without the need of an open association that was started by
the client.
C. Availability of an Interface Object Model
In the client-server oriented protocols, DLMS/COSEM and
IEC 61850, the server contains what we call an interface object
model which represents the server device (e.g. the meter).
This model is built in an object oriented fashion and acts as
the visible information interface to the client. The client can
retrieve the interface object model in a standardized way using
the protocol and thus does not need to know in advance about
the exact setup and functionality of the server. We also speak
of a self-descriptive server in this case. A retrievable interface
object model can make things easier in that a client can be
programmed to automatically respond to different models. But
it also cements the client-server structure since the server
always contains the interface object model.
D. Built in security mechanisms
As more smart meters are installed the security of the AMI
systems requires more attention. A protocol can have built
in security mechanisms such as encryption or leave this to a
lower layer protocol such as Transport Layer Security (TLS).
IV. Q UALITATIVE A NALYSIS
A. SML
The Smart Message Language (SML) was developed as part
of the Synchronous Modular Meter (SyM2 ) project [14]. In
Germany SML is widely used and is part of the major smart
metering standardization effort [15]. So far SML is rarely
used outside of Germany but this might change if the effort
to make SML an international standard is successful. In any
case it will be helpful to compare the international standards
DLMS/COSEM and IEC 61850 to SML. This might lead to
valuable improvements in these existing standards.
SML is different from DLMS/COSEM and IEC 61850
in that it defines messages instead of defining an interface
object model and services to access it.1 SML uses a form
similar to ASN.1 to specify hierarchical message structures.
The messages are coded with a special encoding which will
be thoroughly discussed in Section V. A message is either a
request or a response message. But a response message can
be sent without a request. Thus SML does not enforce a strict
client-server principle and meter data can be actively pushed
by the meter.
The message format supports the transmission of load
profiles and their associated digital signatures. The communi-
cation of new firmware and clock synchronization is possible
1 Future enhancements of SML shall support access to the COSEM interface
object model but this is not considered here.

but the exact standardization is left to other standardization
bodies (e.g. [14]).
SML has no built in security except for simple username and
password fields inside the SML messages. For communication
over TCP/IP, the SSL/TLS protocol can be used.
B. DLMS/COSEM
The Device Language Message Specification (DLMS) and
COmpanion Specification for Energy Metering (COSEM)
form together the DLMS/COSEM application layer commu-
nication protocol [5] and an interface model for metering
applications [6]. Using the wrapper layer defined in [16],
DLMS/COSEM can be used over TCP/IP and UDP/IP.
DLMS/COSEM is based on a strict client-server structure.
The server is meant to be within the meter while the client
accessing the meter could be a gateway or the central office.
Other use cases where the server is within the gateway and
the client is in the central office are also feasible.
Before the actual metering information can be exchanged
an association has to be build up, which is initiated by the
client. The DLMS client can then access the interface object
model inside the server. Once an association exists the DLMS
server is also able to send notifications to the client without
an explicit request.
DLMS/COSEM supports clock synchronization and trans-
mission of measurement profiles. So far DLMS/COSEM as
standardized in [5] and [6] neither supports the transmission
of digital signatures with measurement data nor a firmware
download. Both will be supported in the future. Data objects
for firmware updates are already part of the Blue Book Ed.
10. Support for digital signatures is being worked on by the
DLMS User Association.
DLMS/COSEM includes authentication and confidentiality
services based on symmetric encryption. The protocol does not
allow the use of TLS/SSL which could realize these services
with asymmetric keys. Support for asymmetric encryption is
being worked on by CENELEC in WG 02 of TC 13.
C. IEC 61850
The MMS and SOAP mappings of IEC 61850 do not differ
regarding the support of the features analyzed here. For this
reason the following applies to both protocols.
IEC 61850 is a group of standards originally designed for
the use in substation automation. By now the standard has
been extended for controlling hydroelectric power plants [17],
wind turbines [18], and other distributed energy resources [19].
In [19] the DLMS/COSEM and ANSI C12.19 standards are
referred to for revenue metering. IEC 61850 shall only support
those metering applications that have no billing requirements.
This distinction between revenue metering and other metering
seems to be more a political than a technical decision. There
is no technical reason why IEC 61850 should not be used for
revenue metering.
IEC 61850 works according to the same client-server princi-
ple as DLMS/COSEM. The server includes an interface object
model which can be accessed through standardized services.
412
TABLE I
Q UALITATIVE C OMPARISON OF SML, DLMS/COSEM, AND IEC
61850
Protocols
Feature SML DLMS IEC 61850
Load Profile X X X
Digital Signature X -2 -
Clock Synchronization - X X
Firmware Update -1 -2 -
Push Metering Data X O2 O
Interface Object Model O X X
Includes Security Mechanisms O X O
X = is supported by this protocol
O = is not supported by this protocol
- = is not supported by this protocol but could be easily extended
1 is standardized in [14]
2 is being worked on by the DLMS User Association
How the communication of these services is realized depends
on the concrete communication mapping (e.g. MMS or SOAP)
that is being used.
The interface object model of IEC 61850 consists of freely
composable Logical Devices (LD). The LDs consist of two
or more Logical Nodes (LN). IEC 61850-7-4 defines the
LN MMRT for metering. Combined with the logging and/or
reporting services this LN can be used to transmit load profiles.
Digital signatures are not part of the LN and are thus not
supported. A firmware update mechanism is also not part of
the IEC 61850 standard. For time synchronization both the
MMS and the SOAP mapping refer to the SNTP protocol.
When using the MMS mapping, the server can send data
without an explicit request through the IEC 61850 reporting
mechanism. An association and thus an open TCP socket
connection has to be initiated by the client beforehand. The
SOAP mapping does not support the active reporting by the
server.
Neither the MMS nor the SOAP mapping has any built in
security. This is left to the TLS/SSL protocol as recommended
by [20].
D. Comparison
The support for the various qualitative features is summa-
rized in Table I. The most significant difference between SML
and the other two protocols is that SML does not rely on
an information model interface and thus does not emphasize
the standardization on the functional level. This leaves more
flexibility in the use of the protocol but also means that
details (e.g. the message types supported by a device) have
to be specified by other standardization bodies in order to
guarantee interoperability. SML is the only protocol to support
the communication of digitial signatures.
DLMS/COSEM has the advantage over SML that it is
already an international standard that is widely used in Europe.
Numerous parties are working to add missing features to
the standard. The fact that DLMS/COSEM specifies its own
security mechanism is not necessarily an advantage. This way
it restricts the security to symmetric key encryption. If meters
should combine their measured data with digital signatures the
meter would need asymmetric keys anyways and could use the
same key pairs for SSL/TLS, if this were allowed.
IEC 61850 has the advantage that it can also be used
for other smart grid applications besides smart metering.
At this moment though there does not seem to be enough
interest in making it a feature rich protocol for smart metering
applications.
V. E FFICIENCY A NALYSIS
In the previous section the protocols have been analyzed
with respect to qualitative features. In this section the ef-
ficiency of the different protocols is analyzed. In particular
the total number of bytes transmitted by each protocol is
examined. Comparing the protocols is not trivial because they
support the communication of different information types, use
different message structures, and different encoding schemes.
For that reason one application namely the access to in-
stantaneous metering readings was chosen for comparison in
the following subsection. Afterwards the different encoding
schemes are directly compared.
A. Access Instantaneous Meter Readings
Getting instantaneous meter readings is a fundamental ap-
plication that is supported by all four protocols. For that reason
it was chosen as the main application for comparison. Meter
readings can be different measurements from the same meter
(e.g. instantaneous power, total energy from electricity meter)
or measurements from several meters requested from a device
such as a gateway.
First the mechanism for retrieving meter readings is de-
scribed for each protocol separately then their message sizes
are compared. The four protocols use the following methods
to access the instantaneous meter readings:
• SML specifies the GetList message to get instantaneous
measurement values. The request message contains the
names of parameters or parameter lists that are to be read.
The response contains the requested list of values. Two
scenarios have been analyzed:
– The SML meter or gateway was pre-parameterized
with a list of parameters that are to be read together.
This way only a single list name can be sent to
the server and the response will contain all parame-
ters/values associated with that list name.
– The meter or gateway was not pre-parameterized and
all desired readings have to be explicitly requested.
• DLMS/COSEM specifies the Get service to retrieve in-
stantaneous meter readings. A Get-Request can contain
a list of so called COSEM Attribute Descriptors which
unambiguously define the exact parameters to be read.
The response then contains the list of the parameter
values without repeating the associated descriptors again.
• IEC 61850 offers services to manage and access so
called Data-Sets. This way a Data-Set containing an
413
arbitrary number of data points can be dynamically
created. Afterwards the data-set can be retrieved using
the GetDataSetValues service in an efficient manner.
In the following, the size of the respective request and
response messages is determined. More precisely, equations
for the TCP Service Data Unit (SDU) size as a function of
the number of measurement values requested are determined.
Several parameters in the request and response messages are of
variable length. In the following analysis the shortest possible
parameter length was always chosen. Many different data
points can be requested by the protocols. In order to be
able to compare the protocols we only regard the request for
measurement values in the form of four byte integers. The
packet size was determined partly by implementing the actual
communication protocols [21] and capturing the traffic and
partly by using analytical models.
For SML the TCP SDU size of the request and response
messages is composed as follows:
SM L Req = SM L T P V 1 + OpenReq
+ GetListReq + CloseReq
+ Stuf f edBits
(1)
SM L Res = SM L T P V 1 + OpenRes
+ GetListRes + CloseRes
+ Stuf f edBits
SML can potentially be used with different encoding
schemes, but in practice only the SML Binary Encoding
is used. For the non pre-parameterized scenario the size of
GetListReqPDU in bytes for the transmission of x values using
the SML Binary Encoding can be estimated by:
SM L Req = 16 + 28 + 30x + 19 + 0
SM L Res = 16 + 27 + 45x + 19 + 0
The following estimates the size in the pre-parameterized
scenario:
SM L Req = 16 + 28 + 30 + 19 + 0
SM L Res = 16 + 27 + (26 + 19x) + 19 + 0
The composition and size of the DLMS/COSEM TCP SDUs
for the transmission of x values is as follows:
DLM S Req = T CP W rapper + GetReqW ithList
= 8 + (4 + 11x)
(2)
DLM S Res = T CP W rapper + GetResW ithList
= 8 + (4 + 6x)
The composition and size of the MMS TCP SDUs is shown
in (3).
 TABLE II
TCP PAYLOAD SIZE IN BYTES AS A FUNCTION OF THE NUMBER OF MEASUREMENT VALUES REQUESTED ( X )
Protocols
Message Type SML SML preparametrized DLMS IEC 61850 MMS IEC 61850 SOAP
Request 63 + 30x 93 12 + 11x 64 433

Response 62 + 45x 88 + 19x 12 + 6x 30 + 6x 288 + 32x

1600 TABLE III

SML C OMPARING THE BINARY ENCODING LENGTH IN BYTES
TCP payload size in bytes

1400 SOAP
SML-prepar Encodings
1200 MMS
DLMS Message Type SML DLMS MMS
1000
A-XDR BER
800
TL1 Val2 TL Val TL Val
600
MMS (choice) 0 0 0 0 0 0
400
confirmed-Resp. (Seq) 3 0 1 0 2 0
200
invokeID: 458 (Unsigned32) 1 2 0 2 2 2
0
5 10 15 20 25 30 confServiceResp (choice) 0 0 0 0 0 0
Number of measurement values transfered read (Seq) 3 0 1 0 2 0
variableAccessSpec 1 0 1 0 0 0
Fig. 2. Response Messages (optional) not opted
ListOfAccessRes (SeqOf) 1 0 1 0 2 0
AccessRessult (SeqOf) 1 0 2 0 2 0
Data: boolean 1 1 1 1 2 1
M M S Req = RF C 1006 and ISO 8073 Data: visible-str = test 1 4 1 4 2 4
+ ISO 8327 Session
sum 12 7 8 7 14 7
+ ISO P resentation sum (TL + Val) 19 15 21
+ M M S GetListReqP DU 1 length of the Type-Length field
2
= 7 + 4 + 9 + 44 length of the encoded value
(3)
M M S Res = RF C 1006 and ISO 8073
+ ISO 8327 Session
B. Binary Encodings Compared
+ ISO P resentation
MMS, DLMS/COSEM, and SML all use byte oriented
+ M M S GetListResP DU
binary encodings to encode their messages. In this section they
= 7 + 4 + 9 + (10 + 6x) are compared directly.
The composition and size of the SOAP TCP SDUs is shown MMS uses the BER encoding to encode the messages
in (4). specified using ASN.1. DLMS/COSEM also uses BER for the
association messages but once associated the payload is coded
using special encoding rules called A-XDR as defined in [22].
SOAP Req = SOAP Header + SOAP Req XM L A-XDR can only encode a subset of ASN.1 and was developed
= 197 + 236 to reduce the overhead caused by BER. SML also defines a
(4) new encoding called the SML Binary Encoding. It has the
SOAP Res = SOAP Header + SOAP Res XM L
same goal as A-XDR to reduce the message size compared to
= 113 + (175 + 32x)
the BER. Both focus on coding type and length fields more
The resulting sizes are summarized in Table II. In addition efficiently than BER. While BER usually codes one byte for
the response message size is graphed in Figure 2. It can be the type field and one byte for the length, in SML Binary
seen that DLMS and MMS are the most efficient protocols Encoding, the type and length are encoded in one byte if
with respect to message size. It has to be noted though that possible. In A-XDR the type and length fields are omitted
DLMS and IEC 61850 require an existing open association completely where feasible.
for their message exchange. SML does not need this. The The three binary encodings are compared by encoding an
overhead by the association was not taken into account for MMS GetDataValues Response message. Table III shows the
these calculations. If the association is built up once and kept number of bytes necessary to code the different components
up for long time periods the overhead will be negligible. of the MMS message.

414
 As can be seen, A-XDR needs the fewest bytes to encode
the packet. A-XDR encodes as efficiently as BER or better
in all cases except for optional fields that are not opted. The
SML Binary Encoding does not code with fewer bytes in all
cases. That is because tags in choices are coded with at least
two bytes. All savings in A-XDR and SML Binary Encoding
are in the type and length fields. The actual values are encoded
with equal number of bytes.
VI. C ONCLUSION
In this paper the most significant qualitative features of a
smart metering application layer protocol have been identified.
The comparison of DLMS/COSEM, SML, and IEC 61850 has
shown that no single protocol is superior in all aspects. The
analysis and comparison of the message size has shown that
DLMS and the MMS IEC 61850 clearly outperform the rest.
Both DLMS/COSEM and SML use special encodings to code
more efficiently than BER but the SML Binary Encoding has
significant drawbacks when encoding tags of ASN.1 choice
elements. A-XDR does a good job in reducing the overhead
caused by the type and length fields.
In the future it would be interesting to do a similar com-
parison using other promising protocols such as ZigBee Smart
Energy 2.0 and ANSI C12.19.
R EFERENCES
[1] E. Commission, “M/441 EN, standardisation mandate to CEN, CEN-
ELEC and ETSI in the field of measuring instruments for the develop-
ment of an open architecture for utility meters involving communication
protocols enabling interoperability,” Mar. 2009.
[2] NIST, “NIST framework and roadmap for smart grid interoperability
standards, release 1.0,” 2010.
[3] DKE, “Die deutsche normungsroadmap E-Energy/Smart grid,” Apr.
2010.
[4] S. P. Group, “Smart message language (SML) v. 1.03,” Dec. 2008.
[5] “IEC 62056-53 - data exchange for meter reading, tariff and load control
– part 53: COSEM application layer,” 2006.
[6] “IEC 62056-62 - data exchange for meter reading, tariff and load control
– part 62: Interface classes,” 2006.
415
[7] “IEC 61850-8-1 ed1.0 - communication networks and systems in sub-
stations - part 8-1: Specific communication service mapping (SCSM)
- mappings to MMS (ISO 9506-1 and ISO 9506-2) and to ISO/IEC
8802-3,” May 2004.
[8] “IEC 61400-25-4 ed1.0 - wind turbines - part 25-4: Communications
for monitoring and control of wind power plants - mapping to commu-
nication profile,” 2008.
[9] K. D. Craemer and G. Deconinck, “Analysis of state-of-the-art smart
metering communication standards,” Leuven, 2010.
[10] S. Mohagheghi, J. Stoupis, Z. Wang, Z. Li, and H. Kazemzadeh, “De-
mand response architecture: Integration into the distribution management
system,” in Smart Grid Communications (SmartGridComm), 2010 First
IEEE International Conference on, 2010, pp. 501–506.
[11] A. Zaballos, A. Vallejo, M. Majoral, and J. Selga, “Survey and perfor-
mance comparison of AMR over PLC standards,” Power Delivery, IEEE
Transactions on, vol. 24, no. 2, pp. 604–613, 2009.
[12] T. Otani, “A primary evaluation for applicability of IEC 62056 to a
Next-Generation power grid,” in Smart Grid Communications (Smart-
GridComm), 2010 First IEEE International Conference on, 2010, pp.
67–72.
[13] S. Feuerhahn, M. Zillgith, and C. Wittwer, “Standardized communication
of Time-of-Use prices for intelligent energy management in the distri-
bution grid,” in VDE Kongress 2010 - E-Mobility, Leipzig, Germany,
Nov. 2010.
[14] SyMProjectGroup, “SyM - general specification for synchronous mod-
ular meters,” Oct. 2009.
[15] VDE, “Lastenheft MUC - multi utility communication, version 1.0,”
May 2009.
[16] “IEC 62056-47 - data exchange for meter reading, tariff and load control
– part 47: COSEM transport layers for IPv4 networks,” 2006.
[17] “IEC 61850-7-410 ed1.0 - communication networks and systems for
power utility automation - part 7-410: Hydroelectric power plants -
communication for monitoring and control,” Aug. 2007.
[18] “IEC 61400-25-2 ed1.0 - wind turbines - part 25-2: Communications
for monitoring and control of wind power plants - information models,”
Dec. 2006.
[19] “IEC 61850-7-420 ed1.0 - communication networks and systems for
power utility automation - part 7-420: Basic communication structure –
distributed energy resources logical nodes,” Oct. 2009.
[20] “IEC/TS 62351-1 ed1.0 - power systems management and associated
information exchange - data and communications security - part 1:
Communication network and system security - introduction to security
issues,” May 2007.
[21] “openMUC - software platform for energy gate-
ways,” http://www.openmuc.org/, 2011. [Online]. Available:
http://www.openmuc.org/
[22] “IEC 61334-6 - distribution automation using distribution line carrier
systems – part 6: A-XDR encoding rule,” 2000.