## 3 Proposal of an IoMT Architecture and Platform to Enable Pervasive Healthcare
### Performance Evaluation  
Several tests based on metrics, such as latency and resources (CPU and Memory) consumption were applied for validating the platform performance. The use case designed as Proof of Concept (POC) considers an IoMT device which combines a Cooking Hacks e-Health Sensor Kit development platform attached to an Arduino UNO and an ESP8266 Wi-Fi module to provide network access. The IoMT device comprises sensors, such as airflow, ECG, SpO2, electromyography, those related to blood pressure, blood sugar, body temperature, and an accelerometer that detects the patient's position (sitting, lying, or standing). Figure 13 (Experiment 1) shows the network topology considered in the first test. The IoMT device connects through a Wi-Fi Access Point (Station Operation Mode) hosted in a router connected to the fog server via an Ethernet connection. The router provides ADSL Internet access and enables communication with the cloud services. Over this topology, a sequence of 100 body temperature observations was transmitted from the IoMT device to the fog server, allowing comparison of the latency of the three BPs provided in the framework (see Figure 14). CoAP BP achieved the best performance and REST and MQTT BPs showed higher latency with similar results. Table 2 shows the maximum and average latencies for each BP. MQTT BP achieved the worst maximum latency; however, its average was close to that of the REST version. Table 3 shows the maximum RAM memory used in the IoMT device for each BP. Again, CoAP provided the best results. However, REST BP was better than MQTT. Figure 13: Network topology considered for test. The results motivate the use of CoAP BP and MQTT only if an external application is deployed on the fog server and consumes the data according to a publish/subscribe mode. REST BP should be considered only if the sensor has implemented a Web client and faster integration is required. The second experiment considered the transmission latency between two IoMT devices and the IN-CSE on the cloud with a gateway acting as a relay. A device monitors the respiration rate defined in the OpenEHR archetype openEHR-EHR-OBSERVATION.respiration.v1, and the other monitors the saturation of oxygen in the peripheral blood, measured via pulse oximetry and the pulse/heart beat defined in archetypes openEHR-EHR-OBSERVATION.pulse- oximetry.v1 and openEHR-EHR-OBSERVATION.pulse.v1, respectively. As in the previous test, 100 observations of each parameter were collected and forwarded from the IoMT device to the cloud platform. Figure 13 (Experiment 2) shows the network topology considered in this test. The IoMT device connects to a Samsung model S9 smartphone gateway through a Wi-Fi network (IoMT device operates as a Wi-Fi AP) and the gateway connects to the cloud platform through an LTE advance cellular network. Figures 15-17 show the latency between the IoMT devices and the gateway for each of the three flows and binding protocols. Again, CoAP achieved the best performance. A difference observed between the device that manages breathing data and the one that handles oxygen saturation and heart rate data is associated with the low processing resources available for the devices used--one of the devices has only one sensor, whereas the other has two. Figure 16: Latencies in the use of MQTT over Wi-Fi (loMT devices-gateway). Figure 17: Latencies in the use of REST over Wi-Fi (loMT devices-\(>\)gateway). Figure 15: Latencies in the use of CoAP over Wi-Fi (loMT devices-\(<\)\(>\)Gateway). It is important to note that in the previous experiments the latency was measured in the application layer. It is influenced by the processing load on the IoMT device, the Fog Server and cloud platform. For example, the handling of SenML messages (Figures 10-12) can add queuing and processing delays to the latency which was measured once the message had been completely processed. In addition, other processing loads related to the conversion of SenML messages into archetyped OpenEHR observations also have an impact on the results.