## 3 Proposal of an IoMT Architecture and Platform to Enable Pervasive Healthcare
### Description and Implementation of the Platform
#### 3.2.1 IoMT Device (ADN)  
Since the IoMT devices follow the OneM2M specification, we provide a development framework written in an object-oriented paradigm in C++, which simplifies the development process of the AE and Binding Protocols (BPs). Figure 6 displays its main classes.  
The IoMTSensor abstract class must be extended to represent the physical sensors and must implement functions to gather the sensor ID (obtained in the gateway and fog server after a registration process), read an observation value, retrieve the unit of measure associated with the observations, and obtain a friendly measure name (i.e., temperature, blood pressure, among other physical parameters' names).  
Figure 5: Technologies involved in platform implementation.  
Figure 6: Development framework operation for an IoMT Device.  
The BindingProtocol abstract class must be extended to represent novel or custom OneM2M binding protocols redefining the SendValue, Connect, and Set Communication Devices. The development framework already provides extensions of this class for MQTT, CoAP, and REST BPs. The communication must be implemented to have physical network access, and the framework enables implementations for Wi-Fi, GSM and Ethernet modules.  
The ApplicationEntity class provides functionalities that connect the previous concepts and manages the monitoring process, such as conversion from sensor observation to SenML (Sensor Markup Language) data format and time tracking through the Universal Coordinated Time format and Network Time Protocol (NTP) services.  
Figure 7 shows an example of the development framework operation for an IoMT device. Initially, the communication device, NTP client, AE, BP, and sensors are instantiated; the AE starts to run, and the communication device connects to the physical network. An IoMT device was designed as a platform that can host more than one sensor, each of them identified with an Id field. AE monitors the sensors until an observation \(CO(i)\) is available for the ith-sensor. \(CO(i)\), the current observation is then serialized as a SenML message and forwarded to either the gateway, or the fog server through the binding protocol.  
SenML is serialized in three different ways to minimize the consumption of resources (mainly network overhead). An array \(PO[sensorcount]\) containing the previous observation made by each sensor and initialized with \(NULL\) values is maintained in the AE. If \(PO(i)\) is equal to a \(NULL\) value (i.e., first observation for sensor i), the SenML message will include fields for the sensor Id, current observation \(CO(i)\), time, friendly measure name (i.e., body temperature) and unit of measure. \(IfPO(i)\) has a value, SenML will contain the fields relative to sensor Id, observation O(t) and time,  
Figure 7: Initialization and message handling on IoMT devices using the development framework.  
thus reducing the payload length. Moreover, if \(PO(i)\) is equal to \(CO(i)\), the observation does not need to be resent and the SenML message will contain only fields representing the sensor Id, time and a special flag that informs the gateway/fog server on \(CO(i)\) being equal to \(PO(i)\). The \(PO(i)\) value is updated with the \(CO(i)\) value whenever a message from a sensor \(i\) is sent.  
Finally, Figure 8 shows an example code for an Arduino-based IoMT device that uses the CoAP BP provided in the development framework and a temperature sensor; in this case, less than 40 lines of code are necessary for integrating a device to our platform. The Id is configured in line 30 for identifying the sensor within the platform. In this example, it is defined via a code; however, it can be configured through a visual interface or another type of input inserting its value obtained after the registration of the patient and the sensors associated with it on the platform. The next section describes the process.