Comparison of the Communication Protocols DLMS/COSEM, SML and IEC 61850 for Smart Metering Applications

Stefan Feuerhahn , Michael Zillgith , Christof Wittwer and Christian Wietfeld

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
Dept.

AbstractCommunication 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 rst 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 ofce 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 dened 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 different ways in the past. In [9] a general overview of the most common smart metering protocols at all layers is presented. In [10] protocols were briey 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 rst to compare DLMS/COSEM, SML and IEC 61850 based on qualitative criteria and coding efciency. 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 efciency 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 gure 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

Electricity Meter

Home Gateway
d

c e

Utility

Gas/Water/ Heat Meter

Concentrator

Protocols can also be based on a peer-to-peer principle in 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 exible 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

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 information. 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 investigation support the communication of measured data such as energy, power, voltage, or volume. But the protocols can differ by their support for: Load Prole - A meter could store load proles (e.g. with a resolution of 15 min.). The protocol would need to support the transmission of these proles, 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 proles 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 becomes useful to be able to update the rmware remotely to x vulnerabilities or add features. Pricing Information - Communication of pricing information 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.

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 denes messages instead of dening 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 proles and their associated digital signatures. The communication of new rmware 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 elds inside the SML messages. For communication over TCP/IP, the SSL/TLS protocol can be used. B. DLMS/COSEM The Device Language Message Specication (DLMS) and COmpanion Specication for Energy Metering (COSEM) form together the DLMS/COSEM application layer communication protocol [5] and an interface model for metering applications [6]. Using the wrapper layer dened 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 ofce. Other use cases where the server is within the gateway and the client is in the central ofce 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 notications to the client without an explicit request. DLMS/COSEM supports clock synchronization and transmission of measurement proles. So far DLMS/COSEM as standardized in [5] and [6] neither supports the transmission of digital signatures with measurement data nor a rmware download. Both will be supported in the future. Data objects for rmware 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 condentiality 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 principle as DLMS/COSEM. The server includes an interface object model which can be accessed through standardized services.

TABLE I Q UALITATIVE C OMPARISON OF SML, DLMS/COSEM, AND IEC 61850 Protocols Feature Load Prole Digital Signature Clock Synchronization Firmware Update Push Metering Data Interface Object Model Includes Security Mechanisms SML X X -1 X O O DLMS X -2 X -2 O2 X X IEC 61850 X X 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 denes the LN MMRT for metering. Combined with the logging and/or reporting services this LN can be used to transmit load proles. Digital signatures are not part of the LN and are thus not supported. A rmware 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 summarized in Table I. The most signicant 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 exibility in the use of the protocol but also means that details (e.g. the message types supported by a device) have to be specied 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 species 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 efciency 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 instantaneous 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 application 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 described for each protocol separately then their message sizes are compared. The four protocols use the following methods to access the instantaneous meter readings: SML species 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 parameters/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 species the Get service to retrieve instantaneous meter readings. A Get-Request can contain a list of so called COSEM Attribute Descriptors which unambiguously dene 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

arbitrary number of data points can be dynamically created. Afterwards the data-set can be retrieved using the GetDataSetValues service in an efcient 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 trafc 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 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) 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). (2) (1)

TABLE II TCP PAYLOAD SIZE IN BYTES AS A FUNCTION OF THE NUMBER OF MEASUREMENT VALUES REQUESTED ( X ) Protocols Message Type Request Response SML 63 + 30x 62 + 45x SML preparametrized 93 88 + 19x DLMS 12 + 11x 12 + 6x IEC 61850 MMS 64 30 + 6x IEC 61850 SOAP 433 288 + 32x

1600 TCP payload size in bytes 1400 1200 1000 800 600 400 200 0

SML SOAP SML-prepar MMS DLMS

TABLE III C OMPARING THE BINARY ENCODING LENGTH IN BYTES Encodings Message Type SML TL1 0 3 1 0 3 1 1 1 1 1 12 19 Val2 0 0 2 0 0 0 0 0 1 4 7 DLMS A-XDR TL 0 1 0 0 1 1 1 2 1 1 8 15 Val 0 0 2 0 0 0 0 0 1 4 7 MMS BER TL 0 2 2 0 2 0 2 2 2 2 14 21 Val 0 0 2 0 0 0 0 0 1 4 7

MMS (choice) conrmed-Resp. (Seq) invokeID: 458 (Unsigned32)

5 10 15 20 25 30

confServiceResp (choice) read (Seq) variableAccessSpec (optional) not opted ListOfAccessRes (SeqOf) AccessRessult (SeqOf) Data: boolean

Number of measurement values transfered

Fig. 2.

Response Messages

M M S Req = RF C 1006 and ISO 8073 + ISO 8327 Session + ISO P resentation + M M S GetListReqP DU = 7 + 4 + 9 + 44 M M S Res = RF C 1006 and ISO 8073 + ISO 8327 Session + ISO P resentation + M M S GetListResP DU = 7 + 4 + 9 + (10 + 6x) The composition and size of the SOAP TCP SDUs is shown in (4). SOAP Req = SOAP Header + SOAP Req XM L = 197 + 236 SOAP Res = SOAP Header + SOAP Res XM L = 113 + (175 + 32x) The resulting sizes are summarized in Table II. In addition the response message size is graphed in Figure 2. It can be seen that DLMS and MMS are the most efcient protocols with respect to message size. It has to be noted though that DLMS and IEC 61850 require an existing open association for their message exchange. SML does not need this. The overhead by the association was not taken into account for these calculations. If the association is built up once and kept up for long time periods the overhead will be negligible. (4) (3)
sum

Data: visible-str = test

sum (TL + Val)

1 2

length of the Type-Length eld length of the encoded value

B. Binary Encodings Compared MMS, DLMS/COSEM, and SML all use byte oriented binary encodings to encode their messages. In this section they are compared directly. MMS uses the BER encoding to encode the messages specied 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 dened in [22]. A-XDR can only encode a subset of ASN.1 and was developed to reduce the overhead caused by BER. SML also denes a new encoding called the SML Binary Encoding. It has the same goal as A-XDR to reduce the message size compared to the BER. Both focus on coding type and length elds more efciently than BER. While BER usually codes one byte for the type eld and one byte for the length, in SML Binary Encoding, the type and length are encoded in one byte if possible. In A-XDR the type and length elds are omitted completely where feasible. The three binary encodings are compared by encoding an MMS GetDataValues Response message. Table III shows the number of bytes necessary to code the different components of the MMS message.

As can be seen, A-XDR needs the fewest bytes to encode the packet. A-XDR encodes as efciently as BER or better in all cases except for optional elds 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 elds. The actual values are encoded with equal number of bytes. VI. C ONCLUSION In this paper the most signicant qualitative features of a smart metering application layer protocol have been identied. 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 efciently than BER but the SML Binary Encoding has signicant 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 elds. In the future it would be interesting to do a similar comparison 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, CENELEC and ETSI in the eld of measuring instruments for the development 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.

[7] IEC 61850-8-1 ed1.0 - communication networks and systems in substations - part 8-1: Specic 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 communication prole, 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, Demand response architecture: Integration into the distribution management system, in Smart Grid Communications (SmartGridComm), 2010 First IEEE International Conference on, 2010, pp. 501506. [11] A. Zaballos, A. Vallejo, M. Majoral, and J. Selga, Survey and performance comparison of AMR over PLC standards, Power Delivery, IEEE Transactions on, vol. 24, no. 2, pp. 604613, 2009. [12] T. Otani, A primary evaluation for applicability of IEC 62056 to a Next-Generation power grid, in Smart Grid Communications (SmartGridComm), 2010 First IEEE International Conference on, 2010, pp. 6772. [13] S. Feuerhahn, M. Zillgith, and C. Wittwer, Standardized communication of Time-of-Use prices for intelligent energy management in the distribution grid, in VDE Kongress 2010 - E-Mobility, Leipzig, Germany, Nov. 2010. [14] SyMProjectGroup, SyM - general specication for synchronous modular 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 gateways, 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.