## 2 Related Works
### OneM2M Communications  
The main objective of OneM2M [32] is to develop technical specifications for a common M2M service layer, thus minimizing standards market fragmentation. It has consolidated the isolated M2M service layer standards and developed a global specification. The benefits offered by OneM2M to the M2M ecosystem include shortened time to market, since common components do not need to be developed, which simplifies the creation of applications, and a common set of application programming interfaces (APIs).  
Figure 2 shows the functional architecture formed by functional entities called nodes: application dedicated node (ADN), application service node (ASN), middle node (MN), and infrastructure node (IN). Nodes host at least one OneM2M common services entity (CSE) or one OneM2M application entity (AE) [32]. A CSE is a logical entity instantiated in an M2M node and comprises a set of service functions called common services functions (CSFs). CSFs can be used by applications and other CSEs. An AE is a logical entity that provides application logic, e.g., remote blood sugar monitoring, for end-to-end M2M solutions.  
OneM2M currently defines three reference points (Mca, Mcc, and Mcn), where the \"Mc\" prefix stands for M2M communication. The Mca reference point enables AEs to use the services provided  
\begin{table}
\begin{tabular}{l l l l l l} \hline \hline  
by the CSE, and the Mcc reference point enables inter-CSE communications [32]. The Mcn reference point is located between a CSE and the service entities in the underlying networks, such as the device triggering service provided by Third Generation Partnership Project (3 GPP) networks.  
OneM2M does not restrict the Mca, Mcc, and Mcn underlying communication protocols. The \"Binding Protocol\" concept, which represents application and transport layer protocols, such as MQTT, CoAP, or REST over Http, refers to the communication between nodes. Working Group WG3 is a developing standardization of bindings for flows for specific transport protocols [33], as those previously addressed.  
By separating the service layer from the communication layer, OneM2M favors the platform's adaptability and integration with heterogeneous devices and network configurations. This is a key aspect considering the constant evolution of communication protocols for IoMT and the efforts required for its integration with the platform.  
Another important characteristic of OneM2M is its origin. OneM2M is based on the analysis of a set of use cases [34] that involve M2M communications and encompass all their requirements. Particularly for healthcare, three use cases taken considered only integration between devices and applications and disregarded integration with hospital information systems. Moreover, the infrastructure node did not consider tools for data processing. In this sense, we decided to follow a OneM2M-based functional architecture for IoMT device integration, but extended it to fulfill the requirements of the proposed platform.  
In terms of infrastructure and technologies for implementation of M2M, [PERSON] et al. [35] made an extensive review of wireless communication technologies used in M2M-based healthcare solutions. Some of these technologies were considered for the construction of our testbed, as Wi-Fi and LTE.