# A Performance Analysis of Internet of Things Networking Protocols: Evaluating MQTT, CoAP, OPC UA
## 8 Conclusions and Future Work  
This paper contributes to the performance analysis and evaluation of different IoT communication solutions, by first providing a comparison of different protocol features, to then perform experiments with MQTT, CoAP, and OPC UA in both local experimentation environment and in the large-scale experimental facility FIT-IoT. In terms of protocol features most protocols already support both TCP and UDP traffic, being the exception MQTT. UDP support is highly relevant in future IoT environments, as the devices present will become more mobile. Another aspect which requires further future work is service decentralisation, and for that, communication protocols need to be designed in a way that address variable topologies. Today, only DDS and NDN truly support decentralised communication. In regards to security, some solutions, such as QUIC, OPC UA and DDS, provide a specific security framework, which brings in more flexibility and better security in terms of specific domains. Only NDN provides security by design, while the remainder solutions recur to existing solutions, such as DTLS. Other relevant aspects in IoT, such as data/device discovery, are still articulated in a manual way, being the exception DDS and NDN. In terms of end-to-end coverage, the different solutions have mostly been developed to provide support between devices and the edge. They can be applied to cover other regions, e.g., edge to cloud. D2D support is only directly supported by DDS and NDN. Summarising, from a design perspective, DDS and NDN are the solutions that seem to provide the most flexible design, integrated by design a set of features that are relevant when thinking about the potential evolution of IoT environments. DDS is, however, domain specific (manufacturing), and NDN is still not being developed at a commercial IoT level. In regards to the other solutions, OPC UA provides good support in terms of in-plant communication, thus being the de facto communication standard in industrial automation environments. CoAP provides a high level of flexibility and is today one of the most popular solutions for IoT communication. Its main advantage is its flexibility and interoperability towards HTTP. From a performance evaluation, this work has focused on comparing MQTT, CoAP, and OPC UA in regards to time-to-completion and packet loss, under different conditions. The experiments run on local testbed showed that any of these protocols can be run in an embedded environment without significant impact in the selected KPIs. Moreover, all protocols achieved low time-to-completion times across all of the tested scenarios, aspect which is relevant for their application in critical environments. CoAP is the protocol that achieved the lowest time-to-completion, which we believe is due to the reliability exponential backoff mechanism, beneficial for environments with frequent messaging. MQTT results in lower TTCs, but exhibited a larger variability for the different scenarios, being highly dependent on the frequency of messages and on message size. OPC UA shows less sensitivity to variations on the frequency of messages. The fundamental reason for this requires further analysis and is an aspect to pursue as future work whether or not this stability is derived from the communication semantics of OPC UA. However, OPC UA resulted overall in higher TTCs, when compared to CoAP and to MQTT. The experiments that have been repeated in large-scale environments (FIT-IoT) for CoAP and MQTT show that these protocols have a similar behavior to the one observed in the testbed. A detected limitation of the experimentation carried out concerns the lack of experimental, large-scale platforms, easy to use, to carry out experiments in scenarios with more variability. A second detected limitation concerned the impossibility, at the time of the experiments, to have OPC UA running in FIT-IoT. As future work, we shall continue with performance evaluation of the different protocols.