Table 7.4: Data memory (RAM) usage comparative in bytes.
Component EXIP EXIP-EP CTC
Library 292 292 12 notebook.xsd 1196 252 0 netconf.xsd 1748 292 0 SenML.xsd 1348 292 0 SEP2.xsd 11860 292 0 OPC-UA.xsd 13765 292 0
from 7.7% to 61.5%. As has been explained in Chapter 6, the template table can be stripped from devices that do not make use of it, thus, reducing even further CTC memory requirements for the XML test schemas. In this case, the comparative memory usage will be reduced to 4.0% to 29.8%.
Additionally, CTC uses nearly no data RAM while EXIP uses 252 bytes in its best case and up to 13765 bytes in the worst one. The maximum heap used for the EXIP case is 1734 and 1294 bytes for the EXIP-EP case. In contrast, CTC uses no heap memory at all.
Devices need to share the memory between multiple functionalities (application, sensor drivers, communication stacks, etc.) and will likely need to accommodate more than one schema. Thus, it is of most importance to assign memory resources as efficiently as possible and make the most of the available memory. Although the CTC Library used in these tests is still a prototype, results show that CTC memory requirements are much more suited to resource-constrained devices than EXI implementations due to the significantly smaller memory footprint and runtime usage requirements. On the one hand, the CTC core library requires 92% less memory than the EXIP library configured for EXI Profile, and the schema information is reduced to a 4.0% in the best case and to a 61.5% in the worst. On the other hand, CTC core library uses no RAM, no heap and a maximum stack size of 692 bytes, while EXIP uses 252 RAM bytes, 1294 heap bytes and 792 stack size in its best case.
7.2
JSON Compression Evaluation
In this section, the compression efficiency of CTC for JSON document instances is compared against EXI4JSON [PB18] and CBOR [BH13]. A set of JSON instances are compressed using (a) a prototype implementation of CTC, (b) EXIficient [16b], an EXI implementation, and (c) CBOR diagnostic utilities [18b], a command line set of utilities provided by the CBOR community.
This section also includes a comparison of the efficiency in terms of size for two different data formats, XML and JSON, and their respective CTC codification.
The set of JSON instance documents used in the tests is composed of a series of JSON
Schema instances for Media Types for Sensor Measurement Lists (SenML) [JSA+18], the JSON
Table 7.5: JSON instance document compression comparative in bytes (B) and proportion (%).
Document Size EXI4JSON CBOR CTC CTC-S
B % B % B % B % SenML-01 103 83 80.6 86 83.5 61 59.2 60 58.3 SenML-02 291 172 59.1 223 76.6 142 48.8 140 48.1 SenML-03 406 233 57.4 287 70.7 184 45.3 185 45.6 GeoJSON-01 78 47 60.3 44 56.4 13 16.7 12 15.4 GeoJSON-02 116 63 54.3 63 54.3 29 25.0 27 23.3 GeoJSON-03 259 136 52.5 202 78.0 86 33.2 83 32.0 O&M-01 520 453 87.1 449 86.3 270 51.9 264 50.8 O&M-02 335 294 87.8 274 81.8 142 42.4 137 40.9 O&M-03 486 454 93.4 446 91.8 274 56.4 269 55.3
the GeoJSON Format [BDD+16]. For the GeoJSON case, the schema used is the geometry
schema defined within the JSON OGC O&M specification [SJDT15].
Three different instance documents per JSON Schema are considered. For the SenML case, the
three examples included within Sections 5.1.2 and 5.1.3 of the SenML specification [JSA+18]
are used. In the O&M case, the three instances used are the examples included in the JSON OGC O&M specification [SJDT15] within sections 7.6 (Specimen data) and 7.8 (Sampling feature collection), as well as the first example of section 7.9 (Observation data). Finally, the used
GeoJSON instances are taken from the examples included in the GeoJSON Format [BDD+16]
specification in sections A.2 (LineStrings), A.3 (Polygons with no holes) and A.6 (MultiPolygons). For this comparison, the JSON instance documents were first compressed using the EXIfi- cient [16b] EXI processor implementation and the CBOR diagnostic utilities [18b]. EXIficient includes a mode to compress JSON schemas using the EXI4JSON [PB18] approach. This mode automatically sets the EXI options to the ones specified in the EXI4JSON recommendation: the EXI “schema strict” compression mode is set to True, and the EXI schemaId option is set to the constant string “exi4json”. The alignment option is set to “bit-packed”. On the other hand, CBOR diagnostic utilities include a tool to automatically convert from JSON instances to CBOR. No specific label or tag mappings have been used in the codification. Finally, the corresponding CTC schema contexts and template tables were created from the JSON Schemas, and the compression was performed using the CTC approach.
Results in terms of size in bytes are shown in Table 7.5. The Size column lists the original size of the respective JSON instance. The table shows the results for the EXI4JSON, CBOR, CTC in normal mode and CTC in strict mode (column CTC-S) in their corresponding columns. Each case includes two (sub-)columns in order to show the absolute size in bytes (column B) and proportional to the original size (column %).
For example, the original size of the “GeoJSON-01” JSON instance is 78 bytes. EXI4JSON is able to compress the “GeoJSON-01” instance to 47 bytes resulting in a 60.3% of the original size while CBOR achieves a compression to 44 bytes for a 56.4% size compared to the original size. In contrast, the size of the CTC compressed data is 13 and 12 bytes respectively for the CTC normal and strict modes, with a relative size of 16.7% and 15.4%.
Section 7.2. JSON Compression Evaluation 119
Table 7.6: senML instances’ size comparison in bytes for XML, JSON and CTC cases.
Document XML JSON CTC CTC-S CTC-X CTC-J CTC-X CTC-J SenML-01 171 103 61 61 60 60 SenML-02 414 291 143 143 140 141 SenML-03 605 406 184 184 185 185 SenML-04 118 56 39 39 39 39
Results show that CTC outperforms both EXI4JSON and CBOR codifications. EXI4JSON and CBOR achieve an average relative size of 69.8% and 73.6% respectively while CTC shows an average relative size of 39.2% (38.2% in the CTC Schema Strict mode). EXI4JSON does not take advantage of the JSON Schema directly as it depends on a mapping to a dedicated XML Schema, as explained in Section 3.2.1.4. Although the resulting compression is undoubtedly better than the raw JSON, it is outperformed by CTC, which takes advantage of the JSON schema knowledge for the compression. On the other hand, CBOR does not take into account schema information and suffers from the overhead of in-lining the data types into the coded stream.
7.2.1
XML, JSON and CTC comparison
In this section, we will compare the size of data formatted in two different data formats, XML and JSON, as well as the resulting CTC compression efficiency. The selected data model for this evaluation is JSON Schema instances for Media Types for Sensor Measurement Lists
(SenML) [JSA+18]. The SenML specification describes several examples in different data formats
and encodings, including XML and JSON. The example documents used in this evaluation are the four examples found within sections 5.1.1 (SenML-04), 5.1.2 (SenML-01 and SenML-02) and
5.1.3 (SenML-03) of the SenML specification [JSA+18].
Table 7.6 summarizes the original and compressed sizes of the selected instance documents. The XML column contains the size of the data in XML format and the JSON column the size of the data in JSON format. The CTC and CTC-S columns show the compressed size in bytes for CTC in normal and strict modes, respectively for the XML (columns CTC-X ) and JSON (columns CTC-J) cases.
As can be seen in Table 7.6, JSON format is consistently more compact than XML. This is due to the less verbose nature of JSON that uses fewer grammar constructs and string tokens to describe relationships between items of the structure. Nevertheless, CTC codification yields similar results for both XML and JSON cases. This is because CTC mapping captures the core structure of the data model and segregates data format specific artefacts. The codified stream only includes the minimum needed information in order to properly decode and parse the stream while the data format specific information (mainly stored in the template table) is only used if the original format must be reconstructed.
Constrained Devices Network Internet NodeA NodeB CTC gateway
Figure 7.4: REST validation deployment.
/.well−known/core /sch/schema1 /out/data
(a) NodeA CoAP API layout.
/.well−known/core /sch/schema1
(b) NodeB CoAP API layout.
Figure 7.5: Layouts of NodeA and NodeB CoAP APIs.