Protocols for the Smart Energy Grid
In the last post there was an article comparing the different messaging protocols for the IoT. The Smart Energy Grid is a special case of the IoT which receives great attention today. A world of decentralized energy production is envisioned where each household becomes a prosumer and takes part of the Smart Energy Grid which balances production and consumption of energy.
Again, the question for the right messaging protocol is essential here. The following paper compares XMPP, DDS and AMQP as possible solutions:
A lot of standards at the semantic level are analyzed and culminate in some key requirements for a message-oriented middleware (MOM) for the smart energy grid:
– Prioritization – the MOM should support different priorities for messages
– Delivery semantics – advanced delivery semantics are needed, especially to maintain the logical order of changes to some element in the smart grid
– Scabalability – this covers scalability in numbers of users as well as low message delivery latency and the predictability thereof
– Dynamicity – fast reconfiguration of the topology as users come and go
– Data bandwidth – high message throughput
While the focus on only these requirements may be questionable, I solely want to comment on the statements about XMPP made in the paper which need some correction.
Prioritization – The authors say that prioritization can be done using XEP-0168 (Application Priorities). As far as I understand XMPP priorities, this only controls the order of message reception among the set of devices a single user has connected to its XMPP server. Up to my knowledge, there is no way to control the order of message processing at the XMPP server queues. So XEP-0168 is useless and XMPP simply does not support prioritization in the sense mentioned in the paper.
Delivery semantics – The XEP mentioned here (XEP-0079 Advanced Message Processing) is not supported by the “big three” XMPP servers OpenFire, eJabberD and Prosody. But delivery semantics in the sense of best effort vs. reliable delivery is possible with XMPP core technologies. Message stanzas are used for fire-and-forget messages while iq stanzas should be used if acks are needed. A resend can be initiated if the receiver did not respond.
Scalability – To control message latency in XMPP XEP-0203 Delayed Delivery is mentioned here. But this has a quite different focus and will not be used to indicate general message latency. There is no means in XMPP to do this like the latency budget in DDS.
Dynamicity – It is argued that XMPP has no distributed state so XMPP does not support topology changes well. If such a distributed state is necessary, it can easily be implemented using XMPP PubSub (XEP-0060) which supports persistent nodes. Late joiners will immediately get the last state of the persistent nodes if they subscribe to them during startup. XEP-0060 is widely available in XMPP client and server implementations.
Data throughput – According to the paper, all three technologies are very good at this point. Nothing to add. Our own tests show quite comparable results.
The paper comes to the conclusion that DDS is best-suited while AMQP is a close follow-up. XMPP is only a good alternative, if certain XEPs are considered which might contradict its wide use. Besides the points above that need to be corrected in the paper, there is no such thing than basic XMPP (i.e., XMPP without XEPs) in practice. Most real-world applications support the same set of extensions which can be found on this page. Moreover, XMPP PubSub is a mature technology which can solve many of the problems mentioned above. Thus XMPP will at least be on the same level than AMQP regarding the criteria mentioned above. However, if real prioritization and latency budgets are needed, only DDS is currently able to provide this level of QoS control.