factors such as the distance from the base station, link budget, re-transmissions, aging of the battery, or collisions. While the simplicity of the model can be beneficial in terms of ease of use, it is advisable to consider these additional factors for a more comprehensive and accurate estimation of battery life in practical scenarios.

## 6.5. Metadata Comparison

In this section, we evaluated the impact of the new metadata proposed in this article against the metadata proposed in [17]. Consider the metadata defined in Listing 40. This metadata corresponds to a payload of 9294 bytes in the dataset 3 from [46].

**Listing 40.** Old definition example of Metadata in [17].

```
{bt: 1593982800, dt:10, bp:3}
```

The first thing to note is that the proposed metadata takes into account that strings are not optimised in CBOR, and therefore, strings such as "bp" are represented as the integer 3.

Another aspect is the use of the "context" in the metadata proposed in this article. In comparison, the metadata outlined in [17] requires the transmission of all metadata in every packet. In this proposal, once the proxy has gained knowledge of the "context", it is no longer necessary to transmit the full payload, but only the "context" is transmitted.

The representation of the metadata in Listing 40 in the metadata defined in Section 5.5 is depicted in Listing 41. It consists of 13 bytes as opposed to the 17 bytes used in Listing 40. Furthermore, when only the "context" 0:1 is transmitted, it is represented by only 3 bytes in CBOR.

**Listing 41.** New definition example of metadata in [17].

```
{0:1, 1: 1593982800, 2:10, 3:3}
```

Table 5 compares the total number of bytes required to represent metadata. It also shows the percentage of the metadata size in bytes compared to the payload represented in 9294 bytes. The analysis was conducted considering three cases: the first case represents a LoRaWAN network operating with a SF of 7 and the maximum allowed payload size, the second case represents a Wi-Fi network with a Maximum Transmission Unit (MTU) of 1468 bytes, and the third case depicts an LTE/5G network with an MTU of 1428 bytes [17].

<table><caption>**Table 5.** Metadata comparison between actual proposal and proposed in [17].</caption><thead><tr><th rowspan="2"></th><th colspan="3">Metadata Defined in [17]</th><th colspan="3">New Definition of Metadata</th></tr><tr><th>LoRaWAN</th><th>Wi-Fi</th><th>LTE/5G</th><th>LoRaWAN</th><th>Wi-Fi</th><th>LTE/5G</th></tr></thead><tbody><tr><th>Packets number</th><td>10</td><td>2</td><td>2</td><td>10</td><td>2</td><td>2</td></tr><tr><th>Size in Bytes</th><td>170</td><td>34</td><td>34</td><td>40</td><td>16</td><td>16</td></tr><tr><th>Percentage(%)</th><td>1.9</td><td>0.4</td><td>0.4</td><td>0.5</td><td>0.2</td><td>0.2</td></tr></tbody></table>

In addition to the size reduction in the payload, it is also important to note the flexibility of the metadata thanks to the specific metadata depicted in Section 5.5.2. In addition to the reduction in payload size compared to [17] for the metadata, it also offers flexibility thanks to the specific metadata presented in Section 5.5.2. For example, Listing 42 allows the specification of different measurement periodicity, such as temperature readings every 30 s and humidity readings every 45 s, which is not possible in the metadata defined in [17].
**Listing 42.** Change of periodicity for different measurements in metadata. The key-value 2:value for each map that can be identified overrides the periodicity in the general metadata.

```json
[{0:2, 1: 1593982800}, [{2:30,5: 'Cel'}, ], [{2:45,5: '%RH'}, ]]
```

Moreover, as in Listing 42 is also possible to change the unit of the measurement 5: 'Cel' which is not currently possible in the metadata described in [17].

# 7. Discussion

In this section, we delve into certain use cases that may arise during the transmission of data. Our discussion aims to explore whether it is possible to represent the measurements in alternative metric units. Additionally, we explore what happens if a package containing the context of the measurements is lost. Moreover, we analyze scenarios where time series representation is not necessary in the network due to the real-time nature of the data. Lastly, we examine how it is feasible to transform data into other formats apart from the commonly used SenML or JSON. These use cases will help us in assessing the robustness and flexibility of the proposed approach, especially in the face of unforeseen challenges and issues that may arise in real-world IoT applications.

## 7.1. Other Units

One aspect that requires revision is the units of measurement defined in the metadata. Even though they are standardized by the IANA, there are certain units that may not be in this definition. For example, when utilized for GPS, the units latitude and longitude are defined, but degrees (°), minutes (′), and seconds (″) (DMS coordinates) are also possible to use to represent GPS coordinates. However, this representation is difficult to represent using our definitions for VTS template and metadata, and may not reduce the amount of data transmitted. For instance, consider Listing 43 a coordinate example in DMS format, this uses 13 bytes to be represented in JSON format, while in CBOR it uses 15 bytes.

**Listing 43.** GPS coordinate example in DMS format.

```
[
  40° 51' 59'' N
]
```

To be represented using our data format and the VTS template, it would be necessary to translate the DMS format to decimal format and then it will be possible to transmit the corresponding information, which implies a double translation process leading to an increase in the processing power and time used to translate the data.

## 7.2. Lost Context

Another aspect that requires consideration is the context defined in the metadata. It can decrease considerably the amount of data needed to represent the metadata in different measurements; however, if a message is lost during a specification of the context, then default values will be taken when translating the data. This may result in errors in the final representation or even a lack of knowledge of the unit of each measurement present in the time series. For example, consider the GPS data represented in Listing 44.

**Listing 44.** The JSON representation of the first six measurements in the GPS real world data.

```json
[
  {'n': 'Latitude', 'u': 'Lat', 't': 1667135896307, 'v': -29.620745},
  {'n': 'Longitude', 'u': 'Lon', 't': 1, 'v': -51.127167},
  {'n': 'Velocity', 'u': 'm/s', 't': 1, 'v': 0.024192},
  {'n': 'Latitude', 'u': 'Lat', 't': 1, 'v': -29.622693},
  {'n': 'Longitude', 'u': 'Lon', 't': 1, 'v': -51.131297},
  {'n': 'Velocity', 'u': 'm/s', 't': 1, 'v': 12.534}
]
```
**Listing 42.** Change of periodicity for different measurements in metadata. The key-value 2:value for each map that can be identified overrides the periodicity in the general metadata.

```json
[{0:2, 1: 1593982800}, [{2:30,5: 'Cel'}, ], [{2:45,5: '%RH'}, ]]
```

Moreover, as in Listing 42 is also possible to change the unit of the measurement 5: 'Cel' which is not currently possible in the metadata described in [17].

## 7. Discussion

In this section, we delve into certain use cases that may arise during the transmission of data. Our discussion aims to explore whether it is possible to represent the measurements in alternative metric units. Additionally, we explore what happens if a package containing the context of the measurements is lost. Moreover, we analyze scenarios where time series representation is not necessary in the network due to the real-time nature of the data. Lastly, we examine how it is feasible to transform data into other formats apart from the commonly used SenML or JSON. These use cases will help us in assessing the robustness and flexibility of the proposed approach, especially in the face of unforeseen challenges and issues that may arise in real-world IoT applications.

### 7.1. Other Units

One aspect that requires revision is the units of measurement defined in the metadata. Even though they are standardized by the IANA, there are certain units that may not be in this definition. For example, when utilized for GPS, the units latitude and longitude are defined, but degrees (°), minutes (′), and seconds (″) (DMS coordinates) are also possible to use to represent GPS coordinates. However, this representation is difficult to represent using our definitions for VTS template and metadata, and may not reduce the amount of data transmitted. For instance, consider Listing 43 a coordinate example in DMS format, this uses 13 bytes to be represented in JSON format, while in CBOR it uses 15 bytes.

**Listing 43.** GPS coordinate example in DMS format.

```
[
  40° 51' 59'' N
]
```

To be represented using our data format and the VTS template, it would be necessary to translate the DMS format to decimal format and then it will be possible to transmit the corresponding information, which implies a double translation process leading to an increase in the processing power and time used to translate the data.

### 7.2. Lost Context

Another aspect that requires consideration is the context defined in the metadata. It can decrease considerably the amount of data needed to represent the metadata in different measurements; however, if a message is lost during a specification of the context, then default values will be taken when translating the data. This may result in errors in the final representation or even a lack of knowledge of the unit of each measurement present in the time series. For example, consider the GPS data represented in Listing 44.

**Listing 44.** The JSON representation of the first six measurements in the GPS real world data.

```json
[
  {'n': 'Latitude', 'u': 'Lat', 't': 1667135896307, 'v': -29.620745},
  {'n': 'Longitude', 'u': 'Lon', 't': 1, 'v': -51.127167},
  {'n': 'Velocity', 'u': 'm/s', 't': 1, 'v': 0.024192},
  {'n': 'Latitude', 'u': 'Lat', 't': 1, 'v': -29.622693},
  {'n': 'Longitude', 'u': 'Lon', 't': 1, 'v': -51.131297},
  {'n': 'Velocity', 'u': 'm/s', 't': 1, 'v': 12.534}
]
```
Then, the corresponding VTS template is depicted in Listing 45.

<caption>**Listing 45.** VTS template for Listing 44.</caption>

```json
[ { 'n': 'Latitude', 'u': 'Lat', 'v': TAGN(0, True) },
{ 'n': 'Longitude', 'u': 'Lon', 'v': TAGN(1, True) },
{ 'n': 'Velocity', 'u': 'm/s', 'v': TAGN(2, True) }
]
```

After the data processing to build the context and the CBOR data item to send the first two measurements of the GPS data are depicted in Listing 46 and Listing 47 respectively.

<caption>**Listing 46.** Context for CBOR data item needed to send the first three measurements of the GPS data.</caption>

```json
[ {0:1, 1:1667135896307, 2:1, 3:6} ]
```

<caption>**Listing 47.** CBOR data item needed to send the first three measurements of the GPS data.</caption>

```json
[
  {0:1},
  [-29620745, -1984],
  [-51127167, -4130],
  [24192, 11658]
]
```

In case the context is lost, the translation into the JSON data format presented in Listing 44 will face errors due to it will not have a context, and will select the default values (precision of 2 instead of 6, the reception time will be taken instead of 1667135896307, and a difference in time of 60 s instead of 1 s), which differs from reality leading a wrong representation depicted in Listing 48.

<caption>**Listing 48.** The JSON representation of the GPS real world data with context lost.</caption>

```json
[{ 'n': 'Latitude', 'u': 'Lat', 't': *reception time, 'v': -296207.45 },
{ 'n': 'Longitude', 'u': 'Lon', 't': 60, 'v': -511271.67 },
{ 'n': 'Velocity', 'u': 'm/s', 't': 60, 'v': 241.92 }
{ 'n': 'Latitude', 'u': 'Lat', 't': 60, 'v': -296226.93 },
{ 'n': 'Longitude', 'u': 'Lon', 't': 60, 'v': -511312.97 },
{ 'n': 'Velocity', 'u': 'm/s', 't': 60, 'v': 125.34 }
]
```

### 7.3. Real Time Data

While it is common practice to save IoT data in time series for analysis purposes, there are certain situations where real-time data transmission is necessary. One such scenario is where quick response times are critical. For example, in industrial applications where sensor readings must be acted upon immediately. In these cases, data must be transmitted and analyzed in real-time to ensure the proper functioning of the system.

Then, consider a sensor of temperature sending one measurement using JSON and SenML format.

Listing 49 takes 56 bytes to be transmitted, represented in CBOR only takes 40 bytes, 36 bytes when represented with ASN.1, and 31 bytes when represented with Protocol buffers. Instead, if the VTS representation depicted in Listing 50 is used, only 14 bytes are necessary to represent the same information. Leading to a reduction of the 20% for CBOR and the 75% for VTS, and when compared protocols such as ASN.1 or Protocol buffers with VTS, leads to a reduction of 61% and 54%, respectively.

<caption>**Listing 49.** One single measurement of temperature using JSON and SenML format.</caption>

```json
[{ 'n': 'Temperature', 'u': 'Cel', 't': 1650830443, 'v': 20.45 }]
```
Then, the corresponding VTS template is depicted in Listing 45.

<caption>**Listing 45.** VTS template for Listing 44.</caption>

```json
[ { 'n': 'Latitude', 'u': 'Lat', 'v': TAGN(0, True) },
{ 'n': 'Longitude', 'u': 'Lon', 'v': TAGN(1, True) },
{ 'n': 'Velocity', 'u': 'm/s', 'v': TAGN(2, True) }
]
```

After the data processing to build the context and the CBOR data item to send the first two measurements of the GPS data are depicted in Listing 46 and Listing 47 respectively.

<caption>**Listing 46.** Context for CBOR data item needed to send the first three measurements of the GPS data.</caption>

```json
[ {0:1, 1:1667135896307, 2:1, 3:6} ]
```

<caption>**Listing 47.** CBOR data item needed to send the first three measurements of the GPS data.</caption>

```json
[
  {0:1},
  [-29620745, -1984],
  [-51127167, -4130],
  [24192, 11658]
]
```

In case the context is lost, the translation into the JSON data format presented in Listing 44 will face errors due to it will not have a context, and will select the default values (precision of 2 instead of 6, the reception time will be taken instead of 1667135896307, and a difference in time of 60 s instead of 1 s), which differs from reality leading a wrong representation depicted in Listing 48.

<caption>**Listing 48.** The JSON representation of the GPS real world data with context lost.</caption>

```json
[{ 'n': 'Latitude', 'u': 'Lat', 't': *reception time, 'v': -296207.45 },
{ 'n': 'Longitude', 'u': 'Lon', 't': 60, 'v': -511271.67 },
{ 'n': 'Velocity', 'u': 'm/s', 't': 60, 'v': 241.92 }
{ 'n': 'Latitude', 'u': 'Lat', 't': 60, 'v': -296226.93 },
{ 'n': 'Longitude', 'u': 'Lon', 't': 60, 'v': -511312.97 },
{ 'n': 'Velocity', 'u': 'm/s', 't': 60, 'v': 125.34 } ]
```

### 7.3. Real Time Data

While it is common practice to save IoT data in time series for analysis purposes, there are certain situations where real-time data transmission is necessary. One such scenario is where quick response times are critical. For example, in industrial applications where sensor readings must be acted upon immediately. In these cases, data must be transmitted and analyzed in real-time to ensure the proper functioning of the system.

Then, consider a sensor of temperature sending one measurement using JSON and SenML format.

Listing 49 takes 56 bytes to be transmitted, represented in CBOR only takes 40 bytes, 36 bytes when represented with ASN.1, and 31 bytes when represented with Protocol buffers. Instead, if the VTS representation depicted in Listing 50 is used, only 14 bytes are necessary to represent the same information. Leading to a reduction of the 20% for CBOR and the 75% for VTS, and when compared protocols such as ASN.1 or Protocol buffers with VTS, leads to a reduction of 61% and 54%, respectively.

<caption>**Listing 49.** One single measurement of temperature using JSON and SenML format.</caption>

```json
[{ 'n': 'Temperature', 'u': 'Cel', 't': 1650830443, 'v': 20.45 }]
```
**Listing 50.** Listing 49 in VTS representation. It is important to note, that as the time is not defined the default value in the metadata is assigned (the reception time).

[{0:1}, [{5:'Cel'}, 2045]]

Additionally, as mentioned in Section 6.2, 18 bytes are necessary to add in the payload which corresponds to the headers from the protocols IP/UDP and CoAP over SCHC, and the headers from LoRaWAN in the MAC and application layer.

Consequently, if we consider an application scenario transmitting one package per minute with a battery capacity of ($C_{battery} = 2700$ mAh) to calculate the Time-on-Air and Battery Lifetime, we obtain the results depicted in Figures 14 and 15.

When represented in the VTS format, the Time-on-Air is reduced by about 56% (e.g., from 0.107 s to 0.046 s in SF 7) compared to JSON, around 44% (e.g., from 0.082 s to 0.046 s in SF 7) compared to CBOR, around 40% (e.g., from 0.077 s to 0.046 s in SF 7) compared to ASN.1 and around 35% (e.g., from 0.071 s to 0.046 s in SF 7) compared to Protocol buffers. Finally, the Battery Lifetime is increased by around 1.99 times (e.g., from 14.6 months to 29.2 months in SF 7) compared to sending the same information represented in JSON, a 1.7-fold increase (e.g., from 18.4 months to 29.2 months in SF 7) compared to sending the same information represented in CBOR, a 1.5-fold increase (e.g., from 19.5 months to 29.2 months in SF 7) compared to sending the same information represented in ASN.1, and a 1.4-fold increase (e.g., from 20.6 months to 29.2 months in SF 7) compared to sending the same information represented in Protocol buffers.

<figure><img src="image_16.png" /><figcaption>**Figure 14.** Time-on-Air comparison for real-time data payload per SF.</figcaption></figure>

It is also important to note that while real-time data transmission can be useful in certain scenarios, it is not always necessary. In many cases, time series data storage and analysis are sufficient for identifying trends and making informed decisions. Ultimately, the decision to use real time data transmission versus time series data storage and analysis depends on the specific use case and requirements of the system.

However, if it is necessary to start batching the measurements, the effectiveness of the reduction will gradually increase depending on how many bytes are reduced per measurement in each template, as it varies proportionately to the number of bytes required to represent the difference between measurements.
**Listing 50.** Listing 49 in VTS representation. It is important to note, that as the time is not defined the default value in the metadata is assigned (the reception time).

[{0:1}, [{5:'Cel'}, 2045]]

Additionally, as mentioned in Section 6.2, 18 bytes are necessary to add in the payload which corresponds to the headers from the protocols IP/UDP and CoAP over SCHC, and the headers from LoRaWAN in the MAC and application layer.

Consequently, if we consider an application scenario transmitting one package per minute with a battery capacity of ($C_{battery} = 2700$ mAh) to calculate the Time-on-Air and Battery Lifetime, we obtain the results depicted in Figures 14 and 15.

When represented in the VTS format, the Time-on-Air is reduced by about 56% (e.g., from 0.107 s to 0.046 s in SF 7) compared to JSON, around 44% (e.g., from 0.082 s to 0.046 s in SF 7) compared to CBOR, around 40% (e.g., from 0.077 s to 0.046 s in SF 7) compared to ASN.1 and around 35% (e.g., from 0.071 s to 0.046 s in SF 7) compared to Protocol buffers. Finally, the Battery Lifetime is increased by around 1.99 times (e.g., from 14.6 months to 29.2 months in SF 7) compared to sending the same information represented in JSON, a 1.7-fold increase (e.g., from 18.4 months to 29.2 months in SF 7) compared to sending the same information represented in CBOR, a 1.5-fold increase (e.g., from 19.5 months to 29.2 months in SF 7) compared to sending the same information represented in ASN.1, and a 1.4-fold increase (e.g., from 20.6 months to 29.2 months in SF 7) compared to sending the same information represented in Protocol buffers.

<figure><img src="image_16.png" /><figcaption>**Figure 14.** Time-on-Air comparison for real-time data payload per SF.</figcaption></figure>

It is also important to note that while real-time data transmission can be useful in certain scenarios, it is not always necessary. In many cases, time series data storage and analysis are sufficient for identifying trends and making informed decisions. Ultimately, the decision to use real time data transmission versus time series data storage and analysis depends on the specific use case and requirements of the system.

However, if it is necessary to start batching the measurements, the effectiveness of the reduction will gradually increase depending on how many bytes are reduced per measurement in each template, as it varies proportionately to the number of bytes required to represent the difference between measurements.
<figure><img src="image_17.png" /><figcaption>Figure 15. Battery lifetime comparison for real-time data payload per SF.</figcaption></figure>

### 7.4. Transformation into Any Data Format

Our approach aimed to convert the VTS representation, which includes additional data to represent the context of measurements, into any format required by the IoT cloud application. This means that various data formats, such as SenML, JSON, RDF/turtle, RDF/XML, RDF/JSON-LD, or even RDF/EXI can be generated based on the template used and the processing carried out by the proxy in the architecture shown in Section 4.

To achieve the transformation, the template used must be tailored to the desired format. This process enables the data to be transformed into a more suitable format for specific applications. For example, an instance where the data are represented in RDF/XML format is depicted in Listing 7. In order to define the template for this specific format, Listing 51 can be used as a reference.

**Listing 51.** The RDF / XML template representation of the Listing 7. Here the TAGN identify the variables values of the current and voltage.

```xml
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/.../22-rdf-syntax-ns#"
         xmlns:ex="http://...#">
    <rdf:Description rdf:about="urn:::0024...804ff1/current">
        <ex:time></ex:time>
        <ex:unit></ex:unit>
        <ex:value>TAGN(0, true)</ex:value>
    </rdf:Description>

    <rdf:Description rdf:about="urn:::0024...804ff1/voltage">
        <ex:time></ex:time>
        <ex:unit></ex:unit>
        <ex:value>TAGN(1, true)</ex:value>
    </rdf:Description>
</rdf:RDF>
```

Furthermore, once the template is defined, sending only one CBOR data item in VTS format (as shown in Listing 50) is sufficient to represent the data in Listing 7.
<figure><img src="image_17.png" /><figcaption>**Figure 15.** Battery lifetime comparison for real-time data payload per SF.</figcaption></figure>

### 7.4. Transformation into Any Data Format

Our approach aimed to convert the VTS representation, which includes additional data to represent the context of measurements, into any format required by the IoT cloud application. This means that various data formats, such as SenML, JSON, RDF/turtle, RDF/XML, RDF/JSON-LD, or even RDF/EXI can be generated based on the template used and the processing carried out by the proxy in the architecture shown in Section 4.

To achieve the transformation, the template used must be tailored to the desired format. This process enables the data to be transformed into a more suitable format for specific applications. For example, an instance where the data are represented in RDF/XML format is depicted in Listing 7. In order to define the template for this specific format, Listing 51 can be used as a reference.

**Listing 51.** The RDF / XML template representation of the Listing 7. Here the TAGN identify the variables values of the current and voltage.

```xml
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/.../22-rdf-syntax-ns#"
         xmlns:ex="http://...#">
    <rdf:Description rdf:about="urn:::0024...804ff1/current">
        <ex:time></ex:time>
        <ex:unit></ex:unit>
        <ex:value>TAGN(0, true)</ex:value>
    </rdf:Description>

    <rdf:Description rdf:about="urn:::0024...804ff1/voltage">
        <ex:time></ex:time>
        <ex:unit></ex:unit>
        <ex:value>TAGN(1, true)</ex:value>
    </rdf:Description>
</rdf:RDF>
```

Furthermore, once the template is defined, sending only one CBOR data item in VTS format (as shown in Listing 50) is sufficient to represent the data in Listing 7.
Upon comparing Listing 8 with Listing 52, we can see that the RDF/EXI format repeats the same information in the data as IDs, whereas our proposed approach eliminates the need of sending this information as it is handled in the data transformation process at the proxy side.

<caption>**Listing 52.** Listing 49 in VTS representation.</caption>

```json
[{0:1,1:1276020074,2:1,3:1}, [{5:'Cel'}, 15, 1, 1], [{5:'V'}], 1201}]
```

Finally, it is also important for future research to consider the processing time of data transformation at the proxy side of the architecture.

## 8. Conclusions

As IoT networks expand rapidly, they entail a massive deployment of IoT devices and an incredible amount of data generated by these devices. Interoperability is a major challenge that must be addressed, especially the diversity of devices with distinct data formats. The communication among IoT devices is impeded by the lack of semantic data and common standards for data interpretation, as well as the device incompatibility at the data layer, due to the dynamic nature of the data. Furthermore, the data must be discoverable, which is difficult with enormous volumes of remote networks and cloud-based data. Therefore, this article proposed a novel data format for time series based on CBOR. It enhances the efficiency and interoperability of IoT devices by decoupling the application data format from the sensor data format and reducing the amount of data sent while preserving the same information. We have validated our approach with different data types such as GPS measurements, and have evaluated battery life, Fragmentation, and Time-on-Air to demonstrate its benefits.

The experimental results showed that our approach reduces the actual data sent by IoT devices by between 88% to 94% compared to JSON. It also reduces the Time-on-Air by 84% to 94%, resulting in a 12-fold increase in battery life when compared to the payload in JSON format. Then, when our approach was compared against binary formats such as ASN.1, CBOR, and Protocol buffers, it results in a reduction of the payload of between 54% to 75%, which leads to an increase of battery life of between 1.4 times to 17 times. It should be noted that these results are highly dependent on the implementation of the various binary formats and the nature of the data used in this article. Consequently, other implementations may differ slightly depending on these factors. For example, the results may differ depending on how the schema is selected in ASN.1 or in the type and TAG selection in CBOR.

Moreover, our approach provides a very compact format for time series data that reduces the dependency between cloud applications and IoT devices, since with VTS it is possible to transform to any data format required by the cloud application. Then, our approach can be useful in scenarios where the network bandwidth is limited, allowing for more efficient data transmission and meeting the specific requirements of the target application.

The CDDL code enables the validation of any CBOR structure to check if it follows the rules of the proposed data format for time series. This will facilitate the future transformation of the generated time series into any data format needed by the cloud application by verifying if the structure is well formed or not before proceeding with the transformation process. Furthermore, with the refined metadata, we achieved flexibility in representing different data types and changing the context depending on the application's needs. However, future work will investigate how to retrieve the context of a packet containing the values when the context is lost.

Finally, we assert that this approach possesses the potential to be presented and deliberated upon within the working groups of the Internet Engineering Task Force (IETF), as a means to initiate a discussion regarding the establishment of a standardized representation for time series utilizing CBOR templates.
Upon comparing Listing 8 with Listing 52, we can see that the RDF/EXI format repeats the same information in the data as IDs, whereas our proposed approach eliminates the need of sending this information as it is handled in the data transformation process at the proxy side.

<caption>**Listing 52.** Listing 49 in VTS representation.</caption>

```json
[{0:1,1:1276020074,2:1,3:1}, [{5:'Cel'}, 15, 1, 1], [{5:'V'}], 1201}]
```

Finally, it is also important for future research to consider the processing time of data transformation at the proxy side of the architecture.

## 8. Conclusions

As IoT networks expand rapidly, they entail a massive deployment of IoT devices and an incredible amount of data generated by these devices. Interoperability is a major challenge that must be addressed, especially the diversity of devices with distinct data formats. The communication among IoT devices is impeded by the lack of semantic data and common standards for data interpretation, as well as the device incompatibility at the data layer, due to the dynamic nature of the data. Furthermore, the data must be discoverable, which is difficult with enormous volumes of remote networks and cloud-based data. Therefore, this article proposed a novel data format for time series based on CBOR. It enhances the efficiency and interoperability of IoT devices by decoupling the application data format from the sensor data format and reducing the amount of data sent while preserving the same information. We have validated our approach with different data types such as GPS measurements, and have evaluated battery life, Fragmentation, and Time-on-Air to demonstrate its benefits.

The experimental results showed that our approach reduces the actual data sent by IoT devices by between 88% to 94% compared to JSON. It also reduces the Time-on-Air by 84% to 94%, resulting in a 12-fold increase in battery life when compared to the payload in JSON format. Then, when our approach was compared against binary formats such as ASN.1, CBOR, and Protocol buffers, it results in a reduction of the payload of between 54% to 75%, which leads to an increase of battery life of between 1.4 times to 17 times. It should be noted that these results are highly dependent on the implementation of the various binary formats and the nature of the data used in this article. Consequently, other implementations may differ slightly depending on these factors. For example, the results may differ depending on how the schema is selected in ASN.1 or in the type and TAG selection in CBOR.

Moreover, our approach provides a very compact format for time series data that reduces the dependency between cloud applications and IoT devices, since with VTS it is possible to transform to any data format required by the cloud application. Then, our approach can be useful in scenarios where the network bandwidth is limited, allowing for more efficient data transmission and meeting the specific requirements of the target application.

The CDDL code enables the validation of any CBOR structure to check if it follows the rules of the proposed data format for time series. This will facilitate the future transformation of the generated time series into any data format needed by the cloud application by verifying if the structure is well formed or not before proceeding with the transformation process. Furthermore, with the refined metadata, we achieved flexibility in representing different data types and changing the context depending on the application's needs. However, future work will investigate how to retrieve the context of a packet containing the values when the context is lost.

Finally, we assert that this approach possesses the potential to be presented and deliberated upon within the working groups of the Internet Engineering Task Force (IETF), as a means to initiate a discussion regarding the establishment of a standardized representation for time series utilizing CBOR templates.
**Author Contributions:** Conceptualization, S.M.A., L.T. and G.Z.P.; methodology, S.M.A., I.M., L.T. and G.Z.P.; software, S.M.A.; validation, I.M., G.Z.P., L.T. and N.M.; formal analysis, I.M.; investigation, S.M.A.; resources, S.M.A.; data curation, S.M.A.; writing—original draft preparation, S.M.A.; writing—review and editing, I.M., G.Z.P., L.T. and N.M.; supervision, G.Z.P., L.T. and N.M.; project administration, G.Z.P., L.T. and N.M.; funding acquisition, N.M., L.T. and G.Z.P. All authors have read and agreed to the published version of the manuscript.

**Funding:** This research received no external funding.

**Institutional Review Board Statement:** Not applicable.

**Informed Consent Statement:** Not applicable.

**Data Availability Statement:** Publicly available datasets were analyzed in this study. These data can be found here: [https://github.com/sebasmol96/Time-Series-data-set-for-CBOR-templates]. (accessed on 1 March 2023).

**Conflicts of Interest:** The authors declare no conflict of interest.

## References

1. Bouzembrak, Y.; Klüche, M.; Gavai, A.; Marvin, H.J. Internet of Things in food safety: Literature review and a bibliometric analysis. *Trends Food Sci. Technol.* **2019**, *94*, 54–64. [CrossRef]

2. Koohang, A.; Sargent, C.S.; Nord, J.H.; Paliszkiewicz, J. Internet of Things (IoT): From awareness to continued use. *Int. J. Inf. Manag.* **2022**, *62*, 102442. [CrossRef]

3. Brous, P.; Janssen, M.; Herder, P. The dual effects of the Internet of Things (IoT): A systematic review of the benefits and risks of IoT adoption by organizations. *Int. J. Inf. Manag.* **2020**, *51*, 101952. [CrossRef]

4. Insights, F.B. Internet of Things (IoT) Market Size, Share & COVID-19 Impact Analysis, By Component (Platform, Solution & Services), By End-Use Industry (BFSI, Retail, Government, Healthcare, Manufacturing, Agriculture, Sustainable Energy, Transportation, IT & Telecom, Others), and Regional Forecast, 2021–2028. Available online: [https://www.fortunebusinessinsights.com/industry-reports/internet-of-things-iot-market-100307](https://www.fortunebusinessinsights.com/industry-reports/internet-of-things-iot-market-100307) (accessed on 20 January 2022).

5. Dave Evans, C. The Internet of Things. How the Next Evolution of the Internet Is Changing Everything (White Paper). Available online: [https://www.cisco.com/c/dam/en_us/about/ac79/docs/innov/IoT_IBSG_0411FINAL.pdf](https://www.cisco.com/c/dam/en_us/about/ac79/docs/innov/IoT_IBSG_0411FINAL.pdf) (accessed on 23 January 2022).

6. Jouhari, M.; Amhoud, E.M.; Saeed, N.; Alouini, M.S. A Survey on Scalable LoRaWAN for Massive IoT: Recent Advances, Potentials, and Challenges. *IEEE Commun. Surv. Tutor.* **2023**, *1*–[CrossRef]

7. Venceslau, A.; Andrade, R.; Vidal, V.; Nogueira, T.; Pequeno, V. IoT Semantic Interoperability: A Systematic Mapping Study. In Proceedings of the 21st International Conference on Enterprise Information Systems, Heraklion, Crete, Greece, 3–5 May 2019; SCITEPRESS—Science and Technology Publications: Setübal, Portugal 2019.

8. Tolk, A.; Muguira, J. The Levels of Conceptual Interoperability Model. In Proceedings of the 2003 Fall Simulation Interoperability Workshop, Orlando, FL, USA, 14–19 September 2003; Volume 7, pp. 1–11.

9. Panetto, H.; Cecil, J. Information systems for enterprise integration, interoperability and networking: Theory and applications. *Enterp. Inf. Syst.* **2013**, *7*, 1–6. [CrossRef]

10. oneM2M. oneM2M: Solving the IoT Platform Challenge. In Proceedings of the IoT Slam Internet of Things Conference 2015, Virtual, 9 December 2015.

11. Konduru, V.R.; Bharamagoudra, M.R. Challenges and solutions of interoperability on IoT: How far have we come in resolving the IoT interoperability issues. In Proceedings of the 2017 International Conference on Smart Technologies for Smart Nation (SmartTechCon), Bengaluru, India, 17–19 August 2017; pp. 572–576.

12. Cook, A.A.; Misirli, G.; Fan, Z. Anomaly Detection for IoT Time-Series Data: A Survey. *IEEE Internet Things J.* **2020**, *7*, 6481–6494. [CrossRef]

13. Sabri, C.; Kriaa, L.; Azzouz, S.L. Comparison of IoT Constrained Devices Operating Systems: A Survey. In Proceedings of the 2017 IEEE/ACS 14th International Conference on Computer Systems and Applications (AICCSA), Hammamet, Tunisia, 30 October–3 November 2017; pp. 369–375.

14. Ishaq, I.; Carels, D.; Teklemariam, G.; Hoebeke, J.; Abeele, F.; Poorter, E.; Moerman, I.; Demeester, P. IETF Standardization in the Field of the Internet of Things (IoT): A Survey. *J. Sens. Actuator Netw.* **2013**, *2*, 235–287. [CrossRef]

15. Maudet, G.; Batton-Hbert, M.; Maille, P.; Toutain, L. Emission Scheduling Strategies for Massive-IoT: Implementation and Performance Optimization. In Proceedings of the NOMS 2022-2022 IEEE/IFIP Network Operations and Management Symposium, Budapest, Hungary, 25–29 April 2022.

16. RFC 8949; Bormann, C.; Hoffman, P. Concise Binary Object Representation (CBOR). IETF, 2020. Available online: [https://www.rfc-editor.org/info/rfc8949](https://www.rfc-editor.org/info/rfc8949) (accessed on 10 January 2022).
**Author Contributions:** Conceptualization, S.M.A., L.T. and G.Z.P.; methodology, S.M.A., I.M., L.T. and G.Z.P.; software, S.M.A.; validation, I.M., G.Z.P., L.T. and N.M.; formal analysis, I.M.; investigation, S.M.A.; resources, S.M.A.; data curation, S.M.A.; writing—original draft preparation, S.M.A.; writing—review and editing, I.M., G.Z.P., L.T. and N.M.; supervision, G.Z.P., L.T. and N.M.; project administration, G.Z.P., L.T. and N.M.; funding acquisition, N.M., L.T. and G.Z.P. All authors have read and agreed to the published version of the manuscript.

**Funding:** This research received no external funding.

**Institutional Review Board Statement:** Not applicable.

**Informed Consent Statement:** Not applicable.

**Data Availability Statement:** Publicly available datasets were analyzed in this study. These data can be found here: [https://github.com/sebasmol96/Time-Series-data-set-for-CBOR-templates]. (accessed on 1 March 2023).

**Conflicts of Interest:** The authors declare no conflict of interest.

## References

1. Bouzembrak, Y.; Klüche, M.; Gavai, A.; Marvin, H.J. Internet of Things in food safety: Literature review and a bibliometric analysis. *Trends Food Sci. Technol.* **2019**, *94*, 54–64. [CrossRef]

2. Koohang, A.; Sargent, C.S.; Nord, J.H.; Paliszkiewicz, J. Internet of Things (IoT): From awareness to continued use. *Int. J. Inf. Manag.* **2022**, *62*, 102442. [CrossRef]

3. Brous, P.; Janssen, M.; Herder, P. The dual effects of the Internet of Things (IoT): A systematic review of the benefits and risks of IoT adoption by organizations. *Int. J. Inf. Manag.* **2020**, *51*, 101952. [CrossRef]

4. Insights, F.B. Internet of Things (IoT) Market Size, Share & COVID-19 Impact Analysis, By Component (Platform, Solution & Services), By End-Use Industry (BFSI, Retail, Government, Healthcare, Manufacturing, Agriculture, Sustainable Energy, Transportation, IT & Telecom, Others), and Regional Forecast, 2021–2028. Available online: [https://www.fortunebusinessinsights.com/industry-reports/internet-of-things-iot-market-100307](https://www.fortunebusinessinsights.com/industry-reports/internet-of-things-iot-market-100307) (accessed on 20 January 2022).

5. Dave Evans, C. The Internet of Things. How the Next Evolution of the Internet Is Changing Everything (White Paper). Available online: [https://www.cisco.com/c/dam/en_us/about/ac79/docs/innov/IoT_IBSG_0411FINAL.pdf](https://www.cisco.com/c/dam/en_us/about/ac79/docs/innov/IoT_IBSG_0411FINAL.pdf) (accessed on 23 January 2022).

6. Jouhari, M.; Amhoud, E.M.; Saeed, N.; Alouini, M.S. A Survey on Scalable LoRaWAN for Massive IoT: Recent Advances, Potentials, and Challenges. *IEEE Commun. Surv. Tutor.* **2023**, . [CrossRef]

7. Venceslau, A.; Andrade, R.; Vidal, V.; Nogueira, T.; Pequeno, V. IoT Semantic Interoperability: A Systematic Mapping Study. In Proceedings of the 21st International Conference on Enterprise Information Systems, Heraklion, Crete, Greece, 3–5 May 2019; SCITEPRESS—Science and Technology Publications: Setübal, Portugal 2019.

8. Tolk, A.; Muguira, J. The Levels of Conceptual Interoperability Model. In Proceedings of the 2003 Fall Simulation Interoperability Workshop, Orlando, FL, USA, 14–19 September 2003; Volume 7, pp. 1–11.

9. Panetto, H.; Cecil, J. Information systems for enterprise integration, interoperability and networking: Theory and applications. *Enterp. Inf. Syst.* **2013**, *7*, 1–6. [CrossRef]

10. oneM2M. oneM2M: Solving the IoT Platform Challenge. In Proceedings of the IoT Slam Internet of Things Conference 2015, Virtual, 9 December 2015.

11. Konduru, V.R.; Bharamagoudra, M.R. Challenges and solutions of interoperability on IoT: How far have we come in resolving the IoT interoperability issues. In Proceedings of the 2017 International Conference on Smart Technologies for Smart Nation (SmartTechCon), Bengaluru, India, 17–19 August 2017; pp. 572–576.

12. Cook, A.A.; Misirli, G.; Fan, Z. Anomaly Detection for IoT Time-Series Data: A Survey. *IEEE Internet Things J.* **2020**, *7*, 6481–6494. [CrossRef]

13. Sabri, C.; Kriaa, L.; Azzouz, S.L. Comparison of IoT Constrained Devices Operating Systems: A Survey. In Proceedings of the 2017 IEEE/ACS 14th International Conference on Computer Systems and Applications (AICCSA), Hammamet, Tunisia, 30 October–3 November 2017; pp. 369–375.

14. Ishaq, I.; Carels, D.; Teklemariam, G.; Hoebeke, J.; Abeele, F.; Poorter, E.; Moerman, I.; Demeester, P. IETF Standardization in the Field of the Internet of Things (IoT): A Survey. *J. Sens. Actuator Netw.* **2013**, *2*, 235–287. [CrossRef]

15. Maudet, G.; Batton-Hbert, M.; Maille, P.; Toutain, L. Emission Scheduling Strategies for Massive-IoT: Implementation and Performance Optimization. In Proceedings of the NOMS 2022-2022 IEEE/IFIP Network Operations and Management Symposium, Budapest, Hungary, 25–29 April 2022.

16. RFC 8949; Bormann, C.; Hoffman, P. Concise Binary Object Representation (CBOR). IETF, 2020. Available online: [https://www.rfc-editor.org/info/rfc8949](https://www.rfc-editor.org/info/rfc8949) (accessed on 10 January 2022).
17. Molina Araque, S.; Martinez, I.; Papadopoulos, G.Z.; Montavont, N.; Toutain, L. Toward a Standard Time Series Representation for IoT based on CBOR Templates. In Proceedings of the 2022 Global Information Infrastructure and Networking Symposium (GIIS), Argostoli, Greece, 26–28 September 2022; pp. 13–19.

18. RFC 8259; Bray, E.T. The JavaScript Object Notation (JSON) Data Interchange Format. IETF, 2017. Available online: https://www.rfc-editor.org/info/rfc8259 (accessed on 10 January 2022)

19. RFC 8428; Jennings, C.; Shelby, Z.; Bormann, C.; Arkko, J.; Keranen, A. Sensor Measurement Lists (SenML). IETF, 2018. Available online: https://www.rfc-editor.org/info/rfc8428 (accessed on 10 January 2022)

20. (RDF) 1.1; RDF Working Group. Resource Description Framework. Standard Specification, W3C, 2014. Available online: https://www.w3.org/RDF/ (accessed on 17 April 2023)

21. RFC 8610; Birkholz, C.V.H.; Bormann, C. Concise Data Definition Language (CDDL). IETF, 2019. Available online: https://www.rfc-editor.org/info/rfc8610 (accessed on 10 January 2022)

22. Tomaszuk, D.; Angles, R.; Szeremeta, L.; Litman, K.; Cisterna, D. Serialization for Property Graphs. In *Beyond Databases, Architectures, and Structures. Paving the Road to Smart Data Processing and Analysis, Proceedings of the 15th International Conference, BDAS 2019, Ustroń, Poland, 28–31 May*; Springer: Berlin/Heidelberg, Germany, 2019; pp. 57–69.

23. Pereira, F.; Correia, R.; Pinho, P.; Lopes, S.I.; Carvalho, N.B. Challenges in Resource-Constrained IoT Devices: Energy and Communication as Critical Success Factors for Future IoT Deployment. *Sensors* **2020**, *20*, 6420. [CrossRef] [PubMed]

24. Biswal, A.K.; Al Mallah, O. Analytical Assessment of Binary Data Serialization Techniques in IoT Context (Evaluating Protocol Buffers, Flat Buffers, Message Pack, and BSON for Sensor Nodes. (Politecnico Milano 1863). 2019. Available online: https://www.politesi.polimi.it/handle/10589/150617 (accessed on 26 October 2022).

25. Neufeld, G.; Vuong, S. An overview of ASN.1. *Comput. Netw. ISDN Syst.* **1992**, *23*, 393–415. [CrossRef]

26. Álvaro Luis, Pablo Casares, J.J.C.G.; Patricio, M.A. PSON: A Serialization Format for IoT Sensor Networks. *Sensors* **2021**, *21*, 4559. [CrossRef] [PubMed]

27. Viotti, J.C.; Kinderkhedia, M. A Survey of JSON-compatible Binary Serialization Specifications. *arXiv* **2022**, arXiv:2201.02089.

28. Ivanovo. Comparison of JSON Like Serializations—JSON vs. UJSON vs. MessagePack vs. CBOR. Available online: http://zderadicka.eu/comparison-of-json-like-serializations-json-vs-ubjson-vs-messagepack-vs-cbor/ (accessed on 28 January 2022).

29. Hasemann, H.; Kröller, A.; Pagel, M. RDF provisioning for the Internet of Things. In Proceedings of the 2012 3rd IEEE International Conference on the Internet of Things, Wuxi, China, 24–26 October 2012; pp. 143–150.

30. Kábisch, S.; Peintner, D.; Anicic, D. Standardized and Efficient RDF Encoding for Constrained Embedded Networks. In Proceedings of the 12th European Semantic Web Conference, ESWC 2015, Portoroz, Slovenia, 31 May–4 June 2015; Springer International Publishing: Berlin/Heidelberg, Germany, 2015; pp. 437–452.

31. Fernández, J.D.; Martínez-Prieto, M.A.; Arias, M.; Gutierrez, C.; Álvarez-García, S.; Brisaboa, N.R. Lightweighting the Web of Data through Compact RDF/HDT. In *Advances in Artificial Intelligence*; Springer: Berlin/Heidelberg, Germany, 2011; pp. 483–493.

32. Fernández, N.; Arias, J.; Sánchez, L.; Fuentes-Lorenzo, D.; Corcho, Ó. RDSZ: An Approach for Lossless RDF Stream Compression. In *Lecture Notes in Computer Science*; Springer International Publishing: Berlin/Heidelberg, Germany, 2014; pp. 52–67.

33. Sherif, M.A.; Ngomo, A.C.N.; Lehmann, J. Automating RDF Dataset Transformation and Enrichment. In Proceedings of the 12th European Semantic Web Conference, ESWC 2015, Portoroz, Slovenia, 31 May–4 June 2015; Springer International Publishing: Berlin/Heidelberg, Germany, 2015; pp. 371–387.

34. Manyika, J.; Chui, M.; Bisson, P.; Woetzel, J.; Dobbs, R.; Bughin, J.; Aharon, D. *Unlocking the potential of the Internet of Things*; Global Institute Report; McKinsey & Company: New York, NY, USA, 2015.

35. Kenda, K.; Kazic, B.; Novak, E.; Mladenić, D. Streaming Data Fusion for the Internet of Things. *Sensors* **2019**, *19*, 1424. [CrossRef] [PubMed]

36. Blalock, D.; Madden, S.; Guttag, J. Sprintz: Time Series Compression for the Internet of Things. *ACM Interact. Mob. Wearable Ubiquitous Technol. (IMWUT)* **2018**, *2*, 1–23. [CrossRef]

37. RFC 8724; Minaburo, A.; Toutain, L.; Gomez, C.; Barthel, D.; Zuniga, J. SCHC: Generic Framework for Static Context Header Compression and Fragmentation. IETF, 2020. Available online: https://www.rfc-editor.org/info/rfc8724 (accessed on 10 January 2022)

38. RFC 9391; Ramos, E.; Minaburo, A. Static Context Header Compression over Narrowband Internet of Things. IETF, 2023. Available online: https://www.rfc-editor.org/info/rfc9391 (accessed on 10 January 2022)

39. RFC 9011; Gimenez, O.; Petrov, I. Static Context Header Compression and Fragmentation (SCHC) over LoRaWAN. IETF, 2021. Available online: https://www.rfc-editor.org/info/rfc9011 (accessed on 10 January 2022)

40. Gomez, C.; Minaburo, A.; Toutain, L.; Barthel, D.; Zuniga, J.C. IPv6 over LPWANs: Connecting Low Power Wide Area Networks to the Internet (of Things). *IEEE Wirel. Commun.* **2020**, *27*, 206–213. [CrossRef]

41. DRAFT 02; Bormann, C.; Hoffman, P. Concise Binary Object Representation (CBOR) Tag for CBOR Templates. IETF, 2018. Available online: https://datatracker.ietf.org/doc/draft-bormann-lpwan-cbor-template/02/ (accessed on 10 January 2022)

42. (IANA). IANA SenML Units. IANA Assignments, 2018. Available online: https://www.iana.org/assignments/senml/senml.xhtml. (accessed on 13 February 2022)

43. Yiğitler, H.; Badihi, B.; Jäntti, R. Overview of Time Synchronization for IoT Deployments: Clock Discipline Algorithms and Protocols. *Sensors* **2020**, *20*, 5928. [CrossRef] [PubMed]
17. Molina Araque, S.; Martinez, I.; Papadopoulos, G.Z.; Montavont, N.; Toutain, L. Toward a Standard Time Series Representation for IoT based on CBOR Templates. In Proceedings of the 2022 Global Information Infrastructure and Networking Symposium (GIIS), Argostoli, Greece, 26–28 September 2022; pp. 13–19.

18. RFC 8259; Bray, E.T. The JavaScript Object Notation (JSON) Data Interchange Format. IETF, 2017. Available online: https://www.rfc-editor.org/info/rfc8259 (accessed on 10 January 2022)

19. RFC 8428; Jennings, C.; Shelby, Z.; Bormann, C.; Arkko, J.; Keranen, A. Sensor Measurement Lists (SenML). IETF, 2018. Available online: https://www.rfc-editor.org/info/rfc8428 (accessed on 10 January 2022)

20. (RDF) 1.1; RDF Working Group. Resource Description Framework. Standard Specification, W3C, 2014. Available online: https://www.w3.org/RDF/ (accessed on 17 April 2023)

21. RFC 8610; Birkholz, C.V.H.; Bormann, C. Concise Data Definition Language (CDDL). IETF, 2019. Available online: https://www.rfc-editor.org/info/rfc8610 (accessed on 10 January 2022)

22. Tomaszuk, D.; Angles, R.; Szeremeta, L.; Litman, K.; Cisterna, D. Serialization for Property Graphs. In *Beyond Databases, Architectures, and Structures. Paving the Road to Smart Data Processing and Analysis, Proceedings of the 15th International Conference, BDAS 2019, Ustroń, Poland, 28–31 May*; Springer: Berlin/Heidelberg, Germany, 2019; pp. 57–69.

23. Pereira, F.; Correia, R.; Pinho, P.; Lopes, S.I.; Carvalho, N.B. Challenges in Resource-Constrained IoT Devices: Energy and Communication as Critical Success Factors for Future IoT Deployment. *Sensors* **2020**, *20*, 6420. [CrossRef] [PubMed]

24. Biswal, A.K.; Al Mallah, O. Analytical Assessment of Binary Data Serialization Techniques in IoT Context (Evaluating Protocol Buffers, Flat Buffers, Message Pack, and BSON for Sensor Nodes. (Politecnico Milano 1863). 2019. Available online: https://www.politesi.polimi.it/handle/10589/150617 (accessed on 26 October 2022).

25. Neufeld, G.; Vuong, S. An overview of ASN.1. *Comput. Netw. ISDN Syst.* **1992**, *23*, 393–415. [CrossRef]

26. Álvaro Luis, Pablo Casares, J.J.C.G.; Patricio, M.A. PSON: A Serialization Format for IoT Sensor Networks. *Sensors* **2021**, *21*, 4559. [CrossRef] [PubMed]

27. Viotti, J.C.; Kinderkhedia, M. A Survey of JSON-compatible Binary Serialization Specifications. *arXiv* **2022**, arXiv:2201.02089.

28. Ivanovo. Comparison of JSON Like Serializations—JSON vs. UJSON vs. MessagePack vs. CBOR. Available online: http://zderadicka.eu/comparison-of-json-like-serializations-json-vs-ubjson-vs-messagepack-vs-cbor/ (accessed on 28 January 2022).

29. Hasemann, H.; Kröller, A.; Pagel, M. RDF provisioning for the Internet of Things. In Proceedings of the 2012 3rd IEEE International Conference on the Internet of Things, Wuxi, China, 24–26 October 2012; pp. 143–150.

30. Kábisch, S.; Peintner, D.; Anicic, D. Standardized and Efficient RDF Encoding for Constrained Embedded Networks. In Proceedings of the 12th European Semantic Web Conference, ESWC 2015, Portoroz, Slovenia, 31 May–4 June 2015; Springer International Publishing: Berlin/Heidelberg, Germany, 2015; pp. 437–452.

31. Fernández, J.D.; Martínez-Prieto, M.A.; Arias, M.; Gutierrez, C.; Álvarez-García, S.; Brisaboa, N.R. Lightweighting the Web of Data through Compact RDF/HDT. In *Advances in Artificial Intelligence*; Springer: Berlin/Heidelberg, Germany, 2011; pp. 483–493.

32. Fernández, N.; Arias, J.; Sánchez, L.; Fuentes-Lorenzo, D.; Corcho, Ó. RDSZ: An Approach for Lossless RDF Stream Compression. In *Lecture Notes in Computer Science*; Springer International Publishing: Berlin/Heidelberg, Germany, 2014; pp. 52–67.

33. Sherif, M.A.; Ngomo, A.C.N.; Lehmann, J. Automating RDF Dataset Transformation and Enrichment. In Proceedings of the 12th European Semantic Web Conference, ESWC 2015, Portoroz, Slovenia, 31 May–4 June 2015; Springer International Publishing: Berlin/Heidelberg, Germany, 2015; pp. 371–387.

34. Manyika, J.; Chui, M.; Bisson, P.; Woetzel, J.; Dobbs, R.; Bughin, J.; Aharon, D. *Unlocking the potential of the Internet of Things*; Global Institute Report; McKinsey & Company: New York, NY, USA, 2015.

35. Kenda, K.; Kazic, B.; Novak, E.; Mladenić, D. Streaming Data Fusion for the Internet of Things. *Sensors* **2019**, *19*, 1424. [CrossRef] [PubMed]

36. Blalock, D.; Madden, S.; Guttag, J. Sprintz: Time Series Compression for the Internet of Things. *ACM Interact. Mob. Wearable Ubiquitous Technol. (IMWUT)* **2018**, *2*, 1–23. [CrossRef]

37. RFC 8724; Minaburo, A.; Toutain, L.; Gomez, C.; Barthel, D.; Zuniga, J. SCHC: Generic Framework for Static Context Header Compression and Fragmentation. IETF, 2020. Available online: https://www.rfc-editor.org/info/rfc8724 (accessed on 10 January 2022)

38. RFC 9391; Ramos, E.; Minaburo, A. Static Context Header Compression over Narrowband Internet of Things. IETF, 2023. Available online: https://www.rfc-editor.org/info/rfc9391 (accessed on 10 January 2022)

39. RFC 9011; Gimenez, O.; Petrov, I. Static Context Header Compression and Fragmentation (SCHC) over LoRaWAN. IETF, 2021. Available online: https://www.rfc-editor.org/info/rfc9011 (accessed on 10 January 2022)

40. Gomez, C.; Minaburo, A.; Toutain, L.; Barthel, D.; Zuniga, J.C. IPv6 over LPWANs: Connecting Low Power Wide Area Networks to the Internet (of Things). *IEEE Wirel. Commun.* **2020**, *27*, 206–213. [CrossRef]

41. DRAFT 02; Bormann, C.; Hoffman, P. Concise Binary Object Representation (CBOR) Tag for CBOR Templates. IETF, 2018. Available online: https://datatracker.ietf.org/doc/draft-bormann-lpwan-cbor-template/02/ (accessed on 10 January 2022)

42. (IANA). IANA SenML Units. IANA Assignments, 2018. Available online: https://www.iana.org/assignments/senml/senml.xhtml. (accessed on 13 February 2022)

43. Yiğitler, H.; Badihi, B.; Jäntti, R. Overview of Time Synchronization for IoT Deployments: Clock Discipline Algorithms and Protocols. *Sensors* **2020**, *20*, 5928. [CrossRef] [PubMed]
44. Balestrieri, E.; Vito, L.D.; Lamonaca, F.; Picariello, F.; Rapuano, S.; Tudosa, I. Research challenges in Measurement for Internet of Things systems. *Acta Imeko* **2019**, *7*, 82. [CrossRef]

45. Jindal, R.; Kumar, N.; Patidar, S. IoT streamed data handling model using delta encoding. *Int. J. Commun. Syst.* **2022**, *35*, e5243. [CrossRef]

46. Sebastian, M.A.J. Time-Series-Data-Set-for-CBOR-Templates. 2022. Available online: https://github.com/sebasmol96/Time-Series-data-set-for-CBOR-templates.git (accessed on 10 August 2022).

47. Blauth da Silva, G.; Tavares, J. *Cyclist Accident Prevention Dataset V3*; Mendeley Dataset. Available online: https://data.mendeley.com/datasets/3j9yh8znj4 (accessed on 16 August 2022).

48. LoRa Alliance Technical Committee. *RP002-1.0.3 LoRaWAN Regional Parameters*; Technical Guideline; LoRa Alliance Technical Committee: Fremont, CA, USA, 2021.

49. Yusri, A.; Nashiruddin, M.I. LORAWAN Internet of Things Network Planning for Smart Metering Services. In Proceedings of the 2020 8th International Conference on Information and Communication Technology (ICoICT), Yogyakarta, Indonesia, 24–26 June 2020; pp. 1–6.

50. Casals Ibáñez, L.; Mir Masnou, B.; Vidal Ferré, R.; Gomez, C. Modeling the energy performance of LoRaWAN. *Sensors* **2017**, *17*, 2364. [CrossRef] [PubMed]

51. Martinez Bolivar, I. Jamming on LoRaWAN Networks: From Modelling to Detection. Doctoral Thesis, Institut National des Sciences Appliquées de Rennes, Rennes, France, 2021.

52. Semtech Corporation. SX1772/73. Wireless and Sensing Products Datasheet, 2019. Available online: https://semtech.my.salesforce.com/sfc/p/#E0000000JelG/a/44000001NCE/v_VBhk1IolDgxwwnOpcS_vTFxPfSEPQbuneK3mWsXIU (accessed on 2 May 2022).

**Disclaimer/Publisher's Note:** The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.
44. Balestrieri, E.; Vito, L.D.; Lamonaca, F.; Picariello, F.; Rapuano, S.; Tudosa, I. Research challenges in Measurement for Internet of Things systems. *Acta Imeko* **2019**, *7*, 82. [CrossRef]

45. Jindal, R.; Kumar, N.; Patidar, S. IoT streamed data handling model using delta encoding. *Int. J. Commun. Syst.* **2022**, *35*, e5243. [CrossRef]

46. Sebastian, M.A.J. Time-Series-Data-Set-for-CBOR-Templates. 2022. Available online: https://github.com/sebasmol96/Time-Series-data-set-for-CBOR-templates.git (accessed on 10 August 2022).

47. Blauth da Silva, G.; Tavares, J. *Cyclist Accident Prevention Dataset V3*; Mendeley Dataset. Available online: https://data.mendeley.com/datasets/3j9yh8znj4 (accessed on 16 August 2022).

48. LoRa Alliance Technical Committee. *RP002-1.0.3 LoRaWAN Regional Parameters*; Technical Guideline; LoRa Alliance Technical Committee: Fremont, CA, USA, 2021.

49. Yusri, A.; Nashiruddin, M.I. LORAWAN Internet of Things Network Planning for Smart Metering Services. In Proceedings of the 2020 8th International Conference on Information and Communication Technology (ICoICT), Yogyakarta, Indonesia, 24–26 June 2020; pp. 1–6.

50. Casals Ibáñez, L.; Mir Masnou, B.; Vidal Ferré, R.; Gomez, C. Modeling the energy performance of LoRaWAN. *Sensors* **2017**, *17*, 2364. [CrossRef] [PubMed]

51. Martinez Bolivar, I. Jamming on LoRaWAN Networks: From Modelling to Detection. Doctoral Thesis, Institut National des Sciences Appliquées de Rennes, Rennes, France, 2021.

52. Semtech Corporation. SX1772/73. Wireless and Sensing Products Datasheet, 2019. Available online: https://semtech.my.salesforce.com/sfc/p/#E0000000JelG/a/440000001NCE/v_VBhk1IolDgxwwnOpcS_vTFxPfSEPQbuneK3mWsXIU (accessed on 2 May 2022).

**Disclaimer/Publisher's Note:** The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.