# An Efficient Interface for the Integration of IoT Devices with Smart Grids
## 4 Architecture
The experimental results also show that the response algorithms, although relatively simple in their implementation, have a relatively high impact when compared to request methods. This cost is due in part to the library used to implement the CoAP protocol. \begin{table}
\begin{tabular}{l l c c c c} \hline \hline
**Type** & **Method** & **Algorithm** & **CoAP (Bytes)** & **OSGP (Bytes)** & **Latency (ns)** \\ \hline Request & PUT\(\rightarrow\)Partial Write & 1 & 512 & 112 & 790 \\ Request & POST\(\rightarrow\)Full Write & 2 & 512 & 88 & 520 \\ Request & GET\(\rightarrow\)Partial Read & 3 & 512 & 64 & 375 \\ Request & GET\(\rightarrow\)Full Read & 4 & 512 & 24 & 275 \\ Request & Partial Write\(\rightarrow\)PUT & 5 & 512 & 112 & 646 \\ Request & Full Write\(\rightarrow\)POST & 6 & 512 & 88 & 390 \\ Request & Partial Read\(\rightarrow\)GET & 7 & 512 & 64 & 196 \\ Request & Full Read\(\rightarrow\)GET & 8 & 512 & 24 & 265 \\ Response & Write\(\rightarrow\)PUT/POST & 9 & 512 & 8 & 470 \\ Response & Read\(\rightarrow\)GET & 10 & 512 & 72 & 440 \\ Response & PUT/POST\(\rightarrow\)Write & 11 & 512 & 8 & 286 \\ Response & GET\(\rightarrow\)Read & 12 & 512 & 72 & 310 \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Packets size and latency of mapping methods running on the PC-based platform. The low latency observed in the results above is due to the type of gateway used in our experiments, a desktop computer that plays the role of a server present in the environment automated by IoT technologies. This approach allows for a low interface impact in conjunction with other features that may be present in home automation systems, for example. However, it is worth noting that a PC-based gateway has high power consumption (e.g., 65 W in a laptop and 200 W in a desktop computer). The ESP-based platform operated at 5 V and drained 52 mA to run the mapping functions, which results in power consumption of about 260 mW. On the other hand, the latency to process each function ranges from 8 to 30 us as it is presented in Table 3.

### Discussion

The experimental results demonstrate that using a low-power platform increases the processing latency significantly (up to two orders of magnitude). However, its impact is negligible when considering the requirements of most of the IoT applications and the typical latency of communication on the Internet. Therefore, the proposed solution enables to integrate the CoAP and OSGP protocols in a solution that presents low latency even when running on an embedded platform. When comparing the solution proposed in this work with that of [33], mainly relating the protocols for SGs (i.e., OSGP and IEC 61850), the solution proposed in this work based on OSGP focuses on end-users (i.e., consumers), while the target audience of solutions such as [33] are energy substations [25]. Besides, integrating CoAP with an SG protocol aimed the end-user to restrict the information available to himself, only in his/her smart meter. The solution presented in [28] does not indicate quantitative results of implementation that validate its API and the gateway that makes use of Graphical User Interface (GUI), which prevents the use in embedded systems with resource restrictions. On the other hand, solutions based on URI mapping require the construction of the URI, as indicated in [23], to carry out the building of the CoAP packet, for instance. It is noteworthy to mention that our evaluations were performed on mapping methods only and did not take the function calls into account. This approach was used because this work describes a mapping layer that integrates a larger IoT system. Another aspect that we did not address in this work is the security of the transmitted data because it does not impact the interface operation directly. We consider that security is a requirement that can be addressed directly at the sender and receiver ends, which is beyond the scope of this work. Finally, it must be highlighted that the current version of