Comparison of DLMS / COSEM, SML and TEC 61850 communication protocols for smart metering applications Comparison of DLMS/COSEM, SML and IEC 61850 ‘communication protocols for smart metering applications Communication technologies are playing an increasingly important role in the growing AMI market. The article is a complete analysis and comparison of four application-level protocols used for smart metering. The following protocols are considered: DLMS/COSEM, SML (Smart Message Language), as well as MMS and SOAP mapping IEC 61850. ‘The work focuses on the use of these protocols in conjunction with the TCP/IP stack. The protocols are first compared with respect to qualitative criteria, for example, the ability to synchronize time, etc. After that, the message size is compared and the coding efficiency is analyzed AMI (Advanced metering infrastructure) is an integrated system of ‘smart metering devices, communication networks and data ‘management systems that includes two-way communication between the service provider and the consumer, | Introduction The number and size of AMI systems is growing rapidly. They consist of smart metering devices located in homes and maintaining two-way communication with the service provider, The introduction of such systems is mainly associated with the achievement of the following three goals: = Providing consumers with information about their consumption and costs, thus contributing to a more © 2022 - EmptyQ Comma)economical use of resources; * Reallocation of resource use from periods of high load to periods of low load. * Build an infrastructure that can readily be used by other smart grid applications in the distribution grid, Communication in smart metering devices is the subject of several standardization works ( eg [1)) and part of national smart grid roadmaps [2, 3]. But until now, most of the installed AMI equipment uses proprietary protocols that do not comply with open or international standards. In the future, however, there is a need to focus on open standards. This will create competition in the free market and reduce the cost of equipment This article compares four different smart metering application protocols. These are SML ( Smart Message Language, IEC 62056-58 Draft ) [4], DLMS/COSEM ( IEC 62056-53 [5] and/EC 62056-62 [6)), as well as MMS [7] and SOAP [8] mapping for the IEC 61850 standard Previously, smart metering protocols have already been analyzed from various points of view. Thus, work [9] provides a general overview of the most common protocols for smart metering of consumption at all levels. Reference [11] compares DLMS/COSEM with IEC 60870-5-104. Work [12] provides a detalled analysis of DLMS/COSEM. This article compares DLMS/COSEM, SML and IEC 61850 for the first time in terms of quality criteria and coding efficiency. The article is organized as follows. The second section discusses common network topologies used in smart metering. Indicates where the protocols in question can be Used, The third section discusses the qualitative criteria by Which protocols are analyzed and compared in the fourth section. The fifth section analyzes the message size and coding efficiency of the protocols under consideration. The conclusion is a conclusion. | Communication topology of smart metering systemsTo organize communication in AMI systems, various network ‘topologies are used. However, most topologies can be derived from the general form shown in . In this figure, metering devices for gas, electricity, water, heat are connected to the so-called "house gateway’, through which an interface to the outside world is realized. In most cases, this gateway is actually integrated into an electricity meter. He will note that 988, walter and heat meters are special in the sense that they are mainly powered by autonomous sources, This feature should be taken into account when choosing communication protocols for the line ( b). The gateway (or electricity meter) can be connected to a data collection system on the side of the service provider, either directly through an Internet connection ( ¢) or through a data concentrator ( d and e) - where d is usually either a power line or @ wireless medium radius of action. The application-level protocols considered in this article can Use the TCP/IP protocol stack for data exchange, therefore they are suitable for organizing communication via an Internet connection (¢ and e ), and can also be applied for data exchange in local networks such as Ethernet and WiFi ( 2). In addition, some of the protocols under consideration support data exchange using other _lowerlevel_ protocols. DLMS/COSEM supports UDP, HDLC, M-Bus and various power line communication protocols such as IEC 61334-5. SML supports serial line and M-Bus communication, MMS and ‘SOAP do not support additional lower layer protocols. This section describes the qualitative criteria by which the protocols will be analyzed and compared in the fourth section, A. Support for various types of informationThe application protocols used for smart metering can be compared with respect to their support for the transfer of different types of information. For AMI systems, as a rule, communication technologies are needed to transfer the following types of information: = Measurement results . Naturally, all considered protocols support the transfer of measured data (energy, power, voltage, volume, etc.) But protocols can differ in their support for such types of information as: = Load profiles . The meter can store load profiles ( for example , with a resolution of 15 minutes) Therefore, the protocols must be able to transfer these profiles, if necessary with appropriate timestamps: = Digital signature . Measurement results can be digitally signed in order to prove the integrity of the data to third parties. = Glock synchronization information Time synchronization is important for metering devices that store load profiles or for metering devices that quickly switch, based on a schedule, between tariff registers. = Firmware update. Since gateways ot metering devices, as well as their communication modules, become more and more complex, the function of remote firmware Update looks quite useful, which allows you to fix errors or add new functionality = Cost information . The transmission of cost information can be implemented in several ways. Analysis of various approaches to the transmission of tariffs and comparison of protocols was done in [13]. This article does not analyze the protocols in relation to their tariff support B. Possibility of proactive transferApplication protocols can follow the strict client-server principle, in which case the connection or association is only established by the client. The server represents a device that stores the metering device data (for example, the metering device itself), and the client represents a device that wants to access this data or set any parameters in the server device. Protocols can also be based on the peer-to-peer principle, in this case, two objects between which information is transferred have equal opportunities. An object can play the role of a client or a server at any time. This principle allows more flexible use of the protocol, since metering devices have the ability to send data to other devices without the need to establish a connection from the client's side. C. Availability of an interface object model In clientserver-oriented protocols DLMS/COSEM and IEC 61850, the server contains what is called an interface object model that represents the server device ( for example, metering device). This model is built using an object-oriented approach and acts as a visible information interface for 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 structure and functionality of the server. In this case, the server is said to be describing itself. On the one hand, the retrievable interface object model simplifies the data exchange mechanism, in the sense that the client can be programmed to automatically match different models. On the other hand, this model consolidates the client- server structure, since the server always contains the front- end object mode. D. Built-in security mechanisms Most installed smart metering devices require more attention in terms of the security of AMI systems. A protocol may have builtin security mechanisms such as encryption, or it may leave this procedure for lower layer protocols such asTransport layer security (TLS). IV. Qualitative analysis ASML SML ( Smart Message Language ) was developed as part of the SyM 2 ( Synchronous Modular Meter) project [14]. SML is Widely used in Germany and is part of a large smart metering standardization work [15]. Until now, SML is rarely used outside of Germany, but this may change if efforts to promote ‘the SML protocol as an international standard prove successful. However, it will be useful to compare the international standards DLMS/COSEM and IEC 61850 with the SML protocol. Since such a comparison can lead to valuable improvements in the international standards in question SML differs from DLMS/COSEM and IEC 61850 in that it defines messages instead of defining an interface object model and accessing services. SML uses a form similar to ASN.1 to define the hierarchical structure of messages. Messages are encoded with a special cipher, which will be discussed in the fifth section. There can be two types of messages, or a request or a response, However, a reply message can be sent without a request. Thus, SML does not follow strict client-server architecture principles and metering devices can issue proactive messages. The message format supports transmission of load profiles and associated digital signatures. It is also possible to transfer a new firmware image and synchronize the clock, but these procedures are described in other standards (for example [14 SML has no builtin security mechanisms other than simple Username and password fields in SML messages. SSL/TLS can be used to transfer data over TCP/IP. B. DLMS/COSEMDLMS ( Device Language Message Specification) and COSEM ( COmpanion Specification for Energy Metering ) together form the DLMS/COSEM application protocol [5] and the interface model for metering applications [6]. Using the intermediate layer defined in [16], DLMS/COSEM can be used to transfer data over TCP/IP and UDP/IP. DLMS/COSEM is based on a strict, client-server architecture. The server is a metering device, and the client is a device that gets access to the metering device. The client, for example, can be a gateway or data collection device on the side of a service provider. Other options are also possible, for example, when the server is located directly in the gateway, and the client is on the side of the service provider. Before exchanging information containing actual measurements, it is necessary to establish 2 so-called association. This operation is initiated by the client. Once the association is established, the DLMS client can access the front-end object model residing on the server. Once the association is established, the DLMS server can send notifications to the client without an explicit request. DLMS/COSEM supports clock synchronization and transfer of measurement profiles. Until now, the DLMS/COSEM described in [5] and [6] does not support the transfer of digital signatures along with the measurement data, nor does it support the loading of a new version of the firmware, However, this functionality will be supported in the future. There are already objects for carrying out the operation of Updating the firmware, described in the blue book of the 10th edition. Support for digital signatures is in the works by DLMS UA DLMS/COSEM includes services for authentication and privacy based on symmetric encryption. However, this protocol does not support TLS/SSL, which could be used to implement the above-mentioned services using an asymmetric key. Support for asymmetric encryption is under development by the second working group of the thirteenthtechnical committee of the CENELEC organization, ¢.1EC 61850 IEC 61850 MMS and SOAP mapping do not differ in terms of support for the quality criteria discussed in this paper. Therefore, everything said below will be true for both protocols IEC 61850 is a group of standards designed specifically for Use in substation automation. The standard has now been expanded to cover the management of hydroelectric power plants [17], wind turbines [18] and other distributed energy resources [19]. In [19], DLMS/COSEM and ANSI C12.19 are referred to as standards used for custody transfer. IEC 61850, applies where there are no custody transfer requirements. This distinction between custody transfer and other types of accounting appears to be more political than technical. As ‘there is no technical reason not to use IEC 61850 as a custody transfer protocol IEC 61850 operates on the same client-server architecture principles as DLMS/COSEM. The server contains an interface object model that is accessible through standardized services. How these services are transmitted depends on the mapping used (for example, MMS or SOAP). The IEC 61850 interface object model consists of freely composable logic devices (LD). Logical devices are made up of one or more logical nodes (LN). IEC 61850-7-4, for measurement, defines the logical node MMRT. Together with logging and/or reporting services, these logical nodes can be Used to transfer load profiles. Digital signatures are not part of a logical node and are therefore not supported. The mechanism for updating the firmware is also not supported by this standard, Both MMS and SOAP mappings use SNTP to synchronize time, When MMS mapping is used, the server can send data without an explicit request, through the IEC 61850 reporting mechanism. The association and thus an open TCP socket connection must be initiated by the client in advance. SOAP‘mapping does not support active reporting by the server. Neither MMS nor SOAP mapping have builtin security mechanisms. This functionality is left to the TLS/SSL. protocol ‘as recommended in [20]. D. Comparison Table 1 provides information on the support of certain qualitative criteria of the protocols under consideration. The main difference between SML and the other two protocols is ‘that SML is not based on an interface object model, and thus it does not emphasize standardization at the functional level. On the one hand, this allows more flexibility in the use of the protocol, on the other, it means that the details (for example, the types of messages supported by the devices) must be defined in other standards in order to ensure interoperability SML is the only protocol supporting the transfer of digital signatures. Table 1 - Comparison of SML, DLMS/COSEM and IEC 61850 protocols DLMS/COSEM has the advantage over SML that it is already an international standard that is widely used in Europe. Numerous teams ate working to add missing options to this standard. The fact that DLMS/COSEM defines its own security mechanism is not necessarily an advantage. Since the functionality related to security is limited only by the use of encryption with a symmetric key. If metering devices combined their measurement results with digital signatures, ‘then one way or another, they would need asymmetric keys and could use the same key pairs for SSL/TLS, if allowed. IEC 61850, compared with other standards, can be applied not only for smart metering, but also for other smart grid applications. However, there is currently not enough interest, 10 make this protocol more functional for smart metering applications. V. Analysis of effectivenessIn the previous section, the protocols were analyzed against qualitative criteria. This section analyzes the effectiveness of the various protocols. In particular, the total number of bytes transmitted by each protocol is considered, In this case, comparing protocols is not a trivial task, because all protocols, support the transfer of different types of information using different message structures and different encryption schemes. For this reason, one operation, namely access to instantaneous readings, was chosen for the comparison of protocols in the next subsection, followed by a subsection on various encryption schemes. A. Access to instantaneous readings Obtaining Instantaneous measured values is a fundamental operation supported by all protocols. For this reason, this operation was chosen as the basis for comparison. 1. we describe the mechanism for obtaining readings from metering devices for each protocol, and then compare the sizes of their messages. The four protocols under consideration use the following methods to access Instantaneous readings: = SML defines a GetList message for getting instantaneous measured values. The request message contains the names of the parameters or parameter lists, to be read. The response contains the requested list of values. Two scenarios will be analyzed = SML metering device or gateway are pre- parameterized with a list of parameters to be read together. Thus, in order to get all the parameters/values associated with the list name, it will be enough to send the server the name of this, list. = The meter or gateway is not pre-parameterized and explicit requests are required to obtain the desired readings. = PIMSICN SEM defines 2 GET service far ahtaininninstantaneous readings. Get-Request can contain a list of so-called COSEM Attribute Descriptors that uniquely define the exact parameters to be read. The response, in this case, contains a list of parameter values without repeating the associated descriptor. = IEC 61850 offers services for managing and accessing so-called datasets, In this way, a dataset containing an arbitrary number of data points can be dynamically created. Subsequently, the dataset can be retrieved quite efficiently using the GetDataSetValue service. Next, the message sizes of the corresponding requests and responses are determined. More precisely, the equations are determined by which the size of the TCP SDU ( Service Data Unit ) is calculated depending on the number of measured values requested. Several parameters in the request and response messages are of variable length. For this reason, the parameters with the shortest length are always selected. In addition, using the considered protocols, you can request a fairly large amount of data. Therefore, in order to compare the protocols, a request for measurement values in the form of, four bytes of integers will be considered. The packet size is determined in part from the implementation of the actual communication protocols [21] and traffic capture, and also in part using analytical models. For SML, the size of the TCP SDU of request and response messages is calculated as follows: SML Req = SML TP V1 + Openfeq + GetListReq + CloseReq + ‘StuffedBits SML Res = SML TP V1 + OpenRes + GetListRes + CloseRes + StuffedBits ‘SML can potentially be used with different encoding schemes, but in practice, only SML Binary Encoding is used. For a scenario with not previously parameterized parameters, the size of GetListReqPDU in bytes to transfer x values, using the SMI Binary Encoding, can be calculated as follows: SML Req = 16 + 28 + 30x + 19 + 0 SML Res 6+ 27+ ASK + 1940The following equations are valid for a scenario with pre- parameterized parameters: SML Req = 16 + 28 + 30 +19 + 0 SML Res 6 +27 + (26+ 19x) +19 +0 Composition and size of TCP SDU DLMS/COSEM, on transmission x values are described by the following equations: DLMS Req = TCP Wrapper + GetReqWithList = +441) DLMS Res = TCP Wrapper + GetResWithList = 8 + (4 + 6x) TCP SDU composition and size MMS: MMS Req = RFC 1006 and ISO 8073 + ISO 8327 Session + ISO Presentation + MMS GetListReqPDU = 7 +4 +9 + 44 MMS Res = RFC 1006 and ISO 8073 + ISO 8327 Session + ISO Presentation + MMS GetListResPD\ +4494(10+6x) Composition and size of TCP SDU SOAP: SOAP Req = SOAP Header + SOAP Req XML = 197 + 236 SOAP Res = SOAP Header + SOAP Res XML = 113 + (175 + 32x) The resulting message sizes are shown in Table 2 . In addition, the size of the response message is plotted in. This figure shows that DLMS and MMS are the most efficient protocols in terms of message size. Keep in mind, however, that DLMS and IEC 61850 require an association in order to exchange messages. The SML protocol does not require an association. The overhead costs associated with establishing ‘the association were not included in these calculations. However, they can be neglected if the association is established once and maintained over a long period of time. Table 2 - Size of the TCP data field in bytes as a function of the number of requested values (x). B. Comparison of binary encodings All protocols, MMS, DLMS/COSEM and SML use byte binary encoding to encode thelr messages. This section compares,directly, encodings. The MMS protocol uses ASN.1 BER encoding to encode messages. DLMS/COSEM also uses BER encoding for association messages, however, after the association is established, special encoding rules are used, the so-called A- XDR, defined in [22]. A-XDR rules were designed to reduce the amount of information compared to BER and only apply to encoding a subset of ASN.1. SML, in turn, also defines new encoding rules called SML Binary Encoding. The goal is the same as for the A-XDR - reducing the message size compared to the BER. When using BER encoding, usually one byte is, required for the field responsible for the value type, and one byte for the field containing information about the length of the encoded value, n the case of SML Binary Encoding, where possible, ype and length are encoded in one byte, In AXXOR, value type and length fields are omitted altogether where possible. The three binary encodings discussed are compared by encoding the GetDataValues MMS response message. Table 3 shows the number of bytes required to encode the various components of an MMS message. Table 3 - Comparison of message lengths for different encodings (in bytes) As can be seen from Table 3, A-XDR requires the smallest number of bytes to encode a packet. AXDR encodes as efficiently as BER, and in some cases, except for unselected extra fields, even better. SML Binary Encoding does not encode with the smallest number of bytes in all cases. This is due to the fact that the tags in the selection are encoded with at least two bytes. All the "efficiency" of A-XDR and SML Binary Encoding is related to the type and length fields. The actual values are encoded in an equal number of bytes. Vi. Conclusion In this work, the most significant quality criteria for the application level protocol used for smart metering weredetermined. Comparison of DLMS/COSEM, SML and IEC 61850 protocols showed that there is no single protocol that is best in all aspects. Analysis and comparison of message size showed that DLMS and MMS IEC 61850 are clearly superior to all others, Both DLMS/COSEM and SML use special encodings for more efficient encoding than BER, however SML Binary Encoding has significant drawbacks When encoding ASN.1 element selection tags. A-XDR does a good job of reducing the overhead caused by type and length fields. In the future, it would be interesting to make @ similar comparison for promising protocols such as ZigBee Smart Energy 2.0 and ANSI 12.19, Bibliography = E, Commission, “M/441 EN, standardization mandate to CEN, CENELEC and ETSI in the field of measuring instruments for the development of an open architecture for utility meters involving communication protocols enabling interoperability” Mar. 2009. = NIST, "NIST framework and roadmap for smart grid interoperability standards, release 1.0 2010. = DKE, "Die deutsche normungsroadmap E-Energy/Smart grid” Apr. 2010. = SP Group, “Smart message language (SML) v. 1.03, “Dec. 2008. = “IEC 62056-53 - data exchange for meter reading, tariff and load control - part 53: COSEM application layer” 2006. 1 "IEC 62056-62 - data exchange for meter reading, tariff 2006. and load control - part 62: Interface classes, = “IEC 61850-8-1 ed1.0 - communication networks and systems in substations - part 81: Specific ‘communication service mapping (SCSM) - mappings to MMS (180 9506-1 and 1S0 9506-2) and to ISO/IEC 8802-5, may 20U8 “EC 61400-25-4 ed1.0 - wind turbines - part 25-4 Communications for monitoring and control of wind power plants - mapping to communication profile” 2008. KD Craemer and G. Deconinck, “Analysis of state-of-the. art smart metering communication standards” Leuven, 2010. S. Mohagheghi, J. Stoupis, Z. Wang, Z. Li, and H. Kazemzadeh, “Demand response architecture Integration into the distribution management system: in Smart Grid Communications (SmartGridGomm), 2010 First IEEE International Conference on, 2010 , pp. 501- 506. 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, 1, 2, pp. 604-613, 2009. 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 Intemational Conference on, 2010, pp. 67-72. S. Feuerhahn, M. Zillgith, and C. Wittwer, “Standardized communication of Time-ofUse prices for intelligent energy management in the distribution grid” in VDE Kongress 2010 - E-Mobilit, Leipzig, Germany, Nov. 2010. SyMProjectGroup, “SyM - general specification for synchronous modular meters," Oct. 2009. VDE, “Lastenheft MUC - multi utility communication, version 1.0° May 2009. “IEC 62056-47 - data exchange for meter reading, tariff and load control - part 47: COSEM transport layers for IPv4 networks,’ 2006. 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. “IEC 61400-25-2 ed1.0 - wind turbines - part 25-2: Communications for monitoring and control of windpower plants - information models,” Dec. 2006. “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, “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, “OpenMUC - software platform for energy gateways,” wiwopenmucorg , 2011. [Online]. Available: wwvwopenmuc.org “IEC 61334-6 - distribution automation using distribution line carrier systems - part 6: A-XDR encoding rule” 2000,