# Architecting and Deploying IoT Smart Applications: A Performance-Oriented Approach
## 4 Performance Analysis: Design and Methods
### Design Decisions and Deployment Configurations  
The scope of this performance analysis study follows design choices focused on typical IoT platform components, independent of application and communication technologies. Figure 5 depicts six deployment configurations of layered IoTecture components into staged IoTinuum places devised following four key design choices:  
* Application independence: Layers L4-Model and L5-Application of IoTecture represent specific applications. This study addresses architectural components that comprise a common IoT platform, oblivious of smart application particularities. Thus, application-specific components are not included in our experiments. As applications must consume data managed by L3-Data, a simple Consumer component was added to represent L4-Model as a generic data sink. As a direct consequence of this choice, data flows only in one way, from sensors to the consumer located at the cloud. In other words, users are not involved, and therefore, L5-Service and T5-Terminal are outside of the scope of this work. Figure 4: Mapping of the 5-layered IoTecture over the 5-staged IoTinuum for a smart irrigation scenario. * Communication independence: in order to understand scalability limits, our study was performed in a lab testbed, wherein we can increase the workload by abstracting a large number of sensors using the SenSE sensor simulator [56] that generates data at different rates. Therefore, real IoT communication technologies-e.g., LPWAN-were not included in our experiments. Nevertheless, since LoRaWAN is currently a key LPWAN technology that needs a middleware component to work properly, a LoRaWAN server was included, as it belongs to L2-Transport playing the role of a sensor data endpoint. SenSE generates data emulating a LoRaWAN device, in a way that the server is unaware of not receiving data from real sensors. The configurations with ChirpStack are compared to configurations with a generic LPWAN technology where the sensor simulator generates data in a simple string-based protocol-e.g., Ultralight 2.0-and does not need to go through to the particularities of a specific LPWAN technology. * Scenario simplicity: to clearly understand the effect of different deployment configurations-i.e., the mapping of IoTecture components into IoTinuum stages-a minimum set of components was used to guarantee a data flow that starts at sensors-actually, at SenSE-and ends at the consumer. The set of software components included in the evaluated IoT platform is composed of (Table 2): SenSE sensor simulator, ChirpStack, FIWARE IoT Agent, FIWARE Orion, and consumer. They include other auxiliary components as MQTT broker and databases (MongoDB, Redis), represented in Figure 6.
* Fog Dilemma: S3-Fog may frequently leave behind in specific configurations for different reasons, such as the choice of the farmer in not hosting IoT infrastructure within the farm in locations with stable and high-speed 4G connections. S2-Mist is required in most cases, especially for LoRaWAN. Also, we assume that S4-Cloud is always present. Therefore, we tested different configurations, with and without S3-Fog, and with heavyweight fog-local processing components-and lightweight fog-only communication components. Table 1 further explains the six deployment configurations that resulted from these four choices, called C1, C2, C3, C4, C5, and C6. They were obtained by varying two factors, namely LPWAN technology (LoRaWAN vs. Generic LPWAN) and fog dilemma (no fog vs. heavyweight fog vs. lightweight fog. Figure 5: Deployment configurations of layered IoTecture components into staged IoTinuum places. * Configurations C1, C2, C3, and C4 contain S3-Fog, whereas configurations C5 and C6 preclude it. It also implies that the former configurations assume Wi-Fi WLAN connectivity between S2-Mist and S3-Fog, while the latter assumes a 4G connection. The difference between Wi-Fi and 4G here is related to the link characteristics emulated by the WANem WAN emulator [57].