## 3 Digital Signage Systems' Design and IoT Technologies Comparison
### Features and Evaluation of MQTT protocol in LTE/4G Communications  
In order to evaluate the applicability of our chosen protocols, we evaluated factors which can be very critical in emergencies, and especially in our case, where every connection and reconnection should be fast and reliable. The signage modules would maintain their connection to the server no matter the situation, e.g., periodically manufacturing nodes or interference from water.  
Figure 5: HTTP flow diagram.  
A very important factor that we should take into account in our case scenario is latency. In [33], a testbench compares the HTTP and MQTT protocols in a mobile scenario with GSM/GPRS modules, and the results show that because of the complexity accompanying the HTTP protocol, MQTT can be as much as 9.6 faster and provides a faster reconnection in the case of lost signal. This can also provide us with more robust server resources as shown in [34], where a comparison between MQTT and HTTP protocols shows that the lightweight protocol overhead of MQTT is notably better in terms of preserving network bandwidth.  
Apart from HTTP, we also compared MQTT with the other candidate, Machine 2 Machine (M2M) internet application protocols. In [35], MQTT, along with CoAP and OPC UA, were evaluated and tested for their performance in different multicasting scenarios, namely \"1 to many\", \"many to 1\", and \"many to many\". MQTT seems to outperform the other two protocols in both \"1 to many\" and \"many to 1\" scenarios, providing the lowest latency. MQTT also seems to show the best integrity when the size of the message is fixed, like in our case. In [36], MQTT, CoAP, and OPC UA are simulated in terms of latency in an LTE scenario. Both MQTT and OPC UA show greater stability than CoAP in terms of network load, and OPC UA slightly outperforms MQTT in latency, which, in the case of LTE, is not more than 20 milliseconds. However, it is noted that the protocol overhead of OPC UA is larger than MQTT and it is not taken into account in the experiment.  
It is also important to evaluate our choice of MQTT features like QoS and the integration of SSL/TLS certificates. In the [32] testbed, MQTT QoS 0 and QoS 1 were compared in regard to latency for TCP connections. For the same payload, MQTT QoS 1 seems to be 30% faster than QoS 0. In [37], a testbed evaluates MQTT in regard to the delay of processing TLS and TLSMA certificates for different payloads and QoS, and the results show that the use of certificates does not significantly influence the latency of the messages (Table 2). For a QoS 1 message of 0-200 bytes, the difference is in the range of ~0.1 msec, and for a message of 1000-1200 bytes, the difference is not more than 4 msec.  
The studies above agree with our case scenario--that we need to have fast and reliable communication for either a \"many to 1\" or a \"1 to many\" scenario with a predefined message. They show that the network capacity and stability of MQTT is needed in an otherwise unstable scenario. This shows that QoS 1 is the preferable choice for the application and that SSL/TLS security can be integrated in a costless way. We did not stand on the power consumption of the protocols, since we did not deem it necessary for this study, and the ship can provide the module and batteries can flexibly be used. However, ref. [38] shows that power consumption for MQTT can be as low as 20% as that of an HTTP application.