## 4 Dataset Generation
### Dataset Setup  
One of the most promising protocols for small devices is CoAP. It is intended to be used for web transfer with restricted devices and networks, such as scenarios with power constraints or dissipating lines. It is created to communicate machine to machine applications, according to a request-response model. It is capable of discovering both services and  
Figure 1: Virtual scenario, including a CoAP client and four CoAP servers (InRows). resources. Moreover, it takes into account very important web ideas, such as the unified resource identification (URI) and media types. For this reason, it can communicate with HTTP; however, at the same time, it allows for multicast communications, very slight overhead, and plainness for limited scenarios. CoAP employs UDP at the transport layer, so it communicates with unreliable and connectionless datagrams [2]. The UDP port is 5683. The structure used in this scenario for the exchange of messages in each of the roles used by every host is described below:  
* Client: The client sends CoAP request messages to InRows (servers). These messages are of type NON (non-confirmable) and do not require a confirmation ACK message (the network will be less overloaded and the devices will consume fewer resources when processing and sending these messages). The request sent by the client has the following structure:
* Version: the value of this field will be 1 (01). * Type: since the messages will be of type NON, the value will be 1 (01). * Code: the messages that are sent from the client requesting a resource from the server will be of the GET method. Therefore, the value of the code field will be 1 (0.01). * Message ID: this is calculated according to the message sent; the message id increases according to each message and follows a chronological order. * Token: each token is a unique and randomly generated field of the message. The size of this token is 4 bytes, the minimum size recommended. * Options: the options used are URI-Host and URI-Path, able to correctly identify the resource on the corresponding server. We will also add the Accept option with value 0, which indicates that the format of resource representation that the client accepts is plain text (text/plain). * Server: the InRows will act as servers, sending back responses to the client. The scenario includes four servers: InRow (1) www.inrow13.gal, (2) www.inrow15.gal, (3) www.inrow23.gal, and (4) www.inrow25.gal. Each InRow has four sensors, whose resource identifier or URI-Path in CoAP will be 1, 2, 3, and 4. The responses sent by the server have the following structure:
* Version: the same as the original message (01). * Type: the same type as the original message (type NON, 01). * Code: the response code is 2.05 Content, which includes a representation of the requested resource. * Message ID: this is generated randomly for each reply message. * Token: the same as the request message. * Options: the URI-Host and URI-Path options are the same as the request. The Content-Format option is also added, which specifies the representation format of the object included in the payload field of the message (in our case, the value will be 0, text/plain). * Payload: this field includes a representation of the object, which is the temperature measured by the sensor in this specific scenario. The Python code shown below indicates how the client constructs the message for each of the InRow nodes:  
```
forserver,ipinself.servers: forsensorinself.sensors: coapPackage=CoAP(ver=1,type=1, code=1,msg_id=, self.create_msgID, token=self.create_token, options=[(''Uri-Host'',server), ''Uri-Path'',sensor), (''Accept'', b''{''x00''}],
```paymark = b''{xff''} packet = (IP(dst=ip) / UDP(sport=5683, dport=5683) / coapPackage)  
Next, the code shown below indicates the reply code from the server to the client.