Performance of the XMPP and the MQTT Protocols on IEC 61850-Based Micro Grid Communication Architecture

Abstract

As micro grids are gradually being deployed in many areas, communication technology is becoming important for collecting data and controlling devices in micro grids. In a micro grid, various devices are distributed and perform their respective functions. These devices exchange information with each other and transmit information to the micro grid management system. This micro grid environment is similar to the IoT environment in which information is exchanged in the presence of a large number of devices. Recent studies have tried to apply various IoT protocols as a communication protocol in the micro grid. However, the data model used in current research is limited in proprietary data mapping. Recently, IEC TC 57 published another IEC 61850 series which maps the IEC 61850 services to XMPP (eXtensible Messaging Presence Protocol), which was the first IoT protocol mapping of IEC 61850. Few research has shown that the mapping of the IEC 61850 data model to the IoT protocol and communication boundary is limited in a lab environment. We developed a micro grid test-bed with an IEC 61850 data and service model, and mapped to two IoT protocols, that is, XMPP and the MQTT (Message Queuing Telemetry Transport). By combining IoT protocol with the IEC 61850 data and service model, the proposed micro grid architecture can provide interoperability with any DMS or other power utility system. Performance analysis was conducted on the test-bed by measuring various metrics, such as the response time, packet size, and packet loss, over a public network.

1. Introduction

Micro grids have been deployed in many areas, such as islands, schools, and hospitals. The micro grid manages the generation of Distributed Energy Resources (DERs), adjusts loads, and stores surplus power in Energy Storage Systems (ESS). Several use cases for utilizing ESS for power system control, active power scheduling, and frequency regulation are presented in [1]. A Micro Grid Management System (MGMS) performs these functions [2,3,4]. The MGMS performs several functions, including acquiring and controlling field data and managing DER, managing ESS, using EVs (Electric Vehicle), and trading power. In order for the MGMS to perform these functions, data exchange with a Distribution Management System (DMS) through a public network is inevitable. To utilize the resources in the micro grid, a power resource, as well as the information in the micro grid, needs to be gathered in a DMS or Supervisory Control and Data Acquisition (SCADA) system [5,6,7].

Internet of Things (IoT) communication protocols are closely related to the micro grid in the sense that the data are distributed over the area and prefer the publisher/subscriber paradigm. Performance of an IoT protocol has been compared only on the feature of the protocols; however, their performance analysis is limited in the lab environment or within private LANs (Local Area Networks) [8,9,10,11]. To ensure the feasibility of IoT protocol, performance analysis should be conducted in a public, wide area network. Another main stream of research on micro grids is cyber attacks in power systems [12,13,14].

In this paper, the eXtensible Messaging Presence Protocol (XMPP) and the Message Queuing Telemetry Transport (MQTT) are applied to an IEC 61850-based grid, and the most suitable protocol for the micro grid environment is derived by comparing two protocols. IEC 61850 services are mapped to a Manufacturing Message Specification (MMS) protocol for client–server-based services, such as Report, Log, and general interrogation, or directly to the Ethernet without transport layer protocols for fast delivery of messages, for example, Generic Object Oriented Substation Event (GOOSE) and sampled measured value.

Recently, IEC TC 57 published another IEC 61850 series, that is, IEC 61850-8-2, which maps the IEC 61850 services to eXtensible Messaging Presence Protocol (XMPP) [15], which was the first IoT protocol mapping of IEC 61850. All data models are encoded to eXtensible Markup Language (XML), and the message format is defined in IEC 61850-8-2. The XMPP is a standard IoT protocol in OneM2M, which is a global standard initiative for machine-to-machine communication [16]. The XMPP was developed for messaging applications and the MQTT was developed for embedded systems for light CPU loads and memory, so the MQTT is mostly applied to smart home applications [17,18]. Data Distribution Service (DDS) protocol is used as communication middleware for frequency regulation operation in [19].

We developed a micro grid test-bed using solar panels, small ESS, wind turbine, and sensors for gathering power data as well as meteorological data. The MGMS system gathers all information using IEC 61850 data and the service model. We also developed a simple DMS to request information from the MGMS. The communication between the DMS and the MGMS was performed over public, wide-area Internet over IEC 61850 mapping to IoT protocols. IEC 61850 data and service are mapped according to IEC 61850 part 8-2. IoT protocol features are compared, and some performances were measured. Security becomes important when data are exchanged over the public Internet. Both the XMPP and the MQTT offer SSL-based security, so security features are not considered in this paper.

2. Micro Grid Management System

The communication interfaces with other systems are illustrated in Figure 1. As shown in Figure 1, the micro grid management system is the heart of the micro grid system which controls the components and interacts with other systems, that is, weather forecast, energy markets, and the DMS. The MGMS integrates and performs the following functions.

• Data aggregator: Acquires data and transmits a command signal in the micro grid. To perform this function, the MGMS needs to communicate with the DMS. The MGMS exchanges or controls data with the DMS through the public network.
• Energy trading management: Purchase power from neighboring micro grids or from the power markets when the power generation inside the micro grid is low, and sell produced power to the energy market at the peak time at the market-decided price. In order for the MGMS to receive market price information and to determine bidding and sales, it is necessary to communicate with the market through the public network.
• Schedule management: Manage the schedule of DER for weather information and demand response. Solar panels and wind-power generation depend on weather conditions. Therefore, the MGMS should receive weather information through the public networks to predict and schedule the generation of the DER within the micro grid.
• Load-shifting system: Move demand in the high time zone to a low time zone.

3. Communications Architecture of Micro Grid

Physical devices in the micro grid can be divided into three parts: power generation parts, for example, solar panels and wind-power generation, local load parts, for example, buildings and households, and prosumer parts, for example, energy storage devices and EVs, as shown in Figure 2. A dotted box indicates the internal communication architecture of the micro grid.

Physical devices inside the micro grid generally use private networks due to security reasons and time-critical characteristics. In this study, we assume that it also complies with IEC 61850 standards to ensure interoperability. Therefore, all field devices in the micro grid are the IEC 61850 server, and the MGMS collects and controls data as IEC 61850 clients. The field devices are called the Intelligent Electrical Device (IED) and follows the data model defined in IEC 61850, as shown in Figure 3.

IEC 61850 defines the Abstract Communication Service Interface (ACSI) model classes. The ACSI service model is divided into three classes, that is, the MMS service, which is used for typical client–server communication, the GOOSE service, which is used for timely and mission critical communication, and the sampled value service for the sampled measured voltage and current. The control block using the MMS service are Report, Log, and general client–server services using request/response messages. In general, the control message is transmitted using the GOOSE service. Field devices communicate through these IEC 61850 services, and the MGMS becomes one Human Machine Interface (HMI) application to monitor and control the system in the overall micro grid. As indicated by the dashed line box in Figure 2, the micro grid also communicates with external systems, such as the DMS, weather information systems, energy market systems, and neighboring micro grids to perform the functions described in Section 2.

As shown in Figure 2, the MGMS supposed to use the public network to communicate with external systems. In this paper, we compared and analyzed the performance of XMPP and the MQTT protocols, among IoT protocols, as an application layer communication protocol for IEC 61850-based MGMS to communicate with other systems through the public network. The XMPP and the MQTT are mapped to the IEC 61850 service and serve as middleware for communicating over the public network. The XMPP is one of the IoT protocols, which is considered to be the most advantageous in terms of diversity and scalability. Recently, the XMPP has been adopted in IEC, and mapping with IEC 61850 was published in IEC 61850-8-2. It also seems to be easy to interoperate with other standards because it is a trend that applies to other standards of smart grids. The XMPP provides XML-based communications. It forms a connection path through the stream and conveys the stanza. There are three types of stanzas:

• <iq>…</iq>
• <message>…</message>
• <presence>…</presence>

To form a connected path, the XMPP uses a unique address called Jabber Identifiers (JID). It is a structure similar to an email format and expresses the destination and the source. Generally, communication is performed by the publish-subscribe method, and Quality of Service (QoS) is not supported. The XMPP is a communication protocol that has the greatest advantage in scalability so that it can be used in a variety of unpredictable communication environments. It sends and receives messages using an XML format. The message consists of a stream and a stanza. The types of stanzas are iq (info/query), message, and presence. The iq stanza is the way in which information is requested and answered, and the message stanza sends an unsolicited message. The presence stanza identifies the status information of the object to communicate with. In addition, the communication mapping of IEC 61850 based on the XMPP is being established as IEC 61850-8-2. When the XMPP is used as a middleware, as shown in Figure 4, the MGMS and the DMS are working as the XMPP client and exchange stanzas through the XMPP server.

The MQTT is a lightweight publish/subscribe messaging protocol. The MQTT messages are identified using topic, which publishes and subscribes to messages through the broker. The client connects to the broker and subscribes to the topic they are interested in. The client can also connect to the broker and publish a message with a specific topic. Several clients can subscribe to the same topic. The broker serves as an interface to connect clients. The topic is treated as a hierarchical structure using ‘/’ as a delimiter. This makes it easy to place common topics, such as file system directories. The MQTT provides three levels of QoS. QoS defines how the broker or client should care so that the message is received correctly. Level 0 is when the broker or client sends the message only once and does not verify that it has been well-received. Level 1 ensures that the broker or client delivers the message more than once and is well-received. Level 2 is when the broker or client delivers the message correctly using a four-step handshake. If the MQTT is used as middleware, the MGMS and the DMS will have both the Publisher and Subscriber, as shown in Figure 5. When they publish a topic to the broker, the broker delivers the message to the subscriber that configured the topic. For a topic that is not set, the subscriber will not receive it even if the publisher publishes the message.

Table 1. Features of the MQTT and the XMPP.

Features	XMPP	MQTT
Transmission Method	Pub/Sub or Req/Res	Pub/Sub
Transport layer protocol	TCP	TCP
Quality of Service	Not supported	3-Level
Overhead	High	Low
Header size	No header	2 Bytes
security	SSL	SSL
Reliability	Reliable	Reliable
Check Status	presence	ping (broker)

summarizes the features of each protocol. As shown in the table, the XMPP does not support QoS features, which means that all messages will be treated in the same manner. As noted in the table, however, the XMPP has a presence stanza which will be used to monitor the participant of the network in real time. This feature is useful when the participants are dynamic in nature, for example, the EVs.

4. IoT-based Micro Grid System Structure

4.1. Framework and Test-Bed Device Specifications

The MGMS exchanges the IEC 61850 data model with the DMS using the public Internet rather than a private network with IEC 61850 services. The framework architecture is illustrated in Figure 6.

The MGMS are connected to the Korea Telecom (KT) line, which is a public Internet service provider in Korea, and the DMS are located in the server room at Sejong University. The number of hops between the MGMS and the XMPP server/MQTT broker was 17 network layer hops, and the number of hops between the XMPP server/MQTT broker and the DMS was 13 network layer hops.

The configuration of the micro grid test-bed used in this paper is illustrated in Figure 7. The test-bed consists of a solar panel, a wind turbine, digital load, the ESS, and EMS, which receives Report services from all the micro grid nodes. Each micro grid node consists of a current sensor and a voltage sensor, and the measured current and voltage information is sent to the Arduino board using a serial link. The Arduino board performs analog to digital conversion, and digitized current and voltage values are sent to Raspberry Pi using a serial link. Raspberry Pi runs the IEC 61850 server, and the received voltage and current values are mapped to the IEC 61850 data model. The voltage and current value are periodically sent to the MGMS, which is implemented in a general PC, using a Report ACSI service. The DMS, which is the target of communication through the XMPP and the MQTT, is also implemented in a general PC.

Figure 8 shows an example of the actual circuit of the solar panel. It consists of a current sensor, a voltage sensor, and an Arduino board to periodically read the sensor values, and sends those measured values using the Distribution Energy Resource Management System (DERMS), which is implemented on Raspberry Pi. The DERMS will send the information to the MGMS using an IEC 61850 Report service.

4.2. Specifications for Test-Bed Devices

To implement a test environment, at least two PCs are required, as described above. Since the XMPP and the MQTT must have a server/broker connected to the public network, a server/broker is implemented in a laptop computer. To test the network performance of each protocol, time synchronization is performed using UTCk3. The specifications of the devices used for the test-bed are summarized in

Table 2. Hardware specification for the test-bed.

	OS	Windows 7
	CPU	Intel Core i7 CPU @ 4.00GHz
	RAM	8GB
MGMS	HDD	SSD 256G SCSI Disk
	IEC 61850 server library	MMS EASE Lite v6.0
	XMPP client	Gloox v1.0.20
	MQTT client	Paho v1.2.0
	OS	Windows 7
	CPU	Intel Core i7 CPU @ 4.00GHz
	RAM	16GB
DMS	HDD	SSD 256G SCSI Disk
	IEC 61850 client library	MMS EASE Lite v6.0
	XMPP client	Gloox v1.0.20
	MQTT client	Paho v1.2.0
	OS	Ubuntu 16.04 LTS
	CPU	Intel Core i7 CPU @ 2.50GHz x 8
XMPP Server	RAM	8GB
/MQTT Broker	HDD	SSD 256G SCSI Disk
	XMPP Server	Openfire v4.1.4
	MQTT Broker	Mosquitto v3.1

.

4.3. Data Modeling

The data of the solar panel, wind turbine, battery, and load are mapped to the IEC 61850 data model. For example, a MMDC logical node (LN) is used to measure the voltage and current of the PV modules. MMET and STMP LNs are used for environmental measurements, such as solar radiation and ambient temperatures. The dataset used in this test-bed is summarized in

Table 3. Dataset used in the test-bed.

Logical Node	Data Object	Description
MMDC	Watt	Power
	Amp	Current (DC current)
	Vol	Voltage (DC voltage) between poles
MMET	EnvTmp	Ambient temperature
	EnvHum	Humidity
	HorWdSpd	Horizontal wind speed

. The MMDC is defined in IEC 61850-7-420 [22] and represents measurement information of the DC system, such as the current, voltage, power, and resistance. There are no mandatory data objects (DOs) in MMDC LN, and all DOs are optional. The $Watt$, $Amp$, and $Vol$ DOs in MMDC LN are used. Since the Common Data Class (CDC) of all DOs are used in the Measured Value (MV), it only consists of $mag$, q, and t attributes representing magnitude, quality, and timestamp, respectively—the mandatory data attribute (DA)s of MV.

The MMET LN consists of DO representing weather information. Although no weather sensor is configured separately in the test-bed, data models are constructed using data used in real solar experiments. The DA of $EnvTmp$, $EnvHum$, and $HorWdSpd$ are used in MMET LN. As in the MMDC LN, since the CDC of all DOs used is the MV, it only consists of $mag$, q, and t, which are the mandatory DAs of MV.

With this configuration, the value measured every 5 min was set to be transmitted using the Report service. Figure 9 shows the Report message received at the MGMS with power of 94 W, current of 0.605 A, voltage of 170.5 V, temperature $18.2$ ${}^{°}\mathrm{C}$, humidity 87.88%, and wind speed of 1.641 mph. The generated power in the solar panel is not high because it is 6:55 a.m. in the morning.

During the daytime, the generated power by the solar panel increases, as shown in Figure 10. The Report message shows the generated power of 208 W, 1.364 A of the current, 192.944 V of the voltage, $27.6$ ${}^{°}\mathrm{C}$ of the temperature, 59.4% of the humidity, and 3.873 mph of the wind speed.

4.4. IEC 61850—IoT Protocol Mapping

As described above, the data models and communication services are defined according to IEC 61850. In addition, it is assumed that the DMS and neighboring micro grid use the IEC 61850 data model and services for internal communication. Therefore, it is important to map data models and services of IEC 61850 to each IoT protocol when exchanging data over a public network. IEC 61850 services considered in this paper are specific to Report and Log services which are over the MMS protocol stack. Services which have strict timing constraints, such as GOOSE or SV services, which have 3 ms timing constraints, are rarely delivered over the public network, so they are not considered in this paper. IEC 61850—IoT protocol mapping in this paper refers to IEC 61850-8-2, which is the first IEC 61850 mapping to IoT protocol [15]. IEC 61850-8-2 defines the mapping of core ACSI services of IEC 61850-7-2 to the XMPP. Encoded data are mapped using the UserData part in XML messages and is sent using the XMPP or the MQTT. Performance is measured for the two IoT protocols in various aspects.

4.4.1. IEC 61850—XMPP Mapping

Request-response messages are exchanged between the MGMS and the DMS using the iq stanza 194 in the XMPP. Figure 11 shows a captured packet from the DMS to the MGMS using Wireshark. Figure 12 shows the screenshot capture of the packet when the MGMS responds to the DMS in response to the request message shown in Figure 11. The request message is sent using the iq stanza, and the id is given when making the initial connection to the XMPP server. The type is set to “get” to request data objects. As discussed before, the from and to attributes include JID. CDATA within ITEMID indicates the LN and DA to be obtained. It requests MMDC1$MX$Watt$mag$f and MMET1$MX$EnvTmp$mag$f to be read. In response to the request message, Figure 12 shows the response message from the MGMS, which has a power of 0.0 and temperature of 21.7, respectively. The packet size of the request message was 594 Bytes and the response message was 431 Bytes.

4.4.2. IEC 61850—MQTT Mapping

Request–response communication between the MQTT based on the MGMS and the DMS communication is done using a message identifier, that is, a topic, which starts with Request when it is a request message, and starts with Response when it is a response message. Figure 13 shows a screenshot of Wireshark in which the DMS sends a request message to the MGMS through the MQTT. We set the topic as Request/SOLAR1/MMDC1 to read MMDC1$MX$Watt$mag$f, and MMET1$MX$EnvTmp$mag$f as in the XMPP case. Topic can be set freely as a set of required DOs. Figure 14 shows the screenshot of the captured packet where the MGMS responds to the DMS using the MQTT topic to the request message shown in Figure 13. The topic becomes Response/SOLAR1/MMDC1 as requested, and transmits a value of $21.7$ within the message.

5. Performance Analysis of IoT-Based Micro Grid System

Based on the framework constructed above, different performance metrics, that is, packet sizes, response times, loss rates, and retransmission rates for each protocol are measured and summarized in

Table 4. Performance comparison of the XMPP and the MQTT protocol.

		XMPP	MQTT
Packet size	Request	594 Bytes	449 Bytes
	Response	431 Bytes	293 Bytes
Response time	Average (ms)	31.34047	20.54181
	Variance	30,647.88	651.0342
	Minimum (ms)	6.760706	17.78336
	Maximum (ms)	5761.62	1488.853
	Significance level (95%)	1.257095	0.426793
Loss rate	Loss rate	0%	0%
	Retransmission rate	0.032%	0.041%

.

The response time is defined as the time it takes for the DMS to send a Request message and receive a Response message, as shown in Figure 15. The XMPP and the MQTT have a server/broker in between and deliver messages. We tried ten 100,000 Request–Response services to calculate the response time. The response time includes the system processing time. Messages were tested for changes in response time by sending messages with varying intervals of 0.5 s, 1 s, 1.5 s, …, and 5 s. There was no big difference in the results, so we conclude that the interval of the request message, which is related to the CPU load, does not affect the response time. As shown in Table 3, the average response time of the MQTT is smaller in the order of 10 ms. Both protocols satisfy the timing constraints defined in IEC 61850-5 for non-critical services. However, note that the maximum response time does not satisfy the timing constraints. This is due to the nature of the transport layer protocol that the XMPP and the MQTT use. In the event of loss or error of segment, TCP will retransmit the segment. The response time includes all retransmitted segments which is a negligible number of segments in the experiment. This case will be recovered in the application layer using a time-out timer.

The loss rate was estimated using the Wireshark packet capture software. Complete lost packets are detected using the “(tcp.analysis.lost_segment) && (XMPP)” filter. The tcp.analysis.lost_segment filter was used to detect the lost segment, and the XMPP filter is used to filter only the XMPP protocol. No packet loss was detected in the XMPP. Retransmitted packets were detected separately because the transport layer communicates over the TCP. To do this, we used “(tcp.analysis.retransmission) && (XMPP)”. The tcp.analysis.retransmission filter is used to detect the retransmitted packet. The retransmitted segment indicated that there is an error in the link, but if there is a lot of retransmission, it can be judged that the communication environment is not good. The retransmission rate of the XMPP was 0.032% and the MQTT was 0.041%. As noted above, this small retransmission could be recovered at the application layer and also verifies how we got such a large maximum response time.

As shown in Table 4, the packet size of the MQTT is about 50 Bytes smaller than that of the XMPP. Both the XMPP and the MQTT use TCP, so the loss rate is 0%, even though there are few retransmitted segments which are 0.032% and 0.041% for the XMPP and the MQTT, respectively. As for the average response time per transaction, the XMPP takes approximately 10 ms larger than the MQTT. This can be seen as different due to the stack processing time for each protocol, rather than the impact of the packet size. The XMPP has a wider distribution of minimum and maximum response times than the MQTT. The MQTT tends to show up as a dense response time, while the XMPP tends to appear more scattered. This shows that the MQTT has a uniform response time compared to the XMPP.

6. Conclusions

To ensure interoperability, this paper presented a performance analysis of IoT protocols to exchange data between the DMS and the micro grids that comply with IEC 61850 standards over the public Internet. Both the XMPP and the MQTT have advantages and disadvantages of protocol features. The XMPP is the strongest advantage of iq stanzas and presence stanzas. The XMPP can directly map a Request–Response message to an iq stanza, but the MQTT can only issue a Publish–Subscribe communication, so it must implement its own Request–Response message in the application layer. The XMPP can periodically check the status information of connected devices using presence stanzas, but the MQTT can only check the connection status of brokers. The MQTT, however, shows excellent results in packet size and response time. Although the XMPP is excellent in terms of functionality and retransmission rates, we conclude that the MQTT is superior in terms of lightweight communication performance. The difference of the communication speed is about 10 ms, so it does not show a big difference in terms of non real-time communication. Therefore, it is reasonable to use the XMPP. In order to use a protocol suitable for the public network communication of the micro grid, however, it would be better to extend a the MQTT protocol, which is suitable for functions, is lightweight, and has better communication performance by adding the function of periodically receiving a Request–Response communication method and device status information.

This paper does not consider security issues. To utilize public networks, security issues need to be considered carefully. IEC 62325 deals with overall security issues in smart grid, and IEC 62325-6 especially deals with security in IEC 61850. New tack force was formed inside TC 57 WG 10 to address access control issues. IEC 61850-90-19 was initiated to adapt role-based access control (RBAC) in IEC 61850 series. In future work, RBAC should be applied in topic registration in IoT protocol, since most IoT protocols exchange data based on topics.