# SOLIOT--Decentralized Data Control and Interactions for IoT
## 8 Evaluation  
At the core of the proposed SOLIOT approach is the combination of the uniform interfaces of the LDP specification (interoperability requirement) with the mature access control regime (data control) as defined by SOLID with the restricted resources of IoT applications (constraint devices). Evaluating these stated contributions target different dimensions and therefore requires different methods. As the interoperability features are heavily relying on the provided SOLID specifications, a distinct validation of their features would only provide a minimal added value. It has been decided to supply proof of concept also as a deployed sandbox instance at ([[https://1.17.197.66](https://1.17.197.66)]([https://1.17.197.66](https://1.17.197.66)): (84431888315683). The typical ports for HTTPS (8443), CoAP (5683), and MQTT (1883) are used. The open code base allows the interested reader to verify the created endpoints implementation and examine the security implementation. The evaluation setup relies on Amazon AWS EC2 instances. The prototypical SOLIOT server has been shipped to T2 Micro instances and deployed using the AWS Client API. This way, the fast deployment of many SOLIOT servers is possible. All instances have their own hostname and thereby act as distinguishable nodes in the evaluation network. Currently, all instances have been equipped with one Thing Description representing one single device. As SOLID, and therefore also SOLIOT, maintains the resources as files on the local disk instead of keeping it in its local RAM, it is assumed that more resources would not significantly affect the performance behavior. Each instance has an allocated disk space of 8 GB, which limits in no test scenario have been reached. The complete identical setting was used for SOLID reference servers as baselines. Both the SOLIOT and SOLID test instances asynchronously report information on incoming and outgoing messages to one central Web server. This server collects and persists the performance results, which serve as the inputs for the following assessments. The instances without data files require around 257 MB, where most (243 MB) is used for external libraries. The exemplary Digital Twin consists of 32 Turtle files (88 KB), with in total 376 triples. The container structure, reflecting in many different files and folders also on the disk, increases the amount of required storage space. However, the management of each RDF subject in one file simplifies the discovery look ups and lets clients easier the relations more easily. The available memory (0.5 and 1.0 GB) and computing power of the EC2 Micro and Nano instances are sufficient for all tests. A memory usage above 50% of the available amount was never observed. Still, the computing power of the host is challenged by the prototype. CPU usages around 80% and higher indicate a bottleneck here. Table 10 provides a comparison on the used bandwidth for each request. This sequence has been 100 times by each client. One can see that typically the request size of the CoAP and HTTP messages are quite similar, while the response deviates significantly. One reason are the rich headers provided by the SOLID endpoint. Loosing this kind of information is a significant drawback of the current state of the IoT protocol mapping. Furthermore, the MQTT publishing behavior only reflects the actual publishing party. The receiving clients or the performance of the MQTT message broker have not been regarded. Another limitation of this evaluation approach is the limited representativeness of the used demo data. The Digital Twin model has been aligned with an existing product, unrelated to the SOLIOT developments. Still, a representative Digital Twin test bed would further increase the informative value of the experiments. Comparing the results of the SOLIOT prototype, one can state a significant reduction in necessary transferred bytes but also in execution time.