# Cost-Aware IoT Extension of DISSECT-CF
## 4 Implementation and Validation  
Based on the generic, architectural plans introduced in Section 3 we implemented a model of a real-world IoT system in the extended DISSECT-CF simulator. As meteorology and weather forecasting were pioneers of sensor networks, our choice for the real-world system was a crowdsourced meteorological service [6]. This service is one of the most popular websites on meteorology in Hungary providing weather updates every 10 minutes and forecasts for up to a week. Our aim in this section is to evaluate the likely behaviour of the data collection and pre-filtering techniques behind the system and analyse the potential costs of utilising cloud provided IoT processing facilities for these operations. Figure 4 details our implementation, which revolves around the classes of the Application and the Station (these are implementations of the IoT Controller and Sensor components from Figure 1). The Station acts as a gateway of interconnected sensors, while the Application implements custom IoT cloud use cases by examining various management and processing algorithms of sensor data in VMs of a specific cloud environment. Station provides the sensors' network connection (e.g., towards the VMs used by the Application) and optimises their bandwidth utilisation by caching and bundling outgoing metering data. This caching behaviour is governed by the Application's tasksize attribute. Figure 3: COST model of Cloud providers. The Provider class is the implementation of the IoT Pricing and Cloud Pricing components of the architecture shown in Figure 1). In the previous section, we defined our proposed cost model with two XML-based, declarative modelling language schemes for representing and configuring IoT and cloud side costs of certain providers. These samples can be used to assign pricing to the corresponding entities within the simulation, and the Provider class is responsible to load (i.e., read) and manage these values for cost calculations. It can be specified for each simulated IoT cloud system and which provider (thus pricing scheme) to be used for the calculation. If one needs to define a new IoT provider (other than the ones introduced), then the abstract class of Provider needs to be extended with an overridden method called: IoTCostCounter(). This extension can use the existing elements of the XML to define its new scheme. If a completely new method is needed for cost calculation, then the relevant XML parsing must also be done by the extension. To define a new cloud provider, one has to change the target and the size attributes (defined in the IoT provider XML file) and keep it in sync with the cloud provider XML file. This could entail the overriding of the CloudCostCounter() method. Figure 5 depicts the data representation of stations in our model. Stations have unique identifiers (i.e., a name) representing a weather station. Their lifetime can be specified with the tag time by defining their starttime (the time of their first activity) and stoptime (the time of their last activity). These details are configured for each use case specifically. The cardinality of the station's supervised sensor set is set via shnumber. Alongside the set cardinality, one can also specify the average data size produced by one of the sensors in the set. Figure 4: IoT extension classes for DISSECT-CF. In our experiments, sbnumber and size are set according to specifications of the weather stations on sale by _idokep.hu_. They sell these to improve the service's sensor network and weather predictions via crowd sourcing. These stations have sensors to monitor at most the following environmental properties: (i) air and dew point temperature (in \({}^{\circ}\)C); (ii) humidity (%); (iii) barometric pressure (hPa); (iv) rainfall (mm/hour and mm/day); (v) wind speed (km/h); (vi) wind direction; (vii) and UV-B level. In summary, data packets from a single station are estimated to be approximately 50 bytes/measurement [25]. To set up more stations with the same properties, one can use the count option in the name tag.