# Communication Protocols of an Industrial Internet of Things Environment: A Comparative Study
## 7 Discussion  
Based on the comparisons of Sections 4-6 as well as the theoretical study of the MODBUS TCP in Section 3, two scenarios are discussed here to build the industrial IoT environment. The first scenario is to employ only the MODBUS TCP to build the IIoT environment. The study of Section 3 proved that MODBUS TCP is able to react as an IoT protocol. Security is a fundamental issue in IoT, which was solved in [32] for MODBUS TCP using TLS. As mentioned above in Section 5, the MODBUS TCP is able to build the IIoT environment using the synchronous request-response communication pattern on a standalone basis, which is a scenario that complies with most industrial applications. However, this solution totally relies on the polling-based mechanism. In the second scenario, the event-based mechanism is fulfilled by MQTT, where M2M communications are required, using the asynchronous publish-subscribe communication pattern. For industrial functions, the MODBUS TCP is employed, which fulfills the synchronous request-response communication pattern. In this scenario, MQTT works in parallel with the MODBUS TCP within the same platform, as shown in Figure 11. This figure illustrates the simulation environment of the second scenario. The environment consisted of a desktop PC running Microsoft Windows XP, a laptop running Linux Ubuntu 16.04, and an LAN/Internet network. The desktop PC is equipped with a  
Figure 10: MQTT-related measurements: (**a**) Round-Trip Time (RTT); (**b**) CPU usage. java-based MODBUS TCP client, the ActiveMQ MQTT server, and the MQTT.FX consumer. The laptop was equipped with a multithreaded Java program; one thread ran the MQTT publisher, and another thread ran the MODBUS TCP server. In addition, an online MQTT broker and consumer, provided by HiveMQ for testing, were employed here as an Internet-based server. The RTT measurements and the CPU usage of this environment were measured for the MODBUS TCP and then compared to the previous results of Section 6. The RTT values of the MODBUS TCP, which were measured on the desktop PC, had a maximum value of 9 ms. This represents an increase of maximum 12.5% from the previous RTT values presented in Section 6. As illustrated in Figure 12, the CPU history of the laptop, which contains an MQTT publisher and a MODBUS TCP server, showed that the CPU usage is always less than 20%. These results indicate that the concurrent execution of MQTT in parallel with the MODBUS TCP within the same platform does not severely influence the performance of the MODBUS TCP. Nevertheless, while MQTT fulfills the event-based paradigm, it lacks interoperability. The MQTT protocol formats the data using the UTF-8 standard, and hence interoperability is not fulfilled. To maintain a homogeneous message for the entire environment, industrial data are organized using the structure of MODBUS messages, formatted in the UTF-8 and then transferred in the payload of an MQTT publish message, as shown in Figure 13a. The hexadecimal representations of Figure 13a were obtained based on the information of Table 3. Digit numbers zero to nine are formatted in UTF-8 using the hexadecimal representation. Digit number \"0\" is represented by \"30\" and digit number \"9\" is represented by \"39\". Additionally, letters \"A\" to \"F\" are represented by \"41\" to \"46\", respectively. Each byte of the MODBUS message is represented by two bytes, as shown in Figure 13. For example, the ID part of the MODBUS message is \"00 01\", which leads to \"30 30 30 31\" representation, and doubles the payload of the MQTT publish message. The MQTT publish  
Figure 11: Simulation environment of the second scenario. Figure 12: CPU history of the laptop that ran an MQTT publisher and MODBUS TCP server. message was subsequently transmitted to the online hivermq.com server, and the result is illustrated in Figure 12(b). Using the arrangement of Figure 12(a), the message structure, which is the MODBUS TCP, was maintained throughout the entire IIoT environment for both the control part and the monitoring part.