## 3 System Architecture and Implementation
### Envisioned Core Activities  
The architecture is built around 3 key activities _setup phase_, _data log_, _data request_ which encompass the key innovations that are illustrated in this design. During the **setup phase**, IoT nodes create the proper MAM channels in order to start broadcasting in the Tangle. Using a unique seed, the IoT node runs the _createChannel(dimension)_ function twice. Note that the higher the dimension of the Merklee Tree, the higher the requirement for memory. The first channel is called status_channel, it has no endpoints other than the central and it is used to publish status messages of 1300 bytes (1300 ASCII char) as follows:  
status_message: [string node_id, integer geo_loc_lat, integer geo_loc_alt, integer battery, string data_channel_child, string last_msgid, string child_PSK, string data_description, integer error_code]. where:  
node_id: Unique id of the IoT node geo_loc_lat: geographic location latitude geo_loc_alt: geographic location altitude battery: Battery level between [0, 100] data_channel_child: string of trytes representing channel_id last_msgid: string of trytes representing the message_id of the last message child_PSK: string of the pre-shared key required to unlock the data stream data_description: short string representing the data (e.g.TEMPBAT|TEMP|PRES|HUMID|RAIN|TEMPSHT21|HUMSHT21 ) error_code: a unique integer that represent error messages (e.g., 103)  
Each message is encrypted with an NTRU scheme, using a public_key that is shared by the backend system. According to the above described scheme, the IoT Node ID is publicly auditable, since it resided in the Tangle, but it is only readable by the parties that have the appropriate private key. In our case, only the backend can read it. As such, everyone can verify its integrity and correctness,  
Figure 11: The Edge Super Node Module. but only the backend can extract the sensitive information. When the channel exhausts the Merklee Tree, the last message points to a newly generated _status_channel_chid_. It is important to underline that the IoT node is able to dynamically change the format of the offered data streams, by changing how the sensor data logs (SDLs) are encapsulated into different channels/endpoints and the frequency of the PSK change. All the changes are eventually mirrored in the status messages. In case a sensor needs to be added to the system, _setup phase_ is initiated through the functions in the _setup_driver.js_ and its data are stored through Mongoose in the MongoDB database. **Data Log Phase:** The IoT node services are activated on event basis and read data from the sensors that are stored in the Tangle. Before that, the data are enriched with metadata (e.g., sensor id, type, etc.) and stored for local use (e.g., local decision-making). Then the MAM service, adhering to the business logic encapsulates the data into data streams. In case a sensor data log (SDL) is divided into multiple data streams, they are referred to as data log segments. Afterwards, the MAM service creates the proper MAM Bundle where the header and packet transactions are placed and hashed. The service then sends the MAM Bundle to an IOTA Full node in order to issue it to the network. Finally, the MAM service updates appropriately the _PSK_ and data_channel_chid fields of the status_message. Each data stream can be viewed as a time series of SDLs \((SDL_{1},SDL_{2},\ldots SDL_{n})\) at corresponding instances \((t_{1},t_{2},...,t_{n})\). Likewise, as _PSK_ changes every m SDL (m \(\geq\)1), the SDL time series creates a _PSK_ time series \((PSK_{1},PSK_{2},...,PSK_{y})\) and a data channel _chid_ time series \((chid_{1},chid_{2},...,chid_{z})\). In the proposed data configuration, in n SDL there are m _PSK_ (m\(\leq\)n) and z _chid_ (z\(\leq\)m), since the _chid_ changes every 2\({}^{d}\) messages, where d is an arbitrary integer as mentioned in Section 1.4.