# Energy-Aware Security Adaptation for Low-Power IoT Applications
## 3 An Architecture for Dynamic Energy and Security Management in IoT  
The architecture in the context of which we design and evaluate the proposed energy and security adaptation strategy is illustrated in Figure 2. This architecture extends the LoRaWAN operational model by adding new elements considered to be indispensable for the management of security and energy in tandem, as per our goals. One important component is the Network Server (NS), and in this case, it preserves the base functionality of a LoRaWAN network server. The NS is responsible for filtering information from the sensors and forwarding the respective payloads to the Application Server (AS). As illustrated, the dynamic safety controller is added in the context of this component of the architecture. An IDS module is added at the Gateway to assist the controller, in particular to allow the assessment, from the analysis of the communications with sensing devices, of the state of the network in relation to intrusions and external attacks. We can also observe that a component for security management is added to the various entities of the architecture, which is responsible for sending information about the security scheme currently being used, as well as for receiving information important for the enforcement of a new security scheme (as decided by the controller). In Figure 2, we also illustrate the data flow for the variablesused by the controller, as well as the distribution of the new security scheme, illustrating in general what happens in the system in each periodic run of the controller logic. In Figures 3 and 4, we illustrate a functional and protocol view of the proposed architecture, particularly the data flows, the origin, the destination and the type of information exchanged between the various entities of the architecture illustrated in Figure 2.  
In Figure 3, we illustrate the process of setting up the controller. In this process, the security levels defined in the controller are shared with the remaining components of the architecture, which make use of this information, in particular, the sensing devices and the AS. The attacks and the security profile tables are also shared, which are required to decode the attack reports transmitted by the IDS component of the architecture and adapt accordingly. In Figure 4, we illustrate the process of exchanging the necessary information for the operation of the controller, in each run of the algorithm. Each sensing device part of the architecture outputs its battery level (in percentage), and the IDS transmits the security  
Figure 3: Setup phase of the proposed architecture (protocol view). Figure 2: System view of the proposed architecture. assessment made at that moment from its analysis of the communications environment. The minimum and initial security levels, as well as the preference threshold (which expresses the preference given to energy saving over security), as well as the security profile table, are transmitted by the AS, since all variables depend on system preferences. Such preferences influence the behavior of the controller and may be expressed via application configuration, either on setup or modified at run time. We must note that this is implementation specific and out of the scope of our implementation and evaluation process. In each run (one per minute), the controller gathers all the required information, analyzes it and reacts to the IDS report and end-node status (battery level), adapting the security level as appropriate. Afterward, the new security scheme is transmitted to the sensor, NS and AS entities of the architecture, using encryption at the network and application layers provided by LoRaWAN. We need also to consider which LoRaWAN device classes are able to support the proposed architecture. From our previous description in Section 1, we may note that Class B and C devices will have no problem using this approach, as they have synchronous or continuous downlink opportunities to transmit.