## 3 Proposal of an IoMT Architecture and Platform to Enable Pervasive Healthcare
### Description and Implementation of the Platform
#### 3.2.2 IoMT Gateway (MN)  
The development stage of the platform considered only gateways based on smartphones, widely used in IoT, M2M and IoMT scenarios ([37; 38; 39]).  
Smartphones avoid the need for an additional equipment to be transported by the user and improve the platform in terms of support for users' mobility. Moreover, end users can download the components from the different application stores as common applications.  
The platform considered, initially, Android smartphones as gateways. According to [40], in July 2019, platforms based on the Android operating system dominate about 80% of the world market and the other 20% are distributed among Apple iOS, Microsoft Windows, and other lesser used operating systems. In addition to Android-based gateways, we are currently working on the implementation of the framework for Apple iOS and for an Arduino-based low-cost gateway.  
IoMT gateways are considered OneM2M MNs, which host AEs, and CSEs. We provide a gateway development framework composed of an Android application skeleton that represents the AE and enables gateway configuration, user and sensor management, and data visualization. Gateways can operate as either a message relay between the ADN and the IN-CSE through the binding protocols available in the IN-CSE, or a bridge between ADNs and fog servers. The CSE is implicitly developed  
Figure 8: Example of coding of the development framework for the IoMT device.  
inside the AE and provides classes such as those proposed for the IoMT device, which enables the extension of binding protocols. Below are some of the steps required for a gateway configuration;  
1. Supply of an IP address or URL of IN-CSE (cloud) or CSE (fog) (operation mode implicitly detected);
2. Registration on the platform for the supply of patient-related data, such as full name, birthday, gender, email, password, address, etc.;
3. Login to the platform by means of users' credentials;
4. Registration of a sensor and obtaining of the sensor Id; and
5. Setting of the sensor Id to the IoMT device.  
The sensor registration process demands particular attention. On our platform, sensor measures are associated with observations defined in OpenEHR, which enables the detection of invalid or damaged messages through an automatic process that validates an observation (and the sensor that generated it) that complies with all the restrictions defined in the observation archetype (detailed in Sections 3.2.3 and 3.2.4). Figure 9 shows the sensor registration process, where the sensor Id is always generated by the cloud entity for avoiding persistence problems, and propagated to the fog, gateway and IoMT device. Each entity stores a record that maps the sensor Id to an OpenEHR archetype Id, which helps in the identification of type of data provided by the sensor and constraints to be fulfilled by the data.  
Once the sensors have been registered and settled in the IoMT devices, the three types of SenML messages are handled (see Figure 10). The gateway stores data on the measure name and unit of measure provided by the first message for completing the subsequent compacted ones. Moreover, when the gateway detects a SenML message marked as repeated, it generates a new one containing all the fields, but using the current time. The gateway also provides other functionalities  
Figure 9: Sensor registration process (Gateway).  
for data persistence, e.g., an offline local cache implemented to be used by the platform in scenarios of poor connectivity.