# An Efficient Interface for the Integration of IoT Devices with Smart Grids
## 4 Architecture  
The solution proposed in this work is named COIIoT, the acronym for \"CoAP and OSGP Integration for Internet of Things\". This section presents the architecture of COIIoT, including the algorithms that describe its mapping methods. We employed the default frameworks of CoAP and OSGP without any modification. For the integration between the protocols, we applied a function mapping layer, individually assigning each type of request/response. We defined the mapping between packets so that the OSGP packet travels internally in CoAP and vice-versa. The proposed model acts as a gateway, serving for the integration between the protocols. Its structure is shown in Figure 3. CoAP uses UDP on the transport layer to travel to the gateway, while OSGP travels through its specific protocols to SGs, i.e., ISO/IEC 14908, and ETSI TS 103 908. We also addressed the mapping of requests and responses and used two packet types in OSGP: request (which is categorized as Full or Partial) and response. For CoAP, we implemented the PUT, GET, and POST methods and use the MicroCoAP [34] library for implementation. This library was chosen because it has a small size and comprises all the methods necessary for this work. The entire development was done using C language to enable future implementations on resource-constrained devices such as microcontrollers. As specified by the application layer [24], the OSGP transmission packet has all the message fields in Most Significant Byte (MSB) format, with the data field being the only exception. For security reasons, all the messages carry a sequence number and a summary. For pending tables, the Pending Event Descriptor (PED) is included in all count and length fields when this information is present. The current version of COIIoT does not yet fully implement the support for pending tables, as it is not a requirement for communication. However, this version already provides the treatment of this structure in code if it is requested. The checksum is calculated based on the PED and data fields. The offset is not influenced by the presence of the PED in partial reads and writes. For instance, to read four bytes of offset three from a pending table, count would equal 10, and offset would equal 3 [35]. Through the table ID, the device using OSGP knows whether it must wait for the PED or not. Figure 4 shows the packet mapping between CoAP and OSGP. In this figure, the client CoAP sends a message directed to the SG network via COIIoT) interface. CoAP executes a GET method using the MicroCoAP library, which is mapped to an OSGP Partial Read request. At the mapping, the CoAP-based packet extracts the request type, the message identifier, and the packet size, and then analyzes the received message. Afterward, the mapping layer matches the request received from CoAP to a request to be sent to OSGP. The payload of the CoAP packet is mapped into two fields of the OSGP packet. The first field (count) contains the message size, and the second field (offset) encloses the contents of the message. Figure 4: Mapping a request packet from CoAP to OSGP. Figure 3: COIIoT architecture. In Figure 5, the OSGP packet inserted into PED for pending queue management is shown; it will be included in the options field of CoAP. The count field reports the message size and is mapped directly to the payload size field of the CoAP packet. Among the services mapped between CoAP and OSGP, some of them depend on information from other protocols and implementations, such as pending events from OSGP. Figure 6 illustrates the application context of the COIIoT interface. The access to the information present in OSGP-based smart meters can be done utilizing devices that use CoAP to control the information transmitted in a smart home. Algorithms 1-4 describe the methods used to map requests from the CoAP domain to the OSGP domain. It is worth noting that in the OSGP domain, a packet is called Application Protocol Data Unit (APDU).