# Sustainable IoT Sensing Applications Development through GraphQL-Based Abstraction Layer
## 5 Experimental Testbed Setup  
In detailing our experimental testbed, we first discuss our server-side setup of Runtime with cloud services. For our setup implementation, we used the state-of-the-art cloud services of Google Platform infrastructure. Google has introduced Firebase storage services for IoT data and which gained popularity as NoSQL cloud storage [31]. We evaluated our GraphQL-based approach in IoT applications through experiments using real IoT devices (Z1) and Firebase appears to be an effective cloud service storage for our designed testbed for experiments. For our experimentation of server-side module, we also used cloud functions for hosting. The Runtime environment was hosted via Google Cloud Functions and it connects the server-side Firebase service with the client-side GraphQL queries. NoSQL-based databases used as cloud services and its types, which store data in an aggregated form offering single view data retrieval, are called aggregate-oriented NoSQL databases. The category of graph-based NoSQL databases provide multiple views of data. This ability comes from storing data as graph nodes and putting relationships as labels on the edges of the graph, but this category takes advantage of a standard language for data querying. Firebase is an aggregate-oriented NoSQL database for storage in the cloud environment, in which data are discrete, thus lacking support for relationships, in comparison to graph databases. Therefore, our implementation needs a parser for using Firebase with GraphQL-based implementation to store high connected data in discrete data storage. Thus, we used cloud functions of Google to host the required parser, which translates GraphQL queries to the underlying storage. The specification's Runtime implements this parser for storing highly connected data, received from IoT nodes, in the discrete data cloud storage of Firebase. As far as choosing GraphQL query language on client side IoT devices for our implementation is concerned, GraphQL has introduced a new way of clients querying an API. There are also some other query languages available for graph databases, but they mostly have dependencies on other software. Therefore, their acceptance as standard in the domain could not be possible. The GraphQL query language has an inherent design of API interaction. As Firebase database can also allow interaction through APIs, we chose it in our implementation with API facing GraphQL. The experimental setup/testbed used in this research comprised of real IoT devices Z1 manufactured by Zolertia, having low power MSP430F2617 micro-controller, with 16 MHz RISC CPU, 8 KB RAM and 92 KB internal memory. Deployment was done in real indoor environment of university environment with walls, people's mobility, WiFi interference, etc. Moreover, connectivity and traffic scenarios were changed in many ways to check different possible real world situations. Figure 8 shows a snapshot of a typical scenario of our working setup. For our IoT devices, we used Contiki OS with its default implementation and used IEEE 802.15.4 standard protocol on lower layers of the stack. Data transmission was limited to 250 kbps and 2.4 GHz radio band was used as a medium for channels. We used RPL of the Contiki stack as the routing layer protocol and radio duty cycling was set to off, to make a case study of continuous sensing IoT scenarios. At the MAC layer, we enabled re-transmissions for one-hop packet reliability and the border router using RPL DODAG worked as a gateway for connection with the cloud services. The messages used for sensor values were of POST nature used to deliver data to destination end-point repositories with typical size of 96 bytes under Contiki OS layered stack. Energy values were measured using Powertrace [32], a network level power profiling model for low power wireless networks. It uses a linear power model to estimate the power as the sum of all active power states and energy of the system is derived from the time spent in each power state.