# SOLIOT--Decentralized Data Control and Interactions for IoT
## 6 Mapping and Interaction Model
### Protocol Bindings
#### 6.3.3 SOLIOT Network Architecture  
Two basic architecture designs are possible. The SOLIOT server can host a MQTT message broker and expose its endpoint to subscribing clients. Alternatively, the SOLIOT application only implements a MQTT client socket and distributes the notifications using an external MQTT message broker. The obvious advantage is a reduced computing load on the SOLIOT instance and increased scalability through the usage of several Message Brokers. However, the access control--moreover, any kind of data protection--is thereby transferred to the MQTT Broker and thereby not under control of the provider anymore. A MQTT Broker may or may not take the respective ACL files into account, the providing SOLIOT application cannot be certain. While this challenge certainly can be solved through additional mechanisms, for instance exchanging encrypted payloads and at the same time handing out proper decryption keys only to authorized subscribers [42], this shall only be briefly mentioned at this position. Still, the outlined issues are highly relevant but regarded as out of scope for explaining the core of the SOLIOT approach.  
The next requirement is the choice of the appropriate media type (**P9**). RDF and its serializations have been designed with a clear focus on interoperability and self-description. The schema-less  
\begin{table}
\begin{tabular}{l l l l} \hline \hline
**Interaction** & **Mandatory** & **MQTT Method** & **Status Code** \\ \hline Create & no & – & – \\ Read Resource & yes & – & – \\ Read Metadata & yes & – & – \\ Read Operations & yes & – & – \\ Extend & no & publish solid/patch/[resource] & – \\ Overwrite & no & publish solid/put/[resource] & – \\ Delete & no & – & – \\ Subscribe & no & subscribe solid/+/[resource] & – \\ Unsubscribe & no & unsubscribe solid/+/[resource] & – \\ Notify & no & publish solid/[interaction]/[resource] & – \\ Alarm & no & publish solid/alarm/[resource] & – \\ Invoke Functions & no & – & – \\ \hline \hline \end{tabular}
\end{table}
Table 6: Interaction methods with MQTT, based on [PERSON] et al. [27].  
characteristics of RDF objects allow its flexible usage and simple extension at runtime. As the commonly appearing data files kilobyte to low megabyte range, this is usually problematic for both Web servers and clients. In the regarded use case however, this is obviously a significant challenge. One way to solve it is to examine the different serialization formats, namely RDF/XML, NTriples, Turtle and JSON-LD.  
A differentiation must be made for JSON and its RDF variant, JSON-LD. A plain encoding of RDF with completely serialized URIs as JSON keys and values requires a lot of space and is therefore not suitable. Namespace replacements through the '@context' element reduces the required space significantly but increases the parsing effort. Receiving parties need to look up the reference if they do not know it yet, resulting in probably even higher traffic. The current context of the 'Thing Description' alone has more than 22,000 bytes. Still, the broad usage of JSON justifies this trade-off, and makes it the recommended format. To face the context issue, SOLIOT places a respective JSON file at the reserved path '/things/context.jsonld'.  
The further identified requirements of protocol bindings (Bandwidth (P6) and Latency (P8)) are discussed in Section 8. Energy Consumption (P7) is by its nature hard to measure for a concept such as SOLIOT and was not examined separately. It is assumed that the bandwidth is a sufficient indicator for the power demand of a SOLIOT implementation.