Lightweight Dew Computing Paradigm to Manage Heterogeneous Wireless Sensor Networks with UAVs

The proliferation of the Internet of Things (IoT) technologies have strengthen the self-monitoring and autonomous characteristics of the sensor networks deployed in numerous application areas. The recent developments of the edge computing paradigms have also enabled on-sight processing and managing capabilities of sensor networks. In this paper we introduce a lightweight realization of the novel dew computing paradigm that helps to manage data processing tasks of a heterogeneous wireless sensor networks. The performance of proposed solution is analyzed by using the simulation results. Moreover, in order to demonstrate the practical usability of the given solution, the prototype implementation is presented using the commercial off-the-shelf devices.



There are no comments yet.


page 1

page 7


Internet of Things (IoT) and New Computing Paradigms

The chapter presents foundations of computing paradigms for realizing em...

Evolutionary Computing Approach to Optimize Superframe Scheduling on Industrial Wireless Sensor Networks

There has been a paradigm shift in the industrial wireless sensor domain...

An Edge Computing Paradigm for Massive IoT Connectivity over High-Altitude Platform Networks

With the advent of the Internet-of-Things (IoT) era, the ever-increasing...

ORCA: Enabling an Owner-centric and Data-driven Management Paradigm for Future Heterogeneous Edge-IoT Systems

Integrating Internet of Things (IoT) and edge computing for "Edge-IoT" s...

Pervasive Communications Technologies For Managing Pandemics

Pandemics always have had serious consequences unless they were effectiv...

Towards Large-Scale Autonomous Wireless Sensor Networks

Wireless Sensor Networks (WSNs) have the goal of gathering data from the...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

I Introduction

The world of Internet of Things (IoT) allows the data retrieved by multiple smart devices to transmit to different cloud servers, in order to build a more comprehensive picture of the whole ecosystem [1]. However, this needs seamless connectivity between the IoT sensor and the central cloud (i.e., end-to-end connectivity), which is hard to be guaranteed every time [2]. Edge computing paradigms (eg., Fog computing, cloudlets) have appeared to bridge the gap between remote clouds and the IoT devices [3, 4]. Dew computing is another emerging research area that permits on-premises hardware availability for software processing with cloud computing capabilities [5, 6]. Instead of offloading the processing to the cloud, the concept of dew computing brings the computing closer to the sources of data.

Typically, low power IoT devices are equipped with unlicensed band short-range radio access technologies, including Bluetooth Low Energy (BLE), HaLow, ZigBee, and Smart Utility Networks (SUNs) [7]. BLE is a commonly used stateless protocol where the requests are independently transmitted. Moreover, BLE allows a flexible topology that can be adjusted to accommodate in many applications [8]. The IoT sensor nodes that use standalone BLE for communication purposes require dedicated nodes that serve as local gateways (GWs) to provide back-end connectivity with the central cloud servers. In our previous work we presented a mobile-based relay assistance solution for establishing secure End-to-End (E2E) connectivity between low-power IoT sensors and cloud servers without using a dedicated gateway [8, 9].

Lately, Unmanned Aerial Vehicle (UAV) systems and drones received great attention for autonomous monitoring applications [10]. However, to the best of our knowledge there is still no sufficient work available to show the synergies between UAV systems and dew computing and their cooperative applicability in sensor networks. In order to describe the concept of integrating dew computing in a real world problem, we describe a smart agriculture use case as depicted in Figure 1.

Fig. 1: Smart Agriculture Use Case

As illustrated, wireless sensors are deployed in a remote agricultural site which is difficult to reach and monitor by humans in frequent terms. A drone can be sent to the farm site to collect sensed data and perform particular actions (e.g. apply water or fertilizer, activate crop monitoring sensors). These actions can be activated based on the data received by the sensors, which are then processed already at the drone. The user can control the drone, send control commands, or program the flight route whenever needed. Although, we used this use case for the sake of clarity and simplicity, similar setup can be used for environmental monitoring, disaster detection, anomaly detection in sensor networks or mobile crowd sensing applications.

In this paper, we present a novel dew computing based architecture which entails an UAV to assist data retrieving, data processing, and data management in a heterogeneous Wireless Sensor Network (WSN) located in a remote area. The proposed system model supports dew computing architecture to provide both insight and remote processing capabilities to the remotely located IoT sensor networks. Instead of using mobile phone as the relay in [8], in this work we use a drone accompanied by a Raspberry Pi to perform as an edge processor. We have proven the viability of the proposed solution by providing the comprehensive analysis of the simulation results. Finally, a prototype implementation is presented using the commercial off-the-shelf devices to demonstrate the practical viability of the proposed solution.

The remainder of the paper is organized as follows: Section II provides the background about dew computing and BLE communication. Section III describes the proposed architecture and the communication protocols. Section IV and V present the simulation and implementation results of the proposal. Finally, Section VI concludes the paper by drawing the future research directions.

Ii Background

Ii-a Dew Computing

Dew computing is a novel computing paradigm which merges the cloud computing with the capabilities of local computing. In cloud computing, users are able to store their data in the cloud server and simply they can use their computers to access the cloud. The main advancement of the cloud computing is data mobility; user can access his/her data from anywhere using internet. The main disadvantage of this concept is that the user highly depends on the internet connectivity. Hence, the Cloud-Dew Architecture [11] proposed as a feasible solution to the offline data accessibility problem [6]. Figure 2 illustrates comparison between cloud computing architecture and dew computing architecture.

Fig. 2: Dew Computing vs Cloud Computing [11]

As compared to the cloud server architecture, the novelty of the dew computing architecture is that the dew server which is a web server that occupies on user’s local computer [11]. The dew server and its database have two main functions,

  • Provides services similar to the cloud server [11].

  • Synchronizes dew server database with cloud server database [11].

Characteristics of dew server can be briefed as follows,

  • Lightweight and normally it serves only one client [11].

  • Size of the dew server is very small compared to size of the cloud server, usually it stores user’s own data [11].

  • Dew server can be vanished easily, due to different factors like hardware destruction and viruses [11].

  • It’s easy to recreate a vanished dew server since cloud server has the copy of dew server data [11].

  • Accessible both online or offline [11].

Currently dew computing is not limited to research area. It has now been expanded to application area as well. Nowadays many researchers try to implement dew computing in Internet of Things (IoT) streaming, medical care, indoor navigation, and cyber physical systems [6].

Ii-B Bluetooth Low Energy (BLE)

BLE is a recent technology that has been introduced, as an advancement to the low power wireless technology as well as the classic Bluetooth. BLE technology is only capable of sending a small amount of data frequently. BLE technology can be used in two main device types: [12]

  • Dual mode devices - support Bluetooth classic and BLE

  • Single mode devices - only support BLE

Nowadays, most of the researchers used to introduce UAVs into WSNs to improve remote surveillance of the system. With the massive development of UAV technology, the remote sensing platform has improved with its cost effectiveness, productiveness, mobility, etc. However the UAV operation in WSN platform can depend on many parameters, such as speed, time, position, communication media and path.

Iii The Proposed Architecture

Iii-a System Model

In Figure 3 we describe the system model that we consider for UAV assisted dew computing architecture.

Fig. 3: Use case scenario

We consider heterogeneous IoT devices which contains diversified sensor nodes with different capabilities whereas the drone is performing as the dew server. It will perform as a lightweight server and serves one sensor at a particular time. The drone can provide end-to-end connectivity from the sensor to cloud when there is Internet connectivity or allow offline accessibility otherwise. Thereby, we consider that the drone will perform in sight data processing and take the control functions of the IoT sensor network. These can be sensor type nodes that monitors the environmental conditions and collect data or the actuator type devices that perform given actions based on the received commands. We consider three types of links that can exist in this particular setting.

  • Link 1: Sensors collect data and send to the central cloud via the drone, when the drone is returned to home-location. Drone can access and process the retrieved data.

  • Link 2: Sensors collect data and send to drone for further processing. Drone can control the actuator nodes based on the retrieved data. No data is transferred to the central cloud. As given in dew computing paradigm, the drone will provide offline data accessibility to the actuator nodes, even though without real-time access to the central cloud.

  • Link 3: Sensors collect data and send to the central cloud via the drone in the encrypted format. Drone is acting as a relay and cannot decrypt the data. Data offloading from the drone to cloud can be performed once the drone returns to home location.

Iii-B Communication Protocol

Two communication protocols are used in the proposed architecture. First protocol is used to upload the data from sensor node to the drone and second protocol is used to upload the data from the drone to the sensor node.

Iii-B1 Data upload process

Fig. 4: Communication Protocol for data upload process

Figure 4 illustrates the message sequence between the sensor node, BLE module and the drone for the data upload process from sensor node to drone. Drone initiates the connection establishment process by sending connection establishment request to the BLE module of the sensor node. Then BLE module acknowledges the connection request and establishes the connection between drone and BLE module. After that BLE module requests data from sensor node, which has already been saved inside the sensor node. In the next step, sensor node writes data in BLE module’s local attribute. After that BLE module notifies the drone that it has data to be transferred to the drone. Drone then sends attribute read request to the BLE module. Once the attribute request is acknowledged by BLE module, drone starts reading data and sends acknowledgment to the BLE module to ensure a reliable communication between the drone and the BLE module. This process continues until the drone retrieves required information and then the drone terminates the connection between drone and the BLE module. Once the drone has terminated the connection, BLE module sends a command to the sensor node to save the data until it makes another connection with the drone in its next flying cycle.

Iii-B2 Data download process

Figure 5 illustrates the message sequence between drone, BLE module and the sensor node during data download procedure. Similar to the upload procedure, drone initiates the connection establishment process by sending connection establishment request to the BLE module. BLE module acknowledges this request to complete the connection establishment process. After that drone begins the data download by requesting attribute writing permission from BLE module of the sensor node. Then BLE module acknowledges the request from the drone and start retrieving data from drone. In the same time, BLE module sends the command to the sensor node to save those data in flash memory. Drone also receives an acknowledgement so that it knows the data has been successfully transferred. After successful completion of data transfer, drone terminates the connection between drone and the BLE module.

Fig. 5: Communication Protocol for data download process

Iv Numerical Analysis

To measure the performance of the proposed system, we implemented a simulation using MATLAB simulator. Simulation steps are explained below. Results of the simulation provides the number of sensors nodes, for which the drone can fly and collect its data, during one flying cycle of the drone.

In the simulation setup, we considered three main sensor node arrays as depicted in Figure 6, which can be practically deployed in the environment. Therefore we contemplated linear, circular and square orientations of sensor node arrays. For each array, we observe the number of sensor nodes in the array supported during drone’s one flying cycle, assuming that the drone starts flying from the first sensor node of the array.

We consider that the sensor node array comprised on sensor nodes as depicted in Figure 6. For the square sensor node array i. e where we consider

as an odd number.

Fig. 6: Orientation of Sensor Arrays

Following (1), (2) and (3) equations illustrate the relationship between drone’s maximum hovering time and number of sensor nodes that can be covered during data collection procedure.


Where, Tw is the drone’s waiting time near a sensor node. n1, n2, n3 are the number of sensor nodes in linear sensor node array, circular sensor node array and square sensor node array respectively that can be covered during data collection procedure. TF is the total flying time of the drone, assuming that the drone starts flying from the first sensor node of the array. TC is the battery charging time of the drone, TP is the data processing time of Raspberry Pi, TDL is the data download time from Raspberry Pi to sensor node and S is the speed of the drone. RBLE is the data transfer rate between Raspberry Pi and sensor node, RS is the data generation rate of sensor node and D is the distance between two sensor nodes.

Table I summarizes parameters we used in the experiments in order to obtain the simulation results. Moreover, we have evaluated how significantly each parameter contributes to decide the number of sensor nodes serviced by the drone.


Total Flying Time (TF)
25 minutes [13]
Battery Charging Time of The Drone (TC) 90 minutes [13]
Data Processing Time of the Drone (TP) 1 second
Data Download Time from Drone to Node (TDL) 10 seconds
Data Generation Rate of the Sensor Node (RS) 20 Bytes/min [14]
BLE Data Rate (RBLE) between Drone and Node 14 kbps [15]
Speed of the Drone (S) 12 m/s
Distance between two Sensor Nodes (D) 100 m
TABLE I: General simulation parameters

Figure 7 illustrates the results of the experiment obtained using MATLAB simulator.

Fig. 7: Simulation Results

Iv-a Impact of BLE Data Rate

In our proposed system we use BLE communication protocol between the drone and the sensor nodes. Data rate of BLE communication has a significant impact on waiting time of the drone near the location of sensor node. Waiting time of the drone at a sensor node decreases as BLE data rate increases. Therefore, with lower waiting time spent at a particular sensor node, drone can collect data from more sensor nodes throughout its maximum flying time.

In order to illustrate the relationship between the BLE data rate and the number of sensor nodes supported at each BLE data rate, we considered different values for BLE data rate and executed the simulation. We considered BLE data rate (RBLE) as 2 kbps, 4 kbps, 8 kbps, 12 kbps, 16 kbps while keeping the other parameters fixed. These parameters are depicted in Table I. This experiment has been carried out for all three sensor node arrays i.e. linear, circular and square.

Figure 7(A), illustrates the results of the simulation. It is clear that, with a higher BLE data rate, drone is capable to collect data from more nodes and this observation is valid for all three sensor node arrays. Results further demonstrated that circular and square arrays yield better performance than the linear array of sensor nodes.

Iv-B Impact of Sensor Data Rate

Sensor node data rate, also has a substantial impact to the performance of the system. With lower sensor node data rate, drone can collect data from more sensor nodes than having higher data rates. This behaviour is opposite to the behaviour we considered for BLE data rate. When the sensor data rate is low, the amount of data that the drone has to collect is low, thereby requiring a less amount of time to retrieve the data. Figure 7(B), illustrates the simulation results for this scenario. Here we have changed sensor nodes data rates (RS) as 20 Bytes/min, 40 Bytes/min, 60 Bytes/min, 80 Bytes/min, 100 Bytes/min while keeping other parameters in Table I fixed. Also we assumed one in-built sensor generates 20 Bytes/min. In this case also, circular and square arrays provided better performance than linear sensor node array.

Iv-C Impact of Drone’s Speed

In our implementation prototype we used DJI Phantom 3 SE drone which is capable of flying at maximum 16 m/s  [13]. For the simulation experiments we used 12 m/s as average speed considering the time taken to accelerate and decelerate. By using a drone with a higher maximum flying speed, performance of the system can be enhanced. In order to validate this phenomena, we carried out our simulation experiments from lower drone speeds to higher speeds. We changed speed values as 4, 8, 12, 16, 20 m/s while keeping other parameters fixed as in Table I. Figure 7(C), illustrates the simulation results for this scenario. According to Figure 7(C) , drones with higher speed are capable of collecting data from more sensor nodes than drones with lower speeds. In this case also, circular and square array provided better performance compared to linear array.

Iv-D Impact of Distance Between Sensors

In order to analyze how the distance between two sensor nodes affect the number of sensor nodes supported, we used 50 m, 100 m, 150 m, 200 m, 250 m as distance (D) and carried out the simulations. In this case also we kept other parameters fixed as in Table I. Based on the results as depicted in Figure 7(D), the lower the distance between two sensor nodes, the higher the number of sensor nodes supported by the drone during data collection. Moreover, circular and square arrays provided better system performance than the linear array.

Iv-E Impact of Drone’s charging Time

Relationship between drone’s charging time and maximum hovering time can be expressed as,


Where TF is the total flying time of the drone, assuming that the drone starts flying from the first sensor node of the array. TC is the battery charging time of the drone and k is a constant.

According to DJI Phantom 3 SE drone specifications, maximum battery charging time is 1 hour and 30 minutes while its maximum hovering time is 25 minutes [13]. Therefore we changed charging time for 30 minutes, 1 hour, 1 and half hours, 2 and half hours while keeping other parameters fixed as in Table I. Figure 7(E), illustrates the simulation results for this scenario. When the charging time is lower, drone can collect data from more sensor nodes as opposed to a higher charging time. Compared to previous results in A, B, C and D, charging time parameter does not exhibit a significant impact on system performances. In this case also, circular and square arrays provided better performances than linear array.

V Prototype Implementation

To establish the prototype implementation we used five Waspmotes with BLE modules, Raspberry Pi 3 and DJI phantom 3 SE  [13] drone as core instruments of the setup.

Fig. 8: Prototype

Figure 8 illustrates system model of the prototype implementation. For the prototype implementation, we first implemented the Waspmote sensor network. To setup the BLE communication capability of the Waspmote we used Waspmote BLE module introduced by LIbelium  [14]. For the implementation, we considered Wapmote’s in-built accelerometer generated data. This data is then transferred to Raspberry Pi over BLE. Raspberry Pi is coupled with the drone. Generally, Raspberry Pi 3 is powered by a +5.1V micro USB supply and recommended input current is 2.5A [16]. To cater these specifications we used a portable external power source coupled with Raspberry Pi. This prototype implementation was basically based on two scenarios, real time and non-real time.

To initialize the connection between Raspberry Pi and Waspmote sensors, we defined Waspmote as the master and Raspberry Pi as the slave. Therefore Waspmote sends advertising packets to Raspberry Pi through advertising attribute and then Raspberry Pi sends the connection request to Waspmote to establish the connection. Moreover, Raspberry Pi uses MAC addresses of Waspmotes to establish the connection.

The real time scenario has implemented to collect the data when the drone is within the range of sensor network. Hence in the real time scenario we created a local attribute in Waspmote for data transferring process. Therefore we programmed handler in BLE user services profile of the Waspmote to send the accelerometer sensed data to Raspberry Pi attached to the drone.

Non-real time scenario has proposed and implemented to maintain the continuity of data collection while drone was away from the sensor network. In the non-real time scenario Waspmote generates the accelerometer data and saves them into a text file in its SD memory. When the drone arrives Waspmote sends those text files through pre-defined handler as in the real time scenario.

After extracting the sensed data (real time and non-real time) from Waspmotes, Raspberry Pi saves all sensed data into a SQLite database. Hence when the drone comes to its home location, Raspberry Pi sends those saved data from SQLite database to the cloud server over HTTPS protocol. The prototype setup with equipment is illustrated in Figure 9.

Fig. 9: Prototype Implementation

V-a Cloud Integration

The last part of the implementation was to deploy the cloud storage server. As the drone arrives at the docking station after extracting the data from sensors, Raspberry Pi 3 coupled with the drone connects to the 802.11 WLAN router with internet access; to upload the locally saved sensor data. The cloud server is implemented on the Google Firebase111 where Raspberry Pi first authenticates itself using its private key. After authentication, Raspberry Pi starts uploading the sensed data to cloud and stores in the database. The Firebase Real-time Database is a cloud-hosted database. Data is stored as JSON and synchronized in real-time to every connected client. Moreover, Firebase uses HTTPS connection over Transport Layer Security for secure communications between Raspberry Pi and cloud server along with real-time database security. The database provides a flexible, expression-based rules language, to define how your data should be structured and when data can be read from or written to the database. It is capable of defining who has access to what data, and how they can access it. After successful transferring of the data, Raspberry Pi deletes the stored data from the local database.

V-B Performance Results

We used handler 0x0038 from BLE user services profile of the Waspmote to send the accelerometer sensor data to the Raspberry Pi. Handler 0x0038 is capable of creating a reliable BLE communication between Raspberry Pi and Waspmote, because it caters the master with read/write and indication operations. Maximum data size that can be transferred during a particular transmission attempt is 20 bytes. Waspmote sends those accelerometer sensor data in an encoded format which has to be decoded at Raspberry Pi to make it readable. After the decoding process, it extracts to 112 Bytes at Raspberry Pi. Hence, we consider this 112 Bytes as maximum data that can be send within one particular transmission. To obtain the performance results, we fixed the drone’s flying altitude as 10 m above the ground level.

For the data download scenario (i. e. the transmission from Raspberry Pi to Waspmote) we used handler 0x0029. Here we considered 10 seconds time duration to send the data packets over BLE from Raspberry Pi to Waspmote. The following Table II summarizes the results obtained from the experiment.

Data Rate Parameter

Data transfer rate from Waspmote to Raspberry Pi RUL
672 Bytes/min
Data transfer rate from Raspberry Pi to Waspmote RDL 148 Bytes/s

TABLE II: Experimental Data Rates

According to the results depicted in Table II , Raspberry Pi to Waspmote data download rate is higher than the Waspmote to Raspberry Pi data upload rate. With the buffer size limitation in Waspmote, Raspberry Pi is only allowed to send maximum 74 data packets (each 20 Bytes) to the Waspmote. This maximum data transmission causes to fill the buffer size at Waspmote and then it stops retrieving data from Raspberry Pi.

Vi Conclusions

The widespread of low-power IoT technologies and their sensing and monitoring applications may demand processing power at the edge of the network, rather than accessing the remote central cloud. Throughout this paper, we have addressed how to provide edge processing power in a similar manner as in dew computing architecture, for the low-power BLE sensors with the help of UAVs such as drones. We have described the protocol in detail along with the simulation and prototyping results. The key findings of the simulations are as follows: The number of served sensor nodes by the drone is directly proportional to the speed of the drone; The distance between two sensor nodes is the most dominant parameter that defines the overall performance of system; Circular and square array type sensor node topologies always outperform the linear array topology. The prototyping caused some problems due to the hardware limitations of the Wsapmotes.

We intend to extend the research by implementing a fully working prototype and measring energy consumptions in an actual WSN where the sensors are deployed in a higher density. The current experimental results are taken in an ideal situation assuming a constant drone speed by taking the wind speed as zero. In future we plan to investigate how the drone speed and the wind speed will impact on the proposed system model.


This work has been performed under the framework of three projects, 6Genesis Flagship (grant 318927) SECUREConnect (Secure Connectivity of Future Cyber-Physical Systems) and Towards Digital Paradise. This research is funded by Academy of Finland and TEKES, Finland.


  • [1] A. Al-Fuqaha, M. Guizani, M. Mohammadi, M. Aledhari, and M. Ayyash, “Internet of Things: A Survey on Enabling Technologies, Protocols, and Applications,” IEEE Communications Surveys & Tutorials, vol. 17, no. 4, pp. 2347–2376, 2015.
  • [2] O. Bello and S. Zeadally, “Intelligent Device-to-Device Communication in the Internet of Things,” IEEE Systems Journal, vol. 10, no. 3, pp. 1172–1182, 2016.
  • [3]

    W. Shi, J. Cao, Q. Zhang, Y. Li, and L. Xu, “Edge computing: Vision and Challenges,”

    IEEE Internet of Things Journal, vol. 3, no. 5, pp. 637–646, 2016.
  • [4] P. Porambage, J. Okwuibe, M. Liyanage, M. Ylianttila, and T. Taleb, “Survey on Multi-Access Edge Computing for Internet of Things Realization,” IEEE Communications Surveys Tutorials, 2018.
  • [5] Y. Wang, “Definition and Categorization of Dew Computing,” Open Journal of Cloud Computing (OJCC), vol. 3, no. 1, pp. 1–7, 2016.
  • [6] Y. Wang, K. Skala, A. Rindos, M. Gusev, S. Yang, and Y. PAN, “Dew Computing and Transition of Internet Computing Paradigms,” ZTE COMMUNICATIONS, vol. 15, no. 4, 2017.
  • [7] N. Xia, H.-H. Chen, and C.-S. Yang, “Radio Resource Management in Machine-to-Machine Communications-A Survey,” IEEE Communications Surveys & Tutorials, 2017.
  • [8] P. Porambage, A. Manzoor, M. Liyanage, A. Gurtov, and M. Ylianttila, “Managing Mobile Relays for Secure E2E Connectivity of Low-Power IoT Devices,” in IEEE Consumer Communications & Networking Conference, 2019.
  • [9] A. Manzoor, P. Porambage, M. Liyanage, M. Ylianttila, and A. Gurtov, “Mobile Relay Architecture for Low-Power IoT Devices,” in IEEE 19th International Symposium on” A World of Wireless, Mobile and Multimedia Networks”(WoWMoM), 2018, pp. 14–16.
  • [10] Y. Zeng, R. Zhang, and T. J. Lim, “Wireless Communications with Unmanned Aerial Vehicles: Opportunities and Challenges,” IEEE Communications Magazine, 2016.
  • [11] Y. Wang, “Cloud-Dew Architecture,” International Journal of Cloud Computing, vol. 4, no. 3, pp. 199–210, 2015.
  • [12] R. Heydon, Bluetooth Low Energy: The Developer’s Handbook.   Prentice Hall Upper Saddle River, NJ, 2013, vol. 1.
  • [13] “DJI Specs.” [Online]. Available:
  • [14] “Libelium.” [Online]. Available:
  • [15] “Practical BLE Throughput.” [Online]. Available:
  • [16] “Raspberry Pi Power.” [Online]. Available: